SEthernet icon indicating copy to clipboard operation
SEthernet copied to clipboard

ENC624J600 may generate spurious interrupts when system is restarted

Open rhalkyard opened this issue 2 years ago • 4 comments

Because the ENC624J600 has no hardware reset input, spurious interrupts may be generated on a warm restart if the link state changes or packets are received. This may cause a Sad Mac or a System Error during early boot.

Workaround

Shut the Mac down fully and cold-boot it, or disconnect the ethernet cable before warm-restarting and only reconnect it after the driver has loaded.

If the system has crashed, the MacsBug command sm <base-address>+7f6e 1000;rb (where <base-address> is the card base address) will reset the ENC624J600 to put it into a safe state, and then reboot the system.

rhalkyard avatar Dec 06 '23 15:12 rhalkyard

While I don't think this issue can be completely resolved without a hardware revision, it could be mitigated in software by resetting the chip during a clean shutdown. It won't help for the 'hit the reset button' case, but it'll be better than nothing.

We already reset the chip in response to a Close call on the driver, but the OS does not seem to ever close the driver, even at shutdown. An alternative would be to install a Shutdown Manager procedure to do the reset, but this would be a bit ugly as there is no mechanism to pass arguments to shutdown procedures.

rhalkyard avatar Dec 08 '23 20:12 rhalkyard

Commit f1a081a has a Shutdown Manager procedure that resets the ENC624J600. It won't help with a reset after a crash, but it works for the "clean restart" case.

rhalkyard avatar Dec 12 '23 03:12 rhalkyard

Resolved in CPLD-based glue logic for rev1 - interrupts are disabled until the ENC624J600 has been written to 3 times to indicate that the driver is in control.

rhalkyard avatar Feb 17 '24 02:02 rhalkyard

This did not work as planned - the memory test run by the driver causes enough activity to unmask interrupts🤦, and the shutdown-manager workaround does not work on System 6. Additionally, the lack of reset means that even when interrupts are masked, the ethernet chip is left in a 'running' state when booting into an environment that lacks a driver for it. This will cause it to continuously assert flow control once the receive buffer fills up, which is a bit un-neighborly.

Instead I'm working on a modified power supply arrangement that powers the ENC624J600 down on reset, and does not power it on until a positive action is taken by the driver to enable it. This will have the effect of power-on-resetting the chip at every reset, which is what we could have had all along if it had just had a reset pin.

rhalkyard avatar Feb 07 '25 18:02 rhalkyard