Jump to content

USB sleep then wake "Device Removal" problem


  • Please log in to reply
150 replies to this topic

#1
pcb355

pcb355

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
I'm new to this forum, but I have been active in OSX86 development for some time. I'm trying to solve a problem with USB on an otherwise perfect OSX86 system. It involves sleep functionality on the EHCI USB bus. Upon wake from sleep, if a USB drive has been attached, the system displays the "Device Removal" warning dialog. I have tried everything on the internet available for this problem, including Slice's kexts, AnV's kexts, teh EHCISleepEnabler.kext, variois IOPCIFamily.kexts, BIOS settings, all to no avail. USB is working absolutly perfect except for this issue, as is the rest of the system. It seems to me that the problem (at least on this MB, and probably other ICH10R MBs) is related to how the USB drivers initialize the ports, and thus determine their power management (sleep) capabilities. On this system, the EHCI USB ports are seen as PCI devices, rather than as built-in devices. This means that the driver will turn off the port and turn it back on again instead of suspending and resuming the port like it should.

I've written device drivers before and done some XCode development, and I'm currently getting my build environment correct, and starting to test some simple changes in the sleep capability section of AppleUSBEHCI.

Am I heading in the right direction?

If so, any pointers or other suggestions?

Thanks for the feedback.

#2
indraganzo

indraganzo

    InsanelyMac Protégé

  • Members
  • PipPip
  • 83 posts
I'm having the same problem on my GA EP45T DS3 board and Disableing or enabling the wake on usb and keyboard in bios does not have an affect I still get the Device removal error for my usb drives.. This does not happen like this on my mac book
I have been trying to fix this one for weeks looking for any hints on the web with out success. I can not belive only you and me are geting this error upon wake up my board is also ICH10 ,there must be more people getting this one
I think a possible fix might be through editing the usb wake parameters on the DSDT but I'm not quite sure how exactly that works we might have to compare a mac pro DSDT with our ones

#3
pcb355

pcb355

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
I would like to coordinate and maybe we can solve this together. I haven't yet gotten into the DSDT patching yet, but after doing some research, it seems that it's superior to the /Extra method for some devices, like audio. I have a few questions for you:

On your ethernet, you are using the DSDT patch instead of any replacement kext in the /Extra folder correct? If so, are you able to get full functionality, in other words, bonjour, AFP, DHCP reconnect after sleep, etc? I had to use the Psystar 1.8.1 extension inside of the IONetworkingFamily.kext in the /Extra folder for complete functionality.

On the audio, do you have full functionality, including front panel headphone switching and mic input working? I have full functionality using the legacy kexts (stickpin ALC889a Beta5) for HDA as well as the HDAEnabler.kext in the /Extra folder. One slight problem I have is that there are a couple of sound assertion errors in the system log on bootup, and there is an additional delay on bootup of about 10 seconds, and this is probably related. My legacy kexts are probably not quite right for my system. Would you mind sharing yours with me?

I've been using the older disabler.kext in the /Extra folder, and it has worked well so far. You are using a patch in the DSDT that doesn't require this. I just ran into another problem, as I'm using the G92 based video card, and there is a problem with AppleUpstreamUserClient.kext, which must be disabled, or use of iTunes results in a jerky system. There is a newer disabler which has just the CPUPM and this kext disabled, which solves this problem for me. So I would probably have to continue using some sort of disabler, at least for this, correct?

I'm also using AnV's AppleSMBIOS.kext, and Psystar's OpenHaltRestart.kext. I'm assuming that with a proper DSDT these aren't needed either?

Thanks so much for any and all feedback.

#4
indraganzo

indraganzo

    InsanelyMac Protégé

  • Members
  • PipPip
  • 83 posts

On your ethernet, you are using the DSDT patch instead of any replacement kext in the /Extra folder correct? If so, are you able to get full functionality, in other words, bonjour, AFP, DHCP reconnect after sleep, etc? I had to use the Psystar 1.8.1 extension inside of the IONetworkingFamily.kext in the /Extra folder for complete functionality.


I have not included Ethernet on my DSDT yet. I am using EFI string for it. To be able to work bonjour and stuff I also had to use the Psystar realtek r1000 driver 1.8.1 , this only worked on 10.5.6 not 10.5.5

On the audio, do you have full functionality, including front panel headphone switching and mic input working? I have full functionality using the legacy kexts (stickpin ALC889a Beta5) for HDA as well as the HDAEnabler.kext in the /Extra folder. One slight problem I have is that there are a couple of sound assertion errors in the system log on bootup, and there is an additional delay on bootup of about 10 seconds, and this is probably related. My legacy kexts are probably not quite right for my system. Would you mind sharing yours with me?

I have fully working 7.1 Audio no errors using no front panel legacy kexts as my case does not have a front panel from this thread http://www.insanelym...p...st&p=998397

I've been using the older disabler.kext in the /Extra folder, and it has worked well so far. You are using a patch in the DSDT that doesn't require this. I just ran into another problem, as I'm using the G92 based video card, and there is a problem with AppleUpstreamUserClient.kext, which must be disabled, or use of iTunes results in a jerky system. There is a newer disabler which has just the CPUPM and this kext disabled, which solves this problem for me. So I would probably have to continue using some sort of disabler, at least for this, correct?
I'm also using AnV's AppleSMBIOS.kext, and Psystar's OpenHaltRestart.kext. I'm assuming that with a proper DSDT these aren't needed either?

There comes the advantages of using the DSDT patcher and the DSDT override method. Once you fix your DSDT you can actually run AppleIntelCPU.kext without Disabler problems also you can get HPET and sleep working too..
I personally use a mix of EFI strings DSDT override and Extra/Extensions.mkext methods to run a totally vanilla Sytem/Library/Extensions and aflexible upgrade hassle free system.
here are my Extra kexts :
AppleDecrypt.kext

SMBios from karaakeha1
AppleSMBIOS.kext

JmicronATA fix from CycloneFr
LegacyJMicronATA.kext

for ICH10 and Yellow drive icon fix from netkas
LegacyAppleAHCIPort.kext
LegacyAppleIntelPIIXATA.kext
LegacyIOAHCIBlockStorage.kext

for Audio from tmongkol
LegacyHDAController.kext
LegacyHDAPlatformDriver.kext

Attached File  Extra_Extensions.zip   62.54KB   160 downloads

Note : the r1000 from psystar I had to put in S/L/E some how it did not work in the extra folder
how did you do yours?



Coming back to our real subject the notorious Device Removal error of USB drives upon wake up .......

I have noticed something in my logs
Mar  2 12:15:49 localhost kernel[0]: .534	AppleUSBOHCI[0xacf0000]::CheckSleepCapability - controller will be unloaded across sleep

This obviously addresses the issue we have as the controller unloadds across sleep

can we edit something in the AppleUSBOHCI kext?

what do you think

#5
hafnium

hafnium

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
I have the exact same problem (USB functions lost during sleep).

I recently switched from a P35 (ICH9R) based board to a P45 (ICH10R) based board. With the P35 board, using IOUSBFamily.kext patched by Slice (see thread), I was able to get full USB functionality, including wake from sleep using a USB keyboard. With the P45 board, USB functionality behaves exactly like the P35 board with the unpatched IOUSBFamily. Using the patched IOUSBFamily.kext from Slice with the P45 board made no difference.

Booting the P45 board with -v gives the following information (regardless of using vanilla or Slice-patched IOUF.kext):

USBF: 0.356 AppleUSBOHCI[0x8945000]::CheckSleepCapability - controller will be unloaded across sleep.

According to Slice in the above thread, he did not correct anything in the kext for ICH10, as it was "added by Apple".

Strangely though, weaksauce12 states that the EP45-UD3P board works OOB with regards to USB (wake from sleep using the keyboard; see thread).

I think we should beg Slice to take another look at the IOUSBFamily.kext with specific focus on the P45 (ICH10) chipset.

Coming back to our real subject the notorious Device Removal error of USB drives upon wake up .......

I have noticed something in my logs

Mar  2 12:15:49 localhost kernel[0]: .534	AppleUSBOHCI[0xacf0000]::CheckSleepCapability - controller will be unloaded across sleep

This obviously addresses the issue we have as the controller unloadds across sleep

can we edit something in the AppleUSBOHCI kext?

what do you think


I don't think the ICH10 chipset contains any USBOHCI controllers. I've installed the Apple Dev program USB Prober, which doesn't find any OHCI controllers. Probably a bug (mistyping?) in the IOUSBFamily.kext because AppleOHCIUSB.kext is not loaded (AppleEHCIUSB and AppleUHCIUSB both are loaded).

Lets beg Slice (see my other reply) to look at his patches for ICH10 once again.

#6
indraganzo

indraganzo

    InsanelyMac Protégé

  • Members
  • PipPip
  • 83 posts
I have done a little research and I have come across these I haven't tested them but feel free to try them out and report
one work arround
http://www.macosxhin...080329201951648
and an other one
http://vocaro.com/tr...efore-sleeping/

I think this is also a problem with real macs when used with some equipment

#7
TheBogieMan

TheBogieMan

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 112 posts
  • Gender:Male
  • Location:Ireland
I'm having the same issue since upgrading to 10.5.6, I'll give the scripts a whirl and report back....or not as the case may be :D

I've also lost time machine functionality since the upgrade but that's a load of other threads for to trawl to see if there's a fix

#8
indraganzo

indraganzo

    InsanelyMac Protégé

  • Members
  • PipPip
  • 83 posts
when I boot without the usb drive I get this one instead of the one above

Mar  2 17:47:15 localhost kernel[0]: controller will be unloaded across sleep

any ideas? :D

#9
hafnium

hafnium

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
Sorry, but I don't think this is the solution we are looking for.

The problem seems to be that the USB driver in OS X (in this case the AppleUSBEHCI.kext plugin in the IOUSBFamily.kext) recognizes the ICH10 USB controller as not being sleep capable.

You can download the source code from Apple. If you look inside, you'll find that every USB controller (EHCI) that doesn't contain a specific Apple phrase (AAPL) will be treated as being located on an expansion slot (PCI) and therefore not sleep capable.

If you go to System Profiler/USB, you'll see that the "Host Controller Location" is "Expansion Slot". We need to have OS X recognize the location as being built in (Built In USB), which is the case for other USB busses listed in the System Profiler (under USB Bus).

Also, inside the AppleUSBEHCI.kext, where the distinction is being made between sleep capable and not sleep capable, there is a reference to USBOHCI (note the O) even though we are dealing with the EHCI controller driver.

We need to ask Slice to look at his patched kexts again or to find a way to make OS X recognize EHCI controllers as being built in and no located on a expansion slot.

#10
pcb355

pcb355

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
I agree. The root of the problem is the designation of PCI vs Built-in on the EHCI USB ports. There are two ways to deal with this, IMHO:

1. Work with the DSDT or other method to modify the IORegistry to indicate Built-in for the EHCI USB ports. This is the best method as it should work going forward with the standard Apple vanilla USB drivers.

2. Modify the source code for the EHCI driver to set the correct sleep capability. This is not as clean as it requires putting the entire modified IOUSBFamily.kext in the /Extra folder, which may cause problems with future updates.

On my system, USB is working perfectly, sleep and wake from sleep with KB and mouse, just the "Device Removal" problem on USB storage devices, so I would prefer a vanilla USB driver solution with this problem fixed. I will be working on a DSDT solution first, and I will report back on my progress.

#11
pcb355

pcb355

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
On the Psystar 1.8.1 driver, it has to be in the plug-ins folder of the IONetworkingFamily.kext, as it has dependencies there. I took the latest 10.5.6 version of this, added the Psystar kext to it, and then put this in the /Extra folder. It's not the most elegant solution, as a future update to IONetworkingFamily might break this, but it's the best solution I've found so far for full networking functionality on the Realtek 8111C ethernet chipset.

#12
hafnium

hafnium

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
Yes, I agree too. Vanilla kexts are preferred. If you are able to find a DSDT or perhaps a EFI string solution, that will be nice. Looking forward to hearing about your progress.

In the meantime I have asked Slice to take another look at his patches for IOUSBFamily.kexts. Let's hope he responds (always a good idea to ride two horses).

#13
indraganzo

indraganzo

    InsanelyMac Protégé

  • Members
  • PipPip
  • 83 posts

Sorry, but I don't think this is the solution we are looking for.

If you go to System Profiler/USB, you'll see that the "Host Controller Location" is "Expansion Slot". We need to have OS X recognize the location as being built in (Built In USB), which is the case for other USB busses listed in the System Profiler (under USB Bus).


on my mac book I Don't have this problem and USB high speed bus' Host Controller reports as built in where as my GA EP45T DS3 reports it as expansion slot.

But on my GA EP45T DS3 when I insert my USB Drive to any other UHCI USB port which reports as built in still I get the "Device Removal" isn't that weird too.??
My expectation would be that the built in UHCI ports would work with out a problem which is not the case here...
Are we missing something ?

Here is a document about Intel EHCI USB for Developers.
May be we can understand better how EHCI works
INTEL EHCI USB

Yes I would also like to try to report my EHCI ports as Built in and see if we can nail it this way...

#14
pcb355

pcb355

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
This is the edit I made to the stock AppleUSBEHCI.kext:

[codebox] if (!_hasPCIPwrMgmt)
{
// USBError(1, "AppleUSBOHCI[%p]::CheckSleepCapability - controller will be unloaded across sleep",this);
// _controllerCanSleep = false;
// setProperty("Card Type","PCI");

// My power management fix
_controllerCanSleep = true;
setProperty("Card Type","Built-in");
}

[/codebox]

This works on my system, a GA-EP45-Extreme.

I've attached the compiled AppleUSBEHCI.kext to test, which has only the change above from the current vanilla 10.5.6 driver.

Attached Files



#15
indraganzo

indraganzo

    InsanelyMac Protégé

  • Members
  • PipPip
  • 83 posts
pcb355,
you rock man
working on my GA EP45T DS3 :D

#16
TheBogieMan

TheBogieMan

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 112 posts
  • Gender:Male
  • Location:Ireland
Out of interest lads, what does your Host & PCi bridge show up as when you run LSPCI ?
As I'm wondering if this will work for GA-G31M-S2L boards as well, that shows up as the following

00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 10)
00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1] (rev 10)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 01)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller [8086:27c0] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01)

#17
pcb355

pcb355

    InsanelyMac Protégé

  • Members
  • Pip
  • 13 posts
Thanks for the feedback.

Alas, I'm having an additional problem: After resume, the attached USB drive has slower read/write speeds until it's ejected and then reinserted. A very handy little utility for checking drive speed is "AJA System Test", google it it's a free download. Could you check to see whether you have this little problem as well?

Thanks so much.

#18
hafnium

hafnium

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts

Out of interest lads, what does your Host & PCi bridge show up as when you run LSPCI ?
As I'm wondering if this will work for GA-G31M-S2L boards as well, that shows up as the following

00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 10)
00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1] (rev 10)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 01)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller [8086:27c0] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01)


Well, try it out. Do you get the "... controller will be unloaded across sleep" message during boot? If so, it should work. ICH7 support was added by Slice in his patches IOUSBFamily.kext (see thread).

#19
TheBogieMan

TheBogieMan

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 112 posts
  • Gender:Male
  • Location:Ireland

Well, try it out. Do you get the "... controller will be unloaded across sleep" message during boot? If so, it should work. ICH7 support was added by Slice in his patches IOUSBFamily.kext (see thread).


Yes I do, I'll give it a try later (when the wife goes out and I can get away from the decorating :rolleyes: )

#20
TheBogieMan

TheBogieMan

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 112 posts
  • Gender:Male
  • Location:Ireland
Don't panic, I didn't break it.....just spent the best part of the week on the beer :D

I'd forgotten to do the "sudo rm -r -v /System/Library/Extensions/PCGenUSB*
sudo rm -r -v /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/PCGenUSB*
" bit

Sleep is all working fine and dandy now ;)





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy