tech-kern archive

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

Re: evbarm hang



On 18/04/2019 15:32, Manuel Bouyer wrote:
Hello,
I got several hard hang while building packages on an allwinner a20 (lime2)
I use distcc so there is moderate network traffic in addition to
local CPU load.

most of the time I can't enter ddb from serial console, I just get
Stopped in pid 25136.1 (cc1) at netbsd:cpu_Debugger+0x4:<hang>

On 2 occasion, I could enter ddb, and both time the stack trace on CPU 0
was similar:

0x9cea7c0c: netbsd:pool_get+0x70 <-- hang here
0x9cea7c5c: netbsd:pool_cache_get_slow+0x1f4
0x9cea7cac: netbsd:pool_cache_get_paddr+0x288
0x9cea7ccc: netbsd:m_clget+0x34
0x9cea7d2c: netbsd:dwc_gmac_intr+0x194
0x9cea7d44: netbsd:gic_fdt_intr+0x2c
0x9cea7d6c: netbsd:pic_dispatch+0x110
0x9cea7dcc: netbsd:armgic_irq_handler+0xf4
0x9cea7e3c: netbsd:irq_entry+0x68
0x9cea7e7c: netbsd:uvm_unmap_detach+0x80
0x9cea7eac: netbsd:uvmspace_free+0x100
0x9cea7f14: netbsd:exit1+0x190
0x9cea7f34: netbsd:sys_exit+0x3c
0x9cea7fac: netbsd:syscall+0x12c


(the common point is the dwc_gmac_intr() call, which ends up in pool_get().
pool_get() seems to spin on the mutex_enter(&pp->pr_lock); call
just before startover:.
Unfortunably I can't get a stack trace for CPU 1:
db{0}> mach cpu 1
kdb_trap: switching to cpu1
Stopped in pid 26110.1 (gcc) at netbsd:_kernel_lock+0xc4:<hang>

Maybe you can get it by looking for the lwp on the other cpu using ps/l
and using bt/a?


Nick


Home | Main Index | Thread Index | Old Index