public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy TARREAU <willy@w.ods.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH] solved APM bug with -rc5 (take 2)
Date: Fri, 2 Aug 2002 02:12:58 +0200	[thread overview]
Message-ID: <20020802001258.GA178@pcw.home.local> (raw)
In-Reply-To: <1028240183.15022.99.camel@irongate.swansea.linux.org.uk>

On Thu, Aug 01, 2002 at 11:16:23PM +0100, Alan Cox wrote:
> On Thu, 2002-08-01 at 21:35, Willy TARREAU wrote:
> > +#ifdef CONFIG_SMP
> > +	/* 2002/08/01 - WT
> > +	 * This is to avoid random crashes at boot time during initialization
> > +	 * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
> > +	 * Some bioses don't like being called from CPU != 0.
> > +	 */
> > +	while (cpu_number_map(smp_processor_id()) != 0) {
> > +		schedule();
> > +	}
> > +#endif
> 
> What guarantees that loop will ever exit ?

I asked Ingo for some advice, and he gently sent me a piece of code as an
example of how to reliably bind a task to a CPU. I tried it, and it's OK here.
I could reliably switch several times from cpu0 to cpu1, then back to cpu0.
Since it was cleaner than the previous method, I also did the same for
apm_power_off(), thus getting rid of apm_magic() and its dedicated thread.
Then again, I tested with multiple cpu switches, and every time, my system
correctly handles the case. I'm writing this mail under 2.4.19-rc5.

So here is the patch against 2.4.19-rc5, hoping it will get in this time.
I think it should apply without a glitch to 2.4.19-rc5-ac1, but don't
know about 2.5, nor even if it is needed.

Feedback welcome, of course ;-)

Cheers,
Willy


--- linux-2.4.19-rc5/arch/i386/kernel/apm.c	Thu Aug  1 22:07:39 2002
+++ linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c	Fri Aug  2 01:52:55 2002
@@ -862,14 +862,6 @@
 		apm_do_busy();
 }
 
-#ifdef CONFIG_SMP
-static int apm_magic(void * unused)
-{
-	while (1)
-		schedule();
-}
-#endif
-
 /**
  *	apm_power_off	-	ask the BIOS to power off
  *
@@ -897,10 +889,11 @@
 	 */
 #ifdef CONFIG_SMP
 	/* Some bioses don't like being called from CPU != 0 */
-	while (cpu_number_map(smp_processor_id()) != 0) {
-		kernel_thread(apm_magic, NULL,
-			CLONE_FS | CLONE_FILES | CLONE_SIGHAND | SIGCHLD);
+	if (cpu_number_map(smp_processor_id()) != 0) {
+		current->cpus_allowed = 1;
 		schedule();
+		if (unlikely(cpu_number_map(smp_processor_id()) != 0))
+			BUG();
 	}
 #endif
 	if (apm_info.realmode_power_off)
@@ -1661,6 +1654,21 @@
 	strcpy(current->comm, "kapmd");
 	sigfillset(&current->blocked);
 
+#ifdef CONFIG_SMP
+	/* 2002/08/01 - WT
+	 * This is to avoid random crashes at boot time during initialization
+	 * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
+	 * Some bioses don't like being called from CPU != 0.
+	 * Method suggested by Ingo Molnar.
+	 */
+	if (cpu_number_map(smp_processor_id()) != 0) {
+		current->cpus_allowed = 1;
+		schedule();
+		if (unlikely(cpu_number_map(smp_processor_id()) != 0))
+			BUG();
+	}
+#endif
+	
 	if (apm_info.connection_version == 0) {
 		apm_info.connection_version = apm_info.bios.version;
 		if (apm_info.connection_version > 0x100) {
@@ -1707,7 +1715,7 @@
 		}
 	}
 
-	if (debug && (smp_num_cpus == 1)) {
+	if (debug) {
 		error = apm_get_power_status(&bx, &cx, &dx);
 		if (error)
 			printk(KERN_INFO "apm: power status not available\n");


  parent reply	other threads:[~2002-08-02  0:10 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-01  6:38 Linux v2.4.19-rc5 Marcelo Tosatti
2002-08-01  7:49 ` Jens Axboe
2002-08-01  7:14   ` Marcelo Tosatti
2002-08-01  8:10     ` Jens Axboe
2002-08-01  9:02       ` Andrew Morton
2002-08-01  8:58         ` Jens Axboe
2002-08-01 14:45         ` Steven Cole
2002-08-01 18:57           ` Andrew Morton
2002-08-01 20:15     ` Steven Cole
2002-08-06  3:46       ` Bill Davidsen
2002-08-06  4:30         ` Andrew Morton
2002-08-06 14:07           ` Steven Cole
2002-08-06 14:20             ` Rik van Riel
2002-08-06 17:12             ` Andrew Morton
2002-08-06  5:42         ` Jens Axboe
2002-08-06  8:30           ` Adrian Bunk
2002-08-06  8:48             ` Jens Axboe
2002-08-06 10:31           ` Lincoln Dale
2002-08-06 12:59         ` Rik van Riel
2002-08-07  1:09           ` Bill Davidsen
2002-08-07  2:54             ` Steven Cole
2002-08-07 22:30               ` Bill Davidsen
2002-08-07 22:39                 ` Rik van Riel
2002-08-07 23:44                   ` Bill Davidsen
2002-08-07 23:53                     ` Rik van Riel
2002-08-09 17:46                       ` Bill Davidsen
2002-08-09 19:27                         ` Rik van Riel
2002-08-01  7:55 ` Keith Owens
2002-08-01  8:10   ` Jens Axboe
2002-08-04  6:50   ` H. Peter Anvin
2002-08-01 11:32 ` Willy TARREAU
2002-08-01 13:54   ` Alan Cox
2002-08-01 12:48     ` Willy TARREAU
2002-08-01 12:12 ` Linux v2.4.19-rc5 - APM bug Willy TARREAU
2002-08-01 13:32   ` [PANIC] APM bug with -rc4 and -rc5 Willy TARREAU
2002-08-01 14:55     ` Alan Cox
2002-08-01 13:56       ` Willy Tarreau
2002-08-01 15:24         ` Willy Tarreau
2002-08-01 16:53           ` Alan Cox
2002-08-01 16:41             ` Willy Tarreau
2002-08-01 20:35             ` [PATCH] solved APM bug with -rc5 Willy TARREAU
2002-08-01 20:52               ` Richard Gooch
2002-08-01 20:54                 ` Richard Gooch
2002-08-01 21:17                   ` Willy TARREAU
2002-08-01 22:37                     ` Alan Cox
2002-08-01 20:58                 ` Dave Jones
2002-08-01 22:16               ` Alan Cox
2002-08-01 21:07                 ` Willy Tarreau
2002-08-01 21:47                   ` Linus Torvalds
2002-08-02  0:12                 ` Willy TARREAU [this message]
2002-08-02  1:47 ` [PATCH] pdc20265 problem Nick Orlov
2002-08-02  2:29   ` Nick Orlov
2002-08-02 12:27   ` Alan Cox
2002-08-02 12:52     ` Nick Orlov
2002-08-02 14:00       ` Bartlomiej Zolnierkiewicz
2002-08-02 14:45         ` Nick Orlov

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=20020802001258.GA178@pcw.home.local \
    --to=willy@w.ods.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox