linux-kernel - Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2016 11:07:41 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Mario Limonciello <Mario_Limonciello@...l.com>
Cc:	Peter Jones <pjones@...hat.com>,
	Rafael Wysocki <rafael@...nel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] ACPI: don't show an error when we're not in charge of
 PCIe hotplug.

On Tue, Jun 21, 2016 at 11:01 AM,  <Mario_Limonciello@...l.com> wrote:
>> -----Original Message-----
>> From: Peter Jones [mailto:pjones@...hat.com]
>> Sent: Tuesday, June 21, 2016 10:19 AM
>> To: Rafael J. Wysocki <rafael@...nel.org>
>> Cc: ACPI Devel Maling List <linux-acpi@...r.kernel.org>; Limonciello, Mario
>> <Mario_Limonciello@...l.com>; Linux Kernel Mailing List <linux-
>> kernel@...r.kernel.org>; Len Brown <lenb@...nel.org>; Rafael J . Wysocki
>> <rjw@...ysocki.net>; Andy Lutomirski <luto@...capital.net>
>> Subject: Re: [PATCH] ACPI: don't show an error when we're not in charge of
>> PCIe hotplug.
>>
>> (Sorry for the slow response - it's deadline time over here.)
>>
>> On Thu, Jun 16, 2016 at 04:56:57PM +0200, Rafael J. Wysocki wrote:
>> > On Thu, Jun 16, 2016 at 2:12 AM, Rafael J. Wysocki <rafael@...nel.org>
>> wrote:
>> > > On Thu, Jun 16, 2016 at 12:15 AM, Peter Jones <pjones@...hat.com>
>> wrote:
>> > >> Right now when booting, on many laptops the firmware manages the
>> PCIe
>> > >> bus.  As a result, when we call the _OSC ACPI method, it returns an
>> > >> error code.  Unfortunately the errors are not very articulate.
>> > >
>> > > What exactly do you mean here?
>> > >
>> > >>  As a result, we show:
>> > >>
>> > >> ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fe])
>> > >> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM
>> Segments MSI]
>> > >> \_SB_.PCI0 (33DB4D5B-1FF7-401C-9657-7441C03DD766): _OSC invalid
>> UUID
>> > >> _OSC request data: 1 1f 0
>> > >
>> > > So _OSC told us that the UUID was invalid, didn't it?
>> >
>> > BTW, the above messages are KERN_DEBUG, so at least in theory they
>> > shouldn't be visible in production runs.
>> >
>> > Maybe the bug to fix is that they show up when they aren't supposed to?
>>
>> No - the workflow that I am really trying to remedy is this:
>>
>>  1) S3 resume sometimes isn't working on some laptop you've got.
>>  2) start looking at debug messages
>>  3) this shows an error, so it looks like it's probably the problem
>>  4) go fishing for red herring
>>  5) if you happen to know who maintains the DSDT for the platform in
>>     question, eventually work out that this is working as intended and
>>     the bug is someplace else.
>> 5b) if you don't know that person, eventually work out that it /might/
>>      be someplace else...
>>
>> So the idea was to make it look more like an indication of status, and
>> less like an error that's causing unrelated problems.
>>
>> When I talked to Mario at Dell (Cc'd), it wasn't clear to us that
>> there's a way to distinguish the between the UUID being
>> invalid/malformed, being merely unsupported, or being supported in some
>> configurations but not the current one.  In this particular DSDT, the
>> machine doesn't support the OS controlling any of this if USB-C /
>> thunderbolt are enabled.  The DSDT is clearly written with the belief
>> that you have to completely disable the handling for that UUID in this
>> case, and googling for this looks like it's not the only one written
>> with that belief.
>>
>> Reading the spec (v6.1, sections 6.2.11.3 and 6.2.11.4), it seems
>> plausible that you can express this instead by handling the UUID but
>> choosing each individual query/status bit in the way that accomplishes
>> the OS doing nothing with the response.  So it may well be that that's
>> just more code that vendors have thought wasn't necessary (or wasn't
>> correct for some reason.)
>>
>> Mario, want to jump in on your thinking here?
>>
>> --
>>   Peter
>
> After talking to the team, I was told this particular implementation to not let
> OS take control when acting on that specific UUID based upon a variable
> (NEXP in this case) came from Intel RC code.
>
> That's probably why this is all across a lot of platforms, including non-Dell.
>
> At least in the context of the laptop Peter noticed this on (Dell XPS 13 9350)
> NEXP is set in GNVS based upon Thunderbolt capability.
>
> As for why they return unrecognized UUID instead of just masking all the
> capabilities bits?  It's the same net functional result.  If the vendor provided
> RC code doesn't caused WCHK problems or functional problems it's hard to
> make a case for why it needs to be changed by the OEM.
>
> I think that Peter's patch is appropriate to message this is specifically
> what's going on.
>

In general, it seems that Windows is considerably less inclined to
throw out errors when the DSDT contains spec violations.  It would be
great if Microsoft were to tighten up their requirements :)

I wonder if Intel could be persuaded to add an ACPI mechanism to grant
PCIe native control per device or per bus instead of more-or-less
globally as it is now.

--Andy