Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
I've tried; it wasn't accepted. The patch below should be more acceptable to the maintainer. Try it instead of the other one; it ought to get rid of all those error messages showing up in the log as well as fixing the mouse problem. That is, it won't prevent the actual errors from occurring at a rate of ~1 per minute -- it will just stop the driver from logging the messages. If it works well, I'll submit it. OK, it works well for me since 8 days. I hope it will be included in one of the next kernel releases. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Thu, 22 Dec 2005, Willi Mann wrote: > >>- Now see what's happening when I unplug the mouse "fast": > >> > >>Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > >>status -84 received > >>Dec 21 14:40:44 wmiwilli last message repeated 2 times > >>... > > > >>- When I unplug it "slowly": > >> > >>Dec 21 14:41:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > >>status -84 received > >>Dec 21 14:41:28 wmiwilli last message repeated 7 times > >>.. > > > I don't see any significant difference. Did I miss something? > > I was just thinking what will happen if someone unplugs the mouse (or > another HID device) not completely. Will that fill up the kernel logs? It shouldn't. Either the device is able to drive the USB data lines or it isn't. If it can then it should function normally. If it can't, the kernel will realize it was disconnected. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
I've dropped Helmut Zeisel as cc: and will send him notice a when the issue is resolved. He can read our conversation in the mailing list archive anyway. I've tried; it wasn't accepted. The patch below should be more acceptable to the maintainer. Try it instead of the other one; it ought to get rid of all those error messages showing up in the log as well as fixing the mouse problem. That is, it won't prevent the actual errors from occurring at a rate of ~1 per minute -- it will just stop the driver from logging the messages. If it works well, I'll submit it. I'll try. - Now see what's happening when I unplug the mouse "fast": Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:40:44 wmiwilli last message repeated 2 times ... - When I unplug it "slowly": Dec 21 14:41:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:41:28 wmiwilli last message repeated 7 times .. I don't see any significant difference. Did I miss something? I was just thinking what will happen if someone unplugs the mouse (or another HID device) not completely. Will that fill up the kernel logs? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Wed, 21 Dec 2005, Willi Mann wrote: > > By the way, it looks like you don't need the entire patch. Just the parts > > the remove the lines saying > > > > case -EILSEQ: > > > > should be enough to help. > > confirmed. What's needed to get that into the offical kernel releases? I've tried; it wasn't accepted. The patch below should be more acceptable to the maintainer. Try it instead of the other one; it ought to get rid of all those error messages showing up in the log as well as fixing the mouse problem. That is, it won't prevent the actual errors from occurring at a rate of ~1 per minute -- it will just stop the driver from logging the messages. If it works well, I'll submit it. > - Now see what's happening when I unplug the mouse "fast": > > Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > status -84 received > Dec 21 14:40:44 wmiwilli last message repeated 2 times > Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: state 5 ports 2 chg > evt 0002 > Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: port 1 portsc > 008a,00 > Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: port 1, status 0100, > change 0003, 12 Mb/s > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: USB disconnect, address 2 > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: usb_disable_device nuking all URBs > Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: shutdown urb > dd36b740 pipe 40408280 ep1in-intr > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: unregistering interface 2-1:1.0 > Dec 21 14:40:44 wmiwilli kernel: usb 2-1:1.0: hotplug > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: unregistering device > Dec 21 14:40:44 wmiwilli kernel: usb 2-1: hotplug > Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: debounce: port 1: total > 100ms stable 100ms status 0x100 > - When I unplug it "slowly": > > Dec 21 14:41:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq > status -84 received > Dec 21 14:41:28 wmiwilli last message repeated 7 times > Dec 21 14:41:28 wmiwilli kernel: hub 2-0:1.0: state 5 ports 2 chg > evt 0002 > Dec 21 14:41:28 wmiwilli kernel: uhci_hcd :00:1d.1: port 1 portsc > 008a,00 > Dec 21 14:41:28 wmiwilli kernel: hub 2-0:1.0: port 1, status 0100, > change 0003, 12 Mb/s > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: USB disconnect, address 4 > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: usb_disable_device nuking all URBs > Dec 21 14:41:28 wmiwilli kernel: uhci_hcd :00:1d.1: shutdown urb > cb373140 pipe 40408480 ep1in-intr > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: unregistering interface 2-1:1.0 > Dec 21 14:41:28 wmiwilli kernel: usb 2-1:1.0: hotplug > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: unregistering device > Dec 21 14:41:28 wmiwilli kernel: usb 2-1: hotplug > Dec 21 14:41:28 wmiwilli kernel: hub 2-0:1.0: debounce: port 1: total > 100ms stable 100ms status 0x100 I don't see any significant difference. Did I miss something? Alan Stern Index: linux-2.6.15-rc6/drivers/usb/input/hid-core.c === --- linux-2.6.15-rc6.orig/drivers/usb/input/hid-core.c +++ linux-2.6.15-rc6/drivers/usb/input/hid-core.c @@ -927,8 +927,8 @@ static void hid_irq_in(struct urb *urb, case -ENOENT: case -EPERM: case -ESHUTDOWN:/* unplug */ - case -EILSEQ: /* unplug timeout on uhci */ return; + case -EILSEQ: /* protocol error or unplug */ case -ETIMEDOUT:/* NAK */ break; default:/* error */ @@ -1101,8 +1101,8 @@ static void hid_irq_out(struct urb *urb, case 0: /* success */ break; case -ESHUTDOWN:/* unplug */ - case -EILSEQ: /* unplug timeout on uhci */ unplug = 1; + case -EPROTO: /* protocol error or unplug */ case -ECONNRESET: /* unlink */ case -ENOENT: break; @@ -1149,8 +1149,9 @@ static void hid_ctrl(struct urb *urb, st hid_input_report(hid->ctrl[hid->ctrltail].report->type, urb, 0, regs); break; case -ESHUTDOWN:/* unplug */ - case -EILSEQ: /* unplug timectrl on uhci */ unplug = 1; + case -EILSEQ: /* protocol error or unplug */ + case -EPROTO: /* protocol error or unplug */ case -ECONNRESET: /* unlink */ case -ENOENT: case -EPIPE:/* report not available */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
That particular error generally means that something is interfering with the USB data transmission. It could be a poor cable connection, or it could be the mouse sending a bad signal, or it could be some sort of outside electromagnetic interference. I would like to test with other USB mice. Unfortunately, I only have these two logitech mice for testing. By the way, it looks like you don't need the entire patch. Just the parts the remove the lines saying case -EILSEQ: should be enough to help. confirmed. What's needed to get that into the offical kernel releases? For reference, some more log snippets: - Log snippet from today to see the frequency: Dec 21 11:32:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:34:12 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:37:28 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:38:54 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:40:06 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:41:04 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:53:06 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:54:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:55:17 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:57:42 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:53:23 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:54:36 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:55:17 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:56:04 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:57:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:02:23 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:03:17 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:03:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:05:01 wmiwilli last message repeated 2 times Dec 21 13:06:46 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:07:47 wmiwilli last message repeated 2 times Dec 21 13:08:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:09:54 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:11:07 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:13:15 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:13:52 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:14:55 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:20:48 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:21:33 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:23:14 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:24:26 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:25:45 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:28:41 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:18:15 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:18:28 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:30:33 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:31:21 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:37:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:39:05 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received - Now see what's happening when I unplug the mouse "fast": Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:40:44 wmiwilli last message repeated 2 times Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: state 5 ports 2 chg evt 0002 Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: port 1 portsc 008a,00 Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: port 1, status 0100, change 0003, 12 Mb/s Dec 21 14:40:44 wmiwilli kernel: usb 2-1: USB disconnect, address 2 Dec 21 14:40:44 wmiwilli kernel: usb 2-1: usb_disable_device nuking all URBs Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: shutdown urb dd36b740 pipe 40408280 ep1in-intr Dec 21 14:40:44 wmiwilli kernel: usb 2-1: unregistering inter
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sat, 17 Dec 2005, Willi Mann wrote: > There seems to be relation between mouse usage and the -84 signal: The > more I use the mouse the less it occurs. That particular error generally means that something is interfering with the USB data transmission. It could be a poor cable connection, or it could be the mouse sending a bad signal, or it could be some sort of outside electromagnetic interference. By the way, it looks like you don't need the entire patch. Just the parts the remove the lines saying case -EILSEQ: should be enough to help. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sat, 17 Dec 2005, Willi Mann wrote: > > Yes indeed. This looks very similar to the problem reported in > > > > http://bugzilla.kernel.org/show_bug.cgi?id=4916 > > > > See especially comment #19. > > > > It's possible that the patch adding an HID reset routine (the last > > attachment in the bug report) will work for you. You might have to fiddle > > with it a little, because it is now four months old. > > Yes, it works. No more freezing mouse despite the cold weather outside :-) > > > This _should_ have shown up in the dmesg log if you had CONFIG_USB_DEBUG > > turned on. Make sure you have it on when running more tests. > > Do you mean, it should have shown up without this patch? Since you told > me to enable CONFIG_USB_DEBUG, I had it always on while testing, but I > never saw that messages. Or do you mean, it is bug that these messages > weren't reported when CONFIG_USB_DEBUG is on? I meant that there should have been something in the log even without the patch. Not the same as what you get with the patch, but something. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
I now recreated the patch in a more usable way.
BTW:
Dec 17 20:50:30 wmiwilli kernel: mtrr: 0xe800,0x800 overlaps
existing 0xe800,0x100
Dec 17 21:01:25 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:25:43 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:29:56 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:56:45 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:58:49 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 22:07:52 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 22:08:26 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 22:10:29 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
There seems to be relation between mouse usage and the -84 signal: The
more I use the mouse the less it occurs.
Willi
diff -ru rr/linux-source-2.6.14/drivers/usb/input/hid-core.c
linux-source-2.6.14/drivers/usb/input/hid-core.c
--- rr/linux-source-2.6.14/drivers/usb/input/hid-core.c 2005-10-28
02:02:08.0 +0200
+++ linux-source-2.6.14/drivers/usb/input/hid-core.c2005-12-17
20:31:41.0 +0100
@@ -909,6 +909,29 @@
}
/*
+ * Request a device reset.
+ */
+static void hid_reset(void *_hid)
+{
+ struct hid_device *hid = _hid;
+ int rc, result;
+
+ hid->in_error_cnt = 0;
+ rc = result = usb_lock_device_for_reset(hid->dev, hid->intf);
+ if (rc >= 0) {
+ result = usb_reset_device(hid->dev);
+ if (result == 0 && hid->open)
+ result = usb_submit_urb(hid->urbin, GFP_NOIO);
+ if (rc)
+ usb_unlock_device(hid->dev);
+ }
+ if (result < 0)
+ warn("can't reset device, %s-%s/input%d, result %d",
+ hid->dev->bus->bus_name, hid->dev->devpath,
+ hid->ifnum, result);
+}
+
+/*
* Input interrupt completion handler.
*/
@@ -919,18 +942,20 @@
switch (urb->status) {
case 0: /* success */
+ hid->in_error_cnt = 0;
hid_input_report(HID_INPUT_REPORT, urb, 1, regs);
break;
case -ECONNRESET: /* unlink */
case -ENOENT:
case -EPERM:
case -ESHUTDOWN:/* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
return;
- case -ETIMEDOUT:/* NAK */
- break;
default:/* error */
warn("input irq status %d received", urb->status);
+ if (++hid->in_error_cnt >= 10) {
+ schedule_work(&hid->work);
+ return;
+ }
}
status = usb_submit_urb(urb, SLAB_ATOMIC);
@@ -1099,7 +1124,6 @@
case 0: /* success */
break;
case -ESHUTDOWN:/* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1147,7 +1171,6 @@
hid_input_report(hid->ctrl[hid->ctrltail].report->type, urb, 0, regs);
break;
case -ESHUTDOWN:/* unplug */
- case -EILSEQ: /* unplug timectrl on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1781,6 +1804,7 @@
hid->urbctrl->transfer_dma = hid->ctrlbuf_dma;
hid->urbctrl->transfer_flags |= (URB_NO_TRANSFER_DMA_MAP |
URB_NO_SETUP_DMA_MAP);
+ INIT_WORK(&hid->work, hid_reset, hid);
return hid;
fail:
@@ -1808,6 +1832,7 @@
usb_kill_urb(hid->urbin);
usb_kill_urb(hid->urbout);
usb_kill_urb(hid->urbctrl);
+ flush_scheduled_work();
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_disconnect(hid);
diff -ru rr/linux-source-2.6.14/drivers/usb/input/hid.h
linux-source-2.6.14/drivers/usb/input/hid.h
--- rr/linux-source-2.6.14/drivers/usb/input/hid.h 2005-10-28
02:02:08.0 +0200
+++ linux-source-2.6.14/drivers/usb/input/hid.h 2005-12-17 21:12:07.0
+0100
@@ -396,6 +396,8 @@
struct urb *urbin; /*
Input URB */
char *inbuf;/*
Input buffer */
dma_addr_t inbuf_dma; /*
Input buffer dma */
+ int in
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
Yes indeed. This looks very similar to the problem reported in
http://bugzilla.kernel.org/show_bug.cgi?id=4916
See especially comment #19.
It's possible that the patch adding an HID reset routine (the last
attachment in the bug report) will work for you. You might have to fiddle
with it a little, because it is now four months old.
Yes, it works. No more freezing mouse despite the cold weather outside :-)
This _should_ have shown up in the dmesg log if you had CONFIG_USB_DEBUG
turned on. Make sure you have it on when running more tests.
Do you mean, it should have shown up without this patch? Since you told
me to enable CONFIG_USB_DEBUG, I had it always on while testing, but I
never saw that messages. Or do you mean, it is bug that these messages
weren't reported when CONFIG_USB_DEBUG is on?
The last 4 kernel messages since the first boot with your patch:
Dec 17 20:50:30 . kernel: mtrr: 0xe800,0x800 overlaps existing
0xe800,0x100
Dec 17 21:01:25 . kernel: drivers/usb/input/hid-core.c: input irq status
-84 received
Dec 17 21:25:43 . kernel: drivers/usb/input/hid-core.c: input irq status
-84 received
Dec 17 21:29:56 . kernel: drivers/usb/input/hid-core.c: input irq status
-84 received
I'm CCing Helmut Zeisel, he reported the same issue in an austrian
newsgroup. Helmut, you might want to try attached patch to fix our
"dying mouse" issue.
Willi
--- hid.h.bak 2005-12-17 20:25:41.0 +0100
+++ hid.h 2005-12-17 21:12:07.0 +0100
@@ -396,6 +396,8 @@
struct urb *urbin; /* Input URB */
char *inbuf; /* Input buffer */
dma_addr_t inbuf_dma; /* Input buffer dma */
+ int in_error_cnt; /* Input error counter */
+ struct work_struct work; /* Perform asynchronous reset */
struct urb *urbctrl; /* Control URB */
struct usb_ctrlrequest *cr; /* Control request struct */
--- hid-core.c.bak 2005-12-17 20:26:53.0 +0100
+++ hid-core.c 2005-12-17 20:31:41.0 +0100
@@ -909,6 +909,29 @@
}
/*
+ * Request a device reset.
+ */
+static void hid_reset(void *_hid)
+{
+ struct hid_device *hid = _hid;
+ int rc, result;
+
+ hid->in_error_cnt = 0;
+ rc = result = usb_lock_device_for_reset(hid->dev, hid->intf);
+ if (rc >= 0) {
+ result = usb_reset_device(hid->dev);
+ if (result == 0 && hid->open)
+ result = usb_submit_urb(hid->urbin, GFP_NOIO);
+ if (rc)
+ usb_unlock_device(hid->dev);
+ }
+ if (result < 0)
+ warn("can't reset device, %s-%s/input%d, result %d",
+hid->dev->bus->bus_name, hid->dev->devpath,
+hid->ifnum, result);
+}
+
+/*
* Input interrupt completion handler.
*/
@@ -919,18 +942,20 @@
switch (urb->status) {
case 0: /* success */
+ hid->in_error_cnt = 0;
hid_input_report(HID_INPUT_REPORT, urb, 1, regs);
break;
case -ECONNRESET: /* unlink */
case -ENOENT:
case -EPERM:
case -ESHUTDOWN: /* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
return;
- case -ETIMEDOUT: /* NAK */
- break;
default: /* error */
warn("input irq status %d received", urb->status);
+ if (++hid->in_error_cnt >= 10) {
+schedule_work(&hid->work);
+return;
+ }
}
status = usb_submit_urb(urb, SLAB_ATOMIC);
@@ -1099,7 +1124,6 @@
case 0: /* success */
break;
case -ESHUTDOWN: /* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1147,7 +1171,6 @@
hid_input_report(hid->ctrl[hid->ctrltail].report->type, urb, 0, regs);
break;
case -ESHUTDOWN: /* unplug */
- case -EILSEQ: /* unplug timectrl on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1781,6 +1804,7 @@
hid->urbctrl->transfer_dma = hid->ctrlbuf_dma;
hid->urbctrl->transfer_flags |= (URB_NO_TRANSFER_DMA_MAP | URB_NO_SETUP_DMA_MAP);
+ INIT_WORK(&hid->work, hid_reset, hid);
return hid;
fail:
@@ -1808,6 +1832,7 @@
usb_kill_urb(hid->urbin);
usb_kill_urb(hid->urbout);
usb_kill_urb(hid->urbctrl);
+ flush_scheduled_work();
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_disconnect(hid);
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sat, 17 Dec 2005, Willi Mann wrote: > Ok, here is what I did: > cat 2t > -> minimize the gnome-terminal > -> surfed the web > -> suddenly mouse died > -> Strg + Alt + F1, Alt+ F7 > -> reopened the terminal > -> marked the last > 200 lines > -> pasted in file > -> grepped for the mouse identifier 002:01 > here are the last lines of that output: > ddd8de40 618383777 S Ii:002:01 -115 4 = 00ff > ddd8de40 618431747 C Ii:002:01 0 4 = 00ff > ddd8de40 618431774 S Ii:002:01 -115 4 = 00ff > ddd8de40 723190277 C Ii:002:01 -84 0 > ddd8de40 769897561 S Ii:002:01 -115 4 = 00ff > ddd8de40 769910480 C Ii:002:01 0 4 = 00838200 > ddd8de40 769910495 S Ii:002:01 -115 4 = 00838200 > > Does that somehow help to track it down? The event in µs 723190277 seems > very suspicious to me. Yes indeed. This looks very similar to the problem reported in http://bugzilla.kernel.org/show_bug.cgi?id=4916 See especially comment #19. It's possible that the patch adding an HID reset routine (the last attachment in the bug report) will work for you. You might have to fiddle with it a little, because it is now four months old. This _should_ have shown up in the dmesg log if you had CONFIG_USB_DEBUG turned on. Make sure you have it on when running more tests. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
Yes. Read Documentation/usb/usbmon.txt in the kernel source. Ok, here is what I did: cat 2t -> minimize the gnome-terminal -> surfed the web -> suddenly mouse died -> Strg + Alt + F1, Alt+ F7 -> reopened the terminal -> marked the last > 200 lines -> pasted in file -> grepped for the mouse identifier 002:01 here are the last lines of that output: ddd8de40 605937824 C Ii:002:01 0 4 = 00010100 ddd8de40 605937845 S Ii:002:01 -115 4 = 00010100 ddd8de40 605969820 C Ii:002:01 0 4 = 0001 ddd8de40 605969843 S Ii:002:01 -115 4 = 0001 ddd8de40 606809680 C Ii:002:01 0 4 = 01ff ddd8de40 606809704 S Ii:002:01 -115 4 = 01ff ddd8de40 607105630 C Ii:002:01 0 4 = 00ff ddd8de40 607105656 S Ii:002:01 -115 4 = 00ff ddd8de40 607121630 C Ii:002:01 0 4 = 00ff ddd8de40 607121656 S Ii:002:01 -115 4 = 00ff ddd8de40 607169624 C Ii:002:01 0 4 = 00ff ddd8de40 607169655 S Ii:002:01 -115 4 = 00ff ddd8de40 612744692 C Ii:002:01 0 4 = 00ff ddd8de40 612744717 S Ii:002:01 -115 4 = 00ff ddd8de40 613024644 C Ii:002:01 0 4 = 00ff ddd8de40 613024670 S Ii:002:01 -115 4 = 00ff ddd8de40 613040644 C Ii:002:01 0 4 = 00ff ddd8de40 613040670 S Ii:002:01 -115 4 = 00ff ddd8de40 613056640 C Ii:002:01 0 4 = 00ff ddd8de40 613056665 S Ii:002:01 -115 4 = 00ff ddd8de40 613072638 C Ii:002:01 0 4 = 00ff ddd8de40 613072661 S Ii:002:01 -115 4 = 00ff ddd8de40 613088637 C Ii:002:01 0 4 = 00ff ddd8de40 613088667 S Ii:002:01 -115 4 = 00ff ddd8de40 613112637 C Ii:002:01 0 4 = 00ff ddd8de40 613112671 S Ii:002:01 -115 4 = 00ff ddd8de40 613760520 C Ii:002:01 0 4 = 00ff ddd8de40 613760545 S Ii:002:01 -115 4 = 00ff ddd8de40 613800519 C Ii:002:01 0 4 = 00ff ddd8de40 613800546 S Ii:002:01 -115 4 = 00ff ddd8de40 614552386 C Ii:002:01 0 4 = 00ff ddd8de40 614552411 S Ii:002:01 -115 4 = 00ff ddd8de40 614568386 C Ii:002:01 0 4 = 00ff ddd8de40 614568411 S Ii:002:01 -115 4 = 00ff ddd8de40 614584385 C Ii:002:01 0 4 = 00ff ddd8de40 614584412 S Ii:002:01 -115 4 = 00ff ddd8de40 614600387 C Ii:002:01 0 4 = 00ff ddd8de40 614600414 S Ii:002:01 -115 4 = 00ff ddd8de40 614616379 C Ii:002:01 0 4 = 00ff ddd8de40 614616401 S Ii:002:01 -115 4 = 00ff ddd8de40 614672373 C Ii:002:01 0 4 = 00ff ddd8de40 614672399 S Ii:002:01 -115 4 = 00ff ddd8de40 617215945 C Ii:002:01 0 4 = 00ff ddd8de40 617215970 S Ii:002:01 -115 4 = 00ff ddd8de40 617879834 C Ii:002:01 0 4 = 00ff ddd8de40 617879859 S Ii:002:01 -115 4 = 00ff ddd8de40 617911835 C Ii:002:01 0 4 = 00ff ddd8de40 617911864 S Ii:002:01 -115 4 = 00ff ddd8de40 618383751 C Ii:002:01 0 4 = 00ff ddd8de40 618383777 S Ii:002:01 -115 4 = 00ff ddd8de40 618431747 C Ii:002:01 0 4 = 00ff ddd8de40 618431774 S Ii:002:01 -115 4 = 00ff ddd8de40 723190277 C Ii:002:01 -84 0 ddd8de40 769897561 S Ii:002:01 -115 4 = 00ff ddd8de40 769910480 C Ii:002:01 0 4 = 00838200 ddd8de40 769910495 S Ii:002:01 -115 4 = 00838200 Does that somehow help to track it down? The event in µs 723190277 seems very suspicious to me. thanks Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Sun, 4 Dec 2005, Willi Mann wrote: > > > To get more information, turn on USB verbose debugging (CONFIG_USB_DEBUG) > > in the kernel configuration and rebuild the USB drivers. Post the kernel > > or dmesg log showing what happens when the connection is lost. > > I've used the debian source for that. They currently don't patch > anything usb-related. I've set CONFIG_USB_DEBUG=y and changed the > processor family to Pentium M. These are the only differences to the > distributed debian kernels. > > Unfortunatly, when the connection is lost, there is no message in dmesg. > And there's also no message when the connection is reactivated. (By chvt > 1 && sleep 1 && chvt 7) Then the problem must be unrelated to the USB stack. > when I unplug and replug the mouse, the following happens: > > hub 2-0:1.0: state 5 ports 2 chg evt 0004 > uhci_hcd :00:1d.1: port 2 portsc 008a,00 > hub 2-0:1.0: port 2, status 0100, change 0003, 12 Mb/s > usb 2-2: USB disconnect, address 3 > usb 2-2: usb_disable_device nuking all URBs > usb 2-2: unregistering interface 2-2:1.0 > usb 2-2:1.0: hotplug > usb 2-2: unregistering device > usb 2-2: hotplug > hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 > hub 4-0:1.0: state 5 ports 6 chg evt 0010 > ehci_hcd :00:1d.7: GetStatus port 4 status 001403 POWER sig=k CSC > CONNECT > hub 4-0:1.0: port 4, status 0501, change 0001, 480 Mb/s > hub 4-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x501 > ehci_hcd :00:1d.7: port 4 low speed --> companion > ehci_hcd :00:1d.7: GetStatus port 4 status 003002 POWER OWNER > sig=se0 CSC > hub 2-0:1.0: state 5 ports 2 chg evt 0004 > uhci_hcd :00:1d.1: port 2 portsc 01a3,00 > hub 2-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s > hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 > usb 2-2: new low speed USB device using uhci_hcd and address 4 > usb 2-2: skipped 1 descriptor after interface > usb 2-2: default language 0x0409 > usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=0 > usb 2-2: Product: USB Mouse > usb 2-2: Manufacturer: Logitech > usb 2-2: hotplug > usb 2-2: adding 2-2:1.0 (config #1, interface 0) > usb 2-2:1.0: hotplug > usbhid 2-2:1.0: usb_probe_interface > usbhid 2-2:1.0: usb_probe_interface - got id > input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:1d.1-2 > hub 2-0:1.0: state 5 ports 2 chg evt 0004 That's all normal. > Is there some usb sniffer for linux around? Maybe that would shed some > more light on this issue. Yes. Read Documentation/usb/usbmon.txt in the kernel source. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
To get more information, turn on USB verbose debugging (CONFIG_USB_DEBUG) in the kernel configuration and rebuild the USB drivers. Post the kernel or dmesg log showing what happens when the connection is lost. I've used the debian source for that. They currently don't patch anything usb-related. I've set CONFIG_USB_DEBUG=y and changed the processor family to Pentium M. These are the only differences to the distributed debian kernels. Unfortunatly, when the connection is lost, there is no message in dmesg. And there's also no message when the connection is reactivated. (By chvt 1 && sleep 1 && chvt 7) when I unplug and replug the mouse, the following happens: hub 2-0:1.0: state 5 ports 2 chg evt 0004 uhci_hcd :00:1d.1: port 2 portsc 008a,00 hub 2-0:1.0: port 2, status 0100, change 0003, 12 Mb/s usb 2-2: USB disconnect, address 3 usb 2-2: usb_disable_device nuking all URBs usb 2-2: unregistering interface 2-2:1.0 usb 2-2:1.0: hotplug usb 2-2: unregistering device usb 2-2: hotplug hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 hub 4-0:1.0: state 5 ports 6 chg evt 0010 ehci_hcd :00:1d.7: GetStatus port 4 status 001403 POWER sig=k CSC CONNECT hub 4-0:1.0: port 4, status 0501, change 0001, 480 Mb/s hub 4-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x501 ehci_hcd :00:1d.7: port 4 low speed --> companion ehci_hcd :00:1d.7: GetStatus port 4 status 003002 POWER OWNER sig=se0 CSC hub 2-0:1.0: state 5 ports 2 chg evt 0004 uhci_hcd :00:1d.1: port 2 portsc 01a3,00 hub 2-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 usb 2-2: new low speed USB device using uhci_hcd and address 4 usb 2-2: skipped 1 descriptor after interface usb 2-2: default language 0x0409 usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-2: Product: USB Mouse usb 2-2: Manufacturer: Logitech usb 2-2: hotplug usb 2-2: adding 2-2:1.0 (config #1, interface 0) usb 2-2:1.0: hotplug usbhid 2-2:1.0: usb_probe_interface usbhid 2-2:1.0: usb_probe_interface - got id input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:1d.1-2 hub 2-0:1.0: state 5 ports 2 chg evt 0004 Is there some usb sniffer for linux around? Maybe that would shed some more light on this issue. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse "dies"
On Thu, 1 Dec 2005, Willi Mann wrote: > > > I have already reported this bug in the Debian BTS with many details: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314954 > > > I have now tested with a second logitech mouse attached. > > Bus 004 Device 004: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 > USB-2.0 "TetraHub" > Bus 004 Device 001: ID : > Bus 002 Device 006: ID 046a:0004 Cherry GmbH > Bus 002 Device 001: ID : > Bus 001 Device 007: ID 046d:c00e Logitech, Inc. Optical Mouse > Bus 001 Device 006: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse > Bus 001 Device 001: ID : > Bus 003 Device 001: ID : > > It also loses the connection after a random amount of time (or maybe > mouse move distance), but they lose the connection independently of each > other. (Note that both mice are wheel mice, and share the same design, > doesn't make sense to me that one is named ".. Mouse" and one ".. Wheel > Mouse") To get more information, turn on USB verbose debugging (CONFIG_USB_DEBUG) in the kernel configuration and rebuild the USB drivers. Post the kernel or dmesg log showing what happens when the connection is lost. Alan Stern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
