The collected works of miod - Page 4

ClassicHasClass wrote: I'm waiting for miod to protest

Oh, come on. Now I have to contribute something to this thread

ClassicHasClass wrote: There is a NetBSD/dreamcast which is current, but the quality of the LiveCDs that are floating around is questionable insofar as you really need NFS to do just about anything. Even if you set up the RAM disk version, there's not a lot you can do with it out of the box unless you (surprise) extend the filesystem with NFS. I would ordinarily use NetBSD here, but that kind of sucks.

Well I'm not even sure these can be called LiveCD. They are just boot media, which can also (more or less) help you setup a NetBSD/dreamcast system as a diskless system. I am not aware of anyone working on a real, usable, LiveCD for NetBSD/dreamcast.

ClassicHasClass wrote: What I'd really like is a new kernel. Anyone else out there played with Linux on SH systems? linux-sh.org seems to have gone to the Wayback Machine in the sky, and their backups don't have a lot of info or even any kernel binaries.

I can't comment on that, but I'm not sure there is much interest in anything on SuperH in the free software world those days, given the state of the GNU toolchain (especially the compiler, which is plagued by subtle SuperH-specific optimization bugs).

This is a bit sad, as the SH4 is a nice critter (with FPU, unlike the SH3). Too bad SH5 got eventually cancelled

One thing definitely worth checking is your PSU. Can you try to temporarily use a different power supply (preferrably a reliable model matching its specs, not some $20 cheapo bag of components put together without any proper filter) and see if it makes your machine any happier?

Kumba wrote: I've got an RM5200 stashed in the closet somewhere. I'd be interested in one of these to see how well Linux plays with it. I assume this RM7k chip wouldn't have any L3 cache available, right? I know on the 350MHz RM7k, the L3 cache is externally mounted on the CPU board.

On the RM7k, L1 and L2 are on-die, and L3 is the external cache. When you upgrade an RM5200 O2 with an RM7k, the RM5200 1MB external L2 becomes the RM7k 1MB external L3.

GL1zdA wrote: Does anyone have the installer for the trial version of Cosmo Code 2.5 for 95/NT? Since I'm a Java programmer I'm interested how Java development looked like in 97. I searched for this release of Cosmo Code, but it seems it's gone.

I still have a MSFT ``Site Builder Workshop'' cd-rom from this timeframe, with many demonstration/trial version of commercial software. When I'm back home I'll have a look in what's in it, if it's still readable.

surrealdeal wrote: i keep reading conflicting information that 'openbsd now supports x on MIPS' as well as 'bsd is text only on octanes'


I wanted to see if using only the unaccelerated framebuffer would give me x11 on a defective card that causes segfaults under irix.

OpenBSD supports X on some SGI systems, but unfortunately at the moment the Octane (and anything with Impact or V6/8/10/12, really) isn't part of them.

ClassicHasClass wrote: So it really is running on a BeagleBone in a shoebox?

Not a shoebox but egg cardboard boxes for better sound isolation!

hoosyny wrote: You should have warned me before joining in.

I'm not sure putting a ``warning: hamei inside'' large sign on the forum new member registration page would be of any help

hamei wrote: You think he's kidding ... at smj's place, if you ask to use the bathroom he says, "Sure ! Sure, no problem. Can't get there through the hall, it's full. But here, take this path through the kitchen. When you get to the stack of HP-9000's, veer right. Then at the NeXT turboslabs, joggle around the Indy's on your left. A few yards farther you should see some RS/6000's, if you squeeze in behind them you can get through the opening into the bathroom. Just take the Atari's off the seat if you want to pee."

It's actually easier to go outside and climb in through the window

This kinda reminds me of the place I was living in the early '00s. At some point there was so much hardware piled that I had to walk like an egyptian to reach the bathroom. Really - the space left in the corridor to the bathroom was really tight! This was annoying enough to make me relocate into a larger place a few weeks later.

duck wrote: Before we all jump back in here, I'd like to point out that this has been rather extensively answered already. Perhaps ivelegacy ought to make acquaintance with the search function.

