Jump to content

Asus P5Q-Pro - "kernel-_SYMTAB" not a kext


wasureppoi
 Share

39 posts in this topic

Recommended Posts

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

  • 1 month later...

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

 

  • Like 1
Link to comment
Share on other sites

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

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

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, ( B) 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.

  • Like 4
Link to comment
Share on other sites

  • 3 months later...

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

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

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

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

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

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

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

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

 Share

×
×
  • Create New...