# Re: SG_BIG_BUFF setting in Problems incorrect

From: Douglas Gilbert (dgilbert@interlog.com)
Date: Thu Feb 03 2000 - 19:49:33 PST

- Next message: Bill Wohler: "Re: new snapshot?"
  - Previous message: Petter Reinholdtsen: "Re: new snapshot?"
  - In reply to: Bill Wohler: "SG_BIG_BUFF setting in Problems incorrect"
  - Next in thread: Bill Wohler: "Re: SG_BIG_BUFF setting in Problems incorrect"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Bill Wohler wrote:
  >
  > I just installed DEVEL_1_9 from the CVS repository and couldn't get
  > to my scanner (HP Photosmart SCSI, running under a Linux 2.2.1
  > kernel).

  Linux kernels < 2.2.6 (including RH 6.0) have the original sg driver
  (what I now call version 1). So an unpatched lk 2.2.1 has the original
  sg driver.

  > Thanks to the debugging output, the problem was clear:
  >
  > [wohler@gbr:587]% SANE_DEBUG_SANEI_SCSI=128 SANE_DEBUG_HP=128 scanimage
  > ...
  > [sanei_scsi] sanei_scsi_open: could not allocate SG buffer memory wanted: 131072 got: 32768

  With the original sg driver you are unable to change the buffer
  memory size dynamically (via an ioctl). So any attempt to change
  the default will fail and you will be left with the compiled
  in default.

  Worse, in the original driver there is only one SG_BIG_BUFF
  sized buffer available at any one time (other users would
  be restricted to a 4 KB maximum buffer size). So running
  SANE and cdrecord on the original sg driver at the same
  time is almost guaranteed to fail.
  > The sane-scsi manpage suggested bumping SG_BIG_BUFF in
  > /usr/src/linux/include/scsi/sg.h to 128*1024-512=130560 bytes, but
  > this doesn't work. After bumping SG_BIG_BUFF to 128*1024=131072
  > bytes, recompiling the kernel, rebooting, and recompiling sane, all
  > was well (phew!). I would suggest updating the sane-scsi man page
  > with the correct value to save others from an extra kernel compiling
  > step.

  SG_BIG_BUFF in the original sg driver needs to be a power of 2
  (I think). That SG_BIG_BUFF hack should only be done on the
  original sg driver which is what you seem to have. If you
  upgraded just your sg driver rather than the whole kernel
  then hopefully that "could not allocate" debug message would
  go away. For example you could get the sg driver version 2.1.36
  (as used in lk 2.2.14) from the table at
  http://www/torque.net/sg

  I agree that the man page could do with some fine tuning
  in this area.
  > Also, the Problems document mentions that newer kernels (>=2.2) can
  > get the value from /proc/sys/kernel/sg-big-buff. I have 2.2.1 and
  > this file is not present.

  This file is only present if sg is built into the kernel (i.e. it is
  _not_ a module). As far as I can see it has always been like this.
  Using this file has never been a very sound tecnique IMHO.

  > Note that the 1.0.1 snapshot was working previously although I had
  > not updated the value of SG_BIG_BUFF.

  This is a worry. Time I had a close look at that code in SANE.
  It seems pretty important to keep backward compatibility with
  the original linux sg driver. Is the problem just in the HP
  backend or common to all backends, I wonder. If any tester with
  a recent 2.2 series linux kernel wants to test backward
  compatibility with the original sg driver then they can get
  it at the above website.

  Doug Gilbert
  linux sg maintainer

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Bill Wohler: "Re: new snapshot?"
  - Previous message: Petter Reinholdtsen: "Re: new snapshot?"
  - In reply to: Bill Wohler: "SG_BIG_BUFF setting in Problems incorrect"
  - Next in thread: Bill Wohler: "Re: SG_BIG_BUFF setting in Problems incorrect"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Thu Feb 03 2000 - 19:40:26 PST