[Qemu-devel] DSC timeouts using all of -hda -hdb -hdc -cdrom

[Qemu-devel] DSC timeouts using all of -hda -hdb -hdc -cdrom

[J M Cerqueira Esteves]

Still under

 host CPU: AMD Athlon 64 3500+
 host operating system: Ubuntu 6.06 LTS,
      kernel: Ubuntu 2.6.15-26-amd64-k8 (SMP PREEMPT)
 QEMU: 0.8.2, configured with -cc=gcc-3.4 --enable-alsa
 kqemu: 1.3.0pre9

I tried to install Debian testing i386 in a vm with
3 virtual disks, booting from a Debian etch netinst iso file
(with a 2.6 kernel):

 vdeq qemu-system-x86_64 .. -hda .. -hdb .. -hdd .. -cdrom .. -boot d

On many CD reading attempts there were longer-than-normal waits, for
which the kernel reported

  hdc: DSC timeout

This occurred both with and without the -kernel-kqemu option active.


But it *didn't* happen when I tried the same installation process only
using one virtual disk image  (-hda ...  -cdrom ...).

Are there any know issues (or recommendations against) using all 3
"hard disk connections" (-hda -hdb -hdd) ?

Best regards
                           J Esteves

-- 
+351 939838775   Skype:jmcerqueira   http://del.icio.us/jmce

Re: [Qemu-devel] DSC timeouts using all of -hda -hdb -hdc -cdrom

[J M Cerqueira Esteves]

J M Cerqueira Esteves wrote:
>  vdeq qemu-system-x86_64 .. -hda .. -hdb .. -hdd .. -cdrom .. -boot d
> 
> On many CD reading attempts there were longer-than-normal waits, for
> which the kernel reported 
>   hdc: DSC timeout
[...]
> But it *didn't* happen when I tried the same installation process only
> using one virtual disk image  (-hda ...  -cdrom ...).

Also:

- had DSC timeouts with
    -hda ... -hdd ... -cdrom

- didn't have DSC timeouts with
    -hda ... -hdb ...  -cdrom

So the "culprit" of the cdrom timeouts seems to be -hdd ...
but why?

-- 
+351 939838775   Skype:jmcerqueira   http://del.icio.us/jmce

Re: [Qemu-devel] DSC timeouts using all of -hda -hdb -hdc -cdrom

[Christian MICHON]

On 8/19/06, J M Cerqueira Esteves <jmce@artenumerica.com> wrote:
> So the "culprit" of the cdrom timeouts seems to be -hdd ...
> but why?

I saw the same things few weeks ago. Since then, I do
not use hdd anymore (my qemu host is winXP).

I remember it was better on real hardware to have the cdrom
either alone on one IDE interface, or at most slave on the
IDE interface if shared with a hard disk. In this case, hdc
is the master.

I believe qemu is really a very good hardware emulator...

Indeed we can see the implication of having hdd and hdc
active at the same time. :)

--
Christian

[Qemu-devel] DSC timeout with a CD as ide1 slave / Lost interrupts without -no-acpi

[J M Cerqueira Esteves]

Returning to an old topic...

Christian MICHON wrote:
> On 8/19/06, J M Cerqueira Esteves <jmce@artenumerica.com> wrote:
>> So the "culprit" of the cdrom timeouts seems to be -hdd ...
>> but why?
> 
> 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 \
     -drive 
file=/tmp/debian-40r2-i386-netinst.iso,if=ide,index=3,media=cdrom \
     -boot d

But if I put the cdrom device as a slave of ide0,
   file=...,if=ide,index=1,media=cdrom
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).

Best regards
                     J Esteves