In article <CAAw6btkQ34JoUNjt-Vht0aKVe=havptwy5k7idm5ycb6pza...@mail.gmail.com>,
Rohan Desai <desai.p.ro...@gmail.com> wrote:
>-=-=-=-=-=-
>
>Having an issue with vioscsi in GCE. vioscsi decrements the target id in
>commands it sends to virtio. This means that the upper layers notion of the
>target id is off by 1. This is especially problematic when presented a lun
>on the last target of a bus. It never gets discovered because the scsipi
>probe code sends down an xs with the last target number, which vioscsi then
>decrements in the command it sends along. The probe code never moves on to
>the next target (since it thinks its probed all the targets on the bus) and
>the lun is never discovered. I hit this in GCE for local disks because they
>create a new bus with a single target for each local disk.
>
>Here's a patch that fixes the issue for me:
>
>@@ -279,12 +279,12 @@ vioscsi_scsipi_request(struct scsipi_channel *chan,
>scsipi_adapter_req_t
> goto stuffup;
> }
> req->lun[0] = 1;
>- req->lun[1] = periph->periph_target - 1;
>+ req->lun[1] = periph->periph_target;
> req->lun[2] = 0x40 | (periph->periph_lun >> 8);
> req->lun[3] = periph->periph_lun;
> memset(req->lun + 4, 0, 4);
> DPRINTF(("%s: command for %u:%u at slot %d\n", __func__,
>- periph->periph_target - 1, periph->periph_lun, slot));
>+ periph->periph_target, periph->periph_lun, slot));
>
> if ((size_t)xs->cmdlen > sizeof(req->cdb)) {
> DPRINTF(("%s: bad cmdlen %zu > %zu\n", __func__,
>
>Any reason for decrementing periph_target in the first place?
Yes, somehow the first target presented to me was unusable. I tried it with
qemu..
https://wiki.netbsd.org/tutorials/how_to_setup_virtio_scsi_with_qemu/
christos
