* kernel panic "killing interrupt handler" and kernel BUG at sched.c:468
@ 2002-09-30 12:13 Federico Sevilla III
2002-09-30 16:29 ` Federico Sevilla III
0 siblings, 1 reply; 2+ messages in thread
From: Federico Sevilla III @ 2002-09-30 12:13 UTC (permalink / raw)
To: Linux-XFS Mailing List, Linux Kernel Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2769 bytes --]
Hi everyone,
On our server that had been running for 55 days with this 2.4.19-xfs
kernel (XFS CVS snapshot 20020809 patched with RML's preempt patches for
2.4.19-rc3 and sys-magic 20020314 from Randy Dunlap, built using GCC
3.1.1 running Debian GNU/Linux), I hit a kernel panic in the process
running the distributed-net client. I had been running the
distributed-net client -- and everything else on the server -- with no
significant changes recently. The server wasn't under any significantly
different load, either.
I copied the oops by hand onto another computer and am attaching a
ksymoops output of that as kernel-panic.out. I rebooted and a few
minutes after all the initialization had completed I hit another kernel
panic, again because of the distributed-net client process. The oops
(passed through ksymoops) is attached as kernel-panic-2.out.
After copying the oops message, I attempted to sync the disks using the
(Alt + SysRq + S) key combination and after the sync messages I hit a
kernel BUG at sched.c:568. In my sched.c (different from the XFS tree
only because of RML's preempt patch) line 568 is in the "asmlinkage void
schedule(void)" function. The oops (passed through ksymoops) is attached
as kernel-bug.out.
Some other notes that may be significant to mention:
- system is an Intel Pentium III with 512MB RAM and a 3ware 6400 IDE
RAID controller,
- system has one small ext2 partition for /boot, one ReiserFS
partition for Squid cache, and 5 XFS partitions,
- system is an NFS server, with NFSv3 enabled in the kernel and
running nfs-kernel-server 1.0.2,
- system is not exclusively an NFS server, it's a Samba, mail, IRC
server as well, and runs lm-sensors,
- this happened during a lull in the load because everyone was on
their way home at the end of our work day.
I am recompiling the kernel now, using a current CVS snapshot of the XFS
tree, and using Debian Sid's current default gcc (2.95.4 20011002)
instead of gcc 3.1.1 like before, and without RML's preempt patch (the
SysMagic patch does not touch sched.c and probably didn't have anything
to do with this). I turned off distributed-net as soon as I rebooted
this third time, and the system's alive so far and was able to recompile
the kernel. I will turn it back on when I boot with the new kernel and
will send a follow-up if the kernel panics again.
Pointers as to what probably caused this are welcome. If this is a "new"
issue I hope the decoded oops messages will be help. Thank you everyone
for your time.
--> Jijo
--
Federico Sevilla III : http://jijo.free.net.ph
Network Administrator : The Leather Collection, Inc.
GnuPG Key ID : 0x93B746BE
[-- Attachment #1.2: kernel-bug.out --]
[-- Type: text/plain, Size: 3554 bytes --]
ksymoops 2.4.6 on i686 2.4.19-xfs. Options used
-V (specified)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.19-xfs/ (specified)
-m /boot/System.map-2.4.19-xfs (specified)
kernel BUG at sched.c:568!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c011b96a>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000018 ebx: 00000004 ecx: dcfda000 edx: 00000001
esi: db41c000 edi: ce9d0d28 ebp: db41dce0 esp: db41dcb8
ds: 0018 es: 0018 ss: 0018
Process distributed-net (pid: 598, stackpage=db41d000)
Stack: c0338daa dd287dc0 df2e5600 00000292 db41c000 00000000 00000001 ce9d0ce0
db41c000 ce9d0d28 db41dcec c01428cd 00000000 00000000 db41c000 dd00dd18
ce9d0d28 ce9d0ce0 ce9d0ce0 00000000 00000808 c0142c07 ce9d0ce0 db41c000
Call Trace: [<c01428cd>] [<c0142c07>] [<c0142c43>] [<c0142cca>] [<c0142e42>]
[<0c25f77b>] [<c025f87d>] [<c011e823>] [<c0122597>] [<c011a980>] [<c0109856>]
[<c011ac44>] [<c0246afd>] [<c02bdc99>] [<c02476b2>] [<c02493ed>] [<c02480ff>]
[<c011a980>] [<c01092bc>] [<c02bc5ea>] [<c0246976>] [<c02bc971>] [<c02bcf16>]
[<c02bcff1>] [<c010a755>] [<c010a99f>] [<c010d273>]
Code: 0f 0b 38 02 a2 8d 33 c0 e9 6f fc ff ff 0f 0b 31 02 a2 8d 33
>>EIP; c011b96a <schedule+3ea/410> <=====
>>ecx; dcfda000 <_end+1cbcdc7c/2049dcdc>
>>esi; db41c000 <_end+1b00fc7c/2049dcdc>
>>edi; ce9d0d28 <_end+e5c49a4/2049dcdc>
>>ebp; db41dce0 <_end+1b01195c/2049dcdc>
>>esp; db41dcb8 <_end+1b011934/2049dcdc>
Trace; c01428cd <__wait_on_buffer+6d/a0>
Trace; c0142c07 <wait_for_buffers+c7/d0>
Trace; c0142c43 <wait_for_locked_buffers+33/50>
Trace; c0142cca <sync_buffers+6a/70>
Trace; c0142e42 <fsync_dev+62/a0>
Trace; 0c25f77b Before first symbol
Trace; c025f87d <do_emergency_sync+fd/120>
Trace; c011e823 <panic+103/130>
Trace; c0122597 <do_exit+257/260>
Trace; c011a980 <do_page_fault+0/500>
Trace; c0109856 <die+86/90>
Trace; c011ac44 <do_page_fault+2c4/500>
Trace; c0246afd <tty_default_put_char+2d/40>
Trace; c02bdc99 <serial_write_room+29/f0>
Trace; c02476b2 <opost+22/1b0>
Trace; c02493ed <n_tty_receive_char+13d/6a0>
Trace; c02480ff <n_tty_receive_buf+17f/4b0>
Trace; c011a980 <do_page_fault+0/500>
Trace; c01092bc <error_code+34/40>
Trace; c02bc5ea <process_transfer+4a/310>
Trace; c0246976 <tty_flip_buffer_push+36/40>
Trace; c02bc971 <process_interrupt+c1/270>
Trace; c02bcf16 <process_urb+286/2c0>
Trace; c02bcff1 <uhci_interrupt+a1/1a0>
Trace; c010a755 <handle_IRQ_event+45/70>
Trace; c010a99f <do_IRQ+8f/f0>
Trace; c010d273 <call_do_IRQ+5/a>
Code; c011b96a <schedule+3ea/410>
00000000 <_EIP>:
Code; c011b96a <schedule+3ea/410> <=====
0: 0f 0b ud2a <=====
Code; c011b96c <schedule+3ec/410>
2: 38 02 cmp %al,(%edx)
Code; c011b96e <schedule+3ee/410>
4: a2 8d 33 c0 e9 mov %al,0xe9c0338d
Code; c011b973 <schedule+3f3/410>
9: 6f outsl %ds:(%esi),(%dx)
Code; c011b974 <schedule+3f4/410>
a: fc cld
Code; c011b975 <schedule+3f5/410>
b: ff (bad)
Code; c011b976 <schedule+3f6/410>
c: ff 0f decl (%edi)
Code; c011b978 <schedule+3f8/410>
e: 0b 31 or (%ecx),%esi
Code; c011b97a <schedule+3fa/410>
10: 02 a2 8d 33 00 00 add 0x338d(%edx),%ah
<0>Kernel panic: Aiee, killing interrupt handler!
[-- Attachment #1.3: kernel-panic.out --]
[-- Type: text/plain, Size: 2288 bytes --]
ksymoops 2.4.6 on i686 2.4.19-xfs. Options used
-V (specified)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.19-xfs/ (specified)
-m /boot/System.map-2.4.19-xfs (specified)
Unable to handle kernel NULL pointer dereference at virtual address 00000028
c02bc5ea
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<C02BC5EA>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000001 ebx: dfcce3e0 ecx: dfcce3c0 edx: 00000000
esi: dfcce380 edi: c0010200 ebp: dfcce3a8 esp: d1899ee4
ds: 0018 es: 0018 ss: 0018
Process distributed-net (pid: 22272, stackpage=d1899000)
Stack: 00000008 c0246976 c354f130 c037e504 dfcce3c0 c15db660 dfcce3a0 dfcce3c0
dfcce380 c64f51e0 00000000 c15db67c c15db660 c15db660 dfc285a0 c02bcf16
c15db660 dfc285a0 00000001 d1898000 d328a000 d1899f48 00000000 c15db67c
Call Trace: [<c0246979>] [<c02bcf16>] [<c02bcff1>] [<c010a755>] [<c010a99f>]
[<c010d273>]
Code: 8b 44 82 24 89 f9 c7 44 24 14 00 00 00 00 c1 e9 0f 83 e1 0f
>>EIP; c02bc5ea <process_transfer+4a/310> <=====
>>ebx; dfcce3e0 <_end+1f8c205c/2049dcdc>
>>ecx; dfcce3c0 <_end+1f8c203c/2049dcdc>
>>esi; dfcce380 <_end+1f8c1ffc/2049dcdc>
>>ebp; dfcce3a8 <_end+1f8c2024/2049dcdc>
>>esp; d1899ee4 <_end+1148db60/2049dcdc>
Trace; c0246979 <tty_flip_buffer_push+39/40>
Trace; c02bcf16 <process_urb+286/2c0>
Trace; c02bcff1 <uhci_interrupt+a1/1a0>
Trace; c010a755 <handle_IRQ_event+45/70>
Trace; c010a99f <do_IRQ+8f/f0>
Trace; c010d273 <call_do_IRQ+5/a>
Code; c02bc5ea <process_transfer+4a/310>
00000000 <_EIP>:
Code; c02bc5ea <process_transfer+4a/310> <=====
0: 8b 44 82 24 mov 0x24(%edx,%eax,4),%eax <=====
Code; c02bc5ee <process_transfer+4e/310>
4: 89 f9 mov %edi,%ecx
Code; c02bc5f0 <process_transfer+50/310>
6: c7 44 24 14 00 00 00 movl $0x0,0x14(%esp,1)
Code; c02bc5f7 <process_transfer+57/310>
d: 00
Code; c02bc5f8 <process_transfer+58/310>
e: c1 e9 0f shr $0xf,%ecx
Code; c02bc5fb <process_transfer+5b/310>
11: 83 e1 0f and $0xf,%ecx
<0>Kernel panic: Aiee, killing interrupt handler!
[-- Attachment #1.4: kernel-panic-2.out --]
[-- Type: text/plain, Size: 2343 bytes --]
ksymoops 2.4.6 on i686 2.4.19-xfs. Options used
-V (specified)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.19-xfs/ (specified)
-m /boot/System.map-2.4.19-xfs (specified)
Unable to handle kernel NULL pointer dereference at virtual address 00000028
c02bc5ea
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c02bc5ea>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000001 ebx: dfcce3e0 ecx: dfcce3c0 edx: 00000000
esi: dfcce380 edi: c0010200 ebp: dfcce3a8 esp: d1899ee4
ds: 0018 es: 0018 ss: 0018
Process distributed-net (pid: 598, stackpage=db41d000)
Stack: 00000005 c0246976 d935c130 c037e504 c02bc971 d935c000 dfc285a0 dfcce3c0
dfcce380 dfc1a1a0 00000000 c15db67c c15db660 c15db660 dfc28420 c02bcf16
c15db660 dfc28420 00000001 db41c000 d5c1c000 db41df48 00000000 c15db67c
Call Trace: [<c0246976>] [<c02bc971>] [<c02bcf16>] [<c02bcff1>] [<c010a755>]
[<c010a99f>] [<c010d273>]
Code: 8b 44 82 24 89 f9 c7 44 24 14 00 00 00 00 c1 e9 0f 83 e1 0f
>>EIP; c02bc5ea <process_transfer+4a/310> <=====
>>ebx; dfcce3e0 <_end+1f8c205c/2049dcdc>
>>ecx; dfcce3c0 <_end+1f8c203c/2049dcdc>
>>esi; dfcce380 <_end+1f8c1ffc/2049dcdc>
>>ebp; dfcce3a8 <_end+1f8c2024/2049dcdc>
>>esp; d1899ee4 <_end+1148db60/2049dcdc>
Trace; c0246976 <tty_flip_buffer_push+36/40>
Trace; c02bc971 <process_interrupt+c1/270>
Trace; c02bcf16 <process_urb+286/2c0>
Trace; c02bcff1 <uhci_interrupt+a1/1a0>
Trace; c010a755 <handle_IRQ_event+45/70>
Trace; c010a99f <do_IRQ+8f/f0>
Trace; c010d273 <call_do_IRQ+5/a>
Code; c02bc5ea <process_transfer+4a/310>
00000000 <_EIP>:
Code; c02bc5ea <process_transfer+4a/310> <=====
0: 8b 44 82 24 mov 0x24(%edx,%eax,4),%eax <=====
Code; c02bc5ee <process_transfer+4e/310>
4: 89 f9 mov %edi,%ecx
Code; c02bc5f0 <process_transfer+50/310>
6: c7 44 24 14 00 00 00 movl $0x0,0x14(%esp,1)
Code; c02bc5f7 <process_transfer+57/310>
d: 00
Code; c02bc5f8 <process_transfer+58/310>
e: c1 e9 0f shr $0xf,%ecx
Code; c02bc5fb <process_transfer+5b/310>
11: 83 e1 0f and $0xf,%ecx
<0>Kernel panic: Aiee, killing interrupt handler!
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468
2002-09-30 12:13 kernel panic "killing interrupt handler" and kernel BUG at sched.c:468 Federico Sevilla III
@ 2002-09-30 16:29 ` Federico Sevilla III
0 siblings, 0 replies; 2+ messages in thread
From: Federico Sevilla III @ 2002-09-30 16:29 UTC (permalink / raw)
To: Linux-XFS Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
Hi everyone,
On Mon, Sep 30, 2002 at 08:13:24PM +0800, Federico Sevilla III wrote:
> On our server that had been running for 55 days with this 2.4.19-xfs
> kernel (XFS CVS snapshot 20020809 patched with RML's preempt patches
> for 2.4.19-rc3 and sys-magic 20020314 from Randy Dunlap, built using
> GCC 3.1.1 running Debian GNU/Linux)
And then after approximately 1.5 hours on 2.4.19-xfs (XFS CVS snapshot
20020930 patched only with Randy Dunlap's sys-magic 20020314, built
using gcc 2.95.4 running Debian GNU/Linux).
> I hit a kernel panic in the process running the distributed-net
> client.
Now in the process running syslogd. Attached kernel-panic-3.out is the
oops.
> After copying the oops message, I attempted to sync the disks using
> the (Alt + SysRq + S) key combination and after the sync messages I
> hit a kernel BUG at sched.c:568.
I did this, as well, and hit a kernel BUG at sched.c:566. My sched.c is
now exactly the same as the one in the XFS tree (which I think is the
same as the one in vanilla 2.4.19). Oops is attached as
kernel-bug-2.out.
> Pointers as to what probably caused this are welcome. If this is a
> "new" issue I hope the decoded oops messages will be help. Thank you
> everyone for your time.
System has been up for two hours so far and is thankfully alive. I hope
someone can point me to what the probably cause of this problem is. I
did an xfs_check -- which is from the latest 2.3.1 package -- and all my
XFS partitions are okay. I will be looking for a memory scanning tool
shortly to make sure I don't suddenly have bad RAM, although the problem
doesn't seem to be that.
Thanks again to everyone for your time.
--> Jijo
--
Federico Sevilla III : http://jijo.free.net.ph
Network Administrator : The Leather Collection, Inc.
GnuPG Key ID : 0x93B746BE
[-- Attachment #2: kernel-panic-3.out --]
[-- Type: text/plain, Size: 2874 bytes --]
ksymoops 2.4.6 on i686 2.4.19-xfs. Options used
-V (specified)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.19-xfs/ (specified)
-m /boot/System.map-2.4.19-xfs (specified)
Unable to handle kernel NULL pointer dereference at virtual address 00000002c
c026d0c9
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c026d0c9>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 00000028 ebx: dfccc3a8 ecx: 01800204 edx: 00000001
esi: dfccc3a8 edi: dfc265a0 ebp: 00000000 esp: defe5da8
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 281, stackpage=defe5000)
Stack: c15d957c dfc265a0 c15d9560 00000000 df381018 c01da1dc dfccc3c0 dfc26620
dfccc3e0 dfccc380 dfc0c1e0 00000000 c026d750 c15d9560 dfc265a0 00000001
c15d957c c15d9560 00000001 00000000 00000008 c038e600 00000000 c026d9c2
Call Trace: [<c01da1dc>] [<c026d750>] [<c026d9c2>] [<c010985d>] [<c01099c6>]
[<c010bbc8>] [<c02707e9>] [<c0271792>] [<c012f3e4>] [<c012f5c3>] [<c012f5de>]
[<c01408fa>] [<c0140bf8>] [<c027188e>] [<c0271f44>] [<c010856f>]
Code: 8b 2c 90 8b 44 24 28 c1 e9 08 83 e1 0f d3 ed 83 e5 01 c7 44
>>EIP; c026d0c9 <process_transfer+51/2e4> <=====
>>ebx; dfccc3a8 <_end+1f924484/2050213c>
>>esi; dfccc3a8 <_end+1f924484/2050213c>
>>edi; dfc265a0 <_end+1f87e67c/2050213c>
>>esp; defe5da8 <_end+1ec3de84/2050213c>
Trace; c01da1dc <xlog_assign_tail_lsn+18/74>
Trace; c026d750 <process_urb+54/200>
Trace; c026d9c2 <uhci_interrupt+c6/12c>
Trace; c010985d <handle_IRQ_event+31/5c>
Trace; c01099c6 <do_IRQ+6a/a8>
Trace; c010bbc8 <call_do_IRQ+5/d>
Trace; c02707e9 <sockfd_lookup+1/7c>
Trace; c0271792 <sys_recvfrom+2a/108>
Trace; c012f3e4 <__alloc_pages+40/178>
Trace; c012f5c3 <__free_pages+1b/1c>
Trace; c012f5de <free_pages+1a/1c>
Trace; c01408fa <poll_freewait+3a/44>
Trace; c0140bf8 <do_select+1c4/1dc>
Trace; c027188e <sys_recv+1e/24>
Trace; c0271f44 <sys_socketcall+15c/200>
Trace; c010856f <system_call+33/38>
Code; c026d0c9 <process_transfer+51/2e4>
00000000 <_EIP>:
Code; c026d0c9 <process_transfer+51/2e4> <=====
0: 8b 2c 90 mov (%eax,%edx,4),%ebp <=====
Code; c026d0cc <process_transfer+54/2e4>
3: 8b 44 24 28 mov 0x28(%esp,1),%eax
Code; c026d0d0 <process_transfer+58/2e4>
7: c1 e9 08 shr $0x8,%ecx
Code; c026d0d3 <process_transfer+5b/2e4>
a: 83 e1 0f and $0xf,%ecx
Code; c026d0d6 <process_transfer+5e/2e4>
d: d3 ed shr %cl,%ebp
Code; c026d0d8 <process_transfer+60/2e4>
f: 83 e5 01 and $0x1,%ebp
Code; c026d0db <process_transfer+63/2e4>
12: c7 44 00 00 00 00 00 movl $0x0,0x0(%eax,%eax,1)
Code; c026d0e2 <process_transfer+6a/2e4>
19: 00
<0>Kernel panic: Aiee, killing interrupt handler!
[-- Attachment #3: kernel-bug-2.out --]
[-- Type: text/plain, Size: 3683 bytes --]
ksymoops 2.4.6 on i686 2.4.19-xfs. Options used
-V (specified)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.19-xfs/ (specified)
-m /boot/System.map-2.4.19-xfs (specified)
kernel BUG at sched.c:566!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0116879>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000018 ebx: defe5be0 ecx: def9c000 edx: 00000001
esi: def4c3e0 edi: defe4000 ebp: defe5bcc esp: defe5ba8
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 281, stackpage=defe5000)
Stack: c02ca05e defe5be0 def4c3e0 defe4000 dfe24a18 defe5be0 00000000 defe4000
dfe24a74 00000808 c0134a5a def4c3e0 00000005 def4c9e0 00000000 defe4000
def4c42c def4c42c c0134c8b def4c3e0 00000808 00000001 00000001 0000000b
Call Trace: [<c0134a5a>] [<c0134c8b>] [<c0134cd0>] [<c0134d17>] [<c0134dd7>]
[<c02203ca>] [<c0220428>] [<c0118da3>] [<c011baf0>] [<c0115e54>] [<c0108b36>]
[<c01161a7>] [<c0115e5f>] [<c0116af6>] [<c0134a70>] [<c013552d>] [<c0108660>]
[<c026d0c9>] [<c01da1dc>] [<c012d750>] [<c026d9c2>] [<c010985d>] [<c01099c6>]
[<c010bbc8>] [<c02707e9>] [<c0271792>] [<c012f3e4>] [<c012f5c3>] [<c012f5de>]
[<c01408fa>] [<c0140bf8>] [<c027188e>] [<c0271f44>] [<c010856f>]
Code: 0f 0b 36 02 56 a0 2c c0 83 c4 04 8b 4d f4 c1 e1 05 81 c1 40
>>EIP; c0116879 <schedule+4d/2f4> <=====
>>ebx; defe5be0 <_end+1ec3dcbc/2050213c>
>>ecx; def9c000 <_end+1ebf40dc/2050213c>
>>esi; def4c3e0 <_end+1eba44bc/2050213c>
>>edi; defe4000 <_end+1ec3c0dc/2050213c>
>>ebp; defe5bcc <_end+1ec3dca8/2050213c>
>>esp; defe5ba8 <_end+1ec3dc84/2050213c>
Trace; c0134a5a <__wait_on_buffer+6e/90>
Trace; c0134c8b <wait_for_buffers+63/90>
Trace; c0134cd0 <wait_for_locked_buffers+18/28>
Trace; c0134d17 <sync_buffers+37/44>
Trace; c0134dd7 <fsync_dev+2b/30>
Trace; c02203ca <go_sync+126/140>
Trace; c0220428 <do_emergency_sync+44/b0>
Trace; c0118da3 <panic+e3/e8>
Trace; c011baf0 <do_exit+28/240>
Trace; c0115e54 <do_page_fault+0/490>
Trace; c0108b36 <die+56/58>
Trace; c01161a7 <do_page_fault+353/490>
Trace; c0115e5f <do_page_fault+b/490>
Trace; c0116af6 <schedule+2ca/2f4>
Trace; c0134a70 <__wait_on_buffer+84/90>
Trace; c013552d <fsync_buffers_list+135/14c>
Trace; c0108660 <error_code+34/3c>
Trace; c026d0c9 <process_transfer+51/2e4>
Trace; c01da1dc <xlog_assign_tail_lsn+18/74>
Trace; c012d750 <kmem_cache_grow+1b4/1d4>
Trace; c026d9c2 <uhci_interrupt+c6/12c>
Trace; c010985d <handle_IRQ_event+31/5c>
Trace; c01099c6 <do_IRQ+6a/a8>
Trace; c010bbc8 <call_do_IRQ+5/d>
Trace; c02707e9 <sockfd_lookup+1/7c>
Trace; c0271792 <sys_recvfrom+2a/108>
Trace; c012f3e4 <__alloc_pages+40/178>
Trace; c012f5c3 <__free_pages+1b/1c>
Trace; c012f5de <free_pages+1a/1c>
Trace; c01408fa <poll_freewait+3a/44>
Trace; c0140bf8 <do_select+1c4/1dc>
Trace; c027188e <sys_recv+1e/24>
Trace; c0271f44 <sys_socketcall+15c/200>
Trace; c010856f <system_call+33/38>
Code; c0116879 <schedule+4d/2f4>
00000000 <_EIP>:
Code; c0116879 <schedule+4d/2f4> <=====
0: 0f 0b ud2a <=====
Code; c011687b <schedule+4f/2f4>
2: 36 02 56 a0 add %ss:0xffffffa0(%esi),%dl
Code; c011687f <schedule+53/2f4>
6: 2c c0 sub $0xc0,%al
Code; c0116881 <schedule+55/2f4>
8: 83 c4 04 add $0x4,%esp
Code; c0116884 <schedule+58/2f4>
b: 8b 4d f4 mov 0xfffffff4(%ebp),%ecx
Code; c0116887 <schedule+5b/2f4>
e: c1 e1 05 shl $0x5,%ecx
Code; c011688a <schedule+5e/2f4>
11: 81 c1 40 00 00 00 add $0x40,%ecx
<0>Kernel panic: Aiee, killing interrupt handler!
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-09-30 16:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-30 12:13 kernel panic "killing interrupt handler" and kernel BUG at sched.c:468 Federico Sevilla III
2002-09-30 16:29 ` Federico Sevilla III
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).