Bug 3100 - general protection fault after shutdown
Summary: general protection fault after shutdown
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
: 3009 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-05-27 19:12 UTC by tbarraza
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-06-14 15:54:17 UTC

Attachments (Terms of Use)

Description tbarraza 1999-05-27 19:12:50 UTC
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

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:
esi: bfff8146   edi: fee1dead   ebp: 67890000   esp:
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:
esi: 0000002b   edi: c7cec000   ebp: c8000000   esp:
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

Comment 1 Jeff Johnson 1999-06-05 17:48:59 UTC
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
	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


Comment 2 Jeff Johnson 1999-06-05 17:50:59 UTC
*** 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

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

------- 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).

Comment 3 Alan Cox 1999-06-12 13:20:59 UTC
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

Ask the vendor for a BIOS upgrade if this worries you.


Comment 4 Chaim Frenkel 1999-06-13 16:34:59 UTC
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?

Comment 5 Jeff Johnson 1999-06-14 15:54:59 UTC
Try recompiling a kernel and turning off CONFIG_APM.

Note You need to log in before you can comment on or make changes to this bug.