diff options
author | Gleb Natapov <gleb@redhat.com> | 2009-08-02 11:36:47 +0300 |
---|---|---|
committer | Anthony Liguori <aliguori@us.ibm.com> | 2009-08-10 13:05:48 -0500 |
commit | 93c8cfd9e67a62711b86f4c93747566885eb7928 (patch) | |
tree | 713304d96d967e0bc85f13ecfd46a3c0aafd3bc8 /gdb-xml | |
parent | 73006d2a9a6f226486674c0ee92b5ea5bb1a2cf6 (diff) | |
download | qemu-93c8cfd9e67a62711b86f4c93747566885eb7928.zip qemu-93c8cfd9e67a62711b86f4c93747566885eb7928.tar.gz qemu-93c8cfd9e67a62711b86f4c93747566885eb7928.tar.bz2 |
make windows notice media change
Windows seems to be very stupid about cdrom media change. It polls
cdrom status and if status goes ready->media not present->ready
it assumes that media was changed. If "media not present" step doesn't
happen even if "medium may have changed" was seen it assumes media
haven't changed. Fake "media not present" step.
Filip Navara did a great job debugging this issue in Windows and this is
what he found out:
BINGO! ... The media present notifications were broken ever since
Windows 2000 it seems. The media change is detected properly and it's
passed to ClassSetMediaChangeState function which in turn calls
ClasspInternalSetMediaChangeState. This function is responsible for
changing some internal state of the device object and sending the PnP
events which later result in application notifications. It has this
tiny bit of code (not copied byte for byte):
if (oldMediaState == NewState) {
// Media is in the same state it was before.
return;
}
so the end result is that for the case of UNIT NEEDS ATTENTION /
MEDIUM MAY HAVE CHANGED without NOT READY in-between is really broken.
It results in the internal media change counter incremented, so the
media contents are re-read when necessary, instead of relying on the
cache, but the notifications to applications are never sent.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-Id:
Diffstat (limited to 'gdb-xml')
0 files changed, 0 insertions, 0 deletions