Re: smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited
> Am 31.01.2022 um 21:13 schrieb Yuri : > > Got this panic after booting GENERIC kernel: > Probably best to open a PR. It usually gets assigned to the microchip-people - I’m not sure if they are following the mailing-lists.
Re: POLLHUP detected on devd socket
On Fri, Jan 28, 2022 at 02:54:25AM +, tech-lists wrote: On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote: Will try to play with zfsd disabled, as suggested. since reporting the issue and disabling zfsd, the problem has not re-occurred so far at this time (28th Jan) It's happened again. But with zfsd being disabled, it meant I wasn't detecting the problem except by indirect means. Like "hm why isn't nginx working". The problem is, one of the things that stops first is syslogd. So it's not recorded anywhere. syslogd is loaded with these flags: syslogd_enable="YES" syslogd_flags="-ss" syslogd_oomprotect="YES" context is main-n252544-7406ec4ea99 on a rpi4b/8GB. zfs-on-root. There is no microsd; it boots from usb3. How would I debug this? In the meantime, I'm re-enabling zfsd. thanks, -- J. signature.asc Description: PGP signature
Re: randomdev hangs during initial boot of -current on Raspberry Pi
Mike Karels wrote on Date: Mon, 31 Jan 2022 12:27:41 -0600 : > A bisect > would be rather laborious, building a modified SD card each time, > even if just testing kernel changes. Any other suggestions? Historically I've used: https://artifact.ci.freebsd.org/snapshot/main/?C=M=D and the likes of kernel.txz (or more) from, for example: https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M=D to update just the kernel (or whatever) and rebooted. (It can help to have a somewhat older world that is left in place instead of running newer worlds on older kernels. Avoiding needing got update world as well has been helpful when testing for kernel issues.) This avoids building the kernels and allows a somewhat bisect like activity until some subrange has no arm64/aarch64 artifacts available. One can sometimes run into the dates for the sort for: https://artifact.ci.freebsd.org/snapshot/main/?C=M=D not matching up well with the dates on the files of interest in specific sub directoreis. (Some sort of directory update?) This can make the bisect far more difficult, given the choice to not have the directory names prefixed with text that would sort by a date/time estimate when sorted by name. (Only using the commit id/hash completely randomizes the naming.) === Mark Millard marklmi at yahoo.com
smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited
Got this panic after booting GENERIC kernel: panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 3 time = 1643658859 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c7b20ae0 vpanic() at vpanic+0x17f/frame 0xfe00c7b20b30 panic() at panic+0x43/frame 0xfe00c7b20b90 malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00c7b20bb0 malloc_domainset() at malloc_domainset+0x36/frame 0xfe00c7b20c20 bounce_bus_dmamem_alloc() at bounce_bus_dmamem_alloc+0x5b/frame 0xfe00c7b20c50 os_dma_mem_alloc() at os_dma_mem_alloc+0xe3/frame 0xfe00c7b20c90 pqisrc_build_send_raid_request() at pqisrc_build_send_raid_request+0x78/frame 0xfe00c7b20d30 pqisrc_write_current_time_to_host_wellness() at pqisrc_write_current_time_to_host_wellness+0xff/frame 0xfe00c7b20df0os_wellness_periodic() at os_wellness_periodic+0x1a/frame 0xfe00c7b20e10 softclock_call_cc() at softclock_call_cc+0x14d/frame 0xfe00c7b20ec0 softclock_thread() at softclock_thread+0xc6/frame 0xfe00c7b20ef0 fork_exit() at fork_exit+0x80/frame 0xfe00c7b20f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c7b20f30 The reason seems to be obvious enough, changing BUS_DMA_WAITOK to BUS_DMA_NOWAIT in os_dma_mem_alloc() helps.
randomdev hangs during initial boot of -current on Raspberry Pi
I hadn't updated my Raspberry Pi 4B running -current for a couple of months, so I booted the latest snapshot (Jan 27). It hangs when it does the "growfs" step, expanding the root partition and fs to fill the SD card. When it hangs, it prints this every 10 seconds or so: random: randomdev_wait_until_seeded unblock wait I waited several minutes the first time, and 20 minutes on another trial. If I hold down the return key on the serial console, the device unblocks and the boot continues. This only happens on the initial boot, when the growfs script runs. The hang happens on a Raspberry Pi 3B+ as well. It also happens with the two-week-old snapshot, but not the Nov 25 snapshot. The program that's running during the hang is awk, doing a read, according to ^T; the script uses awk to parse output from mount, glabel, and sysctl. It sounds like there is no source of entropy at this point, and there was no cache. I don't see any changes to the random device since this was working. Does anyone have a guess what to look for? A bisect would be rather laborious, building a modified SD card each time, even if just testing kernel changes. Any other suggestions? An excerpt from /var/log/messages during this time is appended. Mike Jan 27 10:38:48 generic kernel: umass0 on uhub0 Jan 27 10:38:48 generic kernel: umass0: on usbus0 Jan 27 10:38:48 generic kernel: umass0: SCSI over Bulk-Only; quirks = 0x8100 Jan 27 10:38:48 generic kernel: umass0:0:0: Attached to scbus0 Jan 27 10:38:48 generic kernel: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 Jan 27 10:38:48 generic kernel: da0: Fixed Direct Access SPC-4 SCSI device Jan 27 10:38:48 generic kernel: da0: Serial Number 40118905201B Jan 27 10:38:48 generic kernel: da0: 400.000MB/s transfers Jan 27 10:38:48 generic kernel: da0: 228936MB (468862128 512 byte sectors) Jan 27 10:38:48 generic kernel: da0: quirks=0x2 Jan 27 10:38:48 generic kernel: random: randomdev_wait_until_seeded unblock wait Jan 27 10:38:48 generic syslogd: last message repeated 48 times Jan 27 10:38:48 generic kernel: random: unblocking device. Jan 27 10:38:48 generic kernel: GEOM_PART: mmcsd0s2 was automatically resized. Jan 27 10:38:48 generic kernel: Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them. Jan 27 10:38:48 generic kernel: lo0: link state changed to UP
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On Sun, 30 Jan 2022 21:23:49 +0300 Vladimir Kondratyev wrote: > On 30.01.2022 00:25, Stefan Esser wrote: >> After rebooting with freshly built world, kernel and the amdgpu driver >> my console stopped working. It goes blank and the display goes into a >> power save mode, as soon as the amdgpu driver is loaded. >> >> The GPU (a Radeon R7 250E) is correctly detected as before, but there >> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >> >> I'm asking here and not on the ports list, since the AMDGPU driver has >> not been updated for half a year. But to be sure that there is no mismatch >> between kernel and user land, I have rebuilt all X11 server and library >> ports. >> >> There have been changes affecting the i2c driver, IIRC, and the error >> message seems to point at an issue obtaining information from the LCD >> display. > > drm-kmod commit 534aa199c10d forced it to use i2c from base. > > You may try to checkout previous revision (444dc58f0247) to find out if > in-base > i2c is guilty or not. I found that since base dbc920bd9a9b (linuxkpi interval_tree) linuxkpi.ko now exports some rb_* functions (from rbtree.h). These are declared static inline but the compiler may decide not to inline them. These functions conflict with the ones in linuxkpi_gplv2.ko from drm-kmod, because both implementations use a different order for the fields in struct rb_node.
Re: Dragonfly Mail Agent (dma) in the base system
Baptiste Daroussin writes: > Dag-Erling Smørgrav writes: > > [...] does not have a default domain setting, so it cannot handle > > email from cron, periodic etc. where the recipient is just a user > > name (usually “root”) [...] > This has been fixed since. (not by me) In that case, assuming that it behaves sensibly out of the box, my only objection is the lack of documentation, which I understand is being worked on. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Dragonfly Mail Agent (dma) in the base system
On Sun, Jan 30, 2022 at 11:25:54PM +0100, Dag-Erling Smørgrav wrote: > Ed Maste writes: > > I am interested in determining whether dma is a viable minimal base > > system MTA, and if not what gaps remain. > > It cannot. Ask bapt@ who was the one to import it, and later abandon > the idea of making it our default MTA. The reason was that it does not > have a default domain setting, so it cannot handle email from cron, > periodic etc. where the recipient is just a user name (usually “root”), > and the devs were not willing to add that feature. I have email as far > back as 2015 on the subject. > This has been fixed since. (not by me) Bapt
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On Mon, 31 Jan 2022 14:19:53 +0300 Vladimir Kondratyev wrote: > On 30.01.2022 22:43, Stefan Esser wrote: > > Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: > >> On 30.01.2022 00:25, Stefan Esser wrote: > >>> After rebooting with freshly built world, kernel and the amdgpu driver > >>> my console stopped working. It goes blank and the display goes into a > >>> power save mode, as soon as the amdgpu driver is loaded. > >>> > >>> The GPU (a Radeon R7 250E) is correctly detected as before, but there > >>> is an error message "drmn0: [drm] Cannot find any crtc or sizes". > >>> > > [...] > >>> [drm] AMDGPU Display Connectors > >>> [drm] Connector 0: > >>> [drm] DP-1 > >>> [drm] HPD4 > >>> [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 > >>> [drm] Encoders: > >>> [drm] DFP1: INTERNAL_UNIPHY2 > >>> [drm] Connector 1: > >>> [drm] HDMI-A-1 > >>> [drm] HPD1 > >>> [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f > >>> [drm] Encoders: > >>> [drm] DFP2: INTERNAL_UNIPHY2 > >>> [drm] Connector 2: > >>> [drm] DVI-I-1 > >>> [drm] HPD2 > >>> [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b > >>> [drm] Encoders: > >>> [drm] DFP3: INTERNAL_UNIPHY > >>> [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 > >>> > >>> A successful driver attach from a reboot a few days ago had ended in: > >>> > >>> [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >>> [drm] fb mappable at 0xE0503000 > >>> [drm] vram apper at 0xE000 > >>> [drm] size 33177600 > >>> [drm] fb depth is 24 > >>> [drm] pitch is 15360 > >>> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 > >>> > >>> Regards, STefan > >> > >> drm-kmod commit 534aa199c10d forced it to use i2c from base. > > > > Hi Vladimir, > > > > thank you for the information! I'm using drm-devel-kmod, and in fact found > > that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as > > 0c38674b389ad > > on 2022-01-26) causes the failure. > > > >> You may try to checkout previous revision (444dc58f0247) to find out if > >> in-base > >> i2c is guilty or not. > > > > Assuming that the same change to use the system i2c code has been in the > > latest > > commit to the drm-devel-kmod port, this should be proven, now. ;-) > > > > These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on > > an > > ASUS mainboard with B550 chip-set): > > > > $ kldstat -v | grep iic > > 68 iicsmb/smbus > > 67 iicbus/iicsmb > > 66 iichb/iicbus > > 65 iicbb/iicbus > > 64 iicbus/iic > > 63 iicbus/ic > > 213 lkpi_iicbb/iicbb > > 212 lkpi_iic/lkpi_iicbb > > 211 lkpi_iic/iicbus > > 210 drmn/lkpi_iic > > 56 iichid/hidbus > > > > Can I help debug this issue? > > > > I could re-install the latest version and boot with hw.dri.drm_debug or > > dev.drm.drm_debug set? > > > > Or are there other settings to get a debug log from the i2c side? > > > > Regards, STefan > > > > PS: I'm keeping the CC to current@, since this might be an issue in the i2c > > kernel code ... > > There are no successful lkpi_iic attachments in your output. They look like: > > lkpi_iic0: on drmn0 > > Please share your `devinfo -v` output. > Kldload output with verbose boot enabled can be helpful too. That's because this card is probably using the bitbang part. As stated in the commit this wasn't tested as I don't have compatible hardware. It's likely a timing issue in the bitbang part. That's the main reason it's only in master and 5.7 branch of drm-kmod, so people can debug/fix. -- Emmanuel Vadot
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On 30.01.2022 22:43, Stefan Esser wrote: Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: On 30.01.2022 00:25, Stefan Esser wrote: After rebooting with freshly built world, kernel and the amdgpu driver my console stopped working. It goes blank and the display goes into a power save mode, as soon as the amdgpu driver is loaded. The GPU (a Radeon R7 250E) is correctly detected as before, but there is an error message "drmn0: [drm] Cannot find any crtc or sizes". [...] [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] DVI-I-1 [drm] HPD2 [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 A successful driver attach from a reboot a few days ago had ended in: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xE0503000 [drm] vram apper at 0xE000 [drm] size 33177600 [drm] fb depth is 24 [drm] pitch is 15360 [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 Regards, STefan drm-kmod commit 534aa199c10d forced it to use i2c from base. Hi Vladimir, thank you for the information! I'm using drm-devel-kmod, and in fact found that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c38674b389ad on 2022-01-26) causes the failure. You may try to checkout previous revision (444dc58f0247) to find out if in-base i2c is guilty or not. Assuming that the same change to use the system i2c code has been in the latest commit to the drm-devel-kmod port, this should be proven, now. ;-) These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on an ASUS mainboard with B550 chip-set): $ kldstat -v | grep iic 68 iicsmb/smbus 67 iicbus/iicsmb 66 iichb/iicbus 65 iicbb/iicbus 64 iicbus/iic 63 iicbus/ic 213 lkpi_iicbb/iicbb 212 lkpi_iic/lkpi_iicbb 211 lkpi_iic/iicbus 210 drmn/lkpi_iic 56 iichid/hidbus Can I help debug this issue? I could re-install the latest version and boot with hw.dri.drm_debug or dev.drm.drm_debug set? Or are there other settings to get a debug log from the i2c side? Regards, STefan PS: I'm keeping the CC to current@, since this might be an issue in the i2c kernel code ... There are no successful lkpi_iic attachments in your output. They look like: lkpi_iic0: on drmn0 Please share your `devinfo -v` output. Kldload output with verbose boot enabled can be helpful too. -- WBR Vladimir Kondratyev
