Device Issues with 2.6.24 Kernels, HAL, and Xorg

Block Devices

The first thing that bit me was an apparent peculiarity with various brands of optical drives, in this case a budget DVD-R/W drive. When I booted up the 2.6.24 kernel, the drive seemed to stop working (at least the tray was locked and closed and nothing I tried could make it open) but it would work fine before the OS loaded or when booted from the Gentoo LiveCD. When running the kernel in question, I was also seeing the following repeated messages in the system logs:


...
Apr  3 19:04:47 rama hdc: ATAPI CD-ROM drive, 0kB Cache
...
Apr  3 19:04:47 rama hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
Apr  3 19:04:47 rama hdc: status error: error=0x00 { }
Apr  3 19:04:47 rama ide: failed opcode was: unknown
Apr  3 19:04:47 rama hdc: drive not ready for command
Apr  3 19:04:47 rama Uniform CD-ROM driver Revision: 3.20
Apr  3 19:04:47 rama hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
Apr  3 19:04:47 rama hdc: status error: error=0x00 { }
Apr  3 19:04:47 rama ide: failed opcode was: unknown
Apr  3 19:04:47 rama hdc: drive not ready for command
Apr  3 19:04:47 rama hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
Apr  3 19:04:47 rama hdc: status error: error=0x00 { }
Apr  3 19:04:47 rama ide: failed opcode was: unknown
Apr  3 19:04:47 rama hdc: drive not ready for command
...

At first I thought the hardware had actually failed until I noticed it still worked fine before the 2.6.24 kernel booted up; what fixed it for me was switching from the old IDE/ATAPI drivers to the new PATA drivers. My previous "standard" kernel config for systems with IDE drives was to enable the generic IDE support, along with the IDE controller drivers for the motherboard in question (e.g., VIA, Intel, SiS, etc). I would then usually modularize the SCSI drivers for disk, cdrom, etc, mostly to support USB flash and optical drives. Since SATA drives are seen as sda devices (i.e., SCSI disks), obviously you would need to use an initial ram disk if you wanted to modularize the controller or disk drivers, but unless you're already doing that, it's easier to just build them directly into the kernel. Like SATA, the newer PATA drivers also use the generic SCSI layer (note this will change your CDROM/DVD devices to their SCSI equivalents). To switch to PATA, you would enable both the PATA controller drivers for your motherboard, plus the SCSI disk support, then disable the old IDE driver section completely.

Once booted, your new PATA disk devices would look like this:


 # ls -l /dev/s* 
lrwxrwxrwx 1 root root      3 Apr 13 10:11 /dev/scd0 -> sr0
brw-r----- 1 root disk   8, 0 Apr 13 10:11 /dev/sda
brw-r----- 1 root disk   8, 1 Apr 13 10:11 /dev/sda1
brw-r----- 1 root disk   8, 2 Apr 13 10:11 /dev/sda2
brw-r----- 1 root disk   8, 3 Apr 13 10:11 /dev/sda3
brw-r----- 1 root disk   8, 4 Apr 13 10:11 /dev/sda4
crw-r----- 1 root disk  21, 0 Apr 13 10:11 /dev/sg0
crw-rw---- 1 root cdrom 21, 1 Apr 13 10:11 /dev/sg1
brw-rw---- 1 root cdrom 11, 0 Apr 13 10:11 /dev/sr0

which, unless you were using the ide-scsi layer, previously appeared as /dev/hda and /dev/hdc respectively.

Input Devices

This is not specifically a kernel quirk that I know of, although apparently the kernel evdev driver has a different view of things than the Xorg evdev driver does now... Anyway, this one can be a bit tricky to pin down until you know what to search for. The symptoms for me happened to be with certain USB wireless mouse and keyboard combos that started acting decidedly weird; once X started, the mouse would only move vertically but not horizontally. They would work fine with the gpm console driver, and if I plugged in a wired USB mouse, it worked as expected. In this case the mouse motion problem happened with both a Logitech Internet keyboard/mouse combo that has both a PS/2 and USB connector for the receiver, and one from I/O Gear (which lsusb shows as Belkin/Holtek) that only has a single USB connector.

This problem should probably be called the premature-hal-Xorg-integration-release bug, since it seems to be a function of the latest HAL verison (sys-apps/hal-0.5.10 in Gentoo) taking over the Xorg input devices and forcing the evdev driver for both keyboard and mouse devices (the other relevant packages are x11-base/xorg-server-1.4.0.90-r3 and x11-drivers/xf86-input-evdev-1.2.0). Most distributions seem to ship HAL by default, but if you aren't using it, then this is not the cause of your problem. There are several possible solutions to this, depending on your mood:

Remove HAL. A little drastic, but...
Downgrade to hal-0.5.9.1*
Easiest: add this to xorg.conf and restart X
```
Option "AutoAddDevices" "False"
```

The above option is supposed to keep HAL from taking over your X input devices and forcing whatever the default device config turns out to be; this whole problem seems to be due to HAL not parsing the mouse axes correctly, so presumably a custom .fdi file might also fix it. You will need to specify the device options in xorg.conf (just as we've always had to) in order to get the proper device config, which everyone should already have anyway. You might also think the above command would stop a second mouse from working when you plug it in, but that seems to work fine as well.

See this bug trail for some discussion: Bugzilla Bug 199317 - Summary: x11-drivers/xf86-input-evdev-1.2.0 horizontal X axis not working on MX-600 and MX-1000 mouse (Unable to parse 'RelAxis 0' as a map specifier)

You may also have seen some recent keyboard weirdness, especially if you've set a custom Gnome keyboard type, layout, etc. If you're also having keyboard problems, usually keys doing something other than what you expect, then try selecting "Reset to Defaults" in the Layouts tab of the Gnome Keyboard Preferences (which should be "Evdev-managed keyboard").