Prev: 2.6.34-rc3-git6: Reported regressions from 2.6.33
Next: [PATCH 02/11] ARM: MMCI: pass max frequency from platform
From: H. Peter Anvin on 9 Apr 2010 18:50
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 9 Apr 2010 19:00
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 9 Apr 2010 19:00
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 9 Apr 2010 19:10
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(a)kernel.org>
Cc: Guenter Roeck <guenter.roeck(a)ericsson.com>
Cc: Andy Isaacson <adi(a)hexapodia.org>
Cc: Bjorn Helgaas <bjorn.helgaas(a)hp.com>
Acked-by: H. Peter Anvin <hpa(a)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 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 9 Apr 2010 21:20
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(a)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 "
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: 2.6.34-rc3-git6: Reported regressions from 2.6.33
Next: [PATCH 02/11] ARM: MMCI: pass max frequency from platform