M2875FW rebooting upon scan over the network

[zachary]

I've just bought a Samsung M2875FW and I'm using it via the SULDR packages (thanks a lot BTW!).
I'm on Debian testing (Jessie, at present).
Printing works fine. Scanning has some issues.

First of all xsane (but in general everything sane-related, it seems) takes a lot to scan for devices, about 35 seconds before showing the device dialog. It's not clear to me if that is normal or not. Any takers? If it is "normal", is there a way to avoid the device scanning and reuse the results from the last run? I'd be particularly cool if that could be done even when xsane is invoked by other applications, and most notably gimp.

More importantly, network scanning doesn't work at all for me and triggers a scanner reboot. Here is what happens.
I run xsane (wait 35 seconds...) and choose the scanner option over the net (which I've configured in /etc/sane.d/xerox_mfp.conf).
I run "acquire preview" and preview acquisition starts. Immediately after (maybe 1, 2 seconds max), the scanner briefly shows what it seems to be a debugging message on the display, which reads:

  PCS_Parser.c 20
   34 CPCS

and the reboots, starting again from the usual bootstrap display message:

  System
  Initialize

at the very same time xsane crashes with a line like this one in dmesg:

  [236800.401928] traps: xsane[7112] trap divide error ip:7f651fc31c4c sp:7fffc1a2a820 error:0 in libsane-xerox_mfp.so.1.0.23[7f651fc27000+11000]

It looks like a bug in the scanner firmware, but it's probably one which is caused by xsane and/or the suld driver (because otherwise there will be way more people than me complaining about this over the net... :)).

Any idea about how to fix / work around this?

FWIW, I've updated the firmware to the printer/scanner firmware to the latest version available on the samsung.com website, but unfortunately it didn't help.

Cheers.

[bchemnet]

First of all xsane (but in general everything sane-related, it seems) takes a lot to scan for devices, about 35 seconds before showing the device dialog. It's not clear to me if that is normal or not. Any takers? If it is "normal", is there a way to avoid the device scanning and reuse the results from the last run? I'd be particularly cool if that could be done even when xsane is invoked by other applications, and most notably gimp.

This seems to depend on what hardware you have present.  For example, the device scan time on my computer went up substantially after I added a TV tuner card.  I have no idea why, presumably sane is testing hardware that it thinks might be responsive.  I know you can set the environment variable SANE_DEFAULT_DEVICE to designate a particular default device, but I don't think that actually prevents sane from searching for devices every time xsane starts.

It looks like a bug in the scanner firmware, but it's probably one which is caused by xsane and/or the suld driver (because otherwise there will be way more people than me complaining about this over the net... :)).

Any idea about how to fix / work around this?

Since it seems to be using the xerox-mfp backend, I would guess that's where the problem lies, not the Samsung driver.  There is a newer version of sane available (1.24 and 1.25 in development) than is currently in the Debian repositories, you could try installing that and see if it resolves the problem.  Otherwise I would suggest filing a bug report with the SANE project, and/or searching their reports for something similar that may provide a clue to a work-around.

[zachary]

First of all thanks for your reply!

Since it seems to be using the xerox-mfp backend, I would guess that's where the problem lies, not the Samsung driver.

Are there other backends that I could/should use? I went for the xerox-mfp because that's what I've seen mentioned on the suld website and in other replies on this forum. In fact, I wasn't entirely sure about whether which one I should use between xerox-mfp and xerox-mfp_smfp... If there are alternatives I should try, I'm all ears! :)

There is a newer version of sane available (1.24 and 1.25 in development) than is currently in the Debian repositories, you could try installing that and see if it resolves the problem.  Otherwise I would suggest filing a bug report with the SANE project, and/or searching their reports for something similar that may provide a clue to a work-around.

I'll give newer sane versions a try. Still, it seems to me that there is arguably a bug *also* in the scanner firmware. It is definitely inappropriate for it to reboot, no matter what the client is telling it over the network.

Cheers.

[bchemnet]

Are there other backends that I could/should use? I went for the xerox-mfp because that's what I've seen mentioned on the suld website and in other replies on this forum. In fact, I wasn't entirely sure about whether which one I should use between xerox-mfp and xerox-mfp_smfp... If there are alternatives I should try, I'm all ears! :)

xerox-mfp_smfp is not a real backend, it still refers to xerox-mfp.  The only other thing to try is to not specify a backend at all and see if it picks up the suld backend (which can't be forced, because it isn't a SANE component).

I'll give newer sane versions a try. Still, it seems to me that there is arguably a bug *also* in the scanner firmware. It is definitely inappropriate for it to reboot, no matter what the client is telling it over the network.

Agreed.  If you can't get it work without xerox-mfp or with a newer SANE, it's probably also worth contacting Samsung (or perhaps even if you do get it work).

[zachary]

xerox-mfp_smfp is not a real backend, it still refers to xerox-mfp.  The only other thing to try is to not specify a backend at all and see if it picks up the suld backend (which can't be forced, because it isn't a SANE component).

I see. How can I try not to specify a backend at all?

Thus far I had used the expression "specify a backend" to mean that I've added the "tcp..." line to a specific file under /etc/sane.d. So I've specified the xmfp_mfp backend only in the sense that it is at the end of /etc/sane.d/xmfp_mfp.conf my "tcp..." line. Where should I put it instead not to specify a backend, and trying that way to have the suld backend picked up?

TIA,

[bchemnet]

Thus far I had used the expression "specify a backend" to mean that I've added the "tcp..." line to a specific file under /etc/sane.d. So I've specified the xmfp_mfp backend only in the sense that it is at the end of /etc/sane.d/xmfp_mfp.conf my "tcp..." line. Where should I put it instead not to specify a backend, and trying that way to have the suld backend picked up?

In theory, the suld driver should be able to work with the scanner without modifying anything.  So simply remove anything you have added to the .conf file.

Of course, the result may also be that the scanner isn't detected by SANE at all.

[zachary]

In theory, the suld driver should be able to work with the scanner without modifying anything.  So simply remove anything you have added to the .conf file.

Uhm, I'm puzzled by this. The only thing I've added to the .conf file is the line:

    tcp 192.168.X.Y

(with the appropriate values for X and Y). How is suld supposed to find the scanner without the IP address indication?

If it is via some network auto detection, that implies (I suspect) configuration of other services to that end, such avahi or equivalent.
If I'm on the right track, can you clarify which mechanisms suld uses to find the scanner address?

With continued thanks for your help :-)

[bchemnet]

If it is via some network auto detection, that implies (I suspect) configuration of other services to that end, such avahi or equivalent.
If I'm on the right track, can you clarify which mechanisms suld uses to find the scanner address?

It uses its own utility, either /opt/Samsung/mfp/bin/netdiscovery or /usr/lib/cups/backend/smfpnetdiscovery depending on the version of the driver.  Basically it seems to run a UDP scan of some sort (I've never looked into it much detail).  For it to work, the only thing you need to do is ensure is that your firewall allows UDP replies from the printer IP address (which is standard behavior).

That said, because it is a custom utility, there certainly have been times it hasn't worked correctly.  I don't know how it gets triggered, but the idea is that you shouldn't need to manually modify any files.

[pentike]

Hi!

The exact same error happens with Samsung Xpress M2885FW. I have installed the following components:

Unpacking samsungmfp-scanner (2:2) ...
Beállítás: suld-network-2 (4.01.17-1) ...
Beállítás: suld-driver-common-1 (1-7) ...
Beállítás: suld-ppd-2 (4.01.17-3) ...
Beállítás: suld-driver-4.01.17 (4.01.17-3) ...
Beállítás: samsungmfp-scanner (2:2) ...

The scanner is connected to the computer via USB so it is not related to the network configuration. If using the scanning process starts and about half of the page the device restarts itself with the same error message:
  PCS_Parser.c 20
   34 CPCS

[bchemnet]

Have you tried a newer driver, such as driver2-1.00.36?

[pentike]

Yes, I have just tried it but the result is the same. However it seems that the problem is only present if I choose xerox_mfp:libusb.
If I select smfp: upon XSane startup I am able to scan with the flatbed scanner but there is no ADF option.

I have also reported the issue to samsung support. They suggested to get the device repaired, but it is more likely a driver or firmware issue I guess.

[bchemnet]

It sounds to me like a potential bug in xerox_mfp, which is part of the SANE project.  You might try a bug report directed to them.

The lack of ADF in smfp is presumably Samsung simply not implementing that within their own driver, which is unfortunate but unlikely to change.

[pentike]

Filed a bug report:
https://alioth.debian.org/tracker/index.php?func=detail&aid=315361&group_id=30186&atid=410366