Provided by: manpages-de_4.21.0-2_all 

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.
Adaptec AHA1542CF
Läuft Berichten zu Folge gut unter FreeBSD 2.2.2R mit dem Treiber aha.
Adaptec 2940
Soll unter FreeBSD 2.2.2 gut laufen.
Adaptec 1522
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.
Adaptec 1505
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.
Tekram DC390
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.
Acard/Advance SCSI-Adapter
Einige alte Versionen des Kerneltreibers (atp870u.c) schnitten die Abfrageinformationen ab.
Daher konnte der Scanner nicht korrekt erkannt werden. Verwenden Sie einen aktuellen
Kernel.
Adaptec AHA-1505/AHA-1542/AHA-2940
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.
ASUS SC200
Soll unter Linux seit Version 2.0 gut funktionieren.
BusLogic BT958
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.
NCR/Symbios 53c400/53c400a oder Domex DTC3181E/L/LE (DTCT436/436P) ISA-SCSI-Karte
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.
NCR/Symbios 810
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.
Tekram DC315
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.
Tekram DC390
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
SANE_DEBUG_SANEI_SCSI
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.
SANE_SCSICMD_TIMEOUT
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 sane-scsi(5)