[lkml]   [1997]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Race conditions galore (2.0.33 and possibly 2.1.x)
    Gerard Roudier wrote:
    >The patch that fixes your problem makes differences when an interrupt
    >from the SCSI controller that will unlock the buffer occurs during the
    >queuing of disk requests.
    >As stated by Linus and Bill, and probably checked by lots of other people,
    >your change should not make differences on the wait_on_buffer() final

    True. The only thing that could arguably be influenced by my patch
    is that we do not reset current->state to TASK_UNINTERRUPTIBLE
    after it (apparently) has changed from within run_task_queue(&tq_disk)
    *without* unlocking the buffer.
    The buffer is then unlocked later, without setting the task to being
    runnable again.

    >Given the strangeness of the problem you reported, checking the effect
    >of not using 'write and invalidate' should help, IMO.
    >Trying another CPU, for example a PENTIUM, should help too.

    I wanted to wait for patches in the md driver.
    But, if that doesn't happen soon, I guess I could change the "write
    and invalidate" behaviour.

    >> eth0: DC21041 at 0xe000 (PCI bus 0, device 11), h/w address 00:80:48:e8:67:ee,
    >> and requires IRQ10 (provided by PCI BIOS).

    >This board is also master capable.

    I know. It does. I only use master capable devices.
    Stephen R. van den Berg (AKA BuGless).

    To boldly program, where *no* man has programmed before!

     \ /
      Last update: 2005-03-22 13:40    [W:0.019 / U:15.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site