[Qemu-devel] DMA timeouts running a FreeBSD guest with last CVS snapshot

[Carlo Marcelo Arenas Belon]

Greetings,

while testing a snapshot from the last CVS tree with a freshly installed amd64 
FreeBSD 6.2 guest I noticed the following errors at boot time :

  ad0: 2048MB <QEMU HARDDISK 0.8.3> at ata0-master WDMA2
  ad0: FAILURE - READ_DMA timed out LBA=4194301
  acd0: CDROM <QEMU CD-ROM/0.8.3> at ata1-master WDMA2
  acd0: TIMEOUT - READ BIG retrying (1 retry left)

after the system finishes booting  there are apparently no more timeouts and 
the disk reports it is using UDMA2 through atacontrol but the IO performance is 
poor while reads to the virtual disk around the same sector (the disk is 4194304
sectors long) that failed work fine.

  # atacontrol mode ad0
  current mode = WDMA2

  # atacontrol cap ad0

  Protocol              ATA/ATAPI revision 7
  device model          QEMU HARDDISK
  serial number         QM00001
  firmware revision     0.8.3
  cylinders             4161
  heads                 16
  sectors/track         63
  lba supported         4194304 sectors
  lba48 supported       4194304 sectors
  dma supported
  overlap not supported

the same can be reproduced with a FreeBSD 6.1 guest and also with i386 guests
including an old FreeBSD 5.3 guest and even with an amd64 Debian GNU/kFreeBSD
guest but AFAIK not with Linux, OpenBSD or [Open]Solaris.

the following are the details as detected by the FreeBSD kernel at boot from
dmesg (the relevant stuff) :

  acpi0: <QEMU QEMURSDT> on motherboard
  pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
  pci0: <ACPI PCI bus> on pcib0
  atapci0: <Intel PIIX3 WDMA2 controller> port
  0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0
  ata0: <ATA channel 0> on atapci0
  ata1: <ATA channel 1> on atapci0

the ata driver is configured to ask the devide for the available modes and 
seems to be getting DMA2 and PIO4 from it, while defaulting to DMA as
configured.

the problem goes away if it is forced to run in PIO4 mode which is the only 
possibility for the FreeBSD 5.3 system which otherwise hungs at boot.

the problem doesn't exist in qemu 0.8.2 and is therefore a regression, but 
i'd yet to bisect the last changes to find the culprit, and since it seems to 
be a FreeBSD only problem I am first adding debugging to the guest kernel, 
to track it from the guest side.

nonetheless wanted to send this email, so that you guys had a heads up, and to
see if anyone had any ideas or some similar problems in other platforms (I am
using a Gentoo Linux Host).

Carlo