Re: Raspberry Pi 3B USB Printing Issue

On Mon, Mar 14, 2022 at 6:12 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Mon, Mar 14, 2022 at 5:31 PM Hans Petter Selasky <hps@selasky.org>
> wrote:
>
>> On 3/14/22 10:20, Archimedes Gaviola wrote:
>> > On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <
>> > archimedes.gaviola@gmail.com> wrote:
>> >
>> >>
>> >>
>> >> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <
>> >> archimedes.gaviola@gmail.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky <hps@selasky.org
>> >
>> >>> wrote:
>> >>>
>> >>>> On 3/12/22 16:31, Archimedes Gaviola wrote:
>> >>>>>>
>> >>>>>> IOERROR usually means an electrical error. The RPI3B will use a
>> >>>>>> transaction translator for the FULL speed traffic, which is driven
>> by
>> >>>>>> software.
>> >>>>>
>> >>>>
>> >>>> Hi Archimedes,
>> >>>>
>> >>>>> Hi Hans,
>> >>>>>
>> >>>>> I'm curious about the transaction translator you've mentioned, any
>> >>>> idea why
>> >>>>> there's a need for translation and what is being translated?
>> >>>>
>> >>>> When the High Speed USB HUB was invented, there was a need to support
>> >>>> FULL and LOW speed USB transactions. Because FULL and LOW speed
>> >>>> transactions are slow and take up much bandwidth, a transactions
>> >>>> translator was invented which translates between High Speed USB and
>> >>>> FULL/LOW speed USB. That means the RPi 3B consists of a single USB
>> HIGH
>> >>>> speed port, followed by a USB HUB. These transactions are not
>> visible in
>> >>>> usbdump .
>> >>>>
>> >>>>   >Does this only
>> >>>>> happen when RPi 3B (acting as host controller) is transmitting data
>> to
>> >>>> the
>> >>>>> Epson printer? Are translation events visible in the usbdump? In
>> this
>> >>>> case
>> >>>>> there's a way to possibly track what's going on and how to identify
>> any
>> >>>>> info that is being translated?
>> >>>>
>> >>>> By turning on the HC debugging, you can possibly track via debug
>> >>>> messages what is going on. Maybe it is a timing issue, that the SW is
>> >>>> too slow serving the micro transactions.
>> >>>>
>> >>>> Any idea also if translation is being
>> >>>>> performed in RPi 4B?
>> >>>>
>> >>>> The later RPi's do the transaction translator bits in HW or via the
>> XHCI
>> >>>> block.
>> >>>>
>> >>>> As I have conducted several printing cases with my
>> >>>>> Epson printer without any issues with either of the 4 ports.
>> >>>>>
>> >>>>> Sorry for these questions as I am catching-up to the USB technology
>> >>>>> internal workings under the hood.
>> >>>>
>> >>>> You are welcome!
>> >>>>
>> >>>
>> >>>
>> >>> Thank you so much Hans for answering my questions, really appreciate
>> it!
>> >>> I have a much better understanding now.
>> >>>
>> >>> I came from testing with 13.0-RELEASE having the same RPi 3B hardware
>> and
>> >>> setup and it's very stable. I haven't encountered any IOERROR and
>> >>> incomplete printed outputs that were encountered with 14.0-CURRENT
>> >>> (February 24, 2022). By the way, I found in the repository here
>> >>> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
>> >>> that there were two latest snapshots released dated March 3 and March
>> 10,
>> >>> respectively. I need to take printing tests first, especially the
>> latest to
>> >>> check if it also manifests before I go back to the Feb. 24 snapshot
>> and do
>> >>> a thorough test with debugging. I'll provide updates for any
>> observations.
>> >>>
>> >>> Thanks,
>> >>> Archimedes
>> >>>
>> >>
>> >>
>> >> Hi Hans,
>> >>
>> >> Initial testing conducted with the latest 14.0-CURRENT (March 10, 2022
>> >> snapshot) seems to be stable. Another test will be performed tomorrow.
>> >>
>> >> Thanks,
>> >> Archimedes
>> >>
>> >
>> > Hi Hans,
>> >
>> > I still encountered the issue this morning with 14.0-CURRENT (March 10,
>> > 2022 snapshot). I just noticed when I left my RPi 3B idle for a long
>> period
>> > of time (2-3 hours and more) and started printing, then the issue
>> pops-up.
>> > Another concern I encountered was when I started enabling
>> > hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network
>> > interface (remotely connected over SSH from my laptop) seemed to freeze
>> and
>> > I got disconnected.
>> >
>> > freebsd@generic:~ % uname -a
>> > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
>> > main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022
>> > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
>> > arm64
>> >
>> > root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=1
>> > hw.usb.dwc_otg.debug: 0 -> 1
>> >
>> > See attached initial debug info (no printing testing yet).
>>
>
>
> Hi Hans,
>
>
>>
>> Hi,
>>
>> Nothing obvious there.
>>
>> Maybe you need to add a conditional to DPRINTF's in the fast path, to
>> only print for a certain device, to reduce the debug prints.
>>
>> How many USB devices are connected?
>>
>
> Only two devices, one is my USB keyboard and the other one is my Epson
> printer.
>
>
>>
>> One experiment you might try is to comment out:
>>
>> usbd_transfer_submit(xfer);
>>
>> in
>>
>> uhub_intr_callback()
>>
>> in
>>
>> /usr/src/sys/dev/usb/usb_hub.c
>>
>> It will save some USB resources, but also makes USB enumeration a bit
>> slower.
>
>
> This is noted, I'll try.
>
>
>> Maybe the chip is out of USB HW endpoints and is only polling
>> for RX data ...
>>
>
> This is noted as well, we'll probably see later what's going on. I'll get
> back to you once I recompile the kernel and perform the testing.
>
> Thanks,
> Archimedes
>


Hi Hans,

I did comment-out usbd_transfer_submit(xfer) and still the same behavior is
experienced when hw.usb.dwc_otg.debug is enabled. The system seems to
freeze as my USB keyboard is unresponsive and I cannot connect over the
Ethernet NIC with SSH. I can't print and capture.

freebsd@generic:/usr/src/sys/dev/usb % diff -Nur usb_hub.c.orig usb_hub.c
--- usb_hub.c.orig      2022-03-14 22:37:03.162678000 +0800
+++ usb_hub.c   2022-03-14 22:38:23.832660000 +0800
@@ -202,7 +202,7 @@

        case USB_ST_SETUP:
                usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer));
-               usbd_transfer_submit(xfer);
+               /* usbd_transfer_submit(xfer); */
                break;

Let me know our next step.

Thanks,
Archimedes