All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Finch <Uberboxen-pVBOr+mkmsReoWH0uzbU5w@public.gmane.org>
To: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Willy Tarreau <willy-tRhHnHjXm5DYtjvyW6yDsg@public.gmane.org>,
	Marcelo Tosatti
	<marcelo.tosatti-3EexvZdKGZQ39yzSjRtAkw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	ACPI Developers
	<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [RFC] ACPI power-off on P4 HT
Date: Wed, 25 Feb 2004 23:56:09 -0800	[thread overview]
Message-ID: <20040226075609.GA745@uberboxen> (raw)
In-Reply-To: <1077695701.5911.130.camel-D2Zvc0uNKG8@public.gmane.org>

My workstation has a problem with power-off as well. It is a dual P3
(Katmai) Epox motherboard with Intel 440BX chipset. About 50% of the
time I try powering off the system, the NMI watchdog fires detecting
CPU1 as locked up. I would be willing to try any patches that may fix
this, as I miss being able to let my workstation shutdown on it's own.

Thanks,
-Greg

On Wed, Feb 25, 2004 at 02:55:01AM -0500, Len Brown wrote:
> Willy,
> I do think we need a generic way to be sure that certain routines are
> run only on cpu0.
> 
> I don't see it in the ACPI spec, but it seems that on some platforms,
> some register accesses (such as writing to the sleep control reg) are
> reliable only when accessed from cpu0.
> 
> This issue has been with us for some time:
> http://bugzilla.kernel.org/show_bug.cgi?id=1141
> 
> I am hopeful that the prepare-shutdown sequence you suggest below will
> not be necessary.
> 
> thanks,
> -Len
> 
> 
> On Wed, 2004-02-25 at 02:00, Willy Tarreau wrote:
> > Hi Len & Marcelo,
> > 
> > as I previously said, the patch I sent which fixes the poweroff on my VAIO is
> > not enough to shut down the supermicro P4 HT. So I borrowed some code from
> > machine_restart() to try to :
> >   - disable APIC  => was not enough, but I must retry on the VAIO
> >   - stop the second CPU => was not enough either
> >   - bounce on boot_cpu and stop the others => it did work.
> > 
> > So I think that ACPI is not SMP-proof nor HT-proof on some hardware. My new
> > problem is that I feel like the code I have included in acpi_power_off() to
> > do this is a bit too much x86 specific, so I'd like to move this to
> > arch/i386/kernel/process.c with all the rest, but I don't know how to cut
> > this. I think that a general function such as machine_prepare_shutdown() or
> > something like this would be useful and could be shared by both ACPI and
> > machine_restart(). It would basically to everything that is needed in such
> > a case :
> >   - on SMP, bounce on boot_cpu, then halt the current CPU if != boot_cpu
> >   - on SMP, stop all other CPUs
> >   - on UP, disable IOAPIC
> >   - disable local APIC
> > 
> > I suspect that this function would be useful for some suspend cases, but I'm
> > not sure. My other problem is to know what we should do then with other
> > arches. Create an identical function for everyone, or just call it from
> > ACPI on CONFIG_X86, or even add a CONFIG_MACHINE_PREPARE_SHUTDOWN ?
> > 
> > I need some feedback here. Any suggestions ?
> > 
> > Regards,
> > Willy
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

WARNING: multiple messages have this Message-ID (diff)
From: Gregory Finch <Uberboxen@Telus.net>
To: Len Brown <len.brown@intel.com>
Cc: Willy Tarreau <willy@w.ods.org>,
	Marcelo Tosatti <marcelo.tosatti@cyclades.com.br>,
	linux-kernel@vger.kernel.org,
	ACPI Developers <acpi-devel@lists.sourceforge.net>
Subject: Re: [RFC] ACPI power-off on P4 HT
Date: Wed, 25 Feb 2004 23:56:09 -0800	[thread overview]
Message-ID: <20040226075609.GA745@uberboxen> (raw)
In-Reply-To: <1077695701.5911.130.camel@dhcppc4>

My workstation has a problem with power-off as well. It is a dual P3
(Katmai) Epox motherboard with Intel 440BX chipset. About 50% of the
time I try powering off the system, the NMI watchdog fires detecting
CPU1 as locked up. I would be willing to try any patches that may fix
this, as I miss being able to let my workstation shutdown on it's own.

Thanks,
-Greg

