Date: Wed, 27 Apr 2011 05:57:36 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Denny Schierz <linuxmail@4lin.net> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: MPS driver: force bus rescan after remove SAS cable Message-ID: <20110427125736.GA1977@icarus.home.lan> In-Reply-To: <1303906834.4232.91.camel@pcdenny> References: <1303906834.4232.91.camel@pcdenny>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 27, 2011 at 02:20:34PM +0200, Denny Schierz wrote: > hi, > > if I remove the SAS cable from the JBOD (connected through a SAS > switch), all disks disappears, that's fine and expected, but if I > reconnect the cable, the disks are not added anymore. > I've red to use "camcontrol rescan all", but nothing happens. I don't > get my /dev/da0-47 devices anymore and have to reboot the whole machine. > > What is my mistake? Does resetting the bus then rescanning improve things at all? E.g. for bus 0 (use "all" only if it's safe): camcontrol reset 0 camcontrol rescan 0 I'm doubting it will. This is the first time I've heard of something called a SAS switch (looks like a SAS expander to me), but searching the Web indicates that most of these devices have a form of firmware/administrative interface on them, which means it's highly likely that the device itself is "getting in the way". Meaning: what's to say the issue is with FreeBSD and not with the SAS switch? To me, my first choice of action would be to contact the device vendor and ask what the behaviour should be. If there's some sort of device with an ASIC in between your disks and the controller (which is the case here), that could be responsible for what you're seeing. Or, if the hot-swap backplane has something like SES (not a typo) or a QLogic GEM chip on it, that could be causing some issues. (In the case of the latter on our SCSI systems at work, we change the physical SCSI cabling in our systems to remove the GEM from the bus entirely, otherwise it does odd things like tries to renumber the SCSI IDs on devices during a failure, and more often than not locks the entire SCSI controller up). Bottom line: less actual stuff between the disk and the controller the better. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110427125736.GA1977>