From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 07:15:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86A016A418 for ; Mon, 13 Aug 2007 07:15:40 +0000 (UTC) (envelope-from lists@billsf.net) Received: from curacao.billsf.net (billsf.net [213.130.164.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF3713C46E for ; Mon, 13 Aug 2007 07:15:39 +0000 (UTC) (envelope-from lists@billsf.net) Received: by curacao.billsf.net (Postfix, from userid 1004) id 7620829027A; Mon, 13 Aug 2007 09:15:38 +0200 (CEST) Date: Mon, 13 Aug 2007 09:15:38 +0200 From: FreeBSD Mailing Lists To: Nathan Butcher Message-ID: <20070813071538.GA2058@curacao.billsf.net> References: <46BFE620.8070906@fusiongol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46BFE620.8070906@fusiongol.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Mon, 13 Aug 2007 11:21:52 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 07:15:40 -0000 On Mon, Aug 13, 2007 at 02:03:28PM +0900, Nathan Butcher wrote: > >I tried to roll back to right before the above mentioned change > >Karsten (well, I assume it was him :-) ) noted on IRC that it might > >be the cause of the problems since I have a similar controller, though > >not exactly the same one, but it didn't fix the timeouts for me. > > >For this server I have 3 disks in a graid3 (so no ZFS but the errors > >are similar to what I have seen / heard about wrt. ZFS + ata use) and > >I get timeouts several times a day which causes FreeBSD to loose > >contact with one or more disks where I have to reboot before things > >recover (usually FreeBSD panic's enough so the system reboots by > >itself). > > I'm certain that the issue with this card isn't limited to ZFS. It's > been seen before in the 6.x series too. > > I really would like to find out which code changes ruined the card's > correct operation... if that could help the ata maintainer in some way. > Unfortunately my csup-fu isn't that strong, otherwise I would send my > source tree back to June 15th and analyse daily buildworlds from that > date until I could pin-point the exact date and file changes that caused > the problem all of us are seeing. > > Could someone teach me how to do csup rollbacks to a specific date in > the source tree? If it's not obvious already, I'd really like to squash > this bug. Nathan, This problem has gone away for me, for the most part. At one point, out of desparation, I changed a few lines in the kernel to prevent crashes. I don't have this problem with zfs, but that is on a production server using a SCSI RAID system. (v6.2-stable about a year old) According to csup(1) just add 'date=[cc]yy.mm.dd.hh.mm.ss' to your cmdline arguments. Presumably it also works in 'supfile'. Note that you must supply the full year past 2000. I'd either reserve another space or back-up your current source tree. I've only needed to backtrack once before and that was using cvsup(1). Corrupted or improperly tagged material just stays. Actually this is a feature, but offtopic. The machine I'm referring too uses an on-board nVidia N570 SATA-300 system, though the Promise cards are 100% compatible. (and preferred because the connectors are hard to reach and as a result are easy to break) Bill