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< -------------------------------
- Navigate by Date:
- Prev:
dm macro arithmetic Ian A Smith
- Next:
Re: dm macro arithmetic Bob Dalesio
- 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
- Navigate by Thread:
- Prev:
Re: dm macro arithmetic Bob Dalesio
- Next:
passing a string to a subroutine record Geoff Savage
- 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
|