From: Patrick McHardy <kaber@trash.net>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Strange Oops with 2.4.20 and ISDN Channel bundling
Date: Fri, 14 Mar 2003 15:39:18 +0100 [thread overview]
Message-ID: <3E71E996.8060302@trash.net> (raw)
Hi,
we receive the following oops reproducible with vanilla 2.4.20 and isdn
channel bundling:
Oops: 0007
CPU: 0
EIP: 0023:[<0804b6e7>] Not tainted
EFLAGS: 00010287
eax: 080d7940 ebx: 080d7958 ecx: 3fdd2b14 edx: 3fdd2bb4
esi: 0806c204 edi: 00000001 ebp: bffffdc8 esp: bffff7a0
ds: 002b es: 002b ss: 002b
Process ipppd (pid: 1001, stackpage=cded5000)
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
No backtrace is displaced. We had to linux machines connected, only the
one sending data
oopses. Before it happens "Warning: kfree_skb on hard IRQ d08342a4" is
logged a couple of times.
We first noticed the oops with a heavily patched kernel we use. With
this kernel, all kinds of
BUG()s were hit, f.e. in schedule() and alloc_skb(), both expected
in_interrupt() to be false.
The alloc_skb BUG() looks like this:
kernel BUG at skbuff.c:174!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c02204e8>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 0000003a ebx: 00000000 ecx: cd674000 edx: 00000001
esi: 000001f0 edi: c8f5f4c0 ebp: cd6a8000 esp: cd6a9ddc
ds: 0018 es: 0018 ss: 0018
Process ipppd (pid: 876, stackpage=cd6a9000)
Stack: c02a8580 c021f894 000001f0 00000000 c021f894 00000078 000001f0
00000000
c8f5f4c0 00000078 00000000 c8f5fb80 c021f99b c8f5f4c0 00000078
00000000
00000000 cd6a9e48 c02676f4 c8f5f4c0 00000078 00000000 cd6a9e48
c8f5fbc8
Call Trace: [<c021f894>] [<c021f894>] [<c021f99b>] [<c02676f4>]
[<c021d48c>]
[<c0118740>] [<c021e20b>] [<d0836bb6>] [<c022f03f>] [<c0224a34>]
[<c011c7d9>]
[<c0108421>] [<c021e24d>] [<c021e949>] [<c01070d3>]
Code: 0f 0b ae 00 20 85 2a c0 58 5a e9 7c fe ff ff 90 90 8d b4 26
>>EIP; c02204e8 <alloc_skb+1a8/1c0> <=====
>>ecx; cd674000 <_end+d30dc54/104acc54>
>>edi; c8f5f4c0 <_end+8bf9114/104acc54>
>>ebp; cd6a8000 <_end+d341c54/104acc54>
>>esp; cd6a9ddc <_end+d343a30/104acc54>
Trace; c021f894 <sock_alloc_send_pskb+b4/1a0>
Trace; c021f894 <sock_alloc_send_pskb+b4/1a0>
Trace; c021f99b <sock_alloc_send_skb+1b/20>
Trace; c02676f4 <unix_stream_sendmsg+124/2e0>
Trace; c021d48c <sock_sendmsg+5c/90>
Trace; c0118740 <printk+f0/130>
Trace; c021e20b <sys_sendto+cb/f0>
Trace; d0836bb6 <[isdn]isdn_net_start_xmit+196/2e0>
Trace; c022f03f <qdisc_restart+6f/d0>
Trace; c0224a34 <net_tx_action+74/a0>
Trace; c011c7d9 <do_softirq+99/a0>
Trace; c0108421 <do_IRQ+a1/b0>
Trace; c021e24d <sys_send+1d/30>
Trace; c021e949 <sys_socketcall+e9/1b0>
Trace; c01070d3 <system_call+33/40>
Code; c02204e8 <alloc_skb+1a8/1c0>
00000000 <_EIP>:
Code; c02204e8 <alloc_skb+1a8/1c0> <=====
0: 0f 0b ud2a <=====
Code; c02204ea <alloc_skb+1aa/1c0>
2: ae scas %es:(%edi),%al
Code; c02204eb <alloc_skb+1ab/1c0>
3: 00 20 add %ah,(%eax)
Code; c02204ed <alloc_skb+1ad/1c0>
5: 85 2a test %ebp,(%edx)
Code; c02204ef <alloc_skb+1af/1c0>
7: c0 58 5a e9 rcrb $0xe9,0x5a(%eax)
Code; c02204f3 <alloc_skb+1b3/1c0>
b: 7c fe jl b <_EIP+0xb>
Code; c02204f5 <alloc_skb+1b5/1c0>
d: ff (bad)
Code; c02204f6 <alloc_skb+1b6/1c0>
e: ff 90 90 8d b4 26 call *0x26b48d90(%eax)
<0>Kernel panic: Aiee, killing interrupt handler!
To me it looks like something in the area of isdn_net_start_xmit does
something
so in_interrupt later returns true when it is not supposed to do so (all
unix socket
handling should be done in user context if i understand correctly).
I'm not sure what this would be, is it correct to look for:
- *_lock_bk() without *_unlock_bh()
- local_bh_disable() without local_bh_enable()
- save_flags(), sti() without restore_flags()
Am i missing some ? Any other suggestions would be welcome, too.
Regards,
Patrick
Additional Information:
Gnu C 3.2
Gnu make 3.79.1
binutils 2.11.2
util-linux 2.11w
mount 2.11w
modutils 2.4.19
e2fsprogs 1.29
reiserfsprogs 3.x.1b
pcmcia-cs 3.2.4
PPP 2.4.1
isdn4k-utils 3.2p1
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Linux C++ Library 5.0.0
Procps 2.0.9
Net-tools 1.60
Kbd 1.06
Sh-utils 2.0
reply other threads:[~2003-03-14 14:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E71E996.8060302@trash.net \
--to=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.