# Re: sanei_scsi_cmd / snapscan / Prisa640S

From: Douglas Gilbert (dgilbert@interlog.com)
Date: Thu Jan 11 2001 - 07:43:54 PST

- Next message: Joseph chock: "Dynotak 6P parallel port scanner . . ."
  - Previous message: Douglas Gilbert: "Re: MICROTEK2 failure : out of memory with kernel 2.4"
  - In reply to: Christian Nassau: "sanei_scsi_cmd / snapscan / Prisa640S"
  - Next in thread: Christian Nassau: "Re: sanei_scsi_cmd / snapscan / Prisa640S"
  - Reply: Christian Nassau: "Re: sanei_scsi_cmd / snapscan / Prisa640S"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Christian Nassau wrote:
  >
  > I'm currently trying to get an Acer ScanPrisa640S (patched atp870u
  > scsi driver, kernel version 2.2.16) working with a (modified) snapscan
  > backend. I had the following problem...
  >
  > aborting scanimage in the middle of a scan with CRTL-C leads
  > to a system lock (requiring an instant reboot).
  >
  > ...and have found that sanei_scsi_cmd(..) only protects the
  > scsi read and write instructions individually against user
  > breaks. The SCSI-Programming-FAQ (dated 1997) that I have says
  > that the **pair** (write/read) has to be protected, because
  > otherwise very bad things will happen... (depending on the
  > kernel version)...
  >
  > ... so, I've created a wrapper "sanei_scsi_protected_cmd(..)" and
  > made snapscan use this function, and -- alas! -- userbreaks are
  > safe now.
  >
  > Couldn't one make sanei_scsi_cmd(..) protected by default, or at
  > least provide a protected alternative? (or make the Makefile decide
  > which one to install, based on the kernel version?)

  Christian,
  Almost 2 years ago, the Linux sg driver was secured against
  a control-C induced failures. The latest SCSI-Programming-HOWTO
  that I can find is dated 7th May 1996 and what it said was
  correct then. Are you using the sg driver that came with
  lk 2.2.16 ?

  The level of protection provided against a control-C
  prematurely terminating the sane process is to safely
  receive and dispose of any responses that arrive after
  the sg device fds have been closed. It is possible that
  the scanner gets upset because a subsequent SCSI command
  (e.g. RECEIVE) is not transmitted.

  To debug such a lockup is difficult. Do the CapsLock and
  NumLock keys still operate the LEDs on the keyboard? If
  so, Alt-SysRq ("p" and "t") may gather some information.
  Do you have a SCSI disk with your root partition on
  the same SCSI bus as the scanner?

  So I think you have a very "special" case that does
  not require the sanei interface to be changed. The
  problem with such a lock, is that it will make SANE
  inoperable for the timeout period (often 10 minutes)
  if the scanner locks up before sending a response.

  Doug Gilbert

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

  - Next message: Joseph chock: "Dynotak 6P parallel port scanner . . ."
  - Previous message: Douglas Gilbert: "Re: MICROTEK2 failure : out of memory with kernel 2.4"
  - In reply to: Christian Nassau: "sanei_scsi_cmd / snapscan / Prisa640S"
  - Next in thread: Christian Nassau: "Re: sanei_scsi_cmd / snapscan / Prisa640S"
  - Reply: Christian Nassau: "Re: sanei_scsi_cmd / snapscan / Prisa640S"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Thu Jan 11 2001 - 07:23:25 PST