[Daniel Kerry Hiltgen]
> Does anyone know if saned and the network protocol is byte order clean,
> independent of the underlying architecture? (just a hunch...)
The protocol itself is byte order clean, but not the image date
> I've got my scanner hooked up to a Sun Sparc (running linux), and I'm
> trying to access it from an x86 box. Local scans on the sparc seem to
> work, but it's headless/no X so I really want to use my desktop machine
> to do real scans.
Do local scans work or scans over localhost?
For debugging saned/net use the following:
Start saned from commandline as
# export SANE_DEBUG_YOURBACKEND=128
# saned -d128
and start scanimage on the other pc as
$ export SANE_DEBUG_NET=128
$ scanimage -L
note that saned also produces output for syslog.
In your case, I think, saned isn't even accessed by the net backend...
maybe your client has no access rights on the saned port on your sparc?
> Here's one stack trace of the seg-fault. (I get roughly the same stack
> in scanimage -L, xsane, and xscanimage)
This is always the same... sanei_w_space can't read from the pipe and
returns. The next call to sanei_w_space generates a sig11... I've
attached a simple patch, maybe you get a better error-msg with this one.
> Any thoughts? Can I provide more information that might be helpful in
> diagnosing the problem? (FWIW: Mustek 1200 LS)
Could you please try this patch? and if it works (e.g. doesn't segfault
anymore), please send the output from saned & scanimage... thanks
BTW. the patch was made against the current cvs tree but it should also
work with SANE 1.0.3.
--- ../sane/sane-backends/sanei/sanei_wire.c Sat Aug 12 17:11:37 2000
+++ sane-backends/sanei/sanei_wire.c Sun Dec 10 12:38:19 2000
@@ -56,6 +56,9 @@
int fd = w->io.fd;
ssize_t nread, nwritten;
+ if (w->status != 0)
if (w->buffer.curr + howmuch > w->buffer.end)
@@ -80,6 +83,8 @@
left_over = w->buffer.end - w->buffer.curr;
+ if ((signed) (left_over < 0))
memcpy (w->buffer.start, w->buffer.curr, left_over);
w->buffer.curr = w->buffer.start;
This archive was generated by hypermail 2b29 : Fri Dec 22 2000 - 08:19:26 PST