Re: kern/44366: poweroff doesn't work

[David Young <dyoung%pobox.com@localhost>]

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

From: David Young <dyoung%pobox.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, mihai.chelaru%ngnetworks.ro@localhost
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 12:07:18 -0600

 On Thu, Jan 13, 2011 at 03:25:04PM +0000, Jukka Ruohonen wrote:
 > The following reply was made to PR kern/44366; it has been noted by GNATS.
 > 
 > From: Jukka Ruohonen <jruohonen%iki.fi@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: mihai.chelaru%ngnetworks.ro@localhost
 > Subject: Re: kern/44366: poweroff doesn't work
 > Date: Thu, 13 Jan 2011 17:20:51 +0200
 > 
 >  On Thu, Jan 13, 2011 at 01:10:07PM +0000, Mihai Chelaru wrote:
 >  >  It still doesn't work, sorry. Moreover, I just tested 5.0/i386
 >  >  and 5.1 GENERIC kernels and both completes power off.
 >  
 >  Thanks to Jared D. McNeill, the bug was located. This regression was caused
 >  by adding detach-routines to acpi(4) followed by the commit to i386/amd64
 >  machdep.c:
 >  
 >  revision 1.669
 >  date: 2009/06/26 23:40:27;  author: dyoung;  state: Exp;  lines: +52 -27
 >  During a normal shutdown, gracefully tear down arbitrary stacks of
 >  filesystems and (pseudo-)devices, according to the algorithm at A3
 >  and A4, below.
 >  
 >  Proposed and discussed at
 >  <http://mail-index.netbsd.org/tech-kern/2009/04/20/msg004864.html>.  No
 >  objections.
 >  
 >  ...
 >  
 >  In particular, cpu_reboot() now runs config_detach_all(), while acpi(4) can
 >  not obviously be detached as it is responsible for the hardware powerdown. 
 >  It was also disucssed that removing the dopowerhooks() could be unsafe (even
 >  on x86).
 >  
 >  At the moment it is unclear how this should be resolved.
 
 Two corrections to the above:
 
 acpi(4) is not flagged as detachable at shutdown, so I don't think that
 the kernel actually detaches it.  The kernel should print a message for
 each device that it detaches during shutdown.
 
 I think that you meant shutdownhooks, not powerhooks.  You should
 be able to rule that out quickly, because few drivers establish
 shutdownhooks any longer:
 
 find sys/dev/ sys/arch/{i386,amd64,x86} -type f | xargs grep -l 
shutdownhook_est
 sys/dev/bi/if_ni.c
 sys/dev/eisa/if_fea.c
 sys/dev/i2o/iop.c
 sys/dev/ic/aac.c
 sys/dev/ic/awi.c
 sys/dev/ic/cac.c
 sys/dev/ic/ciss.c
 sys/dev/ic/dpt.c
 sys/dev/ic/mlx.c
 sys/dev/ic/mtd803.c
 sys/dev/ic/tropic.c
 sys/dev/isa/if_lc_isa.c
 sys/dev/isa/if_ntwoc_isa.c
 sys/dev/marvell/gtmpsc.c
 sys/dev/mvme/clock_pcctwo.c
 sys/dev/pci/amr.c
 sys/dev/pci/if_de.c
 sys/dev/pci/if_fpa.c
 sys/dev/pci/if_lmc.c
 sys/dev/pci/if_ntwoc_pci.c
 sys/dev/pci/mly.c
 sys/dev/pci/twa.c
 sys/dev/qbus/if_de.c
 sys/dev/sysmon/sysmon_wdog.c
 sys/dev/tc/if_fta.c
 sys/arch/i386/tags
 sys/arch/amd64/tags
 
 If an incomplete or broken detachment routine causes the trouble, you
 can narrow in on the problem driver by removing DVF_DETACH_SHUTDOWN
 flags from CFATTACH_DECL3_NEW() calls affecting drivers for your
 hardware, and adding them back again one by one.
 
 Dave
 
 -- 
 David Young             OJC Technologies
 dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933