2.6.29-rc5+: usb bluetooth crashes system

2.6.29-rc5+: usb bluetooth crashes system

[Pavel Machek]

Hi!

Since switch to 2.6.29-rc, bluetooth crashes system... usually on
disconnect or killall pppd.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Greg KH]

On Tue, Mar 10, 2009 at 12:23:07PM +0100, Pavel Machek wrote:
> Hi!
> 
> Since switch to 2.6.29-rc, bluetooth crashes system... usually on
> disconnect or killall pppd.

Do we have a trace?

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Rafael J. Wysocki]

On Tuesday 10 March 2009, Pavel Machek wrote:
> Hi!
> 
> Since switch to 2.6.29-rc, bluetooth crashes system... usually on
> disconnect or killall pppd.

OK, I _guess_ you have switched from 2.6.28.

Thanks,
Rafael

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Pavel Machek]

On Fri 2009-03-13 20:48:52, Greg KH wrote:
> On Tue, Mar 10, 2009 at 12:23:07PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > Since switch to 2.6.29-rc, bluetooth crashes system... usually on
> > disconnect or killall pppd.
> 
> Do we have a trace?

We have "bad magic" message, see bugzilla. I guess it is use of
spinlock after free?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Marcel Holtmann]

Hi Pavel,

>>> Since switch to 2.6.29-rc, bluetooth crashes system... usually on
>>> disconnect or killall pppd.
>>
>> Do we have a trace?
>
> We have "bad magic" message, see bugzilla. I guess it is use of
> spinlock after free?

can you double check with the net-next-2.6 or bluetooth-next-2.6 tree  
and see if that issue is still present.

Regards

Marcel

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Pavel Machek]

On Tue 2009-03-17 10:39:54, Marcel Holtmann wrote:
> Hi Pavel,
>
>>>> Since switch to 2.6.29-rc, bluetooth crashes system... usually on
>>>> disconnect or killall pppd.
>>>
>>> Do we have a trace?
>>
>> We have "bad magic" message, see bugzilla. I guess it is use of
>> spinlock after free?
>
> can you double check with the net-next-2.6 or bluetooth-next-2.6 tree  
> and see if that issue is still present.

Well, I took btusb.c from 2.6.28 and that fixed the issue; so we know
the regression is in btusb.c file between 28 and 29-rc7. If you have
specific version of btusb.c you want me to test, please mail it to me.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Marcel Holtmann]

Hi Oliver,

> > > Well, I took btusb.c from 2.6.28 and that fixed the issue; so we know
> > > the regression is in btusb.c file between 28 and 29-rc7. If you have
> > > specific version of btusb.c you want me to test, please mail it to me.
> >
> > This smaller patch (partial revert of btusb.c to 2.6.28 state) seems
> > to help, too....
> 
> Could you test whether reversing the changes to btusb_probe() alone
> helps?

just test net-next-2.6 or latest Linus' tree once he pulled the
networking changes from Dave.

We had to partly revert that change for some hardware. Believe it or
not, but some Bluetooth chips don't work if we don't submit the bulk
URBs along with the interrupt URBs.

Regards

Marcel

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Pavel Machek]

Hi!

> >>>> Since switch to 2.6.29-rc, bluetooth crashes system... usually on
> >>>> disconnect or killall pppd.
> >>>
> >>> Do we have a trace?
> >>
> >> We have "bad magic" message, see bugzilla. I guess it is use of
> >> spinlock after free?
> >
> > can you double check with the net-next-2.6 or bluetooth-next-2.6 tree  
> > and see if that issue is still present.
> 
> Well, I took btusb.c from 2.6.28 and that fixed the issue; so we know
> the regression is in btusb.c file between 28 and 29-rc7. If you have
> specific version of btusb.c you want me to test, please mail it to me.

This smaller patch (partial revert of btusb.c to 2.6.28 state) seems
to help, too....

									Pavel
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b5fbda6..75f9fc0 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -655,19 +680,8 @@ static void btusb_notify(struct hci_dev *hdev, unsigned int evt)
 
 	BT_DBG("%s evt %d", hdev->name, evt);
 
-	if (hdev->conn_hash.acl_num > 0) {
-		if (!test_and_set_bit(BTUSB_BULK_RUNNING, &data->flags)) {
-			if (btusb_submit_bulk_urb(hdev, GFP_ATOMIC) < 0)
-				clear_bit(BTUSB_BULK_RUNNING, &data->flags);
-			else
-				btusb_submit_bulk_urb(hdev, GFP_ATOMIC);
-		}
-	} else {
-		clear_bit(BTUSB_BULK_RUNNING, &data->flags);
-		usb_unlink_anchored_urbs(&data->bulk_anchor);
-	}
-
-	schedule_work(&data->work);
+	if (evt == HCI_NOTIFY_CONN_ADD || evt == HCI_NOTIFY_CONN_DEL)
+		schedule_work(&data->work);
 }
 
 static int inline __set_isoc_interface(struct hci_dev *hdev, int altsetting)
@@ -718,6 +732,18 @@ static void btusb_work(struct work_struct *work)
 	struct btusb_data *data = container_of(work, struct btusb_data, work);
 	struct hci_dev *hdev = data->hdev;
 
+	if (hdev->conn_hash.acl_num > 0) {
+		if (!test_and_set_bit(BTUSB_BULK_RUNNING, &data->flags)) {
+			if (btusb_submit_bulk_urb(hdev) < 0)
+				clear_bit(BTUSB_BULK_RUNNING, &data->flags);
+			else
+				btusb_submit_bulk_urb(hdev);
+		}
+	} else {
+		clear_bit(BTUSB_BULK_RUNNING, &data->flags);
+		usb_kill_anchored_urbs(&data->bulk_anchor);
+	}
+
 	if (hdev->conn_hash.sco_num > 0) {
 		if (data->isoc_altsetting != 2) {
 			clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
@@ -852,23 +876,9 @@ static int btusb_probe(struct usb_interface *intf,
 	if (id->driver_info & BTUSB_BROKEN_ISOC)
 		data->isoc = NULL;
 
-	if (id->driver_info & BTUSB_DIGIANSWER) {
-		data->cmdreq_type = USB_TYPE_VENDOR;
-		set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
-	}
-
-	if (id->driver_info & BTUSB_CSR) {
-		struct usb_device *udev = data->udev;
-
-		/* Old firmware would otherwise execute USB reset */
-		if (le16_to_cpu(udev->descriptor.bcdDevice) < 0x117)
-			set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
-	}
-
 	if (id->driver_info & BTUSB_SNIFFER) {
 		struct usb_device *udev = data->udev;
 
-		/* New sniffer firmware has crippled HCI interface */
 		if (le16_to_cpu(udev->descriptor.bcdDevice) > 0x997)
 			set_bit(HCI_QUIRK_RAW_DEVICE, &hdev->quirks);
 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.29-rc5+: usb bluetooth crashes system

[Oliver Neukum]

Am Donnerstag 26 März 2009 10:58:56 schrieb Pavel Machek:

> > Well, I took btusb.c from 2.6.28 and that fixed the issue; so we know
> > the regression is in btusb.c file between 28 and 29-rc7. If you have
> > specific version of btusb.c you want me to test, please mail it to me.
>
> This smaller patch (partial revert of btusb.c to 2.6.28 state) seems
> to help, too....

Could you test whether reversing the changes to btusb_probe() alone
helps?

	Regards
		Oliver