In article <CAAw6btkQ34JoUNjt-Vht0aKVe=hAVpTwy5K7iDm5ycb6Pza2Ng@mail. >,gmail.com
Rohan Desai <desai.p.rohan%gmail.com@localhost> wrote:
>-=-=-=-=-=-
Yes, somehow the first target presented to me was unusable. I tried it with>
>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?
qemu..
https://wiki.netbsd.org/tutorials/how_to_setup_virtio_ scsi_with_qemu/
christos