EtherLan600 fails with CF attached to IDE channel

As mentioned in this thread an EtherLAN600 in the RiscPC network slot fails to initialised correctly when a CF is connected to the IDE channel, reporting Send errors and:

Cable is not connected at unit 0

In my case, if I then add a slave HD, in conjunction with the master CF, the NIC starts working again so this could be a hardware issue.

Reinitialising the EtherH Module doesn’t resolve the issue, but does clear the “Cable is not connected” error.

On a separate note, SharedCLibrary needs updating in the ROM within NIC drivers.zip as EtherH fails when a newer version of SharedCLibrary is subsequently loaded in the !Boot sequence. The ROM really needs to be rebuilt whenever CLib is updated and reflashed, otherwise the only fix is to unplug all of it’s Modules.

In my case, if I then add a slave HD, in conjunction with the master CF, the NIC starts working again so this could be a hardware issue.

Don’t forget that if you have a particularly old and slow drive you plug in as slave then the standard says the whole bus (cable) slows down to the speed of the slowest device so you could still be looking at a timing issue.

But how would the IDE transfer speed affect the EtherLan? To rule out IDE transfers affecting the NIC, I copied the network drivers to both RAM and ADFS:0 and pulled the CF’s. I couldn’t get the NIC to work though, it seems that if it doesn’t initialise during POST, it’s impossible to get working again.

I also tried booting to Supervisor, to no avail.

But how would the IDE transfer speed affect the EtherLan?

1. It doesn’t have to be one fault on the setup¹
2. If it is timing related then bear in mind that the RPC data bus is a masterpiece of close timing (for that era) and if something is slightly off on it’s timing you’re heading for a motorway pileup. My thinking was that a potentially fast response from the CF which caused problems with it as a lone item on the IDE bus would be masked when the CF slowed to match a slow drive.
3. It could actually be neither of those and be a control line being pulled high/low by the slave drive
4. You could also ask yourself whether it’s a bug in the EtherLAN code (as well) – nobody said the bugs all have to in the same place. Do the general errors reduce if the NIC is not present?

Even though the RPC is old tech I’m glad these bugs and fixes are being found.

¹ Over many years of technical support I’ve been proved right on the multiple fault possibility so often that I always look for additional errors even after I’ve found a fix for the reported problem.
Yesterdays was a misconfiguration on a wireless LAN controller and a memory leak noted in the monitoring stats after the fix and reboot (which means a patch job after we get the code from Cisco TAC – not on standard release)

It could actually be neither of those and be a control line being pulled high/low by the slave drive

That was my initial suspicion, possibly combined with a bug in the EtherLan code.

I’m now leaning towards a “feature” in the EtherLan code, as I believe a link sense failure requires a power cycle to get it working again. Given the “Cable not connected” error with a CF attached, its possible they’re the same issue, perhaps triggered by the POST drive detection coinciding with the EtherLan link sense.

I need to test if it’s possible to get the NIC working after powering on the machine with the network cable disconnected, if it is, I’ll do the same test with a CF attached.

EDIT: The code that brings the NIC up is here and the card initialisation is here

What version of the EtherH module are you using? A later one (4.52, something like that) offers the *Ehconnection command to force which interface you want to use, as the cn fallback to 10-base-2 was usually a bad choice since the late ’90s when people realised that 10b2 was kinda rubbish.

What version of the EtherH module are you using?

The latest (4.59 off the top of my head), hence my comment about the flash ROM’s CLib being out of date and needing an update.

https://www.riscosopen.org/viewer/view/bsd/RiscOS/Sources/Networking/Ethernet/EtherH/c/if_eh?rev=1.9#l1977

;-)