067b:2305 printing issue with parallel-to-usb adapter

Bug #1258919 reported by boblinux
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

I have an old HP Deskjet 710C parallel printer. I really don't print a lot, so it ages well. I just replaced my former desktop with a new barebone without parallel port - no space to embed a PCI IEEE 1284 adapter. So I just bought a cable which is a parallel-to-usb adapter : it is a Sweex adapter, the kernel recognizes it as :
Prolific Technology, Inc. PL2305 Parallel Port

I configured cups to use this new adapter, with the same old pnm2ppa driver. When I try to print a test page from cups (or other printings) it goes well, until close to the end, when the printing suddenly stops, without the sheet being released : I have to power off the printer, which as a side effect triggers the sheet ejection before power off. I read various articles and forums on this topic before posting. Playing with usblp, kernel blacklists and /dev/usb/lp0 does not solve anything. I wanted to be sure that it was not the Prolific controller which was flawed. So I connected it to a windows 7 virtual machine into Virtualbox; Windows installed various drivers, and eventually various printings ran seamlessly - without my issue on GNU/Linux. So my conclusion is that the controller is ok. I also just tested mainline kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc3-trusty/linux-image-3.13.0-031300rc3-generic_3.13.0-031300rc3.201312061335_amd64.deb . No improvement, my test page stops being printed at the same spot close to the end. So I can assume that there is a bug in the controller's driver. Best regards R. Grasso

WORKAROUND: Setup Lprng locally from lpr - not configurable from KDE/Systemsettings - then from my main computer with CUPS 1.6.1, I configured a remote printer:
lpd://10.0.0.1/lp

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image (not installed)
ProcVersionSignature: Ubuntu 3.11.0-14.21-generic 3.11.7
Uname: Linux 3.11.0-14-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/hwC0D3', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/pcmC0D2c', '/dev/snd/pcmC0D3p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
Date: Sun Dec 8 13:53:43 2013
HibernationDevice: RESUME=UUID=a16e3a2c-0f38-4e72-9c51-145a864b60a1
InstallationDate: Installed on 2013-11-06 (32 days ago)
InstallationMedia: Kubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MachineType: Shuttle Inc. DS47D
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-14-generic root=UUID=8c51cecc-9054-4edc-8b06-afb7bb4ebd2e ro
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-14-generic N/A
 linux-backports-modules-3.11.0-14-generic N/A
 linux-firmware 1.116
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/09/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.03
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: FS47D
dmi.board.vendor: Shuttle Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 10
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03:bd08/09/2013:svnShuttleInc.:pnDS47D:pvrV1.0:rvnShuttleInc.:rnFS47D:rvr1.0:cvnToBeFilledByO.E.M.:ct10:cvrToBeFilledByO.E.M.:
dmi.product.name: DS47D
dmi.product.version: V1.0
dmi.sys.vendor: Shuttle Inc.

Revision history for this message
boblinux (robert-grasso) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Re: printing issue with parallel-to-usb adapter

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
boblinux (robert-grasso) wrote :

Sorry I have been busy all week.

Before posting to the usb list, do you confirm my first guess that this may be a kernel bug ? I saw that cups does not support usblp anymore. Can we be sure that this is not a cups issue ? I just mentioned the kernel because it seemed one possible thing to do. But is usblp is not used, how can we diagnose eiher the kernel or cups ? There are no /dev/usb/lp? devices anymore.

I did another test : I generate a long list in the following way :

line 1
line 2
etc ...

I store it in a Postcsript file with groff

If the list is 20 lines long, it is printinted completely and the printer releases the page. If it is 56 lines or more, one or two lines at the end are not printed and the printer does not release the page. In both situations, lpstat -t returns :

root@rubedo:~# lpstat -t
scheduler is running
system default destination: DESKJET-710C
device for DESKJET-710C: usb://HP/DESKJET%20710C
DESKJET-710C accepting requests since Sun 15 Dec 2013 09:34:18 PM CET
printer DESKJET-710C is idle. enabled since Sun 15 Dec 2013 09:34:18 PM CET
        Sending data to printer.

Please note the final "Sending data to printer." which is not removed.

Do we have enough to say that the culprit is the kernel, of cups ?

What should I do now ? Can I write an alternate backend ? I saw an example with usblp, but not with libusb ?

