linux-kernel - Re: PCI MAINTAINER change

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>] [day] [month] [year] [list]

Date:	Mon, 21 Apr 2008 19:27:40 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz,
	pcihpd-discuss@...ts.sourceforge.net, mingo@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: PCI MAINTAINER change

Ingo Molnar wrote:
> * Linus Torvalds <torvalds@...ux-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@...orld.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.

I think the reason for this being needed in the first place was in the 
old days we didn't honor the ACPI reserved motherboard resources, or did 
only for certain resource types (and we still have problems with this, 
like the hard-coded limit on max number of PnPACPI resources that's hit 
by many boards and which results in us ignoring some of the BIOS 
reservations). Once that junk is fixed, hopefully we won't have to worry 
about such problems.
--
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/