unbootable kernel 188.8.131.52
sfaulborn at web.de
Tue Apr 25 13:22:35 PDT 2006
>Declan Moriarty wrote:
>> Recently, Somebody Somewhere wrote these words
>>> Console: switching to colour frame buffer device 160x64
>>> fb0: VESA VGA frame buffer device
>>> Unable to handle kernel NULL pointer dereference at virtual
>>> address 00000000
>> Are we running a vesa mode lcd here? That is a WEIRD video mode to
>> order and I doubt personally if vesa went there. The smallest I
>> heard of was 320x200, and afair that was a graphics mode only.
>> Text looked terrible.
<> If there's some weird driver, mebbe we ought to know about it.
>pda stuff does that resolution
a) The resolution of the vesa driver is here 1280x1024 in true color
("vesafb: mode is 1280x1024x32, linelength=5120, pages=0") - which
is perfect for X-Windows and allows you to use high graphics resolution
without bothering to setup any graphics driver (handy if your brand
new laptop is not supported by the current kernel or for a live cd).
Also VESA is not a strange mode - it was originally the only graphics
mode available on most UNIX workstations.
b) I believe this slightly misleading line is talking about the charcters per
line of the console. So there are 160 characters and 64 lines
("Console: switching to colour frame buffer device 160x64").
c) The text looks great in this mode. You never want to use console in the
default mode again (use in grub vga=0x31B for 1280x1024 and vga=0x318 for
1024x768 and compile in generic framebuffer/vesa support).
d) The framebuffer device and the console have nothing to do with the problem
of the kernel panic. It also happens with the default VGA driver and the ugly
60x25 characters or whatever the default is. It just panics at some later point.
It seems that the problem arises when frandom initialises itself with the kernel
([<c0250c3d>] frandom_init_module+0x10d/0x185). Thats where there is the difference
between the old and the current patch. I have frandom compiled into the kernel.
Maybe somebody who knows a bit more about kernel programming could have a look at
Also: are other people having the same problems? Do the solutions I suggested work
for others? It would be nice to know how stable the 184.108.40.206 kernel actually is
before I install it on our production servers.
More information about the hlfs-dev