[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] DSC timeout with a CD as ide1 slave / Lost interrupts witho
J M Cerqueira Esteves
[Qemu-devel] DSC timeout with a CD as ide1 slave / Lost interrupts without -no-acpi
Sun, 20 Jan 2008 09:27:29 +0000
Thunderbird 22.214.171.124 (X11/20070728)
Returning to an old topic...
Christian MICHON wrote:
On 8/19/06, J M Cerqueira Esteves <address@hidden> wrote:
So the "culprit" of the cdrom timeouts seems to be -hdd ...
I saw the same things few weeks ago. Since then, I do
not use hdd anymore (my qemu host is winXP).
My previous issue on this was with QEMU 0.8.2 and kqemu 1.3.0pre9
(in fact the subject was misleading, since I really used
-hda .. -hdb .. -hdd .. -cdrom .. -boot d).
Now with QEMU 0.9.1 and kqemu 1.3.0pre11 (host: Debian Etch on a Pentium
M 1400MHz) I got DSC timeout again when trying to use a cdrom as a slave
of ide1 (CD image: Debian netinst CD for i386:
debian-40r2-i386-netinst.iso), invoking qemu with
vdeq qemu \
-kernel-kqemu -no-acpi \
-m 256 \
-net nic,vlan=0,model=rtl8139,macaddr=$MAC_ADDR_0 \
-net vde,vlan=0,sock=/var/run/vde2/tap-vde-1.ctl \
-drive file=/dev/sda,if=ide,index=2,media=disk \
But if I put the cdrom device as a slave of ide0,
I get no DSC timeouts.
By the way, in the few tests I made until now in this Pentium M host
(mostly with Debian guest systems) I had to use -no-acpi since otherwise
the boot process gets stuck or at least very slow and the guest reports
hdc: lost interrupt
(or "hda:" or "hdb:" depending on what was the first existing IDE device
in the specific guest). This happens also with a Debian virtual
machine which was previously running in a P4 host with QEMU 0.8.2 and
kqemu 1.3.0pre9 not requiring the -no-acpi option... I'll test a bit
more, but apparently I also get *no* such 'lost interrupt' messages with
32-bit guests in a 64-bit host (AMD Athlon 64 3500+, also with Debian
Etch and QEMU 0.9.1).
|[Prev in Thread]
||[Next in Thread]|
- [Qemu-devel] DSC timeout with a CD as ide1 slave / Lost interrupts without -no-acpi,
J M Cerqueira Esteves <=