freebsd stable - Jun 2010 - mfiutil create .. leads to deadlock in 6-STABLE

hi,

I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps).

As I can see, lockup is caused by sleeping on sx lock after Giant was acquired.
Can r160217 help me or am I go the wrong way?
from r160217: "Use a sleep mutex instead of an sx lock for the kernel
environment."

after `# mfiutil create raid5 8,9,10,11,12,13`

db> bt 924
Tracing pid 924 tid 100156 td 0xc6fcb340
sched_switch(c6fcb340,0,2) at sched_switch+0x15b
mi_switch(2,0,c0ac4020,0,c09b478a,...) at mi_switch+0x270
critical_exit(1,c6fcb340,c677d88a,b,a,...) at critical_exit+0x8b
intr_execute_handlers(c67ae678,ed2f16a8,10,ed2f1838,c09141e3,...) at
intr_execute_handlers+0x129
lapic_handle_intr(36) at lapic_handle_intr+0x2e
Xapic_isr1() at Xapic_isr1+0x33
--- interrupt, eip = 0xc06d2c2f, esp = 0xed2f16ec, ebp = 0xed2f1838 ---
vsscanf(c677d880,c09b523b,ed2f1864,ed2f1944,c06cd5c9,...) at vsscanf+0x123
sscanf(c677d880,c09b523b,ed2f1918,ed2f1874,ed2f18f8,...) at sscanf+0x12
res_find(ed2f19c8,0,c0993cb1,ed2f19dc,c09b5c62,0,0,0,0,0,0,ed2f19cc)
at res_find+0x225
resource_find(ed2f19c8,0,c0993cb1,ed2f19dc,c09b5c62,0,0,0,0,0,0,ed2f19cc)
at resource_find+0x3b
resource_int_value(c0993cb1,0,c09b5c62,c6f5843c) at resource_int_value+0x32
device_probe_child(c695d200,c6f58400) at device_probe_child+0xc5
device_probe_and_attach(c6f58400) at device_probe_and_attach+0x7d
bus_generic_attach(c695d200,c6f58400,c0993995,c6f58400,c6cb8800,...)
at bus_generic_attach+0x16
mfi_add_ld_complete(c697b130,c697b130,c6cb8800,0,c6974400,...) at
mfi_add_ld_complete+0xe5
mfi_add_ld(c6974400,0) at mfi_add_ld+0xcc
mfi_ldprobe(c6974400) at mfi_ldprobe+0xfe
mfi_check_command_post(c6974400,c697ad70,eae97080,c700d0c0,34) at
mfi_check_command_post+0x1b6
mfi_user_command(c6974400,c700d0c0,2,c09b478a,27d,...) at mfi_user_command+0x1a4
mfi_ioctl(c6963900,c03c4366,c700d0c0,3,c6fcb340,...) at mfi_ioctl+0x790
devfs_ioctl_f(c70092d0,c03c4366,c700d0c0,c6d37000,c6fcb340) at
devfs_ioctl_f+0xaf
ioctl(c6fcb340,ed2f1d04) at ioctl+0x396
syscall(3b,3b,3b,bfbfeaa0,240,...) at syscall+0x22f
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28150877, esp 0xbfbfea8c, ebp =
0xbfbfeaf8 ---
db>

all cpus in idle

db> show alllocks
Process 924 (mfiutil) thread 0xc6fcb340 (100156)
shared sx kernel environment r = 0 (0xc0ac2140) locked @
/usr/src/sys/kern/subr_hints.c:117
exclusive sleep mutex Giant r = 0 (0xc0ac4060) locked @
/usr/src/sys/dev/mfi/mfi.c:1329
exclusive sx MFI config r = 0 (0xc6974578) locked @
/usr/src/sys/dev/mfi/mfi.c:1737


-- 
wbr,
pluknet

On Tue, Jun 8, 2010 at 2:30 AM, pluknet <pluknet@gmail.com>
wrote:
> hi,
>
> I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps).
>
> As I can see, lockup is caused by sleeping on sx lock after Giant was
acquired.
> Can r160217 help me or am I go the wrong way?
> from r160217: "Use a sleep mutex instead of an sx lock for the kernel
> environment."
Where are you coming from :)?
Thanks,
-Garrett

On 8 June 2010 13:54, Garrett Cooper <yanefbsd@gmail.com>
wrote:
> On Tue, Jun 8, 2010 at 2:30 AM, pluknet <pluknet@gmail.com> wrote:
>> hi,
>>
>> I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0
6Gbps).
>>
>> As I can see, lockup is caused by sleeping on sx lock after Giant was
acquired.
>> Can r160217 help me or am I go the wrong way?
>> from r160217: "Use a sleep mutex instead of an sx lock for the
kernel
>> environment."
>
> Where are you coming from :)?
>From large legacy land. Hi there.
-- 
wbr,
pluknet

On 8 June 2010 13:30, pluknet <pluknet@gmail.com>
wrote:
> hi,
>
> I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps).
Also, subj FreeBSD version has general instability namely
w/ this controller (another issue). It locks up every time immediately after:
<118>Starting sshd.
<118>Starting cron.
<118>cron: can't open or create /var/run/cron.pid: Operation not
supported
<118>Local package initialization:
<118>.
<118>Starting background file system checks in 60 seconds.
^^ here

I've collected alltrace if that makes sense (attached).
show alllocks produces nothing here.

-- 
wbr,
pluknet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: typescript
Type: application/octet-stream
Size: 28516 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100608/0cd276c2/typescript.obj

On Tuesday 08 June 2010 5:30:30 am pluknet wrote:
> hi,
> 
> I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps).
> 
> As I can see, lockup is caused by sleeping on sx lock after Giant was 
acquired.
> Can r160217 help me or am I go the wrong way?
> from r160217: "Use a sleep mutex instead of an sx lock for the kernel
> environment."
Giant is special, it can be acquired both before and after sx locks because it 
is released while blocking on an sx lock.  Are you sure that mfiutil is hung?  
The thread appears to be running rather than blocked on a lock.

-- 
John Baldwin