Miod Vallat wrote:
mainbus0 at root: Unknown IP35 type 0
Wow. I would not have expected this. Can you send the output of `hinv
-mvvv' of this machine at the PROM `>>>' prompt? I would have expected
Origin 3000 to report themselves as Origin 300. Oh well.
here it goes:
hinv -mvvv
location: /hw/rack/001/bay/33
Part:030-1604-004;Name:IP35;Serial:LMT028;Revision:-B;Group:ff;Capability:ffffffff;Variety:ff;Laser:000000004df7ef90;

location: /hw/rack/001/bay/33
Part:030-1557-007;Name:IBRICK;Serial:LMZ317;Revision:-A;Group:ff;Capability:ffffffff;Variety:ff;Laser:000000004dfc441b;

Ah, of course. Your system is built of a C-Brick connected to an
I-Brick, so it reports itself as a regular C-Brick.
yes, indeed.


iec0 at ioc0: 128KB SSRAM, address ff:ff:ff:ff:ff:ff
This is bad. On these systems, the Ethernet address is obtained by
querying the brick L1 controller for the proper IA record. Either the
query failed or the Ethernet address is stored elsewhere. Can you send
This is not too bad. The ethernet from the L1 controller and the OpenBSD system differ, but I was actually able to install OpenBSD on a USB drive. After reboot I tried to boot from it, but then it went into ddb.
The L1 MAC Address is: 08:00:69:11:ca:be
The MAC Address OpenBSD then used for dhcp was: fe:e1:ba:d0:b7:1f

This is normal - sort of. When the Ethernet address can not be obtained,
the kernel uses a random address starting with fe:e1:ba:d (to be
pronounced `feel bad'). Unfortunately it will change on every boot.

Can you elaborate on ``it went into ddb''? This is bad, the kernel
should have asked for its root device and followed with the usual
multiuser boot.
Sorry for being not clear enough. Yes, it asked me for the root device, which I told the system to use sd0, then it asked for swap, where it proposed to use sb0b, there I pressed return, and then it seemed to hang for about 30 seconds, and then went into ddb. I still had it in my console history, here is what happened:

OpenBSD 4.7-current (GENERIC-IP27) #291: Sat Apr 24 16:52:52 MDT 2010
   dera...@sgi.openbsd.org:/usr/src/sys/arch/sgi/compile/GENERIC-IP27
real mem = 1073741824 (1024MB)
rsvd mem = 20463616 (19MB)
avail mem = 998162432 (951MB)
mainbus0 at root: Unknown IP35 type 0
cpu0 at mainbus0 nasid 0: MIPS R12000 CPU rev 3.5 400 MHz, R12000 FPU rev 3.5
cpu0: cache L1-I 32KB D 32KB 2 way, L2 8192KB 2 way
clock0 at mainbus0 nasid 0: ticker on int5 using count register
spdmem0 at mainbus0 nasid 0 dimm 4: 512MB DDR SDRAM registered ECC PC1600CL2.5 spdmem1 at mainbus0 nasid 0 dimm 6: 512MB DDR SDRAM registered ECC PC1600CL2.5
xbow0 at mainbus0 nasid 0: XXBow revision 2
xbridge0 at xbow0 widget 15: XBridge revision 2
xbpci0 at xbridge0 bus 0: 33 MHz PCI bus
pci0 at xbpci0 bus 0
ioc0 at pci0 dev 4 function 0 "SGI IOC3" rev 0x01
onewire0 at ioc0
ioc0: ethernet irq 4, xbow irq 62
ioc0: superio irq 0, xbow irq 61
com0 at ioc0 base 0x20178: ns16550a, 16 byte fifo
com0: console
com1 at ioc0 base 0x20170: ns16550a, 16 byte fifo
com1: probed fifo depth: 0 bytes
iockbc0 at ioc0
iec0 at ioc0: 128KB SSRAM, address ff:ff:ff:ff:ff:ff
nsphyter0 at iec0 phy 1: DP83843 10/100 PHY, rev. 0
lpt at ioc0 not configured
dsrtc0 at ioc0: DS1742W
ohci0 at pci0 dev 5 function 0 "AT&T/Lucent USB 2-port" rev 0x10: irq 5, xbow irq 60, version 1.0, legacy support
"TI TSB12LV22 FireWire" rev 0x01 at pci0 dev 6 function 0 not configured
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "AT&T/Lucent OHCI root hub" rev 1.00/1.00 addr 1
xbridge1 at xbow0 widget 14: XBridge revision 2
xbpci1 at xbridge1 bus 0: 66 MHz PCI bus
pci1 at xbpci1 bus 0
/dev/ksyms: Symbol table not valid.
umass0 at uhub0 port 2 configuration 1 interface 0 "memory USB2.0" rev 2.00/2.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <memory, USB2.0, 1.00> SCSI2 0/direct removable
sd0: 3931MB, 512 bytes/sec, 8051200 sec total
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
boot device: 'dksc(0,1,0)' unrecognized.
root device: sd0a swap device (default sd0b):
root on sd0a swap on sd0b dump on sd0b
usb_transfer_complete: xfer=0xc00000000000a600 not busy 0x42555359
panic: cannot read disk label, 0x0/0x900, error 5
Stopped at      0xa800000000437db4:     jr      ra
0xa800000000437db8:      nop
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
ddb> trace
0xa800000000437db0 (9200000001000000,0,a800000000614b80,d) ra 0xa800000000167d
0c sp 0xa80000000061fcf0, sz 0
0xa800000000167c48 (9200000001000000,0,900,5) ra 0xa800000000161034 sp 0xa8000
0000061fcf0, sz 96
0xa800000000160fd8 (9200000001000000,0,900,5) ra 0x0 sp 0xa80000000061fd50, sz
0
User-level: pid 0
ddb> ps
  PID   PPID   PGRP    UID  S       FLAGS  WAIT          COMMAND
    7      0      0      0  3    0x100200  pftm          pfpurge
    6      0      0      0  3    0x100200  usbtsk        usbtask
    5      0      0      0  3    0x100200  usbevt        usb0
    4      0      0      0  3    0x100200  bored         syswq
    3      0      0      0  3  0x40100200                idle0
    2      0      0      0  3    0x100200  kmalloc       kmthread
    1      0      0      0  3           0  initexec      swapper
*    0     -1      0      0  7     0x80200                swapper
ddb> halt

I just tried to reproduce with the same kernel, but it did not happened again, now it goes up to:

...
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
boot device: 'dksc(0,1,0)' unrecognized.
root device: sd0
swap device (default sd0b):
root on sd0a swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/rsd0a: file system is clean; not checking
/dev/rsd0e: file system is clean; not checking
/dev/rsd0d: file system is clean; not checking
setting tty flags

then the output stops, I also do not see a dhcp request coming in on the dhcp server for a "feel bad" IP address. Does the stop after setting the tty flags is because /etc/ttys is not correct in using my ?


the output of `eeprom' at the `L1>' prompt? (you will probably need to
hit ^T or ^D on the L1 serial port to get such a prompt)
Here is the output:
[...]
Indeed, the Ethernet address is not stored on your C-Brick eeprom, but
on the I-Brick eeprom.

I have changed this code to query the I-Brick for the Ethernet address
when running on a C-Brick, would you mind testing this kernel?
I'll need to setup a NFS root and try to boot the SGI diskless to be able to compile a new kernel for it, that may take some time. Or could you send me a compiled kernel off-list?


AARGH!!! I found out the misery of the hard drives. I actually have two 18 GB 10k RPM FC hard drives in the box. But the Fibre Channel Bulkhead Card, which should be normally in the i-brick is missing. I just figured out yesterday. Unfortunately I bougth the box about 1 and a half year ago via e-bay. I already sent a mail to those people yesterday asking whether they may still have one around. I don't have much hope, but who knows... So right now I am looking for such a thing, but guess I can plug in any SCSI card and plug a SCSI disk to it?

Yes, but there are two things to consider: first, the I-Brick probably
only accepts 3.3V PCI cards, and second, only QLogic boards will get
recognized by the PROM (i.e. you won't be able to boot from a non-QLogic
board).
Ah, thanks for that hint, I unfortunately only have one or two adaptec scsi cards here, need to see what I get first or cheaper. I'd prefer to get the FC bulkhead card to make use of the fast internal disks. But is this card supported by OpenBSD anyways? I don't see it in the list of supported hardware in the sgi.html but that may just because the Origin itself is also not (yet) supported.
Will it also work when I try to attach a PCI graphics card, and a USB keyboard into the i-brick and use the cluster as a desktop? ;)

Not yet. PCI graphics will neither get initialized by the PROM, nor by
OpenBSD (to be fair, some ATI cards may get recognized and initialized
by the PROM, turning your machine from an Origin into an Onyx, but I am
not sure about this).
Ah, I was just curious, getting a harddisk to work is right now more important.

thanks,
Sebastian

Reply via email to