The collected works of recondas - Page 22

jdboyd wrote: What packages need installed (and perhaps tracked down first) to be able to make XZ work?

Already tired booting your current install with the XZ?

robespierre wrote: So the answer is mu.

As in Xin Loi?

jpstewart wrote: Wow! That sounds like a nice, but very long, trip.

Thanks! It was a great trip. Have had the opportunity to ride to all of the lower 48 States, but it was only my third motorcycle trip into Canada.

jpstewart wrote: Mind if I ask how many days you were on the road and/or how many miles you covered?

Twelve days, four thousand miles.

jpstewart wrote: It sure looks like you got some spectacular photos out of it, too!

There are some great ones, so it was hard to pick just a few for this post. If you're curious, there are photos from a few other trips farther back in this thread ( or in this one ). My passenger deserves most of the credit, she took the vast majority. She recently upgraded to a Nikon AW100 that's reasonably compact, waterproof and has an internal gps to geotag the images - so it's a good match for shooting photos from a moving motorcycle (rain or shine).

Robyn wrote: After replacing an impeller module in an Altix 350 C-brick, the brick won't power up because of serial number mismatch.
The problem is that the NVRAM reports a checksum error, and the board
serial number (BSN) in NVRAM does not match the BSN in EEPROM. The EEPROM is correct. Excerpts from "L1> log" :

Code: Select all

08/29/13 18:40:16 nvram checksum error - log pointers invalid, using backup copy

Anybody know how to fix up the NVRAM's BSN?

I'll be the first to admit that I have zero experience with the Altix 350, so take the following with a grain of salt.

The nvram checksum error has cropped up before in the L1 logs of the somewhat similar Origin 350 and Origin 300.

What resolved both of those cases was replacing the PROM battery. If you'd like to take a look, here's a link to the thread - with a photo of the battery location and info on where you could obtain a replacement: viewtopic.php?f=3&t=16727448#p7357727

http://www.google.com/search?q=aix+tutorial+for+beginners

The Portalis/InfiniteReality/Onyx2 Demo CD set includes an interactive demo of the Apex F14 simulator from Paradigm Simulation: In the day Paradigm Simulation Inc created a number of simulators that ran on SGI hardware. Here's a brief quote from the Paradigm Wiki:

The Paradigm Entertainment Wiki wrote: Paradigm Simulation was founded in 1990 as a company based in Addison, Texas. It initially focused on creating commercial products for graphics developers, including military training simulations for pilots and ship captains and a lengthy client list that included the United States Department of Defense, The Walt Disney Company, NASA, Lockheed Martin, Boeing, and McDonnell Douglas. Paradigm acted as a proponent of 3D computer graphics and virtual reality in the mid-1990s with its applications including the IRIS GL-based VisionWorks and the Performer-based Vega, which were used on Silicon Graphics workstations. Project sales for the company were $7 million in 1995, up from $3.5 million in 1994. During that time, the company frequented the annual Consumer Electronics Show, SIGGRAPH, and Electronic Entertainment Expo (E3) conferences with its 3D technological demonstrations.

http://en.wikipedia.org/wiki/Paradigm_Entertainment

bluecode wrote: Is it possible to delete an account on nekochan?

GL1zdA wrote: But please, make sure you don't delete posts when deleting users. There are already many topics, which are hard to understand, because one member's posts were deleted with his account.

smj wrote: +1

bluecode wrote: Why is censorship ok for some people and not others? That doesn't sound very egalitarian, modern, UNIXy etc.

bluecode apparently felt that nekochan.net's policy of not allowing members to buy/sell/trade commercial software was an affront to his right to do as he pleased .

While we do prohibit commercial software sales, we otherwise allowed bluecode pretty much free rein in the content of his posts - so much so that we even allowed him to censor himself. He elected to open each of the posts he'd made and remove the original content, then use the empty space to vandalize the threads those posts were in.

If his desire was to force the removal of his posts, he got his wish. I've deleted all of his historical posts to remove the graffiti he left behind.

Have you set the xserver to use 24-bit color? http://www.nekochan.net/wiki/True_Color

Hello emilen72 - welcome to the nekochan forums.

Regarding your problems with e-uae, could post the error message(s) you're seeing?

vishnu wrote: Not to be contrapuntal but in my opinion Bluecode did not violate forum rules.

Don't think anybody said bluecode violated the no-commercial-software rule, though I did mention that he apparently wasn't too happy with it.

vishnu wrote: Asking about the availability of software is not the same as asking to buy commercial software from someone/something who is/are not authorized by the software's copyright holder to sell it.

If you're talking about the same thread that seemed to have set bluecode off, considering that the OP there posted in the "Hardware Wanted " forum:

Hi there, looking for a C++ Compiler for IRIX 5.3. If possible with a permanent license.

I think his intent was fairly transparent - the OP in that thread wanted / was asking for a C++ Compiler for IRIX 5.3 with a permanent license.

vishnu wrote: Which, by the way, is how the forum rule should be worded...

You're obviously free to make that demand of your/our host, but please respect the fact that he's equally free to do what he thinks is in the best interests of nekochan.net.

vishnu wrote: find out if you're overburdening your machine by running `top` in a terminal window.

If you'd like something that takes up less of your desktop, you might try gr_osview:

TechPubs wrote: Viewing System Resources

The View System Resources selection in the System Manager System Performance category launches the gr_osview application, a real-time, graphical display of how your system resources are being used. The resources displayed are CPU usage, memory, CPU wait time (if any), and key system and graphics activity.

Next to the header for each resource displayed is a key that tells you which color is being used for a particular portion of the resource. For example, the CPU Usage band displays idle CPU time in green, user time in blue, system time in red, and so on.

For further information, see the gr_osview command.

http://techpubs.sgi.com/library/tpl/cgi ... 620-PARENT

I have gr_osview set to open every time I log in - I leave running right below the Toolchest (re-sized to be the same width).

vishnu wrote: It wasn't a completely eggregious violation of the rule or you would have either edited the post or deleted the thread, right?

I actually didn't delete the thread *because* of jan-jaap and bluecode's responses - in particular bluecode's query of "Is this explained anywhere?" Some newer users seem not to understand the reasoning behind the no-commercial-software rule and might not have seen previous explanations. Not deleting the thread allowed me to answer bluecode's question *and* offer the explanation anyone else not already familiar.

vishnu wrote: I think he was upset because in your answer you asked him to respect forum rules, none of which he had broken.

My request to please respect the forum rules was intended for bluecode and *anyone* who might also read it:

recondas wrote: One final note on the subject. Most of the nekochan moderators will edit (or delete) the first post made that doesn't comply with the commercial software rule. That's usually been more than sufficient to get the attention and willing cooperation of the offending poster. It'd be nice if that was always the case, but we recently had a member who reincarnated his deleted request for warez. As a result he's now permanently banned. Please respect the forum rules.

If bluecode found that request offensive he could have publicly voiced his concerns in another thread or even by PM. Which is pretty much what you've just done, without having been "censored by nekochan".

vishnu wrote: So then it is permissible to ask if anyone knows of a vendor who offers a software product that can do one thing or another? In this case it was a C++ compiler for Irix 5.3, but mentioning a perment license crossed the boundary?

As you've already pointed out, "the rule is perfectly clear as it is". I'm in complete agreement with you. When it comes right down to it, the no-commercial-software rule wasn't intended to protect the commercial software industry, it was intended to protect the forums from the commercial software industry.

hamei wrote: A 1 ghz dualcore O2 with 3 GB of memory

That would be someting - an O2 powerful enough to be slow in real time.

vishnu wrote: Uploading it to nekowiki right now, will edit this post to show a link when the upload is complete, going pretty slooooooowly at the moment... EDIT: I guess it ain't gonna happen, the wiki said This file is bigger than the server is configured to allow.

For all the semi-droll reasons we kicked around in the possible-to-delete-account-on-nekochan thread, please don't continue to try ( Stoo summed up the reasons quite nicely ).

Don't know that there's anyone who still cares, but why risk putting nekonoko in a position to have to find out the hard way?

In the flyleaf of HMQ-380-C, SGI wrote: Silicon Graphics, Inc. Unpublished Proprietary Information - All Right Reserved

A few copies of HMQ-380-C have made appearances on eBay. The ones I recall had starting bids in the silly money range and got quickly bid into the stratosphere: viewtopic.php?f=3&t=13610&p=107110&hilit=Hardware+Quick+Reference#p107110 I also recall at least one auction for an HMQ-380-C getting pulled the same day it was listed.

The rumor at the time was HMQ-380-C required an NDA and was intended for SGI's Field Engineer staff or for sites with large enough SGI hardware deployments to have a support contract that allowed for their own in-house SGI-qualified FE.

opcode wrote: Could anyone with one running off a 110v outlet throw out some info?

You could always get a Kill-a-Watt and generate your own empirical data set. Handy tool to have around even if you don't have a room full of decade(s) old computer gear.

Had the opportunity to try the DM10 IIDC camera setup connected through a Firewire hub.

Did initial testing using the Tezro and ADS Pyro 1394 IIDC camera described earlier in this thread. The hub used is a Belkin FU526-APL-S 6-port Firewire hub . During this test the ADS Pyro 1394 was connected to the FW hub rather than directly to the DM10 (for those not already familiar with the DM10, no rare $GI hardware is needed - a generic PCI firewire HBA can be used ).

The booting the system with the FU526 FW hub attached (added the ADS Pyro later) produced an 'businfo read' alert message in the syslog: Just to make the test a little more challenging, after IRIX booted the ADS Pryo camera was hot-plugged into the FW hub. Syslog again produced a businfo read alert: In spite of the businfo alerts, the ADS Pyro worked without issue when connected to the FW hub, as did a MicroTech Firewire Compact Flash card reader .

Haven't had the opportunity to test it yet, but don't expect the FW iSight will behave much differently.

hamei wrote: Have you been able to get an iSight to work directly attached ? I remember that a few people tried to use an iSight before but had problems with it.

Yep, It works.

Out late last night showin' up the whippersnappers?

in the second post in this very thread, hamei wrote: Another small step for Man ! Congratulations

I remember that neko got almost to that point but his iSight would not work. Maybe this means that the supported Canopus ADVC device could one day be persuaded to function ?

Super news, thank you !

viewtopic.php?f=3&t=16727655#p7359565

Looked at how the desktop flag is set in chkconfig?

If it's off, as root run:

Nice write up Trippynet, thanks for taking the time to create and share your work.

If I had one minor suggestion to offer, it would be to attach the photos to your post.

There have been a number of instances in the past where for one reason or another the off-site photo links have gone dead in similar posts, leaving those posts incomplete.

If you'd consider attaching the photos, just scale the photos for attachment to a reasonable size for on-line viewing, (I usually set the longer aspect to 1000px), and the forum interface will automatically create a smaller thumbnail for display in the article. The reader can view thew larger version by clicking the thumbnail.

In either case, thanks again for sharing.

scottE wrote: So, it seems there's an at least an occasional issue with using an Octane compression board on a system with more than a certain amount a RAM (one GB?); the system it's installed in currently has 2 GB. (Though sometimes it works, sometimes it just stops everything.)

From the information in this thread it sounded like the issue with the OCO and RAM came down to the size, type or brand of memory installed.

In that thread bigD wrote: I finally got around to playing with this more, and this morning I gave it a workout using dmrecord. It *generally* works just fine, but still seemingly crashes at random intervals. I'll play a clip back perfectly one time, but the system will go down if I immediately try to play it again.

All I had installed were two 1GB Dataram sticks, so I removed those and took my system down to 1.25GB using the various 256MB and 128MB sticks I still have laying around. And lo and behold, I can't get the system to crash anymore. I've recorded gigs of video, played it back over and over again, tried different compression settings and methods, and everything just works. ::knock on wood::

So it appears that at least in my case, the compression option doesn't like the 1GB sticks of Dataram memory. Perhaps it just doesn't like higher capacity memory at all - I dunno. That might be what lead people to think that it wouldn't work with more than 2GB installed - you'd need 1GB or 512MB sticks to accomplish that (I don't have any 512MB modules to test with).

hamei wrote: can add another camera known to work ...

Thanks for the write up, the Blackhawk IEEE1394 Digital Camera has been added to the list in the Fuel IP35 Hardware Aggregator .

Hi John - I sent you a PM.

Pontus wrote: I'm blessed/cursed with one Onyx2 rack, one Origin2k deskside and one Onyx2 deskside........What do I gain by having the rack with a proper graphics module over linking the the two desksides together(I have all needed cables)?

Unfortunately you can't CrayLink an Onyx2 Deskside. In order to shoehorn in the graphics boards into an Onyx2 Deskside they omitted the slot/circuitry for the second required-to-craylink router board.

Either of these threads might shed a little additional light on the issue:
viewtopic.php?f=4&t=16721904&p=7309092&#p7309092
viewtopic.php?f=10&t=16723803&start=15#p7326607

Pontus wrote: I could have sworn that I had seen a picture of an Onyx2 deskside craylinked with "something". If this is not possible, what is the little hatch in the front that access the routerboard for?

I'd suspect it's because they used the same molds as the O2k Deskside (and just switched the color to purple).

Pontus wrote: So.. lets talk graphics instead, how does the deskside compare with the full graphics module?

Previously Pontus wrote: Obviously less texture memory will reduce performance, will it also reduce maximum resolution? Can the two pipelines of the graphics module be combined for more perfomance?

With the Graphics Module you can have two pipes. The second pipe is roughly equivalent to what the deskside offers - room for two Raster Managers. The first pipe in a Graphics Module has room for four Raster Managers. Increasing the number of Raster Managers does have an effect on performance: viewtopic.php?f=3&t=16722836&start=15#p7319524 - read through the thread for details on what the numbers mean.

Increasing the number of Raster Managers / texture memory doesn't have an effect on the maximum resolution the pipe can display. The display resolution is controlled by the Display Generator, which has a maximum *output* bandwidth of 300 Mpix/sec (enough for two 1920x1080_60 displays, but not enough for two at 1920x1200_60).

You can combine the output of both pipes in a Graphics Module. If you want to do it in hardware you'll need a pair of DG5/DPLEX display managers (and likely an application that supports the hardware). You can also do it in software. The quick-n-dirty method would be xinerama. The big downside to xinerama is only the primary pipe can display OpenGL graphics. The better method would be SGI's OpenGL Multipipe software . OMP works very well, isn't to difficult to setup/configure, and depending on the configuration you choose, allows OpenGL graphics to be displayed across both pipes .

I'll offer Pontus the possibility of a third InfiniteReality solution. Sell the Deskside, the rack compute module and the rack. Use the money to buy quad-processor O300, a KTown2, a set of G-Brick panels, a G-Brick L2 module and a Numalink cable. Stack the O300 on top of the rackless Graphics Module/G-Brick. Same floor space as the Deskside, all the graphics horsepower of a rack Onyx2, and improved compute power (with the ability to take advantage of the extras that come with IP35-generation hardware - USB, SATA, firewire, etc.)

The conversion from Graphics module to G-Brick is bolt-on/plug-in - no solder or firmware incantations involved.

Does the green LED in the front panel power switch illuminate after you start the systems using the L1?

Mismatched PROM revisions will cause a non-fatal barrier sync warning during power on diagnostics. You can flash the PROM(s) from an IRIX command prompt. The flash process will use the PROM revision included with your most recent IRIX install. See man flash for details.

The SGI Origin 300 System with NUMAlink Module User's Guide follows the same method j-j describes for powering up with the font panel button.

You could also start both modules with one button press via the L2 controller touchscreen: Alternatively you could emulate the L2 (and display) using the L3 software:

If you only have the two compute modules (see #5), power the master module first and the slave second.

Pontus wrote: Which left me wondering, could a graphics module be hooked up to an Octane?

An x-town board is the compute end of the Graphics Module CrayLink connection. It uses the same standard half-height XIO configuration as the Octane: Whether or not it'll work will remains an exercise for someone with a strong sense of adventure.

Info on versions that work with FF 3.0.19 here: viewtopic.php?f=15&t=16727397&start=15#p7357077

Even if it is currently missing on my end 'cause I'm blocking javascript and those persistent tracking cookies that photo hosting sites inject into your system so they can turn a buck selling your browsing history, browse through the some of the older forum threads. Eventually most off-site hosted photos go MIA, and it leaves the next person looking for info or help hanging in the proverbial breeze.....

Jack Luminous wrote: Curiously, the various 1600x1024 vfos found in my install didn't work at all.

It's likely the timing in those vfos was intended for the 24" CRTs SGI sold with Octanes.

Jack Luminous wrote: I finally used the 1600x1024_60-1704TPPL-1056TLPF.vfo file (to be found here : http://forums.nekochan.net/viewtopic.php?f=3&t=16725775 ).

Been a while since I made that one, but I'm pretty sure it was created from a random xFree86 1600SW modeline captured from the internet.

Jack Luminous wrote: Still, there remains a minor annoyance that I couldn't solve. When the Octane boots up with the 1600SW+MLA plugged in one of the DVI slot, the above mentionned 1600x1024 vfo disappears from the list in xsetmon and some default 1280x1024 is automatically selected.

As mentioned in your other Octane/monitor thread IRIX looks at the DDC or EDID info from the monitor and presents only those graphics formats it deems appropriate. Be nice if that process was fully documented / could be updated.... (we'll leave that pipe dream for another time).

In the mean time you might try connecting the DVI port of the 1600SW/MLA to another system to see if you can capture the EDID info and try for a 1600SW/MLA tailored VFO using the EDID template .

Jack Luminous wrote: At this point, there is no way to get back to 1600x1024. When I boot up the machine without any monitor connected until the graphic login screen, and then hotplug the DVI, the vfo is back in the list and I can select it properly and make it the default choice. That means : every time I reboot or start up, I need to unplug first the DVI (so that IRIX can't detect the 1600SW+MLA contraption) and plug it later to get the native 1600x1024 or else I'm back at 1280x1024. It is workable as it is but kinda annoying. Is there's a way to avoid that ?

Probably not the elegant workaround you were hoping for, but instead of hot-plugging the DVI cable have you tried disconnecting the MLA power supply before booting (to see if that stops the exchange of DDC/EDID info)?

Jack Luminous wrote: I don't have a DVI equipped computer at home apart from the Octane. Though I googled some EDID info about 1600SW+MLA and found this

Nice find, though it looks like that info might have been obtained when the MLA was switched to analog mode:

Jack Luminous wrote: It looks like it's the same values you used for the previous vfo : Horizontal Image Size : 1704 mm Vertical Image Size : 1056 mm.

That'd fit with the EDID mention of "video input definition: analog". Been a while, but ISTR the xFree modeline I used (to build the vfo you're currently) using was for an MLA in analog mode. I'll have sort through some archived data and see if I can find the vfoinfo file from that format. (EDIT: found some additional info in this post - looks like I manually modified/swagged an xFree modeline to use the 1704 TotalPixelsPerLine and 1056 TotalLinesPerFrame values mentioned in the MLA manual - hence the inclusion of "1704TPPL-1056TLPF" in the name assigned to that format).

Using EDID info from an MLA in digital mode would be the next step. Hopefully that would resolve the issue with IRIX rejecting the MLA's offer of 1600x1024 at boot, but until it's tested we won't know for certain. The DDC/EDID info presented by the MLA/1600SW still might fall outside of the range accepted by IRIX for an Octane with VPro graphics. Since the 1600SW/MLA does work/boot when attached to an O2, the inconsistency might be attributable to code that was inserted into the O2 PROM to support the MLA/1600SW EDID info ( the 1600SW got added for specifically for the *O2* beginning with the IRIX 6.5.2 update ) but didn't make it into the Octane PROM. If that's the case, then you may still see the occasional Octane/MLA glitch ( scroll down to the highlighted line ).

Jack Luminous wrote: I tried and apparently the EDID is read as long as the DVI cable is plugged, even when the MLA is not powered. I haven't tried to disconnect the 1600SW itself. I'll try tonight.

Let us know - might be helpful to someone else down the line.

Attached a format built using the EDID info you found for an MLA in analog mode. It's pretty close to the timing I swagged into the 1600x1024_60-1704TPPL-1056TLPF.vfo. The EDID generated version does provide slightly wider horizontal and vertical back porches (8 pixels and 4 lines respectively).

Here's the VFC -generated format analysis:


If the idea of hot-swapping *two* 1600SWs appeals to you I also found the 2@/DCD version of 1600x1024_60-1704TPPL-1056TLPF.vfo (mentioned in that older thread).

EDIT: While poking through my VFC archives, I also ran across a couple of VFO's I built for a 1600x1024 Apple Cinema Display (the old school ADC version). One has a 60Hz refresh rate, the other 50Hz. The versions I archived use the same 1704 TotalPixelsPerLine and 1056 TotalLinesPerFrame called for by the 1600SW, so if all else fails (and you're feeling lucky) let me know and I'll send you copies You could also try the ones ZoontF attached to the thread (the TPPL and TLPF in those were adjusted to something other than 1704TPPL/1056TLPF to suit ZoontF's Apple ADC monitor).

Hate to see you go Jimmer. You've made some significant contributions to the forums in those 10 years.

Come back any time - for you the door is always open!

Jack Luminous wrote: Yes the DCD works with a single monitor. I'm using a 1600SW+Multilink Adapter.

If you don't mind pin-plucking another DVI cable (and just happen to have a second 1600SW/MLA) you can always try for a 2@ monitor set up.

vishnu wrote: Presumably your DCD works? Mine doesn't work for crap

Thought we figured out that was self-inflicted .

guardian452 wrote: Yes, this is on a 2006 mac pro with 10.9.2 with a modified boot.efi. Yes, it is an unsupported configuration. No, I don't care (as it works fine otherwise).

@guardian452 - If you're willing I'd love to hear more on your experiences with that process.

Thanks for the write up guardian452!