Keyboard Jammed error patch 2.4.35-pre4

Keyboard Jammed error patch 2.4.35-pre4

[David W Studeman]

  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

Re: Keyboard Jammed error patch 2.4.35-pre4

[Willy Tarreau]

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@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@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

Re: Keyboard Jammed error patch 2.4.35-pre4

[David W Studeman]

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@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@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

Re: Keyboard Jammed error patch 2.4.35-pre4

[Willy Tarreau]

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

Re: Keyboard Jammed error patch 2.4.35-pre4

[David W Studeman]

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;
      }

Re: Keyboard Jammed error patch 2.4.35-pre4

[Willy Tarreau]

On Wed, Jul 30, 2008 at 03:39:04AM -0700, David W Studeman wrote:
> >This was the important part. Did you fix it by hand ? If not, it would
> >explain why it did not change the behaviour.
> >
>  It didn't change the behaviour because it would not apply cleanly, 
> kernel compilation stopped there.

Ah OK, so if you applied half of the patch, it's expected that the fix is
not applied !

> A raq/qube3, raq4, raq550, and xtr are all x86 based

OK, that's what I wanted to know, because I needed to understand whether
the compiled code was in the i386 directory or in another one.

> but they do not use 
> a typical bios and a bootloader to start the boot process but that part 
> is not important here.

that's what I understood.

> 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

Why? I have it running on several machines! What error do you get ? Or
perhaps it's just a matter of not finding the appropriate configuration
(which is not obvious, I agree) ?

> and I need no dummy driver even though it would not compile by 
> choosing the dummy driver by itself either.

Why would it not compile ?

I'm sorry, but you keep saying that solution XXX would not work but you
don't indicate what issue you encounter when you try it. If there are
problems, obviously they need to be fixed, but I cannot fix problems
based on suppositions.

> Regression patching to 
> 2.4.34 restored the ability to compile without keyboard and vt support. 
> This is what it took:

I'm well aware of the patch you reverted. But in my opinion, you fix
symptoms and not the cause. This patch fixed a problem. Reverting it
causes either :
  - kbd_controller_present being uncondtionally defined to 1, meaning
    it would not change anything for you

  - kbd_controller_present being defined to zero by some obscure other
    configuration that we just need to find out. However, the last patch
    I sent to you would have taken care of it, had it applied correctly
    (please apply it by hand in this case, it's just a matter of changing
    one macro name in the "if").

Thanks,
Willy

Re: Keyboard Jammed error patch 2.4.35-pre4

[David W Studeman]

Willy Tarreau wrote:

> On Wed, Jul 30, 2008 at 03:39:04AM -0700, David W Studeman wrote:
>> >This was the important part. Did you fix it by hand ? If not, it would
>> >explain why it did not change the behaviour.
>> >
>>  It didn't change the behaviour because it would not apply cleanly,
>> kernel compilation stopped there.
> 
> Ah OK, so if you applied half of the patch, it's expected that the fix is
> not applied !
> 
>> A raq/qube3, raq4, raq550, and xtr are all x86 based
> 
> OK, that's what I wanted to know, because I needed to understand whether
> the compiled code was in the i386 directory or in another one.
> 
>> but they do not use
>> a typical bios and a bootloader to start the boot process but that part
>> is not important here.
> 
> that's what I understood.
> 
>> 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
> 
> Why? I have it running on several machines! What error do you get ? Or
> perhaps it's just a matter of not finding the appropriate configuration
> (which is not obvious, I agree) ?
> 
>> and I need no dummy driver even though it would not compile by
>> choosing the dummy driver by itself either.
> 
> Why would it not compile ?
> 
> I'm sorry, but you keep saying that solution XXX would not work but you
> don't indicate what issue you encounter when you try it. If there are
> problems, obviously they need to be fixed, but I cannot fix problems
> based on suppositions.
> 
>> Regression patching to
>> 2.4.34 restored the ability to compile without keyboard and vt support.
>> This is what it took:
> 
> I'm well aware of the patch you reverted. But in my opinion, you fix
> symptoms and not the cause. This patch fixed a problem. Reverting it
> causes either :
>   - kbd_controller_present being uncondtionally defined to 1, meaning
>     it would not change anything for you
> 
>   - kbd_controller_present being defined to zero by some obscure other
>     configuration that we just need to find out. However, the last patch
>     I sent to you would have taken care of it, had it applied correctly
>     (please apply it by hand in this case, it's just a matter of changing
>     one macro name in the "if").
> 
> Thanks,
> Willy


Ok, I finally applied the patch manually to 2.4.36.7 and then made my own
diff from that. Your patch would likely have applied if I increased the
fuzz factor as it was merely off by a number of lines. When trying to
compile with no keyboard or VT support, I still get this error:

arch/i386/kernel/kernel.o(.text.init+0x33e6): In function
`disable_console_keyboard':
: undefined reference to `keyboard_controller_present'
make: *** [vmlinux] Error 1

When I did a regression patch I also did the arch/i386/kernel/dmi_scan.c
since some of the changes made back in 2.4.35 to this file are where the
error comes from in the above error. DMI blacklisting will NOT work with
Cobalt hardware as there is no dmi present to blacklist. Also note that the
above error does not occur with a normal pc configuration where you include
keyboard support and VT support but once you try to make a kernel without
keyboard and VT support for embedded devices, dmi_scan.c breaks the build. 


Dave

Re: Keyboard Jammed error patch 2.4.35-pre4

[Willy Tarreau]

Hello David,

first, please always take care of keeping persons in CC when replying to
LKML, otherwise you risk your mail being missed.

On Sun, Sep 21, 2008 at 06:00:50AM -0700, David W Studeman wrote:
> Ok, I finally applied the patch manually to 2.4.36.7 and then made my own
> diff from that. Your patch would likely have applied if I increased the
> fuzz factor as it was merely off by a number of lines. When trying to
> compile with no keyboard or VT support, I still get this error:
> 
> arch/i386/kernel/kernel.o(.text.init+0x33e6): In function
> `disable_console_keyboard':
> : undefined reference to `keyboard_controller_present'
> make: *** [vmlinux] Error 1

I know what causes this. The fix is merged into 2.4.37-rc1. I've been
using it for a long time without even noticing that it was still not
merged. The fix is trivial as it simply removes the disable_console_keyboard
function when CONFIG_VT is not set. This is needed because the variable
keyboard_controller_present is only defined when CONFIG_VT is set.

Here's the patch if it can help you.

Also, next time you encounter problems, please post your config. It's
very hard to troubleshoot build bugs without a config. I would have
immediately spotted this missing patch on the first time had I got
that config.

Regards,
Willy

----
>From 90e228888a59d630c8094d5d1b273b00a2c76cc0 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 7 Sep 2008 12:37:51 +0200
Subject: x86 would not build without CONFIG_VT

I've been using this patch for a while without noticing it never
went into mainline. It is required to build i386 without CONFIG_VT.

Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/i386/kernel/dmi_scan.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/dmi_scan.c b/arch/i386/kernel/dmi_scan.c
index 07c6d94..9c27ca2 100644
--- a/arch/i386/kernel/dmi_scan.c
+++ b/arch/i386/kernel/dmi_scan.c
@@ -524,6 +524,7 @@ static __init int disable_acpi_pci(struct dmi_blacklist *d)
  */
  
 
+#ifdef CONFIG_VT
 /*      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
@@ -538,6 +539,7 @@ static __init int disable_console_keyboard(struct dmi_blacklist *d)
         keyboard_controller_present = 0;
         return 0;
 }
+#endif
 
 /*
  *	This will be expanded over time to force things like the APM 
@@ -825,7 +827,8 @@ static __initdata struct dmi_blacklist dmi_blacklist[]={
 			MATCH(DMI_SYS_VENDOR, "IBM"),
 			NO_MATCH, NO_MATCH, NO_MATCH
 			} },
- /*
+#ifdef CONFIG_VT
+        /*
          *      IBM Bladeservers
          */
 
@@ -834,6 +837,7 @@ static __initdata struct dmi_blacklist dmi_blacklist[]={
                         MATCH(DMI_BOARD_NAME, "Server Blade"),
                         NO_MATCH, NO_MATCH
                         } },
+#endif
 
 #ifdef	CONFIG_ACPI_BOOT
 	/*
-- 
1.5.3.3

Re: Keyboard Jammed error patch 2.4.35-pre4

[David W Studeman]

Willy Tarreau wrote:
> Hello David,
> 
> first, please always take care of keeping persons in CC when replying to
> LKML, otherwise you risk your mail being missed.
> 
> On Sun, Sep 21, 2008 at 06:00:50AM -0700, David W Studeman wrote:
>> Ok, I finally applied the patch manually to 2.4.36.7 and then made my own
>> diff from that. Your patch would likely have applied if I increased the
>> fuzz factor as it was merely off by a number of lines. When trying to
>> compile with no keyboard or VT support, I still get this error:
>>
>> arch/i386/kernel/kernel.o(.text.init+0x33e6): In function
>> `disable_console_keyboard':
>> : undefined reference to `keyboard_controller_present'
>> make: *** [vmlinux] Error 1
> 
> I know what causes this. The fix is merged into 2.4.37-rc1. I've been
> using it for a long time without even noticing that it was still not
> merged. The fix is trivial as it simply removes the disable_console_keyboard
> function when CONFIG_VT is not set. This is needed because the variable
> keyboard_controller_present is only defined when CONFIG_VT is set.
> 
> Here's the patch if it can help you.
> 
> Also, next time you encounter problems, please post your config. It's
> very hard to troubleshoot build bugs without a config. I would have
> immediately spotted this missing patch on the first time had I got
> that config.
> 
> Regards,
> Willy
> 
> ----
> From 90e228888a59d630c8094d5d1b273b00a2c76cc0 Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w@1wt.eu>
> Date: Sun, 7 Sep 2008 12:37:51 +0200
> Subject: x86 would not build without CONFIG_VT
> 
> I've been using this patch for a while without noticing it never
> went into mainline. It is required to build i386 without CONFIG_VT.
> 
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
>  arch/i386/kernel/dmi_scan.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/i386/kernel/dmi_scan.c b/arch/i386/kernel/dmi_scan.c
> index 07c6d94..9c27ca2 100644
> --- a/arch/i386/kernel/dmi_scan.c
> +++ b/arch/i386/kernel/dmi_scan.c
> @@ -524,6 +524,7 @@ static __init int disable_acpi_pci(struct dmi_blacklist *d)
>   */
>   
>  
> +#ifdef CONFIG_VT
>  /*      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
> @@ -538,6 +539,7 @@ static __init int disable_console_keyboard(struct dmi_blacklist *d)
>          keyboard_controller_present = 0;
>          return 0;
>  }
> +#endif
>  
>  /*
>   *	This will be expanded over time to force things like the APM 
> @@ -825,7 +827,8 @@ static __initdata struct dmi_blacklist dmi_blacklist[]={
>  			MATCH(DMI_SYS_VENDOR, "IBM"),
>  			NO_MATCH, NO_MATCH, NO_MATCH
>  			} },
> - /*
> +#ifdef CONFIG_VT
> +        /*
>           *      IBM Bladeservers
>           */
>  
> @@ -834,6 +837,7 @@ static __initdata struct dmi_blacklist dmi_blacklist[]={
>                          MATCH(DMI_BOARD_NAME, "Server Blade"),
>                          NO_MATCH, NO_MATCH
>                          } },
> +#endif
>  
>  #ifdef	CONFIG_ACPI_BOOT
>  	/*


Ok, Thanks Willy! The changes to the dmi_scan.c as you gave above from 
2.4.37rc1 fixed the remaining problem. I have a 2.4.36.7 Cobalt patched 
kernel running in a Raq550 as I type this and it compiled with no 
keyboard or VT support cleanly with your dmi_scan and pc_keybd patch so 
I no longer am using the old regression patch I made previously.

  Thanks for your effort in solving this.


Dave Studeman

Re: Keyboard Jammed error patch 2.4.35-pre4

[Willy Tarreau]

On Sun, Sep 21, 2008 at 08:30:22PM -0700, David W Studeman wrote:
> Willy Tarreau wrote:
> >Hello David,
> >
> >first, please always take care of keeping persons in CC when replying to
> >LKML, otherwise you risk your mail being missed.
> >
> >On Sun, Sep 21, 2008 at 06:00:50AM -0700, David W Studeman wrote:
> >>Ok, I finally applied the patch manually to 2.4.36.7 and then made my own
> >>diff from that. Your patch would likely have applied if I increased the
> >>fuzz factor as it was merely off by a number of lines. When trying to
> >>compile with no keyboard or VT support, I still get this error:
> >>
> >>arch/i386/kernel/kernel.o(.text.init+0x33e6): In function
> >>`disable_console_keyboard':
> >>: undefined reference to `keyboard_controller_present'
> >>make: *** [vmlinux] Error 1
> >
> >I know what causes this. The fix is merged into 2.4.37-rc1. I've been
> >using it for a long time without even noticing that it was still not
> >merged. The fix is trivial as it simply removes the 
> >disable_console_keyboard
> >function when CONFIG_VT is not set. This is needed because the variable
> >keyboard_controller_present is only defined when CONFIG_VT is set.
> >
> >Here's the patch if it can help you.
> >
> >Also, next time you encounter problems, please post your config. It's
> >very hard to troubleshoot build bugs without a config. I would have
> >immediately spotted this missing patch on the first time had I got
> >that config.
> >
> >Regards,
> >Willy
> >
> >----
> >From 90e228888a59d630c8094d5d1b273b00a2c76cc0 Mon Sep 17 00:00:00 2001
> >From: Willy Tarreau <w@1wt.eu>
> >Date: Sun, 7 Sep 2008 12:37:51 +0200
> >Subject: x86 would not build without CONFIG_VT
> >
> >I've been using this patch for a while without noticing it never
> >went into mainline. It is required to build i386 without CONFIG_VT.
> >
> >Signed-off-by: Willy Tarreau <w@1wt.eu>
> >---
> > arch/i386/kernel/dmi_scan.c |    6 +++++-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
> >
> >diff --git a/arch/i386/kernel/dmi_scan.c b/arch/i386/kernel/dmi_scan.c
> >index 07c6d94..9c27ca2 100644
> >--- a/arch/i386/kernel/dmi_scan.c
> >+++ b/arch/i386/kernel/dmi_scan.c
> >@@ -524,6 +524,7 @@ static __init int disable_acpi_pci(struct 
> >dmi_blacklist *d)
> >  */
> >  
> > 
> >+#ifdef CONFIG_VT
> > /*      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
> >@@ -538,6 +539,7 @@ static __init int disable_console_keyboard(struct 
> >dmi_blacklist *d)
> >         keyboard_controller_present = 0;
> >         return 0;
> > }
> >+#endif
> > 
> > /*
> >  *	This will be expanded over time to force things like the APM 
> >@@ -825,7 +827,8 @@ static __initdata struct dmi_blacklist 
> >dmi_blacklist[]={
> > 			MATCH(DMI_SYS_VENDOR, "IBM"),
> > 			NO_MATCH, NO_MATCH, NO_MATCH
> > 			} },
> >- /*
> >+#ifdef CONFIG_VT
> >+        /*
> >          *      IBM Bladeservers
> >          */
> > 
> >@@ -834,6 +837,7 @@ static __initdata struct dmi_blacklist 
> >dmi_blacklist[]={
> >                         MATCH(DMI_BOARD_NAME, "Server Blade"),
> >                         NO_MATCH, NO_MATCH
> >                         } },
> >+#endif
> > 
> > #ifdef	CONFIG_ACPI_BOOT
> > 	/*
> 
> 
> Ok, Thanks Willy! The changes to the dmi_scan.c as you gave above from 
> 2.4.37rc1 fixed the remaining problem. I have a 2.4.36.7 Cobalt patched 
> kernel running in a Raq550 as I type this and it compiled with no 
> keyboard or VT support cleanly with your dmi_scan and pc_keybd patch so 
> I no longer am using the old regression patch I made previously.

fine, it will be merged into 2.4.36.8 too.

Willy