On Thu, Sep 24, 1998 at 12:14:27AM -0500, Brian E. Bothwell wrote:
> On Wed, 23 Sep 1998, Bernd Schroeder wrote:
>
>
> > > Oops! I sent the debug info without SANE_DEBUG_MICROTEK2=128. Looks like
> > > I may have answered my own question given the line "Model 0x98 not
> > > supported"... :(
> >
> > This means that the backend doesn't yet know this model, but it doesn't
> > mean that the backend does not work with it or can be made to work with
> > it.
> >
> Sh trnsf func equ: 1
> Buffer type: Ring
> FEPROM: No
> [microtek2] scsi_read_system_status: md=0x80b1448, fd=-1
> [microtek2] dump_area2: readsystemstatus
> [readsystemstatus]
> 28008100000000000900
> [microtek2] dump_area2: readsystemstatusresult
> [readsystemstatusresult]
> 030000001100000000
> [microtek2] scsi_test_unit_ready: md=/dev/sgd
> [microtek2] dump_area2: testunitready
> [testunitready]
> 000000000000
this model should work with the backend.
But it is very strange, that the application hangs at a "test unit ready".
This is perhaps the most simple SCSI command at all and should at least
return anything (eventually 'busy'). The above commands are model
independent.
Does it always hang at this command ?
Can you check, what happens, if you remove the scsi_test_uni_ready()
call in microtek2.c (it is called in one place) ?
Bernd
-- Bernd Schroeder Email: mailto:bernd@aquila.muc.de PGP public key available: mailto:pgp@aquila.muc.de | Subject: send key
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com