Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Dec 2002 14:54:25 +0100 (CET)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
To:        Peter Much <pmc@citylink.dinoex.sub.org>
Cc:        freebsd-scsi@FreeBSD.ORG, <freebsd-questions@FreeBSD.ORG>, <sane-devel@www.mostang.com>
Subject:   Re: Getting SCSI Scanner to work (with Symbios 53c810a and FreeBSD 4.4)
Message-ID:  <20021201142316.K2519-100000@localhost.my.domain>
In-Reply-To: <200212010221.gB12LZk02947@disp.oper.dinoex.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sun, 1 Dec 2002, Peter Much wrote:

> Keywords: FreeBSD SANE Scanner Mustek SCSI MFS-6000CX synchronous disable=
 Symbios 53c810a
>
> Just for the records, or: to whom it may concern.
>
> This is what I had to do to get a scsi scanner to work. I post it
> here so others having a similar problem may get inspired.
>
> I got some Mustek MFS-6000CX. The SANE docs say this scanner
> will not run synchronous scsi transfers and will not disconnect/
> reconnect.

Such simplistic SCSI devices always surprise me a lot. :)

> The Qlogic 1020 controller does not detect it, but instead it will
> hang infinitely at biosboot.
>
> The WD7000 controller will detect it, but either it does not report
> it to the host, or the FreeBSD driver does not recognize it. I did
> not check this further, as this ISA controller is rather outdated
> (although it likely might be good enough for a scanner).

And seem to have surprised other SCSI people too. :)

> The Symbios 53c810a will detect the scanner at biosboot as an
> asynchronous scsi device, and also FreeBSD detects it as devicetype
> "Scanner" when looking for devices. But it is not possible
> to send any scsi command (like tur, inquiry, etc.) to the scanner;
> none will be answered.
>
> Modifying parameters with "camcontrol negotiate" does not help.
>
> The scanner will be lost at "camcontrol rescan" and will never be
> detected again until system reboot.
>
> Each time a scsi command is issued to the scanner, there will be
> no answer, but a kernel error message is logged:
>
> /kernel: (probe5:sym0:0:6:0): phase change 6-7 6@07c5bf8c resid=3D5.
>
> -------------------------------------------------------------------
>
> I investigated the source of the Symbios driver and found out:
> It is not possible to switch off synchronous transfer negotiation
> for a device. There is a variable named "period" in the source,
> and it is set to 25, and it has to do something with synchronous
> transfer.

Indeed it has to do.

This value is set for USER SETTINGS. As your controller hasn't NVRAM, the
driver sets it to the capability of the controller.

The driver doesn't try to negotiate by itself but wait either for a
negotiation from the device, or for CAM to say that transfer settings must
be changed.

If your device reports its uncapabilities ;) to CAM correctly by the
INQUIRY response, CAM should tell the driver that transfer settings are
sync_period=3D0 and sync_offset=3D0.

If you can display the INQUIRY data of the device, we could check at least
that the device didn't confuse CAM by reporting features it doesn't want
to support.

Anyway, the sym driver code let me think that it will not behave correctly
in such situation. The issue is that the driver will scale the new
transfer setting values against controller capabilities without
considering that period=3D0 means asynchronous, and thus fall back to 25.

You may try this tiny patch. Even if there is a couple of other places
where the equivalent change has to be done, this one-liner has chance to
also make the driver work with your scanner. You may let me know.

--- sym_hipd.c.orig=09Sun Dec  2 20:01:10 2001
+++ sym_hipd.c=09Sun Dec  1 14:42:44 2002
@@ -8791,7 +8791,7 @@
 =09=09=09tip->offset =3D np->maxoffs_dt;
 =09}
 =09else {
-=09=09if (tip->period < np->minsync)
+=09=09if (tip->period !=3D 0 && tip->period < np->minsync)
 =09=09=09tip->period =3D np->minsync;
 =09=09if (tip->period > np->maxsync)
 =09=09=09tip->period =3D np->maxsync;
------------- CUT HERE ---------------


Thanks for your report.

  G=E9rard.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021201142316.K2519-100000>