Not yet
This is a nut we’re still trying to crack.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
This is a nut we’re still trying to crack.I just wondered whether they might be functional under Intel 10A96 or 10A190 and not ppc if this seems to be the issue here (which I finally understood to be the stakes here)
If it's down to kernel level then swapping kexts also should not work on the Mac Pro I guess
FWIW they don’t work on 10.5.0 through 10.5.5 on Intel either.
Is this something you verified through applied trial and error? Although I’ve no doubt you’re correct, I’m unable to find any documentation about changes to AHCI support with the 10.5.6 Update documentation.
I went through every version from 10.5.0 to 10.5.7 and hooked up the blade via ExpressCard. 10.5.0 through 10.5.5 panicked, mentioning the AHCI kexts. 10.5.6 and 10.5.7 did not, although they didn’t see the blade (neither did 10.6.8 on the 2007 MBP).
Would make sense as 10.5.8 was released days before SL, and it's unlikely that Apple patched both the 10.5.8 and 10A432 kernels just to add in AHCI support. Let's also remember that 10.5.8 can function with the 10.5.5 kernel without any trouble (unsupported Leopard installations, I have one such myself on a G4-upgraded B&W)
P. S. As a quick and silly fix on 10A190, do this:
sudo port patch R-app (this will download, extract and patch sources)
Navigate to /opt/local/var/macports/build, find the folder, inside find Mac-GUI-1.72, inside it there is R.xcodeproj, right-click, Show package contents, open project.pbxproj in BBEdit, delete all lines with Vignettes.xib, save, install the port:
sudo port install R-app.
I think that I asked earlier but I do not recall getting an answer: has anyone tried using a newer kernel with 10A190? 10A222 is likely compatible, they share some dylibs and PPC support is largely present in the OS.
I will need to go digging, both into this long thread and also into my own test results, but as memory serves, an attempt to move the 10A222 kernel into either 10A190 or 10A96 produced, in verbose boot, an immediate kernel panic.
Given my inconclusive results, would either of you be willing to test if 10.5.6 recognises external AHCI controllers? Booting from a 10.5.6 install DVD and firing up Disk Utility would be enough.
Testing SL on the G5 a bit more tonight, trying to see if it is stable enough to act as a local server while also seeing if it does better than 10.5. Have a couple of questions (if those on here know).
1. My install keeps attempting to check the Superdrive (CD/DVD) every 30 seconds or so. Why is this, and is there a way to disable that? The only way I can stop it from doing that is by keeping a CD/DVD in the drive.
2. Still wanting to know if anyone has had luck installing a PCI video card in an early G5, to get back some graphics performance that AGP is lacking.
1. My install keeps attempting to check the Superdrive (CD/DVD) every 30 seconds or so. Why is this, and is there a way to disable that? The only way I can stop it from doing that is by keeping a CD/DVD in the drive.
2. Still wanting to know if anyone has had luck installing a PCI video card in an early G5, to get back some graphics performance that AGP is lacking.
Can’t recall which build you’re testing. This is not something I’ve experienced on the A1138 PowerBook running Build 10A96. Is the Console system.log showing an action being called roughly every half-minute, corresponding with the auto-eject action?
Aside from @666sheep managing to run a GeForce 6200 PCI card in (I think) a G4 and another person (unknown) who ran a GeForce FX5200 PCI, I don’t know anyone else who’s tried PCI video support for either of Build 10A96 or Build 10A190.
What about PCIe cards over a PCIe to PCI-X bridge for the PCI-X G5s? Should reach 4x PCIe speed (PCI-X: 64-bit 133 MHz = 1067 MB/s, and PCIe 2.5 GT/s x4 = 1000 MB/s), which, while half of AGP 8x speed, is still massively better than the 0.5x or 1x offered by 32-bit PCI graphics cards (depending on whether they will run at 33 or 66 MHz)?
Great idea on watching Console, I was simply monitoring activity monitor to see what process was being called live. The drive doesn't eject, it simply attempts to spin up when a disk isn't in the drive. If I leave a CD / DVD in and mounted, the behavior is not present.
I will research the PCI video card suggestion.
Thanks!
Looks like those did once exist, and cost about $150 or so. Interesting idea but would add some complexity in finding a low profile / compatible GPU, it may also add in a layer of complexity the already limited (10.6) kernel can cope with.
I will keep my eyes open for these, but I am more inclined to deal with the slower GPU performance as I don't intend to do many (if any) GPU intense tasks in SL, I can (hopefully) still boot into 10.5 and use my AGP card for those projects.
Could also be PCIe to 32-bit PCI (those go for $20 a pop) in which case it would be 2X speed (assuming that they will run at 32-bit 133 MHz = 533 MB/s), still better than 0.5/1X
32-bit PCI tops out at 66 MHz AFAIK, and most, if not all, PCI-to-PCIe bridges top out at 33 MHz. So 133 MB/s max.
You were spot on on that oneYou need at least a pachedmach_kernelto prevent panicking due to the Haswell CPU.
I'm 99.999999% sure it will panic on theMacPro5,1due to the CPU(s) being way too new — and due to the AHCI blade, if you have one.
, 10A190 halts just past kextload on the 5,1, very likely needs a kernel patch to support Gulftown and Westmere (but potentially not Bloomfield and Gainsetown since they are both supported under 10.5.6 with the MP 4,1)Attachments
Yes I wondered about that too, but not by much, 10A190 12/11/08, 10.5.6 15/12/08, so it might have it in as they were likely developed in parallel, but possibly independently, in which case 10A190 might not have Bloomfield/Gainestown support
Thanks a lot for that; R GUI 1.72 seems to work, I did get 1.73 to compile and work on El Cap however indeed with minor bugs too (notably exiting with status 0 when either having a typo in the package name with library() or trying a missing one).
Most things seem to work but with R 4.X under old versions of Darwin such as under SL (and El Cap too) all calls to CLOCK_MONOTONIC will fail as this is unsupported <10.12. I had tried setting -D_POSIX_C_SOURCE=199309L as compile flags (also in .R/Makevars) but to no avail. However a workaround in the source of the R packages (and other sources that use it obviously) is as follows:
Code:#ifdef __APPLE__ #include <sys/types.h> #include <sys/_types/_timespec.h> #include <mach/mach.h> #include <mach/clock.h> #include <mach/mach_time.h> #ifndef mach_time_h #define mach_time_h #ifndef CLOCK_MONOTONIC #define CLOCK_MONOTONIC SYSTEM_CLOCK #endif // CLOCK_MONOTONIC static void clock_gettime(int clk_id, struct timespec *tp) { clock_serv_t cclock; mach_timespec_t mts; host_get_clock_service(mach_host_self(), SYSTEM_CLOCK, &cclock); //retval = clock_get_time(cclock, &mts); mach_port_deallocate(mach_task_self(), cclock); tp->tv_sec = mts.tv_sec; tp->tv_nsec = mts.tv_nsec; } #endif /* mach_time_t */ #endif /* __APPLE__ */
from
proxysql/include/gen_utils.h at v1.4.10 · sysown/proxysql
High-performance MySQL proxy with a GPL license. Contribute to sysown/proxysql development by creating an account on GitHub.github.com
There might be a way to patch <sys/time.h> directly to avoid to have to patch the source codes of the various packages involved, but this approach a la Mac Gyver seems to work; I was able to build later_1.30 which required it for example (and then ultimately Seurat 4.0)
Regarding the status 0 exit on wrong lib name, did you get this too, and if so did you manage to fix it?
Cheers,
Still interested in R?
I have written an implementation to install R packages via Macports – and while it is not as easy as adding a PG line, once I figured out how to deal with typical errors in a alien R way, things get fixed.
You will likely get malloc errors on PPC, if you install packages directly. I suspect it is because some packages link to libgcc_s.1 in /usr/lib and not a native dylib of the compiler (since C++11 is needed, gcc-4.2 cannot be used).
otool -L shows libraries being linked.
So anyway, normally these are quite easy to fix in Macports with legacysupport.redirect_bins, but it does not work with R packages (or my implementation of install system); however, I found a manual way to achieve the same result.
Long story short, in about a day I wrote PG, about 120 ports, and finally have RStan built and provisionally working:
You can’t drag and drop kernels from one build to another unfortunately - they need to be built against the system components. I’m sorry I can’t offer more assistance at the moment, but I haven’t lost interest in this and will jump back in as soon as i’m able. Great to see new interest in the project. For those just joining, please read the wiki and at least as much of the thread as you can to avoid retreading covered ground.
So in other words we need to compile the 10A222 kernel on 10A190? Shame that it's one of those instances where replacing the kernel from an older version works, e.g. 10.5.8 with the 10.5.5 kernel...
In theory, along with any other required dependencies that changed between 10A190 and 10A222. There’s no list that i’m aware of so you’d need to compare each version from each build. If you could setup gdb to step through the boot process on 10A222 it would be useful (2nd machine required).
With regard to systems (intel) supported, there is a list of supported models in the seed notes shared previously for the builds and you can’t just rely on release year vs build date for compatibility. I did manage to get 10A190 up and running on an unsupported MacBook but had to copy over some hardware specific kexts from retail SL.
Kexts can override the kernel, as they are kernel extensions and designed to do this, so there is wriggle room for some of the suggestions for expanding functionality i’ve read above potentially.
The 10A190 kernel and base system is pretty stable as is to be honest, and i’m unsure that a switch to the 10A222 kernel, if possible, would benefit the end user necessarily without the updated front end components making calls to any changes in the updated kernel.
Plenty of room testing and experimentation should anyone wish to try any of this.