From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422741AbWGNUC3 (ORCPT ); Fri, 14 Jul 2006 16:02:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422739AbWGNUC3 (ORCPT ); Fri, 14 Jul 2006 16:02:29 -0400 Received: from rtr.ca ([64.26.128.89]:35272 "EHLO mail.rtr.ca") by vger.kernel.org with ESMTP id S1422724AbWGNUC2 (ORCPT ); Fri, 14 Jul 2006 16:02:28 -0400 Message-ID: <44B7F852.3040501@rtr.ca> Date: Fri, 14 Jul 2006 16:02:26 -0400 From: Mark Lord User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Justin Piszcz Cc: Alan Cox , Jeff Garzik , Sander , linux-kernel@vger.kernel.org, IDE/ATA development list Subject: Re: LibPATA code issues / 2.6.17.3 (What is the next step?) References: <44AEB3CA.8080606@pobox.com> <200607091224.31451.liml@rtr.ca> <1152545639.27368.137.camel@localhost.localdomain> <44B7D168.2080304@rtr.ca> <44B7D6CE.4030406@rtr.ca> In-Reply-To: <44B7D6CE.4030406@rtr.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Mark Lord wrote: > Justin Piszcz wrote: >> They are Western Digital 400* drives. >> >> [4294678.049000] Vendor: ATA Model: WDC WD4000KD-00N Rev: 01.0 >> [4294678.050000] Vendor: ATA Model: WDC WD4000KD-00N Rev: 01.0 >> >> On a SiL controller, it also happens when they are on a promise >> controller too. >> >> On Fri, 14 Jul 2006, Mark Lord wrote: >> >>> Justin Piszcz wrote: >>>> >>>> opcode=0x35 & opcode=0xca >>> >>> Those are non-DMA WRITE opcodes. Using PIO for I/O is pretty rare >>> these days, >>> so I'm betting that this is not a hard disk device -- compactflash? > > Okay. So why are we issuing PIO WRITE commands to drives that > obviously should only be sent DMA commands by libata? > > Perhaps that's the bug. Oh wait.. I remember this.. No, those are DMA commands, despite the misleading libata name for them. We went through this before last spring.. Okay. So I wonder what's really going on. The next step would be to instrument the interrupt handler, so that when it sees bad-status, it dumps out the stat/err values right then and there, before anything else can muck with them. It might also be good to have it dump out the controller engine's DMA status/err values, assuming the controller has registers for those. Then we should get a better picture of what's going on. Assuming the drives aren't lying to us (a perfectly good assumption here), then the controller must be aborting the transfer unexpectedly. Cheers