STM32 usb networking stack threading issue

[Coi-l]

Describe the bug
I am using RNDIS/ECM on an stm32 nucleo-h743zi2 board.
I am using civetweb as a webserver.
I have a html page which in turn loads a number of other javascript files.
When I am using only 1 worker thread in civetweb everything works perfectly, but a bit slow due to only one thread.
When I try to increase this to 2 or more threads I get decoding/loading issues on the files that are loaded after the first html file is loaded. The files are corrupt and can't be completely unpacked by the browser.

When I try the same but using the RJ45 connection and normal ethernet driver on the same board it works perfectly.
I can make the USB connection work by adding a lot of debug logs while sending the data.

I've tested the USB connection on a nrf board where it works without issue.

This leads me to believe it is a problem with the thread safety of the usb networking stack on the stm32 platform.

To Reproduce
See above

Expected behavior
Pages should be sent without error

Impact
showstopper

Logs and console output

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK
• zephyr-v3.2.0

Additional context

[nordicjm]

I am using civetweb as a webserver.
zephyr-v3.2.0

These two statements are at odds with each other, civetweb was unmaintained for a few releases and was removed prior to the 3.2 release. Please fix your post

[erwango]

@Coi-l Would you be able to share a project that could be used to reproduce the issue you're seeing?

[Coi-l]

I am using civetweb as a webserver.
zephyr-v3.2.0

These two statements are at odds with each other, civetweb was unmaintained for a few releases and was removed prior to the 3.2 release. Please fix your post

I'm not sure why you have such an aggressive tone.
While civetweb was indeed deprecated and removed between 3.1 and 3.2, it does not mean that it is impossible to make civetweb work with zephyr. It took less than an hour to get civetweb working again after I upgraded to 3.2.

While I am new to zephyr community interactions I sincerely hope that your attitude is not representative for the rest of the community here.

[Coi-l]

@Coi-l Would you be able to share a project that could be used to reproduce the issue you're seeing?

I can't share the full project. I will try to put together a smaller example.

[jfischer-no]

I'm not sure why you have such an aggressive tone.
While civetweb was indeed deprecated and removed between 3.1 and 3.2, it does not mean that it is impossible to make civetweb work with zephyr. It took less than an hour to get civetweb working again after I upgraded to 3.2.

However, you should understand that you are probably reporting a bug in your project to upstream. There is no more support for civetweb, your description is very vague, and claims to be a bug in upstream. Please report it so that it can be reproduced with few changes in the tree, without external dependencies (like civetweb).

@erwango +1 to move to discussion.

[Coi-l]

However, you should understand that you are probably reporting a bug in your project to upstream. There is no more support for civetweb, your description is very vague, and claims to be a bug in upstream. Please report it so that it can be reproduced with few changes in the tree, without external dependencies (like civetweb).

@erwango +1 to move to discussion.

I understand that. I am very open for the possibility that it is a bug in my own project/civetweb integration. However the behaviour I saw at least in my opinion hinted at a bug somewhere in the stm32 networked usb stack.
If I should have filed this not under bug but somewhere else I apologize. I am fairly new to using github for partaking in a community. I can see now that there is a Discussions tab, please move it there if that is better suited for my question.

[erwango]

ok, moving to discussion until a genuine upstream bug is characterized