CURRENT crashes at early boot on Lenovo T540p: rtsx to blame
Lev Serebryakov
Several versions of 14-CURRENT (including FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img) can not boot on Lenovo T540p 19 times out of 20.
It crashes on device detection, after detecting sound subsystem, with traps 9 and 12 (9 is more often) and mostly with this stacktrace (9 out of 10 crashes have this stacktrace:
-- trap
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()
btext()
But twice I've got more interesting stacktraces:
-- trap
strlen()
kvprintf()
vsnprintf()
vpanic()
panic()
__mtx_lock_flags()
_sleep()
mmc_wait_for_request()
mmc_wait_for_cmd()
mmc_go_discovery()
mmc_delayed_attach()
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()
btext()
--- trap
__mtx_lock_sleep()
__mtx_lock_flags()
mmc_wakeup()
rtsx_intr()
ithread_loop()
fork_exit()
fork_trampoline()
Looks like there is problem with rtsx driver!
I've checked memory with memtest86+ for 24 hours (4.5 passes) without any problems.
--
// Lev Serebryakov
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Lev Serebryakov
> 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.
Lev Serebryakov
>> 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.
Rodney W. Grimes
>
> > ?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.
I have issues with rtsx on a Dell 5740 in that if the media
in in the drive during boot it times out the rtsx probe, but
after the system is up if I eject and re-insert the media it
comes on line and works fine.
Also if I try to boot from that media it gets all the way
to mountroot, which then fails cause the device did not
pass probe, but if I eject, and reinsert and then type in
the path to root it does continue to boot and properly
start up.
--
Rod Grimes rgr...@freebsd.org
Gary Jennejohn
Lev Serebryakov <l...@FreeBSD.org> 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.
>
The only thing I can recommend is to install with the SD card reader
disabled in the BIOS.
It may be the case that rtsx still works even if the card reader is
disabled in the BIOS. That's the first thing I would try out.
If that fails then generate a kernel with rtsx as a module rather than
it being hard coded into the kernel.
You could then re-enable the SD card reader in the BIOS and load the
module to check whether the SD card reader works or causes a panic
when the moduke is loaded. This approach might make it possible to
get a crash dump if a problem occurs.
--
Gary Jennejohn (g...@freebsd.org)
Lev Serebryakov
>>>> ?? 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.
>
> Is this with or without media in the SD reader?
--
// Lev Serebryakov
Lev Serebryakov
>>>> 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.
>>
>
> I see that rtsx was added to GENERIC. Might have been premature.
>
> The only thing I can recommend is to install with the SD card reader
> disabled in the BIOS.
Yep, it works. Not only install, but booting of installed system too — any GENERIC kernel panics, even new, built by hands from latest sources.
> It may be the case that rtsx still works even if the card reader is
> disabled in the BIOS. That's the first thing I would try out.
Nope, it doesn't work (and I don't need it on this Laptop, to be honest). If SD reader is disabled in BIOS, it isn't detected at all.
> If that fails then generate a kernel with rtsx as a module rather than
> it being hard coded into the kernel.
>
> You could then re-enable the SD card reader in the BIOS and load the
> module to check whether the SD card reader works or causes a panic
> when the moduke is loaded. This approach might make it possible to
> get a crash dump if a problem occurs.
Ok, I'll try this, good idea.
BTW, I've got hints that it it rtsx-related only after ~40 crashes, as most of stack traces don't have rtsx in them and are very generic. Looks like rtsx mangle kernel memory and it crashes in other places/kernel threads.
--
// Lev Serebryakov
Gary Jennejohn
Lev Serebryakov <l...@FreeBSD.org> wrote:
> On 07.05.2021 16:22, Gary Jennejohn 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.
> >>
> >
> > I see that rtsx was added to GENERIC. Might have been premature.
> >
> > The only thing I can recommend is to install with the SD card reader
> > disabled in the BIOS.
> > It may be the case that rtsx still works even if the card reader is
> > disabled in the BIOS. That's the first thing I would try out.
> Nope, it doesn't work (and I don't need it on this Laptop, to be honest). If SD reader is disabled in BIOS, it isn't detected at all.
>
> > If that fails then generate a kernel with rtsx as a module rather than
> > it being hard coded into the kernel.
> >
> > You could then re-enable the SD card reader in the BIOS and load the
> > module to check whether the SD card reader works or causes a panic
> > when the moduke is loaded. This approach might make it possible to
> > get a crash dump if a problem occurs.
> Ok, I'll try this, good idea.
>
> BTW, I've got hints that it it rtsx-related only after ~40 crashes, as most of stack traces don't have rtsx in them and are very generic. Looks like rtsx mangle kernel memory and it crashes in other places/kernel threads.
>
was done with a loaner laptop. So, all I can offer is moral support :)
--
Gary Jennejohn (g...@freebsd.org)
Gleb Popov
I'm running CURRENT with rtsx device and driver and it works fine for me.
Jesper Schmitz Mouridsen
>
> Several versions of 14-CURRENT (including
> FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img)
> can not boot on Lenovo T540p 19 times out of 20.
>
> It crashes on device detection, after detecting sound subsystem, with
> traps 9 and 12 (9 is more often) and mostly with this stacktrace (9
> out of 10 crashes have this stacktrace:
>
https://forums.freebsd.org/threads/boot-timeout-error-on-rtsx-freebsd-13-0-hp-840-g3.80031/#post-508072
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255130
Do you happen to have an empty adapter (sd->micro sd) inserted in the
slot. That causes a card-inserted interrupt, on all the realtek sd-card
readers I have touched.
Regards
Tomoaki AOKI
dev.rtsx.0.inversion=1
in /boot/loader.conf with the device enabled on BIOS?
If not yet, it would be worth trying.
In rtsx(4) manpage,
> 〓 RTS522A on Lenovo P50s and Lenovo T470p, card detection and read-only
> switch are reversed. This is sovled by adding in loader.conf(5):
>
> dev.rtsx.0.inversion=1
If it works for you, possibly no one had tested on T540p yet.
And there can be much, much more PCs/chips which need it, but no one has
tested yet.
My rtsx driver on ThinkPad P52 works fine without it, but IIRC,
paniced with it (I did it just a test purpose when it landed).
And one more.
If you insert write-protected card and then mount it as writable,
it SHOULD certainly crash the system.
It's not a rtsx driver issue, but promised to happen.
I've encountered the problem on USB card readers, too.
>
> --
> // Lev Serebryakov
> _______________________________________________
> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
>
Tomoaki AOKI <junc...@dec.sakura.ne.jp>
Daniel Dowse
Lev Serebryakov <l...@FreeBSD.org> wrote:
>
> Several versions of 14-CURRENT (including
> FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img) can not
> boot on Lenovo T540p 19 times out of 20.
>
Hi Lev,
Just my story with SDCARD Reader.
I own a HP Elitebook 2170p. It crashed also with any Release i had used on it.
Adding
hw.sdhci.quirk_set="1"
hw.sdhci.quirk_clear="1"
hw.sdhci.enable_msi="0"
to /boot/device.hints solved the problem and the reader is usable, with GENERIC
Kernel.
-cheers
--
Daniel Dowse <freeb...@daemonbytes.net>
Lev Serebryakov
> On 07.05.2021 13.33, Lev Serebryakov wrote:
>>
>> Several versions of 14-CURRENT (including FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img) can not boot on Lenovo T540p 19 times out of 20.
>>
>> It crashes on device detection, after detecting sound subsystem, with traps 9 and 12 (9 is more often) and mostly with this stacktrace (9 out of 10 crashes have this stacktrace:
>>
> Perhaps similar to bug reported here https://forums.freebsd.org/threads/boot-timeout-error-on-rtsx-freebsd-13-0-hp-840-g3.80031/#post-508072
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255130
> Do you happen to have an empty adapter (sd->micro sd) inserted in the slot. That causes a card-inserted interrupt, on all the realtek sd-card readers I have touched. Nope, slot is empty. I'll try this combination too :).
--
// Lev Serebryakov
Lev Serebryakov
> Have you try
>
> dev.rtsx.0.inversion=1
>
> in /boot/loader.conf with the device enabled on BIOS?
Not yet :-) I'll try.
> If not yet, it would be worth trying.
>
> In rtsx(4) manpage,
>
>> 〓 RTS522A on Lenovo P50s and Lenovo T470p, card detection and read-only
>> switch are reversed. This is sovled by adding in loader.conf(5):
>>
>> dev.rtsx.0.inversion=1
>
> If it works for you, possibly no one had tested on T540p yet.
> And there can be much, much more PCs/chips which need it, but no one has
> tested yet.
>
> My rtsx driver on ThinkPad P52 works fine without it, but IIRC,
> paniced with it (I did it just a test purpose when it landed).
>
> And one more.
> If you insert write-protected card and then mount it as writable,
> it SHOULD certainly crash the system.
> It's not a rtsx driver issue, but promised to happen.
> I've encountered the problem on USB card readers, too.
My slot is empty, no card, no adapters, no plastic pseudo-card, nothing.
Henri Hennebert via freebsd-current
> 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.
At prompt try
set hint.rtsx.0.disabled="1"
boot
show if it save your boot to 13.0
Henri
Sergey V. Dyatko
Gleb Popov <arr...@freebsd.org> wrote:
> Just to add to this thread:
>
> I'm running CURRENT with rtsx device and driver and it works fine for me.
trying to probe sd card long enough
IMHO it wasn't good idea to include it to GENERIC kernel
--
wbr, Sergey
Henri Hennebert via freebsd-current
> On Fri, 7 May 2021 18:53:03 +0300
> Gleb Popov <arr...@freebsd.org> 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 sloooow OS boot, it is
> trying to probe sd card long enough
> IMHO it wasn't good idea to include it to GENERIC kernel
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
Lev Serebryakov
> 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).
See (2), (3) and (4) — when rtsx doesn't cause panic on boot, it still mangle other devices detection & initialization.
I could provide any additional information. Unfortunately, memory dump of panic-on-boot is impossible :-(
--
// Lev Serebryakov
Gary Jennejohn
Lev Serebryakov <l...@FreeBSD.org> 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:
>
>
> (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
>
> reports "Card present" when I remove card and vice versa.
>
>
> (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 (!) 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
>
>
> 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).
>
> I could provide any additional information. Unfortunately, memory dump of panic-on-boot is impossible :-(
>
land in ddb if that is set. I suppose it is, since you posted some
back trace in an earlier mail. It also seems to be the default, at
least in my FreeBSD-14 kernel.
AFAIK ddb has a command to generate a crash dump. But I can't easily
check that :(
It seems like there's a major bug when no SD card is inserted and the
driver is in the kernel. And a timing problem when a card is in the
slot at boot time.
Good to know that the module still works.
Difficult to debug without your laptop model in the hands of a developer.
--
Gary Jennejohn
Henri Hennebert via freebsd-current
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.
pciconf -lvbc
and
vmstat -i
>
> I could provide any additional information. Unfortunately, memory dump of
> panic-on-boot is impossible :-(
>
Lev Serebryakov
> Is sysctl debug.debugger_on_panic set to 1? You should automatically
> land in ddb if that is set. I suppose it is, since you posted some
> back trace in an earlier mail. It also seems to be the default, at
> least in my FreeBSD-14 kernel.
> AFAIK ddb has a command to generate a crash dump. But I can't easily
> check that :(
> It seems like there's a major bug when no SD card is inserted and the
> driver is in the kernel. And a timing problem when a card is in the
> slot at boot time.
>
> Good to know that the module still works.
>
> Difficult to debug without your laptop model in the hands of a developer.
--
// Lev Serebryakov
Gary Jennejohn
Lev Serebryakov <l...@FreeBSD.org> wrote:
> On 12.05.2021 16:34, Gary Jennejohn wrote:
>
> > Is sysctl debug.debugger_on_panic set to 1? You should automatically
> > land in ddb if that is set. I suppose it is, since you posted some
> > back trace in an earlier mail. It also seems to be the default, at
> > least in my FreeBSD-14 kernel.
>
> I see ddb report about panic, but it's all. Keyboard doesn't work, and panic occurs before any disks are detected, so there is no space for crash dump.
>
> > AFAIK ddb has a command to generate a crash dump. But I can't easily
> > check that :(
>
> Yep, but console is dead & there are no disks for crash dump at this stage.
>
Maybe you could break into boot and start it with the -d flag (see boot(8))
so that it will enter ddb as early as possible. Don't know whether you use
the boot menu or not. I always disable it.
> > It seems like there's a major bug when no SD card is inserted and the
> > driver is in the kernel. And a timing problem when a card is in the
> > slot at boot time.
> >
> > Good to know that the module still works.
>
> Yep, smoke tests for module (without inversion!) pass: I could mount R/W SD card with release image, mount FS, read and write files, unmount FS and eject card without panics and errors. I didn't try any high-load tests, though.
>
> >
> > Difficult to debug without your laptop model in the hands of a developer.
>
> It is "pretty common" (but old) Lenovo ThinkPad T540p. I could provide remote access to it, but it will not help for such low-level and early panic :-(
>
On the order of 500 Euros.
--
Gary Jennejohn
Marc Veldman
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.
Best regards,
Marc Veldman
Lev Serebryakov
Indeed. But boot panics is not 100%, it is about 95%, and I've tested each case only one time...
>
>>
>> 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
hostb0@pci0:0:0:0: class=0x060000 rev=0x06 hdr=0x00 vendor=0x8086 device=0x0c04 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller'
class = bridge
subclass = HOST-PCI
cap 09[e0] = vendor (length 12) Intel cap 0 version 1
pcib1@pci0:0:1:0: class=0x060400 rev=0x06 hdr=0x01 vendor=0x8086 device=0x0c01 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller'
class = bridge
subclass = PCI-PCI
cap 0d[88] = PCI Bridge subvendor=0x17aa subdevice=0x2210
cap 01[80] = powerspec 3 supports D0 D3 current D0
cap 05[90] = MSI supports 1 message
cap 10[a0] = PCI-Express 2 root port max data 256(256)
max read 128
link x8(x8) speed 2.5(8.0) ASPM L0s/L1(L0s/L1)
slot 1 power limit 75000 mW
ecap 0002[100] = VC 1 max VC0
ecap 0005[140] = Root Complex Link Declaration 1
ecap 0019[d94] = PCIe Sec 1 lane errors 0xfe
vgapci1@pci0:0:2:0: class=0x030000 rev=0x06 hdr=0x00 vendor=0x8086 device=0x0416 subvendor=0x17aa subdevice=0x221e
vendor = 'Intel Corporation'
device = '4th Gen Core Processor Integrated Graphics Controller'
class = display
subclass = VGA
bar [10] = type Memory, range 64, base 0xf3000000, size 4194304, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xc0000000, size 536870912, enabled
bar [20] = type I/O Port, range 32, base 0x5000, size 64, enabled
cap 05[90] = MSI supports 1 message enabled with 1 message
cap 01[d0] = powerspec 2 supports D0 D3 current D0
cap 13[a4] = PCI Advanced Features: FLR TP
hdac0@pci0:0:3:0: class=0x040300 rev=0x06 hdr=0x00 vendor=0x8086 device=0x0c0c subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller'
class = multimedia
subclass = HDA
bar [10] = type Memory, range 64, base 0xf4630000, size 16384, enabled
cap 01[50] = powerspec 2 supports D0 D3 current D0
cap 05[60] = MSI supports 1 message enabled with 1 message
cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR NS
max read 128
xhci0@pci0:0:20:0: class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c31 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family USB xHCI'
class = serial bus
subclass = USB
bar [10] = type Memory, range 64, base 0xf4620000, size 65536, enabled
cap 01[70] = powerspec 2 supports D0 D3 current D0
cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
none0@pci0:0:22:0: class=0x078000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c3a subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family MEI Controller'
class = simple comms
bar [10] = type Memory, range 64, base 0xf4639000, size 16, enabled
cap 01[50] = powerspec 3 supports D0 D3 current D0
cap 05[8c] = MSI supports 1 message, 64 bit
em0@pci0:0:25:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x153a subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = 'Ethernet Connection I217-LM'
class = network
subclass = ethernet
bar [10] = type Memory, range 32, base 0xf4600000, size 131072, enabled
bar [14] = type Memory, range 32, base 0xf463f000, size 4096, enabled
bar [18] = type I/O Port, range 32, base 0x5080, size 32, enabled
cap 01[c8] = powerspec 2 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 13[e0] = PCI Advanced Features: FLR TP
ehci0@pci0:0:26:0: class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c2d subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family USB EHCI'
class = serial bus
subclass = USB
bar [10] = type Memory, range 32, base 0xf463e000, size 1024, enabled
cap 01[50] = powerspec 2 supports D0 D3 current D0
cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
cap 13[98] = PCI Advanced Features: FLR TP
hdac1@pci0:0:27:0: class=0x040300 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c20 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset High Definition Audio Controller'
class = multimedia
subclass = HDA
bar [10] = type Memory, range 64, base 0xf4634000, size 16384, enabled
cap 01[50] = powerspec 2 supports D0 D3 current D0
cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR
max read 128
ecap 0002[100] = VC 1 max VC1
pcib2@pci0:0:28:0: class=0x060400 rev=0xd4 hdr=0x01 vendor=0x8086 device=0x8c10 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family PCI Express Root Port'
class = bridge
subclass = PCI-PCI
cap 10[40] = PCI-Express 2 root port max data 128(128)
max read 128
link x1(x1) speed 2.5(5.0) ASPM L0s/L1(L0s/L1)
slot 0 power limit 100 mW
cap 05[80] = MSI supports 1 message
cap 0d[90] = PCI Bridge subvendor=0x17aa subdevice=0x2210
cap 01[a0] = powerspec 3 supports D0 D3 current D0
pcib3@pci0:0:28:1: class=0x060400 rev=0xd4 hdr=0x01 vendor=0x8086 device=0x8c12 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family PCI Express Root Port'
class = bridge
subclass = PCI-PCI
cap 10[40] = PCI-Express 2 root port max data 128(128)
max read 128
link x1(x1) speed 2.5(5.0) ASPM L1(L0s/L1)
slot 1 power limit 100 mW
cap 05[80] = MSI supports 1 message
cap 0d[90] = PCI Bridge subvendor=0x17aa subdevice=0x2210
cap 01[a0] = powerspec 3 supports D0 D3 current D0
pcib4@pci0:0:28:2: class=0x060400 rev=0xd4 hdr=0x01 vendor=0x8086 device=0x8c14 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family PCI Express Root Port'
class = bridge
subclass = PCI-PCI
cap 10[40] = PCI-Express 2 root port max data 128(128)
max read 128
link x0(x1) speed 0.0(5.0) ASPM L0s/L1(L0s/L1)
slot 2 power limit 100 mW HotPlug(empty) surprise
cap 05[80] = MSI supports 1 message enabled with 1 message
cap 0d[90] = PCI Bridge subvendor=0x17aa subdevice=0x2210
cap 01[a0] = powerspec 3 supports D0 D3 current D0
ehci1@pci0:0:29:0: class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c26 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family USB EHCI'
class = serial bus
subclass = USB
bar [10] = type Memory, range 32, base 0xf463d000, size 1024, enabled
cap 01[50] = powerspec 2 supports D0 D3 current D0
cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
cap 13[98] = PCI Advanced Features: FLR TP
isab0@pci0:0:31:0: class=0x060100 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c4f subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = 'QM87 Express LPC Controller'
class = bridge
subclass = PCI-ISA
cap 09[e0] = vendor (length 12) Intel cap 1 version 0
features: AMT, 4 PCI-e x1 slots
ahci0@pci0:0:31:2: class=0x010601 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c03 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode]'
class = mass storage
subclass = SATA
bar [10] = type I/O Port, range 32, base 0x50a8, size 8, enabled
bar [14] = type I/O Port, range 32, base 0x50b4, size 4, enabled
bar [18] = type I/O Port, range 32, base 0x50a0, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0x50b0, size 4, enabled
bar [20] = type I/O Port, range 32, base 0x5060, size 32, enabled
bar [24] = type Memory, range 32, base 0xf463c000, size 2048, enabled
cap 05[80] = MSI supports 1 message enabled with 1 message
cap 01[70] = powerspec 3 supports D0 D3 current D0
cap 12[a8] = SATA Index-Data Pair
ichsmb0@pci0:0:31:3: class=0x0c0500 rev=0x04 hdr=0x00 vendor=0x8086 device=0x8c22 subvendor=0x17aa subdevice=0x2210
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family SMBus Controller'
class = serial bus
subclass = SMBus
bar [10] = type Memory, range 64, base 0xf4638000, size 256, enabled
bar [20] = type I/O Port, range 32, base 0xefa0, size 32, enabled
vgapci0@pci0:1:0:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1290 subvendor=0x17aa subdevice=0x221e
vendor = 'NVIDIA Corporation'
device = 'GK208M [GeForce GT 730M]'
class = display
subclass = VGA
bar [10] = type Memory, range 32, base 0xf2000000, size 16777216, enabled
bar [14] = type Prefetchable Memory, range 64, base 0xe0000000, size 268435456, enabled
bar [1c] = type Prefetchable Memory, range 64, base 0xf0000000, size 33554432, enabled
bar [24] = type I/O Port, range 32, base 0x4000, size 128, enabled
cap 01[60] = powerspec 3 supports D0 D3 current D0
cap 05[68] = MSI supports 1 message, 64 bit
cap 10[78] = PCI-Express 2 endpoint max data 256(256) RO NS
max read 512
link x8(x8) speed 2.5(8.0) ASPM L0s/L1(L0s/L1) ClockPM disabled
ecap 0002[100] = VC 1 max VC0
ecap 0004[128] = Power Budgeting 1
ecap 000b[600] = Vendor [1] ID 0001 Rev 1 Length 36
ecap 0019[900] = PCIe Sec 1 lane errors 0
rtsx0@pci0:3:0:0: class=0xff0000 rev=0x01 hdr=0x00 vendor=0x10ec device=0x5227 subvendor=0x17aa subdevice=0x2210
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS5227 PCI Express Card Reader'
bar [10] = type Memory, range 32, base 0xf4500000, size 4096, enabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[70] = PCI-Express 2 endpoint max data 128(128) RO
max read 512
link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM enabled
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 00000001004ce000
ecap 0018[150] = LTR 1
ecap 001e[158] = L1 PM Substates 1
iwm0@pci0:4:0:0: class=0x028000 rev=0x6b hdr=0x00 vendor=0x8086 device=0x08b2 subvendor=0x8086 subdevice=0xc262
vendor = 'Intel Corporation'
device = 'Wireless 7260'
class = network
bar [10] = type Memory, range 64, base 0xf4400000, size 8192, enabled
cap 01[c8] = powerspec 3 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[40] = PCI-Express 2 endpoint max data 128(128) FLR RO NS
max read 128
link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ClockPM enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 7c7a91ffff988046
ecap 0018[14c] = LTR 1
ecap 000b[154] = Vendor [1] ID cafe Rev 1 Length 20
> and
>
> vmstat -i
interrupt total rate
irq1: atkbd0 278 3
irq9: acpi0 232 3
irq16: ehci0 171 2
irq23: ehci1 226 3
cpu0:timer 3636 43
cpu1:timer 2033 24
cpu2:timer 1839 22
cpu3:timer 1610 19
cpu4:timer 2363 28
cpu5:timer 3004 36
cpu6:timer 2990 36
cpu7:timer 2894 34
irq32: hdac0 6 0
irq33: xhci0 109175 1299
irq35: hdac1 45 1
irq36: rtsx0 359 4
irq38: ahci0 3098 37
irq39: iwm0 550 7
irq40: vgapci1 82 1
Total 134591 1602
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
> 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.
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.
Henri Hennebert via freebsd-current
>
> 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
"mmc0: detached"
do you have the previous lines of the dmesg?
Marc Veldman
> On 12 May 2021, at 17:46, Henri Hennebert <h...@restart.be> 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’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?
>
Yes. With wifi disabled in the BIOS, the laptop boots both with and without a card inserted.
Booting a recent GENERIC with the following /boot/loader.conf
#dev.rtsx.0.inversion="1"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
cryptodev_load="YES"
zfs_load=“YES"
uname -a:
FreeBSD supernovo 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n246598-30659d1dcbc:
Wed May 12 10:53:48 CEST 2021 marc@devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> can you also try a boot with a card inserted as in case (2) of Lev tests.
Booting with card inserted, wifi enabled in BIOS succeeds.
Booting with no card inserted wifi enabled in BIOS fails.
Booting with a card insert wifi enabled in BIOS succeeds.
Booting with no card inserted with wifi disabled in BIOS succeeds
The dev.rtsx.0.inversion flag inverts the behaviour: With wifi enabled
booting fails with the card inserted and succeeds with no card inserted.
Marc Veldman
> On 12 May 2021, at 18:06, Henri Hennebert <h...@restart.be> 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: <ACPI PCI-PCI bridge> at device 28.2 on pci0
pci2: <ACPI PCI bus> on pcib2
pci2: <network> at device 0.0 (no driver attached)
pcib3: <ACPI PCI-PCI bridge> at device 29.0 on pci0
pci3: <ACPI PCI bus> on pcib3
vgapci1: <VGA-compatible display> port 0xd000-0xd07f mem 0xf3000000-0xf3ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff at device 0.0 on pci3
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
pci0: <memory> at device 31.2 (no driver attached)
hdac0: <Intel Sunrise Point-LP HDA Controller> mem 0xf4240000-0xf4243fff,0xf4230000-0xf423ffff at device 31.3 on pci0
em0: <Intel(R) I219-V SPT> mem 0xf4200000-0xf421ffff 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: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> 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: <ACPI Control Method Battery> on acpi0
battery1: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
hwpstate_intel0: <Intel Speed Shift> on cpu0
hwpstate_intel1: <Intel Speed Shift> on cpu1
hwpstate_intel2: <Intel Speed Shift> on cpu2
hwpstate_intel3: <Intel Speed Shift> on cpu3
Timecounters tick every 1.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
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.
Henri Hennebert via freebsd-current
> 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.
I will check in my mail archive...
Thank you for your time
Marc Veldman
Yes.
rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem 0xf4100000-0xf4100fff at device 0.0 on pci1>
rtsx0: Card present
mmc0: <MMC/SD bus> on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
pcib2: <ACPI PCI-PCI bridge> ad device 28.2 on pci0
… (continue as above, with panic)
Note: The card is not inserted.
Henri Hennebert via freebsd-current
Can you please show the dmesg after a warm reboot with no card inserted.
Lev Serebryakov
> 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!
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
> 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!
>
rtsx0: <2.0c Realtek ...
mmc0: <MMC/SD bus> on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
Marc Veldman
> On 13 May 2021, at 11:49, Henri Hennebert <h...@restart.be> wrote:
>
...
...
>>>
>>>> mmc0: detached
>>>> ugen0.1: <0x8086
>> Yes.
>> rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem 0xf4100000-0xf4100fff at device 0.0 on pci1>
>> rtsx0: Card present
>> mmc0: <MMC/SD bus> 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.
>
It is a slightly modified kernel with a few debug printfs in them.
---<<BOOT>>---
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
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
AMD Features2=0x121<LAHF,ABM,Prefetch>
Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
TSC: P-state invariant, performance statistics
real memory = 17179869184 (16384 MB)
avail memory = 16430579712 (15669 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <LENOVO TP-N1K >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0 <Version 2.0> irqs 0-119
Launching APs: 1 2 3
Timecounter "TSC-low" frequency 1296042202 Hz quality 1000
random: entropy device external interface
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0.
kbd1 at kbdmux0
mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020)
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 1.000000s
smbios0: <System Management BIOS> at iomem 0xb703e000-0xb703e01e
smbios0: Version: 2.8, BCD Revision: 2.8
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <LENOVO TP-N1K>
acpi_ec0: <Embedded Controller: GPE 0x16, ECDT> port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 24000000 Hz quality 950
Event timer "HPET" frequency 24000000 Hz quality 550
Event timer "HPET1" frequency 24000000 Hz quality 440
Event timer "HPET2" frequency 24000000 Hz quality 440
Event timer "HPET3" frequency 24000000 Hz quality 440
Event timer "HPET4" frequency 24000000 Hz quality 440
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Sleep Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xe000-0xe03f mem 0xf2000000-0xf2ffffff,0xc0000000-0xdfffffff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 0xf4220000-0xf422ffff at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0: <simple comms> at device 22.0 (no driver attached)
ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0
ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
ahcich1: <AHCI channel> at channel 1 on ahci0
pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
rtsx0: <2.0c Realtek RTS522A PCI MMC/SD Card Reader> mem 0xf4100000-0xf4100fff at device 0.0 on pci1
rtsx0: Card absent
hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
pcm0: <Realtek ALC293 (Analog)> at nid 20 and 26 on hdaa0
pcm1: <Realtek ALC293 (Analog)> at nid 21 and 18 on hdaa0
hdacc1: <Intel Skylake HDA CODEC> at cad 2 on hdac0
hdaa1: <Intel Skylake Audio Function Group> at nid 1 on hdacc1
pcm2: <Intel Skylake (HDMI/DP 8ch)> at nid 3 on hdaa1
WARNING: WITNESS option enabled, expect reduced performance.
ugen0.1: <0x8086 XHCI root HUB> at usbus0
uhub0Trying to mount root from zfs:zroot/ROOT/default []...
on usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
Root mount waiting for: usbus0 CAM
ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
ada0: <Samsung SSD 850 PRO 512GB EXM04B6Q> ACS-2 ATA SATA 3.x device
ada0: Serial Number S39FNX0J625463T
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 488386MB (1000215216 512 byte sectors)
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
uhub0: 18 ports with 18 removable, self powered
Root mount waiting for: usbus0
ugen0.2: <Realtek Bluetooth Radio> at usbus0
Root mount waiting for: usbus0
ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
Root mount waiting for: usbus0
ugen0.5: <vendor 0x138a product 0x0017> at usbus0
pchtherm0: <Skylake PCH Thermal Subsystem> mem 0xf424b000-0xf424bfff at device 20.2 on pci0
ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem 0xf424e000-0xf424e0ff at device 31.4 on pci0
smbus0: <System Management Bus> on ichsmb0
iwm0: <Intel(R) Dual Band Wireless AC 8260> mem 0xf4000000-0xf4001fff at device 0.0 on pci2
iwm0: hw rev 0x200, fw ver 22.361476.0, address f4:8c:50:50:22:83
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: Embedded MOF found
ACPI: \134_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20210331/nsarguments-361)
acpi_wmi1: <ACPI-WMI mapping> on acpi0
acpi_wmi1: Embedded MOF found
ACPI: \134_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI object (Buffer) (20210331/nsarguments-361)
acpi_wmi2: <ACPI-WMI mapping> on acpi0
acpi_wmi2: Embedded MOF found
ACPI: \134_SB.WMI3.WQBC: 1 arguments were passed to a non-method ACPI object (Buffer) (20210331/nsarguments-361)
lo0: link state changed to UP
em0: link state changed to UP
ubt0 on uhub0
ubt0: <Bluetooth Radio> on usbus0
ubt1 on uhub0
ubt1: <vendor 0x8087 product 0x0a2b, class 224/1, rev 2.00/0.01, addr 2> on usbus0
WARNING: attempt to domain_add(bluetooth) after domainfinalize()
WARNING: attempt to domain_add(netgraph) after domainfinalize()
Security policy loaded: MAC/ntpd (mac_ntpd)
Lev Serebryakov
>>> 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: <MMC/SD bus> on rtsx0
> rtsx0: Interrupt card inserted/removed
> rtsx0: Card absent
When it panics, it panics before rtsx0 prints something in my case.
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
> pci1: <ACPI PCI bus> on pcib1
> rtsx0: <2.0c Realtek RTS522A PCI MMC/SD Card Reader> mem 0xf4100000-0xf4100fff at device 0.0 on pci1
> rtsx0: Card absent
> pcib2: <ACPI PCI-PCI bridge> at device 28.2 on pci0
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
Henri Hennebert via freebsd-current
> 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: <MMC/SD bus> on rtsx0
>> rtsx0: Interrupt card inserted/removed
>> rtsx0: Card absent
> When it panics, it panics before rtsx0 prints something in my case.
>
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
Lev Serebryakov
> 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...
--
// Lev Serebryakov
Lev Serebryakov
>>>>> 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: <MMC/SD bus> 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?)
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: <MMC/SD bus> on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card 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!)
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
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: <MMC/SD bus> 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?)
> 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: <MMC/SD bus> on rtsx0
> rtsx0: Interrupt card inserted/removed
> rtsx0: Card 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!)
>
Lev Serebryakov
>> rtsx0: <2.0c .....>
>> rtsx0: Card present
>> mmc0: <MMC/SD bus> 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.
Henri Hennebert via freebsd-current
> On 13.05.2021 15:48, Henri Hennebert via freebsd-current wrote:
>
>>> rtsx0: <2.0c .....>
>>> rtsx0: Card present
>>> mmc0: <MMC/SD bus> 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.
to see if this is a path to dig further.
Lev Serebryakov
>>> try to rebuild your kernel with the attached patch.
>> Nope, same panic after cold (power-cycle) boot.
>
> Can you try with "DELAY(500000);"
>
> to see if this is a path to dig further.
It helps with panic!
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
> 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(500000);"
>>
>> to see if this is a path to dig further.
>
> It helps with panic!
Lev Serebryakov
>>>>> try to rebuild your kernel with the attached patch.
>>>> Nope, same panic after cold (power-cycle) boot.
>>>
>>> Can you try with "DELAY(500000);"
>>>
>>> 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: <ACPI PCI-PCI bridge> at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
rtsx0: <2.0c Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf4500000-0xf4500fff at device 0.0 on pci2
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
rtsx0: Card absent
pcib3: <ACPI PCI-PCI bridge> at device 28.1 on pci0
pci3: <ACPI PCI bus> on pcib3
(no visible pause between two "Card absent" lines).
--
// Lev Serebryakov
Chris
Doesn't this look like an interrupt sharing/storm problem?
MSI vs MSI-X maybe?
Just thought I'd throw that out.
--Chris
Henri Hennebert via freebsd-current
> 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(500000);"
>>>>
>>>> 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: <ACPI PCI-PCI bridge> at device 28.0 on pci0
> pci2: <ACPI PCI bus> on pcib2
> rtsx0: <2.0c Realtek RTS5227 PCI MMC/SD Card Reader> mem 0xf4500000-0xf4500fff
> at device 0.0 on pci2
> rtsx0: Interrupt card inserted/removed
> rtsx0: Card absent
> rtsx0: Card absent
> pcib3: <ACPI PCI-PCI bridge> at device 28.1 on pci0
> pci3: <ACPI PCI bus> on pcib3
>
> (no visible pause between two "Card absent" lines).
>
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.
Thank you for your time
Lev Serebryakov
> 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.
Output WITHOUT card is like this:
pci2: <ACPI PCI bus> on pcib2
rtsx0: We are running with inversion: 0
rtsx0: Card absent
pci2: <ACPI PCI bus> on pcib2
rtsx0: We are running with inversion: 0
rtsx0: Interrupt card inserted/removed
rtsx0: Card present
rtsx0: A card is detected
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
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
I will push this new version to current, but it will take some time because I am
not a committer.
Henri
Marc Veldman
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 —
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.
Again, thank you very much for your work on this!
Best regards,
Marc Veldman
Lev Serebryakov
> So if I understand correctly, your problem is solved.
Card REMOVAL when boot was WITH CARD:
Instant panic:
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
cpuid = 3
time = 1620928154
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c6a989c0
vpanic() at vpanic+0x181/frame 0xfffffe00c6a98a10
panic() at panic+0x43/frame 0xfffffe00c6a98a70
__mtx_assert() at __mtx_assert+0xb0/frame 0xfffffe00c6a98a80
device_detach() at device_detach+0x2e/frame 0xfffffe00c6a98ac0
device_delete_child() at device_delete_child+0x15/frame 0xfffffe00c6a98ae0
rtsx_card_task() at rtsx_card_task+0xfa/frame 0xfffffe00c6a98b00
taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfffffe00c6a98b80
taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 0xfffffe00c6a98bb0
fork_exit() at fork_exit+0x80/frame 0xfffffe00c6a98bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c6a98bf0
--- 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
time = 1620928312
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c6a98a10
vpanic() at vpanic+0x181/frame 0xfffffe00c6a98a60
panic() at panic+0x43/frame 0xfffffe00c6a98ac0
__mtx_assert() at __mtx_assert+0xb0/frame 0xfffffe00c6a98ad0
device_probe_and_attach() at device_probe_and_attach+0x2a/frame 0xfffffe00c6a98b00
taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfffffe00c6a98b80
taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 0xfffffe00c6a98bb0
fork_exit() at fork_exit+0x80/frame 0xfffffe00c6a98bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c6a98bf0
--- 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.
--
// Lev Serebryakov
Gary Jennejohn
The driver was originally developed when current was what is now 12 or
13, I think.
Might be worth looking at dwmmc.c (where I got the card insertion/removal
code) to see whether there are any recent changes there.
--
Gary Jennejohn
Rodney W. Grimes
>
> > a cold boot with the card inserted.
>
> It could explain, why my tests with "same code path" gave different results!
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.
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 0xe1000000-0xe1000fff irq 18 at device 0.0 on pci3
rtsx0: pci_read_config() error - reg: 0xeeffffaa
rtsx0: Card present
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: Card absent
rtsx0: Card present
Further note that this is a different controller chip version,
from a Dell E5470:
rtsx0@pci0:3:0:0: class=0xff0000 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 0xe1000000, 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 00000001004ce000
ecap 0018[158] = LTR 1
ecap 001e[160] = L1 PM Substates 1
> // Lev Serebryakov
--
Rod Grimes rgr...@freebsd.org
Henri Hennebert via freebsd-current
(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.
Henri Hennebert via freebsd-current
Henri
Lev Serebryakov
> Please test the 2.0h version from GitHub.
Card removal after boot: OK
Cold Boot without card: OK
Card insertion after boot: OK
It is with 14-CURRENT n246524-95a74ab4fb0
--
// Lev Serebryakov
Henri Hennebert via freebsd-current
>> 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.
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
Rodney W. Grimes
> >> 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.
any system that presents the SD card as a bios disk device. IIRC when
booting with an SD card in the slot the loader finds drives C to E,
which, again IIRC are:
C: nvme
D: USB to SATA disk in external enclosure
E: SD card
>
> Please show
>
> kenv | grep smbios.system
smbios.system.family="Latitude"
smbios.system.maker="Dell Inc."
smbios.system.product="Latitude E5470"
smbios.system.serial="5YK7RF2"
smbios.system.sku="06DE"
smbios.system.uuid="4c4c4544-0059-4b10-8037-b5c04f524632"
>
> and
>
> pciconf -lvbc
The output of that was included in my original mail, and is still
in your reply below.
Repeated here:
Rod Grimes rgr...@freebsd.org
Marc Veldman
> On 14 May 2021, at 10:22, Henri Hennebert <h...@restart.be> wrote:
>
>
> Please test the 2.0h version from GitHub.
>
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: <MMC/SD bus> on rtsx0
I have the inversion flag turned on /boot/loader.conf
dev.rtsx.0.inversion=1
dev.rtsx.0.debug=1
Best regards,
Marc Veldman
Gary Jennejohn
Marc Veldman <ma...@bumblingdork.com> wrote:
> > On 14 May 2021, at 10:22, Henri Hennebert <h...@restart.be> 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: <MMC/SD bus> on rtsx0
>
> I have the inversion flag turned on /boot/loader.conf
>
> dev.rtsx.0.inversion=1
> dev.rtsx.0.debug=1
>
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
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.
--
Gary Jennejohn
Marc Veldman
What is it in the trace that indicated that the inversion flag is not needed?
Best Regards,
Marc Veldman
Lev Serebryakov
>
> I removed the flag, and it works now.Thanks!
> What is it in the trace that indicated that the inversion flag is not needed?
>>> 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
--
// Lev Serebryakov
Graham Perrin
> It doesn't panic, boots and works more than 500 seconds :-)
The Power To Serve
Henri Hennebert via freebsd-current
>>
>> 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?
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
Marc Veldman
smbios.system.family="ThinkPad P50s"
smbios.system.maker="LENOVO"
smbios.system.product="20FLCTO1WW"
smbios.system.serial="R90N30VP"
smbios.system.sku="LENOVO_MT_20FL_BU_Think_FM_ThinkPad P50s"
smbios.system.uuid="cbc5ee4c-2b18-11b2-a85c-a62da394388c"
smbios.system.version="ThinkPad P50s"
marc@supernovo:~ $
>
> and
>
> dmesg|grep rtsx
>
rtsx0: <2.0h Realtek RTS522A PCI MMC/SD Card Reader> mem 0xf4100000-0xf4100fff at device 0.0 on pci1
rtsx0: Inversion activated for LENOVO/ThinkPad P50s/20FLCTO1WW, see BUG in rtsx(4)
rtsx0: If a card is detected without an SD card present, add dev.rtsx.0.inversion=0 in loader.conf(5)
rtsx0: Card present
rtsx0: Card absent
rtsx0: Card present
rtsx0: Card absent
Warner Losh
things to do that by default is a nice to have item.
Warner
Gary Jennejohn
you removed the card and the trace shows that a card is present. This
is exactly what the inversion flag would result in if it is not needed.
--
Gary Jennejohn
Adrian Chadd
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.
If I disable it at the boot console then it's fine.
-adrian
Henri Hennebert via freebsd-current
> 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.
GitHub (2.0i).
Henri