I've seen the following problem after shutting down. I have an AMD K6-2/350 based computer in an InWin A500 case with a Soyo 5EMA "super 7" motherboard, 128MB of pc100 RAM, 10.1 GB Hard Drive (EIDE), a root "/" partition of ~ 300MB, a "/usr" partition of ~ 1200MB, a "/home" partition of ~ 650 MB, and a swap partition of 133 MB. I have power management enabled in my BIOS (Award Modular BIOS v4.51PG, motherboard flash version: EMA-1BD1), and the computer is able to be powered down automatically by Windows 98, which I also have installed. I currently have an open incident, #990521-0068, but was told to submit a bug report, which I am now doing ... Here is what is reported on my screen (verbatim, except for leading dashes): ------------------------------------------------------------ [root@fiend /root]# shutdown -h now INIT: Switching to runlevel: 0 Broadcast message from root (tty1) Sun May 9 14:20:15 1999... The system is going down for system halt NOW !! INIT: Sending processes the TERM signal Shutting down X Font Server: [ OK ] Stopping gpm [ OK ] Shutting down http: [ OK ] Stopping sound [ OK ] Shutting down NFS services: [ OK ] Shutting down NFS mountd: [ OK ] Shutting down NFS daemon: nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: terminating on signal 9 nfsd: last server exiting [ OK ] Shutting down NFS quotas: [ OK ] Shutting down NFS statd: [ OK ] Shutting down sendmail: [ OK ] Stopping INET services: [ OK ] Stopping at daemon: [ OK ] Stopping cron daemon: [ OK ] Shutting down lpd: [ OK ] Saving random seed: [ OK ] Stopping portmap services: [ OK ] Shutting down interface eth0: [ OK ] Disabling IPv4 packet forwarding [ OK ] Shutting down APM daemon: [ OK ] Shutting down kernel logger: [ OK ] Shutting down system logger: [ OK ] INIT: no more processes left in this runlevel [ OK ] Sending all processes the KILL signal.. md: recovery thread got woken up ... md: recovery thread finished ... mdrecoveryd(5) flushing signals. [ OK ] Turning off swap and accounting [ OK ] Unmounting file systems [ OK ] The system is halted stopping all md devices. Power down. general protection fault: f000 CPU: 0 EIP: 0050:[<00008875>] EFLAGS: 00010046 eax: 00005301 ebx: 00000001 ecx: 00000000 edx: 00000000 esi: bfff8146 edi: fee1dead ebp: 67890000 esp: c7cebe14 ds: 0058 es: 0000 ss: 0018 Process halt (pid: 965, process nr: 11, stackpage=c7ceb000) Stack: 0000bfff be2e6789 0001c7ce 00000000 00030000 53070000 00000000 00000000 81350058 810afee5 000080dd 00160000 00488036 c7cebfbc c010719d 00000010 c7cebfbc fee1dead 00000018 00000018 00000000 bffffee5 fee1dead 00000282 Call Trace: [<c010719d>] [<c0107290>] [<c01072b3>] [<c01072d1>] [<c0107fb9>] [<c 0113bb7>] [<c01d032a>] [<c014d777>] [<c802f5a0>] [<c010f335>] [<c010f550>] [<c010fc17>] [<c012f5 33>] [<c01240fe>] [<c012519b>] [<c01251be>] [<c01109a7>] [<c01095a8>] Code: <1>Unable to handle kernel paging request at virtual address 00008875 current->tss.cr3 = 07ce9000, %cr3 = 07ce9000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c0109a09>] EFLAGS: 00010046 eax: 00000000 ebx: 00000000 ecx: 00008875 edx: 00000001 esi: 0000002b edi: c7cec000 ebp: c8000000 esp: c7cebd64 ds: 0018 es: 0018 ss: 0018 Process halt (pid: 965, process nr: 11, stackpage=c7ceb000) Stack: fee1dead 67890000 c0228d62 bfff8146 fee1dead 67890000 00005301 00000001 00000000 00000000 00008875 00010046 07ff0000 c8800000 c0109a6c c7cebdd8 c01ce898 c01ce96d 0000f000 c7cebdd8 c0109f70 c01ce96d c7cebdd8 0000f000 Call Trace: [<c8800000>] [<c0109a6c>] [<c01ce898>] [<c01ce96d>] [<c0109f70>] [<c 01ce96d>] [<c01096ad>] [<c010719d>] [<c0107290>] [<c01072b3>] [<c01072d1>] [<c0107fb9>] [<c0113b b7>] [<c01d032a>] [<c014d777>] [<c802f5a0>] [<c010f335>] [<c010f550>] [<c010fc17>] [<c012f533>] [<c01240 fe>] [<c012519b>] [<c01251be>] [<c01109a7>] [<c01095a8>] Code: 8a 04 0b 89 44 24 38 50 68 90 e8 1c c0 e8 6d 99 00 00 83 c4
Um, could you please reply to this message with the file attached? Decoding the en-of-line wrapping and de-htmlising is very difficultto do accurately with a kernel oops ... Thanks. If you do that, here's what I'm gonna do with the file you send me: After making sure that I have the right kernel rpms installed, I'm going to do cd /usr/src/linux/scripts/ksymoops make ksymoops [some flags] < oops_file and examine the output. There is a README in that directory that explains many of the details of decoding a kernel oops. In fact, if the oops is actually in /var/log/messages, you should be able to do /usr/src/linux/scripts/ksymoops/ksymoops < /var/log/messages Thanks.
*** Bug 3009 has been marked as a duplicate of this bug. *** A strange screen appears just before the system shuts down. This appears to be a dump of registers and/or memory. If someone would tell me how to capture this (it seems to be more than one screen full.) I will be happy to pass it on. This is an HP Series 4 5/133 with 48MB of memory. The output of first few lines of dmesg. Linux version 2.2.5-15 (root.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Apr 19 22:21:09 EDT 1999 Detected 132633208 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 52.84 BogoMIPS Memory: 46920k/49152k available (996k kernel code, 412k reserved, 764k data, 60k init) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium 75 - 200 stepping 0b Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Intel Pentium with F0 0F bug - workaround enabled. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xf70dc ------- Additional Comments From jturner 05/24/99 14:23 ------- Really need more information about this in order to determine what is happening with the system. Please try to post the dump that you are getting. ------- Additional Comments From atd7 05/24/99 16:11 ------- How would we capture the kernel dump? I'm experiencing the same bug. I don't consider it too serious, as it happens when the system would normally be halted anyway. It occurs in stock RedHat kernels for both 5.9 and 6.0. Kernels that I compile myself have absolutely no problems. ------- Email Received From Chaim Frenkel <chaimf> 05/24/99 17:01 ------- ------- Additional Comments From rbrown 05/27/99 09:53 ------- I have 2 boxes at home--one does this, the other doesn't. On the good one, the output of halt is this (not verbatim, sorry): INIT: changing runlevel.. Shutting down ____ (repeats a lot) The System is halted. Power down (there's some new-to-2.2 "md_* awoken" messages in there, too) On the bad system, it's the same until the last two lines: The System is halted Kernel Page Fault ... blah blah blah.. oops... blah blah... So, AFAIK, the net effect is that instead of getting a single line "Power Down", I get 2 pages of kernel error messages. Pretty innocuous, but interesting (and ugly).
The 0x0050: in the crash is a giveaway. This is a BIOS APM flaw. Win98 uses 16bit bios to do APM shutdown, we use 32bit. Several biosen have buggy 32bit shutdowns although vendors are fixing them on the whole. Ask the vendor for a BIOS upgrade if this worries you. Alan
Err, Is there a way to avoid the call? The machine that has the problem is not fully under my control. I can run the OS but not actually upgrade the bios. And how did the OOPS get captured?
Try recompiling a kernel and turning off CONFIG_APM.