Jump to content

mercurysquad2

Members
  • Content count

    20
  • Joined

  • Last visited

About mercurysquad2

  • Rank
    InsanelyMac Protégé
  1. mercurysquad Voodoo3945 dependency problem

    The kext is for 10.6.3 To use it on 10.6.2 you have to manually open the kexts (all 3) Info.plist and change the bundle version to match the versions you have (use kextstat).
  2. Mercurysquad Voodoo3945 Troubleshoot

    No, I will find and fix it over the weekend or on Monday.
  3. Mercurysquad Voodoo3945 Troubleshoot

    Yes it's a bug in the kext during scanning.
  4. Mercurysquad Voodoo3945 Troubleshoot

    Link to latest IO80211Family.kext - http://www.mediafire.com/?9widdksfewe Thanks to Chris M
  5. Mercurysquad Voodoo3945 Troubleshoot

    Can you please post the contents of /System/Library/Extensions/IO80211Family.kext/Contents/Info.plist ? You have an old version of this kext, and the 3945 driver depends on the newest version. It might be possible to make it work by changing the dependency version in 3945 driver once we know which version you have.
  6. Intel Wireless 2100, 2200bg, 2915bg, 3945abg, 4965agn

    No need to apologize, maybe I should. My post was not directed at you personally, but more at the general ambience on the forums here...
  7. Help with IOMemoryMap

    There are some things with which you have to be very careful when you are doing I/O using structures. For example, in your ioRead, you call ioRead8 to read only one byte, but your struct has Reg1 mapped to a uint32 = 4 bytes. Secondly, make sure you add __attribute__((__packed__)); at the end of your struct so that the individual fields do not get padded or aligned. In general you must now make sure your register struct layout is exactly the same as the underlying hardware. Just play around with that and after a while it will begin to give expected results. (calculating the struct's field layout based on register addresses is kinda tricky!)
  8. Help with IOMemoryMap

    Check the return type of ->getVirtualAddress(). It doesn't return a pointer, it returns the address as a value. You have to force-cast it as a pointer. Try replacing that line with this: PCIRegisters = reinterpret_cast<PCIRegisterType*> (PCIMemoryMap->getVirtualAddress()); And it should work then.
  9. Intel Wireless 2100, 2200bg, 2915bg, 3945abg, 4965agn

    ffs, stop imagining things up! There is no conflict, any apparent 'pissing contest' is the invention of the community here. Jalavoui is not only well aware of project:camphor, he has in fact offered me many tips to help. Note the link to project:camphor on the first post of this thread. The only reason mods are deleting posts related to project:camphor is because it leads to more confusion when 2 projects are being discussed in the same thread. Simple fact is that jalavoui has the skills but doesn't have the time. Can we at least appreciate what he has already done? I didn't have the skills when I started, but made up for it by spending a lot of time on the project. And that is the reason money is involved. I am tired of explaining this over and over, but let me put it down AGAIN: 1. The amount of time needed was very large. No other developer has been able to spend that much time "as a hobby" and we'd never get the drivers if everyone relied on this happening. 2. The number of people who want the driver is so large that no one has to spend any significant amount (or any amount at all since it will be freely available). There is no buying/selling business here. Just mutual benefit to both parties. If you think this is bull, by all means go write your own driver. I am seriously getting pissed off now.
  10. Where to get the kext

    The kext loading too early is intentional, but I have added a waitForService(resourceMatching(IOCPU)) so that the auto-throttler and PState creation will wait up to 1 minute for the CPU service to be initialized. That's why the kext still works well. Though on my machine I don't get that message about not finding the CPU, so you should verify using sysctl that the freqs and voltages are appropriate for your CPU. It is entirely possible that the kext really can't find your CPU and is thus auto-creating the PState list. As for C-states, yes maybe in the future I want to add that support. It's not immediately on the list, but it's definitely a "want-to-have". The targetload was increased to 40 because I felt 30 was too low, and the CPU was switching up to higher freqs even on small load bursts of 40-50%. On my FreeBSD system, my CPU can throttle all the way down to 100 MHz and stays at 40-60% cpu usage, only throttling to higher freqs then usage goes above around 65-70%! I think I might change default target load to even higher, around 60% because going by the stats that v1.5.0 collects : kern.cputhrottle_freqs: 800 1067 1333 1733 kern.cputhrottle_usage: 82.0% 2.0% 2.0% 12.0% You see that most of the time the CPU is either in the lowest or highest P-state, and this is most likely because once the cpu load in 800 mhz goes to 80%, which is 2x the target load, the throttler wants to make the frequency 2 times too, getting 1600 mhz as the optimal frequency, and thus choosing 1733 which is the closest one supported by the CPU. In other words, the kext tries to maintain 40% usage and in doing so, skips most of the intermediate pstates. I might tune the algorithm based on stats I receive from other users once 1.5.0 goes online. Yes there is hysteresis built into the throttler too, since the very beginning, and I'm actually quite happy with the algorithm. In short, the kext chooses the most appropriate frequency and switches directly to it instead of switching in steps. After this, the throttler will stay on this frequency for a time period which is proportional to the chosen P-state (ie, it won't stay long on a high frequency but won't switch down too early either). But this initial 'sustain' period happens only just after switching. If the optimal P-state is found to be the same on the next check, throttler checks the load more often so it can switch back to a more appropriate p-state as soon as there is no need to operate at high frequency. Actually it's tough to explain in words, just check the code here : http://opensource.mercurysquad.com/xnu-spe...edSpeedStep.cpp Line 828 and later (scroll the the very bottom).
  11. ›› Voodoo XNU Kernel is now Released

    Actually this cache thing confuses me a hell lot too. The kernel reports cache size as "cache size" (ie. for each level all the way up to RAM) and "cacheconfig" (ie. how each cache is shared). So for L2 it reports 2MB with sharing 2 (ie. 2x2). System profiler is the only source I have used to check this info is being reported correctly. SO IF any other programs, instead of multiplying by 'sharing' and getting 2x2=4MB, are dividing 2/2 and getting 1MB, it's the program's fault. In any case, as BladeRunner will tell you, I will not fix any more cache issues It's purely cosmetic.
  12. ›› Voodoo XNU Kernel is now Released

    Well there are many ways to get information about the processor. The only realiable way is to execute CPUID instruction and then read the returned values. But some programs use CPUID, some use sysctl, some even use system profiler.. they all get the CPU type from different places, and the "hw.cpufamily" sysctl is just one source. Within sysctl keys itself there are like 3-4 keys which give the cpu type info in slightly different ways. "Hyperspaces" probably uses the hw.cpufamily sysctl key and thus gets Intel Core 2. Reggie/Processor control panel probably query some other place and get actual CPU info, see that it's a non-apple cpu and report it as Unknown. Whatever. The point is that for the sysctl hw.cpufamily key, we can only report one of the defined values, so I chose Intel Core or Core 2 which seems to fix many problems. For this particular key, there is no way to report any CPU type other than the values defined in the Apple source code.
  13. ›› Voodoo XNU Kernel is now Released

    Cool. The next step is going over all the source code changes compared to stock Apple sources. For example, you can clone another copy, update to "rev 0" which is stock Apple source, and then compare the two using FileMerge: cd xnu-1228.12.14 hg update -C tip cd .. hg clone xnu-1228.12.14 stockxnu cd stockxnu hg update -C 0 cd .. opendiff xnu-1228.12.14 stockxnu Cheers.
  14. ›› Voodoo XNU Kernel is now Released

    That's weird, I just checked http://opensource.mercurysquad.com/voodoo-...k/i386/commpage and the files are there. After hg clone, you also have to do hg update -C voodoo-merge-intel or hg update -C alpha3 for example, to update the working directory to a particular branch, tag or revision. Try that and see if it works.. EDIT: OK I figured out why the tip doesn't build -- I forgot to include the bcopy_sse3_64.s file (unrelated to sse3 emulator) after fixing the pentium D commpage bug. It's now included and the "alpha3" tag has been reset. It should build now if you hg update -C tip, or hg update -C alpha3, before building.
  15. ›› Voodoo XNU Kernel is now Released

    Since this issue keeps coming up again and again, let me try to paste the Apple source code and my own source code snippet (includes comments) -- /* * CPU families (sysctl hw.cpufamily) * * These are meant to identify the CPU's marketing name - an * application can map these to (possibly) localized strings. * NB: the encodings of the CPU families are intentionally arbitrary. * There is no ordering, and you should never try to deduce whether * or not some feature is available based on the family. * Use feature flags (eg, hw.optional.altivec) to test for optional * functionality. */ #define CPUFAMILY_UNKNOWN 0 #define CPUFAMILY_POWERPC_G3 0xcee41549 #define CPUFAMILY_POWERPC_G4 0x77c184ae #define CPUFAMILY_POWERPC_G5 0xed76d8aa #define CPUFAMILY_INTEL_6_13 0xaa33392b #define CPUFAMILY_INTEL_6_14 0x73d67300 /* "Intel Core Solo" and "Intel Core Duo" (32-bit Pentium-M with SSE3) */ #define CPUFAMILY_INTEL_6_15 0x426f69ef /* "Intel Core 2 Duo" */ #define CPUFAMILY_INTEL_6_23 0x78ea4fbc /* Penryn */ #define CPUFAMILY_INTEL_6_26 0x6b5a4cd2 /* Nehalem */ #define CPUFAMILY_ARM_9 0xe73283ae #define CPUFAMILY_ARM_11 0x8ff620d8 #define CPUFAMILY_ARM_XSCALE 0x53b005f5 #define CPUFAMILY_ARM_13 0x0cc90e64 #define CPUFAMILY_INTEL_YONAH CPUFAMILY_INTEL_6_14 #define CPUFAMILY_INTEL_MEROM CPUFAMILY_INTEL_6_15 #define CPUFAMILY_INTEL_PENRYN CPUFAMILY_INTEL_6_23 #define CPUFAMILY_INTEL_NEHALEM CPUFAMILY_INTEL_6_26 #define CPUFAMILY_INTEL_CORE CPUFAMILY_INTEL_6_14 #define CPUFAMILY_INTEL_CORE2 CPUFAMILY_INTEL_6_15 As you can see above, the CPU type to report (via sysctl key hw.cpufamily) here must be from among the arbitrarily defined values. Badly written programs (like Microsoft Silverlight) use these values to identify the CPU's "Marketing Name." They usually have a list of these values that they support and fail on anything else. So we MUST supply a value which is from this list, and we can't invent our own values for other CPUs like Pentium D. Here is the snippet of code where I've made changes to report an alternate CPU: /* mercurysquad: Report cpu family as one of the Apple-recognized * CPUs, for CPU families other than 6. This entire system is very * myopic, where the kernel explicitly encourages checking for a handful * of families with arbitrary signatures. We cannot define our own * signatures here as we never know when an installer or other app * might check among only the ones stock kernel supports.*/ case 15: /* This applies to Pentium 4/D and AMD Phenom. In the future * we might want to choose a more specific cpufamily based on the * number of cores etc., but for now it's just not worth it IMO */ switch (cpuid_info()->cpuid_model) { case 0: case 1: case 2: /* Report Core Solo/Duo for these models */ cpufamily = CPUFAMILY_INTEL_6_14; default: /* For higher models, report Core 2 Duo */ cpufamily = CPUFAMILY_INTEL_6_15; } default: /* For unknown CPU families, just report Intel Core */ cpufamily = CPUFAMILY_INTEL_6_14; } Hope it's clear now.
×