From: Andrew Morton <akpm@zip.com.au>
To: j-nomura@ce.jp.nec.com
Cc: linux-kernel@vger.kernel.org, David Mosberger <davidm@hpl.hp.com>,
Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: [PATCH] 2.4.16 kernel/printk.c (per processorinitializationcheck)
Date: Thu, 06 Dec 2001 19:40:14 -0800 [thread overview]
Message-ID: <3C103A1E.2524A7B7@zip.com.au> (raw)
In-Reply-To: <3C0C2AAF.6141D797@zip.com.au>, <3C0B43DC.7A8F582A@zip.com.au> <20011203193235S.nomura@hpc.bs1.fc.nec.co.jp> <3C0C2AAF.6141D797@zip.com.au> <20011206140102Z.nomura@hpc.bs1.fc.nec.co.jp>
j-nomura@ce.jp.nec.com wrote:
>
> Hi,
> excuse me for not prompt response. I've been off-line for 2 days.
>
> > > The reason I put it in release_console_sem() is that release_console_sem()
> > > can be called from other functions than printk(), e.g. console_unblank().
> > > I agree with you that it is clearer but I think it is not sufficient.
> >
> > I really doubt if any of those paths could be called before
> > even the MMU is set up.
>
Marcelo,
after a fairly lengthy off-list discussion, it turns out that
special-casing printk is probably the best way to proceed
to fix this one.
The problem is that the boot processor sets up the console drivers,
and is able to call them via printk(), but the application processors
at that time are not able to call printk() because the console device
driver mappings are not set up. Undoing this inside the ia64 boot code is
complex and fragile. Possibly the problem exists on other platforms
but hasn't been discovered yet.
So the patch defines an architecture-specific macro `arch_consoles_callable()'
which, if not defined, defaults to `1', so the impact to other platforms
(and to uniprocessor ia64) is zero.
--- linux-2.4.17-pre4/include/asm-ia64/system.h Thu Nov 22 23:02:59 2001
+++ linux-akpm/include/asm-ia64/system.h Wed Dec 5 23:09:15 2001
@@ -405,6 +405,10 @@ extern void ia64_load_extra (struct task
ia64_psr(ia64_task_regs(prev))->dfh = 1; \
__switch_to(prev,next,last); \
} while (0)
+
+/* Return true if this CPU can call the console drivers in printk() */
+#define arch_consoles_callable() (cpu_online_map & (1UL << smp_processor_id()))
+
#else
# define switch_to(prev,next,last) do { \
ia64_psr(ia64_task_regs(next))->dfh = (ia64_get_fpu_owner() != (next)); \
--- linux-2.4.17-pre4/kernel/printk.c Thu Nov 22 23:02:59 2001
+++ linux-akpm/kernel/printk.c Wed Dec 5 23:03:54 2001
@@ -38,6 +38,10 @@
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
+#ifndef arch_consoles_callable
+#define arch_consoles_callable() (1)
+#endif
+
/* printk's without a loglevel use this.. */
#define DEFAULT_MESSAGE_LOGLEVEL 4 /* KERN_WARNING */
@@ -438,6 +442,14 @@ asmlinkage int printk(const char *fmt, .
log_level_unknown = 1;
}
+ if (!arch_consoles_callable()) {
+ /*
+ * On some architectures, the consoles are not usable
+ * on secondary CPUs early in the boot process.
+ */
+ spin_unlock_irqrestore(&logbuf_lock, flags);
+ goto out;
+ }
if (!down_trylock(&console_sem)) {
/*
* We own the drivers. We can drop the spinlock and let
@@ -454,6 +466,7 @@ asmlinkage int printk(const char *fmt, .
*/
spin_unlock_irqrestore(&logbuf_lock, flags);
}
+out:
return printed_len;
}
EXPORT_SYMBOL(printk);
next prev parent reply other threads:[~2001-12-07 3:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 5:46 [PATCH] 2.4.16 kernel/printk.c (per processor initialization check) j-nomura
2001-12-03 9:20 ` Andrew Morton
2001-12-03 10:32 ` j-nomura
2001-12-04 1:45 ` [PATCH] 2.4.16 kernel/printk.c (per processor initializationcheck) Andrew Morton
2001-12-06 5:01 ` j-nomura
2001-12-07 3:40 ` Andrew Morton [this message]
2001-12-07 18:52 ` [PATCH] 2.4.16 kernel/printk.c (per processorinitializationcheck) Marcelo Tosatti
2001-12-07 20:52 ` William Lee Irwin III
2001-12-07 21:37 ` David Mosberger
2001-12-07 20:47 ` Marcelo Tosatti
2001-12-07 22:17 ` David Mosberger
2001-12-07 21:09 ` Marcelo Tosatti
2001-12-08 1:10 ` David Mosberger
2001-12-08 11:27 ` Alan Cox
2001-12-08 16:41 ` David Mosberger
2001-12-08 20:45 ` Alan Cox
2001-12-09 0:32 ` David Mosberger
2001-12-09 0:55 ` Alan Cox
2001-12-09 0:58 ` David Mosberger
2001-12-09 1:15 ` Alan Cox
2001-12-09 1:14 ` David Mosberger
2001-12-09 1:32 ` Alan Cox
2001-12-07 22:08 ` Alan Cox
2001-12-07 22:14 ` Christopher Friesen
-- strict thread matches above, loose matches on Subject: below --
2001-12-08 17:36 Manfred Spraul
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=3C103A1E.2524A7B7@zip.com.au \
--to=akpm@zip.com.au \
--cc=davidm@hpl.hp.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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