From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [PATCH] 2.6.17-rc5: the latest consensus libata resume fix Date: Sun, 28 May 2006 21:28:02 -0400 Message-ID: <447A4E22.8090508@garzik.org> References: <200605272245.30108.axboe@suse.de> <4478F681.8050607@garzik.org> <200605281128.00532.liml@rtr.ca> <20060528171424.GA12982@suse.de> <4479F487.5080507@garzik.org> <4479F76D.40506@rtr.ca> <447A03CC.50300@garzik.org> <20060528222832.GA26918@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:23738 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1751085AbWE2B2M (ORCPT ); Sun, 28 May 2006 21:28:12 -0400 In-Reply-To: <20060528222832.GA26918@suse.de> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jens Axboe , Mark Lord Cc: Linus Torvalds , "zhao, forrest" , Tejun Heo , linux-ide@vger.kernel.org Jens Axboe wrote: > On Sun, May 28 2006, Jeff Garzik wrote: >> Mark Lord wrote: >>> Jeff Garzik wrote: >>>> Jens Axboe wrote: >>>>> On Sun, May 28 2006, Mark Lord wrote: >>> .. >>>>>> int ata_device_resume(struct ata_port *ap, struct ata_device *dev) >>>>>> { >>>>>> if (ap->flags & ATA_FLAG_SUSPENDED) { >>>>>> + ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000); >>>>>> ap->flags &= ~ATA_FLAG_SUSPENDED; >>>>>> ata_set_mode(ap); >>>>> Sorry for the unresponsiveness, still away and internet connectivity >>>>> spotty. Just tested the above, and it works for me! I think Marks >>>>> analisys wrt DRQ is completely correct and this validates it. >>>> Does your box work without ATA_DRQ? >>> Without ATA_DRQ, we're back to the original Linus one-liner, >>> which Jens said did NOT work for him on Saturday. >> Indeed, but nowhere in the ATA Status printks did I ever see the DRQ bit >> asserted. It was all 80/50/50. > > Mark is right, ATA_BUSY alone does _not_ work for me. I agree it's a > little odd based on the printk output, it must be a timing thing. Its not a timing thing, because it consumes exactly the same amount of CPU cycles, and exactly the same amount of IO cycles. You're just testing a different static constant, that's it. It works and it's merged... If you and Mark would be kind enough to satisfy my paranoia, please test the current upstream kernel, without any additional patches, and make sure it works. Jeff