Tried to installl new RC to my testbed machine. This is a T440p with and i5-4300M with 16GB RAM and 1TB Samsung 860 EVO. I also have an Lenovo Ultra Dock. With 12.2-RELEASE the usb stick boots no problem while laptop is attached to docking station. With 13.0-RC{1,2} it kernel panics on boot. Testing without being attached to dock allowed me to boot and install. It ran fine being docked, after being booted. Rebooting installed system while attached to docking station resulted in kernel panic once again. Attached is picture I took of the initial kernel panics.
I've heart same story about Lenovo dock in combination with T14 yesterday. You mentioned attachment, but ticket has no attachments at the moment. Can you please attach it?
Sorry bugzilla does not like pictures so here is a link to the picture I took. https://www.dropbox.com/s/asvea77kglch8wv/IMG_1618.JPEG?dl=0 Will be reinstalling and grabbing dmesg, /var/log/message when docking, and pciconf -lv when I get up.
Thank you for attachment. Panic happened inside delayed attachment of mmc after detaching of mmc (see "mmc0: detach"). Detachment of devices during boot is abnormal behaviour, but I can't explain reason why it happened. Can you please boot docked laptop with verbose option chosen in boot menu? It may bring information about detachment reason. Thanks!
Created attachment 223380 [details] dmesg.boot of T440p after install. Here is the dmesg.boot after doing install without the dock.
Created attachment 223381 [details] /var/log/messages after docking Here is the /var/log/messages after docking the laptop
Created attachment 223382 [details] pciconf -lv without docking station Here is the pciconf -lv without the docking station.
Created attachment 223383 [details] pciconf -lv with docking station Here is pciconf -lv with the docking station
Hi, Is it possible to boot laptop attached to docking station with increased verbosity? Thanks!
Created attachment 223437 [details] Panic screenshot and backtrace
Can you try to add following parameters to loader.conf? dev.rtsx.0.inversion=1 rtsx_load="YES"
Created attachment 226275 [details] panic: modified loader.conf and SD card plugged in I'm experiencing a very similar issue with my T440p, but without any docks. When I try to boot an unmodified FreeBSD-13.0-RELEASE-amd64-mini-memstick.img while the laptop's SD card slot is empty, I get the same kernel panic as https://bugs.freebsd.org/bugzilla/attachment.cgi?id=223437. (Some of the addresses are different; I can upload an image if necessary.) If I plug an SD card into the slot before booting, the unmodified image boots fine. I also tried a modified image with the lines dev.rtsx.0.inversion=1 rtsx_load="YES" added to loader.conf. With no SD card it boots successfully, but on the first installation screen these lines slowly overwrite the interface: rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD1 rtsx0: Controller timeout for CMD1 rtsx0: Controller timeout for CMD1 rtsx0: Controller timeout for CMD1 mmc0: No compatible cards found on bus iwm0: hw rev 0x140, fw ver 17.352738, address 7c:7a:91:c2:9b:56 I cannot perform any interface actions until the last line prints. When I boot the modified image with an SD card plugged in beforehand, I get the attached kernel panic.
Here is a patch that should fix this problem: https://reviews.freebsd.org/D31262 (I don't have a dock and so can't test this exact issue, but the cause is likely the same)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d5341d72a11be200e536ac7d8967449a3f521792 commit d5341d72a11be200e536ac7d8967449a3f521792 Author: Yang Zhong <yzhong@freebsdfoundation.org> AuthorDate: 2021-07-22 17:16:01 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-07-22 17:50:10 +0000 mmc: Drain the intrhook in mmc_detach() Buggy SD card drivers may attach and detach a mmc(4) driver instance in quick succession. In this case mmc(4) must disestablish its intrhook callback during detach. Thus, this change adds a call to config_intrhook_drain(), which blocks or does nothing if the intrhook is running or has already ran (the SD card was plugged in), and disestablishes the hook if it hasn't ran yet (the SD card was not plugged in). PR: 254373 Reviewed by: imp, manu, markj MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31262 sys/dev/mmc/mmc.c | 1 + 1 file changed, 1 insertion(+)
*** Bug 257293 has been marked as a duplicate of this bug. ***
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=50b26566c7f4b605d5db4464e259d7db9626dd86 commit 50b26566c7f4b605d5db4464e259d7db9626dd86 Author: Yang Zhong <yzhong@freebsdfoundation.org> AuthorDate: 2021-07-22 17:16:01 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-07-29 12:11:50 +0000 mmc: Drain the intrhook in mmc_detach() Buggy SD card drivers may attach and detach a mmc(4) driver instance in quick succession. In this case mmc(4) must disestablish its intrhook callback during detach. Thus, this change adds a call to config_intrhook_drain(), which blocks or does nothing if the intrhook is running or has already ran (the SD card was plugged in), and disestablishes the hook if it hasn't ran yet (the SD card was not plugged in). PR: 254373 Reviewed by: imp, manu, markj Sponsored by: The FreeBSD Foundation (cherry picked from commit d5341d72a11be200e536ac7d8967449a3f521792) sys/dev/mmc/mmc.c | 1 + 1 file changed, 1 insertion(+)
Resolving since the problem has been reported fixed by this change for several users, and it is triggered by rtsx, which is in 13.0 only.