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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