The collected works of Kumba - Page 2

ivelegacy wrote: everything > 1.5Gbyte has issues with the XIO_PCI-EHCI, no chances about that, unfortunately.

ivelegacy wrote: no, with 2Gbyte of ram the XIO_PCI has success in its probe but the PCI_EHCI NEC chip does not respond correctly, while if i remove 2 memory modules (each one is 256Mbyte, 8x256Mbyte=2Gbyte, 6x256Mbyte=1.5Gbyte) then the issue disappears and i am able to have a working PCI_EHCI.

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.

ivelegacy wrote: good, it may be your patch is good to be back ported to 2.6.17 in order to fix the 2Gbyte memory problem.

I'd recommend moving on from 2.6.17 and focus on 3.19+. My patch only addressed the PCI bus enumeration problem, and that seems to have been something that came after 2.6.17. There's several known memory issues that I haven't figured out yet (namely why CONFIG_SLUB screws up and the whole R14K TLB problems).

ivelegacy wrote: i had 2Gbyte installed, and i needed to remove a few of them in order to have the usb working, also other issues with the V6 and Impact/Pro, so … it's not as easy as expected with linux, and finally … do not expect to have a recent kernel working, everything above 2.6.17 is simply dead/broken and needs a lot of work to be fixed

Minor correction (for the Google Spider), everything between 2.6.17 and 3.13 is/was dead/broken in many varied and fantastical ways. Starting with 3.14, I got Octane to boot Linux again, and sans things like SMP support, it runs fine now for command-line stuff. Still a lot more work to be done, but it's in good enough shape that I can start cutting the patches up in a few months and see about getting them into mainline where it'll get greater exposure (and maybe fixes).

TeamBlackFox wrote: Sure, but the XSGI, Magic Desktop, 4DWM etc isn't even PART of System V R4, furthermore they should be able to release any non-original SVR4 code. Sounds like poppycock to me as at the time of that letter, 2003, IRIX was still being developed. And now, with Rackable continuing to ignore the original SGI legacy mostly, it makes sense that they've no more commercial interest in these things.

Nicknames redacted to protect sources, but this is a snippet from a conversation that I had with someone back on 20110312 on IRC about SGI and open-sourcing:

TeamBlackFox wrote: I actually found the email CEO of the new SGI/Rackable Systems: [email protected] ...

Maybe the right person can light a fire under his arse, preferably a customer with an active contract, to do SOMETHING, like I dunno, offer a hobbyist license program for IRIX in the vein of the VMS one, or something.

CEOs are up there ::points WAY up in the sky::, and little hobbyists like us are down here. In fact, we're so far apart, I have to assume that CEOs don't breathe oxygen. Instead, they absorb cosmic rays and gamma rays as their source of energy. Ergo, attempts to e-mail them will simply mean the secretary reads it and puts it in the trash, it automatically goes to the spam folder, or skips the spam and goes straight to /dev/null.

IOW, emailing the guy ain't going to work. Especially if it has anything to do with IRIX source code. Likely, SGI has similar problems that Sun had when they prepped the Solaris code for open-source under the CDDL. And if certain sections of IRIX are copyrighted by eneties that no longer exist and ownership chains can't be traced to active entities, then they're stuck. If you've never heard of a cheap 1980's movie named "Monster Squad", they had the same problem. After the movie was made, the original studio got split apart into three entities, each owning a piece of the original copyright. It took until 2006 to re-acquire all three pieces so the film could be re-mastered and put onto DVD. An OS kernel is going to be a lot harder.

What you might have luck getting is hardware documentation. That's what I'd sacrifice someone's soul for: documentation. Especially anything on the R14k/R16k, HEART, XBow, etc. Hopefully, over time, those documents will leak out and Google's spider will find and cache them. Until then....I wait.

TeamBlackFox wrote: While I agree with you on the professional workstation market being a figment of the past, I disagree. GNU/Linux users especially seem to hate the commercial UNIXes especially, the only ones interested in IRIX being open sourced are the BSD and illumos communities, outside of those here.

I think you need to talk to more GNU/Linux users. Especially the older, more seasoned ones. Stay away from the young hotshots, and you'll find your subjective analysis will gain some objectivity.

I personally would like to get some time on an AIX, s390, or even a zOS box. I also want to play with the obscure UNIXen like NEC's SUPER-UX (for their SX-9 systems), Cray's UNICOS, and whatever Honeywell has current. I think they still cook up supercomputers periodically... Throw in hunting down QNX and UnixWare 7.1.4 installs at some point. I'm not saying I'll ever master any of those, but being able to spend a few hours dorking around with them, likely breaking an install? I'd love to.

alexott wrote: Are you sure there is a lot of interesting stuff left buried in closed IRIX, which these communities need for the their operating systems?

From a hardware standpoint on SGI machines, IRIX's source would be very interesting to look at. Especially 6.5.30 and bits on the R14000/R16000 TLB hardware.

foetz wrote: i'm aware of Illumos but whether that's an actual improvement over the original Solaris is very much up for discussion

Considering Oracle has resumed closed development of Solaris again, I'd consider Illumos a fork now, one which will develop entirely independent from Solaris 11+. Oracle promised to periodically release updates to the ZFS code, but, it's Oracle. So I wouldn't be surprised if they halted that after a while as well.

commodorejohn wrote: It is an interesting point that the most likely outcome of making the IRIX source available isn't an IRIX revival, but the appropriation of a handful of components into the Linux ecosystem. The philosophy of the GNU and Linux developer communities overall (and, consequently, a large part of the open-source community as a whole) has always been "embrace, extend, ASSIMILATE!" and I don't doubt that's mostly what we'd see here, if it came to pass. It's only to be expected when you make your software also an ideology.

This isn't something unique to software development. It's a core function of life. Adapt, or die. IRIX has many useful things internally that Linux might be able to emulate (it could never copy due to license differences). The release of the Solaris code and ZFS spurred and influenced the development of btrfs, for example. On the BSD-side, I'd imagine a lot of the hardware bits would get sucked up from IRIX so as to improve support on old SGI gear.

But look beyond software. Successful anything is emulated and/or copied by others. In 2005, Sony ridiculed Nintendo for their Wii Remote, then immediately turned around and added accelerometers into their redesigned "six-axis" controllers (after the "batarang" fiasco). The number of coaches who "mutually agreed to part ways" with their NFL teams jumped after Jim Harbaugh left the San Francisco 49ers using that strategy, usually over minor or trivial things.

IOW, if it works well, it'll get copied. It's not inherently a Linux-only thing to emulate/copy other successful things. It's just that because Linux seems to be everywhere, that Linux seems to do it the most often .

Oh, and throw GNU/Hurd in the list of UNIX-like OSes to try out. I'm certain that'll be able to boot to a basic shell prompt before the heat death of the Universe, so I'll have to try that out as well.

TeamBlackFox wrote: Already have met countless GNU/Linux guys and gals - you're by far the friendliest and most pro-social of them. I get insulted because I don't advocate their "free software" agenda it seems - I realistically see that all software must coexist in order to be successful. Many GNU/Linux users of all ages share the anti-proprietary sentiment, and it seems to be growing.

Insults are only insults if you let them affect you that way. Everyone's got an opinion, so there's always going to be someone who is insulted. Just a fact of life. Don't let it get to you. If some GPL fanboi starts one up with you, rather than get insulted, play along and troll the guy. Have fun, and maybe look for openings in their arguments and slip a few truths in on them when they least expect it.

TeamBlackFox wrote: I'd be the first to start revitalizing IRIX if the source was released. Between illumos, and the BSDs, there's plenty of code to patch any holes left behind, because there are definitely original parts to the IRIX kernel - the pieces that are IRIX-original I imagine would give us all the references we would need to develop "OpenIRIX" or something.

Is it not possible that SGI/Rackable could open-source the IRIX kernel in a license that would be incompatible with the BSD license (other than the GPL, that is, even though we know that won't happen)?

Personally, I'd love to see NetWare open-sourced. It's such a twisted, yet weird platform. An "OpenNetWare" platform's first objectives would be to disentangle Java from the NW kernel in its entirety. There's just something fundamentally wrong about running Java processes in kernel threads.

TeamBlackFox wrote: Pardon me if I find this funny, but I've used Hurd, Debian GNU/Hurd specifically.

This was the intent. Notice the "heat death of the universe" bit in there.

TeamBlackFox wrote: Last call, anyone? Before I give up hope and buy new 256MB modules, because my Octane fried the old ones I had >.>

Did it include some fava beans and a nice chanti?

Did anyone here win this auction?

I've practically given up bidding on mirei's items. There's a group of 2-3 bidders that are able to outbid pretty much anyone else now, though I've definitely made them pay for a few of those items.

hamei wrote:

astouffer wrote: Just think how cheap and easy it would be to counterfeit these :twisted:

How do you know the one that sold was real ?

I've bought enough odd SGI stuff off of that seller to have a reasonably good idea that she worked for SGI in the 1990's and accumulated a lot of corporate junk. I told her she'll make bank off of that stuff, but the vulture sellers that are outbidding everyone are something else. They're not relisting the items on eBay, either, so I have to wonder if they aren't former SGI employees or something.

bittenbyte wrote: I tried to mail him on his gmail and yahoo account
no luck yet. as SGI these days is not the same company anymore silicon graphics ceased to exist in the last turmoiled SGI (aka rackable) financial switch. leaving behind the IP from IRIX, XFS, and as a result there is no legal entity that can claim property of the source code.

in this light it should be possible to release the linux source code to 5Dwm and all its surrounding code without any legal implications.

even the original Irix sources which are silicon graphics proprietary ( changed from the Unix SVR4 base code).
irix ended in 2006, support ended in 2013, only under retired mode, fixes only on demand, if possible.
this classifies IRIX as abandonware since 2013. 2 years ago.

A lot of the proprietary stuff was reportedly spun off to an external entity called Graphics Properties Holdings Inc (GPHO) or such. Uncertain of what it is they actually own nor what legal or business links they have to the Rackable-owned elements of SGI. I believe some stuff was also retained by MIPS Technologies, itself now a subsidiary of Imagination Technologies (Imgtec).

bittenbyte wrote: oh well, what is their interest in this, there is 0 value to be gotten here.
I would just let it be, the most important parts of irix are already in Linux, pcp, numa, xfs, ... etc
the desktop was not the most valuable part, it did make the experience unique, and usable from a graphics app.

used to work on poweranimator / newtek lightwave on Onyx and onyx2...

There would still be some interest, at least for me, in seeing the IRIX source. Namely in helping to improve Linux's support of the old MIPS hardware. Hardware documentation would be better, since I doubt the IRIX code would be released under a GPLv2-compatible license, but there could possibly be code comments about oddities or errata of the hardware that may not have made it into documentation that may be of value.

If you have a second one by chance, let me know as well...

TeamBlackFox wrote: I do not know C++ and do not care to. Do not ask me to port C++ based software - not gonna happen anytime soon.

TeamBlackFox wrote: Priorities are first on getting them to compile using MIPSPro, if not I will fall back to GCC.

You might want to look at open64 as well. It's an old variant of gcc merged with some of the code from an unidentified version of MIPSPro. I've never tried it, though deep in the code, you can find some information on CPU scheduling for the R10K and Loongson. Main website is down right now, but was up a few weeks ago:
http://en.wikipedia.org/wiki/Open64

TeamBlackFox wrote: You're free to suggest programs, ...

systemd? :D

I'M KIDDING

ledzep wrote: Agreed. Having used SGIs back in the day (Digital Domain, Disney) it was always a comfort knowing you could leave those machines up for days upon days (can't say that for any modern PCs I've seen) without incident.

I have easily kept Windows desktops running for 4+ months w/o a reboot. Probably longer. Sadly, we live in a world of constant cyber threats now, and Windows has a *lot* of code that needs patching, so there's going to be the need for the periodic reboot. I honestly cringe to know what odd security bugs still exist in the final release of IRIX that no one knows about.

jan-jaap wrote: If you limit that to SSH you should be reasonably safe, even if the source of random on IRIX probably can't compete with current implementations.

I have NetWare VMs, and that's probably got far worse vulns than even IRIX can dream of (running Java 1.4 in kernel threads, anyone?). What's the OpenSSH version in IRIX? I think there's been some recent vulns that SGI's not patched. Though, I'd assume someone has also built a nekoware version that corrects that.

robespierre wrote:

foetz wrote: please do list those that affect irix. i'm sure that'd be very interesting for everybody running irix.
heartbleed for example is not a problem.

Do you use glibc?
http://www.openwall.com/lists/oss-security/2015/01/27/9

IRIX doesn't use GNU libc as its central C lib, so it wasn't affected by GHOST. Furthermore, GHOST itself was largely a non-event and absolutely no where near the scale of Heartbleed or Shellshock. Section 3 of that oss-security link highlights the threat level pretty well:
The only reason GHOST got into the news was because one of these new cyber-intelligence firms sat on the vulnerability for several months while they worked on PR and marketing material prior to announcing it. Somehow, a link to the PR image got leaked out, and someone checked the creation date on it and noticed it was ~3 months old (Oct 2014, since this happened in Jan 2015), and blogged about it.

Ditto for the recent Qemu VENOM attack. Largely a complete non-event, since that only affected Qemu and Virtualbox users via antiquated floppy disk driver code (hah!), and it had a very narrow set of requirements in order to be exploitabe.

----------

If you really want to harden yourself from attack, there are a few easy, simple steps beyond the usual patching and firewall stuff, especially for Windows users, that can be followed:

Adobe:
- Disable Javascript in Adobe Reader/Acrobat.
- Disable Execution of embedded PDF Attachments in Adobe Reader/Acrobat.
- Install a browser add-on that prohibits automatic execution/loading of Adobe Flash/Shockwave.

Specific to Microsoft Office:
- Disallow automatic execution of macros, especially untrusted. If you wrote it yourself, MS has steps on creating a self-signed certificate that you can use to allow your own code to still run w/o prompting: https://support.office.com/en-nz/articl ... 1c35079891

Java:
- If you have no choice but to use Java, then keep it up-to-date. If, for whatever reason, you're wedded to a specific, vulnerable version and you can't run multiple versions concurrently, then prevent your web browser from loading up Java content at all.

Those are the three, most commonly-used attack vectors in pretty much all cyber attacks these days. The fourth major vector is a "watering hole" attack, in which a legit website is compromised with things like hidden <IFRAME> tags that exploit a known or unknown browser vulnerability to load malicious code (and typically, this is actually done via Flash/Java, but there have been a handful affecting IE directly). A "spearphish" email is sent to a fairly-specific list of targeted individuals, usually on corporate systems, in an attempt to get them to visit the watering hole site and execute the exploit. These are a lot less common, and I'm fairly certain most people here are smart enough to not fall for your average spearphish e-mail.

If you already do all of these things, but know someone that doesn't, clue them in. Use a 2x4 if needed. A little pain can go a very long way.

TeamBlackFox wrote: ...MIPS is historically not well supported on Linux...

Eh, that's not entirely correct. It depends heavily on the particular MIPS platform you're running Linux on. If you're referring to the new MIPS32R6 stuff by ImgTec, that is *very* well supported. If you're talking Indigo² R10000, then this statement applies.

rwengerter wrote: I want to be able to run at least some Irix binaries.

This was attempted once, a long time ago. Ralf (the Linux/MIPS maintainer) exorcised the remaining bits of code a few years ago (via this URL linked to by bplaa.yai) since it was unmaintained and didn't work. If you start from that, you might be able to take a look at how it might be brought up to work with current Linux kernels. Mind you, this will not be a trivial project or task. You can probably find more information out in #mipslinux on Freenode. It can be dead in there at times, though, so just idle until you see activity.

nyef wrote: This looks like the sort of project that can see promising results fairly quickly, but then get tied up with various undocumented incompatibilities and whatnot very shortly afterwards. The idea of running an IRIX userland in a Linux chroot is amusing, though. Or even just as the root filesystem. That would be worth some serious hack value, but I'd expect it to be a lot of work.

It would allow for a lot of study of IRIX program behavior, especially if one could patch strace/ltrace to see what commands it sends back and forth (such as Xsgi, for example). But would be very difficult to pull off and the ROI of time would be questionable. Would need a dedicated maintainer to keep the emulation layer in the kernel working, else Ralf would just pull it again a few years down the road.

nyef wrote: I have lots of other things to do, so I am not particularly willing to play dedicated maintainer.

Wasn't nominating you in any way to tackle this :) Just pointing out in general that it would require someone willing to upkeep it for some time because of the way the kernel can change its internals periodically.

nyef wrote: For that matter, I still don't have any "fully working" MIPS64 Linux systems quite yet (by which I mean with a working bootloader, and SMP if it's not a Fuel, and there's that IOC3 IRQ conflict, and if it is a Fuel or Tezro then the graphics card driver, and then there's the L1 controller stuff...).

Not to threadjack, but IOC3 IRQ conflict? IIRC, at least on Octane with the Metadriver, IOC3 should be requesting two IRQs, one for ethernet, and ethernet+2 for I/O by kb/mouse. Serial uses a UART polling hack built into 8250 core to run the serial ports for now (by telling it to use IRQ 0), but the end goal would be to make the Altix DMA-capable IOC3 driver work.

nyef wrote: Second, can we use strace against Xsgi on IRIX itself to any useful purpose?

Apparently so. I was digging into my chat logs from 2004, and Stan used a patched strace to monitor Xsgi calls to MGras, which helped him figure out some of the DMA bits needed to write the Impact driver. I don't think he ever released that patch, though. Would probably be useful for a lot of things outside of Linux porting.

nyef wrote: First off, I'm not (yet?) using the IOC3 Metadriver, just the IP27 drivers.

Yup, Metadriver isn't in the tree just yet. I hope to start sending it in after 4.2, but we'll see. Technically, it's already in the tree, just under drivers/sn, and it's Altix only, so my actual patches move it to drivers/misc (where ioc4.c is at) and fixes it up to work on MIPS. Only problem is, I don't know if those changes break ia64/Altix, since I don't have one of those systems...

nyef wrote: Second, that "just add $n$ to the IRQ number" idea is horrifically broken in a modern Linux kernel (dynamically-allocated IRQ numbers, after all). It probably works on IP30 because of the pcibr driver allocating numbers for all eight IRQ pins at once. Next thing we know, it'll turn out to vary depending on which type of system or expansion card the IOC3 is in.

Won't argue with you there, but it does call request_irq() to get the IRQ numbers, and this works fine on IP30 and IP27 so far. It'll be interesting to see if it JustWorks(TM) with IP35 as well, once I can combine your code with some of my out-of-tree patches. 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...).

nyef wrote: Third, I misremembered. My notes say that it's a conflict between the SCSI controller and the USB host controller leading to lost interrupts, not the IOC3. Which isn't to say that there's not an IOC3 IRQ issue still, but that it's not at the level of "known IRQ conflict"... yet, if ever.

It might be IOC3. It's a weird little piece of hardware, and Cthulhu knows if the existing in-tree driver isn't messing things up somehow. In reality, the MIPS IOC3 bits are all in ioc3-eth.c. Only Altix uses the drivers/sn/ioc3.c copy (for now).

nyef wrote: Fourth, none of the MIPS Bridge/XBridge/PIC drivers, even for IP30, support all of the song and dance involved with shared IRQs, or the mapping of interrupt lines other than INTA.

There's a lot not currently supported, such as hard-wiring the RRB allocations, Octane's screwed-up DMA mapping (which I highly suspect is giving me grief with >2GB RAM), using the one-wire drivers to query the NIC chips to build a hardware inventory, etc...

nyef wrote: Sixth, Ralf was suggesting switching to IRQ domains...

That or this new irqchip thing. Or are both used? It seems right as I finally figure something out in Linux, some wise guy goes off and implements an entirely new subsystem to replace it. I'll loathe the day fbdev/CONFIG_VT become dependent on systemd...if those devs ever get their way, that is :/

nyef wrote: Hrm... I wonder if we could do that to get better support with the VPro driver? Although first I'd need to get a working VPro machine...

Entirely possible, but way beyond my skill level. Stan was the graphics god. Even though I understand things better now than I did 10 years ago, it's still boggling how easy hardware hacking came to him.

maxxi.desktop wrote: that looks awesome! As per my agreement with SGI, MaXX can ONLY run on Linux intel . This is the main reason why I couldn't release the source for 5Dwm for example. But again, I am reopening the communication channel with them... will see :)

Think they'd be open to dumping hardware documentation for their old MIPS platforms? *Really* want to get my hands on the "Godzilla Architecture Specification" and "HEART Specification" documents...

zagnut wrote: Just for noting, the other ports I have found for SGI boxes are Debian, linux-mips, linux ce-mips and Gentoo. But, I'm not sure if any of those are still being developed or compatible on the IP30 specifically. The Gentoo port appears to be dead in support. But I am not certain of that.

I'm the guy actively working on the Linux/IP30/Gentoo support, as time permits (and it hasn't permitted much, sadly). Gentoo does work mostly fine on IP30, with various caveats. Getting it installed is a tad tricky right now because building a netboot by hand is not easy, and my last attempt mostly works using the musl libc, but a key program, mdadm (for managing software RAID) page faults for no good reason. Probably just going to rebuild the netboot using bloated glibc, because I have no working uclibc alternative at the moment, and something is better than nothing. Maybe a -Os based chroot...

I just got SMP support working again in 4.1, which I haven't released yet due to time (any time lords in the house?). Side-tracked for 2-3 weeks on trying to fix DMA/memory, but have to abandon that for now. Maybe can do a final sync-up of the patches tonight and place mips-sources-4.1.2 into the portage tree, but that may not happen until next weekend now.

Generally speaking, *once* you get Gentoo installed, it runs pretty damn stable of all of the supported SGI boxen in Linux. Aside from the electrical draw (which can be reduced by removing the graphics board and inserting an XIO sled w/ four blank plates), it makes a good build machine, especially w/ the higher-end CPUs. Ironically, 2x 600MHz R14K compiles packages faster than the 4x 500MHz R14K in my Onyx2, and at half the electrical cost. Mostly because the 'configure' phase of most packages runs on one CPU only, and 600MHz is going to move along quicker than 500MHz in that regard.

zagnut wrote: However....I've never used Free/OpenBSD either. Since I am turning my Octane into a NAS/RAS RAID for my photography uses, and redundancy, I may try OpenBSD in order to familiarize myself with it due to choosing that as my Octane's OS. OpenBSD seems to have the greatest support for the IP30.

If miod is around, he can tell you all about OpenBSD/IP30, as he's the lead developer there. But generally, OpenBSD has working netboots and install media, so if you're looking for a no-frills, "git er done" approach, probably your best bet.

zagnut wrote: And I pronounce as LIN-iks :)

https://www.kernel.org/pub/linux/kernel/SillySounds/english.au

PS, forgot to add, the "linux-mips" port is actually the main Linux/MIPS development group. And while that got started with Linux on SGI, it's become much more than that now, with Imagination Technologies (ImgTec) buying up the old MIPS Technologies and working on putting out 32-bit/64-bit products to compete with ARM in the embedded space. The head maintainer of Linux/MIPS, though, is Ralf Baechle and he's an old-school SGI guy with extensive knowledge on Indy and Origin 2000/Onyx2 systems.

"linux-ce-mips" likely refers to the old, now dead, attempt to port Linux/MIPS to the WinCE-based devices, many of which were little-endian in nature and were quite limited in CPU and RAM.

Debian's core support is (still?) focused on IP22 (Indy/Indugo2 R4x00) and IP32 (O2) systems. Uncertain of support beyond that, but I do know some of the Debian/MIPS devs have IP28 (Indigo2 R10000) and IP30 (Octane) hardware. You'd have to ask on their mailing lists for current support status.

foetz wrote: very nice, just correct the toolchest font and i'll change to "extremely nice" :D

Shouldn't the items in the toolchest also be italicized?

"If you're livin' in a bubble and you haven't got a care
Well, you're gonna be in trouble, cause we're gonna steal your air
Cause what you got is what we need and all we do is dirty deeds
We're the Spaceballs, Watch Out! Cause we're the Spaceballs
We're the master of space
Hey, Don't mess around with the Spaceballs
Uh"

There was also this one:

FlasBurn wrote: Does anyone have an idea what I can do about it?

It might be your system board or PROM version needs updating (my guess is PROM). One of my O2's is basically an O2+, just with blue skins. 1GB RAM, RM7000 350MHz, MD-RAID1 w/ 2x 73GB drives, runs Linux. PROM is 4.18, and the system board is one of the later revisions.

ivelegacy wrote: Indigo2 cpu_module hack: can we predict the expected speedup between an R10K@195Mhz and an R12K@200Mhz ?

the difference is just the ISA, new instructions and more efficiency in the R12K core
I do not expect a great difference

R12K had a few enhancements to branch prediction that likely helped a bit (e.g., global history), but the real kicker would be the Delay Speculative Dirty (DSD) bit added to the CP0 config register, which would be useful in helping to offset some of the side effects of speculative execution, which affects non-coherent machines like IP28 (and IP32). Would still need to back that up w/ cache barriers and, I think, some bounce buffers, but it'd make running Linux on that platform less of an annoyance.

FlasBurn wrote: I hope that I can do more tests at the weekend. I´ve got an older board with PROM 4.18 and a newer board with PROM 4.14 or 4.15. Problem with the newer board is, I would need to get the board out of the "tray". Is this possible?

Yup, entirely possible. More tedious and tricky than difficult, though. In addition to the various screws you have to undo, you also have to unscrew the mounting screws on the rear-facing ports as well (and put them back when re-mounting the board).

hamei wrote:

guardian452 wrote: Linux mint left a foul taste in my mouth ...

Do you suppose there are enough people in the kermyooonity to create a "distro" <spit> that's quality-centric ? It would be a lot of work but there's really nothing out there like what Linux used to be, or Irix, or BeOS or even classic Macintosh. It's all such avaricious shit now :(

Or is personal computing well and truly dead ?

Gentoo lets you build your system however you want. Sure, it's not for the faint of heart, and even I've had my days of tearing my hair out over strange depsolver oddities where Perl wants to marry its own mother. But in the end, Gentoo gives any user more switches, knobs, dials, levers, and even some booby traps, that lets them tailor the systems however they want, given time. You can maintain your own custom ebuilds in an overlay, set CFLAGS however insane you want (just don't blame compile-time failures on us unless you have proof), turn off various features in packages via USE flags, and so on.

We're still one of the better distros as far as SELinux support goes, we've got a full hardened profile that uses grsecurity+PaX, we support different libc's, like glibc, uclibc, and just recently, musl. There's even, as ghastly as it sounds, Gentoo/FreeBSD, which uses Portage as the package manager instead of Ports (but retains the BSD Userland, so no, it's not like Debian's kFreeBSD). Oddly enough, I actually like our FreeBSD port better than original FreeBSD. Multiple architectures (the ia64 team would love some help, if anyone wants to put their Prisms and Altixes to use), multiple ABI's (MIPS o32 and MIPS n32 are well tested, need some n64 love), etc.

We've even got an active s390 port, just in case anyone has one of those sitting in their kitchen/garage. Could use some help on a VAX port, though...

So, no, personal computing is far from dead. The definition of "personal computing" might have changed from the desktop to the laptop to the tablet, but who wants to live their lives defined by someone else's definition? Redefine "personal computing" to whatever you want and go with that.

hamei wrote:

Kumba wrote: ... the package manager ...

There. Right there, you put your finger on it, and this is probably why there will never again be a Linux I can stand.

"Package manager." FUCK PACKAGE MANAGERS !!!

The "tree" (/usr/portage right now, though that may change) is just a collection of build instructions. I.e., if you want to compile software A, odds are likely you'll need to have software B, C, and W already built. So really, all Portage is, is a glorified dependency solver with extra bits like tracking what files were installed and where, so it can remove them later on if needed. Not everyone likes Portage (the name for the primary package manager in Gentoo, not the tree of ebuilds; yes it's a touch confusing), so one guy went off and wrote his own, called Paludis. So Gentoo even gives users choice there, too.

That said, there's nothing wrong with the general concept of a package manager. Ultimately, all it's doing is following instructions. Source-based distros like Gentoo just allow a lot more functionality because you are giving the user control of what to compile. Binary distros are more limited because of just simple combinatorial insanity -- choices have to be made somewhere, and sometimes, those choices don't go over well with the users (like Debian switching to systemd for Jessie). How a distro handles the making of those choices is often where the conflict lies (again, Debian's method for handling the systemd thing pissed off a *lot* of people).

But the package manager itself? It's actually innocent. Surprisingly.

hamei wrote: Sounds like Gentoo might be nifty.

Then what ?

Yeah. A huge shitpile of applications designed and built by chimpanzees poured over the top.

What if I don't want atk anywhere near my computer ? thanks much but I am not crippled.

What if I can't stand CUPS ?

Why the hell should I want Truetype when Type1 is what real printers use ? When Type1 is better ? When X supports Type1 without six more layers of shit ?

I could continue for a week :P

Then don't build atk and its related dependencies. Or CUPS, or truetype fonts, or X entirely, etc. That's the awesomeness behind USE flags:
https://wiki.gentoo.org/wiki/Handbook:X86/Working/USE

Downside is, there's almost 10,000 USE flags, so for the person who really wants to control things, they'll spend a lot of time reading over both global flags (those which affect multiple packages in the tree) and local flags (those which are specific to a small handful of packages, or individual packages only). This is where binary distros win out, as most people just don't want to invest the time into completely tailoring an OS to their liking. They're more apt to accept the defaults and just "get used to it", they figure, like everyone else.

I personally don't use CUPS, nor atk. I pretty much eliminate all sound-related packages entirely from my main Linux system. But, you have to watch what you merge, as sometimes, a package update adds a new dependency on something you don't want. So a lot of users always test an update by passing the '-p' flag to emerge to see what actions emerge would take for the parameters given to it. Others pass the '-a' flag, which causes emerge to prompt the user for every package merge.

hamei wrote: The point, to me, is that the operating system itself can be mucho nifty (this seems to be where all the Loonies with taste hide out), but if the applications are trash, what's the point ?

The Desktop, in LoonixLand, has become nothing but a mass of Windows wannabe apps, except with no quality control.

There's really no good answer for "Linux on the Desktop". Humans love to copy what works, and give Microsoft credit, Windows does work, and works very well. The NT Kernel especially is a piece of work. Side-effect of Windows being successful is people copy it. Some do it poorly, while others do it well. The nice thing, though, is users have the choice to choose what interface they want to run. The downside is, unlike most other Linux/UNIX/BSD packages, Getting X to work is often an exercise in futility and voodoo sacrifices. And then, you go to try and figure out how sound works, and next thing you know, Windows is getting reinstalled.

Also, a lot of free software is coded by one or two people. Sometimes, it's just a project that they started for themselves and later decided to dump it out to the rest of the world (ironically, this is how Linux got started). Other times, they want to really make a polished product for some kind of motivation. That means further lack of consistency between projects.

hamei wrote: They need to get away from package managers entirely, instead put the work into making the build system robust, reliable, flexible, and functional.

Again, it's not package managers that are the real fault. Linux is the way it is because it's extremely heterogenous. Lots of little parts each doing their own thing w/o really considering what every other part (mostly) is doing, let alone what the whole organism is try to do. Imagine a Linux distro as an OS designed by intelligent cats (no, not the Kilrathi). It's very....ADHD.

hamei wrote: And we need a penalty box for anyone who says, "Works in gcc !" -- a line from each ankle to the stern of Arneson's speedboat, fifteen minutes on the Bay. There's nothing like a 50 mph power enema to teach people to keep their stupid trap shut :D

gcc is still the only free, multiplatform, multiarch C/C++/Ada/Java/Fortran compiler out there. Clang/LLVM is coming along nicely, but it's still not there yet, especially on the other, non-Intel architectures. There's a lot of work and effort going into making Clang more robust, and for once, gcc will have some serious competition, which is a good thing.

uunix wrote: Maybe they are working on a new version? Backwards compatible..

I predict that the release of NetWare 7.0 will happen before this.

After a ~2 month hiatus, I've got the Octane running and have been building N32 stages for the last week. mips4_r12k_n32 and mips3_n32 are done, but then I discovered a ~2012 uclibc-based stage4, mips3 big-endian, that another Gentoo dev rolled, and have been trying to bit-bang that into updating so I can use it as a seed stage to finally create new MIPS uClibc-based stages for generating new netboot images. Install stages are only good if you can boot something to install them with. Last uclibc stages were done in ~2006 or 2007.

I had tried a musl-based netboot image, but I have been experimenting with PAGE_SIZE=64K on my Octane/Origin kernels lately, which really helps speed up compiling (shaves ~45mins off of a binutils compile). However, musl seems to hardcode the PAGE_SIZE it was built with somewhere, so if you booted a kernel with PAGE_SIZE=4K with this musl netboot....all sorts of problems cropped up. Glibc is just too bloated to make an all-purpose netboot, as IP22-class systems have severe limitations on the size of the kernel image that can be loaded, and IP32 can get fussy as well.

Other successes include gcc-5.3.0 building successfully under uclibc (O32). I'll have to build it again under glibc (N32) later tonight to see if gcc PR66038 is resolved now, as that's prevented me from successfully building any gcc-5.x release under glibc (N32) so far. If that holds true, well, I'll be restarting my stage builds all over again. It's a pity the Onyx2 still locks up at random, else I could run that to speed up my stage builds. I suspect the lock up has something to do with a race condition and page migration, but I haven't had time to chase it down much more.

nyef wrote:

Code: Select all

*    - Greater than 2GB memory causes problems with DMA.  This is a long-standing
*      problem and patches to fix it by DMA experts would be greatly appreciated!


On my list to hack on once I get a working IP30 setup. IP35 doesn't have a problem with this, and I have some experience with getting DMA working on XBridge and PIC, and BRIDGE is basically XBridge so I don't expect too much trouble on that front.

Hopefully I'll be able to get you a working beta-netboot within the next 1-2 weeks for the Octane, if this uclibc experiment pans out. The DMA thing has been driving me up the wall, because once the 2GB barrier is worked around and I can hunt down some more high-density RAM chips, I can maybe use a ramdisk for some of the compiling to further speed things up.

nyef wrote:

Code: Select all

*    - Do not use OHCI-based USB cards in Octane.  They're broke on this machine.
*      Patches are welcome to fix the issue.


On my O300, I find that enabling the OHCI driver causes the SCSI driver to stop functioning (!).

I don't even know why anyone would want to run USB1.x anymore. I should probably get EHCI and xHCI cards and plug them in to do some USB2 and USB3 testing under IP30. As long as nothing I test is a USB hub, might get something workable out. Speed tests especially would be interesting.

nyef wrote:

Code: Select all

*    - Serial support on the Octane uses a very basic UART driver that drives
*      the 16550A chip on the IOC3 directly.  It does not use interrupts,
*      only a polling routine on a timer, which makes it slow and CPU-
*      intensive.  The baud rate is limited to no more than 38.4kbps on
*      this driver.  Patches for getting the Altix IOC3 serial driver to
*      work (which uses DMA and supports faster baud rates) are welcome.


Working on IP35, using the DMA-based driver. Took a bit to sort out endianness issues and DMA and whatnot, but was fairly straightforward overall.

Got a stand-alone patch for that? Fixes for that are probably distinct from the core IOC3 mess. Would be interesting to see if Octane's DMA situation is sane enough to run that. After I fix the "ttyIOCx" names back to a proper "ttySx" naming scheme...

nyef wrote:

Code: Select all

*    - UHCI Cards are known to have issues, but should still have some functionality.
*      This issue primarily manifests itself when using pl2303 USB->Serial adapters.


I have a few pl2303 adapters handy, not sure about the UHCI cards, though.

pl2303 converters are junk anyways. I've switched to using the XS880 from U.S. Converters, which is based off of an FTDI FT232RL chipset and ZyWyn ZT213LEEA serial driver. They're not cheap at about ~$44 a pop, but all of the problems I've had with serial consoles has practically vanished since picking several of these up. Have yet to test them in the Octane, though, but I assume any problems will be in the IP30 code and not tied to these devices or the Linux driver for them.

nyef wrote: Unfortunately, the IP35 code conflicts a bit with the IP30 code, so merging things is a bit tricky.

Yeah, we still gotta work on that :) Getting the IOC3 bits hammered out and upstreamed will simplify things a bit. I just got busy the last two months, and may do so again in the new year (but we'll see).

nyef wrote: I have bad news for you: If you check, you'll find that the FPU won't kick over to FR1 mode, which is required for N32 and N64. It's on my shortlist to try and fix, but my project bandwidth has shifted away from MIPS kernel hacking for the past while.

Is this affecting IP35-only? I haven't had much of an issue on IP30 running N32. IP27 had a minor buggeroo w/ FP support when Maciej added a patch that didn't account for IP27's setting FCSR to random values on a cold restart. That was quickly detected and fixed, though. That all said, I haven't tried running any programs that fully exploit N32 and FP yet, either.

nyef wrote: Interesting (probably bad) news: I have a short C test program that causes my O350 to reliably do something weird, and one of the failure modes is a bus error. And it runs perfectly well on my ERLite-3. I think it's a TLB thing, but haven't tracked it down beyond getting a test program, which I did hand off to Ralf so that there'd be more than one set of eyes on the problem. http://paste.lisp.org/display/160204 if you want to take a look.

Running this won't crash the kernel, will it? Don't want to interrupt the compile run on the uclibc stuff if it will...

nyef wrote: As part of http://git.linux-mips.org/cgit/nyef/linux-ip35/log/?h=v4.2-ioc-changes , there is commit http://git.linux-mips.org/cgit/nyef/linux-ip35/commit/?h=v4.2-ioc-changes&id=6142674bcb716f1702ec2e364887a4434f75720d , which is the IOC3 serial magic.

It looks like this is the most relevant bit:

I believe I have most of what is in your ioc3.h hunk in the base IOC3 patch. I'll try to apply this one change and see if IP30 comes up on the DMA driver.

nyef wrote: I've got a possible further angle so that we don't have to do this constant "blah, blah, and on SGI MIPS we also have to twiddle this bit in the DMA address" thing. And, now that I'm thinking about it, my patches may not work for you due to the differences between the DMA setup between the IP30 bridge driver and the IP35 bridge driver.

I got a feeling a lot of the [X]BRIDGE setup code between IP27, IP30, and IP35 can be unified a bit more over time. Make the mess a lot easier to read and follow. IP27's big issue is the resource allocation part. I ended up changing that to the XIO window bases, and it works for internal PCI stuff, but that system was not picking up on a USB2.0 card I installed via an XIO shoehorn. Ended up pulling that card before I thought to revert to the original code and test again.

nyef wrote: I'm wondering if it might not make sense for me to create an IP30 branch from my current IP35 tree and basically try to bring it up like a new port, cribbing liberally from your existing patch set.

That should work. I can cherry pick as needed until things are more unified. I track upstream a lot faster, using rolling new patches from my local git repo when a new kernel is released and Ralf pulls from upstream. 4.4 looks to still be a few weeks off, probably 2-3rd week of January, if I had to guess. I need to re-submit patches I had for 4.4 for 4.5 (or 4.6), as Ralf didn't get to them for the 4.4 merge window.

ivelegacy wrote:

Hopefully I'll be able to get you a working beta-netboot within the next 1-2 weeks for the Octane,

already done for 2.6.17, I can re-use the ramrootfs with kernel 4.* :D

You can, as I sometimes use that old ~2007 netboot for fixing things. But it is *severely* bitrotted. mdadm can't create RAID arrays at all, networking is a touch fickle, etc there's other issues that I can't even remember. I wouldn't trust the filesystem tools one bit, either, in that netboot.

ivelegacy wrote: p.s.
is there a Gigabit/sec PCI card that is known to work with XIO_PCI (ShoeHorn or ShoeBox) ?

Unknown. Just has to support 5V power, so look for PCI-X gigabit cards. Two I ran into earlier tonight are from Sonnet, which caters more to the Mac crowd (but their PCI boards are purple). They have a single-port gigabit card as well as a dual-port. I am told their products are not at all cheap, but are very well built. I have no idea if they'll work in an Octane or Origin/Onyx2:

Sonnet Presto™ Gigabit Pro PCI card:
http://www.sonnettech.com/product/prestogigpro.html

Sonnet Presto™ Gigabit Server:
http://www.sonnettech.com/product/prestogigserver.html

nyef wrote: All R1x000 CPUs. The FPU implementation/revision ID register is defined to have the top half wired to zero, but the kernel treats it as a bunch of flags for features present or not present (probably a mips32/mips64 thing, and since mips4 predates them we get bit).

Yeah, I've always noticed that the Kernel seems to read the FPU revision a bit oddly, always reporting it in "uname -a" as "0.0" (Gentoo's version of uname parses the Machine/CPU/FPU type out of /proc/cpuinfo). Sounds like a bug to report to the linux-mips ML; maybe get Ralf or Maciej's attention on it. That said, I haven't seen any ill effects running N32 on the Octane, so I must not have managed to trip it up just yet.

nyef wrote: I've not noticed it crash the kernel, but you may want to play it safe anyway. It also might only crash on the smaller page size.

Or the stars will become right again and dead Cthulhu will live once more.

nyef wrote: I have near certainty that they can be unified. The main differences are the IRQ mapping, and that 512-meg DMA thing on IP30. And since the DMA thing is for D32 DMA, which neither IP27 nor IP35 are using (and I'll argue that IP30 probably shouldn't use either)...

Agreed. I have a test branch in my local repo where I switched the bits over to do DMA64 and use large XIO windows. The machine actually booted and ran for a few minutes, before something in the SCSI subsystem locked it up. So it's definitely doable, but needs further work. Also, the other bits are to properly handle pure-XIO devices with Linux's DMA setup, because it blindly assumes anything doing DMA is a PCI device. That's likely the source of the Impact driver's ills.

ivelegacy wrote: gentoo-4.3.0.20151126: the first try … fails

Code: Select all

xtalk:0 xbow widget (rev 2.0) registered as a platform device.
xtalk:8 heart widget (rev F) registered as a platform device.
xtalk:10 bridge widget (rev D) registered as a platform device.
xtalk:11 bridge widget (rev D) registered as a platform device.
xtalk:15 bridge widget (rev D) registered as a platform device.



Running power-on diagnostics…

I am switching back to "ip30_defconfig-4.3.0", then I will try to add features and options

I said I stripped that defconfig down a fair bit. Can't rule out I removed something critical. I'll have to remember to do some test boots to work out a generic defconfig and add it to my patch set.

That said, at the above point you indicated, did it simply freeze up or auto-reboot itself?

ivelegacy wrote:

Code: Select all

>> bootp():
Setting $netaddr to 192.168.1.4 (from server )
Obtaining  from server
10547500+256516 entry: 0xa80000002049d240

*** PROM write error on cacheline 0x1fcc1100 at PC=0xa8000000205f8270 RA=0xa8000000205dc24c


the the second try fails funnier :lol:

This is one of those annoying errors that no one has ever figured out. Similar to why CONFIG_DEBUG_LOCK_ALLOC always triggers the "doesn't fit in a FreeMemory area." error on at least IP27 and IP30. I suspect both are probably related to alignment oddies in the final kernel image.

ivelegacy wrote:

Code: Select all

[5] mips64-unknown-linux-gnu-4.3.5
[6] mips64-unknown-linux-gnu-4.9.3 *


emerged & switched to sys-devel/kgcc64-v4.9.3!
(64bit kernel compiler)

Yeah, please use a more recent compiler than 4.3.x. That's over 5 years old.

You can also build a cross-compiler on a faster Intel box using Gentoo's crossdev tool (if you have Gentoo on another box). The kernel currently running on my Octane is built with gcc-5.3.0, although right now, you can't compile 5.3.0 on MIPS N32 itself, possibly due to PR66038. Might work on O32, as I can build gcc-5.3.0 in a uclibc chroot, but haven't tried on a glibc chroot yet.

You have dual R14K/600MHz in your Octane, right? What graphics card?

ivelegacy wrote: auto-reboot itself!

That would indeed be odd. Usually, the kernel would just lock up, not trigger the PROM reset vector or HEART's cold reset bit. Gonna have to write this one off to your compiler for now.

ivelegacy wrote: my IP30 is SMP2xR12K@400Mhz, my friend machine is 2XR14K@600Mhz
both machines do not have a GfX installed, mine has a MENET and ShoeHorn
his machine has a empty carrier (just the plastics without anything installed)

the above screenshot is from his machine, mine auto-reboot itself
so we get the same reaction from both of them

I'll upload a config in a bit that has SMP stuff, but lacks graphics entirely. If that fails, then I'll build a kernel for you to try.

ivelegacy wrote: my production kernel, 2.6.17-rc4-hack, gets compiled by kgcc-v4.3.5 and boots fine
I have switched to the last kgcc in the portage

gcc-5.3.0, as far as I see from the portage (last --sync, yesterday) it's currently ~mips
but I can force it, just give me the time, my Atheros9 takes 9 hours to compile gcc

Still need to get you off of 2.6.x entirely. I can only wonder about the security flaws that cumulatively exist in such an old release.

gcc-5.3.0 is ~mips, but as I mentioned previously, none of the 5.x series will compile under N32 (N64 is unknown). It might under O32, but I can only vouch for that on a Uclibc root, as my glibc-based o32 root got brain-damaged when I was trying to migrate to N32 a while back, and I just haven't set up another one yet. That said, I *think* 5.x compiles faster. In uclibc, I timed a full build at ~11 hours, while I know 4.9.x is closer to 13 hours. That was on a dual R14K/600MHz CPU, though. The 5.3 release notes suggest that this release sports faster code generation and link times, so that might explains the differences.

ivelegacy wrote:

Code: Select all

Instruction bus error, epc == 0000000000443b3c, ra == 0000000000444b88
/usr/bin/myNET-web-machine-info: line 51:   246 Bus error               myNET-networktraffic $netdev >>$page_name2


How old is your initramfs? The problems I ran into on the Octane were Data Bus Errors (DBE), not IBEs, and those were solved once I learned to use the correct handle_*_irq() function. I'm wondering if you've got that initramfs built using really old toolchains/kernel headers and it's just not playing nice.