c_c wrote: > I was reading about the power consumption issues with WiFi, and so made a > small script to switch off WiFi containing > iwconfig eth0 txpower off
This is already implied by --wlan disable. > wmiconfig -i eth0 --wlan disable This is good as long as you make sure you never touch --power maxperf. If you want to be extra-careful, you would first issue wmiconfig -i eth0 --power rec > ifconfig eth0 down (probably don't need this) Only if you want to use interface removal/creation as a way to signal the upper layers that reconfiguration is needed. But see below for a better solution. > And last night I had an uninterrupted suspend from 22:51 to 05:53! Ah, nothing like a good night's sleep ;-) > 1. Were most of my wakeups because of WiFi? WLAN has a wakeup-on-WLAN (WoW) mechanism that could indeed cause wakeups. I've only noticed stray WoW interrupts while powering down, but it's not impossible that there's some yet to be explores problem. The kernel printk's "ar6000_wow interrupt" whenever such an interrupt is delivered, so you can easily check if they're causing problems. > I should have kept track of > the reason - but I didn't. Will do so now. But, Isn't WiFi supposed to be > off by default? This depends on how your kernel is configured and if user space is taking any actions. If we consider only the kernel itself and further assume that you're using one of the default configurations, then the module itself used to be powered up but unconfigured until recently. With this week's changes to andy-tracking (2.6.28), you still get the old behaviour if you build your kernel with gta02-moredrivers-defconfig. If you build it with gta02-packaging-defconfig, the WLAN driver is built as a module and thus inactive until user space decides to load it. > Top causes for wakeups: > 39.0% (204.0) <interrupt> : s3c-mci This comparably high interrupt rate is expected behaviour, as far as SDIO is concerned. What happens is that the SDIO stack polls the device periodically for pending interrupts, which involves sending a command over the bus each time, which in turn produces a completion interrupt on the host side. The stack does this seemingly foolish thing because the S3C MMC driver does not support handling SDIO interrupt as real interrupts. You can avoid all these complications by either using module removal or by unbinding the driver during a period in which you wish to minimize power consumption: cd /sys/bus/platform/drivers/s3c2440-sdi echo s3c2440-sdi >unbind To reactivate: echo s3c2440-sdi >bind This will, while unbound: - power down the module's function (not the module itself. Our hardware can't do that. But the remaining power consumption should be marginal.) - stop the SDIO stack's polling - remove the network interface (eth0) - signal the removal and - when re-binding - addition of the interface through netlink - lose all configuration of the network interface kept inside the kernel, including ESSID, IP address, and routes So you need user space to pick up the notification and configure the interface. Since the device may have moved to a different network while incommunicado, you usually wouldn't want to blindly reuse the previous settings anyway. - Werner
