RE: asyn driver problem running Linux 3.8.13 with arm processor

["Jim Chen" <jim.chen@hytec-electronics.co.uk>]

Hi Mark,

Last time we discovered that those functions cannot be used in interrupt
service routine and I think that makes sense. 

The queuetask is a message queue created by epicsMessageQueueCreate waiting
interrupt in a thread created by epicsThreadCreate. The strange thing is
that in other arch and Linux, it works fine. Is it anything to do with arm
processor or the 3.8.13 Linux distro or the gcc compiler?

Thanks,
Jim 
 


> -----Original Message-----
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: 07 February 2014 15:10
> To: Jim Chen; tech-talk@aps.anl.gov
> Subject: RE: asyn driver problem running Linux 3.8.13 with arm processor
> 
> I don't know anything about the queuetask, but I have a guess about what
> could be causing the problem.  The getIntegerParam, etc. functions use C++
> try/catch blocks, because the underlying classes can throw exceptions.
> 
> Perhaps exceptions are not allowed in queuetask?
> 
> Mark
> 
> ________________________________________
> From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on
> behalf of Jim Chen [jim.chen@hytec-electronics.co.uk]
> Sent: Friday, February 07, 2014 8:47 AM
> To: tech-talk@aps.anl.gov
> Subject: asyn driver problem running Linux 3.8.13 with arm processor
> 
> Hello,
> 
> Has anybody experienced segmentation fault when using asynPortDriver
> parameter interfaces such as
> 
>         getIntegerParam
>         setIntegerParam
>         setDoubleParam
> 
> in the queuetask in Linux 3.8.13 for arm processor?
> 
> My environment is an EPICS application on BeagleBone Black:
> 
>         Platform: BeagleBone Black
>         Processor: ARMv7 Processor rev 2 (v7l)
>         Linux distro: Angstrom Linux version 3.8.13 (koen@rrMBP) (gcc
version
> 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Thu Sep
12
> 10:27:06 CEST 2013
>         EPICS R3.14.12.3
>         Asyn4-22/4-18
> 
> Everything else works fine until an interrupt which wakes up the
queuetask.
> Inside the queuetask, any of those parameter interfaces causes the
> segmentation fault.
> 
> I have tried the same code in other arch like Intel but running Scientific
Linux
> without problem.
> 
> Any idea?
> 
> Thanks,
> Jim
>