NetBSD Problem Report #38683

From smb@cs.columbia.edu  Sun May 18 02:52:06 2008
Return-Path: <smb@cs.columbia.edu>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 19ADB63B8BC
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 18 May 2008 02:52:06 +0000 (UTC)
Message-Id: <20080518023441.E058D282E14@yellowstone.machshav.com>
Date: Sat, 17 May 2008 22:34:41 -0400 (EDT)
From: smb@cs.columbia.edu
Reply-To: smb@cs.columbia.edu
To: gnats-bugs@gnats.NetBSD.org
Subject: T61 cannot suspend with recent kernels
X-Send-Pr-Version: 3.95

>Number:         38683
>Category:       kern
>Synopsis:       Thinkpad T61/amd64 cannot suspend with recent kernels
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    jmcneill
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 18 02:55:00 +0000 2008
>Closed-Date:    Mon Mar 02 20:48:48 +0000 2009
>Last-Modified:  Mon Mar 02 20:48:48 +0000 2009
>Originator:     Steven M. Bellovin
>Release:        NetBSD 4.99.63
>Organization:
Department of Computer Science, Columbia University
>Environment:


System: NetBSD yellowstone.machshav.com 4.99.63 NetBSD 4.99.63 (YELLOWSTONE) #0: Fri May 16 23:56:11 EDT 2008 smb@yellowstone.machshav.com:/usr/BUILD/obj/sys/arch/amd64/compile/YELLOWSTONE amd64
Architecture: x86_64
Machine: amd64
>Description:
	My Thinkpad T61 (running amd64) cannot suspend/resume with recent
	-current kernels.  It suspends; at resume time, it prints
	ioapic0 renabling -- and nothing more happens.  The crescent 'suspend'
	light stays on.  I also have some evidence that the system will
	overheat if I leave it in this state for too long; for fairly obvious
	reasons, I'm not inclined to experiment further on that point...

	I've tried disabling [eou]hci and azalia via 'boot -c'; that didn't
	help.  If I diable ioapic, it does resume; however, the keyboard
	is dead, so it's not a very useful workaround.

	I don't know just when this started.  I'm running a kernel from
	March 7; it works.  However, I can't upgrade, since every kernel I've
	built in the last few weeks exhibits this problem.

	I've tried a kernel that works for Jared; it does not work for me.
	As far as I know, the primary difference between his machine and
	mine is that I have a fingerprint reader and Bluetooth; those, however,
	show up as USB devices, so disabling [eou]hci should have prevented
	any problems from them.
>How-To-Repeat:
	Boot to single-user and do 'sysctl -w machdep.sleep_state=3'.
	Alternatively, try any other way to suspend, such as shutting
	the lid or hitting Fn+F4.
>Fix:
	Unknown

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->joerg
Responsible-Changed-By: joerg@NetBSD.org
Responsible-Changed-When: Mon, 02 Jun 2008 14:16:07 +0000
Responsible-Changed-Why:
Given that it hangs after lapic reset but before resuming
the devices, it is likely that one of the lapic related changes
in this time frame is the culprit. Can you try to do a
binary search between to somewhat reduce the time frame when
the regression was introduced? Due to the license cleanup
and some other cosmetic changes the diff is quite large.


State-Changed-From-To: open->feedback
State-Changed-By: joerg@NetBSD.org
State-Changed-When: Mon, 02 Jun 2008 14:16:07 +0000
State-Changed-Why:


From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: joerg@NetBSD.org, kern-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org,
 gnats-admin@NetBSD.org
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with recent
 kernels)
Date: Mon, 2 Jun 2008 11:36:35 -0400

 On Mon,  2 Jun 2008 14:16:09 +0000 (UTC)
 joerg@NetBSD.org wrote:

 > Synopsis: Thinkpad T61/amd64 cannot suspend with recent kernels
 > 
 > Responsible-Changed-From-To: kern-bug-people->joerg
 > Responsible-Changed-By: joerg@NetBSD.org
 > Responsible-Changed-When: Mon, 02 Jun 2008 14:16:07 +0000
 > Responsible-Changed-Why:
 > Given that it hangs after lapic reset but before resuming
 > the devices, it is likely that one of the lapic related changes
 > in this time frame is the culprit. Can you try to do a
 > binary search between to somewhat reduce the time frame when
 > the regression was introduced? Due to the license cleanup
 > and some other cosmetic changes the diff is quite large.
 > 
 That's what I'm going to try.  Is there any archive of snapshot
 kernels, or do I need to pull in lots of source trees?  (Btw -- as of
 yesterday, I can't even suspend.  For that matter, I can't even boot
 -current kernels unless I disable ugen, the fingerprint reader.  I
 wonder if that's related.)


 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org,
	kern-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org,
	gnats-admin@NetBSD.org
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with 
	recentkernels) 
Date: Mon, 02 Jun 2008 19:17:59 +0200

 smb@cs.columbia.edu 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...

 best regards
 Matthias




 -------------------------------------------------------------------
 -------------------------------------------------------------------
 Forschungszentrum Juelich GmbH
 52425 Juelich

 Sitz der Gesellschaft: Juelich
 Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
 Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
 Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
 Dr. Sebastian M. Schmidt
 -------------------------------------------------------------------
 -------------------------------------------------------------------

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
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>
 > To: "Steven M. Bellovin" <smb@cs.columbia.edu>
 > Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org,
 > 	kern-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org,
 > 	gnats-admin@NetBSD.org
 > Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with 
 > 	recentkernels) 
 > Date: Mon, 02 Jun 2008 19:17:59 +0200
 > 
 >  smb@cs.columbia.edu 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?

 Joerg

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: joerg@britannica.bec.de, joerg@NetBSD.org, gnats-admin@NetBSD.org,
 netbsd-bugs@NetBSD.org
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> wrote:

 > The following reply was made to PR kern/38683; it has been noted by
 > GNATS.
 > 
 > From: Joerg Sonnenberger <joerg@britannica.bec.de>
 > To: gnats-bugs@NetBSD.org
 > 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>
 >  > To: "Steven M. Bellovin" <smb@cs.columbia.edu>
 >  > Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org,
 >  > 	kern-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org,
 >  > 	gnats-admin@NetBSD.org
 >  > Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with 
 >  > 	recentkernels) 
 >  > Date: Mon, 02 Jun 2008 19:17:59 +0200
 >  > 
 >  >  smb@cs.columbia.edu 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

From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: gnats-bugs@NetBSD.org
Cc: joerg@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
	smb@cs.columbia.edu
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend 
	withrecentkernels) 
Date: Mon, 02 Jun 2008 21:23:57 +0200

 [hang on suspend]
 joerg@britannica.bec.de said:
 >  Is that with sysctl or apm? 

 sysctl

 best regards
 Matthias




 -------------------------------------------------------------------
 -------------------------------------------------------------------
 Forschungszentrum Juelich GmbH
 52425 Juelich

 Sitz der Gesellschaft: Juelich
 Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
 Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
 Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
 Dr. Sebastian M. Schmidt
 -------------------------------------------------------------------
 -------------------------------------------------------------------

From: "Jared D. McNeill" <jmcneill@invisible.ca>
To: gnats-bugs@NetBSD.org
Cc: joerg@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
 smb@cs.columbia.edu
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with recentkernels)
Date: Mon, 02 Jun 2008 19:26:10 -0400

 Steven M. Bellovin wrote:
 >  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.

 I thought that was the case but it appears my powerd scripts still do it.

 Jared

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: joerg@NetBSD.org, kern-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org,
 gnats-admin@NetBSD.org
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with recent
 kernels)
