Messages in this thread |  | | Date | Sat, 24 Nov 2001 13:25:06 +0100 (CET) | Subject | Oops in ksoftirqd | From | "Martin Petruzzi" <> |
| |
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/
|  |