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, 15 Sep 2010 16:44:37 -0600
From:	Bjorn Helgaas <>
To:	"H. Peter Anvin" <>
Cc:	Jesse Barnes <>,
	Brian Bloniarz <>,
	Charles Butterfield <>,
	Denys Vlasenko <>,,,
	Stefan Becker <>,
	Yinghai Lu <>,
	Thomas Gleixner <>,
	Linus Torvalds <>,
	Ingo Molnar <>
Subject: Re: [PATCH 3/3] PCI: allocate bus resources from the top down

On Wednesday, September 15, 2010 03:50:14 pm H. Peter Anvin wrote:
> On 09/15/2010 02:09 PM, Bjorn Helgaas wrote:
> > 
> > On the machine above (a Dell T3500), the [mem 0xbff00000-0xbfffffff] region
> > doesn't actually work and is likely a BIOS defect.  The symptom is that we
> > move the AHCI controller to 0xbff00000, which leads to "Boot has failed,
> > sleeping forever," a BUG in ahci_stop_engine(), or some other boot failure.
> > 
> Acked-by: H. Peter Anvin <>
> ... for the patch in general, but I would like to *also* request a DMA
> or PCI quirk to explicitly reserve the above range on the affected Dell
> machines.

I'd like to do that, but I don't see a good way to do it yet.

We saw the problem on a T3500, a T3400, and a T4500, and I'm sure there
are others.  So I don't know how to identify the affected machines.

And I don't know how to identify the invalid ranges, because I suspect
it depends on the memory size.  I think it would be quite unusual for
a window to start 1MB under the nice 256MB boundary, but I'm not sure
I'm ready to say that's always illegal.

On these machines, the [mem 0xbff00000-0xbfffffff] area is actually
reported as reserved in the E820 map, and I first thought we could
simply rely on that.  But I'm not really comfortable with that either,
because I don't think there's a dependable relationship between those
E820 entries and ACPI and PCI devices.  For one thing, I experimented
with Windows, and it happily places PCI devices in reserved areas,
and I think we're likely to trip over more BIOS bugs if we rely on
something Windows doesn't.

I suspect Windows would blow up, too, if we could somehow fill up the
rest of the window and force it to allocate the bottom.  But since
it's only a 1MB area, I think that would be very difficult to do
unless there's some way to tweak PCI BARs before booting Windows.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists