linux-kernel - Re: Keyboard Jammed error patch 2.4.35-pre4

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: <20080730075101.GA31668@1wt.eu>
Date:	Wed, 30 Jul 2008 09:51:01 +0200
From:	Willy Tarreau <w@....eu>
To:	David W Studeman <avionicsdv@....com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Keyboard Jammed error patch 2.4.35-pre4

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