/dev/ch0 not recognized

[Scott Long]

On Jul 17, 2010, at 7:11 PM, Justin T. Gibbs wrote:
> On 7/8/2010 8:00 AM, Scott Long wrote:
> 
> ...
> 
>> With that note aside, you have to understand how this system works.  It
>> doesn't follow the traditional rules of SCSI when it comes to device
>> discovery; instead the CISS firmware controls what devices are allowed to
>> be seen by the OS.
> 
> My hunch on this is that these changers show up as non-zero luns on the
> tape device.  Since the ciss driver tells CAM that the max-lun is 0,
> the changer device will never be probed.  Even if this were changed,
> someone with more knowledge of the ciss_device_address format (i.e.
> how to pass through lun information to a physical pass-through device)
> would need to step forward so we could support this.
> 

Yeah, that's what I get for keeping track of too many raid drivers in my head without looking closely at the code from time to time.  The trick with CISS is that it advertises extended LUNs, which CAM really doesn't understand.  There are two problems.  The first is that LUN addressing in CAM is restricted to a u_int, which cannot reliably hold the extended LUN space on all platforms.  The second is that, until recently, it was not feasible to search the extended LUN space (or even the traditional LUN space).  Matt Jacob's REPORT_LUNS work might help with this, assuming that the CISS controller will respond to such commands.  That's worth looking into.  But even if it does, the limited definition of a LUN in CAM is going to be problematic; it can be hacked to just ignore the problem, but it would be nice to fix it correctly.

Scott