Running Fedora Core 3 on a Compaq Presario r3004

I've got myself a Compaq Presario r3004 notebook, my first Athlon64 box. I've run into a surprisingly small number of problems, and, with some help from Google and others that, like me, ran into interesting issues, I managed to set it up to my liking. I believe some of my findings may be useful for others, even for newer models in the Compaq Presario r3000z series (and probably Pavillion zv5000 as well), and even if they have Athlon XP instead of Athlon 64. Most of the comments should apply to other GNU/Linux distributions as well.

Shrinking the Windows XP Home partition

The first stumbling block to installing Fedora Core was to resize the Windows XP Home partition. I might as well have thrown it away, but I like to keep it around such that I can install patches on it every now and then. Since Fedora doesn't have ntfsresize, I downloaded ntfsresize-static-1.9.4.tgz from here.

I unfortunately had to boot into Windows XP and run chkdsk /f before ntfsresize would work. Oddly, it didn't ask me to agree with any EULA, which I was sort of expecting. Perhaps my notebook supplier had already done me the favor of accepting the license? I found it quite odd that it was already set up with dead keys support for Portuguese on the US keyboard layout. (In a previous version of this web page, I mentioned it appeared that the notebook was reconditioned, but it is now looking more like a glitch in the HP database or some big misunderstanding. I apologize to Holland Export, Inc., for implying they might have misrepresented the product they had for sale.)

Anyway, back to the point. As soon as chkdsk completed, having fixed at least one error in the NTFS volume, I could boot into the Fedora Core installer/rescue CD, scp the executable from the install server, resize the filesystem to as little as possible and proceed to the installation.

(Not?) Messing with BIOS updates

In earlier versions of this documented, I suggested downgrading the BIOS to version F.03, as a work-around for the problem of the clock often running about 3 times as fast as expected (and the CPU frequency being reported as 1/3 the expected), but I've since found out the downgrade doesn't fix the problem. It's still not clear to me whether my wife experiences the problem and I don't because of actual hardware differences, or because of our differences in use. My notebook is pretty much permanently on power, whereas hers is carried over elsewhere. It appears that the clock runs fast most often right after plugging the notebook into a power outlet and then powering it on; rebooting doesn't seem to fix it, but a poweroff/poweron cycle does. You can probably disregard this entire section, that I'm leaving in just in case someone is interested in the story or the links.

I noticed, as some others had reported, that the clock would often run too fast on my wife's notebook (yeah, she got one of these for her too). As it turns out, even though we got the very same notebooks from the very same reseller at the very same time, they came out a bit differently. Mine had an older F.03 BIOS, whereas hers had the F.12 one. Since mine wasn't displaying the problem and hers was, I figured it was worth a shot, in spite of the risk. So I downloaded the older (and the newer) BIOSes from here (if this URL isn't as stable as one would hope, go to www.hp.com, click on Support & Drivers, enter Presario r3004, click on Windows XP, and then on the Previous Version column for Winflash for HP Notebook System BIOS - Windows-based (AMD). I'm not sure the ROMPaq downloads, that appear to also be BIOS updates, apply, but I figured I'd go with something that was known to work (on a nearly identical notebook). And, indeed, it appears to have fixed the problem.

Beware of the 2.5MB-sized ROMPaq files! They're not appropriate for Presario R3004 notebooks, and HP is hopefully going to fix their web site soon. While at that, thumbs up to HP's chat support! A technician named Visu did I great job verifying and confirming the problem, and following up later by e-mail with a pointer to the latest available BIOS, that had been pulled out of the site as of 2004-10-15.

The Fedora Core 3 test 3 kernel still reports something odd about K8 errata #93 not being fixed in the BIOS, and that disabling legacy USB might fix it, and that the work-around in the kernel might cause random hangs or cpu burn. I haven't experienced any such issues, and it doesn't come up on every boot, but one of these days I might try a BIOS update.

I've since upgraded to F.21, and the fast-clock problem came back on my wife's notebook, even though mine still works flawlessly. Since I still get the K8 errata message, I figured I'd downgrade it back.

If you can't get to the BIOS downloads from the web pages any more, you may get them straight from the FTP server. You may get the F.21 BIOS as download SP28824.exe. I got the URL straight from an HP technician, as a temporary work-around for its absence in the official web page. Since I had downloaded the F.03 BIOS before, I knew its download name: SP27465.exe.

HP has released an F.30 BIOS update that fixed the problems above, but that broke USB. F.33 fixes it, as well as the K8 errata message, and apparently all other BIOS-related problems except, perhaps, for the fast-clock problem, that I haven't run into lately, but it's hard to tell whether it's fixed for good. I've been experimenting with the acpi_skip_timer_override kernel option (which appears to be enabled by default on these notebooks, at least in 2.6.11rc kernels). It appears to help, but nothing conclusive.

F.35 was supposed to fix the fast-clock problem, at least on MS-Windows, but I still got the problem after the BIOS upgrade at least once. Oh, well :-(

On Aug 20, 2005, David G. Miller suggested on fedora-list the kernel option no_timer_check=0. Let's see how that goes...

Getting the ALPS Touchpad to work

Linux (the kernel) 2.6.9 doesn't have support for ALPS Touchpads yet. PS/2 mouse emulation should work, but due to some bug, in the BIOS and/or in Linux, it doesn't work in the Fedora Core 3 test3 kernel. If I rebuild the same kernel with psmouse as a module, I still don't get PS/2 emulation, but if I run rmmod psmouse; modprobe psmouse, then it starts working. Cool, eh?

I wasn't happy with PS/2 emulation, having been spoiled by the full-featured touchpad of my previous notebook, so I went ahead and found a kernel patch that added ALPS support to the psmouse module, thanks to pointers from several other web pages like this. I started with this patch, downloaded from a web front-end to some kernel BitKeeper tree, and got it to apply to the latest Fedora Core development kernels in this form. After installing the latter patch into the SOURCES directory in the rpm build tree, I installed the kernel SRPM, entered the SPECS dir and applied this patch, that also modifies the kernel configuration file for x86_64 such that it builds psmouse as a module.

One rpmbuild later (hey, it's a fast box, and ccache really helps), I had a kernel with ALPS Touchpad support. Since mkinitrd, and nothing else in Fedora Core, expects these features to be supplied by modules, you have to run mkinitrd -f --with=psmouse /boot/vmlinuz-2.6.8-1.624.0.mousemod.1 2.6.8-1.624.0.mousemod.1 to get them built into the initrd, and add these flags for any new kernel you build.

I tried --preload=psmouse, but then the touchpad wouldn't be detected. I've got a number of modules loaded in initrd, including those needed for Firewire and USB hard disks to be available early in the boot, so I suspect something in psmouse that only works when loaded after them, possibly related with USB legacy emulation and the K8 errata. I'll keep poking at it and add a note here if I find out something else.

The nice surprise was that, after this patch, I didn't even need the rmmod;modprobe any more. The unfortunate surprise was that, one more kernel build later, now with psmouse built into the kernel, it didn't work any more. So I went back to the working one, and lived happily ever after.

Some investigation revealed that, if psmouse is initialized before ohci_hcd, the touchpad is not detected. I'm guessing it has something to do with PS/2 USB emulation code. Unfortunately, the crappy BIOS configuration screens don't offer the option to disable this emulation.

Fortunately, Vojtech Pavlik had posted a patch that forces PS/2 USB emulation off early enough to enable a built-in psmouse to probe the touchpad properly. I've updated the patch to the latest Fedora Core development kernel, in such a way that it is only active if you add the nops2usbemul option to the kernel command line, and used this patch against the spec file to build it.

The resulting kernel detects the Touchpad without any need for special mkinitrd command lines or module reloading, as long as the nops2usbemul option is passed in the kernel command line.

If you don't feel like rebuilding a kernel, kernel-2.6.9 has introduced a mechanism to re-probe for a mouse without having to have built psmouse as a module. It doesn't have ALPS support yet, so all you'll get is a regular mouse emulation (no scrolling, no edge movements, etc), but hey, it's a start! Try this:

    echo -n reconnect > /sys/bus/serio/devices/serio3/driver
    

You may have to change serio3 to something else in your case, depending on how the touchpad is connected internally.

I was told ALPS touchpad support would be in kernel-2.6.10, but it didn't make it. A significantly reworked version of the usb-handoff patch may have made it too, but I haven't needed it in 2.6.10-1.741_FC3. Let's hope... While at that, thanks to Dmitry Torokhov for the reconnect tip, and for being working on ALPS Touchpad support.

As for good news, the ALPS touchpad support is in the latest Linus' tree, as well as in the Fedora Core Development tree, that tracks Linus' tree. This means that if you install today's rawhide (AKA Fedora Core Development), odds are that it's going to just work. I'm running rawhide-20050130 now, with kernel 2.6.10-1.1115_FC4 (based on Linus' 2.6.11-rc2-bk4), and it can use the touchpad as such without any kernel patching. Yay! And it also fixes the X text mode issue mentioned below, without any work-arounds. Double-yay! For those of you not adventurous enough to run rawhide, look forward to FC4test1, or maybe FC4 final.

Configuring X without losing text mode

Well... Not for that long. The installer had configured X to use the nv driver, since this NVidia GeForce 440 Go card is supposed to be supported. And, indeed, it worked almost out-of-the-box. Unfortunately, X doesn't have a built-in video mode for 1280x800, so you have to introduce it yourself. That's not too bad, especially having an example to copy from.

But beware, that config file will only work if you're willing to use NVidia's proprietary X driver. If you, like me, prefer to not taint your kernel with proprietary modules, you can use my config file instead. It has ALPS Touchpad settings with some timings that I find comfortable.

As you can probably tell from the file, I've experimented a bit with the vesa driver as well. There's a reason for that: my former notebook used to get myself into unfortunate surprises whenever I needed to plug it into an external monitor to deliver say an important presentation about the wonders of Free Software to a few hundred people. Doing that using any proprietary software, a proprietary video driver included, would be a shame, so I try to stick to the nv driver, but that came at a price: I had to switch to the external monitor before starting X, otherwise the driver would get in a very confused state, and nothing would work from then on. The vesa driver never got me into such surprises, since then the it's the machine BIOS that does all the dirty work, and it can handle the switching from one monitor to another quite happily.

The unfortunate thing is that the BIOS doesn't always know about all video modes. With the former notebook, I was limited to 1280x1024, but I'd paid for the 1600x1200 screen and really wanted to be able to use it. But 1280x1024, or even 1024x768, is generally good enough, and even recommende, for projectors, so I like to keep such a configuration handy.

As with every notebook BIOS, the new one didn't fare any better: the highest resolution the BIOS supports is 1024x768, which, expanded to 1280x800, looks a bit odd, because of the wrong aspect ratio. I played with it for some time, but quickly got tired of the non-uniform dot expansion. And then, I wanted to be able to enjoy the higher resolution!

So I went back to the nv driver, just to find out, at the first switch to text mode, that it was totally garbled. Also, switching back to the vesa driver after that point was pointless: I had to reboot to restore video, and sometimes such a reboot would hang. Ouch! A bit of googling later revealed that there was no known solution to this problem.

I noticed, after some investigation, that, if I connected an external monitor to the notebook, and switched to it, everything would work fine again, until the next reboot. That was nice, but not good enough; I'd probably need text mode at the very time when I wouldn't have one, so I kept trying.

After switching back and forth between nv and vesa drivers, I noticed that, if I entered Fn-F4 (the hotkey to switch between internal monitor, external monitor, both or none) while in a graphical mode started by the vesa driver, switching back to text would work again from then on, even if I didn't have an external monitor connected. And, from that point on, everything worked flawlessly. I also found out that, if you entered Fn-F4, while in a functional text mode (i.e., before the nv driver messes it up), everything would keep on working until the next reboot. Yay! I had not only one solution, but two!

Figuring I'd often forget to stay around after powering the notebook up to enter Fn-F4 early enough, I decided to hack a solution that would enable me to walk away from the machine while it booted up and recover from the video mode mess without having to reboot. I also didn't want the machine to keep waiting for me to do something before it started all services, such that I could turn it on and then ssh into it from elsewhere.

At this time, the alternate vesa layout in my X config file came in handy. After rhgb (the graphical boot thingie) completed, I'd arrange for X to be started in vesa mode, such that I could press the magic key combination to fix text mode (Fn-F4) and exit. Since at that point nv would have already corrupted the video modes, I'd better let whoever happened to be at the console what was about to happen, so I used an xmessage box with an nv-controlled X session before that. It's ugly, but I'm quite proud of it.

If you want to use my hack (instead of just pressing Fn-F4 early in the boot), you'll have to edit the last few lines of /etc/rc.d/rc (where the call to rhgb-client --quit is, such that they look like this file. If you don't use rhgb, you'll have to change it a bit, but it shouldn't be difficult. Just don't run it in rc.local; it appears to be too late (or too early?) then.

To sum in up, in case I lost you in my ramblings: if you press Fn-F4 before you ever start X with the nv driver after a reboot, text mode will work. If you missed that, you don't have to reboot: start X with the vesa driver, press Fn-F4 while in the garbled graphics mode, and, when you switch back to text mode, you'll have working text and vesa graphics again.

Yet another possibility is to load module rivafb, that as far as I can tell gets us a graphics mode for text, avoiding the broken text mode issue entirely. It's actually more than that: it also fixes VESA graphics video modes, and apparently in a way that gets VESA video modes to work with the correct aspect ratio, as opposed to expanded horizontally to take up all of the screen size (it seems to still take up all of the vertical space).

I've had a hard freeze while playing with it, having rivafb loaded, an X session started in VT7 using the nv driver and another X session in VT8 using the vesa driver, then switching back and forth between an internal and external display. I guess it's one of those cases of `if it hurts, don't do that', but it would be nice to have some set up I knew I could use for presentations on external projectors. More as I learn more about it. You may want to keep an eye on the relevant X.org bug report.

What worked out of the box, and what didn't work at all