Can I instal raq4 software on a raq3? ( whith os-restore cd of raq4)


TNX
regards,
babak

Yes
No problems reported on that

tnx for your replay.

so let say I have a raq3, install a raq4 software whit os-restore and that's it? no probleems? no hardware issue's? so I think you can put raq550 software also on a raq3 ? Am I right?

regards,
babak

Yes you are correct

- and if for some reason it dosn't work, come back here and give us a shout, I'm sure we can help...:)

Just to be clear, no you can't put 550 software on another RaQ. The hardware in the 3 and 4 are identical except for the CPU, so that's why it works. Same story for the RaQ2 OS on a RaQ (1).

Brandon

actually you can put 550 software on a 3 or a 4 it works just fine however i personally wouldnt recommend it for a production machine. (yes i know the thread is 3 months old i just thought i would share )


Steve

I'd be interested in seeing proof of someone having done this without modifying the RaQ3/4 at all.

Yes, that's a challenge. :)

Brandon

here you are
server ip
http://216.234.186.222/
that would be the start page for a cobalt raq 550

here is the dmesg and /proc/cpuinfo for that server
note the processor cpu MHz : 448.211 whereas an actual 550 would read about 998 or so (raid messages removed to accomidate post length restrictions)

[root /root]# dmesg
Linux version 2.4.16C12_III (root@galvatron.cobalt.com) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 4 22:45:04
PST 2002
BIOS-provided physical RAM map:
BIOS-e801: 0000000000000000 - 000000000009f000 (usable)
BIOS-e801: 0000000000100000 - 0000000008000000 (usable)
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,115200 ip=off
Initializing CPU#0
Detected 448.211 MHz processor.
Calibrating delay loop... 894.56 BogoMIPS
Memory: 126324k/131072k available (1443k kernel code, 4360k reserved,
426k data, 212k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 008021bf c08029bf 00000000, vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
CPU: After vendor init, caps: 008021bf c08029bf 00000000 00000002
CPU: After generic, caps: 008021bf c08029bf 00000000 00000002
CPU: Common caps: 008021bf c08029bf 00000000 00000002
CPU: AMD-K6(tm)-III Processor stepping 04
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: AMD K6
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
SGI XFS with ACLs, EAs, realtime, quota, no debug enabled
i2c-core.o: i2c core module
i2c-dev.o: i2c /dev entries driver module
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-proc.o version 2.6.1 (20010825)
i2c-ali15x3.o version 2.6.2 (20011118)
i2c-dev.o: Registered 'SMBus ALI15X3 adapter at ff60' as minor 0
i2c-core.o: adapter SMBus ALI15X3 adapter at ff60 registered as adapter
0.
i2c-ali15x3.o: ALI15X3 SMBus Controller detected and initialized
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT
SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e
Non-volatile memory driver v1.2
block: 128 slots per queue, batch=32
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
ALI15X3: chipset revision 193
ALI15X3: 100% native mode on irq 14
ide0: BM-DMA at 0xfdd0-0xfdd7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xfdd8-0xfddf, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALLP AS20.5, SN=792114678331, FWREV=A1Y.1500QUANTUM
FIREBALLP AS20.5, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ide0 at 0xfdf8-0xfdff,0xfdf6 on irq 14
hda: 40132503 sectors (20548 MB) w/1902KiB Cache, CHS=39813/16/63,
UDMA(33)
Partition check:
hda: hda1 hda2 hda3 hda4
Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994
Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak.
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 14, function 0
sym53c8xx: 53c875 detected
sym53c875-0: rev 0x4 on pci bus 0 device 14 function 0 irq 12
sym53c875-0: ID 7, Fast-20, Parity Checking
scsi0 : sym53c8xx-1.7.3c-20010512
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 438.400 MB/sec
32regs : 379.200 MB/sec
pII_mmx : 838.800 MB/sec
p5_mmx : 778.000 MB/sec
raid5: using function: pII_mmx (838.800 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
[events: 00000018]
[events: 00000018]
[events: 00000018]
[events: 00000018]
md: autorun ...
md: considering hda4 ...
md: adding hda4 ...
md: created md4
md: bind<hda4,1>
md: running: <hda4>
md: hda4's event counter: 00000018
md4: max total readahead window set to 256k
md4: 1 data-disks, max readahead per data-disk: 256k
md: updating md4 RAID superblock on device
md: hda4 [events: 00000019]<6>(write) hda4's sb offset: 13908800
md: considering hda3 ...
md: adding hda3 ...
md: created md3
md: bind<hda3,1>
md: running: <hda3>
md: hda3's event counter: 00000018
md3: max total readahead window set to 256k
md3: 1 data-disks, max readahead per data-disk: 256k
md: updating md3 RAID superblock on device
md: hda3 [events: 00000019]<6>(write) hda3's sb offset: 524544
md: considering hda2 ...
md: adding hda2 ...
md: created md2
md: bind<hda2,1>
md: running: <hda2>
md: hda2's event counter: 00000018
md2: max total readahead window set to 256k
md2: 1 data-disks, max readahead per data-disk: 256k
md: updating md2 RAID superblock on device
md: hda2 [events: 00000019]<6>(write) hda2's sb offset: 1536128
md: considering hda1 ...
md: adding hda1 ...
md: created md1
md: bind<hda1,1>
md: running: <hda1>
md: hda1's event counter: 00000018
md1: max total readahead window set to 256k
md1: 1 data-disks, max readahead per data-disk: 256k
md: updating md1 RAID superblock on device
md: hda1 [events: 00000019]<6>(write) hda1's sb offset: 4095936
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
XFS mounting filesystem md(9,1)
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 212k freed
Adding Swap: 524536k swap-space (priority -1)
XFS mounting filesystem md(9,2)
XFS mounting filesystem md(9,4)
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.8.2.1 $ 2000/11/17 Modified by Andrey V.
Savochkin <saw@saw.sw.com.sg> and others
eth0: Invalid EEPROM checksum 0x2806, check settings before activating
this device!
eth0: Intel Corp. 82559ER, 00:10:E0:03:26:14, IRQ 11.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 000000-000, Physical connectors present:
Primary interface chip None PHY #0.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0xdbd8681d).
Receiver lock-up workaround activated.
eth1: Invalid EEPROM checksum 0x9d08, check settings before activating
this device!
eth1: Intel Corp. 82559ER (#2), 00:10:E0:03:28:89, IRQ 10.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 000000-000, Physical connectors present:
Primary interface chip None PHY #0.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0xdbd8681d).
Receiver lock-up workaround activated.
Sun Cobalt Bandwidth Limiting Module
[root /root]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 13
model name : AMD-K6(tm)-III Processor
stepping : 4
cpu MHz : 448.211
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall
3dnowext 3dnow k6_mtrr
temperature : 30.50
bogomips : 894.56

That's pretty interesting. Did you have to do anything different to get the 550 OSRCD to work?

B

the reason that the above exists is a staff member did it by mistake he was suposed to be doing a raq 4 restore on that server so no he didnt do anything special at all.

Steve

i suggest you give him a raise..

;)

Be careful when putting RaQ 550 payload on a RaQ 3 or RaQ 4 (or Qube 3 or RaQ XTR). It _will_ install on any of those (connect a serial cable during the OSRestore and you'll see the menu appear for which machine you want to install on in your console), however it first does a ROM upgrade, then reboots, then does the traditional OS Restore process. On some machines the ROM upgrade fails, leaving you with a nice blue boat anchor.

The capability to install the 550 OS on other platforms was the first phase of an upgrade/ migration path that hasn't materialized. Consequently, not much QA (if any) went into the process. Sometimes it "just works" and other times it doesn't...

My personal experience involved installation on a RaQ 4i, and it worked fine. The 550 has some hardware pieces the RaQ 4 doesn't, so Active Monitor will cry about the fans being stopped, etc.

One caveat: I was unable to reinstall a regular RaQ 4 OS on the RaQ 4 I put the 550 payload onto. So if you do successfully migrate, you're done. Going back does not appear to be an option.