Date: Fri, 6 Jun 2008 16:33:08 -0400

 A 12 April kernel works; a 13 April kernel fails.  Here's the list of
 files in sys updated by cvs for that change.

 ----
 P sys/arch/acorn32/mainbus/lpt_pioc.c
 P sys/arch/acorn32/stand/boot32/boot32.c
 P sys/arch/dreamcast/dev/g2/if_mbe_g2.c
 P sys/arch/x86/x86/bus_space.c
 P sys/dev/ic/fmv.c
 P sys/dev/ic/iha.c
 P sys/dev/ic/ihavar.h
 P sys/dev/ic/mb86960.c
 P sys/dev/ic/mb86960var.h
 P sys/dev/isa/if_ate.c
 P sys/dev/isa/if_fmv_isa.c
 P sys/dev/isapnp/if_fmv_isapnp.c
 P sys/dev/mca/if_ate_mca.c
 P sys/dev/pci/iha_pci.c
 P sys/dev/pci/trm.c
 P sys/dev/pcmcia/if_mbe_pcmcia.c
 P sys/dist/acpica/acapps.h
 P sys/dist/acpica/acconfig.h
 P sys/dist/acpica/acdebug.h
 P sys/dist/acpica/acdisasm.h
 P sys/dist/acpica/acdispat.h
 P sys/dist/acpica/acefi.h
 P sys/dist/acpica/acenv.h
 P sys/dist/acpica/acevents.h
 P sys/dist/acpica/acexcep.h
 P sys/dist/acpica/acgcc.h
 P sys/dist/acpica/acglobal.h
 P sys/dist/acpica/achware.h
 P sys/dist/acpica/acinterp.h
 P sys/dist/acpica/aclocal.h
 P sys/dist/acpica/acmacros.h
 P sys/dist/acpica/acnames.h
 P sys/dist/acpica/acnamesp.h
 P sys/dist/acpica/acnetbsd.h
 P sys/dist/acpica/acobject.h
 P sys/dist/acpica/acopcode.h
 P sys/dist/acpica/acoutput.h
 P sys/dist/acpica/acparser.h
 P sys/dist/acpica/acpi.h
 P sys/dist/acpica/acpiosxf.h
 P sys/dist/acpica/acpixf.h
 P sys/dist/acpica/acresrc.h
 P sys/dist/acpica/acstruct.h
 P sys/dist/acpica/actables.h
 P sys/dist/acpica/actbl.h
 P sys/dist/acpica/actbl1.h
 P sys/dist/acpica/actbl2.h
 P sys/dist/acpica/actypes.h
 P sys/dist/acpica/acutils.h
 P sys/dist/acpica/amlcode.h
 P sys/dist/acpica/amlresrc.h
 P sys/dist/acpica/dbcmds.c
 P sys/dist/acpica/dbdisply.c
 P sys/dist/acpica/dbexec.c
 P sys/dist/acpica/dbfileio.c
 P sys/dist/acpica/dbhistry.c
 P sys/dist/acpica/dbinput.c
 P sys/dist/acpica/dbstats.c
 P sys/dist/acpica/dbutils.c
 P sys/dist/acpica/dbxface.c
 P sys/dist/acpica/dmbuffer.c
 P sys/dist/acpica/dmnames.c
 P sys/dist/acpica/dmobject.c
 P sys/dist/acpica/dmopcode.c
 P sys/dist/acpica/dmresrc.c
 P sys/dist/acpica/dmresrcl.c
 P sys/dist/acpica/dmresrcs.c
 P sys/dist/acpica/dmutils.c
 P sys/dist/acpica/dmwalk.c
 P sys/dist/acpica/dsfield.c
 P sys/dist/acpica/dsinit.c
 P sys/dist/acpica/dsmethod.c
 P sys/dist/acpica/dsmthdat.c
 P sys/dist/acpica/dsobject.c
 P sys/dist/acpica/dsopcode.c
 P sys/dist/acpica/dsutils.c
 P sys/dist/acpica/dswexec.c
 P sys/dist/acpica/dswload.c
 P sys/dist/acpica/dswscope.c
 P sys/dist/acpica/dswstate.c
 P sys/dist/acpica/evevent.c
 P sys/dist/acpica/evgpe.c
 P sys/dist/acpica/evgpeblk.c
 P sys/dist/acpica/evmisc.c
 P sys/dist/acpica/evregion.c
 P sys/dist/acpica/evrgnini.c
 P sys/dist/acpica/evsci.c
 P sys/dist/acpica/evxface.c
 P sys/dist/acpica/evxfevnt.c
 P sys/dist/acpica/evxfregn.c
 P sys/dist/acpica/exconfig.c
 P sys/dist/acpica/exconvrt.c
 P sys/dist/acpica/excreate.c
 P sys/dist/acpica/exdump.c
 P sys/dist/acpica/exfield.c
 P sys/dist/acpica/exfldio.c
 P sys/dist/acpica/exmisc.c
 P sys/dist/acpica/exmutex.c
 P sys/dist/acpica/exnames.c
 P sys/dist/acpica/exoparg1.c
 P sys/dist/acpica/exoparg2.c
 P sys/dist/acpica/exoparg3.c
 P sys/dist/acpica/exoparg6.c
 P sys/dist/acpica/exprep.c
 P sys/dist/acpica/exregion.c
 P sys/dist/acpica/exresnte.c
 P sys/dist/acpica/exresolv.c
 P sys/dist/acpica/exresop.c
 P sys/dist/acpica/exstore.c
 P sys/dist/acpica/exstoren.c
 P sys/dist/acpica/exstorob.c
 P sys/dist/acpica/exsystem.c
 P sys/dist/acpica/exutils.c
 P sys/dist/acpica/hwacpi.c
 P sys/dist/acpica/hwgpe.c
 P sys/dist/acpica/hwregs.c
 P sys/dist/acpica/hwsleep.c
 P sys/dist/acpica/hwtimer.c
 P sys/dist/acpica/nsaccess.c
 P sys/dist/acpica/nsalloc.c
 P sys/dist/acpica/nsdump.c
 P sys/dist/acpica/nsdumpdv.c
 P sys/dist/acpica/nseval.c
 P sys/dist/acpica/nsinit.c
 P sys/dist/acpica/nsload.c
 P sys/dist/acpica/nsnames.c
 P sys/dist/acpica/nsobject.c
 P sys/dist/acpica/nsparse.c
 P sys/dist/acpica/nssearch.c
 P sys/dist/acpica/nsutils.c
 P sys/dist/acpica/nswalk.c
 P sys/dist/acpica/nsxfeval.c
 P sys/dist/acpica/nsxfname.c
 P sys/dist/acpica/nsxfobj.c
 P sys/dist/acpica/psargs.c
 P sys/dist/acpica/psloop.c
 P sys/dist/acpica/psopcode.c
 P sys/dist/acpica/psparse.c
 P sys/dist/acpica/psscope.c
 P sys/dist/acpica/pstree.c
 P sys/dist/acpica/psutils.c
 P sys/dist/acpica/pswalk.c
 P sys/dist/acpica/psxface.c
 P sys/dist/acpica/rsaddr.c
 P sys/dist/acpica/rscalc.c
 P sys/dist/acpica/rscreate.c
 P sys/dist/acpica/rsdump.c
 P sys/dist/acpica/rsinfo.c
 P sys/dist/acpica/rsio.c
 P sys/dist/acpica/rsirq.c
 P sys/dist/acpica/rslist.c
 P sys/dist/acpica/rsmemory.c
 P sys/dist/acpica/rsmisc.c
 P sys/dist/acpica/rsutils.c
 P sys/dist/acpica/rsxface.c
 P sys/dist/acpica/tbfadt.c
 P sys/dist/acpica/tbfind.c
 P sys/dist/acpica/tbinstal.c
 P sys/dist/acpica/tbutils.c
 P sys/dist/acpica/tbxface.c
 P sys/dist/acpica/tbxfroot.c
 P sys/dist/acpica/utalloc.c
 P sys/dist/acpica/utcache.c
 P sys/dist/acpica/utcopy.c
 P sys/dist/acpica/utdebug.c
 P sys/dist/acpica/utdelete.c
 P sys/dist/acpica/uteval.c
 P sys/dist/acpica/utglobal.c
 P sys/dist/acpica/utinit.c
 P sys/dist/acpica/utmath.c
 P sys/dist/acpica/utmisc.c
 P sys/dist/acpica/utmutex.c
 P sys/dist/acpica/utobject.c
 P sys/dist/acpica/utresrc.c
 P sys/dist/acpica/utstate.c
 P sys/dist/acpica/uttrack.c
 P sys/dist/acpica/utxface.c
 P sys/dist/pf/net/pf.c
 P sys/kern/kern_cpu.c
 P sys/kern/kern_kthread.c
 P sys/kern/kern_sleepq.c
 P sys/kern/kern_softint.c
 P sys/kern/kern_synch.c
 P sys/kern/sched_4bsd.c
 P sys/kern/sched_m2.c
 P sys/kern/subr_prf.c
 P sys/kern/sysv_shm.c
 P sys/kern/vfs_cache.c
 P sys/net/if_bridge.c
 U sys/netinet/icmp_private.h
 P sys/netinet/icmp_var.h
 P sys/netinet/in_gif.c
 P sys/netinet/ip_etherip.c
 P sys/netinet/ip_flow.c
 P sys/netinet/ip_icmp.c
 P sys/netinet/ip_input.c
 P sys/netinet/ip_output.c
 U sys/netinet/ip_private.h
 P sys/netinet/ip_var.h
 P sys/netinet/raw_ip.c
 P sys/netinet/tcp_input.c
 P sys/netinet/tcp_output.c
 U sys/netinet/tcp_private.h
 P sys/netinet/tcp_subr.c
 P sys/netinet/tcp_timer.c
 P sys/netinet/tcp_usrreq.c
 P sys/netinet/tcp_var.h
 U sys/netinet/udp_private.h
 P sys/netinet/udp_usrreq.c
 P sys/netinet/udp_var.h
 P sys/netinet6/ipsec.c
 P sys/netinet6/udp6_output.c
 P sys/sys/lwp.h
 P sys/sys/sched.h
 P sys/sys/shm.h

