Resume from suspend fails on new FireWire stack (TSB43AB22/A IEEE-1394a-2000 Controller)
A message that is not in the archive (sent off-list or not yet received): [email protected]/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · On Mar 19 [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=31432
Rafael J. Wysocki <[email protected]> changed:
Quoted 8 lines
What |Removed |Added
----------------------------------------------------------------------------CC| |[email protected] 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:
Quoted 3 lines
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]
Quoted 39 lines
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_tracetracing 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/Linuxrelevant 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
Quoted 2 lines
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:
Quoted 34 lines
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/LinuxXorg 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.
[ 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
Quoted 9 lines
$ lsmod|grep fire firewire_ohci 24839 0 firewire_core 54327 1 firewire_ohci crc_itu_t 1739 1 firewire_core$sudo modprobe -r
firewire_corefirewire_ohciAnd 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.)
Signature · 7 lines
Stefan Richter -=====-==-== --== =--== http://arcgraph.de/sr/ _______________________________________________ linux-pm mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/linux-pm
A message that is not in the archive (sent off-list or not yet received): 20110319145248.3a5cf71f@stein
Quoted 3 lines
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.
This is because I can't get the message buffer from the hung kernel. The log is from a forcefully rebooted kernel which logs the trace information which is stored in the RTC between reboots (supposedly this is the only non-volatile register available). You can see that overwriting the RTC results in date in the 2020's. More here:
https://wiki.ubuntu.com/DebuggingKernelSuspend#%22resume-trace%22%20debugging%20procedure%20for%20finding%20buggy%20drivers
Quoted 6 lines
The downstream tracker item is:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/732641It contains a somewhat different failure description from a 2.6.35 Ubuntu kernel:
...
Quoted 2 lines
Jaša, are all of the dmesg messages in this report from the same session?
dmesg messages on Launchpad are from 2.6.35 as it is the shipped kernel in Ubuntu 10.10. In the comment on Launchpad you can also see dmesg from 2.6.38-rc8 that was latest mainline at the time. On this kernel bugzilla I posted the dmesg of the just released 2.6.38 stable kernel because I think this version is most relevant at this time (right?).
Quoted 3 lines
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_probeto the PCI device?
I think you can find an explanation for this in my first paragraph of this email.
Quoted 5 lines
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).
The VT switching is only possible on 2.6.35 for me. That is why I only mentioned it on Launchpad. With .38 my display receives no signal after attempting a resume.
Quoted 1 line
(Jaša, prefer reply-to-all for responses. Thanks for your reports so far.)
* Stefan, sorry for duplicate, replying to rest of your CC * Thanks for your patience, this is my first bug report here. :)
_______________________________________________
linux-pm mailing list [email protected]
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
A message that is not in the archive (sent off-list or not yet received): [email protected]
Is the failure in resume from suspend(-to-RAM), or in restore from hibernate (alias resume from suspend-to-disk), or both?
Signature · 3 lines
Stefan Richter -=====-==-== --== =-=-= http://arcgraph.de/sr/