[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080730123839.GA2397@1wt.eu>
Date: Wed, 30 Jul 2008 14:38:39 +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 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
--
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