Date: Sat, 20 Jun 2015 13:49:57 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: ZFS passdevgonecb Message-ID: <5584E2E5.3000203@herveybayaustralia.com.au> In-Reply-To: <5583D5BE.7050508@herveybayaustralia.com.au> References: <557F90DB.80601@herveybayaustralia.com.au> <mlshi7$3of$1@ger.gmane.org> <5583D5BE.7050508@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5584E2E5.3000203>