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

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

[Rafael J. Wysocki]

On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
> On Friday, 29 of August 2008, Linus Torvalds wrote:
> > 
> > Another week (my weeks do seem to be eight days, don't they? Very odd), 
> > another -rc.
> > 
> > The dirstat pretty much says it all:
> > 
> >   43.0% arch/arm/configs/
> >   43.9% arch/arm/
> >   25.5% arch/powerpc/configs/
> >   26.8% arch/powerpc/
> >   73.9% arch/
> >    4.4% drivers/usb/musb/
> >    5.4% drivers/usb/
> >    4.0% drivers/watchdog/
> >   16.0% drivers/
> >    3.5% fs/
> > 
> > yeah, the bulk of it is all config updates, and with arm and powerpc 
> > leading the pack.
> 
> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
> 
> Bisecting ...

Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:

commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date:   Mon Aug 25 00:56:08 2008 -0700

    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3

Reverting this commit helps.

The symptom is that AHCI probe fails with this commit applied.

Thanks,
Rafael

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
>> On Friday, 29 of August 2008, Linus Torvalds wrote:
>> >
>> > Another week (my weeks do seem to be eight days, don't they? Very odd),
>> > another -rc.
>> >
>> > The dirstat pretty much says it all:
>> >
>> >   43.0% arch/arm/configs/
>> >   43.9% arch/arm/
>> >   25.5% arch/powerpc/configs/
>> >   26.8% arch/powerpc/
>> >   73.9% arch/
>> >    4.4% drivers/usb/musb/
>> >    5.4% drivers/usb/
>> >    4.0% drivers/watchdog/
>> >   16.0% drivers/
>> >    3.5% fs/
>> >
>> > yeah, the bulk of it is all config updates, and with arm and powerpc
>> > leading the pack.
>>
>> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>>
>> Bisecting ...
>
> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>
> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date:   Mon Aug 25 00:56:08 2008 -0700
>
>    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>
> Reverting this commit helps.
>

can i get whole bootlog with "debug"?

YH

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 2:13 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
>>> On Friday, 29 of August 2008, Linus Torvalds wrote:
>>> >
>>> > Another week (my weeks do seem to be eight days, don't they? Very odd),
>>> > another -rc.
>>> >
>>> > The dirstat pretty much says it all:
>>> >
>>> >   43.0% arch/arm/configs/
>>> >   43.9% arch/arm/
>>> >   25.5% arch/powerpc/configs/
>>> >   26.8% arch/powerpc/
>>> >   73.9% arch/
>>> >    4.4% drivers/usb/musb/
>>> >    5.4% drivers/usb/
>>> >    4.0% drivers/watchdog/
>>> >   16.0% drivers/
>>> >    3.5% fs/
>>> >
>>> > yeah, the bulk of it is all config updates, and with arm and powerpc
>>> > leading the pack.
>>>
>>> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>>>
>>> Bisecting ...
>>
>> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>>
>> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
>> Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date:   Mon Aug 25 00:56:08 2008 -0700
>>
>>    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>>
>> Reverting this commit helps.

can you try tip/master?  we have another fix according to Linus..

YH

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

[Rafael J. Wysocki]

On Friday, 29 of August 2008, Yinghai Lu wrote:
> On Fri, Aug 29, 2008 at 2:13 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >> On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
> >>> On Friday, 29 of August 2008, Linus Torvalds wrote:
> >>> >
> >>> > Another week (my weeks do seem to be eight days, don't they? Very odd),
> >>> > another -rc.
> >>> >
> >>> > The dirstat pretty much says it all:
> >>> >
> >>> >   43.0% arch/arm/configs/
> >>> >   43.9% arch/arm/
> >>> >   25.5% arch/powerpc/configs/
> >>> >   26.8% arch/powerpc/
> >>> >   73.9% arch/
> >>> >    4.4% drivers/usb/musb/
> >>> >    5.4% drivers/usb/
> >>> >    4.0% drivers/watchdog/
> >>> >   16.0% drivers/
> >>> >    3.5% fs/
> >>> >
> >>> > yeah, the bulk of it is all config updates, and with arm and powerpc
> >>> > leading the pack.
> >>>
> >>> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
> >>>
> >>> Bisecting ...
> >>
> >> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> >>
> >> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> >> Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Date:   Mon Aug 25 00:56:08 2008 -0700
> >>
> >>    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> >>
> >> Reverting this commit helps.
> 
> can you try tip/master?  we have another fix according to Linus..

I have tested the patch that Linus sent me and it works.  Please see my reply
to Linus for the link to the dmesg output.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Friday, 29 of August 2008, Yinghai Lu wrote:
> On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
> >> On Friday, 29 of August 2008, Linus Torvalds wrote:
> >> >
> >> > Another week (my weeks do seem to be eight days, don't they? Very odd),
> >> > another -rc.
> >> >
> >> > The dirstat pretty much says it all:
> >> >
> >> >   43.0% arch/arm/configs/
> >> >   43.9% arch/arm/
> >> >   25.5% arch/powerpc/configs/
> >> >   26.8% arch/powerpc/
> >> >   73.9% arch/
> >> >    4.4% drivers/usb/musb/
> >> >    5.4% drivers/usb/
> >> >    4.0% drivers/watchdog/
> >> >   16.0% drivers/
> >> >    3.5% fs/
> >> >
> >> > yeah, the bulk of it is all config updates, and with arm and powerpc
> >> > leading the pack.
> >>
> >> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
> >>
> >> Bisecting ...
> >
> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> >
> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> > Author: Yinghai Lu <yhlu.kernel@gmail.com>
> > Date:   Mon Aug 25 00:56:08 2008 -0700
> >
> >    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> >
> > Reverting this commit helps.
> >
> 
> can i get whole bootlog with "debug"?

http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log

Thanks,
Rafael

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 3:31 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Friday, 29 of August 2008, Yinghai Lu wrote:
>> On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> > On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
>> >> On Friday, 29 of August 2008, Linus Torvalds wrote:
>> >> >
>> >> > Another week (my weeks do seem to be eight days, don't they? Very odd),
>> >> > another -rc.
>> >> >
>> >> > The dirstat pretty much says it all:
>> >> >
>> >> >   43.0% arch/arm/configs/
>> >> >   43.9% arch/arm/
>> >> >   25.5% arch/powerpc/configs/
>> >> >   26.8% arch/powerpc/
>> >> >   73.9% arch/
>> >> >    4.4% drivers/usb/musb/
>> >> >    5.4% drivers/usb/
>> >> >    4.0% drivers/watchdog/
>> >> >   16.0% drivers/
>> >> >    3.5% fs/
>> >> >
>> >> > yeah, the bulk of it is all config updates, and with arm and powerpc
>> >> > leading the pack.
>> >>
>> >> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>> >>
>> >> Bisecting ...
>> >
>> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>> >
>> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
>> > Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > Date:   Mon Aug 25 00:56:08 2008 -0700
>> >
>> >    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>> >
>> > Reverting this commit helps.
>> >
>>
>> can i get whole bootlog with "debug"?
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>


pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
pci 0000:00:12.0: BAR 5: can't allocate resource
pci 0000:00:13.0: BAR 0: can't allocate resource
pci 0000:00:13.1: BAR 0: can't allocate resource
pci 0000:00:13.2: BAR 0: can't allocate resource
pci 0000:00:13.3: BAR 0: can't allocate resource
pci 0000:00:13.4: BAR 0: can't allocate resource
pci 0000:00:13.5: BAR 0: can't allocate resource
pci 0000:00:14.2: BAR 0: can't allocate resource

your mmconf in BAR is broken....

after forcibly insert that block all others...

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> >
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
> 
> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff

And that seems utter crap to begin with.

	PCI: Using MMCONFIG at e0000000 - efffffff

Where did it get that bogus "ffffffff" end address?

Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with, 
and it's reverted now in my tree, so I guess it doesn't much matter.

			Linus

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> >
>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>>
>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>
> And that seems utter crap to begin with.
>
>        PCI: Using MMCONFIG at e0000000 - efffffff
>
> Where did it get that bogus "ffffffff" end address?

the BAR is from pci_read_bases..., so that chipset is broken...
they are even supposed to to hide that BAR to os.

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> the BAR is from pci_read_bases..., so that chipset is broken...
> they are even supposed to to hide that BAR to os.

Ok, can we please

 - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is 
   not an x86 issue)

 - *not* get any more random PCI work-arounds that go through the x86 tree 
   and aren't even looked at by the (very few) people who actually 
   understand the PCI resource handling?

IOW, for the first issue, just teach pci_mmcfg_check_hostbridge() about 
this broken bridge, and have it fix things up (including hiding the thing, 
but also just verifying that the dang thing even -works- etc).

For the second issue - please do realize that we have had much over a 
_decade_ of work on the PCI resource handling, and it's fragile. The thing 
I reverted really isn't something that Ingo should ever have committed in 
the first place. It's not something an x86 maintainer can even make sane 
decisions on.

Resource handling things _need_ to get ACK's from people like Ivan 
Kokshaysky or me. Or at least _several_ other people who actually really 
understand not just PCI resource handling, but have actually seen all the 
horrible crap it causes, and understand how fragile this stuff is. It's 
all different, and it's all about all the million of broken machines out 
there that screw things up.

			Linus

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

[Linus Torvalds]

Btw, what was the original regression that commit was 
a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?

It's not listed in that commit, even though the commit has a "Bisected-by: 
David Witbrodt <dawitbro-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org>".

In fact, I can find it with google by searching for

	David Witbrodt bisect

and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.

I'm wondering why that commit wasn't just reverted? Because now that I see 
it, I notice that _that_ is the real bug to begin with.

That commit really was buggy. NO WAY can you insert the code/bss/data 
resources before you've done e820 handling, because it may well be that 
some strange e820 table contains things that cross the resources.

So that original thing was buggy, and made x86-64 do odd thigns. They were 
doubly odd, since x86-32 did it differently (and better, I think).

Then, when actally doing the common arch/x86/kernel/setup.c, the commit 
that does so _claims_ that the common code came from the 32-bit version, 
but that doesn't seem to be true, at least wrt this thing. The current 
setup.c comes from the *broken* cleanup of setup_64.c that had been 
bisected to be broken.

And that, in turn, happened in 41c094fd3ca54f1a71233049cf136ff94c91f4ae 
("x86: move e820_resource_resources to e820.c") which also did "and make 
32-bit resource registration more like 64 bit.", so it got the bug into 
32-bit code that had been introduced in 64-bit code.

Ugh.

So why was then that other broken commit added to paper it over, even 
though the original broken commit had been bisected and the breakage was 
known to have been due to _that_?

Hmm?

Yinghai - I'm hoping that the code movement is all over and done with, but 
you need to be a _lot_ more careful here. And Ingo, this really wasn't 
very well done.

			Linus

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 6:11 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> Btw, what was the original regression that commit was
> a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?
>
> It's not listed in that commit, even though the commit has a "Bisected-by:
> David Witbrodt <dawitbro-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org>".
>
> In fact, I can find it with google by searching for
>
>        David Witbrodt bisect
>
> and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.
>
> I'm wondering why that commit wasn't just reverted? Because now that I see
> it, I notice that _that_ is the real bug to begin with.
>
> That commit really was buggy. NO WAY can you insert the code/bss/data
> resources before you've done e820 handling, because it may well be that
> some strange e820 table contains things that cross the resources.

we reverted the commit , David's problem still happen.

the root cause is:
before 2.6.26, call init_apic_mapping and will insert_resource for
lapic address.
and then call e820_resource_resouce (with request_resource) to
register e820 entries.
so the lapic entry in the resource tree will prevent some entry in
e820 to be registered.
later request_resource for BAR res (==hpet) will succeed.

from 2.6.26. we move lapic address registering to late_initcall, so
the entry is reserved in e820 getting into resource tree at first.
and later pci_resource_survey::request_resource for BAR res (==hpet,
0xfed00000) will fail. so pci_assign_unsigned... will get new
res for the BAR, so it messed up hpet setting.

solutions will be
1. use quirk to protect hpet in BAR, Ingo said it is not generic.
2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
mmconfig) --> happenly reveal another problem with Rafael's
system/chipset.
3. or sticky resource... , but could have particallly overlapping
4. or don't register reserved entries in e820.. Eric, Nacked.
5. or you sugges, regiser some reserved entries later...., and have
insert_resource_expand_to_fit...

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> the root cause is:
> before 2.6.26, call init_apic_mapping and will insert_resource for
> lapic address.
> and then call e820_resource_resouce (with request_resource) to
> register e820 entries.

So the problem there was that traditionally, e820_reserve_resource() 
expected to be the first one to populate any resources. That's changed, 
and that's why it now needs to use "insert_resource()" rather than 
"request_resource()".

> so the lapic entry in the resource tree will prevent some entry in
> e820 to be registered.
> later request_resource for BAR res (==hpet) will succeed.
> 
> from 2.6.26. we move lapic address registering to late_initcall, so
> the entry is reserved in e820 getting into resource tree at first.
> and later pci_resource_survey::request_resource for BAR res (==hpet,
> 0xfed00000) will fail. so pci_assign_unsigned... will get new
> res for the BAR, so it messed up hpet setting.

So this didn't work _originally_ either? 

> solutions will be
> 1. use quirk to protect hpet in BAR, Ingo said it is not generic.

Yeah, I don't like it. The quirk I was talking about was the one about 
apparetly bogus MMIO address:

>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>        PCI: Using MMCONFIG at e0000000 - efffffff
>
> Where did it get that bogus "ffffffff" end address?

which you said came from another BAR. That isn't the HPET.


> 2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
> mmconfig) --> happenly reveal another problem with Rafael's
> system/chipset.

Yeah, no, that's horrid. I'm happy it's reverted.

> 3. or sticky resource... , but could have particallly overlapping

And no, this doesn't work.

> 4. or don't register reserved entries in e820.. Eric, Nacked.

Yeah, no, we do want reserved entries from e820 to show up to at least 
stop late _dynamic_ allocations from taking over.

> 5. or you sugges, regiser some reserved entries later...., and have
> insert_resource_expand_to_fit...

Yes. And I do think this is a workable model.

			Linus

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Linus Torvalds wrote:
> 
> Yes. And I do think this is a workable model.

Ok, and here's the patch to do

	insert_resource_expand_to_fit(root, new);

and while I still haven't actually tested it, it looks sane and compiles 
to code that also looks sane.

I'll happily commit this as basic infrastructure as soon as somebody ack's 
it and tests that it works (and I'll try it myself soon enough, just for 
fun)

		Linus

---
 include/linux/ioport.h |    1 +
 kernel/resource.c      |   88 ++++++++++++++++++++++++++++++++++-------------
 2 files changed, 64 insertions(+), 25 deletions(-)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 22d2115..8d3b7a9 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -109,6 +109,7 @@ extern struct resource iomem_resource;
 extern int request_resource(struct resource *root, struct resource *new);
 extern int release_resource(struct resource *new);
 extern int insert_resource(struct resource *parent, struct resource *new);
+extern void insert_resource_expand_to_fit(struct resource *root, struct resource *new);
 extern int allocate_resource(struct resource *root, struct resource *new,
 			     resource_size_t size, resource_size_t min,
 			     resource_size_t max, resource_size_t align,
diff --git a/kernel/resource.c b/kernel/resource.c
index f5b518e..72ee95b 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -362,35 +362,21 @@ int allocate_resource(struct resource *root, struct resource *new,
 
 EXPORT_SYMBOL(allocate_resource);
 
-/**
- * insert_resource - Inserts a resource in the resource tree
- * @parent: parent of the new resource
- * @new: new resource to insert
- *
- * Returns 0 on success, -EBUSY if the resource can't be inserted.
- *
- * This function is equivalent to request_resource when no conflict
- * happens. If a conflict happens, and the conflicting resources
- * entirely fit within the range of the new resource, then the new
- * resource is inserted and the conflicting resources become children of
- * the new resource.
+/*
+ * Insert a resource into the resource tree. If successful, return NULL,
+ * otherwise return the conflicting resource (compare to __request_resource())
  */
-int insert_resource(struct resource *parent, struct resource *new)
+static struct resource * __insert_resource(struct resource *parent, struct resource *new)
 {
-	int result;
 	struct resource *first, *next;
 
-	write_lock(&resource_lock);
-
 	for (;; parent = first) {
-	 	result = 0;
 		first = __request_resource(parent, new);
 		if (!first)
-			goto out;
+			return first;
 
-		result = -EBUSY;
 		if (first == parent)
-			goto out;
+			return first;
 
 		if ((first->start > new->start) || (first->end < new->end))
 			break;
@@ -401,15 +387,13 @@ int insert_resource(struct resource *parent, struct resource *new)
 	for (next = first; ; next = next->sibling) {
 		/* Partial overlap? Bad, and unfixable */
 		if (next->start < new->start || next->end > new->end)
-			goto out;
+			return next;
 		if (!next->sibling)
 			break;
 		if (next->sibling->start > new->end)
 			break;
 	}
 
-	result = 0;
-
 	new->parent = parent;
 	new->sibling = next->sibling;
 	new->child = first;
@@ -426,10 +410,64 @@ int insert_resource(struct resource *parent, struct resource *new)
 			next = next->sibling;
 		next->sibling = new;
 	}
+	return NULL;
+}
 
- out:
+/**
+ * insert_resource - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ *
+ * This function is equivalent to request_resource when no conflict
+ * happens. If a conflict happens, and the conflicting resources
+ * entirely fit within the range of the new resource, then the new
+ * resource is inserted and the conflicting resources become children of
+ * the new resource.
+ */
+int insert_resource(struct resource *parent, struct resource *new)
+{
+	struct resource *conflict;
+
+	write_lock(&resource_lock);
+	conflict = __insert_resource(parent, new);
 	write_unlock(&resource_lock);
-	return result;
+	return conflict ? -EBUSY : 0;
+}
+
+/**
+ * insert_resource_expand_to_fit - Insert a resource into the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Insert a resource into the resource tree, possibly expanding it in order
+ * to make it encompass any conflicting resources.
+ */
+void insert_resource_expand_to_fit(struct resource *root, struct resource *new)
+{
+	if (new->parent)
+		return;
+
+	write_lock(&resource_lock);
+	for (;;) {
+		struct resource *conflict;
+
+		conflict = __insert_resource(root, new);
+		if (!conflict)
+			break;
+		if (conflict == root)
+			break;
+
+		/* Ok, expand resource to cover the conflict, then try again .. */
+		if (conflict->start < new->start)
+			new->start = conflict->start;
+		if (conflict->end > new->end)
+			new->end = conflict->end;
+
+		printk("Expanded resource %s due to conflict with %s", new->name, conflict->name);
+	}
+	write_unlock(&resource_lock);	
 }
 
 /**

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 7:56 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Linus Torvalds wrote:
>>
>> Yes. And I do think this is a workable model.
>
> Ok, and here's the patch to do
>
>        insert_resource_expand_to_fit(root, new);
>
> and while I still haven't actually tested it, it looks sane and compiles
> to code that also looks sane.
>
> I'll happily commit this as basic infrastructure as soon as somebody ack's
> it and tests that it works (and I'll try it myself soon enough, just for
> fun)

we need to use insert_resource_split_to_fit instead...

otherwise __request_region will not be happy.

have one shrink one

only work with
  |----------------|
          |---------------------|

still has problem with

  |----------------| |------------|     |-----------|
          |------------------------------------|

need to get rid of middle one too.

YH


---
 arch/x86/kernel/e820.c |   20 +++++++++++++-
 include/linux/ioport.h |    2 +
 kernel/resource.c      |   66 ++++++++++++++++++++++++++++++++++++++++---------
 3 files changed, 74 insertions(+), 14 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1319,8 +1319,24 @@ void __init e820_reserve_resources_late(

        res = e820_res;
        for (i = 0; i < e820.nr_map; i++) {
-               if (!res->parent && res->end)
-                       insert_resource(&iomem_resource, res);
+#if 1
+               /* test for shrink_with fit */
+               if (!res->parent && res->end) {
+                       if (res->start == 0xe0000000)
+                               res->start = 0xde000000;
+               }
+#endif
+
+               if (!res->parent && res->end &&
insert_resource(&iomem_resource, res)) {
+
+                       printk(KERN_WARNING "found conflict for %s
[%08llx, %08llx], try to insert with shrink\n",
+                               res->name, res->start, res->end);
+
+                       insert_resource_shrink_to_fit(&iomem_resource, res);
+
+                       printk(KERN_WARNING "   shrink to %s [%08llx,
%08llx]\n",
+                               res->name, res->start, res->end);
+               }
                res++;
        }
 }
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -108,6 +108,8 @@ extern struct resource iomem_resource;

 extern int request_resource(struct resource *root, struct resource *new);
 extern int release_resource(struct resource *new);
+extern void insert_resource_shrink_to_fit(struct resource *root,
+                                         struct resource *new);
 extern int insert_resource(struct resource *parent, struct resource *new);
 extern int allocate_resource(struct resource *root, struct resource *new,
                             resource_size_t size, resource_size_t min,
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -363,32 +363,30 @@ int allocate_resource(struct resource *r
 EXPORT_SYMBOL(allocate_resource);

 /**
- * insert_resource - Inserts a resource in the resource tree
+ * __insert_resource - Inserts a resource in the resource tree
  * @parent: parent of the new resource
  * @new: new resource to insert
  *
- * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ * Returns NULL on success, or first conflict resource.
  *
- * This function is equivalent to request_resource when no conflict
+ * This function is equivalent to __request_resource when no conflict
  * happens. If a conflict happens, and the conflicting resources
  * entirely fit within the range of the new resource, then the new
  * resource is inserted and the conflicting resources become children of
  * the new resource.
  */
-int insert_resource(struct resource *parent, struct resource *new)
+static struct resource *__insert_resource(struct resource *parent,
struct resource *new)
 {
-       int result;
+       struct resource *ret_res;
        struct resource *first, *next;

-       write_lock(&resource_lock);
-
        for (;; parent = first) {
-               result = 0;
+               ret_res = NULL;
                first = __request_resource(parent, new);
                if (!first)
                        goto out;

-               result = -EBUSY;
+               ret_res = first;
                if (first == parent)
                        goto out;

@@ -400,15 +398,17 @@ int insert_resource(struct resource *par

        for (next = first; ; next = next->sibling) {
                /* Partial overlap? Bad, and unfixable */
-               if (next->start < new->start || next->end > new->end)
+               if (next->start < new->start || next->end > new->end) {
+                       ret_res = next;
                        goto out;
+               }
                if (!next->sibling)
                        break;
                if (next->sibling->start > new->end)
                        break;
        }

-       result = 0;
+       ret_res = NULL;

        new->parent = parent;
        new->sibling = next->sibling;
@@ -428,11 +428,53 @@ int insert_resource(struct resource *par
        }

  out:
+       return ret_res;
+}
+
+/**
+ * insert_resource_shrink_to_fit - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ */
+void insert_resource_shrink_to_fit(struct resource *root, struct resource *new)
+{
+       write_lock(&resource_lock);
+       while (new->start && !new->parent) {
+               struct resource *conflict;
+
+               conflict = __insert_resource(root, new);
+               if (!conflict)
+                       break;
+               if (conflict->start < new->start) {
+                       new->start = conflict->end;
+                       continue;
+               }
+               if (conflict->end > new->end) {
+                       new->end = conflict->start;
+                       continue;
+               }
+       }
        write_unlock(&resource_lock);
-       return result;
 }

 /**
+ * insert_resource - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ */
+int insert_resource(struct resource *parent, struct resource *new)
+{
+       struct resource *res_conflict;
+
+       write_lock(&resource_lock);
+       res_conflict = __insert_resource(parent, new);
+       write_unlock(&resource_lock);
+
+       return res_conflict ? -EBUSY : 0;
+}
+/**
  * adjust_resource - modify a resource's start and size
  * @res: resource to modify
  * @start: new start value

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> we need to use insert_resource_split_to_fit instead...
> 
> otherwise __request_region will not be happy.

Are you really really sure?

Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI 
BAR's to work with the e820 resources, then BUSY really is simply not 
right any more. Not that I think it should matter either..

The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones 
that cover RAM), but the others we now expect to nest with PCI BARs.

But since we add them after we have parsed the BAR's, I don't even see why 
the BUSY bit should even matter - we've already added the fixed BARs, and 
any newly allocated non-fixed ones shouldn't be allocated in e820 areas 
_regardless_ of whether the BUSY bit is set or not.

So pls explain why it matters?

		Linus

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> we need to use insert_resource_split_to_fit instead...
>>
>> otherwise __request_region will not be happy.
>
> Are you really really sure?
>
> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
> BAR's to work with the e820 resources, then BUSY really is simply not
> right any more. Not that I think it should matter either..
>
> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
> that cover RAM), but the others we now expect to nest with PCI BARs.

not all. some are MMCONF, some are for GART, and some for fixed lapic,
and fixed ioapic, and fixed HPET.

>
> But since we add them after we have parsed the BAR's, I don't even see why
> the BUSY bit should even matter - we've already added the fixed BARs, and
> any newly allocated non-fixed ones shouldn't be allocated in e820 areas
> _regardless_ of whether the BUSY bit is set or not.
>
> So pls explain why it matters?

if we don't add the IORESOURCE_BUSY, why bother to add these entries...

good layout from BIOS, it should only reserve mmio range is not showing in BAR.

for example:
0xdc000000 - 0xdd000000 for GART ( some offset BAR 0x94)
0xdd000000 - 0xde000000 is for bus 0x80
0xde000000 - 0xdf000000 is for bus 0x00
0xe0000000 - 0xf0000000 is for mmconfig ( CPU set it in MSR for amd fam 10h)

if one stupid BIOS set
0xdc000000 - 0x100000000 for reserved.

then when in insert that range late
we should still have set ranges other than range 0xdd000000 - 0xdf000000

also do we need set other leaf range in 0xdd000000 - 0xdf0000000 ?

YH

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 9:41 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>
>>
>> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>>
>>> we need to use insert_resource_split_to_fit instead...
>>>
>>> otherwise __request_region will not be happy.
>>
>> Are you really really sure?
>>
>> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
>> BAR's to work with the e820 resources, then BUSY really is simply not
>> right any more. Not that I think it should matter either..
>>
>> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
>> that cover RAM), but the others we now expect to nest with PCI BARs.
>
> not all. some are MMCONF, some are for GART, and some for fixed lapic,
> and fixed ioapic, and fixed HPET.

we may not need put reserve entries from e820 into resource tree.
and only insert those sticky resources (with _BUSY) before
pci_assign_unassign and _request_region etc.

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> if we don't add the IORESOURCE_BUSY, why bother to add these entries...

You don't understand how the resource allocator works.

IORESOURCE_BUSY is really more of a "legacy bit". It has almost no bearing 
on the actual allocations.

Just grep for IORSOURCE_BUSY in kernel/resource.c. The _only_ thing that 
cares about busy/non-busy is the legact "request_region()" function. That 
one isn't actually used by any core PCI code - it's more of a driver 
issue to claim exclusive ownership of particular resources by inserting a 
marker in that resource.

So IORESOURCE_BUSY is a red herring. The only reason I said you can clear 
it is because you claimed it causes problems, but the more I look at it, 
the more I think you're likely just mistaken - because IORESOURCE_BUSY 
doesn't make any difference at all to normal resource handling until you 
get to actual drivers.

The bigger issue is that just inserting the resource (and it really 
doesn't matter if it is marked busy or not) is in itself a mark of 
"there's something here". THAT is what all the resource code cares about. 
The IORESOURCE_BUSY bit is almost immaterial (ie _is_ immaterial except 
for some very specific cases).

And the reason we need to add the e820 resources is exactly so that we 
don't try to allocate PCI resources on top of some system resources we 
don't even know about!

> good layout from BIOS, it should only reserve mmio range is not showing in BAR.

I agree, but "good layour" and "BIOS" don't really go together. There's 
too many broken BIOSes.

> if one stupid BIOS set
> 0xdc000000 - 0x100000000 for reserved.
> 
> then when in insert that range late

Sure, but really, the only point of even caring about e820 resources in 
the first place has really nothing to do with the BAR's we can see 
(because the kernel can handle _those_ perfectly well on its own), and has 
everything to do with teh fact that a lot of devices have invisible 
resources that we _cannot_ see (ie magic non-standard BAR's for the 
motherboard chips).

And those are exactly why we want to populate the resource map with the 
e820 information - to avoid having dynamic resources (like Cardbus or PCI 
hotplug, or just devices that weren't set up statically by the BIOS) be 
then allocated by the kernel on top of those "invisible" resources.

And the dynamic code actually doesn't care about IORESOURCE_BUSY at all: 
it will avoid _any_ resource it can see. Think about it: it has to - since 
existing PCI resources we have set up will _not_ have that IORESOURCE_BUSY 
set.

In many ways, IORESOURCE_BUSY is pure legacy stuff, and is meant for "this 
is a black hole and you must not look into it at all". It originates with 
a need to originally having to lock drivers away from other drives by 
marking their resources busy - in an ISA world, where there are no other 
ways of saying "I own this device".

(Yeah, yeah, PCI drivers do the same thing too - they mark their BAR's by 
inserting a per-driver entry in the BAR to say 'I own this resource').

But this is where adding the e820 resources _after_ doing PCI discovery 
comes in. We don't want to clash with PCI discovery per se - we just want 
to make sure that later allocations don't allocate over anything that we 
either saw earlier (the BAR's we found set up in regular PCI discovery) 
_or_ anything that the system has said is reserved (e820 reserved 
entries).

Doing it before obviously works too - in fact, it has worked for us for 
years. But it does mean that we consider the e820 reserved areas _so_ 
reserved that we don't allow PCI BAR's in them. Which is apparently a 
mistake.

We want to consider them so reserved that we don't add _new_ PCI resources 
to them (and perhaps we might even want to stop regular PCI drivers from 
attaching to them), but not so exclusive that we don't allow BARs that 
have been set up by the BIOS in them.

			Linus

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Linus Torvalds wrote:
> 
> IORESOURCE_BUSY is really more of a "legacy bit". It has almost no bearing 
> on the actual allocations.

And just to clarify - I think that while you get that error for the 
qla2xxx driver, I suspect that your actual resource tree is all good, and 
that the PCI allocations were fine.

And then the problem you his is now that the driver literally thinks that 
some other driver already took that resource.

The patch I just sent is not actually the patch I think you should do: the 
proper patch is to just remove IORESOURCE_BUSY from the e820 resources, 
simply because they are _not_ indicative of a driver already holding on to 
the resource.

Of course, the sad part is that potentially IORESOURCE_BUSY might actually 
be a really good bit for exactly that - we've had tons of issues with 
hardware sensors literally having a kernel driver _and_ a system level 
driver (ie ACPI), and things get confused exactly because there are now 
two drivers trying to drive the same piece of hardware.

But basically, if you have BAR's and the e820 resource areas co-existing, 
then the e820 resources shouldn't be marked BUSY.

Anyway - to just re-cap - you might as well just ignore the patch I just 
sent out, and instead just avoid doing that BUSY bit to begin with in the 
"late e820" case. Simpler and more correct.

		Linus

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

[Yinghai Lu]

please check fix v3

[PATCH] x86: split e820 reserved entries record to late v4 - fix v3

try to insert_resource second time, by expand the resource...

for case: e820 reserved entry is partially overlapped with bar res...

hope it will never happen

v3: use reserve_region_with_split() instead to hand overlapping
       with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
       get
               e0000000-efffffff : PCI MMCONFIG 0
                        e0000000-efffffff : reserved
       in /proc/iomem
       get
               found conflict for reserved [dd800000, efffffff], try
to reserve with split
                   __reserve_region_with_split: (PCI Bus #80)
[dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
                   __reserve_region_with_split: (PCI Bus #00)
[de000000, dfffffff], res: (reserved) [de000000, efffffff]
               initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
       in dmesg

YH

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> we need to use insert_resource_split_to_fit instead...
>>
>> otherwise __request_region will not be happy.
>
> Are you really really sure?
>
> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
> BAR's to work with the e820 resources, then BUSY really is simply not
> right any more. Not that I think it should matter either..
>
> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
> that cover RAM), but the others we now expect to nest with PCI BARs.


please check

  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(qla2xxx) [ddffc000, ddffffff]
busy flag
qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]

YH

...



Initializing cgroup subsys cpuset...............................................
Linux version 2.6.27-rc5-tip-00672-ge5c5407-dirty (yhlu@linux-zpir)
(gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux) ) #220 SMP Fri Aug 29 22:02:53 PDT 2008..
Command line: console=uart8250,io,0x3f8,115200n8
initrd=kernel.org/mydisk11_x86_64.gz rw root=/dev/ram0 debug
show_msr=1 i8042.noaux initcall_debug apic=verbose pci=routeirq
ip=dhcp load_ramdisk=1 ramdisk_size=131072
BOOT_IMAGE=kernel.org/bzImage_2.6.27_k8.1
                     done
KERNEL supported cpus:s
  Intel GenuineIntel
  AMD AuthenticAMD
  Centaur CentaurHauls                                               done
BIOS-provided physical RAM map:                                      done
 BIOS-e820: 0000000000000000 - 0000000000097400 (usable)             done
 BIOS-e820: 0000000000097400 - 00000000000a0000 (reserved)           done
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)s.
 BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
 BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (usable)
 BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
 BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
 BIOS-e820: 00000000d7ff0000 - 00000000d8000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000002028000000 (usable)
Early serial console at I/O port 0x3f8 (options '115200n8')
console [uart0] enabled
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel
code) [200000, 970103]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (Kernel code) [200000, 970103]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel
data) [970104, ea9657]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (Kernel data) [970104, ea9657]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel
bss) [f8f000, 1147ee3]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (Kernel bss) [f8f000, 1147ee3]
last_pfn = 0x2028000 max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
last_pfn = 0xd7fb0 max_arch_pfn = 0x3ffffffff
init_memory_mapping
Using GB pages for direct mapping
 0000000000 - 00c0000000 page 1G
 00c0000000 - 00d7e00000 page 2M
 00d7e00000 - 00d7fb0000 page 4k
kernel direct mapping tables up to d7fb0000 @ 8000-b000
last_map_addr: d7fb0000 end: d7fb0000
init_memory_mapping
Using GB pages for direct mapping
 0100000000 - 2000000000 page 1G
 2000000000 - 2028000000 page 2M
kernel direct mapping tables up to 2028000000 @ a000-c000
last_map_addr: 2028000000 end: 2028000000
RAMDISK: 7e6d7000 - 7ffffe0b
DMI present.
..
SRAT: PXM 0 -> APIC 4 -> Node 0
SRAT: PXM 0 -> APIC 5 -> Node 0
SRAT: PXM 0 -> APIC 6 -> Node 0
SRAT: PXM 0 -> APIC 7 -> Node 0
SRAT: PXM 1 -> APIC 8 -> Node 1
SRAT: PXM 1 -> APIC 9 -> Node 1
SRAT: PXM 1 -> APIC 10 -> Node 1
SRAT: PXM 1 -> APIC 11 -> Node 1
SRAT: PXM 2 -> APIC 12 -> Node 2
SRAT: PXM 2 -> APIC 13 -> Node 2
SRAT: PXM 2 -> APIC 14 -> Node 2
SRAT: PXM 2 -> APIC 15 -> Node 2
SRAT: PXM 3 -> APIC 16 -> Node 3
SRAT: PXM 3 -> APIC 17 -> Node 3
SRAT: PXM 3 -> APIC 18 -> Node 3
SRAT: PXM 3 -> APIC 19 -> Node 3
SRAT: Node 0 PXM 0 0-a0000
Adding active range (0, 0x0, 0x97) 0 entries of 12800 used
SRAT: Node 0 PXM 0 100000-d8000000
Adding active range (0, 0x100, 0xd7fa0) 1 entries of 12800 used
Adding active range (0, 0xd7fae, 0xd7fb0) 2 entries of 12800 used
SRAT: Node 0 PXM 0 100000000-828000000
Adding active range (0, 0x100000, 0x828000) 3 entries of 12800 used
SRAT: Node 1 PXM 1 828000000-1028000000
Adding active range (1, 0x828000, 0x1028000) 4 entries of 12800 used
SRAT: Node 2 PXM 2 1028000000-1828000000
Adding active range (2, 0x1028000, 0x1828000) 5 entries of 12800 used
SRAT: Node 3 PXM 3 1828000000-2028000000
Adding active range (3, 0x1828000, 0x2028000) 6 entries of 12800 used
ACPI: SLIT: nodes = 4
 10 13 13 16
 13 10 16 13
 13 16 10 13
 16 13 13 10
NUMA: Allocated memnodemap from b000 - 4b580
NUMA: Using 20 for the hash shift.
..
ACPI: PM-Timer IO Port: 0xe008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x08] enabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x09] enabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0a] enabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x0b] enabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x0c] enabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0d] enabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0e] enabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0f] enabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x10] enabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x11] enabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x12] enabled)
ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x01] address[0xddeff000] gsi_base[24])
IOAPIC[1]: apic_id 1, version 0, address 0xddeff000, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
ACPI: HPET id: 0x10de8201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 16 CPUs, 0 hotplug CPUs
init_cpu_to_node:
cpu 0 -> apicid 0x4 -> node 0
cpu 1 -> apicid 0x5 -> node 0
cpu 2 -> apicid 0x6 -> node 0
cpu 3 -> apicid 0x7 -> node 0
cpu 4 -> apicid 0x8 -> node 1
cpu 5 -> apicid 0x9 -> node 1
cpu 6 -> apicid 0xa -> node 1
cpu 7 -> apicid 0xb -> node 1
cpu 8 -> apicid 0xc -> node 2
cpu 9 -> apicid 0xd -> node 2
cpu 10 -> apicid 0xe -> node 2
cpu 11 -> apicid 0xf -> node 2
cpu 12 -> apicid 0x10 -> node 3
cpu 13 -> apicid 0x11 -> node 3
cpu 14 -> apicid 0x12 -> node 3
cpu 15 -> apicid 0x13 -> node 3
mapped APIC to ffffffffff5fc000 (        fee00000)
mapped IOAPIC to ffffffffff5fb000 (fec00000)
mapped IOAPIC to ffffffffff5fa000 (ddeff000)
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [0, 973ff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (System RAM) [0, 973ff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [97400, 9ffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (reserved) [97400, 9ffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [e0000, fffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (reserved) [e0000, fffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [100000, d7f9ffff]
  insert_resource: first: (Kernel code) [200000, 970103], new: (System
RAM) [100000, d7f9ffff]
  insert_resource: direct parent: (PCI mem) [0, ffffffffffffffff],
new: (System RAM) [100000, d7f9ffff]
    insert_resource: child: (Kernel code) [200000, 970103], new:
(System RAM) [100000, d7f9ffff]
    insert_resource: child: (Kernel data) [970104, ea9657], new:
(System RAM) [100000, d7f9ffff]
    insert_resource: child: (Kernel bss) [f8f000, 1147ee3], new:
(System RAM) [100000, d7f9ffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [d7fae000, d7faffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (System RAM) [d7fae000, d7faffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (ACPI
Tables) [d7fb0000, d7fbdfff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (ACPI Tables) [d7fb0000, d7fbdfff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (ACPI
Non-volatile Storage) [d7fbe000, d7feffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (ACPI Non-volatile Storage) [d7fbe000,
d7feffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [100000000, 2027ffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (System RAM) [100000000, 2027ffffff]
request_resource: root: (PCI IO) [0, ffff], new: (dma1) [0, 1f] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (pic1) [20, 21] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (timer0) [40, 43] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (timer1) [50, 53] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (keyboard) [60, 60] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (keyboard) [64, 64] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (dma page reg) [80,
8f] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (pic2) [a0, a1] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (dma2) [c0, df] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (fpu) [f0, ff] conflict 0
Allocating PCI resources starting at f1000000 (gap: f0000000:ec00000)
dyn_array irq_2_pin_head+0x0/0x8 size:0x10 nr:256 align:0x1000
dyn_array irq_cfgx+0x0/0x8 size:0xa0 nr:32 align:0x1000
dyn_array sparse_irqs+0x0/0x8 size:0x180 nr:32 align:0x1000
dyn_array irq_2_iommuX+0x0/0x8 size:0x10 nr:256 align:0x1000
dyn_array total_size: 0x7000
dyn_array irq_2_pin_head+0x0/0x8  ==> [0x5c000 - 0x5d000]
dyn_array irq_cfgx+0x0/0x8  ==> [0x5d000 - 0x5e400]
dyn_array sparse_irqs+0x0/0x8  ==> [0x5f000 - 0x62000]
kstat_irqs ==> [0x63000 - 0x63800]
dyn_array irq_2_iommuX+0x0/0x8  ==> [0x62000 - 0x63000]
PERCPU: Allocating 53248 bytes of per cpu data
per cpu data for cpu0 on node0 at 000000000124e000
per cpu data for cpu1 on node0 at 000000000125b000
per cpu data for cpu2 on node0 at 0000000001268000
per cpu data for cpu3 on node0 at 0000000001275000
per cpu data for cpu4 on node1 at 0000000844218000
per cpu data for cpu5 on node1 at 0000000844225000
per cpu data for cpu6 on node1 at 0000000844232000
per cpu data for cpu7 on node1 at 000000084423f000
per cpu data for cpu8 on node2 at 0000001044418000
per cpu data for cpu9 on node2 at 0000001044425000
per cpu data for cpu10 on node2 at 0000001044432000
per cpu data for cpu11 on node2 at 000000104443f000
per cpu data for cpu12 on node3 at 0000001844218000
per cpu data for cpu13 on node3 at 0000001844225000
per cpu data for cpu14 on node3 at 0000001844232000
per cpu data for cpu15 on node3 at 000000184423f000
NR_CPUS: 512, nr_cpu_ids: 16, nr_node_ids 4
Built 4 zonelists in Zone order, mobility grouping on.  Total pages: 33093064
Policy zone: Normal
Kernel command line: console=uart8250,io,0x3f8,115200n8
initrd=kernel.org/mydisk11_x86_64.gz rw root=/dev/ram0 debug
show_msr=1 i8042.noaux initcall_debug apic=verbose pci=routeirq
ip=dhcp load_ramdisk=1 ramdisk_size=131072
BOOT_IMAGE=kernel.org/bzImage_2.6.27_k8.1
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
TSC calibrated against PM_TIMER
Detected 2300.091 MHz processor.
spurious 8259A interrupt: IRQ7.
request_resource: root: (PCI IO) [0, ffff], new: (vga+) [3c0, 3df] conflict 0
Console: colour VGA+ 80x25
console handover: boot [uart0] -> real [ttyS0]
Checking aperture...
No AGP bridge found
Node 0: aperture @ 20000000 size 32 MB
Aperture pointing to e820 RAM. Ignoring.
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 20000000
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (GART)
[20000000, 23ffffff]
  insert_resource: first: (System RAM) [100000, d7f9ffff], new: (GART)
[20000000, 23ffffff]
    insert_resource: good with request direct parent: (System RAM)
[100000, d7f9ffff], new: (GART) [20000000, 23ffffff]
numa_free_all_bootmem node 0 done
numa_free_all_bootmem node 1 done
numa_free_all_bootmem node 2 done
numa_free_all_bootmem node 3 done
Memory: 132270808k/134873088k available (7616k kernel code, 1946124k
reserved, 5349k data, 744k init)
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=4
hpet clockevent registered
Calibrating delay loop (skipped), value calculated using timer
frequency.. 4600.17 BogoMIPS (lpj=9200352)
Dentry cache hash table entries: 16777216 (order: 15, 134217728 bytes)
Inode-cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/4 -> Node 0
tseg: 0000000000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
using C1E aware idle routine
ACPI: Core revision 20080609
Parsing all Control Methods:
Table [DSDT](id 0001) - 1291 Objects with 137 Devices 414 Methods 21 Regions
Parsing all Control Methods:
Table [SSDT](id 0002) - 80 Objects with 0 Devices 0 Methods 0 Regions
 tbxface-0596 [00] tb_load_namespace     : ACPI Tables successfully acquired
evxfevnt-0091 [00] enable                : Transition to ACPI mode successful
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 29337 hash entries in 231 pages
Setting APIC routing to physical flat
enabled ExtINT on CPU#0
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 0-0 not connected.
 0 add_pin_to_irq: irq 1 --> apic 0 pin 1
IOAPIC[0]: Set routing entry (0-1 -> 0x31 -> IRQ 1 Mode:0 Active:0)
 0 add_pin_to_irq: irq 0 --> apic 0 pin 2
IOAPIC[0]: Set routing entry (0-2 -> 0x30 -> IRQ 0 Mode:0 Active:0)
 0 add_pin_to_irq: irq 3 --> apic 0 pin 3
IOAPIC[0]: Set routing entry (0-3 -> 0x33 -> IRQ 3 Mode:0 Active:0)
 0 add_pin_to_irq: irq 4 --> apic 0 pin 4
IOAPIC[0]: Set routing entry (0-4 -> 0x34 -> IRQ 4 Mode:0 Active:0)
 0 add_pin_to_irq: irq 5 --> apic 0 pin 5
IOAPIC[0]: Set routing entry (0-5 -> 0x35 -> IRQ 5 Mode:0 Active:0)
 0 add_pin_to_irq: irq 6 --> apic 0 pin 6
IOAPIC[0]: Set routing entry (0-6 -> 0x36 -> IRQ 6 Mode:0 Active:0)
 0 add_pin_to_irq: irq 7 --> apic 0 pin 7
IOAPIC[0]: Set routing entry (0-7 -> 0x37 -> IRQ 7 Mode:0 Active:0)
 0 add_pin_to_irq: irq 8 --> apic 0 pin 8
IOAPIC[0]: Set routing entry (0-8 -> 0x38 -> IRQ 8 Mode:0 Active:0)
 0 add_pin_to_irq: irq 9 --> apic 0 pin 9
IOAPIC[0]: Set routing entry (0-9 -> 0x39 -> IRQ 9 Mode:1 Active:0)
 0 add_pin_to_irq: irq 10 --> apic 0 pin 10
IOAPIC[0]: Set routing entry (0-10 -> 0x3a -> IRQ 10 Mode:0 Active:0)
 0 add_pin_to_irq: irq 11 --> apic 0 pin 11
IOAPIC[0]: Set routing entry (0-11 -> 0x3b -> IRQ 11 Mode:0 Active:0)
 0 add_pin_to_irq: irq 12 --> apic 0 pin 12
IOAPIC[0]: Set routing entry (0-12 -> 0x3c -> IRQ 12 Mode:0 Active:0)
 0 add_pin_to_irq: irq 13 --> apic 0 pin 13
IOAPIC[0]: Set routing entry (0-13 -> 0x3d -> IRQ 13 Mode:0 Active:0)
 0 add_pin_to_irq: irq 14 --> apic 0 pin 14
IOAPIC[0]: Set routing entry (0-14 -> 0x3e -> IRQ 14 Mode:0 Active:0)
 0 add_pin_to_irq: irq 15 --> apic 0 pin 15
IOAPIC[0]: Set routing entry (0-15 -> 0x3f -> IRQ 15 Mode:0 Active:0)
 IO-APIC (apicid-pin) 0-16, 0-17, 0-18, 0-19, 0-20, 0-21, 0-22, 0-23,
1-0, 1-1, 1-2, 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-9, 1-10, 1-11, 1-12,
1-13, 1-14, 1-15, 1-16, 1-17, 1-18, 1-19, 1-20, 1-21, 1-22, 1-23 not
connected.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
CPU0: Quad-Core AMD Opteron(tm) Processor 8356 stepping 03
Using local APIC timer interrupts.
calibrating APIC timer ...
... lapic delta = 1250039
... PM timer delta = 357952
... PM timer result ok
..... delta 1250039
..... mult: 53685410
..... calibration result: 800024
..... CPU clock speed is 2300.0282 MHz.
..... host bus clock speed is 200.0024 MHz.

calling  migration_init+0x0/0x5b
initcall migration_init+0x0/0x5b returned 1 after 0 msecs
initcall migration_init+0x0/0x5b returned with error code 1

calling  spawn_ksoftirqd+0x0/0x59
initcall spawn_ksoftirqd+0x0/0x59 returned 0 after 0 msecs

calling  init_call_single_data+0x0/0x5a
initcall init_call_single_data+0x0/0x5a returned 0 after 0 msecs

calling  spawn_softlockup_task+0x0/0x74
initcall spawn_softlockup_task+0x0/0x74 returned 0 after 0 msecs

calling  relay_init+0x0/0x14
initcall relay_init+0x0/0x14 returned 0 after 0 msecs
Booting processor 1/5 ip 6000
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4605.68 BogoMIPS (lpj=9211364)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/5 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Quad-Core AMD Opteron(tm) Processor 8356 stepping 03
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Booting processor 2/6 ip 6000
...
Brought up 16 CPUs
Total of 16 processors activated (73628.27 BogoMIPS).
..

calling  pci_arch_init+0x0/0x4e
    __request_region: good with request direct parent: (PCI IO) [0,
ffff], res: (PCI conf1) [cf8, cff]
PCI: Found AMD Family 10h NB with MMCONFIG support.
PCI: Using MMCONFIG at e0000000 - efffffff
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
MMCONFIG 0) [e0000000, efffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI MMCONFIG 0) [e0000000, efffffff]
PCI: Using configuration type 1 for base access
initcall pci_arch_init+0x0/0x4e returned 0 after 26 msecs

...

calling  acpi_pci_root_init+0x0/0x28
ACPI: PCI Root Bridge [PCI0] (0000:00)
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #00) [8000, dfff]
    insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #00) [8000, dfff]
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #00) [e000, efff]
    insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #00) [e000, efff]
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #00) [0, 3fff]
  insert_resource: first: (dma1) [0, 1f], new: (PCI Bus #00) [0, 3fff]
  insert_resource: direct parent: (PCI IO) [0, ffff], new: (PCI Bus
#00) [0, 3fff]
    insert_resource: child: (dma1) [0, 1f], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (pic1) [20, 21], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (timer0) [40, 43], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (timer1) [50, 53], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (keyboard) [60, 60], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (keyboard) [64, 64], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (dma page reg) [80, 8f], new: (PCI Bus
#00) [0, 3fff]
    insert_resource: child: (pic2) [a0, a1], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (dma2) [c0, df], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (fpu) [f0, ff], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (vga+) [3c0, 3df], new: (PCI Bus #00) [0, 3fff]
    insert_resource: child: (PCI conf1) [cf8, cff], new: (PCI Bus #00) [0, 3fff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [de000000, dfffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [de000000, dfffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [a0000, bffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [a0000, bffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [d8000000, dcffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [d8000000, dcffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [f0000000, ffffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [f0000000, ffffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [2028000000, fcffffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [2028000000, fcffffffff]
PCI: Scanning bus 0000:00
pci 0000:00:00.0: found [10de/0369] class 000500 header type 00
pci 0000:00:01.0: found [10de/0364] class 000601 header type 00
PCI: 0000:00:01.0 reg 10 io port: [ef00, ef7f]
pci 0000:00:01.0: calling nvidia_force_enable_hpet+0x0/0xc4
pci 0000:00:01.1: found [10de/0368] class 000c05 header type 00
PCI: 0000:00:01.1 reg 10 io port: [ac00, ac3f]
PCI: 0000:00:01.1 reg 20 io port: [ed00, ed3f]
PCI: 0000:00:01.1 reg 24 io port: [ee00, ee3f]
pci 0000:00:01.1: PME# supported from D3hot D3cold
pci 0000:00:01.1: PME# disabled
pci 0000:00:02.0: found [10de/036c] class 000c03 header type 00
PCI: 0000:00:02.0 reg 10 32bit mmio: [defbf000, defbffff]
pci 0000:00:02.0: supports D1
pci 0000:00:02.0: supports D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.0: PME# disabled
pci 0000:00:02.1: found [10de/036d] class 000c03 header type 00
PCI: 0000:00:02.1 reg 10 32bit mmio: [defbec00, defbecff]
pci 0000:00:02.1: supports D1
pci 0000:00:02.1: supports D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.1: PME# disabled
pci 0000:00:05.0: found [10de/037f] class 000101 header type 00
PCI: 0000:00:05.0 reg 10 io port: [a480, a487]
PCI: 0000:00:05.0 reg 14 io port: [a400, a403]
PCI: 0000:00:05.0 reg 18 io port: [a080, a087]
PCI: 0000:00:05.0 reg 1c io port: [a000, a003]
PCI: 0000:00:05.0 reg 20 io port: [9c00, 9c0f]
PCI: 0000:00:05.0 reg 24 32bit mmio: [defbd000, defbdfff]
pci 0000:00:05.1: found [10de/037f] class 000101 header type 00
PCI: 0000:00:05.1 reg 10 io port: [9880, 9887]
PCI: 0000:00:05.1 reg 14 io port: [9800, 9803]
PCI: 0000:00:05.1 reg 18 io port: [9480, 9487]
PCI: 0000:00:05.1 reg 1c io port: [9400, 9403]
PCI: 0000:00:05.1 reg 20 io port: [9080, 908f]
PCI: 0000:00:05.1 reg 24 32bit mmio: [defbc000, defbcfff]
pci 0000:00:05.2: found [10de/037f] class 000101 header type 00
PCI: 0000:00:05.2 reg 10 io port: [9000, 9007]
PCI: 0000:00:05.2 reg 14 io port: [8c00, 8c03]
PCI: 0000:00:05.2 reg 18 io port: [8880, 8887]
PCI: 0000:00:05.2 reg 1c io port: [8800, 8803]
PCI: 0000:00:05.2 reg 20 io port: [8480, 848f]
PCI: 0000:00:05.2 reg 24 32bit mmio: [defbb000, defbbfff]
pci 0000:00:06.0: found [10de/0370] class 000604 header type 01
pci 0000:00:08.0: found [10de/0373] class 000680 header type 00
PCI: 0000:00:08.0 reg 10 32bit mmio: [defba000, defbafff]
PCI: 0000:00:08.0 reg 14 io port: [8400, 8407]
PCI: 0000:00:08.0 reg 18 32bit mmio: [defbe800, defbe8ff]
PCI: 0000:00:08.0 reg 1c 32bit mmio: [defbe400, defbe40f]
pci 0000:00:08.0: supports D1
pci 0000:00:08.0: supports D2
pci 0000:00:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:08.0: PME# disabled
pci 0000:00:09.0: found [10de/0373] class 000680 header type 00
PCI: 0000:00:09.0 reg 10 32bit mmio: [defb9000, defb9fff]
PCI: 0000:00:09.0 reg 14 io port: [8080, 8087]
PCI: 0000:00:09.0 reg 18 32bit mmio: [defbe000, defbe0ff]
PCI: 0000:00:09.0 reg 1c 32bit mmio: [defb8c00, defb8c0f]
pci 0000:00:09.0: supports D1
pci 0000:00:09.0: supports D2
pci 0000:00:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:09.0: PME# disabled
pci 0000:00:0a.0: found [10de/0377] class 000604 header type 01
pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:0e.0: found [10de/0376] class 000604 header type 01
pci 0000:00:0e.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0e.0: PME# disabled
pci 0000:00:0f.0: found [10de/0375] class 000604 header type 01
pci 0000:00:0f.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0f.0: PME# disabled
pci 0000:00:18.0: found [1022/1200] class 000600 header type 00
pci 0000:00:18.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.1: found [1022/1201] class 000600 header type 00
pci 0000:00:18.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.2: found [1022/1202] class 000600 header type 00
pci 0000:00:18.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.3: found [1022/1203] class 000600 header type 00
pci 0000:00:18.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.4: found [1022/1204] class 000600 header type 00
pci 0000:00:18.4: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.0: found [1022/1200] class 000600 header type 00
pci 0000:00:19.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.1: found [1022/1201] class 000600 header type 00
pci 0000:00:19.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.2: found [1022/1202] class 000600 header type 00
pci 0000:00:19.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.3: found [1022/1203] class 000600 header type 00
pci 0000:00:19.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.4: found [1022/1204] class 000600 header type 00
pci 0000:00:19.4: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.0: found [1022/1200] class 000600 header type 00
pci 0000:00:1a.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.1: found [1022/1201] class 000600 header type 00
pci 0000:00:1a.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.2: found [1022/1202] class 000600 header type 00
pci 0000:00:1a.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.3: found [1022/1203] class 000600 header type 00
pci 0000:00:1a.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.4: found [1022/1204] class 000600 header type 00
pci 0000:00:1a.4: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.0: found [1022/1200] class 000600 header type 00
pci 0000:00:1b.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.1: found [1022/1201] class 000600 header type 00
pci 0000:00:1b.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.2: found [1022/1202] class 000600 header type 00
pci 0000:00:1b.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.3: found [1022/1203] class 000600 header type 00
pci 0000:00:1b.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.4: found [1022/1204] class 000600 header type 00
pci 0000:00:1b.4: calling fam10h_pci_cfg_space_size+0x0/0x24
PCI: Fixups for bus 0000:00
pci 0000:00:06.0: scanning behind bridge, config 010100, pass 0
PCI: Scanning bus 0000:01
pci 0000:01:05.0: found [1a03/2000] class 000300 header type 00
PCI: 0000:01:05.0 reg 10 32bit mmio: [df000000, df7fffff]
PCI: 0000:01:05.0 reg 14 32bit mmio: [dfbe0000, dfbfffff]
PCI: 0000:01:05.0 reg 18 io port: [bc00, bc7f]
pci 0000:01:05.0: supports D1
pci 0000:01:05.0: supports D2
PCI: Fixups for bus 0000:01
pci 0000:00:06.0: transparent bridge
PCI: bridge 0000:00:06.0 io port: [b000, bfff]
PCI: bridge 0000:00:06.0 32bit mmio: [df000000, dfbfffff]
PCI: Bus scan for 0000:01 returning with max=01
pci 0000:00:0a.0: scanning behind bridge, config 020200, pass 0
PCI: Scanning bus 0000:02
PCI: Fixups for bus 0000:02
PCI: Bus scan for 0000:02 returning with max=02
pci 0000:00:0e.0: scanning behind bridge, config 030300, pass 0
PCI: Scanning bus 0000:03
pci 0000:03:00.0: found [10df/fc40] class 000c04 header type 00
PCI: 0000:03:00.0 reg 10 64bit mmio: [dfcff000, dfcfffff]
PCI: 0000:03:00.0 reg 18 64bit mmio: [dfcf8000, dfcfbfff]
PCI: 0000:03:00.0 reg 20 io port: [c800, c8ff]
PCI: 0000:03:00.0 reg 30 32bit mmio: [dfc80000, dfcbffff]
pci 0000:03:00.1: found [10df/fc40] class 000c04 header type 00
PCI: 0000:03:00.1 reg 10 64bit mmio: [dfcfe000, dfcfefff]
PCI: 0000:03:00.1 reg 18 64bit mmio: [dfcf4000, dfcf7fff]
PCI: 0000:03:00.1 reg 20 io port: [c400, c4ff]
PCI: 0000:03:00.1 reg 30 32bit mmio: [dfc40000, dfc7ffff]
PCI: Fixups for bus 0000:03
PCI: bridge 0000:00:0e.0 io port: [c000, cfff]
PCI: bridge 0000:00:0e.0 32bit mmio: [dfc00000, dfcfffff]
PCI: Bus scan for 0000:03 returning with max=03
pci 0000:00:0f.0: scanning behind bridge, config 040400, pass 0
PCI: Scanning bus 0000:04
pci 0000:04:00.0: found [9005/0285] class 000104 header type 00
PCI: 0000:04:00.0 reg 10 64bit mmio: [dfe00000, dfffffff]
PCI: 0000:04:00.0 reg 30 32bit mmio: [dfd80000, dfdfffff]
pci 0000:04:00.0: supports D1
PCI: Fixups for bus 0000:04
PCI: bridge 0000:00:0f.0 32bit mmio: [dfd00000, dfffffff]
PCI: Bus scan for 0000:04 returning with max=04
pci 0000:00:06.0: scanning behind bridge, config 010100, pass 1
pci 0000:00:0a.0: scanning behind bridge, config 020200, pass 1
pci 0000:00:0e.0: scanning behind bridge, config 030300, pass 1
pci 0000:00:0f.0: scanning behind bridge, config 040400, pass 1
PCI: Bus scan for 0000:00 returning with max=04
bus 00 -> pxm 0 -> node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Root Bridge [PCIB] (0000:80)
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #80) [4000, 7fff]
    insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #80) [4000, 7fff]
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #80) [f000, ffff]
    insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #80) [f000, ffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #80) [dd000000, ddffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #80) [dd000000, ddffffff]
PCI: Scanning bus 0000:80
pci 0000:80:00.0: found [10de/0369] class 000500 header type 00
pci 0000:80:01.0: found [10de/0361] class 000500 header type 00
PCI: 0000:80:01.0 reg 10 io port: [fc00, fc7f]
PCI: 0000:80:01.0 reg 14 32bit mmio: [ddeff000, ddefffff]
pci 0000:80:01.0: calling nvidia_force_enable_hpet+0x0/0xc4
pci 0000:80:01.1: found [10de/0368] class 000c05 header type 00
PCI: 0000:80:01.1 reg 10 io port: [6880, 68bf]
PCI: 0000:80:01.1 reg 20 io port: [6800, 683f]
PCI: 0000:80:01.1 reg 24 io port: [6480, 64bf]
pci 0000:80:01.1: PME# supported from D3hot D3cold
pci 0000:80:01.1: PME# disabled
pci 0000:80:05.0: found [10de/037f] class 000101 header type 00
PCI: 0000:80:05.0 reg 10 io port: [6400, 6407]
PCI: 0000:80:05.0 reg 14 io port: [6080, 6083]
PCI: 0000:80:05.0 reg 18 io port: [6000, 6007]
PCI: 0000:80:05.0 reg 1c io port: [5c00, 5c03]
PCI: 0000:80:05.0 reg 20 io port: [5880, 588f]
PCI: 0000:80:05.0 reg 24 32bit mmio: [ddefe000, ddefefff]
pci 0000:80:05.1: found [10de/037f] class 000101 header type 00
PCI: 0000:80:05.1 reg 10 io port: [5800, 5807]
PCI: 0000:80:05.1 reg 14 io port: [5480, 5483]
PCI: 0000:80:05.1 reg 18 io port: [5400, 5407]
PCI: 0000:80:05.1 reg 1c io port: [5080, 5083]
PCI: 0000:80:05.1 reg 20 io port: [5000, 500f]
PCI: 0000:80:05.1 reg 24 32bit mmio: [ddefd000, ddefdfff]
pci 0000:80:05.2: found [10de/037f] class 000101 header type 00
PCI: 0000:80:05.2 reg 10 io port: [4c00, 4c07]
PCI: 0000:80:05.2 reg 14 io port: [4880, 4883]
PCI: 0000:80:05.2 reg 18 io port: [4800, 4807]
PCI: 0000:80:05.2 reg 1c io port: [4480, 4483]
PCI: 0000:80:05.2 reg 20 io port: [4400, 440f]
PCI: 0000:80:05.2 reg 24 32bit mmio: [ddefc000, ddefcfff]
pci 0000:80:08.0: found [10de/0373] class 000680 header type 00
PCI: 0000:80:08.0 reg 10 32bit mmio: [ddefb000, ddefbfff]
PCI: 0000:80:08.0 reg 14 io port: [4080, 4087]
PCI: 0000:80:08.0 reg 18 32bit mmio: [ddefac00, ddefacff]
PCI: 0000:80:08.0 reg 1c 32bit mmio: [ddefa800, ddefa80f]
pci 0000:80:08.0: supports D1
pci 0000:80:08.0: supports D2
pci 0000:80:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:08.0: PME# disabled
pci 0000:80:09.0: found [10de/0373] class 000680 header type 00
PCI: 0000:80:09.0 reg 10 32bit mmio: [ddef9000, ddef9fff]
PCI: 0000:80:09.0 reg 14 io port: [4000, 4007]
PCI: 0000:80:09.0 reg 18 32bit mmio: [ddefa400, ddefa4ff]
PCI: 0000:80:09.0 reg 1c 32bit mmio: [ddefa000, ddefa00f]
pci 0000:80:09.0: supports D1
pci 0000:80:09.0: supports D2
pci 0000:80:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:09.0: PME# disabled
pci 0000:80:0b.0: found [10de/0378] class 000604 header type 01
pci 0000:80:0b.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:0b.0: PME# disabled
pci 0000:80:0e.0: found [10de/0376] class 000604 header type 01
pci 0000:80:0e.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:0e.0: PME# disabled
pci 0000:80:0f.0: found [10de/0377] class 000604 header type 01
pci 0000:80:0f.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:0f.0: PME# disabled
PCI: Fixups for bus 0000:80
pci 0000:80:0b.0: scanning behind bridge, config 818180, pass 0
PCI: Scanning bus 0000:81
PCI: Fixups for bus 0000:81
PCI: Bus scan for 0000:81 returning with max=81
pci 0000:80:0e.0: scanning behind bridge, config 828280, pass 0
PCI: Scanning bus 0000:82
PCI: Fixups for bus 0000:82
PCI: Bus scan for 0000:82 returning with max=82
pci 0000:80:0f.0: scanning behind bridge, config 838380, pass 0
PCI: Scanning bus 0000:83
pci 0000:83:00.0: found [1077/2532] class 000c04 header type 00
PCI: 0000:83:00.0 reg 10 io port: [7800, 78ff]
PCI: 0000:83:00.0 reg 14 64bit mmio: [ddffc000, ddffffff]
PCI: 0000:83:00.0 reg 30 32bit mmio: [ddf80000, ddfbffff]
pci 0000:83:00.1: found [1077/2532] class 000c04 header type 00
PCI: 0000:83:00.1 reg 10 io port: [7400, 74ff]
PCI: 0000:83:00.1 reg 14 64bit mmio: [ddff8000, ddffbfff]
PCI: 0000:83:00.1 reg 30 32bit mmio: [ddf40000, ddf7ffff]
PCI: Fixups for bus 0000:83
PCI: bridge 0000:80:0f.0 io port: [7000, 7fff]
PCI: bridge 0000:80:0f.0 32bit mmio: [ddf00000, ddffffff]
PCI: Bus scan for 0000:83 returning with max=83
pci 0000:80:0b.0: scanning behind bridge, config 818180, pass 1
pci 0000:80:0e.0: scanning behind bridge, config 828280, pass 1
pci 0000:80:0f.0: scanning behind bridge, config 838380, pass 1
PCI: Bus scan for 0000:80 returning with max=83
bus 80 -> pxm 1 -> node 1
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB.BR81._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB.BR82._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB.BR83._PRT]
initcall acpi_pci_root_init+0x0/0x28 returned 0 after 1148 msecs


..

calling  pci_subsys_init+0x0/0x121
..
request_resource: root: (PCI Bus #00) [8000, dfff], new: (PCI Bus
0000:01) [b000, bfff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new: (PCI
Bus 0000:01) [df000000, dfbfffff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new: (PCI Bus
0000:03) [c000, cfff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new: (PCI
Bus 0000:03) [dfc00000, dfcfffff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new: (PCI
Bus 0000:04) [dfd00000, dfffffff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new: (PCI Bus
0000:83) [7000, 7fff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new: (PCI
Bus 0000:83) [ddf00000, ddffffff] conflict 0
request_resource: root: (PCI Bus #00) [e000, efff], new:
(0000:00:01.0) [ef00, ef7f] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:01.1) [ac00, ac3f] conflict 0
request_resource: root: (PCI Bus #00) [e000, efff], new:
(0000:00:01.1) [ed00, ed3f] conflict 0
request_resource: root: (PCI Bus #00) [e000, efff], new:
(0000:00:01.1) [ee00, ee3f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:02.0) [defbf000, defbffff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:02.1) [defbec00, defbecff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a480, a487] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a400, a403] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a080, a087] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a000, a003] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [9c00, 9c0f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:05.0) [defbd000, defbdfff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9880, 9887] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9800, 9803] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9480, 9487] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9400, 9403] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9080, 908f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:05.1) [defbc000, defbcfff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [9000, 9007] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8c00, 8c03] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8880, 8887] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8800, 8803] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8480, 848f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:05.2) [defbb000, defbbfff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:08.0) [defba000, defbafff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:08.0) [8400, 8407] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:08.0) [defbe800, defbe8ff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:08.0) [defbe400, defbe40f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:09.0) [defb9000, defb9fff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:09.0) [8080, 8087] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:09.0) [defbe000, defbe0ff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:09.0) [defb8c00, defb8c0f] conflict 0
request_resource: root: (PCI Bus 0000:01) [df000000, dfbfffff], new:
(0000:01:05.0) [df000000, df7fffff] conflict 0
request_resource: root: (PCI Bus 0000:01) [df000000, dfbfffff], new:
(0000:01:05.0) [dfbe0000, dfbfffff] conflict 0
request_resource: root: (PCI Bus 0000:01) [b000, bfff], new:
(0000:01:05.0) [bc00, bc7f] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.0) [dfcff000, dfcfffff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.0) [dfcf8000, dfcfbfff] conflict 0
request_resource: root: (PCI Bus 0000:03) [c000, cfff], new:
(0000:03:00.0) [c800, c8ff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.1) [dfcfe000, dfcfefff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.1) [dfcf4000, dfcf7fff] conflict 0
request_resource: root: (PCI Bus 0000:03) [c000, cfff], new:
(0000:03:00.1) [c400, c4ff] conflict 0
request_resource: root: (PCI Bus 0000:04) [dfd00000, dfffffff], new:
(0000:04:00.0) [dfe00000, dfffffff] conflict 0
request_resource: root: (PCI Bus #80) [f000, ffff], new:
(0000:80:01.0) [fc00, fc7f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:01.0) [ddeff000, ddefffff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:01.1) [6880, 68bf] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:01.1) [6800, 683f] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:01.1) [6480, 64bf] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [6400, 6407] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [6080, 6083] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [6000, 6007] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [5c00, 5c03] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [5880, 588f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:05.0) [ddefe000, ddefefff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5800, 5807] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5480, 5483] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5400, 5407] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5080, 5083] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5000, 500f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:05.1) [ddefd000, ddefdfff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4c00, 4c07] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4880, 4883] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4800, 4807] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4480, 4483] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4400, 440f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:05.2) [ddefc000, ddefcfff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:08.0) [ddefb000, ddefbfff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:08.0) [4080, 4087] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:08.0) [ddefac00, ddefacff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:08.0) [ddefa800, ddefa80f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:09.0) [ddef9000, ddef9fff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:09.0) [4000, 4007] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:09.0) [ddefa400, ddefa4ff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:09.0) [ddefa000, ddefa00f] conflict 0
request_resource: root: (PCI Bus 0000:83) [7000, 7fff], new:
(0000:83:00.0) [7800, 78ff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.0) [ddffc000, ddffffff] conflict 0
request_resource: root: (PCI Bus 0000:83) [7000, 7fff], new:
(0000:83:00.1) [7400, 74ff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.1) [ddff8000, ddffbfff] conflict 0
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [d7ff0000, d7ffffff]
    insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (reserved) [d7ff0000, d7ffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [dd800000, efffffff]
  insert_resource: first: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd800000, efffffff]
found conflict for reserved [dd800000, efffffff], try to insert with expand
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [dd800000, efffffff]
  insert_resource: first: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd800000, efffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [dd000000, efffffff]
  insert_resource: first: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd000000, efffffff]
  insert_resource: direct parent: (PCI mem) [0, ffffffffffffffff],
new: (reserved) [dd000000, efffffff]
    insert_resource: child: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd000000, efffffff]
    insert_resource: child: (PCI Bus #00) [de000000, dfffffff], new:
(reserved) [dd000000, efffffff]
    insert_resource: child: (PCI MMCONFIG 0) [e0000000, efffffff],
new: (reserved) [dd000000, efffffff]
   expand to reserved [dd000000, efffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [fec00000, fec00fff]
  insert_resource: first: (PCI Bus #00) [f0000000, ffffffff], new:
(reserved) [fec00000, fec00fff]
    insert_resource: good with request direct parent: (PCI Bus #00)
[f0000000, ffffffff], new: (reserved) [fec00000, fec00fff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [fee00000, feefffff]
  insert_resource: first: (PCI Bus #00) [f0000000, ffffffff], new:
(reserved) [fee00000, feefffff]
    insert_resource: good with request direct parent: (PCI Bus #00)
[f0000000, ffffffff], new: (reserved) [fee00000, feefffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [ff700000, ffffffff]
  insert_resource: first: (PCI Bus #00) [f0000000, ffffffff], new:
(reserved) [ff700000, ffffffff]
    insert_resource: good with request direct parent: (PCI Bus #00)
[f0000000, ffffffff], new: (reserved) [ff700000, ffffffff]
initcall pci_subsys_init+0x0/0x121 returned 0 after 770 msecs

calling  proto_init+0x0/0x2e
initcall proto_init+0x0/0x2e returned 0 after 0 msecs

calling  net_dev_init+0x0/0x155
initcall net_dev_init+0x0/0x155 returned 0 after 0 msecs

calling  neigh_init+0x0/0x71
initcall neigh_init+0x0/0x71 returned 0 after 0 msecs

calling  genl_init+0x0/0xd9
initcall genl_init+0x0/0xd9 returned 0 after 15 msecs

calling  sysctl_init+0x0/0x49
initcall sysctl_init+0x0/0x49 returned 0 after 0 msecs

calling  pci_iommu_init+0x0/0x17
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 20000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
initcall pci_iommu_init+0x0/0x17 returned 0 after 22 msecs


calling  pnp_system_init+0x0/0x12
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:05) [4d0, 4d1]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:05) [4d0, 4d1]
system 00:05: ioport range 0x4d0-0x4d1 has been reserved
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:05) [800, 80f]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:05) [800, 80f]
system 00:05: ioport range 0x800-0x80f has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e000, e07f]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e000, e07f]
system 00:05: ioport range 0xe000-0xe07f has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e080, e0ff]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e080, e0ff]
system 00:05: ioport range 0xe080-0xe0ff has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e400, e47f]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e400, e47f]
system 00:05: ioport range 0xe400-0xe47f has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e480, e4ff]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e480, e4ff]
system 00:05: ioport range 0xe480-0xe4ff has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e800, e87f]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e800, e87f]
system 00:05: ioport range 0xe800-0xe87f has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e880, e8ff]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e880, e8ff]
system 00:05: ioport range 0xe880-0xe8ff has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [ec00, ec7f]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [ec00, ec7f]
system 00:05: ioport range 0xec00-0xec7f has been reserved
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [ec80, ecff]
    __request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [ec80, ecff]
system 00:05: ioport range 0xec80-0xecff has been reserved
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(pnp 00:05) [defc0000, deffffff]
busy flag
system 00:05: iomem range 0xdefc0000-0xdeffffff could not be reserved
  __request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:05) [fee01000, feefffff]
  __request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:05) [fee01000, feefffff]
busy flag
system 00:05: iomem range 0xfee01000-0xfeefffff could not be reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f000, f07f]
    __request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f000, f07f]
system 00:06: ioport range 0xf000-0xf07f has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f080, f0ff]
    __request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f080, f0ff]
system 00:06: ioport range 0xf080-0xf0ff has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f400, f47f]
    __request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f400, f47f]
system 00:06: ioport range 0xf400-0xf47f has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f480, f4ff]
    __request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f480, f4ff]
system 00:06: ioport range 0xf480-0xf4ff has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f800, f87f]
    __request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f800, f87f]
system 00:06: ioport range 0xf800-0xf87f has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f880, f8ff]
    __request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f880, f8ff]
system 00:06: ioport range 0xf880-0xf8ff has been reserved
  __request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:06) [fee01000, fef00fff]
  __request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:06) [fee01000, fef00fff]
busy flag
system 00:06: iomem range 0xfee01000-0xfef00fff could not be reserved
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:0a) [ca0, ca1]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:0a) [ca0, ca1]
system 00:0a: ioport range 0xca0-0xca1 has been reserved
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:0a) [ca4, caf]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:0a) [ca4, caf]
system 00:0a: ioport range 0xca4-0xcaf has been reserved
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:0a) [cf9, cf9]
  __request_region: conflict: (PCI conf1) [cf8, cff], res: (pnp 00:0a)
[cf9, cf9]
busy flag
system 00:0a: ioport range 0xcf9-0xcf9 could not be reserved
  __request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0a) [fec00000, fec00fff]
  __request_region: conflict: (reserved) [fec00000, fec00fff], res:
(pnp 00:0a) [fec00000, fec00fff]
busy flag
system 00:0a: iomem range 0xfec00000-0xfec00fff could not be reserved
  __request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0a) [fee00000, fee00fff]
  __request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:0a) [fee00000, fee00fff]
busy flag
system 00:0a: iomem range 0xfee00000-0xfee00fff could not be reserved
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(pnp 00:0b) [e0000000, efffffff]
busy flag
system 00:0b: iomem range 0xe0000000-0xefffffff could not be reserved
  __request_region: conflict: (System RAM) [0, 973ff], res: (pnp
00:0c) [0, 9ffff]
busy flag
system 00:0c: iomem range 0x0-0x9ffff could not be reserved
    __request_region: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], res: (pnp 00:0c) [c0000, cffff]
system 00:0c: iomem range 0xc0000-0xcffff has been reserved
  __request_region: conflict: (reserved) [e0000, fffff], res: (pnp
00:0c) [e0000, fffff]
busy flag
system 00:0c: iomem range 0xe0000-0xfffff could not be reserved
  __request_region: conflict: (System RAM) [100000, d7f9ffff], res:
(pnp 00:0c) [100000, ddffffff]
busy flag
system 00:0c: iomem range 0x100000-0xddffffff could not be reserved
  __request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0c) [fec00000, ffffffff]
  __request_region: conflict: (reserved) [fec00000, fec00fff], res:
(pnp 00:0c) [fec00000, ffffffff]
busy flag
system 00:0c: iomem range 0xfec00000-0xffffffff could not be reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f000, f07f]
  __request_region: conflict: (pnp 00:06) [f000, f07f], res: (pnp
00:0e) [f000, f07f]
    __request_region: good with request direct parent: (pnp 00:06)
[f000, f07f], res: (pnp 00:0e) [f000, f07f]
system 00:0e: ioport range 0xf000-0xf07f has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f080, f0ff]
  __request_region: conflict: (pnp 00:06) [f080, f0ff], res: (pnp
00:0e) [f080, f0ff]
    __request_region: good with request direct parent: (pnp 00:06)
[f080, f0ff], res: (pnp 00:0e) [f080, f0ff]
system 00:0e: ioport range 0xf080-0xf0ff has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f400, f47f]
  __request_region: conflict: (pnp 00:06) [f400, f47f], res: (pnp
00:0e) [f400, f47f]
    __request_region: good with request direct parent: (pnp 00:06)
[f400, f47f], res: (pnp 00:0e) [f400, f47f]
system 00:0e: ioport range 0xf400-0xf47f has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f480, f4ff]
  __request_region: conflict: (pnp 00:06) [f480, f4ff], res: (pnp
00:0e) [f480, f4ff]
    __request_region: good with request direct parent: (pnp 00:06)
[f480, f4ff], res: (pnp 00:0e) [f480, f4ff]
system 00:0e: ioport range 0xf480-0xf4ff has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f800, f87f]
  __request_region: conflict: (pnp 00:06) [f800, f87f], res: (pnp
00:0e) [f800, f87f]
    __request_region: good with request direct parent: (pnp 00:06)
[f800, f87f], res: (pnp 00:0e) [f800, f87f]
system 00:0e: ioport range 0xf800-0xf87f has been reserved
  __request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f880, f8ff]
  __request_region: conflict: (pnp 00:06) [f880, f8ff], res: (pnp
00:0e) [f880, f8ff]
    __request_region: good with request direct parent: (pnp 00:06)
[f880, f8ff], res: (pnp 00:0e) [f880, f8ff]
system 00:0e: ioport range 0xf880-0xf8ff has been reserved
  __request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0e) [fee01000, fef00fff]
  __request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:0e) [fee01000, fef00fff]
busy flag
system 00:0e: iomem range 0xfee01000-0xfef00fff could not be reserved
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(pnp 00:0e) [dde80000, ddebffff]
busy flag
system 00:0e: iomem range 0xdde80000-0xddebffff could not be reserved
initcall pnp_system_init+0x0/0x12 returned 0 after 828 msecs

calling  chr_dev_init+0x0/0xa1
initcall chr_dev_init+0x0/0xa1 returned 0 after 0 msecs

calling  firmware_class_init+0x0/0x79
initcall firmware_class_init+0x0/0x79 returned 0 after 0 msecs

calling  loopback_init+0x0/0x12
initcall loopback_init+0x0/0x12 returned 0 after 0 msecs

calling  cpufreq_gov_performance_init+0x0/0x12
initcall cpufreq_gov_performance_init+0x0/0x12 returned 0 after 0 msecs

calling  init_acpi_pm_clocksource+0x0/0xa9
initcall init_acpi_pm_clocksource+0x0/0xa9 returned 0 after 0 msecs

calling  pcibios_assign_resources+0x0/0x88
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.0) [dfc80000, dfcbffff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.1) [dfc40000, dfc7ffff] conflict 0
request_resource: root: (PCI Bus 0000:04) [dfd00000, dfffffff], new:
(0000:04:00.0) [dfd80000, dfdfffff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.0) [ddf80000, ddfbffff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.1) [ddf40000, ddf7ffff] conflict 0
pci 0000:00:06.0: PCI bridge, secondary bus 0000:01
pci 0000:00:06.0:   IO window: 0xb000-0xbfff
pci 0000:00:06.0:   MEM window: 0xdf000000-0xdfbfffff
pci 0000:00:06.0:   PREFETCH window: disabled
pci 0000:00:0a.0: PCI bridge, secondary bus 0000:02
pci 0000:00:0a.0:   IO window: disabled
pci 0000:00:0a.0:   MEM window: disabled
pci 0000:00:0a.0:   PREFETCH window: disabled
pci 0000:00:0e.0: PCI bridge, secondary bus 0000:03
pci 0000:00:0e.0:   IO window: 0xc000-0xcfff
pci 0000:00:0e.0:   MEM window: 0xdfc00000-0xdfcfffff
pci 0000:00:0e.0:   PREFETCH window: disabled
pci 0000:00:0f.0: PCI bridge, secondary bus 0000:04
pci 0000:00:0f.0:   IO window: disabled
pci 0000:00:0f.0:   MEM window: 0xdfd00000-0xdfffffff
pci 0000:00:0f.0:   PREFETCH window: disabled
pci 0000:00:06.0: setting latency timer to 64
pci 0000:00:0a.0: setting latency timer to 64
pci 0000:00:0e.0: setting latency timer to 64
pci 0000:00:0f.0: setting latency timer to 64
pci 0000:80:0b.0: PCI bridge, secondary bus 0000:81
pci 0000:80:0b.0:   IO window: disabled
pci 0000:80:0b.0:   MEM window: disabled
pci 0000:80:0b.0:   PREFETCH window: disabled
pci 0000:80:0e.0: PCI bridge, secondary bus 0000:82
pci 0000:80:0e.0:   IO window: disabled
pci 0000:80:0e.0:   MEM window: disabled
pci 0000:80:0e.0:   PREFETCH window: disabled
pci 0000:80:0f.0: PCI bridge, secondary bus 0000:83
pci 0000:80:0f.0:   IO window: 0x7000-0x7fff
pci 0000:80:0f.0:   MEM window: 0xddf00000-0xddffffff
pci 0000:80:0f.0:   PREFETCH window: disabled
pci 0000:80:0b.0: setting latency timer to 64
pci 0000:80:0e.0: setting latency timer to 64
pci 0000:80:0f.0: setting latency timer to 64
bus: 00 index 0 io port: [8000, dfff]
bus: 00 index 1 io port: [e000, efff]
bus: 00 index 2 io port: [0, 3fff]
bus: 00 index 3 mmio: [de000000, dfffffff]
bus: 00 index 4 mmio: [a0000, bffff]
bus: 00 index 5 mmio: [d8000000, dcffffff]
bus: 00 index 6 mmio: [f0000000, ffffffff]
bus: 00 index 7 mmio: [2028000000, fcffffffff]
bus: 01 index 0 io port: [b000, bfff]
bus: 01 index 1 mmio: [df000000, dfbfffff]
bus: 01 index 2 mmio: [0, 0]
bus: 01 index 3 io port: [8000, dfff]
bus: 01 index 4 io port: [e000, efff]
bus: 01 index 5 io port: [0, 3fff]
bus: 01 index 6 mmio: [de000000, dfffffff]
bus: 01 index 7 mmio: [a0000, bffff]
bus: 01 index 8 mmio: [d8000000, dcffffff]
bus: 01 index 9 mmio: [f0000000, ffffffff]
bus: 01 index a mmio: [2028000000, fcffffffff]
bus: 02 index 0 mmio: [0, 0]
bus: 02 index 1 mmio: [0, 0]
bus: 02 index 2 mmio: [0, 0]
bus: 02 index 3 mmio: [0, 0]
bus: 03 index 0 io port: [c000, cfff]
bus: 03 index 1 mmio: [dfc00000, dfcfffff]
bus: 03 index 2 mmio: [0, 0]
bus: 03 index 3 mmio: [0, 0]
bus: 04 index 0 mmio: [0, 0]
bus: 04 index 1 mmio: [dfd00000, dfffffff]
bus: 04 index 2 mmio: [0, 0]
bus: 04 index 3 mmio: [0, 0]
bus: 80 index 0 io port: [4000, 7fff]
bus: 80 index 1 io port: [f000, ffff]
bus: 80 index 2 mmio: [dd000000, ddffffff]
bus: 81 index 0 mmio: [0, 0]
bus: 81 index 1 mmio: [0, 0]
bus: 81 index 2 mmio: [0, 0]
bus: 81 index 3 mmio: [0, 0]
bus: 82 index 0 mmio: [0, 0]
bus: 82 index 1 mmio: [0, 0]
bus: 82 index 2 mmio: [0, 0]
bus: 82 index 3 mmio: [0, 0]
bus: 83 index 0 io port: [7000, 7fff]
bus: 83 index 1 mmio: [ddf00000, ddffffff]
bus: 83 index 2 mmio: [0, 0]
bus: 83 index 3 mmio: [0, 0]
initcall pcibios_assign_resources+0x0/0x88 returned 0 after 327 msecs

calling  inet_init+0x0/0x1f2
NET: Registered protocol family 2
IP route cache hash table entries: 4194304 (order: 13, 33554432 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
initcall inet_init+0x0/0x1f2 returned 0 after 93 msecs

calling  af_unix_init+0x0/0x55
NET: Registered protocol family 1
initcall af_unix_init+0x0/0x55 returned 0 after 2 msecs

calling  populate_rootfs+0x0/0x238
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 25763k freed
initcall populate_rootfs+0x0/0x238 returned 0 after 1081 msecs

calling  pci_init+0x0/0x109
..

calling  ehci_hcd_init+0x0/0x1b
ehci_hcd 0000:00:02.1: PCI INT B -> Link[LUB2] -> GSI 21 (level, low) -> IRQ 21
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(ehci_hcd) [defbec00, defbecff]
busy flag
ehci_hcd 0000:00:02.1: PCI INT B disabled
ehci_hcd 0000:00:02.1: init 0000:00:02.1 fail, -16
ehci_hcd: probe of 0000:00:02.1 failed with error -16
initcall ehci_hcd_init+0x0/0x1b returned 0 after 28 msecs

calling  ohci_hcd_mod_init+0x0/0x42
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:02.0: PCI INT A -> Link[LUB0] -> GSI 22 (level, low) -> IRQ 22
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(ohci_hcd) [defbf000, defbffff]
busy flag
ohci_hcd 0000:00:02.0: PCI INT A disabled
ohci_hcd 0000:00:02.0: init 0000:00:02.0 fail, -16
ohci_hcd: probe of 0000:00:02.0 failed with error -16
initcall ohci_hcd_mod_init+0x0/0x42 returned 0 after 34 msecs



calling  acpi_reserve_resources+0x0/0xeb
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
PM1a_EVT_BLK) [e000, e003]
  __request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
PM1a_EVT_BLK) [e000, e003]
    __request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI PM1a_EVT_BLK) [e000, e003]
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
PM1a_CNT_BLK) [e004, e005]
  __request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
PM1a_CNT_BLK) [e004, e005]
    __request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI PM1a_CNT_BLK) [e004, e005]
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
PM_TMR) [e008, e00b]
  __request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
PM_TMR) [e008, e00b]
    __request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI PM_TMR) [e008, e00b]
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
GPE0_BLK) [e020, e027]
  __request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
GPE0_BLK) [e020, e027]
    __request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI GPE0_BLK) [e020, e027]
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
GPE1_BLK) [e4a0, e4af]
  __request_region: conflict: (pnp 00:05) [e480, e4ff], res: (ACPI
GPE1_BLK) [e4a0, e4af]
    __request_region: good with request direct parent: (pnp 00:05)
[e480, e4ff], res: (ACPI GPE1_BLK) [e4a0, e4af]
initcall acpi_reserve_resources+0x0/0xeb returned 0 after 125 msecs

calling  acpi_ac_init+0x0/0x28
initcall acpi_ac_init+0x0/0x28 returned 0 after 0 msecs

calling  acpi_fan_init+0x0/0x32
initcall acpi_fan_init+0x0/0x32 returned 0 after 0 msecs

calling  irqrouter_init_sysfs+0x0/0x38
initcall irqrouter_init_sysfs+0x0/0x38 returned 0 after 0 msecs

calling  acpi_pci_slot_init+0x0/0x20
initcall acpi_pci_slot_init+0x0/0x20 returned 0 after 0 msecs

calling  acpi_processor_init+0x0/0x10a
  __request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
CPU throttle) [e010, e015]
  __request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI CPU
throttle) [e010, e015]
    __request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI CPU throttle) [e010, e015]
processor ACPI0007:00: registered as cooling_device0
processor ACPI0007:01: registered as cooling_device1
processor ACPI0007:02: registered as cooling_device2
processor ACPI0007:03: registered as cooling_device3
processor ACPI0007:04: registered as cooling_device4
processor ACPI0007:05: registered as cooling_device5
processor ACPI0007:06: registered as cooling_device6
processor ACPI0007:07: registered as cooling_device7
processor ACPI0007:08: registered as cooling_device8
processor ACPI0007:09: registered as cooling_device9
processor ACPI0007:0a: registered as cooling_device10
processor ACPI0007:0b: registered as cooling_device11
processor ACPI0007:0c: registered as cooling_device12
processor ACPI0007:0d: registered as cooling_device13
processor ACPI0007:0e: registered as cooling_device14
processor ACPI0007:0f: registered as cooling_device15
initcall acpi_processor_init+0x0/0x10a returned 0 after 99 msecs

calling  hpet_init+0x0/0x6a
hpet_resources: 0xfed00000 is busy
initcall hpet_init+0x0/0x6a returned 0 after 3 msecs

calling  serial8250_init+0x0/0x116
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [3f8, 3ff]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [3f8, 3ff]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [3f0, 3f7]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [3f0, 3f7]
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [2f8, 2ff]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [2f8, 2ff]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [2f0, 2f7]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [2f0, 2f7]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [3e8, 3ef]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [3e8, 3ef]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [3e0, 3e7]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [3e0, 3e7]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [2e8, 2ef]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [2e8, 2ef]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [2e0, 2e7]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [2e0, 2e7]
initcall serial8250_init+0x0/0x116 returned 0 after 136 msecs

calling  serial8250_pnp_init+0x0/0x12
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [3f8, 3ff]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [3f8, 3ff]
  __request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [3f0, 3f7]
    __request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [3f0, 3f7]
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
initcall serial8250_pnp_init+0x0/0x12 returned 0 after 36 msecs


calling  init_nic+0x0/0x1b
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
forcedeth 0000:00:08.0: PCI INT A -> Link[LMAC] -> GSI 21 (level, low) -> IRQ 21
forcedeth 0000:00:08.0: setting latency timer to 64
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [defba000, defbafff]
busy flag
forcedeth 0000:00:08.0: BAR 0: can't reserve mem region [0xdefba000-0xdefbafff]
forcedeth 0000:00:08.0: PCI INT A disabled
forcedeth: probe of 0000:00:08.0 failed with error -16
forcedeth 0000:00:09.0: PCI INT A -> Link[LMAD] -> GSI 20 (level, low) -> IRQ 20
forcedeth 0000:00:09.0: setting latency timer to 64
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [defb9000, defb9fff]
busy flag
forcedeth 0000:00:09.0: BAR 0: can't reserve mem region [0xdefb9000-0xdefb9fff]
forcedeth 0000:00:09.0: PCI INT A disabled
forcedeth: probe of 0000:00:09.0 failed with error -16
forcedeth 0000:80:08.0: PCI INT A -> Link[IIM0] -> GSI 47 (level, low) -> IRQ 47
forcedeth 0000:80:08.0: setting latency timer to 64
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [ddefb000, ddefbfff]
busy flag
forcedeth 0000:80:08.0: BAR 0: can't reserve mem region [0xddefb000-0xddefbfff]
forcedeth 0000:80:08.0: PCI INT A disabled
forcedeth: probe of 0000:80:08.0 failed with error -16
forcedeth 0000:80:09.0: PCI INT A -> Link[IIM1] -> GSI 46 (level, low) -> IRQ 46
forcedeth 0000:80:09.0: setting latency timer to 64
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [ddef9000, ddef9fff]
busy flag
forcedeth 0000:80:09.0: BAR 0: can't reserve mem region [0xddef9000-0xddef9fff]
forcedeth 0000:80:09.0: PCI INT A disabled
forcedeth: probe of 0000:80:09.0 failed with error -16
initcall init_nic+0x0/0x1b returned 0 after 148 msecs
...

calling  qla2x00_module_init+0x0/0x12c
QLogic Fibre Channel HBA Driver: 8.02.01-k7
vendor=10de device=0377
qla2xxx 0000:83:00.0: PCI INT A -> Link[LE3B] -> GSI 43 (level, low) -> IRQ 43
  __request_region: conflict: (reserved) [dd000000, efffffff], res:
(qla2xxx) [ddffc000, ddffffff]
busy flag
qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]
qla2xxx 0000:83:00.0: Failed to reserve PIO/MMIO regions (0000:83:00.0)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff80672f9c>] qla2x00_free_device+0x571/0x618
PGD 0
Oops: 0000 [1] SMP
Dumping ftrace buffer:
   (ftrace buffer empty)
CPU 4
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.27-rc5-tip-00672-ge5c5407-dirty #220
RIP: 0010:[<ffffffff80672f9c>]  [<ffffffff80672f9c>]
qla2x00_free_device+0x571/0x618
RSP: 0018:ffff881824cafb10  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8810228ec630 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff881824cafb60 R08: ffff881824caf9c0 R09: 0000000000000000
R10: ffffffff8105b190 R11: 0000000000000010 R12: 00000000fffffff4
R13: ffff8810228ee790 R14: ffff882024acf890 R15: ffff8810228ec630
FS:  0000000000000000(0000) GS:ffff881024c78400(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff881824cae000, task ffff881024c90000)
Stack:  ffffffff80cd7a4b 0000000000000042 ffff882024acf800 ffff8810228ec630
 ffff881824cafb60 ffff882024acf9c0 00000000fffffff4 0000000000000042
 ffff882024acf890 ffff8810228ec630 ffff881824cafc70 ffffffff80948a81
Call Trace:
 [<ffffffff80948a81>] qla2x00_probe_one+0x112a/0x121a
 [<ffffffff8025393d>] ? default_wake_function+0x0/0xf
 [<ffffffff80966aa2>] ? wait_for_completion+0x18/0x1a
 [<ffffffff80257944>] ? set_cpus_allowed_ptr+0xfc/0x120
 [<ffffffff804cbf4a>] pci_device_probe+0xc8/0x11f
 [<ffffffff80544820>] driver_probe_device+0xc5/0x173
 [<ffffffff80544922>] __driver_attach+0x54/0x7e
 [<ffffffff805448ce>] ? __driver_attach+0x0/0x7e
 [<ffffffff80544076>] bus_for_each_dev+0x54/0x8e
 [<ffffffff804ba3c8>] ? kobject_get+0x1a/0x22
 [<ffffffff8054465c>] driver_attach+0x21/0x23
 [<ffffffff80543964>] bus_add_driver+0xbc/0x206
 [<ffffffff80544b34>] driver_register+0xad/0x12d
 [<ffffffff804cc213>] __pci_register_driver+0x6b/0xa4
 [<ffffffff80f00eb6>] ? qla2x00_module_init+0x0/0x12c
 [<ffffffff80f00fb2>] qla2x00_module_init+0xfc/0x12c
 [<ffffffff8020904c>] _stext+0x4c/0x144
 [<ffffffff8026aa63>] ? start_workqueue_thread+0x2b/0x2f
 [<ffffffff8026ae85>] ? __create_workqueue_key+0x112/0x22c
 [<ffffffff80ed578f>] kernel_init+0x228/0x29d
 [<ffffffff80227ff9>] child_rip+0xa/0x11
 [<ffffffff8023d489>] ? ftrace_test_p6nop+0x0/0xa
 [<ffffffff80ed5567>] ? kernel_init+0x0/0x29d
 [<ffffffff80227fef>] ? child_rip+0x0/0x11
Code: c7 83 c8 00 00 00 00 00 00 00 48 c7 83 c0 00 00 00 00 00 00 00
48 c7 83 a8 00 00 00 00 00 00 00 48 c7 83 a0 00 00 00 00 00 00 00 <4c>
8b 27 eb 21 48 8b 17 48 8b 47 08 48 89 42 08 48 89 10 48 89
RIP  [<ffffffff80672f9c>] qla2x00_free_device+0x571/0x618
 RSP <ffff881824cafb10>
CR2: 0000000000000000
---[ end trace 0e925ad07301302a ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G      D
2.6.27-rc5-tip-00672-ge5c5407-dirty #220
Call Trace:
 [<ffffffff80966666>] panic+0xa5/0x15c
 [<ffffffff80966789>] ? printk+0x6c/0x73
 [<ffffffff80517ce7>] ? account+0xe3/0xf2
 [<ffffffff80517e37>] ? extract_entropy+0x55/0x9c
 [<ffffffff8025dc5e>] do_exit+0x73/0x812
 [<ffffffff80517f72>] ? get_random_bytes+0x20/0x22
 [<ffffffff80969688>] oops_begin+0x0/0x9a
 [<ffffffff8096b679>] do_page_fault+0x7cb/0x8bf
 [<ffffffff8025ad99>] ? __call_console_drivers+0x6a/0x7b
 [<ffffffff8025b7da>] ? vprintk+0x2a0/0x2cc
 [<ffffffff80966789>] ? printk+0x6c/0x73
 [<ffffffff80969029>] error_exit+0x0/0x51
 [<ffffffff80672f9c>] ? qla2x00_free_device+0x571/0x618
 [<ffffffff80948a81>] qla2x00_probe_one+0x112a/0x121a
 [<ffffffff8025393d>] ? default_wake_function+0x0/0xf
 [<ffffffff80966aa2>] ? wait_for_completion+0x18/0x1a
 [<ffffffff80257944>] ? set_cpus_allowed_ptr+0xfc/0x120
 [<ffffffff804cbf4a>] pci_device_probe+0xc8/0x11f
 [<ffffffff80544820>] driver_probe_device+0xc5/0x173
 [<ffffffff80544922>] __driver_attach+0x54/0x7e
 [<ffffffff805448ce>] ? __driver_attach+0x0/0x7e
 [<ffffffff80544076>] bus_for_each_dev+0x54/0x8e
 [<ffffffff804ba3c8>] ? kobject_get+0x1a/0x22
 [<ffffffff8054465c>] driver_attach+0x21/0x23
 [<ffffffff80543964>] bus_add_driver+0xbc/0x206
 [<ffffffff80544b34>] driver_register+0xad/0x12d
 [<ffffffff804cc213>] __pci_register_driver+0x6b/0xa4
 [<ffffffff80f00eb6>] ? qla2x00_module_init+0x0/0x12c
 [<ffffffff80f00fb2>] qla2x00_module_init+0xfc/0x12c
 [<ffffffff8020904c>] _stext+0x4c/0x144
 [<ffffffff8026aa63>] ? start_workqueue_thread+0x2b/0x2f
 [<ffffffff8026ae85>] ? __create_workqueue_key+0x112/0x22c
 [<ffffffff80ed578f>] kernel_init+0x228/0x29d
 [<ffffffff80227ff9>] child_rip+0xa/0x11
 [<ffffffff8023d489>] ? ftrace_test_p6nop+0x0/0xa
 [<ffffffff80ed5567>] ? kernel_init+0x0/0x29d
 [<ffffffff80227fef>] ? child_rip+0x0/0x11

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> please check
> 
>   __request_region: conflict: (reserved) [dd000000, efffffff], res:
> (qla2xxx) [ddffc000, ddffffff]
> busy flag
> qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]

Ok, this is actually when the driver wants to reserve the BAR, and then it 
norices that there is an existing "reservation" there.

So yes, drivers will care - they literally will think that somebody else 
owns their resource if they have a BUSY resource inside of them. So this 
is a driver protecting against another driver.

The sad part is that it looks like it's entirely due to the PCI code 
trying to emulate an ISA driver model, and use a flat resource space - so 
it hits the upper resources first.

Does this patch make a difference? It actually removes a fair chunk of 
code, by just saying "we really don't care if the resource is IO or MEM, 
we just want to reserve space inside of it, regardless of type".

Untested - obviously.

		Linus

---
 drivers/pci/pci.c |   26 +++++++++-----------------
 1 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c9884bb..a3de4fe 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1304,15 +1304,11 @@ pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge)
 void pci_release_region(struct pci_dev *pdev, int bar)
 {
 	struct pci_devres *dr;
+	struct resource *res = pdev->resource + bar;
 
 	if (pci_resource_len(pdev, bar) == 0)
 		return;
-	if (pci_resource_flags(pdev, bar) & IORESOURCE_IO)
-		release_region(pci_resource_start(pdev, bar),
-				pci_resource_len(pdev, bar));
-	else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM)
-		release_mem_region(pci_resource_start(pdev, bar),
-				pci_resource_len(pdev, bar));
+	__release_region(res, pci_resource_start(pdev, bar), pci_resource_len(pdev, bar));
 
 	dr = find_pci_dr(pdev);
 	if (dr)
@@ -1336,20 +1332,16 @@ void pci_release_region(struct pci_dev *pdev, int bar)
 int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name)
 {
 	struct pci_devres *dr;
+	struct resource *res = pdev->resource + bar;
 
 	if (pci_resource_len(pdev, bar) == 0)
 		return 0;
-		
-	if (pci_resource_flags(pdev, bar) & IORESOURCE_IO) {
-		if (!request_region(pci_resource_start(pdev, bar),
-			    pci_resource_len(pdev, bar), res_name))
-			goto err_out;
-	}
-	else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
-		if (!request_mem_region(pci_resource_start(pdev, bar),
-				        pci_resource_len(pdev, bar), res_name))
-			goto err_out;
-	}
+
+	if (!res->parent)
+		goto err_out;
+
+	if (!__request_region(res, pci_resource_start(pdev, bar), pci_resource_len(pdev, bar), res_name))
+		goto err_out;
 
 	dr = find_pci_dr(pdev);
 	if (dr)

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Linus Torvalds wrote:
> 
> and while I still haven't actually tested it, it looks sane and compiles 
> to code that also looks sane.

.. and it even works (apart from a missing '\n' for the expansion report 
;).

I tested it with the appended silly test-case, and it shows

	...
	 BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
	 BIOS-e820: 0000000100000000 - 0000000160000000 (usable)
	Expanded resource Kernel dummy due to conflict with Kernel code
	Expanded resource Kernel dummy due to conflict with Kernel data
	last_pfn = 0x160000 max_arch_pfn = 0x3ffffffff
	x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
	...

and /proc/iomem shows

	...
	00100000-9cf64fff : System RAM
	  00200000-006ea27f : Kernel dummy
	    00200000-00561f37 : Kernel code
	    00561f38-006ea27f : Kernel data
	  00777000-007d6cc7 : Kernel bss
	...

so it correctly expanded that "Kernel dummy" resource to cover the 
resources it had clashed with.

And no, it's not perfect. We certainly _could_ split things instead. But I 
hope that odd "e820 resources were bogus" case almost never would actually 
trigger in practice, and the expansion case is not only simpler, it's also 
slightly more robust in the sense that a single big resource is likely to 
fit the things we need than multiple smaller resources that have been 
chopped up.

		Linus

--- dummy test patch for the 'insert-resource-expand-to-fit' thing ---
 arch/x86/kernel/setup.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 362d4e7..6265a38 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -578,6 +578,14 @@ static struct x86_quirks default_x86_quirks __initdata;
 
 struct x86_quirks *x86_quirks __initdata = &default_x86_quirks;
 
+static struct resource dummy_resource = {
+	.name	= "Kernel dummy",
+	.start	= 0,
+	.end	= 0,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+};
+
+
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been
  * passed the efi memmap, systab, etc., so we should use these data structures
@@ -665,6 +673,9 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = virt_to_phys(&__bss_start);
 	bss_resource.end = virt_to_phys(&__bss_stop)-1;
 
+	dummy_resource.start = code_resource.end - 1024;
+	dummy_resource.end = data_resource.start + 1024;
+
 	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
 
@@ -704,6 +715,8 @@ void __init setup_arch(char **cmdline_p)
 	insert_resource(&iomem_resource, &data_resource);
 	insert_resource(&iomem_resource, &bss_resource);
 
+	insert_resource_expand_to_fit(&iomem_resource, &dummy_resource);
+
 	if (efi_enabled)
 		efi_init();
 

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 7:33 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> the root cause is:
>> before 2.6.26, call init_apic_mapping and will insert_resource for
>> lapic address.
>> and then call e820_resource_resouce (with request_resource) to
>> register e820 entries.
>
> So the problem there was that traditionally, e820_reserve_resource()
> expected to be the first one to populate any resources. That's changed,
> and that's why it now needs to use "insert_resource()" rather than
> "request_resource()".
>
>> so the lapic entry in the resource tree will prevent some entry in
>> e820 to be registered.
>> later request_resource for BAR res (==hpet) will succeed.
>>
>> from 2.6.26. we move lapic address registering to late_initcall, so
>> the entry is reserved in e820 getting into resource tree at first.
>> and later pci_resource_survey::request_resource for BAR res (==hpet,
>> 0xfed00000) will fail. so pci_assign_unsigned... will get new
>> res for the BAR, so it messed up hpet setting.
>
> So this didn't work _originally_ either?

orginally it works, because lapic address entry open the big hole for
near address.

>
>> solutions will be
>> 1. use quirk to protect hpet in BAR, Ingo said it is not generic.
>
> Yeah, I don't like it. The quirk I was talking about was the one about
> apparetly bogus MMIO address:
>
>>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>>        PCI: Using MMCONFIG at e0000000 - efffffff
>>
>> Where did it get that bogus "ffffffff" end address?
>
> which you said came from another BAR. That isn't the HPET.

that is from Rafael's system mmconfig BAR in 00:00.0. that chipset is broken ...

>
>
>> 2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
>> mmconfig) --> happenly reveal another problem with Rafael's
>> system/chipset.
>
> Yeah, no, that's horrid. I'm happy it's reverted.

if update res->end according mmconfig end, before insert it forcibly,
then could fix the chipset BAR problem too.

>
>> 3. or sticky resource... , but could have particallly overlapping
>
> And no, this doesn't work.
>
>> 4. or don't register reserved entries in e820.. Eric, Nacked.
>
> Yeah, no, we do want reserved entries from e820 to show up to at least
> stop late _dynamic_ allocations from taking over.
>
>> 5. or you sugges, regiser some reserved entries later...., and have
>> insert_resource_expand_to_fit...
>
> Yes. And I do think this is a workable model.

BTW, insert_resource_expand_to_fit need to be replaced with
insert_resource_split_to_fit....
test stub reveal expand will make __request_region not working for
some devices...because reserved_entries from e820 take
IORESOUCE_BUSY...

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> > Yeah, no, that's horrid. I'm happy it's reverted.
> 
> if update res->end according mmconfig end, before insert it forcibly,
> then could fix the chipset BAR problem too.

Except it's still a horrible patch that special-cases all the wrong things 
(ie random resources that we just happen to know that ACPI etc cares 
about).

There's no way to know in general if ACPI might care deeply where some 
random resource is (say, graphics memory) and it might be done with a BAR.

So that's why I think the approach stinks.

> BTW, insert_resource_expand_to_fit need to be replaced with
> insert_resource_split_to_fit....
> test stub reveal expand will make __request_region not working for
> some devices...because reserved_entries from e820 take
> IORESOUCE_BUSY...

Well, we should probably just remove the IORESOURCE_BUSY part.

Again, that comes from the fact that the e820 resources used to _override_ 
everything - they were inserted first, and nothing else was _ever_ allowed 
to allocate in that region. 

But if we're changing that, then the whole IORESOURCE_BUSY part doesn't 
make sense.

In fact, in general, IORESOURCE_BUSY doesn't much make sense any more in 
general, because it was actually more of an ISA-timeframe locking model 
saying "you can't touch this region". But if the whole point is that we 
now try to allow PCI device BAR's and the e820 maps to co-exist, then the 
whole - and only - reason for IORESOURCE_BUSY for them goes away..

			Linus

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 5:45 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> the BAR is from pci_read_bases..., so that chipset is broken...
>> they are even supposed to to hide that BAR to os.
>
> Ok, can we please
>
>  - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
>   not an x86 issue)

the quirk work at the first point for David' system.

[PATCH] x86: protect hpet in BAR for one ATI chipset v3

so avoid kernel don't allocate nre resource for it because it can not
allocate the old
address from BIOS.

the same way like some IO APIC address in BAR handling

v3: device id should be 0x4385

Signed-off-by: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

---
 drivers/pci/quirks.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: linux-2.6/drivers/pci/quirks.c
===================================================================
--- linux-2.6.orig/drivers/pci/quirks.c
+++ linux-2.6/drivers/pci/quirks.c
@@ -1918,6 +1918,22 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_B
                         PCI_DEVICE_ID_NX2_5709S,
                         quirk_brcm_570x_limit_vpd);

+static void __init quirk_hpet_in_bar(struct pci_dev *pdev)
+{
+       int i;
+       u64 base, size;
+
+       /* the BAR1 is the location of the HPET...we must
+        * not touch this, so forcibly insert it into the resource tree */
+       base = pci_resource_start(pdev, 1);
+       size = pci_resource_len(pdev, 1);
+       if (base && size) {
+               insert_resource(&iomem_resource, &pdev->resource[1]);
+               dev_info(&pdev->dev, "HPET at %08llx-%08llx\n", base,
base + size - 1);
+       }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, 0x4385, quirk_hpet_in_bar);
+
 #ifdef CONFIG_PCI_MSI
 /* Some chipsets do not support MSI. We cannot easily rely on setting
  * PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually


or waiting for another quirk from Jordan to set magic to hide the that BAR?


>
>  - *not* get any more random PCI work-arounds that go through the x86 tree
>   and aren't even looked at by the (very few) people who actually
>   understand the PCI resource handling?

stop working on following path?
[PATCH] x86: split e820 reserved entries record to late v4
[PATCH] x86: split e820 reserved entries record to late v4 - fix v2


>
> IOW, for the first issue, just teach pci_mmcfg_check_hostbridge() about
> this broken bridge, and have it fix things up (including hiding the thing,
> but also just verifying that the dang thing even -works- etc).

sound good, will look at after get lspci -tv and lspci -vvxxx from Rafael.

also quirk between probe::pci_read_bases and pci_resource_survey
could be used to make the BAR res ->end to be more reasonable.

>
> For the second issue - please do realize that we have had much over a
> _decade_ of work on the PCI resource handling, and it's fragile. The thing
> I reverted really isn't something that Ingo should ever have committed in
> the first place. It's not something an x86 maintainer can even make sane
> decisions on.
>
> Resource handling things _need_ to get ACK's from people like Ivan
> Kokshaysky or me. Or at least _several_ other people who actually really
> understand not just PCI resource handling, but have actually seen all the
> horrible crap it causes, and understand how fragile this stuff is. It's
> all different, and it's all about all the million of broken machines out
> there that screw things up.

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> > Ok, can we please
> >
> >  - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
> >   not an x86 issue)
> 
> the quirk work at the first point for David' system.

That was not what I meant - meant the known-broken MMIO bar.

> [PATCH] x86: protect hpet in BAR for one ATI chipset v3

Now, this is probably fine too in theory, but

 - you didn't check if the BAR is even enabled, afaik

 - the other patch - to move the reserved e820 range later - should make 
   this pointless, no?

> >  - *not* get any more random PCI work-arounds that go through the x86 tree
> >   and aren't even looked at by the (very few) people who actually
> >   understand the PCI resource handling?
> 
> stop working on following path?
> [PATCH] x86: split e820 reserved entries record to late v4
> [PATCH] x86: split e820 reserved entries record to late v4 - fix v2

No, I think this is worth doing, BUT IT MUST NOT BE MERGED BY JUST SENDING 
IT TO INGO.

It's not an "x86 patch". It's about the PCI resources.

And those kinds of patches need to be acked by people who know and 
understand the PCI resource issues and have some memory of just how 
broken machines can exist.

			Linus

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 7:16 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> > Ok, can we please
>> >
>> >  - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
>> >   not an x86 issue)
>>
>> the quirk work at the first point for David' system.
>
> That was not what I meant - meant the known-broken MMIO bar.
>
>> [PATCH] x86: protect hpet in BAR for one ATI chipset v3
>
> Now, this is probably fine too in theory, but
>
>  - you didn't check if the BAR is even enabled, afaik
>
>  - the other patch - to move the reserved e820 range later - should make
>   this pointless, no?

yes.

>
>> >  - *not* get any more random PCI work-arounds that go through the x86 tree
>> >   and aren't even looked at by the (very few) people who actually
>> >   understand the PCI resource handling?
>>
>> stop working on following path?
>> [PATCH] x86: split e820 reserved entries record to late v4
>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v2
>
> No, I think this is worth doing, BUT IT MUST NOT BE MERGED BY JUST SENDING
> IT TO INGO.
>
> It's not an "x86 patch". It's about the PCI resources.
>
> And those kinds of patches need to be acked by people who know and
> understand the PCI resource issues and have some memory of just how
> broken machines can exist.

i see.

YH

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> >
>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>>
>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>
> And that seems utter crap to begin with.
>
>        PCI: Using MMCONFIG at e0000000 - efffffff
>
> Where did it get that bogus "ffffffff" end address?
>
> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
> and it's reverted now in my tree, so I guess it doesn't much matter.

we need to handle it. otherwise if the BAR go first, and it will stop
other BARs to be registered...

a quirk should do the work....

Rafael, can you send out lspci -tv and lspci --vvxxx too.

YH

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

[Yinghai Lu]

On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>
>>
>> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>> >
>>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>>>
>>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>>
>> And that seems utter crap to begin with.
>>
>>        PCI: Using MMCONFIG at e0000000 - efffffff
>>
>> Where did it get that bogus "ffffffff" end address?
>>
>> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
>> and it's reverted now in my tree, so I guess it doesn't much matter.
>
> we need to handle it. otherwise if the BAR go first, and it will stop
> other BARs to be registered...
>
> a quirk should do the work....
>
> Rafael, can you send out lspci -tv and lspci --vvxxx too.

cat /proc/iomem please.

YH

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
> > <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> >>
> >>
> >> On Fri, 29 Aug 2008, Yinghai Lu wrote:
> >>> >
> >>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
> >>>
> >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
> >>
> >> And that seems utter crap to begin with.
> >>
> >>        PCI: Using MMCONFIG at e0000000 - efffffff
> >>
> >> Where did it get that bogus "ffffffff" end address?
> >>
> >> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
> >> and it's reverted now in my tree, so I guess it doesn't much matter.
> >
> > we need to handle it. otherwise if the BAR go first, and it will stop
> > other BARs to be registered...
> >
> > a quirk should do the work....
> >
> > Rafael, can you send out lspci -tv and lspci --vvxxx too.
> 
> cat /proc/iomem please.

http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt

Thanks,
Rafael

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

On Sat, Aug 30, 2008 at 6:32 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
>> > <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>> >>
>> >>
>> >> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> >>> >
>> >>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>> >>>
>> >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>> >>
>> >> And that seems utter crap to begin with.
>> >>
>> >>        PCI: Using MMCONFIG at e0000000 - efffffff
>> >>
>> >> Where did it get that bogus "ffffffff" end address?
>> >>
>> >> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
>> >> and it's reverted now in my tree, so I guess it doesn't much matter.
>> >
>> > we need to handle it. otherwise if the BAR go first, and it will stop
>> > other BARs to be registered...
>> >
>> > a quirk should do the work....
>> >
>> > Rafael, can you send out lspci -tv and lspci --vvxxx too.
>>
>> cat /proc/iomem please.
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt
>

00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual
slot PCI-e_GFX and HT3 K8 part
	Subsystem: ATI Technologies Inc RD790 Northbridge only dual slot
PCI-e_GFX and HT3 K8 part
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Region 3: Memory at <ignored> (64-bit, non-prefetchable)
	Capabilities: [c4] HyperTransport: Slave or Primary Interface
		Command: BaseUnitID=0 UnitCnt=12 MastHost- DefDir- DUL-
		Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
IsocEn- LSEn- ExtCTL- 64b-
		Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit
DwFcInEn- LWO=16bit DwFcOutEn-
		Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
IsocEn- LSEn- ExtCTL- 64b-
		Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
DwFcInEn- LWO=8bit DwFcOutEn-
		Revision ID: 3.00
		Link Frequency 0: [b]
		Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+
800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
		Link Frequency 1: 200MHz
		Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz-
800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF-
RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
		Prefetchable memory behind bridge Upper: 00-00
		Bus Number: 00
	Capabilities: [40] HyperTransport: Retry Mode
	Capabilities: [54] HyperTransport: UnitID Clumping
	Capabilities: [9c] HyperTransport: #1a
00: 02 10 56 59 06 00 30 22 00 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 e0

so bar3 of 00:00.0 has oxe0000000 - 0xffffffff
and request_resource failed, so
	Region 3: Memory at <ignored> (64-bit, non-prefetchable)

BIOS should hide that region, and because AMD quad core has MMCONFIG
set in NB MSR already.

please try to apply attached patches, and boot with "debug initcall_debug"

applying sequence:

split_e820_reserve=.patch
pci_res_print_out.patch
split_e820_reserve_xx1.patch
insert_resource_debug.patch
pci_mmconf.patch

please send out
dmesg -s 262144 > x.txt
cat /proc/iomem

need to verify if we need quirk to clear that resource.

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pci_mmconf.patch --]
[-- Type: text/x-patch; name=pci_mmconf.patch, Size: 1720 bytes --]

From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: unify using pci_mmcfg_insert_resource

even with known_bridge insert them late too.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

Index: linux-2.6/arch/x86/pci/mmconfig-shared.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/mmconfig-shared.c
+++ linux-2.6/arch/x86/pci/mmconfig-shared.c
@@ -209,7 +209,7 @@ static int __init pci_mmcfg_check_hostbr
 	return name != NULL;
 }
 
-static void __init pci_mmcfg_insert_resources(unsigned long resource_flags)
+static void __init pci_mmcfg_insert_resources(void)
 {
 #define PCI_MMCFG_RESOURCE_NAME_LEN 19
 	int i;
@@ -233,7 +233,7 @@ static void __init pci_mmcfg_insert_reso
 			 cfg->pci_segment);
 		res->start = cfg->address;
 		res->end = res->start + (num_buses << 20) - 1;
-		res->flags = IORESOURCE_MEM | resource_flags;
+		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		insert_resource(&iomem_resource, res);
 		names += PCI_MMCFG_RESOURCE_NAME_LEN;
 	}
@@ -434,11 +434,9 @@ static void __init __pci_mmcfg_init(int
 	    (pci_mmcfg_config[0].address == 0))
 		return;
 
-	if (pci_mmcfg_arch_init()) {
-		if (known_bridge)
-			pci_mmcfg_insert_resources(IORESOURCE_BUSY);
+	if (pci_mmcfg_arch_init())
 		pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
-	} else {
+	else {
 		/*
 		 * Signal not to attempt to insert mmcfg resources because
 		 * the architecture mmcfg setup could not initialize.
@@ -475,7 +473,7 @@ static int __init pci_mmcfg_late_insert_
 	 * marked so it won't cause request errors when __request_region is
 	 * called.
 	 */
-	pci_mmcfg_insert_resources(0);
+	pci_mmcfg_insert_resources();
 
 	return 0;
 }

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: pci_res_print_out.patch --]
[-- Type: text/x-patch; name=pci_res_print_out.patch, Size: 2424 bytes --]

From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] pci: fix merging left out for BAR print out

print out for Device BAR address before kernel try to update them.

also change it to KERN_DEBUG instead...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cce2f4c..4ee06c3 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -304,6 +304,8 @@ static int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
 		} else {
 			res->start = l64;
 			res->end = l64 + sz64;
+			printk(KERN_DEBUG "PCI: %s reg %x 64bit mmio: [%llx, %llx]\n",
+				 pci_name(dev), pos, res->start, res->end);
 		}
 	} else {
 		sz = pci_size(l, sz, mask);
@@ -313,6 +315,10 @@ static int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
 
 		res->start = l;
 		res->end = l + sz;
+		printk(KERN_DEBUG "PCI: %s reg %x %s: [%llx, %llx]\n", pci_name(dev),
+			 pos, (res->flags & IORESOURCE_IO) ? "io port":"32bit mmio",
+			 res->start, res->end);
+
 	}
 
  out:
