2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]

[Mattia Dongili <malattia@linux.it>]

On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> 
> > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > 
> > > > Hello,
> > > > 
> > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > I'm now experiencing an immediate resume after suspending.
> > > > 
> > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > 
> > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > and a str cycle with PM_DEBUG=y:
> > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > ...
> > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > time...)
> > > 
> > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> > 
> > ok, git-acpi.patch is not the bad boy :)
> > Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
> > suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
> > can.
> > I'm now bisecting this, will come to -mm1 later when done with this one.
> 
> OK, thanks.
> 
> > Who is the regression-guy?
> 
> Len, usually ;)    But I think you meant Michal, cc'ed here.

LOL, not this time. We have the responsible commit for 2.6.22-rc1 (Cc
added):

3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5 is first bad commit
commit 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5
Author: Alex Dubov <oakad@yahoo.com>
Date:   Thu Apr 12 16:59:15 2007 +1000

    tifm: replace per-adapter kthread with freezeable workqueue
    
    Freezeable workqueue makes sure that adapter work items (device insertions
    and removals) would be handled after the system is fully resumed. Previously
    this was achieved by explicit freezing of the kthread.
    
    Signed-off-by: Alex Dubov <oakad@yahoo.com>
    Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

I'm now seeing if avoiding the tifm stuff in -mm1 fixes the
immediately-resumes-after-str problem (unfortunately the commint doesn't
revert cleanly).
-- 
mattia
:wq!