Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a):

On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman [off-list ref] wrote:

quoted

Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):

quoted

Op 19-08-2021 om 23:04 schreef Pavel Hofman:

quoted

Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):

quoted

Op 19-08-2021 om 09:51 schreef Pavel Hofman:

quoted

Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):

quoted

Op 18-08-2021 om 00:00 schreef Ferry Toth:

...

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

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.