USB ehci_hcd woes

Posting to help the next person who runs into this problem and Googles for help.

I noticed that several log files in /var/log/ on my T400 running Ubuntu 10.04 were filling up with stuff like

... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 17 
... kernel: ... usb 2-4: device descriptor read/all, error -71 
... kernel: ... hub 2-0:1.0: unable to enumerate USB device on port 4 
... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 19 
... kernel: ... usb 2-4: device not accepting address 19, error -71 
... kernel: ... hub 2-0:1.0: unable to enumerate USB device on port 4 
... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 21 
... kernel: ... usb 2-4: device descriptor read/all, error -71 
... kernel: ... hub 2-0:1.0: unable to enumerate USB device on port 4 
... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 23 

And by ‘filling up’, I meant 10s of megabytes each, across several log files. And there wasn’t a USB device plugged in. (There’d been a thumb drive plugged in briefly before noticing the problem, but the log spewage continued after a cold restart.)

When I went digging for info, it sounded like this might be a problem with some USB device/chipset combinations. In my case, it’s probably a flakey USB chip.

To stop the spew, I added the following to /etc/rc.local

cd /sys/bus/pci/drivers/ehci_hcd
echo -n "0000:00:1d.7" > unbind
cd /sys/bus/pci/drivers/uhci_hcd
echo -n "0000:00:1d.1" > unbind

I unbound ehci_hcd and uhci_hcd because both were showing up in my logs. You might only need one. If you only need to unbind ehci_hcd, you’ll be downgrading the speed of that USB port, which may just be what you need to do to make things work. You’ll also need to adjust those numbers to correspond to how your drivers are numbered, which will be evident when you look at the files in /sys/bus/pci/drivers/*. Since unbind doesn’t survive a reboot, it’s a simple matter of

sudo tail -f /var/log/syslog

in one window while you try an echo in another to verify that the log spewage stops.

Good luck. There’s the chance that this is an entirely wrong thing to do, so caveat emptor.

Edited to add that’s a bug filed against this that makes for interesting reading.

Google App Engine SDK on Ubuntu 10.04

Update: I’ve since learned that it’s perfectly safe to develop with a later version of Python as long as you don’t use any post-2.5 language features or libraries. I’m now using 2.6.5 on Ubuntu, and things are working just fine. So what follows may be interesting, but it isn’t necessary.

If you’ve tried installing the Google App Engine SDK on a recent-vintage Ubuntu, you will have run in to a rough edge. The current GAE (1.4) requires Python 2.5, but Ubuntu 10.04 ships with Python 2.6 and doesn’t seem to know about earlier versions. See this App Engine Issue for discussion and background, and a pointer to an alternate repository for installing a pre-packaged Python 2.5.

I opted instead to build Python 2.5 from source. It wasn’t rocket surgery, but it wasn’t simple. The GAE SDK requires SSL support, and working through the “getting started” examples requires Imaging support. Here’s a simplified walk through of what I did, culled from shell history.
Continue reading “Google App Engine SDK on Ubuntu 10.04”

WordPress Plugin Hell

You’re going slowly mad wrestling with WordPress plugins. You might have gotten to this point by deciding to fancy up your own blog, or you might have volunteered to help a friend out with theirs. Either way, you’ve found yourself neck deep in sorting out some bizarre interactions between third-party plugins, and have been cursing both PHP and the lack of good PHP debugging tools.

And, you probably never read the documentation. Documentation? Yeah, that.

Here’s what you need:

The API doc lays out the theory of WordPress hooks, which’ll give you insight into the “how the heck did that get called, and from where?!?” question that you’ve probably been asking yourself. Much will become clearer. Then it’s a matter of having documentation for the hundreds of WordPress hooks within quick reach.

My Technology Radar for 2010

ThoughtWorks recently published their Technology Radar for 2010. I liked the format, and borrowed it to organize and prioritize my own Technology Radar.

Here’s where I plan to invest learning time this year.

My Tech Radar for 2010

1. I’m continuing to actively explore how non-trivial relational data models can be mapped on to distributed data stores. I’ve seen relational databases pushed to their limits, and need to look beyond that. There’s a gap. The non-relational (e.g., NoSQL) work I’ve seen so far hasn’t gotten beyond simple data models. What do do about large, transactional schemas remains a puzzle worth investigating.

If this moves from ‘assess’ to ‘trial’, it’ll probably involve Google’s Big Table, by way of Google App Engine.

2. When building web apps, making them look good is my weak point. It’s time to get better. That means some deliberate design experiments and exercise time with CSS, followed by cleaning up the UI on a Google App Engine hack from last year.

3. I’ve been using git as a CVS/Subversion replacement, and not much more. It’s time now to get serious and master the rest of git, and to level up by branch fu.

4. Some of the data analysis problems that I run into could benefit from a good statistics package. R seems like a useful tool to get acquainted with. I can see this getting bumped from ‘assess’ to ‘trial’.

5. The Silicon Valley Patterns Group’s current track is on Haskell. So far, it’s been mind-bending in the same way that Smalltalk was on first encounter. There’s depth to Haskell that’s worth experimenting with, though I don’t yet see using Haskell for production work.

6. Colleagues are doing some very cool stuff with Clojure, a LISP for the JVM. My plate is too full to be spending time with Clojure right now, so it’s on the radar as a hold.

7. Arduino is there for the fun of building something tangible, and for the opportunity to re-learn some basic Electronics. This is a hold-over from last year, and is the most likely thing to remain undone at the end of this year.

As with any plan, this will likely be completely upended by year-end.

The View From Jerry’s Shoulders

In the software community, when we speak of the giants on whose shoulders we aspire to perch, names like Turing, Dijkstra, Wirth, and Knuth are often mentioned–names associated with the Computer Science side of software development. And there are giants on the hardware side: Von Neumann, and, if you want to go a lot farther back, Babbage.

There’s also a side of software development that doesn’t get enough attention, but is nonetheless critically important: The side that’s about people. Until some distant future when software development is fully automated, it will remain an endeavor that includes humans. And, by extension, our imperfections and foibles.

One of the giants on the people side of software is Gerald M. (Jerry) Weinberg. If you’re not familiar with Jerry’s writings, I envy the discoveries you have ahead.

Full disclosure: I’ve been a student of Jerry’s for many years, first through his books, then through his workshops, and finally through working with him on the AYE Conference. His teachings, wisdom, and subtle wit have had a profound impact on my career and life.

Where to start reading Weinberg depends on where you are in your career.

I came to know of Jerry’s work through the chance discovery of The Psychology of Computer Programming, a book that introduced many to the idea that there’s much more to programming than languages and algorithms. It’s a timeless book; human nature evolves much slower than technology. This is where I learned about ‘goal displacement’, which you’ve seen if you’ve ever been puzzled why it’s become more important to some developer that a system runs fast than it is that it works right. I’m not sure this book is the best place to start if you haven’t read Weinberg, but do read it at some point.

If you’re just starting out, Becoming a Technical Leader is full of excellent advise for planning and managing the external and internal aspects of your career. The idea that there’s internal stuff to be managed is a surprise to some, but if you’re going to be a leader, you’re going to have to learn to cope with a whole range of emotions, including frustration, anger, and hopefully elation. It’s worth re-reading every five years or so, if only to see how far you’ve come. This is the book that I gave away the most copies of when I was a manager.

If you’re a bit further along, Are Your Lights On? How to Figure Out What the Problem Really Is (with Don Gause) can help you avoid solving the wrong problems. Exploring Requirements: Quality Before Design will change the way you look at requirements. Though both were written before Agile, both still apply, since much can be lost in imperfect communication between customers and developers. The perils of mind reading remain even when there’s a Product Owner colocated with the team.

If you aspire to lead projects, any or all of Jerry’s four volume “Quality Software Management” series are a great investment. Volume 1, Systems Thinking, is one of the best introductions to a this very powerful technique that I’ve found (Senge’s The Fifth Discipline being the other). Volume 3, Congruent Action is especially good if your career path leads to management. It’s all about dealing with people effectively.

If you consult or advise for a living, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, about the external aspects of consulting, is full of deep and useful advice. If you use the services of consultants, this book can help you get more value out of that relationship.

Perfect Software: And Other Illusions about Testing is in my reading queue, so I can’t recommend it yet, but a friend who has read it left the better part of a pad of sticky notes in his copy of the book.

Finally, Weinberg on Writing: The Fieldstone Method has some very good advice on writing for those of us technical folk who have to squeeze writing in to small blocks of time. You won’t find the writing techniques that you were given in school, and may wish that you’d had Jerry’s book instead.

That should be enough to get you started. Your next step is to pick one to add to your reading queue.

Since it’s pretty clear that I’m biased about Jerry’s work, check out the reviews of Jerry’s books on

Finding Boundaries

Re-reading Martin Fowler’s writeup on rake, Using the Rake Build Language, I found this buried gem:

Often when you come across something new it can be a good idea to overuse it in order to find out it’s boundaries. This is a quite reasonable learning strategy. It’s also why people always tend to overuse new technologies or techniques in the early days. People often criticize this but it’s a natural part of learning. If you don’t push something beyond its boundary of usefulness how do you find where that boundary is? The important thing is to do so in a relatively controlled environment so you can fix things when you find the boundary.

Two thoughts:

First, I’m not doing enough pushing of boundaries when playing with new things, tending instead to test-drive new technologies “on road” rather than off. Solving familiar problems in familiar ways but with a new tool is a good way to get a feeling for the tool, but it shortchanges learning. Perhaps I’ve let the set of problems I’m tackling become too narrow.

The second thought is that “a relatively controlled environment” is both key and often ignored. I’ve seen plenty of examples of people overusing new technologies in production code bases. If that’s you, please get yourself a side project to experiment in. Finding a science experiment buried in a code base can cause a major headache. There’s a time and a place for boundary-pushing experiments.