Ubuntu Hardware: Debugging Hard Problems
June 21, 2011 3 Comments
Some of the work done to enable Sandybridge Suspend (S3) and Hibernate(S4) showed how painful it can be to get hardware to do what it oughts to do! The problem arises when you find yourself with not many tools to debug what is going on, since your console and half of the OS functionality has already gone to sleep.
BIOS Vendors rely on the use of expensive JTAG debugging tools. While this is ok, it does not really allow for the community to participate and considerably increases the cost of enabling a system to work with Ubuntu.
Faced with this problem, the Hardware Enablement team at Canonical has set themselves the goal in Oneiric to create a “tool to analyze and suggest where suspend/resume is failing to help guide people through debug phase” i.e an automated version of Colin King.
The basic idea is going back to debugging basics: “Have you hit that print statement before dying?”. The problem is that you are trying to instrument a fairly complex part of the systems and you do not have a screen to print stuff to.
For the first problem, the team is trying an ready available open source solution: System tap. For the second problem, they are going old school: Audio and Light signals. Today most systems have speakers and a few LEDs to let you know one thousand irrelevant things that you can do with your keyboard. So why not put them to good use?
The blueprint goes beyond a simple “BEEP” when you hit your breakpoint :
We would need some hardware to record the lights/sound at a sensible speed:
- Have another PC record the audio and interpret it
- Leverage ham radio code already done to interpret sound
With some initial prototypes already floating around, I can’t wait to see what they deliver!