I noticed the following question from Otavio Salvador in the discussion for bug #440161:
> I still fail to understand how i2o_block will work for your device if > it's not registered for it on pcialias file ... that makes me worry > about it. I think the answer to the question is that the i2o_core module also supports the "0x000e0000" class. For example, the modules.pcimap file for our 2.6.18-5-k7 installation includes the following line: i2o_core 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000e0000 0x00ffff00 0x0 This matches the "I2O" class of the Adaptec 2100S card: # lspci -nn [...] 00:0a.1 I2O [0e00]: Adaptec (formerly DPT) SmartRAID V Controller [1044:a501] (rev 02) Earlier in the thread there was a mention that the following two devices were listed in modules.pcimap as being supported by i2o_core: > 1044:a511 dpt_i2o i2o_core > 8086:1962 i2o_core I believe these two device ids are listed specifically in order support two particular types of cards that don't match the 0x0e00 class: http://i2o.shadowconnect.com/faq.php#promise http://i2o.shadowconnect.com/faq.php#zerochannel [More specifically, for the Promise card the line from modules.pcimap is: # pci module vendor device subvendor subdevice class class_mask driver_data i2o_core 0x00008086 0x00001962 0x0000105a 0xffffffff 0x00000000 0x00000000 0x0 , and /usr/share/misc/pci.ids lists that vendor/device/subvendor as as: --- 8086 Intel Corp. [...] 1962 80960RM [i960RM Microprocessor] 105a 0000 SuperTrak SX6000 I2O CPU --- Similarly, the Zero Channel card reports itself as class "0104", according to "lspci -n" output included at the bottom of https://www.redhat.com/archives/rhl-beta-list/2004-October/msg01321.html , and so the driver needs to support that specific card by device id. ] Hope this helps. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
