> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Mon, 21 Apr 2008, Jesse Barnes wrote:
>>> And now I get to figure out just how much trouble I've gotten myself into...
>> Mwhahahaaa! Sucker. You'll find out.
>>
>> The good news is that most of the time, the PCI code works fine. The
>> bad news is that when it doesn't work, it's usually due to something
>> *really* odd, like some magic motherboard device that has magic
>> resources that aren't part of the standard PCI resource set and that
>> clash with some of our resource allocation.
>>
>> And they don't show up in the PnP lists because Windows never put
>> anything that could clash with them, so there was no reason for the
>> BIOS engineers to bother.
>>
>> IOW, it's usually almost totally undebuggable crud like "driver X
>> doesn't work on my machine", and then it turns out that it only
>> happens on that particular motherboard that is totally identical to
>> all other motherboards _except_ for that BIOS table not having the
>> right reserved IO regions.
>>
>> .. and then there's the pluggable PCI stuff, of course. I'm not sure
>> whether you took that over too. That's a whole different set of
>> issues.
>
> that reminds me of the observations about differences between Linux's
> and Windows's PCI resource allocation stategies, see the bugzilla entry
> from today below.
>
> Ingo
>
> ----------------->
>
>
http://bugzilla.kernel.org/show_bug.cgi?id=10461
>
> ------- Comment #6 from
linux@tjworld.net 2008-04-18 11:03 -------
> After a few debug printk() runs watching the allocation strategy I wondered why
> the PCI resources region doesn't start at the beginning of the largest gap:
>
> [ 0.000000] Allocating PCI resources starting at c2000000 (gap:
> c0000000:20000000)
>
> since, when 3GB RAM is installed, the gap starts at 0xC0000000 but the
> allocation region begins at 0xC2000000.
>
> The other issue is that only the largest gap seems to be used for allocations,
> which explains why smaller allocations for other devices effectively choke off
> use of the range in 32-bit address space.
>
> In contrast, from looking at the addresses in the allocation comparison with
> Windows, it looks as if Windows uses *all* gaps for allocation rather than just
> the largest. It is noticeable that Windows allocates smaller regions in the
> gaps between the various 'high' e820 reservations.
