Just had another nasty crash to top off the night (in addition to multiple SVGA server crashes when I move the mouse TOO EARLY after switching from console mode). Everything just fried itself, then I found this in the syslog: May 11 03:22:42 palantir kernel: Unable to handle kernel paging request at virtual address e90833c4 May 11 03:22:42 palantir kernel: current->tss.cr3 = 00299000, %cr3 = 00299000 May 11 03:22:42 palantir kernel: *pde = 00000000 May 11 03:22:42 palantir kernel: Oops: 0000 May 11 03:22:42 palantir kernel: CPU: 0 May 11 03:22:42 palantir kernel: EIP: 0010:[add_timer+257/348] May 11 03:22:42 palantir kernel: EFLAGS: 00010082 May 11 03:22:42 palantir kernel: eax: 00000000 ebx: 0026332c ecx: 00872f7c edx: 0000002d May 11 03:22:42 palantir kernel: esi: 00000206 edi: 0026332d ebp: 00872f5c esp: 00872f54 May 11 03:22:42 palantir kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 May 11 03:22:42 palantir kernel: Process WindowMaker (pid: 517, process nr: 32, stackpage=00872000) May 11 03:22:42 palantir kernel: Stack: 00d51810 0026332d 00872f90 001126cb 00872f7c 0026332d 00000000 00000001 May 11 03:22:42 palantir kernel: 0026332d 01264018 0293bebc 00000000 0026332d 00d51810 00112424 00872fb4 May 11 03:22:42 palantir kernel: 00113b47 00d51810 08081a57 0804c0a0 020c5550 0000541b 00000000 004c4b40 May 11 03:22:42 palantir kernel: Call Trace: [schedule+543/652] [process_timeout+0/128] [sys_nanosleep+271/348] [system_call+85/124] May 11 03:22:42 palantir kernel: Code: 00 89 48 04 89 0c 95 08 e6 19 00 8d 04 95 08 e6 19 00 89 41 May 11 03:22:42 palantir kernel: task not on run-queue Anyone understand what's up? Is it just a problem with the memory management of the 2.0.33 kernel? Maybe I should switch back to 2.0.32, or perhaps the new 2.0 kernel is out and is stable? This sucks. Bash crashed my whole system today too. NOT a good day. And to think, I was actually beginning to yearn for an uptime of over a week (I used to shut my computer off at night, but now I've got the rc5des client running nonstop, so...) ANY HELP APPRECIATED IN THE EXTREME. Thanks -- kiyan@iname.com A scientific truth does not triumph by convincing A. Kiyan Azarbar its opponents and making them see the light, but Ottawa, Canada rather because its opponents eventually die and a Linux 2.0.32 new generation grows up that is familiar with it. 1024/0x9A9EC5EA 4F3ADBDA1EE5850209DD8BB205250ED2F696A7BE ^- Max Planck
Attachment:
pgp0pI4I2T9O1.pgp
Description: PGP signature