[Bug 253232] ulpt possible regression in 12.2

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253232

Peter Much <pmc@citylink.dinoex.sub.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pmc@citylink.dinoex.sub.org

--- Comment #6 from Peter Much <pmc@citylink.dinoex.sub.org> ---
I'm getting the same errors only on one of two identical Prolific devices.

I bought such a piece, it worked immediately with no further problems. 
A year later I ordered another one, got the very identcal piece (branded
"Logitech"), the kernel detects it as the same thing, so I put it into my OK
shelf.

Now I try to use it, and it doesn't work. No data whatsoever goes through. From
this report I now got the idea to write to /dev/usb/1.3.1 - and voila, I get a
line written on the printer!

So the piece is apparently not just broken, and, from the timeline, t doesn't
seem to be the unsufficiently-tested prize from the guangzhou lottery, but
rather the silently-upgraded-with-new-bugs-or-features prize. (Sorry,
Hans-Petter)

Have a closer look:

old:
ugen2.3: <vendor 0x1a86 USB2.0-Print> at usbus2, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (96mA)
new:
ugen1.3: <vendor 0x1a86 USB2.0-Print> at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)

old:
ugen2.3: <vendor 0x1a86 USB2.0-Print> at usbus2
ulpt_probe: 
syslog: last message repeated 1 times
ulpt0 on uhub4
ulpt_attach: sc=0xfffff80006957000
ulpt0: <vendor 0x1a86 USB2.0-Print, class 0/0, rev 1.10/2.54, addr 3> on usbus2
ulpt_attach: setting alternate config number: 0
ulpt0: using bi-directional mode
ulpt0: out of paper

new:
ugen1.3: <vendor 0x1a86 USB2.0-Print> at usbus1
ulpt_probe: 
syslogd: last message repeated 1 times
ulpt1 on uhub3
ulpt_attach: sc=0xfffff800bcc0f400
ulpt1: <vendor 0x1a86 USB2.0-Print, class 0/0, rev 1.10/2.54, addr 3> on usbus1
ulpt_attach: setting alternate config number: 1
ulpt1: using bi-directional mode
ulpt_status_callback: error=USB_ERR_STALLED
ulpt_status_callback: error=USB_ERR_STALLED
ulpt_status_callback: error=USB_ERR_STALLED
ulpt_status_callback: error=USB_ERR_STALLED
[loops forever, once a second]

The alternate config number is different.
The old one has only one config with <BULK IN> and <BULK OUT>:

    Interface 0
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0002 
      bInterfaceClass = 0x0007  <Printer device>
      bInterfaceSubClass = 0x0001 
      bInterfaceProtocol = 0x0002 

The new one has three of them:

    Interface 0
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0001       
      bInterfaceClass = 0x0007  <Printer device>
      bInterfaceSubClass = 0x0001 
      bInterfaceProtocol = 0x0001 
[ <BULK OUT> only ]

    Interface 0 Alt 1
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0001 
      bNumEndpoints = 0x0002 
      bInterfaceClass = 0x0007  <Printer device>
      bInterfaceSubClass = 0x0001 
      bInterfaceProtocol = 0x0002 
[ <BULK IN> and <BULK OUT> ]

    Interface 0 Alt 2
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0002 
      bNumEndpoints = 0x0003 
      bInterfaceClass = 0x00ff  <Vendor specific>
      bInterfaceSubClass = 0x0000 
      bInterfaceProtocol = 0x00ff 
[ <BULK IN>, <BULK OUT> and <INTERRUPT IN> ]

I'll now try and test the suggested patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.