| Message ID | 1623923899-16759-1-git-send-email-wcheng@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Re-introduce TX FIFO resize for larger EP bursting | expand |
Hi Op 17-06-2021 om 11:58 schreef Wesley Cheng: > Changes in V10: > - Fixed compilation errors in config where OF is not used (error due to > unknown symbol for of_add_property()). Add of_add_property() stub. > - Fixed compilation warning for incorrect argument being passed to dwc3_mdwidth This fixes the OOPS I had in V9. I do not see any change in performance on Merrifield though. > Changes in V9: > - Fixed incorrect patch in series. Removed changes in DTSI, as dwc3-qcom will > add the property by default from the kernel. > > Changes in V8: > - Rebased to usb-testing > - Using devm_kzalloc for adding txfifo property in dwc3-qcom > - Removed DWC3 QCOM ACPI property for enabling the txfifo resize > > Changes in V7: > - Added a new property tx-fifo-max-num for limiting how much fifo space the > resizing logic can allocate for endpoints with large burst values. This > can differ across platforms, and tie in closely with overall system latency. > - Added recommended checks for DWC32. > - Added changes to set the tx-fifo-resize property from dwc3-qcom by default > instead of modifying the current DTSI files. > - Added comments on all APIs/variables introduced. > - Updated the DWC3 YAML to include a better description of the tx-fifo-resize > property and added an entry for tx-fifo-max-num. > > Changes in V6: > - Rebased patches to usb-testing. > - Renamed to PATCH series instead of RFC. > - Checking for fs_descriptors instead of ss_descriptors for determining the > endpoint count for a particular configuration. > - Re-ordered patch series to fix patch dependencies. > > Changes in V5: > - Added check_config() logic, which is used to communicate the number of EPs > used in a particular configuration. Based on this, the DWC3 gadget driver > has the ability to know the maximum number of eps utilized in all configs. > This helps reduce unnecessary allocation to unused eps, and will catch fifo > allocation issues at bind() time. > - Fixed variable declaration to single line per variable, and reverse xmas. > - Created a helper for fifo clearing, which is used by ep0.c > > Changes in V4: > - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() > - Removed WARN_ON(1) in case we run out of fifo space > > Changes in V3: > - Removed "Reviewed-by" tags > - Renamed series back to RFC > - Modified logic to ensure that fifo_size is reset if we pass the minimum > threshold. Tested with binding multiple FDs requesting 6 FIFOs. > > Changes in V2: > - Modified TXFIFO resizing logic to ensure that each EP is reserved a > FIFO. > - Removed dev_dbg() prints and fixed typos from patches > - Added some more description on the dt-bindings commit message > > Currently, there is no functionality to allow for resizing the TXFIFOs, and > relying on the HW default setting for the TXFIFO depth. In most cases, the > HW default is probably sufficient, but for USB compositions that contain > multiple functions that require EP bursting, the default settings > might not be enough. Also to note, the current SW will assign an EP to a > function driver w/o checking to see if the TXFIFO size for that particular > EP is large enough. (this is a problem if there are multiple HW defined > values for the TXFIFO size) > > It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 > is required for an EP that supports bursting. Otherwise, there may be > frequent occurences of bursts ending. For high bandwidth functions, > such as data tethering (protocols that support data aggregation), mass > storage, and media transfer protocol (over FFS), the bMaxBurst value can be > large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB > throughput. (which can be associated to system access latency, etc...) It > allows for a more consistent burst of traffic, w/o any interruptions, as > data is readily available in the FIFO. > > With testing done using the mass storage function driver, the results show > that with a larger TXFIFO depth, the bandwidth increased significantly. > > Test Parameters: > - Platform: Qualcomm SM8150 > - bMaxBurst = 6 > - USB req size = 256kB > - Num of USB reqs = 16 > - USB Speed = Super-Speed > - Function Driver: Mass Storage (w/ ramdisk) > - Test Application: CrystalDiskMark > > Results: > > TXFIFO Depth = 3 max packets > > Test Case | Data Size | AVG tput (in MB/s) > ------------------------------------------- > Sequential|1 GB x | > Read |9 loops | 193.60 > | | 195.86 > | | 184.77 > | | 193.60 > ------------------------------------------- > > TXFIFO Depth = 6 max packets > > Test Case | Data Size | AVG tput (in MB/s) > ------------------------------------------- > Sequential|1 GB x | > Read |9 loops | 287.35 > | | 304.94 > | | 289.64 > | | 293.61 > ------------------------------------------- > > Wesley Cheng (6): > usb: gadget: udc: core: Introduce check_config to verify USB > configuration > usb: gadget: configfs: Check USB configuration before adding > usb: dwc3: Resize TX FIFOs to meet EP bursting requirements > of: Add stub for of_add_property() > usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default > dt-bindings: usb: dwc3: Update dwc3 TX fifo properties > > .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- > drivers/usb/dwc3/core.c | 9 + > drivers/usb/dwc3/core.h | 15 ++ > drivers/usb/dwc3/dwc3-qcom.c | 9 + > drivers/usb/dwc3/ep0.c | 2 + > drivers/usb/dwc3/gadget.c | 212 +++++++++++++++++++++ > drivers/usb/gadget/configfs.c | 22 +++ > drivers/usb/gadget/udc/core.c | 25 +++ > include/linux/of.h | 5 + > include/linux/usb/gadget.h | 5 + > 10 files changed, 317 insertions(+), 2 deletions(-) >
Hi, On 6/17/2021 2:01 PM, Ferry Toth wrote: > Hi > > Op 17-06-2021 om 11:58 schreef Wesley Cheng: >> Changes in V10: >> - Fixed compilation errors in config where OF is not used (error due to >> unknown symbol for of_add_property()). Add of_add_property() stub. >> - Fixed compilation warning for incorrect argument being passed to >> dwc3_mdwidth > This fixes the OOPS I had in V9. I do not see any change in performance > on Merrifield though. I see...thanks Ferry! With your testing, are you writing to the device's internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as well? If not with a ramdisk, we might want to give that a try to avoid the storage path being the bottleneck. You can use "dd" to create an empty file, and then just use that as the LUN's backing file. echo ramdisk.img > /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file Thanks Wesley Cheng >> Changes in V9: >> - Fixed incorrect patch in series. Removed changes in DTSI, as >> dwc3-qcom will >> add the property by default from the kernel. >> >> Changes in V8: >> - Rebased to usb-testing >> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >> - Removed DWC3 QCOM ACPI property for enabling the txfifo resize >> >> Changes in V7: >> - Added a new property tx-fifo-max-num for limiting how much fifo >> space the >> resizing logic can allocate for endpoints with large burst >> values. This >> can differ across platforms, and tie in closely with overall >> system latency. >> - Added recommended checks for DWC32. >> - Added changes to set the tx-fifo-resize property from dwc3-qcom by >> default >> instead of modifying the current DTSI files. >> - Added comments on all APIs/variables introduced. >> - Updated the DWC3 YAML to include a better description of the >> tx-fifo-resize >> property and added an entry for tx-fifo-max-num. >> >> Changes in V6: >> - Rebased patches to usb-testing. >> - Renamed to PATCH series instead of RFC. >> - Checking for fs_descriptors instead of ss_descriptors for >> determining the >> endpoint count for a particular configuration. >> - Re-ordered patch series to fix patch dependencies. >> >> Changes in V5: >> - Added check_config() logic, which is used to communicate the >> number of EPs >> used in a particular configuration. Based on this, the DWC3 >> gadget driver >> has the ability to know the maximum number of eps utilized in all >> configs. >> This helps reduce unnecessary allocation to unused eps, and will >> catch fifo >> allocation issues at bind() time. >> - Fixed variable declaration to single line per variable, and >> reverse xmas. >> - Created a helper for fifo clearing, which is used by ep0.c >> >> Changes in V4: >> - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() >> - Removed WARN_ON(1) in case we run out of fifo space >> Changes in V3: >> - Removed "Reviewed-by" tags >> - Renamed series back to RFC >> - Modified logic to ensure that fifo_size is reset if we pass the >> minimum >> threshold. Tested with binding multiple FDs requesting 6 FIFOs. >> >> Changes in V2: >> - Modified TXFIFO resizing logic to ensure that each EP is reserved a >> FIFO. >> - Removed dev_dbg() prints and fixed typos from patches >> - Added some more description on the dt-bindings commit message >> >> Currently, there is no functionality to allow for resizing the >> TXFIFOs, and >> relying on the HW default setting for the TXFIFO depth. In most >> cases, the >> HW default is probably sufficient, but for USB compositions that contain >> multiple functions that require EP bursting, the default settings >> might not be enough. Also to note, the current SW will assign an EP to a >> function driver w/o checking to see if the TXFIFO size for that >> particular >> EP is large enough. (this is a problem if there are multiple HW defined >> values for the TXFIFO size) >> >> It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 >> is required for an EP that supports bursting. Otherwise, there may be >> frequent occurences of bursts ending. For high bandwidth functions, >> such as data tethering (protocols that support data aggregation), mass >> storage, and media transfer protocol (over FFS), the bMaxBurst value >> can be >> large, and a bigger TXFIFO depth may prove to be beneficial in terms >> of USB >> throughput. (which can be associated to system access latency, >> etc...) It >> allows for a more consistent burst of traffic, w/o any interruptions, as >> data is readily available in the FIFO. >> >> With testing done using the mass storage function driver, the results >> show >> that with a larger TXFIFO depth, the bandwidth increased significantly. >> >> Test Parameters: >> - Platform: Qualcomm SM8150 >> - bMaxBurst = 6 >> - USB req size = 256kB >> - Num of USB reqs = 16 >> - USB Speed = Super-Speed >> - Function Driver: Mass Storage (w/ ramdisk) >> - Test Application: CrystalDiskMark >> >> Results: >> >> TXFIFO Depth = 3 max packets >> >> Test Case | Data Size | AVG tput (in MB/s) >> ------------------------------------------- >> Sequential|1 GB x | >> Read |9 loops | 193.60 >> | | 195.86 >> | | 184.77 >> | | 193.60 >> ------------------------------------------- >> >> TXFIFO Depth = 6 max packets >> >> Test Case | Data Size | AVG tput (in MB/s) >> ------------------------------------------- >> Sequential|1 GB x | >> Read |9 loops | 287.35 >> | | 304.94 >> | | 289.64 >> | | 293.61 >> ------------------------------------------- >> >> Wesley Cheng (6): >> usb: gadget: udc: core: Introduce check_config to verify USB >> configuration >> usb: gadget: configfs: Check USB configuration before adding >> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >> of: Add stub for of_add_property() >> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default >> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >> >> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >> drivers/usb/dwc3/core.c | 9 + >> drivers/usb/dwc3/core.h | 15 ++ >> drivers/usb/dwc3/dwc3-qcom.c | 9 + >> drivers/usb/dwc3/ep0.c | 2 + >> drivers/usb/dwc3/gadget.c | 212 >> +++++++++++++++++++++ >> drivers/usb/gadget/configfs.c | 22 +++ >> drivers/usb/gadget/udc/core.c | 25 +++ >> include/linux/of.h | 5 + >> include/linux/usb/gadget.h | 5 + >> 10 files changed, 317 insertions(+), 2 deletions(-) >>
Hi, On 6/17/2021 2:55 PM, Ferry Toth wrote: > Hi > > Op 17-06-2021 om 23:48 schreef Wesley Cheng: >> Hi, >> >> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>> Hi >>> >>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>> Changes in V10: >>>> - Fixed compilation errors in config where OF is not used (error due to >>>> unknown symbol for of_add_property()). Add of_add_property() stub. >>>> - Fixed compilation warning for incorrect argument being passed to >>>> dwc3_mdwidth >>> This fixes the OOPS I had in V9. I do not see any change in performance >>> on Merrifield though. >> I see...thanks Ferry! With your testing, are you writing to the device's >> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as well? > > In this case I just tested the EEM path using iperf3. > Got it. I don't believe f_eem will use a high enough (if at all) bMaxBurst value to change the TXFIFO size. >> If not with a ramdisk, we might want to give that a try to avoid the >> storage path being the bottleneck. You can use "dd" to create an empty >> file, and then just use that as the LUN's backing file. >> >> echo ramdisk.img > >> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file > > Ah, why didn't I think of that. I have currently mass storage setup with > eMMC but it seems that is indeed the bottleneck. > :), not a problem...I've been working on getting the ideal set up for the performance profiling for awhile, so anything I can do to make sure we get some good results. > I'll try with a ramdisk and let you know. > Thanks again for the testing, Ferry. Thanks Wesley Cheng >> Thanks >> Wesley Cheng >> >>>> Changes in V9: >>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>> dwc3-qcom will >>>> add the property by default from the kernel. >>>> >>>> Changes in V8: >>>> - Rebased to usb-testing >>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo resize >>>> >>>> Changes in V7: >>>> - Added a new property tx-fifo-max-num for limiting how much fifo >>>> space the >>>> resizing logic can allocate for endpoints with large burst >>>> values. This >>>> can differ across platforms, and tie in closely with overall >>>> system latency. >>>> - Added recommended checks for DWC32. >>>> - Added changes to set the tx-fifo-resize property from dwc3-qcom by >>>> default >>>> instead of modifying the current DTSI files. >>>> - Added comments on all APIs/variables introduced. >>>> - Updated the DWC3 YAML to include a better description of the >>>> tx-fifo-resize >>>> property and added an entry for tx-fifo-max-num. >>>> >>>> Changes in V6: >>>> - Rebased patches to usb-testing. >>>> - Renamed to PATCH series instead of RFC. >>>> - Checking for fs_descriptors instead of ss_descriptors for >>>> determining the >>>> endpoint count for a particular configuration. >>>> - Re-ordered patch series to fix patch dependencies. >>>> >>>> Changes in V5: >>>> - Added check_config() logic, which is used to communicate the >>>> number of EPs >>>> used in a particular configuration. Based on this, the DWC3 >>>> gadget driver >>>> has the ability to know the maximum number of eps utilized in all >>>> configs. >>>> This helps reduce unnecessary allocation to unused eps, and will >>>> catch fifo >>>> allocation issues at bind() time. >>>> - Fixed variable declaration to single line per variable, and >>>> reverse xmas. >>>> - Created a helper for fifo clearing, which is used by ep0.c >>>> >>>> Changes in V4: >>>> - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() >>>> - Removed WARN_ON(1) in case we run out of fifo space >>>> Changes in V3: >>>> - Removed "Reviewed-by" tags >>>> - Renamed series back to RFC >>>> - Modified logic to ensure that fifo_size is reset if we pass the >>>> minimum >>>> threshold. Tested with binding multiple FDs requesting 6 FIFOs. >>>> >>>> Changes in V2: >>>> - Modified TXFIFO resizing logic to ensure that each EP is reserved a >>>> FIFO. >>>> - Removed dev_dbg() prints and fixed typos from patches >>>> - Added some more description on the dt-bindings commit message >>>> >>>> Currently, there is no functionality to allow for resizing the >>>> TXFIFOs, and >>>> relying on the HW default setting for the TXFIFO depth. In most >>>> cases, the >>>> HW default is probably sufficient, but for USB compositions that contain >>>> multiple functions that require EP bursting, the default settings >>>> might not be enough. Also to note, the current SW will assign an EP to a >>>> function driver w/o checking to see if the TXFIFO size for that >>>> particular >>>> EP is large enough. (this is a problem if there are multiple HW defined >>>> values for the TXFIFO size) >>>> >>>> It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 >>>> is required for an EP that supports bursting. Otherwise, there may be >>>> frequent occurences of bursts ending. For high bandwidth functions, >>>> such as data tethering (protocols that support data aggregation), mass >>>> storage, and media transfer protocol (over FFS), the bMaxBurst value >>>> can be >>>> large, and a bigger TXFIFO depth may prove to be beneficial in terms >>>> of USB >>>> throughput. (which can be associated to system access latency, >>>> etc...) It >>>> allows for a more consistent burst of traffic, w/o any interruptions, as >>>> data is readily available in the FIFO. >>>> >>>> With testing done using the mass storage function driver, the results >>>> show >>>> that with a larger TXFIFO depth, the bandwidth increased significantly. >>>> >>>> Test Parameters: >>>> - Platform: Qualcomm SM8150 >>>> - bMaxBurst = 6 >>>> - USB req size = 256kB >>>> - Num of USB reqs = 16 >>>> - USB Speed = Super-Speed >>>> - Function Driver: Mass Storage (w/ ramdisk) >>>> - Test Application: CrystalDiskMark >>>> >>>> Results: >>>> >>>> TXFIFO Depth = 3 max packets >>>> >>>> Test Case | Data Size | AVG tput (in MB/s) >>>> ------------------------------------------- >>>> Sequential|1 GB x | >>>> Read |9 loops | 193.60 >>>> | | 195.86 >>>> | | 184.77 >>>> | | 193.60 >>>> ------------------------------------------- >>>> >>>> TXFIFO Depth = 6 max packets >>>> >>>> Test Case | Data Size | AVG tput (in MB/s) >>>> ------------------------------------------- >>>> Sequential|1 GB x | >>>> Read |9 loops | 287.35 >>>> | | 304.94 >>>> | | 289.64 >>>> | | 293.61 >>>> ------------------------------------------- >>>> >>>> Wesley Cheng (6): >>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>> configuration >>>> usb: gadget: configfs: Check USB configuration before adding >>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>> of: Add stub for of_add_property() >>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default >>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>> >>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>> drivers/usb/dwc3/core.c | 9 + >>>> drivers/usb/dwc3/core.h | 15 ++ >>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>> drivers/usb/dwc3/ep0.c | 2 + >>>> drivers/usb/dwc3/gadget.c | 212 >>>> +++++++++++++++++++++ >>>> drivers/usb/gadget/configfs.c | 22 +++ >>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>> include/linux/of.h | 5 + >>>> include/linux/usb/gadget.h | 5 + >>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>
Hi Op 18-06-2021 om 00:25 schreef Wesley Cheng: > Hi, > > On 6/17/2021 2:55 PM, Ferry Toth wrote: >> Hi >> >> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>> Hi, >>> >>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>> Hi >>>> >>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>> Changes in V10: >>>>> - Fixed compilation errors in config where OF is not used (error due to >>>>> unknown symbol for of_add_property()). Add of_add_property() stub. >>>>> - Fixed compilation warning for incorrect argument being passed to >>>>> dwc3_mdwidth >>>> This fixes the OOPS I had in V9. I do not see any change in performance >>>> on Merrifield though. >>> I see...thanks Ferry! With your testing, are you writing to the device's >>> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as well? >> In this case I just tested the EEM path using iperf3. >> > Got it. I don't believe f_eem will use a high enough (if at all) > bMaxBurst value to change the TXFIFO size. > >>> If not with a ramdisk, we might want to give that a try to avoid the >>> storage path being the bottleneck. You can use "dd" to create an empty >>> file, and then just use that as the LUN's backing file. >>> >>> echo ramdisk.img > >>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >> Ah, why didn't I think of that. I have currently mass storage setup with >> eMMC but it seems that is indeed the bottleneck. >> I created a 64MB disk following the instructions here http://www.linux-usb.org/gadget/file_storage.html (that seems a little outdated, at least I can not start the first partition at sector 8, but minimum 2048), and added a test file on it. I then copy the file to /dev/shm prior to setting configfs (composite device gser/eem/mass_storage/uac2). journal shows: kernel: Mass Storage Function, version: 2009/09/11 kernel: LUN: removable file: (no medium) I don't know what that means, because I see the test file on the ramdisk. Then I again used gnome disks to benchmark (read/write 10MB): With V10 on top v5.13.0-rc5: R/W speed = 35.6/35.8MB/s, access time 0.35ms With no patches on top v5.12.0: R/W speed = 35.7/36.1MB/s, access time 0.35ms I see no speed difference (and it's about the same as with the eMMC backed disk). But the patches are causing a new call trace kernel: using random self ethernet address kernel: using random host ethernet address kernel: Mass Storage Function, version: 2009/09/11 kernel: LUN: removable file: (no medium) kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 kernel: usb0: MAC aa:bb:cc:dd:ee:f1 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in depth:115540359 kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 usb_ep_queue+0x75/0x80 kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat bnep snd_sof_nocodec spi_pxa2> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted 5.13.0-rc5-edison-acpi-standard #1 kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 kernel: RIP: 0010:usb_ep_queue+0x75/0x80 kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 <0f> 0b 41 bd 94 ff ff ff > kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: ffff8af202f06400 kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: ffff8af202e9ae00 kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: ffff8af208785780 kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: ffff8af208785780 kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: ffff8af203e26cc0 kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: 00000000001006f0 kernel: Call Trace: kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] kernel: composite_setup+0x224/0x1ba0 [libcomposite] kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 kernel: ? usb_ep_queue+0x2a/0x80 kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] kernel: dwc3_ep0_interrupt+0x469/0xa80 kernel: dwc3_thread_interrupt+0x8ee/0xf40 kernel: ? __wake_up_common_lock+0x85/0xb0 kernel: ? disable_irq_nosync+0x10/0x10 kernel: irq_thread_fn+0x1b/0x60 kernel: irq_thread+0xd6/0x170 kernel: ? irq_thread_check_affinity+0x70/0x70 kernel: ? irq_forced_thread_fn+0x70/0x70 kernel: kthread+0x116/0x130 kernel: ? kthread_create_worker_on_cpu+0x60/0x60 kernel: ret_from_fork+0x22/0x30 kernel: ---[ end trace e5b9e28058c53584 ]--- kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in depth:115540359 kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to ep5in kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in depth:115540359 kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in depth:115540359 kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in depth:115540359 kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in Removing uac2 from the config makes the call trace go away, but the R/W speed does not change. > :), not a problem...I've been working on getting the ideal set up for > the performance profiling for awhile, so anything I can do to make sure > we get some good results. > >> I'll try with a ramdisk and let you know. >> > Thanks again for the testing, Ferry. > > Thanks > Wesley Cheng > >>> Thanks >>> Wesley Cheng >>> >>>>> Changes in V9: >>>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>>> dwc3-qcom will >>>>> add the property by default from the kernel. >>>>> >>>>> Changes in V8: >>>>> - Rebased to usb-testing >>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo resize >>>>> >>>>> Changes in V7: >>>>> - Added a new property tx-fifo-max-num for limiting how much fifo >>>>> space the >>>>> resizing logic can allocate for endpoints with large burst >>>>> values. This >>>>> can differ across platforms, and tie in closely with overall >>>>> system latency. >>>>> - Added recommended checks for DWC32. >>>>> - Added changes to set the tx-fifo-resize property from dwc3-qcom by >>>>> default >>>>> instead of modifying the current DTSI files. >>>>> - Added comments on all APIs/variables introduced. >>>>> - Updated the DWC3 YAML to include a better description of the >>>>> tx-fifo-resize >>>>> property and added an entry for tx-fifo-max-num. >>>>> >>>>> Changes in V6: >>>>> - Rebased patches to usb-testing. >>>>> - Renamed to PATCH series instead of RFC. >>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>> determining the >>>>> endpoint count for a particular configuration. >>>>> - Re-ordered patch series to fix patch dependencies. >>>>> >>>>> Changes in V5: >>>>> - Added check_config() logic, which is used to communicate the >>>>> number of EPs >>>>> used in a particular configuration. Based on this, the DWC3 >>>>> gadget driver >>>>> has the ability to know the maximum number of eps utilized in all >>>>> configs. >>>>> This helps reduce unnecessary allocation to unused eps, and will >>>>> catch fifo >>>>> allocation issues at bind() time. >>>>> - Fixed variable declaration to single line per variable, and >>>>> reverse xmas. >>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>> >>>>> Changes in V4: >>>>> - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() >>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>> Changes in V3: >>>>> - Removed "Reviewed-by" tags >>>>> - Renamed series back to RFC >>>>> - Modified logic to ensure that fifo_size is reset if we pass the >>>>> minimum >>>>> threshold. Tested with binding multiple FDs requesting 6 FIFOs. >>>>> >>>>> Changes in V2: >>>>> - Modified TXFIFO resizing logic to ensure that each EP is reserved a >>>>> FIFO. >>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>> - Added some more description on the dt-bindings commit message >>>>> >>>>> Currently, there is no functionality to allow for resizing the >>>>> TXFIFOs, and >>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>> cases, the >>>>> HW default is probably sufficient, but for USB compositions that contain >>>>> multiple functions that require EP bursting, the default settings >>>>> might not be enough. Also to note, the current SW will assign an EP to a >>>>> function driver w/o checking to see if the TXFIFO size for that >>>>> particular >>>>> EP is large enough. (this is a problem if there are multiple HW defined >>>>> values for the TXFIFO size) >>>>> >>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 >>>>> is required for an EP that supports bursting. Otherwise, there may be >>>>> frequent occurences of bursts ending. For high bandwidth functions, >>>>> such as data tethering (protocols that support data aggregation), mass >>>>> storage, and media transfer protocol (over FFS), the bMaxBurst value >>>>> can be >>>>> large, and a bigger TXFIFO depth may prove to be beneficial in terms >>>>> of USB >>>>> throughput. (which can be associated to system access latency, >>>>> etc...) It >>>>> allows for a more consistent burst of traffic, w/o any interruptions, as >>>>> data is readily available in the FIFO. >>>>> >>>>> With testing done using the mass storage function driver, the results >>>>> show >>>>> that with a larger TXFIFO depth, the bandwidth increased significantly. >>>>> >>>>> Test Parameters: >>>>> - Platform: Qualcomm SM8150 >>>>> - bMaxBurst = 6 >>>>> - USB req size = 256kB >>>>> - Num of USB reqs = 16 >>>>> - USB Speed = Super-Speed >>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>> - Test Application: CrystalDiskMark >>>>> >>>>> Results: >>>>> >>>>> TXFIFO Depth = 3 max packets >>>>> >>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>> ------------------------------------------- >>>>> Sequential|1 GB x | >>>>> Read |9 loops | 193.60 >>>>> | | 195.86 >>>>> | | 184.77 >>>>> | | 193.60 >>>>> ------------------------------------------- >>>>> >>>>> TXFIFO Depth = 6 max packets >>>>> >>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>> ------------------------------------------- >>>>> Sequential|1 GB x | >>>>> Read |9 loops | 287.35 >>>>> | | 304.94 >>>>> | | 289.64 >>>>> | | 293.61 >>>>> ------------------------------------------- >>>>> >>>>> Wesley Cheng (6): >>>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>>> configuration >>>>> usb: gadget: configfs: Check USB configuration before adding >>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>> of: Add stub for of_add_property() >>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default >>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>> >>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>> drivers/usb/dwc3/core.c | 9 + >>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>> drivers/usb/dwc3/gadget.c | 212 >>>>> +++++++++++++++++++++ >>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>> include/linux/of.h | 5 + >>>>> include/linux/usb/gadget.h | 5 + >>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>
On 6/19/2021 5:40 AM, Ferry Toth wrote: > Hi > > Op 18-06-2021 om 00:25 schreef Wesley Cheng: >> Hi, >> >> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>> Hi >>> >>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>> Hi, >>>> >>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>> Hi >>>>> >>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>> Changes in V10: >>>>>> - Fixed compilation errors in config where OF is not used >>>>>> (error due to >>>>>> unknown symbol for of_add_property()). Add of_add_property() >>>>>> stub. >>>>>> - Fixed compilation warning for incorrect argument being passed to >>>>>> dwc3_mdwidth >>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>> performance >>>>> on Merrifield though. >>>> I see...thanks Ferry! With your testing, are you writing to the >>>> device's >>>> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as >>>> well? >>> In this case I just tested the EEM path using iperf3. >>> >> Got it. I don't believe f_eem will use a high enough (if at all) >> bMaxBurst value to change the TXFIFO size. >> >>>> If not with a ramdisk, we might want to give that a try to avoid the >>>> storage path being the bottleneck. You can use "dd" to create an empty >>>> file, and then just use that as the LUN's backing file. >>>> >>>> echo ramdisk.img > >>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>> Ah, why didn't I think of that. I have currently mass storage setup with >>> eMMC but it seems that is indeed the bottleneck. >>> > I created a 64MB disk following the instructions here > http://www.linux-usb.org/gadget/file_storage.html (that seems a little > outdated, at least I can not start the first partition at sector 8, but > minimum 2048), and added a test file on it. > > I then copy the file to /dev/shm prior to setting configfs (composite > device gser/eem/mass_storage/uac2). > > journal shows: > > kernel: Mass Storage Function, version: 2009/09/11 > kernel: LUN: removable file: (no medium) > > I don't know what that means, because I see the test file on the ramdisk. > > Then I again used gnome disks to benchmark (read/write 10MB): > > With V10 on top v5.13.0-rc5: > > R/W speed = 35.6/35.8MB/s, access time 0.35ms > > With no patches on top v5.12.0: > > R/W speed = 35.7/36.1MB/s, access time 0.35ms Hi Ferry, > > I see no speed difference (and it's about the same as with the eMMC > backed disk). But the patches are causing a new call trace > Would you happen to know what DWC3 controller revision the device is using? The callstack print occurs, because it looks like it ran out of internal memory, although there should be logic present for making sure that at least there is enough room for 1 FIFO per endpoint. (possibly the logic/math depends on the controller revision) Also, is there a way to use just a mass storage only composition? Based on the above observation, that probably means that the mass storage interface wasn't resized at all, because the configuration took up a lot of the internal FIFO space. Thanks Wesley Cheng > kernel: using random self ethernet address > kernel: using random host ethernet address > kernel: Mass Storage Function, version: 2009/09/11 > kernel: LUN: removable file: (no medium) > kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 > kernel: usb0: MAC aa:bb:cc:dd:ee:f1 > kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready > kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in > depth:115540359 > kernel: ------------[ cut here ]------------ > kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 > usb_ep_queue+0x75/0x80 > kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage > usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat > bnep snd_sof_nocodec spi_pxa2> > kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted > 5.13.0-rc5-edison-acpi-standard #1 > kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 > 2015.01.21:18.19.48 > kernel: RIP: 0010:usb_ep_queue+0x75/0x80 > kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 > 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 > <0f> 0b 41 bd 94 ff ff ff > > kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 > kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: ffff8af202f06400 > kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: ffff8af202e9ae00 > kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: ffff8af208785780 > kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: ffff8af208785780 > kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: ffff8af203e26cc0 > kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) > knlGS:0000000000000000 > kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: 00000000001006f0 > kernel: Call Trace: > kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] > kernel: composite_setup+0x224/0x1ba0 [libcomposite] > kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 > kernel: ? usb_ep_queue+0x2a/0x80 > kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] > kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] > kernel: dwc3_ep0_interrupt+0x469/0xa80 > kernel: dwc3_thread_interrupt+0x8ee/0xf40 > kernel: ? __wake_up_common_lock+0x85/0xb0 > kernel: ? disable_irq_nosync+0x10/0x10 > kernel: irq_thread_fn+0x1b/0x60 > kernel: irq_thread+0xd6/0x170 > kernel: ? irq_thread_check_affinity+0x70/0x70 > kernel: ? irq_forced_thread_fn+0x70/0x70 > kernel: kthread+0x116/0x130 > kernel: ? kthread_create_worker_on_cpu+0x60/0x60 > kernel: ret_from_fork+0x22/0x30 > kernel: ---[ end trace e5b9e28058c53584 ]--- > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in > depth:115540359 > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in > depth:115540359 > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in > depth:115540359 > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in > depth:115540359 > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! > kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in > kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in > > Removing uac2 from the config makes the call trace go away, but the R/W > speed does not change. > >> :), not a problem...I've been working on getting the ideal set up for >> the performance profiling for awhile, so anything I can do to make sure >> we get some good results. >> >>> I'll try with a ramdisk and let you know. >>> >> Thanks again for the testing, Ferry. >> >> Thanks >> Wesley Cheng >> >>>> Thanks >>>> Wesley Cheng >>>> >>>>>> Changes in V9: >>>>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>>>> dwc3-qcom will >>>>>> add the property by default from the kernel. >>>>>> >>>>>> Changes in V8: >>>>>> - Rebased to usb-testing >>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo resize >>>>>> >>>>>> Changes in V7: >>>>>> - Added a new property tx-fifo-max-num for limiting how much fifo >>>>>> space the >>>>>> resizing logic can allocate for endpoints with large burst >>>>>> values. This >>>>>> can differ across platforms, and tie in closely with overall >>>>>> system latency. >>>>>> - Added recommended checks for DWC32. >>>>>> - Added changes to set the tx-fifo-resize property from >>>>>> dwc3-qcom by >>>>>> default >>>>>> instead of modifying the current DTSI files. >>>>>> - Added comments on all APIs/variables introduced. >>>>>> - Updated the DWC3 YAML to include a better description of the >>>>>> tx-fifo-resize >>>>>> property and added an entry for tx-fifo-max-num. >>>>>> >>>>>> Changes in V6: >>>>>> - Rebased patches to usb-testing. >>>>>> - Renamed to PATCH series instead of RFC. >>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>> determining the >>>>>> endpoint count for a particular configuration. >>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>> >>>>>> Changes in V5: >>>>>> - Added check_config() logic, which is used to communicate the >>>>>> number of EPs >>>>>> used in a particular configuration. Based on this, the DWC3 >>>>>> gadget driver >>>>>> has the ability to know the maximum number of eps utilized in >>>>>> all >>>>>> configs. >>>>>> This helps reduce unnecessary allocation to unused eps, and will >>>>>> catch fifo >>>>>> allocation issues at bind() time. >>>>>> - Fixed variable declaration to single line per variable, and >>>>>> reverse xmas. >>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>> >>>>>> Changes in V4: >>>>>> - Removed struct dwc3* as an argument for >>>>>> dwc3_gadget_resize_tx_fifos() >>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>> Changes in V3: >>>>>> - Removed "Reviewed-by" tags >>>>>> - Renamed series back to RFC >>>>>> - Modified logic to ensure that fifo_size is reset if we pass the >>>>>> minimum >>>>>> threshold. Tested with binding multiple FDs requesting 6 FIFOs. >>>>>> >>>>>> Changes in V2: >>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>> reserved a >>>>>> FIFO. >>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>> - Added some more description on the dt-bindings commit message >>>>>> >>>>>> Currently, there is no functionality to allow for resizing the >>>>>> TXFIFOs, and >>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>> cases, the >>>>>> HW default is probably sufficient, but for USB compositions that >>>>>> contain >>>>>> multiple functions that require EP bursting, the default settings >>>>>> might not be enough. Also to note, the current SW will assign an >>>>>> EP to a >>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>> particular >>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>> defined >>>>>> values for the TXFIFO size) >>>>>> >>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>> depth = 3 >>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>> may be >>>>>> frequent occurences of bursts ending. For high bandwidth functions, >>>>>> such as data tethering (protocols that support data aggregation), >>>>>> mass >>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst value >>>>>> can be >>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in terms >>>>>> of USB >>>>>> throughput. (which can be associated to system access latency, >>>>>> etc...) It >>>>>> allows for a more consistent burst of traffic, w/o any >>>>>> interruptions, as >>>>>> data is readily available in the FIFO. >>>>>> >>>>>> With testing done using the mass storage function driver, the results >>>>>> show >>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>> significantly. >>>>>> >>>>>> Test Parameters: >>>>>> - Platform: Qualcomm SM8150 >>>>>> - bMaxBurst = 6 >>>>>> - USB req size = 256kB >>>>>> - Num of USB reqs = 16 >>>>>> - USB Speed = Super-Speed >>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>> - Test Application: CrystalDiskMark >>>>>> >>>>>> Results: >>>>>> >>>>>> TXFIFO Depth = 3 max packets >>>>>> >>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>> ------------------------------------------- >>>>>> Sequential|1 GB x | >>>>>> Read |9 loops | 193.60 >>>>>> | | 195.86 >>>>>> | | 184.77 >>>>>> | | 193.60 >>>>>> ------------------------------------------- >>>>>> >>>>>> TXFIFO Depth = 6 max packets >>>>>> >>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>> ------------------------------------------- >>>>>> Sequential|1 GB x | >>>>>> Read |9 loops | 287.35 >>>>>> | | 304.94 >>>>>> | | 289.64 >>>>>> | | 293.61 >>>>>> ------------------------------------------- >>>>>> >>>>>> Wesley Cheng (6): >>>>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>>>> configuration >>>>>> usb: gadget: configfs: Check USB configuration before adding >>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>> of: Add stub for of_add_property() >>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default >>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>> >>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>> +++++++++++++++++++++ >>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>> include/linux/of.h | 5 + >>>>>> include/linux/usb/gadget.h | 5 + >>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>
Hi Op 22-06-2021 om 20:38 schreef Wesley Cheng: > > On 6/19/2021 5:40 AM, Ferry Toth wrote: >> Hi >> >> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>> Hi, >>> >>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>> Hi >>>> >>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>> Hi, >>>>> >>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>> Hi >>>>>> >>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>> Changes in V10: >>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>> (error due to >>>>>>> unknown symbol for of_add_property()). Add of_add_property() >>>>>>> stub. >>>>>>> - Fixed compilation warning for incorrect argument being passed to >>>>>>> dwc3_mdwidth >>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>> performance >>>>>> on Merrifield though. >>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>> device's >>>>> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as >>>>> well? >>>> In this case I just tested the EEM path using iperf3. >>>> >>> Got it. I don't believe f_eem will use a high enough (if at all) >>> bMaxBurst value to change the TXFIFO size. >>> >>>>> If not with a ramdisk, we might want to give that a try to avoid the >>>>> storage path being the bottleneck. You can use "dd" to create an empty >>>>> file, and then just use that as the LUN's backing file. >>>>> >>>>> echo ramdisk.img > >>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>> Ah, why didn't I think of that. I have currently mass storage setup with >>>> eMMC but it seems that is indeed the bottleneck. >>>> >> I created a 64MB disk following the instructions here >> http://www.linux-usb.org/gadget/file_storage.html (that seems a little >> outdated, at least I can not start the first partition at sector 8, but >> minimum 2048), and added a test file on it. >> >> I then copy the file to /dev/shm prior to setting configfs (composite >> device gser/eem/mass_storage/uac2). >> >> journal shows: >> >> kernel: Mass Storage Function, version: 2009/09/11 >> kernel: LUN: removable file: (no medium) >> >> I don't know what that means, because I see the test file on the ramdisk. >> >> Then I again used gnome disks to benchmark (read/write 10MB): >> >> With V10 on top v5.13.0-rc5: >> >> R/W speed = 35.6/35.8MB/s, access time 0.35ms >> >> With no patches on top v5.12.0: >> >> R/W speed = 35.7/36.1MB/s, access time 0.35ms > Hi Ferry, > >> I see no speed difference (and it's about the same as with the eMMC >> backed disk). But the patches are causing a new call trace >> > Would you happen to know what DWC3 controller revision the device is > using? The callstack print occurs, because it looks like it ran out of > internal memory, although there should be logic present for making sure > that at least there is enough room for 1 FIFO per endpoint. (possibly > the logic/math depends on the controller revision) Do you know where I could find that in a file on the device? Otherwise, I'm hoping Andy will know? > > Also, is there a way to use just a mass storage only composition? Based > on the above observation, that probably means that the mass storage > interface wasn't resized at all, because the configuration took up a lot > of the internal FIFO space. Sure, it's configured through configfs. With only mass_storage I have: With V10 on top v5.13.0-rc5: R/W speed = 41,6/39,3MB/s, access time 0.33ms With no patches on top v5.12.0: R/W speed = 41,1/38,7MB/s, access time 0.38ms > Thanks > Wesley Cheng > >> kernel: using random self ethernet address >> kernel: using random host ethernet address >> kernel: Mass Storage Function, version: 2009/09/11 >> kernel: LUN: removable file: (no medium) >> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: ------------[ cut here ]------------ >> kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 >> usb_ep_queue+0x75/0x80 >> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat >> bnep snd_sof_nocodec spi_pxa2> >> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >> 5.13.0-rc5-edison-acpi-standard #1 >> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >> 2015.01.21:18.19.48 >> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 >> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >> <0f> 0b 41 bd 94 ff ff ff > >> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: ffff8af202f06400 >> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: ffff8af202e9ae00 >> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: ffff8af208785780 >> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: ffff8af208785780 >> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: ffff8af203e26cc0 >> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >> knlGS:0000000000000000 >> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: 00000000001006f0 >> kernel: Call Trace: >> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >> kernel: ? usb_ep_queue+0x2a/0x80 >> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >> kernel: dwc3_ep0_interrupt+0x469/0xa80 >> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >> kernel: ? __wake_up_common_lock+0x85/0xb0 >> kernel: ? disable_irq_nosync+0x10/0x10 >> kernel: irq_thread_fn+0x1b/0x60 >> kernel: irq_thread+0xd6/0x170 >> kernel: ? irq_thread_check_affinity+0x70/0x70 >> kernel: ? irq_forced_thread_fn+0x70/0x70 >> kernel: kthread+0x116/0x130 >> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >> kernel: ret_from_fork+0x22/0x30 >> kernel: ---[ end trace e5b9e28058c53584 ]--- >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >> >> Removing uac2 from the config makes the call trace go away, but the R/W >> speed does not change. >> >>> :), not a problem...I've been working on getting the ideal set up for >>> the performance profiling for awhile, so anything I can do to make sure >>> we get some good results. >>> >>>> I'll try with a ramdisk and let you know. >>>> >>> Thanks again for the testing, Ferry. >>> >>> Thanks >>> Wesley Cheng >>> >>>>> Thanks >>>>> Wesley Cheng >>>>> >>>>>>> Changes in V9: >>>>>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>>>>> dwc3-qcom will >>>>>>> add the property by default from the kernel. >>>>>>> >>>>>>> Changes in V8: >>>>>>> - Rebased to usb-testing >>>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo resize >>>>>>> >>>>>>> Changes in V7: >>>>>>> - Added a new property tx-fifo-max-num for limiting how much fifo >>>>>>> space the >>>>>>> resizing logic can allocate for endpoints with large burst >>>>>>> values. This >>>>>>> can differ across platforms, and tie in closely with overall >>>>>>> system latency. >>>>>>> - Added recommended checks for DWC32. >>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>> dwc3-qcom by >>>>>>> default >>>>>>> instead of modifying the current DTSI files. >>>>>>> - Added comments on all APIs/variables introduced. >>>>>>> - Updated the DWC3 YAML to include a better description of the >>>>>>> tx-fifo-resize >>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>> >>>>>>> Changes in V6: >>>>>>> - Rebased patches to usb-testing. >>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>>> determining the >>>>>>> endpoint count for a particular configuration. >>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>> >>>>>>> Changes in V5: >>>>>>> - Added check_config() logic, which is used to communicate the >>>>>>> number of EPs >>>>>>> used in a particular configuration. Based on this, the DWC3 >>>>>>> gadget driver >>>>>>> has the ability to know the maximum number of eps utilized in >>>>>>> all >>>>>>> configs. >>>>>>> This helps reduce unnecessary allocation to unused eps, and will >>>>>>> catch fifo >>>>>>> allocation issues at bind() time. >>>>>>> - Fixed variable declaration to single line per variable, and >>>>>>> reverse xmas. >>>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>>> >>>>>>> Changes in V4: >>>>>>> - Removed struct dwc3* as an argument for >>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>> Changes in V3: >>>>>>> - Removed "Reviewed-by" tags >>>>>>> - Renamed series back to RFC >>>>>>> - Modified logic to ensure that fifo_size is reset if we pass the >>>>>>> minimum >>>>>>> threshold. Tested with binding multiple FDs requesting 6 FIFOs. >>>>>>> >>>>>>> Changes in V2: >>>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>>> reserved a >>>>>>> FIFO. >>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>> - Added some more description on the dt-bindings commit message >>>>>>> >>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>> TXFIFOs, and >>>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>>> cases, the >>>>>>> HW default is probably sufficient, but for USB compositions that >>>>>>> contain >>>>>>> multiple functions that require EP bursting, the default settings >>>>>>> might not be enough. Also to note, the current SW will assign an >>>>>>> EP to a >>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>> particular >>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>> defined >>>>>>> values for the TXFIFO size) >>>>>>> >>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>> depth = 3 >>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>> may be >>>>>>> frequent occurences of bursts ending. For high bandwidth functions, >>>>>>> such as data tethering (protocols that support data aggregation), >>>>>>> mass >>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst value >>>>>>> can be >>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in terms >>>>>>> of USB >>>>>>> throughput. (which can be associated to system access latency, >>>>>>> etc...) It >>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>> interruptions, as >>>>>>> data is readily available in the FIFO. >>>>>>> >>>>>>> With testing done using the mass storage function driver, the results >>>>>>> show >>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>> significantly. >>>>>>> >>>>>>> Test Parameters: >>>>>>> - Platform: Qualcomm SM8150 >>>>>>> - bMaxBurst = 6 >>>>>>> - USB req size = 256kB >>>>>>> - Num of USB reqs = 16 >>>>>>> - USB Speed = Super-Speed >>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>> - Test Application: CrystalDiskMark >>>>>>> >>>>>>> Results: >>>>>>> >>>>>>> TXFIFO Depth = 3 max packets >>>>>>> >>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>> ------------------------------------------- >>>>>>> Sequential|1 GB x | >>>>>>> Read |9 loops | 193.60 >>>>>>> | | 195.86 >>>>>>> | | 184.77 >>>>>>> | | 193.60 >>>>>>> ------------------------------------------- >>>>>>> >>>>>>> TXFIFO Depth = 6 max packets >>>>>>> >>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>> ------------------------------------------- >>>>>>> Sequential|1 GB x | >>>>>>> Read |9 loops | 287.35 >>>>>>> | | 304.94 >>>>>>> | | 289.64 >>>>>>> | | 293.61 >>>>>>> ------------------------------------------- >>>>>>> >>>>>>> Wesley Cheng (6): >>>>>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>>>>> configuration >>>>>>> usb: gadget: configfs: Check USB configuration before adding >>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>>> of: Add stub for of_add_property() >>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default >>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>> >>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>> +++++++++++++++++++++ >>>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>>> include/linux/of.h | 5 + >>>>>>> include/linux/usb/gadget.h | 5 + >>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>
On 6/22/2021 1:09 PM, Ferry Toth wrote: > Hi > > Op 22-06-2021 om 20:38 schreef Wesley Cheng: >> >> On 6/19/2021 5:40 AM, Ferry Toth wrote: >>> Hi >>> >>> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>>> Hi, >>>> >>>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>>> Hi >>>>> >>>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>>> Hi, >>>>>> >>>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>>> Hi >>>>>>> >>>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>>> Changes in V10: >>>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>>> (error due to >>>>>>>> unknown symbol for of_add_property()). Add of_add_property() >>>>>>>> stub. >>>>>>>> - Fixed compilation warning for incorrect argument being >>>>>>>> passed to >>>>>>>> dwc3_mdwidth >>>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>>> performance >>>>>>> on Merrifield though. >>>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>>> device's >>>>>> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as >>>>>> well? >>>>> In this case I just tested the EEM path using iperf3. >>>>> >>>> Got it. I don't believe f_eem will use a high enough (if at all) >>>> bMaxBurst value to change the TXFIFO size. >>>> >>>>>> If not with a ramdisk, we might want to give that a try to avoid the >>>>>> storage path being the bottleneck. You can use "dd" to create an >>>>>> empty >>>>>> file, and then just use that as the LUN's backing file. >>>>>> >>>>>> echo ramdisk.img > >>>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>>> Ah, why didn't I think of that. I have currently mass storage setup >>>>> with >>>>> eMMC but it seems that is indeed the bottleneck. >>>>> >>> I created a 64MB disk following the instructions here >>> http://www.linux-usb.org/gadget/file_storage.html (that seems a little >>> outdated, at least I can not start the first partition at sector 8, but >>> minimum 2048), and added a test file on it. >>> >>> I then copy the file to /dev/shm prior to setting configfs (composite >>> device gser/eem/mass_storage/uac2). >>> >>> journal shows: >>> >>> kernel: Mass Storage Function, version: 2009/09/11 >>> kernel: LUN: removable file: (no medium) >>> >>> I don't know what that means, because I see the test file on the >>> ramdisk. >>> >>> Then I again used gnome disks to benchmark (read/write 10MB): >>> >>> With V10 on top v5.13.0-rc5: >>> >>> R/W speed = 35.6/35.8MB/s, access time 0.35ms >>> >>> With no patches on top v5.12.0: >>> >>> R/W speed = 35.7/36.1MB/s, access time 0.35ms >> Hi Ferry, >> >>> I see no speed difference (and it's about the same as with the eMMC >>> backed disk). But the patches are causing a new call trace >>> >> Would you happen to know what DWC3 controller revision the device is >> using? The callstack print occurs, because it looks like it ran out of >> internal memory, although there should be logic present for making sure >> that at least there is enough room for 1 FIFO per endpoint. (possibly >> the logic/math depends on the controller revision) Hi Ferry, > > Do you know where I could find that in a file on the device? > Maybe you can just dump the DWC3 registers? cat /sys/kernel/debug/usb/<controller name>/regdump Was going to ask for the same to confirm the TXFIFO sizes from your results below :). > Otherwise, I'm hoping Andy will know? > >> >> Also, is there a way to use just a mass storage only composition? Based >> on the above observation, that probably means that the mass storage >> interface wasn't resized at all, because the configuration took up a lot >> of the internal FIFO space. > > Sure, it's configured through configfs. With only mass_storage I have: > > With V10 on top v5.13.0-rc5: > > R/W speed = 41,6/39,3MB/s, access time 0.33ms > > With no patches on top v5.12.0: > > R/W speed = 41,1/38,7MB/s, access time 0.38ms > Thanks Ferry! Could you collect the regdump, so I can confirm the two things mentioned? Thanks Wesley Cheng >> Thanks >> Wesley Cheng >> >>> kernel: using random self ethernet address >>> kernel: using random host ethernet address >>> kernel: Mass Storage Function, version: 2009/09/11 >>> kernel: LUN: removable file: (no medium) >>> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >>> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >>> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>> depth:115540359 >>> kernel: ------------[ cut here ]------------ >>> kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 >>> usb_ep_queue+0x75/0x80 >>> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >>> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat >>> bnep snd_sof_nocodec spi_pxa2> >>> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >>> 5.13.0-rc5-edison-acpi-standard #1 >>> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>> 2015.01.21:18.19.48 >>> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >>> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 >>> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >>> <0f> 0b 41 bd 94 ff ff ff > >>> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >>> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: >>> ffff8af202f06400 >>> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: >>> ffff8af202e9ae00 >>> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: >>> ffff8af208785780 >>> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: >>> ffff8af208785780 >>> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: >>> ffff8af203e26cc0 >>> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >>> knlGS:0000000000000000 >>> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: >>> 00000000001006f0 >>> kernel: Call Trace: >>> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >>> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >>> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >>> kernel: ? usb_ep_queue+0x2a/0x80 >>> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >>> kernel: dwc3_ep0_interrupt+0x469/0xa80 >>> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >>> kernel: ? __wake_up_common_lock+0x85/0xb0 >>> kernel: ? disable_irq_nosync+0x10/0x10 >>> kernel: irq_thread_fn+0x1b/0x60 >>> kernel: irq_thread+0xd6/0x170 >>> kernel: ? irq_thread_check_affinity+0x70/0x70 >>> kernel: ? irq_forced_thread_fn+0x70/0x70 >>> kernel: kthread+0x116/0x130 >>> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >>> kernel: ret_from_fork+0x22/0x30 >>> kernel: ---[ end trace e5b9e28058c53584 ]--- >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>> depth:115540359 >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>> depth:115540359 >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>> depth:115540359 >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>> depth:115540359 >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>> ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>> ep5in >>> >>> Removing uac2 from the config makes the call trace go away, but the R/W >>> speed does not change. >>> >>>> :), not a problem...I've been working on getting the ideal set up for >>>> the performance profiling for awhile, so anything I can do to make sure >>>> we get some good results. >>>> >>>>> I'll try with a ramdisk and let you know. >>>>> >>>> Thanks again for the testing, Ferry. >>>> >>>> Thanks >>>> Wesley Cheng >>>> >>>>>> Thanks >>>>>> Wesley Cheng >>>>>> >>>>>>>> Changes in V9: >>>>>>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>>>>>> dwc3-qcom will >>>>>>>> add the property by default from the kernel. >>>>>>>> >>>>>>>> Changes in V8: >>>>>>>> - Rebased to usb-testing >>>>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo >>>>>>>> resize >>>>>>>> >>>>>>>> Changes in V7: >>>>>>>> - Added a new property tx-fifo-max-num for limiting how much >>>>>>>> fifo >>>>>>>> space the >>>>>>>> resizing logic can allocate for endpoints with large burst >>>>>>>> values. This >>>>>>>> can differ across platforms, and tie in closely with overall >>>>>>>> system latency. >>>>>>>> - Added recommended checks for DWC32. >>>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>>> dwc3-qcom by >>>>>>>> default >>>>>>>> instead of modifying the current DTSI files. >>>>>>>> - Added comments on all APIs/variables introduced. >>>>>>>> - Updated the DWC3 YAML to include a better description of the >>>>>>>> tx-fifo-resize >>>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>>> >>>>>>>> Changes in V6: >>>>>>>> - Rebased patches to usb-testing. >>>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>>>> determining the >>>>>>>> endpoint count for a particular configuration. >>>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>>> >>>>>>>> Changes in V5: >>>>>>>> - Added check_config() logic, which is used to communicate the >>>>>>>> number of EPs >>>>>>>> used in a particular configuration. Based on this, the DWC3 >>>>>>>> gadget driver >>>>>>>> has the ability to know the maximum number of eps utilized in >>>>>>>> all >>>>>>>> configs. >>>>>>>> This helps reduce unnecessary allocation to unused eps, >>>>>>>> and will >>>>>>>> catch fifo >>>>>>>> allocation issues at bind() time. >>>>>>>> - Fixed variable declaration to single line per variable, and >>>>>>>> reverse xmas. >>>>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>>>> >>>>>>>> Changes in V4: >>>>>>>> - Removed struct dwc3* as an argument for >>>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>>> Changes in V3: >>>>>>>> - Removed "Reviewed-by" tags >>>>>>>> - Renamed series back to RFC >>>>>>>> - Modified logic to ensure that fifo_size is reset if we >>>>>>>> pass the >>>>>>>> minimum >>>>>>>> threshold. Tested with binding multiple FDs requesting 6 >>>>>>>> FIFOs. >>>>>>>> >>>>>>>> Changes in V2: >>>>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>>>> reserved a >>>>>>>> FIFO. >>>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>>> - Added some more description on the dt-bindings commit message >>>>>>>> >>>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>>> TXFIFOs, and >>>>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>>>> cases, the >>>>>>>> HW default is probably sufficient, but for USB compositions that >>>>>>>> contain >>>>>>>> multiple functions that require EP bursting, the default settings >>>>>>>> might not be enough. Also to note, the current SW will assign an >>>>>>>> EP to a >>>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>>> particular >>>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>>> defined >>>>>>>> values for the TXFIFO size) >>>>>>>> >>>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>>> depth = 3 >>>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>>> may be >>>>>>>> frequent occurences of bursts ending. For high bandwidth >>>>>>>> functions, >>>>>>>> such as data tethering (protocols that support data aggregation), >>>>>>>> mass >>>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst >>>>>>>> value >>>>>>>> can be >>>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in >>>>>>>> terms >>>>>>>> of USB >>>>>>>> throughput. (which can be associated to system access latency, >>>>>>>> etc...) It >>>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>>> interruptions, as >>>>>>>> data is readily available in the FIFO. >>>>>>>> >>>>>>>> With testing done using the mass storage function driver, the >>>>>>>> results >>>>>>>> show >>>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>>> significantly. >>>>>>>> >>>>>>>> Test Parameters: >>>>>>>> - Platform: Qualcomm SM8150 >>>>>>>> - bMaxBurst = 6 >>>>>>>> - USB req size = 256kB >>>>>>>> - Num of USB reqs = 16 >>>>>>>> - USB Speed = Super-Speed >>>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>>> - Test Application: CrystalDiskMark >>>>>>>> >>>>>>>> Results: >>>>>>>> >>>>>>>> TXFIFO Depth = 3 max packets >>>>>>>> >>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>> ------------------------------------------- >>>>>>>> Sequential|1 GB x | >>>>>>>> Read |9 loops | 193.60 >>>>>>>> | | 195.86 >>>>>>>> | | 184.77 >>>>>>>> | | 193.60 >>>>>>>> ------------------------------------------- >>>>>>>> >>>>>>>> TXFIFO Depth = 6 max packets >>>>>>>> >>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>> ------------------------------------------- >>>>>>>> Sequential|1 GB x | >>>>>>>> Read |9 loops | 287.35 >>>>>>>> | | 304.94 >>>>>>>> | | 289.64 >>>>>>>> | | 293.61 >>>>>>>> ------------------------------------------- >>>>>>>> >>>>>>>> Wesley Cheng (6): >>>>>>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>>>>>> configuration >>>>>>>> usb: gadget: configfs: Check USB configuration before adding >>>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>>>> of: Add stub for of_add_property() >>>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by >>>>>>>> default >>>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>>> >>>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>>> +++++++++++++++++++++ >>>>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>>>> include/linux/of.h | 5 + >>>>>>>> include/linux/usb/gadget.h | 5 + >>>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>>
Hi Op 23-06-2021 om 00:00 schreef Wesley Cheng: > > On 6/22/2021 1:09 PM, Ferry Toth wrote: >> Hi >> >> Op 22-06-2021 om 20:38 schreef Wesley Cheng: >>> On 6/19/2021 5:40 AM, Ferry Toth wrote: >>>> Hi >>>> >>>> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>>>> Hi, >>>>> >>>>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>>>> Hi >>>>>> >>>>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>>>> Hi, >>>>>>> >>>>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>>>> Changes in V10: >>>>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>>>> (error due to >>>>>>>>> unknown symbol for of_add_property()). Add of_add_property() >>>>>>>>> stub. >>>>>>>>> - Fixed compilation warning for incorrect argument being >>>>>>>>> passed to >>>>>>>>> dwc3_mdwidth >>>>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>>>> performance >>>>>>>> on Merrifield though. >>>>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>>>> device's >>>>>>> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as >>>>>>> well? >>>>>> In this case I just tested the EEM path using iperf3. >>>>>> >>>>> Got it. I don't believe f_eem will use a high enough (if at all) >>>>> bMaxBurst value to change the TXFIFO size. >>>>> >>>>>>> If not with a ramdisk, we might want to give that a try to avoid the >>>>>>> storage path being the bottleneck. You can use "dd" to create an >>>>>>> empty >>>>>>> file, and then just use that as the LUN's backing file. >>>>>>> >>>>>>> echo ramdisk.img > >>>>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>>>> Ah, why didn't I think of that. I have currently mass storage setup >>>>>> with >>>>>> eMMC but it seems that is indeed the bottleneck. >>>>>> >>>> I created a 64MB disk following the instructions here >>>> http://www.linux-usb.org/gadget/file_storage.html (that seems a little >>>> outdated, at least I can not start the first partition at sector 8, but >>>> minimum 2048), and added a test file on it. >>>> >>>> I then copy the file to /dev/shm prior to setting configfs (composite >>>> device gser/eem/mass_storage/uac2). >>>> >>>> journal shows: >>>> >>>> kernel: Mass Storage Function, version: 2009/09/11 >>>> kernel: LUN: removable file: (no medium) >>>> >>>> I don't know what that means, because I see the test file on the >>>> ramdisk. >>>> >>>> Then I again used gnome disks to benchmark (read/write 10MB): >>>> >>>> With V10 on top v5.13.0-rc5: >>>> >>>> R/W speed = 35.6/35.8MB/s, access time 0.35ms >>>> >>>> With no patches on top v5.12.0: >>>> >>>> R/W speed = 35.7/36.1MB/s, access time 0.35ms >>> Hi Ferry, >>> >>>> I see no speed difference (and it's about the same as with the eMMC >>>> backed disk). But the patches are causing a new call trace >>>> >>> Would you happen to know what DWC3 controller revision the device is >>> using? The callstack print occurs, because it looks like it ran out of >>> internal memory, although there should be logic present for making sure >>> that at least there is enough room for 1 FIFO per endpoint. (possibly >>> the logic/math depends on the controller revision) > Hi Ferry, > >> Do you know where I could find that in a file on the device? >> > Maybe you can just dump the DWC3 registers? > cat /sys/kernel/debug/usb/<controller name>/regdump This isin host mode: ~# cat /sys/kernel/debug/usb/dwc3.0.auto/regdump GSBUSCFG0 = 0x00000006 GSBUSCFG1 = 0x00000f00 GTXTHRCFG = 0x230a0000 GRXTHRCFG = 0x22800000 GCTL = 0x45801002 GEVTEN = 0x00000000 GSTS = 0x3e800001 GUCTL1 = 0x00000000 GSNPSID = 0x5533250a GGPIO = 0x00000000 GUID = 0x00050d00 GUCTL = 0x0200ce00 GBUSERRADDR0 = 0x00000000 GBUSERRADDR1 = 0x00000000 GPRTBIMAP0 = 0x00000000 GPRTBIMAP1 = 0x00000000 GHWPARAMS0 = 0x2020400a GHWPARAMS1 = 0x0260c93b GHWPARAMS2 = 0x008086a0 GHWPARAMS3 = 0x10420089 GHWPARAMS4 = 0x47a22004 GHWPARAMS5 = 0x04202088 GHWPARAMS6 = 0x0c00ac20 GHWPARAMS7 = 0x038807e6 GDBGFIFOSPACE = 0x00820000 GDBGLTSSM = 0x09550442 GDBGBMU = 0x20300000 GPRTBIMAP_HS0 = 0x00000000 GPRTBIMAP_HS1 = 0x00000000 GPRTBIMAP_FS0 = 0x00000000 GPRTBIMAP_FS1 = 0x00000000 GUSB2PHYCFG(0) = 0x0000a710 GUSB2PHYCFG(1) = 0x00000000 GUSB2PHYCFG(2) = 0x00000000 GUSB2PHYCFG(3) = 0x00000000 GUSB2PHYCFG(4) = 0x00000000 GUSB2PHYCFG(5) = 0x00000000 GUSB2PHYCFG(6) = 0x00000000 GUSB2PHYCFG(7) = 0x00000000 GUSB2PHYCFG(8) = 0x00000000 GUSB2PHYCFG(9) = 0x00000000 GUSB2PHYCFG(10) = 0x00000000 GUSB2PHYCFG(11) = 0x00000000 GUSB2PHYCFG(12) = 0x00000000 GUSB2PHYCFG(13) = 0x00000000 GUSB2PHYCFG(14) = 0x00000000 GUSB2PHYCFG(15) = 0x00000000 GUSB2I2CCTL(0) = 0x00000000 GUSB2I2CCTL(1) = 0x00000000 GUSB2I2CCTL(2) = 0x00000000 GUSB2I2CCTL(3) = 0x00000000 GUSB2I2CCTL(4) = 0x00000000 GUSB2I2CCTL(5) = 0x00000000 GUSB2I2CCTL(6) = 0x00000000 GUSB2I2CCTL(7) = 0x00000000 GUSB2I2CCTL(8) = 0x00000000 GUSB2I2CCTL(9) = 0x00000000 GUSB2I2CCTL(10) = 0x00000000 GUSB2I2CCTL(11) = 0x00000000 GUSB2I2CCTL(12) = 0x00000000 GUSB2I2CCTL(13) = 0x00000000 GUSB2I2CCTL(14) = 0x00000000 GUSB2I2CCTL(15) = 0x00000000 GUSB2PHYACC(0) = 0x014a0027 GUSB2PHYACC(1) = 0x00000000 GUSB2PHYACC(2) = 0x00000000 GUSB2PHYACC(3) = 0x00000000 GUSB2PHYACC(4) = 0x00000000 GUSB2PHYACC(5) = 0x00000000 GUSB2PHYACC(6) = 0x00000000 GUSB2PHYACC(7) = 0x00000000 GUSB2PHYACC(8) = 0x00000000 GUSB2PHYACC(9) = 0x00000000 GUSB2PHYACC(10) = 0x00000000 GUSB2PHYACC(11) = 0x00000000 GUSB2PHYACC(12) = 0x00000000 GUSB2PHYACC(13) = 0x00000000 GUSB2PHYACC(14) = 0x00000000 GUSB2PHYACC(15) = 0x00000000 GUSB3PIPECTL(0) = 0x02000002 GUSB3PIPECTL(1) = 0x00000000 GUSB3PIPECTL(2) = 0x00000000 GUSB3PIPECTL(3) = 0x00000000 GUSB3PIPECTL(4) = 0x00000000 GUSB3PIPECTL(5) = 0x00000000 GUSB3PIPECTL(6) = 0x00000000 GUSB3PIPECTL(7) = 0x00000000 GUSB3PIPECTL(8) = 0x00000000 GUSB3PIPECTL(9) = 0x00000000 GUSB3PIPECTL(10) = 0x00000000 GUSB3PIPECTL(11) = 0x00000000 GUSB3PIPECTL(12) = 0x00000000 GUSB3PIPECTL(13) = 0x00000000 GUSB3PIPECTL(14) = 0x00000000 GUSB3PIPECTL(15) = 0x00000000 GTXFIFOSIZ(0) = 0x00000082 GTXFIFOSIZ(1) = 0x00820184 GTXFIFOSIZ(2) = 0x02060286 GTXFIFOSIZ(3) = 0x048c0000 GTXFIFOSIZ(4) = 0x048c0000 GTXFIFOSIZ(5) = 0x048c0000 GTXFIFOSIZ(6) = 0x048c0000 GTXFIFOSIZ(7) = 0x048c0000 GTXFIFOSIZ(8) = 0x048c0000 GTXFIFOSIZ(9) = 0x048c0000 GTXFIFOSIZ(10) = 0x048c0000 GTXFIFOSIZ(11) = 0x048c0000 GTXFIFOSIZ(12) = 0x048c0000 GTXFIFOSIZ(13) = 0x048c0000 GTXFIFOSIZ(14) = 0x048c0000 GTXFIFOSIZ(15) = 0x048c0000 GTXFIFOSIZ(16) = 0x00000000 GTXFIFOSIZ(17) = 0x00000000 GTXFIFOSIZ(18) = 0x00000000 GTXFIFOSIZ(19) = 0x00000000 GTXFIFOSIZ(20) = 0x00000000 GTXFIFOSIZ(21) = 0x00000000 GTXFIFOSIZ(22) = 0x00000000 GTXFIFOSIZ(23) = 0x00000000 GTXFIFOSIZ(24) = 0x00000000 GTXFIFOSIZ(25) = 0x00000000 GTXFIFOSIZ(26) = 0x00000000 GTXFIFOSIZ(27) = 0x00000000 GTXFIFOSIZ(28) = 0x00000000 GTXFIFOSIZ(29) = 0x00000000 GTXFIFOSIZ(30) = 0x00000000 GTXFIFOSIZ(31) = 0x00000000 GRXFIFOSIZ(0) = 0x00000084 GRXFIFOSIZ(1) = 0x00840104 GRXFIFOSIZ(2) = 0x01880200 GRXFIFOSIZ(3) = 0x00000000 GRXFIFOSIZ(4) = 0x00000000 GRXFIFOSIZ(5) = 0x00000000 GRXFIFOSIZ(6) = 0x00000000 GRXFIFOSIZ(7) = 0x00000000 GRXFIFOSIZ(8) = 0x00000000 GRXFIFOSIZ(9) = 0x00000000 GRXFIFOSIZ(10) = 0x00000000 GRXFIFOSIZ(11) = 0x00000000 GRXFIFOSIZ(12) = 0x00000000 GRXFIFOSIZ(13) = 0x00000000 GRXFIFOSIZ(14) = 0x00000000 GRXFIFOSIZ(15) = 0x00000000 GRXFIFOSIZ(16) = 0x00000000 GRXFIFOSIZ(17) = 0x00000000 GRXFIFOSIZ(18) = 0x00000000 GRXFIFOSIZ(19) = 0x00000000 GRXFIFOSIZ(20) = 0x00000000 GRXFIFOSIZ(21) = 0x00000000 GRXFIFOSIZ(22) = 0x00000000 GRXFIFOSIZ(23) = 0x00000000 GRXFIFOSIZ(24) = 0x00000000 GRXFIFOSIZ(25) = 0x00000000 GRXFIFOSIZ(26) = 0x00000000 GRXFIFOSIZ(27) = 0x00000000 GRXFIFOSIZ(28) = 0x00000000 GRXFIFOSIZ(29) = 0x00000000 GRXFIFOSIZ(30) = 0x00000000 GRXFIFOSIZ(31) = 0x00000000 GEVNTADRLO(0) = 0x00000000 GEVNTADRHI(0) = 0x00000000 GEVNTSIZ(0) = 0x00001000 GEVNTCOUNT(0) = 0x00000000 GHWPARAMS8 = 0x00000c00 DCFG = 0x00080800 DCTL = 0x00f00000 DEVTEN = 0x00000000 DSTS = 0x00539e19 DGCMDPAR = 0x00000000 DGCMD = 0x00000000 DALEPENA = 0x00000000 DEPCMDPAR2(0) = 0x00000000 DEPCMDPAR1(0) = 0x00000002 DEPCMDPAR0(0) = 0x06a39001 DEPCMD(0) = 0x00000000 DEPCMDPAR2(1) = 0x00000000 DEPCMDPAR1(1) = 0x00000000 DEPCMDPAR0(1) = 0x00000000 DEPCMD(1) = 0x00000000 DEPCMDPAR2(2) = 0x07359000 DEPCMDPAR1(2) = 0x00000000 DEPCMDPAR0(2) = 0x0000007f DEPCMD(2) = 0x00000000 DEPCMDPAR2(3) = 0x00000000 DEPCMDPAR1(3) = 0x00000000 DEPCMDPAR0(3) = 0x00000000 DEPCMD(3) = 0x00000000 DEPCMDPAR2(4) = 0x06a40000 DEPCMDPAR1(4) = 0x00000000 DEPCMDPAR0(4) = 0x06a3feb8 DEPCMD(4) = 0x00000000 DEPCMDPAR2(5) = 0x00000000 DEPCMDPAR1(5) = 0x00000000 DEPCMDPAR0(5) = 0x00000008 DEPCMD(5) = 0x00000000 DEPCMDPAR2(6) = 0x00000000 DEPCMDPAR1(6) = 0x00000000 DEPCMDPAR0(6) = 0x00000000 DEPCMD(6) = 0x00000000 DEPCMDPAR2(7) = 0x00000000 DEPCMDPAR1(7) = 0x00000000 DEPCMDPAR0(7) = 0x00000000 DEPCMD(7) = 0x00000000 DEPCMDPAR2(8) = 0x00000000 DEPCMDPAR1(8) = 0x00000000 DEPCMDPAR0(8) = 0x00000000 DEPCMD(8) = 0x00000000 DEPCMDPAR2(9) = 0x00000000 DEPCMDPAR1(9) = 0x00000000 DEPCMDPAR0(9) = 0x00000000 DEPCMD(9) = 0x00000000 DEPCMDPAR2(10) = 0x00000000 DEPCMDPAR1(10) = 0x00000000 DEPCMDPAR0(10) = 0x00000000 DEPCMD(10) = 0x00000000 DEPCMDPAR2(11) = 0x00000000 DEPCMDPAR1(11) = 0x00000000 DEPCMDPAR0(11) = 0x00000000 DEPCMD(11) = 0x00000000 DEPCMDPAR2(12) = 0x00000000 DEPCMDPAR1(12) = 0x00000000 DEPCMDPAR0(12) = 0x00000000 DEPCMD(12) = 0x00000000 DEPCMDPAR2(13) = 0x00000000 DEPCMDPAR1(13) = 0x00000000 DEPCMDPAR0(13) = 0x00000000 DEPCMD(13) = 0x00000000 DEPCMDPAR2(14) = 0x00000000 DEPCMDPAR1(14) = 0x00000000 DEPCMDPAR0(14) = 0x00000000 DEPCMD(14) = 0x00000000 DEPCMDPAR2(15) = 0x00000000 DEPCMDPAR1(15) = 0x00000000 DEPCMDPAR0(15) = 0x00000000 DEPCMD(15) = 0x00000000 DEPCMDPAR2(16) = 0x00000000 DEPCMDPAR1(16) = 0x00000000 DEPCMDPAR0(16) = 0x00000000 DEPCMD(16) = 0x00000000 DEPCMDPAR2(17) = 0x00000000 DEPCMDPAR1(17) = 0x00000000 DEPCMDPAR0(17) = 0x00000000 DEPCMD(17) = 0x00000000 DEPCMDPAR2(18) = 0x00000000 DEPCMDPAR1(18) = 0x00000000 DEPCMDPAR0(18) = 0x00000000 DEPCMD(18) = 0x00000000 DEPCMDPAR2(19) = 0x00000000 DEPCMDPAR1(19) = 0x00000000 DEPCMDPAR0(19) = 0x00000000 DEPCMD(19) = 0x00000000 DEPCMDPAR2(20) = 0x00000000 DEPCMDPAR1(20) = 0x00000000 DEPCMDPAR0(20) = 0x00000000 DEPCMD(20) = 0x00000000 DEPCMDPAR2(21) = 0x00000000 DEPCMDPAR1(21) = 0x00000000 DEPCMDPAR0(21) = 0x00000000 DEPCMD(21) = 0x00000000 DEPCMDPAR2(22) = 0x00000000 DEPCMDPAR1(22) = 0x00000000 DEPCMDPAR0(22) = 0x00000000 DEPCMD(22) = 0x00000000 DEPCMDPAR2(23) = 0x00000000 DEPCMDPAR1(23) = 0x00000000 DEPCMDPAR0(23) = 0x00000000 DEPCMD(23) = 0x00000000 DEPCMDPAR2(24) = 0x00000000 DEPCMDPAR1(24) = 0x00000000 DEPCMDPAR0(24) = 0x00000000 DEPCMD(24) = 0x00000000 DEPCMDPAR2(25) = 0x00000000 DEPCMDPAR1(25) = 0x00000000 DEPCMDPAR0(25) = 0x00000000 DEPCMD(25) = 0x00000000 DEPCMDPAR2(26) = 0x00000000 DEPCMDPAR1(26) = 0x00000000 DEPCMDPAR0(26) = 0x00000000 DEPCMD(26) = 0x00000000 DEPCMDPAR2(27) = 0x00000000 DEPCMDPAR1(27) = 0x00000000 DEPCMDPAR0(27) = 0x00000000 DEPCMD(27) = 0x00000000 DEPCMDPAR2(28) = 0x00000000 DEPCMDPAR1(28) = 0x00000000 DEPCMDPAR0(28) = 0x00000000 DEPCMD(28) = 0x00000000 DEPCMDPAR2(29) = 0x00000000 DEPCMDPAR1(29) = 0x00000000 DEPCMDPAR0(29) = 0x00000000 DEPCMD(29) = 0x00000000 DEPCMDPAR2(30) = 0x00000000 DEPCMDPAR1(30) = 0x00000000 DEPCMDPAR0(30) = 0x00000000 DEPCMD(30) = 0x00000000 DEPCMDPAR2(31) = 0x00000000 DEPCMDPAR1(31) = 0x00000000 DEPCMDPAR0(31) = 0x00000000 DEPCMD(31) = 0x00000000 OCFG = 0x00000000 OCTL = 0x00000040 OEVT = 0x00000000 OEVTEN = 0x00000000 OSTS = 0x00000008 > Was going to ask for the same to confirm the TXFIFO sizes from your > results below :). > >> Otherwise, I'm hoping Andy will know? >> >>> Also, is there a way to use just a mass storage only composition? Based >>> on the above observation, that probably means that the mass storage >>> interface wasn't resized at all, because the configuration took up a lot >>> of the internal FIFO space. >> Sure, it's configured through configfs. With only mass_storage I have: >> >> With V10 on top v5.13.0-rc5: >> >> R/W speed = 41,6/39,3MB/s, access time 0.33ms >> >> With no patches on top v5.12.0: >> >> R/W speed = 41,1/38,7MB/s, access time 0.38ms >> > Thanks Ferry! Could you collect the regdump, so I can confirm the two > things mentioned? > > Thanks > Wesley Cheng > >>> Thanks >>> Wesley Cheng >>> >>>> kernel: using random self ethernet address >>>> kernel: using random host ethernet address >>>> kernel: Mass Storage Function, version: 2009/09/11 >>>> kernel: LUN: removable file: (no medium) >>>> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >>>> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >>>> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>> depth:115540359 >>>> kernel: ------------[ cut here ]------------ >>>> kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 >>>> usb_ep_queue+0x75/0x80 >>>> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >>>> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat >>>> bnep snd_sof_nocodec spi_pxa2> >>>> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >>>> 5.13.0-rc5-edison-acpi-standard #1 >>>> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>> 2015.01.21:18.19.48 >>>> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >>>> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 >>>> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >>>> <0f> 0b 41 bd 94 ff ff ff > >>>> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >>>> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: >>>> ffff8af202f06400 >>>> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: >>>> ffff8af202e9ae00 >>>> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: >>>> ffff8af208785780 >>>> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: >>>> ffff8af208785780 >>>> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: >>>> ffff8af203e26cc0 >>>> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >>>> knlGS:0000000000000000 >>>> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: >>>> 00000000001006f0 >>>> kernel: Call Trace: >>>> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >>>> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >>>> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >>>> kernel: ? usb_ep_queue+0x2a/0x80 >>>> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >>>> kernel: dwc3_ep0_interrupt+0x469/0xa80 >>>> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >>>> kernel: ? __wake_up_common_lock+0x85/0xb0 >>>> kernel: ? disable_irq_nosync+0x10/0x10 >>>> kernel: irq_thread_fn+0x1b/0x60 >>>> kernel: irq_thread+0xd6/0x170 >>>> kernel: ? irq_thread_check_affinity+0x70/0x70 >>>> kernel: ? irq_forced_thread_fn+0x70/0x70 >>>> kernel: kthread+0x116/0x130 >>>> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >>>> kernel: ret_from_fork+0x22/0x30 >>>> kernel: ---[ end trace e5b9e28058c53584 ]--- >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>> depth:115540359 >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>> depth:115540359 >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>> depth:115540359 >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>> depth:115540359 >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>> ep5in >>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>> ep5in >>>> >>>> Removing uac2 from the config makes the call trace go away, but the R/W >>>> speed does not change. >>>> >>>>> :), not a problem...I've been working on getting the ideal set up for >>>>> the performance profiling for awhile, so anything I can do to make sure >>>>> we get some good results. >>>>> >>>>>> I'll try with a ramdisk and let you know. >>>>>> >>>>> Thanks again for the testing, Ferry. >>>>> >>>>> Thanks >>>>> Wesley Cheng >>>>> >>>>>>> Thanks >>>>>>> Wesley Cheng >>>>>>> >>>>>>>>> Changes in V9: >>>>>>>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>>>>>>> dwc3-qcom will >>>>>>>>> add the property by default from the kernel. >>>>>>>>> >>>>>>>>> Changes in V8: >>>>>>>>> - Rebased to usb-testing >>>>>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo >>>>>>>>> resize >>>>>>>>> >>>>>>>>> Changes in V7: >>>>>>>>> - Added a new property tx-fifo-max-num for limiting how much >>>>>>>>> fifo >>>>>>>>> space the >>>>>>>>> resizing logic can allocate for endpoints with large burst >>>>>>>>> values. This >>>>>>>>> can differ across platforms, and tie in closely with overall >>>>>>>>> system latency. >>>>>>>>> - Added recommended checks for DWC32. >>>>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>>>> dwc3-qcom by >>>>>>>>> default >>>>>>>>> instead of modifying the current DTSI files. >>>>>>>>> - Added comments on all APIs/variables introduced. >>>>>>>>> - Updated the DWC3 YAML to include a better description of the >>>>>>>>> tx-fifo-resize >>>>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>>>> >>>>>>>>> Changes in V6: >>>>>>>>> - Rebased patches to usb-testing. >>>>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>>>>> determining the >>>>>>>>> endpoint count for a particular configuration. >>>>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>>>> >>>>>>>>> Changes in V5: >>>>>>>>> - Added check_config() logic, which is used to communicate the >>>>>>>>> number of EPs >>>>>>>>> used in a particular configuration. Based on this, the DWC3 >>>>>>>>> gadget driver >>>>>>>>> has the ability to know the maximum number of eps utilized in >>>>>>>>> all >>>>>>>>> configs. >>>>>>>>> This helps reduce unnecessary allocation to unused eps, >>>>>>>>> and will >>>>>>>>> catch fifo >>>>>>>>> allocation issues at bind() time. >>>>>>>>> - Fixed variable declaration to single line per variable, and >>>>>>>>> reverse xmas. >>>>>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>>>>> >>>>>>>>> Changes in V4: >>>>>>>>> - Removed struct dwc3* as an argument for >>>>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>>>> Changes in V3: >>>>>>>>> - Removed "Reviewed-by" tags >>>>>>>>> - Renamed series back to RFC >>>>>>>>> - Modified logic to ensure that fifo_size is reset if we >>>>>>>>> pass the >>>>>>>>> minimum >>>>>>>>> threshold. Tested with binding multiple FDs requesting 6 >>>>>>>>> FIFOs. >>>>>>>>> >>>>>>>>> Changes in V2: >>>>>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>>>>> reserved a >>>>>>>>> FIFO. >>>>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>>>> - Added some more description on the dt-bindings commit message >>>>>>>>> >>>>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>>>> TXFIFOs, and >>>>>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>>>>> cases, the >>>>>>>>> HW default is probably sufficient, but for USB compositions that >>>>>>>>> contain >>>>>>>>> multiple functions that require EP bursting, the default settings >>>>>>>>> might not be enough. Also to note, the current SW will assign an >>>>>>>>> EP to a >>>>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>>>> particular >>>>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>>>> defined >>>>>>>>> values for the TXFIFO size) >>>>>>>>> >>>>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>>>> depth = 3 >>>>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>>>> may be >>>>>>>>> frequent occurences of bursts ending. For high bandwidth >>>>>>>>> functions, >>>>>>>>> such as data tethering (protocols that support data aggregation), >>>>>>>>> mass >>>>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst >>>>>>>>> value >>>>>>>>> can be >>>>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in >>>>>>>>> terms >>>>>>>>> of USB >>>>>>>>> throughput. (which can be associated to system access latency, >>>>>>>>> etc...) It >>>>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>>>> interruptions, as >>>>>>>>> data is readily available in the FIFO. >>>>>>>>> >>>>>>>>> With testing done using the mass storage function driver, the >>>>>>>>> results >>>>>>>>> show >>>>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>>>> significantly. >>>>>>>>> >>>>>>>>> Test Parameters: >>>>>>>>> - Platform: Qualcomm SM8150 >>>>>>>>> - bMaxBurst = 6 >>>>>>>>> - USB req size = 256kB >>>>>>>>> - Num of USB reqs = 16 >>>>>>>>> - USB Speed = Super-Speed >>>>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>>>> - Test Application: CrystalDiskMark >>>>>>>>> >>>>>>>>> Results: >>>>>>>>> >>>>>>>>> TXFIFO Depth = 3 max packets >>>>>>>>> >>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>> ------------------------------------------- >>>>>>>>> Sequential|1 GB x | >>>>>>>>> Read |9 loops | 193.60 >>>>>>>>> | | 195.86 >>>>>>>>> | | 184.77 >>>>>>>>> | | 193.60 >>>>>>>>> ------------------------------------------- >>>>>>>>> >>>>>>>>> TXFIFO Depth = 6 max packets >>>>>>>>> >>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>> ------------------------------------------- >>>>>>>>> Sequential|1 GB x | >>>>>>>>> Read |9 loops | 287.35 >>>>>>>>> | | 304.94 >>>>>>>>> | | 289.64 >>>>>>>>> | | 293.61 >>>>>>>>> ------------------------------------------- >>>>>>>>> >>>>>>>>> Wesley Cheng (6): >>>>>>>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>>>>>>> configuration >>>>>>>>> usb: gadget: configfs: Check USB configuration before adding >>>>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>>>>> of: Add stub for of_add_property() >>>>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by >>>>>>>>> default >>>>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>>>> >>>>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>>>> +++++++++++++++++++++ >>>>>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>>>>> include/linux/of.h | 5 + >>>>>>>>> include/linux/usb/gadget.h | 5 + >>>>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>>>
On 6/22/2021 3:12 PM, Ferry Toth wrote: > Hi > > Op 23-06-2021 om 00:00 schreef Wesley Cheng: >> >> On 6/22/2021 1:09 PM, Ferry Toth wrote: >>> Hi >>> >>> Op 22-06-2021 om 20:38 schreef Wesley Cheng: >>>> On 6/19/2021 5:40 AM, Ferry Toth wrote: >>>>> Hi >>>>> >>>>> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>>>>> Hi, >>>>>> >>>>>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>>>>> Hi >>>>>>> >>>>>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>>>>> Changes in V10: >>>>>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>>>>> (error due to >>>>>>>>>> unknown symbol for of_add_property()). Add >>>>>>>>>> of_add_property() >>>>>>>>>> stub. >>>>>>>>>> - Fixed compilation warning for incorrect argument being >>>>>>>>>> passed to >>>>>>>>>> dwc3_mdwidth >>>>>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>>>>> performance >>>>>>>>> on Merrifield though. >>>>>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>>>>> device's >>>>>>>> internal storage (ie UFS, eMMC, etc...), or did you use a >>>>>>>> ramdisk as >>>>>>>> well? >>>>>>> In this case I just tested the EEM path using iperf3. >>>>>>> >>>>>> Got it. I don't believe f_eem will use a high enough (if at all) >>>>>> bMaxBurst value to change the TXFIFO size. >>>>>> >>>>>>>> If not with a ramdisk, we might want to give that a try to avoid >>>>>>>> the >>>>>>>> storage path being the bottleneck. You can use "dd" to create an >>>>>>>> empty >>>>>>>> file, and then just use that as the LUN's backing file. >>>>>>>> >>>>>>>> echo ramdisk.img > >>>>>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>>>>>> >>>>>>> Ah, why didn't I think of that. I have currently mass storage setup >>>>>>> with >>>>>>> eMMC but it seems that is indeed the bottleneck. >>>>>>> >>>>> I created a 64MB disk following the instructions here >>>>> http://www.linux-usb.org/gadget/file_storage.html (that seems a little >>>>> outdated, at least I can not start the first partition at sector 8, >>>>> but >>>>> minimum 2048), and added a test file on it. >>>>> >>>>> I then copy the file to /dev/shm prior to setting configfs (composite >>>>> device gser/eem/mass_storage/uac2). >>>>> >>>>> journal shows: >>>>> >>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>> kernel: LUN: removable file: (no medium) >>>>> >>>>> I don't know what that means, because I see the test file on the >>>>> ramdisk. >>>>> >>>>> Then I again used gnome disks to benchmark (read/write 10MB): >>>>> >>>>> With V10 on top v5.13.0-rc5: >>>>> >>>>> R/W speed = 35.6/35.8MB/s, access time 0.35ms >>>>> >>>>> With no patches on top v5.12.0: >>>>> >>>>> R/W speed = 35.7/36.1MB/s, access time 0.35ms >>>> Hi Ferry, >>>> >>>>> I see no speed difference (and it's about the same as with the eMMC >>>>> backed disk). But the patches are causing a new call trace >>>>> >>>> Would you happen to know what DWC3 controller revision the device is >>>> using? The callstack print occurs, because it looks like it ran out of >>>> internal memory, although there should be logic present for making sure >>>> that at least there is enough room for 1 FIFO per endpoint. (possibly >>>> the logic/math depends on the controller revision) >> Hi Ferry, >> >>> Do you know where I could find that in a file on the device? >>> >> Maybe you can just dump the DWC3 registers? >> cat /sys/kernel/debug/usb/<controller name>/regdump > > This isin host mode: > > ~# cat /sys/kernel/debug/usb/dwc3.0.auto/regdump > GSBUSCFG0 = 0x00000006 > GSBUSCFG1 = 0x00000f00 > GTXTHRCFG = 0x230a0000 > GRXTHRCFG = 0x22800000 > GCTL = 0x45801002 > GEVTEN = 0x00000000 > GSTS = 0x3e800001 > GUCTL1 = 0x00000000 > GSNPSID = 0x5533250a > GGPIO = 0x00000000 > GUID = 0x00050d00 > GUCTL = 0x0200ce00 > GBUSERRADDR0 = 0x00000000 > GBUSERRADDR1 = 0x00000000 ... > Hi Ferry, Great! Thanks, that got me the information regarding the DWC3 revision you're using. (its version 2.50a) I checked the DWC3 databook and looks like certain versions have some different math to calculate the TXFIFO size. I have taken this into account and factored that in in the next revision. Is there a way you could collect the regdump in device mode w/ mass storage only composition after enumerating with the PC? That would help confirm how the TXFIFO resizing logic is working on your platform. Thanks Wesley Cheng >> Was going to ask for the same to confirm the TXFIFO sizes from your >> results below :). >> >>> Otherwise, I'm hoping Andy will know? >>> >>>> Also, is there a way to use just a mass storage only composition? >>>> Based >>>> on the above observation, that probably means that the mass storage >>>> interface wasn't resized at all, because the configuration took up a >>>> lot >>>> of the internal FIFO space. >>> Sure, it's configured through configfs. With only mass_storage I have: >>> >>> With V10 on top v5.13.0-rc5: >>> >>> R/W speed = 41,6/39,3MB/s, access time 0.33ms >>> >>> With no patches on top v5.12.0: >>> >>> R/W speed = 41,1/38,7MB/s, access time 0.38ms >>> >> Thanks Ferry! Could you collect the regdump, so I can confirm the two >> things mentioned? >> >> Thanks >> Wesley Cheng >> >>>> Thanks >>>> Wesley Cheng >>>> >>>>> kernel: using random self ethernet address >>>>> kernel: using random host ethernet address >>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>> kernel: LUN: removable file: (no medium) >>>>> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >>>>> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >>>>> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>> depth:115540359 >>>>> kernel: ------------[ cut here ]------------ >>>>> kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 >>>>> usb_ep_queue+0x75/0x80 >>>>> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >>>>> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm >>>>> iptable_nat >>>>> bnep snd_sof_nocodec spi_pxa2> >>>>> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >>>>> 5.13.0-rc5-edison-acpi-standard #1 >>>>> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>> BIOS 542 >>>>> 2015.01.21:18.19.48 >>>>> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >>>>> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 >>>>> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >>>>> <0f> 0b 41 bd 94 ff ff ff > >>>>> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >>>>> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: >>>>> ffff8af202f06400 >>>>> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: >>>>> ffff8af202e9ae00 >>>>> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: >>>>> ffff8af208785780 >>>>> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: >>>>> ffff8af208785780 >>>>> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: >>>>> ffff8af203e26cc0 >>>>> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >>>>> knlGS:0000000000000000 >>>>> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: >>>>> 00000000001006f0 >>>>> kernel: Call Trace: >>>>> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >>>>> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >>>>> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >>>>> kernel: ? usb_ep_queue+0x2a/0x80 >>>>> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>> kernel: dwc3_ep0_interrupt+0x469/0xa80 >>>>> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >>>>> kernel: ? __wake_up_common_lock+0x85/0xb0 >>>>> kernel: ? disable_irq_nosync+0x10/0x10 >>>>> kernel: irq_thread_fn+0x1b/0x60 >>>>> kernel: irq_thread+0xd6/0x170 >>>>> kernel: ? irq_thread_check_affinity+0x70/0x70 >>>>> kernel: ? irq_forced_thread_fn+0x70/0x70 >>>>> kernel: kthread+0x116/0x130 >>>>> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >>>>> kernel: ret_from_fork+0x22/0x30 >>>>> kernel: ---[ end trace e5b9e28058c53584 ]--- >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>> depth:115540359 >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>> depth:115540359 >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>> depth:115540359 >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>> depth:115540359 >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>> ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>> ep5in >>>>> >>>>> Removing uac2 from the config makes the call trace go away, but the >>>>> R/W >>>>> speed does not change. >>>>> >>>>>> :), not a problem...I've been working on getting the ideal set up for >>>>>> the performance profiling for awhile, so anything I can do to make >>>>>> sure >>>>>> we get some good results. >>>>>> >>>>>>> I'll try with a ramdisk and let you know. >>>>>>> >>>>>> Thanks again for the testing, Ferry. >>>>>> >>>>>> Thanks >>>>>> Wesley Cheng >>>>>> >>>>>>>> Thanks >>>>>>>> Wesley Cheng >>>>>>>> >>>>>>>>>> Changes in V9: >>>>>>>>>> - Fixed incorrect patch in series. Removed changes in >>>>>>>>>> DTSI, as >>>>>>>>>> dwc3-qcom will >>>>>>>>>> add the property by default from the kernel. >>>>>>>>>> >>>>>>>>>> Changes in V8: >>>>>>>>>> - Rebased to usb-testing >>>>>>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo >>>>>>>>>> resize >>>>>>>>>> >>>>>>>>>> Changes in V7: >>>>>>>>>> - Added a new property tx-fifo-max-num for limiting how much >>>>>>>>>> fifo >>>>>>>>>> space the >>>>>>>>>> resizing logic can allocate for endpoints with large burst >>>>>>>>>> values. This >>>>>>>>>> can differ across platforms, and tie in closely with >>>>>>>>>> overall >>>>>>>>>> system latency. >>>>>>>>>> - Added recommended checks for DWC32. >>>>>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>>>>> dwc3-qcom by >>>>>>>>>> default >>>>>>>>>> instead of modifying the current DTSI files. >>>>>>>>>> - Added comments on all APIs/variables introduced. >>>>>>>>>> - Updated the DWC3 YAML to include a better description >>>>>>>>>> of the >>>>>>>>>> tx-fifo-resize >>>>>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>>>>> >>>>>>>>>> Changes in V6: >>>>>>>>>> - Rebased patches to usb-testing. >>>>>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>>>>>> determining the >>>>>>>>>> endpoint count for a particular configuration. >>>>>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>>>>> >>>>>>>>>> Changes in V5: >>>>>>>>>> - Added check_config() logic, which is used to >>>>>>>>>> communicate the >>>>>>>>>> number of EPs >>>>>>>>>> used in a particular configuration. Based on this, the >>>>>>>>>> DWC3 >>>>>>>>>> gadget driver >>>>>>>>>> has the ability to know the maximum number of eps >>>>>>>>>> utilized in >>>>>>>>>> all >>>>>>>>>> configs. >>>>>>>>>> This helps reduce unnecessary allocation to unused eps, >>>>>>>>>> and will >>>>>>>>>> catch fifo >>>>>>>>>> allocation issues at bind() time. >>>>>>>>>> - Fixed variable declaration to single line per variable, >>>>>>>>>> and >>>>>>>>>> reverse xmas. >>>>>>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>>>>>> >>>>>>>>>> Changes in V4: >>>>>>>>>> - Removed struct dwc3* as an argument for >>>>>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>>>>> Changes in V3: >>>>>>>>>> - Removed "Reviewed-by" tags >>>>>>>>>> - Renamed series back to RFC >>>>>>>>>> - Modified logic to ensure that fifo_size is reset if we >>>>>>>>>> pass the >>>>>>>>>> minimum >>>>>>>>>> threshold. Tested with binding multiple FDs requesting 6 >>>>>>>>>> FIFOs. >>>>>>>>>> >>>>>>>>>> Changes in V2: >>>>>>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>>>>>> reserved a >>>>>>>>>> FIFO. >>>>>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>>>>> - Added some more description on the dt-bindings commit >>>>>>>>>> message >>>>>>>>>> >>>>>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>>>>> TXFIFOs, and >>>>>>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>>>>>> cases, the >>>>>>>>>> HW default is probably sufficient, but for USB compositions that >>>>>>>>>> contain >>>>>>>>>> multiple functions that require EP bursting, the default settings >>>>>>>>>> might not be enough. Also to note, the current SW will assign an >>>>>>>>>> EP to a >>>>>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>>>>> particular >>>>>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>>>>> defined >>>>>>>>>> values for the TXFIFO size) >>>>>>>>>> >>>>>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>>>>> depth = 3 >>>>>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>>>>> may be >>>>>>>>>> frequent occurences of bursts ending. For high bandwidth >>>>>>>>>> functions, >>>>>>>>>> such as data tethering (protocols that support data aggregation), >>>>>>>>>> mass >>>>>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst >>>>>>>>>> value >>>>>>>>>> can be >>>>>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in >>>>>>>>>> terms >>>>>>>>>> of USB >>>>>>>>>> throughput. (which can be associated to system access latency, >>>>>>>>>> etc...) It >>>>>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>>>>> interruptions, as >>>>>>>>>> data is readily available in the FIFO. >>>>>>>>>> >>>>>>>>>> With testing done using the mass storage function driver, the >>>>>>>>>> results >>>>>>>>>> show >>>>>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>>>>> significantly. >>>>>>>>>> >>>>>>>>>> Test Parameters: >>>>>>>>>> - Platform: Qualcomm SM8150 >>>>>>>>>> - bMaxBurst = 6 >>>>>>>>>> - USB req size = 256kB >>>>>>>>>> - Num of USB reqs = 16 >>>>>>>>>> - USB Speed = Super-Speed >>>>>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>>>>> - Test Application: CrystalDiskMark >>>>>>>>>> >>>>>>>>>> Results: >>>>>>>>>> >>>>>>>>>> TXFIFO Depth = 3 max packets >>>>>>>>>> >>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>> ------------------------------------------- >>>>>>>>>> Sequential|1 GB x | >>>>>>>>>> Read |9 loops | 193.60 >>>>>>>>>> | | 195.86 >>>>>>>>>> | | 184.77 >>>>>>>>>> | | 193.60 >>>>>>>>>> ------------------------------------------- >>>>>>>>>> >>>>>>>>>> TXFIFO Depth = 6 max packets >>>>>>>>>> >>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>> ------------------------------------------- >>>>>>>>>> Sequential|1 GB x | >>>>>>>>>> Read |9 loops | 287.35 >>>>>>>>>> | | 304.94 >>>>>>>>>> | | 289.64 >>>>>>>>>> | | 293.61 >>>>>>>>>> ------------------------------------------- >>>>>>>>>> >>>>>>>>>> Wesley Cheng (6): >>>>>>>>>> usb: gadget: udc: core: Introduce check_config to verify >>>>>>>>>> USB >>>>>>>>>> configuration >>>>>>>>>> usb: gadget: configfs: Check USB configuration before >>>>>>>>>> adding >>>>>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>>>>>> of: Add stub for of_add_property() >>>>>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by >>>>>>>>>> default >>>>>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>>>>> >>>>>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>>>>> +++++++++++++++++++++ >>>>>>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>>>>>> include/linux/of.h | 5 + >>>>>>>>>> include/linux/usb/gadget.h | 5 + >>>>>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>>>>
Hi Op 23-06-2021 om 09:50 schreef Wesley Cheng: > > On 6/22/2021 3:12 PM, Ferry Toth wrote: >> Hi >> >> Op 23-06-2021 om 00:00 schreef Wesley Cheng: >>> On 6/22/2021 1:09 PM, Ferry Toth wrote: >>>> Hi >>>> >>>> Op 22-06-2021 om 20:38 schreef Wesley Cheng: >>>>> On 6/19/2021 5:40 AM, Ferry Toth wrote: >>>>>> Hi >>>>>> >>>>>> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>>>>>> Hi, >>>>>>> >>>>>>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>>>>>> Changes in V10: >>>>>>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>>>>>> (error due to >>>>>>>>>>> unknown symbol for of_add_property()). Add >>>>>>>>>>> of_add_property() >>>>>>>>>>> stub. >>>>>>>>>>> - Fixed compilation warning for incorrect argument being >>>>>>>>>>> passed to >>>>>>>>>>> dwc3_mdwidth >>>>>>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>>>>>> performance >>>>>>>>>> on Merrifield though. >>>>>>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>>>>>> device's >>>>>>>>> internal storage (ie UFS, eMMC, etc...), or did you use a >>>>>>>>> ramdisk as >>>>>>>>> well? >>>>>>>> In this case I just tested the EEM path using iperf3. >>>>>>>> >>>>>>> Got it. I don't believe f_eem will use a high enough (if at all) >>>>>>> bMaxBurst value to change the TXFIFO size. >>>>>>> >>>>>>>>> If not with a ramdisk, we might want to give that a try to avoid >>>>>>>>> the >>>>>>>>> storage path being the bottleneck. You can use "dd" to create an >>>>>>>>> empty >>>>>>>>> file, and then just use that as the LUN's backing file. >>>>>>>>> >>>>>>>>> echo ramdisk.img > >>>>>>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>>>>>>> >>>>>>>> Ah, why didn't I think of that. I have currently mass storage setup >>>>>>>> with >>>>>>>> eMMC but it seems that is indeed the bottleneck. >>>>>>>> >>>>>> I created a 64MB disk following the instructions here >>>>>> http://www.linux-usb.org/gadget/file_storage.html (that seems a little >>>>>> outdated, at least I can not start the first partition at sector 8, >>>>>> but >>>>>> minimum 2048), and added a test file on it. >>>>>> >>>>>> I then copy the file to /dev/shm prior to setting configfs (composite >>>>>> device gser/eem/mass_storage/uac2). >>>>>> >>>>>> journal shows: >>>>>> >>>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>>> kernel: LUN: removable file: (no medium) >>>>>> >>>>>> I don't know what that means, because I see the test file on the >>>>>> ramdisk. >>>>>> >>>>>> Then I again used gnome disks to benchmark (read/write 10MB): >>>>>> >>>>>> With V10 on top v5.13.0-rc5: >>>>>> >>>>>> R/W speed = 35.6/35.8MB/s, access time 0.35ms >>>>>> >>>>>> With no patches on top v5.12.0: >>>>>> >>>>>> R/W speed = 35.7/36.1MB/s, access time 0.35ms >>>>> Hi Ferry, >>>>> >>>>>> I see no speed difference (and it's about the same as with the eMMC >>>>>> backed disk). But the patches are causing a new call trace >>>>>> >>>>> Would you happen to know what DWC3 controller revision the device is >>>>> using? The callstack print occurs, because it looks like it ran out of >>>>> internal memory, although there should be logic present for making sure >>>>> that at least there is enough room for 1 FIFO per endpoint. (possibly >>>>> the logic/math depends on the controller revision) >>> Hi Ferry, >>> >>>> Do you know where I could find that in a file on the device? >>>> >>> Maybe you can just dump the DWC3 registers? >>> cat /sys/kernel/debug/usb/<controller name>/regdump >> This isin host mode: >> >> ~# cat /sys/kernel/debug/usb/dwc3.0.auto/regdump >> GSBUSCFG0 = 0x00000006 >> GSBUSCFG1 = 0x00000f00 >> GTXTHRCFG = 0x230a0000 >> GRXTHRCFG = 0x22800000 >> GCTL = 0x45801002 >> GEVTEN = 0x00000000 >> GSTS = 0x3e800001 >> GUCTL1 = 0x00000000 >> GSNPSID = 0x5533250a >> GGPIO = 0x00000000 >> GUID = 0x00050d00 >> GUCTL = 0x0200ce00 >> GBUSERRADDR0 = 0x00000000 >> GBUSERRADDR1 = 0x00000000 > ... > Hi Ferry, > > Great! Thanks, that got me the information regarding the DWC3 revision > you're using. (its version 2.50a) I checked the DWC3 databook and looks > like certain versions have some different math to calculate the TXFIFO > size. I have taken this into account and factored that in in the next > revision. > > Is there a way you could collect the regdump in device mode w/ mass > storage only composition after enumerating with the PC? That would help > confirm how the TXFIFO resizing logic is working on your platform. Sorry for the wait. Yes I have serial console. So here is in device mode, mass_storage only, enumerated but not mounted: GSBUSCFG0 = 0x00000006 GSBUSCFG1 = 0x00000f00 GTXTHRCFG = 0x230a0000 GRXTHRCFG = 0x02800000 GCTL = 0x45802002 GEVTEN = 0x00000000 GSTS = 0x3e800000 GUCTL1 = 0x00000000 GSNPSID = 0x5533250a GGPIO = 0x00000000 GUID = 0x00050d00 GUCTL = 0x0200ce00 GBUSERRADDR0 = 0x00000000 GBUSERRADDR1 = 0x00000000 GPRTBIMAP0 = 0x00000000 GPRTBIMAP1 = 0x00000000 GHWPARAMS0 = 0x2020400a GHWPARAMS1 = 0x0260c93b GHWPARAMS2 = 0x008086a0 GHWPARAMS3 = 0x10420089 GHWPARAMS4 = 0x47a22004 GHWPARAMS5 = 0x04202088 GHWPARAMS6 = 0x0c00ac20 GHWPARAMS7 = 0x038807e6 GDBGFIFOSPACE = 0x00420000 GDBGLTSSM = 0x01090440 GDBGBMU = 0x20300000 GPRTBIMAP_HS0 = 0x00000000 GPRTBIMAP_HS1 = 0x00000000 GPRTBIMAP_FS0 = 0x00000000 GPRTBIMAP_FS1 = 0x00000000 GUSB2PHYCFG(0) = 0x0000a710 GUSB2PHYCFG(1) = 0x00000000 GUSB2PHYCFG(2) = 0x00000000 GUSB2PHYCFG(3) = 0x00000000 GUSB2PHYCFG(4) = 0x00000000 GUSB2PHYCFG(5) = 0x00000000 GUSB2PHYCFG(6) = 0x00000000 GUSB2PHYCFG(7) = 0x00000000 GUSB2PHYCFG(8) = 0x00000000 GUSB2PHYCFG(9) = 0x00000000 GUSB2PHYCFG(10) = 0x00000000 GUSB2PHYCFG(11) = 0x00000000 GUSB2PHYCFG(12) = 0x00000000 GUSB2PHYCFG(13) = 0x00000000 GUSB2PHYCFG(14) = 0x00000000 GUSB2PHYCFG(15) = 0x00000000 GUSB2I2CCTL(0) = 0x00000000 GUSB2I2CCTL(1) = 0x00000000 GUSB2I2CCTL(2) = 0x00000000 GUSB2I2CCTL(3) = 0x00000000 GUSB2I2CCTL(4) = 0x00000000 GUSB2I2CCTL(5) = 0x00000000 GUSB2I2CCTL(6) = 0x00000000 GUSB2I2CCTL(7) = 0x00000000 GUSB2I2CCTL(8) = 0x00000000 GUSB2I2CCTL(9) = 0x00000000 GUSB2I2CCTL(10) = 0x00000000 GUSB2I2CCTL(11) = 0x00000000 GUSB2I2CCTL(12) = 0x00000000 GUSB2I2CCTL(13) = 0x00000000 GUSB2I2CCTL(14) = 0x00000000 GUSB2I2CCTL(15) = 0x00000000 GUSB2PHYACC(0) = 0x014a0000 GUSB2PHYACC(1) = 0x00000000 GUSB2PHYACC(2) = 0x00000000 GUSB2PHYACC(3) = 0x00000000 GUSB2PHYACC(4) = 0x00000000 GUSB2PHYACC(5) = 0x00000000 GUSB2PHYACC(6) = 0x00000000 GUSB2PHYACC(7) = 0x00000000 GUSB2PHYACC(8) = 0x00000000 GUSB2PHYACC(9) = 0x00000000 GUSB2PHYACC(10) = 0x00000000 GUSB2PHYACC(11) = 0x00000000 GUSB2PHYACC(12) = 0x00000000 GUSB2PHYACC(13) = 0x00000000 GUSB2PHYACC(14) = 0x00000000 GUSB2PHYACC(15) = 0x00000000 GUSB3PIPECTL(0) = 0x02000002 GUSB3PIPECTL(1) = 0x00000000 GUSB3PIPECTL(2) = 0x00000000 GUSB3PIPECTL(3) = 0x00000000 GUSB3PIPECTL(4) = 0x00000000 GUSB3PIPECTL(5) = 0x00000000 GUSB3PIPECTL(6) = 0x00000000 GUSB3PIPECTL(7) = 0x00000000 GUSB3PIPECTL(8) = 0x00000000 GUSB3PIPECTL(9) = 0x00000000 GUSB3PIPECTL(10) = 0x00000000 GUSB3PIPECTL(11) = 0x00000000 GUSB3PIPECTL(12) = 0x00000000 GUSB3PIPECTL(13) = 0x00000000 GUSB3PIPECTL(14) = 0x00000000 GUSB3PIPECTL(15) = 0x00000000 GTXFIFOSIZ(0) = 0x00000042 GTXFIFOSIZ(1) = 0x00000000 GTXFIFOSIZ(2) = 0x00420083 GTXFIFOSIZ(3) = 0x00000000 GTXFIFOSIZ(4) = 0x00000000 GTXFIFOSIZ(5) = 0x00000000 GTXFIFOSIZ(6) = 0x00000000 GTXFIFOSIZ(7) = 0x00000000 GTXFIFOSIZ(8) = 0x00000000 GTXFIFOSIZ(9) = 0x00000000 GTXFIFOSIZ(10) = 0x00000000 GTXFIFOSIZ(11) = 0x00000000 GTXFIFOSIZ(12) = 0x00000000 GTXFIFOSIZ(13) = 0x00000000 GTXFIFOSIZ(14) = 0x00000000 GTXFIFOSIZ(15) = 0x00000000 GTXFIFOSIZ(16) = 0x00000000 GTXFIFOSIZ(17) = 0x00000000 GTXFIFOSIZ(18) = 0x00000000 GTXFIFOSIZ(19) = 0x00000000 GTXFIFOSIZ(20) = 0x00000000 GTXFIFOSIZ(21) = 0x00000000 GTXFIFOSIZ(22) = 0x00000000 GTXFIFOSIZ(23) = 0x00000000 GTXFIFOSIZ(24) = 0x00000000 GTXFIFOSIZ(25) = 0x00000000 GTXFIFOSIZ(26) = 0x00000000 GTXFIFOSIZ(27) = 0x00000000 GTXFIFOSIZ(28) = 0x00000000 GTXFIFOSIZ(29) = 0x00000000 GTXFIFOSIZ(30) = 0x00000000 GTXFIFOSIZ(31) = 0x00000000 GRXFIFOSIZ(0) = 0x00000385 GRXFIFOSIZ(1) = 0x03850000 GRXFIFOSIZ(2) = 0x03850000 GRXFIFOSIZ(3) = 0x00000000 GRXFIFOSIZ(4) = 0x00000000 GRXFIFOSIZ(5) = 0x00000000 GRXFIFOSIZ(6) = 0x00000000 GRXFIFOSIZ(7) = 0x00000000 GRXFIFOSIZ(8) = 0x00000000 GRXFIFOSIZ(9) = 0x00000000 GRXFIFOSIZ(10) = 0x00000000 GRXFIFOSIZ(11) = 0x00000000 GRXFIFOSIZ(12) = 0x00000000 GRXFIFOSIZ(13) = 0x00000000 GRXFIFOSIZ(14) = 0x00000000 GRXFIFOSIZ(15) = 0x00000000 GRXFIFOSIZ(16) = 0x00000000 GRXFIFOSIZ(17) = 0x00000000 GRXFIFOSIZ(18) = 0x00000000 GRXFIFOSIZ(19) = 0x00000000 GRXFIFOSIZ(20) = 0x00000000 GRXFIFOSIZ(21) = 0x00000000 GRXFIFOSIZ(22) = 0x00000000 GRXFIFOSIZ(23) = 0x00000000 GRXFIFOSIZ(24) = 0x00000000 GRXFIFOSIZ(25) = 0x00000000 GRXFIFOSIZ(26) = 0x00000000 GRXFIFOSIZ(27) = 0x00000000 GRXFIFOSIZ(28) = 0x00000000 GRXFIFOSIZ(29) = 0x00000000 GRXFIFOSIZ(30) = 0x00000000 GRXFIFOSIZ(31) = 0x00000000 GEVNTADRLO(0) = 0x08b15000 GEVNTADRHI(0) = 0x00000000 GEVNTSIZ(0) = 0x00001000 GEVNTCOUNT(0) = 0x00000000 GHWPARAMS8 = 0x00000c00 DCFG = 0x008e082c DCTL = 0x80f00a00 DEVTEN = 0x00000257 DSTS = 0x00833f98 DGCMDPAR = 0x00000000 DGCMD = 0x00000000 DALEPENA = 0x00000027 DEPCMDPAR2(0) = 0x00000000 DEPCMDPAR1(0) = 0x06a41000 DEPCMDPAR0(0) = 0x00000000 DEPCMD(0) = 0x00000006 DEPCMDPAR2(1) = 0x00000000 DEPCMDPAR1(1) = 0x06a41000 DEPCMDPAR0(1) = 0x00000000 DEPCMD(1) = 0x00010006 DEPCMDPAR2(2) = 0x00000000 DEPCMDPAR1(2) = 0x00000000 DEPCMDPAR0(2) = 0x00000000 DEPCMD(2) = 0x00020007 DEPCMDPAR2(3) = 0x00000000 DEPCMDPAR1(3) = 0x00000000 DEPCMDPAR0(3) = 0x00000000 DEPCMD(3) = 0x00000000 DEPCMDPAR2(4) = 0x00000000 DEPCMDPAR1(4) = 0x00000000 DEPCMDPAR0(4) = 0x00000001 DEPCMD(4) = 0x00040002 DEPCMDPAR2(5) = 0x00000000 DEPCMDPAR1(5) = 0x00000000 DEPCMDPAR0(5) = 0x00000000 DEPCMD(5) = 0x00040007 DEPCMDPAR2(6) = 0x00000000 DEPCMDPAR1(6) = 0x00000000 DEPCMDPAR0(6) = 0x00000001 DEPCMD(6) = 0x00060002 DEPCMDPAR2(7) = 0x00000000 DEPCMDPAR1(7) = 0x00000000 DEPCMDPAR0(7) = 0x00000001 DEPCMD(7) = 0x00070002 DEPCMDPAR2(8) = 0x00000000 DEPCMDPAR1(8) = 0x00000000 DEPCMDPAR0(8) = 0x00000001 DEPCMD(8) = 0x00080002 DEPCMDPAR2(9) = 0x00000000 DEPCMDPAR1(9) = 0x00000000 DEPCMDPAR0(9) = 0x00000001 DEPCMD(9) = 0x00090002 DEPCMDPAR2(10) = 0x00000000 DEPCMDPAR1(10) = 0x00000000 DEPCMDPAR0(10) = 0x00000001 DEPCMD(10) = 0x000a0002 DEPCMDPAR2(11) = 0x00000000 DEPCMDPAR1(11) = 0x00000000 DEPCMDPAR0(11) = 0x00000001 DEPCMD(11) = 0x000b0002 DEPCMDPAR2(12) = 0x00000000 DEPCMDPAR1(12) = 0x00000000 DEPCMDPAR0(12) = 0x00000001 DEPCMD(12) = 0x000c0002 DEPCMDPAR2(13) = 0x00000000 DEPCMDPAR1(13) = 0x00000000 DEPCMDPAR0(13) = 0x00000001 DEPCMD(13) = 0x000d0002 DEPCMDPAR2(14) = 0x00000000 DEPCMDPAR1(14) = 0x00000000 DEPCMDPAR0(14) = 0x00000001 DEPCMD(14) = 0x000e0002 DEPCMDPAR2(15) = 0x00000000 DEPCMDPAR1(15) = 0x00000000 DEPCMDPAR0(15) = 0x00000001 DEPCMD(15) = 0x000f0002 DEPCMDPAR2(16) = 0x00000000 DEPCMDPAR1(16) = 0x00000000 DEPCMDPAR0(16) = 0x00000000 DEPCMD(16) = 0x00000000 DEPCMDPAR2(17) = 0x00000000 DEPCMDPAR1(17) = 0x00000000 DEPCMDPAR0(17) = 0x00000000 DEPCMD(17) = 0x00000000 DEPCMDPAR2(18) = 0x00000000 DEPCMDPAR1(18) = 0x00000000 DEPCMDPAR0(18) = 0x00000001 DEPCMD(18) = 0x00100002 DEPCMDPAR2(19) = 0x00000000 DEPCMDPAR1(19) = 0x00000000 DEPCMDPAR0(19) = 0x00000001 DEPCMD(19) = 0x00110002 DEPCMDPAR2(20) = 0x00000000 DEPCMDPAR1(20) = 0x00000000 DEPCMDPAR0(20) = 0x00000001 DEPCMD(20) = 0x00120002 DEPCMDPAR2(21) = 0x00000000 DEPCMDPAR1(21) = 0x00000000 DEPCMDPAR0(21) = 0x00000001 DEPCMD(21) = 0x00130002 DEPCMDPAR2(22) = 0x00000000 DEPCMDPAR1(22) = 0x00000000 DEPCMDPAR0(22) = 0x00000001 DEPCMD(22) = 0x00140002 DEPCMDPAR2(23) = 0x00000000 DEPCMDPAR1(23) = 0x00000000 DEPCMDPAR0(23) = 0x00000001 DEPCMD(23) = 0x00150002 DEPCMDPAR2(24) = 0x00000000 DEPCMDPAR1(24) = 0x00000000 DEPCMDPAR0(24) = 0x00000001 DEPCMD(24) = 0x00160002 DEPCMDPAR2(25) = 0x00000000 DEPCMDPAR1(25) = 0x00000000 DEPCMDPAR0(25) = 0x00000001 DEPCMD(25) = 0x00170002 DEPCMDPAR2(26) = 0x00000000 DEPCMDPAR1(26) = 0x00000000 DEPCMDPAR0(26) = 0x00000001 DEPCMD(26) = 0x00180002 DEPCMDPAR2(27) = 0x00000000 DEPCMDPAR1(27) = 0x00000000 DEPCMDPAR0(27) = 0x00000001 DEPCMD(27) = 0x00190002 DEPCMDPAR2(28) = 0x00000000 DEPCMDPAR1(28) = 0x00000000 DEPCMDPAR0(28) = 0x00000001 DEPCMD(28) = 0x001a0002 DEPCMDPAR2(29) = 0x00000000 DEPCMDPAR1(29) = 0x00000000 DEPCMDPAR0(29) = 0x00000001 DEPCMD(29) = 0x001b0002 DEPCMDPAR2(30) = 0x00000000 DEPCMDPAR1(30) = 0x00000000 DEPCMDPAR0(30) = 0x00000001 DEPCMD(30) = 0x001c0002 DEPCMDPAR2(31) = 0x00000000 DEPCMDPAR1(31) = 0x00000000 DEPCMDPAR0(31) = 0x00000001 DEPCMD(31) = 0x001d0002 OCFG = 0x00000000 OCTL = 0x00000040 OEVT = 0x80000000 OEVTEN = 0x00000000 OSTS = 0x0000201f > Thanks > Wesley Cheng > >>> Was going to ask for the same to confirm the TXFIFO sizes from your >>> results below :). >>> >>>> Otherwise, I'm hoping Andy will know? >>>> >>>>> Also, is there a way to use just a mass storage only composition? >>>>> Based >>>>> on the above observation, that probably means that the mass storage >>>>> interface wasn't resized at all, because the configuration took up a >>>>> lot >>>>> of the internal FIFO space. >>>> Sure, it's configured through configfs. With only mass_storage I have: >>>> >>>> With V10 on top v5.13.0-rc5: >>>> >>>> R/W speed = 41,6/39,3MB/s, access time 0.33ms >>>> >>>> With no patches on top v5.12.0: >>>> >>>> R/W speed = 41,1/38,7MB/s, access time 0.38ms >>>> >>> Thanks Ferry! Could you collect the regdump, so I can confirm the two >>> things mentioned? >>> >>> Thanks >>> Wesley Cheng >>> >>>>> Thanks >>>>> Wesley Cheng >>>>> >>>>>> kernel: using random self ethernet address >>>>>> kernel: using random host ethernet address >>>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>>> kernel: LUN: removable file: (no medium) >>>>>> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >>>>>> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >>>>>> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>> depth:115540359 >>>>>> kernel: ------------[ cut here ]------------ >>>>>> kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 >>>>>> usb_ep_queue+0x75/0x80 >>>>>> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >>>>>> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm >>>>>> iptable_nat >>>>>> bnep snd_sof_nocodec spi_pxa2> >>>>>> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >>>>>> 5.13.0-rc5-edison-acpi-standard #1 >>>>>> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>> BIOS 542 >>>>>> 2015.01.21:18.19.48 >>>>>> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >>>>>> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 >>>>>> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >>>>>> <0f> 0b 41 bd 94 ff ff ff > >>>>>> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >>>>>> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: >>>>>> ffff8af202f06400 >>>>>> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: >>>>>> ffff8af202e9ae00 >>>>>> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: >>>>>> ffff8af208785780 >>>>>> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: >>>>>> ffff8af208785780 >>>>>> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: >>>>>> ffff8af203e26cc0 >>>>>> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >>>>>> knlGS:0000000000000000 >>>>>> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: >>>>>> 00000000001006f0 >>>>>> kernel: Call Trace: >>>>>> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >>>>>> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >>>>>> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >>>>>> kernel: ? usb_ep_queue+0x2a/0x80 >>>>>> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>> kernel: dwc3_ep0_interrupt+0x469/0xa80 >>>>>> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >>>>>> kernel: ? __wake_up_common_lock+0x85/0xb0 >>>>>> kernel: ? disable_irq_nosync+0x10/0x10 >>>>>> kernel: irq_thread_fn+0x1b/0x60 >>>>>> kernel: irq_thread+0xd6/0x170 >>>>>> kernel: ? irq_thread_check_affinity+0x70/0x70 >>>>>> kernel: ? irq_forced_thread_fn+0x70/0x70 >>>>>> kernel: kthread+0x116/0x130 >>>>>> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >>>>>> kernel: ret_from_fork+0x22/0x30 >>>>>> kernel: ---[ end trace e5b9e28058c53584 ]--- >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>> depth:115540359 >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>> depth:115540359 >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>> depth:115540359 >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>> depth:115540359 >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>>> ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>> ep5in >>>>>> >>>>>> Removing uac2 from the config makes the call trace go away, but the >>>>>> R/W >>>>>> speed does not change. >>>>>> >>>>>>> :), not a problem...I've been working on getting the ideal set up for >>>>>>> the performance profiling for awhile, so anything I can do to make >>>>>>> sure >>>>>>> we get some good results. >>>>>>> >>>>>>>> I'll try with a ramdisk and let you know. >>>>>>>> >>>>>>> Thanks again for the testing, Ferry. >>>>>>> >>>>>>> Thanks >>>>>>> Wesley Cheng >>>>>>> >>>>>>>>> Thanks >>>>>>>>> Wesley Cheng >>>>>>>>> >>>>>>>>>>> Changes in V9: >>>>>>>>>>> - Fixed incorrect patch in series. Removed changes in >>>>>>>>>>> DTSI, as >>>>>>>>>>> dwc3-qcom will >>>>>>>>>>> add the property by default from the kernel. >>>>>>>>>>> >>>>>>>>>>> Changes in V8: >>>>>>>>>>> - Rebased to usb-testing >>>>>>>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo >>>>>>>>>>> resize >>>>>>>>>>> >>>>>>>>>>> Changes in V7: >>>>>>>>>>> - Added a new property tx-fifo-max-num for limiting how much >>>>>>>>>>> fifo >>>>>>>>>>> space the >>>>>>>>>>> resizing logic can allocate for endpoints with large burst >>>>>>>>>>> values. This >>>>>>>>>>> can differ across platforms, and tie in closely with >>>>>>>>>>> overall >>>>>>>>>>> system latency. >>>>>>>>>>> - Added recommended checks for DWC32. >>>>>>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>>>>>> dwc3-qcom by >>>>>>>>>>> default >>>>>>>>>>> instead of modifying the current DTSI files. >>>>>>>>>>> - Added comments on all APIs/variables introduced. >>>>>>>>>>> - Updated the DWC3 YAML to include a better description >>>>>>>>>>> of the >>>>>>>>>>> tx-fifo-resize >>>>>>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>>>>>> >>>>>>>>>>> Changes in V6: >>>>>>>>>>> - Rebased patches to usb-testing. >>>>>>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>>>>>>> determining the >>>>>>>>>>> endpoint count for a particular configuration. >>>>>>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>>>>>> >>>>>>>>>>> Changes in V5: >>>>>>>>>>> - Added check_config() logic, which is used to >>>>>>>>>>> communicate the >>>>>>>>>>> number of EPs >>>>>>>>>>> used in a particular configuration. Based on this, the >>>>>>>>>>> DWC3 >>>>>>>>>>> gadget driver >>>>>>>>>>> has the ability to know the maximum number of eps >>>>>>>>>>> utilized in >>>>>>>>>>> all >>>>>>>>>>> configs. >>>>>>>>>>> This helps reduce unnecessary allocation to unused eps, >>>>>>>>>>> and will >>>>>>>>>>> catch fifo >>>>>>>>>>> allocation issues at bind() time. >>>>>>>>>>> - Fixed variable declaration to single line per variable, >>>>>>>>>>> and >>>>>>>>>>> reverse xmas. >>>>>>>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>>>>>>> >>>>>>>>>>> Changes in V4: >>>>>>>>>>> - Removed struct dwc3* as an argument for >>>>>>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>>>>>> Changes in V3: >>>>>>>>>>> - Removed "Reviewed-by" tags >>>>>>>>>>> - Renamed series back to RFC >>>>>>>>>>> - Modified logic to ensure that fifo_size is reset if we >>>>>>>>>>> pass the >>>>>>>>>>> minimum >>>>>>>>>>> threshold. Tested with binding multiple FDs requesting 6 >>>>>>>>>>> FIFOs. >>>>>>>>>>> >>>>>>>>>>> Changes in V2: >>>>>>>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>>>>>>> reserved a >>>>>>>>>>> FIFO. >>>>>>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>>>>>> - Added some more description on the dt-bindings commit >>>>>>>>>>> message >>>>>>>>>>> >>>>>>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>>>>>> TXFIFOs, and >>>>>>>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>>>>>>> cases, the >>>>>>>>>>> HW default is probably sufficient, but for USB compositions that >>>>>>>>>>> contain >>>>>>>>>>> multiple functions that require EP bursting, the default settings >>>>>>>>>>> might not be enough. Also to note, the current SW will assign an >>>>>>>>>>> EP to a >>>>>>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>>>>>> particular >>>>>>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>>>>>> defined >>>>>>>>>>> values for the TXFIFO size) >>>>>>>>>>> >>>>>>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>>>>>> depth = 3 >>>>>>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>>>>>> may be >>>>>>>>>>> frequent occurences of bursts ending. For high bandwidth >>>>>>>>>>> functions, >>>>>>>>>>> such as data tethering (protocols that support data aggregation), >>>>>>>>>>> mass >>>>>>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst >>>>>>>>>>> value >>>>>>>>>>> can be >>>>>>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in >>>>>>>>>>> terms >>>>>>>>>>> of USB >>>>>>>>>>> throughput. (which can be associated to system access latency, >>>>>>>>>>> etc...) It >>>>>>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>>>>>> interruptions, as >>>>>>>>>>> data is readily available in the FIFO. >>>>>>>>>>> >>>>>>>>>>> With testing done using the mass storage function driver, the >>>>>>>>>>> results >>>>>>>>>>> show >>>>>>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>>>>>> significantly. >>>>>>>>>>> >>>>>>>>>>> Test Parameters: >>>>>>>>>>> - Platform: Qualcomm SM8150 >>>>>>>>>>> - bMaxBurst = 6 >>>>>>>>>>> - USB req size = 256kB >>>>>>>>>>> - Num of USB reqs = 16 >>>>>>>>>>> - USB Speed = Super-Speed >>>>>>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>>>>>> - Test Application: CrystalDiskMark >>>>>>>>>>> >>>>>>>>>>> Results: >>>>>>>>>>> >>>>>>>>>>> TXFIFO Depth = 3 max packets >>>>>>>>>>> >>>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>>> ------------------------------------------- >>>>>>>>>>> Sequential|1 GB x | >>>>>>>>>>> Read |9 loops | 193.60 >>>>>>>>>>> | | 195.86 >>>>>>>>>>> | | 184.77 >>>>>>>>>>> | | 193.60 >>>>>>>>>>> ------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> TXFIFO Depth = 6 max packets >>>>>>>>>>> >>>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>>> ------------------------------------------- >>>>>>>>>>> Sequential|1 GB x | >>>>>>>>>>> Read |9 loops | 287.35 >>>>>>>>>>> | | 304.94 >>>>>>>>>>> | | 289.64 >>>>>>>>>>> | | 293.61 >>>>>>>>>>> ------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> Wesley Cheng (6): >>>>>>>>>>> usb: gadget: udc: core: Introduce check_config to verify >>>>>>>>>>> USB >>>>>>>>>>> configuration >>>>>>>>>>> usb: gadget: configfs: Check USB configuration before >>>>>>>>>>> adding >>>>>>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>>>>>>> of: Add stub for of_add_property() >>>>>>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by >>>>>>>>>>> default >>>>>>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>>>>>> >>>>>>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>>>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>>>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>>>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>>>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>>>>>> +++++++++++++++++++++ >>>>>>>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>>>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>>>>>>> include/linux/of.h | 5 + >>>>>>>>>>> include/linux/usb/gadget.h | 5 + >>>>>>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>>>>>
On 6/25/2021 2:10 PM, Ferry Toth wrote: > Hi > > Op 23-06-2021 om 09:50 schreef Wesley Cheng: >> >> On 6/22/2021 3:12 PM, Ferry Toth wrote: >>> Hi >>> >>> Op 23-06-2021 om 00:00 schreef Wesley Cheng: >>>> On 6/22/2021 1:09 PM, Ferry Toth wrote: >>>>> Hi >>>>> >>>>> Op 22-06-2021 om 20:38 schreef Wesley Cheng: >>>>>> On 6/19/2021 5:40 AM, Ferry Toth wrote: >>>>>>> Hi >>>>>>> >>>>>>> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>>>>>>> Changes in V10: >>>>>>>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>>>>>>> (error due to >>>>>>>>>>>> unknown symbol for of_add_property()). Add >>>>>>>>>>>> of_add_property() >>>>>>>>>>>> stub. >>>>>>>>>>>> - Fixed compilation warning for incorrect argument being >>>>>>>>>>>> passed to >>>>>>>>>>>> dwc3_mdwidth >>>>>>>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>>>>>>> performance >>>>>>>>>>> on Merrifield though. >>>>>>>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>>>>>>> device's >>>>>>>>>> internal storage (ie UFS, eMMC, etc...), or did you use a >>>>>>>>>> ramdisk as >>>>>>>>>> well? >>>>>>>>> In this case I just tested the EEM path using iperf3. >>>>>>>>> >>>>>>>> Got it. I don't believe f_eem will use a high enough (if at all) >>>>>>>> bMaxBurst value to change the TXFIFO size. >>>>>>>> >>>>>>>>>> If not with a ramdisk, we might want to give that a try to avoid >>>>>>>>>> the >>>>>>>>>> storage path being the bottleneck. You can use "dd" to create an >>>>>>>>>> empty >>>>>>>>>> file, and then just use that as the LUN's backing file. >>>>>>>>>> >>>>>>>>>> echo ramdisk.img > >>>>>>>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Ah, why didn't I think of that. I have currently mass storage >>>>>>>>> setup >>>>>>>>> with >>>>>>>>> eMMC but it seems that is indeed the bottleneck. >>>>>>>>> >>>>>>> I created a 64MB disk following the instructions here >>>>>>> http://www.linux-usb.org/gadget/file_storage.html (that seems a >>>>>>> little >>>>>>> outdated, at least I can not start the first partition at sector 8, >>>>>>> but >>>>>>> minimum 2048), and added a test file on it. >>>>>>> >>>>>>> I then copy the file to /dev/shm prior to setting configfs >>>>>>> (composite >>>>>>> device gser/eem/mass_storage/uac2). >>>>>>> >>>>>>> journal shows: >>>>>>> >>>>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>>>> kernel: LUN: removable file: (no medium) >>>>>>> >>>>>>> I don't know what that means, because I see the test file on the >>>>>>> ramdisk. >>>>>>> >>>>>>> Then I again used gnome disks to benchmark (read/write 10MB): >>>>>>> >>>>>>> With V10 on top v5.13.0-rc5: >>>>>>> >>>>>>> R/W speed = 35.6/35.8MB/s, access time 0.35ms >>>>>>> >>>>>>> With no patches on top v5.12.0: >>>>>>> >>>>>>> R/W speed = 35.7/36.1MB/s, access time 0.35ms >>>>>> Hi Ferry, >>>>>> >>>>>>> I see no speed difference (and it's about the same as with the eMMC >>>>>>> backed disk). But the patches are causing a new call trace >>>>>>> >>>>>> Would you happen to know what DWC3 controller revision the device is >>>>>> using? The callstack print occurs, because it looks like it ran >>>>>> out of >>>>>> internal memory, although there should be logic present for making >>>>>> sure >>>>>> that at least there is enough room for 1 FIFO per endpoint. >>>>>> (possibly >>>>>> the logic/math depends on the controller revision) >>>> Hi Ferry, >>>> >>>>> Do you know where I could find that in a file on the device? >>>>> >>>> Maybe you can just dump the DWC3 registers? >>>> cat /sys/kernel/debug/usb/<controller name>/regdump >>> This isin host mode: >>> >>> ~# cat /sys/kernel/debug/usb/dwc3.0.auto/regdump >>> GSBUSCFG0 = 0x00000006 >>> GSBUSCFG1 = 0x00000f00 >>> GTXTHRCFG = 0x230a0000 >>> GRXTHRCFG = 0x22800000 >>> GCTL = 0x45801002 >>> GEVTEN = 0x00000000 >>> GSTS = 0x3e800001 >>> GUCTL1 = 0x00000000 >>> GSNPSID = 0x5533250a >>> GGPIO = 0x00000000 >>> GUID = 0x00050d00 >>> GUCTL = 0x0200ce00 >>> GBUSERRADDR0 = 0x00000000 >>> GBUSERRADDR1 = 0x00000000 >> ... >> Hi Ferry, >> >> Great! Thanks, that got me the information regarding the DWC3 revision >> you're using. (its version 2.50a) I checked the DWC3 databook and looks >> like certain versions have some different math to calculate the TXFIFO >> size. I have taken this into account and factored that in in the next >> revision. >> >> Is there a way you could collect the regdump in device mode w/ mass >> storage only composition after enumerating with the PC? That would help >> confirm how the TXFIFO resizing logic is working on your platform. > > Sorry for the wait. Yes I have serial console. So here is in device > mode, mass_storage only, enumerated but not mounted: > > GSBUSCFG0 = 0x00000006 > GSBUSCFG1 = 0x00000f00 > GTXTHRCFG = 0x230a0000 > GRXTHRCFG = 0x02800000 > GCTL = 0x45802002 > GEVTEN = 0x00000000 ... > Hi Ferry, Thanks! So does your board support SSUSB by any chance? Based on the DSTS output, it seems that its currently operating in HSUSB mode. I guess we'd expect higher tput values as well in general if we are in SSUSB mode. The resize logic would only happen if the device was in SSUSB, as SSUSB has endpoint bursting, which is the main incentive for the fifo resize. Thanks Wesley Cheng >> Thanks >> Wesley Cheng >> >>>> Was going to ask for the same to confirm the TXFIFO sizes from your >>>> results below :). >>>> >>>>> Otherwise, I'm hoping Andy will know? >>>>> >>>>>> Also, is there a way to use just a mass storage only composition? >>>>>> Based >>>>>> on the above observation, that probably means that the mass storage >>>>>> interface wasn't resized at all, because the configuration took up a >>>>>> lot >>>>>> of the internal FIFO space. >>>>> Sure, it's configured through configfs. With only mass_storage I have: >>>>> >>>>> With V10 on top v5.13.0-rc5: >>>>> >>>>> R/W speed = 41,6/39,3MB/s, access time 0.33ms >>>>> >>>>> With no patches on top v5.12.0: >>>>> >>>>> R/W speed = 41,1/38,7MB/s, access time 0.38ms >>>>> >>>> Thanks Ferry! Could you collect the regdump, so I can confirm the two >>>> things mentioned? >>>> >>>> Thanks >>>> Wesley Cheng >>>> >>>>>> Thanks >>>>>> Wesley Cheng >>>>>> >>>>>>> kernel: using random self ethernet address >>>>>>> kernel: using random host ethernet address >>>>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>>>> kernel: LUN: removable file: (no medium) >>>>>>> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >>>>>>> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >>>>>>> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>> depth:115540359 >>>>>>> kernel: ------------[ cut here ]------------ >>>>>>> kernel: WARNING: CPU: 0 PID: 594 at >>>>>>> drivers/usb/gadget/udc/core.c:278 >>>>>>> usb_ep_queue+0x75/0x80 >>>>>>> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >>>>>>> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm >>>>>>> iptable_nat >>>>>>> bnep snd_sof_nocodec spi_pxa2> >>>>>>> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >>>>>>> 5.13.0-rc5-edison-acpi-standard #1 >>>>>>> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>> BIOS 542 >>>>>>> 2015.01.21:18.19.48 >>>>>>> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >>>>>>> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b >>>>>>> 78 08 >>>>>>> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >>>>>>> <0f> 0b 41 bd 94 ff ff ff > >>>>>>> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >>>>>>> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: >>>>>>> ffff8af202f06400 >>>>>>> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: >>>>>>> ffff8af202e9ae00 >>>>>>> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: >>>>>>> ffff8af208785780 >>>>>>> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: >>>>>>> ffff8af208785780 >>>>>>> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: >>>>>>> ffff8af203e26cc0 >>>>>>> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >>>>>>> knlGS:0000000000000000 >>>>>>> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: >>>>>>> 00000000001006f0 >>>>>>> kernel: Call Trace: >>>>>>> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >>>>>>> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >>>>>>> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >>>>>>> kernel: ? usb_ep_queue+0x2a/0x80 >>>>>>> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>> kernel: dwc3_ep0_interrupt+0x469/0xa80 >>>>>>> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>> kernel: ? __wake_up_common_lock+0x85/0xb0 >>>>>>> kernel: ? disable_irq_nosync+0x10/0x10 >>>>>>> kernel: irq_thread_fn+0x1b/0x60 >>>>>>> kernel: irq_thread+0xd6/0x170 >>>>>>> kernel: ? irq_thread_check_affinity+0x70/0x70 >>>>>>> kernel: ? irq_forced_thread_fn+0x70/0x70 >>>>>>> kernel: kthread+0x116/0x130 >>>>>>> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >>>>>>> kernel: ret_from_fork+0x22/0x30 >>>>>>> kernel: ---[ end trace e5b9e28058c53584 ]--- >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>> depth:115540359 >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>> depth:115540359 >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>> depth:115540359 >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>> depth:115540359 >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>>>> ep5in >>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>>> ep5in >>>>>>> >>>>>>> Removing uac2 from the config makes the call trace go away, but the >>>>>>> R/W >>>>>>> speed does not change. >>>>>>> >>>>>>>> :), not a problem...I've been working on getting the ideal set >>>>>>>> up for >>>>>>>> the performance profiling for awhile, so anything I can do to make >>>>>>>> sure >>>>>>>> we get some good results. >>>>>>>> >>>>>>>>> I'll try with a ramdisk and let you know. >>>>>>>>> >>>>>>>> Thanks again for the testing, Ferry. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Wesley Cheng >>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Wesley Cheng >>>>>>>>>> >>>>>>>>>>>> Changes in V9: >>>>>>>>>>>> - Fixed incorrect patch in series. Removed changes in >>>>>>>>>>>> DTSI, as >>>>>>>>>>>> dwc3-qcom will >>>>>>>>>>>> add the property by default from the kernel. >>>>>>>>>>>> >>>>>>>>>>>> Changes in V8: >>>>>>>>>>>> - Rebased to usb-testing >>>>>>>>>>>> - Using devm_kzalloc for adding txfifo property in >>>>>>>>>>>> dwc3-qcom >>>>>>>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo >>>>>>>>>>>> resize >>>>>>>>>>>> >>>>>>>>>>>> Changes in V7: >>>>>>>>>>>> - Added a new property tx-fifo-max-num for limiting >>>>>>>>>>>> how much >>>>>>>>>>>> fifo >>>>>>>>>>>> space the >>>>>>>>>>>> resizing logic can allocate for endpoints with large >>>>>>>>>>>> burst >>>>>>>>>>>> values. This >>>>>>>>>>>> can differ across platforms, and tie in closely with >>>>>>>>>>>> overall >>>>>>>>>>>> system latency. >>>>>>>>>>>> - Added recommended checks for DWC32. >>>>>>>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>>>>>>> dwc3-qcom by >>>>>>>>>>>> default >>>>>>>>>>>> instead of modifying the current DTSI files. >>>>>>>>>>>> - Added comments on all APIs/variables introduced. >>>>>>>>>>>> - Updated the DWC3 YAML to include a better description >>>>>>>>>>>> of the >>>>>>>>>>>> tx-fifo-resize >>>>>>>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>>>>>>> >>>>>>>>>>>> Changes in V6: >>>>>>>>>>>> - Rebased patches to usb-testing. >>>>>>>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>>>>>>> - Checking for fs_descriptors instead of >>>>>>>>>>>> ss_descriptors for >>>>>>>>>>>> determining the >>>>>>>>>>>> endpoint count for a particular configuration. >>>>>>>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>>>>>>> >>>>>>>>>>>> Changes in V5: >>>>>>>>>>>> - Added check_config() logic, which is used to >>>>>>>>>>>> communicate the >>>>>>>>>>>> number of EPs >>>>>>>>>>>> used in a particular configuration. Based on this, the >>>>>>>>>>>> DWC3 >>>>>>>>>>>> gadget driver >>>>>>>>>>>> has the ability to know the maximum number of eps >>>>>>>>>>>> utilized in >>>>>>>>>>>> all >>>>>>>>>>>> configs. >>>>>>>>>>>> This helps reduce unnecessary allocation to unused eps, >>>>>>>>>>>> and will >>>>>>>>>>>> catch fifo >>>>>>>>>>>> allocation issues at bind() time. >>>>>>>>>>>> - Fixed variable declaration to single line per variable, >>>>>>>>>>>> and >>>>>>>>>>>> reverse xmas. >>>>>>>>>>>> - Created a helper for fifo clearing, which is used by >>>>>>>>>>>> ep0.c >>>>>>>>>>>> >>>>>>>>>>>> Changes in V4: >>>>>>>>>>>> - Removed struct dwc3* as an argument for >>>>>>>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>>>>>>> Changes in V3: >>>>>>>>>>>> - Removed "Reviewed-by" tags >>>>>>>>>>>> - Renamed series back to RFC >>>>>>>>>>>> - Modified logic to ensure that fifo_size is reset if we >>>>>>>>>>>> pass the >>>>>>>>>>>> minimum >>>>>>>>>>>> threshold. Tested with binding multiple FDs >>>>>>>>>>>> requesting 6 >>>>>>>>>>>> FIFOs. >>>>>>>>>>>> >>>>>>>>>>>> Changes in V2: >>>>>>>>>>>> - Modified TXFIFO resizing logic to ensure that each >>>>>>>>>>>> EP is >>>>>>>>>>>> reserved a >>>>>>>>>>>> FIFO. >>>>>>>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>>>>>>> - Added some more description on the dt-bindings commit >>>>>>>>>>>> message >>>>>>>>>>>> >>>>>>>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>>>>>>> TXFIFOs, and >>>>>>>>>>>> relying on the HW default setting for the TXFIFO depth. In >>>>>>>>>>>> most >>>>>>>>>>>> cases, the >>>>>>>>>>>> HW default is probably sufficient, but for USB compositions >>>>>>>>>>>> that >>>>>>>>>>>> contain >>>>>>>>>>>> multiple functions that require EP bursting, the default >>>>>>>>>>>> settings >>>>>>>>>>>> might not be enough. Also to note, the current SW will >>>>>>>>>>>> assign an >>>>>>>>>>>> EP to a >>>>>>>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>>>>>>> particular >>>>>>>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>>>>>>> defined >>>>>>>>>>>> values for the TXFIFO size) >>>>>>>>>>>> >>>>>>>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>>>>>>> depth = 3 >>>>>>>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>>>>>>> may be >>>>>>>>>>>> frequent occurences of bursts ending. For high bandwidth >>>>>>>>>>>> functions, >>>>>>>>>>>> such as data tethering (protocols that support data >>>>>>>>>>>> aggregation), >>>>>>>>>>>> mass >>>>>>>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst >>>>>>>>>>>> value >>>>>>>>>>>> can be >>>>>>>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in >>>>>>>>>>>> terms >>>>>>>>>>>> of USB >>>>>>>>>>>> throughput. (which can be associated to system access latency, >>>>>>>>>>>> etc...) It >>>>>>>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>>>>>>> interruptions, as >>>>>>>>>>>> data is readily available in the FIFO. >>>>>>>>>>>> >>>>>>>>>>>> With testing done using the mass storage function driver, the >>>>>>>>>>>> results >>>>>>>>>>>> show >>>>>>>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>>>>>>> significantly. >>>>>>>>>>>> >>>>>>>>>>>> Test Parameters: >>>>>>>>>>>> - Platform: Qualcomm SM8150 >>>>>>>>>>>> - bMaxBurst = 6 >>>>>>>>>>>> - USB req size = 256kB >>>>>>>>>>>> - Num of USB reqs = 16 >>>>>>>>>>>> - USB Speed = Super-Speed >>>>>>>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>>>>>>> - Test Application: CrystalDiskMark >>>>>>>>>>>> >>>>>>>>>>>> Results: >>>>>>>>>>>> >>>>>>>>>>>> TXFIFO Depth = 3 max packets >>>>>>>>>>>> >>>>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>> Sequential|1 GB x | >>>>>>>>>>>> Read |9 loops | 193.60 >>>>>>>>>>>> | | 195.86 >>>>>>>>>>>> | | 184.77 >>>>>>>>>>>> | | 193.60 >>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> TXFIFO Depth = 6 max packets >>>>>>>>>>>> >>>>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>> Sequential|1 GB x | >>>>>>>>>>>> Read |9 loops | 287.35 >>>>>>>>>>>> | | 304.94 >>>>>>>>>>>> | | 289.64 >>>>>>>>>>>> | | 293.61 >>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> Wesley Cheng (6): >>>>>>>>>>>> usb: gadget: udc: core: Introduce check_config to verify >>>>>>>>>>>> USB >>>>>>>>>>>> configuration >>>>>>>>>>>> usb: gadget: configfs: Check USB configuration before >>>>>>>>>>>> adding >>>>>>>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting >>>>>>>>>>>> requirements >>>>>>>>>>>> of: Add stub for of_add_property() >>>>>>>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by >>>>>>>>>>>> default >>>>>>>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>>>>>>> >>>>>>>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | >>>>>>>>>>>> 15 +- >>>>>>>>>>>> drivers/usb/dwc3/core.c | >>>>>>>>>>>> 9 + >>>>>>>>>>>> drivers/usb/dwc3/core.h | >>>>>>>>>>>> 15 ++ >>>>>>>>>>>> drivers/usb/dwc3/dwc3-qcom.c | >>>>>>>>>>>> 9 + >>>>>>>>>>>> drivers/usb/dwc3/ep0.c | >>>>>>>>>>>> 2 + >>>>>>>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>>>>>>> +++++++++++++++++++++ >>>>>>>>>>>> drivers/usb/gadget/configfs.c | >>>>>>>>>>>> 22 +++ >>>>>>>>>>>> drivers/usb/gadget/udc/core.c | >>>>>>>>>>>> 25 +++ >>>>>>>>>>>> include/linux/of.h | >>>>>>>>>>>> 5 + >>>>>>>>>>>> include/linux/usb/gadget.h | >>>>>>>>>>>> 5 + >>>>>>>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>>>>>>
Hi Op 25-06-2021 om 23:19 schreef Wesley Cheng: > > On 6/25/2021 2:10 PM, Ferry Toth wrote: >> Hi >> >> Op 23-06-2021 om 09:50 schreef Wesley Cheng: >>> On 6/22/2021 3:12 PM, Ferry Toth wrote: >>>> Hi >>>> >>>> Op 23-06-2021 om 00:00 schreef Wesley Cheng: >>>>> On 6/22/2021 1:09 PM, Ferry Toth wrote: >>>>>> Hi >>>>>> >>>>>> Op 22-06-2021 om 20:38 schreef Wesley Cheng: >>>>>>> On 6/19/2021 5:40 AM, Ferry Toth wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>>>>>>>> Changes in V10: >>>>>>>>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>>>>>>>> (error due to >>>>>>>>>>>>> unknown symbol for of_add_property()). Add >>>>>>>>>>>>> of_add_property() >>>>>>>>>>>>> stub. >>>>>>>>>>>>> - Fixed compilation warning for incorrect argument being >>>>>>>>>>>>> passed to >>>>>>>>>>>>> dwc3_mdwidth >>>>>>>>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>>>>>>>> performance >>>>>>>>>>>> on Merrifield though. >>>>>>>>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>>>>>>>> device's >>>>>>>>>>> internal storage (ie UFS, eMMC, etc...), or did you use a >>>>>>>>>>> ramdisk as >>>>>>>>>>> well? >>>>>>>>>> In this case I just tested the EEM path using iperf3. >>>>>>>>>> >>>>>>>>> Got it. I don't believe f_eem will use a high enough (if at all) >>>>>>>>> bMaxBurst value to change the TXFIFO size. >>>>>>>>> >>>>>>>>>>> If not with a ramdisk, we might want to give that a try to avoid >>>>>>>>>>> the >>>>>>>>>>> storage path being the bottleneck. You can use "dd" to create an >>>>>>>>>>> empty >>>>>>>>>>> file, and then just use that as the LUN's backing file. >>>>>>>>>>> >>>>>>>>>>> echo ramdisk.img > >>>>>>>>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Ah, why didn't I think of that. I have currently mass storage >>>>>>>>>> setup >>>>>>>>>> with >>>>>>>>>> eMMC but it seems that is indeed the bottleneck. >>>>>>>>>> >>>>>>>> I created a 64MB disk following the instructions here >>>>>>>> http://www.linux-usb.org/gadget/file_storage.html (that seems a >>>>>>>> little >>>>>>>> outdated, at least I can not start the first partition at sector 8, >>>>>>>> but >>>>>>>> minimum 2048), and added a test file on it. >>>>>>>> >>>>>>>> I then copy the file to /dev/shm prior to setting configfs >>>>>>>> (composite >>>>>>>> device gser/eem/mass_storage/uac2). >>>>>>>> >>>>>>>> journal shows: >>>>>>>> >>>>>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>>>>> kernel: LUN: removable file: (no medium) >>>>>>>> >>>>>>>> I don't know what that means, because I see the test file on the >>>>>>>> ramdisk. >>>>>>>> >>>>>>>> Then I again used gnome disks to benchmark (read/write 10MB): >>>>>>>> >>>>>>>> With V10 on top v5.13.0-rc5: >>>>>>>> >>>>>>>> R/W speed = 35.6/35.8MB/s, access time 0.35ms >>>>>>>> >>>>>>>> With no patches on top v5.12.0: >>>>>>>> >>>>>>>> R/W speed = 35.7/36.1MB/s, access time 0.35ms >>>>>>> Hi Ferry, >>>>>>> >>>>>>>> I see no speed difference (and it's about the same as with the eMMC >>>>>>>> backed disk). But the patches are causing a new call trace >>>>>>>> >>>>>>> Would you happen to know what DWC3 controller revision the device is >>>>>>> using? The callstack print occurs, because it looks like it ran >>>>>>> out of >>>>>>> internal memory, although there should be logic present for making >>>>>>> sure >>>>>>> that at least there is enough room for 1 FIFO per endpoint. >>>>>>> (possibly >>>>>>> the logic/math depends on the controller revision) >>>>> Hi Ferry, >>>>> >>>>>> Do you know where I could find that in a file on the device? >>>>>> >>>>> Maybe you can just dump the DWC3 registers? >>>>> cat /sys/kernel/debug/usb/<controller name>/regdump >>>> This isin host mode: >>>> >>>> ~# cat /sys/kernel/debug/usb/dwc3.0.auto/regdump >>>> GSBUSCFG0 = 0x00000006 >>>> GSBUSCFG1 = 0x00000f00 >>>> GTXTHRCFG = 0x230a0000 >>>> GRXTHRCFG = 0x22800000 >>>> GCTL = 0x45801002 >>>> GEVTEN = 0x00000000 >>>> GSTS = 0x3e800001 >>>> GUCTL1 = 0x00000000 >>>> GSNPSID = 0x5533250a >>>> GGPIO = 0x00000000 >>>> GUID = 0x00050d00 >>>> GUCTL = 0x0200ce00 >>>> GBUSERRADDR0 = 0x00000000 >>>> GBUSERRADDR1 = 0x00000000 >>> ... >>> Hi Ferry, >>> >>> Great! Thanks, that got me the information regarding the DWC3 revision >>> you're using. (its version 2.50a) I checked the DWC3 databook and looks >>> like certain versions have some different math to calculate the TXFIFO >>> size. I have taken this into account and factored that in in the next >>> revision. >>> >>> Is there a way you could collect the regdump in device mode w/ mass >>> storage only composition after enumerating with the PC? That would help >>> confirm how the TXFIFO resizing logic is working on your platform. >> Sorry for the wait. Yes I have serial console. So here is in device >> mode, mass_storage only, enumerated but not mounted: >> >> GSBUSCFG0 = 0x00000006 >> GSBUSCFG1 = 0x00000f00 >> GTXTHRCFG = 0x230a0000 >> GRXTHRCFG = 0x02800000 >> GCTL = 0x45802002 >> GEVTEN = 0x00000000 > ... > Hi Ferry, > > Thanks! So does your board support SSUSB by any chance? Based on the > DSTS output, it seems that its currently operating in HSUSB mode. I > guess we'd expect higher tput values as well in general if we are in > SSUSB mode. Afaik indeed we have only HS. > The resize logic would only happen if the device was in SSUSB, as SSUSB > has endpoint bursting, which is the main incentive for the fifo resize. > > Thanks > Wesley Cheng > >>> Thanks >>> Wesley Cheng >>> >>>>> Was going to ask for the same to confirm the TXFIFO sizes from your >>>>> results below :). >>>>> >>>>>> Otherwise, I'm hoping Andy will know? >>>>>> >>>>>>> Also, is there a way to use just a mass storage only composition? >>>>>>> Based >>>>>>> on the above observation, that probably means that the mass storage >>>>>>> interface wasn't resized at all, because the configuration took up a >>>>>>> lot >>>>>>> of the internal FIFO space. >>>>>> Sure, it's configured through configfs. With only mass_storage I have: >>>>>> >>>>>> With V10 on top v5.13.0-rc5: >>>>>> >>>>>> R/W speed = 41,6/39,3MB/s, access time 0.33ms >>>>>> >>>>>> With no patches on top v5.12.0: >>>>>> >>>>>> R/W speed = 41,1/38,7MB/s, access time 0.38ms >>>>>> >>>>> Thanks Ferry! Could you collect the regdump, so I can confirm the two >>>>> things mentioned? >>>>> >>>>> Thanks >>>>> Wesley Cheng >>>>> >>>>>>> Thanks >>>>>>> Wesley Cheng >>>>>>> >>>>>>>> kernel: using random self ethernet address >>>>>>>> kernel: using random host ethernet address >>>>>>>> kernel: Mass Storage Function, version: 2009/09/11 >>>>>>>> kernel: LUN: removable file: (no medium) >>>>>>>> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >>>>>>>> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >>>>>>>> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >>>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>>> depth:115540359 >>>>>>>> kernel: ------------[ cut here ]------------ >>>>>>>> kernel: WARNING: CPU: 0 PID: 594 at >>>>>>>> drivers/usb/gadget/udc/core.c:278 >>>>>>>> usb_ep_queue+0x75/0x80 >>>>>>>> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >>>>>>>> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm >>>>>>>> iptable_nat >>>>>>>> bnep snd_sof_nocodec spi_pxa2> >>>>>>>> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >>>>>>>> 5.13.0-rc5-edison-acpi-standard #1 >>>>>>>> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>> BIOS 542 >>>>>>>> 2015.01.21:18.19.48 >>>>>>>> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >>>>>>>> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b >>>>>>>> 78 08 >>>>>>>> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >>>>>>>> <0f> 0b 41 bd 94 ff ff ff > >>>>>>>> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >>>>>>>> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: >>>>>>>> ffff8af202f06400 >>>>>>>> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: >>>>>>>> ffff8af202e9ae00 >>>>>>>> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: >>>>>>>> ffff8af208785780 >>>>>>>> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: >>>>>>>> ffff8af208785780 >>>>>>>> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: >>>>>>>> ffff8af203e26cc0 >>>>>>>> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >>>>>>>> knlGS:0000000000000000 >>>>>>>> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: >>>>>>>> 00000000001006f0 >>>>>>>> kernel: Call Trace: >>>>>>>> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >>>>>>>> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >>>>>>>> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >>>>>>>> kernel: ? usb_ep_queue+0x2a/0x80 >>>>>>>> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>> kernel: dwc3_ep0_interrupt+0x469/0xa80 >>>>>>>> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>> kernel: ? __wake_up_common_lock+0x85/0xb0 >>>>>>>> kernel: ? disable_irq_nosync+0x10/0x10 >>>>>>>> kernel: irq_thread_fn+0x1b/0x60 >>>>>>>> kernel: irq_thread+0xd6/0x170 >>>>>>>> kernel: ? irq_thread_check_affinity+0x70/0x70 >>>>>>>> kernel: ? irq_forced_thread_fn+0x70/0x70 >>>>>>>> kernel: kthread+0x116/0x130 >>>>>>>> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >>>>>>>> kernel: ret_from_fork+0x22/0x30 >>>>>>>> kernel: ---[ end trace e5b9e28058c53584 ]--- >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>>> depth:115540359 >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>>> depth:115540359 >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>>> depth:115540359 >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>>>> depth:115540359 >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to >>>>>>>> ep5in >>>>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to >>>>>>>> ep5in >>>>>>>> >>>>>>>> Removing uac2 from the config makes the call trace go away, but the >>>>>>>> R/W >>>>>>>> speed does not change. >>>>>>>> >>>>>>>>> :), not a problem...I've been working on getting the ideal set >>>>>>>>> up for >>>>>>>>> the performance profiling for awhile, so anything I can do to make >>>>>>>>> sure >>>>>>>>> we get some good results. >>>>>>>>> >>>>>>>>>> I'll try with a ramdisk and let you know. >>>>>>>>>> >>>>>>>>> Thanks again for the testing, Ferry. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Wesley Cheng >>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Wesley Cheng >>>>>>>>>>> >>>>>>>>>>>>> Changes in V9: >>>>>>>>>>>>> - Fixed incorrect patch in series. Removed changes in >>>>>>>>>>>>> DTSI, as >>>>>>>>>>>>> dwc3-qcom will >>>>>>>>>>>>> add the property by default from the kernel. >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in V8: >>>>>>>>>>>>> - Rebased to usb-testing >>>>>>>>>>>>> - Using devm_kzalloc for adding txfifo property in >>>>>>>>>>>>> dwc3-qcom >>>>>>>>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo >>>>>>>>>>>>> resize >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in V7: >>>>>>>>>>>>> - Added a new property tx-fifo-max-num for limiting >>>>>>>>>>>>> how much >>>>>>>>>>>>> fifo >>>>>>>>>>>>> space the >>>>>>>>>>>>> resizing logic can allocate for endpoints with large >>>>>>>>>>>>> burst >>>>>>>>>>>>> values. This >>>>>>>>>>>>> can differ across platforms, and tie in closely with >>>>>>>>>>>>> overall >>>>>>>>>>>>> system latency. >>>>>>>>>>>>> - Added recommended checks for DWC32. >>>>>>>>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>>>>>>>> dwc3-qcom by >>>>>>>>>>>>> default >>>>>>>>>>>>> instead of modifying the current DTSI files. >>>>>>>>>>>>> - Added comments on all APIs/variables introduced. >>>>>>>>>>>>> - Updated the DWC3 YAML to include a better description >>>>>>>>>>>>> of the >>>>>>>>>>>>> tx-fifo-resize >>>>>>>>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in V6: >>>>>>>>>>>>> - Rebased patches to usb-testing. >>>>>>>>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>>>>>>>> - Checking for fs_descriptors instead of >>>>>>>>>>>>> ss_descriptors for >>>>>>>>>>>>> determining the >>>>>>>>>>>>> endpoint count for a particular configuration. >>>>>>>>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in V5: >>>>>>>>>>>>> - Added check_config() logic, which is used to >>>>>>>>>>>>> communicate the >>>>>>>>>>>>> number of EPs >>>>>>>>>>>>> used in a particular configuration. Based on this, the >>>>>>>>>>>>> DWC3 >>>>>>>>>>>>> gadget driver >>>>>>>>>>>>> has the ability to know the maximum number of eps >>>>>>>>>>>>> utilized in >>>>>>>>>>>>> all >>>>>>>>>>>>> configs. >>>>>>>>>>>>> This helps reduce unnecessary allocation to unused eps, >>>>>>>>>>>>> and will >>>>>>>>>>>>> catch fifo >>>>>>>>>>>>> allocation issues at bind() time. >>>>>>>>>>>>> - Fixed variable declaration to single line per variable, >>>>>>>>>>>>> and >>>>>>>>>>>>> reverse xmas. >>>>>>>>>>>>> - Created a helper for fifo clearing, which is used by >>>>>>>>>>>>> ep0.c >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in V4: >>>>>>>>>>>>> - Removed struct dwc3* as an argument for >>>>>>>>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>>>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>>>>>>>> Changes in V3: >>>>>>>>>>>>> - Removed "Reviewed-by" tags >>>>>>>>>>>>> - Renamed series back to RFC >>>>>>>>>>>>> - Modified logic to ensure that fifo_size is reset if we >>>>>>>>>>>>> pass the >>>>>>>>>>>>> minimum >>>>>>>>>>>>> threshold. Tested with binding multiple FDs >>>>>>>>>>>>> requesting 6 >>>>>>>>>>>>> FIFOs. >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in V2: >>>>>>>>>>>>> - Modified TXFIFO resizing logic to ensure that each >>>>>>>>>>>>> EP is >>>>>>>>>>>>> reserved a >>>>>>>>>>>>> FIFO. >>>>>>>>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>>>>>>>> - Added some more description on the dt-bindings commit >>>>>>>>>>>>> message >>>>>>>>>>>>> >>>>>>>>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>>>>>>>> TXFIFOs, and >>>>>>>>>>>>> relying on the HW default setting for the TXFIFO depth. In >>>>>>>>>>>>> most >>>>>>>>>>>>> cases, the >>>>>>>>>>>>> HW default is probably sufficient, but for USB compositions >>>>>>>>>>>>> that >>>>>>>>>>>>> contain >>>>>>>>>>>>> multiple functions that require EP bursting, the default >>>>>>>>>>>>> settings >>>>>>>>>>>>> might not be enough. Also to note, the current SW will >>>>>>>>>>>>> assign an >>>>>>>>>>>>> EP to a >>>>>>>>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>>>>>>>> particular >>>>>>>>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>>>>>>>> defined >>>>>>>>>>>>> values for the TXFIFO size) >>>>>>>>>>>>> >>>>>>>>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>>>>>>>> depth = 3 >>>>>>>>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>>>>>>>> may be >>>>>>>>>>>>> frequent occurences of bursts ending. For high bandwidth >>>>>>>>>>>>> functions, >>>>>>>>>>>>> such as data tethering (protocols that support data >>>>>>>>>>>>> aggregation), >>>>>>>>>>>>> mass >>>>>>>>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst >>>>>>>>>>>>> value >>>>>>>>>>>>> can be >>>>>>>>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in >>>>>>>>>>>>> terms >>>>>>>>>>>>> of USB >>>>>>>>>>>>> throughput. (which can be associated to system access latency, >>>>>>>>>>>>> etc...) It >>>>>>>>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>>>>>>>> interruptions, as >>>>>>>>>>>>> data is readily available in the FIFO. >>>>>>>>>>>>> >>>>>>>>>>>>> With testing done using the mass storage function driver, the >>>>>>>>>>>>> results >>>>>>>>>>>>> show >>>>>>>>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>>>>>>>> significantly. >>>>>>>>>>>>> >>>>>>>>>>>>> Test Parameters: >>>>>>>>>>>>> - Platform: Qualcomm SM8150 >>>>>>>>>>>>> - bMaxBurst = 6 >>>>>>>>>>>>> - USB req size = 256kB >>>>>>>>>>>>> - Num of USB reqs = 16 >>>>>>>>>>>>> - USB Speed = Super-Speed >>>>>>>>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>>>>>>>> - Test Application: CrystalDiskMark >>>>>>>>>>>>> >>>>>>>>>>>>> Results: >>>>>>>>>>>>> >>>>>>>>>>>>> TXFIFO Depth = 3 max packets >>>>>>>>>>>>> >>>>>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>>> Sequential|1 GB x | >>>>>>>>>>>>> Read |9 loops | 193.60 >>>>>>>>>>>>> | | 195.86 >>>>>>>>>>>>> | | 184.77 >>>>>>>>>>>>> | | 193.60 >>>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> TXFIFO Depth = 6 max packets >>>>>>>>>>>>> >>>>>>>>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>>> Sequential|1 GB x | >>>>>>>>>>>>> Read |9 loops | 287.35 >>>>>>>>>>>>> | | 304.94 >>>>>>>>>>>>> | | 289.64 >>>>>>>>>>>>> | | 293.61 >>>>>>>>>>>>> ------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> Wesley Cheng (6): >>>>>>>>>>>>> usb: gadget: udc: core: Introduce check_config to verify >>>>>>>>>>>>> USB >>>>>>>>>>>>> configuration >>>>>>>>>>>>> usb: gadget: configfs: Check USB configuration before >>>>>>>>>>>>> adding >>>>>>>>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting >>>>>>>>>>>>> requirements >>>>>>>>>>>>> of: Add stub for of_add_property() >>>>>>>>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by >>>>>>>>>>>>> default >>>>>>>>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>>>>>>>> >>>>>>>>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | >>>>>>>>>>>>> 15 +- >>>>>>>>>>>>> drivers/usb/dwc3/core.c | >>>>>>>>>>>>> 9 + >>>>>>>>>>>>> drivers/usb/dwc3/core.h | >>>>>>>>>>>>> 15 ++ >>>>>>>>>>>>> drivers/usb/dwc3/dwc3-qcom.c | >>>>>>>>>>>>> 9 + >>>>>>>>>>>>> drivers/usb/dwc3/ep0.c | >>>>>>>>>>>>> 2 + >>>>>>>>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>>>>>>>> +++++++++++++++++++++ >>>>>>>>>>>>> drivers/usb/gadget/configfs.c | >>>>>>>>>>>>> 22 +++ >>>>>>>>>>>>> drivers/usb/gadget/udc/core.c | >>>>>>>>>>>>> 25 +++ >>>>>>>>>>>>> include/linux/of.h | >>>>>>>>>>>>> 5 + >>>>>>>>>>>>> include/linux/usb/gadget.h | >>>>>>>>>>>>> 5 + >>>>>>>>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>>>>>>>>
Hi, Op 22-06-2021 om 20:38 schreef Wesley Cheng: > > > On 6/19/2021 5:40 AM, Ferry Toth wrote: >> Hi >> >> Op 18-06-2021 om 00:25 schreef Wesley Cheng: >>> Hi, >>> >>> On 6/17/2021 2:55 PM, Ferry Toth wrote: >>>> Hi >>>> >>>> Op 17-06-2021 om 23:48 schreef Wesley Cheng: >>>>> Hi, >>>>> >>>>> On 6/17/2021 2:01 PM, Ferry Toth wrote: >>>>>> Hi >>>>>> >>>>>> Op 17-06-2021 om 11:58 schreef Wesley Cheng: >>>>>>> Changes in V10: >>>>>>> - Fixed compilation errors in config where OF is not used >>>>>>> (error due to >>>>>>> unknown symbol for of_add_property()). Add of_add_property() >>>>>>> stub. >>>>>>> - Fixed compilation warning for incorrect argument being passed to >>>>>>> dwc3_mdwidth >>>>>> This fixes the OOPS I had in V9. I do not see any change in >>>>>> performance >>>>>> on Merrifield though. >>>>> I see...thanks Ferry! With your testing, are you writing to the >>>>> device's >>>>> internal storage (ie UFS, eMMC, etc...), or did you use a ramdisk as >>>>> well? >>>> In this case I just tested the EEM path using iperf3. >>>> >>> Got it. I don't believe f_eem will use a high enough (if at all) >>> bMaxBurst value to change the TXFIFO size. >>> >>>>> If not with a ramdisk, we might want to give that a try to avoid the >>>>> storage path being the bottleneck. You can use "dd" to create an empty >>>>> file, and then just use that as the LUN's backing file. >>>>> >>>>> echo ramdisk.img > >>>>> /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file >>>> Ah, why didn't I think of that. I have currently mass storage setup with >>>> eMMC but it seems that is indeed the bottleneck. >>>> >> I created a 64MB disk following the instructions here >> http://www.linux-usb.org/gadget/file_storage.html (that seems a little >> outdated, at least I can not start the first partition at sector 8, but >> minimum 2048), and added a test file on it. >> >> I then copy the file to /dev/shm prior to setting configfs (composite >> device gser/eem/mass_storage/uac2). >> >> journal shows: >> >> kernel: Mass Storage Function, version: 2009/09/11 >> kernel: LUN: removable file: (no medium) >> >> I don't know what that means, because I see the test file on the ramdisk. >> >> Then I again used gnome disks to benchmark (read/write 10MB): >> >> With V10 on top v5.13.0-rc5: >> >> R/W speed = 35.6/35.8MB/s, access time 0.35ms >> >> With no patches on top v5.12.0: >> >> R/W speed = 35.7/36.1MB/s, access time 0.35ms > > Hi Ferry, > >> >> I see no speed difference (and it's about the same as with the eMMC >> backed disk). But the patches are causing a new call trace >> > > Would you happen to know what DWC3 controller revision the device is > using? The callstack print occurs, because it looks like it ran out of > internal memory, although there should be logic present for making sure > that at least there is enough room for 1 FIFO per endpoint. (possibly > the logic/math depends on the controller revision) > > Also, is there a way to use just a mass storage only composition? Based > on the above observation, that probably means that the mass storage > interface wasn't resized at all, because the configuration took up a lot > of the internal FIFO space. > > Thanks > Wesley Cheng > >> kernel: using random self ethernet address >> kernel: using random host ethernet address >> kernel: Mass Storage Function, version: 2009/09/11 >> kernel: LUN: removable file: (no medium) >> kernel: usb0: HOST MAC aa:bb:cc:dd:ee:f2 >> kernel: usb0: MAC aa:bb:cc:dd:ee:f1 >> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: ------------[ cut here ]------------ >> kernel: WARNING: CPU: 0 PID: 594 at drivers/usb/gadget/udc/core.c:278 >> usb_ep_queue+0x75/0x80 >> kernel: Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage >> usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat >> bnep snd_sof_nocodec spi_pxa2> >> kernel: CPU: 0 PID: 594 Comm: irq/14-dwc3 Not tainted >> 5.13.0-rc5-edison-acpi-standard #1 >> kernel: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >> 2015.01.21:18.19.48 >> kernel: RIP: 0010:usb_ep_queue+0x75/0x80 >> kernel: Code: 01 73 e4 48 8b 05 fb 63 06 01 48 85 c0 74 12 48 8b 78 08 >> 44 89 e9 4c 89 e2 48 89 ee e8 74 05 00 00 44 89 e8 5d 41 5c 41 5d c3 >> <0f> 0b 41 bd 94 ff ff ff > >> kernel: RSP: 0000:ffff91eec083fc98 EFLAGS: 00010082 >> kernel: RAX: ffff8af20357d960 RBX: 0000000000000000 RCX: ffff8af202f06400 >> kernel: RDX: 0000000000000a20 RSI: ffff8af208785780 RDI: ffff8af202e9ae00 >> kernel: RBP: ffff8af202e9ae00 R08: 00000000000000c0 R09: ffff8af208785780 >> kernel: R10: 00000000ffffe000 R11: 3fffffffffffffff R12: ffff8af208785780 >> kernel: R13: 0000000000000000 R14: ffff8af202e9ae00 R15: ffff8af203e26cc0 >> kernel: FS: 0000000000000000(0000) GS:ffff8af23e200000(0000) >> knlGS:0000000000000000 >> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> kernel: CR2: 000055e2c21f2100 CR3: 0000000003b38000 CR4: 00000000001006f0 >> kernel: Call Trace: >> kernel: u_audio_start_playback+0x107/0x1a0 [u_audio] >> kernel: composite_setup+0x224/0x1ba0 [libcomposite] >> kernel: ? dwc3_gadget_ep_queue+0xf6/0x1a0 >> kernel: ? usb_ep_queue+0x2a/0x80 >> kernel: ? configfs_composite_setup+0x6b/0x90 [libcomposite] >> kernel: configfs_composite_setup+0x6b/0x90 [libcomposite] >> kernel: dwc3_ep0_interrupt+0x469/0xa80 >> kernel: dwc3_thread_interrupt+0x8ee/0xf40 >> kernel: ? __wake_up_common_lock+0x85/0xb0 >> kernel: ? disable_irq_nosync+0x10/0x10 >> kernel: irq_thread_fn+0x1b/0x60 >> kernel: irq_thread+0xd6/0x170 >> kernel: ? irq_thread_check_affinity+0x70/0x70 >> kernel: ? irq_forced_thread_fn+0x70/0x70 >> kernel: kthread+0x116/0x130 >> kernel: ? kthread_create_worker_on_cpu+0x60/0x60 >> kernel: ret_from_fork+0x22/0x30 >> kernel: ---[ end trace e5b9e28058c53584 ]--- >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000036ac129 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >> depth:115540359 >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >> >> Removing uac2 from the config makes the call trace go away, but the R/W >> speed does not change. I am testing with 5.14.0-rc2 and now related error appears (not in rc1). Disabling uac2 solves it still. Any idea what it could be? BUG: unable to handle page fault for address: 0000000500000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI CPU: 0 PID: 494 Comm: irq/14-dwc3 Not tainted 5.14.0-rc2-edison-acpi-standard #1 Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 RIP: 0010:0x500000000 Code: Unable to access opcode bytes at RIP 0x4ffffffd6. RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 Call Trace: ? dwc3_remove_requests.constprop.0+0x14d/0x170 ? __dwc3_gadget_ep_disable+0x7a/0x160 ? dwc3_gadget_ep_disable+0x3d/0xd0 ? usb_ep_disable+0x1c/0x70 ? u_audio_stop_capture+0x79/0x120 [u_audio] ? afunc_set_alt+0x73/0x80 [usb_f_uac2] ? composite_setup+0x224/0x1b90 [libcomposite] ? __dwc3_gadget_kick_transfer+0x160/0x400 ? dwc3_gadget_ep_queue+0xf3/0x1a0 ? configfs_composite_setup+0x6b/0x90 [libcomposite] ? configfs_composite_setup+0x6b/0x90 [libcomposite] ? dwc3_ep0_interrupt+0x459/0xa40 ? dwc3_thread_interrupt+0x8ee/0xf40 ? __schedule+0x235/0x6c0 ? disable_irq_nosync+0x10/0x10 ? irq_thread_fn+0x1b/0x60 ? irq_thread+0xc0/0x160 ? irq_thread_check_affinity+0x70/0x70 ? irq_forced_thread_fn+0x70/0x70 ? kthread+0x122/0x140 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 >>> :), not a problem...I've been working on getting the ideal set up for >>> the performance profiling for awhile, so anything I can do to make sure >>> we get some good results. >>> >>>> I'll try with a ramdisk and let you know. >>>> >>> Thanks again for the testing, Ferry. >>> >>> Thanks >>> Wesley Cheng >>> >>>>> Thanks >>>>> Wesley Cheng >>>>> >>>>>>> Changes in V9: >>>>>>> - Fixed incorrect patch in series. Removed changes in DTSI, as >>>>>>> dwc3-qcom will >>>>>>> add the property by default from the kernel. >>>>>>> >>>>>>> Changes in V8: >>>>>>> - Rebased to usb-testing >>>>>>> - Using devm_kzalloc for adding txfifo property in dwc3-qcom >>>>>>> - Removed DWC3 QCOM ACPI property for enabling the txfifo resize >>>>>>> >>>>>>> Changes in V7: >>>>>>> - Added a new property tx-fifo-max-num for limiting how much fifo >>>>>>> space the >>>>>>> resizing logic can allocate for endpoints with large burst >>>>>>> values. This >>>>>>> can differ across platforms, and tie in closely with overall >>>>>>> system latency. >>>>>>> - Added recommended checks for DWC32. >>>>>>> - Added changes to set the tx-fifo-resize property from >>>>>>> dwc3-qcom by >>>>>>> default >>>>>>> instead of modifying the current DTSI files. >>>>>>> - Added comments on all APIs/variables introduced. >>>>>>> - Updated the DWC3 YAML to include a better description of the >>>>>>> tx-fifo-resize >>>>>>> property and added an entry for tx-fifo-max-num. >>>>>>> >>>>>>> Changes in V6: >>>>>>> - Rebased patches to usb-testing. >>>>>>> - Renamed to PATCH series instead of RFC. >>>>>>> - Checking for fs_descriptors instead of ss_descriptors for >>>>>>> determining the >>>>>>> endpoint count for a particular configuration. >>>>>>> - Re-ordered patch series to fix patch dependencies. >>>>>>> >>>>>>> Changes in V5: >>>>>>> - Added check_config() logic, which is used to communicate the >>>>>>> number of EPs >>>>>>> used in a particular configuration. Based on this, the DWC3 >>>>>>> gadget driver >>>>>>> has the ability to know the maximum number of eps utilized in >>>>>>> all >>>>>>> configs. >>>>>>> This helps reduce unnecessary allocation to unused eps, and will >>>>>>> catch fifo >>>>>>> allocation issues at bind() time. >>>>>>> - Fixed variable declaration to single line per variable, and >>>>>>> reverse xmas. >>>>>>> - Created a helper for fifo clearing, which is used by ep0.c >>>>>>> >>>>>>> Changes in V4: >>>>>>> - Removed struct dwc3* as an argument for >>>>>>> dwc3_gadget_resize_tx_fifos() >>>>>>> - Removed WARN_ON(1) in case we run out of fifo space >>>>>>> Changes in V3: >>>>>>> - Removed "Reviewed-by" tags >>>>>>> - Renamed series back to RFC >>>>>>> - Modified logic to ensure that fifo_size is reset if we pass the >>>>>>> minimum >>>>>>> threshold. Tested with binding multiple FDs requesting 6 FIFOs. >>>>>>> >>>>>>> Changes in V2: >>>>>>> - Modified TXFIFO resizing logic to ensure that each EP is >>>>>>> reserved a >>>>>>> FIFO. >>>>>>> - Removed dev_dbg() prints and fixed typos from patches >>>>>>> - Added some more description on the dt-bindings commit message >>>>>>> >>>>>>> Currently, there is no functionality to allow for resizing the >>>>>>> TXFIFOs, and >>>>>>> relying on the HW default setting for the TXFIFO depth. In most >>>>>>> cases, the >>>>>>> HW default is probably sufficient, but for USB compositions that >>>>>>> contain >>>>>>> multiple functions that require EP bursting, the default settings >>>>>>> might not be enough. Also to note, the current SW will assign an >>>>>>> EP to a >>>>>>> function driver w/o checking to see if the TXFIFO size for that >>>>>>> particular >>>>>>> EP is large enough. (this is a problem if there are multiple HW >>>>>>> defined >>>>>>> values for the TXFIFO size) >>>>>>> >>>>>>> It is mentioned in the SNPS databook that a minimum of TX FIFO >>>>>>> depth = 3 >>>>>>> is required for an EP that supports bursting. Otherwise, there >>>>>>> may be >>>>>>> frequent occurences of bursts ending. For high bandwidth functions, >>>>>>> such as data tethering (protocols that support data aggregation), >>>>>>> mass >>>>>>> storage, and media transfer protocol (over FFS), the bMaxBurst value >>>>>>> can be >>>>>>> large, and a bigger TXFIFO depth may prove to be beneficial in terms >>>>>>> of USB >>>>>>> throughput. (which can be associated to system access latency, >>>>>>> etc...) It >>>>>>> allows for a more consistent burst of traffic, w/o any >>>>>>> interruptions, as >>>>>>> data is readily available in the FIFO. >>>>>>> >>>>>>> With testing done using the mass storage function driver, the results >>>>>>> show >>>>>>> that with a larger TXFIFO depth, the bandwidth increased >>>>>>> significantly. >>>>>>> >>>>>>> Test Parameters: >>>>>>> - Platform: Qualcomm SM8150 >>>>>>> - bMaxBurst = 6 >>>>>>> - USB req size = 256kB >>>>>>> - Num of USB reqs = 16 >>>>>>> - USB Speed = Super-Speed >>>>>>> - Function Driver: Mass Storage (w/ ramdisk) >>>>>>> - Test Application: CrystalDiskMark >>>>>>> >>>>>>> Results: >>>>>>> >>>>>>> TXFIFO Depth = 3 max packets >>>>>>> >>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>> ------------------------------------------- >>>>>>> Sequential|1 GB x | >>>>>>> Read |9 loops | 193.60 >>>>>>> | | 195.86 >>>>>>> | | 184.77 >>>>>>> | | 193.60 >>>>>>> ------------------------------------------- >>>>>>> >>>>>>> TXFIFO Depth = 6 max packets >>>>>>> >>>>>>> Test Case | Data Size | AVG tput (in MB/s) >>>>>>> ------------------------------------------- >>>>>>> Sequential|1 GB x | >>>>>>> Read |9 loops | 287.35 >>>>>>> | | 304.94 >>>>>>> | | 289.64 >>>>>>> | | 293.61 >>>>>>> ------------------------------------------- >>>>>>> >>>>>>> Wesley Cheng (6): >>>>>>> usb: gadget: udc: core: Introduce check_config to verify USB >>>>>>> configuration >>>>>>> usb: gadget: configfs: Check USB configuration before adding >>>>>>> usb: dwc3: Resize TX FIFOs to meet EP bursting requirements >>>>>>> of: Add stub for of_add_property() >>>>>>> usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default >>>>>>> dt-bindings: usb: dwc3: Update dwc3 TX fifo properties >>>>>>> >>>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- >>>>>>> drivers/usb/dwc3/core.c | 9 + >>>>>>> drivers/usb/dwc3/core.h | 15 ++ >>>>>>> drivers/usb/dwc3/dwc3-qcom.c | 9 + >>>>>>> drivers/usb/dwc3/ep0.c | 2 + >>>>>>> drivers/usb/dwc3/gadget.c | 212 >>>>>>> +++++++++++++++++++++ >>>>>>> drivers/usb/gadget/configfs.c | 22 +++ >>>>>>> drivers/usb/gadget/udc/core.c | 25 +++ >>>>>>> include/linux/of.h | 5 + >>>>>>> include/linux/usb/gadget.h | 5 + >>>>>>> 10 files changed, 317 insertions(+), 2 deletions(-) >>>>>>> >
Hi, Ferry Toth <fntoth@gmail.com> writes: >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>> depth:115540359 >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >>> >>> Removing uac2 from the config makes the call trace go away, but the R/W >>> speed does not change. > > I am testing with 5.14.0-rc2 and now related error appears (not in rc1). > Disabling uac2 solves it still. Any idea what it could be? > > BUG: unable to handle page fault for address: 0000000500000000 > #PF: supervisor instruction fetch in kernel mode > #PF: error_code(0x0010) - not-present page > PGD 0 P4D 0 > Oops: 0010 [#1] SMP PTI > CPU: 0 PID: 494 Comm: irq/14-dwc3 Not tainted > 5.14.0-rc2-edison-acpi-standard #1 (cool that you're running on ACPI heh) > Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 > 2015.01.21:18.19.48 > RIP: 0010:0x500000000 > Code: Unable to access opcode bytes at RIP 0x4ffffffd6. > RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 > RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 > RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 > R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 > R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 > FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 > Call Trace: > ? dwc3_remove_requests.constprop.0+0x14d/0x170 > ? __dwc3_gadget_ep_disable+0x7a/0x160 > ? dwc3_gadget_ep_disable+0x3d/0xd0 > ? usb_ep_disable+0x1c/0x70 > ? u_audio_stop_capture+0x79/0x120 [u_audio] > ? afunc_set_alt+0x73/0x80 [usb_f_uac2] > ? composite_setup+0x224/0x1b90 [libcomposite] > ? __dwc3_gadget_kick_transfer+0x160/0x400 > ? dwc3_gadget_ep_queue+0xf3/0x1a0 > ? configfs_composite_setup+0x6b/0x90 [libcomposite] > ? configfs_composite_setup+0x6b/0x90 [libcomposite] > ? dwc3_ep0_interrupt+0x459/0xa40 > ? dwc3_thread_interrupt+0x8ee/0xf40 > ? __schedule+0x235/0x6c0 > ? disable_irq_nosync+0x10/0x10 > ? irq_thread_fn+0x1b/0x60 > ? irq_thread+0xc0/0x160 > ? irq_thread_check_affinity+0x70/0x70 > ? irq_forced_thread_fn+0x70/0x70 > ? kthread+0x122/0x140 > ? set_kthread_struct+0x40/0x40 > ? ret_from_fork+0x22/0x30 Do you mind enabling dwc3 traces and collecting them? Trying to figure out how we got here.
Ferry Toth <fntoth@gmail.com> writes: > Hi > > Op 23-07-2021 om 08:59 schreef Felipe Balbi: >> Hi, >> >> Ferry Toth <fntoth@gmail.com> writes: >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>> depth:115540359 >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >>>>> >>>>> Removing uac2 from the config makes the call trace go away, but the R/W >>>>> speed does not change. >>> I am testing with 5.14.0-rc2 and now related error appears (not in rc1). >>> Disabling uac2 solves it still. Any idea what it could be? >>> >>> BUG: unable to handle page fault for address: 0000000500000000 >>> #PF: supervisor instruction fetch in kernel mode >>> #PF: error_code(0x0010) - not-present page >>> PGD 0 P4D 0 >>> Oops: 0010 [#1] SMP PTI >>> CPU: 0 PID: 494 Comm: irq/14-dwc3 Not tainted >>> 5.14.0-rc2-edison-acpi-standard #1 >> (cool that you're running on ACPI heh) > Thanks to Andy this is Edison-Arduino board with ACPI. >>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>> 2015.01.21:18.19.48 >>> RIP: 0010:0x500000000 >>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>> Call Trace: >>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>> ? usb_ep_disable+0x1c/0x >>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>> ? composite_setup+0x224/0x1b90 [libcomposite] >>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>> ? dwc3_ep0_interrupt+0x459/0xa40 >>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>> ? __schedule+0x235/0x6c0 >>> ? disable_irq_nosync+0x10/0x10 >>> ? irq_thread_fn+0x1b/0x60 >>> ? irq_thread+0xc0/0x160 >>> ? irq_thread_check_affinity+0x70/0x70 >>> ? irq_forced_thread_fn+0x70/0x70 >>> ? kthread+0x122/0x140 >>> ? set_kthread_struct+0x40/0x40 >>> ? ret_from_fork+0x22/0x30 >> Do you mind enabling dwc3 traces and collecting them? Trying to figure >> out how we got here. >> > I'll try if I can get the same error by booting with USB in host mode > and then switch to device mode. If so I can enable traces and collect as > you explained me before. > > I'll try before monday, as then I fly for a holiday and will not be > available before rc5. you can enable all of those with kernel cmdline :-) https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html you need ftrace_dump_on_oops=1 and also need the correct options on trace_buf_size and trace_event.
Hi, Op 23-07-2021 om 13:23 schreef Felipe Balbi: > Ferry Toth <fntoth@gmail.com> writes: > >> Hi >> >> Op 23-07-2021 om 08:59 schreef Felipe Balbi: >>> Hi, >>> >>> Ferry Toth <fntoth@gmail.com> writes: >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in >>>>>> kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in >>>>>> depth:115540359 >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: configfs-gadget gadget: u_audio_start_playback:451 Error! >>>>>> kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in >>>>>> kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in >>>>>> >>>>>> Removing uac2 from the config makes the call trace go away, but the R/W >>>>>> speed does not change. >>>> I am testing with 5.14.0-rc2 and now related error appears (not in rc1). >>>> Disabling uac2 solves it still. Any idea what it could be? >>>> >>>> BUG: unable to handle page fault for address: 0000000500000000 >>>> #PF: supervisor instruction fetch in kernel mode >>>> #PF: error_code(0x0010) - not-present page >>>> PGD 0 P4D 0 >>>> Oops: 0010 [#1] SMP PTI >>>> CPU: 0 PID: 494 Comm: irq/14-dwc3 Not tainted >>>> 5.14.0-rc2-edison-acpi-standard #1 >>> (cool that you're running on ACPI heh) >> Thanks to Andy this is Edison-Arduino board with ACPI. >>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>> 2015.01.21:18.19.48 >>>> RIP: 0010:0x500000000 >>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>> Call Trace: >>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>> ? usb_ep_disable+0x1c/0x >>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>> ? __schedule+0x235/0x6c0 >>>> ? disable_irq_nosync+0x10/0x10 >>>> ? irq_thread_fn+0x1b/0x60 >>>> ? irq_thread+0xc0/0x160 >>>> ? irq_thread_check_affinity+0x70/0x70 >>>> ? irq_forced_thread_fn+0x70/0x70 >>>> ? kthread+0x122/0x140 >>>> ? set_kthread_struct+0x40/0x40 >>>> ? ret_from_fork+0x22/0x30 >>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>> out how we got here. >>> >> I'll try if I can get the same error by booting with USB in host mode >> and then switch to device mode. If so I can enable traces and collect as >> you explained me before. >> >> I'll try before monday, as then I fly for a holiday and will not be >> available before rc5. > you can enable all of those with kernel cmdline :-) > > https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html > > you need ftrace_dump_on_oops=1 and also need the correct options on > trace_buf_size and trace_event. > On Edison-Arduino I have a switch to go to device mode, after which udev triggers a script configure gadgets through configfs. I tried to log following these instructions: https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> Unfortunately the kernel crashes so badly I can not get to the ` cp /t/trace /root/trace.txt` line (after a while the watchdog kicks). What to do next? BTW there is a secondary problem not related to dwc3: the console is not working well and loosing chars. I can connect through wifi/ssh though.
On Sat, Jul 24, 2021 at 11:59 PM Ferry Toth <fntoth@gmail.com> wrote: > BTW there is a secondary problem not related to dwc3: the console is not > working well and loosing chars. I can connect through wifi/ssh though. You mean even on the kernel before any crash happened due to DWC3 stuff?
Hi Op 24-07-2021 om 23:19 schreef Andy Shevchenko: > On Sat, Jul 24, 2021 at 11:59 PM Ferry Toth<fntoth@gmail.com> wrote: > >> BTW there is a secondary problem not related to dwc3: the console is not >> working well and loosing chars. I can connect through wifi/ssh though. > You mean even on the kernel before any crash happened due to DWC3 stuff? Exactly. And this was working fine with rc1. I do have patches (as you know) for improving dma for the hsu. But, for the console afaik dma is disabled.
Hi, Ferry Toth <fntoth@gmail.com> writes: >>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>> 2015.01.21:18.19.48 >>>>> RIP: 0010:0x500000000 >>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>> Call Trace: >>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>> ? usb_ep_disable+0x1c/0x >>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>> ? __schedule+0x235/0x6c0 >>>>> ? disable_irq_nosync+0x10/0x10 >>>>> ? irq_thread_fn+0x1b/0x60 >>>>> ? irq_thread+0xc0/0x160 >>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>> ? kthread+0x122/0x140 >>>>> ? set_kthread_struct+0x40/0x40 >>>>> ? ret_from_fork+0x22/0x30 >>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>> out how we got here. >>>> >>> I'll try if I can get the same error by booting with USB in host mode >>> and then switch to device mode. If so I can enable traces and collect as >>> you explained me before. >>> >>> I'll try before monday, as then I fly for a holiday and will not be >>> available before rc5. >> you can enable all of those with kernel cmdline :-) >> >> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >> >> you need ftrace_dump_on_oops=1 and also need the correct options on >> trace_buf_size and trace_event. >> > On Edison-Arduino I have a switch to go to device mode, after which > udev triggers a script configure gadgets through configfs. > > I tried to log following these instructions: > > https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> > > Unfortunately the kernel crashes so badly I can not get to the ` cp > /t/trace /root/trace.txt` line (after a while the watchdog kicks). > > What to do next? Pass ftrace_dump_on_oops to kernel cmdline.
Hi Op 25-07-2021 om 08:05 schreef Felipe Balbi: > Hi, > > Ferry Toth <fntoth@gmail.com> writes: >>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>> 2015.01.21:18.19.48 >>>>>> RIP: 0010:0x500000000 >>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>> Call Trace: >>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>> ? usb_ep_disable+0x1c/0x >>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>> ? __schedule+0x235/0x6c0 >>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>> ? irq_thread+0xc0/0x160 >>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>> ? kthread+0x122/0x140 >>>>>> ? set_kthread_struct+0x40/0x40 >>>>>> ? ret_from_fork+0x22/0x30 >>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>> out how we got here. >>>>> >>>> I'll try if I can get the same error by booting with USB in host mode >>>> and then switch to device mode. If so I can enable traces and collect as >>>> you explained me before. >>>> >>>> I'll try before monday, as then I fly for a holiday and will not be >>>> available before rc5. >>> you can enable all of those with kernel cmdline :-) >>> >>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>> >>> you need ftrace_dump_on_oops=1 and also need the correct options on >>> trace_buf_size and trace_event. >>> >> On Edison-Arduino I have a switch to go to device mode, after which >> udev triggers a script configure gadgets through configfs. >> >> I tried to log following these instructions: >> >> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >> >> Unfortunately the kernel crashes so badly I can not get to the ` cp >> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >> >> What to do next? > Pass ftrace_dump_on_oops to kernel cmdline. > No sure if I did this right, on oops everything is pushed to console (115k2 serial), I hope nothing essential is lost. I copied the screen buffer to file see attached.
Hi, Ferry Toth <fntoth@gmail.com> writes: > Hi > > Op 25-07-2021 om 08:05 schreef Felipe Balbi: >> Hi, >> >> Ferry Toth <fntoth@gmail.com> writes: >>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>> 2015.01.21:18.19.48 >>>>>>> RIP: 0010:0x500000000 >>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>> Call Trace: >>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] So this is triggered by a SetInterface request... >>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>> ? __schedule+0x235/0x6c0 >>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>> ? irq_thread+0xc0/0x160 >>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>> ? kthread+0x122/0x140 >>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>> ? ret_from_fork+0x22/0x30 >>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>> out how we got here. >>>>>> >>>>> I'll try if I can get the same error by booting with USB in host mode >>>>> and then switch to device mode. If so I can enable traces and collect as >>>>> you explained me before. >>>>> >>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>> available before rc5. >>>> you can enable all of those with kernel cmdline :-) >>>> >>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>> >>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>> trace_buf_size and trace_event. >>>> >>> On Edison-Arduino I have a switch to go to device mode, after which >>> udev triggers a script configure gadgets through configfs. >>> >>> I tried to log following these instructions: >>> >>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>> >>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>> >>> What to do next? >> Pass ftrace_dump_on_oops to kernel cmdline. >> > No sure if I did this right, on oops everything is pushed to console > (115k2 serial), I hope nothing essential is lost. > > I copied the screen buffer to file see attached. Thank you, I bet it took quite a some time :-) Anyway, looking at the logs around Set Interface requests, we can track every endpoint that's disabled. I'll take a guess and assume we're failing at the last Set Interface, that means we should have something odd with ep6in, but everything looks fine in the trace output: [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful Do you mind adding a few prints in dwc3_remove_requests to tell us which endpoint is being processed? Then we'll know for sure which one caused the crash.
Hi Op 25-07-2021 om 16:05 schreef Felipe Balbi: > Hi, > > Ferry Toth <fntoth@gmail.com> writes: > >> Hi >> >> Op 25-07-2021 om 08:05 schreef Felipe Balbi: >>> Hi, >>> >>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>> 2015.01.21:18.19.48 >>>>>>>> RIP: 0010:0x500000000 >>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>> Call Trace: >>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] > So this is triggered by a SetInterface request... > >>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>> ? kthread+0x122/0x140 >>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>> out how we got here. >>>>>>> >>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>> you explained me before. >>>>>> >>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>> available before rc5. >>>>> you can enable all of those with kernel cmdline :-) >>>>> >>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>> >>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>> trace_buf_size and trace_event. >>>>> >>>> On Edison-Arduino I have a switch to go to device mode, after which >>>> udev triggers a script configure gadgets through configfs. >>>> >>>> I tried to log following these instructions: >>>> >>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>> >>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>> >>>> What to do next? >>> Pass ftrace_dump_on_oops to kernel cmdline. >>> >> No sure if I did this right, on oops everything is pushed to console >> (115k2 serial), I hope nothing essential is lost. >> >> I copied the screen buffer to file see attached. > Thank you, I bet it took quite a some time :-) Anyway, looking at > the logs around Set Interface requests, we can track every endpoint > that's disabled. I'll take a guess and assume we're failing at the last > Set Interface, that means we should have something odd with ep6in, but > everything looks fine in the trace output: > > [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< > [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 > [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 > [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 > [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 > [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] > [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) > [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful > [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] > [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) > [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 > [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) > [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful > [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 > [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) > [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful > [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] > [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) > [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 > [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 > [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 > [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 > [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 > [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 > [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< > [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] > [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) > [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful > [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] > [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) > [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 > [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) > [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful > [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] > [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) > [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) > [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful > [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] > [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] > [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] > [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) > [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 > [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] > [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) > [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful > > Do you mind adding a few prints in dwc3_remove_requests to tell us which > endpoint is being processed? Then we'll know for sure which one caused > the crash. > I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. But as I am using configfs (excerpt follows) and just disabling the last 2 line resolves the issue, I'm guessing uac2 is the issue. Or exceeding the available resources. # Create directory structure mkdir "${GADGET_BASE_DIR}" cd "${GADGET_BASE_DIR}" mkdir -p configs/c.1/strings/0x409 mkdir -p strings/0x409 # Serial device mkdir functions/gser.usb0 ln -s functions/gser.usb0 configs/c.1/ ### # Ethernet device mkdir functions/eem.usb0 echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr ln -s functions/eem.usb0 configs/c.1/ # Mass Storage device mkdir functions/mass_storage.usb0 echo 1 > functions/mass_storage.usb0/stall echo 0 > functions/mass_storage.usb0/lun.0/cdrom echo 0 > functions/mass_storage.usb0/lun.0/ro echo 0 > functions/mass_storage.usb0/lun.0/nofua echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file ln -s functions/mass_storage.usb0 configs/c.1/ # UAC2 device mkdir functions/uac2.usb0 ln -s functions/uac2.usb0 configs/c.1
Hi, Ferry Toth <fntoth@gmail.com> writes: >>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>>> Call Trace: >>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >> So this is triggered by a SetInterface request... >> >>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>>> out how we got here. >>>>>>>> >>>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>>> you explained me before. >>>>>>> >>>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>>> available before rc5. >>>>>> you can enable all of those with kernel cmdline :-) >>>>>> >>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>> >>>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>>> trace_buf_size and trace_event. >>>>>> >>>>> On Edison-Arduino I have a switch to go to device mode, after which >>>>> udev triggers a script configure gadgets through configfs. >>>>> >>>>> I tried to log following these instructions: >>>>> >>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>> >>>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>>> >>>>> What to do next? >>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>> >>> No sure if I did this right, on oops everything is pushed to console >>> (115k2 serial), I hope nothing essential is lost. >>> >>> I copied the screen buffer to file see attached. >> Thank you, I bet it took quite a some time :-) Anyway, looking at >> the logs around Set Interface requests, we can track every endpoint >> that's disabled. I'll take a guess and assume we're failing at the last >> Set Interface, that means we should have something odd with ep6in, but >> everything looks fine in the trace output: >> >> [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >> [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >> [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >> [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >> [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >> [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >> [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >> [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >> [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >> [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >> [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >> [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >> [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >> [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful >> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >> [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >> [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >> [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >> [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >> [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >> [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >> [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >> [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >> [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >> [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >> [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >> [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >> [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >> [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >> [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >> [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >> [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] >> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] >> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >> [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >> [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 >> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] >> [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >> [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >> >> Do you mind adding a few prints in dwc3_remove_requests to tell us which >> endpoint is being processed? Then we'll know for sure which one caused >> the crash. >> > I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. not a problem, we'll still be here when you're back :-) > But as I am using configfs (excerpt follows) and just disabling the > last 2 line resolves the issue, I'm guessing uac2 is the issue. Or > exceeding the available resources. > > # Create directory structure > mkdir "${GADGET_BASE_DIR}" > cd "${GADGET_BASE_DIR}" > mkdir -p configs/c.1/strings/0x409 > mkdir -p strings/0x409 > > # Serial device > mkdir functions/gser.usb0 > ln -s functions/gser.usb0 configs/c.1/ > ### > > # Ethernet device > mkdir functions/eem.usb0 > echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr > echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr > ln -s functions/eem.usb0 configs/c.1/ > > # Mass Storage device > mkdir functions/mass_storage.usb0 > echo 1 > functions/mass_storage.usb0/stall > echo 0 > functions/mass_storage.usb0/lun.0/cdrom > echo 0 > functions/mass_storage.usb0/lun.0/ro > echo 0 > functions/mass_storage.usb0/lun.0/nofua > echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file > ln -s functions/mass_storage.usb0 configs/c.1/ > > # UAC2 device > mkdir functions/uac2.usb0 > ln -s functions/uac2.usb0 configs/c.1 Right, either there's an actual bug in uac2, or we're running out of FIFO space.
Hi Ferry, On 7/25/2021 10:57 PM, Felipe Balbi wrote: > > Hi, > > Ferry Toth <fntoth@gmail.com> writes: >>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>>>> Call Trace: >>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>> So this is triggered by a SetInterface request... >>> >>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>>>> out how we got here. >>>>>>>>> >>>>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>>>> you explained me before. >>>>>>>> >>>>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>>>> available before rc5. >>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>> >>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>> >>>>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>>>> trace_buf_size and trace_event. >>>>>>> >>>>>> On Edison-Arduino I have a switch to go to device mode, after which >>>>>> udev triggers a script configure gadgets through configfs. >>>>>> >>>>>> I tried to log following these instructions: >>>>>> >>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>> >>>>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>>>> >>>>>> What to do next? >>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>> >>>> No sure if I did this right, on oops everything is pushed to console >>>> (115k2 serial), I hope nothing essential is lost. >>>> >>>> I copied the screen buffer to file see attached. >>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>> the logs around Set Interface requests, we can track every endpoint >>> that's disabled. I'll take a guess and assume we're failing at the last >>> Set Interface, that means we should have something odd with ep6in, but >>> everything looks fine in the trace output: >>> >>> [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>> [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>> [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>> [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>> [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>> [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>> [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>> [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>> [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>> [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>> [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>> [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>> [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful >>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>> [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>> [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>> [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>> [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>> [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>> [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>> [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>> [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>> [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>> [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>> [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>> [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>> [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>> [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>> [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>> [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>> [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] >>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] >>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>> [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>> [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 >>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] >>> [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>> [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> >>> Do you mind adding a few prints in dwc3_remove_requests to tell us which >>> endpoint is being processed? Then we'll know for sure which one caused >>> the crash. >>> >> I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. > > not a problem, we'll still be here when you're back :-) > >> But as I am using configfs (excerpt follows) and just disabling the >> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >> exceeding the available resources. >> >> # Create directory structure >> mkdir "${GADGET_BASE_DIR}" >> cd "${GADGET_BASE_DIR}" >> mkdir -p configs/c.1/strings/0x409 >> mkdir -p strings/0x409 >> >> # Serial device >> mkdir functions/gser.usb0 >> ln -s functions/gser.usb0 configs/c.1/ >> ### >> >> # Ethernet device >> mkdir functions/eem.usb0 >> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >> ln -s functions/eem.usb0 configs/c.1/ >> >> # Mass Storage device >> mkdir functions/mass_storage.usb0 >> echo 1 > functions/mass_storage.usb0/stall >> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >> echo 0 > functions/mass_storage.usb0/lun.0/ro >> echo 0 > functions/mass_storage.usb0/lun.0/nofua >> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >> ln -s functions/mass_storage.usb0 configs/c.1/ >> >> # UAC2 device >> mkdir functions/uac2.usb0 >> ln -s functions/uac2.usb0 configs/c.1 > > Right, either there's an actual bug in uac2, or we're running out of > FIFO space. > Are you enabling the TXFIFO flag here again? If we suspect that we're running out of FIFO space, then: - First, making sure we're explicitly enabling the TXFIFO resize flag. - Second, we should see the same warning we saw previously: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in depth:115540359 Thanks Wesley Cheng
Hi Op 26-07-2021 om 16:33 schreef Wesley Cheng: > Hi Ferry, > > On 7/25/2021 10:57 PM, Felipe Balbi wrote: >> >> Hi, >> >> Ferry Toth <fntoth@gmail.com> writes: >>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>>>>> Call Trace: >>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>> So this is triggered by a SetInterface request... >>>> >>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>>>>> out how we got here. >>>>>>>>>> >>>>>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>>>>> you explained me before. >>>>>>>>> >>>>>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>>>>> available before rc5. >>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>> >>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>> >>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>>>>> trace_buf_size and trace_event. >>>>>>>> >>>>>>> On Edison-Arduino I have a switch to go to device mode, after which >>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>> >>>>>>> I tried to log following these instructions: >>>>>>> >>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>> >>>>>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>>>>> >>>>>>> What to do next? >>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>> >>>>> No sure if I did this right, on oops everything is pushed to console >>>>> (115k2 serial), I hope nothing essential is lost. >>>>> >>>>> I copied the screen buffer to file see attached. >>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>> the logs around Set Interface requests, we can track every endpoint >>>> that's disabled. I'll take a guess and assume we're failing at the last >>>> Set Interface, that means we should have something odd with ep6in, but >>>> everything looks fine in the trace output: >>>> >>>> [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>>> [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>>> [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>> [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>>> [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>>> [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>> [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>> [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>> [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>>> [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>> [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>>> [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>> [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful >>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>> [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>> [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>> [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>>> [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>>> [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>> [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>>> [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>>> [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>>> [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>> [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>> [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>> [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>>> [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>> [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>> [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>> [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>> [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] >>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] >>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>>> [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>> [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 >>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] >>>> [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>> [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> >>>> Do you mind adding a few prints in dwc3_remove_requests to tell us which >>>> endpoint is being processed? Then we'll know for sure which one caused >>>> the crash. >>>> >>> I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. >> >> not a problem, we'll still be here when you're back :-) >> >>> But as I am using configfs (excerpt follows) and just disabling the >>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>> exceeding the available resources. >>> >>> # Create directory structure >>> mkdir "${GADGET_BASE_DIR}" >>> cd "${GADGET_BASE_DIR}" >>> mkdir -p configs/c.1/strings/0x409 >>> mkdir -p strings/0x409 >>> >>> # Serial device >>> mkdir functions/gser.usb0 >>> ln -s functions/gser.usb0 configs/c.1/ >>> ### >>> >>> # Ethernet device >>> mkdir functions/eem.usb0 >>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>> ln -s functions/eem.usb0 configs/c.1/ >>> >>> # Mass Storage device >>> mkdir functions/mass_storage.usb0 >>> echo 1 > functions/mass_storage.usb0/stall >>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>> ln -s functions/mass_storage.usb0 configs/c.1/ >>> >>> # UAC2 device >>> mkdir functions/uac2.usb0 >>> ln -s functions/uac2.usb0 configs/c.1 >> >> Right, either there's an actual bug in uac2, or we're running out of >> FIFO space. >> > > Are you enabling the TXFIFO flag here again? If we suspect that we're > running out of FIFO space, then: > - First, making sure we're explicitly enabling the TXFIFO resize flag. > - Second, we should see the same warning we saw previously: > dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in > depth:115540359 No, I'm building using a Yocto recipe: https://github.com/htot/meta-intel-edison/blob/gatesgarth/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_5.14-rc2.bb patches are line #64 and on, just one old dwc3 related (edison) patch. > > Thanks > Wesley Cheng >
Hi, Op 26-07-2021 om 07:57 schreef Felipe Balbi: > Hi, > > Ferry Toth <fntoth@gmail.com> writes: >>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>>>> Call Trace: >>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>> So this is triggered by a SetInterface request... >>> >>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>>>> out how we got here. >>>>>>>>> >>>>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>>>> you explained me before. >>>>>>>> >>>>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>>>> available before rc5. >>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>> >>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>> >>>>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>>>> trace_buf_size and trace_event. >>>>>>> >>>>>> On Edison-Arduino I have a switch to go to device mode, after which >>>>>> udev triggers a script configure gadgets through configfs. >>>>>> >>>>>> I tried to log following these instructions: >>>>>> >>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>> >>>>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>>>> >>>>>> What to do next? >>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>> >>>> No sure if I did this right, on oops everything is pushed to console >>>> (115k2 serial), I hope nothing essential is lost. >>>> >>>> I copied the screen buffer to file see attached. >>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>> the logs around Set Interface requests, we can track every endpoint >>> that's disabled. I'll take a guess and assume we're failing at the last >>> Set Interface, that means we should have something odd with ep6in, but >>> everything looks fine in the trace output: >>> >>> [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>> [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>> [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>> [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>> [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>> [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>> [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>> [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>> [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>> [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>> [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>> [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>> [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful >>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>> [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>> [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>> [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>> [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>> [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>> [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>> [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>> [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>> [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>> [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>> [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>> [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>> [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>> [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>> [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>> [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>> [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] >>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] >>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>> [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>> [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 >>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] >>> [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>> [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>> >>> Do you mind adding a few prints in dwc3_remove_requests to tell us which >>> endpoint is being processed? Then we'll know for sure which one caused >>> the crash. >>> >> I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. > not a problem, we'll still be here when you're back :-) Well, let's go then :-) To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 and 5.14.0-rc5. I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. With 5.14.0-rc5 the problem seems worse (or different?), and just disabling uac2 gadget does not prevent the crash. Even disabling gser and mass_storage.usb0 as well there is still a crash. Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)? >> But as I am using configfs (excerpt follows) and just disabling the >> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >> exceeding the available resources. >> >> # Create directory structure >> mkdir "${GADGET_BASE_DIR}" >> cd "${GADGET_BASE_DIR}" >> mkdir -p configs/c.1/strings/0x409 >> mkdir -p strings/0x409 >> >> # Serial device >> mkdir functions/gser.usb0 >> ln -s functions/gser.usb0 configs/c.1/ >> ### >> >> # Ethernet device >> mkdir functions/eem.usb0 >> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >> ln -s functions/eem.usb0 configs/c.1/ >> >> # Mass Storage device >> mkdir functions/mass_storage.usb0 >> echo 1 > functions/mass_storage.usb0/stall >> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >> echo 0 > functions/mass_storage.usb0/lun.0/ro >> echo 0 > functions/mass_storage.usb0/lun.0/nofua >> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >> ln -s functions/mass_storage.usb0 configs/c.1/ >> >> # UAC2 device >> mkdir functions/uac2.usb0 >> ln -s functions/uac2.usb0 configs/c.1 > Right, either there's an actual bug in uac2, or we're running out of > FIFO space. >
Hi, Ferry Toth <fntoth@gmail.com> writes: >> Ferry Toth <fntoth@gmail.com> writes: >>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>>>>> Call Trace: >>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>> So this is triggered by a SetInterface request... >>>> >>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>>>>> out how we got here. >>>>>>>>>> >>>>>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>>>>> you explained me before. >>>>>>>>> >>>>>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>>>>> available before rc5. >>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>> >>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>> >>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>>>>> trace_buf_size and trace_event. >>>>>>>> >>>>>>> On Edison-Arduino I have a switch to go to device mode, after which >>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>> >>>>>>> I tried to log following these instructions: >>>>>>> >>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>> >>>>>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>>>>> >>>>>>> What to do next? >>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>> >>>>> No sure if I did this right, on oops everything is pushed to console >>>>> (115k2 serial), I hope nothing essential is lost. >>>>> >>>>> I copied the screen buffer to file see attached. >>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>> the logs around Set Interface requests, we can track every endpoint >>>> that's disabled. I'll take a guess and assume we're failing at the last >>>> Set Interface, that means we should have something odd with ep6in, but >>>> everything looks fine in the trace output: >>>> >>>> [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>>> [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>>> [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>> [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>>> [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>>> [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>> [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>> [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>> [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>>> [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>> [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>>> [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>> [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful >>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>> [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>> [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>> [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>>> [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>>> [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>> [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>>> [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>>> [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>>> [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>> [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>> [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>> [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>>> [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>> [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>> [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>> [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>> [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] >>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] >>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>>> [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>> [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 >>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] >>>> [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>> [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>> >>>> Do you mind adding a few prints in dwc3_remove_requests to tell us which >>>> endpoint is being processed? Then we'll know for sure which one caused >>>> the crash. >>>> >>> I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. >> not a problem, we'll still be here when you're back :-) > > Well, let's go then :-) > > To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 > and 5.14.0-rc5. > > I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. That's great finding. We have a bisection point. There are a total of 13764 commits between v5.13 and v5.14-rc1 $ git rev-list --count v5.13..v5.14-rc1 13764 git bisect should find the offending commit in at most 14 tries. That's not too bad. > With 5.14.0-rc5 the problem seems worse (or different?), and just > disabling uac2 gadget does not prevent the crash. Even disabling gser > and mass_storage.usb0 as well there is still a crash. > > Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)? I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending commit, verify if reverting that on -rc1 works, then verify if reverting on -rc5 also works :-)
Hi, Op 16-08-2021 om 07:18 schreef Felipe Balbi: > Hi, > > Ferry Toth <fntoth@gmail.com> writes: >>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 >>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: 0000000000000000 >>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: ffff8cd546aed200 >>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: 0000000000000001 >>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: ffff8cd547342828 >>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: ffff8cd548b1d000 >>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) knlGS:0000000000000000 >>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: 00000000001006f0 >>>>>>>>>>>> Call Trace: >>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>> So this is triggered by a SetInterface request... >>>>> >>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? Trying to figure >>>>>>>>>>> out how we got here. >>>>>>>>>>> >>>>>>>>>> I'll try if I can get the same error by booting with USB in host mode >>>>>>>>>> and then switch to device mode. If so I can enable traces and collect as >>>>>>>>>> you explained me before. >>>>>>>>>> >>>>>>>>>> I'll try before monday, as then I fly for a holiday and will not be >>>>>>>>>> available before rc5. >>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>> >>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>> >>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct options on >>>>>>>>> trace_buf_size and trace_event. >>>>>>>>> >>>>>>>> On Edison-Arduino I have a switch to go to device mode, after which >>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>> >>>>>>>> I tried to log following these instructions: >>>>>>>> >>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>> >>>>>>>> Unfortunately the kernel crashes so badly I can not get to the ` cp >>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog kicks). >>>>>>>> >>>>>>>> What to do next? >>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>> >>>>>> No sure if I did this right, on oops everything is pushed to console >>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>> >>>>>> I copied the screen buffer to file see attached. >>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>> the logs around Set Interface requests, we can track every endpoint >>>>> that's disabled. I'll take a guess and assume we're failing at the last >>>>> Set Interface, that means we should have something odd with ep6in, but >>>>> everything looks fine in the trace output: >>>>> >>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>>> [ 76.297418] kworker/-23 0d... 42789670us : dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>>>> [ 76.308278] kworker/-23 0d... 42789695us : dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>> [ 76.395294] kworker/-23 0d... 42789707us : dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params 00000000 00000000 00000000 --> status: Successful >>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI ==> -104 >>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -104 >>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 ring 0/0 flags E:swbp:< >>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) [Status Phase] >>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI ==> 0 >>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) [Data Phase] >>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data Phase] >>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 ZsI ==> 0 >>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) [Status Phase] >>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 1bded000 00000000 --> status: Successful >>>>> >>>>> Do you mind adding a few prints in dwc3_remove_requests to tell us which >>>>> endpoint is being processed? Then we'll know for sure which one caused >>>>> the crash. >>>>> >>>> I wouldn't mind but am leaving on a holiday, won't have time until 6 aug. >>> not a problem, we'll still be here when you're back :-) >> Well, let's go then :-) >> >> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 >> and 5.14.0-rc5. >> >> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. > That's great finding. We have a bisection point. There are a total of > 13764 commits between v5.13 and v5.14-rc1 > > $ git rev-list --count v5.13..v5.14-rc1 > 13764 > > git bisect should find the offending commit in at most 14 tries. That's > not too bad. I correctly guesstimated that the problem got introduced by the usb merge 79160a60 "Merge tag 'usb-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" 116 commits(7 bisects). 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit "usb: gadget: f_uac2/u_audio: add feedback endpoint support" Ruslan's 3 patches are related to each other so I reverted all three 24f779da...e89bb428 and applied the reverts to rc1. I can confirm this indeed resolves the problem in rc1. Is late now, tomorrow evening I will apply the reverts to rc6. >> With 5.14.0-rc5 the problem seems worse (or different?), and just >> disabling uac2 gadget does not prevent the crash. Even disabling gser >> and mass_storage.usb0 as well there is still a crash. >> >> Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)? > I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending > commit, verify if reverting that on -rc1 works, then verify if reverting > on -rc5 also works :-) >
Hi, Op 18-08-2021 om 00:00 schreef Ferry Toth: > Hi, > > Op 16-08-2021 om 07:18 schreef Felipe Balbi: >> Hi, >> >> Ferry Toth <fntoth@gmail.com> writes: >>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>> So this is triggered by a SetInterface request... >>>>>> >>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>> Trying to figure >>>>>>>>>>>> out how we got here. >>>>>>>>>>>> >>>>>>>>>>> I'll try if I can get the same error by booting with USB in >>>>>>>>>>> host mode >>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>> and collect as >>>>>>>>>>> you explained me before. >>>>>>>>>>> >>>>>>>>>>> I'll try before monday, as then I fly for a holiday and will >>>>>>>>>>> not be >>>>>>>>>>> available before rc5. >>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>> >>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>> options on >>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>> >>>>>>>>> On Edison-Arduino I have a switch to go to device mode, after >>>>>>>>> which >>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>> >>>>>>>>> I tried to log following these instructions: >>>>>>>>> >>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs >>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>>> >>>>>>>>> >>>>>>>>> Unfortunately the kernel crashes so badly I can not get to the >>>>>>>>> ` cp >>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>> kicks). >>>>>>>>> >>>>>>>>> What to do next? >>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>> >>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>> console >>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>> >>>>>>> I copied the screen buffer to file see attached. >>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>> the logs around Set Interface requests, we can track every endpoint >>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>> the last >>>>>> Set Interface, that means we should have something odd with >>>>>> ep6in, but >>>>>> everything looks fine in the trace output: >>>>>> >>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring >>>>>> 0/0 flags E:swbp:< >>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: >>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>> [Status Phase] >>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: >>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI >>>>>> ==> 0 >>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params >>>>>> 00000000 00000000 00000000 --> status: Successful >>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: >>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> >>>>>> -115 >>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>> zsI ==> -104 >>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>> ==> -104 >>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> >>>>>> -115 >>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>> zsI ==> -104 >>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>> ==> -104 >>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>> ring 0/0 flags E:swbp:< >>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: >>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>> [Status Phase] >>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: >>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI >>>>>> ==> 0 >>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: >>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: >>>>>> event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>> [Data Phase] >>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: >>>>>> event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data >>>>>> Phase] >>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: >>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 >>>>>> ZsI ==> 0 >>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: >>>>>> event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) >>>>>> [Status Phase] >>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>> >>>>>> Do you mind adding a few prints in dwc3_remove_requests to tell >>>>>> us which >>>>>> endpoint is being processed? Then we'll know for sure which one >>>>>> caused >>>>>> the crash. >>>>>> >>>>> I wouldn't mind but am leaving on a holiday, won't have time until >>>>> 6 aug. >>>> not a problem, we'll still be here when you're back :-) >>> Well, let's go then :-) >>> >>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 >>> and 5.14.0-rc5. >>> >>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >> That's great finding. We have a bisection point. There are a total of >> 13764 commits between v5.13 and v5.14-rc1 >> >> $ git rev-list --count v5.13..v5.14-rc1 >> 13764 >> >> git bisect should find the offending commit in at most 14 tries. That's >> not too bad. > I correctly guesstimated that the problem got introduced by the usb > merge 79160a60 > > "Merge tag 'usb-5.14-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" > > 116 commits(7 bisects). > > 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit > > "usb: gadget: f_uac2/u_audio: add feedback endpoint support" > > Ruslan's 3 patches are related to each other so I reverted all three > 24f779da...e89bb428 and applied the reverts to rc1. > > I can confirm this indeed resolves the problem in rc1. > > Is late now, tomorrow evening I will apply the reverts to rc6. With these reverts rc6 works fine as well. So, where do we go from here? > >>> With 5.14.0-rc5 the problem seems worse (or different?), and just >>> disabling uac2 gadget does not prevent the crash. Even disabling gser >>> and mass_storage.usb0 as well there is still a crash. >>> >>> Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)? >> I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending >> commit, verify if reverting that on -rc1 works, then verify if reverting >> on -rc5 also works :-) >>
Hi, Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): > Hi, > > Op 18-08-2021 om 00:00 schreef Ferry Toth: >> Hi, >> >> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>> Hi, >>> >>> Ferry Toth <fntoth@gmail.com> writes: >>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>> So this is triggered by a SetInterface request... >>>>>>> >>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>> >>>>>>>>>>>> I'll try if I can get the same error by booting with USB in >>>>>>>>>>>> host mode >>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>> and collect as >>>>>>>>>>>> you explained me before. >>>>>>>>>>>> >>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and will >>>>>>>>>>>> not be >>>>>>>>>>>> available before rc5. >>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>> >>>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>> options on >>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>> >>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, after >>>>>>>>>> which >>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>> >>>>>>>>>> I tried to log following these instructions: >>>>>>>>>> >>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs >>>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to the >>>>>>>>>> ` cp >>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>> kicks). >>>>>>>>>> >>>>>>>>>> What to do next? >>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>> >>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>> console >>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>> >>>>>>>> I copied the screen buffer to file see attached. >>>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>>> the logs around Set Interface requests, we can track every endpoint >>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>> the last >>>>>>> Set Interface, that means we should have something odd with >>>>>>> ep6in, but >>>>>>> everything looks fine in the trace output: >>>>>>> >>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring >>>>>>> 0/0 flags E:swbp:< >>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 >>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 >>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 >>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 >>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: >>>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>>> [Status Phase] >>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: >>>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI >>>>>>> ==> 0 >>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params >>>>>>> 00000000 00000000 00000000 --> status: Successful >>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: >>>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> >>>>>>> -115 >>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>> zsI ==> -104 >>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>> ==> -104 >>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> >>>>>>> -115 >>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>> zsI ==> -104 >>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>> ==> -104 >>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>> ring 0/0 flags E:swbp:< >>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: >>>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>>> [Status Phase] >>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: >>>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI >>>>>>> ==> 0 >>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: >>>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: >>>>>>> event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>>> [Data Phase] >>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: >>>>>>> event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data >>>>>>> Phase] >>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: >>>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 >>>>>>> ZsI ==> 0 >>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: >>>>>>> event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) >>>>>>> [Status Phase] >>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>> >>>>>>> Do you mind adding a few prints in dwc3_remove_requests to tell >>>>>>> us which >>>>>>> endpoint is being processed? Then we'll know for sure which one >>>>>>> caused >>>>>>> the crash. >>>>>>> >>>>>> I wouldn't mind but am leaving on a holiday, won't have time until >>>>>> 6 aug. >>>>> not a problem, we'll still be here when you're back :-) >>>> Well, let's go then :-) >>>> >>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 >>>> and 5.14.0-rc5. >>>> >>>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >>> That's great finding. We have a bisection point. There are a total of >>> 13764 commits between v5.13 and v5.14-rc1 >>> >>> $ git rev-list --count v5.13..v5.14-rc1 >>> 13764 >>> >>> git bisect should find the offending commit in at most 14 tries. That's >>> not too bad. >> I correctly guesstimated that the problem got introduced by the usb >> merge 79160a60 >> >> "Merge tag 'usb-5.14-rc1' of >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >> >> 116 commits(7 bisects). >> >> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >> >> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >> >> Ruslan's 3 patches are related to each other so I reverted all three >> 24f779da...e89bb428 and applied the reverts to rc1. >> >> I can confirm this indeed resolves the problem in rc1. >> >> Is late now, tomorrow evening I will apply the reverts to rc6. > > With these reverts rc6 works fine as well. > > So, where do we go from here? > I know the patches have been tested on dwc2 (by me and others). I do not know if Ruslan or Jerome tested them on dwc3 but probably not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? The patches add a new EP-IN for async feedback. I am sorry I have not followed your long thread (it started as unrelated to uac). Does the problem appear with f_uac1 or f_uac2? Please how have you reached the above problem? u_audio_stop_capture calls free_ep_fback https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/u_audio.c#L414 which clears the feedback request prm->req_fback. Then (reading from your the call trace), usb_ep_disable calls dwc3_gadget_ep_disable which for every request in the EP calls dwc3_remove_requests which gives every found request back to the gadget function, IIUC by calling the complete method of the request https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/udc/core.c#L912 . Perhaps the problem is somewhere here? The dwc2 gadget has its endpoint_disable method a bit different https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L4200 -> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L3251 -> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L2090 which also calls usb_gadget_giveback_request https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L2126 . Perhaps there is some minor but important difference in processing the requests when disabling the endpoint between dwc2 and dwc3? Thanks, Pavel.
On Wed, Aug 18, 2021 at 10:07 PM Ferry Toth <fntoth@gmail.com> wrote: > Op 18-08-2021 om 00:00 schreef Ferry Toth: > > Op 16-08-2021 om 07:18 schreef Felipe Balbi: > >> Ferry Toth <fntoth@gmail.com> writes: > >>>> Ferry Toth <fntoth@gmail.com> writes: > >>>>>>>> Ferry Toth <fntoth@gmail.com> writes: > >>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, > >>>>>>>>>>>>> BIOS 542 > >>>>>>>>>>>>> 2015.01.21:18.19.48 > >>>>>>>>>>>>> RIP: 0010:0x500000000 > >>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. > >>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 > >>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: > >>>>>>>>>>>>> ffff8cd546aed200 > >>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: > >>>>>>>>>>>>> 0000000000000001 > >>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: > >>>>>>>>>>>>> ffff8cd547342828 > >>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: > >>>>>>>>>>>>> ffff8cd548b1d000 > >>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) > >>>>>>>>>>>>> knlGS:0000000000000000 > >>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > >>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: > >>>>>>>>>>>>> 00000000001006f0 > >>>>>>>>>>>>> Call Trace: > >>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 > >>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 > >>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 > >>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x > >>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] > >>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] > >>>>>> So this is triggered by a SetInterface request... > >>>>>> > >>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] > >>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 > >>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 > >>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] > >>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] > >>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 > >>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 > >>>>>>>>>>>>> ? __schedule+0x235/0x6c0 > >>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 > >>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 > >>>>>>>>>>>>> ? irq_thread+0xc0/0x160 > >>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 > >>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 > >>>>>>>>>>>>> ? kthread+0x122/0x140 > >>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 > >>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 > >>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? > >>>>>>>>>>>> Trying to figure > >>>>>>>>>>>> out how we got here. > >>>>>>>>>>>> > >>>>>>>>>>> I'll try if I can get the same error by booting with USB in > >>>>>>>>>>> host mode > >>>>>>>>>>> and then switch to device mode. If so I can enable traces > >>>>>>>>>>> and collect as > >>>>>>>>>>> you explained me before. > >>>>>>>>>>> > >>>>>>>>>>> I'll try before monday, as then I fly for a holiday and will > >>>>>>>>>>> not be > >>>>>>>>>>> available before rc5. > >>>>>>>>>> you can enable all of those with kernel cmdline :-) > >>>>>>>>>> > >>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct > >>>>>>>>>> options on > >>>>>>>>>> trace_buf_size and trace_event. > >>>>>>>>>> > >>>>>>>>> On Edison-Arduino I have a switch to go to device mode, after > >>>>>>>>> which > >>>>>>>>> udev triggers a script configure gadgets through configfs. > >>>>>>>>> > >>>>>>>>> I tried to log following these instructions: > >>>>>>>>> > >>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs > >>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Unfortunately the kernel crashes so badly I can not get to the > >>>>>>>>> ` cp > >>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog > >>>>>>>>> kicks). > >>>>>>>>> > >>>>>>>>> What to do next? > >>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. > >>>>>>>> > >>>>>>> No sure if I did this right, on oops everything is pushed to > >>>>>>> console > >>>>>>> (115k2 serial), I hope nothing essential is lost. > >>>>>>> > >>>>>>> I copied the screen buffer to file see attached. > >>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at > >>>>>> the logs around Set Interface requests, we can track every endpoint > >>>>>> that's disabled. I'll take a guess and assume we're failing at > >>>>>> the last > >>>>>> Set Interface, that means we should have something odd with > >>>>>> ep6in, but > >>>>>> everything looks fine in the trace output: > >>>>>> > >>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : > >>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 ring > >>>>>> 0/0 flags E:swbp:< > >>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : > >>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI ==> 0 > >>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : > >>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> -115 > >>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : > >>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI ==> 0 > >>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : > >>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> -115 > >>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: > >>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) > >>>>>> [Status Phase] > >>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : > >>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) > >>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : > >>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params > >>>>>> 00000000 1bded000 00000000 --> status: Successful > >>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: > >>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] > >>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : > >>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) > >>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : > >>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI > >>>>>> ==> 0 > >>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : > >>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) > >>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : > >>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params > >>>>>> 00000000 1bded000 00000000 --> status: Successful > >>>>>> [ 76.297418] kworker/-23 0d... 42789670us : > >>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 > >>>>>> [ 76.308278] kworker/-23 0d... 42789695us : > >>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf > >>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) > >>>>>> [ 76.395294] kworker/-23 0d... 42789707us : > >>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params > >>>>>> 00000000 00000000 00000000 --> status: Successful > >>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: > >>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] > >>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : > >>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) > >>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : > >>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI ==> > >>>>>> -115 > >>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : > >>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 > >>>>>> zsI ==> -104 > >>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : > >>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI > >>>>>> ==> -104 > >>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : > >>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> > >>>>>> -115 > >>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : > >>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 > >>>>>> zsI ==> -104 > >>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : > >>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI > >>>>>> ==> -104 > >>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : > >>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 > >>>>>> ring 0/0 flags E:swbp:< > >>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: > >>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) > >>>>>> [Status Phase] > >>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : > >>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) > >>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : > >>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params > >>>>>> 00000000 1bded000 00000000 --> status: Successful > >>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: > >>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] > >>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : > >>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) > >>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : > >>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 zsI > >>>>>> ==> 0 > >>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : > >>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) > >>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : > >>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params > >>>>>> 00000000 1bded000 00000000 --> status: Successful > >>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: > >>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] > >>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : > >>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) > >>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : > >>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) > >>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : > >>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params > >>>>>> 00000000 1bded000 00000000 --> status: Successful > >>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: > >>>>>> event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) > >>>>>> [Data Phase] > >>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: > >>>>>> event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data > >>>>>> Phase] > >>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: > >>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] > >>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : > >>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) > >>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : > >>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 > >>>>>> ZsI ==> 0 > >>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: > >>>>>> event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) > >>>>>> [Status Phase] > >>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : > >>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf > >>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) > >>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : > >>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params > >>>>>> 00000000 1bded000 00000000 --> status: Successful > >>>>>> > >>>>>> Do you mind adding a few prints in dwc3_remove_requests to tell > >>>>>> us which > >>>>>> endpoint is being processed? Then we'll know for sure which one > >>>>>> caused > >>>>>> the crash. > >>>>>> > >>>>> I wouldn't mind but am leaving on a holiday, won't have time until > >>>>> 6 aug. > >>>> not a problem, we'll still be here when you're back :-) > >>> Well, let's go then :-) > >>> > >>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 > >>> and 5.14.0-rc5. > >>> > >>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. > >> That's great finding. We have a bisection point. There are a total of > >> 13764 commits between v5.13 and v5.14-rc1 > >> > >> $ git rev-list --count v5.13..v5.14-rc1 > >> 13764 > >> > >> git bisect should find the offending commit in at most 14 tries. That's > >> not too bad. > > I correctly guesstimated that the problem got introduced by the usb > > merge 79160a60 > > > > "Merge tag 'usb-5.14-rc1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" > > > > 116 commits(7 bisects). > > > > 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit > > > > "usb: gadget: f_uac2/u_audio: add feedback endpoint support" > > > > Ruslan's 3 patches are related to each other so I reverted all three > > 24f779da...e89bb428 and applied the reverts to rc1. > > > > I can confirm this indeed resolves the problem in rc1. > > > > Is late now, tomorrow evening I will apply the reverts to rc6. > > With these reverts rc6 works fine as well. > > So, where do we go from here? Since it's rc6 to rc7 I think the best is to send a revert series to handle the regression. > >>> With 5.14.0-rc5 the problem seems worse (or different?), and just > >>> disabling uac2 gadget does not prevent the crash. Even disabling gser > >>> and mass_storage.usb0 as well there is still a crash. > >>> > >>> Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)? > >> I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending > >> commit, verify if reverting that on -rc1 works, then verify if reverting > >> on -rc5 also works :-)
Hi Op 19-08-2021 om 09:51 schreef Pavel Hofman: > Hi, > > Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >> Hi, >> >> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>> Hi, >>> >>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>> Hi, >>>> >>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>> So this is triggered by a SetInterface request... >>>>>>>> >>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>> >>>>>>>>>>>>> I'll try if I can get the same error by booting with USB in >>>>>>>>>>>>> host mode >>>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>>> and collect as >>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>> will not be >>>>>>>>>>>>> available before rc5. >>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>> >>>>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>> options on >>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>> >>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, after >>>>>>>>>>> which >>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>> >>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>> >>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs >>>>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>> the ` cp >>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>> kicks). >>>>>>>>>>> >>>>>>>>>>> What to do next? >>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>> >>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>> console >>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>> >>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>>>> the logs around Set Interface requests, we can track every endpoint >>>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>>> the last >>>>>>>> Set Interface, that means we should have something odd with >>>>>>>> ep6in, but >>>>>>>> everything looks fine in the trace output: >>>>>>>> >>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI >>>>>>>> ==> 0 >>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> >>>>>>>> -115 >>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI >>>>>>>> ==> 0 >>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> >>>>>>>> -115 >>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : dwc3_event: >>>>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>>>> [Status Phase] >>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : dwc3_event: >>>>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>> zsI ==> 0 >>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> -115 >>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params >>>>>>>> 00000000 00000000 00000000 --> status: Successful >>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : dwc3_event: >>>>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>> ==> -115 >>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>>> zsI ==> -104 >>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>> ==> -104 >>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>> ==> -115 >>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>> zsI ==> -104 >>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>> ==> -104 >>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : dwc3_event: >>>>>>>> event (000020c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>>>> [Status Phase] >>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : dwc3_event: >>>>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Status Phase] >>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>> zsI ==> 0 >>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : dwc3_event: >>>>>>>> event (0000c040): ep0out: Transfer Complete (sIL) [Setup Phase] >>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : dwc3_event: >>>>>>>> event (000010c2): ep0in: Transfer Not Ready [0] (Not Active) >>>>>>>> [Data Phase] >>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : dwc3_event: >>>>>>>> event (000090c2): ep0in: Transfer Not Ready [0] (Active) [Data >>>>>>>> Phase] >>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : dwc3_event: >>>>>>>> event (0000c042): ep0in: Transfer Complete (sIL) [Data Phase] >>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 >>>>>>>> ZsI ==> 0 >>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : dwc3_event: >>>>>>>> event (000020c0): ep0out: Transfer Not Ready [0] (Not Active) >>>>>>>> [Status Phase] >>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>> >>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to tell >>>>>>>> us which >>>>>>>> endpoint is being processed? Then we'll know for sure which one >>>>>>>> caused >>>>>>>> the crash. >>>>>>>> >>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>> until 6 aug. >>>>>> not a problem, we'll still be here when you're back :-) >>>>> Well, let's go then :-) >>>>> >>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2 >>>>> and 5.14.0-rc5. >>>>> >>>>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >>>> That's great finding. We have a bisection point. There are a total of >>>> 13764 commits between v5.13 and v5.14-rc1 >>>> >>>> $ git rev-list --count v5.13..v5.14-rc1 >>>> 13764 >>>> >>>> git bisect should find the offending commit in at most 14 tries. That's >>>> not too bad. >>> I correctly guesstimated that the problem got introduced by the usb >>> merge 79160a60 >>> >>> "Merge tag 'usb-5.14-rc1' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>> >>> 116 commits(7 bisects). >>> >>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>> >>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>> >>> Ruslan's 3 patches are related to each other so I reverted all three >>> 24f779da...e89bb428 and applied the reverts to rc1. >>> >>> I can confirm this indeed resolves the problem in rc1. >>> >>> Is late now, tomorrow evening I will apply the reverts to rc6. >> >> With these reverts rc6 works fine as well. >> >> So, where do we go from here? >> > > I know the patches have been tested on dwc2 (by me and others). I do > not know if Ruslan or Jerome tested them on dwc3 but probably not. > Ruslan has talked about RPi (my case too) and BeagleboneBlack, both with > dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? > > The patches add a new EP-IN for async feedback. I am sorry I have not > followed your long thread (it started as unrelated to uac). Does the > problem appear with f_uac1 or f_uac2? Please how have you reached the > above problem? I'm sorry too. I first believed the issue was related to the patch mentioned in the subject line. The problem appaers with f_uac2. I bost Edison_Arduino board in host mode (there is a switch allowing to select host/device mode). When flipping the switch to device mode udev run a script: But as I am using configfs (excerpt follows) and just disabling the last 2 line resolves the issue, I'm guessing uac2 is the issue. Or exceeding the available resources. # Create directory structure mkdir "${GADGET_BASE_DIR}" cd "${GADGET_BASE_DIR}" mkdir -p configs/c.1/strings/0x409 mkdir -p strings/0x409 # Serial device mkdir functions/gser.usb0 ln -s functions/gser.usb0 configs/c.1/ ### # Ethernet device mkdir functions/eem.usb0 echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr ln -s functions/eem.usb0 configs/c.1/ # Mass Storage device mkdir functions/mass_storage.usb0 echo 1 > functions/mass_storage.usb0/stall echo 0 > functions/mass_storage.usb0/lun.0/cdrom echo 0 > functions/mass_storage.usb0/lun.0/ro echo 0 > functions/mass_storage.usb0/lun.0/nofua echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file ln -s functions/mass_storage.usb0 configs/c.1/ # UAC2 device mkdir functions/uac2.usb0 ln -s functions/uac2.usb0 configs/c.1 .... > u_audio_stop_capture calls free_ep_fback > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/u_audio.c#L414 > which clears the feedback request prm->req_fback. > > Then (reading from your the call trace), usb_ep_disable calls > dwc3_gadget_ep_disable which for every request in the EP calls > dwc3_remove_requests which gives every found request back to the gadget > function, IIUC by calling the complete method of the request > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/udc/core.c#L912 > . Perhaps the problem is somewhere here? > > The dwc2 gadget has its endpoint_disable method a bit different > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L4200 > -> > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L3251 > -> > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L2090 > which also calls usb_gadget_giveback_request > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/dwc2/gadget.c#L2126 > . Perhaps there is some minor but important difference in processing the > requests when disabling the endpoint between dwc2 and dwc3? > > Thanks, > > Pavel.
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): > Hi > > Op 19-08-2021 om 09:51 schreef Pavel Hofman: >> Hi, >> >> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>> Hi, >>> >>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>> Hi, >>>> >>>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>>> Hi, >>>>> >>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>>> So this is triggered by a SetInterface request... >>>>>>>>> >>>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 [libcomposite] >>>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll try if I can get the same error by booting with USB >>>>>>>>>>>>>> in host mode >>>>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>>>> and collect as >>>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>>> will not be >>>>>>>>>>>>>> available before rc5. >>>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>>> options on >>>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>>> >>>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, >>>>>>>>>>>> after which >>>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>>> >>>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>>> >>>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs >>>>>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>>> the ` cp >>>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>>> kicks). >>>>>>>>>>>> >>>>>>>>>>>> What to do next? >>>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>>> >>>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>>> console >>>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>>> >>>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>>>>> the logs around Set Interface requests, we can track every >>>>>>>>> endpoint >>>>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>>>> the last >>>>>>>>> Set Interface, that means we should have something odd with >>>>>>>>> ep6in, but >>>>>>>>> everything looks fine in the trace output: >>>>>>>>> >>>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI >>>>>>>>> ==> 0 >>>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI ==> >>>>>>>>> -115 >>>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI >>>>>>>>> ==> 0 >>>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI ==> >>>>>>>>> -115 >>>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : >>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>> (Not Active) [Status Phase] >>>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : >>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>> [Status Phase] >>>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>> zsI ==> 0 >>>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> >>>>>>>>> -115 >>>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] params >>>>>>>>> 00000000 00000000 00000000 --> status: Successful >>>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : >>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>> [Setup Phase] >>>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>> ==> -115 >>>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>> zsI ==> -104 >>>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>> ==> -104 >>>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>> ==> -115 >>>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>> zsI ==> -104 >>>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>> ==> -104 >>>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : >>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>> (Not Active) [Status Phase] >>>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : >>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>> [Status Phase] >>>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>> zsI ==> 0 >>>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : >>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>> [Setup Phase] >>>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : >>>>>>>>> dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] >>>>>>>>> (Not Active) [Data Phase] >>>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : >>>>>>>>> dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] >>>>>>>>> (Active) [Data Phase] >>>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : >>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>> [Data Phase] >>>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 36/36 >>>>>>>>> ZsI ==> 0 >>>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : >>>>>>>>> dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] >>>>>>>>> (Not Active) [Status Phase] >>>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>> >>>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to tell >>>>>>>>> us which >>>>>>>>> endpoint is being processed? Then we'll know for sure which one >>>>>>>>> caused >>>>>>>>> the crash. >>>>>>>>> >>>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>>> until 6 aug. >>>>>>> not a problem, we'll still be here when you're back :-) >>>>>> Well, let's go then :-) >>>>>> >>>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, >>>>>> 5.14.0-rc2 >>>>>> and 5.14.0-rc5. >>>>>> >>>>>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >>>>> That's great finding. We have a bisection point. There are a total of >>>>> 13764 commits between v5.13 and v5.14-rc1 >>>>> >>>>> $ git rev-list --count v5.13..v5.14-rc1 >>>>> 13764 >>>>> >>>>> git bisect should find the offending commit in at most 14 tries. >>>>> That's >>>>> not too bad. >>>> I correctly guesstimated that the problem got introduced by the usb >>>> merge 79160a60 >>>> >>>> "Merge tag 'usb-5.14-rc1' of >>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>>> >>>> 116 commits(7 bisects). >>>> >>>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>>> >>>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>>> >>>> Ruslan's 3 patches are related to each other so I reverted all three >>>> 24f779da...e89bb428 and applied the reverts to rc1. >>>> >>>> I can confirm this indeed resolves the problem in rc1. >>>> >>>> Is late now, tomorrow evening I will apply the reverts to rc6. >>> >>> With these reverts rc6 works fine as well. >>> >>> So, where do we go from here? >>> >> >> I know the patches have been tested on dwc2 (by me and others). I do >> not know if Ruslan or Jerome tested them on dwc3 but probably not. >> Ruslan has talked about RPi (my case too) and BeagleboneBlack, both >> with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >> >> The patches add a new EP-IN for async feedback. I am sorry I have not >> followed your long thread (it started as unrelated to uac). Does the >> problem appear with f_uac1 or f_uac2? Please how have you reached the >> above problem? > > I'm sorry too. I first believed the issue was related to the patch > mentioned in the subject line. > > The problem appaers with f_uac2. I bost Edison_Arduino board in host > mode (there is a switch allowing to select host/device mode). When > flipping the switch to device mode udev run a script: > But as I am using configfs (excerpt follows) and just disabling the last > 2 line resolves the issue, I'm guessing uac2 is the issue. Or exceeding > the available resources. > > # Create directory structure > mkdir "${GADGET_BASE_DIR}" > cd "${GADGET_BASE_DIR}" > mkdir -p configs/c.1/strings/0x409 > mkdir -p strings/0x409 > > # Serial device > mkdir functions/gser.usb0 > ln -s functions/gser.usb0 configs/c.1/ > ### > > # Ethernet device > mkdir functions/eem.usb0 > echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr > echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr > ln -s functions/eem.usb0 configs/c.1/ > > # Mass Storage device > mkdir functions/mass_storage.usb0 > echo 1 > functions/mass_storage.usb0/stall > echo 0 > functions/mass_storage.usb0/lun.0/cdrom > echo 0 > functions/mass_storage.usb0/lun.0/ro > echo 0 > functions/mass_storage.usb0/lun.0/nofua > echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file > ln -s functions/mass_storage.usb0 configs/c.1/ > > # UAC2 device > mkdir functions/uac2.usb0 > ln -s functions/uac2.usb0 configs/c.1 > .... > As you say, could perhaps the reason be that the extra EP-IN added in those patches (previously 1, now 2 with the default config you use) exceeds your EP-IN max count or available fifos somehow? You have a number of functions initialized. If you change the load order of the functions, do you get the error later with a different function? Just guessing... You should be able to switch the default async EP-OUT (which configures the new feedback EP-IN ) to adaptive EP-OUT (which requires no feedback EP) with c_sync=8 parameter of f_uac2. https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 Does that fix the problem? Thanks, Pavel.
Pavel Hofman wrote: > > Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >> Hi >> >> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>> Hi, >>> >>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>> Hi, >>>> >>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>> Hi, >>>>> >>>>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>>>> Hi, >>>>>> >>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>>>> So this is triggered by a SetInterface request... >>>>>>>>>> >>>>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll try if I can get the same error by booting with USB >>>>>>>>>>>>>>> in host mode >>>>>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>>>>> and collect as >>>>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>>>> will not be >>>>>>>>>>>>>>> available before rc5. >>>>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html__;!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAPch0qja$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>>>> options on >>>>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>>>> >>>>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, >>>>>>>>>>>>> after which >>>>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>>>> >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*reporting-bugs__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAG64agnA$ >>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*reporting-bugs__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAG64agnA$ >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>>>> the ` cp >>>>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>>>> kicks). >>>>>>>>>>>>> >>>>>>>>>>>>> What to do next? >>>>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>>>> >>>>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>>>> console >>>>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>>>> >>>>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>>>>>> the logs around Set Interface requests, we can track every >>>>>>>>>> endpoint >>>>>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>>>>> the last >>>>>>>>>> Set Interface, that means we should have something odd with >>>>>>>>>> ep6in, but >>>>>>>>>> everything looks fine in the trace output: >>>>>>>>>> >>>>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI >>>>>>>>>> ==> 0 >>>>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI >>>>>>>>>> ==> 0 >>>>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : >>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : >>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>> [Status Phase] >>>>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>> zsI ==> 0 >>>>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> >>>>>>>>>> -115 >>>>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] >>>>>>>>>> params 00000000 00000000 00000000 --> status: Successful >>>>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : >>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>> [Setup Phase] >>>>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : >>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : >>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>> [Status Phase] >>>>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>> zsI ==> 0 >>>>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : >>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>> [Setup Phase] >>>>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : >>>>>>>>>> dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Data Phase] >>>>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : >>>>>>>>>> dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Active) [Data Phase] >>>>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : >>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>> [Data Phase] >>>>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length >>>>>>>>>> 36/36 ZsI ==> 0 >>>>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : >>>>>>>>>> dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> >>>>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to >>>>>>>>>> tell us which >>>>>>>>>> endpoint is being processed? Then we'll know for sure which >>>>>>>>>> one caused >>>>>>>>>> the crash. >>>>>>>>>> >>>>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>>>> until 6 aug. >>>>>>>> not a problem, we'll still be here when you're back :-) >>>>>>> Well, let's go then :-) >>>>>>> >>>>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, >>>>>>> 5.14.0-rc2 >>>>>>> and 5.14.0-rc5. >>>>>>> >>>>>>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >>>>>> That's great finding. We have a bisection point. There are a total of >>>>>> 13764 commits between v5.13 and v5.14-rc1 >>>>>> >>>>>> $ git rev-list --count v5.13..v5.14-rc1 >>>>>> 13764 >>>>>> >>>>>> git bisect should find the offending commit in at most 14 tries. >>>>>> That's >>>>>> not too bad. >>>>> I correctly guesstimated that the problem got introduced by the usb >>>>> merge 79160a60 >>>>> >>>>> "Merge tag 'usb-5.14-rc1' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>>>> >>>>> 116 commits(7 bisects). >>>>> >>>>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>>>> >>>>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>>>> >>>>> Ruslan's 3 patches are related to each other so I reverted all >>>>> three 24f779da...e89bb428 and applied the reverts to rc1. >>>>> >>>>> I can confirm this indeed resolves the problem in rc1. >>>>> >>>>> Is late now, tomorrow evening I will apply the reverts to rc6. >>>> >>>> With these reverts rc6 works fine as well. >>>> >>>> So, where do we go from here? >>>> >>> >>> I know the patches have been tested on dwc2 (by me and others). I do >>> not know if Ruslan or Jerome tested them on dwc3 but probably not. >>> Ruslan has talked about RPi (my case too) and BeagleboneBlack, both >>> with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>> >>> The patches add a new EP-IN for async feedback. I am sorry I have not >>> followed your long thread (it started as unrelated to uac). Does the >>> problem appear with f_uac1 or f_uac2? Please how have you reached the >>> above problem? >> >> I'm sorry too. I first believed the issue was related to the patch >> mentioned in the subject line. >> >> The problem appaers with f_uac2. I bost Edison_Arduino board in host >> mode (there is a switch allowing to select host/device mode). When >> flipping the switch to device mode udev run a script: >> But as I am using configfs (excerpt follows) and just disabling the >> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >> exceeding the available resources. >> >> # Create directory structure >> mkdir "${GADGET_BASE_DIR}" >> cd "${GADGET_BASE_DIR}" >> mkdir -p configs/c.1/strings/0x409 >> mkdir -p strings/0x409 >> >> # Serial device >> mkdir functions/gser.usb0 >> ln -s functions/gser.usb0 configs/c.1/ >> ### >> >> # Ethernet device >> mkdir functions/eem.usb0 >> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >> ln -s functions/eem.usb0 configs/c.1/ >> >> # Mass Storage device >> mkdir functions/mass_storage.usb0 >> echo 1 > functions/mass_storage.usb0/stall >> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >> echo 0 > functions/mass_storage.usb0/lun.0/ro >> echo 0 > functions/mass_storage.usb0/lun.0/nofua >> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >> ln -s functions/mass_storage.usb0 configs/c.1/ >> >> # UAC2 device >> mkdir functions/uac2.usb0 >> ln -s functions/uac2.usb0 configs/c.1 >> .... >> > > As you say, could perhaps the reason be that the extra EP-IN added in > those patches (previously 1, now 2 with the default config you use) > exceeds your EP-IN max count or available fifos somehow? You have a > number of functions initialized. If you change the load order of the > functions, do you get the error later with a different function? Just > guessing... > > You should be able to switch the default async EP-OUT (which configures > the new feedback EP-IN ) to adaptive EP-OUT (which requires no feedback > EP) with c_sync=8 parameter of f_uac2. > > https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAHQ6Lj4y$ > > https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAC7mfgo7$ > > https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPANdeuGIx$ > > Does that fix the problem? > Hi Pavel, I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add feedback endpoint support") that Ferry reported the issue from bisection. I see at least a couple problems in the new UAC2 changes. 1) usb_ep_dequeue() is asynchronous. Don't free requests before the controller driver give them back. 2) Did you test with SuperSpeed? I don't see companion descriptor. Please fix them. Thanks, Thinh
Op 19-08-2021 om 23:04 schreef Pavel Hofman: > > Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >> Hi >> >> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>> Hi, >>> >>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>> Hi, >>>> >>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>> Hi, >>>>> >>>>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>>>> Hi, >>>>>> >>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>>>> So this is triggered by a SetInterface request... >>>>>>>>>> >>>>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll try if I can get the same error by booting with USB >>>>>>>>>>>>>>> in host mode >>>>>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>>>>> and collect as >>>>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>>>> will not be >>>>>>>>>>>>>>> available before rc5. >>>>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>>>> options on >>>>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>>>> >>>>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, >>>>>>>>>>>>> after which >>>>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs >>>>>>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>>>> the ` cp >>>>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>>>> kicks). >>>>>>>>>>>>> >>>>>>>>>>>>> What to do next? >>>>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>>>> >>>>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>>>> console >>>>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>>>> >>>>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>>>>>> the logs around Set Interface requests, we can track every >>>>>>>>>> endpoint >>>>>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>>>>> the last >>>>>>>>>> Set Interface, that means we should have something odd with >>>>>>>>>> ep6in, but >>>>>>>>>> everything looks fine in the trace output: >>>>>>>>>> >>>>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI >>>>>>>>>> ==> 0 >>>>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI >>>>>>>>>> ==> 0 >>>>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : >>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : >>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>> [Status Phase] >>>>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>> zsI ==> 0 >>>>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> >>>>>>>>>> -115 >>>>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] >>>>>>>>>> params 00000000 00000000 00000000 --> status: Successful >>>>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : >>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>> [Setup Phase] >>>>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>> ==> -115 >>>>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>> zsI ==> -104 >>>>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : >>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : >>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>> [Status Phase] >>>>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>> zsI ==> 0 >>>>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : >>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>> [Setup Phase] >>>>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : >>>>>>>>>> dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Data Phase] >>>>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : >>>>>>>>>> dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] >>>>>>>>>> (Active) [Data Phase] >>>>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : >>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>> [Data Phase] >>>>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length >>>>>>>>>> 36/36 ZsI ==> 0 >>>>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : >>>>>>>>>> dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] >>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>> >>>>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to >>>>>>>>>> tell us which >>>>>>>>>> endpoint is being processed? Then we'll know for sure which >>>>>>>>>> one caused >>>>>>>>>> the crash. >>>>>>>>>> >>>>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>>>> until 6 aug. >>>>>>>> not a problem, we'll still be here when you're back :-) >>>>>>> Well, let's go then :-) >>>>>>> >>>>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, >>>>>>> 5.14.0-rc2 >>>>>>> and 5.14.0-rc5. >>>>>>> >>>>>>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >>>>>> That's great finding. We have a bisection point. There are a total of >>>>>> 13764 commits between v5.13 and v5.14-rc1 >>>>>> >>>>>> $ git rev-list --count v5.13..v5.14-rc1 >>>>>> 13764 >>>>>> >>>>>> git bisect should find the offending commit in at most 14 tries. >>>>>> That's >>>>>> not too bad. >>>>> I correctly guesstimated that the problem got introduced by the usb >>>>> merge 79160a60 >>>>> >>>>> "Merge tag 'usb-5.14-rc1' of >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>>>> >>>>> 116 commits(7 bisects). >>>>> >>>>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>>>> >>>>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>>>> >>>>> Ruslan's 3 patches are related to each other so I reverted all >>>>> three 24f779da...e89bb428 and applied the reverts to rc1. >>>>> >>>>> I can confirm this indeed resolves the problem in rc1. >>>>> >>>>> Is late now, tomorrow evening I will apply the reverts to rc6. >>>> >>>> With these reverts rc6 works fine as well. >>>> >>>> So, where do we go from here? >>>> >>> >>> I know the patches have been tested on dwc2 (by me and others). I do >>> not know if Ruslan or Jerome tested them on dwc3 but probably not. >>> Ruslan has talked about RPi (my case too) and BeagleboneBlack, both >>> with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>> >>> The patches add a new EP-IN for async feedback. I am sorry I have not >>> followed your long thread (it started as unrelated to uac). Does the >>> problem appear with f_uac1 or f_uac2? Please how have you reached the >>> above problem? >> >> I'm sorry too. I first believed the issue was related to the patch >> mentioned in the subject line. >> >> The problem appaers with f_uac2. I bost Edison_Arduino board in host >> mode (there is a switch allowing to select host/device mode). When >> flipping the switch to device mode udev run a script: >> But as I am using configfs (excerpt follows) and just disabling the >> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >> exceeding the available resources. >> >> # Create directory structure >> mkdir "${GADGET_BASE_DIR}" >> cd "${GADGET_BASE_DIR}" >> mkdir -p configs/c.1/strings/0x409 >> mkdir -p strings/0x409 >> >> # Serial device >> mkdir functions/gser.usb0 >> ln -s functions/gser.usb0 configs/c.1/ >> ### >> >> # Ethernet device >> mkdir functions/eem.usb0 >> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >> ln -s functions/eem.usb0 configs/c.1/ >> >> # Mass Storage device >> mkdir functions/mass_storage.usb0 >> echo 1 > functions/mass_storage.usb0/stall >> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >> echo 0 > functions/mass_storage.usb0/lun.0/ro >> echo 0 > functions/mass_storage.usb0/lun.0/nofua >> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >> ln -s functions/mass_storage.usb0 configs/c.1/ >> >> # UAC2 device >> mkdir functions/uac2.usb0 >> ln -s functions/uac2.usb0 configs/c.1 >> .... >> > > As you say, could perhaps the reason be that the extra EP-IN added in > those patches (previously 1, now 2 with the default config you use) > exceeds your EP-IN max count or available fifos somehow? You have a > number of functions initialized. If you change the load order of the > functions, do you get the error later with a different function? Just > guessing... > > You should be able to switch the default async EP-OUT (which configures > the new feedback EP-IN ) to adaptive EP-OUT (which requires no feedback > EP) with c_sync=8 parameter of f_uac2. > > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 > > > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 > > > https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 > > > Does that fix the problem? Not sure how to do that. Do you mean the module should have a parameter called c_sync? `modinfo` list no parameters for usb_f_uac2. > Thanks, > > Pavel.
Op 21-08-2021 om 04:57 schreef Thinh Nguyen: > Pavel Hofman wrote: >> >> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>> Hi >>> >>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>> Hi, >>>> >>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>> Hi, >>>>> >>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>>> Hi, >>>>>> >>>>>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>>>>> Hi, >>>>>>> >>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>>>>> So this is triggered by a SetInterface request... >>>>>>>>>>> >>>>>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll try if I can get the same error by booting with USB >>>>>>>>>>>>>>>> in host mode >>>>>>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>>>>>> and collect as >>>>>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>>>>> will not be >>>>>>>>>>>>>>>> available before rc5. >>>>>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html__;!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAPch0qja$ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>>>>> options on >>>>>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, >>>>>>>>>>>>>> after which >>>>>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*reporting-bugs__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAG64agnA$ >>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*reporting-bugs__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAG64agnA$ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>>>>> the ` cp >>>>>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>>>>> kicks). >>>>>>>>>>>>>> >>>>>>>>>>>>>> What to do next? >>>>>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>>>>> >>>>>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>>>>> console >>>>>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>>>>> >>>>>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, looking at >>>>>>>>>>> the logs around Set Interface requests, we can track every >>>>>>>>>>> endpoint >>>>>>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>>>>>> the last >>>>>>>>>>> Set Interface, that means we should have something odd with >>>>>>>>>>> ep6in, but >>>>>>>>>>> everything looks fine in the trace output: >>>>>>>>>>> >>>>>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI >>>>>>>>>>> ==> 0 >>>>>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI >>>>>>>>>>> ==> 0 >>>>>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : >>>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : >>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>> [Status Phase] >>>>>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>>> zsI ==> 0 >>>>>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> >>>>>>>>>>> -115 >>>>>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] >>>>>>>>>>> params 00000000 00000000 00000000 --> status: Successful >>>>>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : >>>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>>> [Setup Phase] >>>>>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>>> zsI ==> -104 >>>>>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>>> zsI ==> -104 >>>>>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>>> zsI ==> -104 >>>>>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>>> zsI ==> -104 >>>>>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : >>>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : >>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>> [Status Phase] >>>>>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>>> zsI ==> 0 >>>>>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : >>>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>>> [Setup Phase] >>>>>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : >>>>>>>>>>> dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Data Phase] >>>>>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : >>>>>>>>>>> dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Active) [Data Phase] >>>>>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : >>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>> [Data Phase] >>>>>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length >>>>>>>>>>> 36/36 ZsI ==> 0 >>>>>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : >>>>>>>>>>> dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> >>>>>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to >>>>>>>>>>> tell us which >>>>>>>>>>> endpoint is being processed? Then we'll know for sure which >>>>>>>>>>> one caused >>>>>>>>>>> the crash. >>>>>>>>>>> >>>>>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>>>>> until 6 aug. >>>>>>>>> not a problem, we'll still be here when you're back :-) >>>>>>>> Well, let's go then :-) >>>>>>>> >>>>>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, >>>>>>>> 5.14.0-rc2 >>>>>>>> and 5.14.0-rc5. >>>>>>>> >>>>>>>> I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1. >>>>>>> That's great finding. We have a bisection point. There are a total of >>>>>>> 13764 commits between v5.13 and v5.14-rc1 >>>>>>> >>>>>>> $ git rev-list --count v5.13..v5.14-rc1 >>>>>>> 13764 >>>>>>> >>>>>>> git bisect should find the offending commit in at most 14 tries. >>>>>>> That's >>>>>>> not too bad. >>>>>> I correctly guesstimated that the problem got introduced by the usb >>>>>> merge 79160a60 >>>>>> >>>>>> "Merge tag 'usb-5.14-rc1' of >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>>>>> >>>>>> 116 commits(7 bisects). >>>>>> >>>>>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>>>>> >>>>>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>>>>> >>>>>> Ruslan's 3 patches are related to each other so I reverted all >>>>>> three 24f779da...e89bb428 and applied the reverts to rc1. >>>>>> >>>>>> I can confirm this indeed resolves the problem in rc1. >>>>>> >>>>>> Is late now, tomorrow evening I will apply the reverts to rc6. >>>>> >>>>> With these reverts rc6 works fine as well. >>>>> >>>>> So, where do we go from here? >>>>> >>>> >>>> I know the patches have been tested on dwc2 (by me and others). I do >>>> not know if Ruslan or Jerome tested them on dwc3 but probably not. >>>> Ruslan has talked about RPi (my case too) and BeagleboneBlack, both >>>> with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>>> >>>> The patches add a new EP-IN for async feedback. I am sorry I have not >>>> followed your long thread (it started as unrelated to uac). Does the >>>> problem appear with f_uac1 or f_uac2? Please how have you reached the >>>> above problem? >>> >>> I'm sorry too. I first believed the issue was related to the patch >>> mentioned in the subject line. >>> >>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>> mode (there is a switch allowing to select host/device mode). When >>> flipping the switch to device mode udev run a script: >>> But as I am using configfs (excerpt follows) and just disabling the >>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>> exceeding the available resources. >>> >>> # Create directory structure >>> mkdir "${GADGET_BASE_DIR}" >>> cd "${GADGET_BASE_DIR}" >>> mkdir -p configs/c.1/strings/0x409 >>> mkdir -p strings/0x409 >>> >>> # Serial device >>> mkdir functions/gser.usb0 >>> ln -s functions/gser.usb0 configs/c.1/ >>> ### >>> >>> # Ethernet device >>> mkdir functions/eem.usb0 >>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>> ln -s functions/eem.usb0 configs/c.1/ >>> >>> # Mass Storage device >>> mkdir functions/mass_storage.usb0 >>> echo 1 > functions/mass_storage.usb0/stall >>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>> ln -s functions/mass_storage.usb0 configs/c.1/ >>> >>> # UAC2 device >>> mkdir functions/uac2.usb0 >>> ln -s functions/uac2.usb0 configs/c.1 >>> .... >>> >> >> As you say, could perhaps the reason be that the extra EP-IN added in >> those patches (previously 1, now 2 with the default config you use) >> exceeds your EP-IN max count or available fifos somehow? You have a >> number of functions initialized. If you change the load order of the >> functions, do you get the error later with a different function? Just >> guessing... >> >> You should be able to switch the default async EP-OUT (which configures >> the new feedback EP-IN ) to adaptive EP-OUT (which requires no feedback >> EP) with c_sync=8 parameter of f_uac2. >> >> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAHQ6Lj4y$ >> >> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAC7mfgo7$ >> >> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPANdeuGIx$ >> >> Does that fix the problem? >> > > Hi Pavel, > > I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add > feedback endpoint support") that Ferry reported the issue from > bisection. I see at least a couple problems in the new UAC2 changes. > > 1) usb_ep_dequeue() is asynchronous. Don't free requests before the > controller driver give them back. > > 2) Did you test with SuperSpeed? I don't see companion descriptor. > > Please fix them. Given it's late in the cycle I agree with Andy it would be best to revert the series now. I will be happy to test on dwc3 when a fixed series arrives. > Thanks, > Thinh >
Dne 22. 08. 21 v 22:10 Ferry Toth napsal(a): > Op 21-08-2021 om 04:57 schreef Thinh Nguyen: >> Pavel Hofman wrote: >>> >>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>> Hi >>>> >>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>> Hi, >>>>> >>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>> Hi, >>>>>> >>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>>>> Hi, >>>>>>> >>>>>>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA BAY, >>>>>>>>>>>>>>>>>>> BIOS 542 >>>>>>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>>>>>> So this is triggered by a SetInterface request... >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'll try if I can get the same error by booting with USB >>>>>>>>>>>>>>>>> in host mode >>>>>>>>>>>>>>>>> and then switch to device mode. If so I can enable traces >>>>>>>>>>>>>>>>> and collect as >>>>>>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>>>>>> will not be >>>>>>>>>>>>>>>>> available before rc5. >>>>>>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html__;!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAPch0qja$ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>>>>>> options on >>>>>>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, >>>>>>>>>>>>>>> after which >>>>>>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*reporting-bugs__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAG64agnA$ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*reporting-bugs__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAG64agnA$ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>>>>>> the ` cp >>>>>>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>>>>>> kicks). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What to do next? >>>>>>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>>>>>> >>>>>>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>>>>>> console >>>>>>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>>>>>> >>>>>>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, >>>>>>>>>>>> looking at >>>>>>>>>>>> the logs around Set Interface requests, we can track every >>>>>>>>>>>> endpoint >>>>>>>>>>>> that's disabled. I'll take a guess and assume we're failing at >>>>>>>>>>>> the last >>>>>>>>>>>> Set Interface, that means we should have something odd with >>>>>>>>>>>> ep6in, but >>>>>>>>>>>> everything looks fine in the trace output: >>>>>>>>>>>> >>>>>>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 zsI >>>>>>>>>>>> ==> 0 >>>>>>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>>>> ==> -115 >>>>>>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 zsI >>>>>>>>>>>> ==> 0 >>>>>>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>>>> ==> -115 >>>>>>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : >>>>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : >>>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>>> [Status Phase] >>>>>>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>>>> zsI ==> 0 >>>>>>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI ==> >>>>>>>>>>>> -115 >>>>>>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] >>>>>>>>>>>> params 00000000 00000000 00000000 --> status: Successful >>>>>>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : >>>>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>>>> [Setup Phase] >>>>>>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>>>> ==> -115 >>>>>>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>>>> zsI ==> -104 >>>>>>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>>>> zsI ==> -104 >>>>>>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>>>> ==> -115 >>>>>>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>>>> zsI ==> -104 >>>>>>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>>>> zsI ==> -104 >>>>>>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : >>>>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : >>>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>>> [Status Phase] >>>>>>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>>>> zsI ==> 0 >>>>>>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : >>>>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>>>> [Setup Phase] >>>>>>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : >>>>>>>>>>>> dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>>> (Not Active) [Data Phase] >>>>>>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : >>>>>>>>>>>> dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>>> (Active) [Data Phase] >>>>>>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : >>>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>>> [Data Phase] >>>>>>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length >>>>>>>>>>>> 36/36 ZsI ==> 0 >>>>>>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : >>>>>>>>>>>> dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] >>>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>>> >>>>>>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to >>>>>>>>>>>> tell us which >>>>>>>>>>>> endpoint is being processed? Then we'll know for sure which >>>>>>>>>>>> one caused >>>>>>>>>>>> the crash. >>>>>>>>>>>> >>>>>>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>>>>>> until 6 aug. >>>>>>>>>> not a problem, we'll still be here when you're back :-) >>>>>>>>> Well, let's go then :-) >>>>>>>>> >>>>>>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, >>>>>>>>> 5.14.0-rc2 >>>>>>>>> and 5.14.0-rc5. >>>>>>>>> >>>>>>>>> I find that 5.13.0 works fine, and the issue starts from >>>>>>>>> 5.14.0-rc1. >>>>>>>> That's great finding. We have a bisection point. There are a >>>>>>>> total of >>>>>>>> 13764 commits between v5.13 and v5.14-rc1 >>>>>>>> >>>>>>>> $ git rev-list --count v5.13..v5.14-rc1 >>>>>>>> 13764 >>>>>>>> >>>>>>>> git bisect should find the offending commit in at most 14 tries. >>>>>>>> That's >>>>>>>> not too bad. >>>>>>> I correctly guesstimated that the problem got introduced by the usb >>>>>>> merge 79160a60 >>>>>>> >>>>>>> "Merge tag 'usb-5.14-rc1' of >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>>>>>> >>>>>>> 116 commits(7 bisects). >>>>>>> >>>>>>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>>>>>> >>>>>>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>>>>>> >>>>>>> Ruslan's 3 patches are related to each other so I reverted all >>>>>>> three 24f779da...e89bb428 and applied the reverts to rc1. >>>>>>> >>>>>>> I can confirm this indeed resolves the problem in rc1. >>>>>>> >>>>>>> Is late now, tomorrow evening I will apply the reverts to rc6. >>>>>> >>>>>> With these reverts rc6 works fine as well. >>>>>> >>>>>> So, where do we go from here? >>>>>> >>>>> >>>>> I know the patches have been tested on dwc2 (by me and others). I do >>>>> not know if Ruslan or Jerome tested them on dwc3 but probably not. >>>>> Ruslan has talked about RPi (my case too) and BeagleboneBlack, both >>>>> with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>>>> >>>>> The patches add a new EP-IN for async feedback. I am sorry I have not >>>>> followed your long thread (it started as unrelated to uac). Does the >>>>> problem appear with f_uac1 or f_uac2? Please how have you reached the >>>>> above problem? >>>> >>>> I'm sorry too. I first believed the issue was related to the patch >>>> mentioned in the subject line. >>>> >>>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>>> mode (there is a switch allowing to select host/device mode). When >>>> flipping the switch to device mode udev run a script: >>>> But as I am using configfs (excerpt follows) and just disabling the >>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>> exceeding the available resources. >>>> >>>> # Create directory structure >>>> mkdir "${GADGET_BASE_DIR}" >>>> cd "${GADGET_BASE_DIR}" >>>> mkdir -p configs/c.1/strings/0x409 >>>> mkdir -p strings/0x409 >>>> >>>> # Serial device >>>> mkdir functions/gser.usb0 >>>> ln -s functions/gser.usb0 configs/c.1/ >>>> ### >>>> >>>> # Ethernet device >>>> mkdir functions/eem.usb0 >>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>> ln -s functions/eem.usb0 configs/c.1/ >>>> >>>> # Mass Storage device >>>> mkdir functions/mass_storage.usb0 >>>> echo 1 > functions/mass_storage.usb0/stall >>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>> >>>> # UAC2 device >>>> mkdir functions/uac2.usb0 >>>> ln -s functions/uac2.usb0 configs/c.1 >>>> .... >>>> >>> >>> As you say, could perhaps the reason be that the extra EP-IN added in >>> those patches (previously 1, now 2 with the default config you use) >>> exceeds your EP-IN max count or available fifos somehow? You have a >>> number of functions initialized. If you change the load order of the >>> functions, do you get the error later with a different function? Just >>> guessing... >>> >>> You should be able to switch the default async EP-OUT (which configures >>> the new feedback EP-IN ) to adaptive EP-OUT (which requires no feedback >>> EP) with c_sync=8 parameter of f_uac2. >>> >>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAHQ6Lj4y$ >>> >>> >>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPAC7mfgo7$ >>> >>> >>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!PZHOWnH3HDs-9a9bz4KLDShZpsubSfG84fu3wEZyK4Q_Wvv2lhHKuk7LJpWPANdeuGIx$ >>> >>> >>> Does that fix the problem? >>> >> >> Hi Pavel, >> >> I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add >> feedback endpoint support") that Ferry reported the issue from >> bisection. I see at least a couple problems in the new UAC2 changes. >> >> 1) usb_ep_dequeue() is asynchronous. Don't free requests before the >> controller driver give them back. >> >> 2) Did you test with SuperSpeed? I don't see companion descriptor. >> >> Please fix them. > > Given it's late in the cycle I agree with Andy it would be best to > revert the series now. > > I will be happy to test on dwc3 when a fixed series arrives. Yes, I agree it's the best solution now. I have asked the patch devs Ruslan and Jerome for help with these issues, I am mostly a tester of the UAC2 gadget changes (with dwc2 USB2 only available for now). Best regards, Pavel.
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): > Op 19-08-2021 om 23:04 schreef Pavel Hofman: >> >> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>> Hi >>> >>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>> Hi, >>>> >>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>> Hi, >>>>> >>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>>> Hi, >>>>>> >>>>>> Op 16-08-2021 om 07:18 schreef Felipe Balbi: >>>>>>> Hi, >>>>>>> >>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>> Ferry Toth <fntoth@gmail.com> writes: >>>>>>>>>>>>>>>>>> Hardware name: Intel Corporation Merrifield/BODEGA >>>>>>>>>>>>>>>>>> BAY, BIOS 542 >>>>>>>>>>>>>>>>>> 2015.01.21:18.19.48 >>>>>>>>>>>>>>>>>> RIP: 0010:0x500000000 >>>>>>>>>>>>>>>>>> Code: Unable to access opcode bytes at RIP 0x4ffffffd6. >>>>>>>>>>>>>>>>>> RSP: 0018:ffffa4d00045fc28 EFLAGS: 00010046 >>>>>>>>>>>>>>>>>> RAX: 0000000500000000 RBX: ffff8cd546aed200 RCX: >>>>>>>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>>>>>>> RDX: 0000000000000000 RSI: ffff8cd547bfcae0 RDI: >>>>>>>>>>>>>>>>>> ffff8cd546aed200 >>>>>>>>>>>>>>>>>> RBP: ffff8cd547bfcae0 R08: 0000000000000000 R09: >>>>>>>>>>>>>>>>>> 0000000000000001 >>>>>>>>>>>>>>>>>> R10: ffff8cd541fd28c0 R11: 0000000000000000 R12: >>>>>>>>>>>>>>>>>> ffff8cd547342828 >>>>>>>>>>>>>>>>>> R13: ffff8cd546aed248 R14: 0000000000000000 R15: >>>>>>>>>>>>>>>>>> ffff8cd548b1d000 >>>>>>>>>>>>>>>>>> FS: 0000000000000000(0000) GS:ffff8cd57e200000(0000) >>>>>>>>>>>>>>>>>> knlGS:0000000000000000 >>>>>>>>>>>>>>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>>>>>>>>>>>>> CR2: 0000000500000000 CR3: 000000000311e000 CR4: >>>>>>>>>>>>>>>>>> 00000000001006f0 >>>>>>>>>>>>>>>>>> Call Trace: >>>>>>>>>>>>>>>>>> ? dwc3_remove_requests.constprop.0+0x14d/0x170 >>>>>>>>>>>>>>>>>> ? __dwc3_gadget_ep_disable+0x7a/0x160 >>>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_disable+0x3d/0xd0 >>>>>>>>>>>>>>>>>> ? usb_ep_disable+0x1c/0x >>>>>>>>>>>>>>>>>> ? u_audio_stop_capture+0x79/0x120 [u_audio] >>>>>>>>>>>>>>>>>> ? afunc_set_alt+0x73/0x80 [usb_f_uac2] >>>>>>>>>>> So this is triggered by a SetInterface request... >>>>>>>>>>> >>>>>>>>>>>>>>>>>> ? composite_setup+0x224/0x1b90 [libcomposite] >>>>>>>>>>>>>>>>>> ? __dwc3_gadget_kick_transfer+0x160/0x400 >>>>>>>>>>>>>>>>>> ? dwc3_gadget_ep_queue+0xf3/0x1a0 >>>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>>> ? configfs_composite_setup+0x6b/0x90 >>>>>>>>>>>>>>>>>> [libcomposite] >>>>>>>>>>>>>>>>>> ? dwc3_ep0_interrupt+0x459/0xa40 >>>>>>>>>>>>>>>>>> ? dwc3_thread_interrupt+0x8ee/0xf40 >>>>>>>>>>>>>>>>>> ? __schedule+0x235/0x6c0 >>>>>>>>>>>>>>>>>> ? disable_irq_nosync+0x10/0x10 >>>>>>>>>>>>>>>>>> ? irq_thread_fn+0x1b/0x60 >>>>>>>>>>>>>>>>>> ? irq_thread+0xc0/0x160 >>>>>>>>>>>>>>>>>> ? irq_thread_check_affinity+0x70/0x70 >>>>>>>>>>>>>>>>>> ? irq_forced_thread_fn+0x70/0x70 >>>>>>>>>>>>>>>>>> ? kthread+0x122/0x140 >>>>>>>>>>>>>>>>>> ? set_kthread_struct+0x40/0x40 >>>>>>>>>>>>>>>>>> ? ret_from_fork+0x22/0x30 >>>>>>>>>>>>>>>>> Do you mind enabling dwc3 traces and collecting them? >>>>>>>>>>>>>>>>> Trying to figure >>>>>>>>>>>>>>>>> out how we got here. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll try if I can get the same error by booting with USB >>>>>>>>>>>>>>>> in host mode >>>>>>>>>>>>>>>> and then switch to device mode. If so I can enable >>>>>>>>>>>>>>>> traces and collect as >>>>>>>>>>>>>>>> you explained me before. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll try before monday, as then I fly for a holiday and >>>>>>>>>>>>>>>> will not be >>>>>>>>>>>>>>>> available before rc5. >>>>>>>>>>>>>>> you can enable all of those with kernel cmdline :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> you need ftrace_dump_on_oops=1 and also need the correct >>>>>>>>>>>>>>> options on >>>>>>>>>>>>>>> trace_buf_size and trace_event. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> On Edison-Arduino I have a switch to go to device mode, >>>>>>>>>>>>>> after which >>>>>>>>>>>>>> udev triggers a script configure gadgets through configfs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to log following these instructions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs >>>>>>>>>>>>>> <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unfortunately the kernel crashes so badly I can not get to >>>>>>>>>>>>>> the ` cp >>>>>>>>>>>>>> /t/trace /root/trace.txt` line (after a while the watchdog >>>>>>>>>>>>>> kicks). >>>>>>>>>>>>>> >>>>>>>>>>>>>> What to do next? >>>>>>>>>>>>> Pass ftrace_dump_on_oops to kernel cmdline. >>>>>>>>>>>>> >>>>>>>>>>>> No sure if I did this right, on oops everything is pushed to >>>>>>>>>>>> console >>>>>>>>>>>> (115k2 serial), I hope nothing essential is lost. >>>>>>>>>>>> >>>>>>>>>>>> I copied the screen buffer to file see attached. >>>>>>>>>>> Thank you, I bet it took quite a some time :-) Anyway, >>>>>>>>>>> looking at >>>>>>>>>>> the logs around Set Interface requests, we can track every >>>>>>>>>>> endpoint >>>>>>>>>>> that's disabled. I'll take a guess and assume we're failing >>>>>>>>>>> at the last >>>>>>>>>>> Set Interface, that means we should have something odd with >>>>>>>>>>> ep6in, but >>>>>>>>>>> everything looks fine in the trace output: >>>>>>>>>>> >>>>>>>>>>> [ 75.823107] irq/14-d-596 0d... 42789194us : >>>>>>>>>>> dwc3_gadget_ep_enable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>>> [ 75.835472] irq/14-d-596 0d... 42789198us : >>>>>>>>>>> dwc3_alloc_request: ep6in: req 0000000002c71409 length 0/0 >>>>>>>>>>> zsI ==> 0 >>>>>>>>>>> [ 75.846416] irq/14-d-596 0d... 42789202us : >>>>>>>>>>> dwc3_ep_queue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 75.857360] irq/14-d-596 0d... 42789204us : >>>>>>>>>>> dwc3_alloc_request: ep6in: req 00000000a324f5d0 length 0/0 >>>>>>>>>>> zsI ==> 0 >>>>>>>>>>> [ 75.868301] irq/14-d-596 0d... 42789206us : >>>>>>>>>>> dwc3_ep_queue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 75.879244] irq/14-d-596 0d... 42789209us : >>>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>> [ 75.891880] irq/14-d-596 0d... 42789211us : >>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>>> [ 75.989131] irq/14-d-596 0d... 42789224us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 76.096261] irq/14-d-596 0d... 42789272us : >>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>> [Status Phase] >>>>>>>>>>> [ 76.107834] irq/14-d-596 0d... 42789275us : >>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>>> [ 76.122944] irq/14-d-596 0d... 42789277us : >>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>>> zsI ==> 0 >>>>>>>>>>> [ 76.134160] irq/14-d-596 0d... 42789280us : >>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>>> [ 76.231322] irq/14-d-596 0d... 42789292us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 76.297418] kworker/-23 0d... 42789670us : >>>>>>>>>>> dwc3_ep_queue: ep3in: req 0000000029586135 length 0/96 ZsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 76.308278] kworker/-23 0d... 42789695us : >>>>>>>>>>> dwc3_prepare_trb: ep3in: trb 00000000b81213d6 (E1:D0) buf >>>>>>>>>>> 0000000003b7a800 size 96 ctrl 00000811 (Hlcs:sC:normal) >>>>>>>>>>> [ 76.395294] kworker/-23 0d... 42789707us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep3in: cmd 'Update Transfer' [60007] >>>>>>>>>>> params 00000000 00000000 00000000 --> status: Successful >>>>>>>>>>> [ 76.471900] irq/14-d-596 0d... 42789842us : >>>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>>> [Setup Phase] >>>>>>>>>>> [ 76.489308] irq/14-d-596 0d... 42789845us : >>>>>>>>>>> dwc3_ctrl_req: Set Interface(Intf = 5, Alt.Setting = 0) >>>>>>>>>>> [ 76.505650] irq/14-d-596 0d... 42789851us : >>>>>>>>>>> dwc3_ep_dequeue: ep6in: req 0000000002c71409 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 76.523315] irq/14-d-596 0d... 42789854us : >>>>>>>>>>> dwc3_gadget_giveback: ep6in: req 0000000002c71409 length >>>>>>>>>>> 0/192 zsI ==> -104 >>>>>>>>>>> [ 76.541427] irq/14-d-596 0d... 42789857us : >>>>>>>>>>> dwc3_free_request: ep6in: req 0000000002c71409 length 0/192 >>>>>>>>>>> zsI ==> -104 >>>>>>>>>>> [ 76.559267] irq/14-d-596 0d... 42789859us : >>>>>>>>>>> dwc3_ep_dequeue: ep6in: req 00000000a324f5d0 length 0/192 zsI >>>>>>>>>>> ==> -115 >>>>>>>>>>> [ 76.576937] irq/14-d-596 0d... 42789861us : >>>>>>>>>>> dwc3_gadget_giveback: ep6in: req 00000000a324f5d0 length >>>>>>>>>>> 0/192 zsI ==> -104 >>>>>>>>>>> [ 76.595046] irq/14-d-596 0d... 42789862us : >>>>>>>>>>> dwc3_free_request: ep6in: req 00000000a324f5d0 length 0/192 >>>>>>>>>>> zsI ==> -104 >>>>>>>>>>> [ 76.612892] irq/14-d-596 0d... 42789865us : >>>>>>>>>>> dwc3_gadget_ep_disable: ep6in: mps 192/346 streams 16 burst 0 >>>>>>>>>>> ring 0/0 flags E:swbp:< >>>>>>>>>>> [ 76.665535] irq/14-d-596 0d... 42789873us : >>>>>>>>>>> dwc3_event: event (000020c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>> [ 76.684716] irq/14-d-596 0d... 42789875us : >>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c33 (HLcs:SC:status2) >>>>>>>>>>> [ 76.819195] irq/14-d-596 0d... 42789886us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 76.926324] irq/14-d-596 0d... 42789930us : >>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>> [Status Phase] >>>>>>>>>>> [ 76.937892] irq/14-d-596 0d... 42789933us : >>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c32 (hLcs:SC:status2) >>>>>>>>>>> [ 76.953003] irq/14-d-596 0d... 42789935us : >>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length 0/0 >>>>>>>>>>> zsI ==> 0 >>>>>>>>>>> [ 76.964217] irq/14-d-596 0d... 42789938us : >>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 8 ctrl 00000c23 (HLcs:SC:setup) >>>>>>>>>>> [ 77.061379] irq/14-d-596 0d... 42789950us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 77.168595] irq/14-d-596 0d... 42790509us : >>>>>>>>>>> dwc3_event: event (0000c040): ep0out: Transfer Complete (sIL) >>>>>>>>>>> [Setup Phase] >>>>>>>>>>> [ 77.180159] irq/14-d-596 0d... 42790512us : >>>>>>>>>>> dwc3_ctrl_req: Get String Descriptor(Index = 18, Length = 255) >>>>>>>>>>> [ 77.190578] irq/14-d-596 0d... 42790537us : >>>>>>>>>>> dwc3_prepare_trb: ep0in: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 0000000003b68000 size 36 ctrl 00000c53 (HLcs:SC:data) >>>>>>>>>>> [ 77.287648] irq/14-d-596 0d... 42790550us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0in: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> [ 77.333107] irq/14-d-596 0d... 42790557us : >>>>>>>>>>> dwc3_event: event (000010c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Data Phase] >>>>>>>>>>> [ 77.407223] irq/14-d-596 0d... 42790575us : >>>>>>>>>>> dwc3_event: event (000090c2): ep0in: Transfer Not Ready [0] >>>>>>>>>>> (Active) [Data Phase] >>>>>>>>>>> [ 77.480985] irq/14-d-596 0d... 42790588us : >>>>>>>>>>> dwc3_event: event (0000c042): ep0in: Transfer Complete (sIL) >>>>>>>>>>> [Data Phase] >>>>>>>>>>> [ 77.492376] irq/14-d-596 0d... 42790590us : >>>>>>>>>>> dwc3_complete_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 0000000003b68000 size 0 ctrl 00000c52 (hLcs:SC:data) >>>>>>>>>>> [ 77.507221] irq/14-d-596 0d... 42790595us : >>>>>>>>>>> dwc3_gadget_giveback: ep0out: req 00000000cb1bd3cd length >>>>>>>>>>> 36/36 ZsI ==> 0 >>>>>>>>>>> [ 77.518609] irq/14-d-596 0d... 42790597us : >>>>>>>>>>> dwc3_event: event (000020c0): ep0out: Transfer Not Ready [0] >>>>>>>>>>> (Not Active) [Status Phase] >>>>>>>>>>> [ 77.531332] irq/14-d-596 0d... 42790598us : >>>>>>>>>>> dwc3_prepare_trb: ep0out: trb 000000004c0ae319 (E0:D0) buf >>>>>>>>>>> 000000001bded000 size 0 ctrl 00000c43 (HLcs:SC:status3) >>>>>>>>>>> [ 77.628669] irq/14-d-596 0d... 42790609us : >>>>>>>>>>> dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params >>>>>>>>>>> 00000000 1bded000 00000000 --> status: Successful >>>>>>>>>>> >>>>>>>>>>> Do you mind adding a few prints in dwc3_remove_requests to >>>>>>>>>>> tell us which >>>>>>>>>>> endpoint is being processed? Then we'll know for sure which >>>>>>>>>>> one caused >>>>>>>>>>> the crash. >>>>>>>>>>> >>>>>>>>>> I wouldn't mind but am leaving on a holiday, won't have time >>>>>>>>>> until 6 aug. >>>>>>>>> not a problem, we'll still be here when you're back :-) >>>>>>>> Well, let's go then :-) >>>>>>>> >>>>>>>> To get back in the mood I have retested 5.13.0, 5.14.0-rc1, >>>>>>>> 5.14.0-rc2 >>>>>>>> and 5.14.0-rc5. >>>>>>>> >>>>>>>> I find that 5.13.0 works fine, and the issue starts from >>>>>>>> 5.14.0-rc1. >>>>>>> That's great finding. We have a bisection point. There are a >>>>>>> total of >>>>>>> 13764 commits between v5.13 and v5.14-rc1 >>>>>>> >>>>>>> $ git rev-list --count v5.13..v5.14-rc1 >>>>>>> 13764 >>>>>>> >>>>>>> git bisect should find the offending commit in at most 14 tries. >>>>>>> That's >>>>>>> not too bad. >>>>>> I correctly guesstimated that the problem got introduced by the >>>>>> usb merge 79160a60 >>>>>> >>>>>> "Merge tag 'usb-5.14-rc1' of >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb" >>>>>> >>>>>> 116 commits(7 bisects). >>>>>> >>>>>> 24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit >>>>>> >>>>>> "usb: gadget: f_uac2/u_audio: add feedback endpoint support" >>>>>> >>>>>> Ruslan's 3 patches are related to each other so I reverted all >>>>>> three 24f779da...e89bb428 and applied the reverts to rc1. >>>>>> >>>>>> I can confirm this indeed resolves the problem in rc1. >>>>>> >>>>>> Is late now, tomorrow evening I will apply the reverts to rc6. >>>>> >>>>> With these reverts rc6 works fine as well. >>>>> >>>>> So, where do we go from here? >>>>> >>>> >>>> I know the patches have been tested on dwc2 (by me and others). I >>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, >>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>>> >>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>> not followed your long thread (it started as unrelated to uac). Does >>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>> reached the above problem? >>> >>> I'm sorry too. I first believed the issue was related to the patch >>> mentioned in the subject line. >>> >>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>> mode (there is a switch allowing to select host/device mode). When >>> flipping the switch to device mode udev run a script: >>> But as I am using configfs (excerpt follows) and just disabling the >>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>> exceeding the available resources. >>> >>> # Create directory structure >>> mkdir "${GADGET_BASE_DIR}" >>> cd "${GADGET_BASE_DIR}" >>> mkdir -p configs/c.1/strings/0x409 >>> mkdir -p strings/0x409 >>> >>> # Serial device >>> mkdir functions/gser.usb0 >>> ln -s functions/gser.usb0 configs/c.1/ >>> ### >>> >>> # Ethernet device >>> mkdir functions/eem.usb0 >>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>> ln -s functions/eem.usb0 configs/c.1/ >>> >>> # Mass Storage device >>> mkdir functions/mass_storage.usb0 >>> echo 1 > functions/mass_storage.usb0/stall >>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>> ln -s functions/mass_storage.usb0 configs/c.1/ >>> >>> # UAC2 device >>> mkdir functions/uac2.usb0 >>> ln -s functions/uac2.usb0 configs/c.1 >>> .... >>> >> >> As you say, could perhaps the reason be that the extra EP-IN added in >> those patches (previously 1, now 2 with the default config you use) >> exceeds your EP-IN max count or available fifos somehow? You have a >> number of functions initialized. If you change the load order of the >> functions, do you get the error later with a different function? Just >> guessing... >> >> You should be able to switch the default async EP-OUT (which >> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires >> no feedback EP) with c_sync=8 parameter of f_uac2. >> >> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 >> >> >> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 >> >> >> https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 >> >> >> Does that fix the problem? > > Not sure how to do that. Do you mean the module should have a parameter > called c_sync? `modinfo` list no parameters for usb_f_uac2. > Those are configfs params, not available in modinfo. I checked and the value is "adaptive" https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c#L1312 In your configfs script: # UAC2 device mkdir functions/uac2.usb0 ln -s functions/uac2.usb0 configs/c.1 On the USB Host: cat /proc/asound/Gadget/stream: Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 0x01 (1 OUT) (ASYNC) Rates: 64000 Data packet interval: 125 us Bits: 16 Channel map: FL FR Sync Endpoint: 0x82 (2 IN) Sync EP Interface: 1 Sync EP Altset: 1 Implicit Feedback Mode: No lsusb -v -d 1d6b:0104 | | grep EP.*IN bEndpointAddress 0x81 EP 1 IN bEndpointAddress 0x82 EP 2 IN bEndpointAddress 0x83 EP 3 IN I have additional patches applied which define controls via EP IN interrupt mode, not part of that patchset. Switching to the adaptive mode: # UAC2 device mkdir functions/uac2.usb0 echo "adaptive" > functions/uac2.usb0/c_sync ln -s functions/uac2.usb0 configs/c.1 On the USB Host: cat /proc/asound/Gadget/stream: Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 0x01 (1 OUT) (ADAPTIVE) Rates: 64000 Data packet interval: 125 us Bits: 16 Channel map: FL FR lsusb -v -d 1d6b:0104 | grep EP.*IN bEndpointAddress 0x81 EP 1 IN bEndpointAddress 0x82 EP 2 IN The feedback EP-IN is gone because the mode is adaptive now. If you think the new input endpoints should not be created by default for resource-compatibility reasons, the adaptive mode can be set by default in a fixed patch. Also the patches defining the new interrupt endpoints can have the controls disabled by default (and not allocate the EP-IN). These patches on top of the async patches are already accepted by Greg for usb-next branch https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb/+/eaf6cbe0992052a46d93047dc122fad5126aa3bd . That's why I was trying to sort out the async patches without reverting them as it will call for more reverts. Thanks, Pavel.
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote: > Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): > > Op 19-08-2021 om 23:04 schreef Pavel Hofman: > >> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): > >>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: > >>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): > >>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: ... > >>>>> So, where do we go from here? > >>>> > >>>> I know the patches have been tested on dwc2 (by me and others). I > >>>> do not know if Ruslan or Jerome tested them on dwc3 but probably > >>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, > >>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? > >>>> > >>>> The patches add a new EP-IN for async feedback. I am sorry I have > >>>> not followed your long thread (it started as unrelated to uac). Does > >>>> the problem appear with f_uac1 or f_uac2? Please how have you > >>>> reached the above problem? > >>> > >>> I'm sorry too. I first believed the issue was related to the patch > >>> mentioned in the subject line. > >>> > >>> The problem appaers with f_uac2. I bost Edison_Arduino board in host > >>> mode (there is a switch allowing to select host/device mode). When > >>> flipping the switch to device mode udev run a script: > >>> But as I am using configfs (excerpt follows) and just disabling the > >>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or > >>> exceeding the available resources. > >>> > >>> # Create directory structure > >>> mkdir "${GADGET_BASE_DIR}" > >>> cd "${GADGET_BASE_DIR}" > >>> mkdir -p configs/c.1/strings/0x409 > >>> mkdir -p strings/0x409 > >>> > >>> # Serial device > >>> mkdir functions/gser.usb0 > >>> ln -s functions/gser.usb0 configs/c.1/ > >>> ### > >>> > >>> # Ethernet device > >>> mkdir functions/eem.usb0 > >>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr > >>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr > >>> ln -s functions/eem.usb0 configs/c.1/ > >>> > >>> # Mass Storage device > >>> mkdir functions/mass_storage.usb0 > >>> echo 1 > functions/mass_storage.usb0/stall > >>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom > >>> echo 0 > functions/mass_storage.usb0/lun.0/ro > >>> echo 0 > functions/mass_storage.usb0/lun.0/nofua > >>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file > >>> ln -s functions/mass_storage.usb0 configs/c.1/ > >>> > >>> # UAC2 device > >>> mkdir functions/uac2.usb0 > >>> ln -s functions/uac2.usb0 configs/c.1 > >>> .... > >> > >> As you say, could perhaps the reason be that the extra EP-IN added in > >> those patches (previously 1, now 2 with the default config you use) > >> exceeds your EP-IN max count or available fifos somehow? You have a > >> number of functions initialized. If you change the load order of the > >> functions, do you get the error later with a different function? Just > >> guessing... > >> > >> You should be able to switch the default async EP-OUT (which > >> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires > >> no feedback EP) with c_sync=8 parameter of f_uac2. > >> > >> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 > >> > >> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 > >> > >> https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 > >> > >> Does that fix the problem? > > > > Not sure how to do that. Do you mean the module should have a parameter > > called c_sync? `modinfo` list no parameters for usb_f_uac2. > > Those are configfs params, not available in modinfo. > > I checked and the value is "adaptive" > https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c#L1312 > In your configfs script: Kernel shouldn't crash with any available set of configuration parameters, right? So, even if the parameter would fix the crash the series is buggy and has to be reverted in my opinion. > # UAC2 device > mkdir functions/uac2.usb0 > ln -s functions/uac2.usb0 configs/c.1 > > > On the USB Host: > cat /proc/asound/Gadget/stream: > Playback: > Status: Stop > Interface 1 > Altset 1 > Format: S16_LE > Channels: 2 > Endpoint: 0x01 (1 OUT) (ASYNC) > Rates: 64000 > Data packet interval: 125 us > Bits: 16 > Channel map: FL FR > Sync Endpoint: 0x82 (2 IN) > Sync EP Interface: 1 > Sync EP Altset: 1 > Implicit Feedback Mode: No > > lsusb -v -d 1d6b:0104 | | grep EP.*IN > bEndpointAddress 0x81 EP 1 IN > bEndpointAddress 0x82 EP 2 IN > bEndpointAddress 0x83 EP 3 IN > > I have additional patches applied which define controls via EP IN > interrupt mode, not part of that patchset. > > Switching to the adaptive mode: > # UAC2 device > mkdir functions/uac2.usb0 > echo "adaptive" > functions/uac2.usb0/c_sync > ln -s functions/uac2.usb0 configs/c.1 > > On the USB Host: > cat /proc/asound/Gadget/stream: > Playback: > Status: Stop > Interface 1 > Altset 1 > Format: S16_LE > Channels: 2 > Endpoint: 0x01 (1 OUT) (ADAPTIVE) > Rates: 64000 > Data packet interval: 125 us > Bits: 16 > Channel map: FL FR > > lsusb -v -d 1d6b:0104 | grep EP.*IN > bEndpointAddress 0x81 EP 1 IN > bEndpointAddress 0x82 EP 2 IN > > The feedback EP-IN is gone because the mode is adaptive now. > > If you think the new input endpoints should not be created by default > for resource-compatibility reasons, the adaptive mode can be set by > default in a fixed patch. Would it be possible to change the mode? If so, then the user may configure it and crash again. > Also the patches defining the new interrupt endpoints can have the > controls disabled by default (and not allocate the EP-IN). These patches > on top of the async patches are already accepted by Greg for usb-next > branch > https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb/+/eaf6cbe0992052a46d93047dc122fad5126aa3bd > . That's why I was trying to sort out the async patches without > reverting them as it will call for more reverts.
Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): > On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote: >> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: > > ... > >>>>>>> So, where do we go from here? >>>>>> >>>>>> I know the patches have been tested on dwc2 (by me and others). I >>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, >>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>>>>> >>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>> not followed your long thread (it started as unrelated to uac). Does >>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>> reached the above problem? >>>>> >>>>> I'm sorry too. I first believed the issue was related to the patch >>>>> mentioned in the subject line. >>>>> >>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>>>> mode (there is a switch allowing to select host/device mode). When >>>>> flipping the switch to device mode udev run a script: >>>>> But as I am using configfs (excerpt follows) and just disabling the >>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>> exceeding the available resources. >>>>> >>>>> # Create directory structure >>>>> mkdir "${GADGET_BASE_DIR}" >>>>> cd "${GADGET_BASE_DIR}" >>>>> mkdir -p configs/c.1/strings/0x409 >>>>> mkdir -p strings/0x409 >>>>> >>>>> # Serial device >>>>> mkdir functions/gser.usb0 >>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>> ### >>>>> >>>>> # Ethernet device >>>>> mkdir functions/eem.usb0 >>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>> >>>>> # Mass Storage device >>>>> mkdir functions/mass_storage.usb0 >>>>> echo 1 > functions/mass_storage.usb0/stall >>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>> >>>>> # UAC2 device >>>>> mkdir functions/uac2.usb0 >>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>> .... >>>> >>>> As you say, could perhaps the reason be that the extra EP-IN added in >>>> those patches (previously 1, now 2 with the default config you use) >>>> exceeds your EP-IN max count or available fifos somehow? You have a >>>> number of functions initialized. If you change the load order of the >>>> functions, do you get the error later with a different function? Just >>>> guessing... >>>> >>>> You should be able to switch the default async EP-OUT (which >>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires >>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>> >>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 >>>> >>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 >>>> >>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 >>>> >>>> Does that fix the problem? >>> >>> Not sure how to do that. Do you mean the module should have a parameter >>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >> >> Those are configfs params, not available in modinfo. >> >> I checked and the value is "adaptive" >> https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c#L1312 > >> In your configfs script: > > Kernel shouldn't crash with any available set of configuration > parameters, right? So, even if the parameter would fix the crash the > series is buggy and has to be reverted in my opinion. Sure, no problem with reverting. I am just trying to start up some troubleshooting. A resource exhaustion was mentioned here, that's why I suggested a way to test the patch with the original number of endpoints allocated. I do not get any crashes on my setup which uses fewer gadget functions. That's why I asked what happens if the functions load order is changed. I am afraid this thread is so complex that the actual problem has been burried in the history. Again, I am not the author of the patches, my USB knowledge is way unsufficient for that. I am trying to make them work as they are important and make the existing audio gadget actually usable. Thanks, Pavel.
Op 23-08-2021 om 17:34 schreef Pavel Hofman: > > > Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >> <pavel.hofman@ivitera.com> wrote: >>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >> >> ... >> >>>>>>>> So, where do we go from here? >>>>>>> >>>>>>> I know the patches have been tested on dwc2 (by me and others). I >>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, >>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>> dwc3? >>>>>>> >>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>> not followed your long thread (it started as unrelated to uac). Does >>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>> reached the above problem? >>>>>> >>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>> mentioned in the subject line. >>>>>> >>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>> flipping the switch to device mode udev run a script: >>>>>> But as I am using configfs (excerpt follows) and just disabling the >>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>> exceeding the available resources. >>>>>> >>>>>> # Create directory structure >>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>> cd "${GADGET_BASE_DIR}" >>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>> mkdir -p strings/0x409 >>>>>> >>>>>> # Serial device >>>>>> mkdir functions/gser.usb0 >>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>> ### >>>>>> >>>>>> # Ethernet device >>>>>> mkdir functions/eem.usb0 >>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>> >>>>>> # Mass Storage device >>>>>> mkdir functions/mass_storage.usb0 >>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>> >>>>>> # UAC2 device >>>>>> mkdir functions/uac2.usb0 >>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>> .... >>>>> >>>>> As you say, could perhaps the reason be that the extra EP-IN added in >>>>> those patches (previously 1, now 2 with the default config you use) >>>>> exceeds your EP-IN max count or available fifos somehow? You have a >>>>> number of functions initialized. If you change the load order of the >>>>> functions, do you get the error later with a different function? Just >>>>> guessing... >>>>> >>>>> You should be able to switch the default async EP-OUT (which >>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires >>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>> >>>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 >>>>> >>>>> >>>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 >>>>> >>>>> >>>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 >>>>> >>>>> >>>>> Does that fix the problem? >>>> >>>> Not sure how to do that. Do you mean the module should have a parameter >>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>> >>> Those are configfs params, not available in modinfo. >>> >>> I checked and the value is "adaptive" >>> https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c#L1312 >>> >> >>> In your configfs script: >> >> Kernel shouldn't crash with any available set of configuration >> parameters, right? So, even if the parameter would fix the crash the >> series is buggy and has to be reverted in my opinion. I will send in reverts tomorrow, unless someone has a better idea. > Sure, no problem with reverting. I am just trying to start up some > troubleshooting. A resource exhaustion was mentioned here, that's why I > suggested a way to test the patch with the original number of endpoints > allocated. I do not get any crashes on my setup which uses fewer gadget > functions. That's why I asked what happens if the functions load order > is changed. I am afraid this thread is so complex that the actual > problem has been burried in the history. I found some time to test your suggestions. So below 3 cases on rc6 with the reverts removed again: 1) the original configfs setup script 2) with uac2 moved to the top so it is created first (I hope) 3) same as 1) but with c_sync = adaptive Summary: 1) still shows the crash as expected 2) has no effect 3) resolves the issue as you expect 1) Normal configfs order (uac2 last) ------------------------------------ root@yuna:~# [ 50.975986] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 50.983125] #PF: supervisor write access in kernel mode [ 50.988470] #PF: error_code(0x0002) - not-present page [ 50.993723] PGD 0 P4D 0 [ 50.996327] Oops: 0002 [#1] SMP PTI [ 50.999899] CPU: 0 PID: 596 Comm: irq/14-dwc3 Tainted: G W 5.14.0-rc6-edison-acpi-standard #1 [ 51.009948] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 51.018922] RIP: 0010:dwc3_gadget_del_and_unmap_request+0x19/0xe0 [ 51.025169] Code: 8b 78 08 e8 89 d6 ff ff 48 89 ef 5d e9 f0 61 a6 ff 41 54 55 48 89 f5 53 48 8b 46 68 48 89 fb 48 8b 4e 60 4c 8b a7 90 00 00 00 <48> 89 41 08 48 89 08 48 b8 00 01 00 00 00 00 ad de 80 a6 b4 00 00 [ 51.044345] RSP: 0000:ffffb2ea40313c10 EFLAGS: 00010093 [ 51.049692] RAX: ffff94dc03aa2c48 RBX: ffff94dc03aa2c00 RCX: 0000000000000000 [ 51.056985] RDX: 00000000ffffff94 RSI: ffff94dc02303d80 RDI: ffff94dc03aa2c00 [ 51.064278] RBP: ffff94dc02303d80 R08: 0000000000000014 R09: 0000000000000001 [ 51.071572] R10: ffff94dc02303d80 R11: 0000000000000001 R12: ffff94dc08b43028 [ 51.078864] R13: ffff94dc03aa2c48 R14: 0000000000000000 R15: ffff94dc031b3c00 [ 51.086159] FS: 0000000000000000(0000) GS:ffff94dc3e200000(0000) knlGS:0000000000000000 [ 51.094429] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 51.100304] CR2: 0000000000000008 CR3: 0000000007e20000 CR4: 00000000001006f0 [ 51.107596] Call Trace: [ 51.110103] dwc3_remove_requests.constprop.0+0x12f/0x170 [ 51.115637] __dwc3_gadget_ep_disable+0x7a/0x160 [ 51.120366] dwc3_gadget_ep_disable+0x3d/0xd0 [ 51.124827] usb_ep_disable+0x1c/0x70 [ 51.128586] u_audio_stop_capture+0x79/0x120 [u_audio] [ 51.133857] afunc_set_alt+0x73/0x80 [usb_f_uac2] [ 51.138683] composite_setup+0x224/0x1b90 [libcomposite] [ 51.144137] ? __dwc3_gadget_kick_transfer+0x160/0x400 [ 51.149404] ? configfs_composite_setup+0x6b/0x90 [libcomposite] [ 51.155562] configfs_composite_setup+0x6b/0x90 [libcomposite] [ 51.161544] dwc3_ep0_interrupt+0x466/0xa70 [ 51.165831] dwc3_thread_interrupt+0x829/0xe90 [ 51.170379] ? __schedule+0x235/0x6c0 [ 51.174138] ? disable_irq_nosync+0x10/0x10 [ 51.178425] irq_thread_fn+0x1b/0x60 [ 51.182092] irq_thread+0xc0/0x160 [ 51.185580] ? irq_thread_check_affinity+0x70/0x70 [ 51.190486] ? irq_forced_thread_fn+0x70/0x70 [ 51.194948] kthread+0x122/0x140 [ 51.198259] ? set_kthread_struct+0x40/0x40 [ 51.202545] ret_from_fork+0x22/0x30 [ 51.206214] Modules linked in: usb_f_uac2 u_audio usb_f_mass_storage usb_f_eem u_ether usb_f_serial u_serial libcomposite rfcomm iptable_nat bnep spi_pxa2xx_platform snd_sof_nocodec dw_dmac smsc smsc95xx intel_mrfld_pwrbtn intel_mrfld_adc dw_dmac_pci pwm_lpss_pci dw_dmac_core pwm_lpss snd_sof_pci_intel_tng snd_sof_pci snd_sof_intel_ipc snd_sof_intel_atom snd_sof snd_sof_xtensa_dsp snd_soc_acpi spi_pxa2xx_pci brcmfmac brcmutil hci_uart btbcm ti_ads7950 industrialio_triggered_buffer kfifo_buf leds_gpio ledtrig_timer ledtrig_heartbeat mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci led_class mmc_core intel_soc_pmic_mrfld btrfs libcrc32c xor zstd_compress zlib_deflate raid6_pq [ 51.267592] CR2: 0000000000000008 [ 51.270981] ---[ end trace 135abe76b19414cc ]--- ferry@delfion:~$ cat /proc/asound/Gadget/stream0 USBArmory USBArmory Gadget at usb-0000:00:14.0-5, high speed : USB Audio Playback: Status: Stop Interface 4 Altset 1 Format: S16_LE Channels: 2 Endpoint: 0x04 (4 OUT) (ASYNC) Rates: 64000 Data packet interval: 1000 us Bits: 16 Channel map: FL FR Sync Endpoint: 0x85 (5 IN) Sync EP Interface: 4 Sync EP Altset: 1 Implicit Feedback Mode: No Capture: Status: Stop Interface 5 Altset 1 Format: S16_LE Channels: 2 Endpoint: 0x86 (6 IN) (ASYNC) Rates: 48000 Data packet interval: 1000 us Bits: 16 Channel map: FL FR root@delfion:~# lsusb -v -d 1d6b:0104 | grep EP.*IN bEndpointAddress 0x82 EP 2 IN bEndpointAddress 0x83 EP 3 IN bEndpointAddress 0x84 EP 4 IN bEndpointAddress 0x85 EP 5 IN bEndpointAddress 0x86 EP 6 IN can't get debug descriptor: Resource temporarily unavailable cannot read device status, Resource temporarily unavailable (11) 2) uac2 first in configfs ------------------------- root@yuna:~# [ 172.094997] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 172.102136] #PF: supervisor write access in kernel mode [ 172.107480] #PF: error_code(0x0002) - not-present page [ 172.112733] PGD 0 P4D 0 [ 172.115338] Oops: 0002 [#1] SMP PTI [ 172.118909] CPU: 0 PID: 604 Comm: irq/14-dwc3 Tainted: G W 5.14.0-rc6-edison-acpi-standard #1 [ 172.128958] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 172.137931] RIP: 0010:dwc3_gadget_del_and_unmap_request+0x19/0xe0 [ 172.144175] Code: 8b 78 08 e8 89 d6 ff ff 48 89 ef 5d e9 f0 61 a6 ff 41 54 55 48 89 f5 53 48 8b 46 68 48 89 fb 48 8b 4e 60 4c 8b a7 90 00 00 00 <48> 89 41 08 48 89 08 48 b8 00 01 00 00 00 00 ad de 80 a6 b4 00 00 [ 172.163352] RSP: 0018:ffffa1438053bc10 EFLAGS: 00010097 [ 172.168698] RAX: ffff9b76c7ec3848 RBX: ffff9b76c7ec3800 RCX: 0000000000000000 [ 172.175990] RDX: 00000000ffffff94 RSI: ffff9b76c79ffc00 RDI: ffff9b76c7ec3800 [ 172.183283] RBP: ffff9b76c79ffc00 R08: 0000000000000014 R09: 0000000000000001 [ 172.190577] R10: ffff9b76c79ffc00 R11: 0000000000000002 R12: ffff9b76c8a66028 [ 172.197870] R13: ffff9b76c7ec3848 R14: 0000000000000000 R15: ffff9b76c7255c00 [ 172.205163] FS: 0000000000000000(0000) GS:ffff9b76fe200000(0000) knlGS:0000000000000000 [ 172.213436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 172.219309] CR2: 0000000000000008 CR3: 000000001360c000 CR4: 00000000001006f0 [ 172.226600] Call Trace: [ 172.229107] dwc3_remove_requests.constprop.0+0x12f/0x170 [ 172.234640] __dwc3_gadget_ep_disable+0x7a/0x160 [ 172.239372] dwc3_gadget_ep_disable+0x3d/0xd0 [ 172.243834] usb_ep_disable+0x1c/0x70 [ 172.247590] u_audio_stop_capture+0x79/0x120 [u_audio] [ 172.252862] afunc_set_alt+0x73/0x80 [usb_f_uac2] [ 172.257688] composite_setup+0x224/0x1b90 [libcomposite] [ 172.263143] ? __dwc3_gadget_kick_transfer+0x160/0x400 [ 172.268410] ? configfs_composite_setup+0x6b/0x90 [libcomposite] [ 172.274568] configfs_composite_setup+0x6b/0x90 [libcomposite] [ 172.280551] dwc3_ep0_interrupt+0x466/0xa70 [ 172.284834] ? newidle_balance.constprop.0+0xfa/0x380 [ 172.290008] dwc3_thread_interrupt+0x829/0xe90 [ 172.294561] ? __schedule+0x235/0x6c0 [ 172.298316] ? disable_irq_nosync+0x10/0x10 [ 172.302606] irq_thread_fn+0x1b/0x60 [ 172.306272] irq_thread+0xc0/0x160 [ 172.309761] ? irq_thread_check_affinity+0x70/0x70 [ 172.314666] ? irq_forced_thread_fn+0x70/0x70 [ 172.319128] kthread+0x122/0x140 [ 172.322440] ? set_kthread_struct+0x40/0x40 [ 172.326724] ret_from_fork+0x22/0x30 [ 172.330390] Modules linked in: usb_f_mass_storage usb_f_eem u_ether usb_f_serial u_serial usb_f_uac2 u_audio libcomposite rfcomm iptable_nat bnep snd_sof_nocodec spi_pxa2xx_platform dw_dmac smsc smsc95xx pwm_lpss_pci pwm_lpss snd_sof_pci_intel_tng snd_sof_pci snd_sof_intel_ipc intel_mrfld_pwrbtn snd_sof_intel_atom intel_mrfld_adc dw_dmac_pci dw_dmac_core snd_sof snd_sof_xtensa_dsp snd_soc_acpi spi_pxa2xx_pci brcmfmac brcmutil hci_uart leds_gpio btbcm ti_ads7950 industrialio_triggered_buffer kfifo_buf ledtrig_timer ledtrig_heartbeat mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci led_class mmc_core intel_soc_pmic_mrfld btrfs libcrc32c xor zstd_compress zlib_deflate raid6_pq [ 172.391766] CR2: 0000000000000008 [ 172.395157] ---[ end trace 8272319264d5a2c0 ]--- 3) With c_sync = adaptive ------------------------- # UAC2 device mkdir functions/uac2.usb0 echo "adaptive" > functions/uac2.usb0/c_sync ln -s functions/uac2.usb0 configs/c.1 (No BUG) root@delfion:~# cat /proc/asound/Gadget/stream0 USBArmory USBArmory Gadget at usb-0000:00:14.0-5, high speed : USB Audio Playback: Status: Stop Interface 4 Altset 1 Format: S16_LE Channels: 2 Endpoint: 0x04 (4 OUT) (ADAPTIVE) Rates: 64000 Data packet interval: 1000 us Bits: 16 Channel map: FL FR Capture: Status: Stop Interface 5 Altset 1 Format: S16_LE Channels: 2 Endpoint: 0x85 (5 IN) (ASYNC) Rates: 48000 Data packet interval: 1000 us Bits: 16 Channel map: FL FR root@delfion:~# lsusb -v -d 1d6b:0104 | grep EP.*IN bEndpointAddress 0x82 EP 2 IN bEndpointAddress 0x83 EP 3 IN bEndpointAddress 0x84 EP 4 IN bEndpointAddress 0x85 EP 5 IN can't get debug descriptor: Resource temporarily unavailable > Again, I am not the author of the patches, my USB knowledge is way > unsufficient for that. I am trying to make them work as they are > important and make the existing audio gadget actually usable. Thanks for the suggestions, I didn't think to set params through configfs. Maybe this will help in tracing the root cause, although that's way over my head. > Thanks, > > Pavel.
Pavel Hofman wrote: > > > Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >> <pavel.hofman@ivitera.com> wrote: >>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >> >> ... >> >>>>>>>> So, where do we go from here? >>>>>>> >>>>>>> I know the patches have been tested on dwc2 (by me and others). I >>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, >>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>> dwc3? >>>>>>> >>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>> not followed your long thread (it started as unrelated to uac). Does >>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>> reached the above problem? >>>>>> >>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>> mentioned in the subject line. >>>>>> >>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>> flipping the switch to device mode udev run a script: >>>>>> But as I am using configfs (excerpt follows) and just disabling the >>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>> exceeding the available resources. >>>>>> >>>>>> # Create directory structure >>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>> cd "${GADGET_BASE_DIR}" >>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>> mkdir -p strings/0x409 >>>>>> >>>>>> # Serial device >>>>>> mkdir functions/gser.usb0 >>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>> ### >>>>>> >>>>>> # Ethernet device >>>>>> mkdir functions/eem.usb0 >>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>> >>>>>> # Mass Storage device >>>>>> mkdir functions/mass_storage.usb0 >>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>> >>>>>> # UAC2 device >>>>>> mkdir functions/uac2.usb0 >>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>> .... >>>>> >>>>> As you say, could perhaps the reason be that the extra EP-IN added in >>>>> those patches (previously 1, now 2 with the default config you use) >>>>> exceeds your EP-IN max count or available fifos somehow? You have a >>>>> number of functions initialized. If you change the load order of the >>>>> functions, do you get the error later with a different function? Just >>>>> guessing... >>>>> >>>>> You should be able to switch the default async EP-OUT (which >>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires >>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>> >>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRbWQzLcU$ >>>>> >>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRfP5TdZC$ >>>>> >>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRejzMbWO$ >>>>> >>>>> Does that fix the problem? >>>> >>>> Not sure how to do that. Do you mean the module should have a parameter >>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>> >>> Those are configfs params, not available in modinfo. >>> >>> I checked and the value is "adaptive" >>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c*L1312__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRTETcbsN$ >> >> >>> In your configfs script: >> >> Kernel shouldn't crash with any available set of configuration >> parameters, right? So, even if the parameter would fix the crash the >> series is buggy and has to be reverted in my opinion. > > Sure, no problem with reverting. I am just trying to start up some > troubleshooting. A resource exhaustion was mentioned here, that's why I > suggested a way to test the patch with the original number of endpoints > allocated. I do not get any crashes on my setup which uses fewer gadget > functions. That's why I asked what happens if the functions load order > is changed. I am afraid this thread is so complex that the actual > problem has been burried in the history. > As I pointed out previously, the crash is probably because of f_uac2 prematurely freeing feedback request before its completion. usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous call so you didn't get a crash. > Again, I am not the author of the patches, my USB knowledge is way > unsufficient for that. I am trying to make them work as they are > important and make the existing audio gadget actually usable. > I'm not sure how easy it is for you to obtain/test a device with dwc3, but it would be great to also have it as part of your testing suite. :) Thanks, Thinh
Dne 24. 08. 21 v 0:50 Thinh Nguyen napsal(a): > Pavel Hofman wrote: >> >> >> Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >>> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >>> <pavel.hofman@ivitera.com> wrote: >>>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>> >>> ... >>> >>>>>>>>> So, where do we go from here? >>>>>>>> >>>>>>>> I know the patches have been tested on dwc2 (by me and others). I >>>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, >>>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>>> dwc3? >>>>>>>> >>>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>>> not followed your long thread (it started as unrelated to uac). Does >>>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>>> reached the above problem? >>>>>>> >>>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>>> mentioned in the subject line. >>>>>>> >>>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>>> flipping the switch to device mode udev run a script: >>>>>>> But as I am using configfs (excerpt follows) and just disabling the >>>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>>> exceeding the available resources. >>>>>>> >>>>>>> # Create directory structure >>>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>>> cd "${GADGET_BASE_DIR}" >>>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>>> mkdir -p strings/0x409 >>>>>>> >>>>>>> # Serial device >>>>>>> mkdir functions/gser.usb0 >>>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>>> ### >>>>>>> >>>>>>> # Ethernet device >>>>>>> mkdir functions/eem.usb0 >>>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>>> >>>>>>> # Mass Storage device >>>>>>> mkdir functions/mass_storage.usb0 >>>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>>> >>>>>>> # UAC2 device >>>>>>> mkdir functions/uac2.usb0 >>>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>>> .... >>>>>> >>>>>> As you say, could perhaps the reason be that the extra EP-IN added in >>>>>> those patches (previously 1, now 2 with the default config you use) >>>>>> exceeds your EP-IN max count or available fifos somehow? You have a >>>>>> number of functions initialized. If you change the load order of the >>>>>> functions, do you get the error later with a different function? Just >>>>>> guessing... >>>>>> >>>>>> You should be able to switch the default async EP-OUT (which >>>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires >>>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>>> >>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRbWQzLcU$ >>>>>> >>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRfP5TdZC$ >>>>>> >>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRejzMbWO$ >>>>>> >>>>>> Does that fix the problem? >>>>> >>>>> Not sure how to do that. Do you mean the module should have a parameter >>>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>>> >>>> Those are configfs params, not available in modinfo. >>>> >>>> I checked and the value is "adaptive" >>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c*L1312__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRTETcbsN$ >>> >>> >>>> In your configfs script: >>> >>> Kernel shouldn't crash with any available set of configuration >>> parameters, right? So, even if the parameter would fix the crash the >>> series is buggy and has to be reverted in my opinion. >> >> Sure, no problem with reverting. I am just trying to start up some >> troubleshooting. A resource exhaustion was mentioned here, that's why I >> suggested a way to test the patch with the original number of endpoints >> allocated. I do not get any crashes on my setup which uses fewer gadget >> functions. That's why I asked what happens if the functions load order >> is changed. I am afraid this thread is so complex that the actual >> problem has been burried in the history. >> > > As I pointed out previously, the crash is probably because of f_uac2 > prematurely freeing feedback request before its completion. > usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous > call so you didn't get a crash. Thanks for your hint, it greatly helps. >> > > I'm not sure how easy it is for you to obtain/test a device with dwc3, > but it would be great to also have it as part of your testing suite. :) Can you recommend a reasonably priced device with viable kernel updates for the testing? Optionally with SS which you mentioned last time? Thanks. Best regards, Pavel.
Hi Op 24-08-2021 om 07:39 schreef Pavel Hofman: > > > Dne 24. 08. 21 v 0:50 Thinh Nguyen napsal(a): >> Pavel Hofman wrote: >>> >>> >>> Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >>>> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >>>> <pavel.hofman@ivitera.com> wrote: >>>>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>> >>>> ... >>>> >>>>>>>>>> So, where do we go from here? >>>>>>>>> >>>>>>>>> I know the patches have been tested on dwc2 (by me and >>>>>>>>> others). I >>>>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>>>> not. Ruslan has talked about RPi (my case too) and >>>>>>>>> BeagleboneBlack, >>>>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>>>> dwc3? >>>>>>>>> >>>>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>>>> not followed your long thread (it started as unrelated to >>>>>>>>> uac). Does >>>>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>>>> reached the above problem? >>>>>>>> >>>>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>>>> mentioned in the subject line. >>>>>>>> >>>>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in >>>>>>>> host >>>>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>>>> flipping the switch to device mode udev run a script: >>>>>>>> But as I am using configfs (excerpt follows) and just disabling >>>>>>>> the >>>>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>>>> exceeding the available resources. >>>>>>>> >>>>>>>> # Create directory structure >>>>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>>>> cd "${GADGET_BASE_DIR}" >>>>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>>>> mkdir -p strings/0x409 >>>>>>>> >>>>>>>> # Serial device >>>>>>>> mkdir functions/gser.usb0 >>>>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>>>> ### >>>>>>>> >>>>>>>> # Ethernet device >>>>>>>> mkdir functions/eem.usb0 >>>>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>>>> >>>>>>>> # Mass Storage device >>>>>>>> mkdir functions/mass_storage.usb0 >>>>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>>>> >>>>>>>> # UAC2 device >>>>>>>> mkdir functions/uac2.usb0 >>>>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>>>> .... >>>>>>> >>>>>>> As you say, could perhaps the reason be that the extra EP-IN >>>>>>> added in >>>>>>> those patches (previously 1, now 2 with the default config you use) >>>>>>> exceeds your EP-IN max count or available fifos somehow? You >>>>>>> have a >>>>>>> number of functions initialized. If you change the load order of >>>>>>> the >>>>>>> functions, do you get the error later with a different function? >>>>>>> Just >>>>>>> guessing... >>>>>>> >>>>>>> You should be able to switch the default async EP-OUT (which >>>>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which >>>>>>> requires >>>>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>>>> >>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRbWQzLcU$ >>>>>>> >>>>>>> >>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRfP5TdZC$ >>>>>>> >>>>>>> >>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRejzMbWO$ >>>>>>> >>>>>>> >>>>>>> Does that fix the problem? >>>>>> >>>>>> Not sure how to do that. Do you mean the module should have a >>>>>> parameter >>>>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>>>> >>>>> Those are configfs params, not available in modinfo. >>>>> >>>>> I checked and the value is "adaptive" >>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c*L1312__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRTETcbsN$ >>>>> >>>> >>>> >>>>> In your configfs script: >>>> >>>> Kernel shouldn't crash with any available set of configuration >>>> parameters, right? So, even if the parameter would fix the crash the >>>> series is buggy and has to be reverted in my opinion. >>> >>> Sure, no problem with reverting. I am just trying to start up some >>> troubleshooting. A resource exhaustion was mentioned here, that's why I >>> suggested a way to test the patch with the original number of endpoints >>> allocated. I do not get any crashes on my setup which uses fewer gadget >>> functions. That's why I asked what happens if the functions load order >>> is changed. I am afraid this thread is so complex that the actual >>> problem has been burried in the history. >>> >> >> As I pointed out previously, the crash is probably because of f_uac2 >> prematurely freeing feedback request before its completion. >> usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous >> call so you didn't get a crash. > > Thanks for your hint, it greatly helps. >>> >> >> I'm not sure how easy it is for you to obtain/test a device with dwc3, >> but it would be great to also have it as part of your testing suite. :) > > Can you recommend a reasonably priced device with viable kernel > updates for the testing? Optionally with SS which you mentioned last > time? Thanks. > Edison-Arduino kit 2nd hand with display on ebay ~$100 :-) > Best regards, > > Pavel.
Ferry Toth wrote: > Hi > > Op 24-08-2021 om 07:39 schreef Pavel Hofman: >> >> >> Dne 24. 08. 21 v 0:50 Thinh Nguyen napsal(a): >>> Pavel Hofman wrote: >>>> >>>> >>>> Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >>>>> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >>>>> <pavel.hofman@ivitera.com> wrote: >>>>>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>>>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>> >>>>> ... >>>>> >>>>>>>>>>> So, where do we go from here? >>>>>>>>>> >>>>>>>>>> I know the patches have been tested on dwc2 (by me and >>>>>>>>>> others). I >>>>>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>>>>> not. Ruslan has talked about RPi (my case too) and >>>>>>>>>> BeagleboneBlack, >>>>>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>>>>> dwc3? >>>>>>>>>> >>>>>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>>>>> not followed your long thread (it started as unrelated to >>>>>>>>>> uac). Does >>>>>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>>>>> reached the above problem? >>>>>>>>> >>>>>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>>>>> mentioned in the subject line. >>>>>>>>> >>>>>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in >>>>>>>>> host >>>>>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>>>>> flipping the switch to device mode udev run a script: >>>>>>>>> But as I am using configfs (excerpt follows) and just disabling >>>>>>>>> the >>>>>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>>>>> exceeding the available resources. >>>>>>>>> >>>>>>>>> # Create directory structure >>>>>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>>>>> cd "${GADGET_BASE_DIR}" >>>>>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>>>>> mkdir -p strings/0x409 >>>>>>>>> >>>>>>>>> # Serial device >>>>>>>>> mkdir functions/gser.usb0 >>>>>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>>>>> ### >>>>>>>>> >>>>>>>>> # Ethernet device >>>>>>>>> mkdir functions/eem.usb0 >>>>>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>>>>> >>>>>>>>> # Mass Storage device >>>>>>>>> mkdir functions/mass_storage.usb0 >>>>>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>>>>> >>>>>>>>> # UAC2 device >>>>>>>>> mkdir functions/uac2.usb0 >>>>>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>>>>> .... >>>>>>>> >>>>>>>> As you say, could perhaps the reason be that the extra EP-IN >>>>>>>> added in >>>>>>>> those patches (previously 1, now 2 with the default config you use) >>>>>>>> exceeds your EP-IN max count or available fifos somehow? You >>>>>>>> have a >>>>>>>> number of functions initialized. If you change the load order of >>>>>>>> the >>>>>>>> functions, do you get the error later with a different function? >>>>>>>> Just >>>>>>>> guessing... >>>>>>>> >>>>>>>> You should be able to switch the default async EP-OUT (which >>>>>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which >>>>>>>> requires >>>>>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>>>>> >>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRbWQzLcU$ >>>>>>>> >>>>>>>> >>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRfP5TdZC$ >>>>>>>> >>>>>>>> >>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRejzMbWO$ >>>>>>>> >>>>>>>> >>>>>>>> Does that fix the problem? >>>>>>> >>>>>>> Not sure how to do that. Do you mean the module should have a >>>>>>> parameter >>>>>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>>>>> >>>>>> Those are configfs params, not available in modinfo. >>>>>> >>>>>> I checked and the value is "adaptive" >>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c*L1312__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRTETcbsN$ >>>>>> >>>>> >>>>> >>>>>> In your configfs script: >>>>> >>>>> Kernel shouldn't crash with any available set of configuration >>>>> parameters, right? So, even if the parameter would fix the crash the >>>>> series is buggy and has to be reverted in my opinion. >>>> >>>> Sure, no problem with reverting. I am just trying to start up some >>>> troubleshooting. A resource exhaustion was mentioned here, that's why I >>>> suggested a way to test the patch with the original number of endpoints >>>> allocated. I do not get any crashes on my setup which uses fewer gadget >>>> functions. That's why I asked what happens if the functions load order >>>> is changed. I am afraid this thread is so complex that the actual >>>> problem has been burried in the history. >>>> >>> >>> As I pointed out previously, the crash is probably because of f_uac2 >>> prematurely freeing feedback request before its completion. >>> usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous >>> call so you didn't get a crash. >> >> Thanks for your hint, it greatly helps. >>>> >>> >>> I'm not sure how easy it is for you to obtain/test a device with dwc3, >>> but it would be great to also have it as part of your testing suite. :) >> >> Can you recommend a reasonably priced device with viable kernel >> updates for the testing? Optionally with SS which you mentioned last >> time? Thanks. >> > Edison-Arduino kit 2nd hand with display on ebay ~$100 :-) > Ferry can correct me if I'm wrong, but I think Edison-Arduino kit only supports up to highspeed. Regardless, Edison-Arduino seems to work well with the latest Linux kernel. I see that there are various development kits with rk3399 that supports up to SuperSpeed at reasonable price, but I think they all require some effort to bring up to the latest Linux kernel and in device mode. Maybe Ferry/Felipe/anyone can provide more recommendations? Thanks, Thinh
Hi Op 26-08-2021 om 03:18 schreef Thinh Nguyen: > Ferry Toth wrote: >> Hi >> >> Op 24-08-2021 om 07:39 schreef Pavel Hofman: >>> >>> >>> Dne 24. 08. 21 v 0:50 Thinh Nguyen napsal(a): >>>> Pavel Hofman wrote: >>>>> >>>>> >>>>> Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >>>>>> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >>>>>> <pavel.hofman@ivitera.com> wrote: >>>>>>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>>>>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>>>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>>> >>>>>> ... >>>>>> >>>>>>>>>>>> So, where do we go from here? >>>>>>>>>>> >>>>>>>>>>> I know the patches have been tested on dwc2 (by me and >>>>>>>>>>> others). I >>>>>>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>>>>>> not. Ruslan has talked about RPi (my case too) and >>>>>>>>>>> BeagleboneBlack, >>>>>>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>>>>>> dwc3? >>>>>>>>>>> >>>>>>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>>>>>> not followed your long thread (it started as unrelated to >>>>>>>>>>> uac). Does >>>>>>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>>>>>> reached the above problem? >>>>>>>>>> >>>>>>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>>>>>> mentioned in the subject line. >>>>>>>>>> >>>>>>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in >>>>>>>>>> host >>>>>>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>>>>>> flipping the switch to device mode udev run a script: >>>>>>>>>> But as I am using configfs (excerpt follows) and just disabling >>>>>>>>>> the >>>>>>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>>>>>> exceeding the available resources. >>>>>>>>>> >>>>>>>>>> # Create directory structure >>>>>>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>>>>>> cd "${GADGET_BASE_DIR}" >>>>>>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>>>>>> mkdir -p strings/0x409 >>>>>>>>>> >>>>>>>>>> # Serial device >>>>>>>>>> mkdir functions/gser.usb0 >>>>>>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>>>>>> ### >>>>>>>>>> >>>>>>>>>> # Ethernet device >>>>>>>>>> mkdir functions/eem.usb0 >>>>>>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>>>>>> >>>>>>>>>> # Mass Storage device >>>>>>>>>> mkdir functions/mass_storage.usb0 >>>>>>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>>>>>> >>>>>>>>>> # UAC2 device >>>>>>>>>> mkdir functions/uac2.usb0 >>>>>>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>>>>>> .... >>>>>>>>> >>>>>>>>> As you say, could perhaps the reason be that the extra EP-IN >>>>>>>>> added in >>>>>>>>> those patches (previously 1, now 2 with the default config you use) >>>>>>>>> exceeds your EP-IN max count or available fifos somehow? You >>>>>>>>> have a >>>>>>>>> number of functions initialized. If you change the load order of >>>>>>>>> the >>>>>>>>> functions, do you get the error later with a different function? >>>>>>>>> Just >>>>>>>>> guessing... >>>>>>>>> >>>>>>>>> You should be able to switch the default async EP-OUT (which >>>>>>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which >>>>>>>>> requires >>>>>>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRbWQzLcU$ >>>>>>>>> >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRfP5TdZC$ >>>>>>>>> >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRejzMbWO$ >>>>>>>>> >>>>>>>>> >>>>>>>>> Does that fix the problem? >>>>>>>> >>>>>>>> Not sure how to do that. Do you mean the module should have a >>>>>>>> parameter >>>>>>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>>>>>> >>>>>>> Those are configfs params, not available in modinfo. >>>>>>> >>>>>>> I checked and the value is "adaptive" >>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c*L1312__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRTETcbsN$ >>>>>>> >>>>>> >>>>>> >>>>>>> In your configfs script: >>>>>> >>>>>> Kernel shouldn't crash with any available set of configuration >>>>>> parameters, right? So, even if the parameter would fix the crash the >>>>>> series is buggy and has to be reverted in my opinion. >>>>> >>>>> Sure, no problem with reverting. I am just trying to start up some >>>>> troubleshooting. A resource exhaustion was mentioned here, that's why I >>>>> suggested a way to test the patch with the original number of endpoints >>>>> allocated. I do not get any crashes on my setup which uses fewer gadget >>>>> functions. That's why I asked what happens if the functions load order >>>>> is changed. I am afraid this thread is so complex that the actual >>>>> problem has been burried in the history. >>>>> >>>> >>>> As I pointed out previously, the crash is probably because of f_uac2 >>>> prematurely freeing feedback request before its completion. >>>> usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous >>>> call so you didn't get a crash. >>> >>> Thanks for your hint, it greatly helps. >>>>> >>>> >>>> I'm not sure how easy it is for you to obtain/test a device with dwc3, >>>> but it would be great to also have it as part of your testing suite. :) >>> >>> Can you recommend a reasonably priced device with viable kernel >>> updates for the testing? Optionally with SS which you mentioned last >>> time? Thanks. >>> >> Edison-Arduino kit 2nd hand with display on ebay ~$100 :-) >> > > Ferry can correct me if I'm wrong, but I think Edison-Arduino kit only > supports up to highspeed. Regardless, Edison-Arduino seems to work well > with the latest Linux kernel. The usb phy TUSB1211 is built into the Edison module so the high speed limitation applies not only to Edison-Arduino kit. The kit does have a HW switch to switch between host / device mode which makes it perfect for testing. Other then that, Edison-Arduino currently receives acpi tables from U-Boot and configfs and works well in i686 and x86_64 since 4.19. USB device mode works well since 5.13 with one patch to extcon or with a few patches to 5.10. The extcon patch landed in 5.14. > I see that there are various development kits with rk3399 that supports > up to SuperSpeed at reasonable price, but I think they all require some > effort to bring up to the latest Linux kernel and in device mode. > > Maybe Ferry/Felipe/anyone can provide more recommendations? > > Thanks, > Thinh >
Dne 26. 08. 21 v 3:18 Thinh Nguyen napsal(a): > Ferry Toth wrote: >> Hi >> >> Op 24-08-2021 om 07:39 schreef Pavel Hofman: >>> >>> >>> Dne 24. 08. 21 v 0:50 Thinh Nguyen napsal(a): >>>> Pavel Hofman wrote: >>>>> >>>>> >>>>> Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): >>>>>> On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman >>>>>> <pavel.hofman@ivitera.com> wrote: >>>>>>> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>>>>>>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>>>>>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>>>>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>>>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: >>>>>> >>>>>> ... >>>>>> >>>>>>>>>>>> So, where do we go from here? >>>>>>>>>>> >>>>>>>>>>> I know the patches have been tested on dwc2 (by me and >>>>>>>>>>> others). I >>>>>>>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>>>>>>> not. Ruslan has talked about RPi (my case too) and >>>>>>>>>>> BeagleboneBlack, >>>>>>>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than >>>>>>>>>>> dwc3? >>>>>>>>>>> >>>>>>>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>>>>>>> not followed your long thread (it started as unrelated to >>>>>>>>>>> uac). Does >>>>>>>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>>>>>>> reached the above problem? >>>>>>>>>> >>>>>>>>>> I'm sorry too. I first believed the issue was related to the patch >>>>>>>>>> mentioned in the subject line. >>>>>>>>>> >>>>>>>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in >>>>>>>>>> host >>>>>>>>>> mode (there is a switch allowing to select host/device mode). When >>>>>>>>>> flipping the switch to device mode udev run a script: >>>>>>>>>> But as I am using configfs (excerpt follows) and just disabling >>>>>>>>>> the >>>>>>>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>>>>>>> exceeding the available resources. >>>>>>>>>> >>>>>>>>>> # Create directory structure >>>>>>>>>> mkdir "${GADGET_BASE_DIR}" >>>>>>>>>> cd "${GADGET_BASE_DIR}" >>>>>>>>>> mkdir -p configs/c.1/strings/0x409 >>>>>>>>>> mkdir -p strings/0x409 >>>>>>>>>> >>>>>>>>>> # Serial device >>>>>>>>>> mkdir functions/gser.usb0 >>>>>>>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>>>>>>> ### >>>>>>>>>> >>>>>>>>>> # Ethernet device >>>>>>>>>> mkdir functions/eem.usb0 >>>>>>>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>>>>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>>>>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>>>>>>> >>>>>>>>>> # Mass Storage device >>>>>>>>>> mkdir functions/mass_storage.usb0 >>>>>>>>>> echo 1 > functions/mass_storage.usb0/stall >>>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>>>>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>>>>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>>>>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>>>>>>> >>>>>>>>>> # UAC2 device >>>>>>>>>> mkdir functions/uac2.usb0 >>>>>>>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>>>>>>> .... >>>>>>>>> >>>>>>>>> As you say, could perhaps the reason be that the extra EP-IN >>>>>>>>> added in >>>>>>>>> those patches (previously 1, now 2 with the default config you use) >>>>>>>>> exceeds your EP-IN max count or available fifos somehow? You >>>>>>>>> have a >>>>>>>>> number of functions initialized. If you change the load order of >>>>>>>>> the >>>>>>>>> functions, do you get the error later with a different function? >>>>>>>>> Just >>>>>>>>> guessing... >>>>>>>>> >>>>>>>>> You should be able to switch the default async EP-OUT (which >>>>>>>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which >>>>>>>>> requires >>>>>>>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L47__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRbWQzLcU$ >>>>>>>>> >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c*L830__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRfP5TdZC$ >>>>>>>>> >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h*L453__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRejzMbWO$ >>>>>>>>> >>>>>>>>> >>>>>>>>> Does that fix the problem? >>>>>>>> >>>>>>>> Not sure how to do that. Do you mean the module should have a >>>>>>>> parameter >>>>>>>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >>>>>>> >>>>>>> Those are configfs params, not available in modinfo. >>>>>>> >>>>>>> I checked and the value is "adaptive" >>>>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c*L1312__;Iw!!A4F2R9G_pg!LBySrM_zgMGV0x-zZ7nSrs54yJw1GlnpUVUVxdQE8PeszSMZ6OkFX8lSoigwRTETcbsN$ >>>>>>> >>>>>> >>>>>> >>>>>>> In your configfs script: >>>>>> >>>>>> Kernel shouldn't crash with any available set of configuration >>>>>> parameters, right? So, even if the parameter would fix the crash the >>>>>> series is buggy and has to be reverted in my opinion. >>>>> >>>>> Sure, no problem with reverting. I am just trying to start up some >>>>> troubleshooting. A resource exhaustion was mentioned here, that's why I >>>>> suggested a way to test the patch with the original number of endpoints >>>>> allocated. I do not get any crashes on my setup which uses fewer gadget >>>>> functions. That's why I asked what happens if the functions load order >>>>> is changed. I am afraid this thread is so complex that the actual >>>>> problem has been burried in the history. >>>>> >>>> >>>> As I pointed out previously, the crash is probably because of f_uac2 >>>> prematurely freeing feedback request before its completion. >>>> usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous >>>> call so you didn't get a crash. >>> >>> Thanks for your hint, it greatly helps. >>>>> >>>> >>>> I'm not sure how easy it is for you to obtain/test a device with dwc3, >>>> but it would be great to also have it as part of your testing suite. :) >>> >>> Can you recommend a reasonably priced device with viable kernel >>> updates for the testing? Optionally with SS which you mentioned last >>> time? Thanks. >>> >> Edison-Arduino kit 2nd hand with display on ebay ~$100 :-) >> > > Ferry can correct me if I'm wrong, but I think Edison-Arduino kit only > supports up to highspeed. Regardless, Edison-Arduino seems to work well > with the latest Linux kernel. > > I see that there are various development kits with rk3399 that supports > up to SuperSpeed at reasonable price, but I think they all require some > effort to bring up to the latest Linux kernel and in device mode. > > Maybe Ferry/Felipe/anyone can provide more recommendations? Guys, thanks a lot for your recommendations. Andy Shevchenko contacted me with Hans de Goede and with their great help one of my Atom Z8350 noname tablets turned out to support the dwc3 device mode on one of its USB3-A ports. Only highspeed, but that's way better now :-) Thanks to all, Pavel.
Hi Thinh, On Sat, Aug 21, 2021 at 02:57:07AM +0000, Thinh Nguyen wrote: > I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add > feedback endpoint support") that Ferry reported the issue from > bisection. I see at least a couple problems in the new UAC2 changes. > > 1) usb_ep_dequeue() is asynchronous. Don't free requests before the > controller driver give them back. > > 2) Did you test with SuperSpeed? I don't see companion descriptor. We caught this too when testing f_uac2 in SuperSpeed mode. I can prepare a patch. Thanks, Jack
Jack Pham wrote: > Hi Thinh, > > On Sat, Aug 21, 2021 at 02:57:07AM +0000, Thinh Nguyen wrote: >> I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add >> feedback endpoint support") that Ferry reported the issue from >> bisection. I see at least a couple problems in the new UAC2 changes. >> >> 1) usb_ep_dequeue() is asynchronous. Don't free requests before the >> controller driver give them back. >> >> 2) Did you test with SuperSpeed? I don't see companion descriptor. > > We caught this too when testing f_uac2 in SuperSpeed mode. I can > prepare a patch. > Thanks for the test and the fix. BR, Thinh
Changes in V10: - Fixed compilation errors in config where OF is not used (error due to unknown symbol for of_add_property()). Add of_add_property() stub. - Fixed compilation warning for incorrect argument being passed to dwc3_mdwidth Changes in V9: - Fixed incorrect patch in series. Removed changes in DTSI, as dwc3-qcom will add the property by default from the kernel. Changes in V8: - Rebased to usb-testing - Using devm_kzalloc for adding txfifo property in dwc3-qcom - Removed DWC3 QCOM ACPI property for enabling the txfifo resize Changes in V7: - Added a new property tx-fifo-max-num for limiting how much fifo space the resizing logic can allocate for endpoints with large burst values. This can differ across platforms, and tie in closely with overall system latency. - Added recommended checks for DWC32. - Added changes to set the tx-fifo-resize property from dwc3-qcom by default instead of modifying the current DTSI files. - Added comments on all APIs/variables introduced. - Updated the DWC3 YAML to include a better description of the tx-fifo-resize property and added an entry for tx-fifo-max-num. Changes in V6: - Rebased patches to usb-testing. - Renamed to PATCH series instead of RFC. - Checking for fs_descriptors instead of ss_descriptors for determining the endpoint count for a particular configuration. - Re-ordered patch series to fix patch dependencies. Changes in V5: - Added check_config() logic, which is used to communicate the number of EPs used in a particular configuration. Based on this, the DWC3 gadget driver has the ability to know the maximum number of eps utilized in all configs. This helps reduce unnecessary allocation to unused eps, and will catch fifo allocation issues at bind() time. - Fixed variable declaration to single line per variable, and reverse xmas. - Created a helper for fifo clearing, which is used by ep0.c Changes in V4: - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() - Removed WARN_ON(1) in case we run out of fifo space Changes in V3: - Removed "Reviewed-by" tags - Renamed series back to RFC - Modified logic to ensure that fifo_size is reset if we pass the minimum threshold. Tested with binding multiple FDs requesting 6 FIFOs. Changes in V2: - Modified TXFIFO resizing logic to ensure that each EP is reserved a FIFO. - Removed dev_dbg() prints and fixed typos from patches - Added some more description on the dt-bindings commit message Currently, there is no functionality to allow for resizing the TXFIFOs, and relying on the HW default setting for the TXFIFO depth. In most cases, the HW default is probably sufficient, but for USB compositions that contain multiple functions that require EP bursting, the default settings might not be enough. Also to note, the current SW will assign an EP to a function driver w/o checking to see if the TXFIFO size for that particular EP is large enough. (this is a problem if there are multiple HW defined values for the TXFIFO size) It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 is required for an EP that supports bursting. Otherwise, there may be frequent occurences of bursts ending. For high bandwidth functions, such as data tethering (protocols that support data aggregation), mass storage, and media transfer protocol (over FFS), the bMaxBurst value can be large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB throughput. (which can be associated to system access latency, etc...) It allows for a more consistent burst of traffic, w/o any interruptions, as data is readily available in the FIFO. With testing done using the mass storage function driver, the results show that with a larger TXFIFO depth, the bandwidth increased significantly. Test Parameters: - Platform: Qualcomm SM8150 - bMaxBurst = 6 - USB req size = 256kB - Num of USB reqs = 16 - USB Speed = Super-Speed - Function Driver: Mass Storage (w/ ramdisk) - Test Application: CrystalDiskMark Results: TXFIFO Depth = 3 max packets Test Case | Data Size | AVG tput (in MB/s) ------------------------------------------- Sequential|1 GB x | Read |9 loops | 193.60 | | 195.86 | | 184.77 | | 193.60 ------------------------------------------- TXFIFO Depth = 6 max packets Test Case | Data Size | AVG tput (in MB/s) ------------------------------------------- Sequential|1 GB x | Read |9 loops | 287.35 | | 304.94 | | 289.64 | | 293.61 ------------------------------------------- Wesley Cheng (6): usb: gadget: udc: core: Introduce check_config to verify USB configuration usb: gadget: configfs: Check USB configuration before adding usb: dwc3: Resize TX FIFOs to meet EP bursting requirements of: Add stub for of_add_property() usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default dt-bindings: usb: dwc3: Update dwc3 TX fifo properties .../devicetree/bindings/usb/snps,dwc3.yaml | 15 +- drivers/usb/dwc3/core.c | 9 + drivers/usb/dwc3/core.h | 15 ++ drivers/usb/dwc3/dwc3-qcom.c | 9 + drivers/usb/dwc3/ep0.c | 2 + drivers/usb/dwc3/gadget.c | 212 +++++++++++++++++++++ drivers/usb/gadget/configfs.c | 22 +++ drivers/usb/gadget/udc/core.c | 25 +++ include/linux/of.h | 5 + include/linux/usb/gadget.h | 5 + 10 files changed, 317 insertions(+), 2 deletions(-)