|
From: Gordon M. <gm...@us...> - 2001-04-17 23:50:27
|
The following file was modified in linux/drivers/char/bluetooth:
Name Old version New version Comment
---- ----------- ----------- -------
bluetooth.c 1.165 1.166=20=20=20=20=20=20=20=20=20=20=20
The accompanying log:
--Fixed a bug that could cause an SDP connection request to block the user =
process indefinitely.
The diff of the modified file(s):
--- bluetooth.c 2001/04/17 16:05:11 1.165
+++ bluetooth.c 2001/04/17 23:50:26 1.166
@@ -1678,6 +1678,29 @@
* half to process the request and get back to us.=20=20=20
*/
=20=09=09=09
+ /* I seem to be having a lot of trouble with the L2CAP
+ traffic just not appearing on this side of the link
+ while I'm waiting for the SDP conneciton to finish
+ up. So let's start a timer to wake us up if things
+ don't appear to be working out.
+ --gmcnutt
+ */
+ /* fixme -- we probably need a lock on this timer since
+ multiple processes could be trying to use it at the
+ same time... or maybe use one timer per session.
+ */
+ start_wq_timer(&bt_timer, BT_CON_TIMEOUT,=20
+ &bt_ctrl.connect_wq[line]);
+
+ /* The timeout routine doesn't have a hendle to our=20
+ session status, so set things up to reflect a=20
+ timeout error by default. If we really do get a=20
+ connection then this value _should_ be changed by
+ the time we wake up to reflect a good connection.
+ --gmcnutt
+ */
+ bt_ctrl.session[line].connect_status =3D -ETIMEDOUT;
+
BT_DRIVER(FNC"sleep on line %d\n", line);
interruptible_sleep_on(&bt_ctrl.connect_wq[line]);
=20
@@ -2408,6 +2431,8 @@
{
s32 found =3D 0;
=20
+ printk(__FUNCTION__ ": line =3D %d (gjm)\n", line);
+
if (!bt_stack_initiated) {
D_WARN("bt_register_sdp : Bluetooth stack not initialized\n");
return -1;=09
@@ -2686,8 +2711,7 @@
#else
struct wait_queue **wq =3D (struct wait_queue **)ptr;
#endif /* LINUX_VERSION_CODE */
-
- //printk("wq_timeout wq 0x%x\n", wq);
+ DSYS(__FUNCTION__"\n");
=20
/* wake up wait queue */
wake_up_interruptible(wq);
|