Bug 9645 - Unrecoverable Oops from APM Resume on TI Extensa 670CDT
Summary: Unrecoverable Oops from APM Resume on TI Extensa 670CDT
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-21 16:15 UTC by extensa
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-21 16:15:40 UTC
Embargoed:


Attachments (Terms of Use)

Description extensa 2000-02-21 16:15:40 UTC
Hi

* 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
00000001
       00000002 00000000 00000000 00010046 04000000 c5000000 c010a314
c3a53ec4
       c01b96f8 c01bad0e 00000000 00000000 c010f354 c01bad0e c3a53ec4
00000000
Call Trace: [<c5000000>] [<c010a314>] [<c01b96f8>]
[<c01bad0e>]
[<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
<do_fork+294/7e0>
Code;  c010a2c3 <error_code+33/34>
  12:   83 c4 00                  addl   $0x0,%esp


Thanks.

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



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