All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
@ 2013-07-18 13:21 Nestor Lopez Casado
  2013-07-18 13:21 ` [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set Nestor Lopez Casado
                   ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Nestor Lopez Casado @ 2013-07-18 13:21 UTC (permalink / raw)
  To: jkosina
  Cc: benjamin.tissoires, adlr, joseph.salisbury, linux-input,
	linux-kernel, Nestor Lopez Casado

This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.

This patch re-adds the workaround introduced by 596264082f10dd4
which was reverted by 8af6c08830b1ae114.

The original patch 596264 was needed to overcome a situation where
the hid-core would drop incoming reports while probe() was being
executed.

This issue was solved by c849a6143bec520af which added
hid_device_io_start() and hid_device_io_stop() that enable a specific
hid driver to opt-in for input reports while its probe() is being
executed.

Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
functionality added to hid-core. Having done that, workaround 596264
was no longer necessary and was reverted by 8af6c08.

We now encounter a different problem that ends up 'again' thwarting
the Unifying receiver enumeration. The problem is time and usb controller
dependent. Ocasionally the reports sent to the usb receiver to start
the paired devices enumeration fail with -EPIPE and the receiver never
gets to enumerate the paired devices.

With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
driver became asynchronous and none was catching the error from the
failing URB.

As the root cause for this failing SET_REPORT is not understood yet,
-possibly a race on the usb controller drivers or a problem with the
Unifying receiver- reintroducing this workaround solves the problem.

Overall what this workaround does is: If an input report from an
unknown device is received, then a (re)enumeration is performed.

related bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649

Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
---
 drivers/hid/hid-logitech-dj.c |   45 +++++++++++++++++++++++++++++++++++++++++
 drivers/hid/hid-logitech-dj.h |    1 +
 2 files changed, 46 insertions(+)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index db3192b..0d13389 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -192,6 +192,7 @@ static struct hid_ll_driver logi_dj_ll_driver;
 static int logi_dj_output_hidraw_report(struct hid_device *hid, u8 * buf,
 					size_t count,
 					unsigned char report_type);
+static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev);
 
 static void logi_dj_recv_destroy_djhid_device(struct dj_receiver_dev *djrcv_dev,
 						struct dj_report *dj_report)
@@ -232,6 +233,7 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
 	if (dj_report->report_params[DEVICE_PAIRED_PARAM_SPFUNCTION] &
 	    SPFUNCTION_DEVICE_LIST_EMPTY) {
 		dbg_hid("%s: device list is empty\n", __func__);
+		djrcv_dev->querying_devices = false;
 		return;
 	}
 
@@ -242,6 +244,12 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
 		return;
 	}
 
+	if (djrcv_dev->paired_dj_devices[dj_report->device_index]) {
+		/* The device is already known. No need to reallocate it. */
+		dbg_hid("%s: device is already known\n", __func__);
+		return;
+	}
+
 	dj_hiddev = hid_allocate_device();
 	if (IS_ERR(dj_hiddev)) {
 		dev_err(&djrcv_hdev->dev, "%s: hid_allocate_device failed\n",
@@ -305,6 +313,7 @@ static void delayedwork_callback(struct work_struct *work)
 	struct dj_report dj_report;
 	unsigned long flags;
 	int count;
+	int retval;
 
 	dbg_hid("%s\n", __func__);
 
@@ -337,6 +346,25 @@ static void delayedwork_callback(struct work_struct *work)
 		logi_dj_recv_destroy_djhid_device(djrcv_dev, &dj_report);
 		break;
 	default:
+	/* A normal report (i. e. not belonging to a pair/unpair notification)
+	 * arriving here, means that the report arrived but we did not have a
+	 * paired dj_device associated to the report's device_index, this
+	 * means that the original "device paired" notification corresponding
+	 * to this dj_device never arrived to this driver. The reason is that
+	 * hid-core discards all packets coming from a device while probe() is
+	 * executing. */
+	if (!djrcv_dev->paired_dj_devices[dj_report.device_index]) {
+		/* ok, we don't know the device, just re-ask the
+		 * receiver for the list of connected devices. */
+		retval = logi_dj_recv_query_paired_devices(djrcv_dev);
+		if (!retval) {
+			/* everything went fine, so just leave */
+			break;
+		}
+		dev_err(&djrcv_dev->hdev->dev,
+			"%s:logi_dj_recv_query_paired_devices "
+			"error:%d\n", __func__, retval);
+		}
 		dbg_hid("%s: unexpected report type\n", __func__);
 	}
 }
@@ -367,6 +395,12 @@ static void logi_dj_recv_forward_null_report(struct dj_receiver_dev *djrcv_dev,
 	if (!djdev) {
 		dbg_hid("djrcv_dev->paired_dj_devices[dj_report->device_index]"
 			" is NULL, index %d\n", dj_report->device_index);
+		kfifo_in(&djrcv_dev->notif_fifo, dj_report, sizeof(struct dj_report));
+
+		if (schedule_work(&djrcv_dev->work) == 0) {
+			dbg_hid("%s: did not schedule the work item, was already "
+			"queued\n", __func__);
+		}
 		return;
 	}
 
@@ -397,6 +431,12 @@ static void logi_dj_recv_forward_report(struct dj_receiver_dev *djrcv_dev,
 	if (dj_device == NULL) {
 		dbg_hid("djrcv_dev->paired_dj_devices[dj_report->device_index]"
 			" is NULL, index %d\n", dj_report->device_index);
+		kfifo_in(&djrcv_dev->notif_fifo, dj_report, sizeof(struct dj_report));
+
+		if (schedule_work(&djrcv_dev->work) == 0) {
+			dbg_hid("%s: did not schedule the work item, was already "
+			"queued\n", __func__);
+		}
 		return;
 	}
 
@@ -444,6 +484,10 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
 	struct dj_report *dj_report;
 	int retval;
 
+	/* no need to protect djrcv_dev->querying_devices */
+	if (djrcv_dev->querying_devices)
+		return 0;
+
 	dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
 	if (!dj_report)
 		return -ENOMEM;
@@ -455,6 +499,7 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
 	return retval;
 }
 
+
 static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
 					  unsigned timeout)
 {
diff --git a/drivers/hid/hid-logitech-dj.h b/drivers/hid/hid-logitech-dj.h
index fd28a5e..4a40003 100644
--- a/drivers/hid/hid-logitech-dj.h
+++ b/drivers/hid/hid-logitech-dj.h
@@ -101,6 +101,7 @@ struct dj_receiver_dev {
 	struct work_struct work;
 	struct kfifo notif_fifo;
 	spinlock_t lock;
+	bool querying_devices;
 };
 
 struct dj_device {
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-07-18 13:21 [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Nestor Lopez Casado
@ 2013-07-18 13:21 ` Nestor Lopez Casado
  2013-08-01 10:09   ` Benjamin Tissoires
  2013-07-18 20:28 ` [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Peter Hurley
  2013-07-22 14:35 ` Jiri Kosina
  2 siblings, 1 reply; 32+ messages in thread
From: Nestor Lopez Casado @ 2013-07-18 13:21 UTC (permalink / raw)
  To: jkosina
  Cc: benjamin.tissoires, adlr, joseph.salisbury, linux-input,
	linux-kernel, Nestor Lopez Casado

Set querying_devices flag to true when we start the enumeration
process.

This was missing from the original patch. It never produced
undesirable effects as it is highly improbable to have a second
enumeration triggered while a first one was still in progress.

Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
---
 drivers/hid/hid-logitech-dj.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 0d13389..d4657a5 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -488,6 +488,8 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
 	if (djrcv_dev->querying_devices)
 		return 0;
 
+	djrcv_dev->querying_devices = true;
+
 	dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
 	if (!dj_report)
 		return -ENOMEM;
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 13:21 [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Nestor Lopez Casado
  2013-07-18 13:21 ` [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set Nestor Lopez Casado
@ 2013-07-18 20:28 ` Peter Hurley
  2013-07-18 22:09   ` Sarah Sharp
  2013-08-12 21:54   ` Peter Wu
  2013-07-22 14:35 ` Jiri Kosina
  2 siblings, 2 replies; 32+ messages in thread
From: Peter Hurley @ 2013-07-18 20:28 UTC (permalink / raw)
  To: Nestor Lopez Casado
  Cc: jkosina, benjamin.tissoires, adlr, joseph.salisbury, linux-input,
	linux-kernel, Sarah Sharp, linux-usb

[ +cc Sarah Sharp, linux-usb ]

On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
> This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
>
> This patch re-adds the workaround introduced by 596264082f10dd4
> which was reverted by 8af6c08830b1ae114.
>
> The original patch 596264 was needed to overcome a situation where
> the hid-core would drop incoming reports while probe() was being
> executed.
>
> This issue was solved by c849a6143bec520af which added
> hid_device_io_start() and hid_device_io_stop() that enable a specific
> hid driver to opt-in for input reports while its probe() is being
> executed.
>
> Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
> functionality added to hid-core. Having done that, workaround 596264
> was no longer necessary and was reverted by 8af6c08.
>
> We now encounter a different problem that ends up 'again' thwarting
> the Unifying receiver enumeration. The problem is time and usb controller
> dependent. Ocasionally the reports sent to the usb receiver to start
> the paired devices enumeration fail with -EPIPE and the receiver never
> gets to enumerate the paired devices.
>
> With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
> driver became asynchronous and none was catching the error from the
> failing URB.
>
> As the root cause for this failing SET_REPORT is not understood yet,
> -possibly a race on the usb controller drivers or a problem with the
> Unifying receiver- reintroducing this workaround solves the problem.


Before we revert to using the workaround, I'd like to suggest that
this new "hidden" problem may be an interaction with the xhci_hcd host
controller driver only.

Looking at the related bug, the OP indicates the machine only has
USB3 ports. Additionally, comments #7, #100, and #104 of the original
bug report [1] add additional information that would seem to confirm
this suspicion.

Let me add I have this USB device running on the uhci_hcd driver
with or without this workaround on v3.10.


> Overall what this workaround does is: If an input report from an
> unknown device is received, then a (re)enumeration is performed.
>
> related bug:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649

I thought I saw someone reporting this problem recently on LKML;
where is the Reported-by so that Sarah can follow-up with the
reporter directly, if desired?

Regards,
Peter Hurley

[1]
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143


> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
> ---
>   drivers/hid/hid-logitech-dj.c |   45 +++++++++++++++++++++++++++++++++++++++++
>   drivers/hid/hid-logitech-dj.h |    1 +
>   2 files changed, 46 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index db3192b..0d13389 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -192,6 +192,7 @@ static struct hid_ll_driver logi_dj_ll_driver;
>   static int logi_dj_output_hidraw_report(struct hid_device *hid, u8 * buf,
>   					size_t count,
>   					unsigned char report_type);
> +static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev);
>
>   static void logi_dj_recv_destroy_djhid_device(struct dj_receiver_dev *djrcv_dev,
>   						struct dj_report *dj_report)
> @@ -232,6 +233,7 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
>   	if (dj_report->report_params[DEVICE_PAIRED_PARAM_SPFUNCTION] &
>   	    SPFUNCTION_DEVICE_LIST_EMPTY) {
>   		dbg_hid("%s: device list is empty\n", __func__);
> +		djrcv_dev->querying_devices = false;
>   		return;
>   	}
>
> @@ -242,6 +244,12 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
>   		return;
>   	}
>
> +	if (djrcv_dev->paired_dj_devices[dj_report->device_index]) {
> +		/* The device is already known. No need to reallocate it. */
> +		dbg_hid("%s: device is already known\n", __func__);
> +		return;
> +	}
> +
>   	dj_hiddev = hid_allocate_device();
>   	if (IS_ERR(dj_hiddev)) {
>   		dev_err(&djrcv_hdev->dev, "%s: hid_allocate_device failed\n",
> @@ -305,6 +313,7 @@ static void delayedwork_callback(struct work_struct *work)
>   	struct dj_report dj_report;
>   	unsigned long flags;
>   	int count;
> +	int retval;
>
>   	dbg_hid("%s\n", __func__);
>
> @@ -337,6 +346,25 @@ static void delayedwork_callback(struct work_struct *work)
>   		logi_dj_recv_destroy_djhid_device(djrcv_dev, &dj_report);
>   		break;
>   	default:
> +	/* A normal report (i. e. not belonging to a pair/unpair notification)
> +	 * arriving here, means that the report arrived but we did not have a
> +	 * paired dj_device associated to the report's device_index, this
> +	 * means that the original "device paired" notification corresponding
> +	 * to this dj_device never arrived to this driver. The reason is that
> +	 * hid-core discards all packets coming from a device while probe() is
> +	 * executing. */
> +	if (!djrcv_dev->paired_dj_devices[dj_report.device_index]) {
> +		/* ok, we don't know the device, just re-ask the
> +		 * receiver for the list of connected devices. */
> +		retval = logi_dj_recv_query_paired_devices(djrcv_dev);
> +		if (!retval) {
> +			/* everything went fine, so just leave */
> +			break;
> +		}
> +		dev_err(&djrcv_dev->hdev->dev,
> +			"%s:logi_dj_recv_query_paired_devices "
> +			"error:%d\n", __func__, retval);
> +		}
>   		dbg_hid("%s: unexpected report type\n", __func__);
>   	}
>   }
> @@ -367,6 +395,12 @@ static void logi_dj_recv_forward_null_report(struct dj_receiver_dev *djrcv_dev,
>   	if (!djdev) {
>   		dbg_hid("djrcv_dev->paired_dj_devices[dj_report->device_index]"
>   			" is NULL, index %d\n", dj_report->device_index);
> +		kfifo_in(&djrcv_dev->notif_fifo, dj_report, sizeof(struct dj_report));
> +
> +		if (schedule_work(&djrcv_dev->work) == 0) {
> +			dbg_hid("%s: did not schedule the work item, was already "
> +			"queued\n", __func__);
> +		}
>   		return;
>   	}
>
> @@ -397,6 +431,12 @@ static void logi_dj_recv_forward_report(struct dj_receiver_dev *djrcv_dev,
>   	if (dj_device == NULL) {
>   		dbg_hid("djrcv_dev->paired_dj_devices[dj_report->device_index]"
>   			" is NULL, index %d\n", dj_report->device_index);
> +		kfifo_in(&djrcv_dev->notif_fifo, dj_report, sizeof(struct dj_report));
> +
> +		if (schedule_work(&djrcv_dev->work) == 0) {
> +			dbg_hid("%s: did not schedule the work item, was already "
> +			"queued\n", __func__);
> +		}
>   		return;
>   	}
>
> @@ -444,6 +484,10 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
>   	struct dj_report *dj_report;
>   	int retval;
>
> +	/* no need to protect djrcv_dev->querying_devices */
> +	if (djrcv_dev->querying_devices)
> +		return 0;
> +
>   	dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
>   	if (!dj_report)
>   		return -ENOMEM;
> @@ -455,6 +499,7 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
>   	return retval;
>   }
>
> +
>   static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
>   					  unsigned timeout)
>   {
> diff --git a/drivers/hid/hid-logitech-dj.h b/drivers/hid/hid-logitech-dj.h
> index fd28a5e..4a40003 100644
> --- a/drivers/hid/hid-logitech-dj.h
> +++ b/drivers/hid/hid-logitech-dj.h
> @@ -101,6 +101,7 @@ struct dj_receiver_dev {
>   	struct work_struct work;
>   	struct kfifo notif_fifo;
>   	spinlock_t lock;
> +	bool querying_devices;
>   };
>
>   struct dj_device {
>


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 20:28 ` [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Peter Hurley
@ 2013-07-18 22:09   ` Sarah Sharp
  2013-07-18 23:37     ` Peter Hurley
                       ` (2 more replies)
  2013-08-12 21:54   ` Peter Wu
  1 sibling, 3 replies; 32+ messages in thread
From: Sarah Sharp @ 2013-07-18 22:09 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Nestor Lopez Casado, jkosina, benjamin.tissoires, adlr,
	joseph.salisbury, linux-input, linux-kernel, linux-usb

On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
> [ +cc Sarah Sharp, linux-usb ]
> 
> On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
> >This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
> >
> >This patch re-adds the workaround introduced by 596264082f10dd4
> >which was reverted by 8af6c08830b1ae114.
> >
> >The original patch 596264 was needed to overcome a situation where
> >the hid-core would drop incoming reports while probe() was being
> >executed.
> >
> >This issue was solved by c849a6143bec520af which added
> >hid_device_io_start() and hid_device_io_stop() that enable a specific
> >hid driver to opt-in for input reports while its probe() is being
> >executed.
> >
> >Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
> >functionality added to hid-core. Having done that, workaround 596264
> >was no longer necessary and was reverted by 8af6c08.
> >
> >We now encounter a different problem that ends up 'again' thwarting
> >the Unifying receiver enumeration. The problem is time and usb controller
> >dependent. Ocasionally the reports sent to the usb receiver to start
> >the paired devices enumeration fail with -EPIPE and the receiver never
> >gets to enumerate the paired devices.
> >
> >With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
> >driver became asynchronous and none was catching the error from the
> >failing URB.
> >
> >As the root cause for this failing SET_REPORT is not understood yet,
> >-possibly a race on the usb controller drivers or a problem with the
> >Unifying receiver- reintroducing this workaround solves the problem.
> 
> 
> Before we revert to using the workaround, I'd like to suggest that
> this new "hidden" problem may be an interaction with the xhci_hcd host
> controller driver only.
> 
> Looking at the related bug, the OP indicates the machine only has
> USB3 ports. Additionally, comments #7, #100, and #104 of the original
> bug report [1] add additional information that would seem to confirm
> this suspicion.

Question: does this USB device need a control transfer to reset its
endpoints when the endpoints are not actually halted?  If so, yes, that
is a known xHCI driver bug that needs to be fixed.  The xHCI host will
not accept a Reset Endpoint command when the endpoints are not actually
halted, but the USB core will send the control transfer to reset the
endpoint.  That means the device and host toggles will be out of sync,
and all messages will start to fail with -EPIPE.

Can the OP capture a usbmon trace when the device starts failing?  That
will reveal whether this actually is the issue.  dmesg output with
CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on would also
be helpful.

Sarah Sharp

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 22:09   ` Sarah Sharp
@ 2013-07-18 23:37     ` Peter Hurley
  2013-07-19  8:35       ` Benjamin Tissoires
  2013-07-19 14:38       ` Joseph Salisbury
  2013-07-19 15:14       ` Alan Stern
  2013-07-19 16:43     ` Nestor Lopez Casado
  2 siblings, 2 replies; 32+ messages in thread
From: Peter Hurley @ 2013-07-18 23:37 UTC (permalink / raw)
  To: Sarah Sharp, joseph.salisbury
  Cc: Nestor Lopez Casado, jkosina, benjamin.tissoires, adlr,
	linux-input, linux-kernel, linux-usb

On 07/18/2013 06:09 PM, Sarah Sharp wrote:
> On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
>> [ +cc Sarah Sharp, linux-usb ]
>>
>> On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
>>> This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
>>>
>>> This patch re-adds the workaround introduced by 596264082f10dd4
>>> which was reverted by 8af6c08830b1ae114.
>>>
>>> The original patch 596264 was needed to overcome a situation where
>>> the hid-core would drop incoming reports while probe() was being
>>> executed.
>>>
>>> This issue was solved by c849a6143bec520af which added
>>> hid_device_io_start() and hid_device_io_stop() that enable a specific
>>> hid driver to opt-in for input reports while its probe() is being
>>> executed.
>>>
>>> Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
>>> functionality added to hid-core. Having done that, workaround 596264
>>> was no longer necessary and was reverted by 8af6c08.
>>>
>>> We now encounter a different problem that ends up 'again' thwarting
>>> the Unifying receiver enumeration. The problem is time and usb controller
>>> dependent. Ocasionally the reports sent to the usb receiver to start
>>> the paired devices enumeration fail with -EPIPE and the receiver never
>>> gets to enumerate the paired devices.
>>>
>>> With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
>>> driver became asynchronous and none was catching the error from the
>>> failing URB.
>>>
>>> As the root cause for this failing SET_REPORT is not understood yet,
>>> -possibly a race on the usb controller drivers or a problem with the
>>> Unifying receiver- reintroducing this workaround solves the problem.
>>
>>
>> Before we revert to using the workaround, I'd like to suggest that
>> this new "hidden" problem may be an interaction with the xhci_hcd host
>> controller driver only.
>>
>> Looking at the related bug, the OP indicates the machine only has
>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>> bug report [1] add additional information that would seem to confirm
>> this suspicion.
>
> Question: does this USB device need a control transfer to reset its
> endpoints when the endpoints are not actually halted?  If so, yes, that
> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
> not accept a Reset Endpoint command when the endpoints are not actually
> halted, but the USB core will send the control transfer to reset the
> endpoint.  That means the device and host toggles will be out of sync,
> and all messages will start to fail with -EPIPE.
>
> Can the OP capture a usbmon trace when the device starts failing?  That
> will reveal whether this actually is the issue.  dmesg output with
> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on would also
> be helpful.

Sarah,

I forwarded your usbmon capture request to the OP in the bug report
(I don't have an email address for the reporter).

As far as getting printk output from a custom kernel, I think that may
be beyond the reporter's capability. Perhaps one of the Ubuntu devs
triaging this bug could provide a test kernel for the OP with those
options on.

Joseph, would you be willing to do that?

Regards,
Peter Hurley

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 23:37     ` Peter Hurley
@ 2013-07-19  8:35       ` Benjamin Tissoires
  2013-07-19 14:38       ` Joseph Salisbury
  1 sibling, 0 replies; 32+ messages in thread
From: Benjamin Tissoires @ 2013-07-19  8:35 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Sarah Sharp, joseph.salisbury, Nestor Lopez Casado, Jiri Kosina,
	Andrew de los Reyes, linux-input, linux-kernel, linux-usb,
	wujun zhou, Linus Torvalds

Hi Peter,

thanks for forwarding this to the appropriate people & mailing list.

Hi Sarah,

thanks for starting investigating this :)

On Fri, Jul 19, 2013 at 1:37 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>>
>>>
>>>
>>> Before we revert to using the workaround, I'd like to suggest that
>>> this new "hidden" problem may be an interaction with the xhci_hcd host
>>> controller driver only.
>>>
>>> Looking at the related bug, the OP indicates the machine only has
>>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>>> bug report [1] add additional information that would seem to confirm
>>> this suspicion.

Definitively, this is a USB3 problem. However, it is not generic (I
can not reproduce it with my USB3 boards.)

>>
>>
>> Question: does this USB device need a control transfer to reset its
>> endpoints when the endpoints are not actually halted?  If so, yes, that
>> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
>> not accept a Reset Endpoint command when the endpoints are not actually
>> halted, but the USB core will send the control transfer to reset the
>> endpoint.  That means the device and host toggles will be out of sync,
>> and all messages will start to fail with -EPIPE.
>>
>> Can the OP capture a usbmon trace when the device starts failing?  That
>> will reveal whether this actually is the issue.  dmesg output with
>> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on would also
>> be helpful.
>

Here is another linux-input thread were you have the usbmon traces:
http://www.spinics.net/lists/linux-input/msg26542.html
Wujun Zhou already did one test of a kernel patch for me (which did
not solve the problem, because I was not at the USB level), so I bet
he will be able to do some testings for you.

In the logs he posted (logitech_work.pcapng.gz), the interesting part
is starting from the capture #45:

#45: SET_REPORT request to switch the receiver to the "DJ" mode (the
receiver stops sending regular HID events, but goes into its
proprietary protocol)
#47: SET_REPORT response -> all good
#48: SET_REPORT request to ask the receiver to enumerate all of his
devices (it is called right after we received the previous response)
#49: SET_REPORT response -> -EPIPE
#50: URB_INTERRUPT_IN (~3 seconds later) -> the device is working normally

The weird thing is that only the first enumeration message failed with
-EPIPE: the device answers later control transfer correctly (#54 /
#55).

>
> Sarah,
>
> I forwarded your usbmon capture request to the OP in the bug report
> (I don't have an email address for the reporter).
>

Here are some other helpful information:
the first "fix" we have done is dcd9006b1b053c7b1c. It is linked to
several bugs:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143
https://bugzilla.redhat.com/show_bug.cgi?id=840391
https://bugzilla.kernel.org/show_bug.cgi?id=49781

Most of them are people complaining, but in one of the comments,
adding a 500ms wait between the two control transfer (switch to DJ +
enumerate) fixed the -EPIPE problem. I interpreted it as a scheduled
problem (using direct call to usb_control_msg() vs use the scheduled
one usbhid_submit_message()) but it was just delaying the problem out
of the probe. Unfortunately, I missed that as I did not asked for the
usbmon traces at that time.

One last thing, I understood that Linus is also experiencing this
problem... Adding him in CC to let him know of the progress.

Cheers,
Benjamin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 23:37     ` Peter Hurley
  2013-07-19  8:35       ` Benjamin Tissoires
@ 2013-07-19 14:38       ` Joseph Salisbury
  2013-07-19 21:31         ` Peter Hurley
  1 sibling, 1 reply; 32+ messages in thread
From: Joseph Salisbury @ 2013-07-19 14:38 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Sarah Sharp, Nestor Lopez Casado, jkosina, benjamin.tissoires,
	adlr, linux-input, linux-kernel, linux-usb

On 07/18/2013 07:37 PM, Peter Hurley wrote:
> On 07/18/2013 06:09 PM, Sarah Sharp wrote:
>> On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
>>> [ +cc Sarah Sharp, linux-usb ]
>>>
>>> On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
>>>> This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
>>>>
>>>> This patch re-adds the workaround introduced by 596264082f10dd4
>>>> which was reverted by 8af6c08830b1ae114.
>>>>
>>>> The original patch 596264 was needed to overcome a situation where
>>>> the hid-core would drop incoming reports while probe() was being
>>>> executed.
>>>>
>>>> This issue was solved by c849a6143bec520af which added
>>>> hid_device_io_start() and hid_device_io_stop() that enable a specific
>>>> hid driver to opt-in for input reports while its probe() is being
>>>> executed.
>>>>
>>>> Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
>>>> functionality added to hid-core. Having done that, workaround 596264
>>>> was no longer necessary and was reverted by 8af6c08.
>>>>
>>>> We now encounter a different problem that ends up 'again' thwarting
>>>> the Unifying receiver enumeration. The problem is time and usb
>>>> controller
>>>> dependent. Ocasionally the reports sent to the usb receiver to start
>>>> the paired devices enumeration fail with -EPIPE and the receiver never
>>>> gets to enumerate the paired devices.
>>>>
>>>> With dcd9006b1b053c7b1c the problem was "hidden" as the call to the
>>>> usb
>>>> driver became asynchronous and none was catching the error from the
>>>> failing URB.
>>>>
>>>> As the root cause for this failing SET_REPORT is not understood yet,
>>>> -possibly a race on the usb controller drivers or a problem with the
>>>> Unifying receiver- reintroducing this workaround solves the problem.
>>>
>>>
>>> Before we revert to using the workaround, I'd like to suggest that
>>> this new "hidden" problem may be an interaction with the xhci_hcd host
>>> controller driver only.
>>>
>>> Looking at the related bug, the OP indicates the machine only has
>>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>>> bug report [1] add additional information that would seem to confirm
>>> this suspicion.
>>
>> Question: does this USB device need a control transfer to reset its
>> endpoints when the endpoints are not actually halted?  If so, yes, that
>> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
>> not accept a Reset Endpoint command when the endpoints are not actually
>> halted, but the USB core will send the control transfer to reset the
>> endpoint.  That means the device and host toggles will be out of sync,
>> and all messages will start to fail with -EPIPE.
>>
>> Can the OP capture a usbmon trace when the device starts failing?  That
>> will reveal whether this actually is the issue.  dmesg output with
>> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on would also
>> be helpful.
>
> Sarah,
>
> I forwarded your usbmon capture request to the OP in the bug report
> (I don't have an email address for the reporter).
>
> As far as getting printk output from a custom kernel, I think that may
> be beyond the reporter's capability. Perhaps one of the Ubuntu devs
> triaging this bug could provide a test kernel for the OP with those
> options on.
>
> Joseph, would you be willing to do that?

Sure thing.  I'll build a kernel and request that the bug reporter
collect usbmon data.

Thanks everyone for the feedback!

>
> Regards,
> Peter Hurley


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 22:09   ` Sarah Sharp
@ 2013-07-19 15:14       ` Alan Stern
  2013-07-19 15:14       ` Alan Stern
  2013-07-19 16:43     ` Nestor Lopez Casado
  2 siblings, 0 replies; 32+ messages in thread
From: Alan Stern @ 2013-07-19 15:14 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Peter Hurley, Nestor Lopez Casado, jkosina, benjamin.tissoires,
	adlr, joseph.salisbury, linux-input, linux-kernel, linux-usb

On Thu, 18 Jul 2013, Sarah Sharp wrote:

> Question: does this USB device need a control transfer to reset its
> endpoints when the endpoints are not actually halted?  If so, yes, that
> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
> not accept a Reset Endpoint command when the endpoints are not actually
> halted, but the USB core will send the control transfer to reset the
> endpoint.  That means the device and host toggles will be out of sync,
> and all messages will start to fail with -EPIPE.

Why -EPIPE?  Isn't that code reserved to indicate a STALL?

In fact, there's no way to detect a toggle mismatch problem with a 
USB-2 device.  Packets with the wrong toggle value are simply ignored 
(or acknowledged and ignored).  The problem ends up appearing as an 
indefinite delay (for an IN transfer) or as data lost (for an OUT 
transfer).

I don't know what happens with USB-3 devices when the sequence numbers 
get out of alignment.

Alan Stern


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
@ 2013-07-19 15:14       ` Alan Stern
  0 siblings, 0 replies; 32+ messages in thread
From: Alan Stern @ 2013-07-19 15:14 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Peter Hurley, Nestor Lopez Casado, jkosina, benjamin.tissoires,
	adlr, joseph.salisbury, linux-input, linux-kernel, linux-usb

On Thu, 18 Jul 2013, Sarah Sharp wrote:

> Question: does this USB device need a control transfer to reset its
> endpoints when the endpoints are not actually halted?  If so, yes, that
> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
> not accept a Reset Endpoint command when the endpoints are not actually
> halted, but the USB core will send the control transfer to reset the
> endpoint.  That means the device and host toggles will be out of sync,
> and all messages will start to fail with -EPIPE.

Why -EPIPE?  Isn't that code reserved to indicate a STALL?

In fact, there's no way to detect a toggle mismatch problem with a 
USB-2 device.  Packets with the wrong toggle value are simply ignored 
(or acknowledged and ignored).  The problem ends up appearing as an 
indefinite delay (for an IN transfer) or as data lost (for an OUT 
transfer).

I don't know what happens with USB-3 devices when the sequence numbers 
get out of alignment.

Alan Stern

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 22:09   ` Sarah Sharp
  2013-07-18 23:37     ` Peter Hurley
  2013-07-19 15:14       ` Alan Stern
@ 2013-07-19 16:43     ` Nestor Lopez Casado
  2 siblings, 0 replies; 32+ messages in thread
From: Nestor Lopez Casado @ 2013-07-19 16:43 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Peter Hurley, Jiri Kosina, Benjamin Tissoires,
	Andrew de los Reyes, Joseph Salisbury, open list:HID CORE LAYER,
	linux-kernel, linux-usb

Hi Sarah,

On Fri, Jul 19, 2013 at 12:09 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
>> [ +cc Sarah Sharp, linux-usb ]
>>
>> On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
>> >This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
>> >
>> >This patch re-adds the workaround introduced by 596264082f10dd4
>> >which was reverted by 8af6c08830b1ae114.
>> >
>> >The original patch 596264 was needed to overcome a situation where
>> >the hid-core would drop incoming reports while probe() was being
>> >executed.
>> >
>> >This issue was solved by c849a6143bec520af which added
>> >hid_device_io_start() and hid_device_io_stop() that enable a specific
>> >hid driver to opt-in for input reports while its probe() is being
>> >executed.
>> >
>> >Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
>> >functionality added to hid-core. Having done that, workaround 596264
>> >was no longer necessary and was reverted by 8af6c08.
>> >
>> >We now encounter a different problem that ends up 'again' thwarting
>> >the Unifying receiver enumeration. The problem is time and usb controller
>> >dependent. Ocasionally the reports sent to the usb receiver to start
>> >the paired devices enumeration fail with -EPIPE and the receiver never
>> >gets to enumerate the paired devices.
>> >
>> >With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
>> >driver became asynchronous and none was catching the error from the
>> >failing URB.
>> >
>> >As the root cause for this failing SET_REPORT is not understood yet,
>> >-possibly a race on the usb controller drivers or a problem with the
>> >Unifying receiver- reintroducing this workaround solves the problem.
>>
>>
>> Before we revert to using the workaround, I'd like to suggest that
>> this new "hidden" problem may be an interaction with the xhci_hcd host
>> controller driver only.
>>
>> Looking at the related bug, the OP indicates the machine only has
>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>> bug report [1] add additional information that would seem to confirm
>> this suspicion.
>
> Question: does this USB device need a control transfer to reset its
> endpoints when the endpoints are not actually halted?  If so, yes, that
> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
> not accept a Reset Endpoint command when the endpoints are not actually
> halted, but the USB core will send the control transfer to reset the
> endpoint.  That means the device and host toggles will be out of sync,
> and all messages will start to fail with -EPIPE.

Could you re-phrase your question providing a bit more detail? I don't
quite get the idea.

>
> Can the OP capture a usbmon trace when the device starts failing?  That
> will reveal whether this actually is the issue.  dmesg output with
> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on would also
> be helpful.
>
> Sarah Sharp

Cheers,
Nestor

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-19 14:38       ` Joseph Salisbury
@ 2013-07-19 21:31         ` Peter Hurley
  2013-07-22 11:44           ` Jiri Kosina
  0 siblings, 1 reply; 32+ messages in thread
From: Peter Hurley @ 2013-07-19 21:31 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Joseph Salisbury, Nestor Lopez Casado, jkosina,
	benjamin.tissoires, adlr, linux-input, linux-kernel, linux-usb

[-- Attachment #1: Type: text/plain, Size: 4278 bytes --]

On 07/19/2013 10:38 AM, Joseph Salisbury wrote:
> On 07/18/2013 07:37 PM, Peter Hurley wrote:
>> On 07/18/2013 06:09 PM, Sarah Sharp wrote:
>>> On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
>>>> [ +cc Sarah Sharp, linux-usb ]
>>>>
>>>> On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
>>>>> This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
>>>>>
>>>>> This patch re-adds the workaround introduced by 596264082f10dd4
>>>>> which was reverted by 8af6c08830b1ae114.
>>>>>
>>>>> The original patch 596264 was needed to overcome a situation where
>>>>> the hid-core would drop incoming reports while probe() was being
>>>>> executed.
>>>>>
>>>>> This issue was solved by c849a6143bec520af which added
>>>>> hid_device_io_start() and hid_device_io_stop() that enable a specific
>>>>> hid driver to opt-in for input reports while its probe() is being
>>>>> executed.
>>>>>
>>>>> Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
>>>>> functionality added to hid-core. Having done that, workaround 596264
>>>>> was no longer necessary and was reverted by 8af6c08.
>>>>>
>>>>> We now encounter a different problem that ends up 'again' thwarting
>>>>> the Unifying receiver enumeration. The problem is time and usb
>>>>> controller
>>>>> dependent. Ocasionally the reports sent to the usb receiver to start
>>>>> the paired devices enumeration fail with -EPIPE and the receiver never
>>>>> gets to enumerate the paired devices.
>>>>>
>>>>> With dcd9006b1b053c7b1c the problem was "hidden" as the call to the
>>>>> usb
>>>>> driver became asynchronous and none was catching the error from the
>>>>> failing URB.
>>>>>
>>>>> As the root cause for this failing SET_REPORT is not understood yet,
>>>>> -possibly a race on the usb controller drivers or a problem with the
>>>>> Unifying receiver- reintroducing this workaround solves the problem.
>>>>
>>>>
>>>> Before we revert to using the workaround, I'd like to suggest that
>>>> this new "hidden" problem may be an interaction with the xhci_hcd host
>>>> controller driver only.
>>>>
>>>> Looking at the related bug, the OP indicates the machine only has
>>>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>>>> bug report [1] add additional information that would seem to confirm
>>>> this suspicion.
>>>
>>> Question: does this USB device need a control transfer to reset its
>>> endpoints when the endpoints are not actually halted?  If so, yes, that
>>> is a known xHCI driver bug that needs to be fixed.  The xHCI host will
>>> not accept a Reset Endpoint command when the endpoints are not actually
>>> halted, but the USB core will send the control transfer to reset the
>>> endpoint.  That means the device and host toggles will be out of sync,
>>> and all messages will start to fail with -EPIPE.
>>>
>>> Can the OP capture a usbmon trace when the device starts failing?  That
>>> will reveal whether this actually is the issue.  dmesg output with
>>> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on would also
>>> be helpful.
>>
>> Sarah,
>>
>> I forwarded your usbmon capture request to the OP in the bug report
>> (I don't have an email address for the reporter).
>>
>> As far as getting printk output from a custom kernel, I think that may
>> be beyond the reporter's capability. Perhaps one of the Ubuntu devs
>> triaging this bug could provide a test kernel for the OP with those
>> options on.
>>
>> Joseph, would you be willing to do that?
>
> Sure thing.  I'll build a kernel and request that the bug reporter
> collect usbmon data.

Thanks Joseph for building the test kernel and getting it to the reporter!

Sarah,

I've attached the dmesg capture supplied by the original reporter on
a 3.10 custom kernel w/ the kbuild options you requested.

It seems as if your initial suspicion is correct:

[   46.785490] xhci_hcd 0000:00:14.0: Endpoint 0x81 not halted, refusing to reset.
[   46.785493] xhci_hcd 0000:00:14.0: Endpoint 0x82 not halted, refusing to reset.
[   46.785496] xhci_hcd 0000:00:14.0: Endpoint 0x83 not halted, refusing to reset.
[   46.785952] xhci_hcd 0000:00:14.0: Waiting for status stage event

At this point, would you recommend proceeding with the workaround or
waiting for an xHCI bug fix?

Regards,
Peter Hurley

[-- Attachment #2: dmesg.logitech_bug.reported_20130719 --]
[-- Type: text/plain, Size: 81441 bytes --]


[   23.866692] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.868677] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.874676] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.882670] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.890666] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.898664] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.906659] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.912656] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.920653] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.928647] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.936644] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.944638] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.952636] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.990618] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   23.998611] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.005391] show_signal_msg: 147 callbacks suppressed
[   24.005397] SyncThread[2394]: segfault at 98 ip 00000000004931b6 sp 00007fde948a22d0 error 4 in python2.7[400000+2bb000]
[   24.006606] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.014605] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.022600] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.030595] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.038592] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.046589] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.054584] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.062580] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.070574] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.078571] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.084569] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.092566] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.100581] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.108568] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.116546] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.124552] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.132548] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.140535] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.148548] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.156526] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.162525] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.170539] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.178518] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.186513] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.194507] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.202519] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.210500] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.218494] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.226490] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.234483] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.242482] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.248478] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.256474] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.264472] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.272464] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.280462] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.288456] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.296455] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.304449] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.312471] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.320441] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.326440] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.334432] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.342431] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.350428] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.358422] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.366443] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.374435] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.382428] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.390425] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.398422] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.406396] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.412393] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.420393] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.428388] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.436385] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.444394] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.452392] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.460366] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.468368] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.476360] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.484355] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.492352] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.498348] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.506345] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.514340] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.522336] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.530334] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.538331] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.546325] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.554324] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.562315] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.570333] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.576308] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.584307] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.592304] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.600296] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.608309] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.616305] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.624300] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.632296] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.640276] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.648289] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.654286] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.662297] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.670261] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.678257] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.686253] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.694250] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.702243] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.710239] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.718261] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.726255] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.734251] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.742243] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.748243] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.756232] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.764231] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.772225] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.780228] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.788217] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.796213] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.804216] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.812210] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.820206] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.826203] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.834198] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.842206] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.850185] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.858196] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.866159] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.874153] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.882169] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.890170] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.898160] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.904154] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.912158] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.924144] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.928147] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.936145] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.946141] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.952137] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.960133] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.968129] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.976121] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.984120] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.990117] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   24.998114] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.006109] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.014105] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.022101] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.030096] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.038092] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.048088] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.054084] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.062079] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.070068] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.076073] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.084069] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.092060] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.100063] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.108053] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.116052] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.124045] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.132036] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.140037] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.148010] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.156006] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.162027] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.170016] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.178015] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.185991] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.194004] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.202000] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.209996] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.217991] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.225987] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.233966] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.241961] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.247958] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.255953] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.263950] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.271945] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.279940] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.287937] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.295932] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.303930] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.311924] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.319921] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.325917] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.333933] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.341908] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   25.357902] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   31.160736] [UFW AUDIT] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:64:b7:04:1a:08:00 SRC=172.25.129.119 DST=172.25.131.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=209 
[   31.161323] [UFW AUDIT] IN= OUT=eth0 SRC=172.25.131.137 DST=172.25.131.255 LEN=223 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=203 
[   31.161328] [UFW ALLOW] IN= OUT=eth0 SRC=172.25.131.137 DST=172.25.131.255 LEN=223 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=203 
[   33.727105] [UFW AUDIT] IN=eth0 OUT= MAC=33:33:00:00:00:fb:00:25:64:b7:04:1a:86:dd SRC=fe80:0000:0000:0000:0225:64ff:feb7:041a DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=87 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=47 
[   36.009704] type=1400 audit(1374263651.347:61): apparmor="DENIED" operation="open" parent=1891 profile="/usr/lib/telepathy/telepathy-*" name="/usr/share/p11-kit/modules/" pid=2516 comm="telepathy-gabbl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[   36.136689] [UFW AUDIT] IN= OUT=eth0 SRC=fe80:0000:0000:0000:3285:a9ff:fe07:c33a DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=310 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=270 
[   36.136695] [UFW ALLOW] IN= OUT=eth0 SRC=fe80:0000:0000:0000:3285:a9ff:fe07:c33a DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=310 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=270 
[   36.257734] type=1400 audit(1374263651.595:62): apparmor="DENIED" operation="capable" parent=1891 profile="/usr/lib/telepathy/telepathy-*" pid=2508 comm="telepathy-haze" pid=2508 comm="telepathy-haze" capability=19  capname="sys_ptrace"
[   36.257739] type=1400 audit(1374263651.595:63): apparmor="DENIED" operation="ptrace" parent=1891 profile="/usr/lib/telepathy/telepathy-*" pid=2508 comm="telepathy-haze" target=B412400E0488FFFFB412400E0488FFFF1004410E0488FFFF1004410E0488FFFF2004410E0488FFFF2004410E0488FFFF2807
[   44.062295] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.070198] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.078196] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.086192] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.094178] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.102182] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.110176] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.118173] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.126169] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.134164] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.142160] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.148156] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.156168] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.164162] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.172149] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.188135] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.196129] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.204128] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.212123] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.220119] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.226116] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.234114] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.242107] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   44.511961] xhci_hcd 0000:00:14.0: Transfer error on endpoint
[   44.511967] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   44.511968] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   44.511970] xhci_hcd 0000:00:14.0: Finding endpoint context
[   44.511971] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   44.511972] xhci_hcd 0000:00:14.0: Cycle state = 0x0
[   44.511973] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880402ee90e0 (virtual)
[   44.511974] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x36443570 (DMA)
[   44.511976] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   44.511977] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880402ee90e0 (0x36443400 dma), new deq ptr = ffff880036443570 (0x36443570 dma), new cycle = 0
[   44.511979] xhci_hcd 0000:00:14.0: // Ding dong!
[   44.511982] xhci_hcd 0000:00:14.0: Giveback URB ffff880403987480, len = 0, expected = 32, status = -71
[   44.511986] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   44.511988] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @36443570
[   44.514791] xhci_hcd 0000:00:14.0: Port Status Change Event for port 4
[   44.514796] xhci_hcd 0000:00:14.0: handle_port_status: starting port polling.
[   44.514826] hub 3-0:1.0: state 7 ports 4 chg 0000 evt 0010
[   44.514832] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x202a0
[   44.514833] xhci_hcd 0000:00:14.0: Get port status returned 0x10100
[   44.514839] xhci_hcd 0000:00:14.0: clear port connect change, actual port 3 status  = 0x2a0
[   44.514844] hub 3-0:1.0: port 4, status 0100, change 0001, 12 Mb/s
[   44.514846] usb 3-4: USB disconnect, device number 3
[   44.514847] usb 3-4: unregistering device
[   44.514849] usb 3-4: unregistering interface 3-4:1.0
[   44.514922] usb 3-4: unregistering interface 3-4:1.1
[   44.514965] usb 3-4: unregistering interface 3-4:1.2
[   44.515002] usbhid 3-4:1.2: removing 0 minor
[   44.515152] usb 3-4: usb_disable_device nuking all URBs
[   44.515156] xhci_hcd 0000:00:14.0: xhci_drop_endpoint called for udev ffff88040e447800
[   44.515159] xhci_hcd 0000:00:14.0: drop ep 0x81, slot id 2, new drop flags = 0x8, new add flags = 0x0, new slot info = 0x8100000
[   44.515162] xhci_hcd 0000:00:14.0: xhci_drop_endpoint called for udev ffff88040e447800
[   44.515164] xhci_hcd 0000:00:14.0: drop ep 0x82, slot id 2, new drop flags = 0x28, new add flags = 0x0, new slot info = 0x8100000
[   44.515167] xhci_hcd 0000:00:14.0: xhci_drop_endpoint called for udev ffff88040e447800
[   44.515169] xhci_hcd 0000:00:14.0: drop ep 0x83, slot id 2, new drop flags = 0xa8, new add flags = 0x0, new slot info = 0x8100000
[   44.515172] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev ffff88040e447800
[   44.515174] xhci_hcd 0000:00:14.0: New Input Control Context:
[   44.515176] xhci_hcd 0000:00:14.0: @ffff88003643f000 (virt) @3643f000 (dma) 0x0000a8 - drop flags
[   44.515179] xhci_hcd 0000:00:14.0: @ffff88003643f004 (virt) @3643f004 (dma) 0x000001 - add flags
[   44.515181] xhci_hcd 0000:00:14.0: @ffff88003643f008 (virt) @3643f008 (dma) 0x000000 - rsvd2[0]
[   44.515183] xhci_hcd 0000:00:14.0: @ffff88003643f00c (virt) @3643f00c (dma) 0x000000 - rsvd2[1]
[   44.515186] xhci_hcd 0000:00:14.0: @ffff88003643f010 (virt) @3643f010 (dma) 0x000000 - rsvd2[2]
[   44.515188] xhci_hcd 0000:00:14.0: @ffff88003643f014 (virt) @3643f014 (dma) 0x000000 - rsvd2[3]
[   44.515190] xhci_hcd 0000:00:14.0: @ffff88003643f018 (virt) @3643f018 (dma) 0x000000 - rsvd2[4]
[   44.515192] xhci_hcd 0000:00:14.0: @ffff88003643f01c (virt) @3643f01c (dma) 0x000000 - rsvd2[5]
[   44.515194] xhci_hcd 0000:00:14.0: Slot Context:
[   44.515197] xhci_hcd 0000:00:14.0: @ffff88003643f020 (virt) @3643f020 (dma) 0x8100000 - dev_info
[   44.515199] xhci_hcd 0000:00:14.0: @ffff88003643f024 (virt) @3643f024 (dma) 0x040000 - dev_info2
[   44.515201] xhci_hcd 0000:00:14.0: @ffff88003643f028 (virt) @3643f028 (dma) 0x000000 - tt_info
[   44.515204] xhci_hcd 0000:00:14.0: @ffff88003643f02c (virt) @3643f02c (dma) 0x000000 - dev_state
[   44.515206] xhci_hcd 0000:00:14.0: @ffff88003643f030 (virt) @3643f030 (dma) 0x000000 - rsvd[0]
[   44.515208] xhci_hcd 0000:00:14.0: @ffff88003643f034 (virt) @3643f034 (dma) 0x000000 - rsvd[1]
[   44.515210] xhci_hcd 0000:00:14.0: @ffff88003643f038 (virt) @3643f038 (dma) 0x000000 - rsvd[2]
[   44.515213] xhci_hcd 0000:00:14.0: @ffff88003643f03c (virt) @3643f03c (dma) 0x000000 - rsvd[3]
[   44.515215] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   44.515217] xhci_hcd 0000:00:14.0: @ffff88003643f040 (virt) @3643f040 (dma) 0x000001 - ep_info
[   44.515219] xhci_hcd 0000:00:14.0: @ffff88003643f044 (virt) @3643f044 (dma) 0x080026 - ep_info2
[   44.515221] xhci_hcd 0000:00:14.0: @ffff88003643f048 (virt) @3643f048 (dma) 0x36440001 - deq
[   44.515224] xhci_hcd 0000:00:14.0: @ffff88003643f050 (virt) @3643f050 (dma) 0x000000 - tx_info
[   44.515226] xhci_hcd 0000:00:14.0: @ffff88003643f054 (virt) @3643f054 (dma) 0x000000 - rsvd[0]
[   44.515228] xhci_hcd 0000:00:14.0: @ffff88003643f058 (virt) @3643f058 (dma) 0x000000 - rsvd[1]
[   44.515230] xhci_hcd 0000:00:14.0: @ffff88003643f05c (virt) @3643f05c (dma) 0x000000 - rsvd[2]
[   44.515233] xhci_hcd 0000:00:14.0: Adding 0 ep ctxs, 6 now active.
[   44.515236] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 4
[   44.515239] xhci_hcd 0000:00:14.0: Final bandwidth: 0, Limit: 1285, Reserved: 129, Available: 89 percent
[   44.515241] xhci_hcd 0000:00:14.0: // Ding dong!
[   44.515292] xhci_hcd 0000:00:14.0: Completed config ep cmd
[   44.515300] usb 3-4: Successful Endpoint Configure command
[   44.515302] xhci_hcd 0000:00:14.0: Removing 3 dropped ep ctxs, 3 now active.
[   44.515304] xhci_hcd 0000:00:14.0: Output context after successful config ep cmd:
[   44.515306] xhci_hcd 0000:00:14.0: Slot Context:
[   44.515309] xhci_hcd 0000:00:14.0: @ffff88003643e000 (virt) @3643e000 (dma) 0x8100000 - dev_info
[   44.515311] xhci_hcd 0000:00:14.0: @ffff88003643e004 (virt) @3643e004 (dma) 0x040000 - dev_info2
[   44.515313] xhci_hcd 0000:00:14.0: @ffff88003643e008 (virt) @3643e008 (dma) 0x000000 - tt_info
[   44.515315] xhci_hcd 0000:00:14.0: @ffff88003643e00c (virt) @3643e00c (dma) 0x10000002 - dev_state
[   44.515317] xhci_hcd 0000:00:14.0: @ffff88003643e010 (virt) @3643e010 (dma) 0x000000 - rsvd[0]
[   44.515320] xhci_hcd 0000:00:14.0: @ffff88003643e014 (virt) @3643e014 (dma) 0x000000 - rsvd[1]
[   44.515322] xhci_hcd 0000:00:14.0: @ffff88003643e018 (virt) @3643e018 (dma) 0x000000 - rsvd[2]
[   44.515324] xhci_hcd 0000:00:14.0: @ffff88003643e01c (virt) @3643e01c (dma) 0x000000 - rsvd[3]
[   44.515327] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   44.515329] xhci_hcd 0000:00:14.0: @ffff88003643e020 (virt) @3643e020 (dma) 0x000003 - ep_info
[   44.515331] xhci_hcd 0000:00:14.0: @ffff88003643e024 (virt) @3643e024 (dma) 0x080026 - ep_info2
[   44.515333] xhci_hcd 0000:00:14.0: @ffff88003643e028 (virt) @3643e028 (dma) 0x36440451 - deq
[   44.515335] xhci_hcd 0000:00:14.0: @ffff88003643e030 (virt) @3643e030 (dma) 0x000000 - tx_info
[   44.515337] xhci_hcd 0000:00:14.0: @ffff88003643e034 (virt) @3643e034 (dma) 0x000000 - rsvd[0]
[   44.515340] xhci_hcd 0000:00:14.0: @ffff88003643e038 (virt) @3643e038 (dma) 0x000000 - rsvd[1]
[   44.515342] xhci_hcd 0000:00:14.0: @ffff88003643e03c (virt) @3643e03c (dma) 0x000000 - rsvd[2]
[   44.515345] xhci_hcd 0000:00:14.0: Cached old ring, 1 ring cached
[   44.515347] xhci_hcd 0000:00:14.0: Cached old ring, 2 rings cached
[   44.515349] xhci_hcd 0000:00:14.0: Cached old ring, 3 rings cached
[   44.515438] xhci_hcd 0000:00:14.0: // Ding dong!
[   44.515446] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x2a0
[   44.515448] xhci_hcd 0000:00:14.0: Get port status returned 0x100
[   44.515452] xhci_hcd 0000:00:14.0: Dropped 1 ep ctxs, flags = 0x1, 2 now active.
[   44.545964] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x2a0
[   44.545967] xhci_hcd 0000:00:14.0: Get port status returned 0x100
[   44.577965] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x2a0
[   44.577968] xhci_hcd 0000:00:14.0: Get port status returned 0x100
[   44.610036] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x2a0
[   44.610044] xhci_hcd 0000:00:14.0: Get port status returned 0x100
[   44.641965] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x2a0
[   44.641968] xhci_hcd 0000:00:14.0: Get port status returned 0x100
[   44.641972] hub 3-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x100
[   44.737957] xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping port polling.
[   46.528329] xhci_hcd 0000:00:14.0: Port Status Change Event for port 4
[   46.528341] xhci_hcd 0000:00:14.0: handle_port_status: starting port polling.
[   46.528394] hub 3-0:1.0: state 7 ports 4 chg 0000 evt 0010
[   46.528400] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x206e1
[   46.528402] xhci_hcd 0000:00:14.0: Get port status returned 0x10101
[   46.528408] xhci_hcd 0000:00:14.0: clear port connect change, actual port 3 status  = 0x6e1
[   46.528411] hub 3-0:1.0: port 4, status 0101, change 0001, 12 Mb/s
[   46.528415] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x6e1
[   46.528419] xhci_hcd 0000:00:14.0: Get port status returned 0x101
[   46.558011] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x6e1
[   46.558028] xhci_hcd 0000:00:14.0: Get port status returned 0x101
[   46.590005] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x6e1
[   46.590013] xhci_hcd 0000:00:14.0: Get port status returned 0x101
[   46.622005] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x6e1
[   46.622013] xhci_hcd 0000:00:14.0: Get port status returned 0x101
[   46.654002] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x6e1
[   46.654010] xhci_hcd 0000:00:14.0: Get port status returned 0x101
[   46.654026] hub 3-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x101
[   46.654029] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.654055] xhci_hcd 0000:00:14.0: Adding 1 ep ctx, 3 now active.
[   46.654059] xhci_hcd 0000:00:14.0: Slot 3 output ctx = 0x3643f000 (dma)
[   46.654060] xhci_hcd 0000:00:14.0: Slot 3 input ctx = 0x3643e000 (dma)
[   46.654064] xhci_hcd 0000:00:14.0: Set slot id 3 dcbaa entry ffff880036406018 to 0x3643f000
[   46.654073] xhci_hcd 0000:00:14.0: set port reset, actual port 3 status  = 0x791
[   46.709242] xhci_hcd 0000:00:14.0: Port Status Change Event for port 4
[   46.709254] xhci_hcd 0000:00:14.0: handle_port_status: starting port polling.
[   46.709966] xhci_hcd 0000:00:14.0: get port status, actual port 3 status  = 0x200603
[   46.709973] xhci_hcd 0000:00:14.0: Get port status returned 0x100103
[   46.765941] xhci_hcd 0000:00:14.0: clear port reset change, actual port 3 status  = 0x603
[   46.765948] usb 3-4: new full-speed USB device number 4 using xhci_hcd
[   46.765951] xhci_hcd 0000:00:14.0: Set root hub portnum to 4
[   46.765952] xhci_hcd 0000:00:14.0: Set fake root hub portnum to 4
[   46.765953] xhci_hcd 0000:00:14.0: udev->tt = ffff880403fbb4a0
[   46.765954] xhci_hcd 0000:00:14.0: udev->ttport = 0x4
[   46.765956] xhci_hcd 0000:00:14.0: Slot ID 3 Input Context:
[   46.765957] xhci_hcd 0000:00:14.0: @ffff88003643e000 (virt) @3643e000 (dma) 0x000000 - drop flags
[   46.765959] xhci_hcd 0000:00:14.0: @ffff88003643e004 (virt) @3643e004 (dma) 0x000003 - add flags
[   46.765960] xhci_hcd 0000:00:14.0: @ffff88003643e008 (virt) @3643e008 (dma) 0x000000 - rsvd2[0]
[   46.765962] xhci_hcd 0000:00:14.0: @ffff88003643e00c (virt) @3643e00c (dma) 0x000000 - rsvd2[1]
[   46.765963] xhci_hcd 0000:00:14.0: @ffff88003643e010 (virt) @3643e010 (dma) 0x000000 - rsvd2[2]
[   46.765964] xhci_hcd 0000:00:14.0: @ffff88003643e014 (virt) @3643e014 (dma) 0x000000 - rsvd2[3]
[   46.765965] xhci_hcd 0000:00:14.0: @ffff88003643e018 (virt) @3643e018 (dma) 0x000000 - rsvd2[4]
[   46.765967] xhci_hcd 0000:00:14.0: @ffff88003643e01c (virt) @3643e01c (dma) 0x000000 - rsvd2[5]
[   46.765968] xhci_hcd 0000:00:14.0: Slot Context:
[   46.765969] xhci_hcd 0000:00:14.0: @ffff88003643e020 (virt) @3643e020 (dma) 0x8100000 - dev_info
[   46.765970] xhci_hcd 0000:00:14.0: @ffff88003643e024 (virt) @3643e024 (dma) 0x040000 - dev_info2
[   46.765972] xhci_hcd 0000:00:14.0: @ffff88003643e028 (virt) @3643e028 (dma) 0x000000 - tt_info
[   46.765973] xhci_hcd 0000:00:14.0: @ffff88003643e02c (virt) @3643e02c (dma) 0x000000 - dev_state
[   46.765974] xhci_hcd 0000:00:14.0: @ffff88003643e030 (virt) @3643e030 (dma) 0x000000 - rsvd[0]
[   46.765975] xhci_hcd 0000:00:14.0: @ffff88003643e034 (virt) @3643e034 (dma) 0x000000 - rsvd[1]
[   46.765977] xhci_hcd 0000:00:14.0: @ffff88003643e038 (virt) @3643e038 (dma) 0x000000 - rsvd[2]
[   46.765978] xhci_hcd 0000:00:14.0: @ffff88003643e03c (virt) @3643e03c (dma) 0x000000 - rsvd[3]
[   46.765979] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.765980] xhci_hcd 0000:00:14.0: @ffff88003643e040 (virt) @3643e040 (dma) 0x000000 - ep_info
[   46.765982] xhci_hcd 0000:00:14.0: @ffff88003643e044 (virt) @3643e044 (dma) 0x400026 - ep_info2
[   46.765983] xhci_hcd 0000:00:14.0: @ffff88003643e048 (virt) @3643e048 (dma) 0x36443001 - deq
[   46.765984] xhci_hcd 0000:00:14.0: @ffff88003643e050 (virt) @3643e050 (dma) 0x000000 - tx_info
[   46.765986] xhci_hcd 0000:00:14.0: @ffff88003643e054 (virt) @3643e054 (dma) 0x000000 - rsvd[0]
[   46.765987] xhci_hcd 0000:00:14.0: @ffff88003643e058 (virt) @3643e058 (dma) 0x000000 - rsvd[1]
[   46.765988] xhci_hcd 0000:00:14.0: @ffff88003643e05c (virt) @3643e05c (dma) 0x000000 - rsvd[2]
[   46.765989] xhci_hcd 0000:00:14.0: Endpoint 01 Context:
[   46.765990] xhci_hcd 0000:00:14.0: @ffff88003643e060 (virt) @3643e060 (dma) 0x000000 - ep_info
[   46.765992] xhci_hcd 0000:00:14.0: @ffff88003643e064 (virt) @3643e064 (dma) 0x000000 - ep_info2
[   46.765993] xhci_hcd 0000:00:14.0: @ffff88003643e068 (virt) @3643e068 (dma) 0x000000 - deq
[   46.765994] xhci_hcd 0000:00:14.0: @ffff88003643e070 (virt) @3643e070 (dma) 0x000000 - tx_info
[   46.765995] xhci_hcd 0000:00:14.0: @ffff88003643e074 (virt) @3643e074 (dma) 0x000000 - rsvd[0]
[   46.765997] xhci_hcd 0000:00:14.0: @ffff88003643e078 (virt) @3643e078 (dma) 0x000000 - rsvd[1]
[   46.765998] xhci_hcd 0000:00:14.0: @ffff88003643e07c (virt) @3643e07c (dma) 0x000000 - rsvd[2]
[   46.765999] xhci_hcd 0000:00:14.0: Endpoint 02 Context:
[   46.766000] xhci_hcd 0000:00:14.0: @ffff88003643e080 (virt) @3643e080 (dma) 0x000000 - ep_info
[   46.766001] xhci_hcd 0000:00:14.0: @ffff88003643e084 (virt) @3643e084 (dma) 0x000000 - ep_info2
[   46.766003] xhci_hcd 0000:00:14.0: @ffff88003643e088 (virt) @3643e088 (dma) 0x000000 - deq
[   46.766004] xhci_hcd 0000:00:14.0: @ffff88003643e090 (virt) @3643e090 (dma) 0x000000 - tx_info
[   46.766005] xhci_hcd 0000:00:14.0: @ffff88003643e094 (virt) @3643e094 (dma) 0x000000 - rsvd[0]
[   46.766006] xhci_hcd 0000:00:14.0: @ffff88003643e098 (virt) @3643e098 (dma) 0x000000 - rsvd[1]
[   46.766008] xhci_hcd 0000:00:14.0: @ffff88003643e09c (virt) @3643e09c (dma) 0x000000 - rsvd[2]
[   46.766010] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.766085] xhci_hcd 0000:00:14.0: Successful Address Device command
[   46.766090] xhci_hcd 0000:00:14.0: Op regs DCBAA ptr = 0x00000036406000
[   46.766092] xhci_hcd 0000:00:14.0: Slot ID 3 dcbaa entry @ffff880036406018 = 0x0000003643f000
[   46.766093] xhci_hcd 0000:00:14.0: Output Context DMA address = 0x3643f000
[   46.766094] xhci_hcd 0000:00:14.0: Slot ID 3 Input Context:
[   46.766096] xhci_hcd 0000:00:14.0: @ffff88003643e000 (virt) @3643e000 (dma) 0x000000 - drop flags
[   46.766097] xhci_hcd 0000:00:14.0: @ffff88003643e004 (virt) @3643e004 (dma) 0x000003 - add flags
[   46.766099] xhci_hcd 0000:00:14.0: @ffff88003643e008 (virt) @3643e008 (dma) 0x000000 - rsvd2[0]
[   46.766100] xhci_hcd 0000:00:14.0: @ffff88003643e00c (virt) @3643e00c (dma) 0x000000 - rsvd2[1]
[   46.766101] xhci_hcd 0000:00:14.0: @ffff88003643e010 (virt) @3643e010 (dma) 0x000000 - rsvd2[2]
[   46.766103] xhci_hcd 0000:00:14.0: @ffff88003643e014 (virt) @3643e014 (dma) 0x000000 - rsvd2[3]
[   46.766104] xhci_hcd 0000:00:14.0: @ffff88003643e018 (virt) @3643e018 (dma) 0x000000 - rsvd2[4]
[   46.766105] xhci_hcd 0000:00:14.0: @ffff88003643e01c (virt) @3643e01c (dma) 0x000000 - rsvd2[5]
[   46.766106] xhci_hcd 0000:00:14.0: Slot Context:
[   46.766107] xhci_hcd 0000:00:14.0: @ffff88003643e020 (virt) @3643e020 (dma) 0x8100000 - dev_info
[   46.766109] xhci_hcd 0000:00:14.0: @ffff88003643e024 (virt) @3643e024 (dma) 0x040000 - dev_info2
[   46.766110] xhci_hcd 0000:00:14.0: @ffff88003643e028 (virt) @3643e028 (dma) 0x000000 - tt_info
[   46.766111] xhci_hcd 0000:00:14.0: @ffff88003643e02c (virt) @3643e02c (dma) 0x000000 - dev_state
[   46.766112] xhci_hcd 0000:00:14.0: @ffff88003643e030 (virt) @3643e030 (dma) 0x000000 - rsvd[0]
[   46.766114] xhci_hcd 0000:00:14.0: @ffff88003643e034 (virt) @3643e034 (dma) 0x000000 - rsvd[1]
[   46.766115] xhci_hcd 0000:00:14.0: @ffff88003643e038 (virt) @3643e038 (dma) 0x000000 - rsvd[2]
[   46.766116] xhci_hcd 0000:00:14.0: @ffff88003643e03c (virt) @3643e03c (dma) 0x000000 - rsvd[3]
[   46.766117] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.766119] xhci_hcd 0000:00:14.0: @ffff88003643e040 (virt) @3643e040 (dma) 0x000000 - ep_info
[   46.766120] xhci_hcd 0000:00:14.0: @ffff88003643e044 (virt) @3643e044 (dma) 0x400026 - ep_info2
[   46.766121] xhci_hcd 0000:00:14.0: @ffff88003643e048 (virt) @3643e048 (dma) 0x36443001 - deq
[   46.766122] xhci_hcd 0000:00:14.0: @ffff88003643e050 (virt) @3643e050 (dma) 0x000000 - tx_info
[   46.766124] xhci_hcd 0000:00:14.0: @ffff88003643e054 (virt) @3643e054 (dma) 0x000000 - rsvd[0]
[   46.766125] xhci_hcd 0000:00:14.0: @ffff88003643e058 (virt) @3643e058 (dma) 0x000000 - rsvd[1]
[   46.766126] xhci_hcd 0000:00:14.0: @ffff88003643e05c (virt) @3643e05c (dma) 0x000000 - rsvd[2]
[   46.766127] xhci_hcd 0000:00:14.0: Endpoint 01 Context:
[   46.766129] xhci_hcd 0000:00:14.0: @ffff88003643e060 (virt) @3643e060 (dma) 0x000000 - ep_info
[   46.766130] xhci_hcd 0000:00:14.0: @ffff88003643e064 (virt) @3643e064 (dma) 0x000000 - ep_info2
[   46.766131] xhci_hcd 0000:00:14.0: @ffff88003643e068 (virt) @3643e068 (dma) 0x000000 - deq
[   46.766132] xhci_hcd 0000:00:14.0: @ffff88003643e070 (virt) @3643e070 (dma) 0x000000 - tx_info
[   46.766134] xhci_hcd 0000:00:14.0: @ffff88003643e074 (virt) @3643e074 (dma) 0x000000 - rsvd[0]
[   46.766135] xhci_hcd 0000:00:14.0: @ffff88003643e078 (virt) @3643e078 (dma) 0x000000 - rsvd[1]
[   46.766136] xhci_hcd 0000:00:14.0: @ffff88003643e07c (virt) @3643e07c (dma) 0x000000 - rsvd[2]
[   46.766137] xhci_hcd 0000:00:14.0: Endpoint 02 Context:
[   46.766138] xhci_hcd 0000:00:14.0: @ffff88003643e080 (virt) @3643e080 (dma) 0x000000 - ep_info
[   46.766140] xhci_hcd 0000:00:14.0: @ffff88003643e084 (virt) @3643e084 (dma) 0x000000 - ep_info2
[   46.766141] xhci_hcd 0000:00:14.0: @ffff88003643e088 (virt) @3643e088 (dma) 0x000000 - deq
[   46.766142] xhci_hcd 0000:00:14.0: @ffff88003643e090 (virt) @3643e090 (dma) 0x000000 - tx_info
[   46.766143] xhci_hcd 0000:00:14.0: @ffff88003643e094 (virt) @3643e094 (dma) 0x000000 - rsvd[0]
[   46.766145] xhci_hcd 0000:00:14.0: @ffff88003643e098 (virt) @3643e098 (dma) 0x000000 - rsvd[1]
[   46.766146] xhci_hcd 0000:00:14.0: @ffff88003643e09c (virt) @3643e09c (dma) 0x000000 - rsvd[2]
[   46.766147] xhci_hcd 0000:00:14.0: Slot ID 3 Output Context:
[   46.766148] xhci_hcd 0000:00:14.0: Slot Context:
[   46.766149] xhci_hcd 0000:00:14.0: @ffff88003643f000 (virt) @3643f000 (dma) 0x8100000 - dev_info
[   46.766150] xhci_hcd 0000:00:14.0: @ffff88003643f004 (virt) @3643f004 (dma) 0x040000 - dev_info2
[   46.766152] xhci_hcd 0000:00:14.0: @ffff88003643f008 (virt) @3643f008 (dma) 0x000000 - tt_info
[   46.766153] xhci_hcd 0000:00:14.0: @ffff88003643f00c (virt) @3643f00c (dma) 0x10000003 - dev_state
[   46.766154] xhci_hcd 0000:00:14.0: @ffff88003643f010 (virt) @3643f010 (dma) 0x000000 - rsvd[0]
[   46.766155] xhci_hcd 0000:00:14.0: @ffff88003643f014 (virt) @3643f014 (dma) 0x000000 - rsvd[1]
[   46.766157] xhci_hcd 0000:00:14.0: @ffff88003643f018 (virt) @3643f018 (dma) 0x000000 - rsvd[2]
[   46.766158] xhci_hcd 0000:00:14.0: @ffff88003643f01c (virt) @3643f01c (dma) 0x000000 - rsvd[3]
[   46.766159] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.766160] xhci_hcd 0000:00:14.0: @ffff88003643f020 (virt) @3643f020 (dma) 0x000001 - ep_info
[   46.766161] xhci_hcd 0000:00:14.0: @ffff88003643f024 (virt) @3643f024 (dma) 0x400026 - ep_info2
[   46.766163] xhci_hcd 0000:00:14.0: @ffff88003643f028 (virt) @3643f028 (dma) 0x36443001 - deq
[   46.766164] xhci_hcd 0000:00:14.0: @ffff88003643f030 (virt) @3643f030 (dma) 0x000000 - tx_info
[   46.766165] xhci_hcd 0000:00:14.0: @ffff88003643f034 (virt) @3643f034 (dma) 0x000000 - rsvd[0]
[   46.766167] xhci_hcd 0000:00:14.0: @ffff88003643f038 (virt) @3643f038 (dma) 0x000000 - rsvd[1]
[   46.766168] xhci_hcd 0000:00:14.0: @ffff88003643f03c (virt) @3643f03c (dma) 0x000000 - rsvd[2]
[   46.766169] xhci_hcd 0000:00:14.0: Endpoint 01 Context:
[   46.766170] xhci_hcd 0000:00:14.0: @ffff88003643f040 (virt) @3643f040 (dma) 0x000000 - ep_info
[   46.766172] xhci_hcd 0000:00:14.0: @ffff88003643f044 (virt) @3643f044 (dma) 0x000000 - ep_info2
[   46.766173] xhci_hcd 0000:00:14.0: @ffff88003643f048 (virt) @3643f048 (dma) 0x000000 - deq
[   46.766174] xhci_hcd 0000:00:14.0: @ffff88003643f050 (virt) @3643f050 (dma) 0x000000 - tx_info
[   46.766175] xhci_hcd 0000:00:14.0: @ffff88003643f054 (virt) @3643f054 (dma) 0x000000 - rsvd[0]
[   46.766176] xhci_hcd 0000:00:14.0: @ffff88003643f058 (virt) @3643f058 (dma) 0x000000 - rsvd[1]
[   46.766178] xhci_hcd 0000:00:14.0: @ffff88003643f05c (virt) @3643f05c (dma) 0x000000 - rsvd[2]
[   46.766179] xhci_hcd 0000:00:14.0: Endpoint 02 Context:
[   46.766180] xhci_hcd 0000:00:14.0: @ffff88003643f060 (virt) @3643f060 (dma) 0x000000 - ep_info
[   46.766181] xhci_hcd 0000:00:14.0: @ffff88003643f064 (virt) @3643f064 (dma) 0x000000 - ep_info2
[   46.766182] xhci_hcd 0000:00:14.0: @ffff88003643f068 (virt) @3643f068 (dma) 0x000000 - deq
[   46.766184] xhci_hcd 0000:00:14.0: @ffff88003643f070 (virt) @3643f070 (dma) 0x000000 - tx_info
[   46.766185] xhci_hcd 0000:00:14.0: @ffff88003643f074 (virt) @3643f074 (dma) 0x000000 - rsvd[0]
[   46.766186] xhci_hcd 0000:00:14.0: @ffff88003643f078 (virt) @3643f078 (dma) 0x000000 - rsvd[1]
[   46.766187] xhci_hcd 0000:00:14.0: @ffff88003643f07c (virt) @3643f07c (dma) 0x000000 - rsvd[2]
[   46.766188] xhci_hcd 0000:00:14.0: Internal device address = 4
[   46.782206] usb 3-4: ep0 maxpacket = 8
[   46.782220] xhci_hcd 0000:00:14.0: Max Packet Size for ep 0 changed.
[   46.782224] xhci_hcd 0000:00:14.0: Max packet size in usb_device = 8
[   46.782227] xhci_hcd 0000:00:14.0: Max packet size in xHCI HW = 64
[   46.782230] xhci_hcd 0000:00:14.0: Issuing evaluate context command.
[   46.782233] xhci_hcd 0000:00:14.0: Slot 3 input context
[   46.782238] xhci_hcd 0000:00:14.0: @ffff88003643e000 (virt) @3643e000 (dma) 0x000000 - drop flags
[   46.782250] xhci_hcd 0000:00:14.0: @ffff88003643e004 (virt) @3643e004 (dma) 0x000002 - add flags
[   46.782252] xhci_hcd 0000:00:14.0: @ffff88003643e008 (virt) @3643e008 (dma) 0x000000 - rsvd2[0]
[   46.782253] xhci_hcd 0000:00:14.0: @ffff88003643e00c (virt) @3643e00c (dma) 0x000000 - rsvd2[1]
[   46.782254] xhci_hcd 0000:00:14.0: @ffff88003643e010 (virt) @3643e010 (dma) 0x000000 - rsvd2[2]
[   46.782255] xhci_hcd 0000:00:14.0: @ffff88003643e014 (virt) @3643e014 (dma) 0x000000 - rsvd2[3]
[   46.782257] xhci_hcd 0000:00:14.0: @ffff88003643e018 (virt) @3643e018 (dma) 0x000000 - rsvd2[4]
[   46.782258] xhci_hcd 0000:00:14.0: @ffff88003643e01c (virt) @3643e01c (dma) 0x000000 - rsvd2[5]
[   46.782259] xhci_hcd 0000:00:14.0: Slot Context:
[   46.782260] xhci_hcd 0000:00:14.0: @ffff88003643e020 (virt) @3643e020 (dma) 0x8100000 - dev_info
[   46.782261] xhci_hcd 0000:00:14.0: @ffff88003643e024 (virt) @3643e024 (dma) 0x040000 - dev_info2
[   46.782263] xhci_hcd 0000:00:14.0: @ffff88003643e028 (virt) @3643e028 (dma) 0x000000 - tt_info
[   46.782264] xhci_hcd 0000:00:14.0: @ffff88003643e02c (virt) @3643e02c (dma) 0x000000 - dev_state
[   46.782265] xhci_hcd 0000:00:14.0: @ffff88003643e030 (virt) @3643e030 (dma) 0x000000 - rsvd[0]
[   46.782266] xhci_hcd 0000:00:14.0: @ffff88003643e034 (virt) @3643e034 (dma) 0x000000 - rsvd[1]
[   46.782267] xhci_hcd 0000:00:14.0: @ffff88003643e038 (virt) @3643e038 (dma) 0x000000 - rsvd[2]
[   46.782269] xhci_hcd 0000:00:14.0: @ffff88003643e03c (virt) @3643e03c (dma) 0x000000 - rsvd[3]
[   46.782270] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.782271] xhci_hcd 0000:00:14.0: @ffff88003643e040 (virt) @3643e040 (dma) 0x000001 - ep_info
[   46.782272] xhci_hcd 0000:00:14.0: @ffff88003643e044 (virt) @3643e044 (dma) 0x080026 - ep_info2
[   46.782274] xhci_hcd 0000:00:14.0: @ffff88003643e048 (virt) @3643e048 (dma) 0x36443001 - deq
[   46.782275] xhci_hcd 0000:00:14.0: @ffff88003643e050 (virt) @3643e050 (dma) 0x000000 - tx_info
[   46.782276] xhci_hcd 0000:00:14.0: @ffff88003643e054 (virt) @3643e054 (dma) 0x000000 - rsvd[0]
[   46.782277] xhci_hcd 0000:00:14.0: @ffff88003643e058 (virt) @3643e058 (dma) 0x000000 - rsvd[1]
[   46.782278] xhci_hcd 0000:00:14.0: @ffff88003643e05c (virt) @3643e05c (dma) 0x000000 - rsvd[2]
[   46.782280] xhci_hcd 0000:00:14.0: Slot 3 output context
[   46.782281] xhci_hcd 0000:00:14.0: Slot Context:
[   46.782282] xhci_hcd 0000:00:14.0: @ffff88003643f000 (virt) @3643f000 (dma) 0x8100000 - dev_info
[   46.782283] xhci_hcd 0000:00:14.0: @ffff88003643f004 (virt) @3643f004 (dma) 0x040000 - dev_info2
[   46.782284] xhci_hcd 0000:00:14.0: @ffff88003643f008 (virt) @3643f008 (dma) 0x000000 - tt_info
[   46.782285] xhci_hcd 0000:00:14.0: @ffff88003643f00c (virt) @3643f00c (dma) 0x10000003 - dev_state
[   46.782286] xhci_hcd 0000:00:14.0: @ffff88003643f010 (virt) @3643f010 (dma) 0x000000 - rsvd[0]
[   46.782288] xhci_hcd 0000:00:14.0: @ffff88003643f014 (virt) @3643f014 (dma) 0x000000 - rsvd[1]
[   46.782289] xhci_hcd 0000:00:14.0: @ffff88003643f018 (virt) @3643f018 (dma) 0x000000 - rsvd[2]
[   46.782290] xhci_hcd 0000:00:14.0: @ffff88003643f01c (virt) @3643f01c (dma) 0x000000 - rsvd[3]
[   46.782291] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.782292] xhci_hcd 0000:00:14.0: @ffff88003643f020 (virt) @3643f020 (dma) 0x000001 - ep_info
[   46.782294] xhci_hcd 0000:00:14.0: @ffff88003643f024 (virt) @3643f024 (dma) 0x400026 - ep_info2
[   46.782295] xhci_hcd 0000:00:14.0: @ffff88003643f028 (virt) @3643f028 (dma) 0x36443001 - deq
[   46.782296] xhci_hcd 0000:00:14.0: @ffff88003643f030 (virt) @3643f030 (dma) 0x000000 - tx_info
[   46.782297] xhci_hcd 0000:00:14.0: @ffff88003643f034 (virt) @3643f034 (dma) 0x000000 - rsvd[0]
[   46.782299] xhci_hcd 0000:00:14.0: @ffff88003643f038 (virt) @3643f038 (dma) 0x000000 - rsvd[1]
[   46.782300] xhci_hcd 0000:00:14.0: @ffff88003643f03c (virt) @3643f03c (dma) 0x000000 - rsvd[2]
[   46.782302] xhci_hcd 0000:00:14.0: Adding 0 ep ctxs, 3 now active.
[   46.782304] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 4
[   46.782306] xhci_hcd 0000:00:14.0: Final bandwidth: 0, Limit: 1285, Reserved: 129, Available: 89 percent
[   46.782308] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.782328] usb 3-4: Successful evaluate context command
[   46.782710] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.782718] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.782722] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.782724] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.782727] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.782730] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.782734] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.782737] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x36443090 (DMA)
[   46.782740] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.782744] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff880036443090 (0x36443090 dma), new cycle = 1
[   46.782747] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.782754] xhci_hcd 0000:00:14.0: Giveback URB ffff880402ee6540, len = 0, expected = 10, status = -32
[   46.782763] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.782767] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @36443091
[   46.782869] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.782877] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.782880] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.782883] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.782886] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.782889] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.782892] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.782895] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x364430c0 (DMA)
[   46.782898] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.782902] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff8800364430c0 (0x364430c0 dma), new cycle = 1
[   46.782906] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.782912] xhci_hcd 0000:00:14.0: Giveback URB ffff880402ee6540, len = 0, expected = 10, status = -32
[   46.782921] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.782925] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @364430c1
[   46.783030] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.783038] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.783041] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.783044] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.783047] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.783050] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.783053] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.783056] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x364430f0 (DMA)
[   46.783059] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.783063] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff8800364430f0 (0x364430f0 dma), new cycle = 1
[   46.783066] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.783073] xhci_hcd 0000:00:14.0: Giveback URB ffff880402ee6540, len = 0, expected = 10, status = -32
[   46.783081] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.783085] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @364430f1
[   46.784196] usb 3-4: skipped 1 descriptor after interface
[   46.784205] usb 3-4: skipped 1 descriptor after interface
[   46.784209] usb 3-4: skipped 1 descriptor after interface
[   46.784335] xhci_hcd 0000:00:14.0: Waiting for status stage event
[   46.784361] usb 3-4: default language 0x0409
[   46.784673] xhci_hcd 0000:00:14.0: Waiting for status stage event
[   46.784984] xhci_hcd 0000:00:14.0: Waiting for status stage event
[   46.785014] usb 3-4: udev 4, busnum 3, minor = 259
[   46.785019] usb 3-4: New USB device found, idVendor=046d, idProduct=c52b
[   46.785023] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   46.785026] usb 3-4: Product: USB Receiver
[   46.785030] usb 3-4: Manufacturer: Logitech
[   46.785198] usb 3-4: usb_probe_device
[   46.785201] usb 3-4: configuration #1 chosen from 1 choice
[   46.785217] xhci_hcd 0000:00:14.0: add ep 0x81, slot id 3, new drop flags = 0x0, new add flags = 0x9, new slot info = 0x18100000
[   46.785219] xhci_hcd 0000:00:14.0: add ep 0x82, slot id 3, new drop flags = 0x0, new add flags = 0x29, new slot info = 0x28100000
[   46.785222] xhci_hcd 0000:00:14.0: add ep 0x83, slot id 3, new drop flags = 0x0, new add flags = 0xa9, new slot info = 0x38100000
[   46.785224] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev ffff8803ce7bf000
[   46.785225] xhci_hcd 0000:00:14.0: New Input Control Context:
[   46.785227] xhci_hcd 0000:00:14.0: @ffff88003643e000 (virt) @3643e000 (dma) 0x000000 - drop flags
[   46.785228] xhci_hcd 0000:00:14.0: @ffff88003643e004 (virt) @3643e004 (dma) 0x0000a9 - add flags
[   46.785230] xhci_hcd 0000:00:14.0: @ffff88003643e008 (virt) @3643e008 (dma) 0x000000 - rsvd2[0]
[   46.785231] xhci_hcd 0000:00:14.0: @ffff88003643e00c (virt) @3643e00c (dma) 0x000000 - rsvd2[1]
[   46.785233] xhci_hcd 0000:00:14.0: @ffff88003643e010 (virt) @3643e010 (dma) 0x000000 - rsvd2[2]
[   46.785234] xhci_hcd 0000:00:14.0: @ffff88003643e014 (virt) @3643e014 (dma) 0x000000 - rsvd2[3]
[   46.785235] xhci_hcd 0000:00:14.0: @ffff88003643e018 (virt) @3643e018 (dma) 0x000000 - rsvd2[4]
[   46.785236] xhci_hcd 0000:00:14.0: @ffff88003643e01c (virt) @3643e01c (dma) 0x000000 - rsvd2[5]
[   46.785238] xhci_hcd 0000:00:14.0: Slot Context:
[   46.785239] xhci_hcd 0000:00:14.0: @ffff88003643e020 (virt) @3643e020 (dma) 0x38100000 - dev_info
[   46.785240] xhci_hcd 0000:00:14.0: @ffff88003643e024 (virt) @3643e024 (dma) 0x040000 - dev_info2
[   46.785241] xhci_hcd 0000:00:14.0: @ffff88003643e028 (virt) @3643e028 (dma) 0x000000 - tt_info
[   46.785243] xhci_hcd 0000:00:14.0: @ffff88003643e02c (virt) @3643e02c (dma) 0x000000 - dev_state
[   46.785244] xhci_hcd 0000:00:14.0: @ffff88003643e030 (virt) @3643e030 (dma) 0x000000 - rsvd[0]
[   46.785246] xhci_hcd 0000:00:14.0: @ffff88003643e034 (virt) @3643e034 (dma) 0x000000 - rsvd[1]
[   46.785247] xhci_hcd 0000:00:14.0: @ffff88003643e038 (virt) @3643e038 (dma) 0x000000 - rsvd[2]
[   46.785249] xhci_hcd 0000:00:14.0: @ffff88003643e03c (virt) @3643e03c (dma) 0x000000 - rsvd[3]
[   46.785250] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.785251] xhci_hcd 0000:00:14.0: @ffff88003643e040 (virt) @3643e040 (dma) 0x000001 - ep_info
[   46.785252] xhci_hcd 0000:00:14.0: @ffff88003643e044 (virt) @3643e044 (dma) 0x080026 - ep_info2
[   46.785254] xhci_hcd 0000:00:14.0: @ffff88003643e048 (virt) @3643e048 (dma) 0x36443001 - deq
[   46.785255] xhci_hcd 0000:00:14.0: @ffff88003643e050 (virt) @3643e050 (dma) 0x000000 - tx_info
[   46.785256] xhci_hcd 0000:00:14.0: @ffff88003643e054 (virt) @3643e054 (dma) 0x000000 - rsvd[0]
[   46.785258] xhci_hcd 0000:00:14.0: @ffff88003643e058 (virt) @3643e058 (dma) 0x000000 - rsvd[1]
[   46.785259] xhci_hcd 0000:00:14.0: @ffff88003643e05c (virt) @3643e05c (dma) 0x000000 - rsvd[2]
[   46.785260] xhci_hcd 0000:00:14.0: Endpoint 01 Context:
[   46.785261] xhci_hcd 0000:00:14.0: @ffff88003643e060 (virt) @3643e060 (dma) 0x000000 - ep_info
[   46.785263] xhci_hcd 0000:00:14.0: @ffff88003643e064 (virt) @3643e064 (dma) 0x000000 - ep_info2
[   46.785264] xhci_hcd 0000:00:14.0: @ffff88003643e068 (virt) @3643e068 (dma) 0x000000 - deq
[   46.785265] xhci_hcd 0000:00:14.0: @ffff88003643e070 (virt) @3643e070 (dma) 0x000000 - tx_info
[   46.785268] xhci_hcd 0000:00:14.0: @ffff88003643e074 (virt) @3643e074 (dma) 0x000000 - rsvd[0]
[   46.785269] xhci_hcd 0000:00:14.0: @ffff88003643e078 (virt) @3643e078 (dma) 0x000000 - rsvd[1]
[   46.785270] xhci_hcd 0000:00:14.0: @ffff88003643e07c (virt) @3643e07c (dma) 0x000000 - rsvd[2]
[   46.785272] xhci_hcd 0000:00:14.0: Endpoint 02 Context:
[   46.785273] xhci_hcd 0000:00:14.0: @ffff88003643e080 (virt) @3643e080 (dma) 0x060000 - ep_info
[   46.785274] xhci_hcd 0000:00:14.0: @ffff88003643e084 (virt) @3643e084 (dma) 0x08003e - ep_info2
[   46.785276] xhci_hcd 0000:00:14.0: @ffff88003643e088 (virt) @3643e088 (dma) 0x36443801 - deq
[   46.785277] xhci_hcd 0000:00:14.0: @ffff88003643e090 (virt) @3643e090 (dma) 0x080008 - tx_info
[   46.785279] xhci_hcd 0000:00:14.0: @ffff88003643e094 (virt) @3643e094 (dma) 0x000000 - rsvd[0]
[   46.785280] xhci_hcd 0000:00:14.0: @ffff88003643e098 (virt) @3643e098 (dma) 0x000000 - rsvd[1]
[   46.785282] xhci_hcd 0000:00:14.0: @ffff88003643e09c (virt) @3643e09c (dma) 0x000000 - rsvd[2]
[   46.785283] xhci_hcd 0000:00:14.0: Endpoint 03 Context:
[   46.785285] xhci_hcd 0000:00:14.0: @ffff88003643e0a0 (virt) @3643e0a0 (dma) 0x000000 - ep_info
[   46.785286] xhci_hcd 0000:00:14.0: @ffff88003643e0a4 (virt) @3643e0a4 (dma) 0x000000 - ep_info2
[   46.785287] xhci_hcd 0000:00:14.0: @ffff88003643e0a8 (virt) @3643e0a8 (dma) 0x000000 - deq
[   46.785289] xhci_hcd 0000:00:14.0: @ffff88003643e0b0 (virt) @3643e0b0 (dma) 0x000000 - tx_info
[   46.785290] xhci_hcd 0000:00:14.0: @ffff88003643e0b4 (virt) @3643e0b4 (dma) 0x000000 - rsvd[0]
[   46.785291] xhci_hcd 0000:00:14.0: @ffff88003643e0b8 (virt) @3643e0b8 (dma) 0x000000 - rsvd[1]
[   46.785293] xhci_hcd 0000:00:14.0: @ffff88003643e0bc (virt) @3643e0bc (dma) 0x000000 - rsvd[2]
[   46.785294] xhci_hcd 0000:00:14.0: Endpoint 04 Context:
[   46.785295] xhci_hcd 0000:00:14.0: @ffff88003643e0c0 (virt) @3643e0c0 (dma) 0x040000 - ep_info
[   46.785296] xhci_hcd 0000:00:14.0: @ffff88003643e0c4 (virt) @3643e0c4 (dma) 0x08003e - ep_info2
[   46.785298] xhci_hcd 0000:00:14.0: @ffff88003643e0c8 (virt) @3643e0c8 (dma) 0x36442801 - deq
[   46.785299] xhci_hcd 0000:00:14.0: @ffff88003643e0d0 (virt) @3643e0d0 (dma) 0x080008 - tx_info
[   46.785301] xhci_hcd 0000:00:14.0: @ffff88003643e0d4 (virt) @3643e0d4 (dma) 0x000000 - rsvd[0]
[   46.785302] xhci_hcd 0000:00:14.0: @ffff88003643e0d8 (virt) @3643e0d8 (dma) 0x000000 - rsvd[1]
[   46.785304] xhci_hcd 0000:00:14.0: @ffff88003643e0dc (virt) @3643e0dc (dma) 0x000000 - rsvd[2]
[   46.785305] xhci_hcd 0000:00:14.0: Endpoint 05 Context:
[   46.785306] xhci_hcd 0000:00:14.0: @ffff88003643e0e0 (virt) @3643e0e0 (dma) 0x000000 - ep_info
[   46.785307] xhci_hcd 0000:00:14.0: @ffff88003643e0e4 (virt) @3643e0e4 (dma) 0x000000 - ep_info2
[   46.785309] xhci_hcd 0000:00:14.0: @ffff88003643e0e8 (virt) @3643e0e8 (dma) 0x000000 - deq
[   46.785310] xhci_hcd 0000:00:14.0: @ffff88003643e0f0 (virt) @3643e0f0 (dma) 0x000000 - tx_info
[   46.785312] xhci_hcd 0000:00:14.0: @ffff88003643e0f4 (virt) @3643e0f4 (dma) 0x000000 - rsvd[0]
[   46.785313] xhci_hcd 0000:00:14.0: @ffff88003643e0f8 (virt) @3643e0f8 (dma) 0x000000 - rsvd[1]
[   46.785315] xhci_hcd 0000:00:14.0: @ffff88003643e0fc (virt) @3643e0fc (dma) 0x000000 - rsvd[2]
[   46.785316] xhci_hcd 0000:00:14.0: Endpoint 06 Context:
[   46.785318] xhci_hcd 0000:00:14.0: @ffff88003643e100 (virt) @3643e100 (dma) 0x040000 - ep_info
[   46.785319] xhci_hcd 0000:00:14.0: @ffff88003643e104 (virt) @3643e104 (dma) 0x20003e - ep_info2
[   46.785320] xhci_hcd 0000:00:14.0: @ffff88003643e108 (virt) @3643e108 (dma) 0x36440801 - deq
[   46.785322] xhci_hcd 0000:00:14.0: @ffff88003643e110 (virt) @3643e110 (dma) 0x200020 - tx_info
[   46.785323] xhci_hcd 0000:00:14.0: @ffff88003643e114 (virt) @3643e114 (dma) 0x000000 - rsvd[0]
[   46.785325] xhci_hcd 0000:00:14.0: @ffff88003643e118 (virt) @3643e118 (dma) 0x000000 - rsvd[1]
[   46.785326] xhci_hcd 0000:00:14.0: @ffff88003643e11c (virt) @3643e11c (dma) 0x000000 - rsvd[2]
[   46.785328] xhci_hcd 0000:00:14.0: Adding 3 ep ctxs, 6 now active.
[   46.785331] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 4
[   46.785333] xhci_hcd 0000:00:14.0: Final bandwidth: 58, Limit: 1285, Reserved: 129, Available: 85 percent
[   46.785335] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.785385] xhci_hcd 0000:00:14.0: Completed config ep cmd
[   46.785394] usb 3-4: Successful Endpoint Configure command
[   46.785395] xhci_hcd 0000:00:14.0: Output context after successful config ep cmd:
[   46.785397] xhci_hcd 0000:00:14.0: Slot Context:
[   46.785398] xhci_hcd 0000:00:14.0: @ffff88003643f000 (virt) @3643f000 (dma) 0x38100000 - dev_info
[   46.785399] xhci_hcd 0000:00:14.0: @ffff88003643f004 (virt) @3643f004 (dma) 0x040000 - dev_info2
[   46.785401] xhci_hcd 0000:00:14.0: @ffff88003643f008 (virt) @3643f008 (dma) 0x000000 - tt_info
[   46.785402] xhci_hcd 0000:00:14.0: @ffff88003643f00c (virt) @3643f00c (dma) 0x18000003 - dev_state
[   46.785404] xhci_hcd 0000:00:14.0: @ffff88003643f010 (virt) @3643f010 (dma) 0x000000 - rsvd[0]
[   46.785405] xhci_hcd 0000:00:14.0: @ffff88003643f014 (virt) @3643f014 (dma) 0x000000 - rsvd[1]
[   46.785406] xhci_hcd 0000:00:14.0: @ffff88003643f018 (virt) @3643f018 (dma) 0x000000 - rsvd[2]
[   46.785408] xhci_hcd 0000:00:14.0: @ffff88003643f01c (virt) @3643f01c (dma) 0x000000 - rsvd[3]
[   46.785410] xhci_hcd 0000:00:14.0: Endpoint 00 Context:
[   46.785411] xhci_hcd 0000:00:14.0: @ffff88003643f020 (virt) @3643f020 (dma) 0x000001 - ep_info
[   46.785413] xhci_hcd 0000:00:14.0: @ffff88003643f024 (virt) @3643f024 (dma) 0x080026 - ep_info2
[   46.785414] xhci_hcd 0000:00:14.0: @ffff88003643f028 (virt) @3643f028 (dma) 0x364430f1 - deq
[   46.785415] xhci_hcd 0000:00:14.0: @ffff88003643f030 (virt) @3643f030 (dma) 0x000000 - tx_info
[   46.785417] xhci_hcd 0000:00:14.0: @ffff88003643f034 (virt) @3643f034 (dma) 0x000000 - rsvd[0]
[   46.785418] xhci_hcd 0000:00:14.0: @ffff88003643f038 (virt) @3643f038 (dma) 0x000000 - rsvd[1]
[   46.785420] xhci_hcd 0000:00:14.0: @ffff88003643f03c (virt) @3643f03c (dma) 0x000000 - rsvd[2]
[   46.785421] xhci_hcd 0000:00:14.0: Endpoint 01 Context:
[   46.785423] xhci_hcd 0000:00:14.0: @ffff88003643f040 (virt) @3643f040 (dma) 0x000000 - ep_info
[   46.785424] xhci_hcd 0000:00:14.0: @ffff88003643f044 (virt) @3643f044 (dma) 0x000000 - ep_info2
[   46.785426] xhci_hcd 0000:00:14.0: @ffff88003643f048 (virt) @3643f048 (dma) 0x000000 - deq
[   46.785427] xhci_hcd 0000:00:14.0: @ffff88003643f050 (virt) @3643f050 (dma) 0x000000 - tx_info
[   46.785429] xhci_hcd 0000:00:14.0: @ffff88003643f054 (virt) @3643f054 (dma) 0x000000 - rsvd[0]
[   46.785430] xhci_hcd 0000:00:14.0: @ffff88003643f058 (virt) @3643f058 (dma) 0x000000 - rsvd[1]
[   46.785431] xhci_hcd 0000:00:14.0: @ffff88003643f05c (virt) @3643f05c (dma) 0x000000 - rsvd[2]
[   46.785432] xhci_hcd 0000:00:14.0: Endpoint 02 Context:
[   46.785434] xhci_hcd 0000:00:14.0: @ffff88003643f060 (virt) @3643f060 (dma) 0x060001 - ep_info
[   46.785435] xhci_hcd 0000:00:14.0: @ffff88003643f064 (virt) @3643f064 (dma) 0x08003e - ep_info2
[   46.785437] xhci_hcd 0000:00:14.0: @ffff88003643f068 (virt) @3643f068 (dma) 0x36443801 - deq
[   46.785438] xhci_hcd 0000:00:14.0: @ffff88003643f070 (virt) @3643f070 (dma) 0x080008 - tx_info
[   46.785440] xhci_hcd 0000:00:14.0: @ffff88003643f074 (virt) @3643f074 (dma) 0x000000 - rsvd[0]
[   46.785441] xhci_hcd 0000:00:14.0: @ffff88003643f078 (virt) @3643f078 (dma) 0x000000 - rsvd[1]
[   46.785442] xhci_hcd 0000:00:14.0: @ffff88003643f07c (virt) @3643f07c (dma) 0x000000 - rsvd[2]
[   46.785443] xhci_hcd 0000:00:14.0: Endpoint 03 Context:
[   46.785445] xhci_hcd 0000:00:14.0: @ffff88003643f080 (virt) @3643f080 (dma) 0x000000 - ep_info
[   46.785446] xhci_hcd 0000:00:14.0: @ffff88003643f084 (virt) @3643f084 (dma) 0x000000 - ep_info2
[   46.785448] xhci_hcd 0000:00:14.0: @ffff88003643f088 (virt) @3643f088 (dma) 0x000000 - deq
[   46.785449] xhci_hcd 0000:00:14.0: @ffff88003643f090 (virt) @3643f090 (dma) 0x000000 - tx_info
[   46.785450] xhci_hcd 0000:00:14.0: @ffff88003643f094 (virt) @3643f094 (dma) 0x000000 - rsvd[0]
[   46.785452] xhci_hcd 0000:00:14.0: @ffff88003643f098 (virt) @3643f098 (dma) 0x000000 - rsvd[1]
[   46.785454] xhci_hcd 0000:00:14.0: @ffff88003643f09c (virt) @3643f09c (dma) 0x000000 - rsvd[2]
[   46.785455] xhci_hcd 0000:00:14.0: Endpoint 04 Context:
[   46.785457] xhci_hcd 0000:00:14.0: @ffff88003643f0a0 (virt) @3643f0a0 (dma) 0x040001 - ep_info
[   46.785458] xhci_hcd 0000:00:14.0: @ffff88003643f0a4 (virt) @3643f0a4 (dma) 0x08003e - ep_info2
[   46.785460] xhci_hcd 0000:00:14.0: @ffff88003643f0a8 (virt) @3643f0a8 (dma) 0x36442801 - deq
[   46.785462] xhci_hcd 0000:00:14.0: @ffff88003643f0b0 (virt) @3643f0b0 (dma) 0x080008 - tx_info
[   46.785463] xhci_hcd 0000:00:14.0: @ffff88003643f0b4 (virt) @3643f0b4 (dma) 0x000000 - rsvd[0]
[   46.785464] xhci_hcd 0000:00:14.0: @ffff88003643f0b8 (virt) @3643f0b8 (dma) 0x000000 - rsvd[1]
[   46.785466] xhci_hcd 0000:00:14.0: @ffff88003643f0bc (virt) @3643f0bc (dma) 0x000000 - rsvd[2]
[   46.785467] xhci_hcd 0000:00:14.0: Endpoint 05 Context:
[   46.785469] xhci_hcd 0000:00:14.0: @ffff88003643f0c0 (virt) @3643f0c0 (dma) 0x000000 - ep_info
[   46.785470] xhci_hcd 0000:00:14.0: @ffff88003643f0c4 (virt) @3643f0c4 (dma) 0x000000 - ep_info2
[   46.785471] xhci_hcd 0000:00:14.0: @ffff88003643f0c8 (virt) @3643f0c8 (dma) 0x000000 - deq
[   46.785472] xhci_hcd 0000:00:14.0: @ffff88003643f0d0 (virt) @3643f0d0 (dma) 0x000000 - tx_info
[   46.785474] xhci_hcd 0000:00:14.0: @ffff88003643f0d4 (virt) @3643f0d4 (dma) 0x000000 - rsvd[0]
[   46.785475] xhci_hcd 0000:00:14.0: @ffff88003643f0d8 (virt) @3643f0d8 (dma) 0x000000 - rsvd[1]
[   46.785476] xhci_hcd 0000:00:14.0: @ffff88003643f0dc (virt) @3643f0dc (dma) 0x000000 - rsvd[2]
[   46.785477] xhci_hcd 0000:00:14.0: Endpoint 06 Context:
[   46.785478] xhci_hcd 0000:00:14.0: @ffff88003643f0e0 (virt) @3643f0e0 (dma) 0x040001 - ep_info
[   46.785480] xhci_hcd 0000:00:14.0: @ffff88003643f0e4 (virt) @3643f0e4 (dma) 0x20003e - ep_info2
[   46.785481] xhci_hcd 0000:00:14.0: @ffff88003643f0e8 (virt) @3643f0e8 (dma) 0x36440801 - deq
[   46.785483] xhci_hcd 0000:00:14.0: @ffff88003643f0f0 (virt) @3643f0f0 (dma) 0x200020 - tx_info
[   46.785485] xhci_hcd 0000:00:14.0: @ffff88003643f0f4 (virt) @3643f0f4 (dma) 0x000000 - rsvd[0]
[   46.785486] xhci_hcd 0000:00:14.0: @ffff88003643f0f8 (virt) @3643f0f8 (dma) 0x000000 - rsvd[1]
[   46.785487] xhci_hcd 0000:00:14.0: @ffff88003643f0fc (virt) @3643f0fc (dma) 0x000000 - rsvd[2]
[   46.785490] xhci_hcd 0000:00:14.0: Endpoint 0x81 not halted, refusing to reset.
[   46.785493] xhci_hcd 0000:00:14.0: Endpoint 0x82 not halted, refusing to reset.
[   46.785496] xhci_hcd 0000:00:14.0: Endpoint 0x83 not halted, refusing to reset.
[   46.785952] xhci_hcd 0000:00:14.0: Waiting for status stage event
[   46.786011] usb 3-4: adding 3-4:1.0 (config #1, interface 0)
[   46.786072] usbhid 3-4:1.0: usb_probe_interface
[   46.786074] usbhid 3-4:1.0: usb_probe_interface - got id
[   46.786871] usb 3-4: adding 3-4:1.1 (config #1, interface 1)
[   46.786890] usbhid 3-4:1.1: usb_probe_interface
[   46.786892] usbhid 3-4:1.1: usb_probe_interface - got id
[   46.786992] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.786994] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.786995] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.786997] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.786998] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.786999] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.787000] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.787001] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x364432a0 (DMA)
[   46.787002] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.787004] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff8800364432a0 (0x364432a0 dma), new cycle = 1
[   46.787005] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.787008] xhci_hcd 0000:00:14.0: Giveback URB ffff880402ee63c0, len = 0, expected = 0, status = -32
[   46.787011] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.787013] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @364432a1
[   46.788382] usb 3-4: adding 3-4:1.2 (config #1, interface 2)
[   46.788394] usbhid 3-4:1.2: usb_probe_interface
[   46.788396] usbhid 3-4:1.2: usb_probe_interface - got id
[   46.788458] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.788460] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.788461] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.788462] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.788463] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.788464] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.788465] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.788466] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x364432f0 (DMA)
[   46.788467] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.788468] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff8800364432f0 (0x364432f0 dma), new cycle = 1
[   46.788469] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.788472] xhci_hcd 0000:00:14.0: Giveback URB ffff8804084c2d80, len = 0, expected = 0, status = -32
[   46.788474] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.788498] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @364432f1
[   46.789550] xhci_hcd 0000:00:14.0: Waiting for status stage event
[   46.789836] xhci_hcd 0000:00:14.0: Waiting for status stage event
[   46.789955] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.789958] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.789960] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.789962] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.789964] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.789965] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.789967] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.789970] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x364433b0 (DMA)
[   46.789971] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.789974] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff8800364433b0 (0x364433b0 dma), new cycle = 1
[   46.789976] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.789981] xhci_hcd 0000:00:14.0: Giveback URB ffff8804071ed9c0, len = 0, expected = 16, status = -32
[   46.789985] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.789987] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @364433b1
[   46.790069] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.790071] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.790072] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.790073] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.790074] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.790075] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.790076] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0e80 (virtual)
[   46.790077] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x364433e0 (DMA)
[   46.790078] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.790080] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0e80 (0x36443000 dma), new deq ptr = ffff8800364433e0 (0x364433e0 dma), new cycle = 1
[   46.790081] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.790084] xhci_hcd 0000:00:14.0: Giveback URB ffff8804071ed9c0, len = 0, expected = 32, status = -32
[   46.790087] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.790088] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @364433e1
[   46.790116] usbhid 3-4:1.2: looking for a minor, starting at 0
[   46.790214] logitech-djreceiver 0003:046D:C52B.0007: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-4/input2
[   46.790462] xhci_hcd 0000:00:14.0: Stalled endpoint
[   46.790464] xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring
[   46.790466] xhci_hcd 0000:00:14.0: Finding segment containing stopped TRB.
[   46.790467] xhci_hcd 0000:00:14.0: Finding endpoint context
[   46.790469] xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD.
[   46.790471] xhci_hcd 0000:00:14.0: Cycle state = 0x1
[   46.790472] xhci_hcd 0000:00:14.0: New dequeue segment = ffff880384ba0ea0 (virtual)
[   46.790474] xhci_hcd 0000:00:14.0: New dequeue pointer = 0x36443450 (DMA)
[   46.790476] xhci_hcd 0000:00:14.0: Queueing new dequeue state
[   46.790478] xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880384ba0ea0 (0x36443400 dma), new deq ptr = ffff880036443450 (0x36443450 dma), new cycle = 1
[   46.790480] xhci_hcd 0000:00:14.0: // Ding dong!
[   46.790484] xhci_hcd 0000:00:14.0: Giveback URB ffff8804071ed9c0, len = 0, expected = 15, status = -32
[   46.790487] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1
[   46.790489] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @36443451
[   46.800787] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.802832] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.804837] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.810780] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.818829] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.826842] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.834831] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.842835] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.850831] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.858821] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.866823] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.874810] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.882813] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.888813] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.896807] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.904799] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.912749] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.920794] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.928787] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.936782] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.944769] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.952741] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.960770] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.968767] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.969996] xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping port polling.
[   46.976740] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.982740] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.990746] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   46.998753] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.006749] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.014745] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.022741] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.030736] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.038733] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.046729] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.054695] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.060709] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.068714] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.076713] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.084702] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.092700] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.100701] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.108693] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.116693] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.124688] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.132684] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.140680] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.146677] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.154672] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.162668] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.170664] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.178660] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.186642] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.194653] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.202648] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.210644] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.218625] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.224636] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.232627] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.240628] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.248624] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.256619] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.264616] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.272611] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.280608] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.288603] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.296599] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.304594] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.310592] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.318586] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.326583] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.334579] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.342574] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.350570] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.358539] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.366557] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.374550] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.382496] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.390519] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.396542] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.404543] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.412459] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.420533] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[   47.428531] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-19 21:31         ` Peter Hurley
@ 2013-07-22 11:44           ` Jiri Kosina
  2013-07-22 14:03             ` Peter Hurley
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Kosina @ 2013-07-22 11:44 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Sarah Sharp, Joseph Salisbury, Nestor Lopez Casado,
	benjamin.tissoires, adlr, linux-input, linux-kernel, linux-usb

On Fri, 19 Jul 2013, Peter Hurley wrote:

> > > As far as getting printk output from a custom kernel, I think that may
> > > be beyond the reporter's capability. Perhaps one of the Ubuntu devs
> > > triaging this bug could provide a test kernel for the OP with those
> > > options on.
> > > 
> > > Joseph, would you be willing to do that?
> > 
> > Sure thing.  I'll build a kernel and request that the bug reporter
> > collect usbmon data.
> 
> Thanks Joseph for building the test kernel and getting it to the reporter!
> 
> Sarah,
> 
> I've attached the dmesg capture supplied by the original reporter on
> a 3.10 custom kernel w/ the kbuild options you requested.
> 
> It seems as if your initial suspicion is correct:
> 
> [   46.785490] xhci_hcd 0000:00:14.0: Endpoint 0x81 not halted, refusing to
> reset.
> [   46.785493] xhci_hcd 0000:00:14.0: Endpoint 0x82 not halted, refusing to
> reset.
> [   46.785496] xhci_hcd 0000:00:14.0: Endpoint 0x83 not halted, refusing to
> reset.
> [   46.785952] xhci_hcd 0000:00:14.0: Waiting for status stage event
> 
> At this point, would you recommend proceeding with the workaround or
> waiting for an xHCI bug fix?

Thanks for your efforts.

Seems like this might be a part of the picture, but not a complete one. 
Linus claims to have similar problem, but his receiver is not connected 
through xHCI (I got this as an off-list report, so can't really provide a 
pointer to ML archives).

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-22 11:44           ` Jiri Kosina
@ 2013-07-22 14:03             ` Peter Hurley
  2013-07-22 15:27                 ` Alan Stern
  0 siblings, 1 reply; 32+ messages in thread
