Re: Fwd: realtime performance of adl_pci9118

hi, Calin and Michal
 thank you for your instruction, but i can't resolve the provlem up to now.
 1: for the TRIG_WAKE_EOS, i try to find where to set or clear the bit, then
i
 find the following lines in the file kcomedilib_main.c:
  if(async->cb_mask & COMEDI_CB_EOS)
cmd->flags |= TRIG_WAKE_EOS;
 in my user code, there is nothing about it. i am confused how to clear this
bit.
 2: i found that my card uses bus mastering, but then how?
 3: my system now will often apear the following messages
  "unexpected FPU trap from hard PID="
 i think this may due to my CPU which is an AMD xp2500 working at xp3200,
the cpuinfo is:
 processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 3200+
stepping : 0
cpu MHz : 2205.002
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 4404.01
 thank you
 regards,
 wicky

 On 10/16/05, Calin A. Culianu <calin_at_ajvar.org> wrote:
>
>
>
> On Thu, 13 Oct 2005, wicky Zhang wrote:
>
> > ---------- Forwarded message ----------
> > From: wicky Zhang <wicky.zhang_at_gmail.com>
> > Date: Oct 13, 2005 9:22 PM
> > Subject: Re: realtime performance of adl_pci9118
> > To: Michal Dobes <dobes_at_tesnet.cz>
> > Cc: rtai_at_rtai.org
> >
> >
> >
> > do you use cmd->flags|=TRIG_WAKE_EOS ?
> >> If yes, then after every sample is generated interrupt and 50
> >> kinterrupts/s
> >> will kill any system.
> >
> > I have not do that operation, but would you tell me how to check this
> > setting
> > or reset it?
>
> Just make sure cmd->flags doesn't contain the TRIG_WAKE_EOS bit.
> If you didn't set it, it should be off by itself (you *did* memset() your
> comedi_cmd struct to 0, right? Either that or it is a global var,
> right?).
>
> If you want to be paranoid (something I always encourage), read the
> sources to your driver to make sure it doesn't default to have the board
> interrupt after each scan -- if it does that (and the driver supports
> not-interrupting-after-each-scan) that's a bug.
>
> Also, as someone else suggested, try and make sure the board is doing DMA
> transfers (by figuring out if the driver is using DMA).
>
> -Calin
>