"ad0: TIMEOUT - WRITE_DMA retrying" error under FreeBSD

W

willmc

Junior Member
I receive this error every minute or less in many situations of heavy disk I/O. It happens under both FreeBSD 5.5 and 6.1. I've run a wide variety of versions of Parallels (I'm currently on build 5540) under both Tiger and Leopard. I reported this issue in the old forums a few times when I was still running Parallels 2 a little under a year ago, and several other users chimed in complaining of the same issue.

Any word on what this is? It doesn't seem to corrupt data (thought I haven't examined things very closely) but it does stall disk I/O for a few seconds before the guest OS's kernel throws that message.
 
Hello willmc,

Could you please give us more data for analysis?

We would like to see a screenshot of your Activity Monitor (Applications -> Utilities) while heavy disk I/O. Please sort the processes by % CPU and choose Disk Activity tab, check I/O.

We would also appreciate you sending the output of top command from Terminal.

Do you have only one VM open when getting the error?

Best regards,
Xenos
 
Sorry, didn't see your reply until now! I'll subscribe to this thread. I've gone ahead and attached two screenshots taken during a "cd /usr/src ; make clean" in FreeBSD. The first is taken when the guest OS "stalls": the HD activity indicator in the bottom-right abruptly stops and the guest OS stops indicating any progress. The second is taken a few seconds later, immediately after the kernel message appearing on the screen. Up to that point, and immediately after the 2nd screenshot there is lots of activity.

Only one VM was running at the time, and I was running FreeBSD 6.2 under Parallels build 5580 under Mac OS 10.5.1. Is there any other information I can provide that might be helpful?
 

Attachments

  • Picture-2.jpg
    Picture-2.jpg
    312.2 KB · Views: 13
  • Picture-3.jpg
    Picture-3.jpg
    313.8 KB · Views: 12
Hello Willmc,

Thank you for the information.

As far as we can see, you can read / write your disk after you get the error - right?
Could you specify, in which situations you get this error? (if it is possible to see any logic here)

Please compact your VM hard disk: Configuration Editor -> Hard Disk -> Advanced -> Compact button.

Best regards,
Xenos
 
Xenos,

Yes, I can read/write to the disk after I get the error. The exact behavior of the issue is as such: I will notice that progress will suddenly stall, and there will be a sudden burst of write activity to the hard drive the VM's HD image lives on. Then there will be the kernel error stating either a read or write timeout, then the aforementioned disk activity will stop and progress of the install (or whatever I'm doing) will resume.

The issue only seems to appear when I'm manipulating large numbers of files. I have two situations where I will usually see these disk timeouts. First is when I'm going through the rebuild world process. Usually not during the actual compilation of FreeBSD, but often during a "make clean" or "make installworld". The other time I usually see it is when I rsync several home folders on another machine via SSH onto my VM. I'll usually see several errors in that one.

I tried compacting my image, but the issue reappeared during "make installworld". I'd be happy to send you guys a copy of my VM if you think it'd help, though I may be jumping ahead of ourselves with that.

Thanks,
W
 
Hello Willmc,

Yes that would be great if you could upload your .hdd file to Parallels FTP server. I've sent you the instruction by Private Message - please check.

Best regards,
Xenos
 
this issue still exists

I don't recall seeing this issue prior to the last few version for Parallels. It seems to be worse in the most recent build 5608.

I'm running on a 2.4GHz MBP with 4GB of RAM, running FreeBSD 7.0p5 under Parallels. The ad0: TIMEOUT error appear frequently when I'm doing heavy IO within the VM, and even more frequently when using MacOS applications that need disk i/o at the same time.

The best way I've found to trigger this behavior is to compile a large application within the FreeBSD VM. Something like mysql50-server does the job. Or "portsnap extract". Anything that generates a large amount of random disk I/O will do. When this happens, the system hangs for about 25-45 seconds. During that period, no applications respond, including the FreeBSD VM. Because I/O is hung, the CPU load which was high (90% on both CPUs) drops to 10% until I/O resumes. The TIMEOUT message appears in the VE immediately after everything "unsticks."

I also noticed that the time in the VE gets behind as well. This is problematic when I scp files into the VE. Because the times are in the future, make throws fits when I attempt to compile. It's a minor annoyance that ntpdate fixes for me.
 
The problem is that FreeBSD 7 is not officially supported and I suppose that I/O operations just are increasing with every Leopard update
 
I see the same issue with FreeBSD 6.2 and 6.3, so this most definitely not a FreeBSD 7 issue. The original poster cited FreeBSD 5.5 and 6.1
 
Last edited:
John@Parallels said:
Agree, but what about high I/O load, did you try to run VM from external disk, when only VM get access to disk?
Click to expand...

Now we're onto something. I tested with both FreeBSD 6 and 7 with the VM moved onto an external disk attached via FireWire 800. After running a number of tests that certainly would have exercised the problem, it did not appear even once.

So, it appears that only happens when the VM is running on the same disk as Mac OS. I hope that in some ways helps you resolve it. Running my VEs on external disks is only practical on 1 of my 3 systems.
 
Thank you for causing me to finally check out VMware Fusion. It does not suffer from this ailment. It supports VMware tools inside my FreeBSD 7 VE. It's faster. It's easier to use.

Since you cannot make Parallels work properly with FreeBSD, I cannot see any reason to continue using it. After using it for 2 hours, I just purchased Fusion and consider this issue resolved. You just lost one long time and previously satisfied customer. You really should consider fixing the problem.
 
I was about to upgrade my Parallels v3 to v4, but thought I'd check the forums first. Lucky I did. As I use Parallels almost exclusively for running FreeBSD, and have also suffered from thsi problem, this thread has helped me decide to upgrade to Vmware's Fusion product instead.

If Parallels is not interested in supporting their software, I'm not interested in supporting them by continuing to upgrade.

Thanks a bunch to the original poster.
 
Still an issue

I just installed FreeBSD-7 and saw the dreaded d0: TIMEOUT error several times. I'd still like to see the Parallels team work on it. I don't believe it is somehow unfixable as was implied earlier in the thread. I would also like to see even simple integration like clipboard. I can't tell you how annoying it is that I can't even copy a URL into my client VM and use "wget".
 
Same problem with Build 6.0.11994

I experience this problem with Build 6.0.11994.

Copying data from a remote system using

ssh root@remote_system "tar -czpf - /path/to/precious/data" | tar zxpf - -C /path/to/directory

gibes deared ad8: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=<some big number>

I also tried two other things: disabling either APIC or ACPI during boot of FreeBSD, but in both cases systems hangs or crashes right away. Have never seen this behaviour on physical hardware.

Best regards,
Tramp
 
IO contention between virtual machines or between host/guest will always disappoint FreeBSD's IO strategy routines. You can relax the FreeBSD VM if you slow down the VM ATA controller with 'atacontrol mode' but your VM's disk performance will suffer.

I solved the problem by installing FreeBSD on ZFS. It was a bit of a pain, first you need to get ZFS bootstrap and kernel installed on a FreeBSD CDROM image, and then you need to escape to the CDROM command prompt to format the disk with gpart/zpool, mount the filesystems on temporary mountpoints, and run the FreeBSD base and ports installer scripts by hand, and manually install the gptzfs bootblocks and add the zfs kernel modules to your /boot/loader.conf.

Once you do this once, you can boot up to a clean system and take a snapshot that you can 'zfs send' to a file somewhere on the network for later use as a golden master so you don't need to do all of the zfs and FreeBSD extraction steps.
 
You must log in or register to reply here.
Back
Top