No, no... if I am deliberately trying to exclude 0x250-0x25f because of conflicts with, say, power management, then the last thing I want is for the SCSI card to land on 0xA50 instead of 0x250. I understand about the 10-bit address issue, but suppose the power management stuff built into the notebook decodes only 10 bits? Then accesses to the SCSI card at 0xA50 will be misread by the power management hardware as accesses intended for it. Even if the power management hardware understands 16 bits, then the SCSI card would misread accesses to the power management hardware as intended for it, too. Only if both components "sharing" the lower 10 bits of the address are capable of decoding all 16 bits will such sharing work.
What you seem to imply is that, in order to protect 10-bit hardware, it is necessary to exclude all equivalent ranges? If that is the case, then perhaps a directive should be added to the "exclude" parameter to do this automatically.
What I should probably do is explicitly tell the driver what port range to use, although I am not sure exactly how to do that without looking into the driver source again. This machine happens to be an IBM ThinkPad 701CS (remember them?) so it also has some funny doings on the parallel port addresses (0x278-0x27f and 0x378x-0x37f) because one of the parallel ports is used for the printer port and the other is used for the disconnectable 3.5-inch floppy drive. In fact, I think there is some sound hardware at 0x220-0x22f also, so probably the only range at which the SCSI controller might be supported is 0x280-0x29f.
I thought of the issue about kernel support for SCSI CD-ROM devices, but I am running on the Debian installation kernel from the 2.2.9 Potato test release. (Note that Debian release numbers have no connection with kernel version numbers, despite looking similar by coincidence.) Until I can get the CD-ROM drive visible to the system, installing enough of Debian to build a kernel on that machine is going to be hard. I am fairly confident that SCSI CD-ROM support is built into the installation kernel, as this would be critically important and a major bug if not. The installation root disk does provide /dev/scd* nodes, too. I will see if I can double check this, however, as I am not absolutely certain.
If the KXLC003 controller really is supposed to work now, then I will put some effort into resolving this properly.
[ Edit This Forum ]