| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <AANLkTimdF_eYurw9k0rQRAzSQ-fZMKsFLupnME_ch1Ru@mail.gmail.com> Date: Wed, 18 Aug 2010 02:56:38 +0100 From: trapDoor <trapdoor6@...il.com> To: "Rafael J. Wysocki" <rjw@...k.pl> Cc: LKML <linux-kernel@...r.kernel.org>, arnd@...db.de, trapDoor <trapdoor6@...glemail.com>, Jiri Kosina <jkosina@...e.cz> Subject: Re: [REGRESSION, bisected] 2.6.36-rc1 - suspend issues On Wed, Aug 18, 2010 at 2:25 AM, Rafael J. Wysocki <rjw@...k.pl> wrote: > On Tuesday, August 17, 2010, trapDoor wrote: >> Hello, >> The merge window is closed so it's time to hunt for bugs. I've got >> one, please find details below. >> ----------------------- >> >> Working kernels: from 2.6.35 - to 2.6.35.2 >> Non working kernels: from (at least) 2.6.35-git2 - to 2.6.36-rc1 >> ----------------------- >> >> Description of the problem(s): >> >> 1. First of all I confirm that the problem is consistent: suspend >> works well every time on the 'good' kernels and it newer works (with >> the symptoms) on any of the 'bad' kernels. I've tested it several >> times on a couple of 'good' and 'bad' kernels to make sure it's not >> some random issue. >> >> 2. On a bad kernel, this is what happens when I try to switch to suspend mode: >> - screen goes blank ['No signal detected !'] - that's OK :) >> - either the CPU fan or PSU fan or both are still running and they >> won't stop (left it for about 30 min. once) >> - the power light is on and still, where in suspend mode it should >> blink - that won't change either >> - pressing the power button obviously doesn't wake the system up; need >> to hard reboot >> >> 3. Now, when booting again, after an unsuccessful suspend and hard >> reboot, something happens to my network card (and it doesn't matter >> what is the next kernel I boot from - it can be any 'good' or 'bad' >> one): >> - in Gnome, the gnome-panel network indicator shows my connection as >> disabled (wired eth0 - the only one I use); enabling it doesn't bring >> my network up >> >> 4. After re-booting from any of the 'good' or 'bad' kernels my network >> connection is working again. >> ----------------------- >> >> Bisecting turned up the following commit. Reverting it in 2.6.36-rc1 >> results in a system that works. >> >> commit bd25f4dd6972755579d0ea50d1a5ace2e9b00d1a >> Author: Arnd Bergmann <arnd@...db.de> >> Date: Sun Jul 11 15:34:05 2010 +0200 >> >> HID: hiddev: use usb_find_interface, get rid of BKL >> >> This removes the private hiddev_table in the usbhid >> driver and changes it to use usb_find_interface >> instead. >> >> The advantage is that we can avoid the race between >> usb_register_dev and usb_open and no longer need the >> big kernel lock. >> >> This doesn't introduce race condition -- the intf pointer could be >> invalidated only in hiddev_disconnect() through usb_deregister_dev(), >> but that will block on minor_rwsem and not actually remove the device >> until usb_open(). >> ----------------------- >> >> Despite mentioned issues with network (occurring every time after >> unsuccessful suspend > hard restart) the bisecting turned up a commit >> which isn't rather related to network. But I can confirm that >> reverting only this one commit in 2.6.36-rc1 >> [da5cabf80e2433131bf0ed8993abc0f7ea618c73] fixes the whole problem - >> suspend works OK and I have no issues with my network after waking the >> system up, neither after re-booting from the same or any other kernel. >> >> Please let me know what further details should I provide. Any logs, >> hardware specifications? I've also made a brief log recording the >> bisect if anyone would need it. > > Well, we should let the HID maintainer know about the problem (CC added). > > Thanks, > Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Thanks Rafael, Before I opened this thread I only searched on http://vger.kernel.org/vger-lists.html for any appropriate mailing list but nothing linke linux-*hid* there. Now I've found out that there is a list of all maintainers included in the kernel source. I'll keep that in mind .. -- Regards Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists