Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

I use "wheezy" latest release. The device provides some web service features and supposes to be active 24/7. However if the server wasn't requested for certain amount of time (it is hard to tell exact time), the device seems going to sleep (hopefully not crash). The device connected to net using wi-fi dongle. I found some answers here that a reason of device freezing can be that wi-fi card is going in economy mode, so I followed the instructions and can confirm that the dongle doesn't go in sleep but it starts blinking like getting not attended from computer. it means that device still goes in sleep although wi-fi is awake. The solution as buy another raspberry pi and make it all time pinging sleeping one doesn't work since only being a server getting requests prevent device going to sleep. Trying to poll something from the device doesn't prevent going in sleep mode. I can't actually confirm that device going to sleep. I do not have monitor or keyboard attached, and attempt to attach something issues rebooting of the device. So I am currently out of clues what can issue the behavior. And yes, I applied all remedies preventing OS crashes as no turbo and increased minimal VM memory size.

share|improve this question
    
is there anything in /var/log files that shows something is happening, going to sleep, device powering down? –  kolin Jan 31 '13 at 10:14
2  
For posterity, please note that the pi hardware does not have a potential sleep, suspend, etc. mode. It is either running, or not. If it is plugged in, the power LED will be on either way. –  goldilocks Feb 13 '13 at 14:54
    
Its not just your wi-fi dongle. I have mine connected through its Ethernet port to serve web requests and it "falls asleep" (or something close to this state) after some time and wont serve requests anymore. If I hit some keys to wake it up it starts working again. But its a pain because the only time I need it to serve requests is when I'm not there to wake it up. –  user7335 May 10 '13 at 2:44
    
I have had this problem of the Pi apparently going to sleep. I can happen every few minutes and can last for about 20 seconds. It is evident when I am trying to access a file via Samba share or when I am SSHing into the Pi - everything just stops. I thought that it might be the Pi that was under load so I ran 'top'. There was no evidence of heavy loading. However, I found that while running 'top', the Pi worked perfectly. Access to files was snappy and SSH connections experienced no outage. So, I can't say what causes this problem but it is not heavy demands on the CPU, on the contrary, the Pi –  Brian Feb 22 at 20:37

8 Answers 8

Something is wrong. The pi does not have a "sleep mode".

I've only had my pi a few weeks and have not left it on the whole time, but I intend to eventually and I have left it on for some long stretches. I'm running raspbian, and I have a personal dislike for NetworkManager, lol, so that is disabled. To keep the wifi up, I run a script which pings the router every five seconds. If the ping fails, it kills the current dhcpcd and tries to set up the wifi again every 5 seconds until it succeeds. It logs attempts, and in fact has been up for over 24 hours now without needing to reconnect once, and when I go to ssh in, no problems.

You've already said,"Trying to poll something from the device doesn't prevent going in sleep mode," so my point here is just that mine obviously doesn't have this problem, so something is wrong.

You say it is going "to sleep" but it sounds like you are actually having to reboot. Why do you believe it is sleeping? AFAICT, the pi cannot go to sleep, it does not have any such capability. Googling around, there seems to be some confusion about this from people who are having problems like yours.

Keep in mind that there is a red LED that stays on whenever power is connected, whether the pi is running or not. But the pi is either booted and running or halted, it does not have a sleep, standby, hibernated, etc. mode.

So your pi has either crashed, halted, or is in some kind of erroneous frozen state. Feel to see if it is more than slightly warm, which would indicate the processor is in a perpetual busy loop (one reason it might be on but unresponsive).

I'm guessing that one reason you believe it is sleeping is that an "attempt to attach something issues rebooting of the device". That can happen when the device is completely halted (try it); it's because some devices will cause a brief voltage drop (but see NOTE) when first plugged in, which amounts to unplugging the pi then plugging it back in again -- which as you know, plugging it in causes it to boot. My nano size wifi dongle will do this.

NOTE: Actually our pi were probably made since last august, when the polyfuses were replaced with "shorts" -- I know very little about electronic components or electricity, but evidently the issue WRT to rebooting from usb devices remains the same.

share|improve this answer

It sounds like your wifi dongle starts pulsing like a laptop in standby mode, but you haven't confirmed that the Pi itself is shutting down. I experience the same issue.

I've tried this, but haven't had it applied long enough to know if it solved my specific issue: http://raspberrypi.stackexchange.com/a/4518/4271

share|improve this answer

I'd check for power issues. Attaching devices causing RPI to reboot does not look related to any sort of sleeping mode.

As a quick test, I'd do this - write a small script (python/shall, whatever is handier) and make it send a simple "I am good" email and put it into your crontab to execute every 30 minutes or so and see how it goes.

share|improve this answer

I used simple steps and it perfectly worked for me:

  1. Open a root terminal in raspberry Pi. Now you need to edit your script that's starting X. In the default build with lightdm.

  2. Open "lightdm.conf" file located in,

    /etc/lightdm/lightdm.conf

  3. Add below line in to SeatDefault section.

    [SeatDefaults]

    xserver-command=X -s 0 -dpms

  4. Restart your Raspberry Pi.

Now issue should be solved.

Source link: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html

share|improve this answer
    
Welcome to Stack Exchange. Here we expect answers to stand on their own, instead of just being links to external sources. If you can add the relevant information into your answer then it will be much better. –  Jivings Mar 29 '13 at 17:21
    
Please add the information that is on that site: links are not acceptable answers. –  xxmbabanexx Mar 30 '13 at 5:48

I wonder if I am experiencing something similar. I would be interested in the chip set your dongle has and the driver you are using?

I have one based on RT3072 chip using the rt2800usb / cfg80211 driver. If I run this in either Master Mode ie an Access Point, or as a normal client to an Access Point/router, it appears as if it goes to sleep and takes a while to respond. I set up my laptop to ping the pi through the wifi adapter at roughly 1 second intervals. I confirmed that in both master and client mode, at times the ping would time out ~ 5-10 seconds in client mode and 5 - 25 seconds in Master mode. In master mode, the timeouts were made a lot worse if I ran the AP in 'n mode' with HT and WMM enabled in hostapd.conf. It was no where near as bad in 'g mode'.

I experimented with another wifi dongle using the RTL8188SU chip with r8712u staging driver. Unfortunately, I could not get this running in Master mode but as a client, it was much more stable than the RT3072 one.

With the 3072 in client mode there was no typical ping delay - they were random from 2ms - 320ms with an occasional timeout. With 8188SU, the typical ping delay was 2-3ms with an occasional delay 166-200ms delay - no observable timeouts. What was particularly strange was that if I opened an ssh session to the pi and set top running at 0.01 sec - so there was quite a lot of cpu load and a 'lot' of wifi traffic, the performance of the 3072 was greatly improved with ping times typically 2-3ms. The loading had a similar effect on the 3072 working in Master mode.

I don't know what is going on but I would be most interested if other users could take the time to do a similar ping test on their pi and report their findings along with their configuration and drivers. It would be interesting if others find poor and random response times are improved by loading the processor/ wifi traffic using top as I did, or say find anything that creates some work and tcp/ip traffic over the wifi.

share|improve this answer
    
This isn't really an answer, however it has sufficently detailed content that probably wouldn't fit in the comments section of the original question –  kolin Feb 13 '13 at 9:30
    
Thanks for the hint kolin - I'm new to this forum and haven't figured everything out yet! –  Ivo Feb 13 '13 at 19:46
    
I tried implementing Stefans answer - turning off power management (for cfg80211/mac80211 drivers you can use iw wlan0 set power_save off), and it made a very big difference in the client mode - random ping delays are now fairly steady at 2-3ms and no timeouts yet. This has not helped with the AP mode (power_save off is not an option with my device), but I don't think it is the source of the problem in AP mode as the ping times are generally stable anyway. Something else is causing the timeouts. It is not clear whether the configuration in the original question was for client or AP mode. –  Ivo Feb 14 '13 at 4:42

While I do agree with @goldilocks about the pi device not having a sleep function, the kernel can still powerdown specific I/O while the device is running. It is through this reasoning that you may want to try the following edit in the KBD files and reboot the device:

Make the following edit in /etc/kbd/config: POWERDOWN_TIME=0

share|improve this answer

Just for information, I had this issue so looked for a solution here and found this question.

However later on I found out it was just my Pi overheating by the looks of things. Once I took it out of its case. The problem appears to have dissapeared

share|improve this answer

For me it worked by editing /etc/X11/xinit/xserverrc and changing

exec /usr/bin/X -nolisten tcp "$@"

by

exec /usr/bin/X -s 0 dpms -nolisten tcp "$@"

I'm using Raspbian “wheezy” and I start my X session with startx.

Source: http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=18200

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.