Best regards
R. Grasso

Revision history for this message
boblinux (robert-grasso) wrote :

I am sorry I have been unclear : with the old Unix, I was able to run low level tests such as :

cat test_file > /dev/lp0

with such a test I would have been able to test the kernel driver only; so would have I been able to do with usblp, which generates such special devices : I could have generated low level printing data with pnm2ppa and sent them to /dev/usb/lp0.

The problem is that I don't know the USB subsystem enough, I don't know libusb at all, and I don't have a clue about how libusb addresses an USB device ? And all the low level tests which I found, implying libusb, make use of cups usb backend : I am for instance able to run :

cat texte.ps | gs -q -sDEVICE=ppmraw -r600 -sPAPERSIZE=letter -dNOPAUSE -sOutputFile=- - | pnm2ppa --eco -v 720 -i - -o - | DEVICE_URI="usb://HP/DESKJET%20710C" /usr/lib/cups/backend/usb 1 1 1 1 ''

but this does not help to understand whether the bug is in cups or elsewhere : this is my problem with this diagnostic. In my opinion we should first clarify this.

What do you think ?

Revision history for this message
boblinux (robert-grasso) wrote :

I ran a last quick search : I began diving in libusb programming : and this is what i was afraid of : they don't use the usual Unix special files : they address the usb devices on the bus directly, as I found on this example :

A short introduction to libusb | Roar of the Jespersaur
http://www.jespersaur.com/drupal/node/25

separating cups from the kernel driver in this diagnostic is getting complicated ... I guess we should contact the cups mailing list directly ? and let them find out ?

Revision history for this message
boblinux (robert-grasso) wrote :

I just made another test : I stopped the cups service, loaded usblp with modprobe, and ran :

 cat lines.ps | gs -q -sDEVICE=ppmraw -r600 -sPAPERSIZE=letter -dNOPAUSE -sOutputFile=- - | pnm2ppa --eco -v 720 -i - -o - > /dev/usb/lp0

so : lines.ps contains 56 lines to be printed, which fails with cups+libusb : here : SUCCESS !

I am not sure that this helps for my diagnostic - it just tells that cups + usblp is flawed with my devices ...

Revision history for this message
boblinux (robert-grasso) wrote :

I meant : cups+libusb is flawed : sorry !

penalvch (penalvch)
tags: added: kernel-bug-exists-upstream-v3.13-rc3
penalvch (penalvch)
tags: added: bios-outdated-1.04
Changed in linux (Ubuntu):
status: Triaged → Incomplete
summary: - printing issue with parallel-to-usb adapter
+ 067b:2305 printing issue with parallel-to-usb adapter
description: updated
tags: added: regression-potential
Revision history for this message
boblinux (robert-grasso) wrote :

I understand why you ask - on http://global.shuttle.com/products/productsDownload?productId=1718&panelId=1, they don't mention that v1.04 fixes anything about USB; as I am able to print with usblp, I am not sure that upgrading the Bios will help - however, one never knows - I will do the upgrade this week-end, no time before.
Thanks for your time.

Revision history for this message
boblinux (robert-grasso) wrote :

Hello,

I upgraded the bios; here is the version :

root@rubedo:~# dmidecode -s bios-version ; dmidecode -s bios-release-date
1.04
09/13/2013

As I expected, the cups behavior did not change; nor the successful print through usblp

What is your suggestion now ?

Best regards
R. Grasso

Revision history for this message
penalvch (penalvch) wrote :

boblinux, thank you for updating your BIOS. With your current hardware setup you initially reported with, is this problem not reproducible in a release prior to Saucy?

tags: added: latest-bios-1.04
removed: bios-outdated-1.04
Revision history for this message
boblinux (robert-grasso) wrote :

Hello,

Actually, this computer (Shuttle) is my firewall. My main computer is still running Ubuntu 12.10 (I have a boot issue because of my TV card - I don't address this issue now, I am mentioning this just so that your understand why I did not upgrade yet).

I just had right now a hardware problem with my USB bus (on my 12.10 main computer), this is why I did not post anything about this in my previous post. I eventually rebooted, and my USB bus is running corretcly now.

Thus I was able to reproduce the issues I had noticed some weeks ago : so, with Ubuntu 12.10, which contains cups 1.6.1:

I have the exact same behaviour than on my Shuttle with Ubuntu 13.10 ! I mean :

- using cups, printing a long page stalls before the end
- running my print test with usblp is completely successful.

What now ?

Revision history for this message
boblinux (robert-grasso) wrote :

Obviously, I noticed this behavior after having unplugged the printer from the Shuttle and having plugged it on the 12.10 computer. I did not report the previous behavior through a network connection, remotely printing from the 12.10 computer onto the printer which would have been connected to the Shuttle : I did not do that : the behavior I noticed on the 12.10 computer was with my printer being locally connected to the 12.10 computer.

Revision history for this message
penalvch (penalvch) wrote :

boblinux, thank you for providing the requested information. For regression testing purposes, could you please test for this in a lucid live environment via http://old-releases.ubuntu.com/releases/lucid/ and advise to the results?

tags: added: quantal
Revision history for this message
boblinux (robert-grasso) wrote :

I will do it. Possibly not now. I am in France, and it is getting late. Later this week I guess.

Revision history for this message
boblinux (robert-grasso) wrote :

Hey, it was quick ! I found back an old Lucid vm in Virtualbox : I started it , configured the printer in cups, printed the test page : success, it did not stall !

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Please do the following on Ubuntu 13.10:

Do you have a file named

/usr/share/cups/usb/org.cups.usb-quirks

Can you attach it?

Can you follow the instructions of the section "USB printer does not print or prints garbage" on https://wiki.ubuntu.com/DebuggingPrintingProblems?

Please also try editing the line

0x067b 0x2305 no-reattach soft-reset unidir

in

/usr/share/cups/usb/org.cups.usb-quirks

Do not change the "0x067b 0x2305" in the beginning, but try other combinations of issue workarounds as described in the initial comments of the file. If you are successful with a combination, please tell us.

Changed in cups (Ubuntu):
status: New → Incomplete
Revision history for this message
boblinux (robert-grasso) wrote :

Wow, Till Kamppeter himself ! Thank you for coming and trying to rescue me ! So, first things first, I am attaching the quirks file

Revision history for this message
boblinux (robert-grasso) wrote :

Now, about https://wiki.ubuntu.com/DebuggingPrintingProblems and the section "USB printer does not print or prints garbage" (I guess I already went through this before posting) :

btw, the system's current state is :
- cups service stopped
- usblp reloaded, so that I could have /dev/usb/lp0 in order to run the tests I posted previously. So I

modprobe -r usblp

but then

service cups start seems to start, but lpstat -t does not return ? So I restopped cups, reloaded usblp, restarted cups, and this time lpstat -t returned ? But you rely on libusb now ? weird, weird ? anyway, I am running the tests below with cups enabled and usblp loaded - just to be accurate.

1 - HP Desjet 710C, no network connection
2 :
  * cancel -a : done
  * lpadmin -p HP_DESKJET_710C -o usb-unidir-default=true : done
  * lp lines.ps (containing 56 lines) : I am remembering, I already ran this test : it fails, the printing stops some lines before the last one - it is not always the same (random)
  * lpadmin -p HP_DESKJET_710C -R usb-unidir-default : done

BTW, here I have (as after each printing) :

root@rubedo:~# lpstat -t
scheduler is running
system default destination: HP_DESKJET_710C
device for HP_DESKJET_710C: usb://HP/DESKJET%20710C
HP_DESKJET_710C accepting requests since Mon 23 Dec 2013 08:21:00 PM CET
printer HP_DESKJET_710C is idle. enabled since Mon 23 Dec 2013 08:21:00 PM CET
        Sending data to printer.

so before running the last test I am restarting cups :

root@rubedo:~# service cups restart
cups stop/waiting
cups start/running, process 9756
root@rubedo:~# lpstat -t
scheduler is running
system default destination: HP_DESKJET_710C
device for HP_DESKJET_710C: usb://HP/DESKJET%20710C
HP_DESKJET_710C accepting requests since Mon 23 Dec 2013 08:21:00 PM CET
printer HP_DESKJET_710C is idle. enabled since Mon 23 Dec 2013 08:21:00 PM CET

clean !

3 :
  * no need for cancel -a, the queue is empty, cups has been reset
  * lpadmin -p HP_DESKJET_710C -o usb-no-reattach-default=true : done
  * lp lines.ps : no way ! it stopped at line #54 (as the previous test did)
  * lpadmin -p HP_DESKJET_710C -R usb-no-reattach-default

Revision history for this message
boblinux (robert-grasso) wrote :

Finally : gosh, I am stupid ! I was searching the quirks file for the Deskjet 710C ! of course there is an entry for the PL2305 chip !

Now, I ran various tests as you requested : I did not try "blacklist" nor "usb-init" (I don't have any vendor string) nor "vendor-class" (I am not sure I understand what this means) nor "whitelist". I list below the various tests I ran : in short : the result is, sadly, always the same, as if the line for the PL2305 chip was not taken into account at all.

What can we do now ?

Tests and their results:
---------------------------

all disabled :
# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir

service cups restart
lp lines.ps => printing stops at line #54 (no change)

=========

# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir
0x067b 0x2305 no-reattach

service cups restart
lp lines.ps => printing stops at line #54 (no change) (no kidding :-(

=========

# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir
0x067b 0x2305 soft-reset

service cups restart
lp lines.ps => printing stops at line #54 (no change)

=========

# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir
0x067b 0x2305 unidir

service cups restart
lp lines.ps => printing stops at line #54 (no change)

=========

# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir
0x067b 0x2305 no-reattach soft-reset

service cups restart
lp lines.ps => printing stops at line #54 (no change)

=========

# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir
0x067b 0x2305 no-reattach unidir

service cups restart
lp lines.ps => printing stops at line #54 (no change)

=========

# Prolific Technology, Inc. PL2305 Parallel Port (USB -> Parallel adapter), https://bugs.launchpad.net/bugs/987485
#0x067b 0x2305 no-reattach soft-reset unidir
0x067b 0x2305 soft-reset unidir

service cups restart
lp lines.ps => printing stops at line #54 (no change)

Revision history for this message
boblinux (robert-grasso) wrote :

Hello,

Can anybody tell me why this bug is still considered "Incomplete" ? I guess I have been thorough with the informations I supplied as requested : did I do any mistake ?

Best regards
R. Grasso

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

As a workaround you can try the following setup (kernel module "usblp" must be loaded, check with "lsmod"):

lpadmin -p test -E -v parallel:/dev/usb/lp0 -P /etc/cups/ppd/DESKJET-710C.ppd

Try to print on this new print queue named "test". Does it work?

Another workaround is to connect your printer to a router or NAS with print server functionality. Most devices which have a USB or parallel port have this functionality, check the configuration web interface of your device. After that set up your printer as network printer with the IP/hostname of your router/NAS.

Please try both workarounds and tell what works for you.

Revision history for this message
boblinux (robert-grasso) wrote :

I understand what you mean.

actually I just setup Lprng and it is fully working : locally from lpr - not configurable from KDE/Systemsettings but I don't really care as this is on my firewall - then from my main computer with CUPS 1.6.1, I configured a remote printer :

lpd://10.0.0.1/lp

I just printed the test page from CUPS successfully, and 2 pages from another document.

Unfortunately I don't have any further PCI slot available in my main computer for a true parallel port card.

So I have right now a very good workaround.

As far as I remember, before sending my first post for this case, I must have tried to print to parallel:/dev/usb/lp0 - and I am almost sure it did not work. Except if this would be very useful to you, as setting up Lprng has required some significant efforts, I would not run this test again right now.

Can I ask if you have a clear roadmap leading someday to PL2305 being fully supported by Cups+libusb ? i understand that it must not be a top priority device, but then, there are still some old printers around ...

penalvch (penalvch)
no longer affects: linux (Ubuntu)
Changed in cups (Ubuntu):
importance: Undecided → Low
status: Incomplete → New
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cups (Ubuntu):
status: New → Confirmed
Revision history for this message
Marko Štamcar (markostamcar) wrote :

I am using PL2305 to print to an old Fujitsu line printer and was missing the last few lines of the printout every time. The workaround suggested above worked for me, too :) I changed:

lpadmin -p fujitsu -v usb://Unknown/Printer -E

to

lpadmin -p fujitsu -E -v parallel:/dev/usb/lp0

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.