Date: Thu, 22 Jan 2009 15:29:12 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: usb keyboard vs btx: an SMI theory Message-ID: <497874A8.3070205@icyb.net.ua> In-Reply-To: <200901211407.44021.jhb@freebsd.org> References: <4947AA3C.4040005@icyb.net.ua> <200901211407.44021.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 21/01/2009 21:07 John Baldwin said the following: > On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: >> Again, I am very fuzzy about the exact details, but I think that this is >> something that could be happening and I think that SMI is of primary >> interest here. I also think that this might explain to a certain degree >> the difference in behavior between "older" btx and "newer" btx. > > One thing to keep in mind is that when an SMI# is delivered, the processor > enters System Management Mode (SMM). In SMM, the CPU actually uses a > different set of memory for its RAM. It also runs in a sort of weird 32-bit > real mode. It is not going to call the stock IRQ 1 handler. Instead, it > passes data back to "normal" mode by changing the values restored into > registers when exiting SMM. Typically doing an I/O port access to the ports > backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler > emulates the inb/outb request by storing the resulting data for an inb in > the %ax register the "normal" mode sees once it resumes execution after > the 'inb' instruction. > I've been thinking about that and also decided that my SMI theory is rubbish. On the other hand, I still suspect that there could be some race in protected<->real transition, but from looking at the code I can not imagine how it could happen. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497874A8.3070205>