Prev: 2.6.34-rc3-git6: Reported regressions from 2.6.33
Next: [PATCH 02/11] ARM: MMCI: pass max frequency from platform
From: Yinghai on 7 Apr 2010 19:00
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
--
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 7 Apr 2010 19:30
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
--
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 7 Apr 2010 19:50
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

--
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 8 Apr 2010 00:50
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.

--
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 8 Apr 2010 01:10
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.

--
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/
 |  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