Thursday, June 23, 2011

Ubuntu 11.04 slowness and high CPU usage

I noticed extremely high CPU usage on my ThinkPad X40 after upgrading from Ubuntu 10.10 to 11.04 a while back.  This rendered the laptop nearly unusable, heated the system up quite a bit, and kicked the fan on all the time.  This was with the Unity interface disabled (it doesn't work on my hardware anyway) and almost nothing of interest running.

A bit of searching revealed that many others have the same problem: there seems to be an issue with the 2.6.28 series kernel provided with 11.04.  I decided to try a newer kernel to see if the problem goes away without me having to troubleshoot further.  There are a number of ways to do this, but I added the kernel PPA and upgraded the kernel packages:

sudo add-apt-repository ppa:kernel-ppa/ppa
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install linux-image-generic linux-headers-generic

and then rebooted.  This gave me the 2.6.39-0-generic which runs much better: the system is nice and cool, CPU usage is quite low, the fan is barely on, and applications run normally.

Hopefully this helps someone out.  As before, it seems that little to no testing was done on a large range of popular hardware.

Update

I had another case of 100% CPU usage and this time it was due to a process, "upowerd" taking nearly 100% CPU.  I don't know how to resolve this one yet but you can get the system back to being usable by simply killing that daemon:

sudo killall upowerd

Friday, April 29, 2011

setting up the finger print reader on a ThinkPad with Ubuntu

This works fine on my ThinkPad X61s (SGS Thomson Microelectronics reader) with Ubuntu 11.04 (and should be the same on the previous few versions).

I like the finger print reader even though it's not particularly secure.  My take on this is that it saves me time and prevents people from seeing my password over my shoulder.  You'd still need need physical access to my laptop to break in, at which point all bets (including the password, finger print reader or not) are off anyway.

To enable the finger print reader, first, install the thinkfinger packages:

sudo apt-get install thinkfinger-tools libpam-thinkfinger

Use tf-tool to acquire a fingerprint for your user account:

sudo tftool --acquire

And tell PAM to use thinkfinger as an authentication option:

sudo apt-get install thinkfinger-tools libpam-thinkfinger

From there on out, a finger swipe will be sufficient for things like "sudo" on the shell or logging in.  It won't let you unlock a locked screen (if you need that, you have to set a few things up for xscreensaver).  If you have multiple users and they want to use the fingerprint reader, you need to repeat the "tf-tool" step per user.

Enjoy your finger print reader while you still can, a whole new mess is coming soon.

Sunday, February 13, 2011

button (or other GPIO pin) debouncing

GPIO pin de-bouncing is a fairly common task and there are many good ways to implement it.  Here's how I handle it on most projects, I think that it's fairly clean and easy to adapt to small microcontrollers or for use in Linux kernel drivers.

Each pin that needs to be sampled and debounced can be represented with a state machine comprised of a state, value, and counter.  A pin is either idle (whether pressed or released) or in transition to being pressed or released.  To transition to the idle state, the pin must maintain the same level for a number of counts.

A pin can therefore be represented something like:

enum pin_state {
        PIN_IDLE       = 0,
        PIN_PRESSING   = 1,
        PIN_RELEASING  = 2,
};

struct pin {
        enum pin_state state;
        char pressed;
        unsigned char debounce;
        unsigned char debounce_threshold;
};

I use three states but with the combination of 'state' and 'pressed' and 'debounce' we really have four real states (idle-pressed, idle-released, pressing, and releasing).

At initialization time, the pin structure(s) should be set to zero.  The 'pin' structure should also contain information about the pin to enable a routine to check its value (for example the GPIO port and pin number).  We then poll the pin or pins in a thread or main loop.  For example, to check just one pin:

static struct pin;

void init(void)
{
        memset(&pin, 0, sizeof(pin));
        /* pick some reasonable threshold, this is a
           factor of your circuit and polling
           frequency */
        pin.debounce_threshold = 10;
}

void check_pins(void)
{
        /* invert this if the pin is active-low, as is common
           for buttons, we treat a '1' as 'active' */
        char cur = gpio_get_pin_value();

        switch (pin.state) {
              case PIN_IDLE:
                     if (cur != pin.pressed) {
                            pin.state = cur ?
                                    PIN_PRESSING : PIN_RELEASING;
                     }
                     break;
              case PIN_PRESSING:
                     if (cur) {
                            pin.debounce++;
                     } else {
                            pin.debounce = 0;
                            pin.state = PIN_IDLE;
                     }
                     break;
              case PIN_RELEASING:
                     if (cur) {
                            pin.debounce = 0;
                            pin.state = PIN_IDLE;
                     } else {
                            pin.debounce++;
                     }
                     break;
       }

       if (pin.state > PIN_IDLE &&
                      pin.debounce > pin.debounce_threshold) {
              /* report the pin press or release */
              report_pin(cur);
              /* and now the pin is idle */
              pin.state = PIN_IDLE;
              pin.debounce = 0;
              pin.pressed = cur;
       }
}

If there are multiple pins to check then I would replace the single 'struct pin' with an array and loop over them. In that case 'struct pin' should contain pin port and pin number information for your implementation of  'gpio_get_pin_value()'.

Thursday, January 20, 2011

inspecting USB HID descriptors in Linux

It's sometimes necessary to see the complete USB HID descriptor for a device, including the report descriptor.  On Debian-based systems like Ubuntu, you can do this with "lsusb".

To see all of the information with the report descriptor you must:
  1. unbind the HID device in question
  2. run "lsusb -vvv" as root
To see a list of HID devices:

$ ls /sys/bus/usb/drivers/usbhid


For example, for the device 3-1:1.0 you can:

$ echo -n 6-1:1.0 | sudo tee -a /sys/bus/usb/drivers/usbhid/unbind
$ sudo lsusb -vvv