Matto Marjanovic wrote:
>
> >OK, so we have indeed a flaw in the Linux SCSI system... I assume that
> >the scanners identify themselves as SCSI 1 devices, where these short
> >sense data blocks are normal.
>
> They do identify themselves, as a protocol between SCSI-1 and SCSI-2.
> ("SCSI_1_CC
>OK, so we have indeed a flaw in the Linux SCSI system... I assume that
>the scanners identify themselves as SCSI 1 devices, where these short
>sense data blocks are normal.
They do identify themselves, as a protocol between SCSI-1 and SCSI-2.
("SCSI_1_CCS" in drivers/scsi/scsi.h. This macr
Matt,
> >are you sure that the Linux SCSI system (or FreeBSD) tries to issue a
> >REQUEST SENSE, if it can't "connect" to device? (If I find enough time,
>
> I'm not exactly sure what is going on in this particular situation.
>
> Last winter, a user (Shawn Rutledge) was really helpful in track
On Saturday 21 June 2003 14:52, Henning Meier-Geinitz wrote:
> If I try to use the "ncr" driver instead of "sym", FreeBSD doesn't
> even boot. With a Tekram 315 controller the results are the same as
> above.
ncr driver is old, you should not use it. As far as I know, sym should
support everythi
Hi, Abel,
>are you sure that the Linux SCSI system (or FreeBSD) tries to issue a
>REQUEST SENSE, if it can't "connect" to device? (If I find enough time,
I'm not exactly sure what is going on in this particular situation.
Last winter, a user (Shawn Rutledge) was really helpful in tracking
dow
Henning Meier-Geinitz wrote:
> Ok. I haven't tested FreeBSD with older scanners for some time so here
> are my results with Mustek SCSI scanners (symbios-compatible 810 SCSI
> controller, FreeBSD 5.0, sym driver):
>
> Scanner1.0.12 your patch
>
Matto Marjanovic wrote:
> A-ha --- ok, the sense handler is not called, an error condition is returned,
> and then - I imagine - the retry logic in the backend takes over.
Right, I think that's happening.
>
> With regards to the mystery status value: in this situation under Linux
> (i.e., th
Hi,
On Fri, Jun 20, 2003 at 08:51:26PM +0200, abel deuring wrote:
> Henning Meier-Geinitz schrieb:
>
> >I'm not volunteering :-) but I can at least test if any of your
> >patches break Mustek scanners on FreeBSD.
>
> Great. I've already sent a patch to Martin, and it seems to fix the
> problem
Matto Marjanovic wrote:
>
> >> I verified Your latest (second) patch. It also works without any
> >> problems, e.a. compiles, scans and picture looks fine.
> ...
> >thanks for this report. To be honest, i must admit that I can't really
> >remember your first mails :( But it's nice to read tha
>> What does the patch do? (And how did it fix up the Microtek scanning?)
...
>depending on the status returned by the OS. The sense handler is only
>called, if ccb->ccb_h.status & CAM_AUTOSNS_VALID is true, which should
>guarantee that useful sense data is available.
...
>Without the patch
Nakal wrote:
> I verified Your latest (second) patch. It also works without any
> problems, e.a. compiles, scans and picture looks fine.
>
> On FreeBSD 5.1 everything works fine, too, with this patch. Even my
> problem with "scanimage -L" disappeared there (still remember? looks
> like a kernel
On Friday 20 June 2003 20:51, abel deuring wrote:
> Great. I've already sent a patch to Martin, and it seems to fix the
> problems with the Microtek Scanamker II. Attached is the proposed new
> version (with Martin's fixes of my typos) of sanei_scsi_cmd2 for
> FreeBSD/CAM. It should replace the fu
>> I verified Your latest (second) patch. It also works without any
>> problems, e.a. compiles, scans and picture looks fine.
...
>thanks for this report. To be honest, i must admit that I can't really
>remember your first mails :( But it's nice to read that the patch fixes
>more bugs than
This is a multi-part message in MIME format.
--010008090309060605090400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Henning Meier-Geinitz schrieb:
> I'm not volunteering :-) but I can at least test if any of your
> patches break Mustek sca
Hi,
On Thu, Jun 19, 2003 at 09:59:10PM +0200, abel deuring wrote:
> 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, i
Matto Marjanovic wrote:
> 0) None of this generation of Microtek scanners supports SCSI disconnect.
> Disconnect needs to be disabled for the scanner device (if not the
> whole bus), and you should expect the scanner to monopolize the entire
> bus during a scan.
>
> 1) The firmware i
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
On Wednesday 18 June 2003 19:30, you wrote:
> 0) None of this generation of Microtek scanners supports SCSI
> disconnect. Disconnect needs to be disabled for the scanner device
> (if not the whole bus), and you should expect the scanner to
> monopolize the entire bus during a scan.
I really don't
Nakal wrote:
>
> On Tuesday 17 June 2003 23:30, abel deuring wrote:
>
> > First a disclaimer for the following stuff: I don't have FreeBSD
> > installed, I used it only rarely, and I never wrote software
> > specifically for FreeBSD. So I am writing as a "backseat driver" ;)
>
>
> Try it :)
>
Hi,
Sorry to get into this thread so late...
I have to pull out all my microtek notes again; I might even already have
a fix for this problem in the works --- a big graduation got in the way,
and now I have to refresh many memories.
But, in the meantime...
0) None of this generation of Micro
On Tuesday 17 June 2003 23:30, abel deuring wrote:
> First a disclaimer for the following stuff: I don't have FreeBSD
> installed, I used it only rarely, and I never wrote software
> specifically for FreeBSD. So I am writing as a "backseat driver" ;)
Try it :)
> I assume that you are using Fre
Nakal wrote:
> On Tuesday 17 June 2003 00:16, abel deuring wrote:
>
>
>>What I meant, was a combination of the log output of the Sane SCVSI
>>library and of the Microtek backend ;)
>
>
> This is the output of:
> SANE_DEBUG_MICROTEK=255 SANE_SCSICMD_TIMEOUT=180
> SANE_DEBUG_SANEI_SCSI=128 scani
--Boundary-00=_ELz7+hd1IAGKfsJ
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Tuesday 17 June 2003 00:16, abel deuring wrote:
> What I meant, was a combination of the log output of the Sane SCVSI
> library and of the Microtek backen
Nakal wrote:
> On Monday 16 June 2003 21:16, abel deuring wrote:
>
>
>>The first error occurs immediately after a "read", and this at least
>>does not contradict my suspicions about the timeout problems. But we
>>could get a better clue, if you add a "SANE_DEBUG_MICROTEK=255". The
>>DLL debug out
--Boundary-00=_bUj7+3jA47kNUKn
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Monday 16 June 2003 21:16, abel deuring wrote:
> The first error occurs immediately after a "read", and this at least
> does not contradict my suspicions
Nakal schrieb:
> On Sunday 15 June 2003 22:20, abel deuring wrote:
>
>
>>IIRC, the delay between two scan passes is really long.
>
>
> I don't think so. It always was working fast. Usually about 1 sec after
> the pass the scanner made some switching noises and then recalibrated
> the position
--Boundary-00=_9TQ7++/s4/fNiZr
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Sunday 15 June 2003 22:20, abel deuring wrote:
> IIRC, the delay between two scan passes is really long.
I don't think so. It always was working fast. Us
Nakal wrote:
>>And you should tell FreeBSD not to look for all LUNs of the scanner
>>while it tries to detect devices on the SCSI bus.
>
>
> Yupp, I did that too, still same. It still gets timeout. I found out that I
> can scan gray pictures, because it's only one pass. It works perfectly! But
On Thursday 12 June 2003 12:10, abel deuring wrote:
> A long shot: IIRC, these Microtek scanners may freeze, if you access
> them with another LUN than 0 -- but they show up with all LUN values
> from 0 to 7. So, if any backend tries to access the scanner with a
> non-zero LUN, you'll have an unac
Nakal wrote:
>
> On Wednesday 11 June 2003 11:27, Henning Meier-Geinitz wrote:
>
> > Looks like a SCSI problem (either hardware or kernel driver). My
> > Mustek SCSI scanners work fine with FreeBSD/386 so I don't think there
> > is a general bug in the SCSI code of SANE.
>
> You might be right.
On Wednesday 11 June 2003 11:27, Henning Meier-Geinitz wrote:
> Looks like a SCSI problem (either hardware or kernel driver). My
> Mustek SCSI scanners work fine with FreeBSD/386 so I don't think there
> is a general bug in the SCSI code of SANE.
You might be right. I will check the cables and th
Hi,
On Tue, Jun 10, 2003 at 11:17:58PM +0200, Nakal wrote:
> Well, how to say... it doesn't work.
>
> I compiled xsane-0.90 from ports. I tried to set 'norealcal' and/or
> 'noprecal'. The scanner always causes a timeout (see attachment) while
> starting "scanimage -d 'microtek:/dev/scanner'".
L
--Boundary-00=_Gsk5+USHsb9suHM
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Well, how to say... it doesn't work.
I compiled xsane-0.90 from ports. I tried to set 'norealcal' and/or
'noprecal'. The scanner always causes a timeout (s
33 matches
Mail list logo
