From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 00:13:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DAD916A427 for ; Fri, 22 Jul 2005 00:13:16 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F1843D9E for ; Fri, 22 Jul 2005 00:12:59 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6M0CrZw071535 for ; Thu, 21 Jul 2005 19:12:53 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 19:12:53 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6M0Crxj071533 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 19:12:53 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 19:12:53 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050722001253.GA70277@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722004340.H16902@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 00:13:16 -0000 On Fri, Jul 22, 2005 at 12:45:03AM +0100, Robert Watson wrote: > > On Thu, 21 Jul 2005, Karl Denninger wrote: > > >ATA-NG (Soren's new code) is not (from what I understand) in the 5.x > >codebase. One bone of contention is that apparently it IS in -HEAD, but > >there are no plans to MFC it to 5.x. > > Then you misunderstand. Soren has asked to MFC it, and we've asked him > to wait until it's had more testing exposure, precisely because it is a > sensitive code base, and we don't want to see further regression. > > Robert N M Watson I don't think I misunderstand at all Robert. "We" (some group) has asked him not to MFC it. Ergo, IT IS NOT THERE NOW, and there are no plans (at present) to MFC it. That's exactly what I said. However, it obviously wasn't that big of a deal (to the -committers) to commit the ORIGINAL changes which broke the implementation going from 4.x to 5.something (early 5.x "early adopter" RELEASEs were ok). What I don't understand Robert is why Soren's code is "too sensitive" to commit, but the explosive reduction in stability that the changes made between 4.x and 5.3 caused weren't enough to back THAT out until it could be fixed. Its not like these problems didn't show up almost immediately when the affected releases hit the street. They did. Six months later, the problems are still there, and I see nothing in the commit logs to suggest that the underlying issues have been addressed. Papering over the failures so that retries work properly (when they were broken before) isn't a fix. A fix would be identifying the root cause of the DMA_TIMEOUT errors and addressing them so that they no longer occur. I realize that this is likely a timing issue in the code, and therefore is difficult to debug. That does not, however, change the fact that this issue has been open for more than six months without resolution, and that one potential resolution to the problem (Soren's ATA-NG code) either (1) doesn't fix it, (2) hasn't been tested to see if it does, or (3) DOES fix it, but for whatever internal reasons has not been MFC'd. If (1), then not only should Soren's code NOT be MFC'd, but 6.x should absolutely be held until it IS identified and resolved. If (2), then how about trying to find out of if that solves the problem? If (3), I think there are a few of us (myself included) that would like an explanation. If Soren BELIEVES (2) is the case, I'll test against -BETA1, IF I can have confirmation that -BETA1 has the ATA-NG code in it. Its trivially easy for me to reproduce this problem on my sandbox machine. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind