[PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Bjorn Helgaas]

Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
x86_32.  But this legacy area is also used on x86_64, so this patch
reserves it there, too.

If we don't reserve it, we may mistakenly move a PCI device to that area,
as we did here:

  pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
  pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
  pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
  pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]

as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375

I think the fact that the BAR is not within a host bridge window is a
BIOS defect, and it's now more visible because we have "pci=use_crs" as
the default.  Using "pci=nocrs" is a workaround, because then we won't
attempt to move the device.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---

 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/head32.c     |    3 +--
 arch/x86/kernel/setup.c      |   25 ++++++++-----------------
 3 files changed, 9 insertions(+), 20 deletions(-)


diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 86b1506..f4c0fe4 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(void) { }
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index b2e2460..b6de8f8 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -20,9 +20,8 @@
 
 static void __init i386_default_early_setup(void)
 {
-	/* Initilize 32bit specific setup functions */
+	/* Initialize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9570541..24d9113 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -575,6 +575,13 @@ static struct resource standard_io_resources[] = {
 		.flags = IORESOURCE_BUSY | IORESOURCE_IO }
 };
 
+static struct resource video_ram_resource = {
+	.name	= "Video RAM area",
+	.start	= 0xa0000,
+	.end	= 0xbffff,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+};
+
 void __init reserve_standard_io_resources(void)
 {
 	int i;
@@ -583,6 +590,7 @@ void __init reserve_standard_io_resources(void)
 	for (i = 0; i < ARRAY_SIZE(standard_io_resources); i++)
 		request_resource(&ioport_resource, &standard_io_resources[i]);
 
+	request_resource(&iomem_resource, &video_ram_resource);
 }
 
 /*
@@ -1042,20 +1050,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/07/2010 02:06 PM, Bjorn Helgaas wrote:
> 
> Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
> x86_32.  But this legacy area is also used on x86_64, so this patch
> reserves it there, too.
> 
> If we don't reserve it, we may mistakenly move a PCI device to that area,
> as we did here:
> 
>   pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
>   pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
>   pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
>   pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
> 
> as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375
> 
> I think the fact that the BAR is not within a host bridge window is a
> BIOS defect, and it's now more visible because we have "pci=use_crs" as
> the default.  Using "pci=nocrs" is a workaround, because then we won't
> attempt to move the device.

that doesn't look right.

It seem another thread, erission has one model without VGA, and they use that area for other device MMIO.

current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM.

in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map.
that is before pci BAR is claimed.

or you can add
boot_params.screen_info.orig_video_isVGA == 1
or double check scan pci tree to see if video is there or not

YH

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Bjorn Helgaas]

On Wednesday 07 April 2010 04:45:30 pm Yinghai wrote:
> On 04/07/2010 02:06 PM, Bjorn Helgaas wrote:
> > 
> > Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
> > x86_32.  But this legacy area is also used on x86_64, so this patch
> > reserves it there, too.
> > 
> > If we don't reserve it, we may mistakenly move a PCI device to that area,
> > as we did here:
> > 
> >   pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
> >   pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
> >   pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
> >   pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
> > 
> > as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375
> > 
> > I think the fact that the BAR is not within a host bridge window is a
> > BIOS defect, and it's now more visible because we have "pci=use_crs" as
> > the default.  Using "pci=nocrs" is a workaround, because then we won't
> > attempt to move the device.
> 
> that doesn't look right.
> 
> It seem another thread, erission has one model without VGA, and they use that area for other device MMIO.
> 
> current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM.
> 
> in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map.
> that is before pci BAR is claimed.
> 
> or you can add
> boot_params.screen_info.orig_video_isVGA == 1
> or double check scan pci tree to see if video is there or not

I'm sorry, I can't understand what you're saying.

It seems like you're saying we already have a mechanism to keep us
from assigning that VGA range to another device, but obviously it's
not working.

Maybe it will be clearer if you propose a different patch that prevents
us from assigning 0xa0000 to the USB controller.

Bjorn

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/07/2010 04:05 PM, Bjorn Helgaas wrote:
> On Wednesday 07 April 2010 04:45:30 pm Yinghai wrote:
>> On 04/07/2010 02:06 PM, Bjorn Helgaas wrote:
>>>
>>> Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
>>> x86_32.  But this legacy area is also used on x86_64, so this patch
>>> reserves it there, too.
>>>
>>> If we don't reserve it, we may mistakenly move a PCI device to that area,
>>> as we did here:
>>>
>>>   pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
>>>   pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
>>>   pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
>>>   pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
>>>
>>> as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375
>>>
>>> I think the fact that the BAR is not within a host bridge window is a
>>> BIOS defect, and it's now more visible because we have "pci=use_crs" as
>>> the default.  Using "pci=nocrs" is a workaround, because then we won't
>>> attempt to move the device.
>>
>> that doesn't look right.
>>
>> It seem another thread, erission has one model without VGA, and they use that area for other device MMIO.
>>
>> current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM.
>>
>> in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map.
>> that is before pci BAR is claimed.
>>
>> or you can add
>> boot_params.screen_info.orig_video_isVGA == 1
>> or double check scan pci tree to see if video is there or not
> 
> I'm sorry, I can't understand what you're saying.

for 64 bit, you may check boot_params.screen_info.orig_video_isVGA to see if you need to reserve that VGA range.
not sure if every bootloader fill that...

> 
> It seems like you're saying we already have a mechanism to keep us
> from assigning that VGA range to another device, but obviously it's
> not working.
> 
> Maybe it will be clearer if you propose a different patch that prevents
> us from assigning 0xa0000 to the USB controller.

when the system only have one peer root bus, can you skip the _CRS for it?

YH

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Bjorn Helgaas]

On Wed, 2010-04-07 at 16:22 -0700, Yinghai wrote:
> On 04/07/2010 04:05 PM, Bjorn Helgaas wrote:
> > On Wednesday 07 April 2010 04:45:30 pm Yinghai wrote:
> >> On 04/07/2010 02:06 PM, Bjorn Helgaas wrote:
> >>>
> >>> Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
> >>> x86_32.  But this legacy area is also used on x86_64, so this patch
> >>> reserves it there, too.
> >>>
> >>> If we don't reserve it, we may mistakenly move a PCI device to that area,
> >>> as we did here:
> >>>
> >>>   pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
> >>>   pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
> >>>   pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
> >>>   pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
> >>>
> >>> as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375
> >>>
> >>> I think the fact that the BAR is not within a host bridge window is a
> >>> BIOS defect, and it's now more visible because we have "pci=use_crs" as
> >>> the default.  Using "pci=nocrs" is a workaround, because then we won't
> >>> attempt to move the device.
> >>
> >> that doesn't look right.
> >>
> >> It seem another thread, erission has one model without VGA, and they use that area for other device MMIO.
> >>
> >> current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM.
> >>
> >> in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map.
> >> that is before pci BAR is claimed.
> >>
> >> or you can add
> >> boot_params.screen_info.orig_video_isVGA == 1
> >> or double check scan pci tree to see if video is there or not
> > 
> > I'm sorry, I can't understand what you're saying.
> 
> for 64 bit, you may check boot_params.screen_info.orig_video_isVGA to see if you need to reserve that VGA range.
> not sure if every bootloader fill that...

If you're saying that on x86_64, you have a reliable way to determine
whether to reserve the legacy VGA MMIO area, I hope you'll provide a
patch, because I don't know about this sort of x86_32 vs x86_64
difference.

I actually did propose doing something in pci_setup_device(), similar to
what we already do for legacy IDE resources, but HPA thought it should
be done in the arch code instead, again for reasons I don't completely
understand.

> when the system only have one peer root bus, can you skip the _CRS for it?

That's ugly.  When we discover the first host bridge, we have no idea
whether there will be more.  I don't want to mess around with trying to
count the number of bridges, then go back and add them in another pass.

I think it's fairly clear from http://lkml.org/lkml/2010/4/7/284 that
Windows is paying attention the _CRS, even though there's only one host
bridge.  So we ought to be able to make it work, too.

This is not a problem with pci=use_crs.  This is only a problem because
we don't reserve the VGA area when we should.  That's the problem we
should fix.

Bjorn

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/07/2010 08:24 PM, Bjorn Helgaas wrote:
> 
> I actually did propose doing something in pci_setup_device(), similar to
> what we already do for legacy IDE resources, but HPA thought it should
> be done in the arch code instead, again for reasons I don't completely
> understand.
> 

"Non-PCI devices" is hard to understand?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Bjorn Helgaas]

On Wed, 2010-04-07 at 21:42 -0700, H. Peter Anvin wrote:
> On 04/07/2010 08:24 PM, Bjorn Helgaas wrote:
> > 
> > I actually did propose doing something in pci_setup_device(), similar to
> > what we already do for legacy IDE resources, but HPA thought it should
> > be done in the arch code instead, again for reasons I don't completely
> > understand.

> "Non-PCI devices" is hard to understand?

I understand that part, and the patch I posted is for the arch code, as
you suggested.

I just thought you were suggesting an x86 change *instead* of something
in PCI, even though it seems like the PCI spec does mention that devices
with VGA class code respond at 0xa0000.  Or maybe you were just
suggesting that we should do something in *both* PCI and in the arch
code?

Of course, the PCI part might be complicated by the VGA arbiter,
although I would think that if the system contains at least one VGA
device, reserving the 0xa0000 region once would solve 99% of the
problem.  If the arbiter changes the actual device that responds there,
the reservation will be for the wrong device, but we still want to avoid
putting anything else there.

Honestly, I don't know enough about x86_32 vs x86_64 to understand
Yinghai's objection.  Is there some platform architecture difference
that means x86_64 can reliably determine whether a non-PCI VGA device is
present, when x86_32 can't?  Unless there's a real difference, we ought
to handle them both the same, as my patch does.

Yinghai mentioned a box with no VGA and another device using 0xa0000.
Unless there's some x86_64-specific spec or convention that addresses
this, maybe we could handle that by (1) doing the legacy reservation as
in this patch, and (2) special-casing the PCI device setup so that if we
find a BAR set to that area, we undo the legacy reservation.  Or maybe
we just leave the legacy reservation unused and relocate the device that
BIOS left there.

Bjorn

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Bjorn Helgaas]

On Wednesday 07 April 2010 05:22:43 pm Yinghai wrote:
> On 04/07/2010 04:05 PM, Bjorn Helgaas wrote:
> > On Wednesday 07 April 2010 04:45:30 pm Yinghai wrote:
> >> On 04/07/2010 02:06 PM, Bjorn Helgaas wrote:
> >>>
> >>> Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
> >>> x86_32.  But this legacy area is also used on x86_64, so this patch
> >>> reserves it there, too.
> >>>
> >>> If we don't reserve it, we may mistakenly move a PCI device to that area,
> >>> as we did here:
> >>>
> >>>   pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
> >>>   pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
> >>>   pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
> >>>   pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
> >>>
> >>> as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375
> >>>
> >>> I think the fact that the BAR is not within a host bridge window is a
> >>> BIOS defect, and it's now more visible because we have "pci=use_crs" as
> >>> the default.  Using "pci=nocrs" is a workaround, because then we won't
> >>> attempt to move the device.
> >>
> >> that doesn't look right.
> >>
> >> It seem another thread, erission has one model without VGA, and they use that area for other device MMIO.
> >>
> >> current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM.
> >>
> >> in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map.
> >> that is before pci BAR is claimed.
> >>
> >> or you can add
> >> boot_params.screen_info.orig_video_isVGA == 1
> >> or double check scan pci tree to see if video is there or not
> > 
> > I'm sorry, I can't understand what you're saying.
> 
> for 64 bit, you may check boot_params.screen_info.orig_video_isVGA to see if you need to reserve that VGA range.
> not sure if every bootloader fill that...

Why is this different for 64-bit vs 32-bit?  Can you point me to any
references where I can learn about this?

Bjorn

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 09:04 AM, Bjorn Helgaas wrote:
>>
>> for 64 bit, you may check boot_params.screen_info.orig_video_isVGA to see if you need to reserve that VGA range.
>> not sure if every bootloader fill that...
> 
> Why is this different for 64-bit vs 32-bit?  Can you point me to any
> references where I can learn about this?
> 

It's not.  Any differences between 32 and 64 bits in this area are just
plain wrong.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/09/2010 09:44 AM, H. Peter Anvin wrote:
> On 04/09/2010 09:04 AM, Bjorn Helgaas wrote:
>>>
>>> for 64 bit, you may check boot_params.screen_info.orig_video_isVGA to see if you need to reserve that VGA range.
>>> not sure if every bootloader fill that...
>>
>> Why is this different for 64-bit vs 32-bit?  Can you point me to any
>> references where I can learn about this?
>>
> 
> It's not.  Any differences between 32 and 64 bits in this area are just
> plain wrong.
> 

then please check this one

update e820 at first, and later put them resource tree, but give pci BAR chance to claim
the range, before assign unassigned resources.

in case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some other pci devices.

Yinghai

Subject: [RFC PATCH] x86: reserve [0xa0000, 0x100000] in e820

And put those range in resource tree after pci BAR claim those range

---
 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/e820.c       |    2 +-
 arch/x86/kernel/head32.c     |    1 -
 arch/x86/kernel/setup.c      |   19 +------------------
 4 files changed, 2 insertions(+), 21 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
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
@@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
 		 * pci device BAR resource and insert them later in
 		 * pcibios_resource_survey()
 		 */
-		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+		if (e820.map[i].type != E820_RESERVED) {
 			res->flags |= IORESOURCE_BUSY;
 			insert_resource(&iomem_resource, res);
 		}
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_se
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

[Adding Guenter Roeck as he was commenting on something writing to the
VGA area...]

On 04/09/2010 10:22 AM, Yinghai wrote:
> 
> then please check this one
> 
> update e820 at first, and later put them resource tree, but give pci BAR chance to claim
> the range, before assign unassigned resources.
> 
> in case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some other pci devices.
> 

Do we have any evidence of any such system?

Either which way, the patch looks saner...

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Guenter Roeck]

On Fri, 2010-04-09 at 14:23 -0400, H. Peter Anvin wrote:
> [Adding Guenter Roeck as he was commenting on something writing to the
> VGA area...]
> 
> On 04/09/2010 10:22 AM, Yinghai wrote:
> > 
> > then please check this one
> > 
> > update e820 at first, and later put them resource tree, but give pci BAR chance to claim
> > the range, before assign unassigned resources.
> > 
> > in case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some other pci devices.
> > 
> 
> Do we have any evidence of any such system?
> 
> Either which way, the patch looks saner...
> 
Yes, we have a system which does not have VGA and uses the VGA memory
space for another device. I don't know exactly what for, but I can find
out if it is relevant.

Guenter

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

update version for test

Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820

Update e820 at first, and later put them resource tree.
But give pci BAR chance to claim the range, before assign unassigned resources.

In case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some
other pci devices.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>

---
 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/e820.c       |    2 +-
 arch/x86/kernel/head32.c     |    1 -
 arch/x86/kernel/setup.c      |   19 +------------------
 4 files changed, 2 insertions(+), 21 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
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
@@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
 		 * pci device BAR resource and insert them later in
 		 * pcibios_resource_survey()
 		 */
-		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+		if (e820.map[i].type != E820_RESERVED) {
 			res->flags |= IORESOURCE_BUSY;
 			insert_resource(&iomem_resource, res);
 		}
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_se
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Fri, Apr 09, 2010 at 12:55:39PM -0700, Yinghai wrote:
> update version for test
> 
> Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820
> 
> Update e820 at first, and later put them resource tree.
> But give pci BAR chance to claim the range, before assign unassigned resources.
> 
> In case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some
> other pci devices.

This doesn't help, my AHCI still fails to initialize in the same way.

-andy

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai Lu]

On 04/09/2010 03:21 PM, Andy Isaacson wrote:
> On Fri, Apr 09, 2010 at 12:55:39PM -0700, Yinghai wrote:
>   
>> update version for test
>>
>> Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820
>>
>> Update e820 at first, and later put them resource tree.
>> But give pci BAR chance to claim the range, before assign unassigned resources.
>>
>> In case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some
>> other pci devices.
>>     
> This doesn't help, my AHCI still fails to initialize in the same way.
>
>   
bootlog?

what is the address used for AHCI?

YH

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Fri, Apr 09, 2010 at 03:27:11PM -0700, Yinghai Lu wrote:
> > On Fri, Apr 09, 2010 at 12:55:39PM -0700, Yinghai wrote:
> >> update version for test
> >>
> >> Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820
> >>
> >> Update e820 at first, and later put them resource tree.
> >> But give pci BAR chance to claim the range, before assign unassigned resources.
> >>
> >> In case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some
> >> other pci devices.
> >>     
> > This doesn't help, my AHCI still fails to initialize in the same way.
> >
> >   
> bootlog?
> 
> what is the address used for AHCI?

Full bootlog attached to
https://bugzilla.kernel.org/show_bug.cgi?id=15744

Snippets:


[    0.000000]  BIOS-e820: 00000000bfe55c00 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 00000001bc000000 (usable)
--
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000bfe01000 - 00000000bfe02000
[    0.000000] PM: Registered nosave memory: 00000000bfe02000 - 00000000bfe53000
[    0.000000] PM: Registered nosave memory: 00000000bfe53000 - 00000000bfe54000
--
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000
[    0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
[    0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
--
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:2304
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] Fast TSC calibration using PIT
--
[    0.684251] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.702226] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.703002] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.704003] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.705002] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
[    0.706002] pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]
[    0.707001] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
--
[    2.059784] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    2.065789] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[    2.070538] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[    2.074594] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    2.075003] vgaarb: loaded
[    2.076073] SCSI subsystem initialized
[    2.077055] usbcore: registered new interface driver usbfs
[    2.078024] usbcore: registered new interface driver hub
--
[    2.247143] pci 0000:00:1c.5: BAR 9: assigned [mem 0xf0200000-0xf03fffff 64bit pref]
[    2.255207] pci 0000:00:1c.0: BAR 7: assigned [io  0x1000-0x1fff]
[    2.261473] pci 0000:00:1c.5: BAR 7: assigned [io  0x2000-0x2fff]
[    2.267740] pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
[    2.274701] pci 0000:00:1f.2: BAR 5: set to [mem 0x000a0000-0x000a07ff] (PCI address [0xa0000-0xa07ff]
[    2.284326] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    2.289725] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    2.295992] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfdefffff]
--
[    4.376870] brd: module loaded
[    4.381469] loop: module loaded
[    4.384915] Loading iSCSI transport class v2.0-870.
[    4.390597] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    4.397684] ahci: SSS flag set, parallel bus scan disabled
[    5.405019] ahci 0000:00:1f.2: controller reset failed (0xffffffff)
[    5.411473] ahci 0000:00:1f.2: PCI INT C disabled
[    5.416347] ahci: probe of 0000:00:1f.2 failed with error -5
[    5.422248] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[    5.428859] Copyright (c) 1999-2006 Intel Corporation.
[    5.434260] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 03:35 PM, Andy Isaacson wrote:
> [    2.267740] pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
> [    2.274701] pci 0000:00:1f.2: BAR 5: set to [mem 0x000a0000-0x000a07ff] (PCI address [0xa0000-0xa07ff]

Looks like this is something the kernel is assigning to it.  It *does*
get marked reserved:

> [    0.000000]   #6 [000009ec00 - 00000f0000]   BIOS reserved

... but that doesn't seem to keep the PCI code from assigning anything
there.  This is a Very Bad thing in general... if we're assigning
devices to areas marked reserved, we have a huge problem.

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/09/2010 03:44 PM, H. Peter Anvin wrote:
> On 04/09/2010 03:35 PM, Andy Isaacson wrote:
>> [    2.267740] pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
>> [    2.274701] pci 0000:00:1f.2: BAR 5: set to [mem 0x000a0000-0x000a07ff] (PCI address [0xa0000-0xa07ff]
> 
> Looks like this is something the kernel is assigning to it.  It *does*
> get marked reserved:
> 
>> [    0.000000]   #6 [000009ec00 - 00000f0000]   BIOS reserved
> 
> ... but that doesn't seem to keep the PCI code from assigning anything
> there.  This is a Very Bad thing in general... if we're assigning
> devices to areas marked reserved, we have a huge problem.

_CRS report those range are used devices under the peer root bus.

and in e820_reserve_resources_late, we are using insert_resource_expand_to_fit()
to register E820_RESERVED region.

could be that insert_resource_expand_to_fit doesn't work in that case.

like in the tree when we have
[    0.704003] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.705002] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
[    0.706002] pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]

and then insert_resource...
[0x9fec00, 0x100000)

it is not inserted to tree properly

YH

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

Please check

Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820

Update e820 at first, and later put them resource tree.

-V2: reserved that early, no PCI BAR can use it, force them to get new one

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>

---
 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/e820.c       |    2 +-
 arch/x86/kernel/head32.c     |    1 -
 arch/x86/kernel/setup.c      |   19 +------------------
 4 files changed, 2 insertions(+), 21 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_se
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Fri, Apr 09, 2010 at 04:01:44PM -0700, Yinghai wrote:
> Please check
> 
> Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820
> 
> Update e820 at first, and later put them resource tree.
> 
> -V2: reserved that early, no PCI BAR can use it, force them to get new one

Still no go.

[    0.000000] Linux version 2.6.34-rc3-00411-g9e969ac (andy@farthing) (gcc version 4.3.3 (Debian 4.3.3-5) ) #11 SMP Fri Apr 9 16:27:51 PDT 2010
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00411-g9e969ac root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro console=tty0 console=ttyS0,115200
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfe01c00 (usable)
[    0.000000]  BIOS-e820: 00000000bfe01c00 - 00000000bfe53c00 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bfe53c00 - 00000000bfe55c00 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bfe55c00 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 00000001bc000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x1bc000 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] last_pfn = 0xbfe01 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000fe710] fe710
[    0.000000] init_memory_mapping: 0000000000000000-00000000bfe01000
[    0.000000] init_memory_mapping: 0000000100000000-00000001bc000000
[    0.000000] RAMDISK: 37c8e000 - 37ff0000
[    0.000000] ACPI: RSDP 00000000000febf0 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000fcea4 0006C (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: FACP 00000000000fcfcc 000F4 (v03 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: DSDT 00000000fff5aafd 03794 (v01   DELL    dt_ex 00001000 INTL 20050624)
[    0.000000] ACPI: FACS 00000000bfe01c00 00040
[    0.000000] ACPI: SSDT 00000000fff5e291 00099 (v01   DELL    st_ex 00001000 INTL 20050624)
[    0.000000] ACPI: APIC 00000000000fd0c0 00092 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: BOOT 00000000000fd152 00028 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: ASF! 00000000000fd17a 00096 (v32 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: MCFG 00000000000fd210 0003E (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: HPET 00000000000fd24e 00038 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: TCPA 00000000000fd4aa 00032 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: SLIC 00000000000fd286 00176 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000001bc000000
[    0.000000] Initmem setup node 0 0000000000000000-00000001bc000000
[    0.000000]   NODE_DATA [0000000100000000 - 0000000100004fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000001 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x001bc000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000001 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x000bfe01
[    0.000000]     0: 0x00100000 -> 0x001bc000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000bfe01000 - 00000000bfe02000
[    0.000000] PM: Registered nosave memory: 00000000bfe02000 - 00000000bfe53000
[    0.000000] PM: Registered nosave memory: 00000000bfe53000 - 00000000bfe54000
[    0.000000] PM: Registered nosave memory: 00000000bfe54000 - 00000000bfe55000
[    0.000000] PM: Registered nosave memory: 00000000bfe55000 - 00000000bfe56000
[    0.000000] PM: Registered nosave memory: 00000000bfe56000 - 00000000c0000000
[    0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000e0000000
[    0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000f0000000
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000
[    0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
[    0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff880001e00000 s81896 r8192 d20504 u262144
[    0.000000] pcpu-alloc: s81896 r8192 d20504 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1531006
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00411-g9e969ac root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro console=tty0 console=ttyS0,115200
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (62 early reservations)
[    0.000000]   #1 [0001000000 - 0001db1168]   TEXT DATA BSS
[    0.000000]   #2 [0037c8e000 - 0037ff0000]         RAMDISK
[    0.000000]   #3 [0001db2000 - 0001db21a8]             BRK
[    0.000000]   #4 [00000fe720 - 0000100000]   BIOS reserved
[    0.000000]   #5 [00000fe710 - 00000fe720]    MP-table mpf
[    0.000000]   #6 [000009ec00 - 00000f0000]   BIOS reserved
[    0.000000]   #7 [00000f0304 - 00000fe710]   BIOS reserved
[    0.000000]   #8 [00000f0000 - 00000f0304]    MP-table mpc
[    0.000000]   #9 [0000001000 - 0000003000]      TRAMPOLINE
[    0.000000]   #10 [0000003000 - 0000007000]     ACPI WAKEUP
[    0.000000]   #11 [0000008000 - 000000b000]         PGTABLE
[    0.000000]   #12 [000000b000 - 000000e000]         PGTABLE
[    0.000000]   #13 [0100000000 - 0100005000]       NODE_DATA
[    0.000000]   #14 [0001db21c0 - 0001db31c0]         BOOTMEM
[    0.000000]   #15 [0001db1180 - 0001db1600]         BOOTMEM
[    0.000000]   #16 [0100005000 - 0100006000]         BOOTMEM
[    0.000000]   #17 [0100006000 - 0100007000]         BOOTMEM
[    0.000000]   #18 [0100200000 - 0105600000]        MEMMAP 0
[    0.000000]   #19 [0001db1600 - 0001db1780]         BOOTMEM
[    0.000000]   #20 [0001db31c0 - 0001dcb1c0]         BOOTMEM
[    0.000000]   #21 [0001dcb1c0 - 0001de31c0]         BOOTMEM
[    0.000000]   #22 [0001de4000 - 0001de5000]         BOOTMEM
[    0.000000]   #23 [0001db1780 - 0001db17c1]         BOOTMEM
[    0.000000]   #24 [0001db1800 - 0001db1843]         BOOTMEM
[    0.000000]   #25 [0001db1880 - 0001db1b58]         BOOTMEM
[    0.000000]   #26 [0001db1b80 - 0001db1be8]         BOOTMEM
[    0.000000]   #27 [0001db1c00 - 0001db1c68]         BOOTMEM
[    0.000000]   #28 [0001db1c80 - 0001db1ce8]         BOOTMEM
[    0.000000]   #29 [0001db1d00 - 0001db1d68]         BOOTMEM
[    0.000000]   #30 [0001db1d80 - 0001db1de8]         BOOTMEM
[    0.000000]   #31 [0001db1e00 - 0001db1e68]         BOOTMEM
[    0.000000]   #32 [0001db1e80 - 0001db1ee8]         BOOTMEM
[    0.000000]   #33 [0001db1f00 - 0001db1f68]         BOOTMEM
[    0.000000]   #34 [0001db1f80 - 0001db1fe8]         BOOTMEM
[    0.000000]   #35 [0001de31c0 - 0001de3228]         BOOTMEM
[    0.000000]   #36 [0001de3240 - 0001de32a8]         BOOTMEM
[    0.000000]   #37 [0001de32c0 - 0001de3328]         BOOTMEM
[    0.000000]   #38 [0001de3340 - 0001de3360]         BOOTMEM
[    0.000000]   #39 [0001de3380 - 0001de33a0]         BOOTMEM
[    0.000000]   #40 [0001de33c0 - 0001de3442]         BOOTMEM
[    0.000000]   #41 [0001de3480 - 0001de3502]         BOOTMEM
[    0.000000]   #42 [0001e00000 - 0001e1b000]         BOOTMEM
[    0.000000]   #43 [0001e40000 - 0001e5b000]         BOOTMEM
[    0.000000]   #44 [0001e80000 - 0001e9b000]         BOOTMEM
[    0.000000]   #45 [0001ec0000 - 0001edb000]         BOOTMEM
[    0.000000]   #46 [0001f00000 - 0001f1b000]         BOOTMEM
[    0.000000]   #47 [0001f40000 - 0001f5b000]         BOOTMEM
[    0.000000]   #48 [0001f80000 - 0001f9b000]         BOOTMEM
[    0.000000]   #49 [0001fc0000 - 0001fdb000]         BOOTMEM
[    0.000000]   #50 [0001de3540 - 0001de3548]         BOOTMEM
[    0.000000]   #51 [0001de3580 - 0001de3588]         BOOTMEM
[    0.000000]   #52 [0001de35c0 - 0001de35e0]         BOOTMEM
[    0.000000]   #53 [0001de3600 - 0001de3640]         BOOTMEM
[    0.000000]   #54 [0001de3640 - 0001de3760]         BOOTMEM
[    0.000000]   #55 [0001de3780 - 0001de37c8]         BOOTMEM
[    0.000000]   #56 [0001de3800 - 0001de3848]         BOOTMEM
[    0.000000]   #57 [0001de5000 - 0001ded000]         BOOTMEM
[    0.000000]   #58 [0001fdb000 - 0005fdb000]         BOOTMEM
[    0.000000]   #59 [0001e1b000 - 0001e3b000]         BOOTMEM
[    0.000000]   #60 [0005fdb000 - 000601b000]         BOOTMEM
[    0.000000]   #61 [000000f000 - 0000017000]         BOOTMEM
[    0.000000] Memory: 6052848k/7274496k available (5380k kernel code, 1051016k absent, 170632k reserved, 6497k data, 612k init)
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:2304
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2394.304 MHz processor.
[    0.002006] Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.60 BogoMIPS (lpj=2394304)
[    0.004021] Security Framework initialized
[    0.005004] SELinux:  Initializing.
[    0.007326] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.013587] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.017337] Mount-cache hash table entries: 256
[    0.018184] Initializing cgroup subsys ns
[    0.019007] Initializing cgroup subsys cpuacct
[    0.020005] Initializing cgroup subsys blkio
[    0.021032] CPU: Physical Processor ID: 0
[    0.022002] CPU: Processor Core ID: 0
[    0.023003] using mwait in idle threads.
[    0.024002] Performance Events: Core2 events, Intel PMU driver.
[    0.027003] ... version:                2
[    0.028002] ... bit width:              40
[    0.029002] ... generic registers:      2
[    0.030002] ... value mask:             000000ffffffffff
[    0.031002] ... max period:             000000007fffffff
[    0.032002] ... fixed-purpose events:   3
[    0.033002] ... event mask:             0000000700000003
[    0.034040] ACPI: Core revision 20100121
[    0.201068] Setting APIC routing to flat
[    0.202470] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.213197] CPU0: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
[    0.216999] Booting Node   0, Processors  #1 #2 #3
[    0.433006] Brought up 4 CPUs
[    0.434002] Total of 4 processors activated (19151.91 BogoMIPS).
[    0.437075] khelper used greatest stack depth: 6008 bytes left
[    0.444149] Time: 23:55:01  Date: 04/09/10
[    0.445044] NET: Registered protocol family 16
[    0.446035] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.447007] ACPI: bus type pci registered
[    0.448043] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.449002] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.470983] PCI: Using configuration type 1 for base access
[    0.483039] bio: create slab <bio-0> at 0
[    0.516503] ACPI: BIOS _OSI(Linux) query ignored
[    0.563293] ACPI: Interpreter enabled
[    0.568002] ACPI: (supports S0 S1 S3 S4 S5)
[    0.572003] ACPI: Using IOAPIC for interrupt routing
[    0.766034] ACPI Warning: Incorrect checksum in table [TCPA] - 00, should be 87 (20100121/tbutils-314)
[    0.775104] ACPI: No dock devices found.
[    0.779003] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.799048] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.825300] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.832002] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.838002] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.846002] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
[    0.853001] pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]
[    0.861002] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
[    0.868001] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
[    0.876002] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
[    0.883001] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
[    0.891001] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]
[    0.899016] pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO
[    0.907003] pci 0000:00:1f.0: quirk: [io  0x0880-0x08bf] claimed by ICH6 GPIO
[    0.914003] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0c00 (mask 007f)
[    0.922002] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 00e0 (mask 0007)
[    0.930258] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.935023] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    0.941051] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    0.946090] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    0.951161] pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
[    2.995364] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
[    3.004002] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
[    3.011620] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    3.020237] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    3.030230] ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    3.038785] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    3.048791] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[    3.056474] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[    3.065209] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    3.073003] vgaarb: loaded
[    3.076075] SCSI subsystem initialized
[    3.081011] usbcore: registered new interface driver usbfs
[    3.086018] usbcore: registered new interface driver hub
[    3.092022] usbcore: registered new device driver usb
[    3.097025] Advanced Linux Sound Architecture Driver Version 1.0.22.1.
[    3.104002] PCI: Using ACPI for IRQ routing
[    3.108037] pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
[    3.116042] Expanded resource reserved due to conflict with PCI Bus 0000:00
[    3.124045] cfg80211: Calling CRDA to update world regulatory domain
[    3.130016] NetLabel: Initializing
[    3.134001] NetLabel:  domain hash size = 128
[    3.138001] NetLabel:  protocols = UNLABELED CIPSOv4
[    3.143010] NetLabel:  unlabeled traffic allowed by default
[    3.149004] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[    3.156005] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    3.161692] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[    3.170024] Switching to clocksource tsc
[    3.183742] pnp: PnP ACPI init
[    3.186998] ACPI: bus type pnp registered
[    3.208023] pnp 00:01: disabling [io  0x0800-0x085f] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    3.218418] pnp 00:01: disabling [io  0x0860-0x08ff] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    3.293516] pnp: PnP ACPI: found 12 devices
[    3.297879] ACPI: ACPI bus type pnp unregistered
[    3.302680] system 00:01: [io  0x0c00-0x0c7f] has been reserved
[    3.314171] pci 0000:00:1c.0: BAR 9: assigned [mem 0xf0000000-0xf01fffff 64bit pref]
[    3.322237] pci 0000:00:1c.5: BAR 9: assigned [mem 0xf0200000-0xf03fffff 64bit pref]
[    3.330300] pci 0000:00:1c.0: BAR 7: assigned [io  0x1000-0x1fff]
[    3.336565] pci 0000:00:1c.5: BAR 7: assigned [io  0x2000-0x2fff]
[    3.342830] pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
[    3.349790] pci 0000:00:1f.2: BAR 5: set to [mem 0x000a0000-0x000a07ff] (PCI address [0xa0000-0xa07ff]
[    3.360179] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    3.365578] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    3.371844] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfdefffff]
[    3.378803] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    3.386857] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    3.392260] pci 0000:00:06.0:   bridge window [io  disabled]
[    3.398102] pci 0000:00:06.0:   bridge window [mem disabled]
[    3.403935] pci 0000:00:06.0:   bridge window [mem pref disabled]
[    3.410211] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    3.415610] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    3.421878] pci 0000:00:1c.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
[    3.428837] pci 0000:00:1c.0:   bridge window [mem 0xf0000000-0xf01fffff 64bit pref]
[    3.436894] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    3.442295] pci 0000:00:1c.5:   bridge window [io  0x2000-0x2fff]
[    3.448561] pci 0000:00:1c.5:   bridge window [mem 0xf9e00000-0xf9efffff]
[    3.455520] pci 0000:00:1c.5:   bridge window [mem 0xf0200000-0xf03fffff 64bit pref]
[    3.463576] pci 0000:00:1e.0: PCI bridge to [bus 05-05]
[    3.468973] pci 0000:00:1e.0:   bridge window [io  disabled]
[    3.474808] pci 0000:00:1e.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
[    3.481767] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    3.488049] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.494927] pci 0000:00:06.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.501806] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.508690] pci 0000:00:1c.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    3.515661] NET: Registered protocol family 2
[    3.520411] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    3.529416] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    3.542003] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    3.549527] TCP: Hash tables configured (established 524288 bind 65536)
[    3.556315] TCP reno registered
[    3.559648] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    3.566012] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    3.572927] NET: Registered protocol family 1
[    3.577700] RPC: Registered udp transport module.
[    3.582583] RPC: Registered tcp transport module.
[    3.587463] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    4.706018] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[    4.713415] Trying to unpack rootfs image as initramfs...
[    4.783612] Freeing initrd memory: 3464k freed
[    4.789242] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    4.795854] Placing 64MB software IO TLB between ffff880001fdb000 - ffff880005fdb000
[    4.803893] software IO TLB at phys 0x1fdb000 - 0x5fdb000
[    4.809719] Simple Boot Flag at 0x7a set to 0x1
[    4.816694] microcode: CPU0 sig=0x6fb, pf=0x10, revision=0xb3
[    4.822621] microcode: CPU1 sig=0x6fb, pf=0x10, revision=0xb3
[    4.828542] microcode: CPU2 sig=0x6fb, pf=0x10, revision=0xb3
[    4.834458] microcode: CPU3 sig=0x6fb, pf=0x10, revision=0xb3
[    4.844024] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    4.853529] audit: initializing netlink socket (disabled)
[    4.859111] type=2000 audit(1270857303.859:1): initialized
[    4.884577] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    4.895294] VFS: Disk quotas dquot_6.5.2
[    4.899502] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    4.907401] msgmni has been set to 11828
[    4.912353] alg: No test for stdrng (krng)
[    4.916786] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    4.924497] io scheduler noop registered
[    4.928589] io scheduler deadline registered
[    4.933201] io scheduler cfq registered (default)
[    4.939255] pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS
[    4.946965] pcieport 0000:00:01.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.956133] pcie_pme: probe of 0000:00:01.0:pcie01 failed with error -13
[    4.962999] pcieport 0000:00:06.0: Requesting control of PCIe PME from ACPI BIOS
[    4.970695] pcieport 0000:00:06.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.979864] pcie_pme: probe of 0000:00:06.0:pcie01 failed with error -13
[    4.986729] pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS
[    4.994444] pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support
[    5.003611] pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13
[    5.010477] pcieport 0000:00:1c.5: Requesting control of PCIe PME from ACPI BIOS
[    5.018178] pcieport 0000:00:1c.5: Failed to receive control of PCIe PME service: no _OSC support
[    5.027365] pcie_pme: probe of 0000:00:1c.5:pcie01 failed with error -13
[    5.034367] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    5.040571] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    5.049245] ACPI: Power Button [VBTN]
[    5.053187] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    5.060888] ACPI: Power Button [PWRF]
[    5.165045] Non-volatile memory driver v1.3
[    5.169408] Linux agpgart interface v0.103
[    5.173908] [drm] Initialized drm 1.1.0 20060810
[    5.178694] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[    5.186481] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ÿ[    5.437337] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    5.444151] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    5.452860] brd: module loaded
[    5.457468] loop: module loaded
[    5.460916] Loading iSCSI transport class v2.0-870.
[    5.466610] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    5.473570] ahci 0000:00:1f.2: BAR 5: can't reserve [mem 0x000a0000-0x000a07ff]
[    5.481192] ahci: probe of 0000:00:1f.2 failed with error -16
[    5.487175] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[    5.493788] Copyright (c) 1999-2006 Intel Corporation.
[    5.499168] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    5.505433] e100: Copyright(c) 1999-2006 Intel Corporation
[    5.511176] tg3.c:v3.108 (February 17, 2010)
[    5.515625] tg3 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    5.532518] tg3 0000:04:00.0: eth0: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address 00:1e:c9:3c:35:1e
[    5.543169] tg3 0000:04:00.0: eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1])
[    5.552595] tg3 0000:04:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    5.560811] tg3 0000:04:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[    5.567831] sky2: driver version 1.27
[    5.571882] console [netcon0] enabled
[    5.575722] netconsole: network logging started
[    5.580654] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    5.587371] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 22 (level, low) -> IRQ 22
[    5.594681] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[    5.600181] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[    5.607915] ehci_hcd 0000:00:1a.7: debug port 1
[    5.616516] ehci_hcd 0000:00:1a.7: irq 22, io mem 0xfdffbc00
[    5.632068] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[    5.638012] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    5.644964] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.652485] usb usb1: Product: EHCI Host Controller
[    5.657529] usb usb1: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac ehci_hcd
[    5.664740] usb usb1: SerialNumber: 0000:00:1a.7
[    5.669727] hub 1-0:1.0: USB hub found
[    5.673649] hub 1-0:1.0: 6 ports detected
[    5.677901] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    5.685220] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    5.690700] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[    5.698438] ehci_hcd 0000:00:1d.7: debug port 1
[    5.707052] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xff980800
[    5.722067] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    5.728011] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    5.734962] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.742483] usb usb2: Product: EHCI Host Controller
[    5.747528] usb usb2: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac ehci_hcd
[    5.754740] usb usb2: SerialNumber: 0000:00:1d.7
[    5.759711] hub 2-0:1.0: USB hub found
[    5.763633] hub 2-0:1.0: 6 ports detected
[    5.767938] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    5.774376] uhci_hcd: USB Universal Host Controller Interface driver
[    5.781044] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    5.788348] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[    5.793830] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[    5.801534] uhci_hcd 0000:00:1a.0: detected 2 ports
[    5.806607] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000ff20
[    5.812551] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    5.819503] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.827025] usb usb3: Product: UHCI Host Controller
[    5.832071] usb usb3: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac uhci_hcd
[    5.839292] usb usb3: SerialNumber: 0000:00:1a.0
[    5.844261] hub 3-0:1.0: USB hub found
[    5.848193] hub 3-0:1.0: 2 ports detected
[    5.852434] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    5.859738] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[    5.865247] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[    5.872968] uhci_hcd 0000:00:1a.1: detected 2 ports
[    5.878042] uhci_hcd 0000:00:1a.1: irq 17, io base 0x0000ff00
[    5.883986] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    5.890938] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.898471] usb usb4: Product: UHCI Host Controller
[    5.903515] usb usb4: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac uhci_hcd
[    5.910726] usb usb4: SerialNumber: 0000:00:1a.1
[    5.915693] hub 4-0:1.0: USB hub found
[    5.919614] hub 4-0:1.0: 2 ports detected
[    5.923858] uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
[    5.931173] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    5.936651] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    5.944366] uhci_hcd 0000:00:1a.2: detected 2 ports
[    5.949430] uhci_hcd 0000:00:1a.2: irq 22, io base 0x0000ecc0
[    5.955411] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    5.962365] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.969886] usb usb5: Product: UHCI Host Controller
[    5.974932] usb usb5: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac uhci_hcd
[    5.982155] usb usb5: SerialNumber: 0000:00:1a.2
[    5.987186] hub 5-0:1.0: USB hub found
[    5.991113] hub 5-0:1.0: 2 ports detected
[    5.995372] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    6.002678] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    6.008165] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[    6.015879] uhci_hcd 0000:00:1d.0: detected 2 ports
[    6.020949] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000ff80
[    6.026896] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[    6.033849] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.041381] usb usb6: Product: UHCI Host Controller
[    6.046427] usb usb6: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac uhci_hcd
[    6.053638] usb usb6: SerialNumber: 0000:00:1d.0
[    6.058611] hub 6-0:1.0: USB hub found
[    6.062536] hub 6-0:1.0: 2 ports detected
[    6.066786] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    6.074092] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    6.079575] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[    6.087292] uhci_hcd 0000:00:1d.1: detected 2 ports
[    6.092364] uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000ff60
[    6.098343] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[    6.105304] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.112825] usb usb7: Product: UHCI Host Controller
[    6.117870] usb usb7: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac uhci_hcd
[    6.125081] usb usb7: SerialNumber: 0000:00:1d.1
[    6.130066] hub 7-0:1.0: USB hub found
[    6.133992] hub 7-0:1.0: 2 ports detected
[    6.138258] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    6.145562] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    6.151042] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[    6.158749] uhci_hcd 0000:00:1d.2: detected 2 ports
[    6.167443] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ff40
[    6.173392] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[    6.180345] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.187866] usb usb8: Product: UHCI Host Controller
[    6.192911] usb usb8: Manufacturer: Linux 2.6.34-rc3-00411-g9e969ac uhci_hcd
[    6.200122] usb usb8: SerialNumber: 0000:00:1d.2
[    6.205127] hub 8-0:1.0: USB hub found
[    6.209053] hub 8-0:1.0: 2 ports detected
[    6.213446] usbcore: registered new interface driver usblp
[    6.219101] Initializing USB Mass Storage driver...
[    6.224250] usbcore: registered new interface driver usb-storage
[    6.230434] USB Mass Storage support registered.
[    6.235321] usbcore: registered new interface driver libusual
[    6.241427] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[    6.251889] serio: i8042 KBD port at 0x60,0x64 irq 1
[    6.257032] serio: i8042 AUX port at 0x60,0x64 irq 12
[    6.262436] mice: PS/2 mouse device common for all mice
[    6.268205] rtc_cmos 00:05: RTC can wake from S4
[    6.273095] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    6.279387] rtc0: alarms up to one day, 242 bytes nvram, hpet irqs
[    6.285824] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    6.294015] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com
[    6.302969] cpuidle: using governor ladder
[    6.307257] cpuidle: using governor menu
[    6.310682] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    6.320292] No iBFT detected.
[    6.325425] usbcore: registered new interface driver hiddev
[    6.331256] usbcore: registered new interface driver usbhid
[    6.337009] usbhid: USB HID core driver
modprobe: FATAL: Could not load /lib/modules/2.6.34-rc3-00411-g9e969ac/modules.dep: No such file or directory