From: Peter Hurley @ 2013-07-22 14:03 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Sarah Sharp, Joseph Salisbury, Nestor Lopez Casado,
	benjamin.tissoires, adlr, linux-input, linux-kernel, linux-usb

On 07/22/2013 07:44 AM, Jiri Kosina wrote:
> On Fri, 19 Jul 2013, Peter Hurley wrote:
>
>>>> As far as getting printk output from a custom kernel, I think that may
>>>> be beyond the reporter's capability. Perhaps one of the Ubuntu devs
>>>> triaging this bug could provide a test kernel for the OP with those
>>>> options on.
>>>>
>>>> Joseph, would you be willing to do that?
>>>
>>> Sure thing.  I'll build a kernel and request that the bug reporter
>>> collect usbmon data.
>>
>> Thanks Joseph for building the test kernel and getting it to the reporter!
>>
>> Sarah,
>>
>> I've attached the dmesg capture supplied by the original reporter on
>> a 3.10 custom kernel w/ the kbuild options you requested.
>>
>> It seems as if your initial suspicion is correct:
>>
>> [   46.785490] xhci_hcd 0000:00:14.0: Endpoint 0x81 not halted, refusing to
>> reset.
>> [   46.785493] xhci_hcd 0000:00:14.0: Endpoint 0x82 not halted, refusing to
>> reset.
>> [   46.785496] xhci_hcd 0000:00:14.0: Endpoint 0x83 not halted, refusing to
>> reset.
>> [   46.785952] xhci_hcd 0000:00:14.0: Waiting for status stage event
>>
>> At this point, would you recommend proceeding with the workaround or
>> waiting for an xHCI bug fix?
>
> Thanks for your efforts.
>
> Seems like this might be a part of the picture, but not a complete one.
> Linus claims to have similar problem, but his receiver is not connected
> through xHCI (I got this as an off-list report, so can't really provide a
> pointer to ML archives).

