Debugging Suspend Resume: Difference between revisions
(New page: There are a number of features built into Open Firmware and the OLPC Linux kernel which aid in debugging suspend/resume problems. =Wake on Broadcast= =NVRAM Logging= The XO provides a...) |
|||
Line 3: | Line 3: | ||
=Wake on Broadcast= |
=Wake on Broadcast= |
||
The ability to control which network packets wake up the machine is available in more recent OLPC stable branch kernels (later than 1114). In these kernels, you enable network wakeup by writing a bit field to <tt>/sys/module/usb8xxx/parameters/wakeup</tt>. The values in the bit field are: |
|||
0 - no wakeup |
|||
1 - wake on broadcast |
|||
2 - wake on unicast addressed to this laptop |
|||
3 - wake on unicast addressed to this laptop or broadcast |
|||
4 - wake on '''mac event''' |
|||
Thus in order to wake out of suspend on packets addressed to this laptop as well as broadcast, you |
|||
can add a line like the following to <tt>/etc/rc.local</tt>: |
|||
echo 3 > /sys/module/usb8xxx/parameters/wakeup |
|||
You can read this file to determine the current wakeup events. |
|||
There is a neater way to do this with udev rules... |
|||
=NVRAM Logging= |
=NVRAM Logging= |
Revision as of 07:05, 16 November 2007
There are a number of features built into Open Firmware and the OLPC Linux kernel which aid in debugging suspend/resume problems.
Wake on Broadcast
The ability to control which network packets wake up the machine is available in more recent OLPC stable branch kernels (later than 1114). In these kernels, you enable network wakeup by writing a bit field to /sys/module/usb8xxx/parameters/wakeup. The values in the bit field are:
0 - no wakeup 1 - wake on broadcast 2 - wake on unicast addressed to this laptop 3 - wake on unicast addressed to this laptop or broadcast 4 - wake on mac event
Thus in order to wake out of suspend on packets addressed to this laptop as well as broadcast, you can add a line like the following to /etc/rc.local:
echo 3 > /sys/module/usb8xxx/parameters/wakeup
You can read this file to determine the current wakeup events. There is a neater way to do this with udev rules...
NVRAM Logging
The XO provides a small amount of nonvolatile RAM. Some of this is used to implement the real time clock, but around 48 bytes are available for debugging use. Some of these values are
Accessing NVRAM from Open Firmware
Accessing NVRAM from Linux
Suspend/Resume Counter
POST Codes
Codes 1n are in the 32-bit ROM-executed code that turns on the memory controller Codes 2n are in the RAM-resident code that restores the system state on a resume.
The CMOS location is 0x34, accessed from OFW with:
ok 34 cmos@ .
From Linux, using /dev/nvram, the seek offset is 0x26. That location does not conflict with the locations that the suspend/resume counter uses.
The codes are only written to CMOS RAM if the firmware thinks that it is a resume wakeup, so that a cold reset won't overwrite them.
CMOS location 0x34 (/dev/nvram offset 0x26)
Auto Wakeup
This currently assumes version q2037.rom (or something later than q2d04f.rom ?)
The EC currently masks SCI events (wakeups) from being generated for 32 mS after the operational power is turned off. This allows the circuits to completely settle before being restarted. It may be programmed to always generate an SCI interrupt at the end of this masking period, causing an auto-wakeup.
The autowakeup period is set using:
wackme wbsplit f64d ec! f64e ec! <value> wackme