From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: crash: 0.99p7A + emacs -> swapper killed! Date: Fri, 16 Apr 1993 07:19:53 GMT
In article <C5K3EC.2AA@fab4box.wa.com> root@fab4box.wa.com (Art Taylor) writes:
>In article <1993Apr14.173533.410@desaster.hanse.de> michaelw@desaster.hanse.de (Michael Will) writes:
>>Hello,
>>
>>I was just downloading my news with uucp, replied to a message with elm+emacs,
>>when suddenly my machine got killed in an unusual way.
>>
>>general protection: 6e70
>>EIP: 0008:00D152
>>EFLAGS: 00010002 int = 58 9a 37 2a a8 c6 0e 3e 3a c9 cf 40 46 08 b9 39
>>fs: 0017
>>base: C000000 limit: 00200000
>>Pid: 0, process No. 0
>>cf: 00 00 00 00 00 00 00 00
>>task[0] (swapper) killed: unable to recover
>>kernel panic: Trying to free up swapper memory space
>>in swapper task - not syncing
>>
>>The machine stopped - I had to reboot cold.
>
>Ok, I got the same response when dl'ing with UUCP(taylor 1.04), and scrolling
>up through a command buffer(up arrow, once in bash, once in ATP(.QWK packet
>offline reader).
It's a known bug (and a very silly one) in the 0.99.7A keyboard driver
routines. It happens mostly when the keyboard does auto-repeat on keys
that send multi-byte sequences (ie cursor keys and other special keys),
but depends a bit on the hardware as well (ie it won't happen on some
hardware, while being almost common on other).
>It would seem that UUCP is the common link here. I've only experienced this
>while running Taylor 1.04, and scrolling up. It's happened twice, and it
>shocked hell out of me both times.
It's the up-scrolling, and possibly the race-condition is made worse by
serial interrupts going on etc, which is why you see it during UUCP.
Others see it only under X11 (probably due to similar reasons), others
won't see it at all... The fix is to get pl8 (together with the vm86
diff if you use NFS or dosemu),
Linus