lkml.org 
[lkml]   [2003]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.4.18: Oops in slip module in sl_tx_timeout
Recently we've been configuring SLIP links to connect to remote sites
over satellite. These are very slow links (4800 baud) with extreme
latency.

However we recently plugged the wrong data stream (a 4800 baud control
channel) into our slip link and it caused the kernel to Oops. This
Oops happens within 30 seconds of connecting the wrong data feed. It
would seem to indicate some incorrect data checking in the slip code.

The machines that are Oopsing are NFS root machines with keyspan USB
serial cards plugged in (24 ports worth!). They've been reliably
pumping serial data for nearly a year until we started on slip
configuration!

slattach -p cslip -L -s 4800 /dev/ttyUSB4

ifconfig sl0 10.0.0.3 pointopoint 10.0.0.1 netmask 255.255.255.255 mtu 296 up

sl0 Link encap:VJ Serial Line IP
inet addr:10.0.0.2 P-t-P:10.0.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1
RX packets:235781 errors:0 dropped:0 overruns:0 frame:0
compressed:0
TX packets:250293 errors:0 dropped:0 overruns:0 carrier:0
collisions:1 compressed:0 txqueuelen:10
RX bytes:16614825 (15.8 MiB) TX bytes:17399377 (16.5 MiB)

Here is the decoded Oops - it was copied from the screen by hand so
may not be 100% but it seemed to decode OK.

Any ideas gratefully received as this particular misconfiguration will
happen again for certain in the next round of network
reconfigurations!

------------------------------------------------------------

ksymoops 2.4.5 on i686 2.4.18-nfs2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.18-nfs2/ (default)
-m /boot/System.map-2.4.18-nfs2 (default)

Warning: 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.

c884a752
*pde = 00000000
CPU: 0
EIP: 0010:[<c884a752>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
eax: 00000000 ebx: c6030a00 ecx: c5e38000 edx: 00000000
esi: c6030a9c edi: 00000000 ebp: c026f5c0 esp: c5e39f30
ds: 0018 es: 0018 ss: 0018
Stack: 00000000 c6030a9c c01a87a8 c01a87fb c6030a9c c0206920 c6030a9c c6030a9c
c011ca62 c6030a9c 00000000 c026f5a0 00000000 c025f5c0 c4671130 c011c3a6
c021e7bc c0119702 c0119640 00000000 00000001 c026f5c0 fffffffe c011946a
Call Trace: c01a87a8 c01a87fb c011ca62 c011c3a6 c0119702
c0119640 c011946a c0108132 c0109f28
Code: 8b 40 7c ff d0 83 c4 04 85 c0 75 06 83 7b 28 00 74 0c b8 4b


>>EIP; c884a752 <[slip]sl_tx_timeout+36/bc> <=====

>>ebx; c6030a00 <_end+5d89740/8567d40>
>>ecx; c5e38000 <_end+5b90d40/8567d40>
>>esi; c6030a9c <_end+5d897dc/8567d40>
>>ebp; c026f5c0 <softirq_vec+0/100>
>>esp; c5e39f30 <_end+5b92c70/8567d40>

Trace; c01a87a8 <dev_watchdog+0/9c>
Trace; c01a87fb <dev_watchdog+53/9c>
Trace; c011ca62 <timer_bh+222/25c>
Trace; c011c3a6 <tqueue_bh+16/1c>
Trace; c0119702 <bh_action+1a/40>

Code; c884a752 <[slip]sl_tx_timeout+36/bc>
00000000 <_EIP>:
Code; c884a752 <[slip]sl_tx_timeout+36/bc> <=====
0: 8b 40 7c mov 0x7c(%eax),%eax <=====
Code; c884a755 <[slip]sl_tx_timeout+39/bc>
3: ff d0 call *%eax
Code; c884a757 <[slip]sl_tx_timeout+3b/bc>
5: 83 c4 04 add $0x4,%esp
Code; c884a75a <[slip]sl_tx_timeout+3e/bc>
8: 85 c0 test %eax,%eax
Code; c884a75c <[slip]sl_tx_timeout+40/bc>
a: 75 06 jne 12 <_EIP+0x12> c884a764 <[slip]sl_tx_timeout+48/bc>
Code; c884a75e <[slip]sl_tx_timeout+42/bc>
c: 83 7b 28 00 cmpl $0x0,0x28(%ebx)
Code; c884a762 <[slip]sl_tx_timeout+46/bc>
10: 74 0c je 1e <_EIP+0x1e> c884a770 <[slip]sl_tx_timeout+54/bc>
Code; c884a764 <[slip]sl_tx_timeout+48/bc>
12: b8 4b 00 00 00 mov $0x4b,%eax

<0>Kernel panic: Aiee, killing inteterrupr handler!

1 warning issued. Results may not be reliable.

------------------------------------------------------------

--
Nick Craig-Wood
ncw1@axis.demon.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.059 / U:15.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site