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
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
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
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>