The Deep End | Paul Venezia » January 2007

January 29, 2007 | Comments: (0)

Forcedeth issues in 2.6.19/FC6

TAGS: ./configure && make && make install, Gear, Systems

If you happen to be running Fedora Core 6 on a AMD64 system with the nVidia MCP55 chipset, specifically the MCP55 Ethernet controllers, the update to kernel 2.6.19-1.2895 will probably break your Ethernet driver. In my minimal testing, the 0.57 forcedeth driver hangs after some number of bytes are passed through the interface, requiring an up/down to reset. This problem is not evidenced in 2.6.18-1.2798 with forcedeth 0.56, at least as far as I can tell.

The more you know.

Posted by Paul Venezia on January 29, 2007 04:11 PM

January 14, 2007 | Comments: (0)

ATI's OS Confusion

TAGS: Gear

The other day, I had to pick up a cheap PCI-X graphics card to add a third monitor to an Apple PowerMac G5. I also had to get a few other items, so I went to PC Connection's website and used their granular search feature to find all Mac-compatible PCI graphics cards. Admittedly, I wasn't paying terribly close attention to the specs of the card, but the ATI Radeon 7000-series card I purchased was in the Mac category, and was only around $45, so I picked it up. Of course, it's not Mac-compatible -- or at least ATI hasn't released drivers for it. It's detected in the system, but unusable. Time for an RMA.

Then, I looked closely at the box. The text on the outside doesn't say anything about Macs and only lists hardware requirements for PCs, but curiously, all images on the box show a desktop that's clearly Mac OS X. Even more bizarrely, the background image on those desktops is the default Windows XP "meadow" scene. And if that wasn't enough, the system pictured to the right of the twin widescreen flat panels on the front of the box is apparently the rear view of a 286 or 386. Note the AT keyboard connector, eight slots, and the old-school power supply.

So what exactly is ATI trying to tell us with this image? Ostensibly, this card will work in a 386 running OS X with Windows XP floating around somewhere. Click the image for the closeup.

Posted by Paul Venezia on January 14, 2007 09:45 AM

January 11, 2007 | Comments: (0)

The floppy is dead. Long live the floppy!

TAGS: Gear, Systems

Today I ran across a dual-CPU HP DL145 G2 that was exhibiting some strange behavior. Although 12GB of RAM was installed in the box (three ranks of 2GB DIMMS per CPU), it was only booting with 6GB visible. Some poking around on HP's support site turned up a technical note that the BIOS on the server (ROM version 2.14) was probably causing the problem. The note's recommendation is to update the BIOS, and provides a handy link to the new firmware download page. This page contains a downloadable Windows executable that will create a floppy disk that updates the BIOS when booted.

Except there's no floppy drive in the server. In fact, it's not possible to buy an internal floppy for the DL145 G2. HP offers a USB floppy drive as an accessory, but that's it. At the risk of berating the obvious, why are the updates distributed this way? What could possibly cause HP to distribute most firmware and BIOS updates as Windows-only executables that can only create floppy disks in the A: drive, especially for servers without even the option of an internal floppy drive?

Another option for booting this server is via virtual floppy. In later revisions of the ILO management code on the DL145 G2, there's an option to enter a TFTP server address and filename that will be presented as a virtual floppy drive on boot. As luck would have it, this server has the older ILO firmware that doesn't support this quite roundabout method of booting from a floppy. The solution? Upgrade the ILO firmware to the later version that does support virtual floppies. Of course, that update is only available as a self-contained floppy-imaging Windows executable. It appears that you simply can't get there from here. My, how aggravating.

Even if booting this server from a virtual floppy was possible, you'd still need to find a Windows XP system to download the update and create a floppy disk, then image that floppy back to a file that could be TFTP'd to the server at boot. Oh, and the Windows-only floppy creating executable in question refuses to run on Windows Server 2003 SP1.

We've been hearing all about the death of the floppy. Many servers and workstations aren't shipping with floppy drives at all, and they aren't an optional part. I've been in many situations where looking for a single usable floppy disk has taken far longer than the update. I recall spending over an hour trying to locate a functional 3.5" 1.44MB floppy at 1am to update the BIOS on another system. What fun that was.

Server vendors are pointing at USB flash drives as the replacement for floppies, which I think is a great idea. But you can't go halfway here -- it's either all or nothing. For compatibility purposes, these updates should be distributed with code that can create a bootable floppy and a bootable USB flash drive. Further, the ability to download the image without the Windows wrapper would make all kinds of sense. There are lots of admins that can use dd; it's not rocket science.

These ideas seem straightforward to me, but are apparently completely novel to HP. Providing required updates in a format that's basically unusable for your own hardware is just breathtakingly ridiculous.

Posted by Paul Venezia on January 11, 2007 02:13 PM