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  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:	Wed, 19 Dec 2007 17:20:21 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Shaohua Li <shaohua.li@...el.com>,
	Mike Houston <mikeserv@...s.com>, Adrian Bunk <bunk@...sta.de>,
	Elvis Pranskevichus <el@...ns.net>, mhoffman@...htlink.com,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org,
	Adam Belay <ambx1@....rr.com>,
	Zhao Yakui <yakui.zhao@...el.com>,
	Thomas Renninger <trenn@...e.de>, lenb@...nel.org,
	linux-acpi@...r.kernel.org,
	Carlos Corbacho <carlos@...angeworlds.co.uk>
Subject: Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails

On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote:
> The real cause is pretty clear here: broken BIOS. In an ideal world we
> would ask the manufacturer for a fixed BIOS and they would give that to
> us, unfortunately my experience is that it won't happen. So, unless we
> accept that idea that some users won't be able to use some of their
> devices because of broken resource enumeration in their BIOS, we will
> have to find a workaround, whatever it is.

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
interesting-looking work on WMI.

> My initial idea was to identify the faulty motherboard using DMI and to
> force pnpacpi=off on the faulty motherboards. If this is considered too
> aggressive, maybe we can just reject resource declarations that
> intersect (but don't match) 0x290-0x297 for these motherboards. Either
> way, we have to do something, and we have to do it quickly. 2.6.24
> final isn't too far away, and more importantly, the patch that revealed
> the problem has been backported to 2.6.23.10 so people are experiencing
> regressions already.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists