as shown in the linked novell bug report, when trying to run any distribution which is using libata by default (like Fedora or OpenSUSE), the cdrom will misbehave due to a bug in the emulation code inside qemu which is now fixed upstream in CVS as shown by : http://cvs.savannah.gnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.63&r2=1.64 the following link contains the patch as used by Fedora/RedHat and OpenSUSE/Novell : http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/qemu/qemu-0.9.0-atapi-hsm.patch?rev=1.1 Reproducible: Always Steps to Reproduce: 1. download an iso for a distribution using libata by default like Fedora 7 or OpenSUSE 10.2 2. start a qemu emulated vm using that iso as a cdrom device 3. wait for the kernel to try to initialize the ATA emulated controller for the cdrom. Actual Results: very slow response and timeouts (when device can be accessed) Expected Results: no errors tested in amd64 with a qemu-0.9.0 ebuild (after adding the corresponding epatch as -r1 in a local overlay)
Created attachment 130393 [details, diff] upstream patch the original one which includes the problem description, and equivalent one can be extracted from a cvs diff -r1.63 -r1.64 hw/ide.c as well if desired
the errors as seen in the guest without the patch look like : ata2: DRQ=1 with device error, dev_stat 0x49 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x5) ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x4a data 8 in res 41/50:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
a patch was silently added to =app-emulation/qemu-softmmu-0.9.0 as shown by the following changelog entry : 09 Sep 2007; Luca Barbato <lu_zero@gentoo.org> +files/qemu-softmmu-0.9.0-ide-cd.patch, qemu-softmmu-0.9.0.ebuild: Address a glitch in the ide/cdrom emulation, thanks to Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> for pointing the patch and reporting the issue the corresponding ebuild with version 1.8 from that day, adds an epatch call that uses it, so a rebuild for that version will what is needed to fix this problem. since the ebuild version wasn't bumped, an update call from emerge won't work and therefore `emerge -Dv qemu-softmmu` should be used instead of just an update to world
