Experimental Physics and
Industrial Control System

[email protected] · Thu, 17 May 2001 09:34:53 +0200

Hi All,

we encountered a serious problem using the new Motorola Petra boards
(MVME162-PAxxx) together with the VxWorks kernel compiled for the
former MVME162 series and the standard mv162-BSP.

The kernel reboots the CPU after some time because of problems dealing with
interrupts from the ethernet chip. 

You have to patch the BSP or exactly the file sysLib.c to get the Petra
boards running well (I´ve attached the information from WindRiver).

After implementing this patch the boards are running well up to now.

Cheers and good luck...
-- 

Joachim

------------+-----------------------------+--------------------------------
 BESSY mbH  | Albert-Einstein-Strasse 15  | Phone : (+49) 30 / 6392 - 4864
            | D - 12489 Berlin, Germany   | Fax   :                 - 4859
            | http://www.bessy.de/        | mailto:[email protected]
------------+-----------------------------+--------------------------------

----- 8< -------------------------------	
Title: mv162 BSP does not correctly handle ethernet transceiver interrupts 
when the Motorola PETRA boards are used

PROBLEM_DESCRIPTION

  The PETRA boards are recent boards from Motorola and are considered to be
  software compatible with the old MVME162 cards.

  Several customers reported that occasional network blocks occurred with
  the ei82596End or the if_ei driver when the new boards are used instead of
  the old ones.
  This problem could be reproduced by the customers for vxWorks 5.2,
  vxWorks 5.3.1 and vxWorks 5.4.  (The boards could recover temporarily
  from the network block when the
  boards have been pinged from the outside).
  The problem does not manifest easily under normal conditions.  But it can
  be readily reproduced by generating a high interrupt load and
  executing at the same time the blaster-blastee test.

  TEST CASE

  Using the standard blaster-blastee code from WindSurf and two vxWorks
  targets,
  I could reproduce the problem.  The blaster was a VME162PA 344SE board
  running vxWorks 5.4 (see setup.log below).
  Blastee was a Pentium 2 (266 MHz) coolmonster board with the Intel 82559
  ethernet chip (fei82557End driver corrected for SPR 30361).

  The following code was executed:

  Blastee:
  -> sp (blastee,
  7000,
  1000000,
  8760)

  Blaster:
  -> sp auxTest
  -> sp (blaster,
  "192.168.4.8",
  7000,
  1000000,
  8194)

  auxTest() generates 300 interrupts per second on the auxiliary clock 
  (code added below).
  A short dummy ISR executes each time an interrupt of the auxiliary clock 
  is generated.
  This is only for imposing a certain interrupt load on the vme162 board.
  Under these conditions the network block can be reproduced after ca.
  5 minutes.
  The network show routines and the driver show routines show nothing 
  abnormal during the network block (see TSR 231722 for details).
  The only things to note in case of the network block are:

  -> eiShow
  cbl head=0x38754c tail=0x387b4a
  free head=0x38ab3a tail=0x386f4e
  clean head=0x0 tail=0x386f4e
  tx head=0x388148 tail=0x38a53c
  rx head=0x350170 tail=0x34f568
  ei0: END_CTRL=0x3b0f08 flags=0x14 txIdle=0 txCleaning=0 rxHandling=0
  ei0: rxLockups=0 txLockups=0 resetCount=0
  ei0: txQ -- cbl=2 free=119 clean=0 txQueue=7 nLoan=-59794
  ei0: rxQ -- count=128
  value = 0 = 0x0

  -> inetstatShow
  Active Internet connections (including servers)
  PCB      Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
  -------- ----- ------ ------  ------------------ ------------------ -------
  3b9984   TCP        0   8162  192.168.4.15.1024  192.168.4.8.7000 
  ESTABLISHED
  value = 1 = 0x1

  Note the value of txQueue as reported by eiShow.
  This value will increase with the time if the target is not pinged from 
  the outside.
  Note also the size of TCP send queue as reported by intetstatShow.

  RESOLUTION

  Motorola pointed me to "Application Note 1 - Interrupt Enable Bits" of 
  the PETRA Errata (Version 0.5 4-3-01).
  There it is stated:

  ---
  4.1 Application Note 1 - Interrupt Enable Bits
  The interrupt enable bit for edge sensitive interrupts works differently
  in PETRA than it does
  in the original MC and IP chips.  In the original chips, if the interrupt
  is disabled the flip flop will still capture the edge but the interrupt
  will be blocked.  If the interrupt is enabled at a later time, an
  interrupt will be generated.  In PETRA, when the interrupt is disabled,
  the flip flop is held in the reset state and will not capture the
  interrupt.  Therefore, if the enable bit is used to mask the interrupt,
  it's possi-ble to miss the interrupt.  Normally software uses the
  processor mask register to temporarily inhibit
  interrupts.
  However, if the application does mask interrupts using the enable bits, a
  possible work around would be to mask the interrupt by changing the
  interrupt level to 0.
  ---

  Consequently,
  sys596IntDisable() in sysLib.c needs to be changed for the PETRA boards.

  From

  *MCC_LANC_IRQ_CR &= ~LANC_IRQ_CR_IEN;*/     /* Clear the enable bit only */

  to

  *MCC_LANC_IRQ_CR &= ~ABORT_IRQ_LEVEL; /*interrupt level 0 => no interrupt*/

  After making this modification,
  the above test case run fine for me for more than 16 hours,
  i.e.
  till the test was stopped by me.
  This test result was confirmed by the customer.
----- 8< -------------------------------	

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System