read_dma timeouts under FreeBSD 6.1

Discussion in 'Parallels Desktop for Mac' started by rbc, Jun 23, 2006.

  1. rbc

    rbc

    Messages:
    11
    I'm running FreeBSD 6.1 under Parallels build 1848, 12 June 2006. The host is a Intel Mac Mini with 2GB's of memory running Mac OS-X 10.4.6. The virtual system is located on a Maxtor OneTouch III External Firewire drive. The drive is 7200RPM, 500GB with a 16MB cache. During heavy FreeBSD IO. I see read_dma timeout errors such as:

    Jun 23 14:09:35 papa kernel: ad2: TIMEOUT - READ_DMA retrying (1 retry left) LBA=260889183

    This doesn't seem to be causing any problems for FreeBSD so far, but I wonder if anyone else has seen it. I used plain disk images for all the BSD drives.

    Any suggestions?

    Thanks,

    --Bruce
     
  2. rbc

    rbc

    Messages:
    11
    I can add some additional information. I created the virtual server with two disk drives, 21505 MB and 128000 MB. The smaller drive is used for FreeBSD system partitions, specifically /, swap, /tmp, /var and /usr. The larger drive is used for non system data such as home directories and web site data. I get the errors during a data database update using postgres.
     
  3. rbc

    rbc

    Messages:
    11
    I think that I found what might be the problem. According to a Mac mini Developer Note, the firewire port on the core duo is connected to the South Bridge controller using a dedicated 33Mhz PCI bus. Here's a link to the drawing:

    http://devworld.apple.com/documenta...ptual/Macmini_0602/Articles/architecture.html

    The USB 2.0 controller is integrated into the South Bridge somehow.

    I'm going to try using USB instead of Firewire and see if that makes a difference on the Mac Mini Core Duo. My Maxtor OneTouch III supports both USB 2.0 and Firewire. I'll post my results.
     
  4. rbc

    rbc

    Messages:
    11
    Well, I tried FreeBSD 6.1 with it's virtual drives on the internal mac mini drive, external firewire and external USB2. During periods of heavy disk IO, I get read_dma timeouts. Whatever the issue is, it seems to be consistant over separate drives and mac mini io systems. This is the error I'm getting:

    Jun 27 14:46:24 papa kernel: ad2: TIMEOUT - READ_DMA retrying (1 retry left) LBA=245801855

    None of this has caused a kernel panic yet. Anyone else seen this kind of thing?

    Thanks,

    --Bruce
     
  5. willmc

    willmc

    Messages:
    12
    Me too!

    I also get this message under heavy disk I/O situations. I'm on a MacBook Pro 2.16GHz Core Duo running FreeBSD 6.1 under Parallels build 1940 with the virtual hard disk on an external FireWire 400 drive. I've noticed that shortly before it happens, the VM seems to alternate back and forth between indicating heavy and no HD activity (about one or two seconds each), even though I can hear the actual disk it's on working away the entire time and the guest OS should be writing to the disk steadily. Sometimes it cycles, sometimes it just does this pause once in a while. It seems almost like there's some sort of buffer getting emptied and then filled again that the VM is waiting on (and causing the guest OS to time out), though that doesn't really make sense.

    I can reproduce this easily enough with a simple "cat /dev/zero > foo", though it takes the better part of a minute for it to happen. Some things seem to cause it more frequently (like rsync-ing /home from another machine on my LAN to my VM), though I'm not sure that it's consistent. It may be, I just can't tell, yet.

    Anyone have any ideas? As the previous poster said, it doesn't seem to cause any problems, but it's definitely a little alarming.
     
  6. tshawkins

    tshawkins

    Messages:
    3
    I get the same problem on bsd 6.1 and 6.2, and im not using any external drives at all, using 3120
     
  7. willmc

    willmc

    Messages:
    12
    Still happening...

    Just wanted to bump this thread as I'm still experiencing this issue intermittently under a variety of FreeBSD 6.2 virtual machines using build 3188 of Parallels. Still haven't figured out what causes it to appear, nor does it seem to be actually causing problems (yet).
     

Share This Page