malfunct Posted June 11, 2011 Share Posted June 11, 2011 I'm suffering from a strange slowdown in my system. It adversely affects my music applications, I believe. I've determined that this happens because of my Virus TI Snow device attached via Firewire. The error recurs on both 32-bit and 64-bit mode. I'm using the latest Virus TI driver to be sure. Still no use. My system is Gigabyte EX-58-UD5 with a core i7 processor. I haven't been able to find out on the web what this means. I think the system is actually momentarily freezing and continuing. How can I fix this? My kernel log is full of these messages! 11.06.2011 17:19:39 kernel KeThread::run - delay:2816us 11.06.2011 17:19:40 kernel KeThread::run - delay:2698us 11.06.2011 17:19:41 kernel KeThread::run - delay:2744us 11.06.2011 17:19:41 kernel KeThread::run - delay:1991us 11.06.2011 17:19:42 kernel KeThread::run - delay:3359us 11.06.2011 17:19:42 kernel KeThread::run - delay:3980us 11.06.2011 17:19:43 kernel KeThread::run - delay:1945us 11.06.2011 17:19:43 kernel KeThread::run - delay:3559us 11.06.2011 17:19:44 kernel KeThread::run - delay:2841us 11.06.2011 17:19:44 kernel KeThread::run - delay:1850us 11.06.2011 17:19:45 kernel KeThread::run - delay:2493us 11.06.2011 17:19:45 kernel KeThread::run - delay:3348us 11.06.2011 17:19:46 kernel KeThread::run - delay:2418us 11.06.2011 17:19:46 kernel KeThread::run - delay:1897us Here is how the kernel log looks like when I plug it in and out: Jun 23 20:57:43 orion kernel[0]: atch failed. wait another 20 ms Jun 23 20:57:43 orion kernel[0]: Mutex::lock() from:AUDIOUSERCLIENTCLASS::userDispatchMutex::lock() from:AUDIOUSERCLIENTCLASS::userDispatch failed. failed. wait another 20 ms Jun 23 20:57:43 orion kernel[0]: wait another 20 ms Jun 23 20:57:43 orion kernel[0]: configured fr:44100 in:6/16 out 2/16 Jun 23 20:57:43 orion kernel[0]: PGDevice::resumeStreaming 0 Jun 23 20:57:43 orion kernel[0]: mBulkIOGuard_CiticalPoint:63 mBulkIOGuard_CiticalPointLow:32 Jun 23 20:57:43 orion kernel[0]: AudioSM::init nUsedSamples != nMaxSamples 131070 - 131072 Jun 23 20:57:43 orion kernel[0]: Mutex::lock() from:AUDIOUSERCLIENTCLASS::userDispatch failed. wait another 20 ms Jun 23 20:57:45: --- last message repeated 4 times --- Jun 23 20:57:44 orion kernel[0]: KeThread::run - delay:1531us Jun 23 20:57:44 orion kernel[0]: KeThread::run - delay:2095us Jun 23 20:57:45 orion kernel[0]: KeThread::run - delay:1713us Jun 23 20:57:45 orion kernel[0]: KeThread::run - delay:2897us Jun 23 20:57:46 orion kernel[0]: KeThread::run - delay:2164us Jun 23 20:57:46 orion kernel[0]: KeThread::run - delay:1722us Jun 23 20:57:47 orion kernel[0]: KeThread::run - delay:4077us Jun 23 20:57:48 orion kernel[0]: KeThread::run - delay:1825us Jun 23 20:57:48 orion kernel[0]: KeThread::run - delay:1940us Jun 23 20:57:49 orion kernel[0]: KeThread::run - delay:1752us Jun 23 20:57:49 orion kernel[0]: KeThread::run - delay:3543us Jun 23 20:57:50 orion kernel[0]: KeThread::run - delay:2125us Jun 23 20:57:50 orion kernel[0]: Lost Sync...Len:33 Expected:44 MaxDelta:2 Jun 23 20:57:50 orion kernel[0]: rtsIsoReadCompleteStatic called with status:E00002ED Jun 23 20:57:50 orion kernel[0]: ENTER terminate PGKernelDeviceVirus v2.1.0 Jun 23 20:57:50 orion kernel[0]: KeThread_IOThreadFunc EXIT Jun 23 20:57:50 orion kernel[0]: rtsIsoReadCompleteStatic called with status kIOReturnAborted m_bCancel:1 m_bStreamingStarted:0 J Link to comment https://www.insanelymac.com/forum/topic/259065-virus-ti-causes-kethreadrun-delay-messages-in-kernellog/ Share on other sites More sharing options...
Gringo Vermelho Posted June 16, 2011 Share Posted June 16, 2011 Wow what a mess. Did you use the "carpet bombing" installation method? So many crutches, most of them should not be necessary on hardware like yours. Don't use ATY_Init and NVEnabler at the same time! I see GF100Hal is loading, do you have a Fermi video card? If so get rid of both ATY_Init and NVEnabler and use Chameleon GraphicsEnabler instead. Upgrade to Chameleon 2.0 RC5 and get rid of Evoreboot, OpenHaltRestart and PlatformUUID.kext Get rid of Sleepenabler.kext, Disabler.kext and NullCPUPowerManagement.kext and try to get native power management working. You can start by getting AppleLPC.kext to load, there are three ways to do it: http://www.projectosx.com/forum/index.php?...post&p=2532 Those Logitech Control Center errors ("trying to change a collection in the registry", USB stuff dependency messages) in your log should only occur in 32-bit mode. Try booting in 64-bit mode. Important: boot with -f the first time so that it doesn't try to load the 32-bit extensions cache. This is probably not related to your issues but it will really help clean up the logs. Make sure the drivers for your outboard audio hardware (if any? It looks like you have something) are 64-bit compatible. Link to comment https://www.insanelymac.com/forum/topic/259065-virus-ti-causes-kethreadrun-delay-messages-in-kernellog/#findComment-1698754 Share on other sites More sharing options...
malfunct Posted June 20, 2011 Author Share Posted June 20, 2011 Hello Gringo, Yes, I did use the carpet bombing installation method I suppose I first installed using a native installation method (using the retail DVD of Leopard). It was working fine then. Then I had some troubles with the upgrade to snow leopard (and with some drivers like the onboard sound device) and as you can see I've messed up things in the process (On the other hand, I've been using [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] and tonymacx86's releases for the upgrade to snow leopard) I am going to carefully try out all of your suggestions and then perhaps I will be able to clear out the mess a bit. :/ You've said that I've been using that system in 32-bit mode, that might explain why the onboard sound device was working (I don't think it works in 64-bit mode). I do have external sound cards (I have one m-audio and one TC electronics), this was the very reason I started using hackintosh. And I do use a Fermi card for GPU coding. I'm using my other hackintosh right now, which doesn't have that problem although I had forked it from that system. I'm diffing kernel extensions and processes of both systems, too. I'll let you helpful hackintosh hackers know what happens after I trim that system a bit! Thanks a bunch! It's really appreciated. malfunct Link to comment https://www.insanelymac.com/forum/topic/259065-virus-ti-causes-kethreadrun-delay-messages-in-kernellog/#findComment-1700853 Share on other sites More sharing options...
Gringo Vermelho Posted June 20, 2011 Share Posted June 20, 2011 Start with the easy stuff, delete OpenHaltRestart and EvoReboot (both do the same thing) and see if you can restart and shut down normally. Chameleon has a "restart fix" built in now (don't remember since which release) that obsoletes those kexts. PlatformUUID.kext has also been obsoleted by Chameleon (UUID is now pulled from your motherboards SMBIOS table and injected automatically), but if you have software that depends on your existing injected PlatformUUID for registration purposes you should probably keep it. Only one way to find out - delete it and try running your pro audio software. If things stop working (invalid registration data/serial number/computer ID messages) then put it back. Your iTunes account is also tied to this ID but I read somewhere that they changed something in itunes so that it is less restrictive now, not sure what the status is on that. Experiment, see what sticks and let me know! ATY_Init is a graphics injector, you don't need it since you already have NVEnabler working. Besides they'll be fighting each other while injecting properties for your video card. Depending on which display ports you are using, you can delete both and use GraphicsEnabler=y instead. The latest SVN builds of Chameleon 2.0 RC5 allows you to set a new property for each connected display (previously only available via DSDT injection or by editing NVEnabler's info.plist) called display-cfg which will let you override your display type if it fails to autodetect. There's more info on that in the NVEnabler release thread over on the ProjectOSX forums. Remember to boot with -f or delete/rebuild the kernel extensions cache when deleting kernel extensions from /System/Library/Extensions. Otherwise they will just load from the cache again on next boot. After deleting kernel extensions, run terminal and type sudo touch /System/Library/Extensions to rebuild the extensions cache before rebooting. Native power management is more complicated, to begin with you will have to delete your disabler.kext and NullCPUPowerManagement.kext - those are hackintosh patches that prevents native power management from working on incompatible hardware. Then get AppleLPC.kext to load. Next step is adding GeneratePStates=y and GenerateCStates=y to com.apple.Boot.plist. If you do some searching you will find references to editing DSDT and SSDT in order to get this working. This should not be necessary anymore, since this version of Chameleon: http://www.insanelymac.com/forum/index.php?showtopic=225766 ( SleepEnabler is primarily used on systems where native power management is not working. With a little luck, S3 sleep should "fix itself" once you get native power management going and then you won't need sleepenabler. On some systems a little DSDT tickling is necessary for sleep and wake to work properly though. Install IORegistryExplorer from apple dev tools so that you can track and verify your work. Link to comment https://www.insanelymac.com/forum/topic/259065-virus-ti-causes-kethreadrun-delay-messages-in-kernellog/#findComment-1700865 Share on other sites More sharing options...
malfunct Posted June 23, 2011 Author Share Posted June 23, 2011 It's caused by Virus TI Snow. The device driver prints those messages. Both on 32-bit and 64-bit, I'm using 4.1 version. Does anyone know how to fix this? Link to comment https://www.insanelymac.com/forum/topic/259065-virus-ti-causes-kethreadrun-delay-messages-in-kernellog/#findComment-1702089 Share on other sites More sharing options...
Recommended Posts