https://bugzilla.kernel.org/show_bug.cgi?id=209411 Bug ID: 209411 Summary: When retrieving string descriptor from mobile device returns eproto error Product: Drivers Version: 2.5 Kernel Version: 4.19 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: USB Assignee: drivers_usb@kernel-bugs.kernel.org Reporter: rachithas104@gmail.com Regression: No I am trying to get get string descriptor from mobile phone,however when trying to retrieve one particular index it returns EPROTO, dev->fd, USB_DIR_IN,USB_REQ_GET_DESCRIPTOR,DESCRIPT_STRING * 256 + index, languageid, sizeof buf, buf); Return value is -1 for ioctl(fd, USBDEVFS_CONTROL, &ioctl_ctrl); kernel: [ 7084.327097] usb 1-1.2: reset high-speed USB device number 12 using ehci-pci kernel: [ 7084.831056] usb 1-1.2: device not accepting address 12, error -71 kernel: [ 7085.119075] usb 1-1.2: reset high-speed USB device number 12 using ehci-pci kernel: [ 7085.431054] usb 1-1.2: reset high-speed USB device number 12 using ehci-pci [ 7085.935069] usb 1-1.2: device not accepting address 12, error -71 [ 7086.227132] usb 1-1.2: reset high-speed USB device number 12 using ehci-pci S[ 7087.321929] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt 128 rq 6 len 255 ret -71 kernel: [ 7087.607093] usb 1-1.2: reset high-speed USB device number 12 using ehci-pci My URB request and without my program in picture request is same -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #1 from Greg Kroah-Hartman (greg@kroah.com) --- On Sun, Sep 27, 2020 at 05:51:20PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=209411 > > Bug ID: 209411 > Summary: When retrieving string descriptor from mobile device > returns eproto error > Product: Drivers > Version: 2.5 > Kernel Version: 4.19 > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: USB > Assignee: drivers_usb@kernel-bugs.kernel.org > Reporter: rachithas104@gmail.com > Regression: No > > I am trying to get get string descriptor from mobile phone,however when > trying > to retrieve one particular index it returns EPROTO, > > dev->fd, USB_DIR_IN,USB_REQ_GET_DESCRIPTOR,DESCRIPT_STRING * 256 + index, > languageid, sizeof buf, buf); > > Return value is -1 for ioctl(fd, USBDEVFS_CONTROL, &ioctl_ctrl); > > kernel: [ 7084.327097] usb 1-1.2: reset high-speed USB device number 12 using > ehci-pci > kernel: [ 7084.831056] usb 1-1.2: device not accepting address 12, error -71 > kernel: [ 7085.119075] usb 1-1.2: reset high-speed USB device number 12 using > ehci-pci > kernel: [ 7085.431054] usb 1-1.2: reset high-speed USB device number 12 > using > ehci-pci > [ 7085.935069] usb 1-1.2: device not accepting address 12, error -71 > [ 7086.227132] usb 1-1.2: reset high-speed USB device number 12 using > ehci-pci > S[ 7087.321929] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt 128 > rq > 6 len 255 ret -71 > kernel: [ 7087.607093] usb 1-1.2: reset high-speed USB device number 12 > using > ehci-pci > > My URB request and without my program in picture request is same Not all strings are readable from the device, are you sure that is a valid string descriptor index to be requesting? -- You are receiving this mail because: You are watching the assignee of the bug.
On Sun, Sep 27, 2020 at 05:51:20PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=209411
>
> Bug ID: 209411
> Summary: When retrieving string descriptor from mobile device
> returns eproto error
> Product: Drivers
> Version: 2.5
> Kernel Version: 4.19
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: USB
> Assignee: drivers_usb@kernel-bugs.kernel.org
> Reporter: rachithas104@gmail.com
> Regression: No
>
> I am trying to get get string descriptor from mobile phone,however when trying
> to retrieve one particular index it returns EPROTO,
>
> dev->fd, USB_DIR_IN,USB_REQ_GET_DESCRIPTOR,DESCRIPT_STRING * 256 + index,
> languageid, sizeof buf, buf);
>
> Return value is -1 for ioctl(fd, USBDEVFS_CONTROL, &ioctl_ctrl);
>
> kernel: [ 7084.327097] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
> kernel: [ 7084.831056] usb 1-1.2: device not accepting address 12, error -71
> kernel: [ 7085.119075] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
> kernel: [ 7085.431054] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
> [ 7085.935069] usb 1-1.2: device not accepting address 12, error -71
> [ 7086.227132] usb 1-1.2: reset high-speed USB device number 12 using ehci-pci
> S[ 7087.321929] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt 128 rq
> 6 len 255 ret -71
> kernel: [ 7087.607093] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
>
> My URB request and without my program in picture request is same
Not all strings are readable from the device, are you sure that is a
valid string descriptor index to be requesting?
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #2 from rachithas104@gmail.com --- (In reply to Greg Kroah-Hartman from comment #1) > On Sun, Sep 27, 2020 at 05:51:20PM +0000, > bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=209411 > > > > Bug ID: 209411 > > Summary: When retrieving string descriptor from mobile device > > returns eproto error > > Product: Drivers > > Version: 2.5 > > Kernel Version: 4.19 > > Hardware: All > > OS: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: USB > > Assignee: drivers_usb@kernel-bugs.kernel.org > > Reporter: rachithas104@gmail.com > > Regression: No > > > > I am trying to get get string descriptor from mobile phone,however when > > trying > > to retrieve one particular index it returns EPROTO, > > > > dev->fd, USB_DIR_IN,USB_REQ_GET_DESCRIPTOR,DESCRIPT_STRING * 256 + index, > > languageid, sizeof buf, buf); > > > > Return value is -1 for ioctl(fd, USBDEVFS_CONTROL, &ioctl_ctrl); > > > > kernel: [ 7084.327097] usb 1-1.2: reset high-speed USB device number 12 > using > > ehci-pci > > kernel: [ 7084.831056] usb 1-1.2: device not accepting address 12, error > -71 > > kernel: [ 7085.119075] usb 1-1.2: reset high-speed USB device number 12 > using > > ehci-pci > > kernel: [ 7085.431054] usb 1-1.2: reset high-speed USB device number 12 > > using > > ehci-pci > > [ 7085.935069] usb 1-1.2: device not accepting address 12, error -71 > > [ 7086.227132] usb 1-1.2: reset high-speed USB device number 12 using > > ehci-pci > > S[ 7087.321929] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt > 128 > > rq > > 6 len 255 ret -71 > > kernel: [ 7087.607093] usb 1-1.2: reset high-speed USB device number 12 > > using > > ehci-pci > > > > My URB request and without my program in picture request is same > > Not all strings are readable from the device, are you sure that is a > valid string descriptor index to be requesting? Yes its valid string, -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #3 from rachithas104@gmail.com --- Also happening only when ioctl(fd, USBDEVFS_SETCONFIGURATION, &configuration ) is called before getting string descriptors -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #4 from Alan Stern (stern@rowland.harvard.edu) --- Maybe the mobile phone just doesn't want to send its string descriptors after the configuration has been set. In any case, it seems like you have found a usable workaround for the problem. If you want to get more information about what's happening, you can use usbmon to trace the packets getting sent and received both during enumeration and while your program is running (see Documentation/usb/usbmon.rst in the kernel source). -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #5 from rachithas104@gmail.com --- Mobile phone having kernel version 4.14 works -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #6 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #4) > Maybe the mobile phone just doesn't want to send its string descriptors > after the configuration has been set. In any case, it seems like you have > found a usable workaround for the problem. > > If you want to get more information about what's happening, you can use > usbmon to trace the packets getting sent and received both during > enumeration and while your program is running (see > Documentation/usb/usbmon.rst in the kernel source). Even reset fails with same error 71 -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #7 from Alan Stern (stern@rowland.harvard.edu) --- So make a usbmon trace with a 4.14 kernel and a trace with a 4.19 kernel, and compare them to see where they are different. That should indicate where the problem is. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #8 from rachithas104@gmail.com --- Created attachment 292725 --> https://bugzilla.kernel.org/attachment.cgi?id=292725&action=edit Non working usbmon traces in ptp mode Hi I have attached usbmon traces of non working device in ptp mode ,reset call fails with this device -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #9 from rachithas104@gmail.com --- Created attachment 292727 --> https://bugzilla.kernel.org/attachment.cgi?id=292727&action=edit Working device in ptp mode Here reset succeeds -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #10 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #7) > So make a usbmon trace with a 4.14 kernel and a trace with a 4.19 kernel, > and compare them to see where they are different. That should indicate > where the problem is. Can you help in checking parallely usbmon traces -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #11 from Alan Stern (stern@rowland.harvard.edu) --- The traces aren't really complete, because you didn't start them until after the USB cable was plugged in. Also, the traces start out with the computer reading string descriptors 1, 2, 3, 4, and 6 (in the non-working trace), and the values of the descriptors are different in the two traces. In the working trace, the values are: 1: "Xiaomi" 2: "MI MAX" 3: "d553b4b6" 4: "ADB Interface" In the non-working trace: 1: "Xiaomi" 2: "Redmi K30 5G" 3: "c2a85d7" 4: "ptp_adb" 6: "ADB Interface" It looks like you used two different phones for the tests, or one phone with two different ROMs installed. Is that what you did? Are you asking why one phone works and the other phone doesn't? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #12 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #11) > The traces aren't really complete, because you didn't start them until after > the USB cable was plugged in. Also, the traces start out with the computer > reading string descriptors 1, 2, 3, 4, and 6 (in the non-working trace), and > the values of the descriptors are different in the two traces. In the > working trace, the values are: > > 1: "Xiaomi" > 2: "MI MAX" > 3: "d553b4b6" > 4: "ADB Interface" > > In the non-working trace: > > 1: "Xiaomi" > 2: "Redmi K30 5G" > 3: "c2a85d7" > 4: "ptp_adb" > 6: "ADB Interface" > > It looks like you used two different phones for the tests, or one phone with > two different ROMs installed. Is that what you did? > > Are you asking why one phone works and the other phone doesn't? Yes Mi Max works ,Redmi doesn't. The traces were taken after I have plugged the device and changed it to PTP mode Mainly the traces has info when my program starts enumerating. Can I know is there any tool you used to get this info -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #13 from rachithas104@gmail.com --- My program issues reset command, it works with MiMax ,but fails with other device -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #14 from Alan Stern (stern@rowland.harvard.edu) --- You can get the descriptor values by running "lsusb -v". If the phone fails when you reset it, you should change your program. Don't issue the reset command! Why did you open this bug report in the first place? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #15 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #14) > You can get the descriptor values by running "lsusb -v". > > If the phone fails when you reset it, you should change your program. Don't > issue the reset command! > > Why did you open this bug report in the first place? Since the device with 4.14 kernel works and 4.19 fails,I opened whether there is any protocol change ,so that I can change my program accrordingly,I am seeing this in syslog when issued reset command kernel: [85237.846504] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci kernel: [85238.146480] usb 1-1.2: device descriptor read/64, error -71 kernel: [85238.558551] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci kernel: [85239.062496] usb 1-1.2: device not accepting address 19, error -71 kernel: [85239.350498] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci kernel: [85240.544425] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt 128 rq 6 len 255 ret -71 0 kernel: [85240.838479] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #16 from Alan Stern (stern@rowland.harvard.edu) --- You would have to ask the people who created those kernels for the phones. Android devices use specialized kernels, not the same ones that we develop here. If you want to avoid getting these errors, just change your program so that it doesn't issue the reset command. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #17 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #16) > You would have to ask the people who created those kernels for the phones. > Android devices use specialized kernels, not the same ones that we develop > here. > > If you want to avoid getting these errors, just change your program so that > it doesn't issue the reset command. OK which tool can be used to analyze usbmon traces -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #18 from Alan Stern (stern@rowland.harvard.edu) --- You can use Wireshark to collect and analyze the traces. Wireshark understands about usbmon and will use it automatically. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #19 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #18) > You can use Wireshark to collect and analyze the traces. Wireshark > understands about usbmon and will use it automatically. Thanks -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #20 from Alan Stern (stern@rowland.harvard.edu) --- WHen you're happy with the results of your testing, you can go ahead and close out this bug report. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #21 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #20) > WHen you're happy with the results of your testing, you can go ahead and > close out this bug report. Can you suggest how to avoid EPROTO error even after calling Select Configuration -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #22 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #20) > WHen you're happy with the results of your testing, you can go ahead and > close out this bug repor (In reply to Alan Stern from comment #20) > WHen you're happy with the results of your testing, you can go ahead and > close out this bug report. Currently while String Descriptor is getting retrieved for index 4 it results in EPROTO error -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #23 from Alan Stern (stern@rowland.harvard.edu) --- As far as I can tell, both of these errors are caused by bugs in the phone's software. Changing your program isn't likely to help. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #24 from rachithas104@gmail.com --- I (In reply to Alan Stern from comment #23) > As far as I can tell, both of these errors are caused by bugs in the phone's > software. Changing your program isn't likely to help. I checked wireshark traces without my software same request of SetConfiguration is called and there is no difference in packets with and without my software in picture -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #25 from Alan Stern (stern@rowland.harvard.edu) --- If your software isn't running, then what software issues the Get-String-Descriptor request for string descriptor 4 that causes the EPROTO error? If the same packets are present with or without your software, then your software isn't sending any packets. Is this really what you mean? In any case, the EPROTO error is caused by the code running on the phone. I can't give you much advice about that. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #26 from rachithas104@gmail.com --- When my software dont call setconfiguration there is no protocol error Protocol error happens when my software calls setconfig and tries to retrieve index 4 -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #27 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #25) > If your software isn't running, then what software issues the > Get-String-Descriptor request for string descriptor 4 that causes the EPROTO > error? > > If the same packets are present with or without your software, then your > software isn't sending any packets. Is this really what you mean? > > In any case, the EPROTO error is caused by the code running on the phone. I > can't give you much advice about that. Also bus reset is happening when I call selectconfiguration from my app -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #28 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #25) > If your software isn't running, then what software issues the > Get-String-Descriptor request for string descriptor 4 that causes the EPROTO > error? > > If the same packets are present with or without your software, then your > software isn't sending any packets. Is this really what you mean? > > In any case, the EPROTO error is caused by the code running on the phone. I > can't give you much advice about that. Hello I see similar thread which you have fixed https://www.spinics.net/lists/linux-usb/msg199677.html I also see the same problem when calling setconfiguration How can I test the fix mentioned in thread,can you kindly help -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #29 from Alan Stern (stern@rowland.harvard.edu) --- That fix is part of the linux-next repository, and it will be included in the release of kernel version 5.10 about 3 months from now. If you don't want to wait that long, you'll have to build your own kernel. It's an involved process, not difficult but time-consuming. I don't want to explain all the details here; there are plenty of guides available on the web describing how to build and test kernels. In fact, the web site for your Linux distribution probably has something that shows how to do this. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #30 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #29) > That fix is part of the linux-next repository, and it will be included in > the release of kernel version 5.10 about 3 months from now. > > If you don't want to wait that long, you'll have to build your own kernel. > It's an involved process, not difficult but time-consuming. I don't want to > explain all the details here; there are plenty of guides available on the > web describing how to build and test kernels. In fact, the web site for > your Linux distribution probably has something that shows how to do this. Should mobile kernel version be upgraded or Ubuntu's kernel to consume the fix? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #31 from rachithas104@gmail.com --- Also do you think my issue is similar to the other issue? I read through description,is there any additional logs should I provide to confirm if its same? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #32 from Alan Stern (stern@rowland.harvard.edu) --- The fix you mentioned in comment #28 applies to the Ubuntu (host) kernel. As to whether it will fix your EPROTO problem... I'm not certain, but there's a good chance that it will. However, I don't think it will help with the device reset failures. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #33 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #32) > The fix you mentioned in comment #28 applies to the Ubuntu (host) kernel. > > As to whether it will fix your EPROTO problem... I'm not certain, but > there's a good chance that it will. However, I don't think it will help > with the device reset failures. Any workaround for now other than not calling SelectConfiguration? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #34 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #32) > The fix you mentioned in comment #28 applies to the Ubuntu (host) kernel. > > As to whether it will fix your EPROTO problem... I'm not certain, but > there's a good chance that it will. However, I don't think it will help > with the device reset failures. Any workaround for now other than not calling SelectConfiguration? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #35 from Alan Stern (stern@rowland.harvard.edu) --- Come to think of it, that particular change probably _won't_ affect your Get-String-Descriptor call. It only affects bulk and interrupt endpoints, not control or isochronous endpoints, and Get-String-Descriptor uses endpoint 0 (which is a control endpoint). Not calling Set-Config seems like the best workaround. Is there any reason why your program calls it in the first place? Isn't the device already using the configuration you want? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #36 from rachithas104@gmail.com --- R(In reply to Alan Stern from comment #35) > Come to think of it, that particular change probably _won't_ affect your > Get-String-Descriptor call. It only affects bulk and interrupt endpoints, > not control or isochronous endpoints, and Get-String-Descriptor uses > endpoint 0 (which is a control endpoint). > > Not calling Set-Config seems like the best workaround. Is there any reason > why your program calls it in the first place? Isn't the device already > using the configuration you want? Regarding Get-String descriptor call,the problem seems to be happening only when I call SelectConfiguration.If we skip SelectConfiguration there is no error So I am thinking SelectConfiguration call is making device to go to undesired state ,its causing bus reset We are calling SelectConfiguration as per the specification Same program works with mobile device which had 4.14 kernel version even on calling SelectConfiguration Is there any log which would give more info on what actually is happening to the device on calling Selectonfiguration I am sure SelectConfiguration is doing something to the device,however no logs are helping much -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #37 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #35) > Come to think of it, that particular change probably _won't_ affect your > Get-String-Descriptor call. It only affects bulk and interrupt endpoints, > not control or isochronous endpoints, and Get-String-Descriptor uses > endpoint 0 (which is a control endpoint). > > Not calling Set-Config seems like the best workaround. Is there any reason > why your program calls it in the first place? Isn't the device already > using the configuration you want? I also see when Set-Config is called from Windows device there is no issue -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #38 from Alan Stern (stern@rowland.harvard.edu) --- \Is there any way to find out exactly what Windows sends to the device? Maybe it's different from what your program sends. Keep in mind also that the kernel sends a Set-Config request to the device when you plug it into the computer. That request doesn't appear to cause problems either. The only logs which might give you more information about what's happening on the device are the device's own logs. Maybe you can learn something, for example, by running dmesg in a terminal app on the device. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #39 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #38) > \Is there any way to find out exactly what Windows sends to the device? > Maybe it's different from what your program sends. > > Keep in mind also that the kernel sends a Set-Config request to the device > when you plug it into the computer. That request doesn't appear to cause > problems either. > > The only logs which might give you more information about what's happening > on the device are the device's own logs. Maybe you can learn something, for > example, by running dmesg in a terminal app on the device. Keep in mind also that the kernel sends a Set-Config request to the device when you plug it into the computer. That request doesn't appear to cause problems either-This doesn't cause problem when the kernel first sends set-config,only problem happens when there is one more select-config call on the same device Its happening only with mobile,other devices are working fine -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 Lars Melin (larsm17@gmail.com) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |larsm17@gmail.com --- Comment #40 from Lars Melin (larsm17@gmail.com) --- (In reply to rachithas104 from comment #37) > I also see when Set-Config is called from Windows device there is no issue That may be because Windows apparently does not go directly to a new configuration, it first goes to config #0 and waits a while to let the device reset its config, then selects the new config. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #41 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #40) > (In reply to rachithas104 from comment #37) > > > I also see when Set-Config is called from Windows device there is no issue > > That may be because Windows apparently does not go directly to a new > configuration, it first goes to config #0 and waits a while to let the > device reset its config, then selects the new config. I have compared wireshark usb traces,calls are similar -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #42 from Lars Melin (larsm17@gmail.com) --- It won't take you long to change your program to select config#0, wait 100mS, then select the intended config in order to test if that is the problem. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #43 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #42) > It won't take you long to change your program to select config#0, wait > 100mS, then select the intended config in order to test if that is the > problem. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=102 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2717 ProdID=ff18 Rev= 4.19 S: Manufacturer=Xiaomi S: Product=Redmi S: SerialNumber=c2a85d9 C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 28 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms There is only one configuration -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #44 from Lars Melin (larsm17@gmail.com) --- (In reply to rachithas104 from comment #43) > There is only one configuration So why do you then select configuration when the configuration descriptor tells you that there is only one? You have a 'user space driver' attached to the PTP interface, are you running under a virtual machine or what is that driver? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #45 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #44) > (In reply to rachithas104 from comment #43) > > > There is only one configuration > > So why do you then select configuration when the configuration descriptor > tells you that there is only one? > > You have a 'user space driver' attached to the PTP interface, are you > running under a virtual machine or what is that driver? I am selecting the config as per spec, I am running in Ubuntu laptop and I have user space driver -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #46 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #44) > (In reply to rachithas104 from comment #43) > > > There is only one configuration > > So why do you then select configuration when the configuration descriptor > tells you that there is only one? > > You have a 'user space driver' attached to the PTP interface, are you > running under a virtual machine or what is that driver? It works with this device having low kernel version Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=100 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2717 ProdID=ff18 Rev= 3.10 S: Manufacturer=Xiaomi S: Product=MI S: SerialNumber=d553b4b6 C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 28 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #47 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #44) > (In reply to rachithas104 from comment #43) > > > There is only one configuration > > So why do you then select configuration when the configuration descriptor > tells you that there is only one? > > You have a 'user space driver' attached to the PTP interface, are you > running under a virtual machine or what is that driver? Also I see when submiting URB's to endpoint OX81 is resulting in failure I dont see signal gets reaped -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #48 from rachithas104@gmail.com --- Created attachment 292945 --> https://bugzilla.kernel.org/attachment.cgi?id=292945&action=edit device in ptp mode without calling SelectConfiguration device in ptp mode without calling SelectConfiguration -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #49 from rachithas104@gmail.com --- Created attachment 292947 --> https://bugzilla.kernel.org/attachment.cgi?id=292947&action=edit device in ptp mode calling SelectConfiguration device in ptp mode calling SelectConfiguration -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #50 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #44) > (In reply to rachithas104 from comment #43) > > > There is only one configuration > > So why do you then select configuration when the configuration descriptor > tells you that there is only one? > > You have a 'user space driver' attached to the PTP interface, are you > running under a virtual machine or what is that driver? I have attached traces when I am trying to enumerate mobile device in PTP mode Working-without calling SelectConfiguration Non-working -calling SelectConfiguration -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #51 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #44) > (In reply to rachithas104 from comment #43) > > > There is only one configuration > > So why do you then select configuration when the configuration descriptor > tells you that there is only one? > > You have a 'user space driver' attached to the PTP interface, are you > running under a virtual machine or what is that driver? Can you kindly help -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #52 from rachithas104@gmail.com --- (In reply to Lars Melin from comment #42) > It won't take you long to change your program to select config#0, wait > 100mS, then select the intended config in order to test if that is the > problem. Tried this but still same results -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #53 from Alan Stern (stern@rowland.harvard.edu) --- The nonworking trace doesn't show any errors. In fact, it looks almost exactly the same as the working trace, except that it has a Set-Config request and it ends earlier. Since your program works when it doesn't issue the Set-Config request, why not simply avoid doing that? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #54 from rachithas104@gmail.com --- (In reply to Alan Stern from comment #53) > The nonworking trace doesn't show any errors. In fact, it looks almost > exactly the same as the working trace, except that it has a Set-Config > request and it ends earlier. > > Since your program works when it doesn't issue the Set-Config request, why > not simply avoid doing that? Correct non working trace doesn't show any errors,thats the reason wanted to know what is happening internally,it is happening with most Android phones,whereas some phones work. I can avoid set-config request,but just wanted to know more why this has started happening,Since with all device we call Select-Configuration and it works fine -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209411 --- Comment #55 from Alan Stern (stern@rowland.harvard.edu) --- Sorry, I don't think anybody reading this bug report knows what's happening on your phone. We don't even know what software is running on the phone; Android is different from ordinary Linux. You should try asking the people who made the phone. -- You are receiving this mail because: You are watching the assignee of the bug.