@@ -383,7 +389,7 @@ void __devinit pci_read_bridge_bases(struct pci_bus *child)
 			res->start = base;
 		if (!res->end)
 			res->end = limit + 0xfff;
-		printk(KERN_INFO "PCI: bridge %s io port: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
+		printk(KERN_DEBUG "PCI: bridge %s io port: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
 	}
 
 	res = child->resource[1];
@@ -395,7 +401,7 @@ void __devinit pci_read_bridge_bases(struct pci_bus *child)
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
 		res->start = base;
 		res->end = limit + 0xfffff;
-		printk(KERN_INFO "PCI: bridge %s 32bit mmio: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
+		printk(KERN_DEBUG "PCI: bridge %s 32bit mmio: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
 	}
 
 	res = child->resource[2];
@@ -431,7 +437,7 @@ void __devinit pci_read_bridge_bases(struct pci_bus *child)
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
 		res->start = base;
 		res->end = limit + 0xfffff;
-		printk(KERN_INFO "PCI: bridge %s %sbit mmio pref: [%llx, %llx]\n", pci_name(dev), (res->flags & PCI_PREF_RANGE_TYPE_64)?"64":"32",res->start, res->end);
+		printk(KERN_DEBUG "PCI: bridge %s %sbit mmio pref: [%llx, %llx]\n", pci_name(dev), (res->flags & PCI_PREF_RANGE_TYPE_64)?"64":"32",res->start, res->end);
 	}
 }
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: split_e820_reserve.patch --]
[-- Type: text/x-patch; name=split_e820_reserve.patch, Size: 3574 bytes --]

