lkml.org 
[lkml]   [2008]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd


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


\
 
 \ /
  Last update: 2008-08-31 06:17    [from the cache]
©2003-2011 Jasper Spaans