[    6.355139] modprobe used greatest stack depth: 5840 bytes left
[    6.361316] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    6.443231] usb 7-2: new low speed USB device using uhci_hcd and address 2
[    6.507523] logips2pp: Detected unknown logitech mouse model 89
[    6.597287] usb 7-2: New USB device found, idVendor=0430, idProduct=0005
[    6.604170] usb 7-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    6.628613] input: HID 0430:0005 as /devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/input/input3
[    6.638022] generic-usb 0003:0430:0005.0001: input,hidraw0: USB HID v1.00 Keyboard [HID 0430:0005] on usb-0000:00:1d.1-2/input0
[    6.739042] ALSA device list:
[    6.742193]   #0: HDA Intel at 0xfdffc000 irq 28
[    6.747032] Netfilter messages via NETLINK v0.30.
[    6.751919] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    6.758391] ctnetlink v0.93: registering with nfnetlink.
[    6.764296] ip_tables: (C) 2000-2006 Netfilter Core Team
[    6.769808] TCP cubic registered
[    6.773208] Initializing XFRM netlink socket
[    6.778110] NET: Registered protocol family 10
[    6.783441] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    6.789052] IPv6 over IPv4 tunneling driver
[    6.793928] NET: Registered protocol family 17
[    6.798843] registered taskstats version 1
[    6.803368]   Magic number: 6:993:958
[    6.807243] mem oldmem: hash matches
[    6.811163] Freeing unused kernel memory: 612k freed
[    6.816449] Write protecting the kernel read-only data: 10240k
[    6.822639] Freeing unused kernel memory: 744k freed
[    6.828085] Freeing unused kernel memory: 1588k freed

-andy

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

in addition to -v2 patch

please apply this patch too

also please boot with "debug" in boot command line.

Thanks

Yinghai

[PATCH] x86,acpi: use request_resource instead of instead of insert_resource

So make pci root resouce from _CRS honor the one We reserve in e820 below 1M

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/acpi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/arch/x86/pci/acpi.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -168,7 +168,7 @@ setup_resource(struct acpi_resource *acp
 		return AE_OK;
 	}
 
-	conflict = insert_resource_conflict(root, res);
+	conflict = request_resource_conflict(root, res);
 	if (conflict) {
 		dev_err(&info->bridge->dev,
 			"address space collision: host bridge window %pR "

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

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

On Fri, Apr 09, 2010 at 06:10:49PM -0700, Yinghai wrote:
> in addition to -v2 patch
> 
> please apply this patch too
> 
> also please boot with "debug" in boot command line.
> 
> Thanks
> 
> Yinghai
> 
> [PATCH] x86,acpi: use request_resource instead of instead of insert_resource
> 
> So make pci root resouce from _CRS honor the one We reserve in e820 below 1M
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/pci/acpi.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6/arch/x86/pci/acpi.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/acpi.c
> +++ linux-2.6/arch/x86/pci/acpi.c
> @@ -168,7 +168,7 @@ setup_resource(struct acpi_resource *acp
>  		return AE_OK;
>  	}
>  
> -	conflict = insert_resource_conflict(root, res);
> +	conflict = request_resource_conflict(root, res);
>  	if (conflict) {
>  		dev_err(&info->bridge->dev,
>  			"address space collision: host bridge window %pR "

That works.  dmesg.gz attached (I'm pretty sure I'm skating close to
vger's size limit without gz).  "debug" didn't seem to make much
difference?

-andy

[-- Attachment #2: dmesg.gz --]
[-- Type: application/octet-stream, Size: 17250 bytes --]

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/09/2010 06:43 PM, Andy Isaacson wrote:
> On Fri, Apr 09, 2010 at 06:10:49PM -0700, Yinghai wrote:
>> in addition to -v2 patch
>>
>> please apply this patch too
>>
>> also please boot with "debug" in boot command line.
>>
>> Thanks
>>
>> Yinghai
>>
>> [PATCH] x86,acpi: use request_resource instead of instead of insert_resource
>>
>> So make pci root resouce from _CRS honor the one We reserve in e820 below 1M
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>
>> ---
>>  arch/x86/pci/acpi.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: linux-2.6/arch/x86/pci/acpi.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/pci/acpi.c
>> +++ linux-2.6/arch/x86/pci/acpi.c
>> @@ -168,7 +168,7 @@ setup_resource(struct acpi_resource *acp
>>  		return AE_OK;
>>  	}
>>  
>> -	conflict = insert_resource_conflict(root, res);
>> +	conflict = request_resource_conflict(root, res);
>>  	if (conflict) {
>>  		dev_err(&info->bridge->dev,
>>  			"address space collision: host bridge window %pR "
> 
> That works.  dmesg.gz attached (I'm pretty sure I'm skating close to
> vger's size limit without gz).  "debug" didn't seem to make much
> difference?

[    0.636805] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.654025] pci_root PNP0A03:00: address space collision: host bridge window [io  0x0000-0x0cf7] conflicts with dma1 [io  0x0000-0x001f]
[    0.654370] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.654586] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000a0000-0x000bffff] conflicts with reserved [mem 0x000a0000-0x000fffff]
[    0.654933] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000c0000-0x000effff] conflicts with reserved [mem 0x000a0000-0x000fffff]
[    0.655002] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000f0000-0x000fffff] conflicts with reserved [mem 0x000a0000-0x000fffff]
[    0.655367] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
[    0.655706] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
[    0.656003] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
[    0.656360] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
[    0.657002] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]

still not optimal.

YH

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Fri, Apr 09, 2010 at 06:48:31PM -0700, Yinghai wrote:
> On 04/09/2010 06:43 PM, Andy Isaacson wrote:
> > On Fri, Apr 09, 2010 at 06:10:49PM -0700, Yinghai wrote:
> >> in addition to -v2 patch
> >>
> >> please apply this patch too
> >>
> >> also please boot with "debug" in boot command line.
> >>
> >> Thanks
> >>
> >> Yinghai
> >>
> >> [PATCH] x86,acpi: use request_resource instead of instead of insert_resource
> >>
> >> So make pci root resouce from _CRS honor the one We reserve in e820 below 1M
> >>
> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> >>
> >> ---
> >>  arch/x86/pci/acpi.c |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> Index: linux-2.6/arch/x86/pci/acpi.c
> >> ===================================================================
> >> --- linux-2.6.orig/arch/x86/pci/acpi.c
> >> +++ linux-2.6/arch/x86/pci/acpi.c
> >> @@ -168,7 +168,7 @@ setup_resource(struct acpi_resource *acp
> >>  		return AE_OK;
> >>  	}
> >>  
> >> -	conflict = insert_resource_conflict(root, res);
> >> +	conflict = request_resource_conflict(root, res);
> >>  	if (conflict) {
> >>  		dev_err(&info->bridge->dev,
> >>  			"address space collision: host bridge window %pR "
> > 
> > That works.  dmesg.gz attached (I'm pretty sure I'm skating close to
> > vger's size limit without gz).  "debug" didn't seem to make much
> > difference?
> 
> [    0.636805] ACPI: PCI Root Bridge [PCI0] (0000:00)
> [    0.654025] pci_root PNP0A03:00: address space collision: host bridge window [io  0x0000-0x0cf7] conflicts with dma1 [io  0x0000-0x001f]
> [    0.654370] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
> [    0.654586] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000a0000-0x000bffff] conflicts with reserved [mem 0x000a0000-0x000fffff]
> [    0.654933] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000c0000-0x000effff] conflicts with reserved [mem 0x000a0000-0x000fffff]
> [    0.655002] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000f0000-0x000fffff] conflicts with reserved [mem 0x000a0000-0x000fffff]
> [    0.655367] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
> [    0.655706] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
> [    0.656003] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
> [    0.656360] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
> [    0.657002] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]
> 
> still not optimal.

Well, thanks for looking at it; if there are any more patches I can try,
let me know (but I may not get to it until Monday morning, since I can't
reliably reboot this machine remotely).

Is this a BIOS error?  I am currently running A04; there's an A10
available, but I didn't want to perturb the situation during the
debugging cycle without guidance.

-andy

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/09/2010 06:57 PM, Andy Isaacson wrote:
> On Fri, Apr 09, 2010 at 06:48:31PM -0700, Yinghai wrote:
>> On 04/09/2010 06:43 PM, Andy Isaacson wrote:
>>> On Fri, Apr 09, 2010 at 06:10:49PM -0700, Yinghai wrote:
>>>> in addition to -v2 patch
>>>>
>>>> please apply this patch too
>>>>
>>>> also please boot with "debug" in boot command line.
>>>>
>>>> Thanks
>>>>
>>>> Yinghai
>>>>
>>>> [PATCH] x86,acpi: use request_resource instead of instead of insert_resource
>>>>
>>>> So make pci root resouce from _CRS honor the one We reserve in e820 below 1M
>>>>
>>>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>>>
>>>> ---
>>>>  arch/x86/pci/acpi.c |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> Index: linux-2.6/arch/x86/pci/acpi.c
>>>> ===================================================================
>>>> --- linux-2.6.orig/arch/x86/pci/acpi.c
>>>> +++ linux-2.6/arch/x86/pci/acpi.c
>>>> @@ -168,7 +168,7 @@ setup_resource(struct acpi_resource *acp
>>>>  		return AE_OK;
>>>>  	}
>>>>  
>>>> -	conflict = insert_resource_conflict(root, res);
>>>> +	conflict = request_resource_conflict(root, res);
>>>>  	if (conflict) {
>>>>  		dev_err(&info->bridge->dev,
>>>>  			"address space collision: host bridge window %pR "
>>>
>>> That works.  dmesg.gz attached (I'm pretty sure I'm skating close to
>>> vger's size limit without gz).  "debug" didn't seem to make much
>>> difference?
>>
>> [    0.636805] ACPI: PCI Root Bridge [PCI0] (0000:00)
>> [    0.654025] pci_root PNP0A03:00: address space collision: host bridge window [io  0x0000-0x0cf7] conflicts with dma1 [io  0x0000-0x001f]
>> [    0.654370] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
>> [    0.654586] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000a0000-0x000bffff] conflicts with reserved [mem 0x000a0000-0x000fffff]
>> [    0.654933] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000c0000-0x000effff] conflicts with reserved [mem 0x000a0000-0x000fffff]
>> [    0.655002] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000f0000-0x000fffff] conflicts with reserved [mem 0x000a0000-0x000fffff]
>> [    0.655367] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
>> [    0.655706] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
>> [    0.656003] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
>> [    0.656360] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
>> [    0.657002] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]
>>
>> still not optimal.
> 
> Well, thanks for looking at it; if there are any more patches I can try,
> let me know (but I may not get to it until Monday morning, since I can't
> reliably reboot this machine remotely).
> 
> Is this a BIOS error?  I am currently running A04; there's an A10
> available, but I didn't want to perturb the situation during the
> debugging cycle without guidance.

thanks.

please use this one replace second patch
[PATCH] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus

So make pci root resource from _CRS honor the range We reserve in e820 below 1M

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/acpi.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/arch/x86/pci/acpi.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -175,6 +175,10 @@ setup_resource(struct acpi_resource *acp
 			"conflicts with %s %pR\n",
 			res, conflict->name, conflict);
 	} else {
+		/* In case it falls in big reserved region */
+		if (res->parent->flags & IORESOURCE_BUSY)
+			res->flags |= IORESOURCE_BUSY;
+
 		pci_bus_add_resource(info->bus, res, 0);
 		info->res_num++;
 		if (addr.translation_offset)

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Fri, Apr 09, 2010 at 07:46:04PM -0700, Yinghai wrote:
> please use this one replace second patch
> [PATCH] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus
> 
> So make pci root resource from _CRS honor the range We reserve in e820 below 1M
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/pci/acpi.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> Index: linux-2.6/arch/x86/pci/acpi.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/acpi.c
> +++ linux-2.6/arch/x86/pci/acpi.c
> @@ -175,6 +175,10 @@ setup_resource(struct acpi_resource *acp
>  			"conflicts with %s %pR\n",
>  			res, conflict->name, conflict);
>  	} else {
> +		/* In case it falls in big reserved region */
> +		if (res->parent->flags & IORESOURCE_BUSY)
> +			res->flags |= IORESOURCE_BUSY;
> +
>  		pci_bus_add_resource(info->bus, res, 0);

That doesn't work:

[    0.000000] Linux version 2.6.34-rc3-00412-gef61642 (andy@farthing) (gcc version 4.3.3 (Debian 4.3.3-5) ) #13 SMP Mon Apr 12 11:12:43 PDT 2010
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00412-gef61642 root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro console=tty0 console=ttyS0,115200
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfe01c00 (usable)
[    0.000000]  BIOS-e820: 00000000bfe01c00 - 00000000bfe53c00 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bfe53c00 - 00000000bfe55c00 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bfe55c00 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 00000001bc000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x1bc000 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] last_pfn = 0xbfe01 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000fe710] fe710
[    0.000000] init_memory_mapping: 0000000000000000-00000000bfe01000
[    0.000000] init_memory_mapping: 0000000100000000-00000001bc000000
[    0.000000] RAMDISK: 37c8e000 - 37ff0000
[    0.000000] ACPI: RSDP 00000000000febf0 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000fcea4 0006C (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: FACP 00000000000fcfcc 000F4 (v03 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: DSDT 00000000fff5aafd 03794 (v01   DELL    dt_ex 00001000 INTL 20050624)
[    0.000000] ACPI: FACS 00000000bfe01c00 00040
[    0.000000] ACPI: SSDT 00000000fff5e291 00099 (v01   DELL    st_ex 00001000 INTL 20050624)
[    0.000000] ACPI: APIC 00000000000fd0c0 00092 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: BOOT 00000000000fd152 00028 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: ASF! 00000000000fd17a 00096 (v32 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: MCFG 00000000000fd210 0003E (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: HPET 00000000000fd24e 00038 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: TCPA 00000000000fd4aa 00032 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: SLIC 00000000000fd286 00176 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000001bc000000
[    0.000000] Initmem setup node 0 0000000000000000-00000001bc000000
[    0.000000]   NODE_DATA [0000000100000000 - 0000000100004fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000001 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x001bc000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000001 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x000bfe01
[    0.000000]     0: 0x00100000 -> 0x001bc000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000bfe01000 - 00000000bfe02000
[    0.000000] PM: Registered nosave memory: 00000000bfe02000 - 00000000bfe53000
[    0.000000] PM: Registered nosave memory: 00000000bfe53000 - 00000000bfe54000
[    0.000000] PM: Registered nosave memory: 00000000bfe54000 - 00000000bfe55000
[    0.000000] PM: Registered nosave memory: 00000000bfe55000 - 00000000bfe56000
[    0.000000] PM: Registered nosave memory: 00000000bfe56000 - 00000000c0000000
[    0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000e0000000
[    0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000f0000000
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000
[    0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
[    0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff880001e00000 s81896 r8192 d20504 u262144
[    0.000000] pcpu-alloc: s81896 r8192 d20504 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1531006
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00412-gef61642 root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro console=tty0 console=ttyS0,115200
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (62 early reservations)
[    0.000000]   #1 [0001000000 - 0001db1168]   TEXT DATA BSS
[    0.000000]   #2 [0037c8e000 - 0037ff0000]         RAMDISK
[    0.000000]   #3 [0001db2000 - 0001db21a8]             BRK
[    0.000000]   #4 [00000fe720 - 0000100000]   BIOS reserved
[    0.000000]   #5 [00000fe710 - 00000fe720]    MP-table mpf
[    0.000000]   #6 [000009ec00 - 00000f0000]   BIOS reserved
[    0.000000]   #7 [00000f0304 - 00000fe710]   BIOS reserved
[    0.000000]   #8 [00000f0000 - 00000f0304]    MP-table mpc
[    0.000000]   #9 [0000001000 - 0000003000]      TRAMPOLINE
[    0.000000]   #10 [0000003000 - 0000007000]     ACPI WAKEUP
[    0.000000]   #11 [0000008000 - 000000b000]         PGTABLE
[    0.000000]   #12 [000000b000 - 000000e000]         PGTABLE
[    0.000000]   #13 [0100000000 - 0100005000]       NODE_DATA
[    0.000000]   #14 [0001db21c0 - 0001db31c0]         BOOTMEM
[    0.000000]   #15 [0001db1180 - 0001db1600]         BOOTMEM
[    0.000000]   #16 [0100005000 - 0100006000]         BOOTMEM
[    0.000000]   #17 [0100006000 - 0100007000]         BOOTMEM
[    0.000000]   #18 [0100200000 - 0105600000]        MEMMAP 0
[    0.000000]   #19 [0001db1600 - 0001db1780]         BOOTMEM
[    0.000000]   #20 [0001db31c0 - 0001dcb1c0]         BOOTMEM
[    0.000000]   #21 [0001dcb1c0 - 0001de31c0]         BOOTMEM
[    0.000000]   #22 [0001de4000 - 0001de5000]         BOOTMEM
[    0.000000]   #23 [0001db1780 - 0001db17c1]         BOOTMEM
[    0.000000]   #24 [0001db1800 - 0001db1843]         BOOTMEM
[    0.000000]   #25 [0001db1880 - 0001db1b58]         BOOTMEM
[    0.000000]   #26 [0001db1b80 - 0001db1be8]         BOOTMEM
[    0.000000]   #27 [0001db1c00 - 0001db1c68]         BOOTMEM
[    0.000000]   #28 [0001db1c80 - 0001db1ce8]         BOOTMEM
[    0.000000]   #29 [0001db1d00 - 0001db1d68]         BOOTMEM
[    0.000000]   #30 [0001db1d80 - 0001db1de8]         BOOTMEM
[    0.000000]   #31 [0001db1e00 - 0001db1e68]         BOOTMEM
[    0.000000]   #32 [0001db1e80 - 0001db1ee8]         BOOTMEM
[    0.000000]   #33 [0001db1f00 - 0001db1f68]         BOOTMEM
[    0.000000]   #34 [0001db1f80 - 0001db1fe8]         BOOTMEM
[    0.000000]   #35 [0001de31c0 - 0001de3228]         BOOTMEM
[    0.000000]   #36 [0001de3240 - 0001de32a8]         BOOTMEM
[    0.000000]   #37 [0001de32c0 - 0001de3328]         BOOTMEM
[    0.000000]   #38 [0001de3340 - 0001de3360]         BOOTMEM
[    0.000000]   #39 [0001de3380 - 0001de33a0]         BOOTMEM
[    0.000000]   #40 [0001de33c0 - 0001de3442]         BOOTMEM
[    0.000000]   #41 [0001de3480 - 0001de3502]         BOOTMEM
[    0.000000]   #42 [0001e00000 - 0001e1b000]         BOOTMEM
[    0.000000]   #43 [0001e40000 - 0001e5b000]         BOOTMEM
[    0.000000]   #44 [0001e80000 - 0001e9b000]         BOOTMEM
[    0.000000]   #45 [0001ec0000 - 0001edb000]         BOOTMEM
[    0.000000]   #46 [0001f00000 - 0001f1b000]         BOOTMEM
[    0.000000]   #47 [0001f40000 - 0001f5b000]         BOOTMEM
[    0.000000]   #48 [0001f80000 - 0001f9b000]         BOOTMEM
[    0.000000]   #49 [0001fc0000 - 0001fdb000]         BOOTMEM
[    0.000000]   #50 [0001de3540 - 0001de3548]         BOOTMEM
[    0.000000]   #51 [0001de3580 - 0001de3588]         BOOTMEM
[    0.000000]   #52 [0001de35c0 - 0001de35e0]         BOOTMEM
[    0.000000]   #53 [0001de3600 - 0001de3640]         BOOTMEM
[    0.000000]   #54 [0001de3640 - 0001de3760]         BOOTMEM
[    0.000000]   #55 [0001de3780 - 0001de37c8]         BOOTMEM
[    0.000000]   #56 [0001de3800 - 0001de3848]         BOOTMEM
[    0.000000]   #57 [0001de5000 - 0001ded000]         BOOTMEM
[    0.000000]   #58 [0001fdb000 - 0005fdb000]         BOOTMEM
[    0.000000]   #59 [0001e1b000 - 0001e3b000]         BOOTMEM
[    0.000000]   #60 [0005fdb000 - 000601b000]         BOOTMEM
[    0.000000]   #61 [000000f000 - 0000017000]         BOOTMEM
[    0.000000] Memory: 6052848k/7274496k available (5380k kernel code, 1051016k absent, 170632k reserved, 6497k data, 612k init)
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:2304
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2393.926 MHz processor.
[    0.002006] Calibrating delay loop (skipped), value calculated using timer frequency.. 4787.85 BogoMIPS (lpj=2393926)
[    0.004021] Security Framework initialized
[    0.005004] SELinux:  Initializing.
[    0.007340] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.013595] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.017347] Mount-cache hash table entries: 256
[    0.018186] Initializing cgroup subsys ns
[    0.019007] Initializing cgroup subsys cpuacct
[    0.020005] Initializing cgroup subsys blkio
[    0.021032] CPU: Physical Processor ID: 0
[    0.022002] CPU: Processor Core ID: 0
[    0.023003] using mwait in idle threads.
[    0.024002] Performance Events: Core2 events, Intel PMU driver.
[    0.027003] ... version:                2
[    0.028002] ... bit width:              40
[    0.029002] ... generic registers:      2
[    0.030002] ... value mask:             000000ffffffffff
[    0.031002] ... max period:             000000007fffffff
[    0.032002] ... fixed-purpose events:   3
[    0.033002] ... event mask:             0000000700000003
[    0.034039] ACPI: Core revision 20100121
[    0.201613] Setting APIC routing to flat
[    0.203194] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.214375] CPU0: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
[    0.217999] Booting Node   0, Processors  #1 #2 #3
[    0.434006] Brought up 4 CPUs
[    0.435002] Total of 4 processors activated (19151.15 BogoMIPS).
[    0.437105] khelper used greatest stack depth: 6008 bytes left
[    0.444410] Time: 18:31:15  Date: 04/12/10
[    0.445034] NET: Registered protocol family 16
[    0.446035] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.447007] ACPI: bus type pci registered
[    0.448043] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.449002] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.471880] PCI: Using configuration type 1 for base access
[    0.484044] bio: create slab <bio-0> at 0
[    0.517496] ACPI: BIOS _OSI(Linux) query ignored
[    0.564286] ACPI: Interpreter enabled
[    0.568002] ACPI: (supports S0 S1 S3 S4 S5)
[    0.572787] ACPI: Using IOAPIC for interrupt routing
[    0.768235] ACPI Warning: Incorrect checksum in table [TCPA] - 00, should be 87 (20100121/tbutils-314)
[    0.778105] ACPI: No dock devices found.
[    0.782003] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.802383] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.828187] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.834002] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.841002] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.849001] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
[    0.856002] pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]
[    0.864002] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
[    0.871002] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
[    0.878002] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
[    0.886001] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
[    0.893001] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]
[    0.901888] pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO
[    0.910003] pci 0000:00:1f.0: quirk: [io  0x0880-0x08bf] claimed by ICH6 GPIO
[    0.917003] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0c00 (mask 007f)
[    0.925003] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 00e0 (mask 0007)
[    0.933265] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.938034] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    0.944052] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    0.949184] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    0.954146] pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
[    2.992616] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
[    3.000443] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
[    3.009073] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    3.017695] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    3.027703] ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    3.036307] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    3.045337] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[    3.053793] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[    3.062035] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    3.071003] vgaarb: loaded
[    3.074034] SCSI subsystem initialized
[    3.078023] usbcore: registered new interface driver usbfs
[    3.084007] usbcore: registered new interface driver hub
[    3.089020] usbcore: registered new device driver usb
[    3.094025] Advanced Linux Sound Architecture Driver Version 1.0.22.1.
[    3.101002] PCI: Using ACPI for IRQ routing
[    3.105037] pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
[    3.114047] Expanded resource reserved due to conflict with PCI Bus 0000:00
[    3.121071] cfg80211: Calling CRDA to update world regulatory domain
[    3.127017] NetLabel: Initializing
[    3.131001] NetLabel:  domain hash size = 128
[    3.135001] NetLabel:  protocols = UNLABELED CIPSOv4
[    3.140011] NetLabel:  unlabeled traffic allowed by default
[    3.146004] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[    3.153004] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    3.158393] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[    3.168022] Switching to clocksource tsc
[    3.181767] pnp: PnP ACPI init
[    3.185027] ACPI: bus type pnp registered
[    3.206083] pnp 00:01: disabling [io  0x0800-0x085f] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    3.216482] pnp 00:01: disabling [io  0x0860-0x08ff] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    3.291583] pnp: PnP ACPI: found 12 devices
[    3.295946] ACPI: ACPI bus type pnp unregistered
[    3.300748] system 00:01: [io  0x0c00-0x0c7f] has been reserved
[    3.312250] pci 0000:00:1c.0: BAR 9: assigned [mem 0xf0000000-0xf01fffff 64bit pref]
[    3.320319] pci 0000:00:1c.5: BAR 9: assigned [mem 0xf0200000-0xf03fffff 64bit pref]
[    3.328379] pci 0000:00:1c.0: BAR 7: assigned [io  0x1000-0x1fff]
[    3.334645] pci 0000:00:1c.5: BAR 7: assigned [io  0x2000-0x2fff]
[    3.340912] pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
[    3.347874] pci 0000:00:1f.2: BAR 5: set to [mem 0x000a0000-0x000a07ff] (PCI address [0xa0000-0xa07ff]
[    3.357490] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    3.362891] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    3.369169] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfdefffff]
[    3.376141] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    3.384208] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    3.389608] pci 0000:00:06.0:   bridge window [io  disabled]
[    3.395442] pci 0000:00:06.0:   bridge window [mem disabled]
[    3.401276] pci 0000:00:06.0:   bridge window [mem pref disabled]
[    3.407543] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    3.412946] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    3.419218] pci 0000:00:1c.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
[    3.426188] pci 0000:00:1c.0:   bridge window [mem 0xf0000000-0xf01fffff 64bit pref]
[    3.434257] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    3.439658] pci 0000:00:1c.5:   bridge window [io  0x2000-0x2fff]
[    3.445926] pci 0000:00:1c.5:   bridge window [mem 0xf9e00000-0xf9efffff]
[    3.452888] pci 0000:00:1c.5:   bridge window [mem 0xf0200000-0xf03fffff 64bit pref]
[    3.460946] pci 0000:00:1e.0: PCI bridge to [bus 05-05]
[    3.466346] pci 0000:00:1e.0:   bridge window [io  disabled]
[    3.472191] pci 0000:00:1e.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
[    3.479162] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    3.485440] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.492320] pci 0000:00:06.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.499212] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.506106] pci 0000:00:1c.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    3.513081] NET: Registered protocol family 2
[    3.517821] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    3.526825] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    3.539418] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    3.546927] TCP: Hash tables configured (established 524288 bind 65536)
[    3.553715] TCP reno registered
[    3.557051] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    3.563418] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    3.570345] NET: Registered protocol family 1
[    3.575101] RPC: Registered udp transport module.
[    3.579983] RPC: Registered tcp transport module.
[    3.584866] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    4.703019] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[    4.710417] Trying to unpack rootfs image as initramfs...
[    4.780651] Freeing initrd memory: 3464k freed
[    4.786286] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    4.792900] Placing 64MB software IO TLB between ffff880001fdb000 - ffff880005fdb000
[    4.800942] software IO TLB at phys 0x1fdb000 - 0x5fdb000
[    4.806768] Simple Boot Flag at 0x7a set to 0x1
[    4.813742] microcode: CPU0 sig=0x6fb, pf=0x10, revision=0xb3
[    4.819672] microcode: CPU1 sig=0x6fb, pf=0x10, revision=0xb3
[    4.825597] microcode: CPU2 sig=0x6fb, pf=0x10, revision=0xb3
[    4.831521] microcode: CPU3 sig=0x6fb, pf=0x10, revision=0xb3
[    4.841109] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    4.850612] audit: initializing netlink socket (disabled)
[    4.856205] type=2000 audit(1271097077.856:1): initialized
[    4.881674] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    4.892424] VFS: Disk quotas dquot_6.5.2
[    4.896631] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    4.904525] msgmni has been set to 11828
[    4.909414] alg: No test for stdrng (krng)
[    4.913847] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    4.921553] io scheduler noop registered
[    4.925646] io scheduler deadline registered
[    4.930258] io scheduler cfq registered (default)
[    4.936330] pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS
[    4.944036] pcieport 0000:00:01.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.953225] pcie_pme: probe of 0000:00:01.0:pcie01 failed with error -13
[    4.960093] pcieport 0000:00:06.0: Requesting control of PCIe PME from ACPI BIOS
[    4.967790] pcieport 0000:00:06.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.976959] pcie_pme: probe of 0000:00:06.0:pcie01 failed with error -13
[    4.983828] pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS
[    4.991536] pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support
[    5.000704] pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13
[    5.007572] pcieport 0000:00:1c.5: Requesting control of PCIe PME from ACPI BIOS
[    5.015289] pcieport 0000:00:1c.5: Failed to receive control of PCIe PME service: no _OSC support
[    5.024476] pcie_pme: probe of 0000:00:1c.5:pcie01 failed with error -13
[    5.031480] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    5.037685] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    5.046360] ACPI: Power Button [VBTN]
[    5.050324] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    5.058026] ACPI: Power Button [PWRF]
[    5.162277] Non-volatile memory driver v1.3
[    5.166644] Linux agpgart interface v0.103
[    5.171228] [drm] Initialized drm 1.1.0 20060810
[    5.176016] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[    5.183799] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ÿ[    5.434353] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    5.441169] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    5.449894] brd: module loaded
[    5.454495] loop: module loaded
[    5.457942] Loading iSCSI transport class v2.0-870.
[    5.463672] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    5.470633] ahci 0000:00:1f.2: BAR 5: can't reserve [mem 0x000a0000-0x000a07ff]
[    5.478257] ahci: probe of 0000:00:1f.2 failed with error -16

-andy

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Yinghai]

On 04/12/2010 11:54 AM, Andy Isaacson wrote:
> On Fri, Apr 09, 2010 at 07:46:04PM -0700, Yinghai wrote:
> [    5.463672] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
> [    5.470633] ahci 0000:00:1f.2: BAR 5: can't reserve [mem 0x000a0000-0x000a07ff]
> [    5.478257] ahci: probe of 0000:00:1f.2 failed with error -16

please check

[PATCH] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus

So make pci root resource from _CRS honor the range We reserve in e820 below 1M
then  will not assign them to unsigned pci BAR

-v2: let pci_bus_alloc_resource() honor IORESOURCE_BUSY
     driver can not use those range, so skip it

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/acpi.c |    4 ++++
 drivers/pci/bus.c   |    4 ++++
 2 files changed, 8 insertions(+)

Index: linux-2.6/arch/x86/pci/acpi.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -175,6 +175,10 @@ setup_resource(struct acpi_resource *acp
 			"conflicts with %s %pR\n",
 			res, conflict->name, conflict);
 	} else {
+		/* In case it falls in big reserved region */
+		if (res->parent->flags & IORESOURCE_BUSY)
+			res->flags |= IORESOURCE_BUSY;
+
 		pci_bus_add_resource(info->bus, res, 0);
 		info->res_num++;
 		if (addr.translation_offset)
Index: linux-2.6/drivers/pci/bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -103,6 +103,10 @@ pci_bus_alloc_resource(struct pci_bus *b
 		if (!r)
 			continue;
 
+		/* Driver can not reserve it later, so don't use it */
+		if (r->flags & IORESOURCE_BUSY)
+			continue;
+
 		/* type_mask must match */
 		if ((res->flags ^ r->flags) & type_mask)
 			continue;

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Mon, Apr 12, 2010 at 12:34:49PM -0700, Yinghai wrote:
> On 04/12/2010 11:54 AM, Andy Isaacson wrote:
> > On Fri, Apr 09, 2010 at 07:46:04PM -0700, Yinghai wrote:
> > [    5.463672] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
> > [    5.470633] ahci 0000:00:1f.2: BAR 5: can't reserve [mem 0x000a0000-0x000a07ff]
> > [    5.478257] ahci: probe of 0000:00:1f.2 failed with error -16
> 
> please check
> 
> [PATCH] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus

What patches should I have applied?  I'm testing with d620a7cf from
linus' tree, plus your "reserve [0xa0000,0x1000000] in e820", plus this
patch.  Please let me know if I should be testing something else (or
just push a git head for me to pull, that would remove all the
uncertainty).

-andy

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[yinghai.lu]

On Apr 12, 2010, at 12:48 PM, Andy Isaacson <adi@hexapodia.org> wrote:

> On Mon, Apr 12, 2010 at 12:34:49PM -0700, Yinghai wrote:
>> On 04/12/2010 11:54 AM, Andy Isaacson wrote:
>>> On Fri, Apr 09, 2010 at 07:46:04PM -0700, Yinghai wrote:
>>> [    5.463672] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low)  
>>> -> IRQ 20
>>> [    5.470633] ahci 0000:00:1f.2: BAR 5: can't reserve [mem  
>>> 0x000a0000-0x000a07ff]
>>> [    5.478257] ahci: probe of 0000:00:1f.2 failed with error -16
>>
>> please check
>>
>> [PATCH] x86,pci, acpi: Inherent BUSY flag when setup_resource for  
>> root bus
>
> What patches should I have applied?  I'm testing with d620a7cf from
> linus' tree, plus your "reserve [0xa0000,0x1000000] in e820", plus  
> this
> patch.
Yes

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Mon, Apr 12, 2010 at 12:34:49PM -0700, Yinghai wrote:
> [PATCH] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus
> 
> So make pci root resource from _CRS honor the range We reserve in e820 below 1M
> then  will not assign them to unsigned pci BAR
> 
> -v2: let pci_bus_alloc_resource() honor IORESOURCE_BUSY
>      driver can not use those range, so skip it
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/pci/acpi.c |    4 ++++
>  drivers/pci/bus.c   |    4 ++++
>  2 files changed, 8 insertions(+)

Success:


