SANE mit Agfa Snapscan haengt

From: Robert Eckardt <Robert.Eckardt(at)aranea.de>
Date: Sun, 3 Dec 2000 14:09:55 +0100 (CET)

Hallo,

seit ich upgegradet habe, mag mein Agfa SnapScan nicht mehr im Farbmodus
ab 300dpi scannen, 200dpi oder Grayscale geht aber noch.
Leider habe ich nicht nur eine Komponente upgegradet.

Ich habe von einem IWill-MB mit P5/180 und on-board Adaptec
zu einem ASUS CUBX mit P III/750 und ahc0+sym0 gewechselt.
ahc0: <Adaptec 2940 SCSI adapter> port 0xb800-0xb8ff mem 0xe0800000-0xe0800fff irq 11 at device 11.0 on pci0
ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs
sym0: <810a> port 0xb400-0xb4ff mem 0xe0000000-0xe00000ff irq 9 at device 12.0 on pci0
sym0: No NVRAM, ID 7, Fast-10, SE, parity checking

Z.Z. hängt der Scanner extern am NCR/Symbios-Controller.
Am Adaptec hängen ein CD-ROM und ein Brenner.
<TOSHIBA CD-ROM XM-3801TA 0207> at scbus0 target 4 lun 0 (pass0,cd0)
<YAMAHA CRW4416S 1.0e> at scbus0 target 5 lun 0 (pass1,cd1)
<AGFA SnapScan 1.60> at scbus1 target 6 lun 0 (pass2)

Neben Motherboard und SCSI-Controller habe ich auch von FreeBSD 3.3-STABLE
mit sane-1.0.1 zu FreeBSD 4.1-RELEASE mit sane-1.0.2 gewechselt.

Das Problem:
Mit truss sehe ich, daß er nach dem 4. oder 5. read-Block hängen bleibt,
bis ich ihn abbreche.
<<truss scanimage --resolution 300 --rgb-lpr 40 -l 2 -t 2 -x 200 -y 270 > out.pnm>>
fstat(1,0xbfbf6dd4) = 0 (0x0)
read(0x1b,0x8063000,0x1bae) = 4096 (0x1000)
read(0x1b,0x8064000,0xbae) = 2990 (0xbae)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 6308 (0x18a4)
read(0x1b,0x80648a4,0x30a) = 778 (0x30a)
read(0x1b,0x8063000,0x1bae) = 3318 (0xcf6)
read(0x1b,0x8063cf6,0xeb8) = 3768 (0xeb8)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
write(1,0x8065000,8192) = 8192 (0x2000)
write(1,0xbfbf91af,8192) = 8192 (0x2000)
write(1,0xbfbfb1af,8192) = 8192 (0x2000)
write(1,0xbfbfd1af,8192) = 8192 (0x2000)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 3646 (0xe3e)
read(0x1b,0x8063e3e,0xd70) = 3440 (0xd70)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
write(1,0x8065000,8192) = 8192 (0x2000)
write(1,0xbfbf91af,8192) = 8192 (0x2000)
write(1,0xbfbfb1af,8192) = 8192 (0x2000)
write(1,0xbfbfd1af,8192) = 8192 (0x2000)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 6186 (0x182a)
read(0x1b,0x806482a,0x384) = 900 (0x384)
write(1,0x8065000,8192) = 8192 (0x2000)
write(1,0xbfbf91af,8192) = 8192 (0x2000)
write(1,0xbfbfb1af,8192) = 8192 (0x2000)
write(1,0xbfbfd1af,8192) = 8192 (0x2000)
read(0x1b,0x8063000,0x1bae) = 7086 (0x1bae)
read(0x1b,0x8063000,0x1bae) = 4302 (0x10ce)
^CSIGNAL 2

Mit CAMDEBUG <<camcontrol debug -I -S -T 1:6:0>> kann ich während des read
hunderte von Meldungen (ca. 120/s) beobachten:
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): camisr(pass2:sym0:0:6:0): entering cdgetccb
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): xpt_schedule
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): added periph to queue
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): calling xpt_run_devq
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): xpt_setup_ccb
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): xpt_action
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): sym_action
Dec 3 13:33:25 axion /kernel: (pass2:sym0:0:6:0): xpt_done

Damit kann ich relativ wenig anfangen. Außer, daß es zu Beginn aussieht wie:
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): camisr
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): entering cdgetccb
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): xpt_schedule
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): added periph to queue
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): calling xpt_run_devq
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): xpt_setup_ccb
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): xpt_action
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): sym_action
Dec 3 13:33:19 axion /kernel: (pass2:sym0:0:6:0): xpt_done

Ich gehe aber davon aus, daß er mit dem Schreiben nicht mitkommt.

Hat irgendjemad eine ähnliche Situation schonmal gelöst oder weiß jemand,
ob sich was Relevantes im SCSI-Code geändert hat oder deutet es auf ein
Konfigurationsproblem oder ist es am Ende ein Hardwareproblem ???

Was kann ich zum Debuggen noch unternehmen?

Vielen Dank vorweg,
Robert

-- 
    Dr. Robert Eckardt          Robert.Eckardt(at)Robert-Eckardt.de
                            or  Robert(at)Eckardt.com
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 03 Dec 2000 - 14:09:44 CET

search this site