lkml.org 
[lkml]   [2010]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: s2ram slow (radeon) / failing (usb)
    On Sun, 02 May 2010 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
    > On Sunday 02 May 2010, Bruno Prémont wrote:
    > > On Sun, 02 May 2010 Alan Stern <stern@rowland.harvard.edu> wrote:
    > > > On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote:
    > > > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
    > > > > It freezes during device suspend (unless I rmmod everything USB
    > > > > related) - usb fails even in pm_test case 'devices'.
    > > > >
    > > > > When the system is able to suspend it takes an eternity (more than 3
    > > > > minutes to wake-up, the radeon apparently being responsible for quite
    > > > > a big share of that slowness.
    > > > >
    > > > >
    > > > > During resume early it looks like every PCI access needs about a second,
    > > > > and there are a few cases where during lots of seconds nothing seems to
    > > > > happen and the first event following is related to radeon.
    > > > >
    > > > > The kernel used is todays Linus's tree at commit be1066bbcd443a65df312fdecea7e4959adedb45
    > > > > with Dave's drm-linus and drm-radeon-testing applied on top.
    > > > >
    > > > > Note, I've not been able to suspend to RAM properly recently (last one
    > > > > that worked correctly but resumed without graphics was some-when during
    > > > > 2.6.2x, before KMS)
    > > > > Since then the system would either fail suspend or resume.
    > > > >
    > > > > Manual changes I applied in order to find out some context information:
    > > > > - add a few debugging printk's to ata/ahci as that was the last entry
    > > > > on serial console for freezing suspends (that one succeeded but
    > > > > following step never completed, from suspend_prepare that would have
    > > > > been USB => unload usb before suspend)
    > > > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial
    > > > > console would continue working as long as possible and output suspend
    > > > > progress (resume output happens only very late)
    > > > >
    > > > > Is there some additional information I could gather in order do help
    > > > > improving s2ram on this system?
    > > > > - get it to suspend with usb loaded (ohci + ehci)
    > > > > - get it to resume a reasonable speed
    > > >
    > > > There's no way to fix the USB problem without knowing what goes wrong.
    > > > Let's see how far you get before the system freezes on a kernel with
    > > > CONFIG_USB_DEBUG enabled.
    > >
    > > Am I missing something?
    > >
    > > I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter
    > > nor anything extra to toggle and I don't get more output than without it.
    > >
    > > Device suspend (pm_test = device) works well when there is no USB device
    > > connected, but with USB keyboard I get the freeze (though the keyboard
    > > is still usable, e.g. CAPS key works and I can issue SYSRQ commands).
    > >
    > > When I issue sysreq-t, I find the following suspicious entry:
    > > [ 669.112505] usbhid_resume D ffff88007a085fd8 0 1145 2 0x00000000
    > > [ 669.112505] ffff88007a085e20 0000000000000046 ffff88007a085fd8 ffff88007c536820
    > > [ 669.112505] ffff88007a085fd8 ffff88007a085fd8 00000000000129c0 00000000000129c0
    > > [ 669.112505] ffff88007c536820 ffff88007cf3f040 ffff88007a085fd8 ffff88007a085fd8
    > > [ 669.112505] Call Trace:
    > > [ 669.112505] [<ffffffff8105d765>] refrigerator+0x95/0xf0
    > > [ 669.112505] [<ffffffff81051a16>] worker_thread+0xc6/0x1e0
    > > [ 669.112505] [<ffffffff81055e90>] ? autoremove_wake_function+0x0/0x40
    > > [ 669.112505] [<ffffffff81051950>] ? worker_thread+0x0/0x1e0
    > > [ 669.112505] [<ffffffff810559be>] kthread+0x8e/0xa0
    > > [ 669.112505] [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
    > > [ 669.112505] [<ffffffff81055930>] ? kthread+0x0/0xa0
    > > [ 669.112505] [<ffffffff81003a90>] ? kernel_thread_helper+0x0/0x10
    > >
    > > Except for that one there are a few async/* tasks waiting.
    >
    > It looks like the freezer fails on your system.
    >
    > How much time did you wait for the failig "pm_test = device" to recover?

    I've given it at least 5 minutes, but didn't check exactly. Is there a
    (big) timeout that could happen, if so how long is it?

    Thanks,
    Bruno


    Those async threads looked like:
    [ 669.112505] async/15 D 0000000000000000 0 2213 2 0x00000000
    [ 669.112505] ffff8800797dbc80 0000000000000046 ffff8800797dbfd8 ffff88007aff8820
    [ 669.112505] ffff8800797dbfd8 ffff8800797dbfd8 00000000000129c0 00000000000129c0
    [ 669.112505] ffff88007aff8820 ffff88007cdf3040 0000000000000002 0000000000000113
    [ 669.112505] Call Trace:
    [ 669.112505] [<ffffffff8146838d>] schedule_timeout+0x19d/0x230
    [ 669.112505] [<ffffffff811f661c>] ? acpi_pci_irq_lookup+0x42/0x1b1
    [ 669.112505] [<ffffffff811f67ff>] ? acpi_pci_irq_disable+0x74/0x7d
    [ 669.112505] [<ffffffff81467961>] wait_for_common+0xe1/0x170
    [ 669.112505] [<ffffffff81037620>] ? default_wake_function+0x0/0x10
    [ 669.112505] [<ffffffff813092f0>] ? dpm_wait_fn+0x0/0x40
    [ 669.112505] [<ffffffff81467a88>] wait_for_completion+0x18/0x20
    [ 669.112505] [<ffffffff8130931f>] dpm_wait_fn+0x2f/0x40
    [ 669.112505] [<ffffffff81302188>] device_for_each_child+0x48/0x70
    [ 669.112505] [<ffffffff81309e68>] __device_suspend+0x38/0x1e0
    [ 669.112505] [<ffffffff8130a504>] async_suspend+0x24/0x60
    [ 669.112505] [<ffffffff8105c772>] async_thread+0x112/0x280
    [ 669.112505] [<ffffffff81037620>] ? default_wake_function+0x0/0x10
    [ 669.112505] [<ffffffff8105c660>] ? async_thread+0x0/0x280
    [ 669.112505] [<ffffffff810559be>] kthread+0x8e/0xa0
    [ 669.112505] [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
    [ 669.112505] [<ffffffff81055930>] ? kthread+0x0/0xa0
    [ 669.112505] [<ffffffff81003a90>] ? kernel_thread_helper+0x0/0x10

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

    \
     
     \ /
      Last update: 2010-05-02 22:59    [W:3.732 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site