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

From: Giovanni Trematerra <giovanni.trematerra_at_gmail.com>
Date: Wed, 10 Mar 2010 22:56:57 +0100
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;

      /*
Received on Wed Mar 10 2010 - 20:56:58 UTC

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