[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: CVS commit: src/sys/dev/bluetooth
> > >> Module Name: src
> > >> Committed By: rkujawa
> > >> Date: Sat Dec 31 01:16:09 UTC 2011
> > >>
> > >> Modified Files:
> > >> src/sys/dev/bluetooth: bthidev.c btkbd.c
> > >>
> > >> Log Message:
> > >> Fix panic triggered by pressing the caps lock key:
> > >> http://c0ff33.net/drop/bt_caps_panic.jpg
> > >
> > > this does not seem right - I've never had such a panic,
> > I can easily reproduce this problem with Apple Wireless Keyboard
> > (version without numeric keypad) on NetBSD/amd64 HEAD. If this patch is
> > not applied, pressing caps lock always results in panic, as in photo.
> Hmm, how long have you been using a Bluetooth keyboard? I wonder if
> something else has changed recently (I've been busy lately - my source is
> from early October, and I want to test something else before updating)
> Also, what kernel options do you have? I am using i386 and have always
> used DIAGNOSTIC (built in now) and I have run with LOCKDEBUG in the past
> though am not at the moment
> I can't see that the type of keyboard will be relevant (I use an older
> apple keyboard here)
for reference, the stack trace from the image is:
the lock that triggers the panic is bt_lock, which was taken in hci_intr()
and attempted to be re-taken in bthidev_output().
> > > btkbd_set_leds() may be called from wskbd directly (by pressing caps lock
> > > on your built-in keyboard for instance)
> > I've tested this patch by pressing the caps lock key on bt keyboard and
> > issuing wsconsctl ledstate=1, and both methods work.
> Do you have a built in keyboard? wsconsctl uses the ioctl, and bt
> keyboard calls the function with the bt_lock held, but if you press the
> caps-lock on the built in keyboard then wscons calls the set_leds routine
> directly, I think? (thus, no lock will be acquired, when sending the
> output report, which is not obviously going to break immediately, but..)
the above trace is from when pressing the caps-lock key, i believe.
> > > probably it should be that bt_lock is released in bthidev_input()
> > > before calling the hid_output function..
> > I'm not sure if I understand correctly. The bthidev_input() does not
> > acquire bt_lock at all.
> it is called from within the bluetooth protocol stack, so will be holding
> it already (thats where the 'locking against myself' originates)
> Just dropping the lock and reaquiring it around the sc_input/sc_feature
> call is probably not exactly the right thing to do though (as the stack
> will not be aware that that might have happened and data structures could
> have changed), it really should disassociate from the context, maybe doing
> the call from a callout or separate task instead. (want that kcont(9) now
> pretty please, gimpy :)
i considered attempt to drop and allow re-taking the bt_lock like you
have described, but i didn't know if it was safe, and there's a lot of
code to read to check. maybe with the above info you can suggest a
better way to solve this problem.
Main Index |
Thread Index |