Edit: On second thought (and some quick searching of my own) I may have jumped the shark, apologies if that was the case.

Did you mean this thread? http://forums.nekochan.net/viewtopic.php?f=6&t=152

alexott wrote: Sorry for the newbie question, but I'm wondering what is the smallest SGI workstation? Indy I presume?

The Indy is the smallest, volume wise. But if you look at the motherboard only, the O2 is even a bit smaller.

hamei, you're about to break nekochan...

vishnu wrote: It's a funny joke but I think we're all aware that in order for an unsigned integer to overflow it's got to be a pure power of two, and since hamei didn't break nekochan at post number 256 you have to figure our post numbers must be stored in at least two bytes, so hamei's got at least another 55537 posts to go before he really breaks nekochan...

What if the numbers are stored in BCD form?

ajw99uk wrote: A quirk indeed. Jan-jaap mentions a difference in bus speed (or an additional speed?). Speculating only, I'd guess it might be a matter of what can be derived through sensible multipliers:
270 = 120 x 2.25 (equivalent to 225 = 100 x 2.25 on the old board)
360 = 120 x 3
but both would be awkward multiples of 100.

There is no 2.25 clock multiplier for R10000 and R12000. Compared to R10000, R12000 lacks the x1 and x1.5 clock multipliers, but has x4.5, x5, x5.5, x6, x7, x8, x9 and x10. Now 270 == 4.5 * 60, so this might be the configuration in use (rather than 3 * 90), which can't be achieved without a motherboard correctly feeding four bits of SysClkDiv at powerup time, rather than only three since the R10000 only needs three.

smj wrote:

wenp wrote: I'd say OS X is the least Unixy Unix-like system out there. ... no /proc

If /proc is a canonical feature of UNIX, somebody has performed a major piece of retcon on the space-time continuum...

Or someone is simply confusing Unix with SVR4.

ivelegacy wrote: fill an impactSR gfx instead of Odissey (if you want a frame buffer, we still do not know how to put a pixel on Odissey)

Of course we know how to put a pixel on Odyssey. Skylark's original Octane work contains console frame buffer drivers for both Impact and Odyssey.
What we don't know is the easiest way to put a pixel.

ClassicHasClass wrote: I am glad RMS is out there and I am glad I am not sitting next to him.

Yes, he should go out more often and get some tan!

Kumba wrote: Oh, that issue. That's the old problem with PCI-to-PCI bridges and other PCI devices not playing really nice with DMA when >2G of RAM. Only way to work around that is likely going to require finding Octane system documentation at some point. Even Stan didn't have a lot of luck in figuring that one out.

I don't understand the problem, here. The XBridge has a 2GB direct window for trivial DMA address computations, allowing PCI bus masters to access the low 2GB of cpu memory (only 1.5GB on Octane, because physical memory starts at 512MB on this platform).

So either your bus master device can use 64-bit addresses for DMA, and you can put any valid XIO address and reach all your node's physical memory, or it is limited to 32-bit addresses, and you have to make sure it will only attempt DMA to addresses reachable through the direct window.

Alternatively, for small DMA areas, you can setup Address Translation Entries, and direct your 32-bit DMA request to the matching area in the translated window, but ATE are a scarce resource.

ivelegacy wrote: @miod
let me understand, are you using gentoo on IP30 ?

I am not using gentoo (or any form of Linux) on IP30. I am just stating how the hardware works.

The Sun design (which RDI's is heavily based upon) does not use the ability for the MK48 to generate interrupts, so this pin isn't likely connected to anything on the motherboard. You can swap with an MK48T59 or a DS1643.

Bufo333 wrote: I just picked up a Sun Blade 2500 with 2 xvr-1200 cards in it. I wanted to put either OpenBSD or FreeBSD on it. However i am not sure if either OS supports the xvr-1200 and i was hoping somebody has some experience with these two operating systems on Sun hardware.

To the best of my knowledge, FreeBSD doesn't support the XVR-1200 at all.
OpenBSD has limited support for the first head of the XVR-1200 boards: console will work, and there is an unaccelerated 7-bit X server. That's about all which can be done without hardware documentation.

ClassicHasClass wrote: I *am* looking for the rear ATX shield, though. The disassembled 164LX I bought didn't come with it.

Good luck with that. When I bought my 164LX new, it was nowhere to be found in the box

TeamBlackFox wrote: Will this replace OpenSSL or does it have an API difference?

PolarSSL has a completely different API.

kokoboi wrote: Do you have RS232 port pinout schema?

The serial port is a 3-in-1 pinout, and not the same layout as the HP 9000/400 layout. I have the breakout cable here, and will try to investigate the wiring and report it.

In my experience before I got the breakout cable, the wiring was good enough to let a regular DB25 cable get the first port's output, but I could not input anything. But it could have been human error or a subtle flow control problem on my side.

ivelegacy wrote: Motorola (today acquired by Freescale)

As a former Motorola SPS employee, I don't know if I should laugh or cry at such an utterly wrong shortcut.

nyef wrote:

Kumba wrote: I think the IRQ thing would only be an issue for the IOC3 PCI card, also known as a CADDuo (which I have stashed in a storage bin somewhere...).

Allow me to shed some light on the subject.

First, you should accept that the IOC3 chip is not a PCI chip. Even though it is connected to the PCI bus, it does not follow the PCI specs.

In the PCI world, a PCI device, by default, is allowed to use only one of the four PCI interrupt pins (A-D). The pin number is reported in the PCI Interrupt Register in the PCI Configuration Space. But if, and only if, it advertizes itself as a multifunction device, then the subfunctions, which will answer to different addresses in the PCI Configuration Space, are allowed to use different values for the PCI Interrupt Register, and thus use different interrupt pins. Note that the way pins A-D are routed to actual interrupt sources can (and will) vary between PCI slots, as configured by the PCI Controller (which might hardwire the logic), so that PCI devices defaulting to interrupt pin A (as recommended) will not necessarily share the same interrupt source on the host.

Now, IOC3 violates the PCI specifications in two ways:
- it will not answer to the first 0x40 bytes of configuration space access, with some addresses being shared (such as the first two BARs), and some not being answered, but without releasing the bus, so you can't even rely upon a bus timeout to recover in software.
- when it actually uses two interrupts, it does not advertize itself as a multi-function device.

Note that I write `when'. The reason is that IOC3 may not necessarily be fitted with all the subcomponents: some IOC3 flavours lack the Ethernet part, for example.

The IOC3 interrupt logic is to use pin A for the SuperIO devices (serial ports, parallel port, PS/2 ports) and pin B for the Ethernet, when it has both. An Ethernet-only IOC3 (such as the first three ones on the MENET board) will only use pin A, and a SuperIO-only IOC3 (such as those found on SIO UFC boards, or the second onboard IOC3 on Origin 2000) will only use pin A as well.

When the IOC3 device exists as a PCI card (such as the CADDuo), the interrupt assignment for pin A and pin B is controlled by the PCI Controller they are plugged into.

When the IOC3 device is onboard, and connected to a Bridge, XBridge, or PIC chip, routing of its interrupt pins is static and will vary accross systems; the rule of thumb being that it uses the lowest unused Bridge interrupt sources. For example, on an Octane, the on-board devices are the two SCSI controllers, Bridge interrupts 0 and 1, and RAD audio, Bridge interrupt 3. IOC3 will use Bridge interrupt 2 for SuperIO and Bridge interrupt 4 for Ethernet. But on a Fuel, the on-board devices are the SCSI controller, Bridge interrupt 1, the two upper PCI slots, Bridge interrupts 2 and 3, and the USB Controller, Bridge interrupt 5. IOC3 here will use Bridge interrupt 0 for SuperIO, and Bridge interrupt 4 for Ethernet.

Don't you love IOC3 now?

ivelegacy wrote: I think the most trouble will be around the PCI, customized by SGI, from the Intel specification I feel it's not a piece of cake, so I am expecting a true blood horror story with zombies, vampires werewolves, witches, black masses and a lot of black magic.

It's not the first you write this, and I think you are confused. The Bridge chip (and its offsprings XBridge and PIC) are PCI 2.1 compliant. It's only their IOC3 chip which is a fraud. If you don't deal with IOC3 in your PCI board experiments, you have nothing to worry about.

uunix wrote: Memory 128MB (I think this is enough?)

You might want to shrink that down to 64MB. Earlier Intel 430 chipsets for Pentium-compatible devices limit cacheable memory to the low 64MB, and putting more memory in them with an operating system which can make proper use of it can reduce performance... See https://en.wikipedia.org/wiki/List_of_Intel_chipsets#Pentium_chipsets for a comprehensive list.

Sorry to be late to the party.

hamei wrote: Within major versions they are supposed to be the same . If you have a library swahili-tagalog 1.1, and come out with an improved version 1.1a then it should do exactly the same thing but maybe with better spelling. So you should be able to replace 1.1 with 1.1a directly, is that not correct ?

No, not necessarily.

The major/minor versions of a library can mean two things:

• either the major/minor version of the software they are part of, which can be anything and only has a human meaning.
• or the major/minor version of the library interface embedded in the libfoo.so file (also known as the `soname').

What matters here, in order to get consumers of the library to keep working, is to take care of changing the major/minor versions only when needed, because keeping the existing tuple would actually break applications.

The usual rules, since the SunOS 4 days, are as simple as this:

• every time you add a new visible interface, you need to increment the minor version. This way, existing binaries linked against libfoo.so.42.0 will still run when linked against libfoo.so.42.1, and in fact the dynamic linker will prefer libfoo.so.42.1 over libfoo.so.42.0, but your new application using the new symbol will explicitely require libfoo.so.42.>=1 and will not run on a machine where you have not upgraded libfoo.so.42.0 to at least libfoo.so.42.1.
• every time you make an incompatible change to an existing interface (change the number of parameters of a function, change the layout of a public structure used by this function, remove a function), you need to increment the major version. This will prevent applications requiring libfoo.so.43.0 semantics to run with libfoo.so.42.* - they would be likely to dump core with this version.

Unfortunately, many shared library maintainers use the current project release as the soname, even if there are no interface changes, or, worse, even if there are interface changes requiring a major number change in a maintainance release. To be fair, most users don't understand this either, and getting angry ``why does your bollocks 4.38 release install libbollocks.so.72.0 and not libbollocks.so.4.38?'' is only funny the first two times.

In the `release early, release often' state of mind, interface changes will happen very often, and will theoretically require many different library versions. With a good packaging system able to remove orphaned libraries, this is bearable. The use of ELF symbol visibility, on ELF systems with modern toolchains, also help a lot, as this allows the visible interface to a library to be shrunk as much as possible.

Still, as long as software evolves, shared library version numbers will continue to evolve as well. And there is IMO nothing bad with this... as long as the versioning rules are understood and followed.

Sorry to dig an almost 3 years old post...

geo wrote:

vwarez wrote: It is worth what you can afford to pay.
For example, I placed $550 bid on this Tadpole ALPHAbook, but it sold for $1,314.79...
http://www.ebay.com/itm/200814581492?

hmmm i got the spare cash for this but hmm will see
wow! that ALPHAbook really looks good!! what a lucky bidder got that nice package does it mean all these interesting things only available in US and Europe right? how about Asia? is it possible? i can only imagine Japan maybe..

Since a few weeks, I have been in possession of an Alphabook, with a yellow block at the end of the power cord. The accessories which came with it (bag, floppies, documentation, SCSI terminators) match those from this auction; it might be the very same machine, unless all Alphabook came with them (but given there was a Sun DD50 SCSI-1 terminator among the accessories, this is very unlikely).

This is quite an odd machine. It has the same form factor as a Tadpole SPARCbook but completely different connectors, and a dock giving access to more; but the LCD, the 2x16 information panel, the keyboard, the disk and PCMCIA slots are the same. The two memory slots in the battery compartment are the same, as well. This machine having 128MB, it has two 64MB SIMMs which are actually two 32MB SIMMs glued together...

Vladio wrote: I'm thinking it's time to add a new-old computer to my collection, I like the old RISC machines. I picked up an SGI Octane 2, dual 600, a couple years ago and really enjoy using it. Next up on my list is something running either a Sparc, PA-RISC or Alpha processor(s). In reading up on the different DEC personal workstations that were made I saw that some were designated with an "a" for Windows NT or "au" for Digital Unix. My question is: can a box with an "a" designation be loaded with Digital Unix?

Yes. The difference between `a' and `au' systems is that `a' systems shipped with AlphaBIOS, while `au' systems shipped with SRM. You can upgrade from AlphaBIOS to SRM by booting the SRM update, either from floppy or from a firmware upgrade CDROM.

ClassicHasClass wrote: Right. NetBSD, Tru64, VMS, etc., need SRM. Only Linux, it seems, can tolerate ARCS.

By ARCS, I suppose you mean `AlphaBIOS'? We're not on SGI hardware here

uunix wrote: What's your naming convention?

Most machines here are named after rivers from the area I was born. As the number of machines grow, the area used to pick names grows as well.

My Multia is dying on me (well, it has been for years, but recently it's became unusable). Its vertical stand is available for free; if you're still interested in it, send me your snail mail address in private and I'll have it shipped later this month.

smj wrote: Referring to what makes it an "a" versus an "au" - didn't the "au" models always have SCSI, whereas some "a" models were only shipped with IDE?

No, `a' models shipped with SCSI, as opposed to `no suffix' models.

hamei wrote: I don't have this problem. I use Irix. Every day, all day

All Irix and no play makes hamei a dull boy...

urbancamo wrote: Yes, I did measure power consumption a while ago... I quoted 45 watts idle but there is no power saving features that I know of in this box so it is 45 watts whatever.

This probably includes 15W for the disk alone. Replacing the disk with an SSD in an adapter would save even more power (and noise) if you want an as-green-as-possible Vax.

nyef wrote: As a data point here, a CAD DUO card doesn't physically fit in a Fuel PCI slot. I suspect that the Fuel PCI is run at 3v3 while the Octane PCI (which does take a CAD DUO) would be run at 5v. There's also something about different versions of the RAD PCI sound card for Fuel?

The Fuel indeed has 3.3V PCI slots, so only 3.3V and universal PCI cards will fit. The CadDuo is a 5V card and therefore can't be used in a Fuel (but can in an Origin 200 or a shoebox/shoehorn).

55cancri wrote: The HIL Keyboard was delivered this morning and since I still have no output on the screen, I had to stop the boot process, navigate through the menu and chance the console output blindly!

Didn't you know you could press the tab key repeatedly during PROM initialization to have it cycle through video modes, until you'd find one your screen would display?

Krokodil wrote: Tru64 is the only official UNIX the platform ever had.

Allow me to disagree. Linux was kind of supported at some point, since user guides for the late models (DS20, DS25) explicitely mention Linux and how to set up the SRM parameters for it to boot, with example boot logs.

StN wrote: My question is - is it possible in the PROM console to disable the GIO sockets and turn off the console output so that it won't report the GFX subsystem? And if so, can you use the nvram tool to turn them back on? Or is there a hardware jumper to reset the PROM?

The answer to all your questions is `no'. You can instruct the PROM to use a serial console even though graphics are present, but they will show in the hinv anyway.

If you don't see your impact assembly in the hinv, chances are that they are damaged or partly disconnected. Try to remove the board assembly and reseat them, making sure the inter-board connexions are well set. Also, make sure the small ribbon cable going from the power supply to the EISA/GIO backplane is firmly connected.

Oh, and welcome to Nekochan!