Re: workQPanic-Kernel work queue overflow while attempting async communication and thereafter initializing tyGSOctalModule with vxWorks

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

I suspect that is a crate we got for free from APS when they were upgrading. It is the less expensive version without the switches that allow missing modules.

Mark

Sent from my iPhone

On Oct 30, 2023, at 11:09 AM, Mrinal Bera <mrinalkb at uchicago.edu> wrote:

 Hi Mark,

As you suggested, moving all the cards to the left side with no module between them worked for this crate.

Thanks,

Mrinal

 

On Oct 28, 2023, at 8:46 PM, Mark Rivers <rivers at cars.uchicago.edu> wrote:

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