What's Chris been doing?

lcfg-sleep has finally been deployed! I’ve put it on all our Student lab machines. It’ll only actually do anything on the new HP 7900s of course. There are several dozen of them in our student labs, so the sleep component will soon begin to earn its keep at last. There’s a big autoreboot due to happen tonight to install a new kernel, and the sleep component should start working after that reboot.

I realised this morning that the component still had an alarming flaw related to autoreboot: although it wakes the machine automatically when it’s time to run the autoreboot component (as it’s kicked off by a cron job), and although it prevents the machine from sleeping once the autoreboot component has started a shutdown command to reboot the machine (I added a sleep test for this), I had forgotten the middle step: autoreboot kicks off the shutdown command from an at job, and I had neglected to tell sleep to refrain from suspending the machine if there was anything in the “at” queue. I’ve never really used “at”, so I don’t tend to think of it much, but the “at” queue is so fundamental that I should really go back and make the sleep component examine the queue properly when assessing a machine’s sleep-worthiness. For the moment I’ve put in a stop-gap extra sleep test which simply vetoes sleep when there’s anything in the “at” queue.

While I was away on a week’s holiday I left a small lab full of Dell GX745 machines testing lcfg-sleep. When I came back I found that half of them had frozen at suspend-time. This has been happening on and off for months and really I’m no nearer to curing the problem. By contrast, the few new HP dc7900s that have been running lcfg-sleep have been as good as gold, suspending and resuming several times a day quite happily, waking up perfectly well both automatically and on a press of the power button – no problems there.

Since effort is short and I’ve been bashing my head against the Dell problems for far too long now, and I’m utterly sick of it, I’ve now disabled sleep on the final two remaining Dell models it was operating on, the GX745 and the 755. The only supported model is therefore the HP dc7900. Happily this is the PC du jour and we’re deploying a lot of them in the student labs right now, so if things go well in my wee HP sleep test lab we can fairly rapidly spread lcfg-sleep to the rest of the student lab HPs. A few months after that, if things seem as reliable as I hope they will, we could perhaps think of spreading lcfg-sleep to HPs in offices too. After all the original point of the project was to cut the Forum’s electricity bill, and the Forum has no student labs.

This isn’t necessarily the end for the hopes of automatic sleep on the Dells. I may well go back and test sleep on a Dell from time to time, or even fix the problem if inspiration strikes, but I won’t spend much more effort on it at the moment: there are more important things to be getting on with.

Less than 24 hours after I enabled it on six Dell 745s, three of them have given up the ghost. Not permanently I suppose (I haven’t physically checked them yet) but they’ve certainly failed to wake up: all three went to sleep just after 1pm yesterday and have failed to communicate with the profile server since then. The other three machines seem fine – they woke up yesterday evening and downloaded new profiles, then last night, then most recently this morning between 8am and 9am.

Also, my own test 745, which went through an accelerated test of hundreds of sleep cycles thanks to my rather cruelly giving it a maximum sleep period of three minutes, yesterday hung rather than wake up. After I’d manually rebooted it and it had slept perfectly happily a number of times more, it then repeated the trick last night shortly after 8pm.

So, to do:

• boot the benighted machines single-user and save copies of whatever they managed to log before freezing
• remove lcfg-sleep from the lab machines (edit: I’m leaving it to run for longer. Nobody uses those machines anyway.)
• rethink the supported models (currently Dell 745, 755 and new HP 7900).

On the last point I’m now wondering whether Dells are just too crappy and unreliable to be trusted with power management at all? The HP has behaved flawlessly – but then, it hasn’t gone through as many sleep cycles as my own test Dell 745, so who knows how it’ll work out. IS seem to manage, but not with Linux, they have to boot the machines into Windows to sleep them – and Windows has traditionally had its hardware support designed specifically around the shortcomings and unreliability of whatever’s provided by the hardware vendors.

I think I’m going to have to arrange a mass HP 7900 sleep test somehow.
There’s still the possibility of getting 755s to behave reliably, and I’ll work on that, but it seems unlikely to succeed.

TiBS LCFG development has temporarily stopped while I take care of some operational matters:

• moving the DIY DICE service to a dedicated machine to simplify admin – and configuring and installing the machine
• decommissioning the fc5 build host (not that this took a great deal of time)
• tidying up a pile of machines that were lurking under my desk
• looking into ways of making the office habitable
• satisfying various bureaucracies
• Investigating a bizarre case of intermittent narcolepsy in my main desktop. I don’t think it’s LCFG-related, I’ve misconfigured Gnome power management somehow.

I’ve also set up a new HP dc7900 and tested it for compatibility with lcfg-sleep. Good news: it’s now supported, or it will be when today’s changes hit the stable release. For the record it appeared to suspend and resume happily when no quirks were used, but a subsequent gnome login would pop up a “something went wrong with your resume” warning, and on logout the whole machine would freeze solid – lovely. Thankfully this behaviour goes away and the machine seems as good as gold when slept with the VBE Post sleep quirk, so that’s what LCFG will now do.