Framebuffer drivers that break the boot on systemswithout the hardware

DISCUSSION Rene Herman 2 participants 4 messages Aug 9, 2008 – Aug 10, 2008 Framebuffer layer

lore

Share & tools

lore

Rene Herman

author

2008-08-09 20:15 UTC #0 lore raw

Hi Antonino.

At:

http://lkml.org/lkml/2008/8/1/96

Ingo Molnar posted a list of drivers he found to break the boot during testing of randconfig kernels and among them are a number of FB drivers:

FB_CIRRUS
FB_ASILIANT
FB_VGA16
FB_VESA
FB_RADEON
FB_CYBLA
(and FB_VIRTUAL)

Looking at some of them there wouldn't seem to be too many very sensible options to avoid this at the individual driver level. Would you perhaps have an idea how to avoid the issue generically for these?

More of the drivers in that list will be considered fine as is but I was fixing some of the old legacy ISA ones as ofcourse any driver not needing special avoidance treatment is one less to have to deal with.

The randconfig testing IS useful in finding bugs, so...

Rene.

Rene Herman

author

2008-08-09 20:33 UTC #1 lore raw

Quoted 5 lines · Rene Herman

At:
http://lkml.org/lkml/2008/8/1/96
Ingo Molnar posted a list of drivers he found to break the boot during testing of randconfig kernels [ ... ]

CONFIG_MDA_CONSOLE is weird. Is that one certain? To have that thing do anything other than <zilch> it seems to need RAM at 0xb0000 which not really anything other than an MDA/HGA should be puting there.

Then again, you also had VGA16FB among the breakers. Very decidedly non-legacy HW or something?

Rene.

Frans Pop

2008-08-09 21:20 UTC #2 lore raw

In reply to Rene Herman

Quoted 4 lines · Rene Herman

Ingo Molnar posted a list of drivers he found to break the boot during testing of randconfig kernels and among them are a number of FB drivers:
FB_VESA

This one is set to "y" in the kernel configs for the generic Debian kernels for i386 and x86_64 and is used by default for the graphical version of the Debian Installer, so I'd be very surprised if it broke very many systems...
AFAIK it is only actually enabled if the 'vga=' boot parameter is passed.

Ingo's mail also lists FRAMEBUFFER_CONSOLE which again is set to "y" in Debian's standard kernel configs for x86 (and probably most other arches).

Quoted 1 line

(and FB_VIRTUAL)

This one should be fixed with 2.6.27-rc1. The commit that fixes it is:
commit b604838ac6d233fd6bffc0e758a818133a01ff22
Author: Frans Pop <[email protected]>
Date: Wed Jul 23 21:31:26 2008 -0700
vfb: only enable if explicitly requested when compiled in

Cheers,
FJP

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Rene Herman

author

2008-08-10 21:48 UTC #3 lore raw

Quoted 13 lines · Frans Pop

Quoted 4 lines · Rene Herman
Ingo Molnar posted a list of drivers he found to break the boot during testing of randconfig kernels and among them are a number of FB drivers:
FB_VESA
This one is set to "y" in the kernel configs for the generic Debian kernels for i386 and x86_64 and is used by default for the graphical version of the Debian Installer, so I'd be very surprised if it broke very many systems...
AFAIK it is only actually enabled if the 'vga=' boot parameter is passed.

Quoted 3 lines

Ingo's mail also lists FRAMEBUFFER_CONSOLE which again is set to "y" in Debian's standard kernel configs for x86 (and probably most other arches).

Okay. MDA_CONSOLE was also in there impying RAM at 0xb0000 which might indicate a gun/foot situation here...

Quoted 7 lines

Quoted 1 line
(and FB_VIRTUAL)
This one should be fixed with 2.6.27-rc1. The commit that fixes it is:
commit b604838ac6d233fd6bffc0e758a818133a01ff22
Author: Frans Pop <[email protected]>
Date: Wed Jul 23 21:31:26 2008 -0700
vfb: only enable if explicitly requested when compiled in

Ah, thanks.

Rene.