NetDLL crash with V8.3 on FreeAXP

Steven,

thanks for sending the CLUE file. As one can tell from the CLUE$HISTORY information, these are all the SAME crashes.

Please upgrade to the latest version of FreeAXP (.283) and re-test.

This type of crash footprint is 'known' and - on real Alphas - indicates pool corruption or a LAN hardware problem. In case of FreeAXP, the emulator would be 'the hardware'...

You can verify the consistency of the LAN driver queues with:

$ ANAL/CRASH dumpfile
SDA> SHOW LAN/FULL/DEV=EWA
...
-- EWA Queue Information ...
...
SDA> EXIT


re: changing the MAC address.

All FreeAXP systems come with the same default pre-defined MAC address. So if you run more than one FreeAXP on the same network segment, this may cause problems. But those problems should not cause crashes, only malfunction of some network operations.

Volker.

Steven,

your NETDLLERR crash does not show any signs of pool corruption. The EWA driver queues are intact. SDA> LAN RING/VALIDATE and SDA> LAN QUEUE/VALIDATE do not report errors.

The 'Last Ring entry done' is the first entry in the transmit ring and it does not have a VCRP associated with it, which is causing the crash.

As you can easily reproduce the problem, could you please turn on LAN tracing and then start TCPIP:

$ MC LANCP SET DEV EWA/TRACE

In the subsequent crash, please verify, that the LAN traces are readable with SDA> LAN TRACE, then please make the crashdump available again.

Volker.<hr>

The Marvel Yukon NIC is on the motherboard, correct? I had a look at the manufacturers site and it does not appear the NIC is available as a standalone device.

Any chance at trying a different NIC driver under Windows?

By any chance, would your network be using Jumbo frames? If so, it is possible this is throwing the FreeAXP emulated NIC for a loop. Check your NIC advanced settings and see if there is a jumbo frames or jumbo packets option that can be turned off.

Deliberately connecting to a 10/100 switch would also disable jumbo frames.<hr>

We supplied Steve with a pre-release of FreeAXP 288. It contains some NIC updates and support for the DE435 NIC. Steve reported the following results:

- Using the DE500, TCP/IP hangs, but the system no longer crashes.

- Using the DE435, TCP/IP works correctly.

So FreeAXP 288 appears to provide a viable work-around for the NETDLLERR. Now we need to understand why the DE435 works and the DE500 hangs. We have ordered some NICs using the Marvell Yukon chip set to see what else we can learn.

FreeAXP 288 will be released once testing has been completed.

We supplied Steve with a pre-release of FreeAXP 288. It contains some NIC updates and support for the DE435 NIC. Steve reported the following results:

- Using the DE500, TCP/IP hangs, but the system no longer crashes.

- Using the DE435, TCP/IP works correctly.

So FreeAXP 288 appears to provide a viable work-around for the NETDLLERR. Now we need to understand why the DE435 works and the DE500 hangs. We have ordered some NICs using the Marvell Yukon chip set to see what else we can learn.

FreeAXP 288 will be released once testing has been completed.