Port-sandpoint archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Some issue in dsm-g600 using netbsd 6.0 release

On Sun, 2 Dec 2012 20:59:29 +0100
Charles Brown <obigiankenobi%gmail.com@localhost> wrote:

> The issue with DHCP sounds strange to me too, but is absolutely
> reproducible.

You're right. I can reproduce it as well.

> If I obtain the address via dhclient and I kill the daemon, everything
> works fine.

Same here.

> Could you (or anyone else reading this message) try to reproduce the
> problem in your DSM-G600?

It also happens with a CH3WNAS, which uses the same board.

It doesn't happen with other Sandpoint NAS, using a different NIC
than stge(4).

Some of my crashes:

  0% |                                   |     0        0.00 KiB/s    --:-- ETA
ubc_uiomove: error=14
ubc_uiomove: error=14

  0% |                                   |     0        0.00 KiB/s    --:-- ETA
trap: kernel read DSI trap @ 0xcdc3394a by 0x991d0 (DSISR 0x40000000, err=14), 
lr 0x99554

  0% |                                   |     0        0.00 KiB/s    --:-- 
ETAtrap: kernel read DSI trap @ 0xcdc3394a by 0x99968 (DSISR 0x40000000, 
err=14), lr 0x99cec
Press a key to panic.
panic: trap
cpu0: Begin traceback...
0x005d49c0: at panic+0x4c
0x005d4a00: at trap+0x16c
0x005d4a90: kernel DSI read trap @ 0xcdc3394a by m_xhalf+0x9c: srr1=0x9032
            r1=0x5d4b60 cr=0x48002048 xer=0 ctr=0x99bc4 dsisr=0x40000000
0x005d4b60: at _bus_dmamap_load_buffer+0x184
0x005d4bf0: at _bpf_mtap+0x118
0x005d4c40: at stge_intr+0x5a4
0x005d4c90: at intr_deliver+0x7c
0x005d4cd0: at pic_do_pending_int+0x1c8
0x005d4d30: at splx+0x4c
0x005d4d40: at mutex_exit+0x6c
0x005d4d60: at pool_put+0x26c
0x005d4de0: at pmap_pvo_free+0x24
0x005d4df0: at pmap_pvo_free_list+0x34
0x005d4e00: at pmap_remove+0xa4
0x005d4e40: at uvm_pagermapout+0x24
0x005d4e70: at uvm_aio_aiodone+0xa4
0x005d4ef0: at uvm_aiodone_worker+0x14
0x005d4f00: at workqueue_worker+0x90
0x005d4f20: at setfunc_trampoline+0x8
0x005d4fe8: at 0xfffffffc
cpu0: End traceback...

The problem is reproducible and always follows after a stge(4) receive

Frank Wille

Home | Main Index | Thread Index | Old Index