From owner-freebsd-stable@FreeBSD.ORG Thu Oct 16 23:25:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22F42106568D; Thu, 16 Oct 2008 23:25:33 +0000 (UTC) (envelope-from prvs=1175a7be7a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9518FC1E; Thu, 16 Oct 2008 23:25:31 +0000 (UTC) (envelope-from prvs=1175a7be7a=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1224198923; x=1224803723; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=me40SVceDrDlslKRT03Kh Cg8zGG+A3uWvPxbNWJsHZ0=; b=TjyJnX9Lr2aVFeJlDIQCeuv/iKeN5AIr+4MRP 8JvJkVZ13RZo7ckrZcmMwP5j4euT1APkj+eI7Wv9PuCZ4Z6h7SZWHbE1DZzVsyCb CQ2l854mCvr5sTKSUmnNJ3rVTNLjFSdIxTGtPKj5VOtjHXG+VjuBmbD1g2RmDCHB sgqrlY= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.3 required=6.0 tests=BAYES_00, FORGED_MUA_OUTLOOK, USER_IN_WHITELIST,USER_IN_WHITELIST_TO,X_PRIORITY_HIGH autolearn=no version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.6) with ESMTP id md50006411917.msg; Fri, 17 Oct 2008 00:15:21 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1175a7be7a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Antony Mawer" , "Jeremy Chadwick" References: <676151223134689@webmail38.yandex.ru> <20081005004808.GA70137@icarus.home.lan> <48E99C18.6070602@yandex.ru> <20081006051211.GA10542@icarus.home.lan> <20081010115855.GA31707@icarus.home.lan><20081016071700.GA2793@icarus.home.lan> <48F7B865.2040604@mawer.org> Date: Fri, 17 Oct 2008 00:15:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 17 Oct 2008 00:15:23 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 17 Oct 2008 00:15:23 +0100 Cc: freebsd-stable@freebsd.org, "Andrey V. Elsukov" , kib@freebsd.org, sos@freebsd.org Subject: Re: Request for testing: ata(4) MFC 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: Thu, 16 Oct 2008 23:25:33 -0000 You must be very careful with using less than 48bit addressing when both the drive and the controller supports it as some disks report errors at none standard crossover points. I saw this first hand with the highpoint driver where it totally trashed the RAID volumes. The solution was to "always" use 48bit addressing if the drive supports / requires it. Regards Steve > I started looking at the moment, as the original 28->48bit crossover bug was in the same function not so long ago (ata-all.c > rev1.280). The 48-bit LBA changes are introduced from ata-all.c rev1.282, which was the port multiplier changes. The logic just > doesn't seem quite right to it to me, but > > I'm not an expert on the code or on ATA, so all of this could just be amateur mis-interpretation. From my reading of it, the > code does this: > > /* > * Check to see if we need to use a 48-bit command in place of the > * standard 28-bit command, and if so, substitute as appropriate > */ > IF ((request_lba_addr + lba_count) >= max addressable by 28-bit LBA > or lba_count > 256) and device supports 48-bit LBA THEN > /* > * The request either: > * > * - extends past the 28-bit boundary > * - is for more than 256 sectors > * > * which necessitates the use of 48-bit LBA. Translate commands > * into their 48-bit equivalents. > */ > ... > ELSEIF the device supports 48-bit lba: > /* > * We prefer (need?) to use the 48-bit equivalents of these > * commands regardless of what the LBA address of the reqest is > */ > ... > END IF > > In rev 1.282, the ATA_READ_NATIVE_MAX_ADDRESS was moved down to the "ELSE" case of the IF statement. In otherwords, when the > request is beyond the 28-bit boundary, OR it's > 256 sectors, ATA_READ_NATIVE_MAX_ADDRESS won't be translated... > > Søren, is this change intentional, or should it be also added to the switch statement in the top half of the IF block? > > The ATA code appears to be very lightly commented, which no doubt is something of a barrier to entry to those who are not > familiar with issues such as the above... would any volunteers be helpful to help comment and/or document some of the code? We > would likely need to confer with Søren and others to ensure that our interpretation was accurate, but it would certainly make > tracking down issues easier for those unfamiliar with the code... ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.