The collected works of recondas - Page 17

You can find all kinds of stuff on SF - maybe the people's committee in charge of the great firewall spotted something potentially subversive and added SF downloads to the do-not-pass-go list at the door to the great firewall ( along with other clearly counter-revolutionary tools-of-capitalism like Norwegian Broadcasting's web site, archive.org or the Internet Movie Database ).

If nothing turns up in Sweden I have one you can have for whatever postage is needed to get it over there.

If you want to double check suitability, it's an HP cable, part number 5062-3370, roughly a meter (40 inches) in length, 50-pin Centronics on one end, clamp-style latch MD-50 on the other.

Thought we'd already had the noscript conversation.....

Things must be a little more cultured over there - I once had a gf kick in my door. Probably right after she broke the rules and downloaded a copy of Fatal Attraction .

Never heard that one - but it does lend a new perspective to the origination of the expression "loose lips sink ships".

Maybe.

There isn't a standard 13W3 pinout, pretty much everybody who used one went their own way. If you'd like to see if your 13W3 adapter is compliant with (one of) the SGI 13W3 pinouts, there's a table of a few of the varieties in the nekowiki. http://www.nekochan.net/wiki/13W3

After you've loaded the 1680x1050 format and rebooted, what does /usr/gfx/gfxinfo -vv show?

Then the most likely answer is IRIX looked at the DDC info provided by your monitor doesn't consider the timing of the format used as compatible.

The right way to correct the situation is to use the Video Format Compiler (VFC) and build a format that is specific to your monitor.

The shot in the dark fix is to try and fool IRIX by loading the format and not powering up the monitor until *after* IRIX reboots. This method doesn't always work, but even if it does I don't recommend it - if it produces a display the timing inside the format might be off enough to cause damage to your monitor.

Some IBM servers used internal SCSI cable with the right 68-pin centronics connector on the planar end - which might be a little easier to source than SGI's OEM cable.

Another possibility is to find a real nice teflon-coated internal SCSI cable with an integrated LVD terminator at the far end, and replace the planar end with a Fuel-compatible crimp-on 68-pin centronics connector .

If you like additional detail, there are a few MAXX Desktop threads in the nekochan archives , and the MAXX Desktop developer is a nekochan member. He hasn't logged in in a while, but contact info is available in his profile .

When it was Saturday night here it was still yesterday in Oz. So he probably missed our Saturday Night, Live or otherwise.

@rwengerter - we're you able to get a working 1680x1050 display on your Fuel?

If you can get a modeline or (better yet) EDID info specific to your monitor you may be able to create a custom vfo file. Be glad to offer assistance if needed.

I have a Mac Pro 2006 that the previous owner upgraded to 2007 Mac Pro2,1+ specs (thanks!). 3Ghz 8-core for the 2.1 part; a Bluray burner in the second optical slot and Apple Radeon 5870 for the "+" part.

It's a rock-solid system. Out of curiosity I recently setup a dualboot/bootcamp install of Win7 64-bit on it and it runs Win7 stuff so much better that I can hardly find a reason use the 3GHz c2d Dell-made-for-windows box kept here for work-related win-centric stuff. I'm considering either VMware Fusion or Parallels to as a means to fulfill my occasional Win/linux needs in the form of no-need-to-reboot VMs.

