Hallo Erich, Am Montag, 4. Juni 2001 23:30 schrieb Erich Vilter:
On Sat, 2 Jun 2001, Bernd Schwab wrote:
Hallo Erich,
[snip]
Beim Aufruf von xscanimage erhalte ich folgende Meldungen modprobe: Can't locate module char-major-81 last message repeated 4 times kernel: Detected scsi generic sg6 at scsi1, channel 0, id 6, lun 0, type 6 Dies scheint mir bedenklich. Was geht hier schief?
evtl mal 'xscanimage /dev/sg6' ... aber ACHTUNG! Hast Du den Scanner denn schon mal mit yast1 eingerichtet? (nachdem Du den Treiber fuer den 152x geladen hast)
Und dann mal noch 'man xscanimage'. Da steht auch noch was drinnen, wegens Uebergabe eines Parameters zum DEVICE.
Danke fuer Deine Anregungen. Leider noch kein Erfolg. Die Einrichtung mit yast1 habe ich nochmals ueberprueft; duerfte ok sein. 'man xscanimage' hat mich nicht viel schlauer gemacht. Hast Du evtl. noch konkrete Hinweise hierzu? Ich habe dies aber zum Anlass genommen, mir 'man scanimage' etwas genauer anzusehen. Scheint ein paar Moeglichkeiten mehr zu besitzen. Folgendes habe ich daraufhin probiert: scanimage -h liefert: microtek2:/dev/sg6 Sieht nicht schlecht aus. Mit export SANE_DEBUG_MICROTEK2=128 auf "geschwaetzig" gestellt scanimage -h liefert nun ca. 160 Zeilen output. Hier zunaechst nur drei Ausschnitte, die mir bedenklich erscheinen:
[sanei_debug] Setting debug level of microtek2 to 128. [microtek2] sane_init: Microtek2 (v0.8) says hello... [microtek2] parse_config_file: fp=0x8050930 [microtek2] attach_one: name='option dump 1' [microtek2] add_device_list: device='option dump 1' [microtek2] attach: device='option dump 1' [microtek2] scsi_inquiry: mi=0x8050b24, device='option dump 1' [microtek2] scsi_inquiry: 'Invalid argument' [microtek2] attach: 'Invalid argument'
[microtek2] scsi_read_attributes: mi=0x80514d4, device='/dev/sg6', source=0 [microtek2] scsi_read_attributes: mi=0x80515d4, device='/dev/sg6', source=2 [microtek2] scsi_read_attributes: mi=0x8051554, device='/dev/sg6', source=1 [microtek2] scsi_read_system_status: md=0x80514d0, fd=-1 [microtek2] scsi_test_unit_ready: md=/dev/sg6 [microtek2] attach: device='option dump 1' [microtek2] scsi_inquiry: mi=0x8050b24, device='option dump 1' [microtek2] scsi_inquiry: 'Invalid argument' [microtek2] attach: 'Invalid argument' [microtek2] sane_get_devices: attach status 'Invalid argument' [microtek2] sane_open: device='/dev/sg6'
[microtek2] scsi_test_unit_ready: md=/dev/sg6 [microtek2] attach: device='option dump 1' [microtek2] scsi_inquiry: mi=0x8050b24, device='option dump 1' [microtek2] scsi_inquiry: 'Invalid argument' [microtek2] attach: 'Invalid argument' [microtek2] sane_get_devices: attach status 'Invalid argument' [microtek2] sane_exit: [microtek2] sane_close: ms=0x8051eb0 [microtek2] cleanup_scanner: ms=0x8051eb0 [microtek2] sane_get_devices: local_only=0 [microtek2] sane_get_devices: sd_list_freed [microtek2] sane_exit: MICROTEK2 says goodbye.
Sieht so aus, als waere 'option dump 1' das Problem. Diese Zeile steht in der 'microtek2.conf'. Diese Datei sieht unter SuSE 6.x und 7.1 bei mir identisch aus. Unter 6.x folgt hieraus kein Problem.
Nur'n Verdacht: die Disconnection ? unten mehr ...
Ich habe scanimage noch mit dem Parameter -T (fuer 'Test') aufgerufen. Dabei haengt sich das System auf. Daher keine Chance das Ergebnis zu sehen.
Dank auch an Joerg Lippmann: Habe in der /etc/sane.d/dll.conf jetzt alles ueberfluessige auskommentiert. Leider kein Erfolg.
Irgendwelche Ideen? Hardware-Probleme schliesse ich zunaechst noch aus. Ich habe im Rechner noch eine kleine Platte mit SuSE 6.0. Hier funktioniert der Scanner. Als Notloesung ist dies aber nur bedingt zu gebrauchen. Offenbar war damals SANE noch weniger ausgereift als unter der Version 6.4. Unter 6.0 gibt es Probleme mit farbigen scans. Diese waren unter 6.4 offenbar behoben. 6.4 habe ich inzwischen komplett vom Rechner entfernt. Ich hatte zunaechst ein Update von 6.4 auf 7.1 vorgenommen, auf Grund diverser Probleme dann aber 7.1 komplett neu installiert.
Fuer weitere Hinweise (ggfs. Erfahrungen mit SuSE 7.2?) waere ich sehr dankbar.
Gruss Erich
<MEHR> In Deiner ersten Mail hast Du ja auch den Aufruf und seine Parameter für das aha154x-Modul angegeben. Hab mir das nochmal angeschaut. --- aus erster Mail - Anfang --- Den Treiber aha152x.o habe ich als Modul mit modprobe aha152x aha152x1=0x140,11,7,1,1,0,0,0 installiert. Unter SuSE 7.1 habe ich mit erheblichen Problemen zu kaempfen. Nachdem ich Plug and Play auf der Karte ausgeschaltet habe (war frueher nicht noetig) bin ich zumindest ein Stueck weiter. Die Installation scheint nun zunaechst zu funktioniern. Die Meldungen kernel: aha152x: BIOS test: passed, detected 1 controller(s) kernel: aha152x: resetting bus... kernel: aha152x1: vital data: rev=3, io=0x140 (0x140/0x140), irq=11, scsiid=7, reconnect=enabled, parity=enabled, synchronous=disabled, delay=0, extended translation=disabled kernel: aha152x1: trying software interrupt, ok. kernel: scsi1 : Adaptec 152x SCSI driver; $Revision: 2.3 $ kernel: Vendor: Model: scanner V636A4 Rev: 1.10 kernel: Type: Scanner ANSI SCSI revision: 02 in /var/log/messages sehen eigentlich nicht schlecht aus. --- aus erster Mail - ENDE --- WICHTIG: Wenn NUR der Scanner am Adapter hängt, und so siehts ja aus, dann evtl. mal den Disconnect 'disablen'. Ich glaub, so was hatte ich auch mal. Ich teste das mal bei mir (muß da mal den Scanner umklemmen) am Zwei-PC. Der hat auch SuSE 7.1 Pro. Das Ergebnis geb ich dann mal durch. Bis dahin Bernd