PR kern/34634 -- Bluetooth SCO crash

[Iain Hibbert <plunky%rya-online.net@localhost>]

The following reply was made to PR kern/34634; it has been noted by GNATS.

From: Iain Hibbert <plunky%rya-online.net@localhost>
To: Jose Vasconcellos <jose%vasmac.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: PR kern/34634 -- Bluetooth SCO crash
Date: Sat, 3 May 2008 20:49:35 +0100 (BST)

 Hi Jose,
 
         I apologise - this PR you sent some time ago I just noticed again.
 
    http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=34634
 
 I did respond once but for some reason my message has not been attached to
 the PR and I wonder if you didn't get it either. Are you still using
 NetBSD-4.0?  There were many changes after this, can you say if this is
 still a problem?
 
 > When attempting to play an audio file to a headset (e.g. audioplay)
 > the program hangs or NetBSD crashes (if sysctl -w hw.ubt0.config=2)
 > This has been duplicated on the GENERIC kernel with Broadcom and CSR
 > USB dongles.
 
 > If hw.ubt0.config=0, SCO connection is established and 8 SCO frames
 > are sent, then the application hangs.
 
 that is because in that case, there is nowhere for the packets to go, so
 the application gets into write-block. Its on my TODO list to clean this
 area up so that the sysctl is not required though I still haven't worked
 out the best way.
 
 > btconfig -v ubt0 class 0x3e0100
 > btconfig -v ubt0 scomtu 48
 > btpin -a headset -p 0000
 > btdevctl -d ubt0 -a headset -s HSET -A
 > # the following line causes a crash when audioplay is executed
 > sysctl -w hw.ubt0.config=2
 
 I think that the problem could have been that this sysctl should not be
 tweaked when the device is already configured - I added a check around
 that time to make this fail explicitly in that case:
 
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/ubt.c.diff?r1=1.17&r2=1.18
 
 I'm not sure if that was in the source you were using - there was a
 problem where the sc_config value was changed even if you couldn't change
 it, and I think this could have cascaded into a later problem such as you
 were seeing.
 
 regards,
 iain