3 ms·
(I'm the author of the blogpost.) > without, you're basically restricted to "guess and test" and reverse-engineering other drivers to see the differences in be
by waddlesplash 8y ago
(I'm the author of the blogpost.)
> without, you're basically restricted to "guess and test" and reverse-engineering other drivers to see the differences in behaviour.
Not entirely. If you look at the commits I linked in the post, you'll see that most of them fixed rather egregious spec violations. Arguably the spec could have been clearer; but still.
> The fact that "real" debugging requires an extremely expensive protocol analyser/oscilloscope also adds to that
USB packets can be sniffed in Wireshark. But for the kinds of bugs that this driver had, that isn't helpful; most of the problems were failure to initialize the controller or sending invalid command sequences. So that wouldn't be very helpful anyway.
- monocasa 8y ago> or sending invalid command sequences Most of the protocol analyzers I've seen go out of their way to highlight invalid sequences and spec violations. IMO, that's most of their benefit.
- waddlesplash 8y agoNo, I mean we were sending invalid command sequences to the XHCI controller, and as a result it wasn't sending anything to the ports at all.
- nitrogen 8y agoThere are probably ways of dumping PCI writes; I'm curious if any tracing of that sort was used (comparing traces to known working OSes), or if it was all about comparing code to the spec.
- jclulow 8y agoWe've gone through similar rounds of debugging our XHCI bits on illumos. PCI and USB sniffing hardware is expensive and we have access to neither. You can get a long way by becoming comfortable with the specification, reading and getting review on your source, and by using the debugging tools on your OS (we have MDB and DTrace, etc).
- userbinator 8y agoUsing a VM is another way --- a virtual USB controller can log how it's being manipulated.
- pas 8y agois there a hall of shame for these broken drivers, devices and vendors?