Executing FPU commands in kernel

Hello.

As common, when the device finish transfering block of data it
generates interrupt to say it's done. Just right after I have to
calculate some specific values and I need a few FPU commands. I do it
in a DPC and use the following commands

static char FPUContext[108];
...
fnsave [FPUContext] ; save FPU environment,
; data registers and do finit
fild
fld
fdivp
fimul
fistp

frstor [FPUContext] ;restore FPU environment and data registers
...

The question is am I alowed to do it in DPC under XP (I know that
under NT it is impossible due to bugs of context switch) or I have to
do it in a some kernel thread created earlier ?

P.S. After some time (an hour, a day) of device working I see various
BSOD...

Thanks in advance.

Calvin
Thu Oct 14 18:10:48 CDT 2004

I would use KeSave/RestoreFloatingPointState.

--
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
"Sinnet del Reccos" <trashy@ua.fm> wrote in message
news:9d0836aa.0410132145.1307c9ee@posting.google.com...
> Hello.
>
> As common, when the device finish transfering block of data it
> generates interrupt to say it's done. Just right after I have to
> calculate some specific values and I need a few FPU commands. I do it
> in a DPC and use the following commands
>
> static char FPUContext[108];
> ...
> fnsave [FPUContext] ; save FPU environment,
> ; data registers and do finit
> fild
> fld
> fdivp
> fimul
> fistp
>
> frstor [FPUContext] ;restore FPU environment and data registers
> ...
>
> The question is am I alowed to do it in DPC under XP (I know that
> under NT it is impossible due to bugs of context switch) or I have to
> do it in a some kernel thread created earlier ?
>
> P.S. After some time (an hour, a day) of device working I see various
> BSOD...
>
> Thanks in advance.

trashy
Fri Oct 15 01:06:11 CDT 2004

"Calvin Guan" <cguan@pleasenospam.ati.com> wrote:
> I would use KeSave/RestoreFloatingPointState.

AFAIK, those functions could not be used in a DPC or I am wrong ?

>> static char FPUContext[108];
>> ...
>> fnsave [FPUContext] ; save FPU environment,
>> ; data registers and do finit
>> fild
>> fld
>> fdivp
>> fimul
>> fistp
>>
>> frstor [FPUContext] ;restore FPU environment and data registers
>> ...
>>
>> The question is am I alowed to do it in DPC under XP (I know that
>> under NT it is impossible due to bugs of context switch) or I have to
>> do it in a some kernel thread created earlier ?

Doron
Sat Oct 16 12:40:26 CDT 2004

they can, see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k105_f004bc61-7a09-46d1-a9c3-dc2a76a03c43.xml.asp

place make sure to check the return from the function before proceeding
though.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Sinnet del Reccos" <trashy@ua.fm> wrote in message
news:9d0836aa.0410142206.13444f18@posting.google.com...
> "Calvin Guan" <cguan@pleasenospam.ati.com> wrote:
>> I would use KeSave/RestoreFloatingPointState.
>
> AFAIK, those functions could not be used in a DPC or I am wrong ?
>
>>> static char FPUContext[108];
>>> ...
>>> fnsave [FPUContext] ; save FPU environment,
>>> ; data registers and do finit
>>> fild
>>> fld
>>> fdivp
>>> fimul
>>> fistp
>>>
>>> frstor [FPUContext] ;restore FPU environment and data registers
>>> ...
>>>
>>> The question is am I alowed to do it in DPC under XP (I know that
>>> under NT it is impossible due to bugs of context switch) or I have to
>>> do it in a some kernel thread created earlier ?

trashy
Tue Oct 19 00:06:58 CDT 2004

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message news:

>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k105_f004bc61-7a09-46d1-a9c3-dc2a76a03c43.xml.asp

Thanx to all. Earlier I have comented the use of those functions
because it seemed to me (maybe coz of NT considerations) those
functions couldn't be used in a DPC.

Now I decommented those lines BUT still have BSOD on some computers,
ie on some machines under XP it doesn't hang and on some it does.

Does anybody know if I create a kernel thread and do all stuff about
transfering blocks of data and FPU there will it be more reliable ?

> place make sure to check the return from the function before proceeding
> though.

>> AFAIK, those functions could not be used in a DPC or I am wrong ?

Doron
Tue Oct 19 23:38:00 CDT 2004

if you create your own thread, you still have to use the
KeSave/RestoreFloatingPoint functions

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Sinnet del Reccos" <trashy@ua.fm> wrote in message
news:9d0836aa.0410182106.43e3d8c9@posting.google.com...
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message news:
>
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k105_f004bc61-7a09-46d1-a9c3-dc2a76a03c43.xml.asp
>
> Thanx to all. Earlier I have comented the use of those functions
> because it seemed to me (maybe coz of NT considerations) those
> functions couldn't be used in a DPC.
>
> Now I decommented those lines BUT still have BSOD on some computers,
> ie on some machines under XP it doesn't hang and on some it does.
>
> Does anybody know if I create a kernel thread and do all stuff about
> transfering blocks of data and FPU there will it be more reliable ?
>
>> place make sure to check the return from the function before proceeding
>> though.
>
>>> AFAIK, those functions could not be used in a DPC or I am wrong ?

trashy
Wed Oct 20 15:16:22 CDT 2004

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message news:

>> Does anybody know if I create a kernel thread and do all stuff
>> transfering blocks of data and FPU there will it be more reliable ?

> if you create your own thread, you still have to use the
> KeSave/RestoreFloatingPoint functions

Surely I have to.

The point is that I have interrupt fires very often - about few
interrupts per millisecond. And that irq flow is supposed to grow: the
more channels work on the device - the greater flow is...

To be able to queue the DPC in the ISR I use few DPC objects - 1 DPC
per channel.

Under DPC I have to form some information and move it to the header of
some big buffer (memory mapped section available in user & kernel
modes).

To form the header I use functions to get current time, correct the
time due to GMT, do FPU calculations, do some large_integer
calculations and RtlCopyMemory.

I'm just afraid of using all this stuff in DPC.

Maybe it is more safe to have a thread per channel (threads number <=
64), set event in a DPC, wait it in a thread and do all the work
there?

BUT, I dont know weather I would be able to receive event in a thread
and the next irq firing would not interrupt my previous header filling
in some thread...

I hope you (read as: "mind guys") here can insure that all can be done
in a some way like above without BSOD :)

Thanx for the answers.

Peter
Wed Oct 20 16:46:20 CDT 2004

do you control the format of the headers? If so, why not just pipe the data
in directly and let the user-mode application do all the time translations &
floating point math?

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sinnet del Reccos" <trashy@ua.fm> wrote in message
news:9d0836aa.0410201216.51c600f8@posting.google.com...
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message news:
>
>>> Does anybody know if I create a kernel thread and do all stuff
>>> transfering blocks of data and FPU there will it be more reliable ?
>
>> if you create your own thread, you still have to use the
>> KeSave/RestoreFloatingPoint functions
>
> Surely I have to.
>
> The point is that I have interrupt fires very often - about few
> interrupts per millisecond. And that irq flow is supposed to grow: the
> more channels work on the device - the greater flow is...
>
> To be able to queue the DPC in the ISR I use few DPC objects - 1 DPC
> per channel.
>
> Under DPC I have to form some information and move it to the header of
> some big buffer (memory mapped section available in user & kernel
> modes).
>
> To form the header I use functions to get current time, correct the
> time due to GMT, do FPU calculations, do some large_integer
> calculations and RtlCopyMemory.
>
> I'm just afraid of using all this stuff in DPC.
>
> Maybe it is more safe to have a thread per channel (threads number <=
> 64), set event in a DPC, wait it in a thread and do all the work
> there?
>
> BUT, I dont know weather I would be able to receive event in a thread
> and the next irq firing would not interrupt my previous header filling
> in some thread...
>
> I hope you (read as: "mind guys") here can insure that all can be done
> in a some way like above without BSOD :)
>
> Thanx for the answers.

trashy
Thu Oct 21 14:41:20 CDT 2004

"Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote in message news:

> do you control the format of the headers?

Yep.

> If so, why not just pipe the data
> in directly and let the user-mode application do all the time translations &
> floating point math?

Because of small data blocks. I need to refresh the header very quick.
Data is refreshed within half of millisecond. And the header should
also be updated right after new block of data is written to the
buffer.

I will not be able to say to user application to update the header
even every millisecond without "tips & tricks" with the OS. Or there
is a common way of a such realtime-like OS behaviour ?

>>>> Does anybody know if I create a kernel thread and do all stuff
>>>> transfering blocks of data and FPU there will it be more
>>>> reliable?

[skipped]

>> Maybe it is more safe to have a thread per channel (threads
>> number <= 64), set event in a DPC, wait it in a thread and
>> do all the work there?

>> BUT, I dont know weather I would be able to receive event in a
>> thread and the next irq firing would not interrupt my previous
>> header filling in some thread...

Peter
Thu Oct 21 16:03:37 CDT 2004

i didn't mean to say that the user-mode application should update the
headers as you write them. but it seems like it could trivially apply
time-zone changes to a timestamp that it read from the header rather than
having your driver do it.

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sinnet del Reccos" <trashy@ua.fm> wrote in message
news:9d0836aa.0410211141.146660ba@posting.google.com...
> "Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote in message
> news:
>
>> do you control the format of the headers?
>
> Yep.
>
>> If so, why not just pipe the data
>> in directly and let the user-mode application do all the time
>> translations &
>> floating point math?
>
> Because of small data blocks. I need to refresh the header very quick.
> Data is refreshed within half of millisecond. And the header should
> also be updated right after new block of data is written to the
> buffer.
>
> I will not be able to say to user application to update the header
> even every millisecond without "tips & tricks" with the OS. Or there
> is a common way of a such realtime-like OS behaviour ?
>
>>>>> Does anybody know if I create a kernel thread and do all stuff
>>>>> transfering blocks of data and FPU there will it be more
>>>>> reliable?
>
> [skipped]
>
>>> Maybe it is more safe to have a thread per channel (threads
>>> number <= 64), set event in a DPC, wait it in a thread and
>>> do all the work there?
>
>>> BUT, I dont know weather I would be able to receive event in a
>>> thread and the next irq firing would not interrupt my previous
>>> header filling in some thread...

trashy
Fri Oct 22 01:04:51 CDT 2004

"Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote in message news:

> i didn't mean to say that the user-mode application should update the
> headers as you write them. but it seems like it could trivially apply
> time-zone changes to a timestamp that it read from the header rather than
> having your driver do it.

There is no difference: apply only time-zone changes to the header or
do all the work about the header. It should be "atomic" operation in
user mode or in a kernel after another small block of data received...

It is done in kernel because there are lots of small blocks comming
copied to the buffer before I can update the header of this buffer in
a user-mode application (which should be updated after EACH block of
data).

>> Because of small data blocks. I need to refresh the header very
>> quick. Data is refreshed within half of millisecond. And the
>> header should also be updated right after new block of data is
>> written to the buffer.

>> I will not be able to say to user application to update the header
>> even every millisecond without "tips & tricks" with the OS. Or
>> there is a common way of a such realtime-like OS behaviour ?