Comment # 5 on bug 934397 from Takashi Iwai

(In reply to Dario Savella from comment #3)
> I tried with kernel 4.0.5-1.gf4cd21b-desktop and the problem is still there.
> I do have a crash dump if it helps (I can only provide the files, not any
> skills to look at them).
> 
> The dmesg from the crash says:
> 
> [   73.957016] ata3: SATA link down (SStatus 0 SControl 300)
> [   73.961017] ata4: SATA link down (SStatus 0 SControl 300)
> [   73.961030] ata6: SATA link down (SStatus 0 SControl 300)
> [   74.114023] usb 5-1: reset low-speed USB device number 2 using uhci_hcd
> [   74.880484] ata7.00: configured for UDMA/33
> [   75.748492] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: Rx/Tx
> [   78.244018] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [   78.245701] ata1.00: configured for UDMA/133
> [   79.002184] ata5: link is slow to respond, please be patient (ready=0)
> [   79.012012] ata2: link is slow to respond, please be patient (ready=0)
> [   83.031024] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [   83.184936] ata5.00: configured for UDMA/133
> [   83.704007] ata2: COMRESET failed (errno=-16)
> [   85.539018] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [   85.663005] sr 6:0:0:0: **** DPM device timeout ****

So this looks like the cause.  The recent kernel has a watchdog for async
resume workers, and if it expires, it panics.  This explains why 3.12 worked;
the watchdog was introduced since 3.13.

The timeout length is unfortunately fixed in Kconfig, set to 12 as default. 
And this seems too short.  We should extend this to at least a minute, I
suppose.  Also, it'd be better to be dynamically configuratble.

The openSUSE-13.2 test kernel packages with the extended timeout to 60 seconds
is being built on OBS home:tiwai:bnc934397 repo.  Could you give it a try?  It
will take some time until the build finishes.