[8900] in linux-scsi channel archive
Re: sg bug fixes
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri May 26 06:29:32 2000
Message-ID: <016601bfc6f8$34a8f3e0$0f17a8c0@eric.home>
From: "Eric Youngdale" <eric@andante.org>
To: "Roman Zippel" <zippel@fh-brandenburg.de>,
"Douglas Gilbert" <dgilbert@interlog.com>
Cc: <linux-scsi@vger.rutgers.edu>
Date: Fri, 26 May 2000 05:53:12 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
----- Original Message -----
From: "Roman Zippel" <zippel@fh-brandenburg.de>
To: "Douglas Gilbert" <dgilbert@interlog.com>
Cc: <linux-scsi@vger.rutgers.edu>
Sent: Friday, May 26, 2000 4:24 AM
Subject: Re: sg bug fixes
> Hi,
>
> > Back to the reported bug fixes and a question. Was there
> > some observed problems that these fixes solved?
>
> I have a multithreaded application, where one thread reads the results
> from the device and the others can write to it. Under load I had two
> problems:
> - sg_read() was too fast, so the sg_command_done() didn't find the request
> in the list.
> - If the sd device tries to do something at the same time,
> scsi_allocate_device() fails and do_sd_request() simply returns and it
> stops until the next request is coming, so I needed to restart it somehow.
This shouldn't happen. Well, actually, with 2.2 kernels, anything could
happen given the horrible way the queueing is structured. In 2.4 it should
never happen at all.
Actually, once I get around to fixing sg to use Scsi_Request instead, things
would be even cleaner.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu