Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751192AbVJKWAq (ORCPT ); Tue, 11 Oct 2005 18:00:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751203AbVJKWAq (ORCPT ); Tue, 11 Oct 2005 18:00:46 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]:25304 "EHLO pne-smtpout2-sn1.fre.skanova.net") by vger.kernel.org with ESMTP id S1751192AbVJKWAp (ORCPT ); Tue, 11 Oct 2005 18:00:45 -0400 To: Guennadi Liakhovetski Cc: linux-kernel@vger.kernel.org, Jens Axboe Subject: Re: [2.6.13] pktcdvd: IO-errors References: From: Peter Osterlund Date: 11 Oct 2005 23:58:57 +0200 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2352 Lines: 51 Guennadi Liakhovetski writes: > On Sun, 9 Oct 2005, Peter Osterlund wrote: > > > In that case, this patch should also work. Does it? > > > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c > > index d4b9c17..cb6bda9 100644 > > --- a/drivers/block/pktcdvd.c > > +++ b/drivers/block/pktcdvd.c > > @@ -538,7 +538,7 @@ static void pkt_iosched_process_queue(st > > spin_unlock(&pd->iosched.lock); > > if (bio && (bio->bi_sector == pd->iosched.last_write)) > > need_write_seek = 0; > > - if (need_write_seek && reads_queued) { > > + if (!writes_queued && reads_queued) { > > if (atomic_read(&pd->cdrw.pending_bios) > 0) { > > VPRINTK("pktcdvd: write, waiting\n"); > > break; > > Well, I've had this patch (to 2.6.13) failing once, whereas I still > haven't been able to reproduce the error with your previous patch. What > now? A bit worrying is that test results are not 100% deterministic now... > Which means, until recently my standard test (copy about 150M co the > CD-RW && sync) produced always consistent results, now I've seen a couple > of times the same driver version either failing or succeeding... My current theory is that there is something wrong with the firmware or hardware in your drive, and different I/O patterns have different probabilities of triggering this problem. Maybe you could use Jens' IO tracing patch to identify the sequence of commands that make the drive fail. See subject "[PATCH] Block device io tracing" posted by Jens earlier today. If the problem is always caused by some well defined sequence of commands, it might be possible to implement a workaround in the pktcdvd driver. > BTW, Peter, I still get errors from mails to you: > > : > 81.228.8.84_does_not_like_recipient./Remote_host_said:_553_RCPT_TO:_refused/G > iving_up_on_81.228.8.84./ It seems like my ISPs mail server doesn't want to talk to your mail server. I have no idea why. I did get mails from you earlier. -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/