Ah, ok. I wasn't aware of that. I'll assume then that the necessary
people have the complete picture.

Regards,
Peter Hurley



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 13:21 [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Nestor Lopez Casado
  2013-07-18 13:21 ` [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set Nestor Lopez Casado
  2013-07-18 20:28 ` [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Peter Hurley
@ 2013-07-22 14:35 ` Jiri Kosina
  2013-07-22 19:21   ` Linus Torvalds
  2 siblings, 1 reply; 32+ messages in thread
From: Jiri Kosina @ 2013-07-22 14:35 UTC (permalink / raw)
  To: Nestor Lopez Casado
  Cc: benjamin.tissoires, adlr, joseph.salisbury, linux-input,
	linux-kernel, Linus Torvalds, Peter Hurley

On Thu, 18 Jul 2013, Nestor Lopez Casado wrote:

> This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
> 
> This patch re-adds the workaround introduced by 596264082f10dd4
> which was reverted by 8af6c08830b1ae114.
> 
> The original patch 596264 was needed to overcome a situation where
> the hid-core would drop incoming reports while probe() was being
> executed.
> 
> This issue was solved by c849a6143bec520af which added
> hid_device_io_start() and hid_device_io_stop() that enable a specific
> hid driver to opt-in for input reports while its probe() is being
> executed.
> 
> Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
> functionality added to hid-core. Having done that, workaround 596264
> was no longer necessary and was reverted by 8af6c08.
> 
> We now encounter a different problem that ends up 'again' thwarting
> the Unifying receiver enumeration. The problem is time and usb controller
> dependent. Ocasionally the reports sent to the usb receiver to start
> the paired devices enumeration fail with -EPIPE and the receiver never
> gets to enumerate the paired devices.
[ ... snip ... ]

Ok, this is now in

	git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-3.11/logitech-enumeration-fix

Linus added to CC.

Linus -- could you please by any chance test whether the two patches in 
that branch make the problem you are observing any better? (and no, this 
is not a pull request yet).

It's still not clear whether we are chasing two different issues here, or 
not.

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-22 14:03             ` Peter Hurley
@ 2013-07-22 15:27                 ` Alan Stern
  0 siblings, 0 replies; 32+ messages in thread
From: Alan Stern @ 2013-07-22 15:27 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Jiri Kosina, Sarah Sharp, Joseph Salisbury, Nestor Lopez Casado,
	benjamin.tissoires, adlr, linux-input, linux-kernel, linux-usb

On Mon, 22 Jul 2013, Peter Hurley wrote:

> On 07/22/2013 07:44 AM, Jiri Kosina wrote:
...
> > Seems like this might be a part of the picture, but not a complete one.
> > Linus claims to have similar problem, but his receiver is not connected
> > through xHCI (I got this as an off-list report, so can't really provide a
> > pointer to ML archives).
> 
> Ah, ok. I wasn't aware of that. I'll assume then that the necessary
> people have the complete picture.

It might help to get a usbmon trace and dmesg log from Linus, if he
still has this problem.

Alan Stern


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
@ 2013-07-22 15:27                 ` Alan Stern
  0 siblings, 0 replies; 32+ messages in thread
From: Alan Stern @ 2013-07-22 15:27 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Jiri Kosina, Sarah Sharp, Joseph Salisbury, Nestor Lopez Casado,
	benjamin.tissoires, adlr, linux-input, linux-kernel, linux-usb

On Mon, 22 Jul 2013, Peter Hurley wrote:

> On 07/22/2013 07:44 AM, Jiri Kosina wrote:
...
> > Seems like this might be a part of the picture, but not a complete one.
> > Linus claims to have similar problem, but his receiver is not connected
> > through xHCI (I got this as an off-list report, so can't really provide a
> > pointer to ML archives).
> 
> Ah, ok. I wasn't aware of that. I'll assume then that the necessary
> people have the complete picture.

It might help to get a usbmon trace and dmesg log from Linus, if he
still has this problem.

Alan Stern

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-22 14:35 ` Jiri Kosina
@ 2013-07-22 19:21   ` Linus Torvalds
  0 siblings, 0 replies; 32+ messages in thread
From: Linus Torvalds @ 2013-07-22 19:21 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Nestor Lopez Casado, benjamin.tissoires, Andrew de los Reyes,
	joseph.salisbury, linux-input, Linux Kernel Mailing List,
	Peter Hurley

On Mon, Jul 22, 2013 at 7:35 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>
> Linus -- could you please by any chance test whether the two patches in
> that branch make the problem you are observing any better? (and no, this
> is not a pull request yet).
>
> It's still not clear whether we are chasing two different issues here, or
> not.

I think it's two different issues. It sounds like the USB3 one is
fairly repeatable?

Mine is quite rare. I think it's so far happened just once during the
the 3.11 merge window+, and that's despite me rebooting usually a few
times a day (less now that things are calming down).

On Mon, Jul 22, 2013 at 8:27 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>
> It might help to get a usbmon trace and dmesg log from Linus, if he
> still has this problem.

So see above. I've sent the dmesg - not that it's useful, since it
just lacks the lines showing the actual wireless device after plugging
it in (but the receiver is recognized). No error messages, just not
any working keyboard.

And it's not common. I think it has happened a handful of times over
the last four months or so.

                  Linus

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-07-18 13:21 ` [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set Nestor Lopez Casado
@ 2013-08-01 10:09   ` Benjamin Tissoires
  2013-08-02  1:11     ` Jiri Kosina
  0 siblings, 1 reply; 32+ messages in thread
From: Benjamin Tissoires @ 2013-08-01 10:09 UTC (permalink / raw)
  To: Nestor Lopez Casado
  Cc: Jiri Kosina, Andrew de los Reyes, joseph.salisbury, linux-input,
	linux-kernel

On Thu, Jul 18, 2013 at 3:21 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> Set querying_devices flag to true when we start the enumeration
> process.
>
> This was missing from the original patch. It never produced
> undesirable effects as it is highly improbable to have a second
> enumeration triggered while a first one was still in progress.
>
> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
> ---
>  drivers/hid/hid-logitech-dj.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 0d13389..d4657a5 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -488,6 +488,8 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
>         if (djrcv_dev->querying_devices)
>                 return 0;
>
> +       djrcv_dev->querying_devices = true;
> +

Unfortunately, this breaks the fallback mechanism :(
We tried to add the two patches in Fedora [1], but this doesn't fix
the bug because the driver actually things that it already asked for
the enumeration, but as we get the -EPIPE error, the request was never
sent.

So, Jiri, if you were to submit that series to Linus (or Greg) for
fixing the bug, please just drop this second patch.

Cheers,
Benjamin

[1] https://bugzilla.redhat.com/show_bug.cgi?id=989138

>         dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
>         if (!dj_report)
>                 return -ENOMEM;
> --
> 1.7.9.5
>

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-01 10:09   ` Benjamin Tissoires
@ 2013-08-02  1:11     ` Jiri Kosina
  2013-08-02 18:31       ` Benjamin Tissoires
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Kosina @ 2013-08-02  1:11 UTC (permalink / raw)
  To: Benjamin Tissoires
  Cc: Nestor Lopez Casado, Andrew de los Reyes, joseph.salisbury,
	linux-input, linux-kernel

On Thu, 1 Aug 2013, Benjamin Tissoires wrote:

> > Set querying_devices flag to true when we start the enumeration
> > process.
> >
> > This was missing from the original patch. It never produced
> > undesirable effects as it is highly improbable to have a second
> > enumeration triggered while a first one was still in progress.
> >
> > Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
> > ---
> >  drivers/hid/hid-logitech-dj.c |    2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> > index 0d13389..d4657a5 100644
> > --- a/drivers/hid/hid-logitech-dj.c
> > +++ b/drivers/hid/hid-logitech-dj.c
> > @@ -488,6 +488,8 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
> >         if (djrcv_dev->querying_devices)
> >                 return 0;
> >
> > +       djrcv_dev->querying_devices = true;
> > +
> 
> Unfortunately, this breaks the fallback mechanism :(
> We tried to add the two patches in Fedora [1], but this doesn't fix
> the bug because the driver actually things that it already asked for
> the enumeration, but as we get the -EPIPE error, the request was never
> sent.
> 
> So, Jiri, if you were to submit that series to Linus (or Greg) for
> fixing the bug, please just drop this second patch.

It's already on its way to Linus (he hasn't pulled yet though) ... which 
is not a big deal per se, I can always push a revert, but I have to admit 
I don't understand the breakage it is causing at all.

Could you please elaborate? (and put an elaborate description to revert 
commit log perhaps?)

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-02  1:11     ` Jiri Kosina
@ 2013-08-02 18:31       ` Benjamin Tissoires
  2013-08-05 13:22         ` Jiri Kosina
  0 siblings, 1 reply; 32+ messages in thread
From: Benjamin Tissoires @ 2013-08-02 18:31 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Nestor Lopez Casado, Andrew de los Reyes, joseph.salisbury,
	linux-input, linux-kernel

On Fri, Aug 2, 2013 at 3:11 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Thu, 1 Aug 2013, Benjamin Tissoires wrote:
>
>> > Set querying_devices flag to true when we start the enumeration
>> > process.
>> >
>> > This was missing from the original patch. It never produced
>> > undesirable effects as it is highly improbable to have a second
>> > enumeration triggered while a first one was still in progress.
>> >
>> > Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
>> > ---
>> >  drivers/hid/hid-logitech-dj.c |    2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
>> > index 0d13389..d4657a5 100644
>> > --- a/drivers/hid/hid-logitech-dj.c
>> > +++ b/drivers/hid/hid-logitech-dj.c
>> > @@ -488,6 +488,8 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
>> >         if (djrcv_dev->querying_devices)
>> >                 return 0;
>> >
>> > +       djrcv_dev->querying_devices = true;
>> > +
>>
>> Unfortunately, this breaks the fallback mechanism :(
>> We tried to add the two patches in Fedora [1], but this doesn't fix
>> the bug because the driver actually things that it already asked for
>> the enumeration, but as we get the -EPIPE error, the request was never
>> sent.
>>
>> So, Jiri, if you were to submit that series to Linus (or Greg) for
>> fixing the bug, please just drop this second patch.
>
> It's already on its way to Linus (he hasn't pulled yet though) ... which
> is not a big deal per se, I can always push a revert, but I have to admit
> I don't understand the breakage it is causing at all.
>
> Could you please elaborate? (and put an elaborate description to revert
> commit log perhaps?)

Sure, so here is the revert commit log:

--

Commit "HID: hid-logitech-dj, querying_devices was never set" activate
a flag which guarantees that we do not ask the receiver for too many
enumeration. When the flag is set, each following enumeration call is
discarded (the usb request is not forwarded to the receiver). The flag
is then released when the driver receive a pairing information event,
which normally follows the enumeration request.
However, the USB3 bug makes the driver think the enumeration request
has been forwarded to the receiver. However, it is actually not the
case because the USB stack returns -EPIPE. So, when a new unknown
device appears, the workaround consisting in asking for a new
enumeration is not working anymore: this new enumeration is discarded
because of the flag, which is never reset.

A solution could be to trigger a timeout before releasing it, but for
now, let's just revert the patch.

--

Does that makes it more understandable? I'm sorry I was not clear last
time, I was trying to catch this up between two sessions at GUADEC.

Cheers,
Benjamin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-02 18:31       ` Benjamin Tissoires
@ 2013-08-05 13:22         ` Jiri Kosina
  2013-08-05 14:40           ` Benjamin Tissoires
  0 siblings, 1 reply; 32+ messages in thread
From: Jiri Kosina @ 2013-08-05 13:22 UTC (permalink / raw)
  To: Benjamin Tissoires
  Cc: Nestor Lopez Casado, Andrew de los Reyes, joseph.salisbury,
	linux-input, linux-kernel

On Fri, 2 Aug 2013, Benjamin Tissoires wrote:

> > Could you please elaborate? (and put an elaborate description to revert
> > commit log perhaps?)
> 
> Sure, so here is the revert commit log:
> 
> --
> 
> Commit "HID: hid-logitech-dj, querying_devices was never set" activate
> a flag which guarantees that we do not ask the receiver for too many
> enumeration. When the flag is set, each following enumeration call is
> discarded (the usb request is not forwarded to the receiver). The flag
> is then released when the driver receive a pairing information event,
> which normally follows the enumeration request.
> However, the USB3 bug makes the driver think the enumeration request
> has been forwarded to the receiver. However, it is actually not the
> case because the USB stack returns -EPIPE. So, when a new unknown
> device appears, the workaround consisting in asking for a new
> enumeration is not working anymore: this new enumeration is discarded
> because of the flag, which is never reset.
> 
> A solution could be to trigger a timeout before releasing it, but for
> now, let's just revert the patch.
> 
> --

Thanks Benjamin.

I'd like to have a bit more clarification about the USB3 bug, as this 
whole issue is not completely clear to me.

To be more specific -- when exactly do we receive -EPIPE, why do we 
receive it and why do we not handle it properly?

Thanks again,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-05 13:22         ` Jiri Kosina
@ 2013-08-05 14:40           ` Benjamin Tissoires
  2013-08-06 21:03             ` Sune Mølgaard
  0 siblings, 1 reply; 32+ messages in thread
From: Benjamin Tissoires @ 2013-08-05 14:40 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Nestor Lopez Casado, Andrew de los Reyes, joseph.salisbury,
	linux-input, linux-kernel

On Mon, Aug 5, 2013 at 3:22 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 2 Aug 2013, Benjamin Tissoires wrote:
>
>> > Could you please elaborate? (and put an elaborate description to revert
>> > commit log perhaps?)
>>
>> Sure, so here is the revert commit log:
>>
>> --
>>
>> Commit "HID: hid-logitech-dj, querying_devices was never set" activate
>> a flag which guarantees that we do not ask the receiver for too many
>> enumeration. When the flag is set, each following enumeration call is
>> discarded (the usb request is not forwarded to the receiver). The flag
>> is then released when the driver receive a pairing information event,
>> which normally follows the enumeration request.
>> However, the USB3 bug makes the driver think the enumeration request
>> has been forwarded to the receiver. However, it is actually not the
>> case because the USB stack returns -EPIPE. So, when a new unknown
>> device appears, the workaround consisting in asking for a new
>> enumeration is not working anymore: this new enumeration is discarded
>> because of the flag, which is never reset.
>>
>> A solution could be to trigger a timeout before releasing it, but for
>> now, let's just revert the patch.
>>
>> --
>
> Thanks Benjamin.
>
> I'd like to have a bit more clarification about the USB3 bug, as this
> whole issue is not completely clear to me.
>
> To be more specific -- when exactly do we receive -EPIPE, why do we
> receive it and why do we not handle it properly?

Sure, I'll try (though the more I think of it, the more it seems
blurry to me :( ).

So the initial probe function in hid-logitech-dj was implemented by
using a direct call to hid_output_raw_report(). This call was
synchronous, so we did get the -EPIPE return code. Then, the probe()
function returns the -EPIPE error, cleaning the receiver and
unregister it from the hid bus.

However, now, we use hid_hw_request(), which is asynchronous (from
what I can read). At least, this code returns "void" as the set_report
command seems to be scheduled for later handling. In usbhid, when the
queue is flushed, I did not found a way to retrieve the error code...

So basically, the -EPIPE is received in usbhid_restart_ctrl_queue(),
but nothing notifies hid-logitech-dj from the error. In the end, the
probe() function returns without error code, but the receiver never
received the notification.

Cheers,
Benjamin

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-05 14:40           ` Benjamin Tissoires
@ 2013-08-06 21:03             ` Sune Mølgaard
  2013-08-09  9:36                 ` Jiri Kosina
  2013-08-10 17:21                 ` Jiri Kosina
  0 siblings, 2 replies; 32+ messages in thread
From: Sune Mølgaard @ 2013-08-06 21:03 UTC (permalink / raw)
  To: Benjamin Tissoires, Jiri Kosina
  Cc: Nestor Lopez Casado, Andrew de los Reyes, joseph.salisbury,
	linux-input, linux-kernel

Being affected by this bug, I can confirm that Linux 3.11-rc4 still
exhibits the unwanted behaviour for me, but that commenting out the
single line from the second patch makes it work.

Thus, for requesting a revert on that line, you are most welcome to put
me down as a "Tested-By".

Best regards,

Sune Mølgaard

Benjamin Tissoires wrote:
> On Mon, Aug 5, 2013 at 3:22 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>> On Fri, 2 Aug 2013, Benjamin Tissoires wrote:
>>
>>>> Could you please elaborate? (and put an elaborate description to revert
>>>> commit log perhaps?)
>>>
>>> Sure, so here is the revert commit log:
>>>
>>> --
>>>
>>> Commit "HID: hid-logitech-dj, querying_devices was never set" activate
>>> a flag which guarantees that we do not ask the receiver for too many
>>> enumeration. When the flag is set, each following enumeration call is
>>> discarded (the usb request is not forwarded to the receiver). The flag
>>> is then released when the driver receive a pairing information event,
>>> which normally follows the enumeration request.
>>> However, the USB3 bug makes the driver think the enumeration request
>>> has been forwarded to the receiver. However, it is actually not the
>>> case because the USB stack returns -EPIPE. So, when a new unknown
>>> device appears, the workaround consisting in asking for a new
>>> enumeration is not working anymore: this new enumeration is discarded
>>> because of the flag, which is never reset.
>>>
>>> A solution could be to trigger a timeout before releasing it, but for
>>> now, let's just revert the patch.
>>>
>>> --
>>
>> Thanks Benjamin.
>>
>> I'd like to have a bit more clarification about the USB3 bug, as this
>> whole issue is not completely clear to me.
>>
>> To be more specific -- when exactly do we receive -EPIPE, why do we
>> receive it and why do we not handle it properly?
> 
> Sure, I'll try (though the more I think of it, the more it seems
> blurry to me :( ).
> 
> So the initial probe function in hid-logitech-dj was implemented by
> using a direct call to hid_output_raw_report(). This call was
> synchronous, so we did get the -EPIPE return code. Then, the probe()
> function returns the -EPIPE error, cleaning the receiver and
> unregister it from the hid bus.
> 
> However, now, we use hid_hw_request(), which is asynchronous (from
> what I can read). At least, this code returns "void" as the set_report
> command seems to be scheduled for later handling. In usbhid, when the
> queue is flushed, I did not found a way to retrieve the error code...
> 
> So basically, the -EPIPE is received in usbhid_restart_ctrl_queue(),
> but nothing notifies hid-logitech-dj from the error. In the end, the
> probe() function returns without error code, but the receiver never
> received the notification.
> 
> Cheers,
> Benjamin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 


-- 
"Testiculos habet et bene pendentes"
See http://www.newint.org/features/1993/06/05/curious/

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-06 21:03             ` Sune Mølgaard
@ 2013-08-09  9:36                 ` Jiri Kosina
  2013-08-10 17:21                 ` Jiri Kosina
  1 sibling, 0 replies; 32+ messages in thread
From: Jiri Kosina @ 2013-08-09  9:36 UTC (permalink / raw)
  To: Sune Mølgaard
  Cc: Benjamin Tissoires, Nestor Lopez Casado, Andrew de los Reyes,
	joseph.salisbury, linux-input, linux-kernel

On Tue, 6 Aug 2013, Sune Mølgaard wrote:

> Being affected by this bug, I can confirm that Linux 3.11-rc4 still
> exhibits the unwanted behaviour for me, but that commenting out the
> single line from the second patch makes it work.
> 
> Thus, for requesting a revert on that line, you are most welcome to put
> me down as a "Tested-By".

Okay, this is now queued, and I will be pushing it to Linus.

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
@ 2013-08-09  9:36                 ` Jiri Kosina
  0 siblings, 0 replies; 32+ messages in thread
From: Jiri Kosina @ 2013-08-09  9:36 UTC (permalink / raw)
  To: Sune Mølgaard
  Cc: Benjamin Tissoires, Nestor Lopez Casado, Andrew de los Reyes,
	joseph.salisbury, linux-input, linux-kernel

On Tue, 6 Aug 2013, Sune Mølgaard wrote:

> Being affected by this bug, I can confirm that Linux 3.11-rc4 still
> exhibits the unwanted behaviour for me, but that commenting out the
> single line from the second patch makes it work.
> 
> Thus, for requesting a revert on that line, you are most welcome to put
> me down as a "Tested-By".

Okay, this is now queued, and I will be pushing it to Linus.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
  2013-08-06 21:03             ` Sune Mølgaard
@ 2013-08-10 17:21                 ` Jiri Kosina
  2013-08-10 17:21                 ` Jiri Kosina
  1 sibling, 0 replies; 32+ messages in thread
From: Jiri Kosina @ 2013-08-10 17:21 UTC (permalink / raw)
  To: Sune Mølgaard
  Cc: Benjamin Tissoires, Nestor Lopez Casado, Andrew de los Reyes,
	joseph.salisbury, linux-input, linux-kernel

On Tue, 6 Aug 2013, Sune Mølgaard wrote:

> Being affected by this bug, I can confirm that Linux 3.11-rc4 still
> exhibits the unwanted behaviour for me, but that commenting out the
> single line from the second patch makes it work.
> 
> Thus, for requesting a revert on that line, you are most welcome to put
> me down as a "Tested-By".

Will be reverted in 3.11-rc5 (8e5654ce69).

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set
@ 2013-08-10 17:21                 ` Jiri Kosina
  0 siblings, 0 replies; 32+ messages in thread
From: Jiri Kosina @ 2013-08-10 17:21 UTC (permalink / raw)
  To: Sune Mølgaard
  Cc: Benjamin Tissoires, Nestor Lopez Casado, Andrew de los Reyes,
	joseph.salisbury, linux-input, linux-kernel

On Tue, 6 Aug 2013, Sune Mølgaard wrote:

> Being affected by this bug, I can confirm that Linux 3.11-rc4 still
> exhibits the unwanted behaviour for me, but that commenting out the
> single line from the second patch makes it work.
> 
> Thus, for requesting a revert on that line, you are most welcome to put
> me down as a "Tested-By".

Will be reverted in 3.11-rc5 (8e5654ce69).

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-07-18 20:28 ` [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Peter Hurley
  2013-07-18 22:09   ` Sarah Sharp
@ 2013-08-12 21:54   ` Peter Wu
  2013-08-13 12:13     ` Peter Hurley
  1 sibling, 1 reply; 32+ messages in thread
From: Peter Wu @ 2013-08-12 21:54 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Nestor Lopez Casado, jkosina, benjamin.tissoires, adlr,
	joseph.salisbury, linux-input, linux-kernel, Sarah Sharp,
	linux-usb

On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
> Before we revert to using the workaround, I'd like to suggest that
> this new "hidden" problem may be an interaction with the xhci_hcd host
> controller driver only.
> 
> Looking at the related bug, the OP indicates the machine only has
> USB3 ports. Additionally, comments #7, #100, and #104 of the original
> bug report add additional information that would seem to confirm
> this suspicion.
> 
> Let me add I have this USB device running on the uhci_hcd driver
> with or without this workaround on v3.10.

This problem does not seem specific to xhci, uhci seems also effected. Today I 
upgraded a system (running Arch Linux) from kernel 3.9.9 to 3.10.5. After a 
reboot to 3.10.5, things broke. The setup:

- There are two USB receivers plugged into USB 1.1 ports (different buses 
according to lsusb, uhci), each receiver is paired to a K360 keyboard.
- One of the receivers are passed to a QEMU guest with -usbdevice host:$busid.
$devid. This keyboard is working (probably because QEMU performed a reset).
- Since 3.10.5, the keyboard that is *not* passed to the QEMU guest is not 
functioning on reboot.

After closing the QEMU guest, the USB bus gets reset(?) after which the other 
keyboard suddenly gets detected. I had only booted 3.10.5 twice before rolling 
back to 3.9.9, both boots triggered the issue. Do I need to provide a usbmon, 
lsusb, dmesg and/ or other details from 3.10.5?


Note that there are other Arch Linux users who have reported issues[1][2] 
since upgrading to 3.10.z. Triggering a re-enumeration by writing the magic 
HID++ message[3] makes the paired devices appear again (as reported in 
forums[1], I haven't tried this on the affected UHCI machine).

While the underlying bug is fixed, can this patch be forwarded to stable? I see 
that 3.10.6 has been released, but still without this patch.

Regards,
Peter

 [1]: https://bbs.archlinux.org/viewtopic.php?id=167210
 [2]: https://bugs.archlinux.org/task/35991
 [3]: https://bbs.archlinux.org/viewtopic.php?pid=1309535#p1309535

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-08-12 21:54   ` Peter Wu
@ 2013-08-13 12:13     ` Peter Hurley
  2013-08-13 15:42         ` Peter Wu
  0 siblings, 1 reply; 32+ messages in thread
From: Peter Hurley @ 2013-08-13 12:13 UTC (permalink / raw)
  To: Peter Wu
  Cc: Nestor Lopez Casado, jkosina, benjamin.tissoires, adlr,
	joseph.salisbury, linux-input, linux-kernel, Sarah Sharp,
	linux-usb

On 08/12/2013 05:54 PM, Peter Wu wrote:
> On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
>> Before we revert to using the workaround, I'd like to suggest that
>> this new "hidden" problem may be an interaction with the xhci_hcd host
>> controller driver only.
>>
>> Looking at the related bug, the OP indicates the machine only has
>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>> bug report add additional information that would seem to confirm
>> this suspicion.
>>
>> Let me add I have this USB device running on the uhci_hcd driver
>> with or without this workaround on v3.10.
>
> This problem does not seem specific to xhci, uhci seems also effected.

If true, it would certainly help to have a bug report confirming uhci
failure from a bare-metal system which contained:
1) kernel version
2) complete dmesg output
3) lsusb -v output
4) lsmod output
5) usbmon capture from a plug attempt

> Today I
> upgraded a system (running Arch Linux) from kernel 3.9.9 to 3.10.5. After a
> reboot to 3.10.5, things broke. The setup:
>
> - There are two USB receivers plugged into USB 1.1 ports (different buses
> according to lsusb, uhci), each receiver is paired to a K360 keyboard.
> - One of the receivers are passed to a QEMU guest with -usbdevice host:$busid.
> $devid. This keyboard is working (probably because QEMU performed a reset).
> - Since 3.10.5, the keyboard that is *not* passed to the QEMU guest is not
> functioning on reboot.
>
> After closing the QEMU guest, the USB bus gets reset(?) after which the other
> keyboard suddenly gets detected. I had only booted 3.10.5 twice before rolling
> back to 3.9.9, both boots triggered the issue. Do I need to provide a usbmon,
> lsusb, dmesg and/ or other details from 3.10.5?

Do both keyboards work on bare metal? Seems like this problem might be
specific to qemu (or kvm) and you may get more insight on those lists.

> Note that there are other Arch Linux users who have reported issues[1][2]

Unfortunately, not even one user in the referenced reports identified
the usb hub the receiver was plugged into.

> since upgrading to 3.10.z. Triggering a re-enumeration by writing the magic
> HID++ message[3] makes the paired devices appear again (as reported in
> forums[1], I haven't tried this on the affected UHCI machine).
>
> While the underlying bug is fixed, can this patch be forwarded to stable? I see
> that 3.10.6 has been released, but still without this patch.

This is still a workaround and not really a fix for the underlying bug.

> Regards,
> Peter
>
>   [1]: https://bbs.archlinux.org/viewtopic.php?id=167210
>   [2]: https://bugs.archlinux.org/task/35991
>   [3]: https://bbs.archlinux.org/viewtopic.php?pid=1309535#p1309535



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
@ 2013-08-13 15:42         ` Peter Wu
  0 siblings, 0 replies; 32+ messages in thread
From: Peter Wu @ 2013-08-13 15:42 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Nestor Lopez Casado, jkosina, benjamin.tissoires, adlr,
	joseph.salisbury, linux-input, linux-kernel, Sarah Sharp,
	linux-usb

On Tuesday 13 August 2013 08:13:17 Peter Hurley wrote:
> On 08/12/2013 05:54 PM, Peter Wu wrote:
> > On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
> >> Before we revert to using the workaround, I'd like to suggest that
> >> this new "hidden" problem may be an interaction with the xhci_hcd host
> >> controller driver only.
> >> 
> >> Looking at the related bug, the OP indicates the machine only has
> >> USB3 ports. Additionally, comments #7, #100, and #104 of the original
> >> bug report add additional information that would seem to confirm
> >> this suspicion.
> >> 
> >> Let me add I have this USB device running on the uhci_hcd driver
> >> with or without this workaround on v3.10.
> > 
> > This problem does not seem specific to xhci, uhci seems also effected.
> 
> If true, it would certainly help to have a bug report confirming uhci
> failure from a bare-metal system which contained:
> 1) kernel version
> 2) complete dmesg output
> 3) lsusb -v output
> 4) lsmod output
> 5) usbmon capture from a plug attempt

