On Mon, Apr 24, 2000 at 01:06:40PM +0200, Thorsten Knabe wrote:
> >>EIP; c011dcf7 <access_process_vm+77/180> <=====
> Trace; c0155ae1 <proc_pid_cmdline+31/40>
> Trace; c0155f4e <proc_info_read+17e/320>
> Trace; c012f3ba <sys_read+ca/f0>
> Trace; c0109794 <system_call+34/40>
Almost exactly the same on my kernel (pre6-7), I also had this in pre6-5 and pre6-3.
Always Oops in access_process_vm and previous frame is from proc_pid_cmdline.
I can reproduce the problem but only on SMP (2xPII-550). On my home system with same
kernel but UP (1xPII-350) it does not crash.
> [6.] A small shell script or example program which triggers the
> problem (if possible)
> top, but hard to reproduce
So, technique: on the one console:
$ top -d0 # Yes, with _no_ delay.
Sure it will Oops even with -d1, but with -d0 it will do so quickly :)
On the another console:
$ find / -xdev -type f | xargs -n1 -P100 md5sum --
After short time (it depends) it will crash. BTW, after Oops it is nearly
impossible to shut system down, however it will function for some time.
One or several processes that are running will be impossible to kill,
and attempt just to 'cd /proc/<pid>' on some of processes will block the
process doing 'cd' (which also becomes unkillable).
SysRq does not help, the only Right Thing (tm) will be SysRq+U and SysRq+S.
NB: Hey, do not kick me - I've not enough time to find it out by myself,
but may be my info will help someone to find out this annoying bug :)
/Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:12 EST