6.2 sporadically locks up

[pluknet]

2009/6/19 Adrian Chadd <adrian at freebsd.org>:
> Just modify the driver slightly to hijack a different device prefix :)
>

Hi, Adrian.

That's where I just go if I should have to.

-       .d_name =       "aac",
+       .d_name =       "aacu", (or vise versa)

While here, I'd like to give some summary about locking up with
 "irq17:bce1 aacu0" vs arcconf scenario.

Abstract: we have a number of boxes with IBM ServeRAID 8k on 6.2.

That scenario takes place only with aacu b15753, and not with b15411
(at least not noticed). We take a decision some time ago to move some
boxes to 6.4 (and leave vendor aacu b15753 there as it's) to see how
it goes. Until now (2 or 3 weeks) there were no lockup.
I hope it will so farther..


>
>
> Adrian
>
> 2009/6/17 pluknet <pluknet at gmail.com>:
>> 2009/6/17 Ed Maste <emaste at freebsd.org>:
>>> On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote:
>>>
>>>> As for allpcpu, I often see the picture, when one CPU runs the "irq17:
>>>> bce1 aacu0" thread
>>>> and another one runs arcconf. I wonder if that might be a source of
>>>> bad locking or races, or..
>>>> The arcconf utility uses ioctl that goes into aac/aacu(4) internals.
>>>
>>> Do you see the same result w/ the in-tree aac(4) driver as opposed to
>>> Adaptec's version?
>>>
>>> -Ed
>>>
>>
>> [It's quite hard to move back to aac(4) as that requires fstab update
>> [ aacdu0 -> aacd0]
>>  and instant reboot, because we use quotas and quotacheck looks into /etc/fstab.
>> Such preparations as fstab update and commenting out load_aacu="YES" will give
>> discrepancy between fstab and actual mount points.]
>>
>> I will try anyway. Thank you for your help.
>>


-- 
wbr,
pluknet