wasureppoi Posted November 23, 2013 Share Posted November 23, 2013 Whilst Mavericks is almost fully functional on my P5Q-Pro with connectivity , sound and display etc I have yet to get it to recognise a windows drive attached to a Marvell IDE controller but am curious whether anybody can shed any light on an error I get during bootup . The title message is preceded by a line "name" not a kext..... Link to comment Share on other sites More sharing options...
wasureppoi Posted November 23, 2013 Author Share Posted November 23, 2013 The Appleviaata.kext fixed my last problem thank you guys but am still curious about the SYMTAB matter.. Link to comment Share on other sites More sharing options...
wasureppoi Posted November 24, 2013 Author Share Posted November 24, 2013 Talking to oneself first sign? At any rate I realize now that this message pops up in the bootable usb I made up - which worked OK but as the twig is bent so shall the tree grow.. Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted November 24, 2013 Share Posted November 24, 2013 Nobody's helping you either because nobody has ever seen that message or because of lack of details. Please provide more information and describe your install method. 1 Link to comment Share on other sites More sharing options...
Jeraldo Posted January 5, 2014 Share Posted January 5, 2014 Please provide more information and describe your install method. bash-3.2# dmesg Longterm timer threshold: 1000 ms PMAP: PCID enabled Darwin Kernel Version 13.1.0: Sun Dec 15 18:48:24 PST 2013; root:xnu-2422.90.17~1/RELEASE_X86_64 vm_page_bootstrap: 1473663 free pages and 58241 wired pages kext submap [0xffffff7f807a6000 - 0xffffff8000000000], kernel text [0xffffff8000200000 - 0xffffff80007a6000] zone leak detection enabled "vm_compressor_mode" is 4 standard timeslicing quantum is 10000 us standard background quantum is 2500 us mig_table_max_displ = 74 "name" not a kext "Kernel-__SYMTAB" not a kext "DriversPackage-213b000" not a kext NullCPUPowerManagement::init: properties=0xffffff800d9994c0 NullCPUPowerManagement::start FakeSMCKeyStore: started AppleACPICPU: ProcessorId=1 LocalApicId=0 Enabled 1 Link to comment Share on other sites More sharing options...
Dmos Posted January 6, 2014 Share Posted January 6, 2014 i have same one my c2d .......but i can't find anything.....i use myhack 10.9.one the other hand my 10.8.5 fine with same config... thnaks Link to comment Share on other sites More sharing options...
Mr.Graphic Posted January 6, 2014 Share Posted January 6, 2014 Install the new version Chameleon. Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted January 6, 2014 Share Posted January 6, 2014 I may be wrong but I don't think this is related to Chameleon. I see them too. I guess maybe they have something to do with Apple's kext blacklisting...probably happens on real Macs too, did you check? Jan 6 19:25:29 localhost kernel[0]: "name" not a kext Jan 6 19:25:29 localhost kernel[0]: "Kernel-__SYMTAB" not a kext Jan 6 19:25:29 localhost kernel[0]: "DriversPackage-26f5000" not a kext Link to comment Share on other sites More sharing options...
Dmos Posted January 7, 2014 Share Posted January 7, 2014 I update boot loader nothing change.but if i use Usekernelcache=No -f (sometime its does not show)..... Link to comment Share on other sites More sharing options...
meklort Posted January 7, 2014 Share Posted January 7, 2014 This is due to a change in 10.9. The function that causes this message is createExcludeListFromBooterData. This function grabs the pre linked kexts and memory ranges allocated by the boot loader. This takes the kernel extensions that were passed in from the boot loader and searchs for the AppleKextExcludeList.kext extension. The kernel then reads the kext bundles its located in the OSKextExcludeList dictionary and uses this to deny the loading of kexts that match the bundle ID and version number. Actualy... this could effectively replace kexts like NullCPUPM. Currently this kext has a list of kexts that are known to panic on 10.9 (such as the zfs kext from greenbytes). The reason that you are seeing this issue is the following: 1) You are either (a) using the kernel patcher, ( using the FileNVRAM module or © using a non-prelinked kernel 2) The apple function checks *all* data based in by the bootlaoder and looks for names that start with Driver-* 3) Chameleon adds data to xnu using names such as Kernel-__SYMTAB 4) FileNVRAM adds data to the kernel using DriversPackage-213b000 5) The kernel's kext logging level is set to kOSKextLogErrorLevel | kOSKextLogGeneralFlag In other words... it's a harmless message. Basically it's the kernel saying that the current item it's looking at is *not* a kext, so it's skipping over it when looking for the exclude kext. Note that one a *real* mac you will not see this message (in most cases) as a kernel cache is almost always used. In the case of FileNVRAM, in addition to a pre linked kernel, an mkext is injected into the kernel (The DriversPackage message) *and* the kernel is patched to take the additional code path for loading non-prelinked extensions (normally pre linked kernels cannot take this path, so the message you se cannot be printed). Anyway.... that's probably way too much informations, but... there you go. 4 Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted January 7, 2014 Share Posted January 7, 2014 No that's awesome, thank you for explaining in such detail. Although now I'm worried that Apple might see that, hire you and put you under an NDA Also, it means I was about 1/2 wrong and 1/2 right, so I'm back to 0 lol Link to comment Share on other sites More sharing options...
wasureppoi Posted April 25, 2014 Author Share Posted April 25, 2014 May I express my abject apologies. I gave up on getting any feedback when I last posted and did not see Gringo's same day response nor the plethora that followed. As Meklort pointed out the message was pretty well irrelevant. i do have one lingering problem though that I might ask about and this time will be more patient. Whilst I was able to set up a few different drives running Mavericks I could only ever get them booting when they had been selected from the chameleon menu on drives running Lion or Mountain Lion. Whenever I selected the drive(s) that were running Mavericks as boot drive default theyI would only get a white cursor top left of the black screen - they would load and run normally ONLY as a selection on the boot menu of another drive... If I ran the chameleon wizard I could at least get the drive to boot and show its own menu but it would invariably crash.... I just cannot get the Mavericks drives to act standalone. Link to comment Share on other sites More sharing options...
wasureppoi Posted April 26, 2014 Author Share Posted April 26, 2014 Before certain crashes I often see references to kernel patcher and note that Meklort suggests I must be using the kernel patcher... Messages like: NAME TOO LONG TO ACCOMODATE PID OR Kernel Patcher c[534] Patching 64bit XNU Kernel (0-0-00 or (1-1-1) Have not deliberately used the kernel patcher and will see if I can UNUSE IT..... Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted April 26, 2014 Share Posted April 26, 2014 Just remove it from /Extra/Modules if you don't need it. 1 Link to comment Share on other sites More sharing options...
wasureppoi Posted April 27, 2014 Author Share Posted April 27, 2014 I removed the kernelpatcher.dylib from the extra/modules but have had no joy running Mavericks standalone. Any other suggestions? Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted April 28, 2014 Share Posted April 28, 2014 What do you mean "Mavericks standalone"? It's an operating system, it can't run on thin air Do you mean it doesn't boot without the kernel patcher module? Link to comment Share on other sites More sharing options...
wasureppoi Posted April 29, 2014 Author Share Posted April 29, 2014 What I meant was that if I selected the drive that had Mavericks on it as the boot drive in bios then I could not get it to boot and have the Mavericks OS running. However when I had another drive selected as the boot drive then I could select the "Mavericks" drive from the chameleon menu and it would boot normally and the OS would be Mavericks.. Thanks for your suggestion about the modules. Just now when I ran Chameleon wizard I went for broke on the plist settings and selected all the modules. Bingo at least I have been able to get Mavericks up and running again because I have to admit lately I could not get it running under any scenario... Standalone or as a selection.. I was so thrilled I just wanted to thank you for pointing me in the right direction. Will reboot now and see if I can get it running standalone.. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted April 29, 2014 Share Posted April 29, 2014 About the error(s), try this patch: 1) open load.c (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/load.c) 2) comment out line 37 3) comment out lines 207-214 4) comment out lines 322-360 5) recompile Chameleon 6) reboot 1 Link to comment Share on other sites More sharing options...
wasureppoi Posted April 29, 2014 Author Share Posted April 29, 2014 Thank you Pike R. I will tackle your suggestion forthwith. Further to my last post I found that when I booted standalone I got the message "kernel patcher reentering" with a "hit any key to continue" message. Hitting a key the kexts continued to load and at about twenty three pages of kexts loading the screen halted on the voodooTSCsync.kext. System did not crash but it was frozen. I found that if I removed the kernel patcher module and deleted the voodooTSCsync.kext the system would boot and load without any need to hit any key but it crashed... Thus your suggestion has given new hope. Link to comment Share on other sites More sharing options...
wasureppoi Posted April 29, 2014 Author Share Posted April 29, 2014 Whilst I could find myself in the Chameleon svn source tree following your link I am totally at sea. It wont let me comment out anything and even if I could what would I recompile with ? Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted April 29, 2014 Share Posted April 29, 2014 Thank you Pike R. I will tackle your suggestion forthwith. Further to my last post I found that when I booted standalone I got the message "kernel patcher reentering" with a "hit any key to continue" message. Hitting a key the kexts continued to load and at about twenty three pages of kexts loading the screen halted on the voodooTSCsync.kext. System did not crash but it was frozen. I found that if I removed the kernel patcher module and deleted the voodooTSCsync.kext the system would boot and load without any need to hit any key but it crashed... Thus your suggestion has given new hope. Instead of VoodooTSCsync.kext you can use 'TSC_sync_timer=0' (case sensitive/without the quotes) in com.apple.Boot.plist Link to comment Share on other sites More sharing options...
joe75 Posted April 29, 2014 Share Posted April 29, 2014 tscsync kext is actually patching tsc where tscsync_timer=0 is just ignoring it.. it would only work for him because he doesn't need tscsync to begin with. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted April 29, 2014 Share Posted April 29, 2014 tscsync kext is actually patching tsc where tscsync_timer=0 is just ignoring it.. it would only work for him because he doesn't need tscsync to begin with. Actually. The kext doesn't patch anything related to the TSC sync error. What it does is that it syncs cores within the Apple specified value of 0xfff (4096). Also. Other people in this forum, who needed the kext, already confirmed that the boot argument worked for them. Not to mention that the OP used the kext. Link to comment Share on other sites More sharing options...
joe75 Posted April 29, 2014 Share Posted April 29, 2014 Did you read that he removed the kext? That command is intended for debug purposes and NO one should be using it for regular use. This command is simply telling the kernel to ignore any differences found in the tsc margin check on boot, basically an unknown cpu. It's still not using a value known to the kernel like the patched value set by Voodoo patches; kernel or kext. So if these other people here in the forum had a true tsc sync error which causes system instabilities, data corruption and eventual system panic they would have no choice but to use a voodoo type solution or cpus=1 command. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted April 29, 2014 Share Posted April 29, 2014 Yes. He removed the kext – hence my use of the word "used". And this boot argument has absolutely nothing to do with being a debug argument and the error is in no way caused by your so called "unknown CPU". That is just not true. Not for someone who knows stuff. p.s. Guys. The other people I referred to can be found in this forum, and they indeed had to use the kext, but no longer need it Link to comment Share on other sites More sharing options...
Recommended Posts