Date: Wed, 21 Jul 2010 10:42:35 -0600 From: Scott Long <scottl@samsco.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com>, frank cheong <kwcheong@gmail.com> Cc: freebsd-scsi@freebsd.org, Mike Hill <mike.hill@kitesystems.com>, Sean Bruno <seanbru@yahoo-inc.com>, Folkert Saathoff <folkert.saathoff@kitesystems.com> Subject: Re: /dev/ch0 not recognized Message-ID: <9E812EFE-B099-408D-906B-0785A2F9C476@samsco.org> In-Reply-To: <4C4254C1.9020803@scsiguy.com> References: <AANLkTik3mfTCcHwgYC4R5ANgf0ydBFkpUyjj90n0-uNP@mail.gmail.com> <6A0E4367-98BB-4C24-B01A-63A3E533D88C@kitesystems.com> <1278433685.2506.9.camel@localhost.localdomain> <AANLkTimjNuezI-yhDzpjnpVoUfp5tI9CwIWrWFN6_pSD@mail.gmail.com> <6EC599F1-3713-4497-9372-4032078890EF@samsco.org> <4C4254C1.9020803@scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 17, 2010, at 7:11 PM, Justin T. Gibbs wrote: > On 7/8/2010 8:00 AM, Scott Long wrote: >=20 > ... >=20 >> 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. >=20 > 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. >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E812EFE-B099-408D-906B-0785A2F9C476>