I have now built about six kernels for this and none of them come up
right - they all refuse to acknowledge the keyboard, and the mouse is
jerky and erratic.
I have checked the config to make sure that USB HID devices are
recognized, and that the keyboard is the right one (AT). I have tried
unplugging and re-plugging the keyboard, switching their positions on
the LCD hub, even plugging directly into the motherboard - nothing
works.
Is there a bug or other problem in the standard USB driver for 42.0.8?
This is frustrating, and it has halted my development. I should be able
to build and run the straight distro rpm without this kind of grief,
shouldn't I?
Suggestions, comments, etc. welcome.
-----Original Message-----
From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
Behalf Of Mark Hull-Richter
Sent: Friday, February 09, 2007 10:33 AM
To: CentOS mailing list
Subject: CentOS 2.6.9-42.0.8 issue - no keyboard after reboot
I did this twice now, although the first couple of builds seemed to work
ok, they just weren't configured quite right.
On my third and fourth builds of the 42.0.8 kernel rpm, when booting,
kudzu came up and ran, but the keyboard was somehow not recognized and I
had to reboot using the mouse on the login screen (no text appears no
matter what I type).
I'm using the rpm build strategy from Jim's wiki, which works nicely,
but my fallback is a 42.0.3 non-smp kernel.
My main question, though, is how did this happen? Is there a config
switch or something else I missed? I'm using the base
kernel-2.6.9-x86_64-smp.config, and tweaking it to include ext3 and xfs
in the kernel (instead of loadable ext3 and no xfs).
Why?
Well, we need xfs to load so we can find out why it's so damned slow on
cached vs. direct i/o. We have some tweaks we put into xfs (current
version, using SuSE Linux 9.something) in order to be able to control
the way the extents are allocated. We need to be able to do large i/os
in large chunks quickly, and that kind of allocation works better than
little pieces all over the place. (We're looking at 8Mb chunks and
larger.) With direct i/o, we can get around 30-40Mb/s transfer rates,
but with cached (i.e., kernel) i/o, we are stuck at 8, which is too
slow. It turns out we get better performance from jfs, but we want to
use xfs because it is faster with our changes.
The main issue here, though, is the failure of CentOS 2.6.9-42.0.8 to
recognize the keyboard - why would that happen?
Thanks.
mhr
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
