On Wed, 4 Jan 2023 12:04:22 -0500
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Jan 04, 2023 at 05:47:31PM +0100, Petr Tesařík wrote:
>[...]
> > V Wed, 4 Jan 2023 11:18:29 -0500
> > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> napsáno:
> >
> > > On Wed, Jan 04, 2023 at 04:49:00PM +0100, Petr Tesařík wrote:
>[...]
> > > > On a second thought, this looks like the actual bug. I don't think
> > > > we're supposed to see a disconnect+reconnect whenever a suspended USB
> > > > device is resumed. Then again, I'm no expert on USB...
> > >
> > > In general there should not be a disconnect during a resume. But it can
> > > happen, depending on how the device behaves.
> >
> >
> > > Perhaps your phone is
> > > disconnecting deliberately.
> > >
> > > The dmesg log ought to contain some useful information, particularly if
> > > you enable USB kernel debugging before starting the experiment:
> > >
> > > echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> >
> > I can see there is an -EIO after the resume attempt:
> >
> > Jan 04 17:44:38 meshulam kernel: usb 1-4: usb auto-resume
> > Jan 04 17:44:38 meshulam kernel: hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0010
> > Jan 04 17:44:38 meshulam kernel: usb 1-4: Waited 0ms for CONNECT
> > Jan 04 17:44:38 meshulam kernel: usb 1-4: finish resume
>
> At this point the host sends a Get-Device-Status request to the device
> (not shown in the log).
>
> [...]
>
> The fact that the host is retrying means that the status request got an
> error. Unfortunately the log message doesn't say sort of error
> occurred.
OK, I see. The URB indicates success, but there is no data:
45 0.432232 host 1.50.0 USB 64 GET STATUS Request
46 0.432659 1.50.0 host USB 64 GET STATUS Response
Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
USB URB
[Source: 1.50.0]
[Destination: host]
URB id: 0xffff98b4383c8d80
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
Device: 50
URB bus id: 1
Device setup request: not relevant ('-')
Data: present ('\0')
URB sec: 1672851450
URB usec: 569060
URB status: Success (0)
URB length [bytes]: 0
Data length [bytes]: 0
-------------------------^
This should be 2, and the device should send a 16-bit status word. Hm.
[Request in: 45]
[Time from request: 0.000427000 seconds]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000200, Dir IN
Number of ISO descriptors: 0
While I do agree that the Samsung phone download mode USB stack
implementation is crappy, multiple models and many users are affected. I
wonder what would be a sensible workaround in heimdall and/or libusb...
Setting a global module parameter does not sound great.
Petr T
> > Jan 04 17:44:38 meshulam kernel: usb 1-4: reset high-speed USB device number 46 using xhci_hcd
> > Jan 04 17:44:38 meshulam kernel: usb 1-4: gone after usb resume? status -5
>
> And here is where the phone disconnected itself, or at least, failed to
> respond properly following the reset.
>
> If you want even more detailed information, you can get a usbmon trace
> (see Documentation/usb/usbmon.rst in the kernel source) of the resume
> procedure. However, I doubt that knowing what happened will help to fix
> the problem.
>
> If you want to prevent the phone from being autosuspended in the first
> place, you can write -1 to /sys/module/usbcore/parameters/autosuspend
> before the phone is plugged in. But of course, this will then affect
> _all_ USB devices plugged in before you set the autosuspend delay back
> to 2.
>
> Alan Stern