From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: split e820 reserved entries record to late v4

Linus said we should register some entries in e820 later,
so could let BAR res register at first, or even pnp?

this one replace
| commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date:   Mon Aug 25 00:56:08 2008 -0700
|
|    x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3

v2: insert e820 reserve resources before pnp_system_init
v3: fix merging problem in tip/x86/core
    please drop the one in tip/x86/core use this one instead
v4: address Linus's review about comments and condition in _late()

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/e820.c |   24 +++++++++++++++++++++++-
 arch/x86/pci/i386.c    |    3 +++
 include/asm-x86/e820.h |    1 +
 3 files changed, 27 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1271,6 +1271,7 @@ static inline const char *e820_type_to_s
 /*
  * Mark e820 reserved areas as busy for the resource manager.
  */
+static struct resource __initdata *e820_res;
 void __init e820_reserve_resources(void)
 {
 	int i;
@@ -1278,6 +1279,7 @@ void __init e820_reserve_resources(void)
 	u64 end;
 
 	res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
+	e820_res = res;
 	for (i = 0; i < e820.nr_map; i++) {
 		end = e820.map[i].addr + e820.map[i].size - 1;
 #ifndef CONFIG_RESOURCES_64BIT
@@ -1291,7 +1293,14 @@ void __init e820_reserve_resources(void)
 		res->end = end;
 
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-		insert_resource(&iomem_resource, res);
+
+		/*
+		 * don't register the region that could be conflicted with
+		 * pci device BAR resource and insert them later in
+		 * pcibios_resource_survey()
+		 */
+		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20))
+			insert_resource(&iomem_resource, res);
 		res++;
 	}
 
