Scroll to navigation

sane-scsi(5) SANE Scanner Access Now Easy sane-scsi(5)

BEZEICHNUNG

sane-scsi - SCSI-Adapter-Tipps für Scanner

BESCHREIBUNG

Diese Handbuchseite enthält verschiedene betriebssystemabhängige Tipps und Tricks, wie Sie Scanner mit einer SCSI-Schnittstelle zum Laufen bekommen.

ALLGEMEINE INFORMATIONEN

Für Scanner mit einer SCSI-Schnittstelle kann es notwendig sein, die geeignete Backend-Konfigurationsdatei zu bearbeiten, bevor SANE erstmalig verwendet wird. Für die meisten Systeme sollte die Konfigurationsdatei die Namen der generischen SCSI-Geräte aufführen, mit denen der Scanner verbunden ist (z.B. ist unter Linux /dev/sg4 oder /dev/sge ein solches generisches SCSI-Gerät). Es ist üblich, einen Symlink von /dev/scanner auf das generische SCSI-Gerät zu erstellen, mit dem der Scanner verbunden ist. In diesem Fall führt die Konfigurationsdatei einfach die Zeile /dev/scanner auf. Für eine detaillierte Beschreibung der Backend-Konfigurationsdateien schauen Sie bitte in die Handbuchseite des relevanten Backends (z.B. sane-epson(5) für Epson-Scanner, sane-hp(5) für HP-Scanner usw.).

Bei einigen Betriebssystemen (z.B. Linux und OS/2) gibt es eine alternative Möglichkeit, Scanner-Geräte festzulegen. Diese alternative Art ermöglicht es, Scanner über den SCSI-Lieferanten und die Modellbezeichnungs-Zeichenkette und/oder über die SCSI-Geräte-Adresse (bestehend aus der Bus-Nummer, der Kanalnummer, der Kennung und der logischen Einheitennummer) zu identifizieren. Die Syntax für die Festlegung eines Scanners auf diese Art ist wie folgt:

scsi LIEFERANT MODELL TYP BUS KANAL KENNUNG LUN

wobei LIEFERANT die Zeichenkette mit dem SCSI-Lieferanten, MODELL ist die SCSI-Modellbezeichnungs-Zeichenkette, TYP ist die SCSI-Gerätetypzeichenkette, BUS ist die SCSI-Bus-Nummer (genannt »host« in /proc/scsi/scsi), KANAL ist die SCSI-Kanalnummer, KENNUNG ist die SCSI-Kennung und LUN ist die logische Einheitennummer des Scanner-Geräts. Die ersten zwei Felder sind Zeichenketten, die in doppelten englischen Anführungszeichen eingeschlossen werden müssen, falls sie Leerraumzeichen enthalten. Die verbleibenden vier Felder sind nicht-negative Ganzzahlen. Die korrekten Werte für diese Felder können mit betriebssystemspezifischen Werkzeugen ermittelt werden, z.B. für Linux durch Prüfen der Ausgabe des Befehls cat /proc/scsi/scsi. Um die Konfiguration zu erleichtern, kann der Wert eines Feldes durch ein Sternsymbol (»*«) ersetzt werden. Ein Stern hat den Effekt, dass für dieses bestimmte Feld jeder Wert erlaubt ist. Dies kann dazu führen, dass eine einzelne SCSI-Zeile auf mehrere Geräte passt. Wenn dies passiert, wird nacheinander jedes passende Gerät durch das Backend geprüft und registriert, falls das Backend glaubt, dass dies ein kompatibles Gerät ist. Die Zeile

scsi MUSTEK MFS-06000CX Scanner 0 00 03 00

würde beispielsweise einen Mustek-SCSI-Scanner mit dem folgenden /proc/scsi/scsi-Eintrag anhängen:

Host: scsi0 Channel: 00 Id: 03 Lun: 00


  Vendor: MUSTEK   Model: MFS-06000CX Rev: 4.04


  Type:   Scanner  ANSI SCSI revision: 0

Normalerweise reicht es aus, nur die Zeichenketten für den Lieferanten und das Modell oder sogar nur für den Lieferanten zu verwenden. Das folgende Beispiel

scsi MUSTEK * * * * * *

hätte den Effekt, das alle SCSI-Geräte in dem System, deren Lieferantenzeichenkette MUSTEK lautet, geprüft und durch das Backend registriert würden.

