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. 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 -MaximReceived on Tue Apr 27 2010 - 18:26:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC