From: Larry Finger <Larry.Finger@lwfinger.net>
To: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux ACPI <linux-acpi@vger.kernel.org>
Subject: Re: Regression in module wmi since 2.6.32 (bisected to commit 1caab3c)
Date: Sat, 26 Dec 2009 09:32:37 -0600 [thread overview]
Message-ID: <4B362C95.4040700@lwfinger.net> (raw)
In-Reply-To: <200912260118.26391.carlos@strangeworlds.co.uk>
On 12/25/2009 07:18 PM, Carlos Corbacho wrote:
> On Friday 25 December 2009 22:09:28 Larry Finger wrote:
>> On 12/25/2009 03:58 PM, Carlos Corbacho wrote:
>>> On Friday 25 December 2009 21:35:49 Larry Finger wrote:
>>>> Should I attach the files DSDT.dat, acpidump.out, or DSDT?
>>>
>>> DSDT from /proc/acpi/dsdt will do fine for my purposes.
>>
>> Attached.
>
> This is the same as bugzilla #14846 - in both cases, the GUID 05901221-D566-11D1-B2F0-00A0C9062910 (a data block query) is duplicated in two different devices, although both look like they are nVidia related hooks.
>
> Since we don't currently have any in kernel drivers that use that stuff, and the query in question just returns a binary MOF, the simplest solution (for now) seems to be to just ignore these duplicates - if and when someone wants to support these hooks, they can clean the mess up properly when they figure out how WMI is supposed to cope with conflicting GUID's.
>
> Matthew, you looked at NVIF for your sins, can you see a better solution? We could just blacklist the offending GUID, rather than trying to catch all duplicates? Although just ignoring all duplicates strikes me as a better solution to catch the next time that J Random BIOS Developer decides to duplicate GUIDs in WMI.
>
> Initial patch below which takes the "ignore all duplicate GUIDs" approach.
The patch fixes my machine.
Thanks,
Larry
next prev parent reply other threads:[~2009-12-26 15:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-25 20:48 Regression in module wmi since 2.6.32 (bisected to commit 1caab3c) Larry Finger
2009-12-25 20:56 ` Carlos Corbacho
2009-12-25 21:35 ` Larry Finger
2009-12-25 21:58 ` Carlos Corbacho
2009-12-25 22:09 ` Larry Finger
2009-12-26 1:18 ` Carlos Corbacho
2009-12-26 1:36 ` Dmitry Torokhov
2009-12-26 15:32 ` Larry Finger [this message]
2009-12-26 18:36 ` Carlos Corbacho
2009-12-26 19:04 ` Larry Finger
2009-12-26 19:14 ` [PATCH] ACPI: WMI: Handle duplicate GUIDs Carlos Corbacho
2009-12-26 19:42 ` Len Brown
2010-01-06 15:27 ` Regression in module wmi since 2.6.32 (bisected to commit 1caab3c) Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B362C95.4040700@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=carlos@strangeworlds.co.uk \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox