The collected works of mazzinia

it's sad to hear it, very sad
If only being close :(

How heavy is one of those toys ? (just to get properly scared )

Where, in Italy ?

mmm , sort of 50km south of Milan, here

PIONEER DVD-ROM DVD-303 1.10 , audio plays perfectly. Only caveat is that it's a slot-in unit, so the front mask cannot be removed to fix the O2 plastic bits, nor is the front door having anywhere to connect to. Moreover the front mask ensures that the front plastic door will stick out half a cm or more.

2nd caveat, it doesn't have a jumper to set Parity

if you mean that you insert the power cable into the psu socket while the other end is plugged to a wall socket, what you hear is totally normal, and happens to all psu.
Usually is better to plug the cable in the psu, and only after, to plug the other end in the wall socket, to prevent unfortunate accidents

Hello,

what happens if an unity that doesn't have a PARITY jumper is added ?
Bus resets upon some operations ?
Can it lead to wear of the system hd ?
Can it cause a segmentation fault if an hd operation happens at the same time as a reset ? (example inst > go)

Hello,

fresh install of 6.5.30.
swmgr crashes with a segmentation fault if the hist file grows past 4mb
inst goes a bit longer as in how big the file can be, but that's all

I've "fixed" it by moving the hist file to let it work on a new one but now even that doesn't help. I'm trying to install Mipspro , and after having opened all the cds and such, inst crashes with a segmentation fault with the smaller hist file present (600k) just after I write go and press enter.

If I remove the hist file, it goes as shown downward, then crashes due to segmentation fault.

Inst> go
Pre-installation check .. 3% Abort (core dumped)

Any idea ? Am I missing maybe some patch that's causing this behavior ? This is hardly fun...

not really... 240gb free....

Does it matter if the OS was installed while on an O2 R12k with 1gb ram, and then the disk was moved to a R5k with 256mb ? (should mention that initially sysmgr was crashing with a memory fault, and started working only after a requickstart all).

"heavy programs" (jaleo/effects, by example) work without issues

mmm so I should assume that the Panasonic slot-in dvd has actually parity.

A bit more data, but is not helping me a lot... maybe gives an idea to someone else

I saw the compatibility list, and I think in part was made thanks to trying and seeing what happened.
In my case, as I reported in another thread, I found out that the Pioneer dvd-303 (slot-in 1999 dvd unit) is able to handle full audio playback, thing that according to the HW Aggregator should be limited to Toshiba drives.

where returns > 0 <Unknown>() [< unknown >, 0x117bb3a4]

Aside that, the machine is stable.

Anyway I "think" I managed to fix it, at least up to now it didn't crash again. The only annoying thing is that each rqsall at the end of inst/swmgr sessions, now, takes 100 to 109 minutes with the cpu past 90%.
Is there any trick to make the whole rsq/rsqall snappier ?

well, I found out that there was a mipspro 4.2.2 installed , and 4.4 partial runtimes, and so on.
First I've used the overlay to mipspro 4.4.4m, then I've kept re running all the sgi made cds I had until they all were showing "same version" or "older version" and 0 conflicts.
Adding the subdirectories (dev) of the 6.5.30 apps / complimentary apps helped bigtime (to the point that all Cosmo Suite parts installed with 0 conflicts with the most recent java)
Pity for the o2 demo cd (damaged), and the lack of the mekton demo

err yes, 7.x ... mispelled. The installation was new but not done by me. I think it was straight 6.5.28 and then overlayed to .30. Could be that something went wrong while overlaying.

And don't ask me how the dev fixed it. The fact is that it has solved all the problems, anyway. I really only would like that the rsqall would not last that long ( suppose that with a 300mhz r5000, the time would go down by 50% due also to the cache )

define the point of no return ?
Thanks for the link, but I think I read it a bit ago, when I was looking to fix the initial issue ( a manual full rqsall as in that thread fixed it ).
Now that I think about it, a full rqsall took over 3 hours (but I may be wrong)

On a side note, the "fix" created a side effect : inst / swmgr -X/ shows NA for installed programs that are in hist, now (while launching without the -X/ allows to see dimensions etc, for such programs).
Weird, I would say. inst/swmgr 4.1 is the latest ? no patches ?
Is there any patch that's required to prevent issues, on 6.5.30 ? (in case one such thing is missing)

Hello,

long story short, I got in possession of another SGI Fuel (whose psu is not giving problems up to now, crossing fingers).
It has still the original installation from the company it used to belong (minus their licenses, ach... there's some catia 4.1 installation whose license was apparently removed - unless it expired, obviously ).
It's a sort of basic, I guess, setup :
R14k 600mhz
1.5gb ram ( strangely 1 module is premium.. would have expected identical pairs )
18gb hd
v10

One monitoring ic went faulty during the 2 - 3 years the previous owner kept it stored and disconnected from any power line ( realized is common to happen on older batches ) so had to disable env monitoring.

The os is a 6.5.15m with 2 or 3 patches installed.

I'm wondering what would be the best way to proceed...
keeping it at 6.5.15m , or cloning the disk and upgrading it... but if going this way I wonder what would be the best way to avoid issues (and breaking some sw already on it).
Like :
installing missing things now , then upgrade ?
wait to install the missing after upgrading ?
upgrade straight from .15 to .30 ? or is better to move up to an intermediate and only then move to .30 ?

Any things I may have forgotten to ask/mention ?

ok thanks.
I guess it depends also what we can define interesting data

thanks for the suggestions.
I'm planning to slowly check the nooks and crannies of the filesystem to see if there's something particular. The previous owner, to my knowledge :
-got it
-looked at what was inside enough to take pics
-disassembled
-took pics of the parts
-reassembled
-put away

I'm fairly sure any action from his side may have been limited to root password reset
any utility for irix to recover deleted files, in case ? ( not just trashed )

jan-jaap wrote: CATIA uses IBM LUM licensing which has it's roots in NetLS. On IRIX a nodelock license should be in /var/lum or /opt/lum/ls/os/svr4.sgi/bin.

If this system used a floating license you'll never find it, of course because you don't have the floating license server.

update

sorry for taking time, but had no time ( pun not intentional )
under /var/lum
there's indeed a bit of things, including a
nodelock-sgi115.txt with a catia license inside for
MECH
ANS (KIN)
SDS (ASH)
expiration date : 2002 / 2003

late night update

ProductVision MockUp present , EAI3.0

Traces that this unit belonged to Bertone engineering, the car designing company

maybe I should make a new thread but...

I just cloned the boot disk using betxen script, changed the id of the cloned to 1 and trying to boot from it I get a

unable to execute dsck(0,1,8)/sash , no such device
unable to load bootfile

printevn from prom gives :
systempartition=dsck(0,1,8)
osloadpartition=dsck(0,1,0)
osloader=sash
osfilename=unix


suggestions ? means the source hd has 2 partitions ?

they were written as you wrote, just I was too lazy to do an 1:1 copy here.
Mainly was trying to understand what I missed / was missed by the scrip... assumed the script would have done all the required steps to clone the original disk.

And what I should do to fix it ( consider this is the first time I try cloning.. )

These

dvhtool -v get sash sash /dev/rdsk/dks${orig_cntrl}d${orig_drv}vh
dvhtool -v get ide ide /dev/rdsk/dks${orig_cntrl}d${orig_drv}vh
dvhtool -v creat sash sash /dev/rdsk/dks${target_cntrl}d${target_drv}vh
dvhtool -v creat ide ide /dev/rdsk/dks${target_cntrl}d${target_drv}vh

were in the script, and were executed. ide was not present in the original disk, but sash didn't give an error
and I added

dvhtool -v get symmon symmon /dev/rdsk/dks${orig_cntrl}d${orig_drv}vh
dvhtool -v creat symmon symmon /dev/rdsk/dks${target_cntrl}d${target_drv}vh

that was found and copied

---

ehm.. seems I have an issue.

I simply plugged back the original disk, and is not booting ... now I get the same error about sash not found

---

progress :

esf read error, bad count
esf read error, bad count
no file system found for "unix".
unable to execute dksc(0,1,0)unix: media not loaded

autoboot failed
dksc(0,1,0)unix: media not loaded

latest edit : the abovementioned progress is relative to the cloned hd. The original one is ok.

mmm I did initialize the disk using the graphical disk manager (aka there's a label)... but now I'm not sure if I did partition it... assumed it was similar to dd, fsdump.

oh well... live and learn.

btw, the original hd has a script in the root, made by the company it was being used for, to clone ( and for multiple installations )
The script is a lot more simple and with less steps than the ones I saw here

xfs_copy -d /dev/dsk/dks0d1s0 /dev/dsk/dks0d2s0

and that's all ( aside being followed by 2 entries to edit the hosts and sys_id ).
I have also the feeling that they cloned a disk originally installed in a server, since strangely there's no ide on it, so no diag tools to launch from prom

sorry to say, but

/usr/stand

doesn't exist on the disk ( I dumped the list of everything )
The only stand present is in the root
/stand

with fx and sash inside ( and now with symmon, too )

in theory those 3 steps were done

gui to initialize and put a label
script formatted and copied the header ( sash and symmon, in my case )

I checked the headers of the 2, and were identical

the only step I think I forgot to do, was to check the source partitioning, and to repartition the target

mmmm, indeed the 2 partitions are not identical

sgi115 2# prtvtoc
Printing label for root disk

* /dev/root (bootfile "/unix")
* 512 bytes/sector
* Unallocated space:
* Start Size
* 35546876 296794
*
Partition Type Fs Start: sec Size: sec Mount Directory
0 xfs yes 8392704 27154172
1 raw 4096 8388608
8 volhdr 0 4096
10 volume 0 35843670

sgi115 3# prtvtoc /dev/rdsk/dks0d9vh
* /dev/rdsk/dks0d9vh (bootfile "/unix")
* 512 bytes/sector
Partition Type Fs Start: sec Size: sec Mount Directory
7 xfs yes 4096 71128863
8 volhdr 0 4096
10 volume 0 71132959

sgi115 4#

I guess it should fit as asking for a tip.

Cd-rom from an O2. The tray is blocked outside...
It's quite a while that, from time to time I try to open it up to fix it, but I've not understood what the trick is to do it.

There are the usual plastic clips on the 2 sides, but even if released and the lid lifted ( with patience, since underside there's a plastic casing ), it lifts just up to a certain point.
It keeps being locked on the front and I notice that if I try to apply more pressure to lift, the plastic frame itself tries to move.

So.. what am I missing ?

sorry for not answering, but for whatever reason I didn't get a notification

tiny tabs underneath ???

With the front cover removed, the only tabs I can see are 2 on both sides, one towards the front, and one towards the back.
Underside i'm not noticing anything aside the screws on the back near the scsi connector.

the top metal casing interlocks on the front with the metal base, seems like a compass , but .... as I mentioned, I seem unable to remove it / tilt it past a 30 degree or such

nono

the cdrom is already removed from the o2.
I'm having troubles to disassemble the cdrom itself , aka to remove the C shaped metal cover that protects it

https://snag.gy/9siNhj.jpg

I've released the 2 circled in red, on both sides, but the top cover is not coming off... at best it tilts 30 degrees from the connector side. Something prevents it to go more than that, and I don't understand what

no suggestions ?

oh wait a bit...

the 2 or 4 screws underside it have to be removed ? I assumed they were used to keep the board attached to the separate metal plate.
mmm grounding bolt...

I didn't know that there was a grounding bolt, but given the kind of sensation I got trying to open it up a bit "more" , it may easily be the trick I was missing.
Who designed that thing wanted to sell more units vs repairing, I guess