From owner-freebsd-questions@FreeBSD.ORG Sat Jun 20 03:50:06 2015 Return-Path: Delivered-To: freebsd-questions@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92DF9492 for ; Sat, 20 Jun 2015 03:50:06 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 050546CF for ; Sat, 20 Jun 2015 03:50:05 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from [192.168.0.175] (laptop1.herveybayaustralia.com.au [192.168.0.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 8815B6211A for ; Sat, 20 Jun 2015 13:49:58 +1000 (EST) Message-ID: <5584E2E5.3000203@herveybayaustralia.com.au> Date: Sat, 20 Jun 2015 13:49:57 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: ZFS passdevgonecb References: <557F90DB.80601@herveybayaustralia.com.au> <5583D5BE.7050508@herveybayaustralia.com.au> In-Reply-To: <5583D5BE.7050508@herveybayaustralia.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 03:50:06 -0000 On 19/06/2015 18:41, Da Rock wrote: > Ok, top posting as a summary really - numerous threads of thought > going on now. > > First, that ggatel and mountver workaround - how does zfs take that? > Is it possible zfs will have a dummy spit if this is between it > writing to the drive? I'd assume not given it can use a md device as a > vnode, but doesn't hurt to ask. > > Second, I've tried another drive and still the same issue; > also.swapped cable, and still errors. So a controller test would be > ideal - or a new system is in order :) > > Third, that consumer/raid drive difference seems a bit dodgy doesn't > it? :) Appears they're basically forcing you to pay up for the > privilege... wouldn't surprise me! Regardless, though, how does that > stack up in an ordinary situation? I doubt you'd have a raid certified > drive in a desktop to play games or edit home movies, and in that > scenario it would spak out as the only drive in the system and > probably crash, wouldn't it? Or am I not thinking it through properly? > Possible given the amount of sleep I've had lately... > > Thanks for the brainstorming help guys. Something to add to this conundrum - pity it couldn't tell me this earlier... cam_periph_alloc: attempt to re-allocate valid device pass1 rejected flags 0x18 refcount 1 passasync: Unable to attach new device due to status 0x6: CCB request was invalid Searching these terms (last one I see a lot with umass myself) it seems this is quite common for most, so why is this mostly ignored? Or so it seems... I also can't seem to grasp the precise meaning of the particular errors - the flags and error codes that is. This appears to be more than a zfs spit either as you can see - this affecting smartd as well, and seems to be low level. FWIW there is no noticeable difference in firmware either. > > > On 06/18/15 05:24, Michael Powell wrote: >> Da Rock wrote: >> >>> I hate jumping in like this out of the blue, but time is not on my side >>> atm with a lot going on. >>> >>> I have a problem with some devices disappearing on various versions of >>> FreeBSD and machines (laptops, workstations/servers). Umass are the >>> norm, with the message occurring most on usb sticks and sd cards. >>> >>> Big problem atm is that my file server has a failed disk in the raid, >>> and I've tried replacing it with a new drive (twice now), and both >>> times >>> it begins to resilver and then it is "REMOVED". If I online it >>> again, it >>> goes for about 10mins then REMOVED again. >>> >>> Dmesg shows that the device is removed from the devfs with a >>> passdevgonecb/lost device message. This apparently occurs right at boot >>> too, as it shows amongst the usual scrolling during boot. >>> >>> I had a chat with someone and they mentioned the cable and/or >>> controller >>> could be the issue. Could anyone add any insight or tests I could do? >>> I'm not exactly claim to be an expert at zfs, so maybe something might >>> need addressing there too. >>> >>> I'd particularly appreciate a means of testing the controller. >>> >>> ATM the main theory is to replace the board - not a happy thought! :/ >>> >> Another item to consider, even if only to exclude it, is: what kind of >> drives are these? Are they server RAID certified or are they 'consumer' >> desktop types. RAID certified are designed to time-limit attempts at >> error >> recovery. There is a window in time that if a consumer drive takes >> too long >> at internal ECC the controller will drop it. Doubt this is your case, >> I bet >> you have server drives. I just mention it because using consumer desktop >> drives on RAID controllers can sometimes be problematic. >> >> -Mike >> >> >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "freebsd-questions-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org"