I came across this link about a Virginia Tech professor that wrote a program to reduce energy wasted by computers. On the face of it, it sounds a bit smarter than the usual power management techniques that shut off parts or all of a computer when its not being used. It claims up to 30% reduction in power, which I expect translates into noticeably longer times between batter charges, if you use it on a laptop.

He also likens his software to cruise control in cars. But while cruise control will ease up on the accelerator as a car gathers speed when descending, it "doesn't look ahead and say, 'Hey, there's a hill coming,'" Cameron says. "It just reacts." In contrast, his program seeks out patterns to determine when a computer will need more power. He says users report electricity savings of 30 percent.

I expected the program, named Granola and distributed by miserware, to be a Windows only affair. However, its available for both Windows and various distributions of Linux. The latter likely a result of wanting to reduce server power usage, an area where Linux has a sizeable presence.  There is even a community supported, AUR package of Granola for ArchLinux. Joy!

When my 3 year old son pressed the sleep button on my keyboard, we discovered that it actually sends my Archlinux desktop to sleep. Who would have thunk it? What was more annoying is that when the machine woke up, the network connection did not come back.

Poking around in the log files, I saw lines like the following lines which lead me to believe it was a NetworkManager problem.

{style="width: 580px; overflow-x: scroll;"} Oct 26 09:12:30 grouch NetworkManager[14296]: (eth0): carrier now OFF (device state 70, deferring action for 4 seconds) Oct 26 09:12:31 grouch NetworkManager[14296]: (eth0): carrier now ON (device state 70) Oct 26 09:12:32 grouch NetworkManager[14296]: (eth0): carrier now OFF (device state 70, deferring action for 4 seconds) Oct 26 09:12:34 grouch NetworkManager[14296]: (eth0): carrier now ON (device state 70) Oct 26 09:12:50 grouch NetworkManager[14296]: (eth0): DHCPv4 request timed out. Oct 26 09:12:50 grouch NetworkManager[14296]: (eth0): canceled DHCP transaction, DHCP client pid 15506 Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 4 of 5 (IP4 Configure Timeout) scheduled... Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 4 of 5 (IP4 Configure Timeout) started... Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled... Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 4 of 5 (IP4 Configure Timeout) complete. Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 5 of 5 (IP Configure Commit) started... Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 5 of 5 (IP Configure Commit) failed (no IP configuration found) Oct 26 09:12:50 grouch NetworkManager[14296]: (eth0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5] Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) failed. Oct 26 09:12:50 grouch NetworkManager[14296]: Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete. Oct 26 09:12:50 grouch NetworkManager[14296]: (eth0): device state change: failed -> disconnected (reason 'none') [120 30 0] Oct 26 09:12:50 grouch NetworkManager[14296]: (eth0): deactivating device (reason 'none') [0]

After a lot of googling, it turns out that the problem was the kernel was using the wrong driver for the network card. First to find out which type of Realtek card you have use the following command:

lspci | grep Real

If you see the following, you need to update the driver loaded by the kernel to one provided by Realtek.

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

If you are using Archiinux, its as simple as installing the AUR package for the r8168 module. Using the package, the module downloaded and compiled fine for me, with the latest 3.0 Linux kernel.

yaourt -S r8168

Finally, reboot and you should still have a working network with the added bonus that it will automatically reconnect when resuming.

Earlier, I wrote about a way to import an exisiting git project into bitbucket. I\'ve since discovered a much easier way to do this using git\'s own commands. Instead of having to use git\'s daemon mode and have bitbucket import your repository, you should setup a new bitbucket repository and push to it. Assume you have a new repository, do the following two commands at your terminal. The key is the -u switch, which sets the master branch to track the remote repository.

git remote add origin git@bitbucket.org:user/newproject.git
git push -u git@bitbucket.org:user/newproject.git master:master

This blog serves as a good way to document what I learn.