lkml.org 
[lkml]   [2001]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectOops in ksoftirqd
From
Dear Community

I think I detected an Oops. I may do any mistakes, but I can reproduce the Oops exactly.
I'm running a server with kernel 2.4.14, patched with br2684-against2.4.2.diff and ext3-2.4-0.9.15-2414.gz.
I'm using an Alcatel Speedtouch USB ADSL-modem.
The clients in the network are all Win98 communicating with Putty (SSH).

The problem is about the following script:
***********************************************************
#!/bin/sh

/usr/bin/clear

/usr/bin/killall pppd
/sbin/ifconfig nas0 down
/usr/bin/killall br2684ctl

sleep 1

/usr/sbin/br2684ctl -b -c 0 -a 8.35
/sbin/iconfig nas0 up
/usr/sbin/pppd

/usr/bin/tail -2 /var/log/messages
echo -n "Press ENTER to quit. "
read x

exit 0
***********************************************************

When I execute this script over sudo, as any user logged in with Putty, it works perfect.
Then I've defined a ssh-user just giving his privatkey-file instead of prompting the passwd. In Putty I set /usr/bin/sudo inet_up to
execute when logged in.

The target was to simply doubleclick the Putty-Icon from any Win-client to set up the connection.

When I do so, it still works fine, it ends with a connection (which is available to all clients) and log out is done as well.
After that, the first keystroke in any console on the server (through ssh or local) causes immediatly the following screen on the server:

***********************************************************
Unable to handle kernel NULL pointer dereference at virtual address 00000004
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01fbbac>] Not tainted
EEFLAGS: 00010012
eax: c13c5080 ebx: 00000080 ecx: 00000002 edx: 00000000
esi: 00000020 edi: 00000019 ebp: 0000004a esp: c13e7e8c
ds: 0018 es: 0018 ss: 0018
Process ksoftirqd_CPU0 (pid: 4, stackpage=c13e7000)
Stack: 0000a020 c13dc944 c01a0f37 0000005c 00000020 00000064 00000001 0000001f
c13dc940 c031d000 c031d07c c02a8340 00000000 00004000 c13dc940 c13dc800
cc880000 c01a099a c13dc800 00004050 00000014 cbfdd740 24000001 0000000b
Call Trace: [<c01a0f37>] [<c01a099a>] [<c0107ffa>] [<c0108178>] [<c010a178>]
[<c01f0018>] [<c01fbef5>] [<c02441da>] [<c01081ac>] [<c020527a>] [<c01192d4>]

[<c01ff8be>] [<c0115fab>] [<c0105000>] [<c01163d5>] [<c0105516>] [<c0166240>]


Code: c7 42 04 a0 95 31 c0 89 15 a0 95 31 c0 c7 00 00 00 00 00 c7
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
************************************************************

I did that several times to exclude all other related actions. It only happens with the sequence
described above, but everytime.

Now I actually don't need any help since I worked around it by setting up DialOnDemand, so I don't use that thing anymore (any other
scripts I have do work the same way), but I still find it could be interesting for the developers.

If there is an obvious mistake in what I did, I would certainly also be interested to know.

Thank you

Martin

-
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:13    [W:0.020 / U:2.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site