bash: echo: write error: Unknown error 524

[ali1234]

First of all, I tried to run:

python -m functionfs.tests.device /dev/mtp

But this gave the error:

/usr/bin/python: No module named tests

So I took a copy of device.py and ran it manually. When I run it, it says:

Succeeded with 14 endpoints
Servicing functionfs events forever...

Then I run in another shell:

echo dummy_udc.0 > /sys/kernel/config/usb_gadget/g1/UDC

This produces the output:

bash: echo: write error: Unknown error 524

And on dmesg:

[  372.253531] configfs-gadget dummy_udc.0: failed to start g1: -524

If I attempt to bind again, the test outputs:

functionfs: BIND
functionfs: UNBIND

and the echo command outputs:

bash: echo: write error: No such device

At this point, if I restart the test without tearing down the gadget in configfs, the kernel will deadlock.

However, if I fully delete the gadget config and then reload it all, rerun the test, and rerun the bind, it does the error 524 thing again (once), followed by the BIND/UNBIND thing on subsequent bind attempts.

[ali1234]

I discovered that if I remove the rndis function from my composite gadget then the test works.

[ali1234]

Removing any single one of the other functions (I have three) makes the test work.

OTOH, running four ACM functions works fine. I think this is something to do with the number of endpoints the test tries to grab.

[vpelletier]

/usr/bin/python: No module named tests

Fixed in 71f13320e276a57a56b8908b4e938c611c9bc9e9 .

bash: echo: write error: Unknown error 524

Functionfs errors are not terribly helpful indeed. From a quick check:

$ git grep "\<524\>" include
[...]
include/linux/errno.h:#define ENOTSUPP  524     /* Operation is not supported */
$ git grep ENOTSUPP drivers/usb/gadget
drivers/usb/gadget/function/f_fs.c:                     return -ENOTSUPP;
drivers/usb/gadget/function/f_fs.c:             return -ENOTSUPP;
[...]

There are also several other ENOTSUP sources in drivers/usb/gadget/udc .

The first line above triggers when a descriptor is given for a speed not supported by the USB Device Controller.

The second line above triggers when endpoint allocation fails, and as you said removing some other functions you configured makes the binding work, this is likely the issue here. If I remember correctly, the number of endpoints is checked in 2 places: when registering the descriptors, and when binding to a UDC. Maybe once to check it does not exceed the maximum total number of endpoints, and the second time to check the endpoints are actually free ? My memory is getting fuzzy.

There are several debug logs in f_fs.c, but I cannot remember how to enable these at the moment (especially whether they are available in the average kernel or if you would have to rebuild one).

At this point, if I restart the test without tearing down the gadget in configfs, the kernel will deadlock.

Ouch, that's a kernel bug. Gadgets do have rough edges. Please report this on linux-usb at vger.kernel.org, if you did not already.

I think this is something to do with the number of endpoints the test tries to grab.

This test is quite aggressive. I wrote it to check a maximum number of endpoints in one go and do some performance testing, so it expects to be the only function on the device.

[vpelletier]

I believe there is not much more to do on this issue at python-functionfs level.