Eike, I think I've resigned myself to the fact that it won't boot. I've done a bit of digging by directly sending commands to the unit. I'm not sure why I can't force scsi_scan to do a REPORT_LUN on it through the Black List, but what I know is that it reports luns as 0x40...00 - 0x40...MAX_LUNS - they are reported as flat addressing, according to the SCSI Architecture Manual. Since TYPE_RAID implements a standard (albeit deprecated), it might actually be worth trying to create a driver for it. The real question I have is whether I could get at the drives simply by masking the LUN's like the cpqfc driver does, or whether something like BLIST_SPARSE_LUNS would do the trick, or maybe even a new blasklist entry like BLIST_FLAT_LUN_ADDRESSING. Here's a quote from cpqfcTSworker.c: // e.g., the Compaq RA4x00 f/w Rev 2.54 and above may report // LUNs 4001, 4004, etc., because other LUNs are masked from // this HBA (owned by someone else). We'll make those appear as // LUN 0, 1... to Linux I'm not sure what the direction of Linux is at this point, but there are a lot of RA4x00's out there for cheap and they (at least initially) seemed like a good entry-level FC RAID system. Also, I'm not sure how strange of a beast the RA4x00 is. If it's a one-off, maybe I could create a specific driver for it that acts as a LUN masker. If there are more, it may make sense to make the changes necessary to deal with flat addressing. At this point, I'm convinced that it would be a minor change to at least the scsi_scan code to deal with TYPE_RAID. I'm a bit more concerned about how widespread a change like flat addressing would be. Mark > > I'm now quoting mkp: > > --- > But the other reason the cpqfcTS driver is special is the RA4100 > array. The two were sold as a packaged solution. The RA4100 isn't a > "real" fibre channel disk device. It represents itself as a TYPE_RAID > as opposed to TYPE_DISK. So even if you had my driver in 2.6.5, you > wouldn't be able to use it. > --- > > What he was talking about as his driver is a replacement he writes for > cpqfc. > cpqfc was deleted from 2.6 because it was horribly written and currently > broken. The 2.4 version is the same, but it might work because the 2.4 > infrastructure is different from the 2.6 one. > > Eike > - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
