Henning Meier-Geinitz wrote:
>
> Hi,
>
> I have some comments/questions on the sg buffer size on Linux kernels
> before 2.2.7 (2.2.5 in this case). I got a bug report for this one. I
> know this could be fixed by increasing the buffer size in the kernel
> includes or by telling the backend (mustek in this case) not to use
> more than 32k.
>
> 1) In README there is a comment: "--enable-scsibuffersize and
> SANE_SG_BUFFERSIZE have no effect for the Mustek, Umax and
> Sharp backends.". This is not true, at least for the mustek
> backend. In this backend you can set the buffer size in the config
> file, but if one of the two methods above is used, the buffer size
> is not bigger then the specified. E.g. mustek.conf: buffersize=128
> (on kilobytes), SANE_SG_BUFFERSIZE=32768 --> real (maximum)
> buffer size = 32768.
>
> 2) Is there any way to detect from a backend how big the available
> buffersize is? I'm using sanei_scsi_open extended and it tells me
> that 128 k is ok even if the kernel doesn't support it. So the
> question is: Must the user set the size to 32k manually (or modify
> the kernel) or is there some other way?
Hi Henning,
You are right; it should read "--enable-scsibuffersize and
SANE_SG_BUFFERSIZE have no effect for the Mustek, Umax and Sharp
backends, if a suffiently new SG driver is being used." (Sorry, I don't
know, when exactly the ioctl calls SG_[GS]ET_RESERVED_SIZE were
introduced) For old SG drivers, which don't support these ioctl calls,
and which also don't have the pseudo file /proc/sys/kernel/sg-big-buff,
sanei_scsi_open_extended indeed must use sanei_scsi_max_request_size,
which in turn can be set by --enable-scsibuffersize and
SANE_SG_BUFFERSIZE.
If both --enable-scsibuffersize and SG_BIG_BUFF are set to 128 kB during
Sane compilation, while SG_BIG_BUFF is set the default 32kB during
kernel compilation, you'll get the old well known inconsistency for the
old SG drivers. The only way to fix this is to set SANE_SG_BUFFERSIZE or
to avoid the inconsistency.
>
> 3) Here is a log from the failing command:
>
> [mustek] reader_process: buffer 1: entering read request for 65484 bytes (buffer 1)
> [sanei_scsi] sanei_scsi_req_enter2: Command: 28 00 00 00 00 00 00 00 6b 00
> [sanei_scsi] scsi_req_enter: entered 0x4038b008
> [sanei_scsi] sanei_scsi.issue: 0x4038b008
> [sanei_scsi] sanei_scsi.issue: bad write (errno=12) Nicht genügend Hauptspeicher verfügbar -1
> [sanei_scsi] sanei_scsi.issue: SG_BIG_BUF inconsistency? Check file PROBLEMS.
> [sanei_scsi] scsi_req_enter: queue_used: 0, queue_max: 1
> [mustek] reader_process: buffer 1: entered (line 107 of 835, buffer 1)
>
> Wouldn't it be nicer to return an error from sanei_scsi_req_enter
> instead of ignoring the situation? The error comes up later when
> waiting for the buffer:
>
> [mustek] reader_process: buffer 1: waiting for request to be ready
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x4038b008
> [sanei_scsi] sanei_scsi.issue: 0x4038b008
> [sanei_scsi] issue: ENOMEM - cannot queue SCSI command. Trying again later.
> [sanei_scsi] sanei_scsi.issue: 0x403ac008
> [sanei_scsi] issue: ENOMEM - cannot queue SCSI command. Trying again later.
> [mustek] reader_process: failed to read data, status: Out of memory, buffer: 1
Well, the error report could of course be added to sanei_scsi_req_enter,
but a backend should check for this error in sanei_scsi_req_wait too: If
you queue two or more commands and the low level driver does not support
command queueing, sanei_scsi_req_enter puts the second and following
commands into its internal queue, so it cannot return an error from the
SG driver.
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sun Jul 15 2001 - 09:00:35 PDT