On Wed, 4 Apr 2001, Boris Pisarcik wrote:
> I looked a bit at the source of sysrq handling. I've found there is
> rather big difference between sysrq+b and other killers handling.
> Sysrq+b is just called with pretty straitforward fashion - stops other
> processors on SMP and reboots directly (hardware impulse or triple fault)
> or through the bios - so it just calls for the corruptions.
ah, that would explain it...
> On the other side sysrq+s marks a single variable, which will be tested
> next cycle in the bdflush kernel threads' main loop, and adds bdflush to
> scheduler runqueue list. So it gets possibility to check for emergency
> sync onle when gets next scheduled. Does it ?
>
> Can you anyhow find something in your logs/console/serial console messages
> like 13.13.2000 kernel : Sysrq: Emergency Sync (this should be present - is
> written within keyboard handler, not after shedule) and what's next logs ?
> We could determine, if the bdflush thread got scheduled and called emergency
> syncing routine indeed.
Nope, there was nothing in the logs.
> As you wrote no of your processes does respond - probably telnet will
> not help. You may try to write experimental programme, that only log
> say current time every n seconds, and see, if it just stopped to
> log messages after lockup-time. If not - it doesn't get scheduled.
> If continues - there's problem with syncing. Again - try, as far
> as i understand, log kernel messages to serial console or alike, because
> the messages should not get written to logfiles - syslogd can't be woken up
> eg.
Telnet's disabled anyways :) Cleartext passwords SUCK. :)
I've got a nifty LCD thingy I can hook up to the serial port and use as a
console if need be.
> Quick help against those corruptions, which comes on my mind, is use
> the reiserfs. I have no real experiences with that and its reliability,
> also as aj followed some of messages in this list about resierfs - it has
> some problems too - but in definition it shoudn't get corrupted by not-
> syncing reboot. But i see this not much helpfull ,cause if you really
> would depend on big reliability, you wouldn't intall 2.3.x-pre kernel :)
I'm not about to convert my filesystems over... It's too much a hassle for
little gain. ext2 is faster anyways, IIRC.
The problem disappeared when I installed 2.4.3 release; I think it was a
DRM issue in the kernel that was causing the lockups
Thanks for the help though
Kelsey Hudson khudson@ctica.com
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:19 EST