O2 unresponsive after amanda connect
Hi,
after I removed the 64MB of memory, I finished the etch install on my O²:
> hinv
System: IP32
Processor: 180 Mhz R5000, with FPU
Primary I-cache size: 32 Kbytes
Primary D-cache size: 32 Kbytes
Memory size: 384 Mbytes
Graphics: CRM, Rev C
Audio: A3 version 1
SCSI Disk: scsi(0)disk(1)
SCSI CDROM: scsi(0)cdrom(4)
tolsyt:~# uname -a
Linux tolsyt 2.6.18-6-r5k-ip32 #1 Mon Feb 11 15:57:56 GMT 2008 mips64 GNU/Linux
Now, I have the problem that it does not respond to pings or anything,
not even returns on the serial console anymore after an attempted backup
via amanda. It does respond to magic-syreqs, however:
SysRq : Show Regs
Cpu 0
$ 0 : 0000000000000000 ffffffff80480000 900000001f280000 0000000000280000
$ 4 : 000000000000c302 0000000000280000 0000000000000007 0000000000000002
$ 8 : 000000000000ffff 9800000057552e80 98000000538dc022 98000000004c7800
$12 : 0000000000000000 ffffffff801dd90c ffffffff8009e938 0000000000000000
$16 : 9800000000602430 9800000000602400 000000002c111720 0000000000000007
$20 : 000000000000003c 9800000000602000 9800000000602400 9800000000602000
$24 : 0000000000000004 ffffffff80022e38
$28 : 9800000056124000 98000000561277c0 ffffffff9001fce1 ffffffff80238eb8
Hi : 0000000000000000
Lo : 0000000000000000
epc : ffffffff80239038 meth_interrupt+0x530/0x8c0 Not tainted
ra : ffffffff80238eb8 meth_interrupt+0x3b0/0x8c0
Status: 9001fce3 KX SX UX KERNEL EXL IE
Cause : 00000400
PrId : 00002321
SysRq : Show Memory
Mem-info:
DMA per-cpu:
cpu 0 hot: high 186, batch 31 used:16
cpu 0 cold: high 62, batch 15 used:8
DMA32 per-cpu: empty
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages: 289796kB (0kB HighMem)
Active:8842 inactive:1994 dirty:414 writeback:0 unstable:0 free:72449 slab:6406 mapped:1044 pagetables:101
DMA free:289796kB min:4800kB low:6000kB high:7200kB active:35368kB inactive:7976kB present:1441792kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 70*4096kB = 289796kB
DMA32: empty
Normal: empty
HighMem: empty
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap = 184312kB
Total swap = 184312kB
Free swap: 184312kB
360448 pages of RAM
0 pages of HIGHMEM
269010 reserved pages
6317 pages shared
0 pages swap cached
All kernel threads are stuck like this:
scsi_eh_0 S ffffffff8023ee94 0 183 5 218 49 (L-TLB)
Stack : 98000000005a4000 9800000002687c18 98000000005a4000 0000000000000000
98000000005dbf30 0000000000000000 98000000005dbf40 0000000000002002
0000000000000000 ffffffff8023ee94 ffffffff9401fce0 0000000000000000
0000000000000001 9800000002687c30 9800000002687c30 0000000000000001
ffffffff80056944 ffffffff80353e5c 98000000005a4000 9800000002687c18
ffffffff8023ee00 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 ffffffff800569b0 ffffffff80056944
ffffffffffffffff ffffffffffffffff 0000000000000000 0000000000000000
0000000000000000 ffffffff80009c00 0000000000000000 ffffffff80009bf0
ffffffffffffffff ffffffffdfffffff ffffffffffffffff ffffffffffffffff
Call Trace:
[<ffffffff80353cb8>] schedule+0x528/0xb20
[<ffffffff8023ee94>] scsi_error_handler+0x94/0x880
[<ffffffff800569b0>] kthread+0x1b8/0x1e0
[<ffffffff80009c00>] kernel_thread_helper+0x10/0x18
And all user tasks are stuck in handle_sys:
amandad R running task 0 1268 1057 1269 (NOTLB)
sendbackup S ffffffff800b0e34 0 1269 1268 1271 (NOTLB)
Stack : 980000005466b400 980000005466b400 9800000053de3e88 0000000000002000
000000000044ea50 0000000000000024 0000000000002000 0000000000000000
00000000001fffff ffffffff800b0e34 0000000000000000 98000000574cf2e0
ffffffff80056e78 980000005466b400 980000005466b400 98000000574cf2e0
98000000560f7020 ffffffff800b149c 000000002aac48d0 98000000575c4a20
0000000000000000 0000000000000000 980000005465a0a0 9800000053de3e30
98000000560f70e0 ffffffff800202a0 980000005465a0a0 000000000044ea50
9800000053de3e88 0000000000002000 000000000044ea50 0000000000000024
0000000000000003 000000002ac20000 00000000001fffff ffffffff800b1904
000000000044ea50 0000000000002000 ffffffff8009e400 ffffffff8009e3a8
...
Call Trace:
[<ffffffff80353cb8>] schedule+0x528/0xb20
[<ffffffff800b0e34>] pipe_wait+0x7c/0xb0
[<ffffffff800b149c>] pipe_readv+0xe4/0x530
[<ffffffff800b1904>] pipe_read+0x1c/0x28
[<ffffffff8009e400>] vfs_read+0xf0/0x1b0
[<ffffffff8009e8f4>] sys_read+0x4c/0x90
[<ffffffff8001e288>] handle_sys+0x128/0x144
Is there anything I can do to provide more info? Is this a known bug?
TIA,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de | Listening to:
Stormweg 24 |Der Weisse Raum (Der Dritte Mann), Caligari
24539 Neumuenster, Germany|(Opération S), Looking For Action (Ghetto Ways)
Reply to: