linux-kernel - Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes

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:	Fri, 7 Jan 2011 16:03:29 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Jiri Slaby <jslaby@...e.cz>, jbarnes@...tuousgeek.org,
	linux-pci@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes

On Friday, January 07, 2011 01:44:35 pm Jiri Slaby wrote:
> On 01/06/2011 08:24 PM, Bjorn Helgaas wrote:
> > On Thursday, January 06, 2011 08:17:46 am Jiri Slaby wrote:

> Only a novell (opensuse) bugzilla:
> https://bugzilla.novell.com/show_bug.cgi?id=558740
> 
> > Is it a regression?  Sounds like an
> > old machine where we should have seen this before.)
> 
> Yes, a regression. 2.6.31 and newer doesn't work. 2.6.27 did. I don't
> know what kernel exactly in between is first defunct.
> 
> > My guess is that we found this "conflict" and tried to move the
> > controller, but it's hardwired to stay at 0x170 when in compatibility
> > mode.  So the hardware is really still at 0x170, but Linux thinks it
> > moved it elsewhere, so it doesn't work.
> 
> Sorry I didn't get this paragraph.

IDE devices are special and are allowed to respond to the legacy
addresses, e.g., 0x170, even if those addresses don't appear in
the BARs.  That's why we have the special case in pci_setup_device().

But the code that detects the address space conflict and tries to
resolve it doesn't know about this hard-wired IDE address decoder.
Linux tries to move it by writing to a BAR, and that probably has
no effect on a compatibility-mode IDE device.

> > Theoretically, ACPI tells us about the GPIO/TCO/etc. regions in a
> > generic way via namespace devices or something in the static tables.
> > Is that generic information missing, or is it there and Linux is
> > ignoring it?  If we're ignoring it, I'd rather fix that.
> 
> It works for most boxes I would say. Try to google for "claimed by ICH4
> ACPI/GPIO/TCO", it reports sane ranges like 0400-047f or 4000-407f.

My point is that BIOS should be telling the OS about GPIO/TCO/etc.
regions via an ACPI mechanism, and, ideally, we would use that rather
than reading the address out of chipset-dependent registers.

Even though PMBASE says the ACPI registers occupy 128 bytes from
0x100-0x17f, it's likely there's no actual conflict between the
last 16 bytes and the IDE device.

ACPI probably reports this region via the FADT (the GPE PM register
blocks) and possibly a PNP0C02 device.  These will probably report
something that doesn't conflict with the legacy IDE ports, i.e., a
subset of the 0x100-0x17f range.

Ooooh, I notice in the bugzilla that something's wrong with SMBIOS
(comment 29) and ACPI is disabled because we couldn't find the
RSDP (dmesg in comment 27).  What sort of machine is this, anyway?
We didn't find PNPBIOS, either.

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/