If there's a catch, first generation Mac Pros (2006/1,1, 2007/2,1 and 2008/3,1) use fully-buffered DDR2 DIMMs. Apple-approved FB-DIMMs with the right specs and Apple's approved heat sinks still command premium prices . I recently picked up some non-apple DDR2-5300F FB-DIMMs with standard flat-side JEDEC heat sinks (in the form six 2GB DIMMs for $24 -inexpensive enough not to hurt my feelings if they didn't work). These have been running 24/7 for several weeks without problem, so I have some equally inexpensive 4GB FB-DIMMs of the same brand/series inbound for further testing. For now I'm using one of the SMC fan control tools to increase air flow across the non-apple DIMMs to ensure adequate cooling with the flat-sided JEDEC heat-sinks. That's been keeping the reported temps of the third-party memory at or below what the OEM memory reported before the change. If the 4GB stuff works as well I could add the apple-approved heat sinks and still be at only a fraction of the cost of apple-approved memory, but I don't really notice the fan noise with all the other stuff running in here.

The other potential catch for the first generation Mac Pros (2006 and 2007 models) is they were dropped from OS X 10.8. If you gotta have 10.8, it isn't hard to find out how to run it on the '06 and '07 MPs - you'll just have a very on-spec 10.8 hackintosh.

AFAIK third-party utilities, and there are a couple of variants out there. smcfancontrol seems to be the most often mentioned in the Mac Pro section of the MacRumors forums http://www.macupdate.com/app/mac/23049/smcfancontrol

A set of the third-party 4GB FB-DIMMs arrived since my last post and they've been up and running w/o problem for a couple of hours. Been doing some stress testing - under a heavy load they're running at 60C - which is about 10C higher than an existing set of equally-stressed 4GB FB-DIMMs with Apple's approved finned heat sinks. If they continue to do ok I'll probably consider picking up some the Apple-original 512MB DIMMs as heat sink donors. That would still leave lots of room for a good deal, managed to get the pair of 4GB third-party FB-DIMMs (8GB total) for about the same price as pair of 1GB FB-DIMMs from one of the major Mac supply houses .

If you haven't already it might be worth investigating to make sure ( all of ) the necessary power from the supply is actually arriving at the molex plug that connects to the hard drive. During the last twenty years one of the leads to the molex connector in the sled might have gotten flexed a few times too many.

The suggestion to make sure the fans in your Tezro are unobstructed is a good one - continued operation at those temperatures might well cause damage. The DM3 is positioned fairly close to the perforated metal shroud that encloses the V12, so it's likely the graphics in your Tezros run cooler without the DM3 because of improved airflow.

I think SGI was aware that graphics boards in certain tower Tezros configurations could run hot. Later revisions of the V12 used in the Tezro included what appears to be an (unused) 3-pin fan header - the one in the photo is an 030-1884-002 Revision D: To my knowledge that V12 fan header was never used - along with the development of 256 and 512MB versions of the V12 it may have fell victim to SGI's decision to scale back/drop MIPS-based systems.

You might also compare the L1 revision in your Tezros with some of those posted in the hinv forums (that have cooler graphics temperatures). I don't know for certain that the temperature threshold/fan speed levels used by the L1's "Autofan Control" changed between Tezro L1 revisions, but I did notice differences in the Autofan Control between different L1 revisions in the very similar O350.

The Tezro I have arrived with a dead V12. There have been other mentions in the forum of failed Tezro graphics boards. Concerned that those failures might be heat related I placed a low-noise fan on the perforated metal cover directly above the heat sink on the V12. The additional fan lowered the average operating temperature of the V12 in my Tezro from 50C to 40C (though the DM3s in your Tezros will make adding a fan directly above the V12 heat sink slightly more challenging).

Very nice - congratulations! There doesn't seem to be much demand for 512MB Mac Pro FB-DIMMs, with some patience I was able to win three sets (six DIMMs) with original Apple heat sinks for at or near the opening bid. Even with shipping the entire lot was about the the same money as one pair of the Max Upgrade heatsinks.

As far as third party FB-DIMMs go, all of the 667MHz 2Rx4 FB-DIMMs I've tried have worked (your mileage may vary, but I tried *one* set in 2Rx8 configuration that weren't recognized). While all of the third-party 2Rx4 FB-DIMMs have worked reliably, the 2RX4 Nanya 2GB FB-DIMMs don't supply a reading to Temperature Monitor, while the 4GB Samsung and Hynix FB-DIMMs I've tried do supply temp readings. May be coincidental to the temperature reading, but if I found the correct spec sheets, the Samsung and Hynix units use an Intel AMB chip, the Nanya units have a non-Intel AMB.

You're welcome. If you decide you might like to use the header, to be safe I'd suggest metering the header to confirm that it was intended for use with a fan. Another possibility might be replacing the Odyssey cooling fans with some that have the same physical dimensions but with a higher RPM/CFM rating. The L1 firmware regulates the system fans using a percentage of the fan speed rather than at a specific RPM, so a fan with a higher speed/flow rating should provide at least some additional cooling: If you decide to try graphics fans with a higher RPM/CFM rating, I'd suggest picking one with a minimum speed higher than the 1300 RPM Warning Level (called for by your L1 firmware), or you'll likely generate fan warning errors that cause the system to auto-power down: Interestingly enough, the Warning RPM for the graphics fans in my Tezro is given as 1350 RPM - perhaps another indication there might be some differences in the environmental parameters called for in different firmware revisions.

The underlying issue may be how you intend to span the display across all four screens. The traditional shipped-with-IRIX method would be to span each pair of DCD-driven displays with one of the 2@ display formats provided by xsetmon (e.g. 2@1280x1024_60), then use the SGI port of Xinerama to tie the two pairs of displays into a single four panel logical display. The downside to using Xinerama is usually only the primary display (or in the case of your DCD equiped V12s, the primary pair of displays) will be able to display OpenGL rendered content - so OpenGL will only work on two of the four displays.

SGI's solution for transparently spanning OpenGL across a multi-panel logical display is/was OpenGL MultiPipe . At one time OpenGL MultiPipe was freely available on SGI's 'Download Cool Software' page. I haven't looked lately, but hopefully it's still (freely) available through Supportfolio .

The current view at my office......

Yes

It is possible to run DCD connected displays at not-provided-by-sgi resolutions. The off-the-beaten-path 2@ display format hamei uses with his T221 mega-display is a good example: viewtopic.php?f=3&t=16726857

It's a (mostly) stock '67. Wouldn't mind having that shovel, but unfortunately that one is a customer bike - that's my *work* office.

The (visible) display image provided by IRIX will be 1920 pixels wide and 1200 lines high. I'm not personally aware of a (consumer-level) monitor that has the internal logic needed to convert that image into one 1200 pixels wide by 1920 lines in height. I'm sure I only looked a a fraction of the 1920x1200 panels that offer landscape to portrait rotation, but everything in that (small) sample used the graphics controller on the host computer to rotate the image.

Indeed - if googling the part number you gave turned up the right images, it would appear that even the assembly part number silk-screened onto both the SGI and HP boards (200027C) are the same:

That article started a nekochan topic when it was originally released:
viewtopic.php?f=1&t=4118&
Which in turn generated a "post your face" thread:
viewtopic.php?p=31270

Won't fit into a single photo, but this one includes the area shown in the first photo.

California runs its own version of the MSF program. If you successfully pass their course they'll waiver the skills/riding test at the DMV - all you'll need to do is pass the written law test:

http://www.ca-msp.org/FAQ.aspx

<cough> You do realize that request for assistance wasn't sent specifically to you? I got the very same message.

If it's not already gone, take a look at the message header. You received that message because somewhere along the line you subscribed to the [email protected] mailing list. The OP was (very politely) following standard protocol for asking a question via a list server.

bitcpy isn't the first new-to-IRIX member to have asked the when-is-24-bit-really-24-bit? question. SAQ's suggestion to use a 24-bit gradient to confirm the change took effect is a good one. Perhaps we should consider adding a sample gradient file to the True Color wiki . It could be made extra new-user friendly by including screen shots of what the gradient would look like in both 8 and 24-bit mode.

Sounds suspiciously normal. The LED blinks white and the monitor is blank during power-on diagnostics - that's also roughly the right amount of time for power-on diagnostics with the amount of memory you have installed.

There's at least a small chance you might be able to revive the missing memory by clearing and resetting the Power On Diagnostic logs. Doesn't always work, but here's an example of success with the hardware-similar Origin 300: viewtopic.php?f=3&t=16725059

Prior to accessing your Fuel's innards, disconnect the power cord, the system isn't fully powered down unless completely disconnected from power.

Before you try the POD mode revival trick I'd suggest using the link GL1zdA provided to ensure your Fuel's memory is installed in the correct alternating-slot configuration , and that each DIMM is fully seated. Those plus-sized IP35 DIMMs have enough mass to suffer inertia disconnects during shipment - if you're lucky that'll be the underlying cause of the missing memory.

While you're in there, locate the 9-pin serial port on the system board. Connecting your serial terminal emulator of choice (38,400/8/N/1) to that port with a null modem cable is the best way to access both the L1 controller and PROM of your Fuel. The L1 will power up as soon as you re-connect power; once you power up the system you can access the PROM/POD by pressing the control and d keys on the serial terminal simultaneously.

IRIX only supports a very limited subset of the USB standard .

The Fuel (IP35) Hardware Aggregator is a good resource for known-to-work Fuel hardware peripherals.

I'd suggest trying the POD sequence again.

When you enter POD mode the system runs a comprehensive memory test, which might need a fair amount of time as it attempts to examine the disabled memory. The 'go cac' command is an indirect acknowledgement that POD mode wasn't built for speed. Once you get that far it allows POD to run in cached memory - but you'll still have to wait for the initial memory tests to run.

enableall?

It was included in the POD mode sequence linked above, but not implicitly mentioned in this thread. So everything/one is on the same page, here it is again:

Before you remove any RAM I'd suggest taking a look at the syslog to see there are any entries there that might give you a better idea of what's going on. If you can't access the syslog from the GUI tool in the Toolchest without generating a crash, you may have to print the contents (of /var/adm/SYSLOG) into a terminal window. You might also find entries related to the crash/error in the L1 log (connect the serial terminal and run the 'log' command at the L1 prompt).

If you aren't able to find anything useful in either log, then you could try booting IRIX from the serial terminal. Configure the serial terminal with a fairly large scroll back buffer (say 5k lines or so). Once IRIX is up and running try running a few of the commands/programs that previously caused the crash. If the system does crash the error message should remain in the serial terminal window as the Fuel crashes.

If any of these methods work, save the error message and post a copy here.