On Tue, Mar 23, 2010 at 09:35:09PM +0100, Paul B Mahol wrote: > On 3/23/10, Kostik Belousov <kostik...@gmail.com> wrote: > > On Tue, Mar 23, 2010 at 08:21:31PM +0100, Ed Schouten wrote: > >> * Ed Maste <ema...@freebsd.org> wrote: > >> > I was just about to follow up with a comment to that effect. We do want > >> > it to become a panic, but I would prefer to hold off until we address > >> > the known issue with padlock(4). > >> > >> I have seen this message appear when using the ndisulator as well. How > >> are we going to solve it in this case? Could the ndisulator be extended > >> to prepare a FPU context using kib's new API? > > > > I looked at http://msdn.microsoft.com/en-us/library/aa489566.aspx > > after someone mentioned ndisulator. It seems that windows requires > > that i386 drivers carefully use braces for use of FPU, while amd64 > > code allowed to use it freely. That suggests that windows clears > > TS on kernel mode entry or driver calls, that seems to be too > > wastefull. > > > > I would very much appreciate the help with changing both ndis and > > padlock to use fpu_kern_enter/leave KPI, since I do not use them. > > I need some time to polish the patch before. > > > > I saw fpudna only on amd64, but I never managed to get ndisulator > fully working on amd64 (at least with broadcom card/driver).
I cannot find KeSaveFloatingPointState symbol defined by ndisulator. Could it be that it is a macro or inline function that expands to proper assembly for i386, and nop on amd64 ? That would explain your observation.
pgpiRjI8MLMJj.pgp
Description: PGP signature