s2ram slow (radeon) / failing (usb)
in [Kernel]
|
Prev: intel_txt: enable VMXON check with SMX in KVM
Next: SCSI: Support HW reset for EH and polling scheme for scsi device
From: Alan Stern on 2 May 2010 18:00 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 2 May 2010 18:10 On Sun, 2 May 2010, Rafael J. Wysocki wrote: > On Sunday 02 May 2010, Bruno Prémont wrote: > > On Sun, 02 May 2010 Alan Stern <stern(a)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. To me it suggests that a kernel thread is needed during system resume even though it is still frozen, rather like the problem with del_gendisk. Jiri, could the usbhid_resume thread cause a hang in this way? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bruno Prémont on 3 May 2010 02:40 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 3 May 2010 10:00 On Mon, 3 May 2010, Bruno [UTF-8] Prémont wrote: > 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. Yes, that's equivalent to the other things. > It looked like there was some more output during boot-up, but nothing > during suspend, at least up to the freezing point. Did you boot with "no_console_suspend"? Are you using a VT console instead of X (a serial console may or may not work as well)? You might also want to #define VERBOSE_DEBUG at the start of drivers/usb/core/driver.c, before the first #include. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bruno Prémont on 3 May 2010 10:50
On Mon, 3 May 2010 09:57:29 -0400 (EDT) Alan Stern wrote: > On Mon, 3 May 2010, Bruno [UTF-8] Prémont wrote: > > > 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. > > Yes, that's equivalent to the other things. > > > It looked like there was some more output during boot-up, but > > nothing during suspend, at least up to the freezing point. > > Did you boot with "no_console_suspend"? Are you using a VT console > instead of X (a serial console may or may not work as well)? Yes, I'm booting with no_console_suspend and console=ttyS0. On that system there is no X. Multiple ttys are showing up on display with KMS or VGA text mode (just the getty, all kernel and init output goes to serial console as expected) As noted in first e-mail, I disabled SERIAL_8250_PNP as that one blocks/prevents serial output much too early during suspend. > You might also want to #define VERBOSE_DEBUG at the start of > drivers/usb/core/driver.c, before the first #include. Will do. > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |