Camcontrol reprobe da0 causes kernel panic

bob prohaska fbsd at www.zefox.net
Mon Sep 17 16:13:14 UTC 2018


Trying to run, in single-user on a pi3 at FreeBSD 12.0-ALPHA6  r338691 arm64

# camcontrol reprobe da0

instigated

panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /usr/src/sys/cam/scsi/scsi_da.c:2123

cpuid = 0
time = 1537199321
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
	 pc = 0xffff00000069b2ec  lr = 0xffff0000000d952c
	 sp = 0xffff0000517c8410  fp = 0xffff0000517c8620

db_trace_self_wrapper() at vpanic+0x1a8
	 pc = 0xffff0000000d952c  lr = 0xffff000000388a18
	 sp = 0xffff0000517c8630  fp = 0xffff0000517c86e0

vpanic() at panic+0x44
	 pc = 0xffff000000388a18  lr = 0xffff0000003887c4
	 sp = 0xffff0000517c86f0  fp = 0xffff0000517c8770

panic() at __mtx_lock_sleep+0x3f8
	 pc = 0xffff0000003887c4  lr = 0xffff000000369924
	 sp = 0xffff0000517c8780  fp = 0xffff0000517c87f0

__mtx_lock_sleep() at __mtx_lock_flags+0xe0
	 pc = 0xffff000000369924  lr = 0xffff000000369440
	 sp = 0xffff0000517c8800  fp = 0xffff0000517c8840

__mtx_lock_flags() at daasync+0x64
	 pc = 0xffff000000369440  lr = 0xffff0000000364e8
	 sp = 0xffff0000517c8850  fp = 0xffff0000517c88a0

daasync() at xpt_async_process_dev+0x204
	 pc = 0xffff0000000364e8  lr = 0xffff00000001f5cc
	 sp = 0xffff0000517c88b0  fp = 0xffff0000517c8900

xpt_async_process_dev() at xptdevicetraverse+0x9c
	 pc = 0xffff00000001f5cc  lr = 0xffff00000001e5b4
	 sp = 0xffff0000517c8910  fp = 0xffff0000517c8950

xptdevicetraverse() at xpttargettraverse+0x78
	 pc = 0xffff00000001e5b4  lr = 0xffff00000001e320
	 sp = 0xffff0000517c8960  fp = 0xffff0000517c89a0

xpttargettraverse() at xpt_async_process+0x130
	 pc = 0xffff00000001e320  lr = 0xffff00000001b2ec
	 sp = 0xffff0000517c89b0  fp = 0xffff0000517c8ac0

xpt_async_process() at xpt_done_process+0x358
	 pc = 0xffff00000001b2ec  lr = 0xffff00000001bcb8
	 sp = 0xffff0000517c8ad0  fp = 0xffff0000517c8af0

xpt_done_process() at xpt_done_td+0x104
	 pc = 0xffff00000001bcb8  lr = 0xffff00000001dac0
	 sp = 0xffff0000517c8b00  fp = 0xffff0000517c8b50

xpt_done_td() at fork_exit+0x7c
	 pc = 0xffff00000001dac0  lr = 0xffff00000034b0d4
	 sp = 0xffff0000517c8b60  fp = 0xffff0000517c8b90

fork_exit() at fork_trampoline+0x10
	 pc = 0xffff00000034b0d4  lr = 0xffff0000006b572c
	 sp = 0xffff0000517c8ba0  fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 7 tid 100033 ]
Stopped at      0
db> 


The circumstance was a desire to enlarge a partition, da0p7, mounted
on /usr/ports, which turned out to be too small. The man page for growfs
suggests using for my predicament

camcontrol reprobe da0
gpart recover da0
gpart resize -i 7 da0
growfs /dev/da0p7

There's nothing irreplaceable on the system, I just wanted to see if
www/chromium will build and run. The root filesystem is on mmcsd0.

Thanks for reading, and any workarounds.

bob prohaska



More information about the freebsd-arm mailing list