John Baldwin wrote:
On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c change first of
all. I'm still thinking about the other change. I wonder if we can figure
out that a keyboard isn't present sooner somehow? Do you know if the keyboard
appears to be present but just slow vs if the keyboard is eventually found to
not be present?
Our syscons does keyboard probing two times - once early during kernel
initialization before most of the subsystems have been initialized yet,
and then "real" probing later in boot process. Interesting thing is that
initially keyboard looks present. Reading status port in
atkbdc_configure() gives value other than 0xff, although reading is
thousand times slower than usually. This causes syscons try attaching
it. Even though reading status port works, apparently either emulation
is not complete or there is some other issue, so that it never responds
to some commands. Slow access and lack of response results in
wait_for_data() function waiting several minutes instead of 200ms as
designed. This what causes that 6-10 minutes delay in boot process.
I believe the USB driver has disabled the keyboard emulation by the time the
second probe happens in syscons. Can you try disabling legacy USB support in
the BIOS just to make sure that is what causes the delay?
Unfortunately it's not possible. Hosting provider doesn't allow me to
have access to BIOS settings.
In fact I've also tried sending 0xAA command instead of just checking
that value read from the status port is not 0xFF, and it actually
completed fine at this point. The controller has returned 0x55 as
expected. Therefore, I believe measuring inb() delay is the only
reasonable way to avoid that big boot delay at this point.
Later on, when we probe/attach keyboard second time (in atkbdc_isa.c)
reading status port returns 0xff, so the we can fail attachment process
immediately. However, this is not a big issue since at this point
reading from status port is as fast as any other ISA inb() operations,
so it doesn't cause any noticeable delay.
Here is the latest version of the patch:
http://sobomax.sippysoft.com/atkbdc.diff
Hmm, still has the issue that we can't assume a TSC on i386. I would still
commit the easy bits to change various '#if defined(__i386__)' to
'#if defined(__i386__) || defined(__amd64__)' now.
One thing that could make this cleaner would be to have a macro defined
something like this in atkbdc.c:
/* CPU will stay inside loops for 100msec at most. */
#ifdef __amd64__
#define KBD_RETRY(kbd) (100000 / ((KBDD_DELAYTIME * 2) +
kbdc->read_delay))
#else
#define KBD_RETRY(kbd) (5000)
#endif
and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places.
Please take a closer look. Use of rdtsc() in this version is conditonal
on __amd64__ only.
-Maxim
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