Falls der Rest einer SCSI-Zeichenkette nur aus Sternchen besteht, können die Sternchen entfallen. Beispielweise ist die folgende Zeile äquivalent zu der vorher festgelegten:

scsi MUSTEK

Auf einigen Plattformen (z.B. OpenStep) nehmen die SANE-Gerätenamen eine besondere Form an. Dies ist nachfolgend in dem relevanten Plattform-spezifischen Abschnitt beschrieben.

Beim Einsatz von SCSI-Scannern stellen Sie sicher, dass die Zugriffsberechtigungen für das generische SCSI-Gerät geeignet gesetzt sind. Wir empfehlen, eine Gruppe »scanner« zu /etc/group hinzuzufügen, die alle Benutzer enthält, die Zugriff auf den Scanner haben sollen. Die Berechtigungen für das Gerät sollten dann so gesetzt werden, dass sie der Gruppe Lese- und Schreibzugriff erlauben. Falls der Scanner beispielsweise das generische SCSI-Gerät /dev/sg0 ist, dann würden die folgenden zwei Befehle die Berechtigungen korrekt setzen:

$ chgrp scanner /dev/sg0
$ chmod 660 /dev/sg0

Wenn Ihr System das Gerätedateisystem (devfs) verwendet, müssen Sie /etc/devfs/perms bearbeiten. Dort müssen Sie nach der Zeile

REGISTER ^sg[^/]* PERMISSIONS root.root 0600

suchen, und eine neue Zeile (z.B. zur Änderung der Berechtigung von sg4) hinzufügen:

REGISTER ^sg4 PERMISSIONS root.scanner 0660

FREEBSD-INFORMATIONEN

Die automatische Konfiguration mittels der Zeilen »scsi *« in den Konfigurationsdateien funktioniert nur, falls der Benutzer, der die Oberfläche ausführt, Lese-/Schreibzugriff auf /dev/xpt0 hat. Sie können stattdessen auch einen Link /dev/scanner auf das geeignete Gerät /dev/uk setzen.

Läuft Berichten zu Folge gut unter FreeBSD 2.2.2R mit dem Treiber aha.
Soll unter FreeBSD 2.2.2 gut laufen.
Der Scanner wird korrekt erkannt, aber jeder Zugriffsversuch darauf hängt das gesamte System auf. Es sieht so aus, als ob etwas Interrupts deaktivieren und dann nicht wieder aktivieren würde, es sieht also wie ein Fehler im Treiber aic von FreeBSD aus.
Funktioniert unter FreeBSD 2.2.5R und 3.0 mittels des Treibers aic, vorausgesetzt, dass die Unterstützung für »Plug-and-Play« für die Karte deaktiviert ist. Falls es keine uk-Geräte gibt, führen Sie einfach ein sh MAKEDEV uk0 in dem Verzeichnis /dev durch. Auf den Scanner sollte dann über /dev/uk0 zugegriffen werden können, so, als ob er während des Systemstarts erkannt worden wäre.
Soll unter FreeBSD 2.2.2R mit dem Treiber amd gut laufen.

LINUX-INFORMATION

Als erstes stellen Sie bitte sicher, dass die generische SCSI-Unterstützung im Kernel aktiviert ist. In make xconfig taucht dies unter »SCSI support->SCSI generic support« auf.

Um Scanzeiten zu minimieren, wird nachdrücklich empfohlen, einen großen Puffer für den generischen SCSI-Treiber zu verwenden. Seit SG-Treiber Version 2.0 kann die Puffergröße zur Laufzeit verändert werden und es gibt keine Größenbeschränkung. Diese Treiberversion ist seit Version 2.2.7 Teil des Linux-Kernels. Falls der neuere SG-Treiber verfügbar ist, erbitten einige Backends (z.B. sane-umax(5), sane-mustek(5), sane-sharp(5)) automatisch größere Puffergrößen. Falls ein Backend nicht automatisch einen größeren SCSI-Puffer anfordert, setzen Sie die Umgebungsvariable SANE_SG_BUFFERSIZE auf die gewünschte Puffergröße in Byte. Es wird nicht empfohlen, mehr als 1 Megabyte zu verwenden, da für größere Werte die Wahrscheinlichkeit zunimmt, dass der SG-Treiber den/die notwendigen Puffer nicht reservieren kann. Für ISA-Karten kann selbst 1 MB ein zu großer Wert sein. Für eine detaillierte Beschreibung von Speicherproblemen des SG-Treibers lesen Sie http://www.torque.net/sg.

