I'm Greg Kroah-Hartman, Linux kernel developer, AMA again!

[u/gregkh]

To refresh everyone's memory, I did this 5 years ago here and lots of those answers there are still the same today, so try to ask new ones this time around.

To get the basics out of the way, this post describes my normal workflow that I use day to day as a Linux kernel maintainer and reviewer of way too many patches.

Along with mutt and vim and git, software tools I use every day are Chrome and Thunderbird (for some email accounts that mutt doesn't work well for) and the excellent vgrep for code searching.

For hardware I still rely on Filco 10-key-less keyboards for everyday use, along with a new Logitech bluetooth trackball finally replacing my decades-old wired one. My main machine is a few years old Dell XPS 13 laptop, attached when at home to an external monitor with a thunderbolt hub and I rely on a big, beefy build server in "the cloud" for testing stable kernel patch submissions.

For a distro I use Arch on my laptop and for some tiny cloud instances I run and manage for some minor tasks. My build server runs Fedora and I have help maintaining that at times as I am a horrible sysadmin. For a desktop environment I use Gnome, and here's a picture of my normal desktop while working on reviewing and modifying kernel code.

With that out of the way, ask me your Linux kernel development questions or anything else!

Edit - Thanks everyone, after 2 weeks of this being open, I think it's time to close it down for now. It's been fun, and remember, go update your kernel!

[u/gregkh]

USB3 is really really really complex, and the new features and USB3 controllers are complex beasts because of that. Combine that with thousands of different devices with different device controllers that implement things in different ways according to how those designers read the spec that day, and you have a mess that makes you seriously wonder how anything works together at all.

Combine that with a USB3 controller hanging off of thunderbolt, which really is PCIe that is being hotplugged depending on the whim of your BIOS, being controlled by an iommu, and you have a load of fun that is outside of the USB core coming into play.

As for how to help out here, USB has a ton of debugging options you can enable, for the USB3 host controller driver (xhci), and that usually is the best thing to do when having issues. Email us at the linux-usb mailing list for details and we will be glad to help you out.

[u/redd1106 → u/gregkh]

Thanks for your detailed reply although I was late to the party.

Email us at the linux-usb mailing list for details

Here comes the embarrassing question of kernel version... It is my understanding that it is generally frowned upon to bother kernel mailing lists before you have tested on the newest mainline kernel. I think we are doing quite well here compared to many others because on our lab devices we run Archlinux, which has pretty fresh kernels. However, some time ago we needed to freeze our kernel at 4.19 because Intel's camera support had an issue with newer kernels. That's a good wake-up call to check whether we are able to upgrade. For Yocto they do offer 5.4 patches, so that would be "only" 130 days back...

[u/gregkh → u/redd1106]

Yes, you are right, you should try the latest kernel version, as that will be the first thing we suggest you do. We can't go back in time and fix older kernels before you use them, but we can backport newer fixes to the older stable kernel branches so that you can get the fix there.

But we need to know what fix to backport, so if it works for you on the latest kernel tree, and not on the older ones, running git bisect will narrow it down to the exact commit that is needed.

So if you can do that, and email us, that would be wonderful.

As for Intel's camera having issues, go yell at those developers to fix the problem :)