| Message ID | ad644d8d56c0355f2b63d70ab6a2b2d1f50494e7.1368718398.git.phrdina@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 05/16/2013 09:34 AM, Pavel Hrdina wrote: > Tray statuses should be also reseted. Some guests may lock the tray s/reseted/reset/ > and after reset before any kernel is loaded the tray should be unlocked. > > Also if you reset the real computer the tray is closed. We should > do the same in qemu. Is that OS-independent hardware behavior, or is tray closing on boot merely a side effect observed on bare metal but caused by installed software (BIOS or OS code)? At any rate, being consistent with IDE doesn't hurt. > > This fix is already commited for IDE CD. s/commited/committed/ > Check the commit a7f3d65b65b8c86a5ff0c0abcfefb45e2ec6fe4c. > > Signed-off-by: Pavel Hrdina <phrdina@redhat.com> > --- > hw/scsi/scsi-disk.c | 3 +++ > 1 file changed, 3 insertions(+) assuming the maintainer can touch up the commit message, feel free to add: Reviewed-by: Eric Blake <eblake@redhat.com>
On 16.5.2013 17:42, Eric Blake wrote: > On 05/16/2013 09:34 AM, Pavel Hrdina wrote: >> Tray statuses should be also reseted. Some guests may lock the tray > > s/reseted/reset/ > >> and after reset before any kernel is loaded the tray should be unlocked. >> >> Also if you reset the real computer the tray is closed. We should >> do the same in qemu. > > Is that OS-independent hardware behavior, or is tray closing on boot > merely a side effect observed on bare metal but caused by installed > software (BIOS or OS code)? At any rate, being consistent with IDE > doesn't hurt. > From what I just tested it is the OS-independent HW behavior. Tested on desktop: 1. Turn off the computer. 2. Turn on the computer and after few second open the CD-ROM tray before any OS system is loaded and holding the power button turn the computer off again. The CD-ROM tray should stay opened. 3. Turn on the computer and the CD-ROM tray is automatically closed. Next time I'll mention this test in the commit message. >> >> This fix is already commited for IDE CD. > > s/commited/committed/ > >> Check the commit a7f3d65b65b8c86a5ff0c0abcfefb45e2ec6fe4c. >> >> Signed-off-by: Pavel Hrdina <phrdina@redhat.com> >> --- >> hw/scsi/scsi-disk.c | 3 +++ >> 1 file changed, 3 insertions(+) > > assuming the maintainer can touch up the commit message, feel free to add: > > Reviewed-by: Eric Blake <eblake@redhat.com> >
Il 16/05/2013 17:48, Pavel Hrdina ha scritto: > > From what I just tested it is the OS-independent HW behavior. > > Tested on desktop: > 1. Turn off the computer. > 2. Turn on the computer and after few second open the CD-ROM tray before > any OS system is loaded and holding the power button turn the computer > off again. The CD-ROM tray should stay opened. > 3. Turn on the computer and the CD-ROM tray is automatically closed. When? Compared to the BIOS splash screen, for example. > Next time I'll mention this test in the commit message. It could mean it is done in the firmware. What happens when you suspend the QEMU machine to RAM? I believe the tray should remain open or, if closed, should remain locked. Can you try the same test on bare-metal (hint: boot to emergency mode to bypass anything that udev can do with locking the tray, then use sg_prevent to toggle the state). Paolo
On 16.5.2013 18:11, Paolo Bonzini wrote: > Il 16/05/2013 17:48, Pavel Hrdina ha scritto: >> >> From what I just tested it is the OS-independent HW behavior. >> >> Tested on desktop: >> 1. Turn off the computer. >> 2. Turn on the computer and after few second open the CD-ROM tray before >> any OS system is loaded and holding the power button turn the computer >> off again. The CD-ROM tray should stay opened. >> 3. Turn on the computer and the CD-ROM tray is automatically closed. > > When? Compared to the BIOS splash screen, for example. Immediately after the computer is turned on. On HP Z400 workstation it means before the monitor is turned on. > >> Next time I'll mention this test in the commit message. > > It could mean it is done in the firmware. > > What happens when you suspend the QEMU machine to RAM? I believe the > tray should remain open or, if closed, should remain locked. Can you > try the same test on bare-metal (hint: boot to emergency mode to bypass > anything that udev can do with locking the tray, then use sg_prevent to > toggle the state). > > Paolo > I've booted to init 1, then ejected the CD-ROM tray and run the pm-suspend. The computer has suspended successfully. And again immediately after the computer is turned on before the screen is turned on the CD-ROM tray is closed. I don't have SCSI CD-ROM device to use the sg_prevent. Pavel
Il 17/05/2013 13:57, Pavel Hrdina ha scritto: >> >> What happens when you suspend the QEMU machine to RAM? I believe the >> tray should remain open or, if closed, should remain locked. Can you >> try the same test on bare-metal (hint: boot to emergency mode to bypass >> anything that udev can do with locking the tray, then use sg_prevent to >> toggle the state). > > I've booted to init 1, then ejected the CD-ROM tray and run the > pm-suspend. The computer has suspended successfully. And again > immediately after the computer is turned on before the screen is turned > on the CD-ROM tray is closed. Ok, these are good signs. :) > I don't have SCSI CD-ROM device to use the sg_prevent. All CD-ROMs ultimately speak SCSI (via ATAPI). You don't have /dev/sr0? Paolo
On 17.5.2013 14:02, Paolo Bonzini wrote: > Il 17/05/2013 13:57, Pavel Hrdina ha scritto: >>> >>> What happens when you suspend the QEMU machine to RAM? I believe the >>> tray should remain open or, if closed, should remain locked. Can you >>> try the same test on bare-metal (hint: boot to emergency mode to bypass >>> anything that udev can do with locking the tray, then use sg_prevent to >>> toggle the state). >> >> I've booted to init 1, then ejected the CD-ROM tray and run the >> pm-suspend. The computer has suspended successfully. And again >> immediately after the computer is turned on before the screen is turned >> on the CD-ROM tray is closed. > > Ok, these are good signs. :) > >> I don't have SCSI CD-ROM device to use the sg_prevent. > > All CD-ROMs ultimately speak SCSI (via ATAPI). You don't have /dev/sr0? > > Paolo > Yes I have. If I run "sg_prevent /dev/sr0" the CD-ROM tray could be still opened. Even with "sg_prevent -p 3 /dev/sr0". Pavel
Il 17/05/2013 14:11, Pavel Hrdina ha scritto: > On 17.5.2013 14:02, Paolo Bonzini wrote: >> Il 17/05/2013 13:57, Pavel Hrdina ha scritto: >>>> >>>> What happens when you suspend the QEMU machine to RAM? I believe the >>>> tray should remain open or, if closed, should remain locked. Can you >>>> try the same test on bare-metal (hint: boot to emergency mode to bypass >>>> anything that udev can do with locking the tray, then use sg_prevent to >>>> toggle the state). >>> >>> I've booted to init 1, then ejected the CD-ROM tray and run the >>> pm-suspend. The computer has suspended successfully. And again >>> immediately after the computer is turned on before the screen is turned >>> on the CD-ROM tray is closed. >> >> Ok, these are good signs. :) >> >>> I don't have SCSI CD-ROM device to use the sg_prevent. >> >> All CD-ROMs ultimately speak SCSI (via ATAPI). You don't have /dev/sr0? >> >> Paolo >> > > Yes I have. If I run "sg_prevent /dev/sr0" the CD-ROM tray could be > still opened. Even with "sg_prevent -p 3 /dev/sr0". Try "init=/bin/sh". Runlevel 1 might not be enough. Also, you can try "echo 0 > /sys/block/sr0/event_poll_msecs" Paolo
On 17.5.2013 14:15, Paolo Bonzini wrote: > Il 17/05/2013 14:11, Pavel Hrdina ha scritto: >> On 17.5.2013 14:02, Paolo Bonzini wrote: >>> Il 17/05/2013 13:57, Pavel Hrdina ha scritto: >>>>> >>>>> What happens when you suspend the QEMU machine to RAM? I believe the >>>>> tray should remain open or, if closed, should remain locked. Can you >>>>> try the same test on bare-metal (hint: boot to emergency mode to bypass >>>>> anything that udev can do with locking the tray, then use sg_prevent to >>>>> toggle the state). >>>> >>>> I've booted to init 1, then ejected the CD-ROM tray and run the >>>> pm-suspend. The computer has suspended successfully. And again >>>> immediately after the computer is turned on before the screen is turned >>>> on the CD-ROM tray is closed. >>> >>> Ok, these are good signs. :) >>> >>>> I don't have SCSI CD-ROM device to use the sg_prevent. >>> >>> All CD-ROMs ultimately speak SCSI (via ATAPI). You don't have /dev/sr0? >>> >>> Paolo >>> >> >> Yes I have. If I run "sg_prevent /dev/sr0" the CD-ROM tray could be >> still opened. Even with "sg_prevent -p 3 /dev/sr0". > > Try "init=/bin/sh". Runlevel 1 might not be enough. Still not preventing from opening. > > Also, you can try "echo 0 > /sys/block/sr0/event_poll_msecs" There is no file event_poll_msecs in that directory. Pavel > > Paolo >
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index c8d2a99..02733dc 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -1984,6 +1984,9 @@ static void scsi_disk_reset(DeviceState *dev) nb_sectors--; } s->qdev.max_lba = nb_sectors; + /* reset tray statuses */ + s->tray_locked = 0; + s->tray_open = 0; } static void scsi_destroy(SCSIDevice *dev)
Tray statuses should be also reseted. Some guests may lock the tray and after reset before any kernel is loaded the tray should be unlocked. Also if you reset the real computer the tray is closed. We should do the same in qemu. This fix is already commited for IDE CD. Check the commit a7f3d65b65b8c86a5ff0c0abcfefb45e2ec6fe4c. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> --- hw/scsi/scsi-disk.c | 3 +++ 1 file changed, 3 insertions(+)