Nakal wrote: > I really don't understand SCSI much. FreeBSD gives me still "unexpected > disconnect" with my scanner, after I switched off "disconnection" in my > controller's BIOS.
Could the FreeBSD driver ignore the BIOS settings? I assume that you can pass a parameter like "don't disconnect" to the driver. > Yes. It is a quite "cheap" scanner and came with a separate ISA SCSI-1 > controller. Now I'm using one with a Symantec chipset (Tekram > DC390/UW). The scanner is attached to external UW bus. I wonder if it > is really correct to connect it like this, but IT WORKED earlier (1 or > 2 years ago?) on Debian, so it should not be a problem. Well, a fast SCSI adapter may have problems with a slow device, but I don't believe that this is the case hre. After all, the scanner finishes one of the three passes, and that shows that several SCSI commands were successful. >> it is unclear which commands can be sent during that delay, if >>that delay can be polled (i.e. ask the scanner if it is ready) or if >>it must be guessed, etc, etc. > > > There is a possibility to compile the FreeBSD kernel with CAM debugging. > This produces LOTS of information (see: man camcontrol(8)). With just a > bit luck, there might be some useful information about the scanner's > behavior. That could be interesting -- but currently I think we can stay with the Sane debug messages. > I don't know how many people are using old Microtek scanners. If it is > too much trouble, simply forget it. From my POV, we should continue ;) I think you had simply the bad luck of being the first one to discover a bug in sanei_scsi.c (and perhaps another one in the Microtek backend) -- but these bugs could bite more people, if we don't fix them... And while I would really prefer it to leave the patches for sanei_scsi.c to somebody who has FreeBSD installed, I'll try to do it myself, if nobody shouts "I'm volunteering". But expect some extra work fixing typos in my patches ;) Abel PS: Considering the log output from running the Scanmaker II under Linux, it its perhaps worth, if you try my simple patch to sanei_scsi.c I am not sure, but both the backend and the scnner seem to be able to deal with a few failing commands. And the patch passes slightly better erro informations to the backend.
