Re: [PATCH] CON_CONSDEV bit not set correctly on last console
On Wed, Apr 06, 2005 at 03:53:17PM -0700, Andrew Morton wrote: | Greg Edwards <[EMAIL PROTECTED]> wrote: | > | > According to include/linux/console.h, CON_CONSDEV flag should be set on | > the last console specified on the boot command line: | > | > 86 #define CON_PRINTBUFFER (1) | > 87 #define CON_CONSDEV (2) /* Last on the command line */ | > 88 #define CON_ENABLED (4) | > 89 #define CON_BOOT(8) | > | > This does not currently happen if there is more than one console specified | > on the boot commandline. Instead, it gets set on the first console on the | > command line. This can cause problems for things like kdb that look for | > the CON_CONSDEV flag to see if the console is valid. | > | > Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next | > preferred console at unregister time if the console being unregistered | > currently has that bit set. | > | > Example (from sn2 ia64): | > | > elilo vmlinuz root= console=ttyS0 console=ttySG0 | > | > in this case, the flags on ttySG console struct will be 0x4 (should be | > 0x6). | > | > Attached patch against bk fixes both issues for the cases I looked at. It | > uses selected_console (which gets incremented for each console specified | > on the command line) as the indicator of which console to set CON_CONSDEV | > on. When adding the console to the list, if the previous one had | > CON_CONSDEV set, it masks it out. Tested on ia64 and x86. | | The `console=a console=b' behaviour seem basically random to me :(. And it | gets re-randomised on a regular basis. | | I wonder if we should leave the existing behaviour alone (continue to set | CON_CONSDEV on the first console) and just change the documentation? | That'll minimise the disruption which we cause. The problem with the current behavior is it breaks overriding the default from the boot line. In the ia64 case, there may be a global append line defining console=a in elilo.conf. Then you want to boot your kernel, and want to override the default by passing console=b on the boot line. elilo constructs the kernel cmdline by starting with the value of the global append line, then tacks on whatever else you specify, which puts console=b last. You can always edit the elilo.conf and change the global value, but that seems like a pretty big hammer for something you may just want to test. Greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CON_CONSDEV bit not set correctly on last console
In article <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> wrote: >Greg Edwards <[EMAIL PROTECTED]> wrote: >> >> According to include/linux/console.h, CON_CONSDEV flag should be set on >> the last console specified on the boot command line: >> >> 86 #define CON_PRINTBUFFER (1) >> 87 #define CON_CONSDEV (2) /* Last on the command line */ >> 88 #define CON_ENABLED (4) >> 89 #define CON_BOOT(8) >> >> This does not currently happen if there is more than one console specified >> on the boot commandline. Instead, it gets set on the first console on the >> command line. This can cause problems for things like kdb that look for >> the CON_CONSDEV flag to see if the console is valid. >> >> Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next >> preferred console at unregister time if the console being unregistered >> currently has that bit set. >> >> Example (from sn2 ia64): >> >> elilo vmlinuz root= console=ttyS0 console=ttySG0 >> >> in this case, the flags on ttySG console struct will be 0x4 (should be >> 0x6). >> >> Attached patch against bk fixes both issues for the cases I looked at. It >> uses selected_console (which gets incremented for each console specified >> on the command line) as the indicator of which console to set CON_CONSDEV >> on. When adding the console to the list, if the previous one had >> CON_CONSDEV set, it masks it out. Tested on ia64 and x86. > >The `console=a console=b' behaviour seem basically random to me :(. And it >gets re-randomised on a regular basis. Well, on the other hand the last registered console is the one that connects to /dev/console and that has never changed afaik (and it shouldn't, many setups rely on it). Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CON_CONSDEV bit not set correctly on last console
Greg Edwards <[EMAIL PROTECTED]> wrote: > > According to include/linux/console.h, CON_CONSDEV flag should be set on > the last console specified on the boot command line: > > 86 #define CON_PRINTBUFFER (1) > 87 #define CON_CONSDEV (2) /* Last on the command line */ > 88 #define CON_ENABLED (4) > 89 #define CON_BOOT(8) > > This does not currently happen if there is more than one console specified > on the boot commandline. Instead, it gets set on the first console on the > command line. This can cause problems for things like kdb that look for > the CON_CONSDEV flag to see if the console is valid. > > Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next > preferred console at unregister time if the console being unregistered > currently has that bit set. > > Example (from sn2 ia64): > > elilo vmlinuz root= console=ttyS0 console=ttySG0 > > in this case, the flags on ttySG console struct will be 0x4 (should be > 0x6). > > Attached patch against bk fixes both issues for the cases I looked at. It > uses selected_console (which gets incremented for each console specified > on the command line) as the indicator of which console to set CON_CONSDEV > on. When adding the console to the list, if the previous one had > CON_CONSDEV set, it masks it out. Tested on ia64 and x86. The `console=a console=b' behaviour seem basically random to me :(. And it gets re-randomised on a regular basis. I wonder if we should leave the existing behaviour alone (continue to set CON_CONSDEV on the first console) and just change the documentation? That'll minimise the disruption which we cause. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CON_CONSDEV bit not set correctly on last console
Greg Edwards [EMAIL PROTECTED] wrote: According to include/linux/console.h, CON_CONSDEV flag should be set on the last console specified on the boot command line: 86 #define CON_PRINTBUFFER (1) 87 #define CON_CONSDEV (2) /* Last on the command line */ 88 #define CON_ENABLED (4) 89 #define CON_BOOT(8) This does not currently happen if there is more than one console specified on the boot commandline. Instead, it gets set on the first console on the command line. This can cause problems for things like kdb that look for the CON_CONSDEV flag to see if the console is valid. Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next preferred console at unregister time if the console being unregistered currently has that bit set. Example (from sn2 ia64): elilo vmlinuz root=dev console=ttyS0 console=ttySG0 in this case, the flags on ttySG console struct will be 0x4 (should be 0x6). Attached patch against bk fixes both issues for the cases I looked at. It uses selected_console (which gets incremented for each console specified on the command line) as the indicator of which console to set CON_CONSDEV on. When adding the console to the list, if the previous one had CON_CONSDEV set, it masks it out. Tested on ia64 and x86. The `console=a console=b' behaviour seem basically random to me :(. And it gets re-randomised on a regular basis. I wonder if we should leave the existing behaviour alone (continue to set CON_CONSDEV on the first console) and just change the documentation? That'll minimise the disruption which we cause. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CON_CONSDEV bit not set correctly on last console
In article [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED] wrote: Greg Edwards [EMAIL PROTECTED] wrote: According to include/linux/console.h, CON_CONSDEV flag should be set on the last console specified on the boot command line: 86 #define CON_PRINTBUFFER (1) 87 #define CON_CONSDEV (2) /* Last on the command line */ 88 #define CON_ENABLED (4) 89 #define CON_BOOT(8) This does not currently happen if there is more than one console specified on the boot commandline. Instead, it gets set on the first console on the command line. This can cause problems for things like kdb that look for the CON_CONSDEV flag to see if the console is valid. Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next preferred console at unregister time if the console being unregistered currently has that bit set. Example (from sn2 ia64): elilo vmlinuz root=dev console=ttyS0 console=ttySG0 in this case, the flags on ttySG console struct will be 0x4 (should be 0x6). Attached patch against bk fixes both issues for the cases I looked at. It uses selected_console (which gets incremented for each console specified on the command line) as the indicator of which console to set CON_CONSDEV on. When adding the console to the list, if the previous one had CON_CONSDEV set, it masks it out. Tested on ia64 and x86. The `console=a console=b' behaviour seem basically random to me :(. And it gets re-randomised on a regular basis. Well, on the other hand the last registered console is the one that connects to /dev/console and that has never changed afaik (and it shouldn't, many setups rely on it). Mike. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CON_CONSDEV bit not set correctly on last console
On Wed, Apr 06, 2005 at 03:53:17PM -0700, Andrew Morton wrote: | Greg Edwards [EMAIL PROTECTED] wrote: | | According to include/linux/console.h, CON_CONSDEV flag should be set on | the last console specified on the boot command line: | | 86 #define CON_PRINTBUFFER (1) | 87 #define CON_CONSDEV (2) /* Last on the command line */ | 88 #define CON_ENABLED (4) | 89 #define CON_BOOT(8) | | This does not currently happen if there is more than one console specified | on the boot commandline. Instead, it gets set on the first console on the | command line. This can cause problems for things like kdb that look for | the CON_CONSDEV flag to see if the console is valid. | | Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next | preferred console at unregister time if the console being unregistered | currently has that bit set. | | Example (from sn2 ia64): | | elilo vmlinuz root=dev console=ttyS0 console=ttySG0 | | in this case, the flags on ttySG console struct will be 0x4 (should be | 0x6). | | Attached patch against bk fixes both issues for the cases I looked at. It | uses selected_console (which gets incremented for each console specified | on the command line) as the indicator of which console to set CON_CONSDEV | on. When adding the console to the list, if the previous one had | CON_CONSDEV set, it masks it out. Tested on ia64 and x86. | | The `console=a console=b' behaviour seem basically random to me :(. And it | gets re-randomised on a regular basis. | | I wonder if we should leave the existing behaviour alone (continue to set | CON_CONSDEV on the first console) and just change the documentation? | That'll minimise the disruption which we cause. The problem with the current behavior is it breaks overriding the default from the boot line. In the ia64 case, there may be a global append line defining console=a in elilo.conf. Then you want to boot your kernel, and want to override the default by passing console=b on the boot line. elilo constructs the kernel cmdline by starting with the value of the global append line, then tacks on whatever else you specify, which puts console=b last. You can always edit the elilo.conf and change the global value, but that seems like a pretty big hammer for something you may just want to test. Greg - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CON_CONSDEV bit not set correctly on last console
According to include/linux/console.h, CON_CONSDEV flag should be set on the last console specified on the boot command line: 86 #define CON_PRINTBUFFER (1) 87 #define CON_CONSDEV (2) /* Last on the command line */ 88 #define CON_ENABLED (4) 89 #define CON_BOOT(8) This does not currently happen if there is more than one console specified on the boot commandline. Instead, it gets set on the first console on the command line. This can cause problems for things like kdb that look for the CON_CONSDEV flag to see if the console is valid. Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next preferred console at unregister time if the console being unregistered currently has that bit set. Example (from sn2 ia64): elilo vmlinuz root= console=ttyS0 console=ttySG0 in this case, the flags on ttySG console struct will be 0x4 (should be 0x6). Attached patch against bk fixes both issues for the cases I looked at. It uses selected_console (which gets incremented for each console specified on the command line) as the indicator of which console to set CON_CONSDEV on. When adding the console to the list, if the previous one had CON_CONSDEV set, it masks it out. Tested on ia64 and x86. Signed-off-by: Greg Edwards <[EMAIL PROTECTED]> printk.c | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) Index: bk-2.6/kernel/printk.c === --- bk-2.6.orig/kernel/printk.c 2005-04-05 10:55:19.258081161 -0500 +++ bk-2.6/kernel/printk.c 2005-04-05 11:50:16.949394443 -0500 @@ -861,8 +861,10 @@ void register_console(struct console * c break; console->flags |= CON_ENABLED; console->index = console_cmdline[i].index; - if (i == preferred_console) + if (i == selected_console) { console->flags |= CON_CONSDEV; + preferred_console = selected_console; + } break; } @@ -882,6 +884,8 @@ void register_console(struct console * c if ((console->flags & CON_CONSDEV) || console_drivers == NULL) { console->next = console_drivers; console_drivers = console; + if (console->next) + console->next->flags &= ~CON_CONSDEV; } else { console->next = console_drivers->next; console_drivers->next = console; @@ -922,10 +926,14 @@ int unregister_console(struct console * /* If last console is removed, we re-enable picking the first * one that gets registered. Without that, pmac early boot console * would prevent fbcon from taking over. +* +* If this isn't the last console and it has CON_CONSDEV set, we +* need to set it on the next preferred console. */ if (console_drivers == NULL) preferred_console = selected_console; - + else if (console->flags & CON_CONSDEV) + console_drivers->flags |= CON_CONSDEV; release_console_sem(); return res; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CON_CONSDEV bit not set correctly on last console
According to include/linux/console.h, CON_CONSDEV flag should be set on the last console specified on the boot command line: 86 #define CON_PRINTBUFFER (1) 87 #define CON_CONSDEV (2) /* Last on the command line */ 88 #define CON_ENABLED (4) 89 #define CON_BOOT(8) This does not currently happen if there is more than one console specified on the boot commandline. Instead, it gets set on the first console on the command line. This can cause problems for things like kdb that look for the CON_CONSDEV flag to see if the console is valid. Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next preferred console at unregister time if the console being unregistered currently has that bit set. Example (from sn2 ia64): elilo vmlinuz root=dev console=ttyS0 console=ttySG0 in this case, the flags on ttySG console struct will be 0x4 (should be 0x6). Attached patch against bk fixes both issues for the cases I looked at. It uses selected_console (which gets incremented for each console specified on the command line) as the indicator of which console to set CON_CONSDEV on. When adding the console to the list, if the previous one had CON_CONSDEV set, it masks it out. Tested on ia64 and x86. Signed-off-by: Greg Edwards [EMAIL PROTECTED] printk.c | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) Index: bk-2.6/kernel/printk.c === --- bk-2.6.orig/kernel/printk.c 2005-04-05 10:55:19.258081161 -0500 +++ bk-2.6/kernel/printk.c 2005-04-05 11:50:16.949394443 -0500 @@ -861,8 +861,10 @@ void register_console(struct console * c break; console-flags |= CON_ENABLED; console-index = console_cmdline[i].index; - if (i == preferred_console) + if (i == selected_console) { console-flags |= CON_CONSDEV; + preferred_console = selected_console; + } break; } @@ -882,6 +884,8 @@ void register_console(struct console * c if ((console-flags CON_CONSDEV) || console_drivers == NULL) { console-next = console_drivers; console_drivers = console; + if (console-next) + console-next-flags = ~CON_CONSDEV; } else { console-next = console_drivers-next; console_drivers-next = console; @@ -922,10 +926,14 @@ int unregister_console(struct console * /* If last console is removed, we re-enable picking the first * one that gets registered. Without that, pmac early boot console * would prevent fbcon from taking over. +* +* If this isn't the last console and it has CON_CONSDEV set, we +* need to set it on the next preferred console. */ if (console_drivers == NULL) preferred_console = selected_console; - + else if (console-flags CON_CONSDEV) + console_drivers-flags |= CON_CONSDEV; release_console_sem(); return res; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/