* debug of a kernel panic leading nowhere...
@ 2001-07-26 1:57 Gerald Walden
2001-07-26 2:40 ` Andrew Morton
2001-07-26 15:41 ` Keith Owens
0 siblings, 2 replies; 3+ messages in thread
From: Gerald Walden @ 2001-07-26 1:57 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
X-Mailer: CommuniGate Pro Web Mailer v.3.4.6
Date: Wed, 25 Jul 2001 22:01:47 -0400
Message-ID: <web-832779@dc-mxdb02.cluster1.charter.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Greetings:
During the rmmod of a fairly simple driver, I get a kernel
panic which crashes the system. I believe I have taken all
the proper steps to attempt to debug the problem to no
avail.
Any suggestions as to how to move further, or how to frame
this question in a more appropriate manner for this list (or
perhaps there is a more appropriate list that I should be
sending this to) would greatly be appreciated.
Please cc me on any reply
Kindest Regards
Jerry
ksymoops 2.4.0 on i486 2.4.2-ac25. Options used
-v /root/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /root (specified)
-m /root/System.map (specified)
before <1>Unable to handle kernel paging request at virtual
address 5a5a5a5e
c482424a
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c482424a>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010a83
eax: 5a5a5a5a ebx: c111aebc ecx: 00000000 edx:
5a5a5a5a
esi: c34fa53c edi: 00000001 ebp: c4823d9c esp:
c2b41de0
ds: 0018 es: 0018 ss: 0018
Process rmmod (pid: 741, stackpage=c2b41000)
Stack: c3d9adc0 c3d9ade8 00000000 c482777b 00000000 00000001
c2b41dfc ffffffff
00000000 00000000 00000000 c482779d 00000000 ffffffff
00000000 00000000
00000000 c482190f 00000000 00000000 00000000 c4854c20
c02d7a50 00000000
Call Trace: [<c482777b>] [<c482779d>] [<c482190f>]
[<c4854c20>] [<c4823dd4>] [<c4854c20>] [<c01196b4>]
[<c4854c20>] [<c0116917>] [<c0116857>] [<c011675e>]
[<c0108124>] [<c0106e9c>] [<ffff0018>] [<c01920a1>]
[<c0190010>] [<c0112717>] [<c011277b>] [<c0112839>]
[<c0112a65>] [<c0112a03>] [<c4821000>] [<c4821000>]
[<c4825168>] [<c48325a3>] [<c4832580>] [<c01146bb>]
[<c4821000>] [<c0113827>] [<c4821000>] [<c0106df3>]
Code: 8b 48 04 8b 10 89 4a 04 89 11 89 58 1c 8d 48 08 ff 40
08 0f
>>EIP; c482424a <__module_parm_watchdog+4fd2/????> <=====
Trace; c482777b <END_OF_CODE+8503/????>
Trace; c482779d <END_OF_CODE+8525/????>
Trace; c482190f <__module_parm_watchdog+2697/????>
Trace; c4854c20 <END_OF_CODE+359a8/????>
Trace; c4823dd4 <__module_parm_watchdog+4b5c/????>
Trace; c4854c20 <END_OF_CODE+359a8/????>
Trace; c01196b4 <timer_bh+244/284>
Trace; c4854c20 <END_OF_CODE+359a8/????>
Trace; c0116917 <bh_action+1b/68>
Trace; c0116857 <tasklet_hi_action+3b/60>
Trace; c011675e <do_softirq+4e/74>
Trace; c0108124 <do_IRQ+9c/ac>
Trace; c0106e9c <ret_from_intr+0/20>
Trace; ffff0018 <END_OF_CODE+3b7d0da0/????>
Trace; c01920a1 <serial_console_write+fd/3a4>
Trace; c0190010 <rs_read_proc+404/484>
Trace; c0112717 <__call_console_drivers+3b/4c>
Trace; c011277b <_call_console_drivers+53/58>
Trace; c0112839 <call_console_drivers+b9/ec>
Trace; c0112a65 <release_console_sem+15/74>
Trace; c0112a03 <printk+127/134>
Trace; c4821000 <__module_parm_watchdog+1d88/????>
Trace; c4821000 <__module_parm_watchdog+1d88/????>
Trace; c4825168 <__module_parm_watchdog+5ef0/????>
Trace; c48325a3 <END_OF_CODE+1332b/????>
Trace; c4832580 <END_OF_CODE+13308/????>
Trace; c01146bb <free_module+1b/a0>
Trace; c4821000 <__module_parm_watchdog+1d88/????>
Trace; c0113827 <sys_delete_module+f3/1b0>
Trace; c4821000 <__module_parm_watchdog+1d88/????>
Trace; c0106df3 <system_call+33/38>
Code; c482424a <__module_parm_watchdog+4fd2/????>
00000000 <_EIP>:
Code; c482424a <__module_parm_watchdog+4fd2/????> <=====
0: 8b 48 04 mov 0x4(%eax),%ecx
<=====
Code; c482424d <__module_parm_watchdog+4fd5/????>
3: 8b 10 mov (%eax),%edx
Code; c482424f <__module_parm_watchdog+4fd7/????>
5: 89 4a 04 mov %ecx,0x4(%edx)
Code; c4824252 <__module_parm_watchdog+4fda/????>
8: 89 11 mov %edx,(%ecx)
Code; c4824254 <__module_parm_watchdog+4fdc/????>
a: 89 58 1c mov %ebx,0x1c(%eax)
Code; c4824257 <__module_parm_watchdog+4fdf/????>
d: 8d 48 08 lea 0x8(%eax),%ecx
Code; c482425a <__module_parm_watchdog+4fe2/????>
10: ff 40 08 incl 0x8(%eax)
Code; c482425d <__module_parm_watchdog+4fe5/????>
13: 0f 00 00 sldt (%eax)
<0>Kernel panic: Aiee, killing interrupt handler!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: debug of a kernel panic leading nowhere...
2001-07-26 1:57 debug of a kernel panic leading nowhere Gerald Walden
@ 2001-07-26 2:40 ` Andrew Morton
2001-07-26 15:41 ` Keith Owens
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2001-07-26 2:40 UTC (permalink / raw)
To: Gerald Walden; +Cc: lkml
Gerald Walden wrote:
> ...
> During the rmmod of a fairly simple driver, I get a kernel
> panic which crashes the system. I believe I have taken all
> the proper steps to attempt to debug the problem to no
> avail.
>
> Any suggestions as to how to move further, or how to frame
> this question in a more appropriate manner for this list (or
> perhaps there is a more appropriate list that I should be
> sending this to) would greatly be appreciated.
You have the right list, although your email headers are
strange.
>From the backtrace it appears that perhaps a pending timer has not
been correctly removed prior to module removal, but that's really
just a guess - the backtrace isn't clear.
Is the problem repeatable? What driver is being removed?
-
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: debug of a kernel panic leading nowhere...
2001-07-26 1:57 debug of a kernel panic leading nowhere Gerald Walden
2001-07-26 2:40 ` Andrew Morton
@ 2001-07-26 15:41 ` Keith Owens
1 sibling, 0 replies; 3+ messages in thread
From: Keith Owens @ 2001-07-26 15:41 UTC (permalink / raw)
To: Gerald Walden; +Cc: linux-kernel
On Wed, 25 Jul 2001 21:57:18 -0400,
"Gerald Walden" <thepond@charter.net> wrote:
>During the rmmod of a fairly simple driver, I get a kernel
>panic which crashes the system. I believe I have taken all
>the proper steps to attempt to debug the problem to no
>avail.
>perhaps there is a more appropriate list that I should be
>sending this to) would greatly be appreciated.
>before <1>Unable to handle kernel paging request at virtual
>address 5a5a5a5e
That bit pattern indicates an attempt to access storage that has been
freed and poisoned by the slab cache.
>>>EIP; c482424a <__module_parm_watchdog+4fd2/????> <=====
>Trace; c482777b <END_OF_CODE+8503/????>
>Trace; c482779d <END_OF_CODE+8525/????>
>Trace; c482190f <__module_parm_watchdog+2697/????>
>Trace; c4854c20 <END_OF_CODE+359a8/????>
At the time the oops occurred, the module symbols had already been
removed. You need to run ksymoops against ksyms and lsmod data from
*before* the rmmod. man insmod, see ksymoops assistance, in particular
directory /var/log/ksymoops. Run ksymoops against the symbols saved
after the module was loaded.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-07-26 15:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-26 1:57 debug of a kernel panic leading nowhere Gerald Walden
2001-07-26 2:40 ` Andrew Morton
2001-07-26 15:41 ` Keith Owens
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).