[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.34-rc3-00412-gbb33c1c (andy@farthing) (gcc version 4.3.3 (Debian 4.3.3-5) ) #14 SMP Mon Apr 12 12:52:26 PDT 2010
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00412-gbb33c1c root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfe01c00 (usable)
[    0.000000]  BIOS-e820: 00000000bfe01c00 - 00000000bfe53c00 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bfe53c00 - 00000000bfe55c00 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bfe55c00 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 00000001bc000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x1bc000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-D3FFF write-protect
[    0.000000]   D4000-EFFFF uncachable
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000 mask 000000000 write-back
[    0.000000]   1 base 0BFF00000 mask FFFF00000 uncachable
[    0.000000]   2 base 0C0000000 mask FC0000000 uncachable
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] e820 update range: 00000000bff00000 - 0000000100000000 (usable) ==> (reserved)
[    0.000000] last_pfn = 0xbfe01 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] found SMP MP-table at [ffff8800000fe710] fe710
[    0.000000] init_memory_mapping: 0000000000000000-00000000bfe01000
[    0.000000]  0000000000 - 00bfe00000 page 2M
[    0.000000]  00bfe00000 - 00bfe01000 page 4k
[    0.000000] kernel direct mapping tables up to bfe01000 @ 8000-d000
[    0.000000] init_memory_mapping: 0000000100000000-00000001bc000000
[    0.000000]  0100000000 - 01bc000000 page 2M
[    0.000000] kernel direct mapping tables up to 1bc000000 @ b000-13000
[    0.000000] RAMDISK: 37c8e000 - 37ff0000
[    0.000000] ACPI: RSDP 00000000000febf0 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000fcea4 0006C (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: FACP 00000000000fcfcc 000F4 (v03 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: DSDT 00000000fff5aafd 03794 (v01   DELL    dt_ex 00001000 INTL 20050624)
[    0.000000] ACPI: FACS 00000000bfe01c00 00040
[    0.000000] ACPI: SSDT 00000000fff5e291 00099 (v01   DELL    st_ex 00001000 INTL 20050624)
[    0.000000] ACPI: APIC 00000000000fd0c0 00092 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: BOOT 00000000000fd152 00028 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: ASF! 00000000000fd17a 00096 (v32 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: MCFG 00000000000fd210 0003E (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: HPET 00000000000fd24e 00038 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: TCPA 00000000000fd4aa 00032 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: SLIC 00000000000fd286 00176 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000001bc000000
[    0.000000] Initmem setup node 0 0000000000000000-00000001bc000000
[    0.000000]   NODE_DATA [0000000100000000 - 0000000100004fff]
[    0.000000]  [ffffea0000000000-ffffea00061fffff] PMD -> [ffff880100200000-ffff8801055fffff] on node 0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000001 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x001bc000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000001 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x000bfe01
[    0.000000]     0: 0x00100000 -> 0x001bc000
[    0.000000] On node 0 totalpages: 1555870
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3941 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 767545 pages, LIFO batch:31
[    0.000000]   Normal zone: 10528 pages used for memmap
[    0.000000]   Normal zone: 759520 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs
[    0.000000] nr_irqs_gsi: 24
[    0.000000] early_res array is doubled to 64 at [7000 - 77ff]
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000bfe01000 - 00000000bfe02000
[    0.000000] PM: Registered nosave memory: 00000000bfe02000 - 00000000bfe53000
[    0.000000] PM: Registered nosave memory: 00000000bfe53000 - 00000000bfe54000
[    0.000000] PM: Registered nosave memory: 00000000bfe54000 - 00000000bfe55000
[    0.000000] PM: Registered nosave memory: 00000000bfe55000 - 00000000bfe56000
[    0.000000] PM: Registered nosave memory: 00000000bfe56000 - 00000000c0000000
[    0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000e0000000
[    0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000f0000000
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000
[    0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
[    0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff880001e00000 s81896 r8192 d20504 u262144
[    0.000000] pcpu-alloc: s81896 r8192 d20504 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] early_res array is doubled to 128 at [e000 - efff]
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1531006
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00412-gbb33c1c root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] Subtract (62 early reservations)
[    0.000000]   #1 [0001000000 - 0001db1168]   TEXT DATA BSS
[    0.000000]   #2 [0037c8e000 - 0037ff0000]         RAMDISK
[    0.000000]   #3 [0001db2000 - 0001db21a8]             BRK
[    0.000000]   #4 [00000fe720 - 0000100000]   BIOS reserved
[    0.000000]   #5 [00000fe710 - 00000fe720]    MP-table mpf
[    0.000000]   #6 [000009ec00 - 00000f0000]   BIOS reserved
[    0.000000]   #7 [00000f0304 - 00000fe710]   BIOS reserved
[    0.000000]   #8 [00000f0000 - 00000f0304]    MP-table mpc
[    0.000000]   #9 [0000001000 - 0000003000]      TRAMPOLINE
[    0.000000]   #10 [0000003000 - 0000007000]     ACPI WAKEUP
[    0.000000]   #11 [0000008000 - 000000b000]         PGTABLE
[    0.000000]   #12 [000000b000 - 000000e000]         PGTABLE
[    0.000000]   #13 [0100000000 - 0100005000]       NODE_DATA
[    0.000000]   #14 [0001db21c0 - 0001db31c0]         BOOTMEM
[    0.000000]   #15 [0001db1180 - 0001db1600]         BOOTMEM
[    0.000000]   #16 [0100005000 - 0100006000]         BOOTMEM
[    0.000000]   #17 [0100006000 - 0100007000]         BOOTMEM
[    0.000000]   #18 [0100200000 - 0105600000]        MEMMAP 0
[    0.000000]   #19 [0001db1600 - 0001db1780]         BOOTMEM
[    0.000000]   #20 [0001db31c0 - 0001dcb1c0]         BOOTMEM
[    0.000000]   #21 [0001dcb1c0 - 0001de31c0]         BOOTMEM
[    0.000000]   #22 [0001de4000 - 0001de5000]         BOOTMEM
[    0.000000]   #23 [0001db1780 - 0001db17c1]         BOOTMEM
[    0.000000]   #24 [0001db1800 - 0001db1843]         BOOTMEM
[    0.000000]   #25 [0001db1880 - 0001db1b58]         BOOTMEM
[    0.000000]   #26 [0001db1b80 - 0001db1be8]         BOOTMEM
[    0.000000]   #27 [0001db1c00 - 0001db1c68]         BOOTMEM
[    0.000000]   #28 [0001db1c80 - 0001db1ce8]         BOOTMEM
[    0.000000]   #29 [0001db1d00 - 0001db1d68]         BOOTMEM
[    0.000000]   #30 [0001db1d80 - 0001db1de8]         BOOTMEM
[    0.000000]   #31 [0001db1e00 - 0001db1e68]         BOOTMEM
[    0.000000]   #32 [0001db1e80 - 0001db1ee8]         BOOTMEM
[    0.000000]   #33 [0001db1f00 - 0001db1f68]         BOOTMEM
[    0.000000]   #34 [0001db1f80 - 0001db1fe8]         BOOTMEM
[    0.000000]   #35 [0001de31c0 - 0001de3228]         BOOTMEM
[    0.000000]   #36 [0001de3240 - 0001de32a8]         BOOTMEM
[    0.000000]   #37 [0001de32c0 - 0001de3328]         BOOTMEM
[    0.000000]   #38 [0001de3340 - 0001de3360]         BOOTMEM
[    0.000000]   #39 [0001de3380 - 0001de33a0]         BOOTMEM
[    0.000000]   #40 [0001de33c0 - 0001de3420]         BOOTMEM
[    0.000000]   #41 [0001de3440 - 0001de34a0]         BOOTMEM
[    0.000000]   #42 [0001e00000 - 0001e1b000]         BOOTMEM
[    0.000000]   #43 [0001e40000 - 0001e5b000]         BOOTMEM
[    0.000000]   #44 [0001e80000 - 0001e9b000]         BOOTMEM
[    0.000000]   #45 [0001ec0000 - 0001edb000]         BOOTMEM
[    0.000000]   #46 [0001f00000 - 0001f1b000]         BOOTMEM
[    0.000000]   #47 [0001f40000 - 0001f5b000]         BOOTMEM
[    0.000000]   #48 [0001f80000 - 0001f9b000]         BOOTMEM
[    0.000000]   #49 [0001fc0000 - 0001fdb000]         BOOTMEM
[    0.000000]   #50 [0001de34c0 - 0001de34c8]         BOOTMEM
[    0.000000]   #51 [0001de3500 - 0001de3508]         BOOTMEM
[    0.000000]   #52 [0001de3540 - 0001de3560]         BOOTMEM
[    0.000000]   #53 [0001de3580 - 0001de35c0]         BOOTMEM
[    0.000000]   #54 [0001de35c0 - 0001de36e0]         BOOTMEM
[    0.000000]   #55 [0001de3700 - 0001de3748]         BOOTMEM
[    0.000000]   #56 [0001de3780 - 0001de37c8]         BOOTMEM
[    0.000000]   #57 [0001de5000 - 0001ded000]         BOOTMEM
[    0.000000]   #58 [0001fdb000 - 0005fdb000]         BOOTMEM
[    0.000000]   #59 [0001e1b000 - 0001e3b000]         BOOTMEM
[    0.000000]   #60 [0005fdb000 - 000601b000]         BOOTMEM
[    0.000000]   #61 [000000f000 - 0000017000]         BOOTMEM
[    0.000000] Memory: 6052848k/7274496k available (5380k kernel code, 1051016k absent, 170632k reserved, 6497k data, 612k init)
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:2304
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2393.738 MHz processor.
[    0.001006] Calibrating delay loop (skipped), value calculated using timer frequency.. 4787.47 BogoMIPS (lpj=2393738)
[    0.002022] Security Framework initialized
[    0.002217] SELinux:  Initializing.
[    0.002416] SELinux:  Starting in permissive mode
[    0.003158] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.008145] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.010765] Mount-cache hash table entries: 256
[    0.011152] Initializing cgroup subsys ns
[    0.011348] Initializing cgroup subsys cpuacct
[    0.011545] Initializing cgroup subsys blkio
[    0.011767] CPU: Physical Processor ID: 0
[    0.012004] CPU: Processor Core ID: 0
[    0.012197] using mwait in idle threads.
[    0.013002] Performance Events: Core2 events, Intel PMU driver.
[    0.013291] ... version:                2
[    0.013483] ... bit width:              40
[    0.013675] ... generic registers:      2
[    0.013867] ... value mask:             000000ffffffffff
[    0.014002] ... max period:             000000007fffffff
[    0.014195] ... fixed-purpose events:   3
[    0.014387] ... event mask:             0000000700000003
[    0.014619] ACPI: Core revision 20100121
[    0.181067] Setting APIC routing to flat
[    0.181729] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.192154] CPU0: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
[    0.192999] Booting Node   0, Processors  #1 #2 #3
[    0.408006] Brought up 4 CPUs
[    0.408403] Total of 4 processors activated (19150.78 BogoMIPS).
[    0.409106] khelper used greatest stack depth: 6008 bytes left
[    0.410564] Time: 19:55:10  Date: 04/12/10
[    0.410789] NET: Registered protocol family 16
[    0.411036] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.411364] ACPI: bus type pci registered
[    0.412042] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.412361] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.434110] PCI: Using configuration type 1 for base access
[    0.446023] bio: create slab <bio-0> at 0
[    0.447363] ACPI: EC: Look up EC in DSDT
[    0.475505] ACPI: BIOS _OSI(Linux) query ignored
[    0.502249] ACPI: Interpreter enabled
[    0.502443] ACPI: (supports S0 S1 S3 S4 S5)
[    0.502895] ACPI: Using IOAPIC for interrupt routing
[    0.628105] ACPI Warning: Incorrect checksum in table [TCPA] - 00, should be 87 (20100121/tbutils-314)
[    0.628632] ACPI: No dock devices found.
[    0.628844] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.637381] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.654879] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.655002] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.655217] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.655557] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
[    0.655895] pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]
[    0.656002] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
[    0.656341] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
[    0.657001] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
[    0.657359] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
[    0.657699] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]
[    0.658067] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    0.658069] pci 0000:00:01.0: PME# disabled
[    0.658108] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
[    0.658111] pci 0000:00:06.0: PME# disabled
[    0.658172] pci 0000:00:1a.0: reg 20: [io  0xff20-0xff3f]
[    0.658254] pci 0000:00:1a.1: reg 20: [io  0xff00-0xff1f]
[    0.658333] pci 0000:00:1a.2: reg 20: [io  0xecc0-0xecdf]
[    0.658393] pci 0000:00:1a.7: reg 10: [mem 0xfdffbc00-0xfdffbfff]
[    0.658445] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    0.658449] pci 0000:00:1a.7: PME# disabled
[    0.658480] pci 0000:00:1b.0: reg 10: [mem 0xfdffc000-0xfdffffff 64bit]
[    0.658519] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[    0.658522] pci 0000:00:1b.0: PME# disabled
[    0.658581] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.658585] pci 0000:00:1c.0: PME# disabled
[    0.658649] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    0.658652] pci 0000:00:1c.5: PME# disabled
[    0.658707] pci 0000:00:1d.0: reg 20: [io  0xff80-0xff9f]
[    0.658786] pci 0000:00:1d.1: reg 20: [io  0xff60-0xff7f]
[    0.658865] pci 0000:00:1d.2: reg 20: [io  0xff40-0xff5f]
[    0.658932] pci 0000:00:1d.7: reg 10: [mem 0xff980800-0xff980bff]
[    0.659046] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    0.659050] pci 0000:00:1d.7: PME# disabled
[    0.659158] pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO
[    0.659518] pci 0000:00:1f.0: quirk: [io  0x0880-0x08bf] claimed by ICH6 GPIO
[    0.659716] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0c00 (mask 007f)
[    0.660002] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 00e0 (mask 0007)
[    0.660412] pci 0000:00:1f.2: reg 10: [io  0xfe00-0xfe07]
[    0.660418] pci 0000:00:1f.2: reg 14: [io  0xfe10-0xfe13]
[    0.660423] pci 0000:00:1f.2: reg 18: [io  0xfe20-0xfe27]
[    0.660428] pci 0000:00:1f.2: reg 1c: [io  0xfe30-0xfe33]
[    0.660433] pci 0000:00:1f.2: reg 20: [io  0xfec0-0xfedf]
[    0.660439] pci 0000:00:1f.2: reg 24: [mem 0xff970000-0xff9707ff]
[    0.660469] pci 0000:00:1f.2: PME# supported from D3hot
[    0.660472] pci 0000:00:1f.2: PME# disabled
[    0.660498] pci 0000:00:1f.3: reg 10: [mem 0xfdffbb00-0xfdffbbff 64bit]
[    0.660510] pci 0000:00:1f.3: reg 20: [io  0xece0-0xecff]
[    0.660566] pci 0000:01:00.0: reg 10: [mem 0xfc000000-0xfcffffff]
[    0.660575] pci 0000:01:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.660583] pci 0000:01:00.0: reg 1c: [mem 0xfa000000-0xfbffffff 64bit]
[    0.660588] pci 0000:01:00.0: reg 24: [io  0xdc80-0xdcff]
[    0.660593] pci 0000:01:00.0: reg 30: [mem 0xfde00000-0xfde1ffff pref]
[    0.660621] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.660816] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    0.660819] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfdefffff]
[    0.660823] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.660848] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    0.661002] pci 0000:00:06.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.661005] pci 0000:00:06.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.661009] pci 0000:00:06.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.661047] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    0.661254] pci 0000:00:1c.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.661258] pci 0000:00:1c.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
[    0.661263] pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.661349] pci 0000:04:00.0: reg 10: [mem 0xf9ef0000-0xf9efffff 64bit]
[    0.661424] pci 0000:04:00.0: PME# supported from D3hot D3cold
[    0.661429] pci 0000:04:00.0: PME# disabled
[    0.661443] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    0.661639] pci 0000:00:1c.5:   bridge window [io  0xf000-0x0000] (disabled)
[    0.661643] pci 0000:00:1c.5:   bridge window [mem 0xf9e00000-0xf9efffff]
[    0.661648] pci 0000:00:1c.5:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.661694] pci 0000:05:04.0: reg 10: [mem 0xf9dff000-0xf9dfffff]
[    0.661738] pci 0000:05:04.0: supports D1 D2
[    0.661739] pci 0000:05:04.0: PME# supported from D0 D1 D2 D3hot
[    0.661743] pci 0000:05:04.0: PME# disabled
[    0.661782] pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
[    0.662003] pci 0000:00:1e.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.662007] pci 0000:00:1e.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
[    0.662012] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.662015] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    0.662017] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    0.662019] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    0.662022] pci 0000:00:1e.0:   bridge window [mem 0x000c0000-0x000effff] (subtractive decode)
[    0.662024] pci 0000:00:1e.0:   bridge window [mem 0x000f0000-0x000fffff] (subtractive decode)
[    0.662027] pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xfebfffff] (subtractive decode)
[    0.662029] pci 0000:00:1e.0:   bridge window [mem 0xbff00000-0xdfffffff] (subtractive decode)
[    0.662031] pci 0000:00:1e.0:   bridge window [mem 0xff980800-0xff980bff] (subtractive decode)
[    0.662034] pci 0000:00:1e.0:   bridge window [mem 0xff97c000-0xff97ffff] (subtractive decode)
[    0.662036] pci 0000:00:1e.0:   bridge window [mem 0xfed20000-0xfed9ffff] (subtractive decode)
[    0.662056] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.662568] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI4._PRT]
[    0.663071] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
[    0.663477] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
[    0.663837] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI6._PRT]
[    1.970610] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
[    1.972277] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
[    1.973780] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    1.975382] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    1.977173] ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    1.978710] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    1.980526] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[    1.982085] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[    1.983047] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    1.983365] vgaarb: loaded
[    1.984008] SCSI subsystem initialized
[    1.984240] libata version 3.00 loaded.
[    1.984240] usbcore: registered new interface driver usbfs
[    1.984240] usbcore: registered new interface driver hub
[    1.985025] usbcore: registered new device driver usb
[    1.985219] Advanced Linux Sound Architecture Driver Version 1.0.22.1.
[    1.986002] PCI: Using ACPI for IRQ routing
[    1.986216] PCI: pci_cache_line_size set to 64 bytes
[    1.986251] pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
[    1.986632] Expanded resource reserved due to conflict with PCI Bus 0000:00
[    1.986828] reserve RAM buffer: 000000000009ec00 - 000000000009ffff 
[    1.986831] reserve RAM buffer: 00000000bfe01c00 - 00000000bfffffff 
[    1.987056] cfg80211: Calling CRDA to update world regulatory domain
[    1.987220] NetLabel: Initializing
[    1.987220] NetLabel:  domain hash size = 128
[    1.987401] NetLabel:  protocols = UNLABELED CIPSOv4
[    1.988011] NetLabel:  unlabeled traffic allowed by default
[    1.988228] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[    1.988426] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    1.988849] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[    1.993022] Switching to clocksource tsc
[    2.002646] pnp: PnP ACPI init
[    2.002859] ACPI: bus type pnp registered
[    2.019932] pnp 00:01: disabling [io  0x0800-0x085f] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    2.020289] pnp 00:01: disabling [io  0x0860-0x08ff] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    2.085362] pnp: PnP ACPI: found 12 devices
[    2.085564] ACPI: ACPI bus type pnp unregistered
[    2.085774] system 00:01: [io  0x0c00-0x0c7f] has been reserved
[    2.091330] PCI: max bus depth: 1 pci_try_num: 2
[    2.091368] pci 0000:00:1c.0: BAR 9: assigned [mem 0xf0000000-0xf01fffff 64bit pref]
[    2.091709] pci 0000:00:1c.5: BAR 9: assigned [mem 0xf0200000-0xf03fffff 64bit pref]
[    2.092053] pci 0000:00:1c.0: BAR 7: assigned [io  0x1000-0x1fff]
[    2.092259] pci 0000:00:1c.5: BAR 7: assigned [io  0x2000-0x2fff]
[    2.092454] pci 0000:00:1f.2: BAR 5: assigned [mem 0xf0400000-0xf04007ff]
[    2.092652] pci 0000:00:1f.2: BAR 5: set to [mem 0xf0400000-0xf04007ff] (PCI address [0xf0400000-0xf04007ff]
[    2.092994] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    2.093202] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    2.093399] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfdefffff]
[    2.093595] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    2.093936] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    2.094144] pci 0000:00:06.0:   bridge window [io  disabled]
[    2.094339] pci 0000:00:06.0:   bridge window [mem disabled]
[    2.094534] pci 0000:00:06.0:   bridge window [mem pref disabled]
[    2.094731] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    2.094926] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    2.095136] pci 0000:00:1c.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
[    2.095334] pci 0000:00:1c.0:   bridge window [mem 0xf0000000-0xf01fffff 64bit pref]
[    2.095676] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    2.095871] pci 0000:00:1c.5:   bridge window [io  0x2000-0x2fff]
[    2.096078] pci 0000:00:1c.5:   bridge window [mem 0xf9e00000-0xf9efffff]
[    2.096280] pci 0000:00:1c.5:   bridge window [mem 0xf0200000-0xf03fffff 64bit pref]
[    2.096623] pci 0000:00:1e.0: PCI bridge to [bus 05-05]
[    2.096817] pci 0000:00:1e.0:   bridge window [io  disabled]
[    2.097018] pci 0000:00:1e.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
[    2.097224] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    2.097431] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    2.097628] pci 0000:00:01.0: setting latency timer to 64
[    2.097633] pci 0000:00:06.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    2.097830] pci 0000:00:06.0: setting latency timer to 64
[    2.097837] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    2.098036] pci 0000:00:1c.0: setting latency timer to 64
[    2.098045] pci 0000:00:1c.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    2.098251] pci 0000:00:1c.5: setting latency timer to 64
[    2.098257] pci 0000:00:1e.0: setting latency timer to 64
[    2.098261] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    2.098263] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    2.098265] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    2.098266] pci_bus 0000:00: resource 7 [mem 0x000c0000-0x000effff]
[    2.098268] pci_bus 0000:00: resource 8 [mem 0x000f0000-0x000fffff]
[    2.098270] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff]
[    2.098272] pci_bus 0000:00: resource 10 [mem 0xbff00000-0xdfffffff]
[    2.098274] pci_bus 0000:00: resource 11 [mem 0xff980800-0xff980bff]
[    2.098276] pci_bus 0000:00: resource 12 [mem 0xff97c000-0xff97ffff]
[    2.098278] pci_bus 0000:00: resource 13 [mem 0xfed20000-0xfed9ffff]
[    2.098281] pci_bus 0000:01: resource 0 [io  0xd000-0xdfff]
[    2.098282] pci_bus 0000:01: resource 1 [mem 0xfa000000-0xfdefffff]
[    2.098285] pci_bus 0000:01: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref]
[    2.098287] pci_bus 0000:03: resource 0 [io  0x1000-0x1fff]
[    2.098289] pci_bus 0000:03: resource 1 [mem 0xf9f00000-0xf9ffffff]
[    2.098291] pci_bus 0000:03: resource 2 [mem 0xf0000000-0xf01fffff 64bit pref]
[    2.098293] pci_bus 0000:04: resource 0 [io  0x2000-0x2fff]
[    2.098295] pci_bus 0000:04: resource 1 [mem 0xf9e00000-0xf9efffff]
[    2.098297] pci_bus 0000:04: resource 2 [mem 0xf0200000-0xf03fffff 64bit pref]
[    2.098299] pci_bus 0000:05: resource 1 [mem 0xf9d00000-0xf9dfffff]
[    2.098301] pci_bus 0000:05: resource 4 [io  0x0000-0x0cf7]
[    2.098303] pci_bus 0000:05: resource 5 [io  0x0d00-0xffff]
[    2.098305] pci_bus 0000:05: resource 6 [mem 0x000a0000-0x000bffff]
[    2.098306] pci_bus 0000:05: resource 7 [mem 0x000c0000-0x000effff]
[    2.098308] pci_bus 0000:05: resource 8 [mem 0x000f0000-0x000fffff]
[    2.098310] pci_bus 0000:05: resource 9 [mem 0xf0000000-0xfebfffff]
[    2.098312] pci_bus 0000:05: resource 10 [mem 0xbff00000-0xdfffffff]
[    2.098314] pci_bus 0000:05: resource 11 [mem 0xff980800-0xff980bff]
[    2.098316] pci_bus 0000:05: resource 12 [mem 0xff97c000-0xff97ffff]
[    2.098318] pci_bus 0000:05: resource 13 [mem 0xfed20000-0xfed9ffff]
[    2.098345] NET: Registered protocol family 2
[    2.098745] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    2.100439] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    2.105559] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    2.106402] TCP: Hash tables configured (established 524288 bind 65536)
[    2.106599] TCP reno registered
[    2.106804] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    2.107100] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    2.107521] NET: Registered protocol family 1
[    2.107935] RPC: Registered udp transport module.
[    2.108144] RPC: Registered tcp transport module.
[    2.108337] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    2.108553] pci 0000:00:1a.0: uhci_check_and_reset_hc: legsup = 0x0f10
[    2.108555] pci 0000:00:1a.0: Performing full reset
[    2.108573] pci 0000:00:1a.1: uhci_check_and_reset_hc: legsup = 0x0010
[    2.108575] pci 0000:00:1a.1: Performing full reset
[    2.108591] pci 0000:00:1a.2: uhci_check_and_reset_hc: legsup = 0x2000
[    2.108593] pci 0000:00:1a.2: Performing full reset
[    2.108625] pci 0000:00:1a.7: EHCI: BIOS handoff
[    2.119042] pci 0000:00:1d.0: uhci_check_and_reset_hc: legsup = 0x001b
[    2.119045] pci 0000:00:1d.0: Performing full reset
[    2.119064] pci 0000:00:1d.1: uhci_check_and_reset_hc: legsup = 0x0010
[    2.119067] pci 0000:00:1d.1: Performing full reset
[    2.119085] pci 0000:00:1d.2: uhci_check_and_reset_hc: legsup = 0x0010
[    2.119088] pci 0000:00:1d.2: Performing full reset
[    2.119119] pci 0000:00:1d.7: EHCI: BIOS handoff
[    3.219020] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[    3.219352] pci 0000:01:00.0: Boot video device
[    3.219360] PCI: CLS 64 bytes, default 64
[    3.219422] Trying to unpack rootfs image as initramfs...
[    3.284926] Freeing initrd memory: 3464k freed
[    3.286232] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    3.286425] Placing 64MB software IO TLB between ffff880001fdb000 - ffff880005fdb000
[    3.286752] software IO TLB at phys 0x1fdb000 - 0x5fdb000
[    3.287188] Simple Boot Flag at 0x7a set to 0x1
[    3.289306] microcode: CPU0 sig=0x6fb, pf=0x10, revision=0xb3
[    3.289519] microcode: CPU1 sig=0x6fb, pf=0x10, revision=0xb3
[    3.289724] microcode: CPU2 sig=0x6fb, pf=0x10, revision=0xb3
[    3.289921] microcode: CPU3 sig=0x6fb, pf=0x10, revision=0xb3
[    3.290182] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.290886] audit: initializing netlink socket (disabled)
[    3.291103] type=2000 audit(1271102113.290:1): initialized
[    3.311115] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    3.315270] VFS: Disk quotas dquot_6.5.2
[    3.315550] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    3.317026] msgmni has been set to 11828
[    3.317367] SELinux:  Registering netfilter hooks
[    3.317972] alg: No test for stdrng (krng)
[    3.318320] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    3.322290] io scheduler noop registered
[    3.322475] io scheduler deadline registered
[    3.322819] io scheduler cfq registered (default)
[    3.323160] pcieport 0000:00:01.0: setting latency timer to 64
[    3.323186] pcieport 0000:00:01.0: irq 24 for MSI/MSI-X
[    3.323337] pcieport 0000:00:06.0: setting latency timer to 64
[    3.323365] pcieport 0000:00:06.0: irq 25 for MSI/MSI-X
[    3.323508] pcieport 0000:00:1c.0: setting latency timer to 64
[    3.323545] pcieport 0000:00:1c.0: irq 26 for MSI/MSI-X
[    3.323783] pcieport 0000:00:1c.5: setting latency timer to 64
[    3.323826] pcieport 0000:00:1c.5: irq 27 for MSI/MSI-X
[    3.324152] pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS
[    3.324494] pcieport 0000:00:01.0: Failed to receive control of PCIe PME service: no _OSC support
[    3.324823] pcie_pme: probe of 0000:00:01.0:pcie01 failed with error -13
[    3.325019] pcieport 0000:00:06.0: Requesting control of PCIe PME from ACPI BIOS
[    3.325357] pcieport 0000:00:06.0: Failed to receive control of PCIe PME service: no _OSC support
[    3.325685] pcie_pme: probe of 0000:00:06.0:pcie01 failed with error -13
[    3.325876] pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS
[    3.326218] pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support
[    3.326546] pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13
[    3.326737] pcieport 0000:00:1c.5: Requesting control of PCIe PME from ACPI BIOS
[    3.327074] pcieport 0000:00:1c.5: Failed to receive control of PCIe PME service: no _OSC support
[    3.327406] pcie_pme: probe of 0000:00:1c.5:pcie01 failed with error -13
[    3.327707] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    3.328322] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    3.328667] ACPI: Power Button [VBTN]
[    3.328948] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    3.329312] ACPI: Power Button [PWRF]
[    3.483371] Non-volatile memory driver v1.3
[    3.483564] Linux agpgart interface v0.103
[    3.483957] [drm] Initialized drm 1.1.0 20060810
[    3.484157] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[    3.484485] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    3.729356] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    3.730139] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    3.733187] brd: module loaded
[    3.734670] loop: module loaded
[    3.734985] Loading iSCSI transport class v2.0-870.
[    3.735755] ahci 0000:00:1f.2: version 3.0
[    3.735774] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    3.736017] ahci 0000:00:1f.2: irq 28 for MSI/MSI-X
[    3.736090] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[    3.736433] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc ems 
[    3.736762] ahci 0000:00:1f.2: setting latency timer to 64
[    3.746211] scsi0 : ahci
[    3.746597] scsi1 : ahci
[    3.746942] scsi2 : ahci
[    3.747303] scsi3 : ahci
[    3.747666] scsi4 : ahci
[    3.748020] scsi5 : ahci
[    3.748356] ata1: SATA max UDMA/133 abar m2048@0xf0400000 port 0xf0400100 irq 28
[    3.748692] ata2: SATA max UDMA/133 abar m2048@0xf0400000 port 0xf0400180 irq 28
[    3.749024] ata3: SATA max UDMA/133 abar m2048@0xf0400000 port 0xf0400200 irq 28
[    3.749361] ata4: SATA max UDMA/133 abar m2048@0xf0400000 port 0xf0400280 irq 28
[    3.749688] ata5: SATA max UDMA/133 abar m2048@0xf0400000 port 0xf0400300 irq 28
[    3.750019] ata6: SATA max UDMA/133 abar m2048@0xf0400000 port 0xf0400380 irq 28
[    3.750493] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[    3.750694] Copyright (c) 1999-2006 Intel Corporation.
[    3.750965] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    3.751178] e100: Copyright(c) 1999-2006 Intel Corporation
[    3.751453] tg3.c:v3.108 (February 17, 2010)
[    3.751659] tg3 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    3.751853] tg3 0000:04:00.0: setting latency timer to 64
[    3.759592] tg3 0000:04:00.0: eth0: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address 00:1e:c9:3c:35:1e
[    3.759922] tg3 0000:04:00.0: eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1])
[    3.760277] tg3 0000:04:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    3.760606] tg3 0000:04:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[    3.760848] sky2: driver version 1.27
[    3.761222] console [netcon0] enabled
[    3.761419] netconsole: network logging started
[    3.761832] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.762033] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    3.762053] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 22 (level, low) -> IRQ 22
[    3.762274] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[    3.762277] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[    3.762479] drivers/usb/core/inode.c: creating file 'devices'
[    3.762482] drivers/usb/core/inode.c: creating file '001'
[    3.762553] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[    3.762893] ehci_hcd 0000:00:1a.7: reset hcs_params 0x103206 dbg=1 cc=3 pcc=2 ordered !ppc ports=6
[    3.762897] ehci_hcd 0000:00:1a.7: reset hcc_params 16871 thresh 7 uframes 1024 64 bit addr
[    3.762919] ehci_hcd 0000:00:1a.7: debug port 1
[    3.763112] ehci_hcd 0000:00:1a.7: reset command 000002 (park)=0 ithresh=0 period=1024 Reset HALT
[    3.766987] ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
[    3.766989] ehci_hcd 0000:00:1a.7: supports USB remote wakeup
[    3.767003] ehci_hcd 0000:00:1a.7: irq 22, io mem 0xfdffbc00
[    3.767203] ehci_hcd 0000:00:1a.7: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
[    3.771078] ehci_hcd 0000:00:1a.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN
[    3.777069] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[    3.777294] usb usb1: default language 0x0409
[    3.777300] usb usb1: udev 1, busnum 1, minor = 0
[    3.777302] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    3.777491] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.777817] usb usb1: Product: EHCI Host Controller
[    3.778004] usb usb1: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c ehci_hcd
[    3.778203] usb usb1: SerialNumber: 0000:00:1a.7
[    3.778485] usb usb1: usb_probe_device
[    3.778489] usb usb1: configuration #1 chosen from 1 choice
[    3.778498] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    3.778563] hub 1-0:1.0: usb_probe_interface
[    3.778565] hub 1-0:1.0: usb_probe_interface - got id
[    3.778572] hub 1-0:1.0: USB hub found
[    3.778765] hub 1-0:1.0: 6 ports detected
[    3.778951] hub 1-0:1.0: standalone hub
[    3.778953] hub 1-0:1.0: no power switching (usb 1.0)
[    3.778954] hub 1-0:1.0: individual port over-current protection
[    3.778956] hub 1-0:1.0: power on to power good time: 20ms
[    3.778960] hub 1-0:1.0: local power source is good
[    3.778962] hub 1-0:1.0: trying to enable port power on non-switchable hub
[    3.778986] drivers/usb/core/inode.c: creating file '001'
[    3.779026] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    3.779238] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[    3.779241] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    3.779432] drivers/usb/core/inode.c: creating file '002'
[    3.779502] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[    3.779841] ehci_hcd 0000:00:1d.7: reset hcs_params 0x103206 dbg=1 cc=3 pcc=2 ordered !ppc ports=6
[    3.779845] ehci_hcd 0000:00:1d.7: reset hcc_params 16871 thresh 7 uframes 1024 64 bit addr
[    3.779863] ehci_hcd 0000:00:1d.7: debug port 1
[    3.780051] ehci_hcd 0000:00:1d.7: reset command 010002 (park)=0 ithresh=1 period=1024 Reset HALT
[    3.783927] ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
[    3.783929] ehci_hcd 0000:00:1d.7: supports USB remote wakeup
[    3.783939] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xff980800
[    3.784132] ehci_hcd 0000:00:1d.7: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
[    3.788014] ehci_hcd 0000:00:1d.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN
[    3.793058] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    3.793290] usb usb2: default language 0x0409
[    3.793296] usb usb2: udev 1, busnum 2, minor = 128
[    3.793297] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    3.793486] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.793812] usb usb2: Product: EHCI Host Controller
[    3.793998] usb usb2: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c ehci_hcd
[    3.794192] usb usb2: SerialNumber: 0000:00:1d.7
[    3.794471] usb usb2: usb_probe_device
[    3.794475] usb usb2: configuration #1 chosen from 1 choice
[    3.794484] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[    3.794548] hub 2-0:1.0: usb_probe_interface
[    3.794550] hub 2-0:1.0: usb_probe_interface - got id
[    3.794552] hub 2-0:1.0: USB hub found
[    3.794748] hub 2-0:1.0: 6 ports detected
[    3.794934] hub 2-0:1.0: standalone hub
[    3.794935] hub 2-0:1.0: no power switching (usb 1.0)
[    3.794937] hub 2-0:1.0: individual port over-current protection
[    3.794939] hub 2-0:1.0: power on to power good time: 20ms
[    3.794942] hub 2-0:1.0: local power source is good
[    3.794944] hub 2-0:1.0: trying to enable port power on non-switchable hub
[    3.794968] drivers/usb/core/inode.c: creating file '001'
[    3.795058] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.795262] ohci_hcd: block sizes: ed 80 td 96
[    3.795323] uhci_hcd: USB Universal Host Controller Interface driver
[    3.795634] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.795834] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[    3.795836] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[    3.796028] drivers/usb/core/inode.c: creating file '003'
[    3.796108] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[    3.796457] uhci_hcd 0000:00:1a.0: detected 2 ports
[    3.796646] uhci_hcd 0000:00:1a.0: uhci_check_and_reset_hc: cmd = 0x0000
[    3.796648] uhci_hcd 0000:00:1a.0: Performing full reset
[    3.796660] uhci_hcd 0000:00:1a.0: supports USB remote wakeup
[    3.796670] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000ff20
[    3.796882] usb usb3: default language 0x0409
[    3.796888] usb usb3: udev 1, busnum 3, minor = 256
[    3.796890] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    3.797084] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.797419] usb usb3: Product: UHCI Host Controller
[    3.797606] usb usb3: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c uhci_hcd
[    3.797795] usb usb3: SerialNumber: 0000:00:1a.0
[    3.798070] usb usb3: usb_probe_device
[    3.798074] usb usb3: configuration #1 chosen from 1 choice
[    3.798082] usb usb3: adding 3-0:1.0 (config #1, interface 0)
[    3.798145] hub 3-0:1.0: usb_probe_interface
[    3.798147] hub 3-0:1.0: usb_probe_interface - got id
[    3.798149] hub 3-0:1.0: USB hub found
[    3.798357] hub 3-0:1.0: 2 ports detected
[    3.798543] hub 3-0:1.0: standalone hub
[    3.798544] hub 3-0:1.0: no power switching (usb 1.0)
[    3.798546] hub 3-0:1.0: individual port over-current protection
[    3.798547] hub 3-0:1.0: power on to power good time: 2ms
[    3.798551] hub 3-0:1.0: local power source is good
[    3.798553] hub 3-0:1.0: trying to enable port power on non-switchable hub
[    3.798565] drivers/usb/core/inode.c: creating file '001'
[    3.798590] ehci_hcd 0000:00:1a.7: HS companion for 0000:00:1a.0
[    3.798606] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    3.798798] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[    3.798801] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[    3.798991] drivers/usb/core/inode.c: creating file '004'
[    3.799073] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[    3.799420] uhci_hcd 0000:00:1a.1: detected 2 ports
[    3.799609] uhci_hcd 0000:00:1a.1: uhci_check_and_reset_hc: cmd = 0x0000
[    3.799611] uhci_hcd 0000:00:1a.1: Performing full reset
[    3.799623] uhci_hcd 0000:00:1a.1: supports USB remote wakeup
[    3.799633] uhci_hcd 0000:00:1a.1: irq 17, io base 0x0000ff00
[    3.799846] usb usb4: default language 0x0409
[    3.799852] usb usb4: udev 1, busnum 4, minor = 384
[    3.799854] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    3.800043] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.800385] usb usb4: Product: UHCI Host Controller
[    3.800572] usb usb4: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c uhci_hcd
[    3.800761] usb usb4: SerialNumber: 0000:00:1a.1
[    3.801031] usb usb4: usb_probe_device
[    3.801035] usb usb4: configuration #1 chosen from 1 choice
[    3.801043] usb usb4: adding 4-0:1.0 (config #1, interface 0)
[    3.801117] hub 4-0:1.0: usb_probe_interface
[    3.801119] hub 4-0:1.0: usb_probe_interface - got id
[    3.801120] hub 4-0:1.0: USB hub found
[    3.801323] hub 4-0:1.0: 2 ports detected
[    3.801509] hub 4-0:1.0: standalone hub
[    3.801510] hub 4-0:1.0: no power switching (usb 1.0)
[    3.801512] hub 4-0:1.0: individual port over-current protection
[    3.801513] hub 4-0:1.0: power on to power good time: 2ms
[    3.801517] hub 4-0:1.0: local power source is good
[    3.801518] hub 4-0:1.0: trying to enable port power on non-switchable hub
[    3.801531] drivers/usb/core/inode.c: creating file '001'
[    3.801554] ehci_hcd 0000:00:1a.7: HS companion for 0000:00:1a.1
[    3.801571] uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
[    3.801762] uhci_hcd 0000:00:1a.2: setting latency timer to 64
[    3.801765] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    3.801955] drivers/usb/core/inode.c: creating file '005'
[    3.802028] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    3.802382] uhci_hcd 0000:00:1a.2: detected 2 ports
[    3.802570] uhci_hcd 0000:00:1a.2: uhci_check_and_reset_hc: cmd = 0x0000
[    3.802572] uhci_hcd 0000:00:1a.2: Performing full reset
[    3.802584] uhci_hcd 0000:00:1a.2: supports USB remote wakeup
[    3.802589] uhci_hcd 0000:00:1a.2: irq 22, io base 0x0000ecc0
[    3.802800] usb usb5: default language 0x0409
[    3.802806] usb usb5: udev 1, busnum 5, minor = 512
[    3.802808] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    3.802997] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.803336] usb usb5: Product: UHCI Host Controller
[    3.803523] usb usb5: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c uhci_hcd
[    3.803712] usb usb5: SerialNumber: 0000:00:1a.2
[    3.803984] usb usb5: usb_probe_device
[    3.803987] usb usb5: configuration #1 chosen from 1 choice
[    3.803995] usb usb5: adding 5-0:1.0 (config #1, interface 0)
[    3.804074] hub 5-0:1.0: usb_probe_interface
[    3.804076] hub 5-0:1.0: usb_probe_interface - got id
[    3.804078] hub 5-0:1.0: USB hub found
[    3.804279] hub 5-0:1.0: 2 ports detected
[    3.804465] hub 5-0:1.0: standalone hub
[    3.804466] hub 5-0:1.0: no power switching (usb 1.0)
[    3.804468] hub 5-0:1.0: individual port over-current protection
[    3.804470] hub 5-0:1.0: power on to power good time: 2ms
[    3.804473] hub 5-0:1.0: local power source is good
[    3.804475] hub 5-0:1.0: trying to enable port power on non-switchable hub
[    3.804488] drivers/usb/core/inode.c: creating file '001'
[    3.804511] ehci_hcd 0000:00:1a.7: HS companion for 0000:00:1a.2
[    3.804528] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    3.804719] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[    3.804722] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    3.804913] drivers/usb/core/inode.c: creating file '006'
[    3.804986] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[    3.805340] uhci_hcd 0000:00:1d.0: detected 2 ports
[    3.805529] uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: cmd = 0x0000
[    3.805531] uhci_hcd 0000:00:1d.0: Performing full reset
[    3.805543] uhci_hcd 0000:00:1d.0: supports USB remote wakeup
[    3.805547] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000ff80
[    3.805758] usb usb6: default language 0x0409
[    3.805764] usb usb6: udev 1, busnum 6, minor = 640
[    3.805766] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[    3.805956] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.806297] usb usb6: Product: UHCI Host Controller
[    3.806485] usb usb6: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c uhci_hcd
[    3.806674] usb usb6: SerialNumber: 0000:00:1d.0
[    3.806941] usb usb6: usb_probe_device
[    3.806944] usb usb6: configuration #1 chosen from 1 choice
[    3.806952] usb usb6: adding 6-0:1.0 (config #1, interface 0)
[    3.807019] hub 6-0:1.0: usb_probe_interface
[    3.807021] hub 6-0:1.0: usb_probe_interface - got id
[    3.807023] hub 6-0:1.0: USB hub found
[    3.807233] hub 6-0:1.0: 2 ports detected
[    3.807419] hub 6-0:1.0: standalone hub
[    3.807420] hub 6-0:1.0: no power switching (usb 1.0)
[    3.807422] hub 6-0:1.0: individual port over-current protection
[    3.807423] hub 6-0:1.0: power on to power good time: 2ms
[    3.807427] hub 6-0:1.0: local power source is good
[    3.807428] hub 6-0:1.0: trying to enable port power on non-switchable hub
[    3.807441] drivers/usb/core/inode.c: creating file '001'
[    3.807467] ehci_hcd 0000:00:1d.7: HS companion for 0000:00:1d.0
[    3.807480] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    3.807672] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[    3.807674] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    3.807865] drivers/usb/core/inode.c: creating file '007'
[    3.807937] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[    3.808291] uhci_hcd 0000:00:1d.1: detected 2 ports
[    3.808480] uhci_hcd 0000:00:1d.1: uhci_check_and_reset_hc: cmd = 0x0000
[    3.808482] uhci_hcd 0000:00:1d.1: Performing full reset
[    3.808494] uhci_hcd 0000:00:1d.1: supports USB remote wakeup
[    3.808498] uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000ff60
[    3.808717] usb usb7: default language 0x0409
[    3.808722] usb usb7: udev 1, busnum 7, minor = 768
[    3.808724] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[    3.808913] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.809254] usb usb7: Product: UHCI Host Controller
[    3.813046] usb usb7: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c uhci_hcd
[    3.813247] usb usb7: SerialNumber: 0000:00:1d.1
[    3.813514] usb usb7: usb_probe_device
[    3.813517] usb usb7: configuration #1 chosen from 1 choice
[    3.813526] usb usb7: adding 7-0:1.0 (config #1, interface 0)
[    3.813591] hub 7-0:1.0: usb_probe_interface
[    3.813593] hub 7-0:1.0: usb_probe_interface - got id
[    3.813595] hub 7-0:1.0: USB hub found
[    3.813792] hub 7-0:1.0: 2 ports detected
[    3.813978] hub 7-0:1.0: standalone hub
[    3.813980] hub 7-0:1.0: no power switching (usb 1.0)
[    3.813981] hub 7-0:1.0: individual port over-current protection
[    3.813983] hub 7-0:1.0: power on to power good time: 2ms
[    3.813986] hub 7-0:1.0: local power source is good
[    3.813988] hub 7-0:1.0: trying to enable port power on non-switchable hub
[    3.814001] drivers/usb/core/inode.c: creating file '001'
[    3.814027] ehci_hcd 0000:00:1d.7: HS companion for 0000:00:1d.1
[    3.814041] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    3.814247] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[    3.814250] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    3.814439] drivers/usb/core/inode.c: creating file '008'
[    3.814510] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[    3.814851] uhci_hcd 0000:00:1d.2: detected 2 ports
[    3.815039] uhci_hcd 0000:00:1d.2: uhci_check_and_reset_hc: cmd = 0x0000
[    3.815041] uhci_hcd 0000:00:1d.2: Performing full reset
[    3.815053] uhci_hcd 0000:00:1d.2: supports USB remote wakeup
[    3.815064] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ff40
[    3.815292] usb usb8: default language 0x0409
[    3.815298] usb usb8: udev 1, busnum 8, minor = 896
[    3.815300] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[    3.815489] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.815815] usb usb8: Product: UHCI Host Controller
[    3.816002] usb usb8: Manufacturer: Linux 2.6.34-rc3-00412-gbb33c1c uhci_hcd
[    3.816195] usb usb8: SerialNumber: 0000:00:1d.2
[    3.816473] usb usb8: usb_probe_device
[    3.816476] usb usb8: configuration #1 chosen from 1 choice
[    3.816484] usb usb8: adding 8-0:1.0 (config #1, interface 0)
[    3.816549] hub 8-0:1.0: usb_probe_interface
[    3.816551] hub 8-0:1.0: usb_probe_interface - got id
[    3.816553] hub 8-0:1.0: USB hub found
[    3.816750] hub 8-0:1.0: 2 ports detected
[    3.816936] hub 8-0:1.0: standalone hub
[    3.816938] hub 8-0:1.0: no power switching (usb 1.0)
[    3.816939] hub 8-0:1.0: individual port over-current protection
[    3.816941] hub 8-0:1.0: power on to power good time: 2ms
[    3.816944] hub 8-0:1.0: local power source is good
[    3.816946] hub 8-0:1.0: trying to enable port power on non-switchable hub
[    3.816961] drivers/usb/core/inode.c: creating file '001'
[    3.816987] ehci_hcd 0000:00:1d.7: HS companion for 0000:00:1d.2
[    3.817121] usbcore: registered new interface driver usblp
[    3.817327] Initializing USB Mass Storage driver...
[    3.817590] usbcore: registered new interface driver usb-storage
[    3.817787] USB Mass Storage support registered.
[    3.818052] usbcore: registered new interface driver libusual
[    3.818395] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[    3.821564] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.821755] serio: i8042 AUX port at 0x60,0x64 irq 12
[    3.822115] mice: PS/2 mouse device common for all mice
[    3.822682] rtc_cmos 00:05: RTC can wake from S4
[    3.822966] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    3.823177] rtc0: alarms up to one day, 242 bytes nvram, hpet irqs
[    3.823473] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    3.824374] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com
[    3.824931] cpuidle: using governor ladder
[    3.825130] cpuidle: using governor menu
[    3.825338] No iBFT detected.
[    3.827535] usbcore: registered new interface driver hiddev
[    3.827815] usbcore: registered new interface driver usbhid
[    3.828009] usbhid: USB HID core driver
[    3.830315] modprobe used greatest stack depth: 5840 bytes left
[    3.830571] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.830938] HDA Intel 0000:00:1b.0: irq 29 for MSI/MSI-X
[    3.830959] HDA Intel 0000:00:1b.0: setting latency timer to 64
[    3.860776] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    3.878107] hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0000
[    3.894092] ehci_hcd 0000:00:1d.7: GetStatus port 4 status 001403 POWER sig=k CSC CONNECT
[    3.894097] hub 2-0:1.0: port 4: status 0501 change 0001
[    3.898098] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    3.901036] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    3.904095] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    3.907045] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    3.913037] uhci_hcd 0000:00:1d.1: port 2 portsc 008a,00
[    3.916096] hub 8-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    3.994088] hub 2-0:1.0: state 7 ports 6 chg 0010 evt 0000
[    3.994099] hub 2-0:1.0: port 4, status 0501, change 0000, 480 Mb/s
[    3.994109] ehci_hcd 0000:00:1d.7: port 4 low speed --> companion
[    4.041176] logips2pp: Detected unknown logitech mouse model 89
[    4.045023] ehci_hcd 0000:00:1d.7: GetStatus port 4 status 003002 POWER OWNER sig=se0 CSC
[    4.045043] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0010
[    4.045053] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0004
[    4.045062] uhci_hcd 0000:00:1d.1: port 2 portsc 01a3,00
[    4.045069] hub 7-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s
[    4.055052] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    4.055056] ata5: SATA link down (SStatus 4 SControl 300)
[    4.055060] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.055099] ata6: SATA link down (SStatus 4 SControl 300)
[    4.055106] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    4.055110] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    4.055270] ata2.00: ATAPI: PLDS DVD+/-RW DH-16A6S, YD11, max UDMA/100
[    4.056074] ata2.00: configured for UDMA/100
[    4.082025] ata4.00: ATA-8: ST3750528AS, CC34, max UDMA/133
[    4.082230] ata4.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    4.082240] ata3.00: ATA-8: ST3750528AS, CC34, max UDMA/133
[    4.082242] ata3.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    4.106733] ata1.00: ATA-7: ST3750640AS, 3.ADG, max UDMA/133
[    4.106930] ata1.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    4.121693] ata3.00: configured for UDMA/133
[    4.122187] ata4.00: configured for UDMA/133
[    4.149069] hub 7-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301
[    4.165063] ata1.00: configured for UDMA/133
[    4.176140] scsi 0:0:0:0: Direct-Access     ATA      ST3750640AS      3.AD PQ: 0 ANSI: 5
[    4.176897] sd 0:0:0:0: [sda] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
[    4.176914] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    4.177500] sd 0:0:0:0: [sda] Write Protect is off
[    4.177687] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    4.177706] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.177986] scsi 1:0:0:0: CD-ROM            PLDS     DVD+-RW DH-16A6S YD11 PQ: 0 ANSI: 5
[    4.178517]  sda:sr0: scsi3-mmc drive: 48x/12x writer dvd-ram cd/rw xa/form2 cdda tray
[    4.183564] Uniform CD-ROM driver Revision: 3.20
[    4.183947] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    4.184101] sr 1:0:0:0: Attached scsi generic sg1 type 5
[    4.184479] scsi 2:0:0:0: Direct-Access     ATA      ST3750528AS      CC34 PQ: 0 ANSI: 5
[    4.185091] sd 2:0:0:0: [sdb] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
[    4.185232] sd 2:0:0:0: Attached scsi generic sg2 type 0
[    4.185361] scsi 3:0:0:0: Direct-Access     ATA      ST3750528AS      CC34 PQ: 0 ANSI: 5
[    4.185528] sd 3:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
[    4.185574] sd 3:0:0:0: [sdc] Write Protect is off
[    4.185576] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    4.185584] sd 3:0:0:0: Attached scsi generic sg3 type 0
[    4.185596] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.185701]  sdc:
[    4.187165] sd 2:0:0:0: [sdb] Write Protect is off
[    4.187538] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    4.187556] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.187993]  sdb: sdc1
[    4.191213] sd 3:0:0:0: [sdc] Attached SCSI disk
[    4.200958] ALSA device list:
[    4.201155]   #0: HDA Intel at 0xfdffc000 irq 29
[    4.201400] Netfilter messages via NETLINK v0.30.
[    4.201600] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    4.201971] ctnetlink v0.93: registering with nfnetlink.
[    4.202586] ip_tables: (C) 2000-2006 Netfilter Core Team
[    4.202805] TCP cubic registered
[    4.202991] Initializing XFRM netlink socket
[    4.203571] NET: Registered protocol family 10
[    4.204488] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    4.204722] IPv6 over IPv4 tunneling driver
[    4.204971]  sdb1
[    4.205654] NET: Registered protocol family 17
[    4.206158] PM: Resume from disk failed.
[    4.206189] registered taskstats version 1
[    4.206287] sd 2:0:0:0: [sdb] Attached SCSI disk
[    4.206827]   Magic number: 6:794:950
[    4.207052] tty tty7: hash matches
[    4.213014]  sda1 sda2 < sda5 sda6 sda7 sda8
[    4.251211] usb 7-2: new low speed USB device using uhci_hcd and address 2
[    4.254326]  sda9 sda10 >
[    4.276744] sd 0:0:0:0: [sda] Attached SCSI disk
[    4.276966] Freeing unused kernel memory: 612k freed
[    4.277319] Write protecting the kernel read-only data: 10240k
[    4.277696] Freeing unused kernel memory: 744k freed
[    4.278185] Freeing unused kernel memory: 1588k freed
[    4.289466] all_generic_ide used greatest stack depth: 5808 bytes left
[    4.294376] all_generic_ide used greatest stack depth: 5776 bytes left
[    4.351062] ata_id used greatest stack depth: 5720 bytes left
[    4.373079] scsi_id used greatest stack depth: 5472 bytes left
[    4.383981] scsi_id used greatest stack depth: 4864 bytes left
[    4.392792] usb 7-2: skipped 1 descriptor after interface
[    4.392798] usb 7-2: udev 2, busnum 7, minor = 769
[    4.392801] usb 7-2: New USB device found, idVendor=0430, idProduct=0005
[    4.393000] usb 7-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.393278] usb 7-2: usb_probe_device
[    4.393281] usb 7-2: configuration #1 chosen from 1 choice
[    4.395794] usb 7-2: adding 7-2:1.0 (config #1, interface 0)
[    4.395864] usbhid 7-2:1.0: usb_probe_interface
[    4.395868] usbhid 7-2:1.0: usb_probe_interface - got id
[    4.410084] input: HID 0430:0005 as /devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/input/input3
[    4.410432] uhci_hcd 0000:00:1d.1: reserve dev 2 ep81-INT, period 8, phase 4, 118 us
[    4.410477] generic-usb 0003:0430:0005.0001: input,hidraw0: USB HID v1.00 Keyboard [HID 0430:0005] on usb-0000:00:1d.1-2/input0
[    4.410836] drivers/usb/core/inode.c: creating file '002'
[    4.519346] input: ImExPS/2 Logitech Explorer Mouse as /devices/platform/i8042/serio1/input/input4
[    4.745312] PM: Starting manual resume from disk
[    4.745501] PM: Resume from partition 8:7
[    4.745502] PM: Checking hibernation image.
[    4.745679] PM: Error -22 checking image file
[    4.745681] PM: Resume from disk failed.
[    4.749967] PM: Marking nosave pages: 000000000009e000 - 0000000000100000
[    4.749972] PM: Marking nosave pages: 00000000bfe01000 - 0000000100000000
[    4.751421] PM: Basic memory bitmaps created
[    4.794834] PM: Basic memory bitmaps freed
[    4.806426] kjournald starting.  Commit interval 5 seconds
[    4.806436] EXT3-fs (sda1): mounted filesystem with writeback data mode
[    4.954047] usb usb3: suspend_rh (auto-stop)
[    4.954069] usb usb4: suspend_rh (auto-stop)
[    4.954088] usb usb5: suspend_rh (auto-stop)
[    4.954107] usb usb6: suspend_rh (auto-stop)
[    4.954126] usb usb8: suspend_rh (auto-stop)
[    5.206025] async/1 used greatest stack depth: 4744 bytes left
[    5.951081] mknod used greatest stack depth: 4648 bytes left
[    6.076515] udev: starting version 151
[    6.365513] blkid used greatest stack depth: 4544 bytes left
[    6.636221] nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    6.636420] nouveau 0000:01:00.0: setting latency timer to 64
[    6.639612] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086f00a2)
[    6.643881] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
[    6.694618] [drm] nouveau 0000:01:00.0: ... appears to be valid
[    6.694810] [drm] nouveau 0000:01:00.0: BIT BIOS found
[    6.694997] [drm] nouveau 0000:01:00.0: Bios version 60.86.5d.00
[    6.695214] [drm] nouveau 0000:01:00.0: TMDS table revision 2.0 not currently supported
[    6.695218] hub 1-0:1.0: hub_suspend
[    6.695226] usb usb1: bus auto-suspend
[    6.695228] ehci_hcd 0000:00:1a.7: suspend root hub
[    6.695260] hub 3-0:1.0: hub_suspend
[    6.695263] usb usb3: bus auto-suspend
[    6.695265] usb usb3: suspend_rh
[    6.695284] hub 4-0:1.0: hub_suspend
[    6.695286] usb usb4: bus auto-suspend
[    6.695288] usb usb4: suspend_rh
[    6.695305] hub 5-0:1.0: hub_suspend
[    6.695308] usb usb5: bus auto-suspend
[    6.695309] usb usb5: suspend_rh
[    6.695326] hub 6-0:1.0: hub_suspend
[    6.695329] usb usb6: bus auto-suspend
[    6.695330] usb usb6: suspend_rh
[    6.695348] hub 8-0:1.0: hub_suspend
[    6.695351] usb usb8: bus auto-suspend
[    6.695352] usb usb8: suspend_rh
[    6.695590] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0
[    6.695918] [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 02011300 00000028
[    6.696118] [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 01011302 00000010
[    6.699914] [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 01000310 00000028
[    6.700113] [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 02000312 00000010
[    6.700305] [drm] nouveau 0000:01:00.0: Raw DCB entry 4: 0000000e 00000000
[    6.700495] [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 14 2
[    6.700684] [drm] nouveau 0000:01:00.0:   0: 0x00002030: type 0x30 idx 0 tag 0x08
[    6.701016] [drm] nouveau 0000:01:00.0:   1: 0x00001130: type 0x30 idx 1 tag 0x07
[    6.701358] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xC2B6
[    6.705022] hub 2-0:1.0: hub_suspend
[    6.705025] usb usb2: bus auto-suspend
[    6.705027] ehci_hcd 0000:00:1d.7: suspend root hub
[    6.727311] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xC620
[    6.746050] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xD261
[    6.746397] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xD353
[    6.748089] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xD54D
[    6.748436] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xD5B2
[    6.769071] [drm] nouveau 0000:01:00.0: 0xD5B2: Condition still not met after 20ms, skipping following opcodes
[    6.769420] [drm] nouveau 0000:01:00.0: 0xB514: parsing output script 0
[    6.769614] [drm] nouveau 0000:01:00.0: 0xB514: parsing output script 0
[    6.844341] [TTM] Zone  kernel: Available graphics memory: 3029628 kiB.
[    6.844532] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
[    6.844729] [drm] nouveau 0000:01:00.0: 256 MiB VRAM
[    6.861342] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
[    6.861535] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
[    6.862046] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
[    6.865828] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1
[    6.866774] [drm] nouveau 0000:01:00.0: Detected a DAC output
[    6.866967] [drm] nouveau 0000:01:00.0: Detected a TMDS output
[    6.867169] [drm] nouveau 0000:01:00.0: Detected a DAC output
[    6.867357] [drm] nouveau 0000:01:00.0: Detected a TMDS output
[    6.867545] [drm] nouveau 0000:01:00.0: Detected a DVI-I connector
[    6.867779] [drm] nouveau 0000:01:00.0: Detected a DVI-I connector
[    7.097623] [drm] nouveau 0000:01:00.0: allocated 1600x1200 fb: 0x40250000, bo ffff8801b9371e00
[    7.103869] Console: switching to colour frame buffer device 200x75
[    7.103883] [drm] nouveau 0000:01:00.0: 0x1083: parsing clock script 0
[    7.106514] fb0: nouveaufb frame buffer device
[    7.106525] registered panic notifier
[    7.106537] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
[    7.106690] modprobe used greatest stack depth: 4048 bytes left
[    7.121175] [drm] nouveau 0000:01:00.0: 0x1083: parsing clock script 0
[    7.461211] Adding 2048252k swap on /dev/sda7.  Priority:-1 extents:1 across:2048252k 
[    7.714863] EXT3-fs (sda1): using internal journal
[    9.953867] kjournald starting.  Commit interval 5 seconds
[    9.954106] EXT3-fs (sda5): using internal journal
[    9.954124] EXT3-fs (sda5): mounted filesystem with writeback data mode
[    9.983353] kjournald starting.  Commit interval 5 seconds
[    9.983519] EXT3-fs (sda6): using internal journal
[    9.983535] EXT3-fs (sda6): mounted filesystem with writeback data mode
[    9.998176] kjournald starting.  Commit interval 5 seconds
[    9.998385] EXT3-fs (sda8): using internal journal
[    9.998402] EXT3-fs (sda8): mounted filesystem with writeback data mode
[   10.031466] kjournald starting.  Commit interval 5 seconds
[   10.031751] EXT3-fs (sda9): using internal journal
[   10.031769] EXT3-fs (sda9): mounted filesystem with writeback data mode
[   10.076221] kjournald starting.  Commit interval 5 seconds
[   10.076407] EXT3-fs (sda10): using internal journal
[   10.076423] EXT3-fs (sda10): mounted filesystem with writeback data mode
[   10.083429] kjournald starting.  Commit interval 5 seconds
[   10.083737] EXT3-fs (sdb1): using internal journal
[   10.083753] EXT3-fs (sdb1): mounted filesystem with writeback data mode
[   10.090731] kjournald starting.  Commit interval 5 seconds
[   10.091047] EXT3-fs (sdc1): using internal journal
[   10.091064] EXT3-fs (sdc1): mounted filesystem with writeback data mode
[   11.521705] tg3 0000:04:00.0: irq 30 for MSI/MSI-X
[   11.565243] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.937870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[   14.692137] tg3 0000:04:00.0: eth0: Link is up at 1000 Mbps, full duplex
[   14.692152] tg3 0000:04:00.0: eth0: Flow control is on for TX and on for RX
[   14.693142] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   24.852059] eth0: no IPv6 routers present
[   28.398733] svc: failed to register lockdv1 RPC service (errno 97).
[   29.606110] mount.nfs used greatest stack depth: 3144 bytes left

-andy

[PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

Update e820 at first, and later put them resource tree.

-V2: reserved that early, no PCI BAR can use it, force them to get new one

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Andy Isaacson <adi@hexapodia.org>
Tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>

---
 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/head32.c     |    1 -
 arch/x86/kernel/setup.c      |   19 +------------------
 3 files changed, 1 insertion(+), 20 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_se
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Bjorn Helgaas]

On Mon, 2010-04-12 at 15:32 -0700, Yinghai wrote:
> Update e820 at first, and later put them resource tree.
> 
> -V2: reserved that early, no PCI BAR can use it, force them to get new one
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Cc: Guenter Roeck <guenter.roeck@ericsson.com>
> Cc: Andy Isaacson <adi@hexapodia.org>
> Tested-by: Andy Isaacson <adi@hexapodia.org>
> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Acked-by: H. Peter Anvin <hpa@zytor.com>
> 
> ---
>  arch/x86/include/asm/setup.h |    1 -
>  arch/x86/kernel/head32.c     |    1 -
>  arch/x86/kernel/setup.c      |   19 +------------------
>  3 files changed, 1 insertion(+), 20 deletions(-)
> 
> Index: linux-2.6/arch/x86/include/asm/setup.h
> ===================================================================
> --- linux-2.6.orig/arch/x86/include/asm/setup.h
> +++ linux-2.6/arch/x86/include/asm/setup.h
> @@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
>  extern unsigned long saved_video_mode;
>  
>  extern void reserve_standard_io_resources(void);
> -extern void i386_reserve_resources(void);
>  extern void setup_default_timer_irq(void);
>  
>  #ifdef CONFIG_X86_MRST
> Index: linux-2.6/arch/x86/kernel/head32.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/head32.c
> +++ linux-2.6/arch/x86/kernel/head32.c
> @@ -22,7 +22,6 @@ static void __init i386_default_early_se
>  {
>  	/* Initilize 32bit specific setup functions */
>  	x86_init.resources.probe_roms = probe_roms;
> -	x86_init.resources.reserve_resources = i386_reserve_resources;
>  	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
>  
>  	reserve_ebda_region();

I like the fact that this makes x86_64 and x86_32 handle the legacy VGA
framebuffer the same way.

What about arch/x86/kernel/probe_roms_32.c?  That deals with expansion
ROMs in the 0xc0000-0xfffff range, including the VGA ROM.  We only build
it for x86_32; is that correct, or should it be unified, too?

> Index: linux-2.6/arch/x86/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup.c
> +++ linux-2.6/arch/x86/kernel/setup.c
> @@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
>  	 * area (640->1Mb) as ram even though it is not.
>  	 * take them out.
>  	 */
> -	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
> +	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);

Let me see if I understand this.  On Andy's machine, the e820 map
doesn't mention the 0xa0000-0xf0000 range at all:

  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)

e820_reserve_resources() inserts resources for some e820 entries (those
that start before 0x100000 or are not E820_RESERVED).  Andy's machine
didn't supply any e820 entries that cover 0xa0000-0xf0000, so we didn't
insert any resources there, and PCI assumed that range was available.

This patch adds the [0xa0000-0x100000] range as E820_RESERVED.  Since
that starts below 0x100000, e820_reserve_resources() will insert a
corresponding resource marked as BUSY.

Then the second patch prevents PCI from using that BUSY region to
allocate resources to devices.

Is my understanding correct?

I don't feel like I know enough about x86 architecture to ack this
patch, but I don't object to it.

Bjorn

>  	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
>  }
>  
> @@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
>  
>  	mcheck_init();
>  }
> -
> -#ifdef CONFIG_X86_32
> -
> -static struct resource video_ram_resource = {
> -	.name	= "Video RAM area",
> -	.start	= 0xa0000,
> -	.end	= 0xbffff,
> -	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
> -};
> -
> -void __init i386_reserve_resources(void)
> -{
> -	request_resource(&iomem_resource, &video_ram_resource);
> -	reserve_standard_io_resources();
> -}
> -
> -#endif /* CONFIG_X86_32 */

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 02:02 PM, Bjorn Helgaas wrote:
> On Mon, 2010-04-12 at 15:32 -0700, Yinghai wrote:
>> Update e820 at first, and later put them resource tree.
>>
>> -V2: reserved that early, no PCI BAR can use it, force them to get new one
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>> Cc: Guenter Roeck <guenter.roeck@ericsson.com>
>> Cc: Andy Isaacson <adi@hexapodia.org>
>> Tested-by: Andy Isaacson <adi@hexapodia.org>
>> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
>> Acked-by: H. Peter Anvin <hpa@zytor.com>
>>
>> ---
>>  arch/x86/include/asm/setup.h |    1 -
>>  arch/x86/kernel/head32.c     |    1 -
>>  arch/x86/kernel/setup.c      |   19 +------------------
>>  3 files changed, 1 insertion(+), 20 deletions(-)
>>
>> Index: linux-2.6/arch/x86/include/asm/setup.h
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/include/asm/setup.h
>> +++ linux-2.6/arch/x86/include/asm/setup.h
>> @@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
>>  extern unsigned long saved_video_mode;
>>  
>>  extern void reserve_standard_io_resources(void);
>> -extern void i386_reserve_resources(void);
>>  extern void setup_default_timer_irq(void);
>>  
>>  #ifdef CONFIG_X86_MRST
>> Index: linux-2.6/arch/x86/kernel/head32.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/head32.c
>> +++ linux-2.6/arch/x86/kernel/head32.c
>> @@ -22,7 +22,6 @@ static void __init i386_default_early_se
>>  {
>>  	/* Initilize 32bit specific setup functions */
>>  	x86_init.resources.probe_roms = probe_roms;
>> -	x86_init.resources.reserve_resources = i386_reserve_resources;
>>  	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
>>  
>>  	reserve_ebda_region();
> 
> I like the fact that this makes x86_64 and x86_32 handle the legacy VGA
> framebuffer the same way.
> 
> What about arch/x86/kernel/probe_roms_32.c?  That deals with expansion
> ROMs in the 0xc0000-0xfffff range, including the VGA ROM.  We only build
> it for x86_32; is that correct, or should it be unified, too?

looks that file could be dropped.

We already put 0xa0000 - 0x100000 to reserved region.

> 
>> Index: linux-2.6/arch/x86/kernel/setup.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/setup.c
>> +++ linux-2.6/arch/x86/kernel/setup.c
>> @@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
>>  	 * area (640->1Mb) as ram even though it is not.
>>  	 * take them out.
>>  	 */
>> -	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
>> +	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
> 
> Let me see if I understand this.  On Andy's machine, the e820 map
> doesn't mention the 0xa0000-0xf0000 range at all:
> 
>   BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>   BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> 
> e820_reserve_resources() inserts resources for some e820 entries (those
> that start before 0x100000 or are not E820_RESERVED).  Andy's machine
> didn't supply any e820 entries that cover 0xa0000-0xf0000, so we didn't
> insert any resources there, and PCI assumed that range was available.
> 
> This patch adds the [0xa0000-0x100000] range as E820_RESERVED.  Since
> that starts below 0x100000, e820_reserve_resources() will insert a
> corresponding resource marked as BUSY.
> 
> Then the second patch prevents PCI from using that BUSY region to
> allocate resources to devices.
> 
> Is my understanding correct?

yes.

> 
> I don't feel like I know enough about x86 architecture to ack this
> patch, but I don't object to it.

Thanks

Yinghai

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

On 04/13/2010 02:02 PM, Bjorn Helgaas wrote:
> 
> I like the fact that this makes x86_64 and x86_32 handle the legacy VGA
> framebuffer the same way.
> 
> What about arch/x86/kernel/probe_roms_32.c?  That deals with expansion
> ROMs in the 0xc0000-0xfffff range, including the VGA ROM.  We only build
> it for x86_32; is that correct, or should it be unified, too?
> 

It should be.

>> Index: linux-2.6/arch/x86/kernel/setup.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/setup.c
>> +++ linux-2.6/arch/x86/kernel/setup.c
>> @@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
>>  	 * area (640->1Mb) as ram even though it is not.
>>  	 * take them out.
>>  	 */
>> -	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
>> +	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
> 
> Let me see if I understand this.  On Andy's machine, the e820 map
> doesn't mention the 0xa0000-0xf0000 range at all:
> 
>   BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>   BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> 
> e820_reserve_resources() inserts resources for some e820 entries (those
> that start before 0x100000 or are not E820_RESERVED).  Andy's machine
> didn't supply any e820 entries that cover 0xa0000-0xf0000, so we didn't
> insert any resources there, and PCI assumed that range was available.

[Note: it's worth noting that the e820 spec specifically says that e820
will not necessarily mark legacy ranges reserved.]

> This patch adds the [0xa0000-0x100000] range as E820_RESERVED.  Since
> that starts below 0x100000, e820_reserve_resources() will insert a
> corresponding resource marked as BUSY.
> 
> Then the second patch prevents PCI from using that BUSY region to
> allocate resources to devices.
> 
> Is my understanding correct?
> 
> I don't feel like I know enough about x86 architecture to ack this
> patch, but I don't object to it.

I guess the real question (which I haven't looked at myself) is if the
E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
moved.  That's bad, not so much for this particular range, but from BARs
which may be assigned by SMM.  Hacking that up in a simulator
(Qemu/Bochs) and testing it is probably on the to do list...

	-hpa

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 02:09 PM, H. Peter Anvin wrote:
> On 04/13/2010 02:02 PM, Bjorn Helgaas wrote:
>>
>> I like the fact that this makes x86_64 and x86_32 handle the legacy VGA
>> framebuffer the same way.
>>
>> What about arch/x86/kernel/probe_roms_32.c?  That deals with expansion
>> ROMs in the 0xc0000-0xfffff range, including the VGA ROM.  We only build
>> it for x86_32; is that correct, or should it be unified, too?
>>
> 
> It should be.
> 
>>> Index: linux-2.6/arch/x86/kernel/setup.c
>>> ===================================================================
>>> --- linux-2.6.orig/arch/x86/kernel/setup.c
>>> +++ linux-2.6/arch/x86/kernel/setup.c
>>> @@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
>>>  	 * area (640->1Mb) as ram even though it is not.
>>>  	 * take them out.
>>>  	 */
>>> -	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
>>> +	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
>>
>> Let me see if I understand this.  On Andy's machine, the e820 map
>> doesn't mention the 0xa0000-0xf0000 range at all:
>>
>>   BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>>   BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>>
>> e820_reserve_resources() inserts resources for some e820 entries (those
>> that start before 0x100000 or are not E820_RESERVED).  Andy's machine
>> didn't supply any e820 entries that cover 0xa0000-0xf0000, so we didn't
>> insert any resources there, and PCI assumed that range was available.
> 
> [Note: it's worth noting that the e820 spec specifically says that e820
> will not necessarily mark legacy ranges reserved.]
> 
>> This patch adds the [0xa0000-0x100000] range as E820_RESERVED.  Since
>> that starts below 0x100000, e820_reserve_resources() will insert a
>> corresponding resource marked as BUSY.
>>
>> Then the second patch prevents PCI from using that BUSY region to
>> allocate resources to devices.
>>
>> Is my understanding correct?
>>
>> I don't feel like I know enough about x86 architecture to ack this
>> patch, but I don't object to it.
> 
> I guess the real question (which I haven't looked at myself) is if the
> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
> moved.  That's bad, not so much for this particular range, but from BARs
> which may be assigned by SMM.  Hacking that up in a simulator
> (Qemu/Bochs) and testing it is probably on the to do list...

no, if some device BAR fall in that range, it should still use that range, and will not be relocated.

will update the change log.

Thanks

Yinghai

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

On 04/13/2010 02:11 PM, Yinghai wrote:
>>
>> I guess the real question (which I haven't looked at myself) is if the
>> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
>> moved.  That's bad, not so much for this particular range, but from BARs
>> which may be assigned by SMM.  Hacking that up in a simulator
>> (Qemu/Bochs) and testing it is probably on the to do list...
> 
> no, if some device BAR fall in that range, it should still use that range, and will not be relocated.
> 
> will update the change log.
> 

Good, that's what we want.

ROM probing in this region should really be possible to skip, since the
only thing safe is to treat the whole region as special.  This is not in
any way 32-bit-specific.

	-hpa

[PATCH -v3 1/3] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

Update e820 at first, and later put them resource tree.

Reserved that early, will not be allocated to unassigned PCI BAR

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Andy Isaacson <adi@hexapodia.org>
Tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>

---
 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/head32.c     |    1 -
 arch/x86/kernel/setup.c      |   19 +------------------
 3 files changed, 1 insertion(+), 20 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_se
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

Re: [PATCH -v3 1/3] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

Hi Jesse,

I am considering putting this patch plus the two followup patches in my
next set of fixes to Linus.  However, the two followup patches are
really more PCI-related than x86-related, so I would appreciate your OK.

I'm using this version (-v3) because the latter cleanup (removing
probe_rom_32.c for example) do not seem to be .34 material.

For the followup patches:

http://marc.info/?i=4BC4E0E9.7000203@oracle.com
http://marc.info/?i=4BC4E115.90805@oracle.com

	-hpa

On 04/13/2010 02:22 PM, Yinghai wrote:
> 
> 
> Update e820 at first, and later put them resource tree.
> 
> Reserved that early, will not be allocated to unassigned PCI BAR
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Cc: Guenter Roeck <guenter.roeck@ericsson.com>
> Cc: Andy Isaacson <adi@hexapodia.org>
> Tested-by: Andy Isaacson <adi@hexapodia.org>
> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Acked-by: H. Peter Anvin <hpa@zytor.com>
> 
> ---
>  arch/x86/include/asm/setup.h |    1 -
>  arch/x86/kernel/head32.c     |    1 -
>  arch/x86/kernel/setup.c      |   19 +------------------
>  3 files changed, 1 insertion(+), 20 deletions(-)
> 
> Index: linux-2.6/arch/x86/include/asm/setup.h
> ===================================================================
> --- linux-2.6.orig/arch/x86/include/asm/setup.h
> +++ linux-2.6/arch/x86/include/asm/setup.h
> @@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
>  extern unsigned long saved_video_mode;
>  
>  extern void reserve_standard_io_resources(void);
> -extern void i386_reserve_resources(void);
>  extern void setup_default_timer_irq(void);
>  
>  #ifdef CONFIG_X86_MRST
> Index: linux-2.6/arch/x86/kernel/head32.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/head32.c
> +++ linux-2.6/arch/x86/kernel/head32.c
> @@ -22,7 +22,6 @@ static void __init i386_default_early_se
>  {
>  	/* Initilize 32bit specific setup functions */
>  	x86_init.resources.probe_roms = probe_roms;
> -	x86_init.resources.reserve_resources = i386_reserve_resources;
>  	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
>  
>  	reserve_ebda_region();
> Index: linux-2.6/arch/x86/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup.c
> +++ linux-2.6/arch/x86/kernel/setup.c
> @@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
>  	 * area (640->1Mb) as ram even though it is not.
>  	 * take them out.
>  	 */
> -	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
> +	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
>  	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
>  }
>  
> @@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
>  
>  	mcheck_init();
>  }
> -
> -#ifdef CONFIG_X86_32
> -
> -static struct resource video_ram_resource = {
> -	.name	= "Video RAM area",
> -	.start	= 0xa0000,
> -	.end	= 0xbffff,
> -	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
> -};
> -
> -void __init i386_reserve_resources(void)
> -{
> -	request_resource(&iomem_resource, &video_ram_resource);
> -	reserve_standard_io_resources();
> -}
> -
> -#endif /* CONFIG_X86_32 */

Re: [PATCH -v3 1/3] x86: Reserve [0xa0000, 0x100000] in e820 map

[Jesse Barnes]

On Fri, 23 Apr 2010 16:30:33 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> Hi Jesse,
> 
> I am considering putting this patch plus the two followup patches in my
> next set of fixes to Linus.  However, the two followup patches are
> really more PCI-related than x86-related, so I would appreciate your OK.
> 
> I'm using this version (-v3) because the latter cleanup (removing
> probe_rom_32.c for example) do not seem to be .34 material.
> 
> For the followup patches:
> 
> http://marc.info/?i=4BC4E0E9.7000203@oracle.com
> http://marc.info/?i=4BC4E115.90805@oracle.com

I was going to congratulate Yinghai on writing good changelogs, but
then I saw Bjorn actually wrote these ones for him. :)  At any rate they
looks good:

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>



-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH -v3 2/3] x86,pci, acpi: host bridge windows inherit BUSY flag from parent

[Yinghai]

If a host bridge window falls inside a region the architecture has
marked busy, the window should inherit the busy flag so we don't
try to assign that region to a device.

[commit log is from Bjorn]

Tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/acpi.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/arch/x86/pci/acpi.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -175,6 +175,10 @@ setup_resource(struct acpi_resource *acp
 			"conflicts with %s %pR\n",
 			res, conflict->name, conflict);
 	} else {
+		/* In case it falls in big reserved region */
+		if (res->parent->flags & IORESOURCE_BUSY)
+			res->flags |= IORESOURCE_BUSY;
+
 		pci_bus_add_resource(info->bus, res, 0);
 		info->res_num++;
 		if (addr.translation_offset)

[PATCH -v3 3/3] pci: don't allocate from a BUSY bus resource

[Yinghai]

  Drivers typically use pci_request_regions() to reserve the resources
  they use, but that fails if the resource is already busy.  Therefore,
  we should ignore busy resources when we're assigning resources to a
  device.

[commit log is from Bjorn]

Tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 drivers/pci/bus.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/drivers/pci/bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -103,6 +103,10 @@ pci_bus_alloc_resource(struct pci_bus *b
 		if (!r)
 			continue;
 
+		/* Driver can not reserve it later, so don't use it */
+		if (r->flags & IORESOURCE_BUSY)
+			continue;
+
 		/* type_mask must match */
 		if ((res->flags ^ r->flags) & type_mask)
 			continue;

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 02:18 PM, H. Peter Anvin wrote:
> On 04/13/2010 02:11 PM, Yinghai wrote:
>>>
>>> I guess the real question (which I haven't looked at myself) is if the
>>> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
>>> moved.  That's bad, not so much for this particular range, but from BARs
>>> which may be assigned by SMM.  Hacking that up in a simulator
>>> (Qemu/Bochs) and testing it is probably on the to do list...
>>
>> no, if some device BAR fall in that range, it should still use that range, and will not be relocated.
>>
>> will update the change log.
>>
> 
> Good, that's what we want.

the driver for that device later can not use pci_request_region(). because that region is BUSY already.

YH

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

On 04/13/2010 02:42 PM, Yinghai wrote:
> On 04/13/2010 02:18 PM, H. Peter Anvin wrote:
>> On 04/13/2010 02:11 PM, Yinghai wrote:
>>>>
>>>> I guess the real question (which I haven't looked at myself) is if the
>>>> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
>>>> moved.  That's bad, not so much for this particular range, but from BARs
>>>> which may be assigned by SMM.  Hacking that up in a simulator
>>>> (Qemu/Bochs) and testing it is probably on the to do list...
>>>
>>> no, if some device BAR fall in that range, it should still use that range, and will not be relocated.
>>>
>>> will update the change log.
>>>
>>
>> Good, that's what we want.
> 
> the driver for that device later can not use pci_request_region(). because that region is BUSY already.
> 

That's not good (in general - for devices in this particular range it's
not such a big deal, but it is potentially really bad for devices marked
reserved for them not to be moved.)

We have talked about a need to resolve this before.

	-hpa

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 02:58 PM, H. Peter Anvin wrote:
> On 04/13/2010 02:42 PM, Yinghai wrote:
>> On 04/13/2010 02:18 PM, H. Peter Anvin wrote:
>>> On 04/13/2010 02:11 PM, Yinghai wrote:
>>>>>
>>>>> I guess the real question (which I haven't looked at myself) is if the
>>>>> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
>>>>> moved.  That's bad, not so much for this particular range, but from BARs
>>>>> which may be assigned by SMM.  Hacking that up in a simulator
>>>>> (Qemu/Bochs) and testing it is probably on the to do list...
>>>>
>>>> no, if some device BAR fall in that range, it should still use that range, and will not be relocated.
>>>>
>>>> will update the change log.
>>>>
>>>
>>> Good, that's what we want.
>>
>> the driver for that device later can not use pci_request_region(). because that region is BUSY already.
>>
> 
> That's not good (in general - for devices in this particular range it's
> not such a big deal, but it is potentially really bad for devices marked
> reserved for them not to be moved.)
> 
> We have talked about a need to resolve this before.

current code for mmio that is just below 4g, if some PCI BAR use that range, and those range is falling into E820_RESERVED,

those range still can be claimed, but driver can not use pci_request_region() later.

So We still
1. rely that BIOS does not reserve the [0xa0000, 0xe0000)
2. kernel only reserve the range when we make sure these is legacy device on that range.

YH

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 03:29 PM, Yinghai wrote:
> On 04/13/2010 02:58 PM, H. Peter Anvin wrote:
>> On 04/13/2010 02:42 PM, Yinghai wrote:
>>> On 04/13/2010 02:18 PM, H. Peter Anvin wrote:
>>>> On 04/13/2010 02:11 PM, Yinghai wrote:
>>>>>>
>>>>>> I guess the real question (which I haven't looked at myself) is if the
>>>>>> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
>>>>>> moved.  That's bad, not so much for this particular range, but from BARs
>>>>>> which may be assigned by SMM.  Hacking that up in a simulator
>>>>>> (Qemu/Bochs) and testing it is probably on the to do list...
>>>>>
>>>>> no, if some device BAR fall in that range, it should still use that range, and will not be relocated.
>>>>>
>>>>> will update the change log.
>>>>>
>>>>
>>>> Good, that's what we want.
>>>
>>> the driver for that device later can not use pci_request_region(). because that region is BUSY already.
>>>
>>
>> That's not good (in general - for devices in this particular range it's
>> not such a big deal, but it is potentially really bad for devices marked
>> reserved for them not to be moved.)
>>
>> We have talked about a need to resolve this before.
> 
> current code for mmio that is just below 4g, if some PCI BAR use that range, and those range is falling into E820_RESERVED,
> 
> those range still can be claimed, but driver can not use pci_request_region() later.
should be
but driver can use pci_request_region() later.

> 
> So We still
> 1. rely that BIOS does not reserve the [0xa0000, 0xe0000)
> 2. kernel only reserve the range when we make sure these is legacy device on that range.
> 
> YH

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

On 04/13/2010 03:29 PM, Yinghai wrote:
>>
>> We have talked about a need to resolve this before.
> 
> current code for mmio that is just below 4g, if some PCI BAR use that range, and those range is falling into E820_RESERVED,
> 
> those range still can be claimed, but driver can not use pci_request_region() later.
> 
> So We still
> 1. rely that BIOS does not reserve the [0xa0000, 0xe0000)
> 2. kernel only reserve the range when we make sure these is legacy device on that range.
> 

This really isn't sufficient.  There are systems in the field which
marks a memory range reserved in E820 because it a device pointed there,
and it doesn't want that device moved because it is used by an SMM handler.

This was reported quite a while ago (like two years.)  I can dig up the
thread if it matters.

	-hpa

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 03:41 PM, H. Peter Anvin wrote:
> On 04/13/2010 03:29 PM, Yinghai wrote:
>>>
>>> We have talked about a need to resolve this before.
>>
>> current code for mmio that is just below 4g, if some PCI BAR use that range, and those range is falling into E820_RESERVED,
>>
>> those range still can be claimed, but driver can not use pci_request_region() later.
>>
>> So We still
>> 1. rely that BIOS does not reserve the [0xa0000, 0xe0000)
>> 2. kernel only reserve the range when we make sure these is legacy device on that range.
>>
> 
> This really isn't sufficient.  There are systems in the field which
> marks a memory range reserved in E820 because it a device pointed there,
> and it doesn't want that device moved because it is used by an SMM handler.
> 
> This was reported quite a while ago (like two years.)  I can dig up the
> thread if it matters.

Are you sure? what is BAR range? greater than 1M ?

e820_reserve_resources() will make that range to be reserved and BUSY in resource tree.
and if driver for that device want to call pci_request_region, it will get failure...

YH

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

> 
> Are you sure? what is BAR range? greater than 1M ?
> 
> e820_reserve_resources() will make that range to be reserved and BUSY in resource tree.
> and if driver for that device want to call pci_request_region, it will get failure...
> 

Yes, > 1 MB in that case, I'm fairly sure.

	-hpa

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 04:02 PM, H. Peter Anvin wrote:
>>
>> Are you sure? what is BAR range? greater than 1M ?
>>
>> e820_reserve_resources() will make that range to be reserved and BUSY in resource tree.
>> and if driver for that device want to call pci_request_region, it will get failure...
>>
> 
> Yes, > 1 MB in that case, I'm fairly sure.

that is ok. actually that is handled by e820_reserve_resource_late(), and it will not put BUSY on the entry at all.

YH

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

On 04/13/2010 04:03 PM, Yinghai wrote:
> On 04/13/2010 04:02 PM, H. Peter Anvin wrote:
>>>
>>> Are you sure? what is BAR range? greater than 1M ?
>>>
>>> e820_reserve_resources() will make that range to be reserved and BUSY in resource tree.
>>> and if driver for that device want to call pci_request_region, it will get failure...
>>>
>>
>> Yes, > 1 MB in that case, I'm fairly sure.
> 
> that is ok. actually that is handled by e820_reserve_resource_late(), and it will not put BUSY on the entry at all.
> 

OK... why is that handled differently?

	-hpa

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 04:07 PM, H. Peter Anvin wrote:
> On 04/13/2010 04:03 PM, Yinghai wrote:
>> On 04/13/2010 04:02 PM, H. Peter Anvin wrote:
>>>>
>>>> Are you sure? what is BAR range? greater than 1M ?
>>>>
>>>> e820_reserve_resources() will make that range to be reserved and BUSY in resource tree.
>>>> and if driver for that device want to call pci_request_region, it will get failure...
>>>>
>>>
>>> Yes, > 1 MB in that case, I'm fairly sure.
>>
>> that is ok. actually that is handled by e820_reserve_resource_late(), and it will not put BUSY on the entry at all.
>>
> 
> OK... why is that handled differently?

about one year ago, Linus made that change to use insert_resource_expand_to_fit() to honor PCI device BAR than E820_RESERVED.

YH

[PATCH -v4 1/3] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

Update e820 at first, and later put them resource tree.
Reserved that early, will not be allocated to unassigned PCI BAR

v3: remove probe_roms() that is not needed, because whole range is reserved
	 already

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Andy Isaacson <adi@hexapodia.org>
Tested-by: Andy Isaacson <adi@hexapodia.org>

---
 arch/x86/include/asm/setup.h    |    3 
 arch/x86/include/asm/x86_init.h |    4 
 arch/x86/kernel/Makefile        |    1 
 arch/x86/kernel/head32.c        |    2 
 arch/x86/kernel/mrst.c          |    2 
 arch/x86/kernel/probe_roms_32.c |  166 ----------------------------------------
 arch/x86/kernel/setup.c         |   25 ------
 arch/x86/kernel/x86_init.c      |    2 
 8 files changed, 8 insertions(+), 197 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -43,8 +43,8 @@ static inline void visws_early_detect(vo
 
 extern unsigned long saved_video_mode;
 
+void trim_bios_range(void);
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
@@ -96,7 +96,6 @@ void *extend_brk(size_t size, size_t ali
 #ifdef __i386__
 
 void __init i386_start_kernel(void);
-extern void probe_roms(void);
 
 #else
 void __init x86_64_start_kernel(char *real_mode);
Index: linux-2.6/arch/x86/include/asm/x86_init.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/x86_init.h
+++ linux-2.6/arch/x86/include/asm/x86_init.h
@@ -32,14 +32,14 @@ struct x86_init_mpparse {
 
 /**
  * struct x86_init_resources - platform specific resource related ops
- * @probe_roms:			probe BIOS roms
+ * @trim_bios_range:		trim BIOS related range in E820
  * @reserve_resources:		reserve the standard resources for the
  *				platform
  * @memory_setup:		platform specific memory setup
  *
  */
 struct x86_init_resources {
-	void (*probe_roms)(void);
+	void (*trim_bios_range)(void);
 	void (*reserve_resources)(void);
 	char *(*memory_setup)(void);
 };
Index: linux-2.6/arch/x86/kernel/Makefile
===================================================================
--- linux-2.6.orig/arch/x86/kernel/Makefile
+++ linux-2.6/arch/x86/kernel/Makefile
@@ -34,7 +34,6 @@ obj-y			+= traps.o irq.o irq_$(BITS).o d
 obj-y			+= time.o ioport.o ldt.o dumpstack.o
 obj-y			+= setup.o x86_init.o i8259.o irqinit.o
 obj-$(CONFIG_X86_VISWS)	+= visws_quirks.o
-obj-$(CONFIG_X86_32)	+= probe_roms_32.o
 obj-$(CONFIG_X86_32)	+= sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o
 obj-$(CONFIG_X86_64)	+= syscall_64.o vsyscall_64.o
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -21,8 +21,6 @@
 static void __init i386_default_early_setup(void)
 {
 	/* Initilize 32bit specific setup functions */
-	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/mrst.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/mrst.c
+++ linux-2.6/arch/x86/kernel/mrst.c
@@ -222,7 +222,7 @@ static void __init mrst_setup_boot_clock
  */
 void __init x86_mrst_early_setup(void)
 {
-	x86_init.resources.probe_roms = x86_init_noop;
+	x86_init.resources.trim_bios_range = x86_init_noop;
 	x86_init.resources.reserve_resources = x86_init_noop;
 
 	x86_init.timers.timer_init = mrst_time_init;
Index: linux-2.6/arch/x86/kernel/probe_roms_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/probe_roms_32.c
+++ /dev/null
@@ -1,166 +0,0 @@
-#include <linux/sched.h>
-#include <linux/mm.h>
-#include <linux/uaccess.h>
-#include <linux/mmzone.h>
-#include <linux/ioport.h>
-#include <linux/seq_file.h>
-#include <linux/console.h>
-#include <linux/init.h>
-#include <linux/edd.h>
-#include <linux/dmi.h>
-#include <linux/pfn.h>
-#include <linux/pci.h>
-#include <asm/pci-direct.h>
-
-
-#include <asm/e820.h>
-#include <asm/mmzone.h>
-#include <asm/setup.h>
-#include <asm/sections.h>
-#include <asm/io.h>
-#include <asm/setup_arch.h>
-
-static struct resource system_rom_resource = {
-	.name	= "System ROM",
-	.start	= 0xf0000,
-	.end	= 0xfffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-};
-
-static struct resource extension_rom_resource = {
-	.name	= "Extension ROM",
-	.start	= 0xe0000,
-	.end	= 0xeffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-};
-
-static struct resource adapter_rom_resources[] = { {
-	.name 	= "Adapter ROM",
-	.start	= 0xc8000,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-} };
-
-static struct resource video_rom_resource = {
-	.name 	= "Video ROM",
-	.start	= 0xc0000,
-	.end	= 0xc7fff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-};
-
-#define ROMSIGNATURE 0xaa55
-
-static int __init romsignature(const unsigned char *rom)
-{
-	const unsigned short * const ptr = (const unsigned short *)rom;
-	unsigned short sig;
-
-	return probe_kernel_address(ptr, sig) == 0 && sig == ROMSIGNATURE;
-}
-
-static int __init romchecksum(const unsigned char *rom, unsigned long length)
-{
-	unsigned char sum, c;
-
-	for (sum = 0; length && probe_kernel_address(rom++, c) == 0; length--)
-		sum += c;
-	return !length && !sum;
-}
-
-void __init probe_roms(void)
-{
-	const unsigned char *rom;
-	unsigned long start, length, upper;
-	unsigned char c;
-	int i;
-
-	/* video rom */
-	upper = adapter_rom_resources[0].start;
-	for (start = video_rom_resource.start; start < upper; start += 2048) {
-		rom = isa_bus_to_virt(start);
-		if (!romsignature(rom))
-			continue;
-
-		video_rom_resource.start = start;
-
-		if (probe_kernel_address(rom + 2, c) != 0)
-			continue;
-
-		/* 0 < length <= 0x7f * 512, historically */
-		length = c * 512;
-
-		/* if checksum okay, trust length byte */
-		if (length && romchecksum(rom, length))
-			video_rom_resource.end = start + length - 1;
-
-		request_resource(&iomem_resource, &video_rom_resource);
-		break;
-	}
-
-	start = (video_rom_resource.end + 1 + 2047) & ~2047UL;
-	if (start < upper)
-		start = upper;
-
-	/* system rom */
-	request_resource(&iomem_resource, &system_rom_resource);
-	upper = system_rom_resource.start;
-
-	/* check for extension rom (ignore length byte!) */
-	rom = isa_bus_to_virt(extension_rom_resource.start);
-	if (romsignature(rom)) {
-		length = extension_rom_resource.end - extension_rom_resource.start + 1;
-		if (romchecksum(rom, length)) {
-			request_resource(&iomem_resource, &extension_rom_resource);
-			upper = extension_rom_resource.start;
-		}
-	}
-
-	/* check for adapter roms on 2k boundaries */
-	for (i = 0; i < ARRAY_SIZE(adapter_rom_resources) && start < upper; start += 2048) {
-		rom = isa_bus_to_virt(start);
-		if (!romsignature(rom))
-			continue;
-
-		if (probe_kernel_address(rom + 2, c) != 0)
-			continue;
-
-		/* 0 < length <= 0x7f * 512, historically */
-		length = c * 512;
-
-		/* but accept any length that fits if checksum okay */
-		if (!length || start + length > upper || !romchecksum(rom, length))
-			continue;
-
-		adapter_rom_resources[i].start = start;
-		adapter_rom_resources[i].end = start + length - 1;
-		request_resource(&iomem_resource, &adapter_rom_resources[i]);
-
-		start = adapter_rom_resources[i++].end & ~2047UL;
-	}
-}
-
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -680,7 +680,7 @@ static struct dmi_system_id __initdata b
 	{}
 };
 
-static void __init trim_bios_range(void)
+void __init trim_bios_range(void)
 {
 	/*
 	 * A special case is the first 4Kb of memory;
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -853,14 +853,12 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	init_hypervisor_platform();
 
-	x86_init.resources.probe_roms();
-
 	/* after parse_early_param, so could debug it */
 	insert_resource(&iomem_resource, &code_resource);
 	insert_resource(&iomem_resource, &data_resource);
 	insert_resource(&iomem_resource, &bss_resource);
 
-	trim_bios_range();
+	x86_init.resources.trim_bios_range();
 #ifdef CONFIG_X86_32
 	if (ppro_with_ram_bug()) {
 		e820_update_range(0x70000000ULL, 0x40000ULL, E820_RAM,
@@ -1052,20 +1050,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */
Index: linux-2.6/arch/x86/kernel/x86_init.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/x86_init.c
+++ linux-2.6/arch/x86/kernel/x86_init.c
@@ -32,7 +32,7 @@ void iommu_shutdown_noop(void) { }
 struct x86_init_ops x86_init __initdata = {
 
 	.resources = {
-		.probe_roms		= x86_init_noop,
+		.trim_bios_range	= trim_bios_range,
 		.reserve_resources	= reserve_standard_io_resources,
 		.memory_setup		= default_machine_specific_memory_setup,
 	},

[PATCH 2/3] x86, resource: Add reserve_region_with_split_check_child()

[Yinghai]

It will cover the whole region to BUSY, except that some regions that have
children under them.

those children normally is PCI bar but it is falling into E820_RESERVED.
We can not put BUSY on them, otherwise driver can not use pci_request_region()
later

/proc/iomem will have
00010000-00094fff : System RAM
00095000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
  000a0000-000bffff : reserved
000c0000-000cffff : reserved
000d0000-000dffff : PCI Bus 0000:00
  000d0000-000dffff : reserved
000e0000-000fffff : reserved

Tested-by: Guenter Roeck <guenter.roeck@ericsson.com>
Tested-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/e820.c |   10 +++++++---
 include/linux/ioport.h |    3 +++
 kernel/resource.c      |   24 +++++++++++++++++++-----
 3 files changed, 29 insertions(+), 8 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
@@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
 		 * pci device BAR resource and insert them later in
 		 * pcibios_resource_survey()
 		 */
-		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+		if (e820.map[i].type != E820_RESERVED) {
 			res->flags |= IORESOURCE_BUSY;
 			insert_resource(&iomem_resource, res);
 		}
@@ -1135,8 +1135,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_expand_to_fit(&iomem_resource, res);
+		if (!res->parent && res->end) {
+			if (res->start < (1ULL<<20))
+				reserve_region_with_split_check_child(&iomem_resource, res->start, res->end, res->name);
+			else
+				insert_resource_expand_to_fit(&iomem_resource, res);
+		}
 		res++;
 	}
 
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -120,6 +120,9 @@ void release_child_resources(struct reso
 extern void reserve_region_with_split(struct resource *root,
 			     resource_size_t start, resource_size_t end,
 			     const char *name);
+void reserve_region_with_split_check_child(struct resource *root,
+			     resource_size_t start, resource_size_t end,
+			     const char *name);
 extern struct resource *insert_resource_conflict(struct resource *parent, 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);
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -609,7 +609,7 @@ int adjust_resource(struct resource *res
 
 static void __init __reserve_region_with_split(struct resource *root,
 		resource_size_t start, resource_size_t end,
-		const char *name)
+		const char *name, bool check_child)
 {
 	struct resource *parent = root;
 	struct resource *conflict;
@@ -631,13 +631,18 @@ static void __init __reserve_region_with
 	kfree(res);
 
 	/* conflict covered whole area */
-	if (conflict->start <= start && conflict->end >= end)
+	if (conflict->start <= start && conflict->end >= end) {
+		if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
+			__reserve_region_with_split(conflict, start, end, name, false);
 		return;
+	}
 
 	if (conflict->start > start)
-		__reserve_region_with_split(root, start, conflict->start-1, name);
+		__reserve_region_with_split(root, start, conflict->start-1, name, check_child);
 	if (conflict->end < end)
-		__reserve_region_with_split(root, conflict->end+1, end, name);
+		__reserve_region_with_split(root, conflict->end+1, end, name, check_child);
+	if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
+		__reserve_region_with_split(conflict, conflict->start, conflict->end, name, false);
 }
 
 void __init reserve_region_with_split(struct resource *root,
@@ -645,7 +650,16 @@ void __init reserve_region_with_split(st
 		const char *name)
 {
 	write_lock(&resource_lock);
-	__reserve_region_with_split(root, start, end, name);
+	__reserve_region_with_split(root, start, end, name, false);
+	write_unlock(&resource_lock);
+}
+
+void __init reserve_region_with_split_check_child(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, true);
 	write_unlock(&resource_lock);
 }
 

[PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Yinghai]

Don't clear root bus resource too early, until We can make sure _CRS works

also restore it, if all _CRS get rejected because of conflicts

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/acpi.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/x86/pci/acpi.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -196,9 +196,6 @@ get_current_resources(struct acpi_device
 	struct pci_root_info info;
 	size_t size;
 
-	if (pci_use_crs)
-		pci_bus_remove_resources(bus);
-
 	info.bridge = device;
 	info.bus = bus;
 	info.res_num = 0;
@@ -217,10 +214,20 @@ get_current_resources(struct acpi_device
 		goto name_alloc_fail;
 	sprintf(info.name, "PCI Bus %04x:%02x", domain, busnum);
 
+	/* Only clear that when _CRS works for sure*/
+	if (pci_use_crs)
+		pci_bus_remove_resources(bus);
+
 	info.res_num = 0;
 	acpi_walk_resources(device->handle, METHOD_NAME__CRS, setup_resource,
 				&info);
 
+	if (pci_use_crs && !info.res_num) {
+		/* Restore default one */
+		bus->resource[0] = &ioport_resource;
+		bus->resource[1] = &iomem_resource;
+	}
+
 	return;
 
 name_alloc_fail:

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Bjorn Helgaas]

On Tuesday 20 April 2010 11:35:59 pm Yinghai wrote:
> 
> Don't clear root bus resource too early, until We can make sure _CRS works

Please observe English conventions like capitalizing the first word
of a sentence (and not things like "We" in the middle) and using
a period at the end.

> also restore it, if all _CRS get rejected because of conflicts
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/pci/acpi.c |   13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> Index: linux-2.6/arch/x86/pci/acpi.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/acpi.c
> +++ linux-2.6/arch/x86/pci/acpi.c
> @@ -196,9 +196,6 @@ get_current_resources(struct acpi_device
>  	struct pci_root_info info;
>  	size_t size;
>  
> -	if (pci_use_crs)
> -		pci_bus_remove_resources(bus);
> -
>  	info.bridge = device;
>  	info.bus = bus;
>  	info.res_num = 0;
> @@ -217,10 +214,20 @@ get_current_resources(struct acpi_device
>  		goto name_alloc_fail;
>  	sprintf(info.name, "PCI Bus %04x:%02x", domain, busnum);
>  
> +	/* Only clear that when _CRS works for sure*/

If you put a comment here, please at least add a space before the
closing "*/".  Otherwise it looks sloppy.

> +	if (pci_use_crs)
> +		pci_bus_remove_resources(bus);
> +
>  	info.res_num = 0;
>  	acpi_walk_resources(device->handle, METHOD_NAME__CRS, setup_resource,
>  				&info);
>  
> +	if (pci_use_crs && !info.res_num) {
> +		/* Restore default one */
> +		bus->resource[0] = &ioport_resource;
> +		bus->resource[1] = &iomem_resource;

This is ugly because it just repeats this code from pci_create_bus(),
and there's no indication either here or there that they are connected.

Admittedly, I think it's also sort of ugly that pci_bus_remove_resources()
exists at all -- I'd rather have some sort of hook so we could set the
bus resources correctly the first time.

Maybe you could at least add a pci_bus_set_default_resources() that
could be called both here and from pci_create_bus().

Why are you doing this patch?  Did you see a machine where the host
bridge was left with no resources because of _CRS issues?  If so,
this patch feels like a band-aid.  I'd rather investigate the issue
directly, because that would probably be a Linux problem we could fix.

Also, if there *is* a reported problem, you should include a link to
the bugzilla or email thread.

Bjorn

> +	}
> +
>  	return;
>  
>  name_alloc_fail:
> 

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Yinghai Lu]

On 04/21/2010 08:21 AM, Bjorn Helgaas wrote:
>
>
>> +	if (pci_use_crs)
>> +		pci_bus_remove_resources(bus);
>> +
>>  	info.res_num = 0;
>>  	acpi_walk_resources(device->handle, METHOD_NAME__CRS, setup_resource,
>>  				&info);
>>  
>> +	if (pci_use_crs && !info.res_num) {
>> +		/* Restore default one */
>> +		bus->resource[0] = &ioport_resource;
>> +		bus->resource[1] = &iomem_resource;
>>     
> This is ugly because it just repeats this code from pci_create_bus(),
> and there's no indication either here or there that they are connected.
>
> Admittedly, I think it's also sort of ugly that pci_bus_remove_resources()
> exists at all -- I'd rather have some sort of hook so we could set the
> bus resources correctly the first time.
>   
sure. that would be better. Can you have patch for that.
> Maybe you could at least add a pci_bus_set_default_resources() that
> could be called both here and from pci_create_bus().
>   
good idea.
> Why are you doing this patch?  Did you see a machine where the host
> bridge was left with no resources because of _CRS issues?  If so,
> this patch feels like a band-aid.  I'd rather investigate the issue
> directly, because that would probably be a Linux problem we could fix.
>
> Also, if there *is* a reported problem, you should include a link to
> the bugzilla or email thread.
>   
No, just code review.

YH

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Bjorn Helgaas]

On Wednesday 21 April 2010 10:45:46 am Yinghai Lu wrote:
> On 04/21/2010 08:21 AM, Bjorn Helgaas wrote:

> > Why are you doing this patch?  Did you see a machine where the host
> > bridge was left with no resources because of _CRS issues?  If so,
> > this patch feels like a band-aid.  I'd rather investigate the issue
> > directly, because that would probably be a Linux problem we could fix.
> >
> > Also, if there *is* a reported problem, you should include a link to
> > the bugzilla or email thread.
> >   
> No, just code review.

In that case, I don't think this patch is a good idea.  Assume we have
a Linux problem with _CRS parsing, and as a result, we don't find any
host bridge resources.  This patch will cause us to silently revert to
the default resources, so we lose the opportunity to debug and fix the
Linux problem.

Even worse, if there's a *BIOS* problem with _CRS, this patch will hide
it and make it harder to diagnose.

Bjorn

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[H. Peter Anvin]

On 04/21/2010 09:59 AM, Bjorn Helgaas wrote:
> On Wednesday 21 April 2010 10:45:46 am Yinghai Lu wrote:
>> On 04/21/2010 08:21 AM, Bjorn Helgaas wrote:
> 
>>> Why are you doing this patch?  Did you see a machine where the host
>>> bridge was left with no resources because of _CRS issues?  If so,
>>> this patch feels like a band-aid.  I'd rather investigate the issue
>>> directly, because that would probably be a Linux problem we could fix.
>>>
>>> Also, if there *is* a reported problem, you should include a link to
>>> the bugzilla or email thread.
>>>   
>> No, just code review.
> 
> In that case, I don't think this patch is a good idea.  Assume we have
> a Linux problem with _CRS parsing, and as a result, we don't find any
> host bridge resources.  This patch will cause us to silently revert to
> the default resources, so we lose the opportunity to debug and fix the
> Linux problem.
> 
> Even worse, if there's a *BIOS* problem with _CRS, this patch will hide
> it and make it harder to diagnose.
> 
> Bjorn

Hi Bjorn,

Do you have opinions on patches 1-2 of the series?

I'm getting concerned about how the size of the patchset has grown, and
we're past -rc5 already... but it is a regression so we can't just defer
it to .35.

	-hpa

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Bjorn Helgaas]

On Wednesday 21 April 2010 04:33:28 pm H. Peter Anvin wrote:
> Do you have opinions on patches 1-2 of the series?
> 
> I'm getting concerned about how the size of the patchset has grown, and
> we're past -rc5 already... but it is a regression so we can't just defer
> it to .35.

Part 1: the essential part of this seems to be the trim_bios_range()
change, and that part is not too big.  In v4, Yinghai also removed
probe_roms_32.c.  That sounds like the right thing to do, but I'd
rather have that in separate patch so it doesn't obfuscate the other
change, and I don't know whether it *has* to be done for .34; maybe
it could be deferred.

Part 2: IMHO, we're putting way too much crap in kernel/resource.c.
A name like "reserve_region_with_split_check_child()" is a pretty
good clue that we've lost our way somewhere.  But that's mostly a
cosmetic thing, and the end result does seem to be something that
fixes the current regression.

So I guess that in spite of my issues with the implementation, I'm
still OK with the concept.

Bjorn

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[H. Peter Anvin]

On 04/21/2010 04:04 PM, Bjorn Helgaas wrote:
> On Wednesday 21 April 2010 04:33:28 pm H. Peter Anvin wrote:
>> Do you have opinions on patches 1-2 of the series?
>>
>> I'm getting concerned about how the size of the patchset has grown, and
>> we're past -rc5 already... but it is a regression so we can't just defer
>> it to .35.
> 
> Part 1: the essential part of this seems to be the trim_bios_range()
> change, and that part is not too big.  In v4, Yinghai also removed
> probe_roms_32.c.  That sounds like the right thing to do, but I'd
> rather have that in separate patch so it doesn't obfuscate the other
> change, and I don't know whether it *has* to be done for .34; maybe
> it could be deferred.

I would agree with that.

> Part 2: IMHO, we're putting way too much crap in kernel/resource.c.
> A name like "reserve_region_with_split_check_child()" is a pretty
> good clue that we've lost our way somewhere.  But that's mostly a
> cosmetic thing, and the end result does seem to be something that
> fixes the current regression.

It's not just a good clue we have lost our way, it's also completely
impossible for anyone but Yinghai to divine what the intended semantics
are supposed to be.  This *greatly* concerns me, especially given
previous track record.

Even the checkin comment is almost unparsable, which makes it very
likely that someone is going to trip up on some of this in the future.
I really would like to get a better description.

The use of a string match in:

+       if (check_child && !conflict->child && strstr(conflict->name,
"PCI Bus"))
^^^^^^^^^

... screams "wrong! ugly! bad!" in my opinion.  I utterly fail to see
how that could be acceptable under any circumstances.  I thought that
had been flagged earlier in the conversation, but it is apparently still
there.

> So I guess that in spite of my issues with the implementation, I'm
> still OK with the concept.

OK, but what is "the implementation" and what is "the concept" here?

	-hap

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Yinghai]

On 04/21/2010 04:10 PM, H. Peter Anvin wrote:
> On 04/21/2010 04:04 PM, Bjorn Helgaas wrote:
>> On Wednesday 21 April 2010 04:33:28 pm H. Peter Anvin wrote:
>>> Do you have opinions on patches 1-2 of the series?
>>>
>>> I'm getting concerned about how the size of the patchset has grown, and
>>> we're past -rc5 already... but it is a regression so we can't just defer
>>> it to .35.
>>
>> Part 1: the essential part of this seems to be the trim_bios_range()
>> change, and that part is not too big.  In v4, Yinghai also removed
>> probe_roms_32.c.  That sounds like the right thing to do, but I'd
>> rather have that in separate patch so it doesn't obfuscate the other
>> change, and I don't know whether it *has* to be done for .34; maybe
>> it could be deferred.
> 
> I would agree with that.

then use -v3 please

-v4: also don't trim [0xa0000, 0x100000] for mrst.

> 
>> Part 2: IMHO, we're putting way too much crap in kernel/resource.c.
>> A name like "reserve_region_with_split_check_child()" is a pretty
>> good clue that we've lost our way somewhere.  But that's mostly a
>> cosmetic thing, and the end result does seem to be something that
>> fixes the current regression.
> 
> It's not just a good clue we have lost our way, it's also completely
> impossible for anyone but Yinghai to divine what the intended semantics
> are supposed to be.  This *greatly* concerns me, especially given
> previous track record.

I don't know.

insert_resource_expand_to_fit() is added by Linus.

And at least he knew old reserve_region_with_split()

> 
> Even the checkin comment is almost unparsable, which makes it very
> likely that someone is going to trip up on some of this in the future.
> I really would like to get a better description.
> 
> The use of a string match in:
> 
> +       if (check_child && !conflict->child && strstr(conflict->name,
> "PCI Bus"))
> ^^^^^^^^^
> 
> ... screams "wrong! ugly! bad!" in my opinion.  I utterly fail to see
> how that could be acceptable under any circumstances.  I thought that
> had been flagged earlier in the conversation, but it is apparently still
> there.


the string checking is to make sure pci device that is hooked into bus0 directly, but pci bar is falling into
0xa0000 - 0x100000.
so can not put "reserved" holder under them.

YH

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[H. Peter Anvin]

On 04/21/2010 04:43 PM, Yinghai wrote:
>
> then use -v3 please
> 
> -v4: also don't trim [0xa0000, 0x100000] for mrst.
> 

That makes a lot of sense for 2.6.34.  I agree with moving the trimming
into subsystems, but I think it's .35 material at this point.

[Cc: Jacob Pan]

>>
>> The use of a string match in:
>>
>> +       if (check_child && !conflict->child && strstr(conflict->name,
>> "PCI Bus"))
>> ^^^^^^^^^
>>
>> ... screams "wrong! ugly! bad!" in my opinion.  I utterly fail to see
>> how that could be acceptable under any circumstances.  I thought that
>> had been flagged earlier in the conversation, but it is apparently still
>> there.
> 
> the string checking is to make sure pci device that is hooked into bus0 directly, but pci bar is falling into
> 0xa0000 - 0x100000.  So can not put "reserved" holder under them.
> 

It makes me extremely concerned, because such hacks tend to be extremely
vulnerable.  Strings are designed primarily for human consumption, and
"find string inside another string" is *very* much so.  As such, I
really would like to understand that there isn't any more sensible way,
such as a flag, that can be used to accomplish the objective.

	-hpa

Re: [PATCH 3/3] x86,pci,acpi: Handle invalid _CRS

[Yinghai]

On 04/21/2010 05:02 PM, H. Peter Anvin wrote:
> On 04/21/2010 04:43 PM, Yinghai wrote:
>>
>> then use -v3 please
>>
>> -v4: also don't trim [0xa0000, 0x100000] for mrst.
>>
> 
> That makes a lot of sense for 2.6.34.  I agree with moving the trimming
> into subsystems, but I think it's .35 material at this point.
> 
> [Cc: Jacob Pan]
> 
>>>
>>> The use of a string match in:
>>>
>>> +       if (check_child && !conflict->child && strstr(conflict->name,
>>> "PCI Bus"))
>>> ^^^^^^^^^
>>>
>>> ... screams "wrong! ugly! bad!" in my opinion.  I utterly fail to see
>>> how that could be acceptable under any circumstances.  I thought that
>>> had been flagged earlier in the conversation, but it is apparently still
>>> there.
>>
>> the string checking is to make sure pci device that is hooked into bus0 directly, but pci bar is falling into
>> 0xa0000 - 0x100000.  So can not put "reserved" holder under them.
>>
> 
> It makes me extremely concerned, because such hacks tend to be extremely
> vulnerable.  Strings are designed primarily for human consumption, and
> "find string inside another string" is *very* much so.  As such, I
> really would like to understand that there isn't any more sensible way,
> such as a flag, that can be used to accomplish the objective.

pass function pointer to additional checking?

YH

Re: [PATCH -v4 1/3] x86: Reserve [0xa0000, 0x100000] in e820 map

[Andy Isaacson]

On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
> Update e820 at first, and later put them resource tree.
> Reserved that early, will not be allocated to unassigned PCI BAR
> 
> v3: remove probe_roms() that is not needed, because whole range is reserved
> 	 already

Test booted this patch series on the problematic t3400, seems to work
fine.  dmesg attached to bug 15744.

-andy

[PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
> > Update e820 at first, and later put them resource tree.
> > Reserved that early, will not be allocated to unassigned PCI BAR
> > 
> > v3: remove probe_roms() that is not needed, because whole range is reserved
> > 	 already
> 
> Test booted this patch series on the problematic t3400, seems to work
> fine.  dmesg attached to bug 15744.

Thanks for testing (again).  I'm not confident that this series is
going to be successful, so I started looking for other approaches.

I can't reproduce the exact problem you're seeing, but in my
kludged-up attempt, the patch below is enough to keep us from
assigning the space below 1MB to a device.

Would you guys (Andy & Andy, what a coincidence :-)) mind giving
it a try?  This is intended to work on top of current upstream,
with no other patches required.

Bjorn


commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7
Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
Date:   Fri Apr 23 15:22:10 2010 -0600

x86/PCI: never allocate PCI MMIO resources below BIOS_END
    
When we move a PCI device or assign resources to a device not configured
by the BIOS, we want to avoid the BIOS region below 1MB.  Note that if the
BIOS places devices below 1MB, we leave them there.
    
See https://bugzilla.kernel.org/show_bug.cgi?id=15744
and https://bugzilla.kernel.org/show_bug.cgi?id=15841
    
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 46fd43f..97da2ba 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -72,6 +72,9 @@ pcibios_align_resource(void *data, const struct resource *res,
 			return start;
 		if (start & 0x300)
 			start = (start + 0x3ff) & ~0x3ff;
+	} else if (res->flags & IORESOURCE_MEM) {
+		if (start < BIOS_END)
+			start = BIOS_END;
 	}
 	return start;
 }

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

On 04/23/2010 04:05 PM, Bjorn Helgaas wrote:
> On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
>> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
>>> Update e820 at first, and later put them resource tree.
>>> Reserved that early, will not be allocated to unassigned PCI BAR
>>>
>>> v3: remove probe_roms() that is not needed, because whole range is reserved
>>> 	 already
>>
>> Test booted this patch series on the problematic t3400, seems to work
>> fine.  dmesg attached to bug 15744.
> 
> Thanks for testing (again).  I'm not confident that this series is
> going to be successful, so I started looking for other approaches.
> 
> I can't reproduce the exact problem you're seeing, but in my
> kludged-up attempt, the patch below is enough to keep us from
> assigning the space below 1MB to a device.
> 
> Would you guys (Andy & Andy, what a coincidence :-)) mind giving
> it a try?  This is intended to work on top of current upstream,
> with no other patches required.
> 

This certainly wins from a simplicity standpoint!

	-hpa

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Yinghai Lu]

On 04/23/2010 04:44 PM, H. Peter Anvin wrote:
> On 04/23/2010 04:05 PM, Bjorn Helgaas wrote:
>   
>> On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
>>     
>>> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
>>>       
>>>> Update e820 at first, and later put them resource tree.
>>>> Reserved that early, will not be allocated to unassigned PCI BAR
>>>>
>>>> v3: remove probe_roms() that is not needed, because whole range is reserved
>>>> 	 already
>>>>         
>>> Test booted this patch series on the problematic t3400, seems to work
>>> fine.  dmesg attached to bug 15744.
>>>       
>> Thanks for testing (again).  I'm not confident that this series is
>> going to be successful, so I started looking for other approaches.
>>
>> I can't reproduce the exact problem you're seeing, but in my
>> kludged-up attempt, the patch below is enough to keep us from
>> assigning the space below 1MB to a device.
>>
>> Would you guys (Andy & Andy, what a coincidence :-)) mind giving
>> it a try?  This is intended to work on top of current upstream,
>> with no other patches required.
>>
>>     
> This certainly wins from a simplicity standpoint!
>
>   
indeed.

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[R. Andrew Bailey]

On 23/04/10 17:05 -0600, Bjorn Helgaas wrote:
>On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
>> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
>> > Update e820 at first, and later put them resource tree.
>> > Reserved that early, will not be allocated to unassigned PCI BAR
>> >
>> > v3: remove probe_roms() that is not needed, because whole range is reserved
>> > 	 already
>>
>> Test booted this patch series on the problematic t3400, seems to work
>> fine.  dmesg attached to bug 15744.
>
>Thanks for testing (again).  I'm not confident that this series is
>going to be successful, so I started looking for other approaches.
>
>I can't reproduce the exact problem you're seeing, but in my
>kludged-up attempt, the patch below is enough to keep us from
>assigning the space below 1MB to a device.
>
>Would you guys (Andy & Andy, what a coincidence :-)) mind giving
>it a try?  This is intended to work on top of current upstream,
>with no other patches required.
>
>Bjorn
>

Good news- that solved it. I tried Yinghai's patches saturday to no
avail (sorry it took me so long to get back to you, I was about 5 bios
revisions behind on this machine and wanted to update it before I
tried any more tests).

  .andy

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

On Monday 26 April 2010 06:50:32 am R. Andrew Bailey wrote:
> On 23/04/10 17:05 -0600, Bjorn Helgaas wrote:
> >On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
> >Would you guys (Andy & Andy, what a coincidence :-)) mind giving
> >it a try?  This is intended to work on top of current upstream,
> >with no other patches required.
> >
> Good news- that solved it. I tried Yinghai's patches saturday to no
> avail (sorry it took me so long to get back to you, I was about 5 bios
> revisions behind on this machine and wanted to update it before I
> tried any more tests).

Great, thanks for testing this!  The only problem here is that we
changed two things at once -- the BIOS and the patch, and we need
to figure out which change fixed the problem.

I want Linux to work correctly even on the old BIOS, on the theory
that "if Windows works, Linux should work, too."  Changing a BIOS
is relatively risky, and it's not something I want users to have to
diagnose and deal with.

If we're lucky, the kernel without the patch will still fail on the
updated BIOS.  If the pre-patch kernel fails and the post-patch kernel
works, and you can attach the entire dmesg log of the post-patch kernel
to the bugzilla, we should be able to see Linux making more sensible
BAR assignments when working around the BIOS bug.  Then we can be pretty
confident that my patch fixed the problem.

If the pre-patch kernel works on the updated BIOS, that means one of
the BIOS updates fixed the BIOS bug, and we didn't actually exercise
my patch at all.  If that's the case, we'll have to wait for a report
from the other Andy.  (Or you could temporarily down-grade your BIOS
to the original version you had.  But I don't know whether that's even
possible...  it probably depends on the BIOS update tools.)

Thanks again for all your help.  All progress in Linux depends on early
adopters like you who are willing to test kernels and help work through
issues :-)

Bjorn

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Andy Isaacson]

On Fri, Apr 23, 2010 at 05:05:24PM -0600, Bjorn Helgaas wrote:
> On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
> > On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
> > > Update e820 at first, and later put them resource tree.
> > > Reserved that early, will not be allocated to unassigned PCI BAR
> > > 
> > > v3: remove probe_roms() that is not needed, because whole range is reserved
> > > 	 already
> > 
> > Test booted this patch series on the problematic t3400, seems to work
> > fine.  dmesg attached to bug 15744.
> 
> Thanks for testing (again).  I'm not confident that this series is
> going to be successful, so I started looking for other approaches.
> 
> I can't reproduce the exact problem you're seeing, but in my
> kludged-up attempt, the patch below is enough to keep us from
> assigning the space below 1MB to a device.
> 
> Would you guys (Andy & Andy, what a coincidence :-)) mind giving
> it a try?  This is intended to work on top of current upstream,
> with no other patches required.
> 
> Bjorn
> 
> 
> commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7
> Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Date:   Fri Apr 23 15:22:10 2010 -0600
> 
> x86/PCI: never allocate PCI MMIO resources below BIOS_END
>     
> When we move a PCI device or assign resources to a device not configured
> by the BIOS, we want to avoid the BIOS region below 1MB.  Note that if the
> BIOS places devices below 1MB, we leave them there.

Works for me.  dmesg at
https://bugzilla.kernel.org/attachment.cgi?id=26150

-andy

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

On Mon, 26 Apr 2010 11:34:36 -0700
Andy Isaacson <adi@hexapodia.org> wrote:

> On Fri, Apr 23, 2010 at 05:05:24PM -0600, Bjorn Helgaas wrote:
> > On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
> > > On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
> > > > Update e820 at first, and later put them resource tree.
> > > > Reserved that early, will not be allocated to unassigned PCI BAR
> > > > 
> > > > v3: remove probe_roms() that is not needed, because whole range is reserved
> > > > 	 already
> > > 
> > > Test booted this patch series on the problematic t3400, seems to work
> > > fine.  dmesg attached to bug 15744.
> > 
> > Thanks for testing (again).  I'm not confident that this series is
> > going to be successful, so I started looking for other approaches.
> > 
> > I can't reproduce the exact problem you're seeing, but in my
> > kludged-up attempt, the patch below is enough to keep us from
> > assigning the space below 1MB to a device.
> > 
> > Would you guys (Andy & Andy, what a coincidence :-)) mind giving
> > it a try?  This is intended to work on top of current upstream,
> > with no other patches required.
> > 
> > Bjorn
> > 
> > 
> > commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7
> > Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Date:   Fri Apr 23 15:22:10 2010 -0600
> > 
> > x86/PCI: never allocate PCI MMIO resources below BIOS_END
> >     
> > When we move a PCI device or assign resources to a device not configured
> > by the BIOS, we want to avoid the BIOS region below 1MB.  Note that if the
> > BIOS places devices below 1MB, we leave them there.
> 
> Works for me.  dmesg at
> https://bugzilla.kernel.org/attachment.cgi?id=26150

Great, thanks for testing.  Applied this one to my for-linus tree.  I
still thing Yinghai's patches should go in as well (marking regions as
busy seems like good housekeeping), but with this fixed they're a better
fit for -next.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

