[mapesdhs]

I'm trying to repair a mbd/gfx assembly from a 12MHz Personal IRIS (I suspect damaged during Customs handling), I had a replacement board I thought would be viable (just had to replace some damaged memory slots, which worked ok), but now it's giving an Ethernet loopback error which prevents the system from reaching the PROM:

http://www.sgidepot.co.uk/misc/P1160877s.jpg

Anyone know what would cause this and how to fix it? I've tried attaching an AUI/RJ45 adapter and a loopback cable but that had no effect. Strange thing is, the board didn't used to do this, so why it's starting moaning about it now is a mystery.

Although I was able to repair the visible damage to the original mbd, namely a wrecked SCSI connector socket (replaced with a new socket), that board is no longer able to detect SCSI devices so it has some other issue, maybe a severed track somewhere:

http://www.sgidepot.co.uk/misc/P1160730s.jpg

For reference, here's the system all working just fine before it was originally shipped:

http://www.sgidepot.co.uk/misc/P1160535s.jpg

Alternatively, if anyone has a fully working IP6 for sale then please let me know, gotta get this sorted asap (I posted in the hw WTD section).

Thanks!!

Ian.

[dexter1]

If i would guess looking at the mainboard configuration of the IP6, could there be debris on the board close to the network controller (SEEQ?) and AUI connector? This could cause shorts between the HPC1.5 and the network controller, rendering connection/loopback tests invalid.

So make sure you eyeloop the affected part of the mainboard.

Also multimeter all the tracks to see if there is a short or broken pad somewhere

[mapesdhs]

I'll have a look, though I should add that I have other IP6s which give the same error, it's bizarre.

Ian.

[weblacky]

Yo Ian,
This might be a dumb question but, could the loopback test failure simply be a symptom that the ethernet controller is generally unable to function?

For example like having a corrupt MAC address or bad local power rail? I'm assuming you have a functional battery on the board and have done some kind of check on the whatever ethernet controller chip VCC/GRD lines?

By check I don't mean while inside a running machine, I generally mean through other means such as providing proper voltage externally on the controller traces with a bench PSU or attempting a diode or Ohm check between VCC and GND for the ethernet chip?

Or perhaps a chip-wide diode check from pins-> grd as a simple profile?

Best of luck,
-Josh

[jan-jaap]

This might be a dumb question but, could the loopback test failure simply be a symptom that the ethernet controller is generally unable to function?

For example like having a corrupt MAC address

This is actually not dumb at all.

The MAC address is stored in a 53c556 serial EEPROM on a little board with the reset switch (SGI made a habit of linking the system serial number to the chassis, not the mainboard). It is connected to the E-module with a ~ 10 wire flatcable.

The photo is from a 4D/25 or 4D/35 but I suspect they're all the same.

There's an internal and an external ethernet loopback test. I assume the external loopback test requires some sort of loopback cable attached to the network port, but the internal loopback test basically sets up a packet or frame for transmission, and checks the RX buffers for the size and checksum. This will almost certainly require a valid MAC address.

[mapesdhs]

I tried the mbd in a different chassis (so a different MAC/cable/etc.), it made no difference. I'm not quite ready yet btw to do that level of board testing (need to setup the microscope, cam, etc.) and a bench PSU is the final item of kit I've yet to buy. :} Diode mode testing and relevant pin/track profiles is the main thing I want to do in the long term for this and a great many other boards. I won't be able to get stuck into this though until probably next summer as atm I'm away much of the time dealing with the estate of my late step-Dad.

However, the original mbd (the one I replaced the SCSI socket on) in the borrowed chassis is now detecting SCSI devices ok, last night I was able to reach the PROM. Turned out aswell that the disk I'd been using was faulty, which is annoying (I've just finished a 4.0.5 reinstall on another disk - thank grud I spent the time way back creating a 4.0.5 installation disk, ie. no need to bother with network installs, CDs or tape). With my own chassis though, given how it behaved with the original mbd after the repair, I think it may have a problem with its long SCSI ribbon cable (perhaps damaged somewhere after soooo many mbd/gfx assembly removals and insertions). This suggests my original mbd repair did actually work ok, I just was horribly unlucky with both a SCSI ribbon cable that became faulty and a disk that developed a fault without my being able to tell.

So, I have a working IP6 again (hurrah!!), now I just need to sort out the gfx which isn't actually fully ok, I can see some speckly artefacts when I run things, or even just move the mouse over an icon. I probably need a replacement GR1.5.

I do need at some point to resolve the loopback issue on the other mbd so that I can still have a working system, but of course I need to sort out the bad SCSI ribbon cable too. The cable inside the chassis looks pretty firmly fixed in, bit tricky to replace. I have an IRIS File chassis stored away though, maybe that will have the same cable.

Ian.