Re: panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock held
On Wed, Apr 22, 2020 at 09:44:56PM +, Andrew Doran wrote: > Hi Paul, > > On Wed, Apr 22, 2020 at 12:06:41PM +1000, Paul Ripke wrote: > > On -current as of ~yesterday, in a 1CPU amd64 qemu boot, I'm seeing: > > > > Waiting for duplicate address detection to finish... > > Starting dhcpcd. > > dhcpcd-9.0.1 starting > > unknown option: > > [ 17.0102686] wm0: link state UP (was UNKNOWN) > > wm0: carrier acquired > > unknown option: > > [ 17.1710186] pid 122 (dhcpcd), uid 35: exited on signal 11 (core not > > dumped, err = 1) > > dhcpcd_fork_cb: truncated read 0 (expected 4) > > /etc/rc.d/dhcpcd exited with code 1 > > Building databases: dev[ 19.2211655] Mutex error: mutex_vector_enter,514: > > spin lock held > > > > [ 19.2211655] lock address : 0x81765a40 type : > > spin > > [ 19.2211655] initialized : 0x80a2690f > > [ 19.2211655] shared holds : 0 exclusive: > > 1 > > [ 19.2211655] shares wanted: 0 exclusive: > > 0 > > [ 19.2211655] relevant cpu : 0 last held: > > 0 > > [ 19.2211655] relevant lwp : 0x80a57f71c2c0 last held: > > 0x80a57f71c2c0 > > [ 19.2211655] last locked* : 0x80a24843 unlocked : > > 0x80a268e7 > > [ 19.2211655] owner field : 0x00010600 wait/spin: > > 0/1 > > > > [ 19.2211655] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin > > lock held > > [ 19.2211655] cpu0: Begin traceback... > > [ 19.2211655] vpanic() at netbsd:vpanic+0x178 > > [ 19.2211655] snprintf() at netbsd:snprintf > > [ 19.2211655] lockdebug_more() at netbsd:lockdebug_more > > [ 19.2211655] mutex_enter() at netbsd:mutex_enter+0x3c7 > > [ 19.2211655] vmem_rehash_all() at netbsd:vmem_rehash_all+0x13a > > [ 19.2211655] workqueue_worker() at netbsd:workqueue_worker+0xe1 > > [ 19.2211655] cpu0: End traceback... > > > > Seems consistent between attempts. > > > > Known? Meanwhile, I'll re-sync and try again. > > This one was fixed with src/sys/kern/subr_vmem.c 1.103. Confirmed, thanks! -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Re: panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock held
On Wed, Apr 22, 2020 at 09:44:56PM +, Andrew Doran wrote: > Hi Paul, > > On Wed, Apr 22, 2020 at 12:06:41PM +1000, Paul Ripke wrote: > > On -current as of ~yesterday, in a 1CPU amd64 qemu boot, I'm seeing: > > > > Waiting for duplicate address detection to finish... > > Starting dhcpcd. > > dhcpcd-9.0.1 starting > > unknown option: > > [ 17.0102686] wm0: link state UP (was UNKNOWN) > > wm0: carrier acquired > > unknown option: > > [ 17.1710186] pid 122 (dhcpcd), uid 35: exited on signal 11 (core not > > dumped, err = 1) > > dhcpcd_fork_cb: truncated read 0 (expected 4) > > /etc/rc.d/dhcpcd exited with code 1 > > Building databases: dev[ 19.2211655] Mutex error: mutex_vector_enter,514: > > spin lock held > > > > [ 19.2211655] lock address : 0x81765a40 type : > > spin > > [ 19.2211655] initialized : 0x80a2690f > > [ 19.2211655] shared holds : 0 exclusive: > > 1 > > [ 19.2211655] shares wanted: 0 exclusive: > > 0 > > [ 19.2211655] relevant cpu : 0 last held: > > 0 > > [ 19.2211655] relevant lwp : 0x80a57f71c2c0 last held: > > 0x80a57f71c2c0 > > [ 19.2211655] last locked* : 0x80a24843 unlocked : > > 0x80a268e7 > > [ 19.2211655] owner field : 0x00010600 wait/spin: > > 0/1 > > > > [ 19.2211655] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin > > lock held > > [ 19.2211655] cpu0: Begin traceback... > > [ 19.2211655] vpanic() at netbsd:vpanic+0x178 > > [ 19.2211655] snprintf() at netbsd:snprintf > > [ 19.2211655] lockdebug_more() at netbsd:lockdebug_more > > [ 19.2211655] mutex_enter() at netbsd:mutex_enter+0x3c7 > > [ 19.2211655] vmem_rehash_all() at netbsd:vmem_rehash_all+0x13a > > [ 19.2211655] workqueue_worker() at netbsd:workqueue_worker+0xe1 > > [ 19.2211655] cpu0: End traceback... > > > > Seems consistent between attempts. > > > > Known? Meanwhile, I'll re-sync and try again. > > This one was fixed with src/sys/kern/subr_vmem.c 1.103. Thanks, I'll wait for the github mirror to catch up - it seems to erratically lag. Unfortunately(?) I switched away from cvsup some time ago... -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Re: panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock held
Hi Paul, On Wed, Apr 22, 2020 at 12:06:41PM +1000, Paul Ripke wrote: > On -current as of ~yesterday, in a 1CPU amd64 qemu boot, I'm seeing: > > Waiting for duplicate address detection to finish... > Starting dhcpcd. > dhcpcd-9.0.1 starting > unknown option: > [ 17.0102686] wm0: link state UP (was UNKNOWN) > wm0: carrier acquired > unknown option: > [ 17.1710186] pid 122 (dhcpcd), uid 35: exited on signal 11 (core not > dumped, err = 1) > dhcpcd_fork_cb: truncated read 0 (expected 4) > /etc/rc.d/dhcpcd exited with code 1 > Building databases: dev[ 19.2211655] Mutex error: mutex_vector_enter,514: > spin lock held > > [ 19.2211655] lock address : 0x81765a40 type : spin > [ 19.2211655] initialized : 0x80a2690f > [ 19.2211655] shared holds : 0 exclusive: 1 > [ 19.2211655] shares wanted: 0 exclusive: 0 > [ 19.2211655] relevant cpu : 0 last held: 0 > [ 19.2211655] relevant lwp : 0x80a57f71c2c0 last held: 0x80a57f71c2c0 > [ 19.2211655] last locked* : 0x80a24843 unlocked : 0x80a268e7 > [ 19.2211655] owner field : 0x00010600 wait/spin:0/1 > > [ 19.2211655] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin > lock held > [ 19.2211655] cpu0: Begin traceback... > [ 19.2211655] vpanic() at netbsd:vpanic+0x178 > [ 19.2211655] snprintf() at netbsd:snprintf > [ 19.2211655] lockdebug_more() at netbsd:lockdebug_more > [ 19.2211655] mutex_enter() at netbsd:mutex_enter+0x3c7 > [ 19.2211655] vmem_rehash_all() at netbsd:vmem_rehash_all+0x13a > [ 19.2211655] workqueue_worker() at netbsd:workqueue_worker+0xe1 > [ 19.2211655] cpu0: End traceback... > > Seems consistent between attempts. > > Known? Meanwhile, I'll re-sync and try again. This one was fixed with src/sys/kern/subr_vmem.c 1.103. Cheers, Andrew
