s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010 17:59:17 -0400 (EDT) Alan Stern wrote: > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > > > 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. > > Depends what you mean by "output". The kernel generates more log > messages, but they may not get sent to your console. You need to > make sure the console's log level is set high enough to see debugging > messages. For example: > > echo 9 >/proc/sys/kernel/printk > > or type Alt-SysRq-9. I've been doing `dmesg -n 8` (9 is rejected as invalid) so it should send out everything. It looked like there was some more output during boot-up, but nothing during suspend, at least up to the freezing point. Bruno
Re: s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010 17:59:17 -0400 (EDT) Alan Stern wrote: On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: 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. Depends what you mean by output. The kernel generates more log messages, but they may not get sent to your console. You need to make sure the console's log level is set high enough to see debugging messages. For example: echo 9 /proc/sys/kernel/printk or type Alt-SysRq-9. I've been doing `dmesg -n 8` (9 is rejected as invalid) so it should send out everything. It looked like there was some more output during boot-up, but nothing during suspend, at least up to the freezing point. Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 "Rafael J. Wysocki" wrote: > On Sunday 02 May 2010, Bruno Pr?mont wrote: > > On Sun, 02 May 2010 Alan Stern 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 88007a085fd8 0 1145 2 > > 0x > > [ 669.112505] 88007a085e20 0046 88007a085fd8 > > 88007c536820 > > [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 > > 000129c0 > > [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 > > 88007a085fd8 > > [ 669.112505] Call Trace: > > [ 669.112505] [] refrigerator+0x95/0xf0 > > [ 669.112505] [] worker_thread+0xc6/0x1e0 > > [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 > > [ 669.112505] [] ? worker_thread+0x0/0x1e0 > > [ 669.112505] [] kthread+0x8e/0xa0 > > [ 669.112505] [] kernel_thread_helper+0x4/0x10 > > [ 669.112505] [] ? kthread+0x0/0xa0 > > [ 669.112505] [] ? 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 0 2213 2 0x [ 669.112505] 8800797dbc80 0046 8800797dbfd8 88007aff8820 [ 669.112505] 8800797dbfd8 8800797dbfd8 000129c0 000129c0 [ 669.112505] 88007aff8820 88007cdf3040 0002 0113 [ 669.112505] Call Trace: [ 669.112505] [] schedule_timeout+0x19d/0x230 [ 669.112505] [] ? acpi_pci_irq_lookup+0x42/0x1b1 [ 669.112505] [] ? acpi_pci_irq_disable+0x74/0x7d [ 669.112505] [] wait_for_common+0xe1/0x170 [ 669.112505] [] ? default_wake_function+0x0/0x10 [ 669.112505] [] ? dpm_wait_fn+0x0/0x40 [ 669.112505] [] wait_for_completion+0x18/0x20 [ 669.112505] [] dpm_wait_fn+0x2f/0x40 [ 669.112505] [] device_for_each_child+0x48/0x70 [ 669.112505] [] __device_suspend+0x38/0x1e0 [ 669.112505] [] async_suspend+0x24/0x60 [ 669.112505] [] async_thread+0x112/0x280 [ 669.112505] [] ? default_wake_function+0x0/0x10 [ 669.112505] [] ?
s2ram slow (radeon) / failing (usb)
On Sunday 02 May 2010, Bruno Pr?mont wrote: > On Sun, 02 May 2010 Alan Stern 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 88007a085fd8 0 1145 2 0x > [ 669.112505] 88007a085e20 0046 88007a085fd8 > 88007c536820 > [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 > 000129c0 > [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 > 88007a085fd8 > [ 669.112505] Call Trace: > [ 669.112505] [] refrigerator+0x95/0xf0 > [ 669.112505] [] worker_thread+0xc6/0x1e0 > [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 > [ 669.112505] [] ? worker_thread+0x0/0x1e0 > [ 669.112505] [] kthread+0x8e/0xa0 > [ 669.112505] [] kernel_thread_helper+0x4/0x10 > [ 669.112505] [] ? kthread+0x0/0xa0 > [ 669.112505] [] ? 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? Rafael
s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Alan Stern 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 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [] refrigerator+0x95/0xf0 [ 669.112505] [] worker_thread+0xc6/0x1e0 [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [] ? worker_thread+0x0/0x1e0 [ 669.112505] [] kthread+0x8e/0xa0 [ 669.112505] [] kernel_thread_helper+0x4/0x10 [ 669.112505] [] ? kthread+0x0/0xa0 [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. Thanks, Bruno
s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010, Bruno [UTF-8] Pr??mont wrote: > > 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. Depends what you mean by "output". The kernel generates more log messages, but they may not get sent to your console. You need to make sure the console's log level is set high enough to see debugging messages. For example: echo 9 >/proc/sys/kernel/printk or type Alt-SysRq-9. Alan Stern
s2ram slow (radeon) / failing (usb)
Hi, 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 Thanks, Bruno List of modules when suspend works (slowly): Module Size Used by snd_atiixp 14095 0 snd_ac97_codec118013 1 snd_atiixp ac97_bus1274 1 snd_ac97_codec snd_pcm71003 2 snd_atiixp,snd_ac97_codec snd_timer 19369 1 snd_pcm snd51992 4 snd_atiixp,snd_ac97_codec,snd_pcm,snd_timer soundcore974 1 snd snd_page_alloc 7797 2 snd_atiixp,snd_pcm sg 18667 0 pata_atiixp 4189 0 tg3 125844 0 lspci: 00:00.0 Host bridge [0600]: ATI Technologies Inc RS690 Host Bridge [1002:7910] 00:01.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) [1002:7912] 00:04.0 PCI bridge [0604]: ATI Technologies Inc Device [1002:7914] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1) [1002:7915] 00:06.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2) [1002:7916] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI2) [1002:4389] 00:13.3 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI3) [1002:438a] 00:13.4 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] 00:13.5 USB Controller [0c03]: ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386] 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 13) 00:14.1 IDE interface [0101]: ATI Technologies Inc SB600 IDE [1002:438c] 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d] 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] 00:14.5 Multimedia audio controller [0401]: ATI Technologies Inc SB600 AC97 Audio [1002:4382] 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690 [Radeon X1200 Series] [1002:791e] 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express [14e4:1693] (rev 02) 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express [14e4:1693] (rev 02) PM related config options: CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_PM_RUNTIME=y CONFIG_X86_PM_TIMER=y USB related config options: CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_PWC=m CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_SND_USB=y CONFIG_USB_HID=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y
s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010, Bruno [UTF-8] Pr??mont wrote: > Hi, > > 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. Alan Stern
Re: s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Alan Stern st...@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 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [8105d765] refrigerator+0x95/0xf0 [ 669.112505] [81051a16] worker_thread+0xc6/0x1e0 [ 669.112505] [81055e90] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [81051950] ? worker_thread+0x0/0x1e0 [ 669.112505] [810559be] kthread+0x8e/0xa0 [ 669.112505] [81003a94] kernel_thread_helper+0x4/0x10 [ 669.112505] [81055930] ? kthread+0x0/0xa0 [ 669.112505] [81003a90] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. Thanks, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Rafael J. Wysocki r...@sisk.pl wrote: On Sunday 02 May 2010, Bruno Prémont wrote: On Sun, 02 May 2010 Alan Stern st...@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 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [8105d765] refrigerator+0x95/0xf0 [ 669.112505] [81051a16] worker_thread+0xc6/0x1e0 [ 669.112505] [81055e90] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [81051950] ? worker_thread+0x0/0x1e0 [ 669.112505] [810559be] kthread+0x8e/0xa0 [ 669.112505] [81003a94] kernel_thread_helper+0x4/0x10 [ 669.112505] [81055930] ? kthread+0x0/0xa0 [ 669.112505] [81003a90] ? 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 0 2213 2 0x [ 669.112505] 8800797dbc80 0046 8800797dbfd8 88007aff8820 [ 669.112505] 8800797dbfd8 8800797dbfd8 000129c0 000129c0 [ 669.112505] 88007aff8820 88007cdf3040 0002 0113 [ 669.112505] Call Trace: [ 669.112505] [8146838d] schedule_timeout+0x19d/0x230 [ 669.112505] [811f661c] ? acpi_pci_irq_lookup+0x42/0x1b1 [ 669.112505] [811f67ff] ? acpi_pci_irq_disable+0x74/0x7d [ 669.112505] [81467961] wait_for_common+0xe1/0x170 [ 669.112505] [81037620] ? default_wake_function+0x0/0x10 [ 669.112505] [813092f0] ? dpm_wait_fn+0x0/0x40 [ 669.112505] [81467a88] wait_for_completion+0x18/0x20 [ 669.112505] [8130931f] dpm_wait_fn+0x2f/0x40 [ 669.112505] [81302188] device_for_each_child+0x48/0x70 [ 669.112505] [81309e68] __device_suspend+0x38/0x1e0 [ 669.112505] [8130a504] async_suspend+0x24/0x60 [ 669.112505]
Re: s2ram slow (radeon) / failing (usb)
On Sunday 02 May 2010, Bruno Prémont wrote: On Sun, 02 May 2010 Alan Stern st...@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 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [8105d765] refrigerator+0x95/0xf0 [ 669.112505] [81051a16] worker_thread+0xc6/0x1e0 [ 669.112505] [81055e90] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [81051950] ? worker_thread+0x0/0x1e0 [ 669.112505] [810559be] kthread+0x8e/0xa0 [ 669.112505] [81003a94] kernel_thread_helper+0x4/0x10 [ 669.112505] [81055930] ? kthread+0x0/0xa0 [ 669.112505] [81003a90] ? 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? Rafael ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: 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. Depends what you mean by output. The kernel generates more log messages, but they may not get sent to your console. You need to make sure the console's log level is set high enough to see debugging messages. For example: echo 9 /proc/sys/kernel/printk or type Alt-SysRq-9. Alan Stern ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
