Mike Larkin wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS
On Wed, Sep 29, 2021 at 06:29:08PM -0700, Mike Larkin wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine
On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> slowdown on my T480. Previously, I experienced slowdown after power cycling
> my machine occasionally. Currently, with this BIOS setting enabled, I
>
After enabling "BIOS Thunderbolt Assist", I experience consistent
machine slowdown on my T480. Previously, I experienced slowdown after
power cycling my machine occasionally. Currently, with this BIOS setting
enabled, I experience slowdown consistently.
I am sorry but I don't know enough
Another T480 user who has noticed the same problem. Per advice given,
I've just enabled "BIOS Thunderbolt Assist". I will report back if I
notice the problem persists.
On 9/19/21 4:50 AM, Daniel Wilkins wrote:
I've ran into this on my T480, it seems most consistently triggered by power
cycles
On Wed, Sep 29, 2021 at 11:47:34AM -0600, Theo de Raadt wrote:
> It would be great if someone figures out why "BIOS Thunderbolt Assist"
> disable, causes a pin to get stuck on resume, and/or figures out how we
> can recognize to handle/clear the event.
The detail in my BIOS options specifically
Hi,
On 2021-09-28 14>18>49, Daniel Wilkins wrote
> All you have to do is go into your bios' settings and turn on
> "BIOS Thunderbolt Assist" then everything will work 100% fine.
>
> Thanks to jcs on IRC for pointing me at that (dunno what his
> email is.)
Success! With this (and the 7.0
Jonathan Thornburg wrote:
> On 2021-09-28 14>18>49, Daniel Wilkins wrote
> > All you have to do is go into your bios' settings and turn on
> > "BIOS Thunderbolt Assist" then everything will work 100% fine.
> >
> > Thanks to jcs on IRC for pointing me at that (dunno what his
> > email is.)
>
>
On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote:
> There are a few people who have experience with this. Maybe one of
> them will mail you privately.
>
I'm glad this thread suddenly got revived, since I tried to find it
in my backlog but it got lost.
All you have to do is go into
On Tue, Sep 28, 2021 at 10:16:23PM -0600, Theo de Raadt wrote:
> Your dmesg lacks tpm0. You probably disabled it in the BIOS:
>
> "STM7304" at acpi0 not configured
>
> If you re-enable TPM uit in the BIOS, and try a snapshot (or upcoming
> 7.0) there is a recent fix which may help. It is a
On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote:
> the term "runaway ACPI" is not the best. What is probably happening
> is a stuck interrupt.
>
> We continue to fight these. Some of them are BIOS bugs, some are
> undocumented behaviours, sometimes AML parse errors in setting
> bios0: vendor LENOVO version "N27ET43W (1.29 )" date 08/13/2021
> bios0: LENOVO 20L9001GUS
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
On the other hand, your BIOS is very new. So new that it has S0.
These days Microsoft is only testing S0.
Lenovo and some other vendors are
BTW, BIOS update has fixed interrupts issues like this in a surprising
number of cases. No promises, tho.
Jonathan Thornburg wrote:
> After more experimentation, I find that the runaway ACPI process occurs
> every time I suspend/resume (Fn-backspace). (The system resumes fine
> apart from the
the term "runaway ACPI" is not the best. What is probably happening
is a stuck interrupt.
We continue to fight these. Some of them are BIOS bugs, some are
undocumented behaviours, sometimes AML parse errors in setting things
up, and potentially a few are due to incorrect resume sequencing.
After more experimentation, I find that the runaway ACPI process occurs
every time I suspend/resume (Fn-backspace). (The system resumes fine
apart from the runaway ACPI process.)
Is there any to kill or reset the kernel ACPI process short of rebooting?
/ps/ doen't see it, and /pkill/ (even
I dunno if this is helpful, but I just unplugged my thinkpad and triggered the
behavior.
ACPI shot right up, and in this case the "charging" LED has stayed on. I've
never triggered
it by unplugging before, but the symptoms are the same. The system was under
some load while
doing so (watching a
I wrote
> During the installation (both in the bsd.rd install script and previously
> when I dropped into the bsd.rd shell to set up softraid-crypto) the machine
> acted incredibly slow, and there was a several-second delay in echoing
> typed characters. I suspected that it was some device
I've ran into this on my T480, it seems most consistently triggered by power
cycles caused by running out of battery. The bug's existed for quite a few
years (I think I first noticed it in 2019.) If I recall correctly I've
posted it to the list a couple of times but I don't think any concrete
I have just installed 6.9-stable/amd64 on a new-to-me (used) Lenovo
Thinkpad T580 (dmesg below). This was a from-scratch install on a
new-from-the-factory SSD (via booting the 6.9/amd64 bsd.rd from a usb
stick).
During the installation (both in the bsd.rd install script and previously
when I
19 matches
Mail list logo
