PEA0 error

[Mark Berryman]

I'm trying to add an x86 system into my current cluster but upon boot
the x86 system shows the following error and never sees the existing
cluster members:

%EIA0, Link up: 1000 mbit, fdx, flow control (rcv only), 00-0C-29-19-61-FE
%PEA0, Port Transition Failure - CNF/PMC/PSR 00000000/00000000/00000014

What does this error mean? I'm assuming that PSR is a status register
and I need to find out what the 2 bits that are set mean.

Mark Berryman

[Steven Schweda]

> I'm trying to add an x86 system [...]

Thanks for that detailed description.

> %EIA0, Link up: 1000 mbit, fdx, flow control (rcv only), 00-0C-29-19-61-FE
> %PEA0, Port Transition Failure - CNF/PMC/PSR 00000000/00000000/00000014

> What does this error mean? [...]

All I know is what I read in the documentation...

help /mess Port Transition Failure CNF

Port Transition Failure - CNF/PMC/PSR 'xxxxxxxx/xxxxxxxx/xxxxxxxx'

Facility: Cluster Port Driver

Explanation: The port driver attempts to reinitialize the port; after
50 failed attempts, it marks the device off line.

User Action: Contact HP Customer Support to check the port hardware.


I wouldn't be amazed if someone who did know something asked what
EIA0 actually was. Or even which software was involved.

[Stephen Hoffman]

Classically this is a wonky or bad NIC, and seemingly involving EIA0:,
or—probably more likely here—a bug in whichever flavor of V9.1 you're
using.
The Port Status Register / Adapter Status Register bit definitions are
also device-dependent, AFAICT.
Have a chat with VSI, given that you're running V9.1, and the existing
doc may not apply to what you're doing here.
(I haven't checked the V9.1 release notes for any listed
cluster-related errors or requirements, either.)

Port Error Bit(s) Set - CNF/PMC/PSR ’xxxxxxxx/xxxxxxxx/xxxxxxxx’

Facility: Cluster Port Driver
Explanation: The port driver attempts to reinitialize the port; after

50 attempts, it marks the device off line.
User Action: Check the error logs for a sanity timeout. This sanity
timeout is indicated by bit 6 of the PSR (PSR = ’xxxxxx4x’). The error
logs describe the sanity timeout bit as a ‘‘Maintenance Timer
Expiration.’’ If sanity timeouts occur, check the console log to see if
the operator has halted and continued the system for any reason. If the
console log does not show operator intervention, increase the PASTIMOUT
SYSGEN parameter until the timeouts no longer occur. For nontimeout
errors, contact a Compaq support representative to check the port
hardware.




--
Pure Personal Opinion | HoffmanLabs LLC

[Robert A. Brooks]

On 2021-09-09 18:46:38 +0000, Mark Berryman said
> I'm trying to add an x86 system into my current cluster but upon boot the x86
> system shows the following error and never sees the existing cluster members:
>
> %EIA0, Link up: 1000 mbit, fdx, flow control (rcv only), 00-0C-29-19-61-FE
> %PEA0, Port Transition Failure - CNF/PMC/PSR  00000000/00000000/00000014

What ethernet device? Prior to attempting to join or form a cluster, had
this node ever successfully booted with a working network adapter?

If so, let's see the output from $ SHOW DEVICE /FULL <ethernet template device>

--
-- Rob

[Mark Berryman]

$ show dev/full eia0

Device EIA0:, device type i8254x, is online, network device, error
logging is
enabled, device is a template only.

Error count 0 Operations completed
0
Owner process "" Owner UIC
[SYSTEM]
Owner process ID 00000000 Dev Prot
S:RWPL,O:RWPL,G,W
Reference count 0 Default buffer size
512
Current preferred CPU Id 1 Fastpath
1
Current Interrupt CPU Id 1

Operating characteristics: Link up, Full duplex, Autonegotiation.

Speed (Mbits/sec) 1000 Adapteri82545 VMware (Gigabit
Ethernet)
Def. MAC addr 00-0C-29-19-61-FE Current MAC addr
00-0C-29-19-61-FE

$ mcr lancp
$ LANCP> show dev/char eia0

