Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 30 Aug 2008, Linus Torvalds wrote:
> 
> Short recap:
> 
>  - we need to populate the resource map with as much possible information 
>    about the system as we can..
> 
>  - .. because when we assign _dynamic_ resources, we need to make sure 
>    that they don't clash with random system resources that we don't really 
>    otherwise have a lot of visibility into.
> 
> So the resource tree is not just about resources we control, it's also 
> about resources that others control(led) and we don't necessarily know a 
> lot about.

Btw, this is a problem that we seldom actually have on most desktops, 
because the BIOS will normally set up just about _all_ the resources, and 
we seldom have to worry about anything but just enumerating them (and the 
occasional buggy setup).

The problems with resource allocation mostly happen on laptops, and 
especially with cardbus controllers. Now, that's obviously going away 
(people mostly use USB for most things that Cardbus/PCMCIA was used for a 
few years ago), but it still exists and with docking stations etc it can 
actually be even worse (although that's mainly because access to docking 
stations is much more limited, I suspect).

So what used to happen _all_ the time was that cardbus worked fine on 99% 
of all machines, but then some machines would lock up when you inserted a 
card in them, or the card just wouldn't work. And the reason was that some 
stupid motherboard resource (like the ACPI sleeping registers or the LPC 
control regs) were not done as a normal BAR, so the kernel wouldn't know 
about them, and the BIOS didn't necessarily even list it because it never 
mattered with Windows (since Windows has a different algorithm for laying 
out the bus resources, and wouldn't hit the magic resource).

So this is why we populate the resources with everything we can _possibly_ 
try to find, including hardware-specific quirks (see things like 
quirk_ali7101_acpi or all the quirk_ich4_lpc_acpi things etc) for finding 
resources that aren't done by BAR's.

And the hardware quirks have generally worked pretty well. I'd love to add 
some quirk for the RD790 chipset, but I'd like to know what the rules are 
for it. I know we have some AMD contacts, I wonder if they could give docs 
(I don't personally do NDA's, but I can do "gentleman's agreements" where 
I just say I won't spread things further, as long as I can write code 
based on them. I know other kernel developers do similar things).

Jordan?

			Linus