lkml.org 
[lkml]   [2005]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [2.6.13] pktcdvd: IO-errors
    From
    Date
    Guennadi Liakhovetski <g.liakhovetski@gmx.de> 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:
    >
    > <petero2@telia.com>:
    > 81.228.8.84_does_not_like_recipient./Remote_host_said:_553_RCPT_TO:<petero2@telia.com>_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/

    \
     
     \ /
      Last update: 2005-10-12 00:03    [W:0.024 / U:120.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site