Für Linux-Kernel vor Version 2.2.7 ist die Puffergröße nur 32 kB. Das funktioniert, aber viele günstigere Geräte scannen dadurch nur noch mit ungefähr einem Viertel der Geschwindigkeit wie bei der Verwendung von 127 kB. Linux definiert die Größe dieses Puffers durch das Makro SG_BIG_BUFF in der Header-Datei /usr/include/scsi/sg.h. Wenn das System nicht extrem speicherarm ist, wird empfohlen, diesen Wert auf den maximal gültigen Wert von 128*1024-512=130560 byte zu erhöhen. Nach der Änderung dieses Werts ist es notwendig, sowohl den Kernel (oder das generische SCSI-Modul) als auch die SCSI-Backends neu zu kompilieren. Beachten Sie, dass dies nur mit älteren Linux-Kerneln notwendig ist.

Ein häufiges Problem bei SCSI-Scannern besteht darin, was Sie machen müssen, wenn Sie Ihr System gestartet haben, während der Scanner ausgeschaltet war? In diesem Fall wird der Scanner nicht vom Kernel erkannt und SANE ist nicht in der Lage, darauf zuzugreifen. Glücklicherweise stellt Linux einen einfachen Mechanismus bereit, um bei Bedarf nach SCSI-Geräten zu suchen. Nehmen wir an, Ihr Scanner hängt an SCSI-Bus 2 und der Scanner hat die SCSI-Kennung 5. Wenn das System hochgefahren ist und der Scanner eingeschaltet ist, können Sie folgenden Befehl eingeben:

echo "scsi add-single-device 2 0 5 0" > /proc/scsi/scsi

Dann wird der Kernel Ihren Scanner untersuchen und erkennen (dies muss als Root erfolgen). Es ist auch möglich, ein SCSI-Gerät dynamisch mit dem Befehl »remove-single-device« zu entfernen. Für Details schauen Sie bitte in das SCSI-2.4-HOWTO.

Scanner funktionieren bekanntermaßen mit den nachfolgend aufgeführten SCSI-Adaptern unter Linux. Die Liste ist nicht vollständig, normalerweise sollte jeder unter Linux unterstützte SCSI-Adapter funktionieren.

