Bug 91538 - [ulpt] [patch] Unable to print to EPSON CX3500
Summary: [ulpt] [patch] Unable to print to EPSON CX3500
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 7.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-09 00:50 UTC by Peter Jeremy
Modified: 2017-12-31 22:29 UTC (History)
0 users

See Also:


Attachments
ulpt.patch (2.19 KB, patch)
2006-01-25 12:15 UTC, Peter Jeremy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Jeremy 2006-01-09 00:50:03 UTC
Attempting to access an EPSON Stylus CX3500 printer fails and locks
up the uhub until the system is rebooted.  I believe this is a problem
with the USB subsystem rather than the port because of the lockup.

I have posted this problem in freebsd-usb and tried contacting the
people mentioned in the PIPS port with no response.

Fix: 

unknown.
How-To-Repeat: 
Enable USB_DEBUG and set the sysctl variables as follows:
hw.usb.debug: 1
hw.usb.ehci.debug: 1
hw.usb.uhci.debug: 1
hw.usb.ulpt.debug: 3

Plug in the printer.  The following shows the behaviour on a USB1 port but
the behaviour is the same on a USB2 port.  The following console output
is generated:
 usbd_new_device bus=0xc3447000 port=1 depth=1 speed=2
 usbd_new_device: adding unit addr=2, rev=110, class=0, subclass=0, protocol=0, maxpacket=8, len=18, speed=2
 usbd_new_device: new dev (addr 2), dev=0xc560b280, parent=0xc3439880
 usbd_probe_and_attach: trying device specific drivers
 usbd_probe_and_attach: no device specific driver found
 usbd_probe_and_attach: looping over 1 configurations
 usbd_set_config_index: status=0x0001, error=NORMAL_COMPLETION
 usbd_set_config_index: (addr 1) cno=2 attr=0xc0, selfpowered=1, power=2
 usbd_set_config_index: set config 1
 ulpt0: EPSON USB MFP, rev 1.10/1.00, addr 2, iclass 255/255
 ulpt0: using bi-directional mode

Run /usr/local/libexec/pips/printer/ekpd as root.
Start /usr/local/bin/ekpstm from an xterm.  This generates the following
console output:
 ulptopen: flags=0x40
 ulpt_open: open input pipe
 ulptopen: done, error=0
 ulptread
 ulptread: transfer 1024 bytes
 ulptread
 ulptread: transfer 1024 bytes
 ulptwrite
 ulpt_status: status=0x18 err=0
 ulptwrite: transfer 27 bytes
 ulptread
 ulptread: transfer 8 bytes
 ulptwrite
 ulpt_status: status=0x18 err=0
 ulptwrite: transfer 8 bytes
 ulptread
 ulptread: transfer 9 bytes
 ulptwrite
 ulpt_status: status=0x18 err=0
 ulptwrite: transfer 17 bytes
 ulptread
 ulptread: transfer 16 bytes
 ulptwrite
 ulpt_status: status=0x18 err=0
 ulptwrite: transfer 13 bytes
 ulptread
 ulptread: transfer 12 bytes
 ulptwrite
 ulpt_status: status=0x18 err=0
 ulptwrite: transfer 11 bytes
 ulptwrite
 ulpt_status: status=0x18 err=0
 ulptwrite: transfer 11 bytes
 ulptread
 ulptread: transfer 10 bytes
 ulptread
 ulptread: transfer 6 bytes
 uhci_idone: error, addr=2, endpt=0x83, status 0x500000<BABBLE,STALLED>
 usbd_bulk_transfer: error=13
 uhci_timeout: uxfer=0xc5b56300
 uhci_timeout_task: xfer=0xc5b56300
 uhci_check_intr: aborted xfer=0xc5b56300
 ulptread: error=13
 ulptread
 ulptread: transfer 6 bytes
 usbd_bulk_transfer: tsleep=-1
 uhci_device_bulk_abort:
 uhci_check_intr: aborted xfer=0xc5bc2e00
 ulptread: error=18
 ulptread
 ulptread: transfer 6 bytes
 usbd_bulk_transfer: tsleep=-1
 uhci_device_bulk_abort:
 uhci_check_intr: aborted xfer=0xc5bc2e00
 ulptread: error=18

Note that error 13 is USBD_IOERROR (reported because BABBLE is set),
error 18 is USBD_INTERRUPTED.

At this point, the last 6 lines will repeat indefinitely until ekpd is killed.
Killing ekpd will give:
 ulptclose: closed

Disconnecting the printer gives:
 ulpt0: at uhub1 port 1 (addr 2) disconnected
 ulpt_detach: sc=0xc560ed00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 ulpt0: detached

Re-connecting the printer, or any other USB device, to the same hub then gives:
 usbd_new_device bus=0xc3447000 port=1 depth=1 speed=2
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 usb_new_device: set address 2 failed - trying a port reset
 [above 13 lines repeat twice]
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 uhci_timeout: uxfer=0xc5bc2e00
 uhci_timeout_task: xfer=0xc5bc2e00
 uhci_check_intr: aborted xfer=0xc5bc2e00
 usb_new_device: set address 2 failed
 usbd_remove_device: 0xc5954d80
 uhub_explore: usb_new_device failed, error=SET_ADDR_FAILED
 uhub1: device problem (SET_ADDR_FAILED), disabling port 1
Comment 1 Peter Jeremy 2006-01-25 12:15:33 UTC
Following further investigation, I have discovered that the problem
is that the PIPS CX3500 driver expects to be able to read parts of
the printer responses whilst ulpt(4) will not accept more data over
the USB bus than the application asked for.  In the particular case,
the printer was sending 74 bytes whilst the driver wanted to read
the 6 byte header followed by a second 68 byte block.

My solution was to change ulpt(4) to internally buffer reads.  A
persistent 1024 byte read buffer is already available.  The attached
patch will always issue 1024 byte reads across the USB bus and any
surplus data will be saved for the next read(2) issued by the
application.

Note that whilst this allows communication between the printer and
the PIPS driver, there remain problems with the port that prevent
printing from working correctly.  I will address these in a separate
PR since they are related to the port, rather than the USB subsystem.

-- 
Peter Jeremy
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:08 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped