[lkml]   [2003]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.0-test8-mm1
On Mon, 20 Oct 2003 18:56:13 PDT, Andrew Morton said:

> Has anyone tried CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC, see if that
> turns anything up?

Well, I built two test kernels, which hopefully tell us something.. ;)

1) I did a 'patch -R' and backed out the two fbdev patches - and a -test8-mm1
with them removed boots and runs fine with a framebuffer console.

2) Kernel *with* fbdev patch, but no 'vga=794' parm at boot works OK as well. So
it can be in the kernel and not used, and works OK.

3) With fbdev patch and DEBUG_SLAB and DEBUG_PAGEALLOC, it got weird.
It booted semi-OK (sort of - some funkyness mounting filesystems) but suffered some
truly horrid bit-droppings as stuff scrolled. Basically, most character cells that were
"blank" had light grey in the top 2 pixes of the cell, and many non-blanks that didn't
have ascenders had them as well. Not all the pixels were the same grey, either..
Looks like the debugging changed the layout in memory enough for things to almost
work (so less stuff was getting overlaid and we lived longer?), but didn't catch any
memory corruption (or at least neither console nor 'dmesg' saw any messages).

I'm wondering if it's stomping on some memory because the vga=794
parameter tells it to use 1280x1024x16, when the underlying card is really 1600x1200x32?
(Yes, I know this means the vesa is using a small corner of the card's memory)...
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:58    [W:0.105 / U:0.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site