Re: PCI MAINTAINER change

Re: PCI MAINTAINER change

[Robert Hancock]

Ingo Molnar wrote:
> * 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.

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.

Re: PCI MAINTAINER change

[Jesse Barnes]

On Monday, April 21, 2008 9:22 am Ingo Molnar wrote:
> * 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.

Yeah, address space allocation seems to be a perennial problem.  Fortunately 
it looks like I'll be able to get ahold of some nifty PCI test equipment so 
that I can reproduce weird topologies.  I'll take a look at the bug you 
mentioned too (gotta triage the rest of the PCI bugs anyway).

Fortunately, Kristen will still be taking care of hotplug issues.  Picking her 
brain about the weirdness she's seen there is on my TODO list.

Thanks,
Jesse

Re: PCI MAINTAINER change

[Ingo Molnar]

* 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.

In looking for the origins of the gap-rounding code I eventually found commit
f0eca9626c6becb6fc56106b2e4287c6c784af3d from 2005-09-09:

[PATCH] Update PCI IOMEM allocation start

    This fixes the problem with "Averatec 6240 pcmcia_socket0: unable to
    apply power", which was due to the CardBus IOMEM register region being
    allocated at an address that was actually inside the RAM window that had
    been reserved for video frame-buffers in an UMA setup.

This introduces a simple 'rounding up' algorithm to create a 'gap' between top
of system RAM and beginning of PCI IOMEM as a guard against unintentional
over-writes.

The algorithm used was suggested in an example by Linus Torvalds with some
provisos but was adopted verbatim in the patch for the Averatec bug. In his
email, Linus went on to say:

"The other alternative is to make PCI allocations generally start at the
high range of the allowable - judging by the lspci listings I've seem from
people under Windows, that seems to be what Windows does, which might be a
good idea (ie the closer we match windows allocation patterns, the more
likely we're to not hit some unmarked region - because windows testing
would have hit it too)."

See:
http://lists.infradead.org/pipermail/linux-pcmcia/2005-September/002625.html

That comment reflects my findings in dealing with this bug. Looking at the bug
there are four issues:

1. No 256MB region on a 256MB boundary available for the GFX IOMEM in the
single largest PCI IOMEM region.

2. The first available 256MB region on a 256MB boundary is unusable because
pci_mem_start is being 'rounded up' to gap_start + round.

3. Multiple gaps higher in the address space are left unused whereas Windows
uses them for smaller allocations thus keeping the largest gap free for the
devices with large requirements.

4. Resources aren't being allocated top-down (subtractive decode) as
recommended in PCI specs and Intel chipset datasheets, and done by Windows.

If [3] was implemented in addition to [4] the smaller allocations would be at
the top of the 32-bit address space much like Windows.

Implementing [3] and [4] together should avoid the need for commit f0eca962
(Cardbus IOMEM in shared video RAM space) since the Cardbus IOMEM would be in a
'high' gap (as it would be with Windws).

Dropping commit f0eca962 would solve [2] since the GFX could allocate 256MB on
the 256MB boundary at 0xC0000000 in the largest gap.

There might be an issue if a system has an undeclared shared video memory
region *and* another PCI device that needs a large allocation.

Also, Linus' mention of maintaining an unused gap between top-of-RAM and
bottom-of-PCI-IOMEM needs to be considered. Would implementation of [2] and [3]
negate the need for it? 
Windows doesn't maintain a similar gap - is there a reason that Linux should?


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Re: PCI MAINTAINER change

[Linus Torvalds]

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.

			Linus

Re: PCI MAINTAINER change

[Jesse Barnes]

On Sunday, April 20, 2008 11:28 pm Greg KH wrote:
> On Sun, Apr 20, 2008 at 11:21:39PM -0700, Greg KH wrote:
> > Here are a some PCI and PCI hotplug patches against your 2.6.25 git tree.
> >
> > They contain:
> > 	- documentation movement into a new directory
> > 	- pci section warning fixes
> > 	- more generic PCI code for some arches
> > 	- removal of the duplicated list of all PCI devices in the system
> > 	- second go-around for the PCI ASPM code
> > 	- various bugs and other minor stuff
> > 	- change the PCI maintainer
>
> I just wanted to highlight this last entry.  I'm passing the PCI
> subsystem maintainership on to Jesse Barnes <jbarnes@virtuousgeek.org>
>
> I'd like to thank him for volunteering for the job, something for which
> I know he is more than capable.
>
> So those of you who have automated scripts to hit me with PCI
> issues/bugs/complaints, might want to adjust them at this point in time.
>
> Now what to do with all of this extra free time I'm going to have...

And now I get to figure out just how much trouble I've gotten myself into...

Thanks for all the time you've put into it, Greg.  Maybe your extra free time 
can be spent on that 5th driver core re-write you've been talking about. :)

Thanks,
Jesse

PCI MAINTAINER change

[Greg KH]

On Sun, Apr 20, 2008 at 11:21:39PM -0700, Greg KH wrote:
> Here are a some PCI and PCI hotplug patches against your 2.6.25 git tree.
> 
> They contain:
> 	- documentation movement into a new directory
> 	- pci section warning fixes
> 	- more generic PCI code for some arches
> 	- removal of the duplicated list of all PCI devices in the system
> 	- second go-around for the PCI ASPM code
> 	- various bugs and other minor stuff
> 	- change the PCI maintainer

I just wanted to highlight this last entry.  I'm passing the PCI
subsystem maintainership on to Jesse Barnes <jbarnes@virtuousgeek.org>

I'd like to thank him for volunteering for the job, something for which
I know he is more than capable.

So those of you who have automated scripts to hit me with PCI
issues/bugs/complaints, might want to adjust them at this point in time.

Now what to do with all of this extra free time I'm going to have...

greg k-h