Einige alte Versionen des Kerneltreibers (atp870u.c) schnitten die Abfrageinformationen ab. Daher konnte der Scanner nicht korrekt erkannt werden. Verwenden Sie einen aktuellen Kernel.
Soll unter Linux seit Version 2.0 gut funktionieren. Falls der Kernel bei Ihnen einfriert oder anderes unerwartetes Verhalten auftritt, verwenden Sie den neusten Kernel (2.2.17 scheint zu funktionieren) oder reduzieren Sie die SCSI-Puffergröße auf 32 kB.
Soll unter Linux seit Version 2.0 gut funktionieren.
Zur Konfiguration des BusLogic-Karte könnte es notwendig sein, den folgenden Anweisungen (beigesteuert von Jeremy <jeremy@xxedgexx.com>) zu folgen: Während des Systemstarts, wenn Ihr BusLogic-Adapter initialisiert wird, drücken Sie Strg-B, um in das BusLogic-Adapter-Setup zu kommen. Wählen Sie die Adresse, unter der Ihr Scanner im BusLogic enthalten ist. Wählen Sie »SCSI Device Configuration«. Wählen Sie »Scan SCSI Bus«. Wählen Sie die SCSI-Kennung, die Ihr Scanner enthält, aus und wählen Sie dann »View/Modify SCSI configuration«. Ändern Sie »Negotiation« auf »async« und »Disconnect« auf »off«. Drücken Sie Esc, speichern Sie und erneut Esc, bis Sie zum Neustart aufgefordert werden.
Diese Karte wird von Mustek (und anderen Lieferanten) bereitgestellt. Sie wird seit Linux 2.2 unterstützt. Die SCSI-Karten werden von dem Modul »g_NCR5380« unterstützt. Es ist notwendig, dem Kernel den E/A-Port und den Typ der Karte mitzuteilen. Beispiel für ein 53c400a: modprobe g_NCR5380 ncr_addr=0x280 ncr_53c400a=1. Sobald der Kernel die Karte erkennt, sollte alles korrekt funktionieren. Obwohl alles funktioniert, erwarten Sie keine gute Leistung von dieser Karte. Sie verfügt über keine Interrupt-Leitung und daher wird das System fast unbenutzbar, während der Scan läuft. Sie können den Wert des Makros USLEEP in drivers/scsi/g_NCR5380.c ändern. Etwas Dokumentation befindet sich in dieser Datei und in NCR5380.c.
Bei einigen Scannern kann es notwendig sein, »disconnect/reconnect« zu deaktivieren. Um dies zu erreichen, verwenden Sie die Option ncr53c8xx="disc:n". Einige Leute berichten, dass ihr Scanner nur mit dem Treiber »53c7,8xx« funktioniert, nicht mit dem »ncr53c8xx«. Verwenden Sie beide, wenn Sie Probleme haben.
Für Linux-Kernel vor 2.0.33 kann es notwendig sein, die SCSI-Zeitüberschreitung zu erhöhen. Die Vorgabezeitüberschreitung für Linux-Kernel vor 2.0.33 ist 10 Sekunden, was für das Scannen großer Bereiche zu klein ist. Falls Sie Nachrichten der Form »restart (ncr dead ?)« in Ihrer Datei /var/log/messages oder auf der System-Konsole erhalten, ist das ein Anzeichen, dass die Zeitüberschreitung zu klein ist. In diesem Fall, suchen Sie die Zeile »if (np->latetime>10)« in der Datei ncr53c8xx. (normalerweise im Verzeichnis /usr/src/linux/drivers/scsi) und ändern die Konstante auf beispielsweise 60 (eine Minute). Dann bauen Sie das Kernelmodul neu und versuchen es erneut.
Der Treiber kann von http://www.garloff.de/kurt/linux/dc395/ heruntergeladen werden. Für einige ältere Scanner kann es notwendig sein, sämtliche fortgeschrittene Funktionalitäten zu deaktivieren, beispielsweise mittels modprobe dc395x_trm dc395x_trm=7,5,1,32.
Version 1.11 des Tekram-Treibers scheint größtenteils korrekt zu funktionieren, außer dass der Scan nicht korrekt beendet wird (er führt zu einer SCSI-Zeitüberschreitung nach 10 Minuten). Der generische AM53C974 scheint auch korrekt zu funktionieren und leidet nicht unter den Zeitüberschreitungsproblemen.

SOLARIS-, OPENSTEP- UND NEXTSTEP-INFOMATION

Unter Solaris, OpenStep und NeXTStep bezieht sich der generische SCSI-Gerätename auf einen SCSI-Bus, nicht ein individuelles Gerät. Beispielsweise bezieht sich /dev/sg0 auf den ersten SCSI-Bus. Um SANE mitzuteilen, welches Gerät verwendet werden soll, hängen Sie das Zeichen »a«+Zielkennung an den besonderen Gerätenamen an. Das SCSI-Gerät, das am ersten SCSI-Controller mit der Zielgerätekennung 0 hängt, würde beispielsweise /dev/sg0a genannt werden und das Gerät mit der Zielgerätekennung 1 auf dem gleichen Bus würde /dev/sg0b genannt werden und so weiter.

UMGEBUNGSVARIABLEN

Falls die Bibliothek mit aktivierter Debug-Unterstützung kompiliert wurde, steuert diese Umgebungsvariable die Debug-Stufe für das generische SCSI-E/A-Subsystem. Ein Wert von 128 fordert beispielsweise, dass sämtliche Debug-Ausgabe vom Backend dargestellt wird. Ein Wert von 255 gibt auch die Kernelnachrichten vom SCSI-Subsystem aus (soweit verfügbar). Kleinere Stufen reduzieren die Ausführlichkeit.
setzt den Zeitüberschreitungswert für SCSI-Befehle in Sekunden. Nur bei sehr langsamen Scannern sollte das Außerkraftsetzen des Vorgabewertes von 120 Sekunden notwendig sein.

SIEHE AUCH

sane(7), sane-find-scanner(1), sane-"backendname"(5), sane-usb(5)

AUTOR

David Mosberger

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.

14. Juli 2008