Re: unpredictable crashes, lock up, freezes, whatever
> Olaf Meeuwissen <olaf@epkowa.co.jp> writes:
>
> Yup, following up on my own post! Please bear along with the long
> quotes. I left them in because I'm now also cross-posting this to
> debian-laptop.
>
[some trimming]
> > > Look for power-change events under apmd.
> >
> > I doubt that has anything to do with it because the machine is on AC
> > 99% of the time. [Goes checking the logs now ...] No correlation
> > between power change events and crash times.
Olaf:
> Okay, so I compiled a kernel without any APM support, installed and
> tried it. My system froze within half an hour :-(
You must compile with one of the two flavors of power management, or else
there will be hardware interrupts that *will* happen, that the kernel will
not have any awareness of, and eventually, something bad will probably
happen.
I've only encountered one laptop BIOS where this wasn't so, and sad to say,
the combination of the asian money crisis and Phoenix killed that company
off.
You can try ACPI - under which some newer systems are frankly much better
behaved, but Linux is not capable of most power management features, or
checking the battery life, in that mode (because userland is barely there
and almost none of the kernel device drivers for misc. things like hard
drives know about the ACPI sleep levels yet). However it may help anyway
because your manufacturer may have bothered to *test* ACPI works - that's
what MSwin uses these days.
> > > > Because I haven't experienced any lock up when using the console, I'm
> > > > wondering if my graphics card (probed as Neomagic NM2200 according to
> > > > XFree86 log, NeoMagic MagicMedia 256AV according to hardware spec) ...
> > >
> > > Possible, but the card's pretty well supported in recent XF86 v.3 and
> > > v.4 drivers.
I believe, but am not sure, that the original "neomagic specific" X server
is still out there, and you could try it. You might have to raid the
complete X setup from an older distro in order to try it if you want to go
that far.
> > > It's not clear how long you're leaving your system in console mode...
> >
> > Sorry, should have mentioned that; somewhere around 5, 6 hours. ...
> Left if sitting at the console and gdm login prompts overnight as
> well. No crash. Bad news is that as soon as I logged in through
> gdm, my machine froze. Actually, it locked up three times in ten
> minutes or so :-(
Interesting, that makes it hard to tell if Gnome, gdm itself, or X is
the problem.
I know it's weird but you could just run 'X' - which should get you the
server, no window manager, and no clients, and see if it lives. Even
leave it that way a while and see if it eventually barfs out on you.
If you want to test Xserver activity, move the mouse.
> > > You might isolate video card issues by running in console mode, by
> > > switching to a version 3 XF86 driver, or by switching from an
> > > accelerated driver to SVGA or VGA16.
> >
> > I've been thinking about running X on the frame buffer device myself.
One machine, an ASUS 8400, had stability problems (symptom: console-mode
screen goes streaky if you switch back and forth twixt console and X too
much) which framebuffer solved. Specifically, some sort of mode switch
reset was performed better by the fb.
If that's what you turn out to need, then it may help.
> 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 ;-)
>
> 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.
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...
Good luck
* Heather Stern * star@ many places...
Reply to: