RE: asyn driver problem running Linux 3.8.13 with arm processor

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

Thanks for everybody's help.

It finally turns out to be a bug in my interrupt mechanism down to the
device driver/API function level -- a wrong (and redundant) pointer
assignment code. Funny enough the same code receives no complain in other
Linux distro like Redhat, Debian etc but with 2.6.x kernel though.

This also means that EPICS (R3.4.12.3) and asyn driver (4-22) work no
problem in ARM based processor (BeagleBone Black at least) and Angstrom
Linux.

Thanks again,
Jim

-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
On Behalf Of Till Straumann
Sent: 07 February 2014 18:23
To: tech-talk@aps.anl.gov
Subject: Re: asyn driver problem running Linux 3.8.13 with arm processor

I would also suggest that you provide as much detail as you can (e.g.,
complete code) rather than snippets.


On 02/07/2014 09:13 AM, Andrew Johnson wrote:
> Hi Jim,
>
> On 02/07/2014 10:38 AM, Jim Chen wrote:
>> while(1) {
>>          /* Wait for event from interrupt routine */
>> printf("====before\n");
>>         epicsMessageQueueReceive(intMsgQId, data, sizeof(data));
>> printf("====queue responsed\n");
>> }
> What does the code at the other end of the message queue look like? Does
> it get called from interrupt context, or from task-level?
>
> The problem might be that you can't use C++ code inside an ARM ISR (I
> don't know whether that's true or not, but it's conceivable), and since
> the libCom/osi/os/default/osdMessageQueue.cpp implementation is written
> in C++ the problem is with the choice of using the epicsMessageQueue
> inthe first place. As I said I don't know whether that is a restriction
> but it's something you should check.
>
> - Andrew



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com