| 2015-05-17 14:39:49 |
Alexander Ponyatykh |
bug |
|
|
added bug |
| 2015-05-17 14:39:49 |
Alexander Ponyatykh |
attachment added |
|
12_hung_after_resume.diff https://bugs.launchpad.net/bugs/1455924/+attachment/4398983/+files/12_hung_after_resume.diff |
|
| 2015-05-17 14:47:48 |
Alexander Ponyatykh |
description |
I'm trying to make g15daemon correctly recover after suspend/resume and found that it occasionally hungs after resume in libusb's usb_urb_transfer() (linux.c) on this line:
ioctl(dev->fd, IOCTL_USB_REAPURB, &context);
After some research I found that linux kernel internally has lists of pending and completed requests. All requests - successful or not - are moved from pending list to completed list, no requests should be lost. But it looks like after suspend/resume some request may be lost (may be a kernel bug). It that case IOCTL_USB_REAPURB would hung forever since request it's waiting for will never appear on completed list.
There is simple workaround. After preceding IOCTL_USB_DISCARDURB call our request is guaranteed to be completed, so there is no need to use blocking IOCTL_USB_DISCARDURB, we may use non-blocking IOCTL_USB_REAPURBNDELAY instead.
I've attached path for this workaround. It also fixes race condition existed in original code, which may cause corruption of stack.
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: libusb-0.1-4 2:0.1.12-25 [modified: lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4]
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: KDE
Date: Sun May 17 13:11:00 2015
Dependencies:
gcc-5-base 5.1~rc1-0ubuntu1
libc6 2.21-0ubuntu4
libgcc1 1:5.1~rc1-0ubuntu1
multiarch-support 2.21-0ubuntu4
SourcePackage: libusb
UpgradeStatus: Upgraded to vivid on 2015-04-26 (21 days ago) |
I'm trying to make g15daemon correctly recover after suspend/resume and found that it occasionally hungs after resume in libusb's usb_urb_transfer() (linux.c) on this line:
ioctl(dev->fd, IOCTL_USB_REAPURB, &context);
After some research I found that linux kernel internally has lists of pending and completed requests. All requests - successful or not - are moved from pending list to completed list, no requests should be lost. But it looks like after suspend/resume some request may be lost (may be a kernel bug). It that case IOCTL_USB_REAPURB would hung forever since request it's waiting for will never appear on completed list.
There is simple workaround. After preceding IOCTL_USB_DISCARDURB call our request is guaranteed to be completed, so there is no need to use blocking IOCTL_USB_DISCARDURB, we may use non-blocking IOCTL_USB_REAPURBNDELAY instead.
I've attached patch with this workaround. It also fixes race condition existed in original code, which may cause corruption of stack.
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: libusb-0.1-4 2:0.1.12-25 [modified: lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4]
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: KDE
Date: Sun May 17 13:11:00 2015
Dependencies:
gcc-5-base 5.1~rc1-0ubuntu1
libc6 2.21-0ubuntu4
libgcc1 1:5.1~rc1-0ubuntu1
multiarch-support 2.21-0ubuntu4
SourcePackage: libusb
UpgradeStatus: Upgraded to vivid on 2015-04-26 (21 days ago) |
|
| 2015-05-17 16:18:48 |
Ubuntu Foundations Team Bug Bot |
tags |
amd64 apport-bug vivid |
amd64 apport-bug patch vivid |
|
| 2015-05-17 16:18:54 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2015-05-17 16:37:35 |
Alexander Ponyatykh |
summary |
libusb occasionally hungs after suspend/resume |
libusb occasionally hangs after suspend/resume |
|
| 2015-05-17 16:38:17 |
Alexander Ponyatykh |
description |
I'm trying to make g15daemon correctly recover after suspend/resume and found that it occasionally hungs after resume in libusb's usb_urb_transfer() (linux.c) on this line:
ioctl(dev->fd, IOCTL_USB_REAPURB, &context);
After some research I found that linux kernel internally has lists of pending and completed requests. All requests - successful or not - are moved from pending list to completed list, no requests should be lost. But it looks like after suspend/resume some request may be lost (may be a kernel bug). It that case IOCTL_USB_REAPURB would hung forever since request it's waiting for will never appear on completed list.
There is simple workaround. After preceding IOCTL_USB_DISCARDURB call our request is guaranteed to be completed, so there is no need to use blocking IOCTL_USB_DISCARDURB, we may use non-blocking IOCTL_USB_REAPURBNDELAY instead.
I've attached patch with this workaround. It also fixes race condition existed in original code, which may cause corruption of stack.
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: libusb-0.1-4 2:0.1.12-25 [modified: lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4]
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: KDE
Date: Sun May 17 13:11:00 2015
Dependencies:
gcc-5-base 5.1~rc1-0ubuntu1
libc6 2.21-0ubuntu4
libgcc1 1:5.1~rc1-0ubuntu1
multiarch-support 2.21-0ubuntu4
SourcePackage: libusb
UpgradeStatus: Upgraded to vivid on 2015-04-26 (21 days ago) |
I'm trying to make g15daemon correctly recover after suspend/resume and found that it occasionally hangs after resume in libusb's usb_urb_transfer() (linux.c) on this line:
ioctl(dev->fd, IOCTL_USB_REAPURB, &context);
After some research I found that linux kernel internally has lists of pending and completed requests. All requests - successful or not - are moved from pending list to completed list, no requests should be lost. But it looks like after suspend/resume some request may be lost (may be a kernel bug). It that case IOCTL_USB_REAPURB would hang forever since request it's waiting for will never appear on completed list.
There is simple workaround. After preceding IOCTL_USB_DISCARDURB call our request is guaranteed to be completed, so there is no need to use blocking IOCTL_USB_DISCARDURB, we may use non-blocking IOCTL_USB_REAPURBNDELAY instead.
I've attached patch with this workaround. It also fixes race condition existed in original code, which may cause corruption of stack.
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: libusb-0.1-4 2:0.1.12-25 [modified: lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4]
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: KDE
Date: Sun May 17 13:11:00 2015
Dependencies:
gcc-5-base 5.1~rc1-0ubuntu1
libc6 2.21-0ubuntu4
libgcc1 1:5.1~rc1-0ubuntu1
multiarch-support 2.21-0ubuntu4
SourcePackage: libusb
UpgradeStatus: Upgraded to vivid on 2015-04-26 (21 days ago) |
|
| 2015-05-17 17:05:39 |
Alexander Ponyatykh |
branch linked |
|
lp:~lazyranma/ubuntu/wily/libusb/bug-1455924 |
|
| 2015-09-05 00:09:18 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2015-11-29 21:37:10 |
Mathew Hodson |
libusb (Ubuntu): importance |
Undecided |
Medium |
|
| 2015-11-29 21:40:01 |
Mathew Hodson |
bug |
|
|
added subscriber Mathew Hodson |
| 2015-11-29 21:45:39 |
Mathew Hodson |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785578 |
|
| 2015-11-29 21:45:39 |
Mathew Hodson |
bug task added |
|
libusb (Debian) |
|
| 2015-11-29 23:35:38 |
Bug Watch Updater |
libusb (Debian): status |
Unknown |
New |
|
| 2016-01-03 06:11:31 |
Mathew Hodson |
removed subscriber Mathew Hodson |
|
|
|
