The problem was, Linux wouldn't boot on them. Or, using a bootable CD, it would — but it would take several minutes trying to detect the hard disk and then claim there was none installed. After trying to boot the installed system (from a drive image), we tried both the Fedora rescue disc and Knoppix with the same results. Essentially, for each ata device it was timing out and then saying:
ata1: dev 0 failed to IDENTIFY (I/O error)Much googling eventually led to a blog entry with the solution.
When we installed these machines in January the latest BIOS release available for them on HP's web site was 1.54A, which had been out since November. They were supplied with 1.04. The 1.54A version was needed, since earlier versions than that don't contain the appropriate config option.
Once 1.54A is installed, you boot to the BIOS screen by pressing F10 and then select Storage -> Storage Options and change the SATA Emulation setting. It's supplied with that set to "Legacy IDE"; for Linux you need it to be "Native IDE".
Lo and behold, our machines now work properly under Linux. (I gather there's some kind of problem with recognising the DVD drive under Windows with this option set, but frankly I don't care.)
Edit (March 20): We have another of these same boxes, but not from the same batch. It came with version 2.10 of the BIOS. However, our system image paused during boot and failed to detect the DVD drive, saying:
ata2: port is slow to respond, please be patient ata2: port failed to respond (30 secs) ata2: softreset failed (device not ready)And after that, the drive was so dead that the tray wouldn't open and the BIOS failed to detect it on reboot.
However, updating the installed 2.6.18-1.2869 kernel to 2.6.20-1.2925 seems to have solved the problem.
The machines still seem to take forever to start udev, though. And they print a ream of ata2.00 messages on the text console once the machine is up, although that stops after a couple of minutes.
The machines come with ATI Radeon X1300 PCI Express graphics cards. The open-source "ati" driver which comes with Xorg does not support this card at all. Most unsupported cards can be driven by Xorg's "vesa" driver which makes video BIOS calls to set up the graphics mode (this however means that no graphics acceleration is used). So we set up the workstations with this driver.
Some time later, we discovered that the screens were not blanking when left idle, despite the software claiming it was turning the monitors off successfully. Therefore, we had no choice but to install the proprietory ATI graphics driver. As the machines are configured to pick up the yum repository at Livna, this was more-or-less as simple as typing "yum install x11-xorg-drv-fglrx" followed by "aticonfig --initial". Some time later: a lab full of blank screens, hoorah.
Unfortunately, things didn't quite go as well as we had hoped.
My colleague attached a projector as a second monitor to one of the machines. Booted it up in Linux and — boom — the screen went blank and stayed blank. It turned out the X server had died with a segfault. The only way I could find to cure this was to set the machine up in dual-head mode. Even just turning clone-mode on resulted in no display at all. Then I discovered that every time I moved the mouse pointer on to the second screen it changed into an ugly square blob which was very difficult to point with.
Meanwhile, some people using the other machines had been finding that when they logged out they ended up with a blue screen (no, not that blue screen — just the default Fedora background) with a moveable mouse pointer on it but nothing else. Judging from Google, it seems that many people over the ages have reported "X hangs on logout" bugs to ATI but not had much response. It wasn't a consistent bug — at least two people failed to be able to demonstrate it while I was present — but when I finally caught one I discovered that the X server was stuck in futex(), which is something that I don't understand at all and find particularly difficult to debug.
What's more, according to the Xorg startup logs, there was some problem with 3D acceleration and it was falling back to 2D mode. It just said "DRI initialization failed" or something equally uninformative. Not that I particularly care about 3D acceleration, mind (which is why I would have been happy with the "vesa" driver really), but one or two of the students do use 3D-intensive stuff in Matlab.
It turns out that, for reasons which are unclear, the 3D problem and the mouse-pointer problem are both solved by turning off the Composite extension:
Section "Extensions" Option "Composite" "false" EndSection
Fortuitously I discovered a procedure for repeating the hanging-at-logout bug. It had to do with executing a GLX application before logging out. As luck would have it, I couldn't repeat the bug after disabling the Composite extension, so that looks like three bugs with one stone. I just hope no one actually needed that extension; I'm not sure what it is, but I gather it's something to do with transparencies.