Olaf Meeuwissen <[EMAIL PROTECTED]> writes: > Heather <[EMAIL PROTECTED]> writes: > > > Olaf Meeuwissen <[EMAIL PROTECTED]> writes: > > > > > This morning, after three lock ups in ten minutes, I compiled > > > frame buffer support in, fiddled my XF86Config-4 to use it and > > > I've been up for 5(!) hours. I think I'll lock my session with > > > xscreensaver (to guarantee some Xserver activity (eh, at least > > > until APM kicks in and blanks the screen)) before I go home and if > > > my machine hasn't crashed by tomorrow morning I'm ready to believe > > > my problem is fixed. I might even get bold and start using that > > > broken DIMM again ;-) > > APM didn't kick in last night it seems. The screensaver was running > happily when I came in this morning. Removed the lock and my session > was still very much alive (left stripchart running). As a matter of > fact I'm typing this mail from a 21 hour old session. I'd say that > even if my problem may not be fixed, I've got myself an acceptable > work around. Using the framebuffer is only a bit slower.
I had my session going for close to 48 hours (20 hours of XFree86 CPU time) without a hitch until I made the mistake of firing up Konqueror (kdeinit gobbled up all memory ;-). Anyway, I stuck that broken DIMM back in an haven't seen any hiccups yet. > > > Problem then is where to put the blame: graphics card or X driver? > > > I'm using xserver-xfree86 4.0.3-4. > > > > Try tuning up SVGAlib to see if that also freaks out the system. If > > it works at all it will be under "VESA" or "Standard VGA". If it > > breaks too then two things remain. > > Not quite sure whether I get what you're saying, but I'll keep this in > mind for when I get oodles of free time (or my boss' blessing :-) to > get to the bottom of this. > > > 1. the modeline. SVGAlib uses XF86 style modelines too. Monitor being > > pushed just barely out of spec could be doing something unknown and > > invisible. To test that, reduce the freq range for your monitor > > values in X's config then try again, so you get new modelines. > > > > 2. yeah, your card could be bad... I was going to blame it on the graphics card until I had a look at http://www.xfree86.org/pipermail/neomagic/. There are some reports that show very similar behaviour as to what I saw but all those folks could still telnet to their machine. Mine didn't even return pings. So, I'm still not sure where to put the blame ;-( At least the frame buffer solutions works and with the extra memory back I hardly notice the performance difference. FWIW, I'll include the frame buffer settings: I compiled the kernel (2.2.19) with CONFIG_FB=y # CONFIG_FB_PM2 is not set # CONFIG_FB_ATY is not set CONFIG_FB_VESA=y CONFIG_FB_VGA16=y # CONFIG_FB_MATROX is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FBCON_ADVANCED is not set CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_VGA_PLANES=y # CONFIG_FBCON_FONTWIDTH8_ONLY is not set # CONFIG_FBCON_FONTS is not set To /etc/X11/XF86Config-4 I added Section "Device" Identifier "Linux Frame Buffer" Driver "fbdev" EndSection changed the Device setting in the Screen section to match this and commented the DefaultDepth out. I also added SubSection "Display" Depth 32 Modes "1024x768-76" EndSubSection In /etc/lilo.conf I set vga=ask and whenever I boot I enter 318 (have not bothered hard wiring this yet). I really like the huge console that gives me! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!'
