1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Bus errors accessing VME with base 7.0.6.1 and latest synApps modules |
From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
To: | Michael Davidsaver <mdavidsaver at gmail.com> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Sat, 21 May 2022 23:45:35 +0000 |
Ø
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 From: Mark Rivers
Ø
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----- 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 |