On 10/03/2012 03:31 PM, Louis Lagendijk wrote:
> On Wed, 2012-10-03 at 12:55 +0900, Gernot Hassenpflug wrote:
>
>> 3) the network backend part probably requires more work, and further
>> debug. I'm not familiar with it though.
>
> I can take that as I wrote it. But lets first see if you can get it
> working over USB. My experience so far is that most if not all issues
> with the network part are the result of more high level issues that also
> show up over USB. The BJNP protocol is just USB over IP (partly UDP and
> partly TCP). The scanner does in many cases not react over IP anymore
> when the USB protocol is not exactly what it wants.
> Please see the man page for the debug settings and get me a logfile so
> we can check what is happening.
>
> Kind regards, Louis
Sorry it tooke me so long to get back to this, but I've now had a chance
to dig a little deeper into the problems with the MX890.
The debug info showed that it was hitting the timeout in
pixma_mp150.c:wait_until_ready(). A quick hack was to increase the
timeout value by a factor of 10, e.g.:
diff --git a/backend/pixma_mp150.c b/backend/pixma_mp150.c
index 473234b..3a8f514 100644
--- a/backend/pixma_mp150.c
+++ b/backend/pixma_mp150.c
@@ -951,7 +951,7 @@ static int
wait_until_ready (pixma_t * s)
{
mp150_t *mp = (mp150_t *) s->subdriver;
- int error, tmo = 60;
+ int error, tmo = 600;
RET_IF_ERR ((mp->generation >= 3) ? query_status_3 (s)
: query_status (s));
With the change, I've done a handful of scans via both USB and network
without any failures. I'll do more extensive testing with various scan
settings and see if it continues to behave properly.
There may be an underlying timing issue somewhere, as the original value
of 60 seemed to correlate to about 3 seconds of real time (and setting
tmo to 120 mapped to 6 seconds of real time). I haven't traced back
through the code to see what the intended resolution is for tmo, but a
50 msec resolution seems odd.
---
Henry Ptasinski
henry at logout.com
