Fun with Open Source®™© Software ! (quality control? We don’t need no stinking quality control! department)
At work, we use a fairly recent version of a US$5000/seat Linux distribution from a large and well known for their ongoing dead parrot routine. The server we've got attached to this frv$5k software is also attached to a UPS via a serial to USB converter. It works well (since the bulk of the usb plugging/unplugging takes place in kernelspace, it all seems to just work(tm) without having to do the traditional Linux routine of scooping up half a dozen tarballs and trying to wedge them into the system without irrevokably breaking several other things), or at least it used to work well, until, for reasons known only to G-d, we were instructed to roll up to the kernel from the latest patch to this version. In long ago days, you could be fairly confident that rolling up to newer versions of software would add features, and that tradition continues here: with the 2.4.21-37.?? version of the Linux kernel, the new feature is that if you have a program talking to a serial port that's connected via a serial to USB converter, the kernel won't bother to invalidate that connection when you physically remove the serial to USB converter. In the old days, the kernel would invalidate that connection, and you'd just get boring old EIO's, but with the new! improved! kernel you'd get the far more exciting result of a kernel panic and a complete system lockup, which, on a modern Linux machine, means that you have to power down the machine, then restart it and wait 20 minutes for the horrible machine to pull itself up by its bootstraps.
The vendor, of course, doesn't care, and the bug report we sent to them was punted back with a curt "we don't support third-party programs on our Linux distribution." note from the technical support person in Bangalore (and, to be fair, getting paid 37 rupees/day is not likely to encourage the sort of imaginative support that the outsourcing salesmen said would happen.) So I find myself, once again, hacking away at a Linux kernel to make the damned thing work. I'll probably even send the patch off to the vendor with a curt little "never mind the bug report; here's the damned fix", but it would have been nice if they'd have taken some of their stable of highly-paid Linux developers and actually developed a test plan for testing the patches they are putting patches into their kernel; it might actually make the idea of paying them money for their software seem more appealing.
Comments
I have no doubt it will be some work, but this particular buglet appears to be one that the anonymous distribution vendor put in with the latest upgrade to their 2.4 kernel. We discovered this at work when we rolled in the latest version of the kernel and all of a sudden the machine started to panic during shutdown (usb was shut down before the ups software, so there's about 10 seconds where the ups software is beating on the no-longer-extant serial port.)
The fun thing is that we can't actually move this server to 2.6, because me must match the kernel version to the kernel version that we ship with our distribution, and there's a scarily large amount of supporting software that will fail if we change the kernel version number out from under it.
I keep threatening to roll back to earlier versions of the kernel, but the .37 patch also includes bios support for the new space-heater dual core Xeon processor boxes our hardware vendor is about to ship in 2006 (the older kernel was tested, and it only found 1 processor.) Sooo. Patchpatchpatchpatchpatch, all the live long day.
Comments are closed
You do know that they did Major Surgery on 2.6. to handle hotplug better?
(And that this resulted in mass migration to udev as well as hal hotplug support and that some things never did recover from having their device nodes able to blink in and out?)
Just by way of suggesting that the patch might be a lot of work, and stealable into the bargain.