# Re: whole system locked

becka@rz.uni-duesseldorf.de
Tue, 12 May 1998 19:54:39 +0200 (MET DST)

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Yuri Dario: "Re: Win32 TWAIN DLL to interface with SANE"
- Previous message: Jim Ford: "Re: [umax] Can't use 10-bit scan: "preview cannot handle depth 16""

Hi !

> I recently encountered real problems out of nowhere:
> the xscanimage-preview crashed the whole system.
>
> to start from the beginning:
>
> hardware: Mustek Paragon 1200SP (firmware 1.02)
> connected to Tekram DC390 which also runs
> IBM SCSI-Harddisk

I am having similar problems with an IDE System with an
MP 12000SP (FW 1.00) connected to the NCR 53c400 SCSI card that came
with it.

> I put the system from IDE-disk to SCSI some time ago. For some time
> everything worked perfect, when suddenly, exactly at the end of a
> preview-scan the whole system froze completely (don't laugh at me).
> No keybord working.

I have a similar effect sometimes that can cause either the whole system
locking up or the SCSI subsystem going mad in a way that can only be cured
by a reboot.
rmmod, power-cycle scanner, insmod does _not_ help.

> I had to reset and repair a more or less corrupt filesystem :-(
> It happend some more times, but only EXACTLY at the end of previewing,
> the normal scanning was fine.

I have seen similar effects. They seem to be connected to the exact amount
of data/the number of lines that have to be transferred.

I can reproduce the hangup by giving specific parameter sets to the scanner.

> With option strip-height (1 or 2) enabled previewing works mostly correct,
> only one crash since.

At previewing ?

If you have the same problem that I have, I assume it would be very likely
that it now happened at scan time, because the strip-height option
causes the "breaks" in the transfer at other places, thus changing the
size of the last strip - what seems to be the cause of the problem -
should either always or never affect previewing - right ?

> smaller strip-heights seem safer and color preview very unsafe
> (more data coming?)

Hmm - sounds somewhat familiar. Color mode significantly increased the
probability for hangs here, too.

> I have no real idea what is going on, to me it seems some kind of
> timing problem?

Hmm - My guess was rather a rounding error in number-of-lines calculations,
because at the parameter sets where I could reproduce the hang, I usually
had calculated "fractional part" of the last line number to be near 0.5.

Could you check further using scanimage, checking, if hangups at given
parameter sets are reproducible and record those parameter sets, so I can cross
check them ?

If you like, you could also already check my theory by calculating the total
number of requested lines which is simply the product of the scan length in
inch and the resolution.

> The system tries to write preview-data to disk while the scanner still
> locks the SCSI-bus?

I don't think preview data gets written to SCSI. It should end up in RAM -
right ? It should only go to disk via swapping. Is that likely to occur for
your system ?

CU,Andy

    --
    = Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

     Next message: Yuri Dario: "Re: Win32 TWAIN DLL to interface with SANE"
     Previous message: Jim Ford: "Re: [umax] Can't use 10-bit scan: "preview cannot handle depth 16""