@@ -1303,6 +1312,19 @@ void __init e820_reserve_resources(void)
 	}
 }
 
+void __init e820_reserve_resources_late(void)
+{
+	int i;
+	struct resource *res;
+
+	res = e820_res;
+	for (i = 0; i < e820.nr_map; i++) {
+		if (!res->parent && res->end)
+			insert_resource(&iomem_resource, res);
+		res++;
+	}
+}
+
 char *__init default_machine_specific_memory_setup(void)
 {
 	char *who = "BIOS-e820";
Index: linux-2.6/arch/x86/pci/i386.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/i386.c
+++ linux-2.6/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
 #include <linux/bootmem.h>
 
 #include <asm/pat.h>
+#include <asm/e820.h>
 
 #include "pci.h"
 
@@ -230,6 +231,8 @@ void __init pcibios_resource_survey(void
 	pcibios_allocate_bus_resources(&pci_root_buses);
 	pcibios_allocate_resources(0);
 	pcibios_allocate_resources(1);
+
+	e820_reserve_resources_late();
 }
 
 /**
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820.h
+++ linux-2.6/include/asm-x86/e820.h
@@ -122,6 +122,7 @@ extern void e820_register_active_regions
 extern u64 e820_hole_size(u64 start, u64 end);
 extern void finish_e820_parsing(void);
 extern void e820_reserve_resources(void);
+extern void e820_reserve_resources_late(void);
 extern void setup_memory_map(void);
 extern char *default_machine_specific_memory_setup(void);
 extern char *machine_specific_memory_setup(void);

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: split_e820_reserve_xx1.patch --]
[-- Type: text/x-patch; name=split_e820_reserve_xx1.patch, Size: 6592 bytes --]

From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: split e820 reserved entries record to late v4 - fix v3

try to insert_resource second time, by expand the resource...

for case: e820 reserved entry is partially overlapped with bar res...

hope it will never happen

v2: according to Linus, add insert_resource_expand_to_fit, and change
	__insert_resource to static without lock

v3: use reserve_region_with_split() instead to hand overlapping
	with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
	get
		e0000000-efffffff : PCI MMCONFIG 0
			 e0000000-efffffff : reserved
	in /proc/iomem
	get
		found conflict for reserved [dd800000, efffffff], try to reserve with split
		    __reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
		    __reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
		initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
	in dmesg

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/e820.c |    8 +++-
 include/linux/ioport.h |    3 +
 kernel/resource.c      |   95 ++++++++++++++++++++++++++++++++++++++++++-------
 3 files changed, 92 insertions(+), 14 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1319,8 +1319,12 @@ void __init e820_reserve_resources_late(
 
 	res = e820_res;
 	for (i = 0; i < e820.nr_map; i++) {
-		if (!res->parent && res->end)
-			insert_resource(&iomem_resource, res);
+		if (!res->parent && res->end && insert_resource(&iomem_resource, res)) {
+			printk(KERN_WARNING "found conflict for %s [%08llx, %08llx], try to reserve with split\n",
+				res->name, res->start, res->end);
+
+			reserve_region_with_split(&iomem_resource, res->start, res->end, res->name);
+		}
 		res++;
 	}
 }
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -108,6 +108,9 @@ extern struct resource iomem_resource;
 
 extern int request_resource(struct resource *root, struct resource *new);
 extern int release_resource(struct resource *new);
+extern void reserve_region_with_split(struct resource *root,
+			     resource_size_t start, resource_size_t end,
+			     const char *name);
 extern int insert_resource(struct resource *parent, struct resource *new);
 extern int allocate_resource(struct resource *root, struct resource *new,
 			     resource_size_t size, resource_size_t min,
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -363,32 +363,30 @@ int allocate_resource(struct resource *r
 EXPORT_SYMBOL(allocate_resource);
 
 /**
- * insert_resource - Inserts a resource in the resource tree
+ * __insert_resource - Inserts a resource in the resource tree
  * @parent: parent of the new resource
  * @new: new resource to insert
  *
- * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ * Returns NULL on success, or first conflict resource.
  *
- * This function is equivalent to request_resource when no conflict
+ * This function is equivalent to __request_resource when no conflict
  * happens. If a conflict happens, and the conflicting resources
  * entirely fit within the range of the new resource, then the new
  * resource is inserted and the conflicting resources become children of
  * the new resource.
  */
-int insert_resource(struct resource *parent, struct resource *new)
+static struct resource *__insert_resource(struct resource *parent, struct resource *new)
 {
-	int result;
+	struct resource *ret_res;
 	struct resource *first, *next;
 
-	write_lock(&resource_lock);
-
 	for (;; parent = first) {
-	 	result = 0;
+		ret_res = NULL;
 		first = __request_resource(parent, new);
 		if (!first)
 			goto out;
 
-		result = -EBUSY;
+		ret_res = first;
 		if (first == parent)
 			goto out;
 
@@ -400,15 +398,17 @@ int insert_resource(struct resource *par
 
 	for (next = first; ; next = next->sibling) {
 		/* Partial overlap? Bad, and unfixable */
-		if (next->start < new->start || next->end > new->end)
+		if (next->start < new->start || next->end > new->end) {
+			ret_res = next;
 			goto out;
+		}
 		if (!next->sibling)
 			break;
 		if (next->sibling->start > new->end)
 			break;
 	}
 
-	result = 0;
+	ret_res = NULL;
 
 	new->parent = parent;
 	new->sibling = next->sibling;
@@ -428,8 +428,79 @@ int insert_resource(struct resource *par
 	}
 
  out:
+	return ret_res;
+}
+
+/**
+ * insert_resource - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ */
+int insert_resource(struct resource *parent, struct resource *new)
+{
+	struct resource *res_conflict;
+
+	write_lock(&resource_lock);
+	res_conflict = __insert_resource(parent, new);
+	write_unlock(&resource_lock);
+
+	return res_conflict ? -EBUSY : 0;
+}
+
+static void __init __reserve_region_with_split(struct resource *root,
+		resource_size_t start, resource_size_t end,
+		const char *name)
+{
+	struct resource *parent = root;
+	struct resource *conflict;
+	struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL);
+
+	if (!res)
+		return;
+
+	res->name = name;
+	res->start = start;
+	res->end = end;
+	res->flags = IORESOURCE_BUSY;
+
+	for (;;) {
+		conflict = __request_resource(parent, res);
+		if (!conflict)
+			break;
+		if (conflict != parent) {
+			parent = conflict;
+			if (!(conflict->flags & IORESOURCE_BUSY))
+				continue;
+		}
+
+		/* Uhhuh, that didn't work out.. */
+		kfree(res);
+		res = NULL;
+		break;
+	}
+
+	if (!res) {
+		printk(KERN_DEBUG "    __reserve_region_with_split: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n",
+			 conflict->name, conflict->start, conflict->end,
+			 name, start, end);
+		/* failed, split and try again */
+		if (conflict->start > start)
+			__reserve_region_with_split(root, start, conflict->start, name);
+		if (conflict->end < end)
+			__reserve_region_with_split(root, conflict->end+1, end, name);
+	}
+
+}
+
+void reserve_region_with_split(struct resource *root,
+		resource_size_t start, resource_size_t end,
+		const char *name)
+{
+	write_lock(&resource_lock);
+	__reserve_region_with_split(root, start, end, name);
 	write_unlock(&resource_lock);
-	return result;
 }
 
 /**

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: insert_resource_debug.patch --]
[-- Type: text/x-patch; name=insert_resource_debug.patch, Size: 3148 bytes --]

---
 kernel/resource.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -201,6 +201,7 @@ int request_resource(struct resource *ro
 	write_lock(&resource_lock);
 	conflict = __request_resource(root, new);
 	write_unlock(&resource_lock);
+	printk(KERN_DEBUG "request_resource: root: (%s) [%llx, %llx], new: (%s) [%llx, %llx] conflict %d\n", root->name, root->start, root->end, new->name, new->start, new->end, !!conflict);
 	return conflict ? -EBUSY : 0;
 }
 
@@ -380,16 +381,20 @@ static struct resource *__insert_resourc
 	struct resource *ret_res;
 	struct resource *first, *next;
 
+	printk(KERN_DEBUG "insert_resource: parent: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, new->name, new->start, new->end);
 	for (;; parent = first) {
 		ret_res = NULL;
 		first = __request_resource(parent, new);
-		if (!first)
+		if (!first) {
+			printk(KERN_DEBUG "    insert_resource: good with request direct parent: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, new->name, new->start, new->end);
 			goto out;
+		}
 
 		ret_res = first;
 		if (first == parent)
 			goto out;
 
+		printk(KERN_DEBUG "  insert_resource: first: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", first->name, first->start, first->end, new->name, new->start, new->end);
 		if ((first->start > new->start) || (first->end < new->end))
 			break;
 		if ((first->start == new->start) && (first->end == new->end))
@@ -413,10 +418,13 @@ static struct resource *__insert_resourc
 	new->parent = parent;
 	new->sibling = next->sibling;
 	new->child = first;
+	printk(KERN_DEBUG "  insert_resource: direct parent: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, new->name, new->start, new->end);
 
 	next->sibling = NULL;
-	for (next = first; next; next = next->sibling)
+	for (next = first; next; next = next->sibling) {
 		next->parent = new;
+		printk(KERN_DEBUG "    insert_resource: child: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", next->name, next->start, next->end, new->name, new->start, new->end);
+	}
 
 	if (parent->child == first) {
 		parent->child = new;
@@ -602,12 +610,16 @@ struct resource * __request_region(struc
 			struct resource *conflict;
 
 			conflict = __request_resource(parent, res);
-			if (!conflict)
+			if (!conflict) {
+				printk(KERN_DEBUG "    __request_region: good with request direct parent: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, res->name, res->start, res->end);
 				break;
+			}
 			if (conflict != parent) {
+				printk(KERN_DEBUG "  __request_region: conflict: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n", conflict->name, conflict->start, conflict->end, res->name, res->start, res->end);
 				parent = conflict;
 				if (!(conflict->flags & IORESOURCE_BUSY))
 					continue;
+				printk(KERN_DEBUG "busy flag\n");
 			}
 
 			/* Uhhuh, that didn't work out.. */

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 6:32 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >> On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
> >> > <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> >> >>
> >> >>
> >> >> On Fri, 29 Aug 2008, Yinghai Lu wrote:
> >> >>> >
> >> >>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
> >> >>>
> >> >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
> >> >>
> >> >> And that seems utter crap to begin with.
> >> >>
> >> >>        PCI: Using MMCONFIG at e0000000 - efffffff
> >> >>
> >> >> Where did it get that bogus "ffffffff" end address?
> >> >>
> >> >> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
> >> >> and it's reverted now in my tree, so I guess it doesn't much matter.
> >> >
> >> > we need to handle it. otherwise if the BAR go first, and it will stop
> >> > other BARs to be registered...
> >> >
> >> > a quirk should do the work....
> >> >
> >> > Rafael, can you send out lspci -tv and lspci --vvxxx too.
> >>
> >> cat /proc/iomem please.
> >
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt
> >
> 
> 00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual
> slot PCI-e_GFX and HT3 K8 part
> 	Subsystem: ATI Technologies Inc RD790 Northbridge only dual slot
> PCI-e_GFX and HT3 K8 part
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> 	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> 	Latency: 0
> 	Region 3: Memory at <ignored> (64-bit, non-prefetchable)
> 	Capabilities: [c4] HyperTransport: Slave or Primary Interface
> 		Command: BaseUnitID=0 UnitCnt=12 MastHost- DefDir- DUL-
> 		Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
> IsocEn- LSEn- ExtCTL- 64b-
> 		Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit
> DwFcInEn- LWO=16bit DwFcOutEn-
> 		Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
> IsocEn- LSEn- ExtCTL- 64b-
> 		Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
> DwFcInEn- LWO=8bit DwFcOutEn-
> 		Revision ID: 3.00
> 		Link Frequency 0: [b]
> 		Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
> 		Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+
> 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
> 		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
> 		Link Frequency 1: 200MHz
> 		Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
> 		Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz-
> 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
> 		Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF-
> RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
> 		Prefetchable memory behind bridge Upper: 00-00
> 		Bus Number: 00
> 	Capabilities: [40] HyperTransport: Retry Mode
> 	Capabilities: [54] HyperTransport: UnitID Clumping
> 	Capabilities: [9c] HyperTransport: #1a
> 00: 02 10 56 59 06 00 30 22 00 00 00 06 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 e0
> 
> so bar3 of 00:00.0 has oxe0000000 - 0xffffffff
> and request_resource failed, so
> 	Region 3: Memory at <ignored> (64-bit, non-prefetchable)
> 
> BIOS should hide that region, and because AMD quad core has MMCONFIG
> set in NB MSR already.
> 
> please try to apply attached patches, and boot with "debug initcall_debug"
> 
> applying sequence:
> 
> split_e820_reserve=.patch
> pci_res_print_out.patch
> split_e820_reserve_xx1.patch

The above one doesn't apply.

> insert_resource_debug.patch
> pci_mmconf.patch

Could you please rebase them on top of current -git?

Rafael

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

>
> Could you please rebase them on top of current -git?

please check attached quilt series based on linus tree.

YH

[-- Attachment #2: reserve_region.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 4393 bytes --]

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
>>
>> Could you please rebase them on top of current -git?
>
> please check attached quilt series based on linus tree.

there is some problem with fix -v4...on one test machine.

please don't use it now

YH

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>>
>>>
>>> Could you please rebase them on top of current -git?
>>
>> please check attached quilt series based on linus tree.
>
> there is some problem with fix -v4...on one test machine.
>

this one should work.

YH

[-- Attachment #2: reserve_region_v5.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 4446 bytes --]

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >>
> >>>
> >>> Could you please rebase them on top of current -git?
> >>
> >> please check attached quilt series based on linus tree.
> >
> > there is some problem with fix -v4...on one test machine.
> >
> 
> this one should work.

dmesg -s 262144

http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/dmesg-test.log

cat /proc/iomem

http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/iomem-test.txt

Thanks,
Rafael

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 12:51 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> >>
>> >>>
>> >>> Could you please rebase them on top of current -git?
>> >>
>> >> please check attached quilt series based on linus tree.
>> >
>> > there is some problem with fix -v4...on one test machine.
>> >
>>
>> this one should work.
>
> dmesg -s 262144
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/dmesg-test.log
>
> cat /proc/iomem
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/iomem-test.txt

calling  pci_subsys_init+0x0/0x120
PCI: Using ACPI for IRQ routing
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:01)
[9000, 9fff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:01) [fe700000, fe7fffff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:01) [d8000000, dfffffff] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:02)
[a000, bfff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:02) [fe800000, fe8fffff] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:03)
[c000, cfff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:03) [fe900000, fe9fffff] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:04)
[d000, efff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:04) [fea00000, feafffff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:05) [feb00000, febfffff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new:
(0000:00:00.0) [e0000000, ffffffff] conflict 1
pci 0000:00:00.0: BAR 3: can't allocate resource

so pci_resource_survey is depth first. sub buses request some resource
at first...

we don't need quirk to handle that strange BAR res.

and we got reserved register correctly
in /proc/iomem
d7fe0000-d7ffffff : reserved
..
fff00000-ffffffff : reserved

for
 BIOS-e820: 00000000d7fe0000 - 00000000d8000000 (reserved)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)

YH

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

[Linus Torvalds]

On Fri, 29 Aug 2008, Rafael J. Wysocki wrote:
> 
> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> 
> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date:   Mon Aug 25 00:56:08 2008 -0700
> 
>     x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> 
> Reverting this commit helps.

Heh, interesting, since we were talking about reverting that one for other 
reasons entirely.

See the thread "x86: split e820 reserved entries record to late" (yeah, I 
know that subject isn't very grammatical or sensible) for some patches 
worth trying _after_ you've reverted that one.

Anyway, clearly that commit needs to be reverted regardless, so I'll do 
the revert. Can you please test the appended test-patch by Yinghai on top 
of the revert?

(This is not the final version, but it should be sufficient to be tested)

And if you have the whole dmesg, that would be useful.

		Linus

---
From: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: [PATCH] x86: split e820 reserved entries record to late v3
Date: Thu, 28 Aug 2008 17:41:29 -0700

so could let BAR res register at first, or even pnp?

v2: insert e820 reserve resources before pnp_system_init
v3: fix merging problem in tip/x86/core
    please drop the one in tip/x86/core use this one instead

Signed-off-by: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

---
 arch/x86/kernel/e820.c |   20 ++++++++++++++++++--
 arch/x86/pci/i386.c    |    3 +++
 include/asm-x86/e820.h |    1 +
 3 files changed, 22 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1271,13 +1271,15 @@ static inline const char *e820_type_to_s
 /*
  * Mark e820 reserved areas as busy for the resource manager.
  */
+struct resource __initdata *e820_res;
 void __init e820_reserve_resources(void)
 {
 	int i;
-	struct resource *res;
 	u64 end;
+	struct resource *res;
 
 	res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
+	e820_res = res;
 	for (i = 0; i < e820.nr_map; i++) {
 		end = e820.map[i].addr + e820.map[i].size - 1;
 #ifndef CONFIG_RESOURCES_64BIT
@@ -1291,7 +1293,8 @@ void __init e820_reserve_resources(void)
 		res->end = end;
 
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-		insert_resource(&iomem_resource, res);
+		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20))
+			insert_resource(&iomem_resource, res);
 		res++;
 	}
 
