Date: Thu, 24 Jul 2003 21:25:20 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Tony Maher <tonymaher@optushome.com.au> Cc: scsi@freebsd.org Subject: Re: probing LUN's Message-ID: <20030724211609.M43159@root.org> In-Reply-To: <200307241101.h6OB1RmI023235@dt.home> References: <200307241101.h6OB1RmI023235@dt.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Jul 2003, Tony Maher wrote: > > Actually, I don't know that that will cause the device on LUN 4 to show up > > if LUN 0 isn't probing. According to SAM-3, all SCSI devices must accept > > LUN 0 as a valid address. > > > > Of course if it does respond on LUN 0, but just says that the LUN isn't > > connected, we may still end up failing to probe additional LUNs.. It has > > been a while since I looked at the probe code. > > Attempts to use CAM_QUIRK_HILUNS were not successful. > Following Matt Jacobs pointer to the code I modified cam_xpt.c > > I am not sure what you mean by "LUN 4 to show up > if LUN 0 isn't probing". > There is no device at LUN 0 so the probe will return no device. The existing > code gives up further probing at this point (no device at lun 0). > This would appear to be a bug. It's not a bug, it's behavior defined by the standard. > configurations) it would be nice if FreeBSD probed all LUNs. > It isn't a big cost is it? > If it is could we have a kernel option CAM_PROBE_ALL_LUNS? Perhaps. I'll let others address the question of breaking standards compatibility. I'm not sure why it's a problem to keep doing "camcontrol rescan 1:0:4" in your rc.local or something. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724211609.M43159>