The changes in this commit are large but also subtle, so an explanation of how they came to be seems to make sense: Earlier today I tried booting Haiku on QEMU under USB3 ... and discovered that it didn't work, with the "Operation timed out" message from in usb_disk upon failing a data transfer. Indeed, turning on tracing showed no event was being posted for the transfer. So, I downloaded QEMU's source code, turned on XHCI debugging, and began tracing what was going on. Eventually I determined by adding more and more printfs into QEMU's XHCI implementation that what was occuring was that it was evaluating a Link TRB, hitting an empty TRB, and then deciding that the TD (aka., the "run" of TRBs) was not ready to be consumed, and bailing. In fact, that very condition (a link TRB leading to an empty TRB) is precisely what _LinkDescriptorForPipe did before this commit. We allocate only a small (8 before this commit, 16 + 1 after this commit) TRB ring for each *endpoint*, and larger ones on a per-*transfer* basis; and just write Link TRBs onto the Endpoint ring pointing to the transfer TD, and then one at the end of each transfer TD leading back to the endpoint ring. The reason this occured inside usb_disk, and not earlier (e.g. during descriptor fetching), is that QEMU has special logic around determining transfer lengths of control transfers which made it not perform the "TRB valid?" check after evaluating the Link TRB. So, being implementation-defined behavior, I am guessing that this same problem was also the cause of boot failures on real hardware. This also means that the problem was essentially a race condition, as if we posted another transfer to the ring before it evaluated the TRB, it would always work. The solution of course is to put some valid TRB at the end of every transfer on the Endpoint ring. A "no-op" would have done the job (well, maybe not, it appears QEMU does not implement "no-op" TRBs for some reason), but there was another feature of XHCI that we did not take advantage of: Event Data TRBs. These provide the "total transferred length" as well as the status, instead of the "remaining length" of the final TRB. This of course required refactoring the use of the CHAIN bit and the IOC bit (namely, more or less all TRBs save the Event Data get the CHAIN bit set, and none save Event Data get the IOC bit.) There was also an update to the XHCI spec since I've last committed here, so the new comments are in reference to the "XHCI 1.2" spec. (I'll eventually find time to update the old ones.) Fixes booting from USB3 on QEMU, and most likely also on bare metal, where it at least got to usb_disk (it does not seem to fix the case where usb_disk does not even start.) Whew!
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling
.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our OpenGrok servers:
- http://xref.plausible.coop/ (provided by Landon Fuller)
- http://code.metager.de/source/xref/haiku (provided by MetaGer)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user
). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.