| Message ID | 1510942228-22822-1-git-send-email-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/17/2017 07:10 PM, Thomas Huth wrote: > When rebooting a guest that has a virtio-scsi disk, the s390-ccw > bios sometimes bails out with an error message like this: > > ! SCSI cannot report LUNs: STATUS=02 RSPN=70 KEY=05 CODE=25 QLFR=00, sure ! > > Enabling the scsi_req* tracing in QEMU shows that the ccw bios is > trying to execute the REPORT LUNS SCSI command with a LUN != 0, and > this causes the SCSI command to fail. > Looks like we neither clear the BSS of the s390-ccw bios during reboot, > nor do we explicitly set the default_scsi_device.lun value to 0, so > this variable can contain random values from the OS after the reboot. > By setting this variable explicitly to 0, the problem is fixed and > the reboots always succeed. > > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1514352 > Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> We had these things multile times in the past. The QEMU elf loader does not zero the BSS (it just loads the load section). Hmm, what about letting the BIOS zero its bss itself. IIRC the kernel does the same thing. I will have a look into that for 2.12. PS: Please do not forget to rebuild the bios > --- > pc-bios/s390-ccw/virtio-scsi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/pc-bios/s390-ccw/virtio-scsi.c b/pc-bios/s390-ccw/virtio-scsi.c > index c92f5d3..4fe4b9d 100644 > --- a/pc-bios/s390-ccw/virtio-scsi.c > +++ b/pc-bios/s390-ccw/virtio-scsi.c > @@ -223,7 +223,8 @@ static void virtio_scsi_locate_device(VDev *vdev) > > for (target = 0; target <= vdev->config.scsi.max_target; target++) { > sdev->channel = channel; > - sdev->target = target; /* sdev->lun will be 0 here */ > + sdev->target = target; > + sdev->lun = 0; /* LUN has to be 0 for REPORT LUNS */ > if (!scsi_report_luns(vdev, data, sizeof(data))) { > if (resp.response == VIRTIO_SCSI_S_BAD_TARGET) { > continue; >
On 17.11.2017 19:10, Thomas Huth wrote: > When rebooting a guest that has a virtio-scsi disk, the s390-ccw > bios sometimes bails out with an error message like this: > > ! SCSI cannot report LUNs: STATUS=02 RSPN=70 KEY=05 CODE=25 QLFR=00, sure ! > > Enabling the scsi_req* tracing in QEMU shows that the ccw bios is > trying to execute the REPORT LUNS SCSI command with a LUN != 0, and > this causes the SCSI command to fail. > Looks like we neither clear the BSS of the s390-ccw bios during reboot, > nor do we explicitly set the default_scsi_device.lun value to 0, so > this variable can contain random values from the OS after the reboot. > By setting this variable explicitly to 0, the problem is fixed and > the reboots always succeed. > > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1514352 > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > pc-bios/s390-ccw/virtio-scsi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/pc-bios/s390-ccw/virtio-scsi.c b/pc-bios/s390-ccw/virtio-scsi.c > index c92f5d3..4fe4b9d 100644 > --- a/pc-bios/s390-ccw/virtio-scsi.c > +++ b/pc-bios/s390-ccw/virtio-scsi.c > @@ -223,7 +223,8 @@ static void virtio_scsi_locate_device(VDev *vdev) > > for (target = 0; target <= vdev->config.scsi.max_target; target++) { > sdev->channel = channel; > - sdev->target = target; /* sdev->lun will be 0 here */ > + sdev->target = target; > + sdev->lun = 0; /* LUN has to be 0 for REPORT LUNS */ > if (!scsi_report_luns(vdev, data, sizeof(data))) { > if (resp.response == VIRTIO_SCSI_S_BAD_TARGET) { > continue; > Reviewed-by: David Hildenbrand <david@redhat.com>
On Fri, 17 Nov 2017 19:10:28 +0100 Thomas Huth <thuth@redhat.com> wrote: > When rebooting a guest that has a virtio-scsi disk, the s390-ccw > bios sometimes bails out with an error message like this: > > ! SCSI cannot report LUNs: STATUS=02 RSPN=70 KEY=05 CODE=25 QLFR=00, sure ! > > Enabling the scsi_req* tracing in QEMU shows that the ccw bios is > trying to execute the REPORT LUNS SCSI command with a LUN != 0, and > this causes the SCSI command to fail. > Looks like we neither clear the BSS of the s390-ccw bios during reboot, > nor do we explicitly set the default_scsi_device.lun value to 0, so > this variable can contain random values from the OS after the reboot. > By setting this variable explicitly to 0, the problem is fixed and > the reboots always succeed. > > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1514352 > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > pc-bios/s390-ccw/virtio-scsi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/pc-bios/s390-ccw/virtio-scsi.c b/pc-bios/s390-ccw/virtio-scsi.c > index c92f5d3..4fe4b9d 100644 > --- a/pc-bios/s390-ccw/virtio-scsi.c > +++ b/pc-bios/s390-ccw/virtio-scsi.c > @@ -223,7 +223,8 @@ static void virtio_scsi_locate_device(VDev *vdev) > > for (target = 0; target <= vdev->config.scsi.max_target; target++) { > sdev->channel = channel; > - sdev->target = target; /* sdev->lun will be 0 here */ > + sdev->target = target; > + sdev->lun = 0; /* LUN has to be 0 for REPORT LUNS */ > if (!scsi_report_luns(vdev, data, sizeof(data))) { > if (resp.response == VIRTIO_SCSI_S_BAD_TARGET) { > continue; Thanks, applied + rebuilt the bios and pushed to s390-fixes.
diff --git a/pc-bios/s390-ccw/virtio-scsi.c b/pc-bios/s390-ccw/virtio-scsi.c index c92f5d3..4fe4b9d 100644 --- a/pc-bios/s390-ccw/virtio-scsi.c +++ b/pc-bios/s390-ccw/virtio-scsi.c @@ -223,7 +223,8 @@ static void virtio_scsi_locate_device(VDev *vdev) for (target = 0; target <= vdev->config.scsi.max_target; target++) { sdev->channel = channel; - sdev->target = target; /* sdev->lun will be 0 here */ + sdev->target = target; + sdev->lun = 0; /* LUN has to be 0 for REPORT LUNS */ if (!scsi_report_luns(vdev, data, sizeof(data))) { if (resp.response == VIRTIO_SCSI_S_BAD_TARGET) { continue;
When rebooting a guest that has a virtio-scsi disk, the s390-ccw bios sometimes bails out with an error message like this: ! SCSI cannot report LUNs: STATUS=02 RSPN=70 KEY=05 CODE=25 QLFR=00, sure ! Enabling the scsi_req* tracing in QEMU shows that the ccw bios is trying to execute the REPORT LUNS SCSI command with a LUN != 0, and this causes the SCSI command to fail. Looks like we neither clear the BSS of the s390-ccw bios during reboot, nor do we explicitly set the default_scsi_device.lun value to 0, so this variable can contain random values from the OS after the reboot. By setting this variable explicitly to 0, the problem is fixed and the reboots always succeed. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1514352 Signed-off-by: Thomas Huth <thuth@redhat.com> --- pc-bios/s390-ccw/virtio-scsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)