Re: Bugzilla: PCI resource address mismatch

[Andrew Morton]

Ivan Kokshaysky <ink@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Feb 20, 2006 at 08:51:15AM +0800, Antonino A. Daplas wrote:
> > Ben Kibbey reported that vesafb has stopped working for him for kernels newer than
> > 2.6.12. His display is completely blanked. After a long debugging session, we noted
> > that the address of resource 0 of his VGA controller as reported by lspci does not
> > match what is reported by the BIOS.
> > 
> > More details:
> > 
> > In the working kernel (2.6.12.x), vesafb correctly ioremap's the framebuffer memory
> > located at 0xff000000.  lspci reports the same thing:
> > 
> > PCI: Using IRQ router SIS [1039/0008] at 0000:00:01.0
> > PCI: Cannot allocate resource region 9 of bridge 0000:00:02.0
> 
> There are two bogus entries in the BIOS memory map table which are
> conflicting with a prefetchable memory range of the AGP bridge:
> 
>  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
>  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> 
> 0000:00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode])
> 	Flags: bus master, fast devsel, latency 0
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: 0000c000-0000cfff
> 	Memory behind bridge: e7e00000-e7efffff
> 	Prefetchable memory behind bridge: fec00000-ffcfffff
> 					   ^^^^^^^^^^^^^^^^^
> 
> Starting from 2.6.13, kernel tries to resolve that sort of conflicts,
> so that prefetch window of the bridge and the framebuffer memory behind
> it get moved to 0x10000000.
> Unfortunately, video BIOS still expects the framebuffer to be at 0xff000000,
> that's why vesafb doesn't work.

Won't this always be a problem if we've moved the framebuffer?  Or is there
some way in whcih the kernel can communicate the new address to the BIOS,
but this BIOS isn't handling that right?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/