Oops on wakeup from susepnd to disk in 2.2.10

David Kastrup (dak@neuroinformatik.ruhr-uni-bochum.de)
Sun, 20 Jun 1999 15:54:17 +0200


Suspend to disk has worked in 2.2.7 with very similar options. Now
after wakeup, after about 1 or 2 seconds or any activity, I get a
kernel panic on my Medion Notebook (an OEM Maxdata Green753, I
believe).

Here is the Oops:
Options used: -V (default)
-o /lib/modules/2.2.10/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /usr/src/linux/System.map (default)
-c 1 (default)

You did not tell me where to find symbol information. I will assume
that the log matches the kernel and modules that are running right now
and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c010fc7e>]
EFLAGS: 00010282
eax: 00000018 ebx: c01b6000 ecx: 0000009e edx: ffffff9d
esi: 00000000 edi: c1ca6834 ebp: c01b7e4c esp: c01b7e38
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c01b7000)
Stack: 00008e2c c1ca6834 c176386c 00000286 c01b7e60 c01b7e74 c010f9ec c01b7e60
00000420 c1763800 00000000 c01a7b74 00008e2c c01b6000 c010f648 c01b7eb8
c283fb25 c1763800 00000001 00000400 00000001 c1723100 0000002b c000d600
Call Trace: [<c010f9ec>] [<c010f648>] [<c283fb25>] [<c2840777>] [<c2855dc8>] [<c283e676>] [<c283e5c0>]
[<c283e564>] [<c01108cd>] [<c0116b91>] [<c0109a23>] [<c01088e4>] [<c0107109>] [<c0106000>] [<c010712c>]
[<c0108848>] [<c0106000>] [<c010607b>] [<c0106000>] [<c0100176>]
Code: c7 05 00 00 00 00 00 00 00 00 8d 65 e8 5b 5e 5f 89 ec 5d c3

>>EIP: c010fc7e <schedule+26a/280>
Trace: c010f9ec <schedule_timeout+6c/8c>
Trace: c010f648 <process_timeout+0/10>
Trace: c283fb25 <request_configuration+1d5/400>
Trace: c2840777 <CardServices+1ff/2f4>
Trace: c2855dc8 <NS8390_module+2728/????>
Trace: c283e676 <send_event+2e/44>
Trace: c283e5c0 <unreset_socket+5c/e4>
Trace: c283e564 <unreset_socket+0/e4>
Trace: c0108848 <system_call+34/38>
Code: c010fc7e <schedule+26a/280> 00000000 <_EIP>: <===
Code: c010fc7e <schedule+26a/280> 0: c7 05 00 00 00 00 00 movl $0x0,0x0 <===
Code: c010fc85 <schedule+271/280> 7: 00 00 00
Code: c010fc88 <schedule+274/280> a: 8d 65 e8 leal 0xffffffe8(%ebp),%esp
Code: c010fc8b <schedule+277/280> d: 5b popl %ebx
Code: c010fc8c <schedule+278/280> e: 5e popl %esi
Code: c010fc8d <schedule+279/280> f: 5f popl %edi
Code: c010fc8e <schedule+27a/280> 10: 89 ec movl %ebp,%esp
Code: c010fc90 <schedule+27c/280> 12: 5d popl %ebp
Code: c010fc91 <schedule+27d/280> 13: c3 ret

Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task, not syncing

3 warnings issued. Results may not be reliable.

Ok, and here is my configuration (a few maybe relevant parts):
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_OPTIMIZE is not set
CONFIG_PCI_OLD_PROC=y

CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
CONFIG_APM_POWER_OFF=y
CONFIG_APM_IGNORE_MULTIPLE_SUSPEND=y
CONFIG_APM_IGNORE_SUSPEND_BOUNCE=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_APM_ALLOW_INTS=y

CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set

# CONFIG_BLK_DEV_CMD646 is not set

Also, the IDE controller (CMD646 type, seemingly) loses interrupts
from time to time. This problem has gotten worse in later kernels. I
have never in any 2.2.x kernel been able to enable the CMD646 support
marked "EXPERIMENTAL" without the kernel panicking at boot time. If
wanted, I can try to record a kernel oops for that to, but up to now
at least the usual CMD640 support worked more or less fine.

-- 
David Kastrup, Goethestr. 20, D-52064 Aachen
Email: David.Kastrup@neuroinformatik.ruhr-uni-bochum.de

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/