From: Josip Rodin [EMAIL PROTECTED]
Date: Fri, 2 Nov 2007 17:21:06 +0100
Great. Here you go, three of them, while the load was 3 and this process was
stuck:
buildd 10813 100 0.8 987368 17504 ?RN 14:44 155:49 dpkg-query
--search libpthread.so.0 libdl.so.2 libstdc++.so.6
Ok, the key in the trace is:
Nov 2 16:25:30 titan kernel: [ 978.134874] CPU[ 1]:
TSTATE[80009603] TPC[0067d2e0] TNPC[0067d2d4]
TASK[aptitude:3204]
Nov 2 16:25:30 titan kernel: [ 978.257809]
TPC[_write_unlock_irq+0x20/0x110]
...
Nov 2
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sun, 04 Nov 2007 20:55:20 +0100
So I'm not sure if the result is really useful for you - if not just let
me know. I've attached the last ~10-20 sysrq-g outputs - as it was
running in a loop I have a ton of them. In case you're wondering: http
is
David Miller wrote:
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sun, 04 Nov 2007 20:55:20 +0100
So I'm not sure if the result is really useful for you - if not just let
me know. I've attached the last ~10-20 sysrq-g outputs - as it was
running in a loop I have a ton of them. In case you're
In the meantime I'll build an aptitude which should exit after running
trough the part which crashed usually, so it should be possible to run
it in a loop...
This was successful - it made crashing the machine pretty simple, even
without activated libnss-db.
To reproduce on Etch:
- get the