@@ -1303,6 +1306,19 @@ void __init e820_reserve_resources(void)
 	}
 }
 
+void __init e820_reserve_resources_late(void)
+{
+	int i;
+	struct resource *res;
+
+	res = e820_res;
+	for (i = 0; i < e820.nr_map; i++) {
+		if (e820.map[i].type == E820_RESERVED && res->start >= (1ULL<<20))
+			insert_resource(&iomem_resource, res);
+		res++;
+	}
+}
+
 char *__init default_machine_specific_memory_setup(void)
 {
 	char *who = "BIOS-e820";
Index: linux-2.6/arch/x86/pci/i386.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/i386.c
+++ linux-2.6/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
 #include <linux/bootmem.h>
 
 #include <asm/pat.h>
+#include <asm/e820.h>
 
 #include "pci.h"
 
@@ -230,6 +231,8 @@ void __init pcibios_resource_survey(void
 	pcibios_allocate_bus_resources(&pci_root_buses);
 	pcibios_allocate_resources(0);
 	pcibios_allocate_resources(1);
+
+	e820_reserve_resources_late();
 }
 
 /**
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820.h
+++ linux-2.6/include/asm-x86/e820.h
@@ -122,6 +122,7 @@ extern void e820_register_active_regions
 extern u64 e820_hole_size(u64 start, u64 end);
 extern void finish_e820_parsing(void);
 extern void e820_reserve_resources(void);
+extern void e820_reserve_resources_late(void);
 extern void setup_memory_map(void);
 extern char *default_machine_specific_memory_setup(void);
 extern char *machine_specific_memory_setup(void);

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

[Rafael J. Wysocki]

On Friday, 29 of August 2008, Linus Torvalds wrote:
> 
> On Fri, 29 Aug 2008, Rafael J. Wysocki wrote:
> > 
> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> > 
> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> > Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date:   Mon Aug 25 00:56:08 2008 -0700
> > 
> >     x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> > 
> > Reverting this commit helps.
> 
> Heh, interesting, since we were talking about reverting that one for other 
> reasons entirely.
> 
> See the thread "x86: split e820 reserved entries record to late" (yeah, I 
> know that subject isn't very grammatical or sensible) for some patches 
> worth trying _after_ you've reverted that one.
> 
> Anyway, clearly that commit needs to be reverted regardless, so I'll do 
> the revert. Can you please test the appended test-patch by Yinghai on top 
> of the revert?
> 
> (This is not the final version, but it should be sufficient to be tested)

This works, thanks.

> And if you have the whole dmesg, that would be useful.

dmesg from -rc5 with the offending commit reverted and with the patch
below applied is at:

http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log

Thanks,
Rafael


> ---
> From: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: [PATCH] x86: split e820 reserved entries record to late v3
> Date: Thu, 28 Aug 2008 17:41:29 -0700
> 
> so could let BAR res register at first, or even pnp?
> 
> v2: insert e820 reserve resources before pnp_system_init
> v3: fix merging problem in tip/x86/core
>     please drop the one in tip/x86/core use this one instead
> 
> Signed-off-by: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> ---
>  arch/x86/kernel/e820.c |   20 ++++++++++++++++++--
>  arch/x86/pci/i386.c    |    3 +++
>  include/asm-x86/e820.h |    1 +
>  3 files changed, 22 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/arch/x86/kernel/e820.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/e820.c
> +++ linux-2.6/arch/x86/kernel/e820.c
> @@ -1271,13 +1271,15 @@ static inline const char *e820_type_to_s
>  /*
>   * Mark e820 reserved areas as busy for the resource manager.
>   */
> +struct resource __initdata *e820_res;
>  void __init e820_reserve_resources(void)
>  {
>  	int i;
> -	struct resource *res;
>  	u64 end;
> +	struct resource *res;
>  
>  	res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
> +	e820_res = res;
>  	for (i = 0; i < e820.nr_map; i++) {
>  		end = e820.map[i].addr + e820.map[i].size - 1;
>  #ifndef CONFIG_RESOURCES_64BIT
> @@ -1291,7 +1293,8 @@ void __init e820_reserve_resources(void)
>  		res->end = end;
>  
>  		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> -		insert_resource(&iomem_resource, res);
> +		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20))
> +			insert_resource(&iomem_resource, res);
>  		res++;
>  	}
>  
> @@ -1303,6 +1306,19 @@ void __init e820_reserve_resources(void)
>  	}
>  }
>  
> +void __init e820_reserve_resources_late(void)
> +{
> +	int i;
> +	struct resource *res;
> +
> +	res = e820_res;
> +	for (i = 0; i < e820.nr_map; i++) {
> +		if (e820.map[i].type == E820_RESERVED && res->start >= (1ULL<<20))
> +			insert_resource(&iomem_resource, res);
> +		res++;
> +	}
> +}
> +
>  char *__init default_machine_specific_memory_setup(void)
>  {
>  	char *who = "BIOS-e820";
> Index: linux-2.6/arch/x86/pci/i386.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/i386.c
> +++ linux-2.6/arch/x86/pci/i386.c
> @@ -33,6 +33,7 @@
>  #include <linux/bootmem.h>
>  
>  #include <asm/pat.h>
> +#include <asm/e820.h>
>  
>  #include "pci.h"
>  
> @@ -230,6 +231,8 @@ void __init pcibios_resource_survey(void
>  	pcibios_allocate_bus_resources(&pci_root_buses);
>  	pcibios_allocate_resources(0);
>  	pcibios_allocate_resources(1);
> +
> +	e820_reserve_resources_late();
>  }
>  
>  /**
> Index: linux-2.6/include/asm-x86/e820.h
> ===================================================================
> --- linux-2.6.orig/include/asm-x86/e820.h
> +++ linux-2.6/include/asm-x86/e820.h
> @@ -122,6 +122,7 @@ extern void e820_register_active_regions
>  extern u64 e820_hole_size(u64 start, u64 end);
>  extern void finish_e820_parsing(void);
>  extern void e820_reserve_resources(void);
> +extern void e820_reserve_resources_late(void);
>  extern void setup_memory_map(void);
>  extern char *default_machine_specific_memory_setup(void);
>  extern char *machine_specific_memory_setup(void);
> 
> 
> 

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Rafael J. Wysocki wrote:
> 
> > And if you have the whole dmesg, that would be useful.
> 
> dmesg from -rc5 with the offending commit reverted and with the patch
> below applied is at:
> 
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log

Ok, the more I look at this, the more interesting it gets.

In particular, this:

	...
	ACPI: bus type pnp registered
	pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
	pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
	pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
	pnp 00:09: mem resource (0xfff00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
	pnp 00:0b: mem resource (0xe0000000-0xefffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
	pnp 00:0c: mem resource (0xfec00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
	pnp: PnP ACPI: found 13 devices
	ACPI: ACPI bus type pnp unregistered
	SCSI subsystem initialized
	libata version 3.00 loaded.
	usbcore: registered new interface driver usbfs
	usbcore: registered new interface driver hub
	usbcore: registered new device driver usb
	PCI: Using ACPI for IRQ routing
	pci 0000:00:00.0: BAR 3: can't allocate resource
	...

there's a few things to note here:

 - the resource at 0000:00:00.0 BAR 3 is totally bogus.

   We know it's totally bogus because you actually have other resources in 
   the 0xf....... range, and they work fine. It's also likely to be 
   totally bogus because it so happens that the end-point of 0xffffffff is 
   commonly something that the BIOS leaves as a "I sized this resource", 
   because that's how resources are sized (you write all ones into them 
   and look what you can read back).

   But your lspci -vxx output clearly shows that (a) MEM is enabled in 
   the command word, and yes, the BAR register at 0x18 does indeed have 
   value 0xe0000000. So it's just the length that is really bogus.

 - pnp clearly sees that bogus resource at 0xe0000000-0xffffffff

 - BUT: the "can't allocate resource" thing is from 
   pcibios_allocate_resources(), and means that the request_resource() 
   failed _despite_ the fact that you hadn't reserved the e820 resources 
   yet with the new patch.

The thing that seems to save you is that we've already allocated something 
in that region. There's a few things there, like:

	fee00000-fee00fff : Local APIC

but that particular one is actually reserved much later, so that doesn't 
explain it. I think that what happens is that we have allocated the _bus_ 
resources earlier in "pcibios_allocate_bus_resources()", and that means 
that we already have these resources:

	fe700000-fe7fffff : PCI Bus 0000:01
	fe800000-fe8fffff : PCI Bus 0000:02
	fe900000-fe9fffff : PCI Bus 0000:03
	fea00000-feafffff : PCI Bus 0000:04
	feb00000-febfffff : PCI Bus 0000:05

in the resource tree, and that in turn means that when we try to allocate 
the bogus MCFG resource, it fails.

Which is good - it mustn't succeed.

What _broke_ for you is that the horrible patch that got reverted said 
that "if we recognize this as an MCFG resource, we will _always_ try to 
insert it", so it fundamentally broke the whole resource tree, because it 
force-inserted that totally crap resource.

Now, the thing that worries me a bit is that I wonder how common this kind 
of crap is. And in particular, I wonder how often we've been saved from 
horrible issues like this by the fact that we've inserted the e820 
resources first. Of course - it can work both ways - sometimes it saves 
us, and sometimes it just causes more problems (eg when we then 
re-allocate the resource successfully somewhere else).

		Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 10:39 AM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

>
> What _broke_ for you is that the horrible patch that got reverted said
> that "if we recognize this as an MCFG resource, we will _always_ try to
> insert it", so it fundamentally broke the whole resource tree, because it
> force-inserted that totally crap resource.

again, should use MCFG end as the res _end

YH

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> again, should use MCFG end as the res _end

No. Again - we shouldn't DO that insane crap.

We simply shouldn't try to compare the BAR start with randomly chosen 
things.

So the crap got reverted, and it's not going to get done again. Get over 
it.


			Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 11:43 AM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> again, should use MCFG end as the res _end
>
> No. Again - we shouldn't DO that insane crap.
>
> We simply shouldn't try to compare the BAR start with randomly chosen
> things.

do you agree to use quirk to make the BAR res to have correct end
between pci_probe and pci_resource_survey?

YH

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
> 
> do you agree to use quirk to make the BAR res to have correct end
> between pci_probe and pci_resource_survey?

In general I would agree, but now that I've looked at it a bit more, I 
actually don't think it's a bug in the chipset any more. See my previous 
email that crossed with yours.

I suspect that that northbridge resource is basically acting as a bridge 
resource. So 0xe0000000 - 0xffffffff is actually _correct_. And MCFG being 
in that window (and being first in it) is just a detail.

Look at the resource allocations on Rafael's machine: there are two 
different classes:

 - outside that BAR3 window:

   The "external gfx0 port A" decode (bridged by device 0000:02.0):

	d8000000-dfffffff : PCI Bus 0000:01
	  d8000000-dfffffff : 0000:01:00.0
	    d8000000-d8ffffff : vesafb

   and suspect the graphics port is special (considering that this is an 
   ATI chipset)

 - inside that BAR3 window: everything else (PCI express):

	e0000000-efffffff : PCI MMCONFIG 0
	fe6f4000-fe6f7fff : 0000:00:14.2
	  fe6f4000-fe6f7fff : ICH HD audio
	fe6fa000-fe6fafff : 0000:00:13.4
	  fe6fa000-fe6fafff : ohci_hcd
	fe6fb000-fe6fbfff : 0000:00:13.3
	  fe6fb000-fe6fbfff : ohci_hcd
	fe6fc000-fe6fcfff : 0000:00:13.2
	  fe6fc000-fe6fcfff : ohci_hcd
	fe6fd000-fe6fdfff : 0000:00:13.1
	  fe6fd000-fe6fdfff : ohci_hcd
	fe6fe000-fe6fefff : 0000:00:13.0
	  fe6fe000-fe6fefff : ohci_hcd
	fe6ff000-fe6ff0ff : 0000:00:13.5
	  fe6ff000-fe6ff0ff : ehci_hcd
	fe6ff800-fe6ffbff : 0000:00:12.0
	  fe6ff800-fe6ffbff : ahci
	fe700000-fe7fffff : PCI Bus 0000:01
	  fe7c0000-fe7dffff : 0000:01:00.0
	  fe7e0000-fe7effff : 0000:01:00.1
	  fe7f0000-fe7fffff : 0000:01:00.0
	fe800000-fe8fffff : PCI Bus 0000:02
	  fe8ffc00-fe8fffff : 0000:02:00.0
	    fe8ffc00-fe8fffff : ahci
	fe900000-fe9fffff : PCI Bus 0000:03
	  fe9c0000-fe9dffff : 0000:03:00.0
	  fe9fc000-fe9fffff : 0000:03:00.0
	    fe9fc000-fe9fffff : sky2
	fea00000-feafffff : PCI Bus 0000:04
	  feaffc00-feafffff : 0000:04:00.0
	    feaffc00-feafffff : ahci
	feb00000-febfffff : PCI Bus 0000:05
	  febff000-febfffff : 0000:05:08.0
	    febff000-febff7ff : ohci1394
	fec00000-fec00fff : IOAPIC 0
	fed00000-fed003ff : HPET 2
	fee00000-fee00fff : Local APIC
	fff00000-ffffffff : reserved

Hmm? 

(yeah, some of those resources are _really_ special, and are inside the 
CPU itself, eg the APIC and possibly HPET, and never necessarily even make 
it to the host bridge at all because they get decoded early).

			Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 12:31 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> do you agree to use quirk to make the BAR res to have correct end
>> between pci_probe and pci_resource_survey?
>
> In general I would agree, but now that I've looked at it a bit more, I
> actually don't think it's a bug in the chipset any more. See my previous
> email that crossed with yours.
>
> I suspect that that northbridge resource is basically acting as a bridge
> resource. So 0xe0000000 - 0xffffffff is actually _correct_. And MCFG being
> in that window (and being first in it) is just a detail.
>
> Look at the resource allocations on Rafael's machine: there are two
> different classes:
>
>  - outside that BAR3 window:
>
>   The "external gfx0 port A" decode (bridged by device 0000:02.0):
>
>        d8000000-dfffffff : PCI Bus 0000:01
>          d8000000-dfffffff : 0000:01:00.0
>            d8000000-d8ffffff : vesafb
>
>   and suspect the graphics port is special (considering that this is an
>   ATI chipset)
>
>  - inside that BAR3 window: everything else (PCI express):
>
>        e0000000-efffffff : PCI MMCONFIG 0
>        fe6f4000-fe6f7fff : 0000:00:14.2
>          fe6f4000-fe6f7fff : ICH HD audio
>        fe6fa000-fe6fafff : 0000:00:13.4
>          fe6fa000-fe6fafff : ohci_hcd
>        fe6fb000-fe6fbfff : 0000:00:13.3
>          fe6fb000-fe6fbfff : ohci_hcd
>        fe6fc000-fe6fcfff : 0000:00:13.2
>          fe6fc000-fe6fcfff : ohci_hcd
>        fe6fd000-fe6fdfff : 0000:00:13.1
>          fe6fd000-fe6fdfff : ohci_hcd
>        fe6fe000-fe6fefff : 0000:00:13.0
>          fe6fe000-fe6fefff : ohci_hcd
>        fe6ff000-fe6ff0ff : 0000:00:13.5
>          fe6ff000-fe6ff0ff : ehci_hcd
>        fe6ff800-fe6ffbff : 0000:00:12.0
>          fe6ff800-fe6ffbff : ahci
>        fe700000-fe7fffff : PCI Bus 0000:01
>          fe7c0000-fe7dffff : 0000:01:00.0
>          fe7e0000-fe7effff : 0000:01:00.1
>          fe7f0000-fe7fffff : 0000:01:00.0
>        fe800000-fe8fffff : PCI Bus 0000:02
>          fe8ffc00-fe8fffff : 0000:02:00.0
>            fe8ffc00-fe8fffff : ahci
>        fe900000-fe9fffff : PCI Bus 0000:03
>          fe9c0000-fe9dffff : 0000:03:00.0
>          fe9fc000-fe9fffff : 0000:03:00.0
>            fe9fc000-fe9fffff : sky2
>        fea00000-feafffff : PCI Bus 0000:04
>          feaffc00-feafffff : 0000:04:00.0
>            feaffc00-feafffff : ahci
>        feb00000-febfffff : PCI Bus 0000:05
>          febff000-febfffff : 0000:05:08.0
>            febff000-febff7ff : ohci1394
>        fec00000-fec00fff : IOAPIC 0
>        fed00000-fed003ff : HPET 2
>        fee00000-fee00fff : Local APIC
>        fff00000-ffffffff : reserved
>
> Hmm?
>
> (yeah, some of those resources are _really_ special, and are inside the
> CPU itself, eg the APIC and possibly HPET, and never necessarily even make
> it to the host bridge at all because they get decoded early).

wonder:
in old kernel, after BAR3 request_filed, pci_assigned_unassigned
should get update resource for that... but it could find that big
space for it.

that is interesting...

YH

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

[Yinghai Lu]

please check

[PATCH] x86: split e820 reserved entries record to late v4
[PATCH] x86: split e820 reserved entries record to late v4 - fix v6

YH

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Yinghai Lu wrote:
> please check
> 
> [PATCH] x86: split e820 reserved entries record to late v4
> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6

What kernel should I apply those to and in what order?

Rafael

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> please check
>>
>> [PATCH] x86: split e820 reserved entries record to late v4
>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>
> What kernel should I apply those to and in what order?

linus git tree
1. [PATCH] x86: split e820 reserved entries record to late v4
2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6

tip/master
1. Resource handling: add 'insert_resource_expand_to_fit()' function
2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: insert_resource_expand_to_fit.patch --]
[-- Type: text/x-patch; name=insert_resource_expand_to_fit.patch, Size: 5015 bytes --]

commit bef69ea0dcce574a425feb0a5aa4c63dd108b9a6
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Aug 29 20:18:31 2008 -0700

    Resource handling: add 'insert_resource_expand_to_fit()' function
    
    Not used anywhere yet, but this complements the existing plain
    'insert_resource()' functionality with a version that can expand the
    resource we are adding in order to fix up any conflicts it has with
    existing resources.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 22d2115..8d3b7a9 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -109,6 +109,7 @@ extern struct resource iomem_resource;
 extern int request_resource(struct resource *root, struct resource *new);
 extern int release_resource(struct resource *new);
 extern int insert_resource(struct resource *parent, struct resource *new);
+extern void insert_resource_expand_to_fit(struct resource *root, struct resource *new);
 extern int allocate_resource(struct resource *root, struct resource *new,
 			     resource_size_t size, resource_size_t min,
 			     resource_size_t max, resource_size_t align,
diff --git a/kernel/resource.c b/kernel/resource.c
index f5b518e..cf0a178 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -362,35 +362,21 @@ int allocate_resource(struct resource *root, struct resource *new,
 
 EXPORT_SYMBOL(allocate_resource);
 
-/**
- * insert_resource - Inserts a resource in the resource tree
- * @parent: parent of the new resource
- * @new: new resource to insert
- *
- * Returns 0 on success, -EBUSY if the resource can't be inserted.
- *
- * This function is equivalent to request_resource when no conflict
- * happens. If a conflict happens, and the conflicting resources
- * entirely fit within the range of the new resource, then the new
- * resource is inserted and the conflicting resources become children of
- * the new resource.
+/*
+ * Insert a resource into the resource tree. If successful, return NULL,
+ * otherwise return the conflicting resource (compare to __request_resource())
  */
-int insert_resource(struct resource *parent, struct resource *new)
+static struct resource * __insert_resource(struct resource *parent, struct resource *new)
 {
-	int result;
 	struct resource *first, *next;
 
-	write_lock(&resource_lock);
-
 	for (;; parent = first) {
-	 	result = 0;
 		first = __request_resource(parent, new);
 		if (!first)
-			goto out;
+			return first;
 
-		result = -EBUSY;
 		if (first == parent)
-			goto out;
+			return first;
 
 		if ((first->start > new->start) || (first->end < new->end))
 			break;
@@ -401,15 +387,13 @@ int insert_resource(struct resource *parent, struct resource *new)
 	for (next = first; ; next = next->sibling) {
 		/* Partial overlap? Bad, and unfixable */
 		if (next->start < new->start || next->end > new->end)
-			goto out;
+			return next;
 		if (!next->sibling)
 			break;
 		if (next->sibling->start > new->end)
 			break;
 	}
 
-	result = 0;
-
 	new->parent = parent;
 	new->sibling = next->sibling;
 	new->child = first;
@@ -426,10 +410,64 @@ int insert_resource(struct resource *parent, struct resource *new)
 			next = next->sibling;
 		next->sibling = new;
 	}
+	return NULL;
+}
 
- out:
+/**
+ * insert_resource - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ *
+ * This function is equivalent to request_resource when no conflict
+ * happens. If a conflict happens, and the conflicting resources
+ * entirely fit within the range of the new resource, then the new
+ * resource is inserted and the conflicting resources become children of
+ * the new resource.
+ */
+int insert_resource(struct resource *parent, struct resource *new)
+{
+	struct resource *conflict;
+
+	write_lock(&resource_lock);
+	conflict = __insert_resource(parent, new);
+	write_unlock(&resource_lock);
+	return conflict ? -EBUSY : 0;
+}
+
+/**
+ * insert_resource_expand_to_fit - Insert a resource into the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Insert a resource into the resource tree, possibly expanding it in order
+ * to make it encompass any conflicting resources.
+ */
+void insert_resource_expand_to_fit(struct resource *root, struct resource *new)
+{
+	if (new->parent)
+		return;
+
+	write_lock(&resource_lock);
+	for (;;) {
+		struct resource *conflict;
+
+		conflict = __insert_resource(root, new);
+		if (!conflict)
+			break;
+		if (conflict == root)
+			break;
+
+		/* Ok, expand resource to cover the conflict, then try again .. */
+		if (conflict->start < new->start)
+			new->start = conflict->start;
+		if (conflict->end > new->end)
+			new->end = conflict->end;
+
+		printk("Expanded resource %s due to conflict with %s\n", new->name, conflict->name);
+	}
 	write_unlock(&resource_lock);
-	return result;
 }
 
 /**

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>>> please check
>>>
>>> [PATCH] x86: split e820 reserved entries record to late v4
>>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>>
>> What kernel should I apply those to and in what order?
>
> linus git tree
> 1. [PATCH] x86: split e820 reserved entries record to late v4
> 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>
> tip/master
> 1. Resource handling: add 'insert_resource_expand_to_fit()' function
> 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6

actually it is almost the same to tar ball send you for your system...

YH

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >>> please check
> >>>
> >>> [PATCH] x86: split e820 reserved entries record to late v4
> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >>
> >> What kernel should I apply those to and in what order?
> >
> > linus git tree
> > 1. [PATCH] x86: split e820 reserved entries record to late v4
> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >
> > tip/master
> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> 
> actually it is almost the same to tar ball send you for your system...

I've just tested these two patches on top of the current Linus' tree and the
system works normally.

Thanks,
Rafael

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> >>> please check
>> >>>
>> >>> [PATCH] x86: split e820 reserved entries record to late v4
>> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >>
>> >> What kernel should I apply those to and in what order?
>> >
>> > linus git tree
>> > 1. [PATCH] x86: split e820 reserved entries record to late v4
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >
>> > tip/master
>> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>>
>> actually it is almost the same to tar ball send you for your system...
>
> I've just tested these two patches on top of the current Linus' tree and the
> system works normally.

thanks,

David, can you test those two patches on top of linus tree?

YH

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> >>> please check
>> >>>
>> >>> [PATCH] x86: split e820 reserved entries record to late v4
>> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >>
>> >> What kernel should I apply those to and in what order?
>> >
>> > linus git tree
>> > 1. [PATCH] x86: split e820 reserved entries record to late v4
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >
>> > tip/master
>> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>>
>> actually it is almost the same to tar ball send you for your system...
>
> I've just tested these two patches on top of the current Linus' tree and the
> system works normally.
>

Can you try attached in addition to those to patches ?

want to check if the BAR3 get new resource..., and after that what
could happen...

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: assign_resource_for_bar_in_host_bridge.patch --]
[-- Type: text/x-patch; name=assign_resource_for_bar_in_host_bridge.patch, Size: 640 bytes --]

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 82634a2..4e0df0a 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -38,9 +38,8 @@ static void pbus_assign_resources_sorted(struct pci_bus *bus)
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		u16 class = dev->class >> 8;
 
-		/* Don't touch classless devices or host bridges or ioapics.  */
-		if (class == PCI_CLASS_NOT_DEFINED ||
-		    class == PCI_CLASS_BRIDGE_HOST)
+		/* Don't touch classless devices or ioapics.  */
+		if (class == PCI_CLASS_NOT_DEFINED)
 			continue;
 
 		/* Don't touch ioapic devices already enabled by firmware */

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

[Rafael J. Wysocki]

On Sunday, 31 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >> >>> please check
> >> >>>
> >> >>> [PATCH] x86: split e820 reserved entries record to late v4
> >> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >> >>
> >> >> What kernel should I apply those to and in what order?
> >> >
> >> > linus git tree
> >> > 1. [PATCH] x86: split e820 reserved entries record to late v4
> >> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >> >
> >> > tip/master
> >> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
> >> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >>
> >> actually it is almost the same to tar ball send you for your system...
> >
> > I've just tested these two patches on top of the current Linus' tree and the
> > system works normally.
> >
> 
> Can you try attached in addition to those to patches ?
> 
> want to check if the BAR3 get new resource..., and after that what
> could happen...

Works, dmesg is at:
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log

Please let me know if you want it with any more command line options.

Thanks,
Rafael

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

[Linus Torvalds]

On Sun, 31 Aug 2008, Rafael J. Wysocki wrote:
> 
> Works, dmesg is at:
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log

That BAR is indeed "locked". Now that we try to reallocate it, you get 
this in the log:

	pci 0000:00:00.0: BAR 3: error updating (0x40000004 != 0xe0000004)
	pci 0000:00:00.0: BAR 3: error updating (high 0x000001 != 0x000000)

ie now the code _tried_ to update the BAR to point to 0x1_4000_0000 
instead, but the hardware refused, and it is still at 0x0_e000_0000.

So Yinghai's patch "worked", but it worked by doing nothing.

See my earlier guess about locked read-only resources a few emails back. 
IOW, I'm not at all surprised. I really do suspect that that BAR is some 
very special "this is the HT->PCIE region" BAR.

			Linus

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

[Yinghai Lu]

On Sun, Aug 31, 2008 at 10:42 AM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sun, 31 Aug 2008, Rafael J. Wysocki wrote:
>>
>> Works, dmesg is at:
>> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log
>
> That BAR is indeed "locked". Now that we try to reallocate it, you get
> this in the log:
>
>        pci 0000:00:00.0: BAR 3: error updating (0x40000004 != 0xe0000004)
>        pci 0000:00:00.0: BAR 3: error updating (high 0x000001 != 0x000000)
>
> ie now the code _tried_ to update the BAR to point to 0x1_4000_0000
> instead, but the hardware refused, and it is still at 0x0_e000_0000.
>
> So Yinghai's patch "worked", but it worked by doing nothing.
>
> See my earlier guess about locked read-only resources a few emails back.
> IOW, I'm not at all surprised. I really do suspect that that BAR is some
> very special "this is the HT->PCIE region" BAR.

so the code could allocate the 64 bit resource above 4g,...

wonder how the probe could find out the size of is 1fff_ffff..

YH

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

[Linus Torvalds]

On Sun, 31 Aug 2008, Yinghai Lu wrote:
> 
> wonder how the probe could find out the size of is 1fff_ffff..

Heh. That's how PCI sizing works: you write all ones to the register, and 
read back the result. The low bits won't change, and that indicates the 
size.

But if _none_ of the bits change, then that simply means that the size 
will be calculated to be 0xffffffff-start.

So the sizing will "work", it will just always report that the BAR covers 
everything from start to the 4G limit.

		Linus

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

On Sun, Aug 31, 2008 at 11:03 AM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sun, 31 Aug 2008, Yinghai Lu wrote:
>>
>> wonder how the probe could find out the size of is 1fff_ffff..
>
> Heh. That's how PCI sizing works: you write all ones to the register, and
> read back the result. The low bits won't change, and that indicates the
> size.
>
> But if _none_ of the bits change, then that simply means that the size
> will be calculated to be 0xffffffff-start.
>
> So the sizing will "work", it will just always report that the BAR covers
> everything from start to the 4G limit.

how about


diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cce2f4c..3b5269a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -240,6 +240,11 @@ static int __pci_read_base(struct pci_dev *dev,
enum pci_bar_type type,
        pci_read_config_dword(dev, pos, &l);
        pci_write_config_dword(dev, pos, mask);
        pci_read_config_dword(dev, pos, &sz);
+
+       /* sticky and non changable */
+       if (sz == l)
+               goto fail;
+
        pci_write_config_dword(dev, pos, l);

        /*


Rafael,

can you check attach one  to see if we still have warning ?

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sticky_bar.patch --]
[-- Type: text/x-patch; name=sticky_bar.patch, Size: 463 bytes --]

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cce2f4c..3b5269a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -240,6 +240,11 @@ static int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
 	pci_read_config_dword(dev, pos, &l);
 	pci_write_config_dword(dev, pos, mask);
 	pci_read_config_dword(dev, pos, &sz);
+
+	/* sticky and non changable */
+	if (sz == l)
+		goto fail;
+
 	pci_write_config_dword(dev, pos, l);
 
 	/*

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

[Linus Torvalds]

On Sun, 31 Aug 2008, Yinghai Lu wrote:
> 
> how about
> 
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index cce2f4c..3b5269a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -240,6 +240,11 @@ static int __pci_read_base(struct pci_dev *dev,
> enum pci_bar_type type,
>         pci_read_config_dword(dev, pos, &l);
>         pci_write_config_dword(dev, pos, mask);
>         pci_read_config_dword(dev, pos, &sz);
> +
> +       /* sticky and non changable */
> +       if (sz == l)
> +               goto fail;

No, because a resource really _can_ be at the end. It's perfectly ok to 
have something like a memory resource at 0xff000000-0xffffffff, and then 
the BAR register would always read 0xff000000 (or 0x...4 for a 64-bit 
resource).

So calling that a failure case would be wrong.

		Linus

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
> 
> in old kernel, after BAR3 request_filed, pci_assigned_unassigned
> should get update resource for that... but it could find that big
> space for it.

Exactly. So what happens is that it doesn't actually re-allocate it at 
all. Not that it is necessarily even possible - it's quite possible that 
that field is effectively locked some way and is read-only. Without 
knowing the chipset details, we can only guess.

		Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 3:41 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> in old kernel, after BAR3 request_filed, pci_assigned_unassigned
>> should get update resource for that... but it could find that big
>> space for it.

wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
it request_resource fails...

>
> Exactly. So what happens is that it doesn't actually re-allocate it at
> all. Not that it is necessarily even possible - it's quite possible that
> that field is effectively locked some way and is read-only. Without
> knowing the chipset details, we can only guess.

not touch it at this time...

except Jordan could find some clue with the DOC.

YH

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
> 
> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
> it request_resource fails...

I don't think we've ever done new allocations in 64 bits. Although looking 
for it, I have to admit that I don't see what would limit us right now. 
There used to be some paths that weren't 64-bit clean, but I think we 
fixed all of those.

		Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
>> it request_resource fails...
>
> I don't think we've ever done new allocations in 64 bits. Although looking
> for it, I have to admit that I don't see what would limit us right now.
> There used to be some paths that weren't 64-bit clean, but I think we
> fixed all of those.

would be some corner case...

didn't see anything there.

calling  pcibios_assign_resources+0x0/0x90
request_resource: root: (PCI Bus 0000:01) [fe700000, fe7fffff], new:
(0000:01:00.0) [fe7c0000, fe7dffff] conflict 0
request_resource: root: (PCI Bus 0000:03) [fe900000, fe9fffff], new:
(0000:03:00.0) [fe9c0000, fe9dffff] conflict 0
pci 0000:00:02.0: PCI bridge, secondary bus 0000:01
pci 0000:00:02.0:   IO window: 0x9000-0x9fff
pci 0000:00:02.0:   MEM window: 0xfe700000-0xfe7fffff
pci 0000:00:02.0:   PREFETCH window: 0x000000d8000000-0x000000dfffffff
pci 0000:00:04.0: PCI bridge, secondary bus 0000:02
pci 0000:00:04.0:   IO window: 0xa000-0xbfff
pci 0000:00:04.0:   MEM window: 0xfe800000-0xfe8fffff
pci 0000:00:04.0:   PREFETCH window: disabled
pci 0000:00:06.0: PCI bridge, secondary bus 0000:03
pci 0000:00:06.0:   IO window: 0xc000-0xcfff
pci 0000:00:06.0:   MEM window: 0xfe900000-0xfe9fffff
pci 0000:00:06.0:   PREFETCH window: disabled
pci 0000:00:07.0: PCI bridge, secondary bus 0000:04
pci 0000:00:07.0:   IO window: 0xd000-0xefff
pci 0000:00:07.0:   MEM window: 0xfea00000-0xfeafffff
pci 0000:00:07.0:   PREFETCH window: disabled
pci 0000:00:14.4: PCI bridge, secondary bus 0000:05
pci 0000:00:14.4:   IO window: disabled
pci 0000:00:14.4:   MEM window: 0xfeb00000-0xfebfffff
pci 0000:00:14.4:   PREFETCH window: disabled
pci 0000:00:02.0: setting latency timer to 64
pci 0000:00:04.0: setting latency timer to 64
pci 0000:00:06.0: setting latency timer to 64
pci 0000:00:07.0: setting latency timer to 64

YH

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 4:39 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>
>>
>> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>>
>>> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
>>> it request_resource fails...
>>
>> I don't think we've ever done new allocations in 64 bits. Although looking
>> for it, I have to admit that I don't see what would limit us right now.
>> There used to be some paths that weren't 64-bit clean, but I think we
>> fixed all of those.
>
> would be some corner case...
>

pci_assign_unassigned_resources==>pci_bus_assign_resources==>pbus_assign_resources_sorted(struct

static void pbus_assign_resources_sorted(struct pci_bus *bus)
{
        struct pci_dev *dev;
        struct resource *res;
        struct resource_list head, *list, *tmp;
        int idx;

        head.next = NULL;
        list_for_each_entry(dev, &bus->devices, bus_list) {
                u16 class = dev->class >> 8;

                /* Don't touch classless devices or host bridges or ioapics.  */
                if (class == PCI_CLASS_NOT_DEFINED ||
                    class == PCI_CLASS_BRIDGE_HOST)
                        continue;


it skips the host bridge...

YH

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 5:27 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Aug 30, 2008 at 4:39 PM, Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
>> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>>>
>>>
>>> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>>>
>>>> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
>>>> it request_resource fails...
>>>
>>> I don't think we've ever done new allocations in 64 bits. Although looking
>>> for it, I have to admit that I don't see what would limit us right now.
>>> There used to be some paths that weren't 64-bit clean, but I think we
>>> fixed all of those.
>>
>> would be some corner case...
>>
>
> pci_assign_unassigned_resources==>pci_bus_assign_resources==>pbus_assign_resources_sorted(struct
>
> static void pbus_assign_resources_sorted(struct pci_bus *bus)
> {
>        struct pci_dev *dev;
>        struct resource *res;
>        struct resource_list head, *list, *tmp;
>        int idx;
>
>        head.next = NULL;
>        list_for_each_entry(dev, &bus->devices, bus_list) {
>                u16 class = dev->class >> 8;
>
>                /* Don't touch classless devices or host bridges or ioapics.  */
>                if (class == PCI_CLASS_NOT_DEFINED ||
>                    class == PCI_CLASS_BRIDGE_HOST)
>                        continue;
>
>
> it skips the host bridge...

what's story for not touching host bridges?

YH

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
> >
> >                /* Don't touch classless devices or host bridges or ioapics.  */
> >                if (class == PCI_CLASS_NOT_DEFINED ||
> >                    class == PCI_CLASS_BRIDGE_HOST)
> >                        continue;
> >
> >
> > it skips the host bridge...
> 
> what's story for not touching host bridges?

Ahh. Exactly because of things like this. The hist bridge BAR's are often 
special.

That code comes from almost four years ago, the commit message was:

  Author: Maciej W. Rozycki <macro-8NJIiSa5LzA@public.gmane.org>
  Date:   Thu Dec 16 21:44:31 2004 -0800

    [PATCH] PCI: Don't touch BARs of host bridges
    
     BARs of host bridges often have special meaning and AFAIK are best left
    to be setup by the firmware or system-specific startup code and kept
    intact by the generic resource handler.  For example a couple of host
    bridges used for MIPS processors interpret BARs as target-mode decoders
    for accessing host memory by PCI masters (which is quite reasonable).
    For them it's desirable to keep their decoded address range overlapping
    with the host RAM for simplicity if nothing else (I can imagine running
    out of address space with lots of memory and 32-bit PCI with no DAC
    support in the participating devices).
    
     This is already the case with the i386 and ppc platform-specific PCI
    resource allocators.  Please consider the following change for the generic
    allocator.  Currently we have a pile of hacks implemented for host bridges
    to be left untouched and I'd be pleased to remove them.
    
    From: "Maciej W. Rozycki" <macro-8NJIiSa5LzA@public.gmane.org>
    Signed-off-by: Greg Kroah-Hartman <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>

and we've had other things where host bridges are special (ie iirc, if you 
turn off PCI_COMMAND_MEM from a host bridge, it stops access to real RAM 
from the CPU for some bridges - so you must never turn those things off or 
you get a dead system).

(But at least Intel host bridges will just ignore writes to the CMD 
register, I think - you cannot turn MEM off).

			Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 8:00 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>> >
>> >                /* Don't touch classless devices or host bridges or ioapics.  */
>> >                if (class == PCI_CLASS_NOT_DEFINED ||
>> >                    class == PCI_CLASS_BRIDGE_HOST)
>> >                        continue;
>> >
>> >
>> > it skips the host bridge...
>>
>> what's story for not touching host bridges?
>
> Ahh. Exactly because of things like this. The hist bridge BAR's are often
> special.
>
> That code comes from almost four years ago, the commit message was:
>
>  Author: Maciej W. Rozycki <macro-8NJIiSa5LzA@public.gmane.org>
>  Date:   Thu Dec 16 21:44:31 2004 -0800
>
>    [PATCH] PCI: Don't touch BARs of host bridges
>
>     BARs of host bridges often have special meaning and AFAIK are best left
>    to be setup by the firmware or system-specific startup code and kept
>    intact by the generic resource handler.  For example a couple of host
>    bridges used for MIPS processors interpret BARs as target-mode decoders
>    for accessing host memory by PCI masters (which is quite reasonable).
>    For them it's desirable to keep their decoded address range overlapping
>    with the host RAM for simplicity if nothing else (I can imagine running
>    out of address space with lots of memory and 32-bit PCI with no DAC
>    support in the participating devices).
>
>     This is already the case with the i386 and ppc platform-specific PCI
>    resource allocators.  Please consider the following change for the generic
>    allocator.  Currently we have a pile of hacks implemented for host bridges
>    to be left untouched and I'd be pleased to remove them.
>
>    From: "Maciej W. Rozycki" <macro-8NJIiSa5LzA@public.gmane.org>
>    Signed-off-by: Greg Kroah-Hartman <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
>
> and we've had other things where host bridges are special (ie iirc, if you
> turn off PCI_COMMAND_MEM from a host bridge, it stops access to real RAM
> from the CPU for some bridges - so you must never turn those things off or
> you get a dead system).
>
> (But at least Intel host bridges will just ignore writes to the CMD
> register, I think - you cannot turn MEM off).

then
1. we should not probe them in probe.c
2. at least we should not try to request_resource for them in
pcibios_resource_survey...

just pretend that they are not existing.

YH

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> then
> 1. we should not probe them in probe.c
> 2. at least we should not try to request_resource for them in
> pcibios_resource_survey...
> 
> just pretend that they are not existing.

You are missing the fact that we need to know where existing resources 
are, even if we can't do anything about them!

Read my explanation from yesterday about why we need to add the e820 
resources to the resource map in the first place.

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.

			Linus

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

[Linus Torvalds]

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

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Linus Torvalds wrote:
> 
> We simply shouldn't try to compare the BAR start with randomly chosen 
> things.

Btw, looking at that bogus BAR#3 some more: I don't actually think it's 
even an MCFG resource.

I think it's literally the resource that describes the HT window for the 
host bridge. So it's literally like the "root" resource - all external 
MMIO resources that go over HT have to be in that window.

IOW, I'm starting to think that it's not even broken. It is probably 
perfectly real. It's not a "PCI bridge" in the sense that it doesn't 
bridge one PCI bus to another, but it's a host bridge, and it bridges the 
CPU memory accesses to another bus. 

The fact that the MCFG area happens to be at the start of that window is 
probably just a random detail.

Does anybody know how to find chipset docs for AMD/ATI chipsets? I find 
CPU docs, and the GPU docs, but not the 790 chipset docs anywhere (yeah, 
it looks promising with a link that says "AMD 790FX Chipset 
Specifications", but the link just takes you to some trivial overview, not 
any actual specs.

Anybody?

			Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 12:14 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Linus Torvalds wrote:
>>
>> We simply shouldn't try to compare the BAR start with randomly chosen
>> things.
>
> Btw, looking at that bogus BAR#3 some more: I don't actually think it's
> even an MCFG resource.
>
> I think it's literally the resource that describes the HT window for the
> host bridge. So it's literally like the "root" resource - all external
> MMIO resources that go over HT have to be in that window.

his system only has one HT chain...

>
> IOW, I'm starting to think that it's not even broken. It is probably
> perfectly real. It's not a "PCI bridge" in the sense that it doesn't
> bridge one PCI bus to another, but it's a host bridge, and it bridges the
> CPU memory accesses to another bus.
>
> The fact that the MCFG area happens to be at the start of that window is
> probably just a random detail.

AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
 the ATI bridge BAR that have same address for MMCONFIG not even have
chance to decode that.
because NB intercept that already.

>
> Does anybody know how to find chipset docs for AMD/ATI chipsets? I find
> CPU docs, and the GPU docs, but not the 790 chipset docs anywhere (yeah,
> it looks promising with a link that says "AMD 790FX Chipset
> Specifications", but the link just takes you to some trivial overview, not
> any actual specs.

it seems ATI chipset doesn't have public version of doc...like reg
info and BIOS/Kernel porting guide.

YH

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

[Linus Torvalds]

On Sat, 30 Aug 2008, Yinghai Lu wrote:
> 
> AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
>  the ATI bridge BAR that have same address for MMCONFIG not even have
> chance to decode that, because NB intercept that already.

Ok, so it's similar to the local APIC in that respect (and presumably IO 
APIC too, I haven't checked).

But that still just implies that the BAR probably means something else 
totally, and the fact that it happens to have the same value as the MCFG 
is just random luck.

> it seems ATI chipset doesn't have public version of doc...like reg
> info and BIOS/Kernel porting guide.

Yeah, I'm not finding anything either. The 690G databook that Rafael 
pointed to does mention the config registers in passing, but it's really 
just about electricals (pin setup etc). No BIOS writers guide indeed..

			Linus

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 12:41 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
>>  the ATI bridge BAR that have same address for MMCONFIG not even have
>> chance to decode that, because NB intercept that already.
>
> Ok, so it's similar to the local APIC in that respect (and presumably IO
> APIC too, I haven't checked).
>
> But that still just implies that the BAR probably means something else
> totally, and the fact that it happens to have the same value as the MCFG
> is just random luck.
>
>> it seems ATI chipset doesn't have public version of doc...like reg
>> info and BIOS/Kernel porting guide.
>
> Yeah, I'm not finding anything either. The 690G databook that Rafael
> pointed to does mention the config registers in passing, but it's really
> just about electricals (pin setup etc). No BIOS writers guide indeed..

Those BIOS porting guide need extra NDA...
they don't want to everyone know that there is lots workaround for
their silicon bugs.

YH

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Linus Torvalds wrote:
> 
> On Sat, 30 Aug 2008, Linus Torvalds wrote:
> > 
> > We simply shouldn't try to compare the BAR start with randomly chosen 
> > things.
> 
> Btw, looking at that bogus BAR#3 some more: I don't actually think it's 
> even an MCFG resource.
> 
> I think it's literally the resource that describes the HT window for the 
> host bridge. So it's literally like the "root" resource - all external 
> MMIO resources that go over HT have to be in that window.
> 
> IOW, I'm starting to think that it's not even broken. It is probably 
> perfectly real. It's not a "PCI bridge" in the sense that it doesn't 
> bridge one PCI bus to another, but it's a host bridge, and it bridges the 
> CPU memory accesses to another bus. 
> 
> The fact that the MCFG area happens to be at the start of that window is 
> probably just a random detail.
> 
> Does anybody know how to find chipset docs for AMD/ATI chipsets? I find 
> CPU docs, and the GPU docs, but not the 790 chipset docs anywhere (yeah, 
> it looks promising with a link that says "AMD 790FX Chipset 
> Specifications", but the link just takes you to some trivial overview, not 
> any actual specs.
> 
> Anybody?

There are some at:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_15137,00.html

Well, that's 690/SB600 only and I'm not sure how useful this is.

Thanks,
Rafael

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 12:29 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

>
> There are some at:
> http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_15137,00.html
>
> Well, that's 690/SB600 only and I'm not sure how useful this is.
>
that is for HW guys.

YH

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Linus Torvalds wrote:
> 
> On Sat, 30 Aug 2008, Rafael J. Wysocki wrote:
> > 
> > > And if you have the whole dmesg, that would be useful.
> > 
> > dmesg from -rc5 with the offending commit reverted and with the patch
> > below applied is at:
> > 
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log
> 
> Ok, the more I look at this, the more interesting it gets.
> 
> In particular, this:
> 
> 	...
> 	ACPI: bus type pnp registered
> 	pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> 	pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> 	pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> 	pnp 00:09: mem resource (0xfff00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> 	pnp 00:0b: mem resource (0xe0000000-0xefffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> 	pnp 00:0c: mem resource (0xfec00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> 	pnp: PnP ACPI: found 13 devices
> 	ACPI: ACPI bus type pnp unregistered
> 	SCSI subsystem initialized
> 	libata version 3.00 loaded.
> 	usbcore: registered new interface driver usbfs
> 	usbcore: registered new interface driver hub
> 	usbcore: registered new device driver usb
> 	PCI: Using ACPI for IRQ routing
> 	pci 0000:00:00.0: BAR 3: can't allocate resource
> 	...
> 
> there's a few things to note here:
> 
>  - the resource at 0000:00:00.0 BAR 3 is totally bogus.
> 
>    We know it's totally bogus because you actually have other resources in 
>    the 0xf....... range, and they work fine. It's also likely to be 
>    totally bogus because it so happens that the end-point of 0xffffffff is 
>    commonly something that the BIOS leaves as a "I sized this resource", 
>    because that's how resources are sized (you write all ones into them 
>    and look what you can read back).
> 
>    But your lspci -vxx output clearly shows that (a) MEM is enabled in 
>    the command word, and yes, the BAR register at 0x18 does indeed have 
>    value 0xe0000000. So it's just the length that is really bogus.
> 
>  - pnp clearly sees that bogus resource at 0xe0000000-0xffffffff
> 
>  - BUT: the "can't allocate resource" thing is from 
>    pcibios_allocate_resources(), and means that the request_resource() 
>    failed _despite_ the fact that you hadn't reserved the e820 resources 
>    yet with the new patch.
> 
> The thing that seems to save you is that we've already allocated something 
> in that region. There's a few things there, like:
> 
> 	fee00000-fee00fff : Local APIC
> 
> but that particular one is actually reserved much later, so that doesn't 
> explain it. I think that what happens is that we have allocated the _bus_ 
> resources earlier in "pcibios_allocate_bus_resources()", and that means 
> that we already have these resources:
> 
> 	fe700000-fe7fffff : PCI Bus 0000:01
> 	fe800000-fe8fffff : PCI Bus 0000:02
> 	fe900000-fe9fffff : PCI Bus 0000:03
> 	fea00000-feafffff : PCI Bus 0000:04
> 	feb00000-febfffff : PCI Bus 0000:05
> 
> in the resource tree, and that in turn means that when we try to allocate 
> the bogus MCFG resource, it fails.
> 
> Which is good - it mustn't succeed.
> 
> What _broke_ for you is that the horrible patch that got reverted said 
> that "if we recognize this as an MCFG resource, we will _always_ try to 
> insert it", so it fundamentally broke the whole resource tree, because it 
> force-inserted that totally crap resource.

Well, I thought something like this happened, but I wasn't quite sure about the
exact mechanism.  Thanks for the explanation. :-)

Rafael

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

[Jeff Garzik]

Rafael J. Wysocki wrote:
> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> 
> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date:   Mon Aug 25 00:56:08 2008 -0700
> 
>     x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> 
> Reverting this commit helps.
> 
> The symptom is that AHCI probe fails with this commit applied.


Just to be sure...  Does "helps" imply that unresolved AHCI behavior 
exists after reverting that commit?

Thanks,

	Jeff

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

[Rafael J. Wysocki]

On Saturday, 30 of August 2008, Jeff Garzik wrote:
> Rafael J. Wysocki wrote:
> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> > 
> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> > Author: Yinghai Lu <yhlu.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date:   Mon Aug 25 00:56:08 2008 -0700
> > 
> >     x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> > 
> > Reverting this commit helps.
> > 
> > The symptom is that AHCI probe fails with this commit applied.
> 
> 
> Just to be sure...  Does "helps" imply that unresolved AHCI behavior 
> exists after reverting that commit?

No, after reverting this commit AHCI works normally.

Thanks,
Rafael

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

[David Witbrodt]

----- Original Message ----
> From: Linus Torvalds <torvalds@linux-foundation.org>
> To: Yinghai Lu <yhlu.kernel@gmail.com>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Jeff Garzik <jeff@garzik.org>; Tejun Heo <htejun@gmail.com>; Ingo Molnar <mingo@elte.hu>; David Witbrodt <dawitbro@sbcglobal.net>; Andrew Morton <akpm@linux-foundation.org>; Kernel Testers <kernel-testers@vger.kernel.org>
> Sent: Friday, August 29, 2008 10:56:50 PM
> Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> 
> 
> 
> On Fri, 29 Aug 2008, Linus Torvalds wrote:
> > 
> > Yes. And I do think this is a workable model.
> 
> Ok, and here's the patch to do
> 
>     insert_resource_expand_to_fit(root, new);
> 
> and while I still haven't actually tested it, it looks sane and compiles 
> to code that also looks sane.
> 
> I'll happily commit this as basic infrastructure as soon as somebody ack's 
> it and tests that it works (and I'll try it myself soon enough, just for 
> fun)
> 
>         Linus
> 
> ---
> include/linux/ioport.h |    1 +
> kernel/resource.c      |   88 ++++++++++++++++++++++++++++++++++-------------
> 2 files changed, 64 insertions(+), 25 deletions(-)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 22d2115..8d3b7a9 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -109,6 +109,7 @@ extern struct resource iomem_resource;
> extern int request_resource(struct resource *root, struct resource *new);
> extern int release_resource(struct resource *new);
> extern int insert_resource(struct resource *parent, struct resource *new);
> +extern void insert_resource_expand_to_fit(struct resource *root, struct 
> resource *new);
> extern int allocate_resource(struct resource *root, struct resource *new,
>                  resource_size_t size, resource_size_t min,
>                  resource_size_t max, resource_size_t align,
> diff --git a/kernel/resource.c b/kernel/resource.c
> index f5b518e..72ee95b 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -362,35 +362,21 @@ int allocate_resource(struct resource *root, struct 
> resource *new,
> 
> EXPORT_SYMBOL(allocate_resource);
> 
> -/**
> - * insert_resource - Inserts a resource in the resource tree
> - * @parent: parent of the new resource
> - * @new: new resource to insert
> - *
> - * Returns 0 on success, -EBUSY if the resource can't be inserted.
> - *
> - * This function is equivalent to request_resource when no conflict
> - * happens. If a conflict happens, and the conflicting resources
> - * entirely fit within the range of the new resource, then the new
> - * resource is inserted and the conflicting resources become children of
> - * the new resource.
> +/*
> + * Insert a resource into the resource tree. If successful, return NULL,
> + * otherwise return the conflicting resource (compare to __request_resource())
>   */
> -int insert_resource(struct resource *parent, struct resource *new)
> +static struct resource * __insert_resource(struct resource *parent, struct 
> resource *new)
> {
> -    int result;
>     struct resource *first, *next;
> 
> -    write_lock(&resource_lock);
> -
>     for (;; parent = first) {
> -         result = 0;
>         first = __request_resource(parent, new);
>         if (!first)
> -            goto out;
> +            return first;
> 
> -        result = -EBUSY;
>         if (first == parent)
> -            goto out;
> +            return first;
> 
>         if ((first->start > new->start) || (first->end < new->end))
>             break;
> @@ -401,15 +387,13 @@ int insert_resource(struct resource *parent, struct 
> resource *new)
>     for (next = first; ; next = next->sibling) {
>         /* Partial overlap? Bad, and unfixable */
>         if (next->start < new->start || next->end > new->end)
> -            goto out;
> +            return next;
>         if (!next->sibling)
>             break;
>         if (next->sibling->start > new->end)
>             break;
>     }
> 
> -    result = 0;
> -
>     new->parent = parent;
>     new->sibling = next->sibling;
>     new->child = first;
> @@ -426,10 +410,64 @@ int insert_resource(struct resource *parent, struct 
> resource *new)
>             next = next->sibling;
>         next->sibling = new;
>     }
> +    return NULL;
> +}
> 
> - out:
> +/**
> + * insert_resource - Inserts a resource in the resource tree
> + * @parent: parent of the new resource
> + * @new: new resource to insert
> + *
> + * Returns 0 on success, -EBUSY if the resource can't be inserted.
> + *
> + * This function is equivalent to request_resource when no conflict
> + * happens. If a conflict happens, and the conflicting resources
> + * entirely fit within the range of the new resource, then the new
> + * resource is inserted and the conflicting resources become children of
> + * the new resource.
> + */
> +int insert_resource(struct resource *parent, struct resource *new)
> +{
> +    struct resource *conflict;
> +
> +    write_lock(&resource_lock);
> +    conflict = __insert_resource(parent, new);
>     write_unlock(&resource_lock);
> -    return result;
> +    return conflict ? -EBUSY : 0;
> +}
> +
> +/**
> + * insert_resource_expand_to_fit - Insert a resource into the resource tree
> + * @parent: parent of the new resource
> + * @new: new resource to insert
> + *
> + * Insert a resource into the resource tree, possibly expanding it in order
> + * to make it encompass any conflicting resources.
> + */
> +void insert_resource_expand_to_fit(struct resource *root, struct resource *new)
> +{
> +    if (new->parent)
> +        return;
> +
> +    write_lock(&resource_lock);
> +    for (;;) {
> +        struct resource *conflict;
> +
> +        conflict = __insert_resource(root, new);
> +        if (!conflict)
> +            break;
> +        if (conflict == root)
> +            break;
> +
> +        /* Ok, expand resource to cover the conflict, then try again .. */
> +        if (conflict->start < new->start)
> +            new->start = conflict->start;
> +        if (conflict->end > new->end)
> +            new->end = conflict->end;
> +
> +        printk("Expanded resource %s due to conflict with %s", new->name, 
> conflict->name);
> +    }
> +    write_unlock(&resource_lock);    
> }
> 
> /**

Not sure if you wanted ME to test this, but I've been watching this
argument with Yinghai and became curious...

I updated my git tree so that I have the insert_resource_expand_to_fit()
changes, and the kernel builds fine.  Unfortunately, it hangs like all
2.6.2[67] kernels without reverting 3def3d6d... and 1e934dda... (or
without the later patches provided by Ingo and Yinghai).

Sorry if I am interfering... just wanted to inject this data, in case
it's meaningful!


Dave W.

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

[Linus Torvalds]

On Fri, 29 Aug 2008, David Witbrodt wrote:
> 
> Not sure if you wanted ME to test this, but I've been watching this
> argument with Yinghai and became curious...

You'll eventually have something to test, this part was just 
infrastructure and didn't change anything at all.

> I updated my git tree so that I have the insert_resource_expand_to_fit()
> changes, and the kernel builds fine.  Unfortunately, it hangs like all
> 2.6.2[67] kernels without reverting 3def3d6d... and 1e934dda... (or
> without the later patches provided by Ingo and Yinghai).
> 
> Sorry if I am interfering... just wanted to inject this data, in case
> it's meaningful!

Yeah, nothing has changed yet for your case. What should change your case 
is the thing Yinghai is working on with the "late add of e820 data to the 
resource tree".

His earlier version already worked for you, didn't it? We're really now 
just finalizing details (in fact, "insert_resource_expand_to_fit()" is 
just a helper function for a detail that may not even matter all that 
much).

		Linus

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

[David Witbrodt]

> > Sorry if I am interfering... just wanted to inject this data, in case
> > it's meaningful!
> 
> Yeah, nothing has changed yet for your case. What should change your case 
> is the thing Yinghai is working on with the "late add of e820 data to the 
> resource tree".

OK.


> His earlier version already worked for you, didn't it? We're really now 
> just finalizing details (in fact, "insert_resource_expand_to_fit()" is 
> just a helper function for a detail that may not even matter all that 
> much).

Yes, it worked fine!  :D

BTW, there was an individual who reported a regression back in May on the
very same commit.  I was not able to get him to participate in the process
of tracking this down, but he did (suddenly) write a post on his blog a
couple of days ago that he had success using some unspecified git tree HEAD.

I believe that was probably the patch that you have reverted, so once I
know that a new candidate is in place I will let him know on his blog and
see if I can talk him into trying it.  This has been a month-long quest
for me -- beginning on Aug. 4 -- and I can understand why he gave up in
May without resolving the issue.  It's too bad for all of us that he didn't
pursue it then, huh?


Thanks,
Dave W.

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

[David Witbrodt]

> David, can you test those two patches on top of linus tree?
> 
> YH

Yinghai,

I believe I have applied those patches correctly -- but I have only
been using git since Aug. 4, so please verify that I have done what
you asked.

My git tree was originally created by cloning Linus' linux-2.6 tree.  
I ran into some difficulty applying the patches, but I found a way to
allow them to apply:

===== SHELL SESSION =============
$ git apply --verbose --check ../split_e820_reserve.patch 
Checking patch arch/x86/kernel/e820.c...
Checking patch arch/x86/pci/i386.c...
Checking patch include/asm-x86/e820.h...

$ git apply --verbose ../split_e820_reserve.patch
Checking patch arch/x86/kernel/e820.c...
Checking patch arch/x86/pci/i386.c...
Checking patch include/asm-x86/e820.h...
Applied patch arch/x86/kernel/e820.c cleanly.
Applied patch arch/x86/pci/i386.c cleanly.
Applied patch include/asm-x86/e820.h cleanly.

$ git apply --verbose --check ../split_e820_reserve_xx1.patch 
Checking patch arch/x86/kernel/e820.c...
Checking patch include/linux/ioport.h...
error: while searching for:

extern int request_resource(struct resource *root, struct resource *new);
extern int release_resource(struct resource *new);
extern int insert_resource(struct resource *parent, struct resource *new);
extern int allocate_resource(stru
error: patch failed: include/linux/ioport.h:108
error: include/linux/ioport.h: patch does not apply
Checking patch kernel/resource.c...
error: while searching for:
EXPORT_SYMBOL(allocate_resource);

/**
 * insert_resource - Inserts a resource in the resource tree
 * @parent: parent of the new resource
 * @new: new resource to insert
 *
 * Returns 0 on success, -EBUSY if the resource can't be ins
error: patch failed: kernel/resource.c:363
error: kernel/resource.c: patch does not apply
=================================


Looking over that second patch, I saw that it changes kernel/resource.c.
But I was watching the messages between you and Linus last night, and
I believe he made a commit touching the same file:

=================================
$ git show | head
commit bef69ea0dcce574a425feb0a5aa4c63dd108b9a6
Author: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date:   Fri Aug 29 20:18:31 2008 -0700

    Resource handling: add 'insert_resource_expand_to_fit()' function
    
    Not used anywhere yet, but this complements the existing plain
    'insert_resource()' functionality with a version that can expand the
    resource we are adding in order to fix up any conflicts it has with
    existing resources.
=================================


So I decided to try applying the patches against the tree as it was
before bef69ea0...:

=================================
$ git checkout -f HEAD^
Note: moving to "HEAD^" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 00aeb42... Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6

$ git apply --verbose --check ../split_e820_reserve.patch 
Checking patch arch/x86/kernel/e820.c...
Checking patch arch/x86/pci/i386.c...
Checking patch include/asm-x86/e820.h...

$ git apply --verbose ../split_e820_reserve.patch 
Checking patch arch/x86/kernel/e820.c...
Checking patch arch/x86/pci/i386.c...
Checking patch include/asm-x86/e820.h...
Applied patch arch/x86/kernel/e820.c cleanly.
Applied patch arch/x86/pci/i386.c cleanly.
Applied patch include/asm-x86/e820.h cleanly.

$ git apply --verbose --check ../split_e820_reserve_xx1.patch 
Checking patch arch/x86/kernel/e820.c...
Checking patch include/linux/ioport.h...
Checking patch kernel/resource.c...

$ git apply --verbose ../split_e820_reserve_xx1.patch 
Checking patch arch/x86/kernel/e820.c...
Checking patch include/linux/ioport.h...
Checking patch kernel/resource.c...
Applied patch arch/x86/kernel/e820.c cleanly.
Applied patch include/linux/ioport.h cleanly.
Applied patch kernel/resource.c cleanly.
=================================


The kernel built from this set of changes runs perfectly, so if I
have handled the patches correctly then I have to thank you yet
again for a nice job!

Here are some excerpts from 'dmesg' and /proc/timer_list in case you
are interested:

$ dmesg
Linux version 2.6.27-rc5.split-e820-patches (dawitbro@fileserver) (gcc version 4.3.1 (Debian 4.3.1-9) ) #1 SMP Sat Aug 30 18:25:30 EDT 2008
[...]
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000077fe0000 (usable)
 BIOS-e820: 0000000077fe0000 - 0000000077fe3000 (ACPI NVS)
 BIOS-e820: 0000000077fe3000 - 0000000077ff0000 (ACPI data)
 BIOS-e820: 0000000077ff0000 - 0000000078000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
last_pfn = 0x77fe0 max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
init_memory_mapping
 0000000000 - 0077e00000 page 2M
 0077e00000 - 0077fe0000 page 4k
kernel direct mapping tables up to 77fe0000 @ 8000-c000
last_map_addr: 77fe0000 end: 77fe0000
DMI 2.5 present.
ACPI: RSDP 000F7B80, 0024 (r2 RS690 )
ACPI: RSDT 77FE3040, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 77FE30C0, 0074 (r1 RS690  AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 77FE3180, 4B0B (r1 RS690  AWRDACPI     1000 MSFT  3000000)
ACPI: FACS 77FE0000, 0040
ACPI: SSDT 77FE7DC0, 028A (r1 PTLTD  POWERNOW        1  LTP        1)
ACPI: HPET 77FE80C0, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD       98)
ACPI: MCFG 77FE8140, 003C (r1 RS690  AWRDACPI 42302E31 AWRD        0)
ACPI: APIC 77FE7D00, 0068 (r1 RS690  AWRDACPI 42302E31 AWRD        0)
[...]
ACPI: HPET id: 0x10b9a201 base: 0xfed00000
[...]
hpet clockevent registered
[...]
calling  pci_arch_init+0x0/0x4b
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG at e0000000 - efffffff
PCI: Using configuration type 1 for base access
initcall pci_arch_init+0x0/0x4b returned 0 after 6 msecs
[...]
calling  pnpacpi_init+0x0/0x91
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp 00:0d: mem resource (0xfed00000-0xfed000ff) overlaps 0000:00:14.0 BAR 1 (0xfed00000-0xfed003ff), disabling
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
initcall pnpacpi_init+0x0/0x91 returned 0 after 3 msecs
[...]
calling  hpet_late_init+0x0/0xf5
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
initcall hpet_late_init+0x0/0xf5 returned 0 after 0 msecs
[...]
calling  pnp_system_init+0x0/0x16
system 00:01: ioport range 0x4100-0x411f has been reserved
system 00:01: ioport range 0x228-0x22f has been reserved
system 00:01: ioport range 0x40b-0x40b has been reserved
system 00:01: ioport range 0x4d6-0x4d6 has been reserved
system 00:01: ioport range 0xc00-0xc01 has been reserved
system 00:01: ioport range 0xc14-0xc14 has been reserved
system 00:01: ioport range 0xc50-0xc52 has been reserved
system 00:01: ioport range 0xc6c-0xc6d has been reserved
system 00:01: ioport range 0xc6f-0xc6f has been reserved
system 00:01: ioport range 0xcd0-0xcd1 has been reserved
system 00:01: ioport range 0xcd2-0xcd3 has been reserved
system 00:01: ioport range 0xcd4-0xcdf has been reserved
system 00:01: ioport range 0x4000-0x40fe has been reserved
system 00:01: ioport range 0x4210-0x4217 has been reserved
system 00:01: ioport range 0xb10-0xb1f has been reserved
system 00:07: ioport range 0x4d0-0x4d1 has been reserved
system 00:07: ioport range 0x220-0x225 has been reserved
system 00:07: ioport range 0xb00-0xb0f has been reserved
system 00:0c: iomem range 0xe0000000-0xefffffff could not be reserved
system 00:0d: iomem range 0xf0000-0xfffff could not be reserved
system 00:0d: iomem range 0x77fe0000-0x77ffffff could not be reserved
system 00:0d: iomem range 0xffff0000-0xffffffff could not be reserved
system 00:0d: iomem range 0x0-0x9ffff could not be reserved
system 00:0d: iomem range 0x100000-0x77fdffff could not be reserved
system 00:0d: iomem range 0x78000000-0x7fffffff has been reserved
system 00:0d: iomem range 0xfec00000-0xfec00fff could not be reserved
system 00:0d: iomem range 0xfee00000-0xfee00fff could not be reserved
system 00:0d: iomem range 0xfff80000-0xfffeffff could not be reserved
initcall pnp_system_init+0x0/0x16 returned 0 after 0 msecs
[...]
calling  hpet_init+0x0/0x6d
hpet_resources: 0xfed00000 is busy
initcall hpet_init+0x0/0x6d returned 0 after 1 msecs
[...]


$ grep -B 1 -A 5 hpet /proc/timer_list
Tick Device: mode:     1
Clock Event Device: hpet
 max_delta_ns:   149983003520
 min_delta_ns:   3352
 mult:           61496115
 shift:          32
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: hpet_legacy_next_event
 set_mode:       hpet_legacy_set_mode
 event_handler:  tick_handle_oneshot_broadcast
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000


Thanks,
Dave W.

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

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

> So I decided to try applying the patches against the tree as it was
> before bef69ea0...:
>
> =================================
> $ git checkout -f HEAD^
> Note: moving to "HEAD^" which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
>  git checkout -b <new_branch_name>
> HEAD is now at 00aeb42... Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
>
> $ git apply --verbose --check ../split_e820_reserve.patch
> Checking patch arch/x86/kernel/e820.c...
> Checking patch arch/x86/pci/i386.c...
> Checking patch include/asm-x86/e820.h...
>
> $ git apply --verbose ../split_e820_reserve.patch
> Checking patch arch/x86/kernel/e820.c...
> Checking patch arch/x86/pci/i386.c...
> Checking patch include/asm-x86/e820.h...
> Applied patch arch/x86/kernel/e820.c cleanly.
> Applied patch arch/x86/pci/i386.c cleanly.
> Applied patch include/asm-x86/e820.h cleanly.
>
> $ git apply --verbose --check ../split_e820_reserve_xx1.patch
> Checking patch arch/x86/kernel/e820.c...
> Checking patch include/linux/ioport.h...
> Checking patch kernel/resource.c...

please use split_e820_reserve_xx2.patch instead...

Thanks

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: split_e820_reserve_xx2.patch --]
[-- Type: text/x-patch; name=split_e820_reserve_xx2.patch, Size: 5127 bytes --]

From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: split e820 reserved entries record to late v4 - fix v6

try to insert_resource second time, by expand the resource...

for case: e820 reserved entry is partially overlapped with bar res...

hope it will never happen

v2: according to Linus, add insert_resource_expand_to_fit, and change
	__insert_resource to static without lock

v3: use reserve_region_with_split() instead to hand overlapping
	with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
	get
		e0000000-efffffff : PCI MMCONFIG 0
			 e0000000-efffffff : reserved
	in /proc/iomem
	get
		found conflict for reserved [dd800000, efffffff], try to reserve with split
		    __reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
		    __reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
		initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
	in dmesg

v4: take out __insert_resource and insert_resource_expand_to_fit : Linus already check in.
    use reserve_region_with_split at the first point
    use const char *name

v5: fix checking on overlapping

v6: only reserve common area in conflict
	so got sth in /proc/iomem
		d8000000-dfffffff : PCI Bus #00
		  dc000000-dfffffff : GART
		    dc000000-dfffffff : reserved
		e0000000-efffffff : PCI MMCONFIG 0
		  e0000000-efffffff : reserved
	when we have big range in e820
		00000000dc000000-00000000f0000000 (reserved)

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/e820.c |    2 -
 include/linux/ioport.h |    3 ++
 kernel/resource.c      |   69 ++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 72 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1320,7 +1320,7 @@ void __init e820_reserve_resources_late(
 	res = e820_res;
 	for (i = 0; i < e820.nr_map; i++) {
 		if (!res->parent && res->end)
-			insert_resource(&iomem_resource, res);
+			reserve_region_with_split(&iomem_resource, res->start, res->end, res->name);
 		res++;
 	}
 }
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -108,6 +108,9 @@ extern struct resource iomem_resource;
 
 extern int request_resource(struct resource *root, struct resource *new);
 extern int release_resource(struct resource *new);
+extern void reserve_region_with_split(struct resource *root,
+			     resource_size_t start, resource_size_t end,
+			     const char *name);
 extern int insert_resource(struct resource *parent, struct resource *new);
 extern void insert_resource_expand_to_fit(struct resource *root, struct resource *new);
 extern int allocate_resource(struct resource *root, struct resource *new,
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -512,10 +512,77 @@ int adjust_resource(struct resource *res
 	result = 0;
 
  out:
-	write_unlock(&resource_lock);
 	return result;
 }
 
+static void __init __reserve_region_with_split(struct resource *root,
+		resource_size_t start, resource_size_t end,
+		const char *name)
+{
+	struct resource *parent = root;
+	struct resource *conflict;
+	struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL);
+
+	if (!res)
+		return;
+
+	res->name = name;
+	res->start = start;
+	res->end = end;
+	res->flags = IORESOURCE_BUSY;
+
+	for (;;) {
+		conflict = __request_resource(parent, res);
+		if (!conflict)
+			break;
+		if (conflict != parent) {
+			parent = conflict;
+			if (!(conflict->flags & IORESOURCE_BUSY))
+				continue;
+		}
+
+		/* Uhhuh, that didn't work out.. */
+		kfree(res);
+		res = NULL;
+		break;
+	}
+
+	if (!res) {
+		printk(KERN_DEBUG "    __reserve_region_with_split: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n",
+			 conflict->name, conflict->start, conflict->end,
+			 name, start, end);
+
+		/* failed, split and try again */
+
+		/* conflict coverred whole area */
+		if (conflict->start <= start && conflict->end >= end)
+			return;
+
+		if (conflict->start > start)
+			__reserve_region_with_split(root, start, conflict->start-1, name);
+		if (!(conflict->flags & IORESOURCE_BUSY)) {
+			resource_size_t common_start, common_end;
+
+			common_start = max(conflict->start, start);
+			common_end = min(conflict->end, end);
+			if (common_start < common_end)
+				__reserve_region_with_split(root, common_start, common_end, name);
+		}
+		if (conflict->end < end)
+			__reserve_region_with_split(root, conflict->end+1, end, name);
+	}
+
+}
+
+void reserve_region_with_split(struct resource *root,
+		resource_size_t start, resource_size_t end,
+		const char *name)
+{
+	write_lock(&resource_lock);
+	__reserve_region_with_split(root, start, end, name);
+	write_unlock(&resource_lock);
+}
+
 EXPORT_SYMBOL(adjust_resource);
 
 /**

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

[David Witbrodt]

> please use split_e820_reserve_xx2.patch instead...

OK, that produces the same result:  a happy kernel!

I compared the full 'dmesg' output from the previous build and the
current build using diff:  the only differences were trivial --
return times from initcall functions, and the order in which some
initcalls were performed was different very late in the boot process.


Thanks Yinghai,
Dave W.

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

[Yinghai Lu]

On Sat, Aug 30, 2008 at 6:25 PM, David Witbrodt <dawitbro-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org> wrote:
>
>
>> please use split_e820_reserve_xx2.patch instead...
>
> OK, that produces the same result:  a happy kernel!
>
> I compared the full 'dmesg' output from the previous build and the
> current build using diff:  the only differences were trivial --
> return times from initcall functions, and the order in which some
> initcalls were performed was different very late in the boot process.

good, let wait for Ingo back to check the two patches too.

YH