As far as I can tell, we hit the kernel bug when Teensy resets, and there is still data begin sent to the Teensy. If we could ensure the reset packet is the last one we try to send, immediately closing the character device after sending it, we might be able to avoid the bug.
However, I happen to have an Ubuntu 18.04 LTS machine and a Teensy 4.0 I can try to reproduce the issue with (I don't have a 3.5 or 3.6), and if I can reproduce the issue, I can build a custom x86-64 Ubuntu kernel to see if they get rid of the race condition. If it does, we can report it to both Ubuntu kernel maintainers and the Linux USB maintainers.
As to reporting kernel bugs directly to kernel developers, the
kernelnewbies.org/FoundBug page outlines the general procedure. (Simon Tatham's old
How to Report Bugs Effectively is also a good read, for generally reporting bugs.)
In this case, we need the crash report. If you can run
dmesg > /tmp/dmesg.txt immediately after, it too will help; you can anonymize (replace identifying information with asterisks or [EDITED OUT] or something similar), but ensure you have data for a second or so before the actual crash, and for a second or so after, because the context is useful. We also need to know which exact kernel you are running; run
uname -a for the full name and architecture (although
uname -rvmp is sufficient). I do believe you are running Ubuntu kernel linux-image-4.15.0-108-generic on x86-64. (I'm running 5.4.0.42-46~18.04.3 after my next boot; I'll see if I can temporarily downgrade.)
(Next, we should look at the oops report RIP: line, here
usb_kill_urb+0x3a/0xc0, and use e.g.
elixir.bootlin.com to find the definition of that function, usb_kill_urb, in your particular kernel. It happens to be in
drivers/usb/core/urb.c. Then, we download the linux sources, and in the linux directory in it, run
perl scripts/get_maintainer.pl -f drivers/usb/core/urb.c to find out who to contact. In this case, doing this to usb_kill_urb tells us to send email to Greg KH, linux-usb, and linux-kernel; and doing this to acm_kill_urbs adds Oliver Neukum (maintainer of the USB ACM driver) to the list. I've included these in the message prototype below.)
Optionally, you should subscribe to the linux-usb mailing list for now, so you don't miss any responses.
Send an email describing the issue, including the dmesg and the crash report as attachments. I would recommend describing the problem something like the following – but please use your own words and understanding. These are technical people, and interested in the work product, so best be concise but ensure you provide enough information. (Here, the dmesg oops is crucial, I believe – but I could obviously be wrong, too, so be prepared for follow-up questions and suggestions.)
To:
linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Oliver Neukum <oneukum@suse.com>,
linux-kernel@vger.kernel.org
Subject: Oops when USB device resets - acm_kill_urbs()/usb_kill_urb()
Hello!
My Ubuntu 18.04 LTS system tends to Oops whenever I upload a new firmware to a Teensy 3.6 microcontroller with a native high speed USB 2.0 interface. This upload process involves the microcontroller rebooting itself, causing the USB device to disconnect. It looks like there are a few URBs in flight when this happens, and an oops happens in acm_kill_urbs()/usb_kill_urb().
I was told that here on linux-usb mailing list, something related has been discussed in the recent weeks, so I was hoping the attached oops and crash report helps. I am not very kernel-savvy, and not sure if I can compiler and run the newest vanilla kernel, but if there is something perhaps simpler I can help you with, I'd be happy to try to.
Best Regards,
MySignature
When dealing with free/open source developers, especially Linux kernel or any GNU project developers, it is important to remember that the core currency in FOSS is time and effort, not money. If you can present the case that here is a problem that hits me, and probably lots of others too, and would like to help fix it – especially trying to provide any information the developers might need to fix this! –, and are willing to try whatever is within your skill range, the response from the developers should be positive.
Unfortunately, sometimes even an obviously correct patch
gets completely ignored. (In my case, that triggers my core issues, which is why I'm so hesitant to try and be more proactive here; hits me in a very soft spot, you see.) One should remember that these lists and people deal with a LOT of email, and sometimes things fall through the cracks. In my case, I should have sent those patches to
Kernel Janitors instead.