On Tue, Apr 27, 2010 at 12:04 PM, John Baldwin <jhb_at_freebsd.org> wrote: > On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote: >> John Baldwin wrote: >> > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: >> >> John Baldwin wrote: >> >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: >> >>>> Maxim Sobolev wrote: >> >>>>> There is already a code to detect non-existing AT keyboard and avoid >> >>>>> attaching atkbd to it. The code is i386-only at the moment, I am > trying >> >>>>> to figure out how to modify it so that it works on amd64 as well. >> >>>> Looks like this huge delay is caused by the inb() being astonishingly >> >>>> slow, which is not factored by the timeout routines. Reading keyboard >> >>>> status port once takes about 0.003s! I am not sure if it's common >> >>>> behaviour of the platform, or something specific to this particular >> >>>> model. Do you know by any chance? >> >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard > ports so >> >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do > you have >> >>> any BIOS options related to the USB legacy compat? I know of the > Nehalem >> >>> systems I've seen they have a separate option for controlling port 60/64 >> >>> emulation which we leave disabled by default. >> >> That makes sense. Unfortunately I don't have access to the BIOS >> >> settings. This is a hosted system, and the provider keeps BIOS password >> >> for themselves. >> >> >> >> I have a patch that fixes that issue by measuring status register >> >> reading time first and then factoring it in the calculations of the >> >> number of retries: >> >> >> >> http://sobomax.sippysoft.com/atkbdc.diff >> >> >> >> It also applies the same logic to detect broken/non-existing keyboard >> >> controller to amd64 as we do to the i386. I'd appreciate if you can do a >> >> review. >> > >> > Hmm, not all i386 CPUs that we support have a TSC. Is the change to >> > atkbdc_isa.c sufficient to fix the hang? If so, I'd rather just commit > that >> > bit and leave out the read_delay changes. >> >> No, it's not sufficient. The problem here is that for some reason that >> test passes on that system (probably emulation works) and so that normal >> keyboard attach routine is invoked early in boot, when we don't even >> have clock initialized. What if I make TSC-related changes amd64? Will >> that be OK? > > 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? S5520UR, Intel BIOS 48 (last 2 digits), Build 2/27/10. If I disable 60/64 emulation the box refuses to go into the BIOS or boot anything. The BIOS just simply hangs after the Intel logo screen. This just seems like a bug. On the last generation Alcolu based machines, we usually have 60/64h emulation disabled which works just fine (USB Legacy Mode is still enabled so things like the debugger still/kinda/sorta work). I will work through our Intel channels to have them look at this (we already discovered some other bugs with respect to flashing and RMM3). I am looking at the atkbd driver for the first time. It would seem to me at first glance that John makes a very good point: there is already code to deal with a lack of a keyboard in the i386 code. I would *assume* that turning it on for amd64 would be all that is necessary? Btw these systems also fail other keyboard related tests. I also see: "atkbd: unable to set the command byte." On all Nehalem systems (this might be less serious given the OS has taken over from the BIOS). I am testing a variant of Maxim's patch right now. Stay tuned, -apsReceived on Tue Apr 27 2010 - 17:11:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC