On the other hand, we have “Enterprise” types who install something to solve a problem, and then have to pay real, tangible, money to upgrade/change. Testing costs money and takes time (and I mean of the non-throw it over the wall and hope – but hey, it’s new so it must be better and worth breakage, right?), and if it aint broke, why fix it? Seriously. If an older version of a Linux distribution with an older kernel works for you, and you can still get essential security fixes, then great. More power to you. This is where Open Source should be offering a compelling choice not to upgrade, if you don’t want to. Incidentally, that’s the reason you don’t see updates for lots of older embedded gadgets – as I pointed out at Linux Symposium when explaining how the average (non-geek) consumer doesn’t necessarily “need” Android 2.2 the moment it is first built in beta. Doing an OTA upgrade for something that already works introduces the risk of bricking many units and incurring cost. It doesn’t mean it’s not fun to upgrade your phone to the latest Android test build, or that some manufacturers won’t choose to do it as a value-add, but it does means it’s something you can do on your own dime. If it breaks because they upgraded it for you, they pay. If it breaks because you couldn’t leave it alone, it’s your fault. Keep both pieces.

I used to fall more into the camp of wanting the latest and greatest on every machine. Back when I enjoyed spending a weekend configuring APS to make my printer work with just the most ultra-pointlessly geeky layout for text files sent to lpr, I enjoyed re-installing, upgrading, and generally playing around. After all, this was before I really finally realized there is more to life than computers all the time. Over time, like many others, I grew up and realized that some things which work can appropriately be left alone without the universe exploding. Sure, we don’t want 40-year-old unmaintainable software disasters driving our government infrastructure of tomorrow, but there’s a medium somewhere in there too. I hope that, as the Open Source community matures, more people will come to appreciate this fact. By all means develop using the latest and greatest, but spare a thought for accepting that not everyone out there in the user community is as excited about wasting a day/weekend doing an upgrade unless or until they have to.

Jon.

This weekend, I’ve gone over all of the recent models and public announcements, read some IDF bits, and learned about Intel’s QPI (as opposed to the one I knew, AMD HT – QPI is basically trying to throw off the FSB, but it does some nice failover things HT does not include AFAIK). I’ve concluded that the model numbers used by these guys these days are way, way too confusing. Even more so than when I last really cared about this stuff – determining which “Xeon” has Intel-VT or AMD-V is a game of looking up lots of 4 digit model numbers where a simple naming formula somehow including reference to the microarchitecture used in the model “name” would suffice to convey far more useful information). But, none of this stuff is your grandfather’s x86. It’s every bit as capable (in x86-64 anyway) of taking on the other Big Endian arches I have always personally preferred.

I expect to do a lot more to keep up with x86 development rather than letting my own personal academic fondness for cleaner ISAs limit my exposure. I’m thinking about getting another older Xeon build/test box for playing with x86 stuff and for speeding up kernel compiles at home – perhals a used Dell PE1950 or Precision 490 as these have the best bang for buck ratio at the moment. What I would like to know, from anyone who bothered to read this far, is where should I be going to get the very latest information on x86 developments? I’m on the k.o lists, and I am specifically not a game playing weenie who cares about that stuff – I want to know about roadmaps, things like the new AES extensions, etc. I don’t care that the “whizzbang X1234 blah blah would look uber l33t in this plexiglass case I just bought on eBay”.

Jon.

Traditionally, I have used a (somewhat loud, and sometimes therefore unfortunately annoying) PC attached to my debugging target via a serial crossover cable. Actually, it’s the inverse of the usual setup in which said other PC is intended to be the target of experimental test kernels, with my desktop generally not being anticipated to fall over with kernel bugs (as it has been doing increasingly of late). In any case, it’s not optimal to leave that PC running and I prefer it being used for evil test experiments. An opportunity to buy random crap on eBay presented itself in the form of an awesome Cyclades (now some other random company) terminal server. I bought a TS-3000 for $115, which is less than a tenth of what they used to go for retail. 48 ports of serial terminal server goodness for the home.

Photo: My Cyclades TS-3000 sitting atop an APC Masterswitch Plus

