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/