On Wed, Feb 25, 2004 at 02:55:01AM -0500, Len Brown wrote:
> Willy,
> I do think we need a generic way to be sure that certain routines are
> run only on cpu0.
> 
> I don't see it in the ACPI spec, but it seems that on some platforms,
> some register accesses (such as writing to the sleep control reg) are
> reliable only when accessed from cpu0.
> 
> This issue has been with us for some time:
> http://bugzilla.kernel.org/show_bug.cgi?id=1141
> 
> I am hopeful that the prepare-shutdown sequence you suggest below will
> not be necessary.
> 
> thanks,
> -Len
> 
> 
> On Wed, 2004-02-25 at 02:00, Willy Tarreau wrote:
> > Hi Len & Marcelo,
> > 
> > as I previously said, the patch I sent which fixes the poweroff on my VAIO is
> > not enough to shut down the supermicro P4 HT. So I borrowed some code from
> > machine_restart() to try to :
> >   - disable APIC  => was not enough, but I must retry on the VAIO
> >   - stop the second CPU => was not enough either
> >   - bounce on boot_cpu and stop the others => it did work.
> > 
> > So I think that ACPI is not SMP-proof nor HT-proof on some hardware. My new
> > problem is that I feel like the code I have included in acpi_power_off() to
> > do this is a bit too much x86 specific, so I'd like to move this to
> > arch/i386/kernel/process.c with all the rest, but I don't know how to cut
> > this. I think that a general function such as machine_prepare_shutdown() or
> > something like this would be useful and could be shared by both ACPI and
> > machine_restart(). It would basically to everything that is needed in such
> > a case :
> >   - on SMP, bounce on boot_cpu, then halt the current CPU if != boot_cpu
> >   - on SMP, stop all other CPUs
> >   - on UP, disable IOAPIC
> >   - disable local APIC
> > 
> > I suspect that this function would be useful for some suspend cases, but I'm
> > not sure. My other problem is to know what we should do then with other
> > arches. Create an identical function for everyone, or just call it from
> > ACPI on CONFIG_X86, or even add a CONFIG_MACHINE_PREPARE_SHUTDOWN ?
> > 
> > I need some feedback here. Any suggestions ?
> > 
> > Regards,
> > Willy
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  parent reply	other threads:[~2004-02-26  7:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-07  9:10 [BKPATCH] ACPI for 2.4 Len Brown
2004-02-07  9:10 ` Len Brown
     [not found] ` <1076145024.8687.32.camel-D2Zvc0uNKG8@public.gmane.org>
2004-02-08  8:20   ` Willy Tarreau
2004-02-08  8:20     ` Willy Tarreau
     [not found]     ` <20040208082059.GD29363-HkMpAodKYdnXX8ko2wsARw@public.gmane.org>
2004-02-08  9:08       ` Willy Tarreau
2004-02-08  9:08         ` Willy Tarreau
     [not found]         ` <20040214081726.GH29363@alpha.home.local>
     [not found]           ` <1076824106.25344.78.camel@dhcppc4>
2004-02-25  7:00             ` [RFC] ACPI power-off on P4 HT Willy Tarreau
     [not found]               ` <20040225070019.GA30971-HkMpAodKYdnXX8ko2wsARw@public.gmane.org>
2004-02-25  7:55                 ` Len Brown
2004-02-25  7:55                   ` Len Brown
     [not found]                   ` <1077695701.5911.130.camel-D2Zvc0uNKG8@public.gmane.org>
2004-02-25 16:13                     ` Zwane Mwaikambo
2004-02-25 16:13                       ` Zwane Mwaikambo
2004-02-26  7:56                     ` Gregory Finch [this message]
2004-02-26  7:56                       ` Gregory Finch
     [not found]                       ` <20040226075609.GA745-t/Pdn6GhL7X/PtFMR13I2A@public.gmane.org>
2004-02-26 10:57                         ` Willy Tarreau
2004-02-26 10:57                           ` Willy Tarreau
     [not found]                           ` <20040226105744.GA3406-HkMpAodKYdnXX8ko2wsARw@public.gmane.org>
2004-02-26 12:28                             ` Stian Jordet
2004-02-26 12:28                               ` Stian Jordet
     [not found]                               ` <1077798440.955.1.camel-rd0e0RNjLLRX8BKYUJ5quQ@public.gmane.org>
2004-02-26 13:07                                 ` Willy Tarreau
2004-02-26 13:07                                   ` Willy Tarreau
     [not found]                                   ` <20040226130724.GA3704-HkMpAodKYdnXX8ko2wsARw@public.gmane.org>
2004-02-26 13:29                                     ` Stian Jordet
2004-02-26 13:29                                       ` Stian Jordet
2004-02-26 13:16               ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040226075609.GA745@uberboxen \
    --to=uberboxen-pvbor+mkmsreowh0uzbu5w@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marcelo.tosatti-3EexvZdKGZQ39yzSjRtAkw@public.gmane.org \
    --cc=willy-tRhHnHjXm5DYtjvyW6yDsg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.