On Dec 05 Rafael J. Wysocki wrote:
quoted text
> 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?

quoted text
> 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/
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/