[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.047 / U:3.164 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site