lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <489044C8.7090006@aim.com>
Date:	Wed, 30 Jul 2008 03:39:04 -0700
From:	David W Studeman <avionicsdv@....com>
To:	Willy Tarreau <w@....eu>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Keyboard Jammed error patch 2.4.35-pre4

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