Created attachment 23274 [details]
After suspend one of my secondary disks doesn't resume. It works ok under kernel 18.104.22.168 and previous. I have 4 disk connected to the same Nvidia sata controller: 3 identical maxtor (sda/b/c) and 1 Hitachi (sdd), and this last one doesn't wakes up.
In attachment the interesting lines from /var/log/messages and the output of hdparm -I.
Created attachment 23275 [details]
Output of hdparm -I sda/b/c
Created attachment 23276 [details]
Output of hdparm -I sdd
Can you attach a complete boot log from 2.6.32-rc3, please?
Created attachment 23282 [details]
Output of dmesg as requested
Created attachment 23283 [details]
More output and done with kernel 2.6.32-rc3
Will you please confirm whether the box can work well on 2.6.31 kernel?
If it can work, will you please use the git-bisect to identify the bad commit which causes the regression?
(In reply to comment #6)
> Will you please confirm whether the box can work well on 2.6.31 kernel?
> If it can work, will you please use the git-bisect to identify the bad commit
> which causes the regression?
Ok, i bisected till this:
7f4774b38ee6270bbc6c3015cb3fa6c415ffb340 is the first bad commit
Author: Tejun Heo <firstname.lastname@example.org>
Date: Wed Jun 10 16:29:07 2009 +0900
sata_nv: use hardreset only for post-boot probing
First-Bad-Commit : 7f4774b38ee6270bbc6c3015cb3fa6c415ffb340
Reset protocol implementations on these nv chips are complete jokes. Good that we aren't gonna see more of them in the future. :-(
One workaround I can think of is to fall back to hardreset if this is the last reset try for the attached device. As failure will lead to device disablement anyway, there isn't much to lose. The problem is that such workaround would still be visible on your case as extra delay during resume. Better than losing a disk over suspend/resume cycle, but still...
Can you please attach the output of "lspci -nn"?
Created attachment 23387 [details]
Output of lspci -nn
Created attachment 23388 [details]
Does this patch make any difference? Regardless of its success, can you please full dmesg output including both the boot and resume messages with this patch applied?
Created attachment 23389 [details]
dmesg with suspend/resume sequence
If you need more testing, i'm here.
Alright, thanks. Patch forwarded upstream. Resolving as CODE_FIX.
Fixed by commit 6489e3262e6b188a1a009b65e8a94b7aa17645b7 .