On Dec 05 Rafael J. Wysocki wrote: > There is a regression I can reproduce 100% of the time on a AMD-based desktop > box that resume from hibernation (or suspend) fails because of the firewire_ohci > module. The box just hangs when firewire_ohci resume runs, apparently, and it > is sufficient to do: > > # echo devices > /sys/power/pm_test > # echo disk > /sys/power/state > > to reproduce the issue. Do you have anything attached to the FireWire bus? What controller do you have? > It definitely works with 2.6.34, but it fails with 2.6.37-rc4+ (latest mainline). > I haven't tested the kernels in between, but I'm going to do that later today > or some time next week. > > If you have any idea about what may be the reason, please let me know. As first quick thought: While we of course need to have a look at firewire-ohci changes, it could also be a higher-level issue in firewire-core. E.g. something with the 2.6.36 workqueue related core kernel changes. (I am only saying so because I noticed some module unloading issues with the firewire stack lately that seem workqueue related.) I admit that PM suspend/resume or hibernate/restore are not part of my personal firewire driver testing regime. I need to address that. I Cc'd Maxim Levitsky who has working firewire suspend/resume on 2.6.37-rc, although with some minor firewire-net related and isochronous I/O related nits for which he sent fixes lately: http://marc.info/?l=linux1394-devel&m=129099665721794 http://marc.info/?l=linux1394-devel&m=129099666021798 But I do not think that these could matter to your hang-at-resume issue. -- Stefan Richter -=====-==-=- ==-- --=-= http://arcgraph.de/sr/ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm