| commit | 2e169c4bb30f1bce12e0e20979d96e6e0d529a13 | [log] [tgz] |
|---|---|---|
| author | Venkatesh Srinivas <venkateshs@google.com> | Mon Jan 28 21:49:35 2019 +0000 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Jan 29 02:23:18 2019 +0000 |
| tree | a7cc391186522a11dd694c5e73e2ffda400f9cc4 | |
| parent | 4a44daeed854564ffd21a80f82b02225e1b6892f [diff] |
[virtio] scsi: Correctly handle command completion
Correct a bug in how ExecuteCommandSync called IrqRingUpdate that would
cause the scan worker thread to wait forever.
virtio ring::IrqRingUpdate will invoke a passed-in functor on descriptor
chains completed by the device. However if no descriptor chains were
completed, it would not call the functor. (I had assumed at first skim
that it would have waited instead).
Modify ExecuteCommandSync to keep invoking IrqRingUpdate with 5 mS steps
until the command completes with either an error or success. Later we will
wire up interrupt mode support, to avoid this 5 mS polling looping.
ZX-2314
Tested:
1) Booted on GCE, dm dump displayed the virtio-scsi target at 1-0.
2) Still boots on QEMU (qemu masked the error by synchronously processing
control commands).
[00:02.0] pid=2006 /boot/driver/bus-pci.so
<00:02.0> pid=2884 /boot/driver/bus-pci.proxy.so
[virtio-scsi] pid=2884 /boot/driver/virtio.so
[scsi-disk-1-1] pid=2884 /boot/driver/virtio.so
Both QEMU and GCE tests need the LUN encoding fix included (see 239313) for
tests to work.
Change-Id: I9a0d8f5860f11cf1f4b900ebe3c5c4cf76a060cd
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.