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 <hlh_at_restart.be> 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 250000 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: <ACPI PCI bus> on pcib2
>>> rtsx0: <2.0g Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf4500000-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: <ACPI PCI-PCI bridge> at device 28.1 on pci0
>>>   Output WITH card is like this:
>>> pci2: <ACPI PCI bus> on pcib2
>>> rtsx0: <2.0g Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf4500000-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: <MMC/SD bus> on rtsx0
>>> pcib3: <ACPI PCI-PCI bridge> at device 28.1 on pci0
>>> ...
>>> mmcsd0: 16GB <SDHC SDC   1.0 SN 0000056F MFG 01/2012 by 116 JE> 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 0xfffffe00c6780910
> vpanic() at vpanic+0x181/frame 0xfffffe00c6780960
> panic() at panic+0x43/frame 0xfffffe00c67809c0
> __mtx_assert() at __mtx_assert+0xb0/frame 0xfffffe00c67809d0
> device_probe_and_attach() at device_probe_and_attach+0x2a/frame 0xfffffe00c6780a00
> taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfffffe00c6780a80
> taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 0xfffffe00c6780ab0
> fork_exit() at fork_exit+0x80/frame 0xfffffe00c6780af0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c6780af0
> --- 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 500000 to 250000.
> 
> Again, thank you very much for your work on this!
> 
> Best regards,
> 
> Marc Veldman
> 
>