EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20232024  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  <20232024 
<== Date ==> <== Thread ==>

Subject: Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: Mrinal Bera <mrinalkb at uchicago.edu>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Sun, 29 Oct 2023 01:46:20 +0000
One possibility is the crate itself. Some crates do not pass interrupts if there are any empty slots between the CPU module and the last card. Try moving all cards to be packed on the left side of the crate with no empty slots, unless you are certain this crate does not require that.

Mark


Sent from my iPhone

On Oct 28, 2023, at 7:44 PM, Mrinal Bera <mrinalkb at uchicago.edu> wrote:


Hi Mark,
Yes, TVME address and interrupt vector are set through switches and both software and hardware values are being matched. I have two other MaxV boards along with the TVME board. The MaxV boards are initialized by:

MAXvSetup(2, 16, 0x2000,     190, 5, 10) 

MAXvConfig(0, "AX LH PSE; AY LH PSE ; AZ LH PSE ; AT LH PSE ; AU LH PSE ; AV LH PSO; AR LH PSO; AS LH PSO;”)

MAXvConfig(1, "AX LH PSO; AY LH PSO; AZ LH PSO; AT LH PSO; AU LH PSO; AV LH PSO; AR LH PSO; AS LH PSO;”)


As I mentioned, I can boot the vxWorks on switching ON the VME crate without any errors. The workQPanic-kernel is invoked for the first time, once I start asyn communication through RS-232 ports of tyGSOctal module. After the vxWorks keeps on rebooting when the tyGSOctalModuleInit command is executed from the st.cmd script. 

I have tested the TVME-200 module with the same settings in another VME crate with MVME3100 where it works perfectly. In the current case, I am setting up a new crate with new MVME3100 and existing MaxV and TVME-200 modules. Do you think I  need to setup anything in the new MVME3100 board?

Best,
Mrinal



Mrinal Kant Bera, PhD
NSF’s ChemMatCARS
The University of Chicago
9700 S Case Ave Bldg 434D
Argonne, IL 60439
United States

Ph: +1-630-252-0472

On Oct 28, 2023, at 6:44 AM, Mark Rivers <rivers at cars.uchicago.edu> wrote:

 Are you sure that you have configured the base address and interrupt vector on the TVME200 correctly? Is that done with switches?  The software and hardware need to agree. Have you checked for potential interrupt vector conflicts with other boards?

Mark

Sent from my iPhone

On Oct 28, 2023, at 12:13 AM, Mrinal Bera via Tech-talk <tech-talk at aps.anl.gov> wrote:


Hello,
While working with vxWorks 6.9.4 on MVME 3100 with TVME 200 and XM Octal modules, I get the following error whenever tried to start any asyn communication.

workQPanic: Kernel work queue overflow.
 
Exception at interrupt level:
Regs at 0x0
 
Exception at interrupt level:

data storage
Exception current instruction address: 0x0026bb84
Machine Status Register: 0x00001230
Data Exception Address Register: 0x01309ff0
Condition Register: 0x28002444
Exception Syndrome Register: 0x00800000
Regs at 0x1309f98


Press any key to stop auto-boot...
 6

After that, the system reboots automatically and then keeps showing the same error while initializing tyGSOctalModule as can be seen below:

# tyGSOctalModuleInit(char *name, charBooting mv3100...


workQPanic: Kernel work queue overflow.
 
Exception at interrupt level:
Regs at 0x0
 
Exception at interrupt level:

data storage
Exception current instruction address: 0x0026bb84
Machine Status Register: 0x00001230
Data Exception Address Register: 0x01309ff0
Condition Register: 0x28002444
Exception Syndrome Register: 0x00800000
Regs at 0x1309f98


Press any key to stop auto-boot...
 6

This error repeats on every auto reboot unless the VME crate is switched OFF and switched ON again. 

I saw a very old tech-talk thread on this error: https://epics.anl.gov/tech-talk/1999/msg00470.php

I could understand that its something to do with too many interrupts happening but couldn’t figure out how to get rid of this issue.

Here is my ipac and serial setup:


ipacAddTVME200("601fa2")

tyGSOctalDrv(2)

tyGSOctalModuleInit("UART0","232", 0x80, 0, 0)
tyGSAsynInit("serial1""UART0", 0, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial2""UART0", 1, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial3""UART0", 2, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial4""UART0", 3, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial5""UART0", 4, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial6""UART0", 5, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial7""UART0", 6, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")

tyGSAsynInit("serial8""UART0", 7, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n”)

tyGSOctalModuleInit("UART1", "232", 0x81, 0, 1)
tyGSAsynInit("serial9""UART1", 0, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial10""UART1", 1, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial11""UART1", 2, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial12""UART1", 3, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial13""UART1", 4, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial14""UART1", 5, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")
tyGSAsynInit("serial15""UART1", 6, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n")

tyGSAsynInit("serial16""UART1", 7, 9600, 'O', 1, 7, 'N', "\r\n", "\r\n”)

dbLoadTemplate("substitutions/asynRecord.substitutions”)

Any ideas on how to get rid of this error?

Thanks and regards,
Mrinal



Replies:
Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks Mrinal Bera via Tech-talk
References:
Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks Mark Rivers via Tech-talk
Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks Mrinal Bera via Tech-talk

Navigate by Date:
Prev: Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks Mrinal Bera via Tech-talk
Next: XSPRESS3 Parameter confusion John Dobbins via Tech-talk
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  <20232024 
Navigate by Thread:
Prev: Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks Mrinal Bera via Tech-talk
Next: Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks Mrinal Bera via Tech-talk
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  <20232024 
ANJ, 30 Oct 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·