Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/15/21 10:31 PM, Adrian Chadd wrote: Hi! So, my Lenovo T540p also doesn't work right now; it just panics the kernel with a NULL pointer deref inside some deferred interrupt registration / callback thing. I move the taskqueue calls as you advice. Can you try the last version from GitHub (2.0i). Henri If I disable it at the boot console then it's fine. -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/14/21 5:05 PM, Marc Veldman wrote: On 14 May 2021, at 16:48, Gary Jennejohn wrote: On Fri, 14 May 2021 16:21:05 +0200 Marc Veldman wrote: On 14 May 2021, at 10:22, Henri Hennebert wrote: Please test the 2.0h version from GitHub. On my Lenovo P50s: Cold boot with card not inserted: OK Insert card after boot, no crash, but the message seems weird: May 14 16:01:27 supernovo kernel: rtsx0: Interrupt card inserted/removed May 14 16:01:27 supernovo kernel: rtsx0: Card absent May 14 16:01:27 supernovo kernel: mmc0: detached Cold boot with card inserted: OK Remove card after boot, no crash, but the message seems weird: May 14 16:06:08 supernovo kernel: rtsx0: Interrupt card inserted/removed May 14 16:06:08 supernovo kernel: rtsx0: Card present May 14 16:06:08 supernovo kernel: mmc0: on rtsx0 I have the inversion flag turned on /boot/loader.conf dev.rtsx.0.inversion=1 dev.rtsx.0.debug=1 This is weird because the man page states that the inversion flag is required with the P50. BTW Henri, if you're reading this, there's a bug in exactly this part of the man page: sovled rather than solved Thank you for the hint - will be corrected in the next push. But, the trace output indicates that you do not need the inversion flag. Maybe your P50 (may be a later model than the P50s tested during driver development) does not have the problem. I removed the flag, and it works now.Thanks! What is it in the trace that indicated that the inversion flag is not needed? In Bug 255130 they ask me to automate the inversion. I do it for the P50s and T470p following informations from Bug 204521. But strangely it is not applicable to this particular P50s. So, as indicated in my previous mail, it must be nullify with dev.rtsx.0.inversion=0. To investigate this last problem can you send kenv | grep smbios.system and dmesg|grep rtsx for the setup that work for you. Thanks Henri Best Regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: More rtsx issues (13.0-R system) was: Re: CURRENT crashes at early boot on Lenovo T540p...
On 5/13/21 9:00 PM, Rodney W. Grimes wrote: On 12.05.2021 21:01, Marc Veldman wrote: I?m not sure if this is an interesting data point or not, but a warm boot without the card inserted succeeds after a cold boot with the card inserted. It could explain, why my tests with "same code path" gave different results! I am suspect of 2 things here, something the bios does that leaves the card in a state that alters the loader's disk probing, and that probling itself leaving the device in a state that our kernel does not like. I have it very "odd" that I can boot from a rtsx sd card, ie the kernel gets loaded, but fails at "mountroot" phase due to a sd card timeout. I am baffled that the loader can read the SD card from a RTS525A. Can you detail the boot process and the SD card partitions. Please show kenv | grep smbios.system and pciconf -lvbc Anyway can you use the driver from GitHub - version 2.0h so we start with something that work for others. Henri If I simply cycle the sd card in and out of its socket and then give the right command string to mountroot it goes on to multiuser without issue. I'll also note that if I am booting from other disks (nvme or usb) that I get these same sd card timeouts and I have to cycle the card in and out of the socket to use it: rtsx0: <2.0c Realtek RTS525A PCI MMC/SD Card Reader> mem 0xe100-0xe1000fff irq 18 at device 0.0 on pci3 rtsx0: pci_read_config() error - reg: 0xeeaa rtsx0: Card present mmc0: on rtsx0 rtsx0: CRC error rtsx0: Transfer fail - status: 0x90010080 rtsx0: CRC error rtsx0: Transfer fail - status: 0x90010080 rtsx0: CRC error rtsx0: Transfer fail - status: 0x90010080 rtsx0: CRC error rtsx0: Transfer fail - status: 0x90010080 rtsx0: Interrupt card inserted/removed rtsx0: Card absent rtsx0: Interrupt card inserted/removed rtsx0: Card present mmc0: on rtsx0 (The last 5 lines caused by me removeing/inserting the card) Further note that this is a different controller chip version, from a Dell E5470: rtsx0@pci0:3:0:0: class=0xff rev=0x01 hdr=0x00 vendor=0x10ec device=0x525a subvendor=0x1028 subdevice=0x06de vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS525A PCI Express Card Reader' bar [14] = type Memory, range 32, base 0xe100, size 4096, enabled cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[90] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[b0] = PCI-Express 2 endpoint max data 256(512) RO max read 512 link x1(x1) speed 5.0(5.0) ASPM disabled(L0s/L1) ClockPM enabled ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0003[148] = Serial 1 0001004ce000 ecap 0018[158] = LTR 1 ecap 001e[160] = L1 PM Substates 1 // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 7:55 PM, Lev Serebryakov wrote: On 13.05.2021 18:56, Henri Hennebert wrote: So if I understand correctly, your problem is solved. Stupid me. I didn't check card insertion/removal after boot. Card REMOVAL when boot was WITH CARD: Instant panic: rtsx0: Interrupt card inserted/removed rtsx0: Card absent panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:3045 cpuid = 3 time = 1620928154 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c6a989c0 vpanic() at vpanic+0x181/frame 0xfe00c6a98a10 panic() at panic+0x43/frame 0xfe00c6a98a70 __mtx_assert() at __mtx_assert+0xb0/frame 0xfe00c6a98a80 device_detach() at device_detach+0x2e/frame 0xfe00c6a98ac0 device_delete_child() at device_delete_child+0x15/frame 0xfe00c6a98ae0 rtsx_card_task() at rtsx_card_task+0xfa/frame 0xfe00c6a98b00 taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfe00c6a98b80 taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 0xfe00c6a98bb0 fork_exit() at fork_exit+0x80/frame 0xfe00c6a98bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c6a98bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Card INSERTION when boot was WITHOUT CARD: Instant panic: rtsx0: Interrupt card inserted/removed rtsx0: Card present panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:2944 cpuid = 1 time = 1620928312 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c6a98a10 vpanic() at vpanic+0x181/frame 0xfe00c6a98a60 panic() at panic+0x43/frame 0xfe00c6a98ac0 __mtx_assert() at __mtx_assert+0xb0/frame 0xfe00c6a98ad0 device_probe_and_attach() at device_probe_and_attach+0x2a/frame 0xfe00c6a98b00 taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfe00c6a98b80 taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 0xfe00c6a98bb0 fork_exit() at fork_exit+0x80/frame 0xfe00c6a98bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c6a98bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Both panics are "debuggable", as keyboard is working in ddb and crash dump could be created. And I'm not sure, that GIANT in 2021 is good thing. Please test the 2.0h version from GitHub. Henri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 7:25 PM, Marc Veldman wrote: On 13 May 2021, at 17:56, Henri Hennebert wrote: On 5/13/21 5:51 PM, Lev Serebryakov wrote: On 13.05.2021 18:38, Henri Hennebert via freebsd-current wrote: This seems a good news. Can you replace sys/dev/rtsx.c by the latest version (2.0g) from https://github.com/hlh-restart/rtsx I reduce the DELAY to 25 and make some other updates waiting in the pipeline. I've replaced two files in /usr/src/sys/dev/rtsx, rebuilt GENERIC kernel and it boots! Output WITHOUT card is like this: pci2: on pcib2 rtsx0: <2.0g Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf450-0xf4500fff at device 0.0 on pci2 rtsx0: We are running with inversion: 0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent rtsx0: No card is detected pcib3: at device 28.1 on pci0 Output WITH card is like this: pci2: on pcib2 rtsx0: <2.0g Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf450-0xf4500fff at device 0.0 on pci2 rtsx0: We are running with inversion: 0 rtsx0: Interrupt card inserted/removed rtsx0: Card present rtsx0: A card is detected mmc0: on rtsx0 pcib3: at device 28.1 on pci0 ... mmcsd0: 16GB at mmc0 50.0MHz/4bit/2048-block ... No visible delays in both cases. Both boots are "cold", with AC cycle So if I understand correctly, your problem is solved. On my laptop (Lenovo P50s) the laptop now boots fine with and without the card inserted, but it panics immediately on insertion or removal of the card, unfortunately. 1) #dev.rtsx.0.inversion=“1" commented out in boot/loader.conf. 1.a) Booting with the card works. When I remove the card a few minutes after boot I get a panic: Unread portion of the kernel message buffer: rtsx0: Interrupt card inserted/removed rtsx0: Card present panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:2944 cpuid = 3 time = 1620924849 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c6780910 vpanic() at vpanic+0x181/frame 0xfe00c6780960 panic() at panic+0x43/frame 0xfe00c67809c0 __mtx_assert() at __mtx_assert+0xb0/frame 0xfe00c67809d0 device_probe_and_attach() at device_probe_and_attach+0x2a/frame 0xfe00c6780a00 taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfe00c6780a80 taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 0xfe00c6780ab0 fork_exit() at fork_exit+0x80/frame 0xfe00c6780af0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c6780af0 --- trap 0, rip = 0, rsp = 0, rbp = 0 — Really strange, on my configuration, under 13.0-STABLE (stable/13-n245247-53c0fd84096) all was working smoothly. I switch back to taskqueue_swi_giant. Please test from GitHub version 2.0h. I am also interested by the output of kenv | grep smbios.system I think that in your case (P50s) inersion is not needed and you must add dev.rtsx.0.inversion=0 in loader.conf The inversion heuristic is not working for you. Please show the rtsx lines from dmesg. 1.b) Booting without the card works, when I insert the card I get the same panic. 2) With ndev.rtsx.0.inversion="1" Now enabled in /boot/loader.conf 2a) Booting with the card inserted works, but when I remove the card I get the above panic. 2b) Booting without the card inserted works, but when Insert the card I get the above panic. I will push this new version to current, but it will take some time because I am not a committer. A minor thing about the patch/change. I suspect the delay is a quarter of a second, not half as stated in the comments. Thanks, I forget to update the comment when I switch from 50 to 25. Again, thank you very much for your work on this! Best regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 5:51 PM, Lev Serebryakov wrote: On 13.05.2021 18:38, Henri Hennebert via freebsd-current wrote: This seems a good news. Can you replace sys/dev/rtsx.c by the latest version (2.0g) from https://github.com/hlh-restart/rtsx I reduce the DELAY to 25 and make some other updates waiting in the pipeline. I've replaced two files in /usr/src/sys/dev/rtsx, rebuilt GENERIC kernel and it boots! Output WITHOUT card is like this: pci2: on pcib2 rtsx0: <2.0g Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf450-0xf4500fff at device 0.0 on pci2 rtsx0: We are running with inversion: 0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent rtsx0: No card is detected pcib3: at device 28.1 on pci0 Output WITH card is like this: pci2: on pcib2 rtsx0: <2.0g Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf450-0xf4500fff at device 0.0 on pci2 rtsx0: We are running with inversion: 0 rtsx0: Interrupt card inserted/removed rtsx0: Card present rtsx0: A card is detected mmc0: on rtsx0 pcib3: at device 28.1 on pci0 ... mmcsd0: 16GB at mmc0 50.0MHz/4bit/2048-block ... No visible delays in both cases. Both boots are "cold", with AC cycle So if I understand correctly, your problem is solved. I will push this new version to current, but it will take some time because I am not a committer. Henri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 5:09 PM, Lev Serebryakov wrote: On 13.05.2021 17:22, Henri Hennebert wrote: try to rebuild your kernel with the attached patch. Nope, same panic after cold (power-cycle) boot. Can you try with "DELAY(50);" to see if this is a path to dig further. It helps with panic! What do you mean? Does it display "card present" before the interrupt ? It doesn't panic, boots and works more than 500 seconds :-) Output is like this: pcib2: at device 28.0 on pci0 pci2: on pcib2 rtsx0: <2.0c Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf450-0xf4500fff at device 0.0 on pci2 rtsx0: Interrupt card inserted/removed rtsx0: Card absent rtsx0: Card absent pcib3: at device 28.1 on pci0 pci3: on pcib3 (no visible pause between two "Card absent" lines). This seems a good news. Can you replace sys/dev/rtsx.c by the latest version (2.0g) from https://github.com/hlh-restart/rtsx I reduce the DELAY to 25 and make some other updates waiting in the pipeline. Thank you for your time Henri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 4:18 PM, Lev Serebryakov wrote: On 13.05.2021 16:40, Henri Hennebert wrote: try to rebuild your kernel with the attached patch. Nope, same panic after cold (power-cycle) boot. Can you try with "DELAY(50);" to see if this is a path to dig further. It helps with panic! What do you mean? Does it display "card present" before the interrupt ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 3:30 PM, Lev Serebryakov wrote: On 13.05.2021 15:48, Henri Hennebert via freebsd-current wrote: rtsx0: <2.0c .> rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent ... This must be the culprit this change from present/absent PANIC! (without rtsx0 in stacktrace, again it is run_interrupt_driven_config_hooks()). if you can't see the verbose output which is too fast on the display: try a boot -p Oooops, keyboard is unresponsive after first pause and I can not unpause output :-( Looks like another bug of early boot — EFI boot can not access keywboard before it is detected as `atkbd` (keyboard in loader works!) try to rebuild your kernel with the attached patch. Nope, same panic after cold (power-cycle) boot. Can you try with "DELAY(50);" to see if this is a path to dig further. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 2:40 PM, Lev Serebryakov wrote: On 13.05.2021 15:13, Henri Hennebert via freebsd-current wrote: I’m not sure if this is an interesting data point or not, but a warm boot without the card inserted succeeds after a cold boot with the card inserted. It could explain, why my tests with "same code path" gave different results! With a "cold" boot and without a card inserted did you see something like: rtsx0: <2.0c Realtek ... rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent When it panics, it panics before rtsx0 prints something in my case. Does iwm0 / mmc0 is shown during boot? can you try a verbose boot (boot -s) do you mean "boot -v"? :) It runs very fast, and there are not so much lines on the screen (is it possible to change screen reoslution before loading i915kms?) OUPS yes boot -v Ok, now I've recorded cold boot without SD, without verbose, with my phone (yes, screenshots by photocamera, I fell so low!) and I was wrong, there is rtsx0: rtsx0: <2.0c .> rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent ... This must be the culprit this change from present/absent PANIC! (without rtsx0 in stacktrace, again it is run_interrupt_driven_config_hooks()). if you can't see the verbose output which is too fast on the display: try a boot -p Oooops, keyboard is unresponsive after first pause and I can not unpause output :-( Looks like another bug of early boot — EFI boot can not access keywboard before it is detected as `atkbd` (keyboard in loader works!) try to rebuild your kernel with the attached patch. diff --git a/sys/dev/rtsx/rtsx.c b/sys/dev/rtsx/rtsx.c index 4400fbef541..a2410d76fe8 100644 --- a/sys/dev/rtsx/rtsx.c +++ b/sys/dev/rtsx/rtsx.c @@ -3715,7 +3715,7 @@ rtsx_attach(device_t dev) * Schedule a card detection as we won't get an interrupt * if the card is inserted when we attach */ - DELAY(500); + DELAY(1000); if (rtsx_is_card_present(sc)) device_printf(sc->rtsx_dev, "Card present\n"); else ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 2:01 PM, Lev Serebryakov wrote: On 13.05.2021 14:35, Henri Hennebert wrote: I’m not sure if this is an interesting data point or not, but a warm boot without the card inserted succeeds after a cold boot with the card inserted. It could explain, why my tests with "same code path" gave different results! With a "cold" boot and without a card inserted did you see something like: rtsx0: <2.0c Realtek ... rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent When it panics, it panics before rtsx0 prints something in my case. Does iwm0 / mmc0 is shown during boot? can you try a verbose boot (boot -s) if you can't see the verbose output which is too fast on the display: try a boot -p Henri PS Thanks for your time ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 1:58 PM, Marc Veldman wrote: On 13 May 2021, at 11:49, Henri Hennebert wrote: ... ... Do you see an rtsx message before this mmc0 ? mmc0: detached ugen0.1: <0x8086 Yes. rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem 0xf410-0xf4100fff at device 0.0 on pci1> rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent The "card present" and just after the iterrupt and "card absent" seems strange... Can you please show the dmesg after a warm reboot with no card inserted. Dmesg below: It is a slightly modified kernel with a few debug printfs in them. ---<>--- Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.0-CURRENT #3 main-n246598-30659d1dcbc-dirty: Thu May 13 06:14:52 CEST 2021 marc@devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1920x1080 CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.08-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 <---clip---> pci1: on pcib1 rtsx0: <2.0c Realtek RTS522A PCI MMC/SD Card Reader> mem 0xf410-0xf4100fff at device 0.0 on pci1 rtsx0: Card absent pcib2: at device 28.2 on pci0 Just what I was thinking: in this case the card status is found correctly without an interrupt. In the "cold" case an interrupt change the card present/absent status, a taskqueue is scheduled. I am digging there... Thanks for your time! henri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 1:31 PM, Lev Serebryakov wrote: On 12.05.2021 21:01, Marc Veldman wrote: I’m not sure if this is an interesting data point or not, but a warm boot without the card inserted succeeds after a cold boot with the card inserted. It could explain, why my tests with "same code path" gave different results! With a "cold" boot and without a card inserted did you see something like: rtsx0: <2.0c Realtek ... rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/13/21 6:00 AM, Marc Veldman wrote: On 12 May 2021, at 20:49, Henri Hennebert wrote: On 5/12/21 8:01 PM, Marc Veldman wrote: On 12 May 2021, at 18:06, Henri Hennebert wrote: On 5/12/21 5:04 PM, Marc Veldman wrote: Unfortunately I can only say “me too”, but on a different Lenovo laptop. I’ve put my diagnostics in this thread, with the SVN revision in which it seems to have broken. https://docs.freebsd.org/cgi/getmsg.cgi?fetch=327822+0+archive/2020/freebsd-current/20201227.freebsd-current I your first message on the thread I see "mmc0: detached" do you have the previous lines of the dmesg? This is what I can see on the display: (Copied by hand, so there might be some typos) pcib2: at device 28.2 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: at device 29.0 on pci0 pci3: on pcib3 vgapci1: port 0xd000-0xd07f mem 0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xf424-0xf4243fff,0xf423-0xf423 at device 31.3 on pci0 em0: mem 0xf420-0xf421 at device 31.6 on pci0 em0: Using 1024 TX descriptors and 1024 RX descriptors em0: Using an MSI interrupt em0: Ethernet address: 54:ee:75:cb:0d:e3 em0: netmap queues/slots: TX 1/1024, RX 1/1024 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0. psm0: model Synaptics Touchpad, device ID 0 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc-0xc pnpid ORM on isa0 hwpstate_intel0: on cpu0 hwpstate_intel1: on cpu1 hwpstate_intel2: on cpu2 hwpstate_intel3: on cpu3 Timecounters tick every 1.000 msec ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Do you see an rtsx message before this mmc0 ? mmc0: detached ugen0.1: <0x8086 Yes. rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem 0xf410-0xf4100fff at device 0.0 on pci1> rtsx0: Card present mmc0: on rtsx0 rtsx0: Interrupt card inserted/removed rtsx0: Card absent The "card present" and just after the iterrupt and "card absent" seems strange... Can you please show the dmesg after a warm reboot with no card inserted. pcib2: ad device 28.2 on pci0 … (continue as above, with panic) Note: The card is not inserted. XHCI root HUB> at usbus0 Fatal trap 9: general protection fault while in kernel mode cupid = 3; apic id = 03 …. …. I’m not sure if this is an interesting data point or not, but a warm boot without the card inserted succeeds after a cold boot with the card inserted. This remind me of a case of rebooting FreeBSD after a window session. I will check in my mail archive... Thank you for your time Best regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/12/21 8:01 PM, Marc Veldman wrote: On 12 May 2021, at 18:06, Henri Hennebert wrote: On 5/12/21 5:04 PM, Marc Veldman wrote: Unfortunately I can only say “me too”, but on a different Lenovo laptop. I’ve put my diagnostics in this thread, with the SVN revision in which it seems to have broken. https://docs.freebsd.org/cgi/getmsg.cgi?fetch=327822+0+archive/2020/freebsd-current/20201227.freebsd-current I your first message on the thread I see "mmc0: detached" do you have the previous lines of the dmesg? This is what I can see on the display: (Copied by hand, so there might be some typos) pcib2: at device 28.2 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: at device 29.0 on pci0 pci3: on pcib3 vgapci1: port 0xd000-0xd07f mem 0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xf424-0xf4243fff,0xf423-0xf423 at device 31.3 on pci0 em0: mem 0xf420-0xf421 at device 31.6 on pci0 em0: Using 1024 TX descriptors and 1024 RX descriptors em0: Using an MSI interrupt em0: Ethernet address: 54:ee:75:cb:0d:e3 em0: netmap queues/slots: TX 1/1024, RX 1/1024 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0. psm0: model Synaptics Touchpad, device ID 0 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc-0xc pnpid ORM on isa0 hwpstate_intel0: on cpu0 hwpstate_intel1: on cpu1 hwpstate_intel2: on cpu2 hwpstate_intel3: on cpu3 Timecounters tick every 1.000 msec ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Do you see an rtsx message before this mmc0 ? mmc0: detached ugen0.1: <0x8086 XHCI root HUB> at usbus0 Fatal trap 9: general protection fault while in kernel mode cupid = 3; apic id = 03 …. …. I’m not sure if this is an interesting data point or not, but a warm boot without the card inserted succeeds after a cold boot with the card inserted. This remind me of a case of rebooting FreeBSD after a window session. I will check in my mail archive... Thank you for your time Best regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/12/21 5:04 PM, Marc Veldman wrote: Unfortunately I can only say “me too”, but on a different Lenovo laptop. I’ve put my diagnostics in this thread, with the SVN revision in which it seems to have broken. https://docs.freebsd.org/cgi/getmsg.cgi?fetch=327822+0+archive/2020/freebsd-current/20201227.freebsd-current I your first message on the thread I see "mmc0: detached" do you have the previous lines of the dmesg? I’m willing to help debug the issue if someone can give me some pointers. Best regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/12/21 5:04 PM, Marc Veldman wrote: Unfortunately I can only say “me too”, but on a different Lenovo laptop. I’ve put my diagnostics in this thread, with the SVN revision in which it seems to have broken. https://docs.freebsd.org/cgi/getmsg.cgi?fetch=327822+0+archive/2020/freebsd-current/20201227.freebsd-current I’m willing to help debug the issue if someone can give me some pointers. Just to try something: Does disabling the WIFI in the BIOS (if possible at all) allow a clean boot with rtsx in the kernel config? can you also try a boot with a card inserted as in case (2) of Lev tests. Best regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/12/21 2:46 PM, Lev Serebryakov wrote: On 12.05.2021 13:01, Henri Hennebert via freebsd-current wrote: It would be fine if you can test the driver with dev.rtsx.0.inversion=1 in loader.conf and see it it solve the problem. the output of sysctl dev.rtsx and kenv | grep smbios.system would be useful BTW is a dummy card inserted in the SD slot? Thank for your time My T540p: (1) rtsx in the kernel, enabled in BIOS, no settings in loader.conf, EMPTY SLOT — panic on boot, typically WITHOUT rtsx in stack trace. (2) rtsx in the kernel, enabled in BIOS, no settings in loader.conf, SD CARD IN THE SLOT — no panic on boot, but WiFi card detected too late for startup scripts to run wpa_supplicant properly. (3) rtsx in the kernel, enabled in BIOS, "dev.rtsx.0.inversion=1", SD CARD IN THE SLOT — no panic on boot, but WiFi card detected too late for startup scripts to run wpa_supplicant properly. And card reporting is inverted related to real deal: rtsx0 reports "Card present" when I remove card and vice versa. (4) rtsx in the kernel, disabled in BIOS — device not found, everything (but SD reader) boots & works (as expected!) (5) rtsx in the kernel, enabled in BIOS, "dev.rtsx.0.inversion=1", EMPTY SLOT — boots, but prints out "timeout for CMD8/55/1" for very long time and *console*is*not*accessible* till "no compatible cards found on bus". ALSO (!) wifi card is found only AFTER all these timeouts, when startup scripts are FAILED to attach to wireless network (!!!). ALSO (!) it says "Card Absent" when I *INSERT* card after boot, and "Card present" (+ a lot of timeouts again) when I *REMOVE* card, looks like this "inversion" is wrong for my hardware. So, it boots, but practically unusable. (6) rtsx in the kernel, enabled in BIOS, "dev.rtsx.0.inversion=1", SD CARD IN THE SLOT (7) rtsx is loaded as module after boot (manually, from console), enabled in BIOS, no setting in loader.conf — looks to work properly. Card could be mounted, read/write, it works. (9) rtsx is loaded as module after boot (manually, from console), enabled in BIOS, "dev.rtsx.0.inversion=1" — don't panic, but thinks wrong about card state (Card Present/Absent is inverted, as instructed). My theory: rtsx detect/attach code has some race conditions / incompatibilities for multi-core boot when card is not present, and it thrash kernel memory and/or block something on boot. "inversion" removes this bad behavior due to waiting for card commands (as with "inversion" it thinks card is here and try to access it). Firts, thank you for your exhaustive testing! Your analysis seems pertinent for me. What seems strange: case (1) and (3) follow the same path in the driver but (1) produce a panic. See (2), (3) and (4) — when rtsx doesn't cause panic on boot, it still mangle other devices detection & initialization. booting in case (2) can you show the output of pciconf -lvbc and vmstat -i I could provide any additional information. Unfortunately, memory dump of panic-on-boot is impossible :-( ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/12/21 11:27 AM, Sergey V. Dyatko wrote: On Fri, 7 May 2021 18:53:03 +0300 Gleb Popov wrote: Just to add to this thread: I'm running CURRENT with rtsx device and driver and it works fine for me. I had to remove (nodevice rtsx) from GENERIC because of slw OS boot, it is trying to probe sd card long enough IMHO it wasn't good idea to include it to GENERIC kernel Maybe... it is the Chicken and egg paradox without visibility it can't be improved. It would be fine if you can test the driver with dev.rtsx.0.inversion=1 in loader.conf and see it it solve the problem. the output of sysctl dev.rtsx and kenv | grep smbios.system would be useful BTW is a dummy card inserted in the SD slot? Thank for your time Henri -- wbr, Sergey ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
On 5/7/21 2:01 PM, Lev Serebryakov wrote: On 07.05.2021 14:36, Lev Serebryakov wrote: Looks like there is problem with rtsx driver! Oh, I forgot to add: disabling SD Card Reader in BIOS solves problem! And console on these crashes is totally dead, and disks are not detected yet, so I can not look at structures in memory and/or dump core. 13.0-RELEASE installation media crashes in same way if SD reader is enabled in BIOS. During kernel boot hit space. At prompt try set hint.rtsx.0.disabled="1" boot show if it save your boot to 13.0 Henri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building virtualbox-ose-kmod
On 1/26/21 9:13 AM, Mark Millard via freebsd-current wrote: monochrome monochrome at twcny.rr.com wrote on Tue Jan 26 06:34:23 UTC 2021 : . . . for quite a while now, maybe over a month . . . --- memobj-r0drv-freebsd.o --- /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80: error: too few arguments to function call, expected 6, have 5 int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE); ~~ ^ /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, ^ 1 error generated. *** [memobj-r0drv-freebsd.o] Error code 1 The change from 5 parameters to 6 parameters is recent: main's 0659df6faddf as of 2021-01-12 23:35:22 + (commit). Its one line description is: QUOTE vm_map_protect: allow to set prot and max_prot in one go END QUOTE It added a "int flags" parameter. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252952 is about: vm_map_protect manual page requires an update after 0659df6faddf . . . (So if there was a problem about a month ago, there may be another problem as well as the above that was something else, the above just happens first now.) Looks like emulators/virtualbox-ose-kmod needs to track the kernel change(s). See solution in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252675 Henri ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