State-Changed-From-To: feedback->open
State-Changed-By: joerg@NetBSD.org
State-Changed-When: Sat, 05 Jul 2008 12:28:23 +0000
State-Changed-Why:
Feedback provided.


From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, "Jared D. McNeill" <jmcneill@invisible.ca>
Subject: Re: kern/38683: T61 cannot suspend with recent kernels
Date: Tue, 9 Sep 2008 23:17:01 -0400

 After conversations with Jared, we've more or less figured out why we
 were seeing different results: we were resuming differently.  I was
 using the Fn key; he was using the power key.

 New data; if I suspend with Fn+F4, I can resume with the power button
 but not with the Fn key.  If I suspend by closing the lid, I cannot
 resume by opening the lid.  If I suspend with Fn+F4, I can open the lid
 and then resume with the power button.  I didn't try Fn+F4, lid-close,
 lid-open, Fn, but I'm reasonably confident that that won't work.

 Perhaps the Fn key is generating some sort of keyboard or ACPI interrupt
 that needs to be cleared but isn't.  I have no idea how the lid switch
 shows up, or why it should be different than the power button.  I do
 recall some issue last fall -- December? -- where the system wouldn't
 resume at all on lid-open; that has since been fixed.  But might that
 fix offer a clue to what's happening?

Responsible-Changed-From-To: joerg->jmcneill
Responsible-Changed-By: jmcneill@NetBSD.org
Responsible-Changed-When: Wed, 10 Sep 2008 03:57:00 +0000
Responsible-Changed-Why:
I'll handle it.


