[lkml]   [2010]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [REGRESSION, bisected] 2.6.36-rc1 - suspend issues
    Posted on Bugzilla as well, ref: 16615 -  [REGRESSION, bisected]
    2.6.36-rc1 - suspend doesn't work and network issues afterwards

    Tomasz B.

    On Tue, Aug 17, 2010 at 6:01 PM, 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
    > 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 <>
    > 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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-08-17 21:29    [W:0.025 / U:32.372 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site