Experimental Physics and
Industrial Control System

Ø  I will also try to make a thin vxWorks IOC application with basically just Industry Pack module support in case it is some strange interaction with another module.

 

A thin IOC with only seq, asyn, iocStats, ipac,  ip330, dac128V, and ipUnidig does not fail with base 7.0.6.1.

 

I will add things back in one at a time and see what is actually causing the problem. 

 

Luckily it is a gray and rainy day in Chicago. J

 

 

Ø  Ok, so all powerpc.  PPC Machine Check exception is asynchronous.

Ø  So I'm more confident in claiming the mention of "CAS-event" is false. 

Ø  The faulting instruction probably originates on some other scan/driver thread, then there is a context switch to "CAS-event" because of a call to db_post_events().

 

I’m not sure I understand the logic.  The other scan/driver threads are always running.  The IP330 is always interrupting at 2 kHz, and doing callbacks to device support.  It runs with no VME bus errors at all until I open an medm screen or run camonitor.  So it seems that the problem must be caused by having the CAS-event task do CA monitors, and it is not just that the CAS-event task is being incorrectly blamed for the problem?

 

I will try 7.0.6.

 

I will also try to make a thin vxWorks IOC application with basically just Industry Pack module support in case it is some strange interaction with another module.

 

Mark

 

 

-----Original Message-----
From: Michael Davidsaver <mdavidsaver at gmail.com>
Sent: Saturday, May 21, 2022 4:31 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: Re: Bus errors accessing VME with base 7.0.6.1 and latest synApps modules

 

On 5/21/22 11:05, Mark Rivers wrote:

> ØWhat specific board is involved?  (eg. mvme3100?)

>

> The test crate is an MVME5100.  But the production crates that were also failing include several MVME2700 boards as well as some MVME5100.

 

Ok, so all powerpc.  PPC Machine Check exception is asynchronous.

So I'm more confident in claiming the mention of "CAS-event"

is false.  The faulting instruction probably originates on some other scan/driver thread, then there is a context switch to "CAS-event" because of a call to db_post_events().

 

It still seems odd to me that the CPU could get all the way into db_post_events() and wake up "CAS-event" before a VME cycle completes.  (maybe there are VME timeout happening?)

 

 

In addition to Base 7.0.5 and and 7.0.6.1, could you test with 7.0.6 ?

 

This might narrow things down a little.

 

 

Since you already have a version range to suspect, you could try to narrow down further with git-bisect.

 

(although I can't honestly recommend this as a good way to pass what for me is a nice Saturday afternoon.)

 

https://git-scm.com/docs/git-bisect

 

> git bisect start R7.0.5 R7.0.6.1