Jump to content

Gorgonops

Moderators
  • Content count

    4537
  • Joined

  • Last visited

2 Followers

About Gorgonops

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

835 profile views
  1. ... replying to myself one more time, there's an interesting comment in the Peripheral Interrupt Controller code: #ifdef CONFIG_PPC_PMAC32_PSURGE /* IPI's are a hack on the powersurge -- Cort */ if (smp_processor_id() != 0) { return psurge_secondary_virq; } IPIs are "Inter-Processor Interrupts", and the platform support code also alludes to them being "not exactly straightforward to handle" on the PowerSurge architecture. If this was the root cause of the instability that was noted in those old mailing list posts about running Linux on these boxes that could well be why no out-of-the-box kernel today has SMP on this hardware enabled. I can only imagine the post-2.6 scheduler would exacerbate this problem... but, of course, I don't know anywhere enough about the situation to really say.
  2. ... actually, it looks like the same code is at least still present in the source tree as of the latest stable, 4.18.16. At some point between that version of 2.4 and now added the following comment to the header, which is now in arch/powerpc/platforms/powermac/smp.c: * Note that we don't support the very first rev. of * Apple/DayStar 2 CPUs board, the one with the funky * watchdog. Hopefully, none of these should be there except * maybe internally to Apple. I should probably still add some * code to detect this card though and disable SMP. --BenH. Whether it's still actually possible to enable this code as a configuration option or if the resulting kernel will just crash incessantly because there will be something else wrong above the platform driver level is of course utterly unknowable to me. If someone has one of these machines and a lot of time on their hands it might be an... interesting, experiment, to try to get a modern Linux distribution working on it.
  3. Doh, I forgot about that. My faulty memory filled in that it had the same framebuffer as the 7/8xx's stashed on the board, but thinking about it at all I know that's wrong. Just as an aside, the Developer Note that covers the 9600/200MP has this to say about it: Unfortunately there's no documentation, not even a block diagram, in that document that hints at how they actually hang the multiple CPUs off the bus. Granted that's not the sort of information Apple used to give out about their machines, since they never intended for anyone to run alternate OSes on them. Therefore it's difficult to take much away from this statement, since the "Asymmetric" part may strictly refer to their particular software implementation rather than a limitation of the hardware. Also, for shiznet and giggles I downloaded a random version of the Linux 2.4 kernel source. Here's what I found in arch/ppc/kernel/pmac_smp.c: /* * SMP support for power macintosh. * * We support both the old "powersurge" SMP architecture * and the current Core99 (G4 PowerMac) machines. * * Support Macintosh G4 SMP by Troy Benjegerdes (hozer@drgw.net) * and Ben Herrenschmidt <benh@kernel.crashing.org>. * * Support for DayStar quad CPU cards * Copyright (C) XLR8, Inc. 1994-2000 * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. */ The comments in that file are interesting reading. Among other things it seems to say that the CPUs in those machines are not mapped to Open Firmware device tree entries, you have to use some not-totally-reliable probing of registers in the Hammerhead memory controller to try to determine if they're present and what exact flavor of "PowerSurge" you're dealing with. The init code for the "Core99" machines is far cleaner with a lot less "cross your fingers and pray you got it right" moments. Given that I can see why they ditched the PowerSurge code in Linux, and it also probably explains why OS X has *no idea* about those extra CPUs either. (OS X is *very* Open Firmware-centric.)
  4. Where there dual-CPU ANSes? I honestly can't remember. I'm googling it and it looks like no? In any case, almost all the chipset hardware in an ANS matches that of a Power Macintosh 9500. The two major differences are the ANS has a modified memory controller to support parity memory, and it uses a Cirrus Logic VGA chip instead of the standard Apple framebuffer ASIC. (I'm guessing the latter was to leverage an existing driver in AIX, some low-end CHIRP RS/6000 hardware used the same.) It's mostly a ROM block (and the weird video) that prevents MacOS from running on them.
  5. The crucial difference when comparing Apple's MP machines and the BeBox is the 603 is fundamentally lacking support at the CPU hardware level to enable the cache coherency you need to enable true SMP. The BeBox gets around this by playing some really ugly games with software and its performance goes completely in the toilet if you ever try to switch a thread between the two cores. Nonetheless it did at one point work on at least an experimental level; I've already posted one reference, here's another. I imagine they pulled support for those machines from later kernels because of some combination of them being "idiosyncratic" in terms of implementation compared to later machines (Linux is known to have trouble with pre-Pentium Pro SMP machines even though technically 486 and Pentium MP boards exist that comply with the Intel MP standard as documented) and the fact that there simply aren't enough of them in circulation to make the effort worthwhile. In particular I'm betting that it turned out to be really difficult to implement the new scheduler that came with the 2.6 kernel release on those old machines, assuming Apple didn't support I/O routing like Intel does with their APIC/MP hardware. (IE, the Beige hardware might be easy enough to make work with a "Big Lock" sort of SMP but is harder to make play nice with more sophisticated algorithms.)
  6. There are old Linux mailing list postings that seem to indicate that SMP worked on those machines in some capacity, although I get the impression that it was never actually stable. Trying to get it to run today would likely be a really frustrating exercise in code archeology. Didn't BEOS support SMP on multi-processor Macs?
  7. So, the date in that article is 2007, not 1997, and what they're talking about is allowing non-Intel devices to reside in the Pentium 4/Core CPU socket. (IE, remember the aforementioned licensing of the patent-encumbered Pentium 4 bus? Intel granted some licenses to make Pentium 4 *chipsets*, but prior to this deal they'd never granted anyone a license to make a "CPU" that fit it. That's why some also-ran companies like VIA were continuing to make CPUs that fit the Pentium 3 socket for long after it wasn't really viable anymore.) That article is frankly pretty terrible. That criticism applies generally to it but that paragraph in particular makes no sense without putting it into the context of Intel's Pentium 4 bus licensing scheme.
  8. To put it another way, the LC "030" bus sort of became the low-end Mac equivalent of the function 16-bit ISA served on PCs well into the early 2000s. Generally speaking there's nothing terribly wrong with hanging a device off a slow bus as long as the bandwidth requirements of that device don't exceed the capacity of said bus. Generally speaking the real reason the 52/62/53/63xx sucked so badly is the original 603 had a smaller split cache (8k each instructions/data vs. 32k unified) than the 601 and the version of the 68k emulation software built into their ROMs didn't work anywhere near as well with it. Considering almost the entirety of the OS ran under emulation in System 7 that was a big problem. This is why those machines show significant improvement when running under OS 8 and later. (A lot more of the OS becomes native.)
  9. Uhm, do you have a citation as to what you're referencing here? I don't think Intel demanded that third-parties pay licensing fees to develop bus chipsets until the Pentium 4. (They slapped a lot of patents on the P4's quad-pumped bus architecture.) That was well *after* 1997.
  10. Gorgonops

    Couldn't help myself...

    I was briefly interested in nForce but Nvidia's lousy attitude towards open source killed that notion pretty quick. Both have improved measurably since but at the time Nvidia and Broadcom were pretty high on my hit list.
  11. Gorgonops

    How to make disks for a IIGS?

    Yes. As olePigeon noted it's possible someone changed the internal mechanism and labeled it appropriately. Inside those drives is a normal MacII-era mechanism cabled to an adapter board that provides the daisy chain function, a SuperDrive cables right up.
  12. Gorgonops

    Couldn't help myself...

    My T-Bird had the KT133A that supported the 266mhz bus. I guess to be fair to Via at the time that chipset was decent enough, it mostly got a black eye because the infamous Soundblaster Live! PCI bus issues affected it badly. (It didn't happen to me but some people suffered hard drive corruption.) I probably would have splurged on getting a DDR board and RAM if I'd bought everything separately but the CPU was a Fry's promo bundle that effectively made the motherboard cost about $20. Maybe SiS made some quality products, but in the early 'aughts they'd built themselves a reputation selling their chipset products to the worst most corner-cutting OEMs. I didn't know anyone that would even give their "high end" offerings a second look after experiencing something like that terrible Compaq.
  13. Gorgonops

    Couldn't help myself...

    There were both 100mhz and 133mhz FSB "T-birds". (The 133mhz variant is sometimes called the "Athlon C".) Originally the only major difference between Thunderbird and "Palomino", IE, Athlon XP, is the latter incorporated SSE instructions (the Athlon C is the last AMD CPU to only have 3Dnow!) and consumes slightly less power. (Thus allowing them to ultimately goose it up to 1700+ mhz.) It's also when AMD went to their Mickey Mouse "PR" rating, which always was something of a turn-off and maybe contributes to my lower level of respect for it. And while there *were* good chipsets for the XP there were also a lot of really bad ones, like the depressingly common SiS products with the horrendous built-in video. My wife had a Compaq equipped with that when we started dating and, yeah, while maybe the CPU was okay the machine it was built into was *trash*. I upgraded (side-graded?) it with a Radeon 7500 I had lying around after seeing how badly it chugged and stuttered and that helped... some.
  14. Gorgonops

    Couldn't help myself...

    In the real world I never noticed much difference between Athlon Thunderbird boxes with DDR vs. SDR. Maybe it was a side effect of the kind of lousy chipsets all too many Athlons were cursed with at the time (looking straight at you, VIA) or maybe in the real world the theoretical increase in memory bandwidth just didn't translate to much of a gain. (IE, there weren't that many things that were memory-bandwidth constrained.) I still have fond memories of my 1.33ghz Thunderbird. (It was a 1.33ghz instead of the 1.4ghz because, as was typical at the time, buying one speed grade under the fastest saved you a *ton* of money.) In sheer FPU grunt it stayed competitive with Pentium 4's for a good three or four years after I bought it, and it was *crazy fast* compared to the PIIIs that were its major competition when I bought it. I never quite felt the same love for the Athlon XP; I didn't bother upgrading when it was new because the T-Bird was fast enough, and when I encountered them my impression of them suffered because a lot of them ended up in really cheap, lousy machines. (Compaqs, eMachines, etc.) By that point I'd pretty much drifted into the Evil Empire's camp not because I cared for the P4 (I didn't), but because Intel won me over with the relative quality/reliability of their later motherboard chipsets. (The 865 is about when they started getting it right.)
  15. Gorgonops

    Couldn't help myself...

    Those ServerWorks boards really would be sort of wasted on gaming, especially a dual-CPU one. (Given that most games chronologically suitable for them don't benefit from multiple CPUs, and I don't even know if those boards had drivers for the non-NT variants of Windows.) The motherboard I ended up with I got in 2003 or so, when a dual Tualatin box was actually still potentially a viable solution for a "workstation" (IE, dual 512k cache PIIIs could still give even the fastest single P4s a solid run for their money), but the lack of AGP meant I'd have had to spend money for a really capable lots-of-VRAM video card instead of using a readily available AGP hand-me-down, and while the SCSI RAID controller was cool I *didn't* have SCSI drives to go with it. (And at the time the price differential between the two was massive; I don't remember precisely but I think it was on the order of 250GB PATA hard drives costing well under the price of a 73GB SCSI.) The price-benefit ratio just didn't add up to being worth my time.
×