Just in case it might help someone else, here's a wrapup of the final status for my issues.
Intent : migrate from "Ubuntu Studio x64 10.10" to "Ubuntu Studio x64 12.10" (both installed, on distinct HDDs)
System specs : Tyan s2915 (non-E) motherboard, Tyan BIOS v3.00, MCP55 Pro chipset, dual Opteron 2212, NUMA + IOMMU + S3 S-state + C2/C3 C-states are enabled, cross-nodes RAM interleave + NVRAID are disabled, NVidia 9600GT PCIe, SiliconImage 3124 eSATA controller PCI-X, 4xSATA II Hitachi HDDs
From info I've gathered here and there while searching for a solution, there seems to be two main "families" of suspend to RAM issues on NVidia chipsets :
1- suspend procedure hangs because some devices refuse to suspend => machine wakes back up after ~30 seconds timeout
2- suspend procedure finishes normally but some device concurrently wakes machine up (this behavior sometimes only occurs randomly, depending upon specific hardware) => machine's back up immediately
I experienced both problems above.
Here's what I believe were their root causes, with the workarounds (numbering corresponds to that of issue above) :
1- kernel 3.5 differs from my previous kernel 2.6 by using by default, an async device-suspend scheme, which revealed an async-suspend-request management bug in NVidia's chipset driver (sata_nv), diag'ed in kernel bug #48951 opened by Joe Sapp (poster in this thread)
=> only workaround at the moment : use udev rule given in kernel bug #48951 thread, comment #20
2- kernel 3.5 also differs from my previous kernel 2.6 by granting by default, USB devices the right to wake machine up from suspend (/proc/acpi/wakeup)
Just in case it might help someone else, here's a wrapup of the final status for my issues.
Intent : migrate from "Ubuntu Studio x64 10.10" to "Ubuntu Studio x64 12.10" (both installed, on distinct HDDs)
System specs : Tyan s2915 (non-E) motherboard, Tyan BIOS v3.00, MCP55 Pro chipset, dual Opteron 2212, NUMA + IOMMU + S3 S-state + C2/C3 C-states are enabled, cross-nodes RAM interleave + NVRAID are disabled, NVidia 9600GT PCIe, SiliconImage 3124 eSATA controller PCI-X, 4xSATA II Hitachi HDDs
From info I've gathered here and there while searching for a solution, there seems to be two main "families" of suspend to RAM issues on NVidia chipsets :
1- suspend procedure hangs because some devices refuse to suspend => machine wakes back up after ~30 seconds timeout
2- suspend procedure finishes normally but some device concurrently wakes machine up (this behavior sometimes only occurs randomly, depending upon specific hardware) => machine's back up immediately
I experienced both problems above.
Here's what I believe were their root causes, with the workarounds (numbering corresponds to that of issue above) :
1- kernel 3.5 differs from my previous kernel 2.6 by using by default, an async device-suspend scheme, which revealed an async-suspend- request management bug in NVidia's chipset driver (sata_nv), diag'ed in kernel bug #48951 opened by Joe Sapp (poster in this thread)
=> only workaround at the moment : use udev rule given in kernel bug #48951 thread, comment #20
2- kernel 3.5 also differs from my previous kernel 2.6 by granting by default, USB devices the right to wake machine up from suspend (/proc/acpi/wakeup)
=> most frequently described workaround : unload driver of offending device before suspending (see for example : https:/ /wiki.archlinux .org/index. php/Pm- utils#Standby_ .2F_Suspend_ to_RAM)
=> a workaround that I find less "invasive" : disable wake-up "permission" for offending devices before suspending, by means of a pm-utils hook (see : http:// askubuntu. com/questions/ 152403/ how-do- i-make- changes- to-proc- acpi-wakeup- permanent)
Hope it can help.
Eric