I had seen a similar error on MVME162 processors many years ago,
in a non-EPICS environment.
I worked with WRS to try to resolve it, or work around it -
unsuccessfully.
In the end, we moved these processors to an isolated network -
separate from other VME processors - to minimize the volume of
network traffic they were exposed to. We never saw the problem after
that.
My (hand-wavy) conclusion is that the network driver for the MVME162
can get "overwhelmed" and lock up under certain circumstances - nothing
(necessarily) to do with EPICS.
HTH -- Larry
On 6/23/2010 9:19 AM, Benjamin Franksen wrote:
> From the console log:
CAS: request from 192.168.21.6:46187 => "CAS: Missaligned protocol
rejected"
[Sun Jun 20 05:23:20 2010]CAS: Request from 192.168.21.6:46187 =>
cmmd=49320
cid=0x91f87157 type=48940 count=5064 postsize=5587
[Sun Jun 20 05:23:20 2010]CAS: Request from 192.168.21.6:46187 =>
available=0xcb45c46e N=1 paddr=0x0
[Sun Jun 20 05:23:20 2010]CAS: invalid (damaged?) UDP request from
192.168.21.6:46187 ?
[Sun Jun 20 05:23:30 2010]interrupt:
[Sun Jun 20 05:23:30 2010]ei0: reset
This is base 3.14.8.2 and VxWorks 5.4.2. Looks like one or more
corrupt UDP
packages arrived at the IOC. The problem is that after the last message
("ei0: reset") the IOC is dead to the network (neither transmits nor
receives anything). No way to recover, other than rebooting.
The question is: what does the CA server do after it outputs these error
messages? Could it be it does something to the socket that makes vxWorks
throw up hands and strike? Also, note the 10 second delay between the
CAS
message and the vxWorks message.
Is this a known bug in VxWorks? In the CAS?
Cheers
Ben