[Desktop-packages] [Bug 1357556] Re: Does not stop/restart service when system sleeps
Upstream seems to be dead - last release was in 2007, and last commit was in 2011, but I've posted it anyway. https://sourceforge.net/p/g15tools/patches/5/ -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1357556 Title: Does not stop/restart service when system sleeps Status in g15daemon package in Ubuntu: Confirmed Status in libg15 package in Ubuntu: New Status in libusb package in Ubuntu: New Bug description: Release Info # lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 Package Info # dpkg -l | grep g15daemon ii g15daemon 1.9.5.3-8.2ubuntu3 amd64Screen multiplexer for Logitech G15 Keyboard Issue G15 Keyboard daemon loses connectivity to the g15daemon after the system resumes from sleeping Resolution: Adding a /etc/pm/sleep.d rule such as https://gist.github.com/rriemann/2947810 seems to fix the issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/g15daemon/+bug/1357556/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1357556] Re: Does not stop/restart service when system sleeps
I've created a PPA with a new version of g15daemon, libg15 and libusb that fixes this bug. Feel free to use it. https://launchpad.net/~lazyranma/+archive/ubuntu/g15daemon/ ** Branch linked: lp:~lazyranma/ubuntu/wily/libg15/bug-1357556 ** Branch linked: lp:~lazyranma/ubuntu/wily/libusb/bug-1455924 ** Branch linked: lp:~lazyranma/ubuntu/wily/g15daemon/g15daemon.dev -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1357556 Title: Does not stop/restart service when system sleeps Status in g15daemon package in Ubuntu: Confirmed Status in libg15 package in Ubuntu: New Status in libusb package in Ubuntu: New Bug description: Release Info # lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 Package Info # dpkg -l | grep g15daemon ii g15daemon 1.9.5.3-8.2ubuntu3 amd64Screen multiplexer for Logitech G15 Keyboard Issue G15 Keyboard daemon loses connectivity to the g15daemon after the system resumes from sleeping Resolution: Adding a /etc/pm/sleep.d rule such as https://gist.github.com/rriemann/2947810 seems to fix the issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/g15daemon/+bug/1357556/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1455924] [NEW] libusb occasionally hungs after suspend/resume
Public bug reported: 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) ** Affects: libusb (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug vivid ** Patch added: 12_hung_after_resume.diff https://bugs.launchpad.net/bugs/1455924/+attachment/4398983/+files/12_hung_after_resume.diff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1455924 Title: libusb occasionally hungs after suspend/resume Status in libusb package in Ubuntu: New Bug 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libusb/+bug/1455924/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1455924] Re: libusb occasionally hungs after suspend/resume
Please note that debug message about lost URB is not 100% accurate in multi-threaded code because of harmless race condition. ** Description changed: 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 + 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 + 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) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1455924 Title: libusb occasionally hungs after suspend/resume Status in libusb package in Ubuntu: New Bug 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libusb/+bug/1455924/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1357556] Re: Does not stop/restart service when system sleeps
There are actually 3 different issues in g15daemon, libg15 and libusb (LP: #1455924) preventing correct recovery after suspend. Patch for libusb is available, and I'll post patches for libg15 and g15daemon soon. ** Also affects: libg15 (Ubuntu) Importance: Undecided Status: New ** Also affects: libusb (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1357556 Title: Does not stop/restart service when system sleeps Status in g15daemon package in Ubuntu: Confirmed Status in libg15 package in Ubuntu: New Status in libusb package in Ubuntu: New Bug description: Release Info # lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 Package Info # dpkg -l | grep g15daemon ii g15daemon 1.9.5.3-8.2ubuntu3 amd64Screen multiplexer for Logitech G15 Keyboard Issue G15 Keyboard daemon loses connectivity to the g15daemon after the system resumes from sleeping Resolution: Adding a /etc/pm/sleep.d rule such as https://gist.github.com/rriemann/2947810 seems to fix the issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/g15daemon/+bug/1357556/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1455924] Re: libusb occasionally hangs after suspend/resume
** Summary changed: - libusb occasionally hungs after suspend/resume + libusb occasionally hangs after suspend/resume ** Description changed: - 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: + 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 hung forever since + 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) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1455924 Title: libusb occasionally hangs after suspend/resume Status in libusb package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libusb/+bug/1455924/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1455924] Re: libusb occasionally hangs after suspend/resume
** Branch linked: lp:~lazyranma/ubuntu/wily/libusb/bug-1455924 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libusb in Ubuntu. https://bugs.launchpad.net/bugs/1455924 Title: libusb occasionally hangs after suspend/resume Status in libusb package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libusb/+bug/1455924/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 998715] [NEW] Unable to install libgck-1-0:i386 on amd64
Public bug reported: libgcr-3-1:i386 depends on libgcr-3-common:i386, but this package doesn't exists, because libgcr-3-common is architecture independent. === $ LANG= sudo apt-get install libgcr-3-1:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgcr-3-1:i386 : Depends: libgcr-3-common:i386 but it is not installable E: Unable to correct problems, you have held broken packages. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libgcr-3-1:i386 (not installed) ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14 Uname: Linux 3.2.0-24-generic x86_64 NonfreeKernelModules: fglrx ApportVersion: 2.0.1-0ubuntu7 Architecture: amd64 Date: Sun May 13 14:05:01 2012 ProcEnviron: TERM=xterm SHELL=/bin/bash PATH=(custom, user) LANG=ru_RU.utf8 LANGUAGE=ru_RU:ru:en_GB:en SourcePackage: gnome-keyring UpgradeStatus: Upgraded to precise on 2012-05-04 (9 days ago) ** Affects: gnome-keyring (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug precise -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/998715 Title: Unable to install libgck-1-0:i386 on amd64 Status in “gnome-keyring” package in Ubuntu: New Bug description: libgcr-3-1:i386 depends on libgcr-3-common:i386, but this package doesn't exists, because libgcr-3-common is architecture independent. === $ LANG= sudo apt-get install libgcr-3-1:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgcr-3-1:i386 : Depends: libgcr-3-common:i386 but it is not installable E: Unable to correct problems, you have held broken packages. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libgcr-3-1:i386 (not installed) ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14 Uname: Linux 3.2.0-24-generic x86_64 NonfreeKernelModules: fglrx ApportVersion: 2.0.1-0ubuntu7 Architecture: amd64 Date: Sun May 13 14:05:01 2012 ProcEnviron: TERM=xterm SHELL=/bin/bash PATH=(custom, user) LANG=ru_RU.utf8 LANGUAGE=ru_RU:ru:en_GB:en SourcePackage: gnome-keyring UpgradeStatus: Upgraded to precise on 2012-05-04 (9 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/998715/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