On Monday 26 April 2010 01:31:35 pm Jesse Barnes wrote:
> On Mon, 26 Apr 2010 11:34:36 -0700
> Andy Isaacson <adi@hexapodia.org> wrote:
> > On Fri, Apr 23, 2010 at 05:05:24PM -0600, Bjorn Helgaas wrote:

> > > commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7
> > > Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > > Date:   Fri Apr 23 15:22:10 2010 -0600
> > > 
> > > x86/PCI: never allocate PCI MMIO resources below BIOS_END
> > >     
> > > When we move a PCI device or assign resources to a device not configured
> > > by the BIOS, we want to avoid the BIOS region below 1MB.  Note that if the
> > > BIOS places devices below 1MB, we leave them there.
> > 
> > Works for me.  dmesg at
> > https://bugzilla.kernel.org/attachment.cgi?id=26150
> 
> Great, thanks for testing.  Applied this one to my for-linus tree.  

Thanks!

> I still think Yinghai's patches should go in as well (marking regions as
> busy seems like good housekeeping), but with this fixed they're a better
> fit for -next.

I'm a little concerned that those patches are a sledgehammer approach.
Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
between drivers that would otherwise claim the same resource.  It hasn't
been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
Right now it feels like undesirable overloading to me.

I think it also leads to at least one problem: Guenter's machine has no
VGA but has a PCI device that lives at 0xa0000.  The driver for that
device won't be able to request that region if the arch code has marked
it busy.

