Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with recentkernels)

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

The following reply was made to PR kern/38683; it has been noted by GNATS.

From: "Steven M. Bellovin" <smb%cs.columbia.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: joerg%britannica.bec.de@localhost, joerg%NetBSD.org@localhost, 
gnats-admin%NetBSD.org@localhost,
 netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with
 recentkernels)
Date: Mon, 2 Jun 2008 14:57:10 -0400

 On Mon,  2 Jun 2008 18:50:02 +0000 (UTC)
 Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
 
 > The following reply was made to PR kern/38683; it has been noted by
 > GNATS.
 > 
 > From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with
 >      recentkernels)
 > Date: Mon, 2 Jun 2008 20:49:16 +0200
 > 
 >  On Mon, Jun 02, 2008 at 05:20:02PM +0000, Matthias Drochner wrote:
 >  > The following reply was made to PR kern/38683; it has been noted
 >  > by GNATS.
 >  > 
 >  > From: Matthias Drochner <M.Drochner%fz-juelich.de@localhost>
 >  > To: "Steven M. Bellovin" <smb%cs.columbia.edu@localhost>
 >  > Cc: gnats-bugs%NetBSD.org@localhost, joerg%NetBSD.org@localhost,
 >  >   kern-bug-people%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
 >  >   gnats-admin%NetBSD.org@localhost
 >  > Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with 
 >  >   recentkernels) 
 >  > Date: Mon, 02 Jun 2008 19:17:59 +0200
 >  > 
 >  >  smb%cs.columbia.edu@localhost said:
 >  >  > as of yesterday, I can't even suspend
 >  >  
 >  >  I'm seeing that too. For me, it helps to disable the other
 >  >  CPU core before suspend (cpuctl offline 1), so it is
 >  >  likely caused by increased concurrency in the kernel.
 >  >  Seems we need to pick up the "get user applications
 >  >  out of the way" topic again...
 >  
 >  Is that with sysctl or apm?
 >  
 I've been doing my tests single-user via
 
        sysctl -w machdep.sleep_state=3
 
 which used to work.  My powerd scripts have long turned off one CPU
 first, but Jared said that was no longer necessary.
 
 
                --Steve Bellovin, http://www.cs.columbia.edu/~smb