Re: T400 suspend/resume regression -- bisected to a mystery mergecommit

[Theodore Tso]

On Thu, Oct 01, 2009 at 06:21:50PM -0700, Linus Torvalds wrote:
> I think the revert is the right thing to do, especially as that 
> 'clocksource_mutex' looks totally bogus. Either the thing is protected by 
> 'stop_machine' or it's not. In neither case does it seem to make any sense 
> to replace a spinlock with a mutex. 
> 
> And resuming anything with a big mutex is crazy anyway. 
> 
> That said, I do wonder if this is already fixed. See commit 
> 89133f93508137231251543d1732da638e6022e1:
> 
>     clocksource: Resume clocksource without taking the clocksource mutex
> 
> which already undid the part that probably mattered for you. That said, I 
> still do think that that mutex is dubious, so maybe we should undo it all.

Hmm, I just tried the latest git release, and the problem does seem to
have disappeared.  I don't know if it was fixed by commit #89133f9,
but I'll take it.  :-)

(Note!  The problem I was bisecting is different and distinct from BZ
#14222.  First of all, for me 2.6.31 works fine, and in #14222 the
reporter claimed that 2.6.30 worked, and 2.6.31 didn't.  For me this
regression happened *after* the merge window opened.  Secondly, in
#14222 the failure reported was an OOPS, whereas in my case, the
system simply doesn't come back after the second suspend-to-memory.
The HD disk flashes once or twice, but then the machine stays dead,
with the screen not coming to life and the suspend light still lit.
Finally, I bisected the failure to a different commit (75c5158) which
is post 2.6.31, where as commit c7121843 which is pre-2.6.31.)

   		      	 		       - Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/