I suspect the manufacturers would say "Oh, the sensors?  The BIOS
isn't broken, you're just supposed to use WMI or some (undocumented)
ACPI device to get at those."

I know next to nothing about WMI, and there are probably IP issues
in that area.  But I'd rather spend effort in figuring out the "right"
way to do this.  Until we do it the same way as Windows, we can pile
on hacks till the cows come home, and we'll still have issues.

I added Carlos to the cc: list because he's been doing a lot of

Windows apparently doesn't reject those resource declarations, so I'm
a bit hesitant to do it in Linux.  That tends to cover up problems,
and then it becomes very difficult to remove the band-aid and figure
out a correct fix in the future.

Bjorn
--

[ message continues ]

It's quite possible - can we have DSDTs for the boards in question so we can 
quickly check if this is a possibility? (Basically, to see if they have 
PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with 
WMI).

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--

[ message continues ]

Hi Carlos,

I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to 
bugzilla entry #9514:

http://bugzilla.kernel.org/attachment.cgi?id=14132

Thanks,
-- 
                Elvis
--

[ message continues ]

A quick look over the DSDT shows that there is no ACPI-WMI mapper device 
(PNP0C14) on this board; so WMI is, at least in this case, not the solution 
to this bug.

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--

[ message continues ]