I was never very good at waiting for santa. I was tracking this damned thing several times a day for the two days it was in transit. And when it arrived – shock! – it might not have the latest firmware! Quick! Time to fix that. I hadn’t even used it in anger before I managed to brick the thing with an update not intended for this model. Cursing myself, I figured I would just rescue it via TFTP. But that requires a special console cable (not quite the same as some others) in order to interrupt the standard boot. Obviously I had none of these cables, and all of the ones here were useless. And I wasn’t prepared to wait ten minutes to order another one. So I went to Microcenter, and bought two RJ45-DB9 generic converters you can click together to wire yourself.

I followed a diagram online to make the RJ45-DB9 cable for the Cyclades – twice. But all of the posted diagrams were incorrect (this is nothing like a Cisco cable, even if you’re a moron and think that it is when you incorrectly make a website with the wrong pinouts, especially if you’re Cyclades and write a manual with the wrong information contained within it…thanks a bunch!). Not to be discouraged, the soldering iron came out, and I rummaged around in a box of parts to find some serial connectors. Fortunately, I had a female DB9 and plenty of old crappyish network cables. I soldered, desoldered, and resoldered this thing about 4 times before finding the correct Cyclades console cable pinout (ADB0036 female DB9) (repeated below, for the benefit of others who read this). Finally, I reflashed the unit with the same firmware it had had when it arrived (zImage_ts_140-3.bin) – the “new” firmware was only for specific other units of which mine was not one thereof, there is a newer “GPL” kit I will poke at sometime – and booted it up.

Photo: A homebrew Cyclades ADB0036 Cable

Figure: The correct pinout for a Cyclades ADB0036 console cable (RJ45 to Female DB9 connector)

Cyclades made good (fanless) hardware, but they were hardly the most adept at making configuration straightforward. Sure, you can configure the network easily (this one is called “morse” after the inventor – in the US – of the coding used for telegraphs, which are an ancient precursor to the RS232 standard used on modern serial ports), but when it comes to the port setup…what you want to know is that you’re looking for the “Socket SSH” option, set to increment (e.g. from “1″ – no need to use the “7001″ example, you’re not directly sshing into the port anyway, as with telnet), and based upon a simple “CAS profile” with local authentication (make sure you add a new “system” user for those SSH logins), unless you want to use RADIUS (I have home KRB5, but haven’t deployed RADIUS at the moment). Always make sure you “Run Configuration” before flashing – it seems the former writes to the actual config files that the latter will use, so you cannot necessarily flash and then “Run Configuration” that way around, depending upon the particular operation you are performing.

Once you have the terminal server running, you can talk to it:

$ ssh user_name:port_number@terminal_server.address

More importantly perhaps, you can use the gdb remote target:

(gdb) target remote | ssh -t -t user_name:port_number@terminal_server.address

Remember to tell ssh not to ruin the day (fail to allocate a pty for your friendly conversation) by specifying the “-t -t”, then you can talk to Jason’s kgdb stub.

Next steps? I need to make some more of these damned ADB0036 cables (or find some more on eBay – anyone want some useless Cisco cables I bought thinking they were the same?) and hook them up to all of my systems at home. They will then constantly log via the awesomeness of GNU screen to a remote VM, and I can jump in if something rolls over and catch it so I won’t miss panic/debug opportunities.

Kernel debuggers FTW.

Jon.

Photo: APC Masterswitch Plus (with an AP9606)

As I mentioned before, I’ve been fencing most of my home/office systems (and even lights) these days. The problem is that cheaper power switches like the IP Power 9258 can be damaged quite easily. Two of mine have failed under a particular load element and I’m not saying in that case that it’s not my fault (I still like those units), but it’s clear that having something more “household name” can be a good idea. So I looked on ebay and discovered that old APC Masterswitches now often go for similar money to other more expensive kit.

I bought an 8-port Masterswitch Plus (with an AP9606) this week. Previously these went for up to $1000, but can now be had for even a tenth of that much. And they do telnet/SNMP (and ssh, if you upgrade them – not so much of a concern in this particular out-of-band configuration). I looked around for fencing scripts and obviously found the Red Hat Cluster Suite fence_apc stuff but I don’t want to install lots of stuff, and I don’t want to talk over telnet if I’ve got a private SNMP community configured and am reasonably comfortable with that. So I updated my previous script to talk to APC Masterswitch units.

APC Masterswitch Plus (with an AP9606) fencing script.

Jon.

I recently registered and setup kernelpodcast.org, where you can find links to the RSS feeds (podcast, and the transcripts), comment, and a lot more besides.

Jon.