hi!
i did some heavy stresstesting on /dev/random
and /dev/urandom, also while the system was under VERY
high load (loadavg >60). no crashes. since the bug-reporter
doesn`t tell, which uml-kernel
you are using,and nobody also seems to have reported this
bug - should this bug better be set to
"closed"? i`m using linux-2.6.0-test11-um on 2.6.0-test9-
skas-host. system is suse9.
i really wonder about this "bug" - what sense would it make to
make uml a honeypot-uml or for jailing
services, if it could be crashed so easily?
regards
roland
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the record, this is not fixed. I'm running a Debian host
with 2.4.25 kernel and host-skas3-2.4.25.patch, and a Debian
guest with 2.4.27 kernel.
In one xterm I ran "while true; do ls -la /dev/*; done" (see
also bug report 617709). In the other, "cat /dev/urandom".
After 5-10 seconds, the 'linux' host process crashes
completely with:
Scheduling in interrupt
Kernel panic: kernel BUG at sched.c:564!
In interrupt handler - not syncing
<6>SysRq : Show Regs
Logged In: NO
hi!
i did some heavy stresstesting on /dev/random
and /dev/urandom, also while the system was under VERY
high load (loadavg >60). no crashes. since the bug-reporter
doesn`t tell, which uml-kernel
you are using,and nobody also seems to have reported this
bug - should this bug better be set to
"closed"? i`m using linux-2.6.0-test11-um on 2.6.0-test9-
skas-host. system is suse9.
i really wonder about this "bug" - what sense would it make to
make uml a honeypot-uml or for jailing
services, if it could be crashed so easily?
regards
roland
Logged In: YES
user_id=750408
For the record, this is not fixed. I'm running a Debian host
with 2.4.25 kernel and host-skas3-2.4.25.patch, and a Debian
guest with 2.4.27 kernel.
In one xterm I ran "while true; do ls -la /dev/*; done" (see
also bug report 617709). In the other, "cat /dev/urandom".
After 5-10 seconds, the 'linux' host process crashes
completely with:
Scheduling in interrupt
Kernel panic: kernel BUG at sched.c:564!
In interrupt handler - not syncing
<6>SysRq : Show Regs
EIP: 0023:[<400e4b38>] CPU: 0 Not tainted ESP: 002b:bffffc68
EFLAGS: 00000246
Not tainted
EAX: ffffffda EBX: 00000001 ECX: 0804cdf0 EDX: 00001000
ESI: 00001000 EDI: 0804cdf0 EBP: bffffc88 DS: 002b ES: 002b
Call Trace: [<a0010e5f>] [<a00cae60>] [<a018db51>]
[<a018dade>] [<a000dc93>]
[<a00cade9>] [<a00b526f>] [<a0010e5f>] [<a001d2ec>]
[<a012d637>] [<a017561e>]
[<a0010e5f>] [<a017561e>] [<a0010405>] [<a00103f1>]
[<a0010e5f>] [<a000d965>]
[<a017561e>] [<a0175616>] [<a00b26ec>] [<a00bd0d1>]
[<a0015e2f>] [<a00bd268>]
[<a00e1fc4>] [<a00b4caf>] [<a00e0057>] [<a00c32d5>]
[<a00b4caf>] [<a00c3a6a>]
[<a012f024>] [<a00c42e2>] [<a00b2816>] [<a00b2855>]
[<a00b277e>] [<a00c3035>]
[<a00c8bc0>] [<a001622f>] [<a001a8e3>] [<a0016153>]
[<a001607b>] [<a0016037>]
[<a00b26ec>] [<a0015de1>] [<a0015dcf>] [<a00ada41>]
[<a00ada52>] [<a00b3dfe>]
[<a00b4108>] [<a00bb278>] [<a00bb211>] [<a00bb211>]
[<a00bb278>] [<a00b4bed>]
[<a00b4ba8>] [<a012ef38>] [<a014639d>] [<a014639d>]
[<a012ef38>] [<a00c8db0>]
[<a00bb56e>] [<a00bb3e0>] [<a00bb7f0>] [<a00b0404>]
[<a00bb7f0>] [<a00bb304>]
[<a0053f2f>] [<a00bb64c>] [<a00ab920>] [<a00b0404>]
[<a00bb3d4>] [<a00c8c7b>]
[<a00bb304>] [<a00bb458>] [<a00bb59c>] [<a00bb64c>]
[<a012f024>] [<a00bb59c>]
[<a00bb3d4>] [<a00b0404>] [<a00bb64c>] [<a00bb458>]
[<a00bb59c>] [<a00bb59c>]
[<a00b597f>] [<a00b2855>] [<a00bb458>] [<a00be776>]
[<a00be776>] [<a00be81d>]
[<a0146380>] [<a00b0658>] [<a00be81d>] [<a00e031b>]
[<a00e05d6>] [<a00bb59c>]
[<a00e1458>] [<a00bb637>] [<a00e0057>] [<a00e0057>]
[<a00c3a29>] [<a00c32d5>]
[<a00c5f3d>] [<a00c5e11>] [<a00c0e91>] [<a00c5d50>]
[<a0033e1a>] [<a00bad8e>]
[<a00b35bb>] [<a00b36e3>] [<a00baddc>] [<a00badd3>]
[<a00b9fb5>] [<a00ba0bd>]
[<a00b01ba>] [<a00ba31a>] [<a00b26ec>] [<a00baa87>]
[<a00baa71>] [<a012ef38>]
[<a012efd1>]