ALDUR3 Device Characteristics EIA0 (9-SEP-2021 18:35:19.85):
Value Characteristic
----- --------------
1500 Device buffer size
Normal Controller mode
External Internal loopback mode
00-0C-29-19-61-FE Default MAC address (Hardware LAN address)
Multicast address list
Ethernet Communication medium
FF-FF-FF-FF-FF-FF MAC address (Current LAN address)
8 Minimum receive buffers
256 Maximum receive buffers
Yes Full duplex enable
Yes Full duplex operational
00-0C-29-19-61-FE MAC address (Current LAN address)
TwistedPair Line media type
1000 Line speed (mbps)
Enabled Auto-negotiation
Enabled Flow control
Disabled Jumbo frames
0 Failover priority
Characteristic #0x0B14, Value = 00000000
Characteristic #0x0B15, Value = 00000000
Characteristic #0x0B16, Value =
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Characteristic #0x0B22, Value =
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Link Up Link state
LANCP>

Mark

[David Jones]

On Thursday, September 9, 2021 at 8:36:55 PM UTC-4, Mark Berryman wrote:
> $ show dev/full eia0
>
> Device EIA0:, device type i8254x, is online, network device, error
> logging is
> enabled, device is a template only.
>
> Error count 0 Operations completed
> 0
> Owner process "" Owner UIC
> [SYSTEM]
> Owner process ID 00000000 Dev Prot
> S:RWPL,O:RWPL,G,W
> Reference count 0 Default buffer size
> 512
> Current preferred CPU Id 1 Fastpath
> 1
> Current Interrupt CPU Id 1
>
> Operating characteristics: Link up, Full duplex, Autonegotiation.
>
> Speed (Mbits/sec) 1000 Adapteri82545 VMware (Gigabit
> Ethernet)

I gave up trusting autonegotiation to reliably get it right. A mismatch between
full and half duplex which let the device interchange enough packets to see
the other nodes but the virtual circuits would be unstable.

> $ mcr lancp
> $ LANCP> show dev/char eia0
>

What does show dev/counter say with regard to errors (collisions and carrier
check failures)?

[Mark Berryman]

On 9/10/21 7:04 AM, David Jones wrote:
> On Thursday, September 9, 2021 at 8:36:55 PM UTC-4, Mark Berryman wrote:
>> $ show dev/full eia0
>>
>> Device EIA0:, device type i8254x, is online, network device, error
>> logging is
>> enabled, device is a template only.
>>
>> Error count 0 Operations completed
>> 0
>> Owner process "" Owner UIC
>> [SYSTEM]
>> Owner process ID 00000000 Dev Prot
>> S:RWPL,O:RWPL,G,W
>> Reference count 0 Default buffer size
>> 512
>> Current preferred CPU Id 1 Fastpath
>> 1
>> Current Interrupt CPU Id 1
>>
>> Operating characteristics: Link up, Full duplex, Autonegotiation.
>>
>> Speed (Mbits/sec) 1000 Adapteri82545 VMware (Gigabit
>> Ethernet)
>
> I gave up trusting autonegotiation to reliably get it right. A mismatch between
> full and half duplex which let the device interchange enough packets to see
> the other nodes but the virtual circuits would be unstable.

The first autonegotiation standard in '95 that came with FastEthernet
had interoperability issues, causing many folks to cease to trust it.

However, the 802.3ab Gigabit Ethernet standard in '99 made
autonegotiation mandatory for Gigabit connections, and it continues to
be for higher speeds, since there are now more features than just speed
and duplex to be negotiated (flow control being a significant one). The
interoperability issues were addressed and, above 1G, half-duplex no
longer exists.

>
>> $ mcr lancp
>> $ LANCP> show dev/char eia0
>>
>
> What does show dev/counter say with regard to errors (collisions and carrier
> check failures)?
>

There are no errors on the Ethernet interface. I should have noted
that, when the node is configured as a standalone node, both DECnet and
IP run just fine over this interface.

Mark Berryman

[Robert A. Brooks]

On 9/10/2021 9:04 AM, David Jones wrote:

> I gave up trusting autonegotiation to reliably get it right. A mismatch between
> full and half duplex which let the device interchange enough packets to see
> the other nodes but the virtual circuits would be unstable.

The long-time (30+ year) developer of our ethernet drivers has been steadfast in
stating that autonegotiation should always work (assuming an adapter that
supports autonegotiation), and he'll sort it out if there is a problem.

With what adapters and switches were (are) you having an issue?

--
-- Rob

[David Jones]

On Friday, September 10, 2021 at 11:19:40 AM UTC-4, Robert A. Brooks wrote:
> With what adapters and switches were (are) you having an issue?
>

Last time I tried was a DS10 connected to a D-Link managed switch. It was a satellite
node so I had to set the parameters in the console to get it to boot.