> function in sys/arch/sparc64/dev/comkbd_ebus.c, it seemed that in
> order for the "no keyboard" statement to be printed that code tried and
> failed the keyboard reset sequence five times.
That's right.
> Using your assumption that the keyboard was not handling the
> reset sequence (or being slow about it), I increased the delay period
> from 1 millisecond (1000 microseconds) to 3 milliseconds (3000
> microseconds) for each of the three portions of the comkbd_init()
> function (each call to DELAY() in comkbd_init() function).
>
> Rebuilt the kernel, and gave it a try. I am happy to report that I
> have booted the computer three times with the SV 125 converter (and a
> PS2 keyboard hooked up), and each time it was properly handled and
> worked well.
Now that's good news! But turning the `ltries = 1000' to `ltries = 3000'
will cause a systems with no keyboard to wait 15 seconds, instead of 5
seconds, at boot time, and this will be horribly annoying (the existing
5 seconds are barely tolerable).
Could you print the value of `ltries' after each of the three loops
exits? This would give us a rough estimate of the real time it takes for
your converter to reply. I'd expect the first loop to take some time,
and the last two to be quick.
We could then change the first
ltries = 1000;
statement to something like
ltries = tries >= 4 ? 2500 : 1000;
to only increase the `missing keyboard' delay from 5 to 8 seconds (with
these values, hopefully these can be lowered even more).
Miod
