Voodooprojects
Chameleon => Bug Reports => Topic started by: chris789 on April 19, 2009, 06:55:26 PM
-
There is a problem with Firewire:
kernel[0]: ERROR: FireWire unable to determine security-mode; defaulting to full-secure.
which is a problem because this disables DMA for Firewire and that means slow transfer and high CPU load.
From the source IOFireWireFamily, IOFireWireController.cpp
/
// assume security mode is normal
//
IOFWSecurityMode mode = kIOFWSecurityModeNormal;
//
// check OpenFirmware security mode
//
{
char matchPath[32]; // IODeviceTree:/:options
OSDictionary * optionsMatchDictionary = IOOFPathMatching( "/options", matchPath, 32 ); // need to release
mach_timespec_t t = { 10, 0 }; //wait 10 secs
IOService * options = IOService::waitForService( optionsMatchDictionary, &t ); // consumes dict ref, don't release options
if( options != NULL )
{
OSString * securityModeProperty = OSDynamicCast( OSString, options->getProperty("security-mode") );
if( securityModeProperty != NULL && strncmp( "none", securityModeProperty->getCStringNoCopy(), 5 ) != 0 )
{
// set security mode to secure/permanent
mode = kIOFWSecurityModeSecurePermanent;
}
}
else
{
ErrorLog("FireWire unable to determine security-mode; defaulting to full-secure.\n");
// turn security on because we can't determine security-mode
mode = kIOFWSecurityModeSecurePermanent;
}
}
I think this means that "IODeviceTree:/options" is not available within 10s.
If anybody could enlighten me if this can be resolved from Chameleon or anything else I would be happy about any hints.
-
I realized that Chameleon 2.0 will defeat this. You can try this http://www.superhai.com/files/deprecated/SMBIOSResolver.kext.zip but you will need an old version of chameleon, as the new one in its endless wisdom is creating the /options node. The Firewire kext is waiting for it to be created, and as chameleon creates it during boot before kernel (on a real mac the /options node is created after kernel starts up by the efinvram kext) it will time out and use permanent security instead of normal.
-
This could definitely explain my slow firewire transfers, I get the same message. SuperHAI, what would prevent me from loading the SMBIOSResolver instead of smbios.plist? I think I can override using smbios.plist in my boot.plist. Also, according to this post, Andy V has incorporated your fixes into this own AppleSMBios.kext
http://www.insanelymac.com/forum/index.php?showtopic=129930
Would you recommend that kext now?
Chameleon team - do you guys plan on changing this to superhai's suggestion? I *do* have very slow firewire transfer rates but thought it came with the territory of hackintosh. If this could be fixed, I'd be very, very happy!
-
I don't know what AnV has changed, you must ask him. But the one I posted here was modified to add securtiy-mode to the options node. It has nothing to do with smbios at all. You will have to try and see if it works
-
I just tried SMBIOSResolver in combination with Chameleon 1.0 with smbios patching, and it gives panic at boot. I haven't a photograph of the panic but it says it is SMBIOSResolver related.
If you need a picture I'll take one.
Any idea about that ?
-
I don't know what AnV has changed, you must ask him. But the one I posted here was modified to add securtiy-mode to the options node. It has nothing to do with smbios at all. You will have to try and see if it works
So I couldn't bypass smbios.plist (in my boot.plist) and load your kext with Chameleon 2.0?
-
If you need a picture I'll take one. Any idea about that ?
It would help alot with the panic, or I would have nothing...
-
humm… A very strange thing hapenned, I reinstalled SMBIOSResolver exactly the same way as before (ie. with Kext Helper) and now it boots normally :o
Sorry for the disturbance, I'm a bit confused…
-
I realized that Chameleon 2.0 will defeat this. You can try this http://www.superhai.com/files/deprecated/SMBIOSResolver.kext.zip but you will need an old version of chameleon, as the new one in its endless wisdom is creating the /options node. The Firewire kext is waiting for it to be created, and as chameleon creates it during boot before kernel (on a real mac the /options node is created after kernel starts up by the efinvram kext) it will time out and use permanent security instead of normal.
Sorry, I am not sure I understand the situation. Why would the Firewire kext not find an existing /options node immediate? Does this mean it's a precondition for success that before the waitForService starts the node does not exist?
From xnu, IOService.cpp:
IOService * IOService::waitForService( OSDictionary * matching,
mach_timespec_t * timeout )
{
IONotifier * notify = 0;
// priority doesn't help us much since we need a thread wakeup
SInt32 priority = 0;
SyncNotifyVars state;
kern_return_t err = kIOReturnBadArgument;
if( !matching)
return( 0 );
state.waitHere = 0;
state.result = 0;
LOCKWRITENOTIFY();
do {
state.result = (IOService *) getExistingServices( matching,
kIOServiceMatchedState, kIONotifyOnce );
if( state.result)
continue;
err = semaphore_create( kernel_task, &state.waitHere,
SYNC_POLICY_FIFO, 0 );
if( KERN_SUCCESS != err)
continue;
notify = IOService::setNotification( gIOMatchedNotification, matching,
&IOService::syncNotificationHandler, (void *) 0,
(void *) &state, priority );
} while( false );
UNLOCKNOTIFY();
if( notify) {
if( timeout)
err = semaphore_timedwait( state.waitHere, *timeout );
else
err = semaphore_wait( state.waitHere );
}
if( notify)
notify->remove(); // dequeues
else
matching->release();
if( state.waitHere)
semaphore_destroy( kernel_task, state.waitHere );
return( state.result );
}
It looks like the kernel checks existing nodes (getExistingServices) first, or is it the kernel doesn't even know about the already existing /options node?
-
Sorry, I am not sure I understand the situation. Why would the Firewire kext not find an existing /options node immediate? Does this mean it's a precondition for success that before the waitForService starts the node does not exist?
It looks like the kernel checks existing nodes (getExistingServices) first, or is it the kernel doesn't even know about the already existing /options node?
I didn't check the kernel source for getExistingServices, just tried it in the kext, and if it is created immediatelt (before the IOFirewire is run) it will fail, waiting till it is doing the watForService method then it will success.
-
I did a few new tests with your SMBIOSResolver v1.0.8. Thansk for that!
Unfortunately I had an older version (v1.0.7) until now which appears not to include the security-mode fix.
This is what I saw:
1) Chameleon2 with SMBIOSResolver.
Two options nodes exist in the device tree. Very strange, how is this possible? Firewire error eccurs.
ioreg -p IODeviceTree -l says (only relevant info shown):
+-o Root <class IORegistryEntry, retain 17>
+-o / <class IOPlatformExpertDevice, registered, matched, active, busy 0, retain 27>
+-o options <class IOService, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <"options">
| "IOPlatformUUID" = <0000000000001000800000508d9f42f0>
| }
+-o options <class IOService, !registered, !matched, active, busy 0, retain 4>
{
"resolver" = ""
"security-mode" = "none"
}
2) Installed munky's efi_boot v6.1 with SMBIOSResolver. munky's source is available and I checked that it does not touch the options node.
The node exists as expected but the firewire error is not fixed. I also checked disk transfer to firewire drive and it's slow with high CPU load.
+-o Root <class IORegistryEntry, retain 17>
+-o / <class IOPlatformExpertDevice, registered, matched, active, busy 0, retain 26>
+-o options <class IOService, !registered, !matched, active, busy 0, retain 4>
{
"resolver" = ""
"security-mode" = "none"
}
I can't really make sense of this.
-
Have you disabled or removed the kext for efinvram?
-
Have you disabled or removed the kext for efinvram?
Yes, I use Disabler.kext, which has the following in it's plist.
<key>IOKitPersonalities</key>
<dict>
<key>EFINVRAMDisabler</key>
<dict>
<key>CFBundleIdentifier</key>
<string>net.osrom.kext.Disabler</string>
<key>IOClass</key>
<string>Disabler</string>
<key>IOMatchCategory</key>
<string>AppleEFINVRAM</string>
<key>IOProbeScore</key>
<integer>1000</integer>
<key>IOProviderClass</key>
<string>AppleEFIRuntime</string>
<key>IOResourceMatch</key>
<string>efi-runtime</string>
</dict>
<key>EFIRuntimeDisabler</key>
<dict>
<key>CFBundleIdentifier</key>
<string>net.osrom.kext.Disabler</string>
<key>IOClass</key>
<string>Disabler</string>
<key>IOMatchCategory</key>
<string>AppleEFIRuntime</string>
<key>IOProbeScore</key>
<integer>1000</integer>
<key>IOProviderClass</key>
<string>AppleACPIPlatformExpert</string>
<key>IOResourceMatch</key>
<string>ACPI</string>
</dict>
<key>IntelCPUPMDisabler</key>
<dict>
<key>CFBundleIdentifier</key>
<string>net.osrom.kext.Disabler</string>
<key>IOClass</key>
<string>Disabler</string>
<key>IOMatchCategory</key>
<string>AppleIntelCPUPowerManagement</string>
<key>IOProbeScore</key>
<integer>1000</integer>
<key>IOProviderClass</key>
<string>IOResources</string>
<key>IOResourceMatch</key>
<string>IOKit</string>
</dict>
<key>SMCPlatformPluginDisabler</key>
<dict>
<key>CFBundleIdentifier</key>
<string>net.osrom.kext.Disabler</string>
<key>IOClass</key>
<string>Disabler</string>
<key>IOMatchCategory</key>
<string>ACPI_SMC_PlatformPlugin</string>
<key>IOProbeScore</key>
<integer>2000</integer>
<key>IOProviderClass</key>
<string>AppleACPICPU</string>
<key>IOResourceMatch</key>
<string>ACPI</string>
</dict>
</dict>
-
I never used it, can you try without disabling applevinvram?
-
I never used it, can you try without disabling applevinvram?
I try. Removed the entry for EFINVRAMDisabler in the Disabler plist.
I see no difference. In both case (before and after) I get:
u2c:~ chris$ kextstat -l | grep NVRAM
8 1 0x0 0x0 0x0 com.apple.iokit.IONVRAMFamily (9.6.0)
Firewire error persists.
-
I try. Removed the entry for EFINVRAMDisabler in the Disabler plist.
I see no difference. In both case (before and after) I get:
u2c:~ chris$ kextstat -l | grep NVRAM
8 1 0x0 0x0 0x0 com.apple.iokit.IONVRAMFamily (9.6.0)
You have to re-enable the EFIruntime to let AppleEFINVRAM to load I think. Try that.
-
You have to re-enable the EFIruntime to let AppleEFINVRAM to load I think. Try that.
OK. I removed all entries except IntelCPUPMDisabler from the Disabler kext.
AppleEFINVRAM loads now!
u2c:~ chris$ kextstat -l | grep NVRAM
8 1 0x0 0x0 0x0 com.apple.iokit.IONVRAMFamily (9.6.0)
43 0 0x5b18b000 0x6000 0x5000 com.apple.driver.AppleEFINVRAM (1.2.0) <35 7 6 5 4>
And the Firewire error is solved if I boot from EFI partition via munky's! I get 41 MB/s FW400 read with < 2% CPU load.
Thats's great. Thanks for your guidance!
The situation with Chameleon2 did not improve. AppleEFINVRAM loads, but there are still 2 options entries and the Firewire error persists.
-
ahhh this is good news...at least you're getting closer to fixing the problem! I'm sure the Chameleon guys are checking this thread....no way to fix this with Chameleon 2.0, eh? I'm not sure what the difference between Disabler.kext and IntelCPUMDisabler.kext - I use both of them on my Chameleon stick. Is that wrong?
-
before installing Chameleon 2 i view uuid data in ioregistryexplorer. Now is not show
-
@superhai
I have only IntelCPUPMDisabler.kext, boot from EFI partition, vanilla nstalls with Chameleon2.
My mobo is Gigabyte 965p. AppleEFINVRAM seems can't load.
Are there any way to make AppleEFINVRAM load?
Thanks in advance.
-
@superhai
I have only IntelCPUPMDisabler.kext, boot from EFI partition, vanilla nstalls with Chameleon2.
My mobo is Gigabyte 965p. AppleEFINVRAM seems can't load.
Are there any way to make AppleEFINVRAM load?
Thanks in advance.
In your IntelCPUPMDisabler.kext, is there any reference to AppleEFINVRAM? Did you clear out your extensions.mkext?
-
In your IntelCPUPMDisabler.kext, is there any reference to AppleEFINVRAM? Did you clear out your extensions.mkext?
Thanks for your reply.
I think there is no reference to AppleEFINVRAM in IntelCPUPMDisabler.kext.
I am sure I have cleared my extensions.mkext.
-
The same problem is happening in my mobo with Chameleon 2 RC1. I moved back to PCEFI v9 and the problem got solved.
Anyway before reverting to PCEFI v9 I tried the SMBIOSResolver.kext superhai´s posted here forcing not to load default smbios values at it seemed to work nicely, but the same kext doesn't load with PCEFI v9.
Any idea? I had to use the old AppleSMBIOSEFI.kext in order to get info from the Apple System Profiler.
I hope Chameleon guys fix this issue (and others http://forum.voodooprojects.org/index.php/topic,353.0.html (http://forum.voodooprojects.org/index.php/topic,353.0.html) ) when the final version is released.
-
hi,
i've got the same problem, but for me is really a big pain, because i'm a live musician and use a firewire audio interface.
i've built a custom box for live performance, with 10.5.6, but the i believe the firewire full secure mode is keeping me from using my rig on it's full potential. i've just tested the same software on it under Windows 7 and it rocks good.. but i still prefer the stability (and other issues, like midi timing) of OSX so if this problem gets solved i'll be very happy cat.
cheers
-
hi,
i've got the same problem, but for me is really a big pain, because i'm a live musician and use a firewire audio interface.
i've built a custom box for live performance, with 10.5.6, but the i believe the firewire full secure mode is keeping me from using my rig on it's full potential. i've just tested the same software on it under Windows 7 and it rocks good.. but i still prefer the stability (and other issues, like midi timing) of OSX so if this problem gets solved i'll be very happy cat.
cheers
Probably your best choice at the moment is installing PCEFI v9. It doesn't suffer the issue with firewire and you have full extra folder support. As you said this firewire problem is crucial for people working with professional audio interfaces (thank god all of my fellow musicians I installed OS X are using either usb or PCI cards).
I'd really love to know some updates about the issue and chamaleon "rc2". It's a pain going back to the ugly text interface after tasting chameleon 2 gui :P
-
I followed this thread with interest, but now I wonder:
Is there anywhere a write up or documentation why we need Disabler.kext, and which extensions still need to be disabled?
I have references to EFINVRAM, EFIRuntime, IntelCPUPM, and SMCPlatformPlugin disablers.
If I understand this thread, EFINVRAM, EFIRuntime could be deleted.
What about the rest, is this all stuff that eventually goes away as Chameleon evolves and emulates more of the EFI and SMBIOS functionality, or are there some fundamental reasons why these have to be disabled that way?
Pointers appreciated...
-
hi,
i've got the same problem, but for me is really a big pain, because i'm a live musician and use a firewire audio interface.
i've built a custom box for live performance, with 10.5.6, but the i believe the firewire full secure mode is keeping me from using my rig on it's full potential. i've just tested the same software on it under Windows 7 and it rocks good.. but i still prefer the stability (and other issues, like midi timing) of OSX so if this problem gets solved i'll be very happy cat.
cheers
Probably your best choice at the moment is installing PCEFI v9. It doesn't suffer the issue with firewire and you have full extra folder support. As you said this firewire problem is crucial for people working with professional audio interfaces (thank god all of my fellow musicians I installed OS X are using either usb or PCI cards).
I'd really love to know some updates about the issue and chamaleon "rc2". It's a pain going back to the ugly text interface after tasting chameleon 2 gui :P
thank you DooV,
now running full speed firewire (texas instruments) 8)
cheers!
-
Probably your best choice at the moment is installing PCEFI v9. It doesn't suffer the issue with firewire and you have full extra folder support. As you said this firewire problem is crucial for people working with professional audio interfaces (thank god all of my fellow musicians I installed OS X are using either usb or PCI cards).
I'd really love to know some updates about the issue and chamaleon "rc2". It's a pain going back to the ugly text interface after tasting chameleon 2 gui :P
We removed creation of /options node in r468, so it shouldn't cause Firewire DMA issues anymore.
The RC2 contains many fixes and improvements since r431, and we will release it as soon as we can :)
-
*Can't wait*
-
We removed creation of /options node in r468, so it shouldn't cause Firewire DMA issues anymore.
The RC2 contains many fixes and improvements since r431, and we will release it as soon as we can :)
Great!!!
-
We removed creation of /options node in r468, so it shouldn't cause Firewire DMA issues anymore.
The RC2 contains many fixes and improvements since r431, and we will release it as soon as we can :)
Will this solve my "No FireWire ports can be detected." problem too?
-
I doubt it. Your problem provably has to do with iopcifamily.kext. Either you are using a bad one or need a modified one.
-
DooV: thanks for your reply. Could you please point me in the right direction, I can't seem to find the problem that's causing the firewire issues.
I never had any issues with firewire before, I've been using the same hardware setup since 10.4.8, and I've updated the software whenever a new update came to the surface. I've been using the PCEFI9 (for about a year), but I decided to make a fresh 10.5.7 install and switch to Chameleon and give it a shot.
About the iopcifamily.kext - I never had to touch it to get the firewire working, it worked without any modifications.
Any information would be greatly appreciated, thanks.
edit: I'm starting to think, this is not a Chameleon related issue: http://discussions.apple.com/thread.jspa?threadID=2014443&tstart=1
edit2: putting it to sleep and then up again seems to bring the FW0 interface to the system. But the message in the system profiler changed to "Warning: Unable to list FireWire devices." and it's still not recognizing my audio interface.
edit3: SOLVED! ... well, kind off -- I had to delete the AppleHPET.kext, cleared the kext cache, rebooted and it worked. But aren't I gonna need the AppleHPET.kext?
-
Hah! just noticed I don't have the Firewire Secure error anymore so that probably means I'm running my DAW latency at maximum performance now. I have to check latency settings asap to confirm this.
I had the Secure issue with the Previous Chameleon pc_efi (V9) and gave up because I could not find any solution to this and I thought it was only affecting my boot time (+20 secs)
But I did not know this affects Firewire transfer and being a guitar player hooked up to an Presonus Inspire 1394 Firewire powered device I need the low latency.
So another + for the Chameleon 2 bootloader.
Now if you could only solve the deep sleep issue with Windows 7 (which worked before with v9) it would be perfect.
Thx and keep up the good work amigos
-
Hah! just noticed I don't have the Firewire Secure error anymore so that probably means I'm running my DAW latency at maximum performance now. I have to check latency settings asap to confirm this.
I had the Secure issue with the Previous Chameleon pc_efi (V9) and gave up because I could not find any solution to this and I thought it was only affecting my boot time (+20 secs)
But I did not know this affects Firewire transfer and being a guitar player hooked up to an Presonus Inspire 1394 Firewire powered device I need the low latency.
So another + for the Chameleon 2 bootloader.
Now if you could only solve the deep sleep issue with Windows 7 (which worked before with v9) it would be perfect.
Thx and keep up the good work amigos
???
Chameleon 2 RC1 does indeed have the firewire bug (which will be solved in the next version), and in fact it's PCEFI v9 the bootloader which doesn't have it at the moment. Have you read and understood this topic? I think you are confusing some things
-
Hi m8, the only thing I'm not 100% sure of is the fact that it happend with efi v9 or v8.
Other then that I think I'm on track here since I had the same Firewire Security Mode issue for a long time. Boot time was delayed about 20 secs or more (halt in between due to Firewire issue)
If I'm completely off topic then my apologies and I'll shut up.
Sorry for my bad english if thats the problem, Belgian user here.
Later lads
-
Probably your problem was a different one, since my osx install boots exactly in the same time with PCEFI v9 (FW ok) and with Chameleon 2 RC1 (FW DMA bug). I mean, the firewire bug doesn't produce any noticeable delay. Anyway there's some I can warrantee you, if you are using the current Chameleon 2 RC1 version you have the DMA bug up and running in your osx installation and so you will have high cpu usage while you make firewire transfers.
-
I keep waiting for RC2 to fix this... right now I can run a good number of tracks with a 128 buffer, which is pretty damn good... but I want want lower latency even! ;D
-
The firewire dma bug is not present in PCEFIv10 :)
-
After updating to Chameleon RC2 i still get the Firewire Security Error:
Aug 3 09:52:56 localhost kernel[0]: FireWire (OHCI) TI ID 8024 PCI now active, GUID 002f101500001fd0; max speed s400.
Aug 3 09:52:59 Hackmac kernel[0]: ERROR: FireWire unable to determine security-mode; defaulting to full-secure.
EDIT:
I had the "AppleEFIRuntime.kext" removed cause of CMOS reset issues. After i copied it back to the Extensionsfolder, the errormessage was gone. So RC2 DOES fix the slow Firewiretransfers IF the AppleEFIRuntime.kext is loaded.
I am trying another cmos-reset fix now (DSDT)
-
I'm still having this error:
ERROR: FireWire unable to determine security-mode; defaulting to full-secure.
after updating to Chameleon 2.0 RC2, no luck for me.
Motherboard: Gigabyte EP35-DS3P with an Intel Core2 Duo E8400.
-
I'm still having this error:
...
do you have AppleEFIRuntime.kext loaded?
-
Yes, I've AppleEFIRuntime , I've a retail insatallation with DSDT patch.
I've DSDT fix for HPET, Audio, ethernet "built-in", nvidia graphichs, and CMOS reset for SL.
I've only remove AppleUpstream.kext and replaced AppleSMBios.kext to inject hardware model.
I'm running 10.5.8, with some legacy kexts in Extra for Audio Path Maps and AHCI Storage.
Thanks.
-
... and replaced AppleSMBios.kext to inject hardware model.
...
Please, don't replace that kext, and use the /Extra/smbios.plist instead.
-
Ok, I restored original AppleSMBios.kext, now I' dont have the firewire error, instead I have
_CFGetHostUUIDString: unable to determine UUID for host. Error: 35
again (that was the reason of AppleSMBios replacement).
EDIT: Solved erroneus info in About this Mac and Sytem Profiler updating smbios.plist
Still having "_CFGetHostUUIDString: unable to determine UUID for host. Error: 35"
and in Harware->Memory : "Se ha producido un error al reunir esta información." an error occurred getting information.
SOLVED: with original AppleSMBios.kext and updating smbios.plist for info, and UUID.kext for
"Error 35".
Thanks.
-
hellow dear friend
i recently built hakintosh with snow 10.6.3 on dg31pr
all works fine
except firewire audio
its intrepted and i saw the same security error when booting verbose mode..
can you please explain how you resolved this issue...
you may have to be more elaborative as i am not expert..just learning by searching
thanks
regards
sachin
india
-
The issue you are having is unrelated to Chameleon, the issue discussed in this thread was resolved almost two years ago.
Make sure you are running Chameleon 2.0 RC5.
We can not offer general Hackintosh support here.
There is a thread about your Firewire issue over on InsanelyMac, IIRC it can be fixed via DSDT. Use the forum search over there to find it.