Keyboard Jammed error patch 2.4.35-pre4
in [Kernel]
|
Prev: What to do with `kswapd0: page allocation failure. ` ?
Next: scalable classic RCU implementation
From: David W Studeman on 28 Jul 2008 03:10 Hello! The changes that were made on 04-25-2007 as "[PATCH 2.4.35-pre4] fix 'pc_keyb: controller jammed (0xA7)' error" have broken the ability to compile with no keyboard and no VT support. This mainly affects Cobalt machines which do not have dmi present as these use a flashrom to boot with and not a typical bios so dmi blacklisting would be pointless unless it allowed for no dmi present and then blacklist. I had to create a patch against 2.4.34 to restore the ability to compile with no keyboard and VT support. With keyboard support whether embedded or modularized, in a Raq/Qube3 and Raq4, it simply gives off a warning in the serial console if you are watching it boot, a Raq 550 on the other hand shows it as an error about 300 times and will also show up in the dmesg log. Unless one was to fix the dmi blacklisting to disable when no dmi is present as is the case here, it needs to be fixed to allow compiling without. A Cobalt can only use two methods of terminal access, one being serial console and ssh being the other. These units do not use a typical bios but rather a flashrom on a 1 OR 2mb flash chip depending on model. The flashrom image contains it's own kernel and Cobalt utilities and starts it's own boot process and looks for a bzipped vmlinux image in boot to hand off to when it's time to actually boot your OS. You have to set the boot and root partition in it the first time and it does not care about or see any bootloader you may have installed. It also does not give off any info about itself either. Sure, the required embedded Cobalt drivers will tell something from /proc/cobalt but that's about it. This ability to compile without had been broken and restored back in kernel 2.4.31 and then as of the 2.4.35.4 it has been broken since. I'm involved in making a Cobalt build of IPCop and would love it if I didn't have to patch for this in addition to the rest that is required to make a Raq/Qube run. Dave Studeman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Willy Tarreau on 29 Jul 2008 01:20 Hello David, On Sun, Jul 27, 2008 at 11:59:47PM -0700, David W Studeman wrote: > Hello! The changes that were made on 04-25-2007 as "[PATCH > 2.4.35-pre4] fix 'pc_keyb: controller jammed (0xA7)' error" have broken > the ability to compile with no keyboard and no VT support. This mainly > affects Cobalt machines which do not have dmi present as these use a > flashrom to boot with and not a typical bios so dmi blacklisting would > be pointless unless it allowed for no dmi present and then blacklist. I > had to create a patch against 2.4.34 to restore the ability to compile > with no keyboard and VT support. Grrr... I see what's happening. I remember having checked that the kbd_controller_present macro was really not used before merging the patch, but obviously I had not looked deep enough. It's defined by ia64, mips and mips64 in include/asm. Could you please test the patch below (untested here). It should revert to pre-2.4.35 behaviour on all architectures cited above. If you confirm that it works, I'll merge it. BTW, in the mean time, you can boot with the "nokeyb" option. It will disable the keyboard. This is what I use on some non-blacklisted systems, and the option was precisely provided by this patch. Also, if you don't have any PC keyboard on your machines, you can build without support for any VT/keyboard. I'm already doing this on some embedded systems, and it works fine. If your platform still requires that some keyboard is enabled, you may want to try to enable CONFIG_DUMMY_KEYB which I've been using in the past. Regards, Willy From e4827f141dc86c540971082877124b213557ece0 Mon Sep 17 00:00:00 2001 From: Willy Tarreau <w(a)1wt.eu> Date: Tue, 29 Jul 2008 07:06:00 +0200 Subject: pc_keyb: fix breakage on ia64/mips/mips64 Commit f8db8c9c81afb4b04c146cae0e2a1fd311de1f22 fixed the keyboard controller jammed issue on keyboard-less PCs, but introduced the problem for other architectures (ia64/mips/mips64) which already define their own keyboard probing method. This patch gives precedence to these archs' probing method and only defines the setup option if no arch-specific method was defined. Problem reported by David W Studeman. Signed-off-by: Willy Tarreau <w(a)1wt.eu> --- drivers/char/pc_keyb.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/char/pc_keyb.c b/drivers/char/pc_keyb.c index d4e1611..b90e659 100644 --- a/drivers/char/pc_keyb.c +++ b/drivers/char/pc_keyb.c @@ -61,6 +61,10 @@ unsigned char pckbd_sysrq_xlate[128] = "\r\000/"; /* 0x60 - 0x6f */ #endif +/* Warning: do not redefine kbd_controller_present on ia64, mips and mips64 */ +#ifndef kbd_controller_present +#define kbd_controller_present() keyboard_controller_present + int keyboard_controller_present __initdata = 1; static int __init removable_keyb(char *str) { @@ -68,6 +72,7 @@ static int __init removable_keyb(char *str) return 0; } __setup("nokeyb", removable_keyb); +#endif static void kbd_write_command_w(int data); static void kbd_write_output_w(int data); @@ -77,8 +82,6 @@ static void __aux_write_ack(int val); static int aux_reconnect = 0; #endif -#define kbd_controller_present() keyboard_controller_present - static spinlock_t kbd_controller_lock = SPIN_LOCK_UNLOCKED; static unsigned char handle_kbd_event(void); @@ -905,7 +908,7 @@ static char * __init initialize_kbd(void) void __init pckbd_init_hw(void) { - if (!keyboard_controller_present) { + if (!kbd_controller_present()) { kbd_exists = 0; return; } -- 1.5.3.8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David W Studeman on 30 Jul 2008 03:40 Willy Tarreau wrote: > Hello David, > > On Sun, Jul 27, 2008 at 11:59:47PM -0700, David W Studeman wrote: > >> Hello! The changes that were made on 04-25-2007 as "[PATCH >> 2.4.35-pre4] fix 'pc_keyb: controller jammed (0xA7)' error" have broken >> the ability to compile with no keyboard and no VT support. This mainly >> affects Cobalt machines which do not have dmi present as these use a >> flashrom to boot with and not a typical bios so dmi blacklisting would >> be pointless unless it allowed for no dmi present and then blacklist. I >> had to create a patch against 2.4.34 to restore the ability to compile >> with no keyboard and VT support. >> > > Grrr... I see what's happening. I remember having checked that the > kbd_controller_present macro was really not used before merging the > patch, but obviously I had not looked deep enough. It's defined by > ia64, mips and mips64 in include/asm. > > Could you please test the patch below (untested here). It should revert > to pre-2.4.35 behaviour on all architectures cited above. If you confirm > that it works, I'll merge it. > > BTW, in the mean time, you can boot with the "nokeyb" option. It will > disable the keyboard. This is what I use on some non-blacklisted systems, > and the option was precisely provided by this patch. > > No I can't use the nokeybd option as a Cobalt uses no bootloader on the mbr. The arguments would have to be embedded into the flashrom image and it isn't something most people want to deal with. > Also, if you don't have any PC keyboard on your machines, you can > build without support for any VT/keyboard. I'm already doing this > on some embedded systems, and it works fine. If your platform still > requires that some keyboard is enabled, you may want to try to enable > CONFIG_DUMMY_KEYB which I've been using in the past. > That didn't work either, what did save me was patching back to 2.4.34 for the dmi and keyboard headers and compiling without any keyboard support at all. Also, since this is essentially a PC without a normal bios, the kernel reports that there is no dmi present. The boot method here reminds me of EFI but it isn't. > Regards, > Willy > > From e4827f141dc86c540971082877124b213557ece0 Mon Sep 17 00:00:00 2001 > From: Willy Tarreau<w(a)1wt.eu> > Date: Tue, 29 Jul 2008 07:06:00 +0200 > Subject: pc_keyb: fix breakage on ia64/mips/mips64 > > Commit f8db8c9c81afb4b04c146cae0e2a1fd311de1f22 fixed the keyboard > controller jammed issue on keyboard-less PCs, but introduced the > problem for other architectures (ia64/mips/mips64) which already > define their own keyboard probing method. > > This patch gives precedence to these archs' probing method and only > defines the setup option if no arch-specific method was defined. > > Problem reported by David W Studeman. > > Signed-off-by: Willy Tarreau<w(a)1wt.eu> > --- > drivers/char/pc_keyb.c | 9 ++++++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/char/pc_keyb.c b/drivers/char/pc_keyb.c > index d4e1611..b90e659 100644 > --- a/drivers/char/pc_keyb.c > +++ b/drivers/char/pc_keyb.c > @@ -61,6 +61,10 @@ unsigned char pckbd_sysrq_xlate[128] = > "\r\000/"; /* 0x60 - 0x6f */ > #endif > > +/* Warning: do not redefine kbd_controller_present on ia64, mips and mips64 */ > +#ifndef kbd_controller_present > +#define kbd_controller_present() keyboard_controller_present > + > int keyboard_controller_present __initdata = 1; > static int __init removable_keyb(char *str) > { > @@ -68,6 +72,7 @@ static int __init removable_keyb(char *str) > return 0; > } > __setup("nokeyb", removable_keyb); > +#endif > > static void kbd_write_command_w(int data); > static void kbd_write_output_w(int data); > @@ -77,8 +82,6 @@ static void __aux_write_ack(int val); > static int aux_reconnect = 0; > #endif > > -#define kbd_controller_present() keyboard_controller_present > - > static spinlock_t kbd_controller_lock = SPIN_LOCK_UNLOCKED; > static unsigned char handle_kbd_event(void); > > @@ -905,7 +908,7 @@ static char * __init initialize_kbd(void) > > void __init pckbd_init_hw(void) > { > - if (!keyboard_controller_present) { > + if (!kbd_controller_present()) { > kbd_exists = 0; > return; > } > The last hunk at 905 fails to apply, line 61 passes due to some fuzz factor although I can't see what is different and why it needs to fuzz but line 61 still passes. Here is a snip from the log: patching file drivers/char/pc_keyb.c Hunk #1 succeeded at 61 with fuzz 1. Hunk #4 FAILED at 908. 1 out of 4 hunks FAILED -- saving rejects to file drivers/char/pc_keyb.c.rej make: *** [/usr/src/log/linux-2.4.36.6] Error 1 And here is the pc_keyb.c.rej: *************** *** 905,911 **** void __init pckbd_init_hw(void) { - if (!keyboard_controller_present) { kbd_exists = 0; return; } --- 908,914 ---- void __init pckbd_init_hw(void) { + if (!kbd_controller_present()) { kbd_exists = 0; return; } Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Willy Tarreau on 30 Jul 2008 04:00 On Wed, Jul 30, 2008 at 12:22:19AM -0700, David W Studeman wrote: > No I can't use the nokeybd option as a Cobalt uses no bootloader on the > mbr. The arguments would have to be embedded into the flashrom image and > it isn't something most people want to deal with. OK, I was not talking about a solution but about a temporary workaround anyway :-) > >Also, if you don't have any PC keyboard on your machines, you can > >build without support for any VT/keyboard. I'm already doing this > >on some embedded systems, and it works fine. If your platform still > >requires that some keyboard is enabled, you may want to try to enable > >CONFIG_DUMMY_KEYB which I've been using in the past. > > > That didn't work either, what did save me was patching back to 2.4.34 > for the dmi and keyboard headers and compiling without any keyboard > support at all. Also, since this is essentially a PC without a normal > bios, the kernel reports that there is no dmi present. The boot method > here reminds me of EFI but it isn't. Just so that I understand, when you say it is a PC, is it x86-based or a different arch ? I thought it was a mips, but now you're speaking about a PC I'm confused. If it's x86, I don't see why the patch caused a regression since it does not change the default behaviour for x86. If it's a mips, I don't see why the proposed patch does not work as it was supposed to revert to previous behaviour :-/ > >@@ -905,7 +908,7 @@ static char * __init initialize_kbd(void) > > > > void __init pckbd_init_hw(void) > > { > >- if (!keyboard_controller_present) { > >+ if (!kbd_controller_present()) { > > kbd_exists = 0; > > return; > > } > > > The last hunk at 905 fails to apply, line 61 passes due to some fuzz > factor although I can't see what is different and why it needs to fuzz > but line 61 still passes. Here is a snip from the log: hmm sorry, I did it in a hurry against next 2.4.37-rc1. I'll check. > patching file drivers/char/pc_keyb.c > Hunk #1 succeeded at 61 with fuzz 1. > Hunk #4 FAILED at 908. > 1 out of 4 hunks FAILED -- saving rejects to file drivers/char/pc_keyb.c.rej > make: *** [/usr/src/log/linux-2.4.36.6] Error 1 > > And here is the pc_keyb.c.rej: > > *************** > *** 905,911 **** > > void __init pckbd_init_hw(void) > { > - if (!keyboard_controller_present) { > kbd_exists = 0; > return; > } > --- 908,914 ---- > > void __init pckbd_init_hw(void) > { > + if (!kbd_controller_present()) { > kbd_exists = 0; > return; > } This was the important part. Did you fix it by hand ? If not, it would explain why it did not change the behaviour. Regards, Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David W Studeman on 30 Jul 2008 06:50 Willy Tarreau wrote: > On Wed, Jul 30, 2008 at 12:22:19AM -0700, David W Studeman wrote: > >> No I can't use the nokeybd option as a Cobalt uses no bootloader on the >> mbr. The arguments would have to be embedded into the flashrom image and >> it isn't something most people want to deal with. >> > > OK, I was not talking about a solution but about a temporary workaround > anyway :-) > > >>> Also, if you don't have any PC keyboard on your machines, you can >>> build without support for any VT/keyboard. I'm already doing this >>> on some embedded systems, and it works fine. If your platform still >>> requires that some keyboard is enabled, you may want to try to enable >>> CONFIG_DUMMY_KEYB which I've been using in the past. >>> >>> >> That didn't work either, what did save me was patching back to 2.4.34 >> for the dmi and keyboard headers and compiling without any keyboard >> support at all. Also, since this is essentially a PC without a normal >> bios, the kernel reports that there is no dmi present. The boot method >> here reminds me of EFI but it isn't. >> > > Just so that I understand, when you say it is a PC, is it x86-based or > a different arch ? I thought it was a mips, but now you're speaking about > a PC I'm confused. If it's x86, I don't see why the patch caused a regression > since it does not change the default behaviour for x86. If it's a mips, I don't > see why the proposed patch does not work as it was supposed to revert to > previous behaviour :-/ > > >>> @@ -905,7 +908,7 @@ static char * __init initialize_kbd(void) >>> >>> void __init pckbd_init_hw(void) >>> { >>> - if (!keyboard_controller_present) { >>> + if (!kbd_controller_present()) { >>> kbd_exists = 0; >>> return; >>> } >>> >>> >> The last hunk at 905 fails to apply, line 61 passes due to some fuzz >> factor although I can't see what is different and why it needs to fuzz >> but line 61 still passes. Here is a snip from the log: >> > > hmm sorry, I did it in a hurry against next 2.4.37-rc1. I'll check. > > >> patching file drivers/char/pc_keyb.c >> Hunk #1 succeeded at 61 with fuzz 1. >> Hunk #4 FAILED at 908. >> 1 out of 4 hunks FAILED -- saving rejects to file drivers/char/pc_keyb.c.rej >> make: *** [/usr/src/log/linux-2.4.36.6] Error 1 >> >> And here is the pc_keyb.c.rej: >> >> *************** >> *** 905,911 **** >> >> void __init pckbd_init_hw(void) >> { >> - if (!keyboard_controller_present) { >> kbd_exists = 0; >> return; >> } >> --- 908,914 ---- >> >> void __init pckbd_init_hw(void) >> { >> + if (!kbd_controller_present()) { >> kbd_exists = 0; >> return; >> } >> > > This was the important part. Did you fix it by hand ? If not, it would > explain why it did not change the behaviour. > > Regards, > Willy > > It didn't change the behaviour because it would not apply cleanly, kernel compilation stopped there. A raq/qube3, raq4, raq550, and xtr are all x86 based but they do not use a typical bios and a bootloader to start the boot process but that part is not important here. When I made the regression patch, I simply diffed the dmi scan and keyboard drivers between the two kernels. The stock 2.4.36.6 kernel cannot be compiled for x86 with no keyboard and vt support and I need no dummy driver even though it would not compile by choosing the dummy driver by itself either. Regression patching to 2.4.34 restored the ability to compile without keyboard and vt support. This is what it took: Dave --- linux-2.4.36/arch/i386/kernel/dmi_scan.c.orig 2008-01-01 12:06:40.000000000 +0000 +++ linux-2.4.36/arch/i386/kernel/dmi_scan.c 2008-07-16 03:36:01.000000000 +0000 @@ -524,21 +524,6 @@ */ -/* IBM bladeservers have a USB console switch. The keyboard type is USB - * and the hardware does not have a console keyboard. We disable the - * console keyboard so the kernel does not try to initialize one and - * spew errors. This can be used for all systems without a console - * keyboard like systems with just a USB or IrDA keyboard. - */ -static __init int disable_console_keyboard(struct dmi_blacklist *d) -{ - extern int keyboard_controller_present; - printk(KERN_INFO "*** Hardware has no console keyboard controller.\n"); - printk(KERN_INFO "*** Disabling console keyboard.\n"); - keyboard_controller_present = 0; - return 0; -} - /* * This will be expanded over time to force things like the APM * interrupt mask settings according to the laptop @@ -825,15 +810,6 @@ MATCH(DMI_SYS_VENDOR, "IBM"), NO_MATCH, NO_MATCH, NO_MATCH } }, - /* - * IBM Bladeservers - */ - - { disable_console_keyboard, "IBM Server Blade", { - MATCH(DMI_SYS_VENDOR,"IBM"), - MATCH(DMI_BOARD_NAME, "Server Blade"), - NO_MATCH, NO_MATCH - } }, #ifdef CONFIG_ACPI_BOOT /* --- linux-2.4.36/drivers/char/pc_keyb.c.orig 2008-01-01 12:06:40.000000000 +0000 +++ linux-2.4.36/drivers/char/pc_keyb.c 2008-07-16 03:37:26.000000000 +0000 @@ -61,14 +61,6 @@ "\r\000/"; /* 0x60 - 0x6f */ #endif -int keyboard_controller_present __initdata = 1; -static int __init removable_keyb(char *str) -{ - keyboard_controller_present = 0; - return 0; -} -__setup("nokeyb", removable_keyb); - static void kbd_write_command_w(int data); static void kbd_write_output_w(int data); #ifdef CONFIG_PSMOUSE @@ -77,8 +69,9 @@ static int aux_reconnect = 0; #endif -#define kbd_controller_present() keyboard_controller_present - +#ifndef kbd_controller_present +#define kbd_controller_present() 1 +#endif static spinlock_t kbd_controller_lock = SPIN_LOCK_UNLOCKED; static unsigned char handle_kbd_event(void); @@ -905,7 +898,7 @@ void __init pckbd_init_hw(void) { - if (!keyboard_controller_present) { + if (!kbd_controller_present()) { kbd_exists = 0; return; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: What to do with `kswapd0: page allocation failure. ` ? Next: scalable classic RCU implementation |