I was too fast in drawing a conclusion, besides the kernel I also upgraded 
some other packages. Today the issue also showed up in 3.9.9 + updated 
packages.

When checking the dmesg, the issue solved by this patch did not occur (the 
enumeration was successful).

> > Today I
> > upgraded a system (running Arch Linux) from kernel 3.9.9 to 3.10.5. After
> > a
> > reboot to 3.10.5, things broke. The setup:
> > 
> > - There are two USB receivers plugged into USB 1.1 ports (different buses
> > according to lsusb, uhci), each receiver is paired to a K360 keyboard.
> > - One of the receivers are passed to a QEMU guest with -usbdevice
> > host:$busid. $devid. This keyboard is working (probably because QEMU
> > performed a reset). - Since 3.10.5, the keyboard that is *not* passed to
> > the QEMU guest is not functioning on reboot.
> > 
> > After closing the QEMU guest, the USB bus gets reset(?) after which the
> > other keyboard suddenly gets detected. I had only booted 3.10.5 twice
> > before rolling back to 3.9.9, both boots triggered the issue. Do I need
> > to provide a usbmon, lsusb, dmesg and/ or other details from 3.10.5?
> 
> Do both keyboards work on bare metal? Seems like this problem might be
> specific to qemu (or kvm) and you may get more insight on those lists.

I haven't tested that, the system automatically boots into openbox + QEMU. 
Previously, both keyboards worked on bare metal, so I think it still works.

> > Note that there are other Arch Linux users who have reported issues[1][2]
> 
> Unfortunately, not even one user in the referenced reports identified
> the usb hub the receiver was plugged into.

I've asked it now.

> > since upgrading to 3.10.z. Triggering a re-enumeration by writing the
> > magic
> > HID++ message[3] makes the paired devices appear again (as reported in
> > forums[1], I haven't tried this on the affected UHCI machine).
> > 
> > While the underlying bug is fixed, can this patch be forwarded to stable?
> > I see that 3.10.6 has been released, but still without this patch.
> 
> This is still a workaround and not really a fix for the underlying bug.

I meant to say, "while the underlying bug is *being* fixed". Anyway, can this 
patch be applied to 3.10?

Sorry for the confusion with uhci, looking further it seems that the wrong USB 
receiver is being passed to QEMU. It's not a kernel issue, perhaps I can blame 
libusbx.

Regards,
Peter

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
@ 2013-08-13 15:42         ` Peter Wu
  0 siblings, 0 replies; 32+ messages in thread
From: Peter Wu @ 2013-08-13 15:42 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Nestor Lopez Casado, jkosina-AlSwsSmVLrQ,
	benjamin.tissoires-Re5JQEeQqe8AvxtiuMwx3w,
	adlr-F7+t8E8rja9g9hUCZPvPmw,
	joseph.salisbury-Z7WLFzj8eWMS+FvcfC7Uqw,
	linux-input-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sarah Sharp,
	linux-usb-u79uwXL29TY76Z2rM5mHXA

On Tuesday 13 August 2013 08:13:17 Peter Hurley wrote:
> On 08/12/2013 05:54 PM, Peter Wu wrote:
> > On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
> >> Before we revert to using the workaround, I'd like to suggest that
> >> this new "hidden" problem may be an interaction with the xhci_hcd host
> >> controller driver only.
> >> 
> >> Looking at the related bug, the OP indicates the machine only has
> >> USB3 ports. Additionally, comments #7, #100, and #104 of the original
> >> bug report add additional information that would seem to confirm
> >> this suspicion.
> >> 
> >> Let me add I have this USB device running on the uhci_hcd driver
> >> with or without this workaround on v3.10.
> > 
> > This problem does not seem specific to xhci, uhci seems also effected.
> 
> If true, it would certainly help to have a bug report confirming uhci
> failure from a bare-metal system which contained:
> 1) kernel version
> 2) complete dmesg output
> 3) lsusb -v output
> 4) lsmod output
> 5) usbmon capture from a plug attempt

I was too fast in drawing a conclusion, besides the kernel I also upgraded 
some other packages. Today the issue also showed up in 3.9.9 + updated 
packages.

When checking the dmesg, the issue solved by this patch did not occur (the 
enumeration was successful).

> > Today I
> > upgraded a system (running Arch Linux) from kernel 3.9.9 to 3.10.5. After
> > a
> > reboot to 3.10.5, things broke. The setup:
> > 
> > - There are two USB receivers plugged into USB 1.1 ports (different buses
> > according to lsusb, uhci), each receiver is paired to a K360 keyboard.
> > - One of the receivers are passed to a QEMU guest with -usbdevice
> > host:$busid. $devid. This keyboard is working (probably because QEMU
> > performed a reset). - Since 3.10.5, the keyboard that is *not* passed to
> > the QEMU guest is not functioning on reboot.
> > 
> > After closing the QEMU guest, the USB bus gets reset(?) after which the
> > other keyboard suddenly gets detected. I had only booted 3.10.5 twice
> > before rolling back to 3.9.9, both boots triggered the issue. Do I need
> > to provide a usbmon, lsusb, dmesg and/ or other details from 3.10.5?
> 
> Do both keyboards work on bare metal? Seems like this problem might be
> specific to qemu (or kvm) and you may get more insight on those lists.

I haven't tested that, the system automatically boots into openbox + QEMU. 
Previously, both keyboards worked on bare metal, so I think it still works.

> > Note that there are other Arch Linux users who have reported issues[1][2]
> 
> Unfortunately, not even one user in the referenced reports identified
> the usb hub the receiver was plugged into.

I've asked it now.

> > since upgrading to 3.10.z. Triggering a re-enumeration by writing the
> > magic
> > HID++ message[3] makes the paired devices appear again (as reported in
> > forums[1], I haven't tried this on the affected UHCI machine).
> > 
> > While the underlying bug is fixed, can this patch be forwarded to stable?
> > I see that 3.10.6 has been released, but still without this patch.
> 
> This is still a workaround and not really a fix for the underlying bug.

I meant to say, "while the underlying bug is *being* fixed". Anyway, can this 
patch be applied to 3.10?

Sorry for the confusion with uhci, looking further it seems that the wrong USB 
receiver is being passed to QEMU. It's not a kernel issue, perhaps I can blame 
libusbx.

Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
  2013-08-13 15:42         ` Peter Wu
  (?)
@ 2013-08-13 16:34         ` Peter Hurley
  -1 siblings, 0 replies; 32+ messages in thread
From: Peter Hurley @ 2013-08-13 16:34 UTC (permalink / raw)
  To: Peter Wu
  Cc: Nestor Lopez Casado, jkosina, benjamin.tissoires, adlr,
	joseph.salisbury, linux-input, linux-kernel, Sarah Sharp,
	linux-usb

On 08/13/2013 11:42 AM, Peter Wu wrote:
> On Tuesday 13 August 2013 08:13:17 Peter Hurley wrote:
>> On 08/12/2013 05:54 PM, Peter Wu wrote:
>>> On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
>>>> Before we revert to using the workaround, I'd like to suggest that
>>>> this new "hidden" problem may be an interaction with the xhci_hcd host
>>>> controller driver only.
>>>>
>>>> Looking at the related bug, the OP indicates the machine only has
>>>> USB3 ports. Additionally, comments #7, #100, and #104 of the original
>>>> bug report add additional information that would seem to confirm
>>>> this suspicion.
>>>>
>>>> Let me add I have this USB device running on the uhci_hcd driver
>>>> with or without this workaround on v3.10.
>>>
>>> This problem does not seem specific to xhci, uhci seems also effected.
>>
>> If true, it would certainly help to have a bug report confirming uhci
>> failure from a bare-metal system which contained:
>> 1) kernel version
>> 2) complete dmesg output
>> 3) lsusb -v output
>> 4) lsmod output
>> 5) usbmon capture from a plug attempt
>
> I was too fast in drawing a conclusion, besides the kernel I also upgraded
> some other packages. Today the issue also showed up in 3.9.9 + updated
> packages.
>
> When checking the dmesg, the issue solved by this patch did not occur (the
> enumeration was successful).

Thanks for double-checking.

>>> Today I
>>> upgraded a system (running Arch Linux) from kernel 3.9.9 to 3.10.5. After
>>> a
>>> reboot to 3.10.5, things broke. The setup:
>>>
>>> - There are two USB receivers plugged into USB 1.1 ports (different buses
>>> according to lsusb, uhci), each receiver is paired to a K360 keyboard.
>>> - One of the receivers are passed to a QEMU guest with -usbdevice
>>> host:$busid. $devid. This keyboard is working (probably because QEMU
>>> performed a reset). - Since 3.10.5, the keyboard that is *not* passed to
>>> the QEMU guest is not functioning on reboot.
>>>
>>> After closing the QEMU guest, the USB bus gets reset(?) after which the
>>> other keyboard suddenly gets detected. I had only booted 3.10.5 twice
>>> before rolling back to 3.9.9, both boots triggered the issue. Do I need
>>> to provide a usbmon, lsusb, dmesg and/ or other details from 3.10.5?
>>
>> Do both keyboards work on bare metal? Seems like this problem might be
>> specific to qemu (or kvm) and you may get more insight on those lists.
>
> I haven't tested that, the system automatically boots into openbox + QEMU.
> Previously, both keyboards worked on bare metal, so I think it still works.
>
>>> Note that there are other Arch Linux users who have reported issues[1][2]
>>
>> Unfortunately, not even one user in the referenced reports identified
>> the usb hub the receiver was plugged into.
>
> I've asked it now.

Thanks. And if someone has a uhci failure, filing a new bug on
bugzilla.kernel.org _and_ posting to linux-usb@ and
linux-input@vger.kernel.org improves the chances of the right
people seeing the problem. [xhci already has several reports plus I
subscribed to the kernel bug linked from the ArchLinux bug report.]

>>> since upgrading to 3.10.z. Triggering a re-enumeration by writing the
>>> magic
>>> HID++ message[3] makes the paired devices appear again (as reported in
>>> forums[1], I haven't tried this on the affected UHCI machine).
>>>
>>> While the underlying bug is fixed, can this patch be forwarded to stable?
>>> I see that 3.10.6 has been released, but still without this patch.
>>
>> This is still a workaround and not really a fix for the underlying bug.
>
> I meant to say, "while the underlying bug is *being* fixed". Anyway, can this
> patch be applied to 3.10?

That's really Jiri's call. TBH, I can't blame him for wanting to shake this
out in 3.11 before pushing to stable.

> Sorry for the confusion with uhci, looking further it seems that the wrong USB
> receiver is being passed to QEMU. It's not a kernel issue, perhaps I can blame
> libusbx.

No apologies necessary.

Regards,
Peter Hurley


^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2013-08-13 16:35 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-18 13:21 [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Nestor Lopez Casado
2013-07-18 13:21 ` [PATCH 2/2] HID: hid-logitech-dj, querying_devices was never set Nestor Lopez Casado
2013-08-01 10:09   ` Benjamin Tissoires
2013-08-02  1:11     ` Jiri Kosina
2013-08-02 18:31       ` Benjamin Tissoires
2013-08-05 13:22         ` Jiri Kosina
2013-08-05 14:40           ` Benjamin Tissoires
2013-08-06 21:03             ` Sune Mølgaard
2013-08-09  9:36               ` Jiri Kosina
2013-08-09  9:36                 ` Jiri Kosina
2013-08-10 17:21               ` Jiri Kosina
2013-08-10 17:21                 ` Jiri Kosina
2013-07-18 20:28 ` [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" Peter Hurley
2013-07-18 22:09   ` Sarah Sharp
2013-07-18 23:37     ` Peter Hurley
2013-07-19  8:35       ` Benjamin Tissoires
2013-07-19 14:38       ` Joseph Salisbury
2013-07-19 21:31         ` Peter Hurley
2013-07-22 11:44           ` Jiri Kosina
2013-07-22 14:03             ` Peter Hurley
2013-07-22 15:27               ` Alan Stern
2013-07-22 15:27                 ` Alan Stern
2013-07-19 15:14     ` Alan Stern
2013-07-19 15:14       ` Alan Stern
2013-07-19 16:43     ` Nestor Lopez Casado
2013-08-12 21:54   ` Peter Wu
2013-08-13 12:13     ` Peter Hurley
2013-08-13 15:42       ` Peter Wu
2013-08-13 15:42         ` Peter Wu
2013-08-13 16:34         ` Peter Hurley
2013-07-22 14:35 ` Jiri Kosina
2013-07-22 19:21   ` Linus Torvalds

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.