[3361] in linux-scsi channel archive
Re: Bug in new SCSI code
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Wed Feb 18 23:05:57 1998
Date: Wed, 18 Feb 1998 23:29:08 -0500 (EST)
From: Eric Youngdale <eric@andante.jic.com>
Reply-To: Eric Youngdale <eric@andante.jic.com>
To: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
cc: torvalds@transmeta.com, linux-scsi@vger.rutgers.edu
In-Reply-To: <199802181253.NAA17123@sunsite.ms.mff.cuni.cz>
On Wed, 18 Feb 1998, Jakub Jelinek wrote:
> Hi Linus, hi linux-scsi!
>
> When converting SSA (pluto) driver I found a bug in scsi.c, which apparently
> does not show up on the other use_new_eh_code aha1542, but as soon as
> further drivers will be converted to use_new_eh_code, it can be seen on many
> other HBAs as well.
> The problem is that author of new scsi_done (Eric Youngdale?) thought no
> more than two scsi_done calls can happen before their bh is serviced.
Yes, it is my code, but there is no such assumption in the code.
There is however a performance enhancement that you are seeing. The
general idea is that if the list is empty, then we can insert something
into the head of the linked list in an atomic operation without incurring
the overhead of turning off interrupts. If there was already a request
in the list, then we grab the lock and insert it.
This isn't to say that there aren't bugs - there could very well
be, and if you have seen evidence of it, then we can look at it.
> Even then I think there are races. But e.g. in pluto, it calls scsi_done
> from one interrupt as many times as needed until there are no entries in the
> incoming queue, so it can be up 64 scsi_done's just from one single array
> before bh is serviced (and during do_bottom_half interrupts are enabled, so
> further can come from other HBAs). This leads to unhandled lost SCpnts,
> which is not what we probably want.
Have you any evidence that requests are being lost in the bottom
half queue, or are you losing requests somewhere and are speculating that
this is what is happening?
-Eric
