On Mar 19 bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=31432 > > > Rafael J. Wysocki <rjw@xxxxxxx> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rjw@xxxxxxx > Component|Hibernation/Suspend |IEEE1394 > Blocks| |7216 > AssignedTo|power-management_other@kern |drivers_ieee1394@kernel-bug > |el-bugs.osdl.org |s.osdl.org > Product|Power Management |Drivers Quoting the bug description for linux1394-devel: > Description From JaÅa 2011-03-19 12:34:00 > Created an attachment (id=51242) [details] > dmesg of 2.6.38 [https://bugzilla.kernel.org/attachment.cgi?id=51242] > > I have diagnosed a regression in several kernel versions (at least > 2.6.35.x and current stable version 2.6.38). > > After upgrading from 2.6.32 (Ubuntu 10.04) to 2.6.35 (Ubunutu 10.10) > resume from suspend failed so I came across the /sys/power/pm_trace > tracing method and with that info I narrowed the issue to a firewire > device which seems to be the issue. I also tried the recently released > 2.6.38 mainline version. > > A workaround which confirmed my suspicions is removing firewire modules: > # modprobe -r firewire_core firewire_ohci > Then resume works well. > > Here's the evidence: > > $ uname -a > Linux sendell 2.6.38-020638-generic #201103151303 SMP Tue Mar 15 > 13:08:09 UTC 2011 x86_64 GNU/Linux > > relevant part of dmesg: > [ 1.181998] PM: Hibernation image not present or could not be loaded. > [ 1.182017] registered taskstats version 1 > [ 1.182307] Magic number: 0:117:476 > [ 1.182310] hash matches /home/kernel-ppa/COD/linux/drivers/base/power/main.c:514 > [ 1.182370] pci 0000:03:05.0: hash matches > [ 1.182442] rtc_cmos 00:05: setting system clock to 2024-03-02 10:28:40 UTC (1709375320) > > $ lspci | grep 03:05 > 03:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) > > $ grep 03:05 dmesg-38.txt > [ 0.360052] pci 0000:03:05.0: [104c:8023] type 0 class 0x000c00 > [ 0.360067] pci 0000:03:05.0: reg 10: [mem 0xfdeff000-0xfdeff7ff] > [ 0.360076] pci 0000:03:05.0: reg 14: [mem 0xfdef8000-0xfdefbfff] > [ 0.360123] pci 0000:03:05.0: supports D1 D2 > [ 0.360125] pci 0000:03:05.0: PME# supported from D0 D1 D2 D3hot > [ 0.360130] pci 0000:03:05.0: PME# disabled > > I've posted this on Launchpad (Bug #732641) but no responses at all > there. Alas there are no messages from the firewire drivers in this log. Not even a message from PCI core that a firewire-ohci driver method failed. Hence we (linux1394-devel people) have nothing to go on yet. Can somebody who knows power management explain what should be investigated next? The downstream tracker item is: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732641 It contains a somewhat different failure description from a 2.6.35 Ubuntu kernel: > Since upgrade to 10.10/kernel 2.6.35 kernel doesn't complete resume from > suspend. > > $ uname -a > Linux sendell 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC > 2011 x86_64 GNU/Linux > > Xorg vty is blank, I can change to other vtys but when i return to the > one with Xorg, switching no longer works. Only manual reset remedies > this situation. > > Tried > https://wiki.ubuntu.com/DebuggingKernelSuspend#%22resume-trace%22%20debugging%20procedure%20for%20finding%20buggy%20drivers > > [ 0.714873] PM: Resume from disk failed. > [ 0.714886] registered taskstats version 1 > [ 0.715167] Magic number: 0:608:476 > [ 0.715170] hash matches /build/buildd/linux-2.6.35/drivers/base/power/main.c:545 > [ 0.715213] pci 0000:03:05.0: hash matches > [ 0.715281] rtc_cmos 00:05: setting system clock to 1980-09-08 10:27:51 UTC (337256871) > > $ lspci | grep 03:05 > 03:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) > > $ dmesg|grep fire > [ 0.380065] pci 0000:03:05.0: reg 10: [mem 0xfdeff000-0xfdeff7ff] > [ 0.380071] pci 0000:03:05.0: reg 14: [mem 0xfdef8000-0xfdefbfff] > [ 0.380105] pci 0000:03:05.0: supports D1 D2 > [ 0.380107] pci 0000:03:05.0: PME# supported from D0 D1 D2 D3hot > [ 0.380111] pci 0000:03:05.0: PME# disabled > [ 0.715213] pci 0000:03:05.0: hash matches > [ 0.893472] firewire_ohci 0000:03:05.0: PCI INT A -> Link[APC4] -> GSI 19 (level, low) -> IRQ 19 > [ 0.950061] firewire_ohci: Added fw-ohci device 0000:03:05.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > > $ lsmod|grep fire > firewire_ohci 24839 0 > firewire_core 54327 1 firewire_ohci > crc_itu_t 1739 1 firewire_core > > $sudo modprobe -r firewire_core firewire_ohci > > And then resuming from suspend works. > JaÅa, are all of the dmesg messages in this report from the same session? Linux-pm folks, why is the PM Restore failure reported at 0.714873 but the system proceeds and logs successful attachment of firewire-ohci's pci_probe to the PCI device? Also, why is base/power/main.c::device_resume mentioned in the PM trace but there is no hint in the log that firewire-ohci's pci_resume was called? Side note: While firewire-ohci's pci_probe succeeded, the controller might actually not have become operational. Usually the success message from firewire-ohci should be followed on circa 500 ms afterwards by a message like this: "firewire_core: created device fw0: GUID 00110600000041cc, S400" Can somebody comment on the phenomenon that VT switching was affected? ... Well, maybe firewire-core hung in a workqueue job which in turn prevented subsequent processing of other subsystems' workqueue jobs. This can be much more of a problem with a kernel like 2.6.35 than with newer ones with concurrency managed workqueues (2.6.36 and later). (JaÅa, prefer reply-to-all for responses. Thanks for your reports so far.) -- Stefan Richter -=====-==-== --== =--== http://arcgraph.de/sr/ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