Bjorn

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

On Mon, 26 Apr 2010 14:27:56 -0600
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> I'm a little concerned that those patches are a sledgehammer approach.
> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
> between drivers that would otherwise claim the same resource.  It hasn't
> been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
> Right now it feels like undesirable overloading to me.

I guess that's true, removing those regions from the pool entirely
might be better?  Or some other, clear way of expressing that the
regions aren't available to drivers.  Maybe we need a new IO resource
type for platform ranges.

> I think it also leads to at least one problem: Guenter's machine has no
> VGA but has a PCI device that lives at 0xa0000.  The driver for that
> device won't be able to request that region if the arch code has marked
> it busy.

Ah good point, so we'll want another approach at any rate.  Yinghai?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Yinghai]

On 04/26/2010 01:37 PM, Jesse Barnes wrote:
> On Mon, 26 Apr 2010 14:27:56 -0600
>> I think it also leads to at least one problem: Guenter's machine has no
>> VGA but has a PCI device that lives at 0xa0000.  The driver for that
>> device won't be able to request that region if the arch code has marked
>> it busy.
> 
> Ah good point, so we'll want another approach at any rate.  Yinghai?

With current linus's tree, there is some difference between mmio > 1M and MMIO < 1M.

Actually it does not care about E820_RESERVED for > 1M range, because it doesn't have _BUSY.

For < 1M range, 
a. MMIO is not with E820_RESERVED, the device driver will work.
b. MMIO is with E820_RESERVED, the device driver can not reserve it's mmio later. because that MMIO could have parent resource with "reserved" name and _BUSY flag

My patch -v3 will break a.
but my patch -v4 patch will make it work.

but looks -v4 is too tricky.

maybe we just need remove change like following.

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7bca3c6..9849824 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
 		 * pci device BAR resource and insert them later in
 		 * pcibios_resource_survey()
 		 */
-		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+		if (e820.map[i].type != E820_RESERVED) {
 			res->flags |= IORESOURCE_BUSY;
 			insert_resource(&iomem_resource, res);
 		}

May need Linus to ack it.

Those strange devices could be some kind of virtual debug devices. and they like to use those low mmio range.

YH

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

>
> but looks -v4 is too tricky.
>

Let's distinguish between what we need for .34 -- we need something
minimal and as soon as possible at this stage -- and concentrate on
getting the right thing to happen going forward.

       -hpa

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

> On Mon, 26 Apr 2010 14:27:56 -0600
> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>> I'm a little concerned that those patches are a sledgehammer approach.
>> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
>> between drivers that would otherwise claim the same resource.  It hasn't
>> been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
>> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
>> Right now it feels like undesirable overloading to me.
>
> I guess that's true, removing those regions from the pool entirely
> might be better?  Or some other, clear way of expressing that the
> regions aren't available to drivers.  Maybe we need a new IO resource
> type for platform ranges.
>
>> I think it also leads to at least one problem: Guenter's machine has no
>> VGA but has a PCI device that lives at 0xa0000.  The driver for that
>> device won't be able to request that region if the arch code has marked
>> it busy.
>
> Ah good point, so we'll want another approach at any rate.  Yinghai?

What we need is to keep track of the areas available for address space
allocation by dynamically addressed devices, as distinct from address
space that is in use by a kernel-known device.  There is an in-between,
which one can call "here there be dragons" space, which should never be
used for dynamic device allocation, but if a platform device or
pre-assigned device uses that space then it should be allowed to be
allocated.

In the case of x86, anything that is E820_RESERVED, *or* in the legacy
region (below 1 MB) and is not RAM, is "here there be dragons" space.

    -hpa

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

On Mon, 26 Apr 2010 14:12:35 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> > On Mon, 26 Apr 2010 14:27:56 -0600
> > Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> >> I'm a little concerned that those patches are a sledgehammer approach.
> >> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
> >> between drivers that would otherwise claim the same resource.  It hasn't
> >> been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
> >> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
> >> Right now it feels like undesirable overloading to me.
> >
> > I guess that's true, removing those regions from the pool entirely
> > might be better?  Or some other, clear way of expressing that the
> > regions aren't available to drivers.  Maybe we need a new IO resource
> > type for platform ranges.
> >
> >> I think it also leads to at least one problem: Guenter's machine has no
> >> VGA but has a PCI device that lives at 0xa0000.  The driver for that
> >> device won't be able to request that region if the arch code has marked
> >> it busy.
> >
> > Ah good point, so we'll want another approach at any rate.  Yinghai?
> 
> What we need is to keep track of the areas available for address space
> allocation by dynamically addressed devices, as distinct from address
> space that is in use by a kernel-known device.  There is an in-between,
> which one can call "here there be dragons" space, which should never be
> used for dynamic device allocation, but if a platform device or
> pre-assigned device uses that space then it should be allowed to be
> allocated.
> 
> In the case of x86, anything that is E820_RESERVED, *or* in the legacy
> region (below 1 MB) and is not RAM, is "here there be dragons" space.

Agreed.  The trickier part is handling any platform devices that
request_resource against that space.  But maybe we don't need to do
anything special; just making sure we avoid it in the PCI "BIOS" code
as Bjorn did may be sufficient.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

>
> Agreed.  The trickier part is handling any platform devices that
> request_resource against that space.  But maybe we don't need to do
> anything special; just making sure we avoid it in the PCI "BIOS" code
> as Bjorn did may be sufficient.
>

Why is that hard?  If a platform device does a request_resource against
that space, it's a request for specific address space and it should be
granted.

        -hpa

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

On Mon, 26 Apr 2010 14:44:50 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> >
> > Agreed.  The trickier part is handling any platform devices that
> > request_resource against that space.  But maybe we don't need to do
> > anything special; just making sure we avoid it in the PCI "BIOS" code
> > as Bjorn did may be sufficient.
> >
> 
> Why is that hard?  If a platform device does a request_resource against
> that space, it's a request for specific address space and it should be
> granted.

I was thinking if we made it a special resource type we'd have to
change any platform drivers to use it; i.e. it wouldn't be
IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS.  That way it
wouldn't be part of the normal resource space.

But that's definitely overkill.  I think Bjorn's fix is sufficient.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Yinghai Lu]

On 04/26/2010 02:25 PM, Jesse Barnes wrote:
> On Mon, 26 Apr 2010 14:12:35 -0700
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>   
>>> On Mon, 26 Apr 2010 14:27:56 -0600
>>> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>>>       
>>>> I'm a little concerned that those patches are a sledgehammer approach.
>>>> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
>>>> between drivers that would otherwise claim the same resource.  It hasn't
>>>> been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
>>>> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
>>>> Right now it feels like undesirable overloading to me.
>>>>         
>>> I guess that's true, removing those regions from the pool entirely
>>> might be better?  Or some other, clear way of expressing that the
>>> regions aren't available to drivers.  Maybe we need a new IO resource
>>> type for platform ranges.
>>>
>>>       
>>>> I think it also leads to at least one problem: Guenter's machine has no
>>>> VGA but has a PCI device that lives at 0xa0000.  The driver for that
>>>> device won't be able to request that region if the arch code has marked
>>>> it busy.
>>>>         
>>> Ah good point, so we'll want another approach at any rate.  Yinghai?
>>>       
>> What we need is to keep track of the areas available for address space
>> allocation by dynamically addressed devices, as distinct from address
>> space that is in use by a kernel-known device.  There is an in-between,
>> which one can call "here there be dragons" space, which should never be
>> used for dynamic device allocation, but if a platform device or
>> pre-assigned device uses that space then it should be allowed to be
>> allocated.
>>
>> In the case of x86, anything that is E820_RESERVED, *or* in the legacy
>> region (below 1 MB) and is not RAM, is "here there be dragons" space.
>>     
> Agreed.  The trickier part is handling any platform devices that
> request_resource against that space.  But maybe we don't need to do
> anything special; just making sure we avoid it in the PCI "BIOS" code
> as Bjorn did may be sufficient.
>
>   

the two regressions from the reporters:

BIOS put 0xa0000-0xb0000, 0xc0000- 0xd0000 with E820_RESERVED.
BIOS ACPI _CRS keep 0xa0000-0xb0000, 0xc0000-0xd0000 as part resources
for peer root bus: BUS 0.

kernel insert 0xa0000-0xb0000 into resource tree with _BUSY in
e820_reserve_resources() at first.
last pci bus scan code, will insert 0xa0000-0xb0000, and it is under
previous reserved entry.

later pci_assign_unassign code, will use bus 0 resources directly, and
don't care if the parent's have _BUSY bit.

solutions:
1. mark _BUSY under bus 0 resource:  ==> -v3
2. split e820 reserve entries to small pieces to fit into bus 0
resources, so will have holder under bus0 resources. it will prevent
those range to be used.
   -v4
3. reject any dynamically allocation under 1M.  ==> Bjorn's new patch.

till now, driver can reserve resource under 1M, only when those range is
not in e820.

case A:
bus 0: --- bus X --- device Y
if the BIOS only assign range to to BUS X bridge with 0xB0000, and
device Y is not assigned.  then with Bojorn's patch, device Y can not
get right resource allocated on first try.

my -v4 can handle that case.

YH

[PATCH -v5] reserve a0000 - 0x10000

[Yinghai]

for memo, sending out -v5 

[PATCH -v5 1/3] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

Update e820 at first, and later put them resource tree.

Reserved that early, will not be allocated to unassigned PCI BAR

-v5: same as -v3

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Andy Isaacson <adi@hexapodia.org>
Tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>

---
 arch/x86/include/asm/setup.h |    1 -
 arch/x86/kernel/head32.c     |    1 -
 arch/x86/kernel/setup.c      |   19 +------------------
 3 files changed, 1 insertion(+), 20 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(vo
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_se
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -693,7 +693,7 @@ static void __init trim_bios_range(void)
 	 * area (640->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
-	e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
+	e820_add_region(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RESERVED);
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 }
 
@@ -1052,20 +1052,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */

[PATCH -v5 2/3] x86: Remove probe_roms for 32bit

[Yinghai]

That is not needed, because whole range is reserved already

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/include/asm/setup.h    |    2 
 arch/x86/include/asm/x86_init.h |    4 
 arch/x86/kernel/Makefile        |    1 
 arch/x86/kernel/head32.c        |    1 
 arch/x86/kernel/mrst.c          |    2 
 arch/x86/kernel/probe_roms_32.c |  166 ----------------------------------------
 arch/x86/kernel/setup.c         |    6 -
 arch/x86/kernel/x86_init.c      |    2 
 8 files changed, 7 insertions(+), 177 deletions(-)

Index: linux-2.6/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -43,6 +43,7 @@ static inline void visws_early_detect(vo
 
 extern unsigned long saved_video_mode;
 
+void trim_bios_range(void);
 extern void reserve_standard_io_resources(void);
 extern void setup_default_timer_irq(void);
 
@@ -95,7 +96,6 @@ void *extend_brk(size_t size, size_t ali
 #ifdef __i386__
 
 void __init i386_start_kernel(void);
-extern void probe_roms(void);
 
 #else
 void __init x86_64_start_kernel(char *real_mode);
Index: linux-2.6/arch/x86/include/asm/x86_init.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/x86_init.h
+++ linux-2.6/arch/x86/include/asm/x86_init.h
@@ -32,14 +32,14 @@ struct x86_init_mpparse {
 
 /**
  * struct x86_init_resources - platform specific resource related ops
- * @probe_roms:			probe BIOS roms
+ * @trim_bios_range:		trim BIOS related range in E820
  * @reserve_resources:		reserve the standard resources for the
  *				platform
  * @memory_setup:		platform specific memory setup
  *
  */
 struct x86_init_resources {
-	void (*probe_roms)(void);
+	void (*trim_bios_range)(void);
 	void (*reserve_resources)(void);
 	char *(*memory_setup)(void);
 };
Index: linux-2.6/arch/x86/kernel/Makefile
===================================================================
--- linux-2.6.orig/arch/x86/kernel/Makefile
+++ linux-2.6/arch/x86/kernel/Makefile
@@ -34,7 +34,6 @@ obj-y			+= traps.o irq.o irq_$(BITS).o d
 obj-y			+= time.o ioport.o ldt.o dumpstack.o
 obj-y			+= setup.o x86_init.o i8259.o irqinit.o
 obj-$(CONFIG_X86_VISWS)	+= visws_quirks.o
-obj-$(CONFIG_X86_32)	+= probe_roms_32.o
 obj-$(CONFIG_X86_32)	+= sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o
 obj-$(CONFIG_X86_64)	+= syscall_64.o vsyscall_64.o
Index: linux-2.6/arch/x86/kernel/head32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head32.c
+++ linux-2.6/arch/x86/kernel/head32.c
@@ -21,7 +21,6 @@
 static void __init i386_default_early_setup(void)
 {
 	/* Initilize 32bit specific setup functions */
-	x86_init.resources.probe_roms = probe_roms;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
Index: linux-2.6/arch/x86/kernel/mrst.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/mrst.c
+++ linux-2.6/arch/x86/kernel/mrst.c
@@ -222,7 +222,7 @@ static void __init mrst_setup_boot_clock
  */
 void __init x86_mrst_early_setup(void)
 {
-	x86_init.resources.probe_roms = x86_init_noop;
+	x86_init.resources.trim_bios_range = x86_init_noop;
 	x86_init.resources.reserve_resources = x86_init_noop;
 
 	x86_init.timers.timer_init = mrst_time_init;
Index: linux-2.6/arch/x86/kernel/probe_roms_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/probe_roms_32.c
+++ /dev/null
@@ -1,166 +0,0 @@
-#include <linux/sched.h>
-#include <linux/mm.h>
-#include <linux/uaccess.h>
-#include <linux/mmzone.h>
-#include <linux/ioport.h>
-#include <linux/seq_file.h>
-#include <linux/console.h>
-#include <linux/init.h>
-#include <linux/edd.h>
-#include <linux/dmi.h>
-#include <linux/pfn.h>
-#include <linux/pci.h>
-#include <asm/pci-direct.h>
-
-
-#include <asm/e820.h>
-#include <asm/mmzone.h>
-#include <asm/setup.h>
-#include <asm/sections.h>
-#include <asm/io.h>
-#include <asm/setup_arch.h>
-
-static struct resource system_rom_resource = {
-	.name	= "System ROM",
-	.start	= 0xf0000,
-	.end	= 0xfffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-};
-
-static struct resource extension_rom_resource = {
-	.name	= "Extension ROM",
-	.start	= 0xe0000,
-	.end	= 0xeffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-};
-
-static struct resource adapter_rom_resources[] = { {
-	.name 	= "Adapter ROM",
-	.start	= 0xc8000,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-}, {
-	.name 	= "Adapter ROM",
-	.start	= 0,
-	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-} };
-
-static struct resource video_rom_resource = {
-	.name 	= "Video ROM",
-	.start	= 0xc0000,
-	.end	= 0xc7fff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
-};
-
-#define ROMSIGNATURE 0xaa55
-
-static int __init romsignature(const unsigned char *rom)
-{
-	const unsigned short * const ptr = (const unsigned short *)rom;
-	unsigned short sig;
-
-	return probe_kernel_address(ptr, sig) == 0 && sig == ROMSIGNATURE;
-}
-
-static int __init romchecksum(const unsigned char *rom, unsigned long length)
-{
-	unsigned char sum, c;
-
-	for (sum = 0; length && probe_kernel_address(rom++, c) == 0; length--)
-		sum += c;
-	return !length && !sum;
-}
-
-void __init probe_roms(void)
-{
-	const unsigned char *rom;
-	unsigned long start, length, upper;
-	unsigned char c;
-	int i;
-
-	/* video rom */
-	upper = adapter_rom_resources[0].start;
-	for (start = video_rom_resource.start; start < upper; start += 2048) {
-		rom = isa_bus_to_virt(start);
-		if (!romsignature(rom))
-			continue;
-
-		video_rom_resource.start = start;
-
-		if (probe_kernel_address(rom + 2, c) != 0)
-			continue;
-
-		/* 0 < length <= 0x7f * 512, historically */
-		length = c * 512;
-
-		/* if checksum okay, trust length byte */
-		if (length && romchecksum(rom, length))
-			video_rom_resource.end = start + length - 1;
-
-		request_resource(&iomem_resource, &video_rom_resource);
-		break;
-	}
-
-	start = (video_rom_resource.end + 1 + 2047) & ~2047UL;
-	if (start < upper)
-		start = upper;
-
-	/* system rom */
-	request_resource(&iomem_resource, &system_rom_resource);
-	upper = system_rom_resource.start;
-
-	/* check for extension rom (ignore length byte!) */
-	rom = isa_bus_to_virt(extension_rom_resource.start);
-	if (romsignature(rom)) {
-		length = extension_rom_resource.end - extension_rom_resource.start + 1;
-		if (romchecksum(rom, length)) {
-			request_resource(&iomem_resource, &extension_rom_resource);
-			upper = extension_rom_resource.start;
-		}
-	}
-
-	/* check for adapter roms on 2k boundaries */
-	for (i = 0; i < ARRAY_SIZE(adapter_rom_resources) && start < upper; start += 2048) {
-		rom = isa_bus_to_virt(start);
-		if (!romsignature(rom))
-			continue;
-
-		if (probe_kernel_address(rom + 2, c) != 0)
-			continue;
-
-		/* 0 < length <= 0x7f * 512, historically */
-		length = c * 512;
-
-		/* but accept any length that fits if checksum okay */
-		if (!length || start + length > upper || !romchecksum(rom, length))
-			continue;
-
-		adapter_rom_resources[i].start = start;
-		adapter_rom_resources[i].end = start + length - 1;
-		request_resource(&iomem_resource, &adapter_rom_resources[i]);
-
-		start = adapter_rom_resources[i++].end & ~2047UL;
-	}
-}
-
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -680,7 +680,7 @@ static struct dmi_system_id __initdata b
 	{}
 };
 
-static void __init trim_bios_range(void)
+void __init trim_bios_range(void)
 {
 	/*
 	 * A special case is the first 4Kb of memory;
@@ -853,14 +853,12 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	init_hypervisor_platform();
 
-	x86_init.resources.probe_roms();
-
 	/* after parse_early_param, so could debug it */
 	insert_resource(&iomem_resource, &code_resource);
 	insert_resource(&iomem_resource, &data_resource);
 	insert_resource(&iomem_resource, &bss_resource);
 
-	trim_bios_range();
+	x86_init.resources.trim_bios_range();
 #ifdef CONFIG_X86_32
 	if (ppro_with_ram_bug()) {
 		e820_update_range(0x70000000ULL, 0x40000ULL, E820_RAM,
Index: linux-2.6/arch/x86/kernel/x86_init.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/x86_init.c
+++ linux-2.6/arch/x86/kernel/x86_init.c
@@ -32,7 +32,7 @@ void iommu_shutdown_noop(void) { }
 struct x86_init_ops x86_init __initdata = {
 
 	.resources = {
-		.probe_roms		= x86_init_noop,
+		.trim_bios_range	= trim_bios_range,
 		.reserve_resources	= reserve_standard_io_resources,
 		.memory_setup		= default_machine_specific_memory_setup,
 	},

[PATCH -v5 3/3] x86, resource: Add reserve_region_with_split_check_child()

[Yinghai]

It will cover the whole region to BUSY, except that some regions that have
children under them.

those children normally is PCI bar but it is falling into E820_RESERVED.
We can not put BUSY on them, otherwise driver can not use pci_request_region()
later

/proc/iomem will have
00010000-00094fff : System RAM
00095000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
  000a0000-000bffff : reserved
000c0000-000cffff : reserved
000d0000-000dffff : PCI Bus 0000:00
  000d0000-000dffff : reserved
000e0000-000fffff : reserved

v5: Add function pointer to put string comparing with caller

Tested-by: Guenter Roeck <guenter.roeck@ericsson.com>
Tested-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/e820.c |   18 +++++++++++++++---
 include/linux/ioport.h |    3 +++
 kernel/resource.c      |   29 ++++++++++++++++++++++++-----
 3 files changed, 42 insertions(+), 8 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
@@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
 		 * pci device BAR resource and insert them later in
 		 * pcibios_resource_survey()
 		 */
-		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+		if (e820.map[i].type != E820_RESERVED) {
 			res->flags |= IORESOURCE_BUSY;
 			insert_resource(&iomem_resource, res);
 		}
@@ -1128,6 +1128,14 @@ static unsigned long ram_alignment(resou
 
 #define MAX_RESOURCE_SIZE ((resource_size_t)-1)
 
+static int __init check_func(struct resource *cf)
+{
+	if (strstr(cf->name, "PCI Bus"))
+		return 1;
+
+        return 0;
+}
+
 void __init e820_reserve_resources_late(void)
 {
 	int i;
@@ -1135,8 +1143,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_expand_to_fit(&iomem_resource, res);
+		if (!res->parent && res->end) {
+			if (res->start < (1ULL<<20))
+				reserve_region_with_split_check_child(&iomem_resource, res->start, res->end, res->name, check_func);
+			else
+				insert_resource_expand_to_fit(&iomem_resource, res);
+		}
 		res++;
 	}
 
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -120,6 +120,9 @@ void release_child_resources(struct reso
 extern void reserve_region_with_split(struct resource *root,
 			     resource_size_t start, resource_size_t end,
 			     const char *name);
+void reserve_region_with_split_check_child(struct resource *root,
+			     resource_size_t start, resource_size_t end,
+			     const char *name, int (*check_func)(struct resource *cf));
 extern struct resource *insert_resource_conflict(struct resource *parent, 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);
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -607,9 +607,14 @@ int adjust_resource(struct resource *res
 	return result;
 }
 
+static int __init check_func_nop(struct resource *cf)
+{
+	return 1;
+}
+
 static void __init __reserve_region_with_split(struct resource *root,
 		resource_size_t start, resource_size_t end,
-		const char *name)
+		const char *name, bool check_child, int (*check_func)(struct resource *cf))
 {
 	struct resource *parent = root;
 	struct resource *conflict;
@@ -631,13 +636,18 @@ static void __init __reserve_region_with
 	kfree(res);
 
 	/* conflict covered whole area */
-	if (conflict->start <= start && conflict->end >= end)
+	if (conflict->start <= start && conflict->end >= end) {
+		if (check_child && !conflict->child && check_func(conflict))
+			__reserve_region_with_split(conflict, start, end, name, false, check_func_nop);
 		return;
+	}
 
 	if (conflict->start > start)
-		__reserve_region_with_split(root, start, conflict->start-1, name);
+		__reserve_region_with_split(root, start, conflict->start-1, name, check_child, check_func);
 	if (conflict->end < end)
-		__reserve_region_with_split(root, conflict->end+1, end, name);
+		__reserve_region_with_split(root, conflict->end+1, end, name, check_child, check_func);
+	if (check_child && !conflict->child && check_func(conflict))
+		__reserve_region_with_split(conflict, conflict->start, conflict->end, name, false, check_func_nop);
 }
 
 void __init reserve_region_with_split(struct resource *root,
@@ -645,7 +655,16 @@ void __init reserve_region_with_split(st
 		const char *name)
 {
 	write_lock(&resource_lock);
-	__reserve_region_with_split(root, start, end, name);
+	__reserve_region_with_split(root, start, end, name, false, check_func_nop);
+	write_unlock(&resource_lock);
+}
+
+void __init reserve_region_with_split_check_child(struct resource *root,
+		resource_size_t start, resource_size_t end,
+		const char *name, int (*check_func)(struct resource *cf))
+{
+	write_lock(&resource_lock);
+	__reserve_region_with_split(root, start, end, name, true, check_func);
 	write_unlock(&resource_lock);
 }
 

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[jacob pan]

H. Peter Anvin Mon, 26 Apr 2010 14:12:35 -0700
>> On Mon, 26 Apr 2010 14:27:56 -0600
>> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>>> I'm a little concerned that those patches are a sledgehammer approach.
>>> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
>>> between drivers that would otherwise claim the same resource.  It hasn't
>>> been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
>>> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
>>> Right now it feels like undesirable overloading to me.
>>
>> I guess that's true, removing those regions from the pool entirely
>> might be better?  Or some other, clear way of expressing that the
>> regions aren't available to drivers.  Maybe we need a new IO resource
>> type for platform ranges.
>>
>>> I think it also leads to at least one problem: Guenter's machine has no
>>> VGA but has a PCI device that lives at 0xa0000.  The driver for that
>>> device won't be able to request that region if the arch code has marked
>>> it busy.
>>
>> Ah good point, so we'll want another approach at any rate.  Yinghai?
>
>What we need is to keep track of the areas available for address space
>allocation by dynamically addressed devices, as distinct from address
>space that is in use by a kernel-known device.  There is an in-between,
>which one can call "here there be dragons" space, which should never be
>used for dynamic device allocation, but if a platform device or
>pre-assigned device uses that space then it should be allowed to be
>allocated.
>
>In the case of x86, anything that is E820_RESERVED, *or* in the legacy
>region (below 1 MB) and is not RAM, is "here there be dragons" space.
>
>    -hpa
>
Moorestown has a similar situation where one of the PCI devices have a BAR
below 1MB. Moorestown also has the option not to have VGA.

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[H. Peter Anvin]

On 04/13/2010 03:58 PM, Yinghai wrote:
> 
> Are you sure? what is BAR range? greater than 1M ?
> 
> e820_reserve_resources() will make that range to be reserved and BUSY in resource tree.
> and if driver for that device want to call pci_request_region, it will get failure...
> 

Let me dig up the thread later... this was so long ago my memory might
be rusty.

	-hpa

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/13/2010 02:58 PM, H. Peter Anvin wrote:
> On 04/13/2010 02:42 PM, Yinghai wrote:
>> On 04/13/2010 02:18 PM, H. Peter Anvin wrote:
>>> On 04/13/2010 02:11 PM, Yinghai wrote:
>>>>>
>>>>> I guess the real question (which I haven't looked at myself) is if the
>>>>> E820_RESERVED -> BUSY will cause an explicitly assigned BAR from being
>>>>> moved.  That's bad, not so much for this particular range, but from BARs
>>>>> which may be assigned by SMM.  Hacking that up in a simulator
>>>>> (Qemu/Bochs) and testing it is probably on the to do list...
>>>>
>>>> no, if some device BAR fall in that range, it should still use that range, and will not be relocated.
>>>>
>>>> will update the change log.
>>>>
>>>
>>> Good, that's what we want.
>>
>> the driver for that device later can not use pci_request_region(). because that region is BUSY already.
>>
> 
> That's not good (in general - for devices in this particular range it's
> not such a big deal, but it is potentially really bad for devices marked
> reserved for them not to be moved.)
> 
> We have talked about a need to resolve this before.

this one should make both cases work.

Andy, can you check this one together with
v3: x86: Reserve [0xa0000, 0x100000] in e820 map

Guenter, can you try the two patches on the system with special device?

Thanks

Yinghai

--------

Subject: [PATCH] x86, resource: Add reserve_region_with_split_check_child()

It will cover the whole region to BUSY, except that some regions that have
children under them.

those children normally is PCI bar but it is falling into E820_RESERVED.
We can not put BUSY on them, otherwise driver can not use pci_request_region()
later

/proc/iomem will have
00010000-00094fff : System RAM
00095000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
  000a0000-000bffff : reserved
000c0000-000cffff : reserved
000d0000-000dffff : PCI Bus 0000:00
  000d0000-000dffff : reserved
000e0000-000fffff : reserved

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/e820.c |   10 +++++++---
 include/linux/ioport.h |    3 +++
 kernel/resource.c      |   24 +++++++++++++++++++-----
 3 files changed, 29 insertions(+), 8 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
@@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
 		 * pci device BAR resource and insert them later in
 		 * pcibios_resource_survey()
 		 */
-		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+		if (e820.map[i].type != E820_RESERVED) {
 			res->flags |= IORESOURCE_BUSY;
 			insert_resource(&iomem_resource, res);
 		}
@@ -1135,8 +1135,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_expand_to_fit(&iomem_resource, res);
+		if (!res->parent && res->end) {
+			if (res->start < (1ULL<<20)) {
+				reserve_region_with_split_check_child(&iomem_resource, res->start, res->end, res->name);
+			} else
+				insert_resource_expand_to_fit(&iomem_resource, res);
+		}
 		res++;
 	}
 
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -120,6 +120,9 @@ void release_child_resources(struct reso
 extern void reserve_region_with_split(struct resource *root,
 			     resource_size_t start, resource_size_t end,
 			     const char *name);
+void reserve_region_with_split_check_child(struct resource *root,
+			     resource_size_t start, resource_size_t end,
+			     const char *name);
 extern struct resource *insert_resource_conflict(struct resource *parent, 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);
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -609,7 +609,7 @@ int adjust_resource(struct resource *res
 
 static void __init __reserve_region_with_split(struct resource *root,
 		resource_size_t start, resource_size_t end,
-		const char *name)
+		const char *name, bool check_child)
 {
 	struct resource *parent = root;
 	struct resource *conflict;
@@ -631,13 +631,18 @@ static void __init __reserve_region_with
 	kfree(res);
 
 	/* conflict covered whole area */
-	if (conflict->start <= start && conflict->end >= end)
+	if (conflict->start <= start && conflict->end >= end) {
+		if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
+			__reserve_region_with_split(conflict, start, end, name, false);
 		return;
+	}
 
 	if (conflict->start > start)
-		__reserve_region_with_split(root, start, conflict->start-1, name);
+		__reserve_region_with_split(root, start, conflict->start-1, name, check_child);
 	if (conflict->end < end)
-		__reserve_region_with_split(root, conflict->end+1, end, name);
+		__reserve_region_with_split(root, conflict->end+1, end, name, check_child);
+	if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
+		__reserve_region_with_split(conflict, conflict->start, conflict->end, name, false);
 }
 
 void __init reserve_region_with_split(struct resource *root,
@@ -645,7 +650,16 @@ void __init reserve_region_with_split(st
 		const char *name)
 {
 	write_lock(&resource_lock);
-	__reserve_region_with_split(root, start, end, name);
+	__reserve_region_with_split(root, start, end, name, false);
+	write_unlock(&resource_lock);
+}
+
+void __init reserve_region_with_split_check_child(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, true);
 	write_unlock(&resource_lock);
 }
 

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Bjorn Helgaas]

On Tuesday 13 April 2010 06:57:54 pm Yinghai wrote:

> Subject: [PATCH] x86, resource: Add reserve_region_with_split_check_child()
> 
> It will cover the whole region to BUSY, except that some regions that have
> children under them.
> 
> those children normally is PCI bar but it is falling into E820_RESERVED.
> We can not put BUSY on them, otherwise driver can not use pci_request_region()
> later
> 
> /proc/iomem will have
> 00010000-00094fff : System RAM
> 00095000-0009ffff : reserved
> 000a0000-000bffff : PCI Bus 0000:00
>   000a0000-000bffff : reserved
> 000c0000-000cffff : reserved
> 000d0000-000dffff : PCI Bus 0000:00
>   000d0000-000dffff : reserved
> 000e0000-000fffff : reserved
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/kernel/e820.c |   10 +++++++---
>  include/linux/ioport.h |    3 +++
>  kernel/resource.c      |   24 +++++++++++++++++++-----
>  3 files changed, 29 insertions(+), 8 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
> @@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
>  		 * pci device BAR resource and insert them later in
>  		 * pcibios_resource_survey()
>  		 */
> -		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
> +		if (e820.map[i].type != E820_RESERVED) {
>  			res->flags |= IORESOURCE_BUSY;
>  			insert_resource(&iomem_resource, res);
>  		}
> @@ -1135,8 +1135,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_expand_to_fit(&iomem_resource, res);
> +		if (!res->parent && res->end) {
> +			if (res->start < (1ULL<<20)) {
> +				reserve_region_with_split_check_child(&iomem_resource, res->start, res->end, res->name);
> +			} else
> +				insert_resource_expand_to_fit(&iomem_resource, res);

I don't like adding all these special-purpose resource interfaces, e.g.,
insert_resource_expand_to_fit(), reserve_region_with_split(),
reserve_region_with_split_check_child(), etc.  They tend to be only
used by one caller, which is a clue to me that we're doing something
wrong.

Sometimes we'd like to print debug information in them (as we do in
insert_resource_expand_to_fit()), but we don't have enough context,
so the message isn't very meaningful.

I think it's better to have more generic interfaces that allow us to
implement this sort of functionality where it's used and where we
have the context to print useful messages.  For example, could the
reserve_region_with_split_check_child() functionality be implemented
in e820.c by building on something like request_resource_conflict()?

> +		}
>  		res++;
>  	}
>  
> Index: linux-2.6/include/linux/ioport.h
> ===================================================================
> --- linux-2.6.orig/include/linux/ioport.h
> +++ linux-2.6/include/linux/ioport.h
> @@ -120,6 +120,9 @@ void release_child_resources(struct reso
>  extern void reserve_region_with_split(struct resource *root,
>  			     resource_size_t start, resource_size_t end,
>  			     const char *name);
> +void reserve_region_with_split_check_child(struct resource *root,
> +			     resource_size_t start, resource_size_t end,
> +			     const char *name);
>  extern struct resource *insert_resource_conflict(struct resource *parent, 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);
> Index: linux-2.6/kernel/resource.c
> ===================================================================
> --- linux-2.6.orig/kernel/resource.c
> +++ linux-2.6/kernel/resource.c
> @@ -609,7 +609,7 @@ int adjust_resource(struct resource *res
>  
>  static void __init __reserve_region_with_split(struct resource *root,
>  		resource_size_t start, resource_size_t end,
> -		const char *name)
> +		const char *name, bool check_child)
>  {
>  	struct resource *parent = root;
>  	struct resource *conflict;
> @@ -631,13 +631,18 @@ static void __init __reserve_region_with
>  	kfree(res);
>  
>  	/* conflict covered whole area */
> -	if (conflict->start <= start && conflict->end >= end)
> +	if (conflict->start <= start && conflict->end >= end) {
> +		if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))

This is kind of gross, too.  Checking the name of a resource for "PCI Bus"?

Bjorn

> +			__reserve_region_with_split(conflict, start, end, name, false);
>  		return;
> +	}
>  
>  	if (conflict->start > start)
> -		__reserve_region_with_split(root, start, conflict->start-1, name);
> +		__reserve_region_with_split(root, start, conflict->start-1, name, check_child);
>  	if (conflict->end < end)
> -		__reserve_region_with_split(root, conflict->end+1, end, name);
> +		__reserve_region_with_split(root, conflict->end+1, end, name, check_child);
> +	if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
> +		__reserve_region_with_split(conflict, conflict->start, conflict->end, name, false);
>  }
>  
>  void __init reserve_region_with_split(struct resource *root,
> @@ -645,7 +650,16 @@ void __init reserve_region_with_split(st
>  		const char *name)
>  {
>  	write_lock(&resource_lock);
> -	__reserve_region_with_split(root, start, end, name);
> +	__reserve_region_with_split(root, start, end, name, false);
> +	write_unlock(&resource_lock);
> +}
> +
> +void __init reserve_region_with_split_check_child(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, true);
>  	write_unlock(&resource_lock);
>  }
>  
> 

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai Lu]

On 04/14/2010 09:55 AM, Bjorn Helgaas wrote:
> On Tuesday 13 April 2010 06:57:54 pm Yinghai wrote:
>
>   
>> Subject: [PATCH] x86, resource: Add reserve_region_with_split_check_child()
>>
>> It will cover the whole region to BUSY, except that some regions that have
>> children under them.
>>
>> those children normally is PCI bar but it is falling into E820_RESERVED.
>> We can not put BUSY on them, otherwise driver can not use pci_request_region()
>> later
>>
>> /proc/iomem will have
>> 00010000-00094fff : System RAM
>> 00095000-0009ffff : reserved
>> 000a0000-000bffff : PCI Bus 0000:00
>>   000a0000-000bffff : reserved
>> 000c0000-000cffff : reserved
>> 000d0000-000dffff : PCI Bus 0000:00
>>   000d0000-000dffff : reserved
>> 000e0000-000fffff : reserved
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>
>> ---
>>  arch/x86/kernel/e820.c |   10 +++++++---
>>  include/linux/ioport.h |    3 +++
>>  kernel/resource.c      |   24 +++++++++++++++++++-----
>>  3 files changed, 29 insertions(+), 8 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
>> @@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
>>  		 * pci device BAR resource and insert them later in
>>  		 * pcibios_resource_survey()
>>  		 */
>> -		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
>> +		if (e820.map[i].type != E820_RESERVED) {
>>  			res->flags |= IORESOURCE_BUSY;
>>  			insert_resource(&iomem_resource, res);
>>  		}
>> @@ -1135,8 +1135,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_expand_to_fit(&iomem_resource, res);
>> +		if (!res->parent && res->end) {
>> +			if (res->start < (1ULL<<20)) {
>> +				reserve_region_with_split_check_child(&iomem_resource, res->start, res->end, res->name);
>> +			} else
>> +				insert_resource_expand_to_fit(&iomem_resource, res);
>>     
> I don't like adding all these special-purpose resource interfaces, e.g.,
> insert_resource_expand_to_fit(), reserve_region_with_split(),
> reserve_region_with_split_check_child(), etc.  They tend to be only
> used by one caller, which is a clue to me that we're doing something
> wrong.
>
> Sometimes we'd like to print debug information in them (as we do in
> insert_resource_expand_to_fit()), but we don't have enough context,
> so the message isn't very meaningful.
>   
print out related resource tree segment ?
> I think it's better to have more generic interfaces that allow us to
> implement this sort of functionality where it's used and where we
> have the context to print useful messages.  For example, could the
> reserve_region_with_split_check_child() functionality be implemented
> in e820.c by building on something like request_resource_conflict()?
>
>   
>> +		}
>>  		res++;
>>  	}
>>  
>> Index: linux-2.6/include/linux/ioport.h
>> ===================================================================
>> --- linux-2.6.orig/include/linux/ioport.h
>> +++ linux-2.6/include/linux/ioport.h
>> @@ -120,6 +120,9 @@ void release_child_resources(struct reso
>>  extern void reserve_region_with_split(struct resource *root,
>>  			     resource_size_t start, resource_size_t end,
>>  			     const char *name);
>> +void reserve_region_with_split_check_child(struct resource *root,
>> +			     resource_size_t start, resource_size_t end,
>> +			     const char *name);
>>  extern struct resource *insert_resource_conflict(struct resource *parent, 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);
>> Index: linux-2.6/kernel/resource.c
>> ===================================================================
>> --- linux-2.6.orig/kernel/resource.c
>> +++ linux-2.6/kernel/resource.c
>> @@ -609,7 +609,7 @@ int adjust_resource(struct resource *res
>>  
>>  static void __init __reserve_region_with_split(struct resource *root,
>>  		resource_size_t start, resource_size_t end,
>> -		const char *name)
>> +		const char *name, bool check_child)
>>  {
>>  	struct resource *parent = root;
>>  	struct resource *conflict;
>> @@ -631,13 +631,18 @@ static void __init __reserve_region_with
>>  	kfree(res);
>>  
>>  	/* conflict covered whole area */
>> -	if (conflict->start <= start && conflict->end >= end)
>> +	if (conflict->start <= start && conflict->end >= end) {
>> +		if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
>>     
> This is kind of gross, too.  Checking the name of a resource for "PCI Bus"?
>   
yes, in case some system have device on BUS 0 directly. but have device
have pci BAR below 1M and fall into E820_RESERVED.

YH

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Andy Isaacson]

On Tue, Apr 13, 2010 at 05:57:54PM -0700, Yinghai wrote:
> On 04/13/2010 02:58 PM, H. Peter Anvin wrote:
> > That's not good (in general - for devices in this particular range it's
> > not such a big deal, but it is potentially really bad for devices marked
> > reserved for them not to be moved.)
> > 
> > We have talked about a need to resolve this before.
> 
> this one should make both cases work.
> 
> Andy, can you check this one together with
> v3: x86: Reserve [0xa0000, 0x100000] in e820 map

I've booted successfully with the patch below, on top of the patch in
Message-ID: <4BC4E09F.9000608@oracle.com>

I'll attach the dmesg to bug 15744.

-andy

> Guenter, can you try the two patches on the system with special device?
> 
> Thanks
> 
> Yinghai
> 
> --------
> 
> Subject: [PATCH] x86, resource: Add reserve_region_with_split_check_child()
> 
> It will cover the whole region to BUSY, except that some regions that have
> children under them.
> 
> those children normally is PCI bar but it is falling into E820_RESERVED.
> We can not put BUSY on them, otherwise driver can not use pci_request_region()
> later
> 
> /proc/iomem will have
> 00010000-00094fff : System RAM
> 00095000-0009ffff : reserved
> 000a0000-000bffff : PCI Bus 0000:00
>   000a0000-000bffff : reserved
> 000c0000-000cffff : reserved
> 000d0000-000dffff : PCI Bus 0000:00
>   000d0000-000dffff : reserved
> 000e0000-000fffff : reserved
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/kernel/e820.c |   10 +++++++---
>  include/linux/ioport.h |    3 +++
>  kernel/resource.c      |   24 +++++++++++++++++++-----
>  3 files changed, 29 insertions(+), 8 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
> @@ -1094,7 +1094,7 @@ void __init e820_reserve_resources(void)
>  		 * pci device BAR resource and insert them later in
>  		 * pcibios_resource_survey()
>  		 */
> -		if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
> +		if (e820.map[i].type != E820_RESERVED) {
>  			res->flags |= IORESOURCE_BUSY;
>  			insert_resource(&iomem_resource, res);
>  		}
> @@ -1135,8 +1135,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_expand_to_fit(&iomem_resource, res);
> +		if (!res->parent && res->end) {
> +			if (res->start < (1ULL<<20)) {
> +				reserve_region_with_split_check_child(&iomem_resource, res->start, res->end, res->name);
> +			} else
> +				insert_resource_expand_to_fit(&iomem_resource, res);
> +		}
>  		res++;
>  	}
>  
> Index: linux-2.6/include/linux/ioport.h
> ===================================================================
> --- linux-2.6.orig/include/linux/ioport.h
> +++ linux-2.6/include/linux/ioport.h
> @@ -120,6 +120,9 @@ void release_child_resources(struct reso
>  extern void reserve_region_with_split(struct resource *root,
>  			     resource_size_t start, resource_size_t end,
>  			     const char *name);
> +void reserve_region_with_split_check_child(struct resource *root,
> +			     resource_size_t start, resource_size_t end,
> +			     const char *name);
>  extern struct resource *insert_resource_conflict(struct resource *parent, 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);
> Index: linux-2.6/kernel/resource.c
> ===================================================================
> --- linux-2.6.orig/kernel/resource.c
> +++ linux-2.6/kernel/resource.c
> @@ -609,7 +609,7 @@ int adjust_resource(struct resource *res
>  
>  static void __init __reserve_region_with_split(struct resource *root,
>  		resource_size_t start, resource_size_t end,
> -		const char *name)
> +		const char *name, bool check_child)
>  {
>  	struct resource *parent = root;
>  	struct resource *conflict;
> @@ -631,13 +631,18 @@ static void __init __reserve_region_with
>  	kfree(res);
>  
>  	/* conflict covered whole area */
> -	if (conflict->start <= start && conflict->end >= end)
> +	if (conflict->start <= start && conflict->end >= end) {
> +		if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
> +			__reserve_region_with_split(conflict, start, end, name, false);
>  		return;
> +	}
>  
>  	if (conflict->start > start)
> -		__reserve_region_with_split(root, start, conflict->start-1, name);
> +		__reserve_region_with_split(root, start, conflict->start-1, name, check_child);
>  	if (conflict->end < end)
> -		__reserve_region_with_split(root, conflict->end+1, end, name);
> +		__reserve_region_with_split(root, conflict->end+1, end, name, check_child);
> +	if (check_child && !conflict->child && strstr(conflict->name, "PCI Bus"))
> +		__reserve_region_with_split(conflict, conflict->start, conflict->end, name, false);
>  }
>  
>  void __init reserve_region_with_split(struct resource *root,
> @@ -645,7 +650,16 @@ void __init reserve_region_with_split(st
>  		const char *name)
>  {
>  	write_lock(&resource_lock);
> -	__reserve_region_with_split(root, start, end, name);
> +	__reserve_region_with_split(root, start, end, name, false);
> +	write_unlock(&resource_lock);
> +}
> +
> +void __init reserve_region_with_split_check_child(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, true);
>  	write_unlock(&resource_lock);
>  }
>  

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/14/2010 12:25 PM, Andy Isaacson wrote:
> On Tue, Apr 13, 2010 at 05:57:54PM -0700, Yinghai wrote:
>> On 04/13/2010 02:58 PM, H. Peter Anvin wrote:
>>> That's not good (in general - for devices in this particular range it's
>>> not such a big deal, but it is potentially really bad for devices marked
>>> reserved for them not to be moved.)
>>>
>>> We have talked about a need to resolve this before.
>>
>> this one should make both cases work.
>>
>> Andy, can you check this one together with
>> v3: x86: Reserve [0xa0000, 0x100000] in e820 map
> 
> I've booted successfully with the patch below, on top of the patch in
> Message-ID: <4BC4E09F.9000608@oracle.com>
> 
> I'll attach the dmesg to bug 15744.

thanks. please put /proc/iomem there too.

Yinghai

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Andy Isaacson]

On Wed, Apr 14, 2010 at 12:27:40PM -0700, Yinghai wrote:
> > I'll attach the dmesg to bug 15744.
> 
> thanks. please put /proc/iomem there too.

I attached it to the bug.

-andy

Re: [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map

[Yinghai]

On 04/14/2010 12:43 PM, Andy Isaacson wrote:
> On Wed, Apr 14, 2010 at 12:27:40PM -0700, Yinghai wrote:
>>> I'll attach the dmesg to bug 15744.
>>
>> thanks. please put /proc/iomem there too.
> 
> I attached it to the bug.

looks good.

000a0000-000bffff : PCI Bus 0000:00
  000a0000-000bffff : reserved
000c0000-000effff : PCI Bus 0000:00
  000c0000-000effff : reserved
000f0000-000fffff : PCI Bus 0000:00
  000f0000-000fffff : reserved

Thanks

Yinghai

[PATCH -v2 2/2] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus

[Yinghai]

So make pci root resource from _CRS honor the range We reserve in e820 below 1M
then  will not assign them to unsigned pci BAR

-v2: let pci_bus_alloc_resource() honor IORESOURCE_BUSY
     driver can not use those range, so skip it

Tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/acpi.c |    4 ++++
 drivers/pci/bus.c   |    4 ++++
 2 files changed, 8 insertions(+)

Index: linux-2.6/arch/x86/pci/acpi.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -175,6 +175,10 @@ setup_resource(struct acpi_resource *acp
 			"conflicts with %s %pR\n",
 			res, conflict->name, conflict);
 	} else {
+		/* In case it falls in big reserved region */
+		if (res->parent->flags & IORESOURCE_BUSY)
+			res->flags |= IORESOURCE_BUSY;
+
 		pci_bus_add_resource(info->bus, res, 0);
 		info->res_num++;
 		if (addr.translation_offset)
Index: linux-2.6/drivers/pci/bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -103,6 +103,10 @@ pci_bus_alloc_resource(struct pci_bus *b
 		if (!r)
 			continue;
 
+		/* Driver can not reserve it later, so don't use it */
+		if (r->flags & IORESOURCE_BUSY)
+			continue;
+
 		/* type_mask must match */
 		if ((res->flags ^ r->flags) & type_mask)
 			continue;

Re: [PATCH -v2 2/2] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus

[Jesse Barnes]

On Mon, 12 Apr 2010 15:33:19 -0700
Yinghai <yinghai.lu@oracle.com> wrote:

> 
> So make pci root resource from _CRS honor the range We reserve in e820 below 1M
> then  will not assign them to unsigned pci BAR
> 
> -v2: let pci_bus_alloc_resource() honor IORESOURCE_BUSY
>      driver can not use those range, so skip it
> 
> Tested-by: Andy Isaacson <adi@hexapodia.org>
> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

I'd like Bjorn to ack this one before it gets applied.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH -v2 2/2] x86,pci, acpi: Inherent BUSY flag when setup_resource for root bus

[Bjorn Helgaas]

On Mon, 2010-04-12 at 15:33 -0700, Yinghai wrote:
> So make pci root resource from _CRS honor the range We reserve in e820 below 1M
> then  will not assign them to unsigned pci BAR
> 
> -v2: let pci_bus_alloc_resource() honor IORESOURCE_BUSY
>      driver can not use those range, so skip it

This -v2 text doesn't belong in the changelog.  If you need it, it
should be in a cover message so it doesn't clutter the permanent git
logs.

> Index: linux-2.6/arch/x86/pci/acpi.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/acpi.c
> +++ linux-2.6/arch/x86/pci/acpi.c
> @@ -175,6 +175,10 @@ setup_resource(struct acpi_resource *acp
>  			"conflicts with %s %pR\n",
>  			res, conflict->name, conflict);
>  	} else {
> +		/* In case it falls in big reserved region */
> +		if (res->parent->flags & IORESOURCE_BUSY)
> +			res->flags |= IORESOURCE_BUSY;
> +
>  		pci_bus_add_resource(info->bus, res, 0);
>  		info->res_num++;
>  		if (addr.translation_offset)
> Index: linux-2.6/drivers/pci/bus.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/bus.c
> +++ linux-2.6/drivers/pci/bus.c
> @@ -103,6 +103,10 @@ pci_bus_alloc_resource(struct pci_bus *b
>  		if (!r)
>  			continue;
>  
> +		/* Driver can not reserve it later, so don't use it */
> +		if (r->flags & IORESOURCE_BUSY)
> +			continue;
> +
>  		/* type_mask must match */
>  		if ((res->flags ^ r->flags) & type_mask)
>  			continue;

I think this makes sense, but I think it should be in two separate
patches.  The first would be the pci_bus_alloc_resource() change, which
is of interest to all architectures, with a changelog like this:

  PCI: don't allocate from a BUSY bus resource

  Drivers typically use pci_request_regions() to reserve the resources
  they use, but that fails if the resource is already busy.  Therefore,
  we should ignore busy resources when we're assigning resources to a
  device.

and the second would be:

  x86/PCI: host bridge windows inherit BUSY flag from parent

  If a host bridge window falls inside a region the architecture has
  marked busy, the window should inherit the busy flag so we don't
  try to assign that region to a device.

Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 11:55 AM, Guenter Roeck wrote:
> On Fri, 2010-04-09 at 14:23 -0400, H. Peter Anvin wrote:
>> [Adding Guenter Roeck as he was commenting on something writing to the
>> VGA area...]
>>
>> On 04/09/2010 10:22 AM, Yinghai wrote:
>>>
>>> then please check this one
>>>
>>> update e820 at first, and later put them resource tree, but give pci BAR chance to claim
>>> the range, before assign unassigned resources.
>>>
>>> in case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some other pci devices.
>>>
>>
>> Do we have any evidence of any such system?
>>
>> Either which way, the patch looks saner...
>>
> Yes, we have a system which does not have VGA and uses the VGA memory
> space for another device. I don't know exactly what for, but I can find
> out if it is relevant.
> 

Quite.  We really need to consider if that kind of devices should be
supported.

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Guenter Roeck]

On Fri, 2010-04-09 at 16:11 -0400, H. Peter Anvin wrote:
> On 04/09/2010 11:55 AM, Guenter Roeck wrote:
> > On Fri, 2010-04-09 at 14:23 -0400, H. Peter Anvin wrote:
> >> [Adding Guenter Roeck as he was commenting on something writing to the
> >> VGA area...]
> >>
> >> On 04/09/2010 10:22 AM, Yinghai wrote:
> >>>
> >>> then please check this one
> >>>
> >>> update e820 at first, and later put them resource tree, but give pci BAR chance to claim
> >>> the range, before assign unassigned resources.
> >>>
> >>> in case some system doesn't have VGA, and use [0xa0000, ..] for mmio of some other pci devices.
> >>>
> >>
> >> Do we have any evidence of any such system?
> >>
> >> Either which way, the patch looks saner...
> >>
> > Yes, we have a system which does not have VGA and uses the VGA memory
> > space for another device. I don't know exactly what for, but I can find
> > out if it is relevant.
> > 
> 
> Quite.  We really need to consider if that kind of devices should be
> supported.

It is used for a custom FPGA implementing a watchdog timer and some
other functionality.

This is not a matter of supporting such a device in Linux, it is a
matter of explicitly excluding non-VGA devices from using VGA memory
space.

If that is the decision, it might be worthwhile mentioning it somewhere
in the documentation, to prevent others from ever using that memory
space in an embedded system (and to save them the time needed to find
out about it and to identify and implement a workaround).

Guenter

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 01:31 PM, Guenter Roeck wrote:
> 
> It is used for a custom FPGA implementing a watchdog timer and some
> other functionality.
> 
> This is not a matter of supporting such a device in Linux, it is a
> matter of explicitly excluding non-VGA devices from using VGA memory
> space.
> 
> If that is the decision, it might be worthwhile mentioning it somewhere
> in the documentation, to prevent others from ever using that memory
> space in an embedded system (and to save them the time needed to find
> out about it and to identify and implement a workaround).
> 

"Don't use legacy fixed-function addresses for nonstandard purposes."

There, there is your documentation.

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Guenter Roeck]

On Fri, 2010-04-09 at 16:44 -0400, H. Peter Anvin wrote:
> On 04/09/2010 01:31 PM, Guenter Roeck wrote:
> > 
> > It is used for a custom FPGA implementing a watchdog timer and some
> > other functionality.
> > 
> > This is not a matter of supporting such a device in Linux, it is a
> > matter of explicitly excluding non-VGA devices from using VGA memory
> > space.
> > 
> > If that is the decision, it might be worthwhile mentioning it somewhere
> > in the documentation, to prevent others from ever using that memory
> > space in an embedded system (and to save them the time needed to find
> > out about it and to identify and implement a workaround).
> > 
> 
> "Don't use legacy fixed-function addresses for nonstandard purposes."
> 
> There, there is your documentation.

Fair and good enough, as long as it is going to show up somewhere.

Guenter

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Alan Cox]

> "Don't use legacy fixed-function addresses for nonstandard purposes."
> 
> There, there is your documentation.

It's probably a good idea to only reserve it if the space is actually
being used. There are a variety of legitimate reasons to use that space
for other things on embedded x86 boards.

They are only "legacy fixed function" if you have a PCI bus...

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 03:42 PM, Alan Cox wrote:
>> "Don't use legacy fixed-function addresses for nonstandard purposes."
>>
>> There, there is your documentation.
> 
> It's probably a good idea to only reserve it if the space is actually
> being used. There are a variety of legitimate reasons to use that space
> for other things on embedded x86 boards.
> 
> They are only "legacy fixed function" if you have a PCI bus...

No they're not.  The 0xa0000...0xbffff range has been a legacy video
area since the very first PC (although the first PC only used
0xb0000..0xbffff, 0xa0000..0xbffff was declared reserved at that time.)

I'm wondering what those legitimate reasons are.  This is particularly
so since it affects our ability to deal with very early errors, long
before we have enumerated anything.  At this point we can at least lay
down bytes in the video area and hope the user can see them.

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Alan Cox]

> No they're not.  The 0xa0000...0xbffff range has been a legacy video
> area since the very first PC (although the first PC only used
> 0xb0000..0xbffff, 0xa0000..0xbffff was declared reserved at that time.)

Depending on your definition of "PC". Quite a few early MSDOS systems had
video elsewhere. Some embedded systems without video use the space for
other stuff. Lots of ISA 386/486 PCs had cards borrowing the unused bits
of video space.

> I'm wondering what those legitimate reasons are.  This is particularly
> so since it affects our ability to deal with very early errors, long
> before we have enumerated anything.  At this point we can at least lay
> down bytes in the video area and hope the user can see them.

Thats why you have the bios equipment byte and video queries.

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 03:54 PM, Alan Cox wrote:
> Depending on your definition of "PC". Quite a few early MSDOS systems had
> video elsewhere. Some embedded systems without video use the space for
> other stuff. Lots of ISA 386/486 PCs had cards borrowing the unused bits
> of video space.

With "early MSDOS" I presume you mean pre-386 (early on there were
computer makers who thought the MS-DOS universe would work like the CP/M
universe had), so that doesn't really matter for these purposes.

>> I'm wondering what those legitimate reasons are.  This is particularly
>> so since it affects our ability to deal with very early errors, long
>> before we have enumerated anything.  At this point we can at least lay
>> down bytes in the video area and hope the user can see them.
> 
> Thats why you have the bios equipment byte and video queries.

Yes of course; just because we don't want people to do the wrong thing
doesn't necessarily mean we won't try to be nice about it, as long as it
doesn't cause excessive pains elsewhere.

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Alan Cox]

> Why is this different for 64-bit vs 32-bit?  Can you point me to any
> references where I can learn about this?

IMHO its wrong for both

You can only reserve the region in question if you actually have a VGA
device and mappings present.

It's wrong for non PCI systems
It's wrong for legacy ISA systems with monochrome video/no video
It's wrong for several embedded platforms.
It's wrong if PCI isn't your root bridge

Basically the reservation is the wrong way to fix it. A much saner way to
fix it would be to simply keep a list of address ranges not to use for
PCI device relocation. For I/O ports of course we just fix up the PCI
resources of the device to list them as we discover it (IDE legacy).

You don't want to put anything at the VGA address that needs assigning an
address. That is *totally* different to the question of whether you want
to believe the space is 'reserved'. If something is at that address then
presumably the firmware knows what it is doing. If a device driver wishes
to reserve that address it's doing so with more information, later in
boot so should be allowed to.

Alan

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/09/2010 03:51 PM, Alan Cox wrote:
>> Why is this different for 64-bit vs 32-bit?  Can you point me to any
>> references where I can learn about this?
> 
> IMHO its wrong for both
> 
> You can only reserve the region in question if you actually have a VGA
> device and mappings present.
> 
> It's wrong for non PCI systems
> It's wrong for legacy ISA systems with monochrome video/no video
> It's wrong for several embedded platforms.
> It's wrong if PCI isn't your root bridge
> 
> Basically the reservation is the wrong way to fix it. A much saner way to
> fix it would be to simply keep a list of address ranges not to use for
> PCI device relocation. For I/O ports of course we just fix up the PCI
> resources of the device to list them as we discover it (IDE legacy).
>
> You don't want to put anything at the VGA address that needs assigning an
> address. That is *totally* different to the question of whether you want
> to believe the space is 'reserved'. If something is at that address then
> presumably the firmware knows what it is doing. If a device driver wishes
> to reserve that address it's doing so with more information, later in
> boot so should be allowed to.

That's what I mean with reserved, I'm using the term in the
E820_RESERVED sense.  As in "don't put anything there without it being
an explicit assignment".

	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/07/2010 03:45 PM, Yinghai wrote:
> 
> It seem another thread, erission has one model without VGA, and they use that area for other device MMIO.
> 
> current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM.
> 

Removing is not the same thing as reserving!

A range with no type in E820 is address space available for allocation;
whereas in order to be reserved, it should be E820_RESERVED.

> in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map.
> that is before pci BAR is claimed.
> 
> or you can add
> boot_params.screen_info.orig_video_isVGA == 1
> or double check scan pci tree to see if video is there or not

Perhaps boot_params.screen_info.orig_video_isVGA != 1 because he's not
booting in a text mode?
	
	-hpa

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Wed, Apr 07, 2010 at 04:43:44PM -0700, H. Peter Anvin wrote:
> > or you can add
> > boot_params.screen_info.orig_video_isVGA == 1
> > or double check scan pci tree to see if video is there or not
> 
> Perhaps boot_params.screen_info.orig_video_isVGA != 1 because he's not
> booting in a text mode?

It's a pretty standard grub2 install (Debian unstable,
1.98~20100128-1.2) with something approaching the default config.  Grub
does seem to put the console in some annoying framebuffer format to draw
the boot menu, but IIRC it switches back to VGA textmode before booting
the kernel.

-andy

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[H. Peter Anvin]

On 04/07/2010 05:19 PM, Andy Isaacson wrote:
> On Wed, Apr 07, 2010 at 04:43:44PM -0700, H. Peter Anvin wrote:
>>> or you can add
>>> boot_params.screen_info.orig_video_isVGA == 1
>>> or double check scan pci tree to see if video is there or not
>>
>> Perhaps boot_params.screen_info.orig_video_isVGA != 1 because he's not
>> booting in a text mode?
> 
> It's a pretty standard grub2 install (Debian unstable,
> 1.98~20100128-1.2) with something approaching the default config.  Grub
> does seem to put the console in some annoying framebuffer format to draw
> the boot menu, but IIRC it switches back to VGA textmode before booting
> the kernel.

Grub2 gratuitously bypasses the 16-bit initialization code in the Linux
kernel, that could easily be a source of bugs (and with Grub's track
record, probably is.)

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32

[Andy Isaacson]

On Wed, Apr 07, 2010 at 03:06:28PM -0600, Bjorn Helgaas wrote:
> 
> Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on
> x86_32.  But this legacy area is also used on x86_64, so this patch
> reserves it there, too.
> 
> If we don't reserve it, we may mistakenly move a PCI device to that area,
> as we did here:
> 
>   pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
>   pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
>   pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
>   pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff]
> 
> as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375
> 
> I think the fact that the BAR is not within a host bridge window is a
> BIOS defect, and it's now more visible because we have "pci=use_crs" as
> the default.  Using "pci=nocrs" is a workaround, because then we won't
> attempt to move the device.

This patch doesn't fix the T3400.

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.34-rc3-00300-g29dc2a0 (andy@farthing) (gcc version 4.3.3 (Debian 4.3.3-5) ) #6 SMP Thu Apr 8 14:22:20 PDT 2010
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00300-g29dc2a0 root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro console=tty0 console=ttyS0,115200
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfe01c00 (usable)
[    0.000000]  BIOS-e820: 00000000bfe01c00 - 00000000bfe53c00 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bfe53c00 - 00000000bfe55c00 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bfe55c00 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 00000001bc000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x1bc000 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] last_pfn = 0xbfe01 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000fe710] fe710
[    0.000000] init_memory_mapping: 0000000000000000-00000000bfe01000
[    0.000000] init_memory_mapping: 0000000100000000-00000001bc000000
[    0.000000] RAMDISK: 37c8e000 - 37ff0000
[    0.000000] ACPI: RSDP 00000000000febf0 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000fcea4 0006C (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: FACP 00000000000fcfcc 000F4 (v03 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: DSDT 00000000fff5aafd 03794 (v01   DELL    dt_ex 00001000 INTL 20050624)
[    0.000000] ACPI: FACS 00000000bfe01c00 00040
[    0.000000] ACPI: SSDT 00000000fff5e291 00099 (v01   DELL    st_ex 00001000 INTL 20050624)
[    0.000000] ACPI: APIC 00000000000fd0c0 00092 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: BOOT 00000000000fd152 00028 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: ASF! 00000000000fd17a 00096 (v32 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: MCFG 00000000000fd210 0003E (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: HPET 00000000000fd24e 00038 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: TCPA 00000000000fd4aa 00032 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] ACPI: SLIC 00000000000fd286 00176 (v01 DELL    B9K     00000015 ASL  00000061)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000001bc000000
[    0.000000] Initmem setup node 0 0000000000000000-00000001bc000000
[    0.000000]   NODE_DATA [0000000100000000 - 0000000100004fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000001 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x001bc000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000001 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x000bfe01
[    0.000000]     0: 0x00100000 -> 0x001bc000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 4 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000f0000
[    0.000000] PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000bfe01000 - 00000000bfe02000
[    0.000000] PM: Registered nosave memory: 00000000bfe02000 - 00000000bfe53000
[    0.000000] PM: Registered nosave memory: 00000000bfe53000 - 00000000bfe54000
[    0.000000] PM: Registered nosave memory: 00000000bfe54000 - 00000000bfe55000
[    0.000000] PM: Registered nosave memory: 00000000bfe55000 - 00000000bfe56000
[    0.000000] PM: Registered nosave memory: 00000000bfe56000 - 00000000c0000000
[    0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000e0000000
[    0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000f0000000
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000feda0000
[    0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
[    0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff880001e00000 s81896 r8192 d20504 u262144
[    0.000000] pcpu-alloc: s81896 r8192 d20504 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1531006
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34-rc3-00300-g29dc2a0 root=UUID=a2359eda-9295-451c-924f-c181c6f49d0d ro console=tty0 console=ttyS0,115200
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (62 early reservations)
[    0.000000]   #1 [0001000000 - 0001db1128]   TEXT DATA BSS
[    0.000000]   #2 [0037c8e000 - 0037ff0000]         RAMDISK
[    0.000000]   #3 [0001db2000 - 0001db21a8]             BRK
[    0.000000]   #4 [00000fe720 - 0000100000]   BIOS reserved
[    0.000000]   #5 [00000fe710 - 00000fe720]    MP-table mpf
[    0.000000]   #6 [000009ec00 - 00000f0000]   BIOS reserved
[    0.000000]   #7 [00000f0304 - 00000fe710]   BIOS reserved
[    0.000000]   #8 [00000f0000 - 00000f0304]    MP-table mpc
[    0.000000]   #9 [0000001000 - 0000003000]      TRAMPOLINE
[    0.000000]   #10 [0000003000 - 0000007000]     ACPI WAKEUP
[    0.000000]   #11 [0000008000 - 000000b000]         PGTABLE
[    0.000000]   #12 [000000b000 - 000000e000]         PGTABLE
[    0.000000]   #13 [0100000000 - 0100005000]       NODE_DATA
[    0.000000]   #14 [0001db21c0 - 0001db31c0]         BOOTMEM
[    0.000000]   #15 [0001db1140 - 0001db15c0]         BOOTMEM
[    0.000000]   #16 [0100005000 - 0100006000]         BOOTMEM
[    0.000000]   #17 [0100006000 - 0100007000]         BOOTMEM
[    0.000000]   #18 [0100200000 - 0105600000]        MEMMAP 0
[    0.000000]   #19 [0001db15c0 - 0001db1740]         BOOTMEM
[    0.000000]   #20 [0001db31c0 - 0001dcb1c0]         BOOTMEM
[    0.000000]   #21 [0001dcb1c0 - 0001de31c0]         BOOTMEM
[    0.000000]   #22 [0001de4000 - 0001de5000]         BOOTMEM
[    0.000000]   #23 [0001db1740 - 0001db1781]         BOOTMEM
[    0.000000]   #24 [0001db17c0 - 0001db1803]         BOOTMEM
[    0.000000]   #25 [0001db1840 - 0001db1b18]         BOOTMEM
[    0.000000]   #26 [0001db1b40 - 0001db1ba8]         BOOTMEM
[    0.000000]   #27 [0001db1bc0 - 0001db1c28]         BOOTMEM
[    0.000000]   #28 [0001db1c40 - 0001db1ca8]         BOOTMEM
[    0.000000]   #29 [0001db1cc0 - 0001db1d28]         BOOTMEM
[    0.000000]   #30 [0001db1d40 - 0001db1da8]         BOOTMEM
[    0.000000]   #31 [0001db1dc0 - 0001db1e28]         BOOTMEM
[    0.000000]   #32 [0001db1e40 - 0001db1ea8]         BOOTMEM
[    0.000000]   #33 [0001db1ec0 - 0001db1f28]         BOOTMEM
[    0.000000]   #34 [0001db1f40 - 0001db1fa8]         BOOTMEM
[    0.000000]   #35 [0001de31c0 - 0001de3228]         BOOTMEM
[    0.000000]   #36 [0001de3240 - 0001de32a8]         BOOTMEM
[    0.000000]   #37 [0001de32c0 - 0001de3328]         BOOTMEM
[    0.000000]   #38 [0001db1fc0 - 0001db1fe0]         BOOTMEM
[    0.000000]   #39 [0001de3340 - 0001de3360]         BOOTMEM
[    0.000000]   #40 [0001de3380 - 0001de3402]         BOOTMEM
[    0.000000]   #41 [0001de3440 - 0001de34c2]         BOOTMEM
[    0.000000]   #42 [0001e00000 - 0001e1b000]         BOOTMEM
[    0.000000]   #43 [0001e40000 - 0001e5b000]         BOOTMEM
[    0.000000]   #44 [0001e80000 - 0001e9b000]         BOOTMEM
[    0.000000]   #45 [0001ec0000 - 0001edb000]         BOOTMEM
[    0.000000]   #46 [0001f00000 - 0001f1b000]         BOOTMEM
[    0.000000]   #47 [0001f40000 - 0001f5b000]         BOOTMEM
[    0.000000]   #48 [0001f80000 - 0001f9b000]         BOOTMEM
[    0.000000]   #49 [0001fc0000 - 0001fdb000]         BOOTMEM
[    0.000000]   #50 [0001de3500 - 0001de3508]         BOOTMEM
[    0.000000]   #51 [0001de3540 - 0001de3548]         BOOTMEM
[    0.000000]   #52 [0001de3580 - 0001de35a0]         BOOTMEM
[    0.000000]   #53 [0001de35c0 - 0001de3600]         BOOTMEM
[    0.000000]   #54 [0001de3600 - 0001de3720]         BOOTMEM
[    0.000000]   #55 [0001de3740 - 0001de3788]         BOOTMEM
[    0.000000]   #56 [0001de37c0 - 0001de3808]         BOOTMEM
[    0.000000]   #57 [0001de5000 - 0001ded000]         BOOTMEM
[    0.000000]   #58 [0001fdb000 - 0005fdb000]         BOOTMEM
[    0.000000]   #59 [0001e1b000 - 0001e3b000]         BOOTMEM
[    0.000000]   #60 [0005fdb000 - 000601b000]         BOOTMEM
[    0.000000]   #61 [000000f000 - 0000017000]         BOOTMEM
[    0.000000] Memory: 6052848k/7274496k available (5342k kernel code, 1051016k absent, 170632k reserved, 6534k data, 612k init)
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:2304
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2394.110 MHz processor.
[    0.002005] Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.22 BogoMIPS (lpj=2394110)
[    0.004021] Security Framework initialized
[    0.005005] SELinux:  Initializing.
[    0.007315] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.013568] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.017320] Mount-cache hash table entries: 256
[    0.018183] Initializing cgroup subsys ns
[    0.019007] Initializing cgroup subsys cpuacct
[    0.020005] Initializing cgroup subsys blkio
[    0.021033] CPU: Physical Processor ID: 0
[    0.022002] CPU: Processor Core ID: 0
[    0.023003] using mwait in idle threads.
[    0.024002] Performance Events: Core2 events, Intel PMU driver.
[    0.027003] ... version:                2
[    0.028002] ... bit width:              40
[    0.029002] ... generic registers:      2
[    0.030002] ... value mask:             000000ffffffffff
[    0.031002] ... max period:             000000007fffffff
[    0.032002] ... fixed-purpose events:   3
[    0.033002] ... event mask:             0000000700000003
[    0.034039] ACPI: Core revision 20100121
[    0.201067] Setting APIC routing to flat
[    0.202471] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.213983] CPU0: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
[    0.216999] Booting Node   0, Processors  #1 #2 #3
[    0.433006] Brought up 4 CPUs
[    0.434002] Total of 4 processors activated (19151.52 BogoMIPS).
[    0.436089] khelper used greatest stack depth: 6008 bytes left
[    0.443352] Time: 21:27:42  Date: 04/08/10
[    0.444032] NET: Registered protocol family 16
[    0.445035] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.446007] ACPI: bus type pci registered
[    0.448045] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.449003] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.472120] PCI: Using configuration type 1 for base access
[    0.485021] bio: create slab <bio-0> at 0
[    0.517507] ACPI: BIOS _OSI(Linux) query ignored
[    0.564263] ACPI: Interpreter enabled
[    0.568002] ACPI: (supports S0 S1 S3 S4 S5)
[    0.572778] ACPI: Using IOAPIC for interrupt routing
[    0.762201] ACPI Warning: Incorrect checksum in table [TCPA] - 00, should be 87 (20100121/tbutils-314)
[    0.772002] ACPI: No dock devices found.
[    0.776002] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.795092] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.821199] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.828002] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.835002] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.842002] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
[    0.850001] pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]
[    0.857002] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
[    0.865001] pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]
[    0.872002] pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff]
[    0.880001] pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
[    0.887001] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]
[    0.895868] pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO
[    0.904003] pci 0000:00:1f.0: quirk: [io  0x0880-0x08bf] claimed by ICH6 GPIO
[    0.911003] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0c00 (mask 007f)
[    0.919002] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 00e0 (mask 0007)
[    0.927257] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.933033] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    0.938047] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    0.943194] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    0.949145] pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
[    2.982594] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
[    2.991196] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
[    2.999778] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    3.008382] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    3.018361] ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12 15)
[    3.026772] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[    3.036785] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[    3.045542] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[    3.053196] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    3.062003] vgaarb: loaded
[    3.065075] SCSI subsystem initialized
[    3.069035] usbcore: registered new interface driver usbfs
[    3.075019] usbcore: registered new interface driver hub
[    3.080021] usbcore: registered new device driver usb
[    3.086033] Advanced Linux Sound Architecture Driver Version 1.0.22.1.
[    3.093002] PCI: Using ACPI for IRQ routing
[    3.097036] pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
[    3.105042] Expanded resource reserved due to conflict with PCI Bus 0000:00
[    3.113047] cfg80211: Calling CRDA to update world regulatory domain
[    3.119015] NetLabel: Initializing
[    3.124001] NetLabel:  domain hash size = 128
[    3.128001] NetLabel:  protocols = UNLABELED CIPSOv4
[    3.133011] NetLabel:  unlabeled traffic allowed by default
[    3.139004] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[    3.146004] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    3.151372] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[    3.160021] Switching to clocksource tsc
[    3.173645] pnp: PnP ACPI init
[    3.176899] ACPI: bus type pnp registered
[    3.197841] pnp 00:01: disabling [io  0x0800-0x085f] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    3.208245] pnp 00:01: disabling [io  0x0860-0x08ff] because it overlaps 0000:00:1f.0 BAR 7 [io  0x0800-0x087f]
[    3.282787] pnp: PnP ACPI: found 12 devices
[    3.287157] ACPI: ACPI bus type pnp unregistered
[    3.291958] system 00:01: [io  0x0c00-0x0c7f] has been reserved
[    3.303431] pci 0000:00:1c.0: BAR 9: assigned [mem 0xf0000000-0xf01fffff 64bit pref]
[    3.311489] pci 0000:00:1c.5: BAR 9: assigned [mem 0xf0200000-0xf03fffff 64bit pref]
[    3.319543] pci 0000:00:1c.0: BAR 7: assigned [io  0x1000-0x1fff]
[    3.325808] pci 0000:00:1c.5: BAR 7: assigned [io  0x2000-0x2fff]
[    3.332077] pci 0000:00:1f.2: BAR 5: assigned [mem 0x000c0000-0x000c07ff]
[    3.339037] pci 0000:00:1f.2: BAR 5: set to [mem 0x000c0000-0x000c07ff] (PCI address [0xc0000-0xc07ff]
[    3.348651] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    3.354050] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    3.360320] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfdefffff]
[    3.367284] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    3.375350] pci 0000:00:06.0: PCI bridge to [bus 02-02]
[    3.380748] pci 0000:00:06.0:   bridge window [io  disabled]
[    3.386581] pci 0000:00:06.0:   bridge window [mem disabled]
[    3.392414] pci 0000:00:06.0:   bridge window [mem pref disabled]
[    3.398683] pci 0000:00:1c.0: PCI bridge to [bus 03-03]
[    3.404087] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    3.410356] pci 0000:00:1c.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
[    3.417321] pci 0000:00:1c.0:   bridge window [mem 0xf0000000-0xf01fffff 64bit pref]
[    3.425388] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    3.430788] pci 0000:00:1c.5:   bridge window [io  0x2000-0x2fff]
[    3.437056] pci 0000:00:1c.5:   bridge window [mem 0xf9e00000-0xf9efffff]
[    3.444017] pci 0000:00:1c.5:   bridge window [mem 0xf0200000-0xf03fffff 64bit pref]
[    3.452079] pci 0000:00:1e.0: PCI bridge to [bus 05-05]
[    3.457479] pci 0000:00:1e.0:   bridge window [io  disabled]
[    3.463319] pci 0000:00:1e.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
[    3.470282] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    3.476558] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.483435] pci 0000:00:06.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.490318] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.497209] pci 0000:00:1c.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    3.504185] NET: Registered protocol family 2
[    3.508920] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    3.517903] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    3.530505] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    3.538017] TCP: Hash tables configured (established 524288 bind 65536)
[    3.544805] TCP reno registered
[    3.548147] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    3.554509] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    3.561434] NET: Registered protocol family 1
[    3.566201] RPC: Registered udp transport module.
[    3.571088] RPC: Registered tcp transport module.
[    3.575969] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    4.693019] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[    4.700455] Trying to unpack rootfs image as initramfs...
[    4.771225] Freeing initrd memory: 3464k freed
[    4.776924] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    4.783544] Placing 64MB software IO TLB between ffff880001fdb000 - ffff880005fdb000
[    4.791588] software IO TLB at phys 0x1fdb000 - 0x5fdb000
[    4.797392] Simple Boot Flag at 0x7a set to 0x1
[    4.803990] microcode: CPU0 sig=0x6fb, pf=0x10, revision=0xb3
[    4.809909] microcode: CPU1 sig=0x6fb, pf=0x10, revision=0xb3
[    4.815825] microcode: CPU2 sig=0x6fb, pf=0x10, revision=0xb3
[    4.821743] microcode: CPU3 sig=0x6fb, pf=0x10, revision=0xb3
[    4.831321] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    4.840768] audit: initializing netlink socket (disabled)
[    4.846360] type=2000 audit(1270762064.846:1): initialized
[    4.870704] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    4.881160] VFS: Disk quotas dquot_6.5.2
[    4.885349] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    4.893253] msgmni has been set to 11828
[    4.898070] alg: No test for stdrng (krng)
[    4.902481] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    4.910199] io scheduler noop registered
[    4.914292] io scheduler deadline registered
[    4.918881] io scheduler cfq registered (default)
[    4.924851] pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS
[    4.932557] pcieport 0000:00:01.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.941725] pcie_pme: probe of 0000:00:01.0:pcie01 failed with error -13
[    4.948593] pcieport 0000:00:06.0: Requesting control of PCIe PME from ACPI BIOS
[    4.956298] pcieport 0000:00:06.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.965467] pcie_pme: probe of 0000:00:06.0:pcie01 failed with error -13
[    4.972334] pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS
[    4.980034] pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support
[    4.989212] pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13
[    4.996086] pcieport 0000:00:1c.5: Requesting control of PCIe PME from ACPI BIOS
[    5.003781] pcieport 0000:00:1c.5: Failed to receive control of PCIe PME service: no _OSC support
[    5.012950] pcie_pme: probe of 0000:00:1c.5:pcie01 failed with error -13
[    5.019925] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    5.026064] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    5.034718] ACPI: Power Button [VBTN]
[    5.038646] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    5.046350] ACPI: Power Button [PWRF]
[    5.220953] Non-volatile memory driver v1.3
[    5.225312] Linux agpgart interface v0.103
[    5.229767] [drm] Initialized drm 1.1.0 20060810
[    5.234556] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[    5.242348] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ÿ[    5.493338] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    5.500096] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    5.508624] brd: module loaded
[    5.513142] loop: module loaded
[    5.516579] Loading iSCSI transport class v2.0-870.
[    5.522209] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
[    5.584017] ------------[ cut here ]------------
[    5.588813] WARNING: at drivers/ata/ahci.c:795 ahci_enable_ahci+0x52/0x5b()
[    5.595938] Hardware name: Precision WorkStation T3400  
[    5.601417] Modules linked in:
[    5.604699] Pid: 1, comm: swapper Not tainted 2.6.34-rc3-00300-g29dc2a0 #6
[    5.611737] Call Trace:
[    5.614358]  [<ffffffff812ec086>] ? ahci_enable_ahci+0x52/0x5b
[    5.620359]  [<ffffffff810390b2>] warn_slowpath_common+0x77/0xa4
[    5.626532]  [<ffffffff810390ee>] warn_slowpath_null+0xf/0x11
[    5.632444]  [<ffffffff812ec086>] ahci_enable_ahci+0x52/0x5b
[    5.638269]  [<ffffffff812ed972>] ahci_init_one+0x370/0x1145
[    5.644108]  [<ffffffff811d8a0a>] ? ida_get_new_above+0xfd/0x1b4
[    5.650281]  [<ffffffff811d8815>] ? idr_get_empty_slot+0x169/0x261
[    5.656626]  [<ffffffff811d8a0a>] ? ida_get_new_above+0xfd/0x1b4
[    5.662800]  [<ffffffff8112f894>] ? sysfs_find_dirent+0x1c/0x31
[    5.668885]  [<ffffffff8112fc2a>] ? sysfs_add_one+0x1c/0xe7
[    5.674624]  [<ffffffff811d95ca>] ? kobject_get+0x1a/0x22
[    5.680200]  [<ffffffff811ee6d3>] local_pci_probe+0x12/0x16
[    5.685940]  [<ffffffff811ef5a6>] pci_device_probe+0xc6/0xf0
[    5.691766]  [<ffffffff812b10a0>] ? driver_sysfs_add+0x4c/0x72
[    5.697766]  [<ffffffff812b11ec>] driver_probe_device+0xad/0x15f
[    5.703939]  [<ffffffff812b12f6>] __driver_attach+0x58/0x7b
[    5.709678]  [<ffffffff812b129e>] ? __driver_attach+0x0/0x7b
[    5.715504]  [<ffffffff812b0a51>] bus_for_each_dev+0x4e/0x84
[    5.721329]  [<ffffffff812b1052>] driver_attach+0x1c/0x1e
[    5.726895]  [<ffffffff812b03a7>] bus_add_driver+0xb8/0x20e
[    5.732633]  [<ffffffff812b15ea>] driver_register+0xb3/0x121
[    5.738461]  [<ffffffff81bdc461>] ? ahci_init+0x0/0x1b
[    5.743767]  [<ffffffff811ef7f8>] __pci_register_driver+0x51/0xbc
[    5.750030]  [<ffffffff81bdc461>] ? ahci_init+0x0/0x1b
[    5.755336]  [<ffffffff81bdc47a>] ahci_init+0x19/0x1b
[    5.760557]  [<ffffffff810001f0>] do_one_initcall+0x5a/0x14a
[    5.766384]  [<ffffffff81baf69d>] kernel_init+0x154/0x1de
[    5.771952]  [<ffffffff810037b4>] kernel_thread_helper+0x4/0x10
[    5.778038]  [<ffffffff81baf549>] ? kernel_init+0x0/0x1de
[    5.783605]  [<ffffffff810037b0>] ? kernel_thread_helper+0x0/0x10
[    5.789866] ---[ end trace 941a3246270f5a35 ]---
[    5.794758] ahci: SSS flag set, parallel bus scan disabled
[    5.855017] ------------[ cut here ]------------
[    5.859809] WARNING: at drivers/ata/ahci.c:795 ahci_enable_ahci+0x52/0x5b()
[    5.866931] Hardware name: Precision WorkStation T3400  
[    5.872410] Modules linked in:
[    5.875692] Pid: 1, comm: swapper Tainted: G        W  2.6.34-rc3-00300-g29dc2a0 #6
[    5.883646] Call Trace:
[    5.886268]  [<ffffffff812ec086>] ? ahci_enable_ahci+0x52/0x5b
[    5.892269]  [<ffffffff810390b2>] warn_slowpath_common+0x77/0xa4
[    5.898441]  [<ffffffff810390ee>] warn_slowpath_null+0xf/0x11
[    5.904352]  [<ffffffff812ec086>] ahci_enable_ahci+0x52/0x5b
[    5.910177]  [<ffffffff812ec0bb>] ahci_reset_controller+0x2c/0x14a
[    5.916523]  [<ffffffff812ee2b6>] ahci_init_one+0xcb4/0x1145
[    5.922349]  [<ffffffff811d8a0a>] ? ida_get_new_above+0xfd/0x1b4
[    5.928521]  [<ffffffff811d8815>] ? idr_get_empty_slot+0x169/0x261
[    5.934867]  [<ffffffff811d8a0a>] ? ida_get_new_above+0xfd/0x1b4
[    5.941039]  [<ffffffff8112f894>] ? sysfs_find_dirent+0x1c/0x31
[    5.947124]  [<ffffffff8112fc2a>] ? sysfs_add_one+0x1c/0xe7
[    5.952864]  [<ffffffff811d95ca>] ? kobject_get+0x1a/0x22
[    5.958429]  [<ffffffff811ee6d3>] local_pci_probe+0x12/0x16
[    5.964167]  [<ffffffff811ef5a6>] pci_device_probe+0xc6/0xf0
[    5.969993]  [<ffffffff812b10a0>] ? driver_sysfs_add+0x4c/0x72
[    5.975991]  [<ffffffff812b11ec>] driver_probe_device+0xad/0x15f
[    5.982162]  [<ffffffff812b12f6>] __driver_attach+0x58/0x7b
[    5.987900]  [<ffffffff812b129e>] ? __driver_attach+0x0/0x7b
[    5.993725]  [<ffffffff812b0a51>] bus_for_each_dev+0x4e/0x84
[    5.999551]  [<ffffffff812b1052>] driver_attach+0x1c/0x1e
[    6.005118]  [<ffffffff812b03a7>] bus_add_driver+0xb8/0x20e
[    6.010857]  [<ffffffff812b15ea>] driver_register+0xb3/0x121
[    6.016684]  [<ffffffff81bdc461>] ? ahci_init+0x0/0x1b
[    6.021988]  [<ffffffff811ef7f8>] __pci_register_driver+0x51/0xbc
[    6.028247]  [<ffffffff81bdc461>] ? ahci_init+0x0/0x1b
[    6.033553]  [<ffffffff81bdc47a>] ahci_init+0x19/0x1b
[    6.038774]  [<ffffffff810001f0>] do_one_initcall+0x5a/0x14a
[    6.044600]  [<ffffffff81baf69d>] kernel_init+0x154/0x1de
[    6.050166]  [<ffffffff810037b4>] kernel_thread_helper+0x4/0x10
[    6.056252]  [<ffffffff81baf549>] ? kernel_init+0x0/0x1de
[    6.061816]  [<ffffffff810037b0>] ? kernel_thread_helper+0x0/0x10
[    6.068074] ---[ end trace 941a3246270f5a36 ]---
[    7.073018] ahci 0000:00:1f.2: controller reset failed (0x3034374b)
[    7.079480] ahci 0000:00:1f.2: PCI INT C disabled
[    7.084358] ahci: probe of 0000:00:1f.2 failed with error -5

-andy

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

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

I don't think it's sufficient, actually.  We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device.  I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions.

"Jesse Barnes" <jbarnes@virtuousgeek.org> wrote:

>On Mon, 26 Apr 2010 14:44:50 -0700
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> >
>> > Agreed.  The trickier part is handling any platform devices that
>> > request_resource against that space.  But maybe we don't need to do
>> > anything special; just making sure we avoid it in the PCI "BIOS" code
>> > as Bjorn did may be sufficient.
>> >
>> 
>> Why is that hard?  If a platform device does a request_resource against
>> that space, it's a request for specific address space and it should be
>> granted.
>
>I was thinking if we made it a special resource type we'd have to
>change any platform drivers to use it; i.e. it wouldn't be
>IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS.  That way it
>wouldn't be part of the normal resource space.
>
>But that's definitely overkill.  I think Bjorn's fix is sufficient.
>
>-- 
>Jesse Barnes, Intel Open Source Technology Center

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

Sorry, sounds like we're talking about a few different things here:
  1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
  2) devices which sit in e820 ram or other space below 1M
  3) how to hand out space from the 0-1M region

Bjorn's patch fixes (3) so that regular PCI devices don't get space
there, which makes sense.

Some devices may be in the special region, but were pointed there by
the BIOS.  Generally this should be ok, so drivers requesting this
space should be allowed to get at it, but we should avoid putting
anything else there.

And below it sounds like you're talking about (1).  If so, then yes I
guess we need a solution there, which will allow drivers to bind to
these "reserved" devices, even though the BIOS has marked them as off
limits, at least as far as e820 goes.

So perhaps both (1) and (2) could be put into a new, special IO
resource space, or could use a new flag, since "busy" doesn't really
reflect what's going on there very well, as Bjorn pointed out.

Jesse

On Mon, 26 Apr 2010 16:02:57 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> I don't think it's sufficient, actually.  We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device.  I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions.
> 
> "Jesse Barnes" <jbarnes@virtuousgeek.org> wrote:
> 
> >On Mon, 26 Apr 2010 14:44:50 -0700
> >"H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> >> >
> >> > Agreed.  The trickier part is handling any platform devices that
> >> > request_resource against that space.  But maybe we don't need to do
> >> > anything special; just making sure we avoid it in the PCI "BIOS" code
> >> > as Bjorn did may be sufficient.
> >> >
> >> 
> >> Why is that hard?  If a platform device does a request_resource against
> >> that space, it's a request for specific address space and it should be
> >> granted.
> >
> >I was thinking if we made it a special resource type we'd have to
> >change any platform drivers to use it; i.e. it wouldn't be
> >IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS.  That way it
> >wouldn't be part of the normal resource space.
> >
> >But that's definitely overkill.  I think Bjorn's fix is sufficient.
> >
> >-- 
> >Jesse Barnes, Intel Open Source Technology Center
> 


-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

> Sorry, sounds like we're talking about a few different things here:
>   1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
>   2) devices which sit in e820 ram or other space below 1M
>   3) how to hand out space from the 0-1M region
>
> Bjorn's patch fixes (3) so that regular PCI devices don't get space
> there, which makes sense.
>
> Some devices may be in the special region, but were pointed there by
> the BIOS.  Generally this should be ok, so drivers requesting this
> space should be allowed to get at it, but we should avoid putting
> anything else there.
>
> And below it sounds like you're talking about (1).  If so, then yes I
> guess we need a solution there, which will allow drivers to bind to
> these "reserved" devices, even though the BIOS has marked them as off
> limits, at least as far as e820 goes.
>
> So perhaps both (1) and (2) could be put into a new, special IO
> resource space, or could use a new flag, since "busy" doesn't really
> reflect what's going on there very well, as Bjorn pointed out.
>
> Jesse

Properly done, these aren't separate cases at all.

The E820 interface as specified doesn't reserve the address space below 1
MB, because it is legacy space -- which is another way of saying "everyone
already knows to reserve it."  The Right Thing[TM] to do is simply to
modify the data output by E820 to reserve all non-memory space below 1 MB;
this can (and should) be done in platform-specific initialization code to
allow overrides.

Once that is done, both your (2) and (3) cases are nothing but special
subcases of (1).  That's what I would like to see as the right solution,
but it is clearly too late to do that in .34.

Bjorn's solution is very attractive for .34 since it is so simple, but
it's not a complete solution.

        -hpa

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

> Sorry, sounds like we're talking about a few different things here:
>   1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
>   2) devices which sit in e820 ram or other space below 1M
>   3) how to hand out space from the 0-1M region
>
> Bjorn's patch fixes (3) so that regular PCI devices don't get space
> there, which makes sense.
>
> Some devices may be in the special region, but were pointed there by
> the BIOS.  Generally this should be ok, so drivers requesting this
> space should be allowed to get at it, but we should avoid putting
> anything else there.
>
> And below it sounds like you're talking about (1).  If so, then yes I
> guess we need a solution there, which will allow drivers to bind to
> these "reserved" devices, even though the BIOS has marked them as off
> limits, at least as far as e820 goes.
>
> So perhaps both (1) and (2) could be put into a new, special IO
> resource space, or could use a new flag, since "busy" doesn't really
> reflect what's going on there very well, as Bjorn pointed out.
>
> Jesse

Properly done, these aren't separate cases at all.

The E820 interface as specified doesn't reserve the address space below 1
MB, because it is legacy space -- which is another way of saying "everyone
already knows to reserve it."  The Right Thing[TM] to do is simply to
modify the data output by E820 to reserve all non-memory space below 1 MB;
this can (and should) be done in platform-specific initialization code to
allow overrides.

Once that is done, both your (2) and (3) cases are nothing but special
subcases of (1).  That's what I would like to see as the right solution,
but it is clearly too late to do that in .34.

Bjorn's solution is very attractive for .34 since it is so simple, but
it's not a complete solution.

        -hpa

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

On Mon, 26 Apr 2010 16:49:55 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> > Sorry, sounds like we're talking about a few different things here:
> >   1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
> >   2) devices which sit in e820 ram or other space below 1M
> >   3) how to hand out space from the 0-1M region
> >
> > Bjorn's patch fixes (3) so that regular PCI devices don't get space
> > there, which makes sense.
> >
> > Some devices may be in the special region, but were pointed there by
> > the BIOS.  Generally this should be ok, so drivers requesting this
> > space should be allowed to get at it, but we should avoid putting
> > anything else there.
> >
> > And below it sounds like you're talking about (1).  If so, then yes I
> > guess we need a solution there, which will allow drivers to bind to
> > these "reserved" devices, even though the BIOS has marked them as off
> > limits, at least as far as e820 goes.
> >
> > So perhaps both (1) and (2) could be put into a new, special IO
> > resource space, or could use a new flag, since "busy" doesn't really
> > reflect what's going on there very well, as Bjorn pointed out.
> >
> > Jesse
> 
> Properly done, these aren't separate cases at all.
> 
> The E820 interface as specified doesn't reserve the address space below 1
> MB, because it is legacy space -- which is another way of saying "everyone
> already knows to reserve it."  The Right Thing[TM] to do is simply to
> modify the data output by E820 to reserve all non-memory space below 1 MB;
> this can (and should) be done in platform-specific initialization code to
> allow overrides.
> 
> Once that is done, both your (2) and (3) cases are nothing but special
> subcases of (1).  That's what I would like to see as the right solution,
> but it is clearly too late to do that in .34.
> 
> Bjorn's solution is very attractive for .34 since it is so simple, but
> it's not a complete solution.

Glad we agree.  As I said (and echoing Bjorn), I think it would be best
to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
We want and need to do allocations from the special region, so we
should mark it as such.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Linus Torvalds]

On Mon, 26 Apr 2010, Jesse Barnes wrote:
> 
> Glad we agree.  As I said (and echoing Bjorn), I think it would be best
> to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
> We want and need to do allocations from the special region, so we
> should mark it as such.

I think Bjorn's patch to pcibios_align_resource() is really good and 
clever, and I think it should take care of the need for IORESOURCE_BUSY, 
no? We do want to let devices that are _already_ allocated there insert 
their resources, it's just that we never want to allocate new ones in the 
low 1M region.

Do we actually have a regression left with Bjorn's patch?

		Linus

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Jesse Barnes]

On Mon, 26 Apr 2010 18:27:27 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Mon, 26 Apr 2010, Jesse Barnes wrote:
> > 
> > Glad we agree.  As I said (and echoing Bjorn), I think it would be best
> > to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
> > We want and need to do allocations from the special region, so we
> > should mark it as such.
> 
> I think Bjorn's patch to pcibios_align_resource() is really good and 
> clever, and I think it should take care of the need for IORESOURCE_BUSY, 
> no? We do want to let devices that are _already_ allocated there insert 
> their resources, it's just that we never want to allocate new ones in the 
> low 1M region.
> 
> Do we actually have a regression left with Bjorn's patch?

No, I think we're covered.  But it sounded like Peter was also
concerned about making new allocations from the 1M space, which would
mean we'd need something other than the IORESOURCE_BUSY bit.  But maybe
Bjorn's patch plus simply removing the IORESOURCE_BUSY line is
sufficient for that.  The downside there is that it doesn't clearly
communicate the special nature of the 1M region.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Yinghai]

On 04/26/2010 06:27 PM, Linus Torvalds wrote:
> 
> 
> On Mon, 26 Apr 2010, Jesse Barnes wrote:
>>
>> Glad we agree.  As I said (and echoing Bjorn), I think it would be best
>> to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
>> We want and need to do allocations from the special region, so we
>> should mark it as such.
> 
> I think Bjorn's patch to pcibios_align_resource() is really good and 
> clever, and I think it should take care of the need for IORESOURCE_BUSY, 
> no? We do want to let devices that are _already_ allocated there insert 
> their resources, it's just that we never want to allocate new ones in the 
> low 1M region.

case A:
bus 0: --- bus X --- device Y
if the BIOS only assign range to to BUS X bridge with 0xB0000, and
device Y is not assigned.  then with Bojorn's patch, device Y can not
get right resource allocated on first try.


> 
> Do we actually have a regression left with Bjorn's patch?

also find one AMD system:

[    6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
[    7.023528] pci_root PNP0A03:00: host bridge window [io  0x0000-0x03af]
[    7.024014] pci_root PNP0A03:00: host bridge window [io  0x03b0-0x03bb]
[    7.028005] pci_root PNP0A03:00: host bridge window [io  0x03bc-0x03bf]
[    7.032005] pci_root PNP0A03:00: host bridge window [io  0x03c0-0x03df]
[    7.036005] pci_root PNP0A03:00: host bridge window [io  0x03e0-0xefff]
[    7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
[    7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
[    7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
[    7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]

[    0.000000]  BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
[    0.000000]  BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
[    0.000000]  BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
[    0.000000]  BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000008028000000 (usable)

pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.

YH

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
> On 04/26/2010 06:27 PM, Linus Torvalds wrote:
> > Do we actually have a regression left with Bjorn's patch?

After the pcibios_align_resource() patch, I'm not aware of any regressions.

But let's double-check this:

> also find one AMD system:
> [    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> ...
> pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.

I agree, it's very unlikely that it's safe to put PCI devices all the
way up to 0xffffffff.  I suspect this might be fixed by d558b483d5a,
which computes the end of the bridge window using _MAX rather than _LEN.

See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
similar to the one above: we originally thought the window was
[mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
[mem 0xcff00000-0xfebfffff], which matches what Windows found.

Yinghai, can you take a look at your AMD system again with a kernel that
includes d558b483d5a, and see whether we still have a problem?  If we
*do* still have a problem, please open a bugzilla and attach a dmesg log
with ACPI resource info collected with the debug patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5

Bjorn

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

Yinghai, ping, do you have any more information about this?

On Tuesday 27 April 2010 09:11:10 am Bjorn Helgaas wrote:
> On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
> But let's double-check this:
> 
> > also find one AMD system:
> > [    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> > ...
> > pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
> 
> I agree, it's very unlikely that it's safe to put PCI devices all the
> way up to 0xffffffff.  I suspect this might be fixed by d558b483d5a,
> which computes the end of the bridge window using _MAX rather than _LEN.
> 
> See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
> similar to the one above: we originally thought the window was
> [mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
> [mem 0xcff00000-0xfebfffff], which matches what Windows found.
> 
> Yinghai, can you take a look at your AMD system again with a kernel that
> includes d558b483d5a, and see whether we still have a problem?  If we
> *do* still have a problem, please open a bugzilla and attach a dmesg log
> with ACPI resource info collected with the debug patch here:
> https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
> 
> Bjorn
> 

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Yinghai Lu]

Never mind, for 2.6.34 your patch should be good enough.

On 04/28/2010 09:07 AM, Bjorn Helgaas wrote:
> Yinghai, ping, do you have any more information about this?
>
> On Tuesday 27 April 2010 09:11:10 am Bjorn Helgaas wrote:
>   
>> On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
>> But let's double-check this:
>>
>>     
>>> also find one AMD system:
>>> [    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
>>> ...
>>> pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
>>>       
>> I agree, it's very unlikely that it's safe to put PCI devices all the
>> way up to 0xffffffff.  I suspect this might be fixed by d558b483d5a,
>> which computes the end of the bridge window using _MAX rather than _LEN.
>>
>> See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
>> similar to the one above: we originally thought the window was
>> [mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
>> [mem 0xcff00000-0xfebfffff], which matches what Windows found.
>>
>> Yinghai, can you take a look at your AMD system again with a kernel that
>> includes d558b483d5a, and see whether we still have a problem?  If we
>> *do* still have a problem, please open a bugzilla and attach a dmesg log
>> with ACPI resource info collected with the debug patch here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
>>
>> Bjorn
>>
>>     
>
>   

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

On Wednesday 28 April 2010 11:14:45 am Yinghai Lu wrote:
> Never mind, for 2.6.34 your patch should be good enough.

Uh, OK.

I'm not trying to be a nuisance, but if there's a machine where
we think there's a bridge window like [mem 0xfed20000-0xffffffff],
I want to fix it, even if you think it's "good enough for 2.6.34."

I was hoping you could specifically confirm that "yes, that AMD
machine was fixed by d558b483d5a," or else give me some more
information that would help me figure out what's going on.

Bjorn

> On 04/28/2010 09:07 AM, Bjorn Helgaas wrote:
> > Yinghai, ping, do you have any more information about this?
> >
> > On Tuesday 27 April 2010 09:11:10 am Bjorn Helgaas wrote:
> >   
> >> On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
> >> But let's double-check this:
> >>
> >>     
> >>> also find one AMD system:
> >>> [    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> >>> ...
> >>> pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
> >>>       
> >> I agree, it's very unlikely that it's safe to put PCI devices all the
> >> way up to 0xffffffff.  I suspect this might be fixed by d558b483d5a,
> >> which computes the end of the bridge window using _MAX rather than _LEN.
> >>
> >> See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
> >> similar to the one above: we originally thought the window was
> >> [mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
> >> [mem 0xcff00000-0xfebfffff], which matches what Windows found.
> >>
> >> Yinghai, can you take a look at your AMD system again with a kernel that
> >> includes d558b483d5a, and see whether we still have a problem?  If we
> >> *do* still have a problem, please open a bugzilla and attach a dmesg log
> >> with ACPI resource info collected with the debug patch here:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
> >>
> >> Bjorn
> >>
> >>     
> >
> >   
> 
> 

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Yinghai]

On 04/28/2010 12:06 PM, Bjorn Helgaas wrote:
> On Wednesday 28 April 2010 11:14:45 am Yinghai Lu wrote:
>> Never mind, for 2.6.34 your patch should be good enough.
> 
> Uh, OK.
> 
> I'm not trying to be a nuisance, but if there's a machine where
> we think there's a bridge window like [mem 0xfed20000-0xffffffff],
> I want to fix it, even if you think it's "good enough for 2.6.34."
> 
> I was hoping you could specifically confirm that "yes, that AMD
> machine was fixed by d558b483d5a," or else give me some more
> information that would help me figure out what's going on.


[    0.000000]  BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
[    0.000000]  BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
[    0.000000]  BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
[    0.000000]  BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000008028000000 (usable)

[    6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
[    7.023528] pci_root PNP0A03:00: host bridge window [io  0x0000-0x03af]
[    7.024014] pci_root PNP0A03:00: host bridge window [io  0x03b0-0x03bb]
[    7.028005] pci_root PNP0A03:00: host bridge window [io  0x03bc-0x03bf]
[    7.032005] pci_root PNP0A03:00: host bridge window [io  0x03c0-0x03df]
[    7.036005] pci_root PNP0A03:00: host bridge window [io  0x03e0-0xefff]
[    7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
[    7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
[    7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
[    7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]


d7ff0000-efffffff : reserved
  d8000000-e7ffffff : PCI Bus 0000:00
    d8000000-dfffffff : GART
  e8000000-efffffff : PCI Bus 0000:80
fec00000-fed0ffff : PCI Bus 0000:00
  fec00000-fec00fff : reserved
    fec00000-fec003ff : IOAPIC 0
  fed00000-fed003ff : HPET 0
fed10000-fed1ffff : PCI Bus 0000:80
fed20000-ffffffff : PCI Bus 0000:00
  fee00000-fee00fff : Local APIC
    fee00000-fee00fff : reserved
  fefff000-feffffff : pnp 00:0a
  ff700000-ffffffff : reserved
    ffb80000-fffffffe : pnp 00:06

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[Bjorn Helgaas]

On Wednesday 28 April 2010 01:10:34 pm Yinghai wrote:
> On 04/28/2010 12:06 PM, Bjorn Helgaas wrote:
> > On Wednesday 28 April 2010 11:14:45 am Yinghai Lu wrote:
> >> Never mind, for 2.6.34 your patch should be good enough.
> > 
> > Uh, OK.
> > 
> > I'm not trying to be a nuisance, but if there's a machine where
> > we think there's a bridge window like [mem 0xfed20000-0xffffffff],
> > I want to fix it, even if you think it's "good enough for 2.6.34."
> > 
> > I was hoping you could specifically confirm that "yes, that AMD
> > machine was fixed by d558b483d5a," or else give me some more
> > information that would help me figure out what's going on.

I can see this is going nowhere.  The information below is essentially
just what you already posted, and I'm sorry, but it's not enough for
me to fix anything.  Can you tell me the model and BIOS version?  Maybe
I can find another one somewhere and do my own poking around.

What I'd like to know is (a) what Windows reports as PCI bus resources,
and (b) what the Linux dmesg looks like with the patch here:
    https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
CONFIG_ACPI_DEBUG=y and the arguments "acpi.debug_level=0x00010000
acpi.debug_layer=0x00000100".

Bjorn

> [    0.000000]  BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
> [    0.000000]  BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
> [    0.000000]  BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000008028000000 (usable)
> 
> [    6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [    6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
> [    7.023528] pci_root PNP0A03:00: host bridge window [io  0x0000-0x03af]
> [    7.024014] pci_root PNP0A03:00: host bridge window [io  0x03b0-0x03bb]
> [    7.028005] pci_root PNP0A03:00: host bridge window [io  0x03bc-0x03bf]
> [    7.032005] pci_root PNP0A03:00: host bridge window [io  0x03c0-0x03df]
> [    7.036005] pci_root PNP0A03:00: host bridge window [io  0x03e0-0xefff]
> [    7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
> [    7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
> [    7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
> [    7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
> [    7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> 
> 
> d7ff0000-efffffff : reserved
>   d8000000-e7ffffff : PCI Bus 0000:00
>     d8000000-dfffffff : GART
>   e8000000-efffffff : PCI Bus 0000:80
> fec00000-fed0ffff : PCI Bus 0000:00
>   fec00000-fec00fff : reserved
>     fec00000-fec003ff : IOAPIC 0
>   fed00000-fed003ff : HPET 0
> fed10000-fed1ffff : PCI Bus 0000:80
> fed20000-ffffffff : PCI Bus 0000:00
>   fee00000-fee00fff : Local APIC
>     fee00000-fee00fff : reserved
>   fefff000-feffffff : pnp 00:0a
>   ff700000-ffffffff : reserved
>     ffb80000-fffffffe : pnp 00:06
> 
> 

Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END

[H. Peter Anvin]

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

The 1 MB range is only one case of a prereserved space.  It's special only in the sense that it is *always* reserved, even if the map doesn't mark it as such.  Fixed (or SMM-used) resources in reserved space above 1 MB are exactly the same issue.

"Jesse Barnes" <jbarnes@virtuousgeek.org> wrote:

>On Mon, 26 Apr 2010 18:27:27 -0700 (PDT)
>Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> 
>> 
>> On Mon, 26 Apr 2010, Jesse Barnes wrote:
>> > 
>> > Glad we agree.  As I said (and echoing Bjorn), I think it would be best
>> > to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
>> > We want and need to do allocations from the special region, so we
>> > should mark it as such.
>> 
>> I think Bjorn's patch to pcibios_align_resource() is really good and 
>> clever, and I think it should take care of the need for IORESOURCE_BUSY, 
>> no? We do want to let devices that are _already_ allocated there insert 
>> their resources, it's just that we never want to allocate new ones in the 
>> low 1M region.
>> 
>> Do we actually have a regression left with Bjorn's patch?
>
>No, I think we're covered.  But it sounded like Peter was also
>concerned about making new allocations from the 1M space, which would
>mean we'd need something other than the IORESOURCE_BUSY bit.  But maybe
>Bjorn's patch plus simply removing the IORESOURCE_BUSY line is
>sufficient for that.  The downside there is that it doesn't clearly
>communicate the special nature of the 1M region.
>
>-- 
>Jesse Barnes, Intel Open Source Technology Center

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.