Most recent kernel where this bug did not occur: 2.6.16
Distribution: N/A
Hardware Environment: Env including PCI card with 0xFFFFFF class.
Software Environment: N/A
Problem Description:

This bug is in the mainline kernel source and was introduced in version 2.6.17.
and is present in the 2.6.18.1 kernel.org source release.  It looks like device
registration in drivers/char/ipmi/ipmi_si_intf.c was cleaned up and a small
error was made when setting the class_mask.  The fix is simple as the correct
mask value is defined in the code but is not used:

===========================================================================
--- ipmi_si_intf.c.b0rked       2006-10-31 16:10:15.000000000 +0000
+++ ipmi_si_intf.c      2006-10-31 16:10:48.000000000 +0000
@@ -1845,7 +1845,7 @@
 
 static struct pci_device_id ipmi_pci_devices[] = {
        { PCI_DEVICE(PCI_HP_VENDOR_ID, PCI_MMC_DEVICE_ID) },
-       { PCI_DEVICE_CLASS(PCI_ERMC_CLASSCODE, PCI_ERMC_CLASSCODE) }
+       { PCI_DEVICE_CLASS(PCI_ERMC_CLASSCODE, PCI_ERMC_CLASSCODE_MASK) }
 };
 MODULE_DEVICE_TABLE(pci, ipmi_pci_devices);
==============================================================================

The problem in this code manifests when a hardware device is installed in the
system that has a class of 0xFF (misc device, i.e. one that does not fit into
any other official class) and has has the other fields also set to 0xFF.  With
the mask set as it is in the current code the "correct" bits are nicely masked
in and a positive match results.  The ipmi_si module thinks it is dealing with
an unknown device but claims ownership all the same and thus a later loaded
correct driver will not get the device as it should.

Steps to reproduce: In a system with a PCI card with class 0xFFFFFF load the
                    ipmi_si driver prior to loading the correct driver for the
                    class 0xFFFFFF PCI device.

Cheers
-Yvan