Re: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?

On Wed, Mar 10, 2010 at 2:07 PM, Tom Couch <tom.couch.storage_at_gmail.com> wrote:
> Hi FreeBSD-current,
>     My name is Tom Couch,
> I am part of the 3ware driver team recently acquired by LSI.
> I believe Giovanni's patch, below, is the correct fix for this bug.
>
> I am available to maintain the twa driver, now that I am on this list.
> Let me know how I can help,
>
> Tom
>
>
> On Wed, Mar 10, 2010 at 1:56 PM, Giovanni Trematerra <
> giovanni.trematerra_at_gmail.com> wrote:
>
>> On Sun, Mar 7, 2010 at 11:24 AM, Garrett Cooper <yanefbsd_at_gmail.com>
>> wrote:
>> > On Sun, Mar 7, 2010 at 2:07 AM, Garrett Cooper <yanefbsd_at_gmail.com>
>> wrote:
>> >> Hi Alexander and Hans,
>> >>    I recently did the following which generated a panic on a
>> >> 9-CURRENT kernel compiled on the 26th:
>> >>
>> >> 1. Executed reboot
>> >> 2. Removed keyboard.
>> >> 3. Some time after `All buffers synced\nUptime: ...' was displayed,
>> >> the keyboard was registered disconnected.
>> >> 4. The interrupt was delivered to my twa(4) enabled card and the
>> >> kernel panicked, like so:
>> >>
>> >> ugen2.2: <Mitsumi Electric> at usbus2 (disconnected)
>> >> uhub8: at uhub2, port 1, addr 2 (disconnected)
>> >> ugen2.3: <Mitsumi Electric> at usbus2 (disconnected)
>> >> ukbd0: at uhub8, port 3, addr 3 (disconnected)
>> >> uhid0: at uhub8, port 3, addr 3 (disconnected)
>> >> panic: mtx_lock_spin() of destroyed mutex _at_
>> /usr/src/sys/dev/twa/tw_cl_intr.c:88
>> >>
>> >> cpuid = 1
>> >> KDB: enter: panic
>> >> [thread pid 12 tid 100025 ]
>> >> Stopped at         kdb_enter+0x3d: movq     $0,0x40289c(%rip)
>> >> db>
>> >>
>> >>    I wish I could provide you with more details, but unfortunately I
>> >> the USB bus isn't registering the fact that I'm reattaching the
>> >> keyboard right now and the box won't reboot automatically :( (didn't
>> >> set the right sysctl beforehand to panic automatically). I'll try and
>> >> reproduce the issue again, but I was just wondering whether or not you
>> >> guys had seen this problem before.
>> >
>> >    Phew... it's reproducible with that kernel. Here's what I did
>> > exactly (because my original directions were incorrect):
>> >    1. Hit power button (for S5).
>> >    2. Disconnect keyboard RIGHT as `Uptime: ...' is displayed.
>> >    Kernel panicked on my system again. Now to figure out if it still
>> > exists with a kernel compiled today, and also how to debug it if it
>> > still does exist :/...
>> > Thanks,
>> > -Garrett
>>
>> Hi Garrett,
>> Could you please try the patch below and report back?
>>
>> Thank you
>>
>> diff -r cab6489de66d sys/dev/twa/tw_cl_intr.c
>> --- a/sys/dev/twa/tw_cl_intr.c        Wed Mar 03 04:51:13 2010 -0500
>> +++ b/sys/dev/twa/tw_cl_intr.c        Wed Mar 10 06:29:05 2010 -0500
>> _at__at_ -75,9 +75,12 _at__at_ tw_cl_interrupt(struct tw_cl_ctlr_handle
>>      if (ctlr == NULL)
>>               goto out;
>>
>> -     /* If we get an interrupt while resetting, it is a shared
>> -        one for another device, so just bail */
>> -     if (ctlr->state & TW_CLI_CTLR_STATE_RESET_IN_PROGRESS)
>> +     /*
>> +      *  If we get an interrupt while resetting or shutting down,
>> +      *  it is a shared one for another device, so just bail
>> +      */
>> +     if (ctlr->state & TW_CLI_CTLR_STATE_RESET_IN_PROGRESS ||
>> +                     (ctrl->state & TW_CLI_CTLR_STATE_ACTIVE) == 0)
>>              goto out;
>>
>>      /*

I'll give the patch a try sometime before the weekend; I have a
critical deadline that I need to work through and the machine can't be
taken offline until then.
Thanks!
-Garrett