State-Changed-From-To: open->feedback
State-Changed-By: jmcneill@NetBSD.org
State-Changed-When: Wed, 10 Sep 2008 03:57:00 +0000
State-Changed-Why:
I checked in a fix. Can you confirm that it works for you now?


From: "Jared D. McNeill" <jmcneill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38683 CVS commit: src/sys
Date: Wed, 10 Sep 2008 03:56:12 +0000 (UTC)

 Module Name:	src
 Committed By:	jmcneill
 Date:		Wed Sep 10 03:56:12 UTC 2008

 Modified Files:
 	src/sys/arch/x86/acpi: acpi_wakeup.c
 	src/sys/dev/acpi: acpi.c

 Log Message:
 PR# 38683 - T61 cannot suspend with recent kernels

 Don't restore spl until after AcpiLeaveSleepState.


 To generate a diff of this commit:
 cvs rdiff -r1.7 -r1.8 src/sys/arch/x86/acpi/acpi_wakeup.c
 cvs rdiff -r1.118 -r1.119 src/sys/dev/acpi/acpi.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: jmcneill@NetBSD.org, joerg@NetBSD.org, netbsd-bugs@NetBSD.org,
 gnats-admin@NetBSD.org
Subject: Re: kern/38683 (Thinkpad T61/amd64 cannot suspend with recent
 kernels)
Date: Wed, 10 Sep 2008 14:15:11 -0400

 On Wed, 10 Sep 2008 03:57:01 +0000 (UTC)
 jmcneill@NetBSD.org wrote:

 > Synopsis: Thinkpad T61/amd64 cannot suspend with recent kernels
 > 
 > Responsible-Changed-From-To: joerg->jmcneill
 > Responsible-Changed-By: jmcneill@NetBSD.org
 > Responsible-Changed-When: Wed, 10 Sep 2008 03:57:00 +0000
 > Responsible-Changed-Why:
 > I'll handle it.
 > 
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: jmcneill@NetBSD.org
 > State-Changed-When: Wed, 10 Sep 2008 03:57:00 +0000
 > State-Changed-Why:
 > I checked in a fix. Can you confirm that it works for you now?
 > 
 > 
 > 
 Yes, this seems to have solved my problems; thanks!  Of course, now I
 have to wait for Joerg's objections to be resolved...


 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

State-Changed-From-To: feedback->analyzed
State-Changed-By: jmcneill@NetBSD.org
State-Changed-When: Fri, 19 Sep 2008 11:20:44 +0000
State-Changed-Why:
Previous fix reverted.


From: Joerg Sonnenberger <joerg@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38683 CVS commit: src/sys/arch/x86/acpi
Date: Tue, 23 Sep 2008 14:54:23 +0000 (UTC)

 Module Name:	src
 Committed By:	joerg
 Date:		Tue Sep 23 14:54:23 UTC 2008

 Modified Files:
 	src/sys/arch/x86/acpi: acpi_wakeup.c

 Log Message:
 Explicitly disable all GPEs and clear fixed events before enabling
 interrupts. This is the first part of PR 38683.


 To generate a diff of this commit:
 cvs rdiff -r1.9 -r1.10 src/sys/arch/x86/acpi/acpi_wakeup.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: joerg@NetBSD.org, jmcneill@NetBSD.org, gnats-admin@NetBSD.org,
 netbsd-bugs@NetBSD.org
Subject: Re: PR/38683 CVS commit: src/sys/arch/x86/acpi
Date: Tue, 23 Sep 2008 22:57:43 -0400

 On Tue, 23 Sep 2008 14:55:02 +0000 (UTC)
 Joerg Sonnenberger <joerg@NetBSD.org> wrote:

 > The following reply was made to PR kern/38683; it has been noted by
 > GNATS.
 > 
 > From: Joerg Sonnenberger <joerg@netbsd.org>
 > To: gnats-bugs@gnats.NetBSD.org
 > Cc: 
 > Subject: PR/38683 CVS commit: src/sys/arch/x86/acpi
 > Date: Tue, 23 Sep 2008 14:54:23 +0000 (UTC)
 > 
 >  Module Name:	src
 >  Committed By:	joerg
 >  Date:		Tue Sep 23 14:54:23 UTC 2008
 >  
 >  Modified Files:
 >  	src/sys/arch/x86/acpi: acpi_wakeup.c
 >  
 >  Log Message:
 >  Explicitly disable all GPEs and clear fixed events before enabling
 >  interrupts. This is the first part of PR 38683.

 This kernel appears to solve the suspend/resume problem.  I had
 mentioned an issue with a powerd script hanging; that was, I believe,
 due to a 'cpuctl offline 1' command I had had to use.  Commenting that
 out has eliminated the problem.  However....

 I sometimes see hundreds of repetitions of the same

 kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkeyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

 key -- you can see an example above.  That happened when I had a system
 build running in another window while I was typing this, which suggests
 something seriously borked in the scheduler or timer management.  No
 clue if it's related to suspend/resume cycles.  And it sometimes
 happens even if I don't have anything else running.

 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org, jmcneill@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/38683 CVS commit: src/sys/arch/x86/acpi
Date: Wed, 24 Sep 2008 20:13:46 +0200

 On Tue, Sep 23, 2008 at 10:57:43PM -0400, Steven M. Bellovin wrote:
 [repeated key]
 > build running in another window while I was typing this, which suggests
 > something seriously borked in the scheduler or timer management.  No
 > clue if it's related to suspend/resume cycles.  And it sometimes
 > happens even if I don't have anything else running.

 Yeah, there are some issues with the current key repeating code in some
 drivers. I think I fixed PS2 back when I was adjusting it, but I might
 have missed it in other drivers or it got broken again.

 Joerg

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Joerg Sonnenberger <joerg@britannica.bec.de>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org, jmcneill@NetBSD.org,
 gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/38683 CVS commit: src/sys/arch/x86/acpi
Date: Wed, 24 Sep 2008 14:19:09 -0400

 On Wed, 24 Sep 2008 20:13:46 +0200
 Joerg Sonnenberger <joerg@britannica.bec.de> wrote:

 > On Tue, Sep 23, 2008 at 10:57:43PM -0400, Steven M. Bellovin wrote:
 > [repeated key]
 > > build running in another window while I was typing this, which
 > > suggests something seriously borked in the scheduler or timer
 > > management.  No clue if it's related to suspend/resume cycles.  And
 > > it sometimes happens even if I don't have anything else running.
 > 
 > Yeah, there are some issues with the current key repeating code in
 > some drivers. I think I fixed PS2 back when I was adjusting it, but I
 > might have missed it in other drivers or it got broken again.
 > 
 I'll send-pr so it doesn't get lost.  Today, it's behaving, but I don't
 know how long that will keep up...


 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: Joerg Sonnenberger <joerg@britannica.bec.de>, gnats-bugs@NetBSD.org,
 joerg@NetBSD.org, jmcneill@NetBSD.org, gnats-admin@NetBSD.org,
 netbsd-bugs@NetBSD.org
Subject: Re: PR/38683 CVS commit: src/sys/arch/x86/acpi
Date: Sun, 28 Sep 2008 12:59:34 -0400

 I think we can mark my PR closed -- the fixes are working well for me,
 enough so that I've upgraded my userland, too.  My thanks to you all for
 working on it.

State-Changed-From-To: analyzed->closed
State-Changed-By: jmcneill@NetBSD.org
State-Changed-When: Mon, 02 Mar 2009 20:48:48 +0000
State-Changed-Why:
Fixed a while ago.


>Unformatted:

Home	PR Database Search