[Noguri]

Hi folks,

I need your lights as I'm having a tough time with my MENET board (on Octane).
To make it short:
- The board is probed (see hinv hereunder)
- Only 2 Ethernet ports (out of the 4) are discovered
- Only 2 Serial ports (out of the 6) are discovered
- Serial ports appear to work strangely: sometimes it works fine, then for some time nothing appears (no communication) and it comes back to normal again

Any idea how to move forward?

Here is the hinv:

Code:

      PM10600MHZ Board: barcode MET805     part 030-1774-002 rev  A
            IP30 Board: barcode KVY924     part 030-1467-001 rev  D
    PWR.SPPLY.ER Board: barcode AAE1480138 part 060-0035-003 rev  A
             FP1 Board: barcode KSV972     part 030-0891-003 rev  G
          ODY128 Board: barcode LDJ915     part 030-1404-003 rev  A
           MENET Board: barcode GPS727     part 030-0873-003 rev  G
1 600 MHZ IP30 Processor
CPU: MIPS R14000 Processor Chip Revision: 2.4
FPU: MIPS R14010 Floating Point Chip Revision: 0.0
Main memory size: 2048 Mbytes
Xbow ASIC: Revision 1.4
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 2 Mbytes
Integral SCSI controller 0: Version QL1040B (rev. 2), single ended
  Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 1: Version QL1040B (rev. 2), single ended
IOC3/IOC4 serial port: tty1
IOC3/IOC4 serial port: tty2
IOC3/IOC4 serial port: tty3
IOC3/IOC4 serial port: tty4
IOC3 parallel port: plp1
Graphics board: V8
Integral Fast Ethernet: ef0, version 1, pci 2
Fast Ethernet: ef1, version 1, pci 2
Fast Ethernet: ef2, version 1, pci 3
Iris Audio Processor: version RAD revision 12.0, number 1

Hardware info:

Code:

/hw/node/xtalk/9/pci/0/# ls
/hw/node/xtalk/9/pci/1/# ls
/hw/node/xtalk/9/pci/2/# ls
.guest   .master  base     config   dma      ef       intr     ioc3     mem      mem.be   mem.le   rom      rom.be   rom.le   usrpci
/hw/node/xtalk/9/pci/3/# ls
.guest   .master  base     config   dma      ef       intr     ioc3     mem      mem.be   mem.le   rom      rom.be   rom.le   usrpci
/hw/node/xtalk/9/pci/4/# ls
.master  usrpci
/hw/node/xtalk/9/pci/5/# ls
.master  usrpci
/hw/node/xtalk/9/pci/6/# ls
.host    .master  base     config   dma      intr     ioc3     mem      mem.be   mem.le   rom      rom.be   rom.le   tty      usrpci
/hw/node/xtalk/9/pci/7/# ls
.host    .master  base     config   dma      intr     ioc3     mem      mem.be   mem.le   rom      rom.be   rom.le   usrpci

[weblacky]

I’m going to assume you’ve read this: https://techpubs.jurassic.nl/manuals/hdw.../ch01.html

You do have a later model xBow and you hopefully have later version of Irix (doesn’t say min). It does say two more things.

1. /etc/ioconfig.conf controls this cards settings.
2. There was a software CD that came with this you’re suppose to install…but the instructions just say install it. Not what it’s called or if it just flips something in the OS. But that’s where I’d start.


I cannot find any rough mention of a needed driver for this board searching to Google. So I’d assume it’s an ioconfig thing?

[Noguri]

Hi Weblacky,

Thanks for your reply.

Yes, my Xbow ASIC is rev.1.4 and my IRIX release is 6.5.30, things are fine on this side... I've tried with IRIX 6.5.22 but things are the same.
As stated in the manpages "ioconfig(1M) walks the /hw hardware graph tree and assigns a unique and persistent logical controller number to each physical device found".
That's where problems is: the /hw graph tree does only show 2xef and 2xtty (I've captured the hw tree in my original post).
- Suppressing the ioconfig.conf file and restarting the machine to regenerate it doesn't change anything, physical devices are not found.
- "Forcing" the missing lines in the ioconfig.conf file has strictly no effect
- Performing a fresh IRIX installation does not change things either.

As you pointed out, the manual is referring to an installation CD, but I wasn't able to figure out which one. Maybe someone there knows...

[weblacky]

Also weird from Neko: http://archive.irixnet.org/apocrypha/nek...cy/17.html
----------------------------
ivelegacy
From Italy
Who joined Jan. 4, 2015, 5:12 a.m.
Wrote on the subject of DUAL Vpro graphics in my new octane, locked and clean. at Jan. 14, 2016, 5:19 a.m...
in my opinion: do not underestimate the compression connector and its catch mechanism
in my experience (with MENET ): the wrong catch mechanism did the difference between " properly working " and " not properly working "
----------------------------


This sounds (from the view of a small child's picture made during class-time) like your problem? That's not a lot but maybe, different slot, and extra push BEFORE engaging locking? I'm grasping here....

[jan-jaap]

Also weird from Neko: http://archive.irixnet.org/apocrypha/nek...cy/17.html
----------------------------
ivelegacy
From Italy
Who joined Jan. 4, 2015, 5:12 a.m.
Wrote on the subject of DUAL Vpro graphics in my new octane, locked and clean. at Jan. 14, 2016, 5:19 a.m...
in my opinion: do not underestimate the compression connector and its catch mechanism
in my experience (with MENET ): the wrong catch mechanism did the difference between " properly working " and " not properly working "
----------------------------


This sounds (from the view of a small child's picture made during class-time) like your problem?  That's not a lot but maybe, different slot, and extra push BEFORE engaging locking?  I'm grasping here....

Oh boy.

I don't see how the compression connector latch (catch mechanism?) could cause this, but filthy or damaged compression connectors certainly can. Also, when installing a new option in an Octane, you have to beware of the dust that accumulates in the system after all these years. If there's dirt on the backplane PCB where it mates to the compression connector, it will end up in the compression connector. I've learned this the hard way when installing a PCI shoebox in my Octane. It never worked reliably until I tore down the system, cleaned the surfaces where the compression connectors mate, replaced the compression connector of the shoebox, and re-assembled everything.

The ethernet and serial functions of the MENET card share a PCI bus on the card, with a single PCI-XTALK 'bridge' upstream. If there's an 'upstream' problem like dirty compression connector, or blown PCI-XTALK (happened to me, crater in the chip!), you'd expect either all PCI functions (serial, ethernet) to either work or not work. Not half of them.

[weblacky]

I was going off the "sometimes works" description from both sources. Grasping I know...but sometimes works?

[Noguri]

Well:
- different slot => same issue
- another Octane => same issue
As of now, I would say either the board is defective, either there's an issue with the host adapter driver...