Do you mean target 0? Isn't that the virtual bus target? The probing code (see scsi_probe_bus in scsiconf.c) should skip this target since it matches the channel id set by vioscsi.
On Thu, Sep 1, 2016 at 10:52 PM, Christos Zoulas <[email protected]> wrote: > In article <CAAw6btkQ34JoUNjt-Vht0aKVe=hAVpTwy5K7iDm5ycb6Pza2Ng@mail. > gmail.com>, > Rohan Desai <[email protected]> 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 > >
