Re: port-i386/38936: system can not power down via acpi

[Markus W Kilbinger <mk%kilbi.de@localhost>]

The following reply was made to PR port-i386/38936; it has been noted by GNATS.

From: Markus W Kilbinger <mk%kilbi.de@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: port-i386/38936: system can not power down via acpi
Date: Sun, 15 Jun 2008 19:32:26 +0200

 >>>>> "Martin" == Martin Husemann <martin%duskware.de@localhost> writes:
 
     Martin> Well, it does the same already, plus some more. Since the
     Martin> pure acpi state transition works, it must be something we
     Martin> do in preparation for it that breaks things.
 
 I digged around that and found that simply commenting out the
 x86_broadcast_ipi(X86_IPI_HALT) call
 
   Index: machdep.c
   ===================================================================
   RCS file: /cvsroot/src/sys/arch/i386/i386/machdep.c,v
   retrieving revision 1.636
   diff -u -r1.636 machdep.c
   --- machdep.c   5 Jun 2008 21:44:31 -0000       1.636
   +++ machdep.c   15 Jun 2008 17:24:06 -0000
   @@ -897,9 +897,11 @@
           /* Disable interrupts. */
           (void)splhigh();
    
   +       /*
    #ifdef MULTIPROCESSOR
           x86_broadcast_ipi(X86_IPI_HALT);
    #endif
   +       */
    
           if ((howto & RB_POWERDOWN) == RB_POWERDOWN) {
    #ifdef XEN
 
 made 'shutdown -p now' working again. Wakeup on lan is also working
 after that...
 
 All other commenting out trials (shutdown hooks, pmf stuff) didn't
 change the otherwise 'shutdown -p now' hangup anyway.
 
 So, is 'x86_broadcast_ipi(X86_IPI_HALT);' superflous?
 
 Or does that call has to be reorder in the sequence of the other
 shutdown preparation steps? (I didn't try that...)
 
 Markus.