Ryota Ozaki <ozak...@netbsd.org> writes: > I think the below patch fixes the above issue, but probably > there is a better solution.
Looks like didn't -- it just changed it a little bit. Just like the last time, the hang happened while reading email over IMAP, which exercises disk and network at the same time, while the machine was busy doing a parallellized system build in the background. This time, though, I got a core dump. Here's the hang (the active process on this CPU is the IMAP server): __cpu_simple_lock_try() at __cpu_simple_lock_try+0x9 pool_grow() at pool_grow+0x55d pool_catchup() at pool_catchup+0x32 pool_get() at pool_get+0x492 pool_cache_get_slow() at pool_cache_get_slow+0x1b4 pool_cache_get_paddr() at pool_cache_get_paddr+0x275 m_get() at m_get+0x2a m_gethdr() at m_gethdr+0x9 wm_add_rxbuf() at wm_add_rxbuf+0x3a wm_rxeof() at wm_rxeof+0x146 wm_intr_legacy() at wm_intr_legacy+0xa1 intr_biglock_wrapper() at intr_biglock_wrapper+0x1d Xintr_ioapic_level2() at Xintr_ioapic_level2+0xf7 --- interrupt --- Xspllower() at Xspllower+0xe uvm_km_kmem_alloc() at uvm_km_kmem_alloc+0x139 pool_page_alloc() at pool_page_alloc+0x2c pool_grow() at pool_grow+0x24f pool_catchup() at pool_catchup+0x32 pool_get() at pool_get+0x492 pool_cache_get_slow() at pool_cache_get_slow+0x1b4 pool_cache_get_paddr() at pool_cache_get_paddr+0x275 m_get() at m_get+0x2a m_gethdr() at m_gethdr+0x9 sosend() at sosend+0x35a soo_write() at soo_write+0x2c dofilewrite() at dofilewrite+0x97 sys_write() at sys_write+0x5f syscall() at syscall+0x1d8 --- syscall (number 4) --- The only other CPU that looks interesting has this (copied from a photograph of the console, as crash(8) doesn't know about CPUs): _kernel_lock() ip_slowtimo() pfslowtimo() callout_softclock() softint_dispatch() The two remaining ones are in x86_pause(), waiting for I/O. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
