panic: mutex SIIS channel lock not owned siis.c:1703

[Alexander Motin]

Hi.

Roger Hammerstein wrote:
> I added a highpoint 1820a card to a machine and moved
> a disk from a <SiI3124 SATA controller> to the highpoint, and
> got this panic on the next boot.   Moving the disk back to the
> SiI3124 removed the panic. 
> 
> panic: mutex SIIS channel lock not owned at
> /usr/src/sys/modules/siis/../../dev/siis/siis.c:1703
> 
> I just rebuilt world and kernel
> 
> FreeBSD butter 9.0-CURRENT FreeBSD 9.0-CURRENT #7: Fri Jan  7 18:56:15
> EST 2011  
> 
> Reading symbols from /boot/kernel/siis.ko...Reading symbols from
> /boot/kernel/siis.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/siis.ko
> #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:250
> 250             if (textdump_pending)
> (kgdb) #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:250
> #1  0xffffffff805de4e7 in kern_reboot (howto=260)
>     at /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xffffffff805de971 in panic (fmt=Variable "fmt" is not available.
> )
>     at /usr/src/sys/kern/kern_shutdown.c:591
> #3  0xffffffff805ced4c in _mtx_assert (m=Variable "m" is not available.
> )
>     at /usr/src/sys/kern/kern_mutex.c:706
> #4  0xffffffff810f6962 in siisaction (sim=0xfffffe0002923e00,
>     ccb=0xffffff8094fa24a0)
>     at /usr/src/sys/modules/siis/../../dev/siis/siis.c:1703
> #5  0xffffffff801a4a89 in ata_device_transport (path=0xffffff8094fa2770)
>     at /usr/src/sys/cam/ata/ata_xpt.c:1500
> #6  0xffffffff801a672c in ata_alloc_device (bus=0xfffffe000251f480,
> target=Variable "target" is not available.
> )
>     at /usr/src/sys/cam/ata/ata_xpt.c:1482
> #7  0xffffffff8019e342 in xpt_compile_path (new_path=0xfffffe00027b9100,
>     perph=0x0, path_id=Variable "path_id" is not available.
> ) at /usr/src/sys/cam/cam_xpt.c:3347
> #8  0xffffffff8019e506 in xpt_create_path (new_path_ptr=0xffffff8094fa2890,
>     perph=0x0, path_id=0, target_id=0, lun_id=0)
>     at /usr/src/sys/cam/cam_xpt.c:3269
> #9  0xffffffff808fd9c6 in hpt_status (oidp=Variable "oidp" is not available.
> ) at osbsd.h:247
> #10 0xffffffff805e8907 in sysctl_root (oidp=Variable "oidp" is not
> available.
> )
>     at /usr/src/sys/kern/kern_sysctl.c:1455
> #11 0xffffffff805e8bae in userland_sysctl (td=0x0, name=0xffffff8094fa2a50,
>     namelen=2, old=0x0, oldlenp=Variable "oldlenp" is not available.
> ) at /usr/src/sys/kern/kern_sysctl.c:1565
> #12 0xffffffff805e905a in __sysctl (td=0xfffffe00032bf450,
>     uap=0xffffff8094fa2bc0) at /usr/src/sys/kern/kern_sysctl.c:1491
> #13 0xffffffff80620d0a in syscallenter (td=0xfffffe00032bf450,
>     sa=0xffffff8094fa2bb0) at /usr/src/sys/kern/subr_trap.c:318
> #14 0xffffffff808d7f5c in syscall (frame=0xffffff8094fa2c50)
>     at /usr/src/sys/amd64/amd64/trap.c:938
> #15 0xffffffff808c2c82 in Xfast_syscall ()
>     at /usr/src/sys/amd64/amd64/exception.S:381
> #16 0x000000080074365c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)

As I can see, it is not siis(4) driver bug, but hptmv(4). As I can see,
hpt_get_periph() function receives argument of sequential number of HPT
controller within the system, but uses it as CAM path (bus) ID. It could
work when HPT's are the only controllers in system, but as soon as you
have another one and it appeared to be the first - things went wrong.

I haven't looked deep into the hptmv(4) driver, but I thing either
pAdapter->mvSataAdapter.adapterId should be made equal to CAM path ID
(not sure how how the driver may react on this), or in all calls to
hpt_get_periph() instead of it use something like:
xpt_path_path_id(&pAdapter->path)

-- 
Alexander Motin