2.6.25-rc7: Ugh. - Kernel

This is a discussion on 2.6.25-rc7: Ugh. - Kernel ; On Fri, 28 Mar 2008 12:22:32 -0700, David Brownell wrote: > On Friday 28 March 2008, Tilman Schmidt wrote: >> FWIW, it's still confusing to have an option "Enhanced Real Time >> Clock Support" under "Character Devices", then later an ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 84

Thread: 2.6.25-rc7: Ugh.

  1. Re: Kconfig RTC selection

    On Fri, 28 Mar 2008 12:22:32 -0700, David Brownell wrote:
    > On Friday 28 March 2008, Tilman Schmidt wrote:
    >> FWIW, it's still confusing to have an option "Enhanced Real Time
    >> Clock Support" under "Character Devices", then later an option
    >> "Real Time Clock" one level higher, none of the two in any way
    >> acknowledging the existence of the other one, and only after
    >> naively selecting both, you are told that there is some sort of
    >> conflict.

    >
    > You mean "still, after applying that patch I sent"?


    No, I was referring to the situation still existing in current mainline.
    My comment was intended to be in support of your patches. Sorry for not
    having made myself clear.

    Regards,
    Tilman


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4-svn0 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFH7jw0Q3+did9BuFsRAgTgAKCU983VTGPndgbH7E0Xmr vn1sO9dgCfWKGe
    x5m6KO2Mey+JgSuNCwxhi+o=
    =E/FI
    -----END PGP SIGNATURE-----


  2. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Pavel Machek wrote:
    >> Hi!
    >>
    >>>> It is with great reluctance when I attempt moving my main "desktop"
    >>>> over to a new kernel version -- because the USB subsystem seems to
    >>>> break every single time.
    >>>>
    >>>> So today I tried 2.6.25-rc7 on it for the first time.
    >>>> Not good.
    >>>>
    >>>> It boots, but just a simple suspend/resume (RAM) was enough to kill it.
    >>>> It comes back on resume, with an X desktop again,
    >>>> but with no USB functionality -- no mouse.
    >>>>
    >>>> The keyboard still works, so I dropped to a console and tried:
    >>>>
    >>>> rmmod usbhid
    >>>> insmod usbhid
    >>>>
    >>>> And the console hung at 100% CPU on the insmod.
    >>>> Back to 2.6.24.3 again, for now -- I've got work to do.
    >>>>
    >>>> The specs of this machine have been posted with great regularity
    >>>> in the past, every new kernel revision it seems. So here we go again:
    >>>>
    >>>> Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
    >>> ..
    >>>
    >>> Correction there: 3GB of RAM, not 2.

    >>
    >> 3GB of RAM can be a problem. Try iommu=soft. .. but in such case
    >> rmmod/insmod of usbhid would not help...

    > ..
    >
    > Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.

    ...

    And booting with iommu=soft is worse: video comes back with bizarre timings
    after suspend/resume -- totally unsynced display afterwards.

    Cheers
    --
    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/

  3. Re: 2.6.25-rc7: Ugh.

    Pavel Machek wrote:
    > Hi!
    >
    >>> It is with great reluctance when I attempt moving my main "desktop"
    >>> over to a new kernel version -- because the USB subsystem seems to
    >>> break every single time.
    >>>
    >>> So today I tried 2.6.25-rc7 on it for the first time.
    >>> Not good.
    >>>
    >>> It boots, but just a simple suspend/resume (RAM) was enough to kill it.
    >>> It comes back on resume, with an X desktop again,
    >>> but with no USB functionality -- no mouse.
    >>>
    >>> The keyboard still works, so I dropped to a console and tried:
    >>>
    >>> rmmod usbhid
    >>> insmod usbhid
    >>>
    >>> And the console hung at 100% CPU on the insmod.
    >>> Back to 2.6.24.3 again, for now -- I've got work to do.
    >>>
    >>> The specs of this machine have been posted with great regularity
    >>> in the past, every new kernel revision it seems. So here we go again:
    >>>
    >>> Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.

    >> ..
    >>
    >> Correction there: 3GB of RAM, not 2.

    >
    > 3GB of RAM can be a problem. Try iommu=soft. .. but in such case
    > rmmod/insmod of usbhid would not help...

    ...

    Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.

    -ml
    --
    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/

  4. Re: 2.6.25-rc7: Ugh.

    Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
    > >> Correction there: *3GB of RAM, not 2.

    > >
    > > 3GB of RAM can be a problem. Try iommu=soft. .. but in such case
    > > rmmod/insmod of usbhid would not help...

    > ..
    >
    > Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.


    Are you running with CONFIG_USB_SUSPEND? If so, please try without it.

    Regards
    Oliver
    --
    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/

  5. Re: 2.6.25-rc7: Ugh.

    Oliver Neukum wrote:
    > Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
    >>>> Correction there: 3GB of RAM, not 2.
    >>> 3GB of RAM can be a problem. Try iommu=soft. .. but in such case
    >>> rmmod/insmod of usbhid would not help...

    >> ..
    >>
    >> Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.

    >
    > Are you running with CONFIG_USB_SUSPEND? If so, please try without it.

    ...

    Funny. One of the first posts in this thread told me to make sure
    that I do use CONFIG_USB_SUSPEND (which I have been for many kernels now).

    One thing I just tried, was to unload all USB stuff before suspend,
    and reload on resume -- just stuck the commands into my suspend/resume script.

    The machine has been 100% rock solid since then.
    So I think that definitely implicates USB.

    Still want USB_SUSPEND=n ? Please explain.

    Thanks
    --
    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/

  6. Re: 2.6.25-rc7: Ugh.

    Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
    > Oliver Neukum wrote:
    > > Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
    > >>>> Correction there: 3GB of RAM, not 2.
    > >>> 3GB of RAM can be a problem. Try iommu=soft. .. but in such case
    > >>> rmmod/insmod of usbhid would not help...
    > >> ..
    > >>
    > >> Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.

    > >
    > > Are you running with CONFIG_USB_SUSPEND? If so, please try without it.

    > ..
    >
    > Funny. One of the first posts in this thread told me to make sure
    > that I do use CONFIG_USB_SUSPEND (which I have been for many kernels now).
    >
    > One thing I just tried, was to unload all USB stuff before suspend,
    > and reload on resume -- just stuck the commands into my suspend/resume script.
    >
    > The machine has been 100% rock solid since then.
    > So I think that definitely implicates USB.


    Yes. What happens if you unload only usbhid at that time?

    > Still want USB_SUSPEND=n ? Please explain.


    It looks like you are hanging in the kthread for autosuspending. Compiling
    that out should confirm it.

    Regards
    Oliver


    --
    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/

  7. Re: 2.6.25-rc7: Ugh.

    Oliver Neukum wrote:
    > Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
    >
    >> One thing I just tried, was to unload all USB stuff before suspend,
    >> and reload on resume -- just stuck the commands into my suspend/resume script.
    >>
    >> The machine has been 100% rock solid since then.
    >> So I think that definitely implicates USB.

    >
    > Yes. What happens if you unload only usbhid at that time?

    ...

    Mmm.. interesting choice, there. I'll try that.

    There is another quirk on this machine that might confuse
    software that's not robust: the internal Bluetooth adapter
    is USB connected, and I normally have it disabled (BIOS hotkey).
    So it normally is "not present".

    But on any power-on / resume, it briefly powers up and becomes "present",
    and, after a second or two, the BIOS powers it down again, "not present".

    Just long enough for software to notice it and try talking to it.
    If that software is not carefully coded, it might get confused.

    This has not been a problem before, but perhaps with the new USB autosuspend code?

    >> Still want USB_SUSPEND=n ? Please explain.

    >
    > It looks like you are hanging in the kthread for autosuspending.
    > Compiling that out should confirm it.

    ...

    Okay, and once we see that it works fine: then what?
    --
    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/

  8. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Oliver Neukum wrote:
    >> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
    >>
    >>> One thing I just tried, was to unload all USB stuff before suspend,
    >>> and reload on resume -- just stuck the commands into my
    >>> suspend/resume script.
    >>>
    >>> The machine has been 100% rock solid since then.
    >>> So I think that definitely implicates USB.

    >>
    >> Yes. What happens if you unload only usbhid at that time?

    > ..
    >
    > Mmm.. interesting choice, there. I'll try that.
    >
    > There is another quirk on this machine that might confuse
    > software that's not robust: the internal Bluetooth adapter
    > is USB connected, and I normally have it disabled (BIOS hotkey).
    > So it normally is "not present".
    >
    > But on any power-on / resume, it briefly powers up and becomes "present",
    > and, after a second or two, the BIOS powers it down again, "not present".
    >
    > Just long enough for software to notice it and try talking to it.
    > If that software is not carefully coded, it might get confused.
    >
    > This has not been a problem before, but perhaps with the new USB
    > autosuspend code?

    ...

    Speaking of which.. what's with this "broken" message?
    I wonder if it could be at all related ?

    kobject: 'hci_usb' (f89d2948): kobject_cleanup
    kobject: 'hci_usb' (f89d2948): does not have a release() function, it is broken and must be fixed.
    kobject: 'hci_usb' (f89d2948): auto cleanup 'remove' event
    kobject: 'hci_usb' (f89d2948): kobject_uevent_env
    kobject: 'hci_usb' (f89d2948): fill_kobj_path: path = '/module/hci_usb'
    kobject: 'hci_usb' (f89d2948): auto cleanup kobject_del
    kobject: 'hci_usb': free name

    --
    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/

  9. Re: 2.6.25-rc7: Ugh.

    Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
    > Oliver Neukum wrote:
    > > Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
    > >
    > >> One thing I just tried, was to unload all USB stuff before suspend,
    > >> and reload on resume -- just stuck the commands into my suspend/resume script.
    > >>
    > >> The machine has been 100% rock solid since then.
    > >> So I think that definitely implicates USB.

    > >
    > > Yes. What happens if you unload only usbhid at that time?

    > ..
    >
    > Mmm.. interesting choice, there. I'll try that.
    >
    > There is another quirk on this machine that might confuse
    > software that's not robust: the internal Bluetooth adapter
    > is USB connected, and I normally have it disabled (BIOS hotkey).
    > So it normally is "not present".
    >
    > But on any power-on / resume, it briefly powers up and becomes "present",
    > and, after a second or two, the BIOS powers it down again, "not present".
    >
    > Just long enough for software to notice it and try talking to it.
    > If that software is not carefully coded, it might get confused.
    >
    > This has not been a problem before, but perhaps with the new USB autosuspend code?


    hci_usb doesn't have any autosuspend code.

    > >> Still want USB_SUSPEND=n ? Please explain.

    > >
    > > It looks like you are hanging in the kthread for autosuspending.
    > > Compiling that out should confirm it.

    > ..
    >
    > Okay, and once we see that it works fine: then what?


    We'll combine that information with the result of only removing usbhid
    and arrive at a pretty good idea where in the kernel the hang occurs.
    There are only two functions that touch autosuspend in the usbhid code.
    So if it works with usbhid unloaded, either of them should be to blame.

    Regards
    Oliver


    --
    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/

  10. Re: 2.6.25-rc7: Ugh.

    Oliver Neukum wrote:
    > Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
    >> Oliver Neukum wrote:
    >>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
    >>>
    >>>> One thing I just tried, was to unload all USB stuff before suspend,
    >>>> and reload on resume -- just stuck the commands into my suspend/resume script.
    >>>>
    >>>> The machine has been 100% rock solid since then.
    >>>> So I think that definitely implicates USB.
    >>> Yes. What happens if you unload only usbhid at that time?

    >> ..
    >>
    >> Mmm.. interesting choice, there. I'll try that.
    >>
    >> There is another quirk on this machine that might confuse
    >> software that's not robust: the internal Bluetooth adapter
    >> is USB connected, and I normally have it disabled (BIOS hotkey).
    >> So it normally is "not present".
    >>
    >> But on any power-on / resume, it briefly powers up and becomes "present",
    >> and, after a second or two, the BIOS powers it down again, "not present".
    >>
    >> Just long enough for software to notice it and try talking to it.
    >> If that software is not carefully coded, it might get confused.
    >>
    >> This has not been a problem before, but perhaps with the new USB autosuspend code?

    >
    > hci_usb doesn't have any autosuspend code.
    >
    >>>> Still want USB_SUSPEND=n ? Please explain.
    >>> It looks like you are hanging in the kthread for autosuspending.
    >>> Compiling that out should confirm it.

    >> ..
    >>
    >> Okay, and once we see that it works fine: then what?

    >
    > We'll combine that information with the result of only removing usbhid
    > and arrive at a pretty good idea where in the kernel the hang occurs.
    > There are only two functions that touch autosuspend in the usbhid code.
    > So if it works with usbhid unloaded, either of them should be to blame.

    ...

    Thanks!

    It does still hang with *usbhid* unloaded,
    but not if all USB stuff is unloaded.
    I'm still working my way through the rest of the suggestions here,
    and USB_DEBUG=n is next.

    I have figured out a way to make this much more reproducible now:
    When suspended, the notebook does not supply +5V over USB.
    But with a voltmeter, I discovered that there is sufficient capacitance
    on the USB +5V, that it takes many minutes for the voltage to decay
    from 5.1V down to near 0V.

    Resuming while the voltage is still relatively high, generally works.
    Resuming after the voltage drops to near zero, always fails (with USB modules loaded).

    So I've put a 2Kohm resistor across the USB +5V lines,
    forcing it to decay to zero within about 5 seconds.
    This helps a lot for debugging here.

    It probably also provides a vital clue as to what is wrong.
    Resume seems to generally work when the USB devices maintain
    some amount of standby power, and always fails when they don't.

    --
    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/

  11. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Oliver Neukum wrote:
    >> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
    >>> Oliver Neukum wrote:
    >>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
    >>>>
    >>>>> One thing I just tried, was to unload all USB stuff before suspend,
    >>>>> and reload on resume -- just stuck the commands into my
    >>>>> suspend/resume script.
    >>>>>
    >>>>> The machine has been 100% rock solid since then.
    >>>>> So I think that definitely implicates USB.
    >>>> Yes. What happens if you unload only usbhid at that time?
    >>> ..
    >>>
    >>> Mmm.. interesting choice, there. I'll try that.
    >>>
    >>> There is another quirk on this machine that might confuse
    >>> software that's not robust: the internal Bluetooth adapter
    >>> is USB connected, and I normally have it disabled (BIOS hotkey).
    >>> So it normally is "not present".
    >>>
    >>> But on any power-on / resume, it briefly powers up and becomes
    >>> "present",
    >>> and, after a second or two, the BIOS powers it down again, "not
    >>> present".
    >>>
    >>> Just long enough for software to notice it and try talking to it.
    >>> If that software is not carefully coded, it might get confused.
    >>>
    >>> This has not been a problem before, but perhaps with the new USB
    >>> autosuspend code?

    >>
    >> hci_usb doesn't have any autosuspend code.
    >>
    >>>>> Still want USB_SUSPEND=n ? Please explain.
    >>>> It looks like you are hanging in the kthread for autosuspending.
    >>>> Compiling that out should confirm it.
    >>> ..
    >>>
    >>> Okay, and once we see that it works fine: then what?

    >>
    >> We'll combine that information with the result of only removing usbhid
    >> and arrive at a pretty good idea where in the kernel the hang occurs.
    >> There are only two functions that touch autosuspend in the usbhid code.
    >> So if it works with usbhid unloaded, either of them should be to blame.

    > ..
    >
    > Thanks!
    >
    > It does still hang with *usbhid* unloaded,
    > but not if all USB stuff is unloaded.
    > I'm still working my way through the rest of the suggestions here,
    > and USB_DEBUG=n is next.

    ...

    Correction.. USB_SUSPEND=n is next.

    > I have figured out a way to make this much more reproducible now:
    > When suspended, the notebook does not supply +5V over USB.
    > But with a voltmeter, I discovered that there is sufficient capacitance
    > on the USB +5V, that it takes many minutes for the voltage to decay
    > from 5.1V down to near 0V.
    >
    > Resuming while the voltage is still relatively high, generally works.
    > Resuming after the voltage drops to near zero, always fails (with USB
    > modules loaded).
    >
    > So I've put a 2Kohm resistor across the USB +5V lines,
    > forcing it to decay to zero within about 5 seconds.
    > This helps a lot for debugging here.
    >
    > It probably also provides a vital clue as to what is wrong.
    > Resume seems to generally work when the USB devices maintain
    > some amount of standby power, and always fails when they don't.
    >
    > --
    > 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/


    --
    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/

  12. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Oliver Neukum wrote:
    >> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
    >>> Oliver Neukum wrote:
    >>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:

    ...
    >>>>> Still want USB_SUSPEND=n ? Please explain.
    >>>> It looks like you are hanging in the kthread for autosuspending.
    >>>> Compiling that out should confirm it.
    >>> ..
    >>>
    >>> Okay, and once we see that it works fine: then what?

    >>
    >> We'll combine that information with the result of only removing usbhid
    >> and arrive at a pretty good idea where in the kernel the hang occurs.
    >> There are only two functions that touch autosuspend in the usbhid code.
    >> So if it works with usbhid unloaded, either of them should be to blame.

    > ..
    > It does still hang with *usbhid* unloaded,
    > but not if all USB stuff is unloaded.

    ...

    And it does *not* hang with # CONFIG_USB_SUSPEND is not set.

    > I have figured out a way to make this much more reproducible now:
    > When suspended, the notebook does not supply +5V over USB.
    > But with a voltmeter, I discovered that there is sufficient capacitance
    > on the USB +5V, that it takes many minutes for the voltage to decay
    > from 5.1V down to near 0V.
    >
    > Resuming while the voltage is still relatively high, generally works.
    > Resuming after the voltage drops to near zero, always fails (with USB
    > modules loaded).
    >
    > So I've put a 2Kohm resistor across the USB +5V lines,
    > forcing it to decay to zero within about 5 seconds.
    > This helps a lot for debugging here.
    >
    > It probably also provides a vital clue as to what is wrong.
    > Resume seems to generally work when the USB devices maintain
    > some amount of standby power, and always fails when they don't.

    --
    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/

  13. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Mark Lord wrote:
    >> Oliver Neukum wrote:
    >>> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
    >>>> Oliver Neukum wrote:
    >>>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:

    > ..
    >>>>>> Still want USB_SUSPEND=n ? Please explain.
    >>>>> It looks like you are hanging in the kthread for autosuspending.
    >>>>> Compiling that out should confirm it.
    >>>> ..
    >>>>
    >>>> Okay, and once we see that it works fine: then what?
    >>>
    >>> We'll combine that information with the result of only removing usbhid
    >>> and arrive at a pretty good idea where in the kernel the hang occurs.
    >>> There are only two functions that touch autosuspend in the usbhid code.
    >>> So if it works with usbhid unloaded, either of them should be to blame.

    >> ..
    >> It does still hang with *usbhid* unloaded,
    >> but not if all USB stuff is unloaded.

    > ..
    >
    > And it does *not* hang with # CONFIG_USB_SUSPEND is not set.
    >
    >> I have figured out a way to make this much more reproducible now:
    >> When suspended, the notebook does not supply +5V over USB.
    >> But with a voltmeter, I discovered that there is sufficient capacitance
    >> on the USB +5V, that it takes many minutes for the voltage to decay
    >> from 5.1V down to near 0V.
    >>
    >> Resuming while the voltage is still relatively high, generally works.
    >> Resuming after the voltage drops to near zero, always fails (with USB
    >> modules loaded).
    >>
    >> So I've put a 2Kohm resistor across the USB +5V lines,
    >> forcing it to decay to zero within about 5 seconds.
    >> This helps a lot for debugging here.
    >>
    >> It probably also provides a vital clue as to what is wrong.
    >> Resume seems to generally work when the USB devices maintain
    >> some amount of standby power, and always fails when they don't.

    ...

    Note that it makes no difference whether I unplug all external USB devices
    prior to suspend or not. The failure patterns remain the same.
    --
    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/

  14. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Mark Lord wrote:
    >> Mark Lord wrote:
    >>> Oliver Neukum wrote:
    >>>> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
    >>>>> Oliver Neukum wrote:
    >>>>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:

    >> ..
    >>>>>>> Still want USB_SUSPEND=n ? Please explain.
    >>>>>> It looks like you are hanging in the kthread for autosuspending.
    >>>>>> Compiling that out should confirm it.
    >>>>> ..
    >>>>>
    >>>>> Okay, and once we see that it works fine: then what?
    >>>>
    >>>> We'll combine that information with the result of only removing usbhid
    >>>> and arrive at a pretty good idea where in the kernel the hang occurs.
    >>>> There are only two functions that touch autosuspend in the usbhid code.
    >>>> So if it works with usbhid unloaded, either of them should be to blame.
    >>> ..
    >>> It does still hang with *usbhid* unloaded,
    >>> but not if all USB stuff is unloaded.

    >> ..
    >>
    >> And it does *not* hang with # CONFIG_USB_SUSPEND is not set.
    >>
    >>> I have figured out a way to make this much more reproducible now:
    >>> When suspended, the notebook does not supply +5V over USB.
    >>> But with a voltmeter, I discovered that there is sufficient capacitance
    >>> on the USB +5V, that it takes many minutes for the voltage to decay
    >>> from 5.1V down to near 0V.
    >>>
    >>> Resuming while the voltage is still relatively high, generally works.
    >>> Resuming after the voltage drops to near zero, always fails (with USB
    >>> modules loaded).
    >>>
    >>> So I've put a 2Kohm resistor across the USB +5V lines,
    >>> forcing it to decay to zero within about 5 seconds.
    >>> This helps a lot for debugging here.
    >>>
    >>> It probably also provides a vital clue as to what is wrong.
    >>> Resume seems to generally work when the USB devices maintain
    >>> some amount of standby power, and always fails when they don't.

    > ..
    >
    > Note that it makes no difference whether I unplug all external USB devices
    > prior to suspend or not. The failure patterns remain the same.

    ...

    I've now removed the internal USB-Bluetooth adaptor, so we can now test
    without any USB devices connected.

    Suspend without any USB devices plugged-in, and it *always* resumes fine
    with working USB, even when the USB stuff is plugged in before hitting
    the resume button.

    But suspend *with* any USB device plugged-in, and it *always* fails resume,
    even when the USB device is unplugged before hitting the resume button.

    Conclusion: the bug is in the usb SUSPEND code, not the RESUME code.
    --
    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/

  15. Re: 2.6.25-rc7: Ugh.

    Am Montag, 31. März 2008 19:30:46 schrieb Mark Lord:
    > I've now removed the internal USB-Bluetooth adaptor, so we can now test
    > without any USB devices connected.
    >
    > Suspend without any USB devices plugged-in, and it *always* resumes fine
    > with working USB, even when the USB stuff is plugged in before hitting
    > the resume button.


    To the USB subsystem these devices are plugged in as soon as power is
    returned.

    > But suspend *with* any USB device plugged-in, and it *always* fails resume,
    > even when the USB device is unplugged before hitting the resume button.
    >
    > Conclusion: * the bug is in the usb SUSPEND code, not the RESUME code.


    I would arrive at the opposite conclusion. Independent from that, loss of
    power is not really supported by USB during STR. Obviously it should not
    hang, but all devices will be disconnected and reconnected.

    But if power is cut with newer kernels and older kernels retain it, something
    must have changed. Can you undo the ACPI changes since the last working
    kernel?

    Regards
    Oliver

    --
    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/

  16. Re: 2.6.25-rc7: Ugh.

    Oliver Neukum wrote:
    >
    > But if power is cut with newer kernels and older kernels retain it, something
    > must have changed. Can you undo the ACPI changes since the last working
    > kernel?

    ...

    No, that's no different.
    This notebook always cuts +5V from USB on suspend or poweroff.
    Regardless of kernel version. I don't know how common this is,
    but all of my notebooks here have always behaved this way,
    as have most (but not all) of the larger systems.

    The two most recent PCIe motherboards I have here
    do provide +5V standby power to USB, even when "OFF",
    much to my annoyance and to the detriment of this planet.

    Cheers
    --
    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/

  17. Re: 2.6.25-rc7: Ugh.

    Hi!

    > > But suspend *with* any USB device plugged-in, and it *always* fails resume,
    > > even when the USB device is unplugged before hitting the resume button.
    > >
    > > Conclusion: * the bug is in the usb SUSPEND code, not the RESUME code.

    >
    > I would arrive at the opposite conclusion. Independent from that, loss of
    > power is not really supported by USB during STR. Obviously it should not
    > hang, but all devices will be disconnected and reconnected.


    All devices disconnected / reconnected is expected, but it has to
    work. Machines like thinkpad x60 kill USB power during s2ram.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    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/

  18. Re: 2.6.25-rc7: Ugh.

    Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
    > Oliver Neukum wrote:
    > >
    > > But if power is cut with newer kernels and older kernels retain it, something
    > > must have changed. Can you undo the ACPI changes since the last working
    > > kernel?

    > ..
    >
    > No, that's no different.
    > This notebook always cuts +5V from USB on suspend or poweroff.
    > Regardless of kernel version. I don't know how common this is,
    > but all of my notebooks here have always behaved this way,
    > as have most (but not all) of the larger systems.
    >
    > The two most recent PCIe motherboards I have here
    > do provide +5V standby power to USB, even when "OFF",
    > much to my annoyance and to the detriment of this planet.


    Very well.

    Mark, can you get a sysrq-t trace of your whole system when USB goes
    dead? And please enable CONFIG_USB_DEBUG. We need to do whether
    khubd and ksuspend_usbd are in state D.

    Regards
    Oliver
    --
    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/

  19. Re: 2.6.25-rc7: Ugh.

    (CCing linux-usb again)
    (CCing Alan Stern on this sub-thread)

    Oliver Neukum wrote:
    > Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
    >> Oliver Neukum wrote:
    >>> But if power is cut with newer kernels and older kernels retain it, something
    >>> must have changed. Can you undo the ACPI changes since the last working
    >>> kernel?

    >> ..
    >>
    >> No, that's no different.
    >> This notebook always cuts +5V from USB on suspend or poweroff.
    >> Regardless of kernel version. I don't know how common this is,
    >> but all of my notebooks here have always behaved this way,
    >> as have most (but not all) of the larger systems.
    >>
    >> The two most recent PCIe motherboards I have here
    >> do provide +5V standby power to USB, even when "OFF",
    >> much to my annoyance and to the detriment of this planet.

    >
    > Very well.
    >
    > Mark, can you get a sysrq-t trace of your whole system when USB goes
    > dead? And please enable CONFIG_USB_DEBUG. We need to do whether
    > khubd and ksuspend_usbd are in state D.

    ...

    Both of those things were already done, and results from the last time
    are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345

    I'll be installing -rc8 today, and see what happens there.

    Cheers

    --
    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/

  20. Re: 2.6.25-rc7: Ugh.

    (CCing Alan Stern on this sub-thread)

    Oliver Neukum wrote:
    > Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
    >> Oliver Neukum wrote:
    >>> But if power is cut with newer kernels and older kernels retain it, something
    >>> must have changed. Can you undo the ACPI changes since the last working
    >>> kernel?

    >> ..
    >>
    >> No, that's no different.
    >> This notebook always cuts +5V from USB on suspend or poweroff.
    >> Regardless of kernel version. I don't know how common this is,
    >> but all of my notebooks here have always behaved this way,
    >> as have most (but not all) of the larger systems.
    >>
    >> The two most recent PCIe motherboards I have here
    >> do provide +5V standby power to USB, even when "OFF",
    >> much to my annoyance and to the detriment of this planet.

    >
    > Very well.
    >
    > Mark, can you get a sysrq-t trace of your whole system when USB goes
    > dead? And please enable CONFIG_USB_DEBUG. We need to do whether
    > khubd and ksuspend_usbd are in state D.

    ...

    Both of those things were already done, and results from the last time
    are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345

    I'll be installing -rc8 today, and see what happens there.

    Cheers
    --
    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/

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast