Total Pageviews

Thursday, 15 September 2011

ER1401 and OpenElec Standby Fix

Ok, so took some reading and exploring to fix this one but it's actually relatively straight forward to fix. I actually don't use the standby/suspend feature that much because I'm a bit of a hippy and would rather it was just off. However it annoyed me that it didn't work.

What was the problem?


Well after loading XBMC on OpenElec, going to Shutdown then to the submenu for Suspend, the screen would go blank but would return within seconds. I had seen this problem before on other Linux based OS's but never got around to understanding why this was happening or investigating a fix.

If you want the fix without the background, go to the bottom of this article :-)

Well for others, here it is along with some additional information that might help. These steps might also assist folk with other Linux based OS's, but of course, no guarantee's, it all comes down to playing around with settings and seeing what happens.


  • Log files to monitor during testing
    • /var/log/messages
      • This log file stores messages logged by all parts of the OS including applications (most commonly referred to as syslog messages). However not all messages are stored here and some applications specifically log messages elsewhere. You will see some messages during Suspend appear here, but for the most part, they won't help. But always worth checking.
    • /storage/.xbmc/temp/xbmc.log
      • This is the XBMC log file. It's normally deleted during the start of each boot but not between suspend sessions. It has more information on whats going on during an attempted suspend however still not enough to indicate what might be causing problems. It may help you if for instance something within XBMC is causing problems with the suspend.
    • dmesg
      • Most likely though it's a device which is keeping your system from going into standby, so monitoring the output of dmesg is key. It should tell you what device is requesting the suspend and which is requesting the resume.
So with some log files to monitor, I could see that my requests from my IR Remote Control via a Microsoft IR Receiver were being accepted and putting the device to sleep, however for some reason another device was waking my ER1401 straight away. Strangely enough this device appears to be USB based however is not one which is plugged into one of the external ports (I only have one and it's the remote control IR reciever)

Based on this information alone, it was time to start disabling devices abilities to resume or wake the system from Suspend (S3 Mode).

You can see what devices have this ability from the output from cat /proc/acpi/wakeup:

root ~/.xbmc/temp # cat /proc/acpi/wakeup 
Device S-state  Status   Sysfs node
SMB0  S4 *disabled  pci:0000:00:01.1
US15  S4 *disabled  pci:0000:00:04.0
US12  S3 *enabled   pci:0000:00:04.1
NMAC  S5 *enabled   pci:0000:00:0a.0
P0P1  S4 *disabled  pci:0000:00:08.0
HDAC  S4 *disabled  pci:0000:00:07.0
MXR0  S4 *disabled  pci:0000:00:10.0
BR11  S4 *disabled  
BR12  S4 *disabled  pci:0000:00:12.0
BR13  S4 *disabled  
BR14  S4 *disabled  
BR15  S4 *disabled  
BR16  S4 *disabled  
BR17  S4 *disabled  
USB0  S3 *enabled   pci:0000:00:02.0
USB2  S3 *disabled  pci:0000:00:02.1


This is the output for a ER1401, please keep this in mind, if you are reading this and have a different hardware setup, this will look completely different.

You can find out which devices these are from the output of lspci:

00:00.0 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.2 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:01.3 Co-processor: nVidia Corporation MCP78S [GeForce 8200] Co-Processor (rev a2)
00:01.4 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1)
00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] SATA Controller (non-AHCI mode) (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation MCP77 Ethernet (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:12.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce 8200] (rev a2)
04:00.0 Network controller: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe

After disabling different ones I found that US12 was causing the problems:

00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)

To disable this specific device and fix the suspend issues, execute the following command:

echo US12 > /proc/acpi/wakeup

This will then set US12 to disabled in /proc/acpi/wakeup. Go ahead and try to suspend and this will now work as expected. If you have Wake On Lan configured or a remote control, you can now wake up the device also using these methods.

Note this fix is not permanent and has to be applied on each cold boot. If you are using OpenElec RC5 then sadly there is no automated way to apply this fix. You could like I did set button 0 on your remote (if you have one) to execute a python script which applies this. Or if you are brave enough, get the latest development build version of OpenElec and put this command into a shell script in /storage/.config/autostart.sh. It will then execute every time you boot and apply the fix.

Other sources which helped me investigate this:


If you have any questions I'll do my best to assist, but always best to check with the guys over at the OpenElec forum first.