linux-kernel - Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails

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]

Message-ID: <20071218185918.5d2d4c7d@hyperion.delvare>
Date:	Tue, 18 Dec 2007 18:59:18 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
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
Subject: Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails

Hi Bjorn,

On Mon, 17 Dec 2007 10:14:43 -0700, Bjorn Helgaas wrote:
> On Sunday 16 December 2007 06:59:39 pm Shaohua Li wrote:
> > On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote:
> > > On Mon, 10 Dec 2007 10:31:27 +0800
> > > Shaohua Li <shaohua.li@...el.com> wrote:
> > > > This should exist in previous kernel (before we remove acpi
> > > > motherboard driver) too. Basically it's a broken BIOS. Could below
> > > > patch work around it?
> > > > 
> > > > Thanks,
> > > > Shaohua
> > > > 
> > > > Index: linux/drivers/pnp/system.c
> > > > ===================================================================
> > > > --- linux.orig/drivers/pnp/system.c	2007-12-10
> > > > 10:17:46.000000000 +0800 +++ linux/drivers/pnp/system.c
> > > 
> > > Thanks Shaohua, I tested this as well and it appears to have worked
> > > around the issue for me.
> > > 
> > > Now, in dmesg, I get:
> > > 
> > > system 00:01: ioport range 0x290-0x29f has been reserved
> > > (...)
> > > system 00:01: ioport range 0x290-0x294 could not be reserved
> > > 
> > > In /proc/ioports I see:
> > > 
> > > 0290-029f : pnp 00:01
> > >   0290-0297 : it87
> > >     0290-0297 : it87
> >
> > Unfortunately this can't solve all such issues.

I don't see any issue here, but anyway it doesn't really matter as the
proposed patch is not sufficient for all affected motherboards.

> > 
> > Adam & Bjorn,
> > Could we just reserve IO ports >= 0x1000 in pnp system driver? The
> > purpose of the driver is to avoid resource conflict with PCI device, and
> > PCI device can't user io port < 0x1000.
> 
> The purpose of the PNP system driver is to avoid conflicts with
> *all* devices.  And if the PNP core were a little smarter, we
> wouldn't need the system driver at all.  We don't have one for
> PCI -- the PCI core manages resources for all PCI devices, even
> ones that have no driver.
> 
> Why is 0x1000 a magic number?  drivers/acpi/motherboard.c used to
> ignore IO port ranges that ended below PCIBIOS_MIN_IO (== 0x1000 for
> most architectures).  I don't think Linux will assign IO ports below
> PCIBIOS_MIN_IO to a PCI device, but the BIOS could, and I've seen
> CardBus devices below PCIBIOS_MIN_IO.
> 
> I think having drivers/pnp/system.c ignore resources below
> PCIBIOS_MIN_IO would be a hack that happens to cover up problems
> like this without understanding the real cause.

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.

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.

-- 
Jean Delvare
--
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/