Bug 9645 - Unrecoverable Oops from APM Resume on TI Extensa 670CDT
Unrecoverable Oops from APM Resume on TI Extensa 670CDT
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Depends On:
  Show dependency treegraph
Reported: 2000-02-21 11:15 EST by extensa
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-21 11:15:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description extensa 2000-02-21 11:15:40 EST

* Resume after Suspend results in an unrecoverable Oops.

* Standby works rather well.

* Details:

My laptop is a TI Extensa 670CDT, running an upgraded version of RH6.1,
using kernel 2.2.13.  Standby (apm -S) works flawlessly, but when I Resume
after a Suspend (apm -s), the machine locks up and gives an Oops message.
This is especially problematic, since the machine goes into Suspend mode
when you close the lid, or push one of the "hotkeys".

* I copied the following Oops from the screen after it locked on Resume:

Code: <1>Unable to handle kernel NULL pointer dereference at virtual
address 00000000
current->tss.cr3 = 03a63000, %cr3 = 03a63000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c010a2b1>]
EFLAGS: 00010046
eax: 00000000   ebx: 00000000   ecx: 00000000   edx: c338a000
esi: 0000002b   edi: c3a54000   ebp: c4800000   esp: c3a53e40
ds: 0018   es: 0018   ss: 0018
Process apmd (pid: 153, process nr: 11, stackpage=c3a53000)
Stack: c3a52000 c3a53f08 c0215f8e 00004102 0000687d c3a53f08 0000000e
       00000002 00000000 00000000 00010046 04000000 c5000000 c010a314
       c01b96f8 c01bad0e 00000000 00000000 c010f354 c01bad0e c3a53ec4
Call Trace: [<c5000000>] [<c010a314>] [<c01b96f8>]
[<c010f354>] [<c01bad0e>] [<c0109f55>]
       [<c01078f9>] [<c01079ec>] [<c0107a0f>]
[<c0107e1b>] [<c010840f>]
[<c012e7e9>] [<c0109e50>]
Code: 8a 04 0b 89 44 24 38 50 68 f0 96 1b c0 e8 71 9b 00 00 83 c4

* I ran this through ksymoops:
>>EIP; c010a2b1 <error_code+21/34>   <=====
Trace; c5000000 <END_OF_CODE+7a0bd0/????>
Trace; c010a314 <debug+8/c>
Trace; c01b96f8 <scsi_old_done+21c/578>
Trace; c01bad0e <rw_intr+32/714>
Trace; c010f354 <show_mem+4/108>
Trace; c01bad0e <rw_intr+32/714>
Trace; c0109f55 <do_signal+89/268>
Trace; c01078f9 <apm_bios_call+39/7c>
Trace; c01079ec <apm_get_event+14/68>
Trace; c0107a0f <apm_get_event+37/68>
Trace; c0107e1b <standby+7/24>
Trace; c010840f <do_release+47/b4>
Trace; c012e7e9 <sys_link+59/194>
Trace; c0109e50 <handle_signal+68/e4>
Code;  c010a2b1 <error_code+21/34>
00000000 <_EIP>:
Code;  c010a2b1 <error_code+21/34>   <=====
   0:   8a 04 0b                  movb   (%ebx,%ecx,1),%al   <=====
Code;  c010a2b4 <error_code+24/34>
   3:   89 44 24 38               movl   %eax,0x38(%esp,1)
Code;  c010a2b8 <error_code+28/34>
   7:   50                        pushl  %eax
Code;  c010a2b9 <error_code+29/34>
   8:   68 f0 96 1b c0            pushl  $0xc01b96f0
Code;  c010a2be <error_code+2e/34>
   d:   e8 71 9b 00 00            call   9b83 <_EIP+0x9b83> c0113e34
Code;  c010a2c3 <error_code+33/34>
  12:   83 c4 00                  addl   $0x0,%esp

Comment 1 Alan Cox 2000-08-08 15:50:33 EDT
This appears to be a BIOS issue

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