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
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.
If I disable it at the boot console then it's fine.
-adrian
___
On Fri, 14 May 2021 17:05:26 +0200
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
On Fri, May 14, 2021, 11:03 AM Marc Veldman wrote:
>
>
> > On 14 May 2021, at 17:29, Henri Hennebert wrote:
> >
> > 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 17:29, Henri Hennebert wrote:
>
> 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:
>
>
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
On 13/05/2021 16:09, Lev Serebryakov wrote:
It doesn't panic, boots and works more than 500 seconds :-)
The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
On 14.05.2021 18:05, Marc Veldman wrote:
I removed the flag, and it works now.Thanks!
What is it in the trace that indicated that the inversion flag is not needed?
THIS:
Insert card after boot, no crash, but the message
seems weird:
May 14 16:01:27 supernovo kernel: rtsx0: Interrupt card
> 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
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
>
> 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
On 14.05.2021 11:22, Henri Hennebert wrote:
Please test the 2.0h version from GitHub.
Cold Boot with card: OK
Card removal after boot: OK
Cold Boot without card:OK
Card insertion after boot: OK
It is with 14-CURRENT n246524-95a74ab4fb0
--
// Lev Serebryakov
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
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
On Thu, 13 May 2021 20:55:20 +0300
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:
>
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
> 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
>>>
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
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
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!
On 2021-05-13 02:49, Henri Hennebert via freebsd-current wrote:
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:
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
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!
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!
--
// Lev Serebryakov
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!
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
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
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!
On 13.05.2021 15:06, Henri Hennebert via freebsd-current wrote:
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...
It could
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"
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>
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"
> 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
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"
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!
--
// Lev Serebryakov
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
> 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
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
> 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.
>>
> On 12 May 2021, at 17:46, 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.
>>
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.
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.
On 12.05.2021 16:35, Henri Hennebert 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
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
On Wed, 12 May 2021 16:44:59 +0300
Lev Serebryakov 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
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
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
On Wed, 12 May 2021 15:46:24 +0300
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
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
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
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
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
On 07.05.2021 19:34, Tomoaki AOKI wrote:
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
On 07.05.2021 19:09, Jesper Schmitz Mouridsen wrote:
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,
On Fri, 7 May 2021 14:33:27 +0300
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
On Fri, 7 May 2021 16:59:35 +0300
Lev Serebryakov 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,
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
Just to add to this thread:
I'm running CURRENT with rtsx device and driver and it works fine for me.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
On Fri, 7 May 2021 16:59:35 +0300
Lev Serebryakov 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,
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
On 07.05.2021 16:07, Rodney W. Grimes 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
On Fri, 7 May 2021 15:01:13 +0300
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
> 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
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
On 07.05.2021 14:33, 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
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
66 matches
Mail list logo
