Our lab recently bought three dozen HP dc5750 desktops. These are based on
the Athlon 64 X2 Dual Core processor 4600+ and an
ATI chipset. They have 2 GiB memory and
250 GB SATA hard disk drives.
SATA timeouts
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.
Graphics drivers
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.