* Re: [Libmtp-discuss] [RFC/PATCH 0/2] u_char.c and mtp.c patches
From: Felipe Balbi @ 2010-04-23 13:04 UTC (permalink / raw)
To: ext pouly amaury
Cc: libmtp-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Balbi Felipe (Nokia-D/Helsinki), linux-embedded,
Mandy Arnaud.2 (EXT-Teleca/Helsinki), Linux USB Mailing List,
Quadros Roger (Nokia-D/Helsinki), David Brownell,
Krogerus Heikki (EXT-Teleca/Helsinki), Tim Bird,
Kaliuta Yauheni (Nokia-D/Helsinki)
In-Reply-To: <p2ze3bf744d1004230602nd09a7570jb3cee76f87ba8c00-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Fri, Apr 23, 2010 at 03:02:31PM +0200, ext pouly amaury wrote:
>Those two patents may apply:
>System and method to specify extended configuration descriptor
>information in USB devices
>System and method to specify device specific user interface information
>in the firmware of a USB device
exactly, those are the ones. Thanks a lot for finding that out.
--
balbi
DefectiveByDesign.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-04-30 22:03 UTC (permalink / raw)
To: linux-embedded; +Cc: linux kernel
Hi,
while i was searching for effective logging of complete console output
produced by the kernel and user phase of the boot process, it turned out
that only kernel messages imho get systematically cached and stored into
log files (if needed). All userspace processes are on their own to use
syslog, which is fine, but there are also many console messages
reporting the boot status via init scripts, .... I came across the
bootlogd daemo, which handles the job of redirecting console output into
a log file, but i find it problematic to use especialy, when using
initial ram disk image.
So in short i came up with an idea to transform console writes into
printks at appropriate code place of some console drivers (the patch
includes code for VT console and SERIAL_CORE console drivers). Printks
eventually reach console device avoiding the patched part of the console
drivers.
I find this feature very interesting for embedded devices with limited
console abilities as well as for other for normal desktops using initial
ram disk images and / or some splash image to beautify booting. It is
always nice to have the possibility to review the complete boot output
at any time.
The more detail configuration of the feature is described in the Kconfig
files within the patch below.
The patch is also available here:
http://84.255.254.67/console_detour-2.6.33.3.patch
have fun, Samo
--
diff --git a_linux-2.6.33.3/drivers/char/Kconfig b_linux-2.6.33.3/drivers/char/Kconfig
index e023682..b5d0909 100644
--- a_linux-2.6.33.3/drivers/char/Kconfig
+++ b_linux-2.6.33.3/drivers/char/Kconfig
@@ -66,6 +66,23 @@ config VT_CONSOLE
If unsure, say Y.
+config VT_CONSOLE_DETOUR
+ bool "Support for VT console detour via printk"
+ depends on VT_CONSOLE
+ default n
+ ---help---
+ If you do say Y here, the support for writing console messages via
+ printk is included into VT console code.
+
+ The feature is usefull to catch all console log. In order to use this
+ feature, you should specify kernel command line option "detour" or write a
+ positive number into /proc/sys/kernel/console_detour. You can disable
+ the feature on-line by writing zero into the proc file. By writing a
+ negative value into the proc file, the feature is disabled permanently
+ (until next boot).
+
+ If unsure, say N.
+
config HW_CONSOLE
bool
depends on VT && !S390 && !UML
diff --git a_linux-2.6.33.3/drivers/char/vt.c b_linux-2.6.33.3/drivers/char/vt.c
index 50faa1f..ba649db 100644
--- a_linux-2.6.33.3/drivers/char/vt.c
+++ b_linux-2.6.33.3/drivers/char/vt.c
@@ -2696,6 +2696,16 @@ static int con_write(struct tty_struct *tty, const unsigned char *buf, int count
{
int retval;
+#ifdef CONFIG_VT_CONSOLE_DETOUR
+ if (console_detour) {
+ int idx = vt_console_driver.index - 1;
+
+ if ((idx >= 0) && (idx == tty->index)) {
+ console_printk_detour(buf, count);
+ return count;
+ }
+ }
+#endif
retval = do_con_write(tty, buf, count);
con_flush_chars(tty);
diff --git a_linux-2.6.33.3/drivers/serial/Kconfig b_linux-2.6.33.3/drivers/serial/Kconfig
index 9ff47db..20acfab 100644
--- a_linux-2.6.33.3/drivers/serial/Kconfig
+++ b_linux-2.6.33.3/drivers/serial/Kconfig
@@ -1031,6 +1031,23 @@ config SERIAL_CORE
config SERIAL_CORE_CONSOLE
bool
+config SERIAL_CORE_CONSOLE_DETOUR
+ bool "Support for serial console detour via printk"
+ depends on SERIAL_CORE_CONSOLE
+ default n
+ ---help---
+ If you do say Y here, the support for writing console messages via
+ printk is included into serial console code.
+
+ The feature is usefull to catch all console log. In order to use this
+ feature, you should specify kernel command line option "detour" or write a
+ positive number into /proc/sys/kernel/console_detour. You can disable
+ the feature on-line by writing zero into the proc file. By writing a
+ negative value into the proc file, the feature is disabled permanently
+ (until next boot).
+
+ If unsure, say N.
+
config CONSOLE_POLL
bool
diff --git a_linux-2.6.33.3/drivers/serial/serial_core.c b_linux-2.6.33.3/drivers/serial/serial_core.c
index 7f28307..5e7e762 100644
--- a_linux-2.6.33.3/drivers/serial/serial_core.c
+++ b_linux-2.6.33.3/drivers/serial/serial_core.c
@@ -513,6 +513,12 @@ uart_write(struct tty_struct *tty, const unsigned char *buf, int count)
}
port = state->uart_port;
+#ifdef CONFIG_SERIAL_CORE_CONSOLE_DETOUR
+ if (console_detour && uart_console(port) && (port->cons->flags & CON_ENABLED)) {
+ console_printk_detour(buf, count);
+ return count;
+ }
+#endif
circ = &state->xmit;
if (!circ->buf)
diff --git a_linux-2.6.33.3/include/linux/console.h b_linux-2.6.33.3/include/linux/console.h
index dcca533..bc88030 100644
--- a_linux-2.6.33.3/include/linux/console.h
+++ b_linux-2.6.33.3/include/linux/console.h
@@ -108,6 +108,12 @@ struct console {
struct console *next;
};
+extern int console_detour;
+extern void console_printk_detour(const unsigned char *, int);
+
+struct ctl_table;
+int detour_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
+
extern int console_set_on_cmdline;
extern int add_preferred_console(char *name, int idx, char *options);
diff --git a_linux-2.6.33.3/init/main.c b_linux-2.6.33.3/init/main.c
index 512ba15..5b1ba11 100644
--- a_linux-2.6.33.3/init/main.c
+++ b_linux-2.6.33.3/init/main.c
@@ -249,6 +249,15 @@ static int __init loglevel(char *str)
early_param("loglevel", loglevel);
+extern int console_detour;
+static int __init detour(char *str)
+{
+ console_detour = 1;
+ return 0;
+}
+
+early_param("detour", detour);
+
/*
* Unknown boot options get handed to init, unless they look like
* unused parameters (modprobe will find them in /proc/cmdline).
diff --git a_linux-2.6.33.3/kernel/printk.c b_linux-2.6.33.3/kernel/printk.c
index 1751c45..5a8056b 100644
--- a_linux-2.6.33.3/kernel/printk.c
+++ b_linux-2.6.33.3/kernel/printk.c
@@ -1368,6 +1368,51 @@ static int __init disable_boot_consoles(void)
}
late_initcall(disable_boot_consoles);
+/*
+ * This option can be enabled with kernel command line option "detour" or
+ * through a proc file (/proc/sys/kernel/console_detour). It enables console
+ * logging through printk, if supported by enabled console.
+ */
+int console_detour = 0;
+EXPORT_SYMBOL(console_detour);
+
+#define DETOUR_STR_SIZE 512
+void console_printk_detour(const unsigned char *buf, int count)
+{
+ char tmp[DETOUR_STR_SIZE + 1];
+
+ do {
+ if (count > DETOUR_STR_SIZE) {
+ memcpy(tmp, buf, DETOUR_STR_SIZE);
+ tmp[DETOUR_STR_SIZE] = '\0';
+ } else {
+ memcpy(tmp, buf, count);
+ tmp[count] = '\0';
+ }
+ count -= DETOUR_STR_SIZE;
+ printk("%s", tmp);
+ } while (count > 0);
+}
+EXPORT_SYMBOL(console_printk_detour);
+
+int detour_sysctl_handler(struct ctl_table *table, int write,
+ void __user *buffer, size_t *length, loff_t *ppos)
+{
+ static int disable_forever = 0;
+
+ proc_dointvec(table, write, buffer, length, ppos);
+ if (write) {
+ if ((console_detour < 0) || (disable_forever != 0)) {
+ disable_forever = 1;
+ console_detour = 0;
+ return 0;
+ }
+ if (console_detour > 1)
+ console_detour = 1;
+ }
+ return 0;
+}
+
#if defined CONFIG_PRINTK
/*
diff --git a_linux-2.6.33.3/kernel/sysctl.c b_linux-2.6.33.3/kernel/sysctl.c
index 8a68b24..ab644cb 100644
--- a_linux-2.6.33.3/kernel/sysctl.c
+++ b_linux-2.6.33.3/kernel/sysctl.c
@@ -50,6 +50,7 @@
#include <linux/ftrace.h>
#include <linux/slow-work.h>
#include <linux/perf_event.h>
+#include <linux/console.h>
#include <asm/uaccess.h>
#include <asm/processor.h>
@@ -936,6 +937,13 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
#endif
+ {
+ .procname = "console_detour",
+ .data = &console_detour,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &detour_sysctl_handler,
+ },
/*
* NOTE: do not add new entries to this table unless you have read
* Documentation/sysctl/ctl_unnumbered.txt
^ permalink raw reply related
* Re: [PATCH] console logging detour via printk
From: Randy Dunlap @ 2010-04-30 22:45 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux-embedded, linux kernel
In-Reply-To: <1272664980.10241.77.camel@itpsd6lap>
On Sat, 01 May 2010 00:03:00 +0200 Samo Pogacnik wrote:
> Hi,
> diff --git a_linux-2.6.33.3/drivers/char/Kconfig b_linux-2.6.33.3/drivers/char/Kconfig
> index e023682..b5d0909 100644
> --- a_linux-2.6.33.3/drivers/char/Kconfig
> +++ b_linux-2.6.33.3/drivers/char/Kconfig
> @@ -66,6 +66,23 @@ config VT_CONSOLE
>
> If unsure, say Y.
>
> +config VT_CONSOLE_DETOUR
> + bool "Support for VT console detour via printk"
> + depends on VT_CONSOLE
> + default n
> + ---help---
> + If you do say Y here, the support for writing console messages via
If you say Y here,
> + printk is included into VT console code.
> +
> + The feature is usefull to catch all console log. In order to use this
useful log messages.
> + feature, you should specify kernel command line option "detour" or write a
> + positive number into /proc/sys/kernel/console_detour. You can disable
> + the feature on-line by writing zero into the proc file. By writing a
> + negative value into the proc file, the feature is disabled permanently
> + (until next boot).
> +
> + If unsure, say N.
> +
> config HW_CONSOLE
> bool
> depends on VT && !S390 && !UML
> diff --git a_linux-2.6.33.3/drivers/serial/Kconfig b_linux-2.6.33.3/drivers/serial/Kconfig
> index 9ff47db..20acfab 100644
> --- a_linux-2.6.33.3/drivers/serial/Kconfig
> +++ b_linux-2.6.33.3/drivers/serial/Kconfig
> @@ -1031,6 +1031,23 @@ config SERIAL_CORE
> config SERIAL_CORE_CONSOLE
> bool
>
> +config SERIAL_CORE_CONSOLE_DETOUR
> + bool "Support for serial console detour via printk"
> + depends on SERIAL_CORE_CONSOLE
> + default n
> + ---help---
> + If you do say Y here, the support for writing console messages via
If you say Y here,
> + printk is included into serial console code.
> +
> + The feature is usefull to catch all console log. In order to use this
useful log messages.
> + feature, you should specify kernel command line option "detour" or write a
> + positive number into /proc/sys/kernel/console_detour. You can disable
> + the feature on-line by writing zero into the proc file. By writing a
> + negative value into the proc file, the feature is disabled permanently
> + (until next boot).
> +
> + If unsure, say N.
> +
The kernel command line option needs to be added to Documentation/kernel-parameters.txt
also, please.
> config CONSOLE_POLL
> bool
>
> diff --git a_linux-2.6.33.3/include/linux/console.h b_linux-2.6.33.3/include/linux/console.h
> index dcca533..bc88030 100644
> --- a_linux-2.6.33.3/include/linux/console.h
> +++ b_linux-2.6.33.3/include/linux/console.h
> @@ -108,6 +108,12 @@ struct console {
> struct console *next;
> };
>
> +extern int console_detour;
> +extern void console_printk_detour(const unsigned char *, int);
Please include parameter names in function prototype(s).
> +
> +struct ctl_table;
> +int detour_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
ditto
> +
> extern int console_set_on_cmdline;
>
> extern int add_preferred_console(char *name, int idx, char *options);
Looks interesting/useful to me. Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-01 8:37 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-embedded, linux kernel
In-Reply-To: <20100430154522.489df8bc.rdunlap@xenotime.net>
Dne 30.04.2010 (pet) ob 15:45 -0700 je Randy Dunlap zapisal(a):
> On Sat, 01 May 2010 00:03:00 +0200 Samo Pogacnik wrote:
>
> > Hi,
>
> > diff --git a_linux-2.6.33.3/drivers/char/Kconfig b_linux-2.6.33.3/drivers/char/Kconfig
> > index e023682..b5d0909 100644
> > --- a_linux-2.6.33.3/drivers/char/Kconfig
> > +++ b_linux-2.6.33.3/drivers/char/Kconfig
> > @@ -66,6 +66,23 @@ config VT_CONSOLE
> >
> > If unsure, say Y.
> >
> > +config VT_CONSOLE_DETOUR
> > + bool "Support for VT console detour via printk"
> > + depends on VT_CONSOLE
> > + default n
> > + ---help---
> > + If you do say Y here, the support for writing console messages via
>
> If you say Y here,
>
> > + printk is included into VT console code.
> > +
> > + The feature is usefull to catch all console log. In order to use this
>
> useful log messages.
>
> > + feature, you should specify kernel command line option "detour" or write a
> > + positive number into /proc/sys/kernel/console_detour. You can disable
> > + the feature on-line by writing zero into the proc file. By writing a
> > + negative value into the proc file, the feature is disabled permanently
> > + (until next boot).
> > +
> > + If unsure, say N.
> > +
> > config HW_CONSOLE
> > bool
> > depends on VT && !S390 && !UML
>
> > diff --git a_linux-2.6.33.3/drivers/serial/Kconfig b_linux-2.6.33.3/drivers/serial/Kconfig
> > index 9ff47db..20acfab 100644
> > --- a_linux-2.6.33.3/drivers/serial/Kconfig
> > +++ b_linux-2.6.33.3/drivers/serial/Kconfig
> > @@ -1031,6 +1031,23 @@ config SERIAL_CORE
> > config SERIAL_CORE_CONSOLE
> > bool
> >
> > +config SERIAL_CORE_CONSOLE_DETOUR
> > + bool "Support for serial console detour via printk"
> > + depends on SERIAL_CORE_CONSOLE
> > + default n
> > + ---help---
> > + If you do say Y here, the support for writing console messages via
>
> If you say Y here,
>
> > + printk is included into serial console code.
> > +
> > + The feature is usefull to catch all console log. In order to use this
>
> useful log messages.
>
> > + feature, you should specify kernel command line option "detour" or write a
> > + positive number into /proc/sys/kernel/console_detour. You can disable
> > + the feature on-line by writing zero into the proc file. By writing a
> > + negative value into the proc file, the feature is disabled permanently
> > + (until next boot).
> > +
> > + If unsure, say N.
> > +
>
> The kernel command line option needs to be added to Documentation/kernel-parameters.txt
> also, please.
>
> > config CONSOLE_POLL
> > bool
> >
> > diff --git a_linux-2.6.33.3/include/linux/console.h b_linux-2.6.33.3/include/linux/console.h
> > index dcca533..bc88030 100644
> > --- a_linux-2.6.33.3/include/linux/console.h
> > +++ b_linux-2.6.33.3/include/linux/console.h
> > @@ -108,6 +108,12 @@ struct console {
> > struct console *next;
> > };
> >
> > +extern int console_detour;
> > +extern void console_printk_detour(const unsigned char *, int);
>
> Please include parameter names in function prototype(s).
>
> > +
> > +struct ctl_table;
> > +int detour_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>
> ditto
>
> > +
> > extern int console_set_on_cmdline;
> >
> > extern int add_preferred_console(char *name, int idx, char *options);
>
>
> Looks interesting/useful to me. Thanks.
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
Good morning,
Thank you for the corrections and hints. i'll catchup with an update as
soon as i can.
regards, Samo
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Geert Uytterhoeven @ 2010-05-01 9:00 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux-embedded, linux kernel
In-Reply-To: <1272664980.10241.77.camel@itpsd6lap>
On Sat, May 1, 2010 at 00:03, Samo Pogacnik <samo_pogacnik@t-2.net> wrote:
> while i was searching for effective logging of complete console output
> produced by the kernel and user phase of the boot process, it turned out
> that only kernel messages imho get systematically cached and stored into
> log files (if needed). All userspace processes are on their own to use
> syslog, which is fine, but there are also many console messages
> reporting the boot status via init scripts, .... I came across the
> bootlogd daemo, which handles the job of redirecting console output into
> a log file, but i find it problematic to use especialy, when using
> initial ram disk image.
>
> So in short i came up with an idea to transform console writes into
> printks at appropriate code place of some console drivers (the patch
> includes code for VT console and SERIAL_CORE console drivers). Printks
> eventually reach console device avoiding the patched part of the console
> drivers.
What about catching /dev/console instead of VT console, SERIAL_CORE
console, ...?
Then it works with whatever console= parameter you specify.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Alan Cox @ 2010-05-01 11:04 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux-embedded, linux kernel
In-Reply-To: <1272664980.10241.77.camel@itpsd6lap>
> while i was searching for effective logging of complete console output
> produced by the kernel and user phase of the boot process, it turned out
> that only kernel messages imho get systematically cached and stored into
> log files (if needed). All userspace processes are on their own to use
> syslog, which is fine, but there are also many console messages
> reporting the boot status via init scripts, .... I came across the
> bootlogd daemo, which handles the job of redirecting console output into
> a log file, but i find it problematic to use especialy, when using
> initial ram disk image.
So you want to patch the kernel because you can't work out how to do this
in userspace ? The distributions seem to have no problem doing this in
user space that I can see. It doesn't seem to be a hard user space
problem, and there are a ton of things you want to do with this sort of
stuff (like network logging) that you can't do in kernel space.
> --- a_linux-2.6.33.3/drivers/char/vt.c
> +++ b_linux-2.6.33.3/drivers/char/vt.c
> @@ -2696,6 +2696,16 @@ static int con_write(struct tty_struct *tty, const unsigned char *buf, int count
> {
> int retval;
>
> +#ifdef CONFIG_VT_CONSOLE_DETOUR
> + if (console_detour) {
> + int idx = vt_console_driver.index - 1;
> +
> + if ((idx >= 0) && (idx == tty->index)) {
> + console_printk_detour(buf, count);
> + return count;
> + }
> + }
> +#endif
This requires you go around hacking up each device which is not a good
idea and becomes rapidly unmaintainable.
I suspect what you actually need for such logging might be to write a
very simple tty driver whose write method is implemented as printk. That
works in the general case and doesn't require hacking up the code
everywhere else.
However given your init stuff can trivially use openpty to set up a logged
console I am not sure I see the point in doing this in kernel in the
first place.
Alan
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-01 16:36 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-embedded, linux kernel
In-Reply-To: <z2r10f740e81005010200we353e3a4v90d9fe64620edb24@mail.gmail.com>
Dne 01.05.2010 (sob) ob 11:00 +0200 je Geert Uytterhoeven zapisal(a):
> On Sat, May 1, 2010 at 00:03, Samo Pogacnik <samo_pogacnik@t-2.net> wrote:
> > while i was searching for effective logging of complete console output
> > produced by the kernel and user phase of the boot process, it turned out
> > that only kernel messages imho get systematically cached and stored into
> > log files (if needed). All userspace processes are on their own to use
> > syslog, which is fine, but there are also many console messages
> > reporting the boot status via init scripts, .... I came across the
> > bootlogd daemo, which handles the job of redirecting console output into
> > a log file, but i find it problematic to use especialy, when using
> > initial ram disk image.
> >
> > So in short i came up with an idea to transform console writes into
> > printks at appropriate code place of some console drivers (the patch
> > includes code for VT console and SERIAL_CORE console drivers). Printks
> > eventually reach console device avoiding the patched part of the console
> > drivers.
>
> What about catching /dev/console instead of VT console, SERIAL_CORE
> console, ...?
> Then it works with whatever console= parameter you specify.
Could not agree more, but that was as close as i was able to detect the
common code and provide something that actually works. Maybe this is
already enough to cover all boot consoles?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
regards, Samo
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-01 18:48 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-embedded, linux kernel
In-Reply-To: <20100501120418.6fca2aad@lxorguk.ukuu.org.uk>
Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a):
> > while i was searching for effective logging of complete console output
> > produced by the kernel and user phase of the boot process, it turned out
> > that only kernel messages imho get systematically cached and stored into
> > log files (if needed). All userspace processes are on their own to use
> > syslog, which is fine, but there are also many console messages
> > reporting the boot status via init scripts, .... I came across the
> > bootlogd daemo, which handles the job of redirecting console output into
> > a log file, but i find it problematic to use especialy, when using
> > initial ram disk image.
>
> So you want to patch the kernel because you can't work out how to do this
> in userspace ? The distributions seem to have no problem doing this in
> user space that I can see. It doesn't seem to be a hard user space
> problem, and there are a ton of things you want to do with this sort of
> stuff (like network logging) that you can't do in kernel space.
The distros have no problem logging complete console output into log
files or over the network, because they simply do not do it at least for
the initrd part of the boot process (i'd be glad, if i'm wrong).
Anyway the proposed mechanism nicely bridges the gap between the kernel
boot start and the system logging daemon start-up. It also solves the
chicken and egg problem of how to log console if user space console
logging facility fails.
>
> > --- a_linux-2.6.33.3/drivers/char/vt.c
> > +++ b_linux-2.6.33.3/drivers/char/vt.c
> > @@ -2696,6 +2696,16 @@ static int con_write(struct tty_struct *tty, const unsigned char *buf, int count
> > {
> > int retval;
> >
> > +#ifdef CONFIG_VT_CONSOLE_DETOUR
> > + if (console_detour) {
> > + int idx = vt_console_driver.index - 1;
> > +
> > + if ((idx >= 0) && (idx == tty->index)) {
> > + console_printk_detour(buf, count);
> > + return count;
> > + }
> > + }
> > +#endif
>
> This requires you go around hacking up each device which is not a good
> idea and becomes rapidly unmaintainable.
Agree, it should have been done within a well defined code volume.
>
> I suspect what you actually need for such logging might be to write a
> very simple tty driver whose write method is implemented as printk. That
> works in the general case and doesn't require hacking up the code
> everywhere else.
Looks to me that some kernel code is welcome:)?
>
> However given your init stuff can trivially use openpty to set up a logged
> console I am not sure I see the point in doing this in kernel in the
> first place.
>
As said above, how to bridge kernel boot start and logging daemon
start-up without kernel help, especially when initrd is in the way? imho
it would be too complicated.
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
thanks for the reply, with best regards, Samo
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Alan Cox @ 2010-05-01 19:41 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux-embedded, linux kernel
In-Reply-To: <1272739689.2147.156.camel@itpsd6lap>
> The distros have no problem logging complete console output into log
> files or over the network, because they simply do not do it at least for
> the initrd part of the boot process (i'd be glad, if i'm wrong).
I'd have to double check - but its trivial to move the log if so.
> > I suspect what you actually need for such logging might be to write a
> > very simple tty driver whose write method is implemented as printk. That
> > works in the general case and doesn't require hacking up the code
> > everywhere else.
>
> Looks to me that some kernel code is welcome:)?
I really don't see the point but if you must do it then doing it as its
own driver would at least avoid making a mess in the rest of the kernel,
at which point it becomes less of a problem
> > However given your init stuff can trivially use openpty to set up a logged
> > console I am not sure I see the point in doing this in kernel in the
> > first place.
> >
>
> As said above, how to bridge kernel boot start and logging daemon
> start-up without kernel help, especially when initrd is in the way? imho
> it would be too complicated.
Put the logging start up in the initrd, its just a ramdisk its not
special in any way at all.
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-01 21:03 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-embedded, linux kernel
In-Reply-To: <1272731814.2147.26.camel@itpsd6lap>
Dne 01.05.2010 (sob) ob 18:36 +0200 je Samo Pogacnik zapisal(a):
> Dne 01.05.2010 (sob) ob 11:00 +0200 je Geert Uytterhoeven zapisal(a):
> > On Sat, May 1, 2010 at 00:03, Samo Pogacnik <samo_pogacnik@t-2.net> wrote:
> > > while i was searching for effective logging of complete console output
> > > produced by the kernel and user phase of the boot process, it turned out
> > > that only kernel messages imho get systematically cached and stored into
> > > log files (if needed). All userspace processes are on their own to use
> > > syslog, which is fine, but there are also many console messages
> > > reporting the boot status via init scripts, .... I came across the
> > > bootlogd daemo, which handles the job of redirecting console output into
> > > a log file, but i find it problematic to use especialy, when using
> > > initial ram disk image.
> > >
> > > So in short i came up with an idea to transform console writes into
> > > printks at appropriate code place of some console drivers (the patch
> > > includes code for VT console and SERIAL_CORE console drivers). Printks
> > > eventually reach console device avoiding the patched part of the console
> > > drivers.
> >
> > What about catching /dev/console instead of VT console, SERIAL_CORE
> > console, ...?
> > Then it works with whatever console= parameter you specify.
>
> Could not agree more, but that was as close as i was able to detect the
> common code and provide something that actually works. Maybe this is
> already enough to cover all boot consoles?
Silly me, i managed to miss the common console write method. I'll
provide the change, so there is not going to be any specifics for
different console types anymore.
>
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
>
> regards, Samo
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-01 22:23 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-embedded, linux kernel
In-Reply-To: <20100430154522.489df8bc.rdunlap@xenotime.net>
Dne 30.04.2010 (pet) ob 15:45 -0700 je Randy Dunlap zapisal(a):
> On Sat, 01 May 2010 00:03:00 +0200 Samo Pogacnik wrote:
>
> > Hi,
>
> > diff --git a_linux-2.6.33.3/drivers/char/Kconfig b_linux-2.6.33.3/drivers/char/Kconfig
> > index e023682..b5d0909 100644
> > --- a_linux-2.6.33.3/drivers/char/Kconfig
> > +++ b_linux-2.6.33.3/drivers/char/Kconfig
> > @@ -66,6 +66,23 @@ config VT_CONSOLE
> >
> > If unsure, say Y.
> >
> > +config VT_CONSOLE_DETOUR
> > + bool "Support for VT console detour via printk"
> > + depends on VT_CONSOLE
> > + default n
> > + ---help---
> > + If you do say Y here, the support for writing console messages via
>
> If you say Y here,
>
> > + printk is included into VT console code.
> > +
> > + The feature is usefull to catch all console log. In order to use this
>
> useful log messages.
>
> > + feature, you should specify kernel command line option "detour" or write a
> > + positive number into /proc/sys/kernel/console_detour. You can disable
> > + the feature on-line by writing zero into the proc file. By writing a
> > + negative value into the proc file, the feature is disabled permanently
> > + (until next boot).
> > +
> > + If unsure, say N.
> > +
> > config HW_CONSOLE
> > bool
> > depends on VT && !S390 && !UML
>
> > diff --git a_linux-2.6.33.3/drivers/serial/Kconfig b_linux-2.6.33.3/drivers/serial/Kconfig
> > index 9ff47db..20acfab 100644
> > --- a_linux-2.6.33.3/drivers/serial/Kconfig
> > +++ b_linux-2.6.33.3/drivers/serial/Kconfig
> > @@ -1031,6 +1031,23 @@ config SERIAL_CORE
> > config SERIAL_CORE_CONSOLE
> > bool
> >
> > +config SERIAL_CORE_CONSOLE_DETOUR
> > + bool "Support for serial console detour via printk"
> > + depends on SERIAL_CORE_CONSOLE
> > + default n
> > + ---help---
> > + If you do say Y here, the support for writing console messages via
>
> If you say Y here,
>
> > + printk is included into serial console code.
> > +
> > + The feature is usefull to catch all console log. In order to use this
>
> useful log messages.
>
> > + feature, you should specify kernel command line option "detour" or write a
> > + positive number into /proc/sys/kernel/console_detour. You can disable
> > + the feature on-line by writing zero into the proc file. By writing a
> > + negative value into the proc file, the feature is disabled permanently
> > + (until next boot).
> > +
> > + If unsure, say N.
> > +
>
> The kernel command line option needs to be added to Documentation/kernel-parameters.txt
> also, please.
>
> > config CONSOLE_POLL
> > bool
> >
> > diff --git a_linux-2.6.33.3/include/linux/console.h b_linux-2.6.33.3/include/linux/console.h
> > index dcca533..bc88030 100644
> > --- a_linux-2.6.33.3/include/linux/console.h
> > +++ b_linux-2.6.33.3/include/linux/console.h
> > @@ -108,6 +108,12 @@ struct console {
> > struct console *next;
> > };
> >
> > +extern int console_detour;
> > +extern void console_printk_detour(const unsigned char *, int);
>
> Please include parameter names in function prototype(s).
>
> > +
> > +struct ctl_table;
> > +int detour_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>
> ditto
>
> > +
> > extern int console_set_on_cmdline;
> >
> > extern int add_preferred_console(char *name, int idx, char *options);
>
>
> Looks interesting/useful to me. Thanks.
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
Hi,
Here is the updated patch providing your hints and generalized for any
console type.
regards, Samo
---
Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net>
diff --git a_linux-2.6.33.3/Documentation/kernel-parameters.txt b_linux-2.6.33.3/Documentation/kernel-parameters.txt
index e2c7487..ab0072c 100644
--- a_linux-2.6.33.3/Documentation/kernel-parameters.txt
+++ b_linux-2.6.33.3/Documentation/kernel-parameters.txt
@@ -628,6 +628,8 @@ and is between 256 and 4096 characters. It is defined in the file
Defaults to the default architecture's huge page size
if not specified.
+ detour [KNL] Enable console logging detour via printk.
+
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
diff --git a_linux-2.6.33.3/drivers/char/Kconfig b_linux-2.6.33.3/drivers/char/Kconfig
index e023682..43c552e 100644
--- a_linux-2.6.33.3/drivers/char/Kconfig
+++ b_linux-2.6.33.3/drivers/char/Kconfig
@@ -88,6 +88,22 @@ config VT_HW_CONSOLE_BINDING
information. For framebuffer console users, please refer to
<file:Documentation/fb/fbcon.txt>.
+config CONSOLE_DETOUR
+ bool "Support for console detour via printk"
+ default n
+ ---help---
+ If you say Y here, the support for writing console messages via
+ printk is included into the console code.
+
+ The feature is useful to catch all console log messages.
+ In order to use this feature, you should specify kernel command line
+ option "detour" or write a positive number into
+ /proc/sys/kernel/console_detour. You can disable the feature on-line
+ by writing zero into the proc file. By writing a negative value into
+ the proc file, the feature is disabled permanently (until next boot).
+
+ If unsure, say N.
+
config DEVKMEM
bool "/dev/kmem virtual device support"
default y
diff --git a_linux-2.6.33.3/drivers/char/tty_io.c b_linux-2.6.33.3/drivers/char/tty_io.c
index 76253cf..f77de34 100644
--- a_linux-2.6.33.3/drivers/char/tty_io.c
+++ b_linux-2.6.33.3/drivers/char/tty_io.c
@@ -1087,6 +1087,13 @@ ssize_t redirected_tty_write(struct file *file, const char __user *buf,
}
spin_unlock(&redirect_lock);
+#ifdef CONFIG_CONSOLE_DETOUR
+ if (console_detour) {
+ console_printk_detour(buf, count);
+ if (!p)
+ return count;
+ }
+#endif
if (p) {
ssize_t res;
res = vfs_write(p, buf, count, &p->f_pos);
diff --git a_linux-2.6.33.3/include/linux/console.h b_linux-2.6.33.3/include/linux/console.h
index dcca533..354a7a8 100644
--- a_linux-2.6.33.3/include/linux/console.h
+++ b_linux-2.6.33.3/include/linux/console.h
@@ -108,6 +108,13 @@ struct console {
struct console *next;
};
+extern int console_detour;
+extern void console_printk_detour(const unsigned char *buf, int count);
+
+struct ctl_table;
+int detour_sysctl_handler(struct ctl_table *table, int write,
+ void __user *buffer, size_t *length, loff_t *ppos);
+
extern int console_set_on_cmdline;
extern int add_preferred_console(char *name, int idx, char *options);
diff --git a_linux-2.6.33.3/init/main.c b_linux-2.6.33.3/init/main.c
index 512ba15..add9e95 100644
--- a_linux-2.6.33.3/init/main.c
+++ b_linux-2.6.33.3/init/main.c
@@ -25,6 +25,7 @@
#include <linux/bootmem.h>
#include <linux/acpi.h>
#include <linux/tty.h>
+#include <linux/console.h>
#include <linux/gfp.h>
#include <linux/percpu.h>
#include <linux/kmod.h>
@@ -249,6 +250,14 @@ static int __init loglevel(char *str)
early_param("loglevel", loglevel);
+static int __init detour(char *str)
+{
+ console_detour = 1;
+ return 0;
+}
+
+early_param("detour", detour);
+
/*
* Unknown boot options get handed to init, unless they look like
* unused parameters (modprobe will find them in /proc/cmdline).
diff --git a_linux-2.6.33.3/kernel/printk.c b_linux-2.6.33.3/kernel/printk.c
index 1751c45..953c6ea 100644
--- a_linux-2.6.33.3/kernel/printk.c
+++ b_linux-2.6.33.3/kernel/printk.c
@@ -1368,6 +1368,51 @@ static int __init disable_boot_consoles(void)
}
late_initcall(disable_boot_consoles);
+/*
+ * This option can be enabled with kernel command line option "detour" or
+ * through a proc file (/proc/sys/kernel/console_detour). It enables console
+ * logging through printk, if supported by enabled console.
+ */
+int console_detour;
+EXPORT_SYMBOL(console_detour);
+
+#define DETOUR_STR_SIZE 512
+void console_printk_detour(const unsigned char *buf, int count)
+{
+ char tmp[DETOUR_STR_SIZE + 1];
+
+ do {
+ if (count > DETOUR_STR_SIZE) {
+ memcpy(tmp, buf, DETOUR_STR_SIZE);
+ tmp[DETOUR_STR_SIZE] = '\0';
+ } else {
+ memcpy(tmp, buf, count);
+ tmp[count] = '\0';
+ }
+ count -= DETOUR_STR_SIZE;
+ printk(KERN_INFO "%s", tmp);
+ } while (count > 0);
+}
+EXPORT_SYMBOL(console_printk_detour);
+
+int detour_sysctl_handler(struct ctl_table *table, int write,
+ void __user *buffer, size_t *length, loff_t *ppos)
+{
+ static int disable_forever;
+
+ proc_dointvec(table, write, buffer, length, ppos);
+ if (write) {
+ if ((console_detour < 0) || (disable_forever != 0)) {
+ disable_forever = 1;
+ console_detour = 0;
+ return 0;
+ }
+ if (console_detour > 1)
+ console_detour = 1;
+ }
+ return 0;
+}
+
#if defined CONFIG_PRINTK
/*
diff --git a_linux-2.6.33.3/kernel/sysctl.c b_linux-2.6.33.3/kernel/sysctl.c
index 8a68b24..ab644cb 100644
--- a_linux-2.6.33.3/kernel/sysctl.c
+++ b_linux-2.6.33.3/kernel/sysctl.c
@@ -50,6 +50,7 @@
#include <linux/ftrace.h>
#include <linux/slow-work.h>
#include <linux/perf_event.h>
+#include <linux/console.h>
#include <asm/uaccess.h>
#include <asm/processor.h>
@@ -936,6 +937,13 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
#endif
+ {
+ .procname = "console_detour",
+ .data = &console_detour,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &detour_sysctl_handler,
+ },
/*
* NOTE: do not add new entries to this table unless you have read
* Documentation/sysctl/ctl_unnumbered.txt
^ permalink raw reply related
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-01 22:45 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-embedded, linux kernel
In-Reply-To: <20100501204131.4c7aeae4@lxorguk.ukuu.org.uk>
Dne 01.05.2010 (sob) ob 20:41 +0100 je Alan Cox zapisal(a):
> > The distros have no problem logging complete console output into log
> > files or over the network, because they simply do not do it at least for
> > the initrd part of the boot process (i'd be glad, if i'm wrong).
>
> I'd have to double check - but its trivial to move the log if so.
>
> > > I suspect what you actually need for such logging might be to write a
> > > very simple tty driver whose write method is implemented as printk. That
> > > works in the general case and doesn't require hacking up the code
> > > everywhere else.
> >
> > Looks to me that some kernel code is welcome:)?
>
> I really don't see the point but if you must do it then doing it as its
> own driver would at least avoid making a mess in the rest of the kernel,
> at which point it becomes less of a problem
>
> > > However given your init stuff can trivially use openpty to set up a logged
> > > console I am not sure I see the point in doing this in kernel in the
> > > first place.
> > >
> >
> > As said above, how to bridge kernel boot start and logging daemon
> > start-up without kernel help, especially when initrd is in the way? imho
> > it would be too complicated.
>
> Put the logging start up in the initrd, its just a ramdisk its not
> special in any way at all.
I understand and can agree with everything you said, however providing
an additional mechanism might not hurt. Funny enough by generalizing the
patch for any console type, the essential code change is made at the
same place where initial console redirection mechanism has been
implemented. And again, console redirection can not log anything that
has been output to console prior to redirection activation.
regards, Samo
^ permalink raw reply
* Can I manage/modify console baud rates from userspace?
From: Paul Smith @ 2010-05-02 0:02 UTC (permalink / raw)
To: linux-embedded
Hi all. I need some advice on an issue that just cropped up. We have a
Linux embedded image (current kernel is 2.6.31-based) that we are
booting up on blade systems using PXE to obtain the kernel image, the
kernel boot line parameters, and an initrd from a server.
On these systems we REALLY need to be able to watch the console, even
after deployment into the field (e.g., not just during
development/internally).
We currently run this image on various hardware platforms, one of which
uses serial-over-LAN, where the console is connected to a dedicated vlan
from the blade to the chassis management module, which you can ssh into
and from there connect to the console on any blade in the chassis. The
vlan configuration on these blades doesn't support any baud rate over
19200, so in order to get this working we use the PXE configuration file
to add "console=ttyS1,19200" to the kernel boot line. Works great!
Here's the problem. The vendor has released a new version of the blade
hardware for this platform, and while the old hardware didn't support
any baud rate above 19200 for serial-over-LAN, the new hardware doesn't
support any baud rate at 19200 or below, so there's no single baud rate
that will work for both types of blades.
These blades are interchangeable in the chassis and since the current
ones are end-of-life we have to start to support the new blade, and we
have to support combinations of new and old blades in the same chassis
(due to replacements).
So I _have_ to find a way to get the console working in this
configuration. Even if I lose the early boot messages but then managed
to configure the console properly from userspace after the kernel
booted, that would be less than ideal but at least it would be progress.
Is there some way to do this? Is there some way in the kernel to handle
this kind of situation?
I've looked at setserial and it supports a baud_base parameter but that
doesn't appear to be what I want (I tried it anyway: changing it didn't
work, my console output was still screwed up).
Trying to do something like creating customized PXE configs on the
server based on the MAC addresses of the blades that are "new" (or old)
would be an absolute nightmare as people swap blades between chassis,
add new ones, etc. all the time.
Please help me find a better way... :-(
^ permalink raw reply
* Re: Can I manage/modify console baud rates from userspace?
From: Marco Stornelli @ 2010-05-02 9:58 UTC (permalink / raw)
To: paul; +Cc: linux-embedded
In-Reply-To: <1272758524.27961.1114.camel@homebase>
02/05/2010 02:02, Paul Smith wrote:
> I've looked at setserial and it supports a baud_base parameter but that
> doesn't appear to be what I want (I tried it anyway: changing it didn't
> work, my console output was still screwed up).
>
> Trying to do something like creating customized PXE configs on the
> server based on the MAC addresses of the blades that are "new" (or old)
> would be an absolute nightmare as people swap blades between chassis,
> add new ones, etc. all the time.
>
>
> Please help me find a better way... :-(
>
It's strange that it's not possible to change the baud rate, but I'm not
an expert of tty layer. A naive implementation could be patch the kernel
to choose a well-known baud rate for your hw reading a revision register
or something like that.
Marco
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Marco Stornelli @ 2010-05-02 9:58 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: Alan Cox, linux-embedded, linux kernel
In-Reply-To: <1272739689.2147.156.camel@itpsd6lap>
01/05/2010 20:48, Samo Pogacnik wrote:
> Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a):
>>> while i was searching for effective logging of complete console output
>>> produced by the kernel and user phase of the boot process, it turned out
>>> that only kernel messages imho get systematically cached and stored into
>>> log files (if needed). All userspace processes are on their own to use
>>> syslog, which is fine, but there are also many console messages
>>> reporting the boot status via init scripts, .... I came across the
>>> bootlogd daemo, which handles the job of redirecting console output into
>>> a log file, but i find it problematic to use especialy, when using
>>> initial ram disk image.
>>
>> So you want to patch the kernel because you can't work out how to do this
>> in userspace ? The distributions seem to have no problem doing this in
>> user space that I can see. It doesn't seem to be a hard user space
>> problem, and there are a ton of things you want to do with this sort of
>> stuff (like network logging) that you can't do in kernel space.
>
> The distros have no problem logging complete console output into log
> files or over the network, because they simply do not do it at least for
> the initrd part of the boot process (i'd be glad, if i'm wrong).
Mmm...It's an interesting problem. I see in my distro (openSuse) a
script called boot.klog that it seems to perform that (even initrd
part). In the file boot.msg I can see the initial prints of the kernel
and user space scripts.
Marco
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Samo Pogacnik @ 2010-05-02 13:29 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Alan Cox, linux-embedded, linux kernel
In-Reply-To: <4BDD4CD7.2060205@gmail.com>
Dne 02.05.2010 (ned) ob 11:58 +0200 je Marco Stornelli zapisal(a):
> 01/05/2010 20:48, Samo Pogacnik wrote:
> > Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a):
> >>> while i was searching for effective logging of complete console output
> >>> produced by the kernel and user phase of the boot process, it turned out
> >>> that only kernel messages imho get systematically cached and stored into
> >>> log files (if needed). All userspace processes are on their own to use
> >>> syslog, which is fine, but there are also many console messages
> >>> reporting the boot status via init scripts, .... I came across the
> >>> bootlogd daemo, which handles the job of redirecting console output into
> >>> a log file, but i find it problematic to use especialy, when using
> >>> initial ram disk image.
> >>
> >> So you want to patch the kernel because you can't work out how to do this
> >> in userspace ? The distributions seem to have no problem doing this in
> >> user space that I can see. It doesn't seem to be a hard user space
> >> problem, and there are a ton of things you want to do with this sort of
> >> stuff (like network logging) that you can't do in kernel space.
> >
> > The distros have no problem logging complete console output into log
> > files or over the network, because they simply do not do it at least for
> > the initrd part of the boot process (i'd be glad, if i'm wrong).
>
> Mmm...It's an interesting problem. I see in my distro (openSuse) a
> script called boot.klog that it seems to perform that (even initrd
> part). In the file boot.msg I can see the initial prints of the kernel
> and user space scripts.
>
Thanks for the info.
Is this boot.klog script from the initrd image or from the real rootfs?
As you can see, i am still suspicious about the initrd part user console
messages:)
Samo
^ permalink raw reply
* Re: Can I manage/modify console baud rates from userspace?
From: Paul Smith @ 2010-05-02 16:14 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <4BDD4CC7.3050507@gmail.com>
On Sun, 2010-05-02 at 11:58 +0200, Marco Stornelli wrote:
> 02/05/2010 02:02, Paul Smith wrote:
> > I've looked at setserial and it supports a baud_base parameter but that
> > doesn't appear to be what I want (I tried it anyway: changing it didn't
> > work, my console output was still screwed up).
> >
> > Trying to do something like creating customized PXE configs on the
> > server based on the MAC addresses of the blades that are "new" (or old)
> > would be an absolute nightmare as people swap blades between chassis,
> > add new ones, etc. all the time.
> >
> >
> > Please help me find a better way... :-(
> >
>
> It's strange that it's not possible to change the baud rate, but I'm not
> an expert of tty layer. A naive implementation could be patch the kernel
> to choose a well-known baud rate for your hw reading a revision register
> or something like that.
I guess; I'd hate to have to modify the kernel like that though. Plus,
as far as I'm aware at the moment the only way to tell these blades
apart is through querying IPMI which would be a serious bummer to try to
do via the kernel, I believe. Maybe there's some other way to do it
that's simpler.
Still hoping someone will say "all you have to do is XYZZY..." Anyone?
^ permalink raw reply
* Re: Can I manage/modify console baud rates from userspace?
From: Sam Ravnborg @ 2010-05-02 20:25 UTC (permalink / raw)
To: Paul Smith, Alan Cox; +Cc: linux-embedded
In-Reply-To: <1272816895.27961.1131.camel@homebase>
On Sun, May 02, 2010 at 12:14:55PM -0400, Paul Smith wrote:
> On Sun, 2010-05-02 at 11:58 +0200, Marco Stornelli wrote:
> > 02/05/2010 02:02, Paul Smith wrote:
> > > I've looked at setserial and it supports a baud_base parameter but that
> > > doesn't appear to be what I want (I tried it anyway: changing it didn't
> > > work, my console output was still screwed up).
> > >
> > > Trying to do something like creating customized PXE configs on the
> > > server based on the MAC addresses of the blades that are "new" (or old)
> > > would be an absolute nightmare as people swap blades between chassis,
> > > add new ones, etc. all the time.
> > >
> > >
> > > Please help me find a better way... :-(
> > >
> >
> > It's strange that it's not possible to change the baud rate, but I'm not
> > an expert of tty layer. A naive implementation could be patch the kernel
> > to choose a well-known baud rate for your hw reading a revision register
> > or something like that.
>
> I guess; I'd hate to have to modify the kernel like that though. Plus,
> as far as I'm aware at the moment the only way to tell these blades
> apart is through querying IPMI which would be a serious bummer to try to
> do via the kernel, I believe. Maybe there's some other way to do it
> that's simpler.
>
> Still hoping someone will say "all you have to do is XYZZY..." Anyone?
I would suggest asking Alan Cox - he if anyone would know.
I lost the original mail and context above is missing some details.
Anyway added to this mail.
Sam
^ permalink raw reply
* Re: [PATCH] console logging detour via printk
From: Marco Stornelli @ 2010-05-03 17:05 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: Alan Cox, linux-embedded, linux kernel
In-Reply-To: <1272806987.2155.34.camel@itpsd6lap>
Il 02/05/2010 15:29, Samo Pogacnik ha scritto:
> Dne 02.05.2010 (ned) ob 11:58 +0200 je Marco Stornelli zapisal(a):
>> 01/05/2010 20:48, Samo Pogacnik wrote:
>>
>> Mmm...It's an interesting problem. I see in my distro (openSuse) a
>> script called boot.klog that it seems to perform that (even initrd
>> part). In the file boot.msg I can see the initial prints of the kernel
>> and user space scripts.
>>
> Thanks for the info.
> Is this boot.klog script from the initrd image or from the real rootfs?
> As you can see, i am still suspicious about the initrd part user console
> messages:)
>
> Samo
>
>
In the initrd there's the script blogd.sh:
if test -z "$fboot" -a -z "$quiet" -a -z "$REDIRECT" ; then
REDIRECT=$(showconsole 2>/dev/null)
if test -n "$REDIRECT" ; then
if test "$devpts" != "yes" ; then
mount -t devpts devpts /dev/pts
devpts=yes
fi
> /dev/shm/initrd.msg
ln -sf /dev/shm/initrd.msg /var/log/boot.msg
mkdir -p /var/run
/sbin/blogd $REDIRECT
fi
fi
And in the rootfs the boot.klog script:
# Read all kernel messages generated until now and put them in one file.
test -s /var/log/boot.msg && mv -f /var/log/boot.msg /var/log/boot.omsg
echo Creating /var/log/boot.msg
if test -x /sbin/klogd ; then
# klogd syncs out the file
/sbin/klogd -s -o -n -f /var/log/boot.msg
test -s /var/log/boot.msg
rc_status -v1 -r
elif test -x /bin/dmesg ; then
/bin/dmesg > /var/log/boot.msg
/bin/sync
test -s /var/log/boot.msg
rc_status -v1 -r
fi
if test -e /dev/shm/initrd.msg ; then
cat /dev/shm/initrd.msg >> /var/log/boot.msg
rm -f /dev/shm/initrd.msg
fi
[ --- cut here --- ]
Regards,
Marco
^ permalink raw reply
* Re: Can I manage/modify console baud rates from userspace?
From: Paul Smith @ 2010-05-03 17:28 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Alan Cox, linux-embedded
In-Reply-To: <20100502202534.GA29535@merkur.ravnborg.org>
On Sun, 2010-05-02 at 22:25 +0200, Sam Ravnborg wrote:
> I would suggest asking Alan Cox - he if anyone would know.
> I lost the original mail and context above is missing some details.
> Anyway added to this mail.
Thanks Sam. Alan, hope you don't mind a direct email. I'll cut down
the original request to just (I hope) the important details.
I have an environment in which a number of (Intel-based) blades in one
or more blade chassis boot from a host using PXE to download a Linux
kernel (2.6.31-based ATM) and a ramdisk root partition. These blades
provide access to the console via serial-over-LAN, where the chassis
provides a special vlan connection to the blades' ttyS1 port. You can
then connect to the chassis management module via SSH, and from there
connect to the console of any of the blades.
We require this capability in our deployed systems, not just during
development, so I need to make sure this is working at all times and
that it's easy to configure and maintain in the field.
Today, all the blades we ship use a maximum baud rate of 19200 so in my
PXE config, I have "console=ttyS1,19200" added to the kernel boot line.
Works great.
The vendor is providing a newer version of these blades and the current
version is end-of-lifed. The new blades are drop-in replaceable,
individually, with the current blades, which is nice. Unfortunately
these new blades do not support any overlapping baud rate with the old
blades, so there's no single value I can provide in the PXE
configuration on my host that will work with all blades in a
heterogeneous blade deployment.
So I'm stuck here and don't have a good idea how to move forward. I
tried using setserial to modify the baud rate (it supports a parameter
baud_base which didn't seem like it would do what I wanted--and it
didn't) but no joy.
Trying to customize the PXE config would be virtually impossible: we'd
have to map all the MAC addresses and figure out which ones were for
newer blades, and maintain that mapping as blades were swapped in and
out and even moved between chassis or between slots in the same chassis.
A nightmare!
Is there some other way to modify the baud rate of the console device
from userspace once I figure out the right one? It would definitely be
less than ideal since we'd lose all the boot output, except what we can
get from dmesg _if_ the system boots, but it would be something.
Any other thoughts or ideas?
Thanks for reading!
^ permalink raw reply
* Re: Can I manage/modify console baud rates from userspace?
From: Alan Cox @ 2010-05-03 19:17 UTC (permalink / raw)
To: paul; +Cc: Sam Ravnborg, linux-embedded
In-Reply-To: <1272907707.31303.23.camel@psmith-ubeta.netezza.com>
> Is there some other way to modify the baud rate of the console device
> from userspace once I figure out the right one? It would definitely be
> less than ideal since we'd lose all the boot output, except what we can
> get from dmesg _if_ the system boots, but it would be something.
stty 57600 < /dev/ttyS1
etc. The console baud rate and settings should behave exactly as any
other serial port if set from user space.
> Any other thoughts or ideas?
If you don't mind doing some small private kernel tweaks then I guess you
could set the default console baud rate based on the dmi strings which
would hopefully differ between the blade types.
Alan
^ permalink raw reply
* [PATCH] ARM: fix inbalance of hardirqs trace before return to user or exception
From: tom.leiming @ 2010-05-09 3:56 UTC (permalink / raw)
To: linux
Cc: linux-arm-kernel, linux-arm-kernel, linux-embedded, a.p.zijlstra,
linux-kernel, Ming Lei
From: Ming Lei <tom.leiming@gmail.com>
This patch introduces macro of trace_ret_hardirqs_on, which will
call asm_trace_hardirqs_on if I flag in the stored CPSR is zero.
The patch adds trace_ret_hardirqs_on before returning to user
or exception mode once disable_irq was called explicitly, which does
fix the inbalance of hardirqs trace and make lockdep happy. The patch
does fix this kind of lockdep warning below:
PU: Testing write buffer coherency: ok
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
Modules linked in:
[<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
[<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
[<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
[<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
[<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
[<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
[<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
[<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
[<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1c ]---
possible reason: unannotated irqs-on.
irq event stamp: 3
hardirqs last enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
softirqs last enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
softirqs last disabled at (0): [<(null)>] (null)
devtmpfs: initialized
The patch refers to implementation on x86, suggested by Peter.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/kernel/entry-armv.S | 14 ++++++++++----
arch/arm/kernel/entry-common.S | 8 ++++++++
| 9 +++++++++
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index e6a0fb0..47abf42 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -210,6 +210,13 @@ __dabt_svc:
@ restore SPSR and restart the instruction
@
ldr r2, [sp, #S_PSR]
+
+ @
+ @trace hardirqs on if hardirq will be enabled before
+ @returning from exception
+ @
+ trace_ret_hardirqs_on r2
+
svc_exit r2 @ return from exception
UNWIND(.fnend )
ENDPROC(__dabt_svc)
@@ -235,10 +242,7 @@ __irq_svc:
blne svc_preempt
#endif
ldr r4, [sp, #S_PSR] @ irqs are already disabled
-#ifdef CONFIG_TRACE_IRQFLAGS
- tst r4, #PSR_I_BIT
- bleq trace_hardirqs_on
-#endif
+ trace_ret_hardirqs_on r4
svc_exit r4 @ return from exception
UNWIND(.fnend )
ENDPROC(__irq_svc)
@@ -297,6 +301,7 @@ __und_svc:
@ restore SPSR and restart the instruction
@
ldr r2, [sp, #S_PSR] @ Get SVC cpsr
+ trace_ret_hardirqs_on r2
svc_exit r2 @ return from exception
UNWIND(.fnend )
ENDPROC(__und_svc)
@@ -333,6 +338,7 @@ __pabt_svc:
@ restore SPSR and restart the instruction
@
ldr r2, [sp, #S_PSR]
+ trace_ret_hardirqs_on r2
svc_exit r2 @ return from exception
UNWIND(.fnend )
ENDPROC(__pabt_svc)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 2c1db77..282576f 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -66,6 +66,14 @@ no_work_pending:
/* perform architecture specific actions before user return */
arch_ret_to_user r1, lr
+ @
+ @trace hardirqs on if hardirq will be enabled before
+ @returning to user
+ @
+#ifdef CONFIG_TRACE_IRQFLAGS
+ ldr r1, [sp, #S_PSR] @ get calling cpsr
+ trace_ret_hardirqs_on r1
+#endif
restore_user_regs fast = 0, offset = 0
ENDPROC(ret_to_user)
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index d93f976..85f4b5b 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -30,6 +30,15 @@
#error "Please fix"
#endif
+ .macro trace_ret_hardirqs_on, rspsr
+#ifdef CONFIG_TRACE_IRQFLAGS
+ tst \rspsr, #PSR_I_BIT
+ bne 1f
+ asm_trace_hardirqs_on
+1:
+#endif
+ .endm
+
.macro zero_fp
#ifdef CONFIG_FRAME_POINTER
mov fp, #0
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] ARM: fix inbalance of hardirqs trace before return to user or exception
From: Russell King - ARM Linux @ 2010-05-09 9:18 UTC (permalink / raw)
To: tom.leiming; +Cc: linux-arm-kernel, linux-embedded, a.p.zijlstra, linux-kernel
In-Reply-To: <1273377379-18078-1-git-send-email-tom.leiming@gmail.com>
On Sun, May 09, 2010 at 11:56:19AM +0800, tom.leiming@gmail.com wrote:
> From: Ming Lei <tom.leiming@gmail.com>
>
> This patch introduces macro of trace_ret_hardirqs_on, which will
> call asm_trace_hardirqs_on if I flag in the stored CPSR is zero.
>
> The patch adds trace_ret_hardirqs_on before returning to user
> or exception mode once disable_irq was called explicitly, which does
> fix the inbalance of hardirqs trace and make lockdep happy. The patch
> does fix this kind of lockdep warning below:
I'm not convinced that this is required in all the places you're adding
it. Eg, in the return-to-user case, userspace _always_ has IRQs
enabled, and when we enter kernel space from the exception handler, we
always enable IRQs. Returning from any syscall with IRQs disabled is a
bug, and so that _should_ produce a warning.
In fact, returning to user mode with IRQs disabled in _any_ case is a
bug.
Please provide your reasoning for adding this to every path.
Finally, using asm_trace_hardirqs_on is extremely expensive, and in
many cases the register saving is completely wasteful. That's why
places were doing this:
#ifdef CONFIG_TRACE_IRQFLAGS
tst r4, #PSR_I_BIT
bleq trace_hardirqs_on
#endif
which is much more efficient.
^ permalink raw reply
* Re: [PATCH] ARM: fix inbalance of hardirqs trace before return to user or exception
From: Ming Lei @ 2010-05-09 13:07 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arm-kernel, linux-embedded, a.p.zijlstra, linux-kernel
In-Reply-To: <20100509091856.GA29763@n2100.arm.linux.org.uk>
2010/5/9 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sun, May 09, 2010 at 11:56:19AM +0800, tom.leiming@gmail.com wrote:
>> From: Ming Lei <tom.leiming@gmail.com>
>>
>> This patch introduces macro of trace_ret_hardirqs_on, which will
>> call asm_trace_hardirqs_on if I flag in the stored CPSR is zero.
>>
>> The patch adds trace_ret_hardirqs_on before returning to user
>> or exception mode once disable_irq was called explicitly, which does
>> fix the inbalance of hardirqs trace and make lockdep happy. The patch
>> does fix this kind of lockdep warning below:
>
> I'm not convinced that this is required in all the places you're adding
> it. Eg, in the return-to-user case, userspace _always_ has IRQs
> enabled, and when we enter kernel space from the exception handler, we
> always enable IRQs. Returning from any syscall with IRQs disabled is a
> bug, and so that _should_ produce a warning.
>
> In fact, returning to user mode with IRQs disabled in _any_ case is a
> bug.
The patch only adds hardirqs on event to make lockdep see it.
Maybe in this paths, we should not trace the hardirqs off event, then we
will not need to add the hardirqs on event before return to user. If
you agree, I'll
write another patch to do it.
>
> Please provide your reasoning for adding this to every path.
The patch adds this in places which disable_irq is called before returning to
user or kernel mode from sys-call or exception. This can keep hardirqs trace
balance to remove lockdep warning of "unannotated irqs-on" since disable_irq
may call trace_hardirqs_off to trace hardirqs off event and lockdep
will see it.
If lockdep warning is produced, lockdep does not work afterwards. It is the
purpose of the patch.
>
> Finally, using asm_trace_hardirqs_on is extremely expensive, and in
> many cases the register saving is completely wasteful. That's why
> places were doing this:
>
> #ifdef CONFIG_TRACE_IRQFLAGS
> tst r4, #PSR_I_BIT
> bleq trace_hardirqs_on
> #endif
>
> which is much more efficient.
Yes, I'll use the efficient way in v2 of the patch.
--
Lei Ming
^ permalink raw reply
* [PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
From: tom.leiming @ 2010-05-10 14:27 UTC (permalink / raw)
To: linux
Cc: linux-arm-kernel, linux-embedded, a.p.zijlstra, linux-kernel,
Ming Lei
From: Ming Lei <tom.leiming@gmail.com>
This patch fixes the 'unannotated irqs-on' lockdep warning below:
CPU: Testing write buffer coherency: ok
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
Modules linked in:
[<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
[<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
[<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
[<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
[<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
[<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
[<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
[<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
[<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1c ]---
possible reason: unannotated irqs-on.
irq event stamp: 3
hardirqs last enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
softirqs last enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
softirqs last disabled at (0): [<(null)>] (null)
This patch introduces macro of trace_ret_hardirqs_on, which will
call trace_hardirqs_on if I flag in the stored CPSR is zero.
In the path of returning to user-space, the patch replaces disable_irq
with disable_irq_notrace in ret_to_user to avoid the 'unannotated irqs-on'
lockdep warning since hardirqs is always enabled before returning to user.
In the path of returning to kernel-space, the patch still replaces
disable_irq with disable_irq_notrace in __xxx_svc handler and adds
trace_hardirqs_on before calling svc_exit to trace the possible hardirqs on
event for avoiding the possible 'unannotated irqs-on' lockdep warning.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/kernel/entry-armv.S | 31 +++++++++++++++++--------------
arch/arm/kernel/entry-common.S | 2 +-
| 7 +++++++
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index e6a0fb0..7202adf 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -204,13 +204,15 @@ __dabt_svc:
@
@ IRQs off again before pulling preserved data off the stack
@
- disable_irq
+ disable_irq_notrace
@
@ restore SPSR and restart the instruction
+ @ trace possible hardirqs on event before returning
@
- ldr r2, [sp, #S_PSR]
- svc_exit r2 @ return from exception
+ ldr r4, [sp, #S_PSR]
+ trace_ret_hardirqs_on r4
+ svc_exit r4 @ return from exception
UNWIND(.fnend )
ENDPROC(__dabt_svc)
@@ -235,10 +237,7 @@ __irq_svc:
blne svc_preempt
#endif
ldr r4, [sp, #S_PSR] @ irqs are already disabled
-#ifdef CONFIG_TRACE_IRQFLAGS
- tst r4, #PSR_I_BIT
- bleq trace_hardirqs_on
-#endif
+ trace_ret_hardirqs_on r4
svc_exit r4 @ return from exception
UNWIND(.fnend )
ENDPROC(__irq_svc)
@@ -291,13 +290,15 @@ __und_svc:
@
@ IRQs off again before pulling preserved data off the stack
@
-1: disable_irq
+1: disable_irq_notrace
@
@ restore SPSR and restart the instruction
+ @ trace possible hardirqs on event before returning
@
- ldr r2, [sp, #S_PSR] @ Get SVC cpsr
- svc_exit r2 @ return from exception
+ ldr r4, [sp, #S_PSR] @ Get SVC cpsr
+ trace_ret_hardirqs_on r4
+ svc_exit r4 @ return from exception
UNWIND(.fnend )
ENDPROC(__und_svc)
@@ -327,13 +328,15 @@ __pabt_svc:
@
@ IRQs off again before pulling preserved data off the stack
@
- disable_irq
+ disable_irq_notrace
@
@ restore SPSR and restart the instruction
- @
- ldr r2, [sp, #S_PSR]
- svc_exit r2 @ return from exception
+ @ trace possible hardirqs on event before returning
+ @
+ ldr r4, [sp, #S_PSR]
+ trace_ret_hardirqs_on r4
+ svc_exit r4 @ return from exception
UNWIND(.fnend )
ENDPROC(__pabt_svc)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 2c1db77..ed471a7 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -58,7 +58,7 @@ work_resched:
*/
ENTRY(ret_to_user)
ret_slow_syscall:
- disable_irq @ disable interrupts
+ disable_irq_notrace @ disable interrupts
ldr r1, [tsk, #TI_FLAGS]
tst r1, #_TIF_WORK_MASK
bne work_pending
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index d93f976..ac51ce3 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -30,6 +30,13 @@
#error "Please fix"
#endif
+ .macro trace_ret_hardirqs_on, rspsr
+#ifdef CONFIG_TRACE_IRQFLAGS
+ tst \rspsr, #PSR_I_BIT
+ bleq trace_hardirqs_on
+#endif
+ .endm
+
.macro zero_fp
#ifdef CONFIG_FRAME_POINTER
mov fp, #0
--
1.6.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox