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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/