[Bug 253232] ulpt possible regression in 12.2

2021-02-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253232

--- Comment #5 from Hans Petter Selasky  ---
Thanks for testing.

It appears that your printer devices has not been through enough low-level USB
testing.

Maybe you could write an e-mail to the manufacturer of the USB ulpt device
saying that the USB request clear endpoint halt is broken and causes the device
to halt.

The main problem here is that if you abort a job, the next job may need a
clear-stall message to recover the so-called data-toggle. Else you may loose
the contents of one USB packet on the wire :-(

If you never abort jobs, than there is no problem.

Should we perhaps implement a quirk you can set, that prevents clear-stall from
happening?

I really don't like to fix FreeBSD because USB manufacturers are not following
specs 

What do you think?

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


[Bug 253232] ulpt possible regression in 12.2

2021-02-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253232

--- Comment #3 from Hans Petter Selasky  ---
Hi,

It might be related to the use of USB clear endpoint stall, prior to
transmission.

You can comment that out in the ulpt driver in the kernel. Look for clear
stall.

If that happens to be the case, your USB device's firmware is not fully USB
class compliant ...

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


[Bug 253232] ulpt possible regression in 12.2

2021-02-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253232

--- Comment #2 from Brock Williams  ---
We are not using cups, and I verified it is not installed on the test system.

I tried a usbdump but not really sure what to look for.  The output looks the
same to me on the ones that work and that don't:

09:12:29.188729 usbus0.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=50
09:12:29.194644 usbus0.2
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=50,ERR=0
09:12:29.194684 usbus0.2 SUBM-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=12,IVAL=0
09:12:29.196558 usbus0.2
DONE-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
09:12:29.457889 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
09:12:29.465653 usbus0.2
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0

vs

09:12:32.490567 usbus0.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=50
09:12:32.496664 usbus0.2
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=50,ERR=0
09:12:32.496703 usbus0.2 SUBM-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=12,IVAL=0
09:12:32.498943 usbus0.2
DONE-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
09:12:32.600296 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
09:12:32.608505 usbus0.2
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0


We also determined that if we send data directly to the /dev/usb/0.2.1 device
as opposed to /dev/ultp0, it prints reliably.  We intend to use that as a
workaround for the time being.

FWIW, we have tried multiple computers, multiple printers, and multiple brands
of usb->parallel adapters, and so far, all of the combinations have had the
same problem.

Brock

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


[Bug 253232] ulpt possible regression in 12.2

2021-02-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253232

Hans Petter Selasky  changed:

   What|Removed |Added

 CC||hsela...@freebsd.org

--- Comment #1 from Hans Petter Selasky  ---
Hi,

Are you using cups for printing?

cups started using libusb for direct USB device access. Verify there is no
conflict.

Also you may find "usbdump" useful, to capture all traffic to/from the USB
device.

Maybe a USB class compliance issue.

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


[Bug 253232] ulpt possible regression in 12.2

2021-02-03 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253232

Bug ID: 253232
   Summary: ulpt possible regression in 12.2
   Product: Base System
   Version: 12.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: usb
  Assignee: u...@freebsd.org
  Reporter: br...@cottonwoodcomputer.com

We have a point of sale system that uses Epson receipt printers attached via a
USB-Parallel adapter.  After upgrading these systems to 12.2-RELEASE the
printing is intermittent.

We have duplicated the issue on a fresh 12.2-RELEASE install upgraded to p3 via
freebsd-update.  For example, when running an 'echo "hello" > /dev/ulpt0'
multiple times on 12.2 only every other line is printed.  No errors are
generated.  I have a separate boot environment on the same hardware with 12.1,
which works perfectly.

We have tried a couple different USB-Parallel adapters, including:

Belk USB Printing Support IEEE-1284 Controller
and
Prolific Technology Inc. IEEE-1284 Controller, class 0/0, rev 1.00/2.02, addr 1

both of these behave the same.

I have tried enabling ulpt debugging with sysctl hw.usb.ulpt.debug=15
after each echo command, we get:
Feb  3 13:57:31 fbtest kernel: ulpt_reset: 
Feb  3 13:57:31 fbtest kernel: ulpt_write_callback: state=0x0 actlen=6
Feb  3 13:57:31 fbtest kernel: ulpt_write_callback: state=0x1 actlen=6
the ones that work look the same as the ones that don't work.

I have also tried using unlpt0 and it behaves the same way.

Using echo is a simplified example, if we point lpd to the same device it is
even more intermittent.  In that case, it seems like the first job or two will
print, and after that, most jobs fail silently.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"