cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
prodigy1210
Paper Tape
Posts: 6
Registered: ‎05-22-2018
Location: US
Views: 2,053
Message 41 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Glad to know it is fixed! Who knows man. Windows has had a mind of its own lately... Enjoy your laptop there brother. It should be all smooth sailing from here on.

pi1otpi1ot
Paper Tape
Posts: 3
Registered: ‎05-22-2018
Location: US
Views: 2,034
Message 42 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Ok nothing is fixed relating to the original issue with this thread. Someone just interjected with a totally different problem unrelated to this bug.

prodigy1210
Paper Tape
Posts: 6
Registered: ‎05-22-2018
Location: US
Views: 2,030
Message 43 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

I just re-read the whole thread and YES.. Agreed. Someone posted about Turbo boost problem.

Is the system still getting hot at idle due to the interrupts?

ThinkTank480
Punch Card
Posts: 31
Registered: ‎04-26-2018
Location: CA
Views: 2,019
Message 44 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

@someotherguy

 

Firstly, let me say that I am very happy to see your reply! I have invested a great deal of time into this issue, and I was becoming quite anxious about the radio silence from Lenovo.

 

We asked BIOS engineer to comment on these 3 patches and got the following reply:

 

Patch1:   The patch code is not effective on ThinkPad because the TBMP value is always 0.
Patch2:   BIOS engineer believes there is no relationship between LTR Enable Bit and SCI generation.
Patch3:   The patch code is not effective because it just modified the debug message in the ACPI method

I will address these in order of importance, from lesser to greater:

 

Patch3: Indeed, the only purpose of this patch is to fix the debug message. You may notice that the message "During TBT_OFF" appears only 6 lines below the incomprehensible "Drng TBT_ON". It is a user-facing debug message, so it should be corrected for consistency. (I can't imagine any possible reason to reject such a patch, especially after being made aware of it.)

 

Patch2: Your engineers are more familiar with the code in question, so I might retract this one (pending further research).

 

Patch1: Your engineer has a compelling argument. However, I am not ready to retract this one. I will explain my logic:

 

The DSDT table contains these two blocks of code. The first appears in the "wake" section, and the second appears in the "initialize" section. It seems clear, based on the second block of code, that the first block of code is written incorrectly; Specifically, it does not acquire and release threads properly. To my understanding, the consequences of this error (permitting TBMP) should be an unreleased thread that endlessly generates ACPI interrupts. Furthermore, this bug should only occur under specific circumstances ("wake" events), and should only be prevented under specific circumstances (an "initialization" event).

 

I will now reiterate the symptoms of this bug observed in practice, because it is quite illuminating:

-The symptoms are endlessly generated ACPI interrupts on one thread.

-The symptoms only occur under specific circumstances ("wake" events).

-The symptoms can only be prevented under specific circumstances (an "initialization" event) (note: v1.11+ with thunderbolt enabled only).

 

That is an incredibly specific set of compound coincidences!

 

Your engineer reports that the TBMP value is always 0. I believe their intention, and I am not in any position to dispute it. However, hypothetically, if TBMP were to be enabled (by any manner of unintentional mistakes), it would trigger *precisely* the symptoms experienced and predicted by the faulty block of code. I find that to be too much of a coincidence to ignore.

 

I will continue to research this issue in as much depth as possible until I have either proven this bug, or until I've proven myself wrong. Smiley Wink

 

In the meantime, patch1 still fixes a legitimate mistake (regardless of TBMP), and patch3 still fixes a user-facing inconsistency. I look forward to testing the next UEFI update with those corrections, and I will report back whether the bug is resolved (which I have high hopes it will be), or whether it requires further research.

 

Once again, I am grateful for your response. I appreciate the ability to communicate directly with you and the engineers about this issue.

 

(I am out of time, so I will address the latter half of your message in another reply.)

Schewa
Punch Card
Posts: 2
Registered: ‎05-21-2018
Location: DE
Views: 1,735
Message 45 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Hello guys,

 

did the topic move to a different thread or is this one still the right place to stay informed about the subject?

Just want to make sure, as it has become a bit quiet in here! 

Aswell, a bump of the thread isn't going to be hurting at all. Smiley Wink

 

Regards,

Schewa

Arjov
Punch Card
Posts: 47
Registered: ‎04-02-2018
Location: IT
Views: 1,660
Message 46 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode


@Schewa wrote:

Hello guys,

 

did the topic move to a different thread or is this one still the right place to stay informed about the subject?

Just want to make sure, as it has become a bit quiet in here! 

Aswell, a bump of the thread isn't going to be hurting at all. Smiley Wink

 

Regards,

Schewa


The thread is still this I guess. Giving another bump. Hope we get answers soon

Lenovo Staff
Lenovo Staff
Posts: 4,881
Registered: ‎10-29-2009
Location: NC
Views: 1,569
Message 47 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Can someone show "endlessly generated ACPI interrupts on one thread"?  I need to see this in a task manager screenshot, or something similar.  As it stands now, we have reviewed the 3 suggested patches and concluded that none of them would change anything related to ACPI interrupts.  We don't see the problem here, that's why I'm asking for help how to prove it with a screenshot, or something.

ThinkTank480
Punch Card
Posts: 31
Registered: ‎04-26-2018
Location: CA
Views: 1,517
Message 48 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Here are snapshots from OpenBSD with thunderbolt enabled on UEFI v1.12:

 

top.png

 

tz.png

 

vmstat.png

 

Your engineer will be able to easily confirm this by cold-booting OpenBSD with thunderbolt enabled.

 

Compiling the kernel with ACPI_DEBUG reveals that the ACPI method _L6F is causing the interrupts.

 

If this is the same bug, then GPE 0x6F should be responsible for the same symptoms on other operating systems.

 

In order to test this theory, I had to intentionally trigger the bug in another operating system:

-I rolled back the UEFI to v1.08

-I disabled thunderbolt

-I cold-booted Linux Mint

-I ran "cat /sys/firmware/acpi/interrupts/gpe6F"

 

and indeed, GPE 0x6F reported thousands of interrupts.

 

In other words, it seems exceedingly likely that this is the same bug, and it still affects OpenBSD (and possibly other operating systems) while thunderbolt is enabled (as of v1.12). Keep in mind that operating systems have the capability to ignore, disable, or squelch interrupt storms (so the bug can still exist, even if you don't see the symptoms while thunderbolt is enabled).

 

Your engineer will be better equipped to debug this problem than I am, but I will continue to investigate. At the moment, the only clue I can offer is that it seems the bug is triggered by the execution of the _WAK method.

ads1080
Punch Card
Posts: 34
Registered: ‎04-09-2018
Location: NZ
Views: 1,430
Message 49 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Thank you so much for your work here ThinkTank480

 

Hopefully this is enough to get the engineers looking in the right areas to address this issue.  Well done mate!

prodigy1210
Paper Tape
Posts: 6
Registered: ‎05-22-2018
Location: US
Views: 1,425
Message 50 of 57

Re: FYI - Linux May Not Support Thunderbolt Native Mode

Ty for all the work you do brother. Is it safe to buy a P52s or a T480s or should I wait for this to be resolved? What is the worst case and is this really fixable by software?

Holiday Deals
HAPPENING NOW!

Get the best deals on PCs and tech now during the Holiday Sale
Shop the sale

Top Kudoed Authors