svn commit: r205444 - head/sys/i386/i386

[Paul B Mahol]

On 3/23/10, Kostik Belousov <kostikbel at gmail.com> wrote:
> On Tue, Mar 23, 2010 at 09:35:09PM +0100, Paul B Mahol wrote:
>> On 3/23/10, Kostik Belousov <kostikbel at gmail.com> wrote:
>> > On Tue, Mar 23, 2010 at 08:21:31PM +0100, Ed Schouten wrote:
>> >> * Ed Maste <emaste at 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.

I have never found any driver that reports such symbol missing when loaded.