Messages in this thread | | | Date | Tue, 17 Aug 2010 20:27:22 +0100 | Subject | Re: [REGRESSION, bisected] 2.6.36-rc1 - suspend issues | From | trapDoor <> |
| |
Posted on Bugzilla as well, ref: 16615 - [REGRESSION, bisected] 2.6.36-rc1 - suspend doesn't work and network issues afterwards
-- Thanks Tomasz B.
On Tue, Aug 17, 2010 at 6:01 PM, trapDoor <trapdoor6@gmail.com> 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@arndb.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. > > -- > Regards > Tomasz B. aka trapDoor >
-- Regards trapDoor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |