netkas post on 64 bit SL kernel confusion...

Discussion in 'Mac Pro' started by DualShock, Aug 14, 2009.

  1. DualShock macrumors 6502

    Joined:
    Jun 29, 2008
    #1
    Hi,

    Don't know if anyone has noticed, but netkas has posted some info about the 64 bit snow leopard kernel here.

    It appears that everything except xserves boot the 32 bit kernel.

    He also says that a particular kernel can only load kexts with the same 'bitness', for lack of a better term.

    So what does this mean then for 2006/7 mac pro owners with EFI32? Also, will 2008/9 mac pro's only load the 32 bit kernel?

    And might this cause a driver nightmare for those who swap kernels as netkas describes in the posting?
     
  2. goMac macrumors 603

    Joined:
    Apr 15, 2004
    #2
    Unless you're running more than 4 gigs of kernel extensions, it means absolutely nothing.

    And yes, K64 needs new drivers.
     
  3. bozz2006 macrumors 68030

    bozz2006

    Joined:
    Aug 24, 2007
    Location:
    Minnesota
    #3
    read this, and this, and this, and this. Lots and lots of pages on the discussion. Nothing is conclusive because Snow Leopard isn't out yet. But yeah, if the 2006 mac pro is to run kernel 64, it will need new drivers. the million dollar question is whether Apple will write new drivers. Past behavior is the best indicator of future behavior, and Apple hardly ever releases new drivers, so I'm basically resigned to the fact that, yes, our 2006 mac pros are going to be stuck with kernel 32.
     
  4. goMac macrumors 603

    Joined:
    Apr 15, 2004
    #4
    The drivers are mostly there, it more seems to be an efi32 vs. efi64 thing for yet unknown reasons.

    But really, it doesn't matter anyway.
     
  5. bozz2006 macrumors 68030

    bozz2006

    Joined:
    Aug 24, 2007
    Location:
    Minnesota
    #5
    regardless of whether it's EFI or drivers (both), it's still only an artificial "problem". You don't *need* EFI 64 to boot kernel 64. Apple has disabled kernel 64 support for macs (see: 2006 mac pro) with EFI 32, and have done the same for certain EFI 64 macs (core 2 macbooks with intel graphics). They could remedy the *problem* by removing their artificially placed non-support and rewriting a few drivers. but will they? i don't think so...
    [​IMG]
     
  6. netkas macrumors 65816

    Joined:
    Oct 2, 2007
    #6
    ohai holy Apple, I was so sad when u told my iphone 2g physically cant support MMS, but with 3.1 firmware, I heard u gonna upgrade hardware of my iphone2g remotely, for mms support, thank you so much!
     
  7. goMac macrumors 603

    Joined:
    Apr 15, 2004
    #7
    You don't need to go through EFI to boot K64, so I'd instead put this into the "wait and see category". It could go either way.

    With regards to Apple gimping K64 on Rev A Mac Pros, there is no reason you need it anyway. Zip. Zilch. None. If you boot it, the only difference will be half your drivers won't load.

    The other issue is that 64 bit kernels should actually be using the 64 bit EFI functions. Windows doesn't use EFI, so I'm not sure what the situation is over there, but I'm pretty sure the BIOS boards have special extensions, much like 64 bit EFI, to do 64 bit kernel booting.
     
  8. netkas macrumors 65816

    Joined:
    Oct 2, 2007
    #8
    Nonsense, for example cham2/pcefi v10 boot chain: bootrom is 16-bit (bios)
    bootrom runs bootloader , which switches into 32-bit mode, and uses 16-bit mdoe to run bios functions (read disk and etc), and it still can run 64-bit kernel
     
  9. gugucom macrumors 68020

    gugucom

    Joined:
    May 21, 2009
    Location:
    Munich, Germany
    #9
    As Bozz has allready said the problem with the 32bit EFI is not the fact it is 32bit. The problem is Apple's lazyness in updating anything that is out of the sales office and handed to after sales.

    Because of this ****** attitude people have all kinds of problems with updating Mac Pros. EFI 32 doen't load Windows anytime upgrade DVDs because the old bootloader isn't reading multiple images correctly. More recent graphic cards do not work as they really could (ATI makes them work!), you can't use 45nm Xeons (X52xx and X54xx) in 2006 and 2007 machines where all Asus or Supermicro boards of the same chipset can easily. The list goes on and on. It is all ****** customer service.:mad:
     
  10. Tesselator macrumors 601

    Tesselator

    Joined:
    Jan 9, 2008
    Location:
    Japan
    #10
    If I had to guess the title by the cover and context it would be:

    "I Didn't Murder Mac
    ...But If I Had Here's How I Would Have Done It"

    :D
     
  11. goMac macrumors 603

    Joined:
    Apr 15, 2004
    #11
    To understand you need to know a bit about the differences between K32 and K64...

    In K32 the kernel maintains a small amount of memory for exchanging data with other processes and hardware. I'm not a kernel engineer, but it's like 500k or something maintained at the end of the kernels 4 gig block. It's not a large amount at all.

    In K64 this block is both expanded (for future performance reasons that are obvious) and moved to the end of the 64 bit addressable space. My guess is, that because this would put it out of the scope of EFI32's addressable memory space, that this would leave EFI32 unable to communicate properly with K64. This is completely a guess as to why EFI32 can't boot K64 (although the kernel internals are not a guess), but it would make sense.

    It's a good, and consistent, design decision, and again, K64 is really only something worth worrying about until many years from now. It was just added now as part of the Snow Leopard "prepare for the future" move. There is absolutely no reason you need to boot K64 now, and it will just be more trouble than it's worth.
     
  12. netkas macrumors 65816

    Joined:
    Oct 2, 2007
    #12
    that block is called commpage, your guess is very wrong, efi-runtime services still located in lower memory, kernel doesnt use static_p2v() function to convert address of runtime-services
     
  13. SnowLeopard2008 macrumors 604

    SnowLeopard2008

    Joined:
    Jul 4, 2008
    Location:
    Silicon Valley
    #13
    I think all this computer jargon is confusing the OP. Furthermore, unless you are running some serious applications that require tremendous amounts of system resources, it shouldn't much of a difference.
     
  14. hyram macrumors regular

    Joined:
    Jun 15, 2009
    #14
    I guess what frustrates me the most about all this is the planned obsolescence. PPC macs are already gone and it took a processor family change to do it. Next on the list are EFI32 machines and this is just the first phase. Can't wait to see what's next.

    On the bright side, there are thousands of us who will not go silently into that good night. :) I'm sure some (or several) creative soul(s) will spring forth with a solution that will stick it to apple and keep this vintage of macs working long after apple would like to see the last one buried in a landfill.

    I will give apple some props though... have you tried running Vista on a 4 year old computer??? At least apple supported PPC for as long as was practically possible.

    hyram
     
  15. goMac macrumors 603

    Joined:
    Apr 15, 2004
    #15
    Again, why? Can you give me one good reason why you'd need K64?

    It's only going to be useful many years from now. If you're still using the same Mac Pro 5 years from now... you're going to have bigger problems than K64.

    I'm not saying that the kernel would need to address memory within the EFI runtime services, I'm saying that EFI might need to give information to the kernel, such as the system bus speed or whatever at startup. This information would have to be loaded by EFI potentially into a space that EFI32 cannot address.

    Either way, we won't know for sure until the new XNU source is released, or possibly never if the key is in Apple's EFI64 source. Knowing people at Apple, they don't do things like this "just because", especially when it's on a feature that nobody will need, give a crap about, or even work correctly for the end user.
     
  16. MacVidCards Suspended

    Joined:
    Nov 17, 2008
    Location:
    Hollywood, CA
    #16
    Well, when I saw Mike @ XLR8 put Netkas on front page, I decided to try out Netkas' K64 trick

    I edited my boot.plist to read:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    <key>Kernel</key>
    <string>mach_kernel</string>
    <key>Kernel Flags</key>
    <string>arch=x86_64</string>
    </dict>
    </plist>


    then rebooted. The 1st Gen wasn't fooled.
     

    Attached Files:

  17. Tesselator macrumors 601

    Tesselator

    Joined:
    Jan 9, 2008
    Location:
    Japan
    #17
    How about just because he want's to? "Having a 64-bit kernel will [in the future as you say] enable Apple to move well beyond PAE to address very large amounts of installed RAM in Macs of the future as memory becomes more affordable. This is particularly useful for servers, but even consumer machines will someday need vast amounts of RAM.

    Additionally, the new 64-bit kernel will gain the advantages that 64-bit Mac OS X apps already have: the ability to set up an address space for itself greater than 32-bits (4GB), as well as the ability to access the full x64 register set of 64-bit CPUs. This wasn't as compelling of a need on the 64-bit PowerPC G5, but 64-bit Intel CPUs like the Core 2 Duo provide more general purpose registers that are conspicuously absent on 32-bit Intel CPUs, leading to a significant performance advantage when moving to 64-bit software.

    Along with these advantages comes the necessity of upgrading all of the kernel's drivers to 64-bit, including any provided by third parties. Again, that's because 64-bit programs can't load and run 32-bit plugins, and vice versa. That means Mac users will need to do the same driver upgrade that Windows Vista users did.

    Fortunately, Apple took steps to plan for the transition. By exposing 64-bit development tools and concepts years in advance, Mac programmers have had time to build a more mature understanding of how things work. If Apple had attempted to simply deliver a 100% 64-bit OS in one fell swoop, it may never have come together. Apple would have run into many of the same catch-22 problems that have held 64-bit Windows from gaining mass adoption.

    Additionally, Apple only needs to deliver a relatively small number of drivers: just those devices used in Macs supported by the Snow Leopard release. Since Apple designed and built all those machines, it won't have nearly as tough of a time as Microsoft had in prodding third parties to deliver good 64-bit versions of their drivers for all the hardware anyone has every put into any brand of PC sold within the last several years."
     
  18. Tesselator macrumors 601

    Tesselator

    Joined:
    Jan 9, 2008
    Location:
    Japan
    #18
    Also if I read this correctly ( http://www.appleinsider.com/article...ard_twice_the_ram_half_the_price_64_bits.html ) a 64 bit kernel is indeed actually important to improved performance.

    "Snow Leopard will deliver both a 64-bit kernel and a full set of 64-bit bundled apps, erasing the entire TLB flush issue because the new kernel won't have to share any address space, even when running 32-bit apps (below right). This will benefit all 64-bit Mac users with a Core 2 CPU or better, even those lacking a Santa Rosa platform-style chipset, as being able to run 64-bit code and virtual memory is not tied to the amount of addressable system RAM."
     
  19. goMac macrumors 603

    Joined:
    Apr 15, 2004
    #19
    Being in the know myself... K64 was not designed for speed. Anyone thinking that the purpose behind adding K64 is for speed improvements is going to be sorely disappointed.

    The primary purpose behind K64 is to increase the addressable space in the kernel. This becomes important when you start seeing graphics cards with 8 gigs of VRAM or whatever years down the road. Again, this is straight from the horses mouth. Apple is not intending the addition of K64 to be a speed/optimization thing.

    In addition, a lot of drivers are still missing in K64, so even if you did boot it, you likely would loose some of your hardware.

    Consumers should not be booting K64 right now, at all.

    ...except the hardware memory controller in a rev A Mac Pro will never accept more RAM than PAE can address.

    Except no one out there right now is using more than 4 gigs of memory in the kernel space. Yes, people are using more than 4 gigs of memory in the application space, but not the kernel, and that will hold true for years to come.

    The kernel being able to access the x64 registers is nice, yes, but generally there has been no significant performance advantage here. It can vary, but something like this is not going to really make Final Cut Pro render faster, or your games much faster. The kernel being able to access the extra x64 registers is going to have a limited impact.

    And again, missing drivers still make K64 a non starter.

    Which again, means that you probably should avoid K64...

    Hahaha... Being a Apple developer who is in on this sort of thing, the original author of this article needs a clue stick. Apple had supplied 64 bit application development tools for the last few years, yes, but that's entirely different than supplying the tools needed to port kernel extensions and drivers over, which they have not done.

    But yes, I was compiling my application code as 64 bit at WWDC years ago. That's an entirely different bag of chips.

    That's actually a large amount of drivers. In my day job I work with software that is very dependent on just the GPU drivers, and NVidia can't even get things working properly under 32 bit OS X. I don't expect their 64 bit OS X drivers will be very dependable. (NVidia actually pushes our software on their pro customers and they still can't get things right.)

    And that's just the NVidia drivers. Every other drivers that makes it into K64 (which still isn't everything) is going to have an entirely new set of bugs.

    Why anyone would want to run K64 in a production environment is beyond me. It's pretty much the new QuartzGL/Quartz 2D Extreme...
     
  20. netkas macrumors 65816

    Joined:
    Oct 2, 2007
    #20
    :D

    such information passed to kernel via flatten device-tree, which created by bootloader(boot.efi e.g.), once this information parsed by kernel, it not used anymore.
    it cant be a problem for efi32 running efi64 kernel.


    btw, anyone know what ethernet/wifi devices macpro1,1 has ?
     
  21. MacVidCards Suspended

    Joined:
    Nov 17, 2008
    Location:
    Hollywood, CA
  22. netkas macrumors 65816

    Joined:
    Oct 2, 2007
    #22
    i mean, is it atheros or broadcom for wifi? atheros is i386 only in sl, broadcom is 32/64
     
  23. LcTrKiD macrumors newbie

    Joined:
    Jul 23, 2009
    #23
    Mac Pro Rev. A is Broadcom BCM43xx 1.0 (5.10.91.19)
     
  24. hyram macrumors regular

    Joined:
    Jun 15, 2009
    #24
    Do I sense a netkas package of 64 bit drivers for the 1,1 crowd??? ;)
     
  25. Tesselator macrumors 601

    Tesselator

    Joined:
    Jan 9, 2008
    Location:
    Japan
    #25
    Some nice info there, Thanks goMac.


    I don't have the bluetooth or any of the airport stuff installed on my machine but here's the rest of it:


    You might need to rename it to ___.rtf
    the system here needed a ____.txt for attaching.
     

    Attached Files:

Share This Page