Jump to content

Power Button & WOL Wakes in Lion (10.7)


rayap
 Share

69 posts in this topic

Recommended Posts

I do think that is intended behavior however.

Agreed. This Apple article 'Wake on Demand' gives an insight on their ways.

 

You should check your console in Lion on the S2L and check what Wake Reason it gives you when you wake it with Power Button or WOL. If you get "?", it has the problem. If you get PWRB or PXS1 or something, then it works as it should.

 

In S2L, as stated before the Power Button Wake Reason is 'power-button' in the Diagnostic and Usage Messages and 'power-button (User)' in Kernel log. The is no 'HID Tickle' required for power-button wakes.

And for WOL the Wake Reason is of course '?'. The problem is it does not stay awake even if graphics are suppressed. It re-sleeps fast. Remote Desktop Wakes fail in a similar manner if this target is sleeping.

D_UMsgs_PB.tiff

KernelMsg_PB.tiff

 

In DS4P setup for the record, all manner of Wakes work in SnowLeopard, although the Wake Reason is left blank for power-button and WOL.

 

Another useful Macworld article. http://www.macworld.com/article/142468/200..._on_demand.html

Link to comment
Share on other sites

hey guys, i was playing a DSDT generated through mald0n's dsdt autopatcher as opposed to my own personally edited one, and came up with some uniquely different wake problems than before, which i found quite interesting.... 1 power button click, as opposed to waking without graphics and going back to sleep, instead woke up to a black screen w/ spinning beach ball and stayed awake, spinning indefinitely. also, 1 click of wireless trackpad the graphics were suppressed, but instead it did not go back to sleep.... the fans continued to spin... with an additional click it became stuck w/ the blue screen when graphics are initializing.

Link to comment
Share on other sites

  • 3 weeks later...

Yes, that's essential too. But we are dealing with something different here. The reason, why the Computer doesn't stay alive after PWR Button wake is that Lion doesn't recognize the Wake-Reason (Power Button), so it goes to sleep immediately again.

 

I guess there must be a way to fix this with DSDT. Can someone with working PWR Button wake post his DSDT please? Please post your "Wake reason:" from system log also after waking with PWR Button.

Link to comment
Share on other sites

I've tried looking around in DSDTs from other boards and Apple DSDTs as well, but I didn't find anything that seemed to make a difference. But again I'm not that experienced with DSDT editing...

 

Would be nice if we could get some help from some of the experts. This thing feels pretty much dead in the water, which is unfortunate, as it leaves many home built Macs without full functionality...

Link to comment
Share on other sites

  • 1 month later...

Has anyone else tried booting with the following kernel parameter:

 

darkwake=0

 

This looks like it switches off Low Power Wake entirely, i.e. reverting to Snow Leopard's behaviour which doesn't care about "wake reason" and the like. I can now wake my Lion box fully with a Wake-on-Lan app and the front power button (which didn't work before).

 

I just came across this in IOPMrootDomain.cpp in the latest XNU sources. It seems to be working for me so far (along with patched AppleRTC.kext). Running a GA-P55M-UD2 with DSDT from tonymacx86.

Link to comment
Share on other sites

Has anyone else tried booting with the following kernel parameter:

 

darkwake=0

@ianmc81

Your first post is a knock-out blow. Thanks for the good reading of the cpp and the great find!. Now I can give up looking at a solution to wake reason = ? for my DS4 setup.

Link to comment
Share on other sites

It's my pleasure, glad this is useful to others! I rely heavily on WOL and this was my final outstanding issue with my Lion install. So today I am a happy bunny.

 

Actually, if you get Wake on Demand (bonjour proxy) working, you will benefit from leaving darkwake=1!

 

The only reason you would like to keep darkwake=0 is if you rely on old-skool WoL packets.

 

If you get Wake on Demand/bonjour proxy working, it means that if you try and access your network drives through finder from second system, the first system will wake with the monitor turned off, but you can still browse files, or activate remote desktop. The system will stay awake as long as the network services are active.

 

The problem is getting Wake on Demand to work though, if you got a Realtek 8111C or the like.

 

I managed to recompile a version of mDNSResponder where Wake on Demand is permanently activated, regardless of what the system believes your driver supports.

Link to comment
Share on other sites

I do use Wake on Demand, and the darkwake=0 behaviour is still preferable to me as making SSH connections to my sleeping workstation didn't seem to be enough wake it up fully or "hold" it in low-power-wake. It seems not all network applications can do this even if they are Bonjour-advertised; I wasn't able to find any documentation on how this is done or why it works for some services and not others.

 

Lion's default behavior also broke wakeups using the iOS Remote.app for me, as sometimes the PC would go back to sleep before the app could fully connect to iTunes.

 

The problem is getting Wake on Demand to work though, if you got a Realtek 8111C or the like.

 

I managed to recompile a version of mDNSResponder where Wake on Demand is permanently activated, regardless of what the system believes your driver supports.

 

I used a similar method for some time, you will be pleased to hear there is a new version of the Realtek driver that has just been released that supports this natively:

 

http://lnx2mac.blogs...osx-driver.html

Link to comment
Share on other sites

I swear I checked the lnx2mac site yesterday with no version 0.90 being there. What the hell! Nice though!

 

Anyway, sounds like I should experiment some with ssh and iOS remote before I settle for which darkwake state to use.

 

Ultimately it would be nice to get a motherboard where the wake reasons are recognized! Doesn't seem like it will ever get fixed for the current gigabyte boards.

 

I'm buying Asus or Intel next time.

Link to comment
Share on other sites

I do use Wake on Demand, and the darkwake=0 behaviour is still preferable to me as making SSH connections to my sleeping workstation didn't seem to be enough wake it up fully or "hold" it in low-power-wake. It seems not all network applications can do this even if they are Bonjour-advertised; I wasn't able to find any documentation on how this is done or why it works for some services and not others.

 

I think the problem still is the fact that on some systems there is no wake reason for WoL.

 

Maybe it would be possible to recompile the "powerd" daemon with a hack that handles "wake reason:?" as if it were something else. Actually I think that would work quite nicely, the only problem is getting powerd to compile. It was a pain getting mDNSResponder to compile for me...

Link to comment
Share on other sites

I think the problem still is the fact that on some systems there is no wake reason for WoL.

 

I think there are a number of issues at play and I think some users of genuine Macs are unhappy with the way that Wake on Demand behaves with non-Apple network services (there are a number of complaints over on Macrumours about things like SSH and LogMeIn). I would be intrigued to know if the kernel param improves matters for them (not sure if you can even pass them on real macs?).

 

Maybe it would be possible to recompile the "powerd" daemon with a hack that handles "wake reason:?" as if it were something else. Actually I think that would work quite nicely, the only problem is getting powerd to compile. It was a pain getting mDNSResponder to compile for me...

 

When I started looking into this I thought powerd was to blame, now I actually think this whole mechanism lives within the kernel, but I could be wrong about this - am not a kernel guru. If you look in IOPMrootDomain.cpp in the latest XNU sources I think you should be able to find the logic for this by seeing where "darkwake" pops up. Maybe with some digging you could re-map the wake reasons at this level (or make them more broad) if you were so inclined. There are a number of guides out there describing how to get the XNU sources to build.

 

Personally, I'd rather just switch the whole thing off as that seems cleaner to me. I am not bothered if my monitor turns on every time I access some network service or other... it did on Snow Leopard and I managed OK then :-)

Link to comment
Share on other sites

I think there are a number of issues at play and I think some users of genuine Macs are unhappy with the way that Wake on Demand behaves with non-Apple network services (there are a number of complaints over on Macrumours about things like SSH and LogMeIn). I would be intrigued to know if the kernel param improves matters for them (not sure if you can even pass them on real macs?).

Could be true. Maybe it won't even stay awake when being accessed on real Macs. I might try and test if that is true.

 

When I started looking into this I thought powerd was to blame, now I actually think this whole mechanism lives within the kernel, but I could be wrong about this - am not a kernel guru. If you look in IOPMrootDomain.cpp in the latest XNU sources I think you should be able to find the logic for this by seeing where "darkwake" pops up. Maybe with some digging you could re-map the wake reasons at this level (or make them more broad) if you were so inclined. There are a number of guides out there describing how to get the XNU sources to build.

I'll look into the kernel sources and see what I can find. I've already managed to get XNU to build. I hardly have any C or hardware programming experience tho.

 

Personally, I'd rather just switch the whole thing off as that seems cleaner to me. I am not bothered if my monitor turns on every time I access some network service or other... it did on Snow Leopard and I managed OK then :-)

My selfbuilt Mac is in my bedroom, and the bonjour proxy wakes the Mac at some interval to keep the bonjour services updated. So I wouldn't mind if it was ultimately possible to get dark wake working perfectly. :)

Link to comment
Share on other sites

My selfbuilt Mac is in my bedroom, and the bonjour proxy wakes the Mac at some interval to keep the bonjour services updated. So I wouldn't mind if it was ultimately possible to get dark wake working perfectly. :(

 

Are you sure it makes a difference in that case? The wakeup every two hours to re-register is actually done with an RTC Alarm on your PC, not a WOL from your router (incidentally - these are logged with a correct "Wake reason = RTC Maintenance Alarm").

 

I'm not sure if I've actually *seen* my PC do this or just *heard* the fans spinning up for a few seconds, but I was pretty sure that this had always been a "dark wake" (even in Snow Leopard) and it didn't switch the monitor on. It definitely isn't up more than a second or two, so it doesn't bring the system fully awake. Maybe I will have to sit next to my sleeping computer for two hours today and observe it, to be sure about this :-)

Link to comment
Share on other sites

Thanks for the info in this thread folks, it fixed my "double tap" wake feature and allows WOL to work with Lnx2Mac's new driver.

 

I am still getting the occasional short wake due to the RTC Alarm, I assume it is supposed to do this though?

 

It would be great if eventually low power wake could be made to work correctly, if anyone wants it testing on different hardware let me know!

Link to comment
Share on other sites

 Share

×
×
  • Create New...