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
...
vesafb: framebuffer at 0xff000000, mapped to 0xc4080000, using 1875k, total 8192k
vesafb: mode is 800x600x16, linelength=1600, pages=7
vesafb: protected mode interface info at c7bd:0000
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 530/620
PCI/AGP VGA Display Adapter (rev a2) (prog-if 00 [VGA])
Subsystem: Silicon Integrated Systems [SiS] SiS530,620 GUI Accelerator+3D
Flags: bus master, 66MHz, medium devsel, latency 32
Memory at ff000000 (32-bit, prefetchable) [size=8M]
Memory at e7ef0000 (32-bit, non-prefetchable) [size=64K]
I/O ports at cc00 [size=128]
Capabilities: <available only to root>
In the non-working kernel, his dmesg has this:
PCI: Using IRQ router SIS [1039/0008] at 0000:00:01.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:02.0
PCI: Cannot allocate resource region 0 of device 0000:01:00.0
PCI: Ignore bogus resource 6 [0:0] of 0000:01:00.0
...
vesafb: framebuffer at 0xff000000, mapped to 0xc4080000, using 1875k, total
8192k
vesafb: mode is 800x600x16, linelength=1600, pages=7
vesafb: protected mode interface info at c7bd:0000
vesafb: pmi: set display start = c00c7c25, set palette = c00c7c99
vesafb: scrolling: ywrap using protected mode interface, yres_virtual=1200
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
Note the message "Cannot allocate resource region 0 of device 0000:01:00.0"
This is the framebuffer memory of his VGA controller.
His lspci reports:
0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]
530/620 PCI/AGP VGA Display Adapter (rev a2) (prog-if 00 [VGA])
Subsystem: Silicon Integrated Systems [SiS] SiS530,620 GUI Accelerator+3D
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 32 (500ns min)
Region 0: Memory at 10000000 (32-bit, prefetchable) [size=8M]
Region 1: Memory at e7ef0000 (32-bit, non-prefetchable) [size=64K]
Region 2: I/O ports at cc00 [size=128]
Capabilities: <available only to root>
In the non-working kernel, the addresses do not match:
"vesafb: framebuffer at 0xff000000"
vs
"Region 0: Memory at 10000000 (32-bit, prefetchable) [size=8M]"
He also tried hard-coding the address to 0x10000000 in vesafb.c, but he still
is not getting any display.
Any ideas?
Tony
PS: Please see http://bugzilla.kernel.org/show_bug.cgi?id=5769 for more details.
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.
Booting with "mem=64M" (or what amount of RAM he has) should fix that,
as it causes the kernel to ignore e820 entries above 64M.
Ivan.
Ivan Kokshaysky <[email protected]> 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?
Ivan Kokshaysky wrote:
> On Mon, Feb 20, 2006 at 08:51:15AM +0800, Antonino A. Daplas wrote:
> 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.
>
> Booting with "mem=64M" (or what amount of RAM he has) should fix that,
> as it causes the kernel to ignore e820 entries above 64M.
>
Ben reported that the mem= option worked for him. I presume that this
is the best solution for this problem?
Tony