Re: ATA_CAM-ed mvsata(4) on OpenRD-client

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Fri, 19 Feb 2010 14:43:19 -0700 (MST)
In message: <4B7EF63C.7030008_at_FreeBSD.org>
            Alexander Motin <mav_at_FreeBSD.org> writes:
: Hi.
: 
: Norikatsu Shigemura wrote:
: > 	I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to
: > 	make mvsata(4) ATA_CAM, like following:
: > 
: > 	But I got following panic, my I help you?
: > 	In this time, I attached no devices to SATA/eSATA port.
: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
: > sata0: <Marvell Integrated SATA Controller> at mem 0xf1080000-0xf1085fff irq 21 on mbus0
: > sata0: [MPSAFE]
: > sata0: [ITHREAD]
: > ata0: <Marvell Integrated SATA Channel> on sata0
: > ata0: [MPSAFE]
: > ata0: [ITHREAD]
: > ata1: <Marvell Integrated SATA Channel> on sata0
: > ata1: [MPSAFE]
: > ata1: [ITHREAD]
: > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long
: > panic: spin lock held too long
: > KDB: enter: panic
: > [ thread pid 0 tid 100000 ]
: > Stopped at      0xc09dcb50 = kdb_enter+0x48:    ldrb    r15, [r15, r15, ror r15]!
: > db> 
: 
: A bit unexpected.
: 
: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
: > 
: > 	So I tried to get following information:
: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
: > _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10
: > scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c)
: >         rsp=0xc0d62d14 rfp=0xc0d62d3c
: >         r10=0xc0d62d70 r9=0xc09039a8
: >         r8=0x00000000 r7=0x00000851 r6=0xc0b47100 r5=0x00000000
: >         r4=0xc35dd974
: > _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10
: > scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c)
: >         rsp=0xc0d62d40 rfp=0xc0d62d68
: >         r8=0xc0bde8f0 r7=0xc090d4a4
: >         r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240
: > xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c
: > scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238)
: >         rsp=0xc0d62d6c rfp=0xc0d62d88
: >         r10=0xc0bde904 r9=0xc0b47100
: >         r8=0x00000000 r7=0xc090d4a4 r6=0x00000080 r5=0x00000000
: >         r4=0x00000001
: > xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218
: > scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0)
: >         rsp=0xc0d62d8c rfp=0xc0d62e34
: > xpt_register_async() at 0xc0905880 = xpt_register_async+0x10
: > scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198)
: >         rsp=0xc0d62e38 rfp=0xc0d62e44
: >         r10=0x00000000 r9=0x00000000
: >         r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0
: >         r4=0x0000001c
: 
: Even more unexpected. I've searched all sources for xpt_sim_opened()
: call and found only one place - in atapi-cam.c, which shouldn't be used
: in your case. You are using different sources, or there is a garbage in
: stack?

IIRC, I got better stack traces when I used the kernel.tramp kernel...

Warner
Received on Fri Feb 19 2010 - 20:53:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:01 UTC