Hello everyone,
I originally hit this with btrfs and assumed I was doing something
wrong, but it looks like it is a generic problem. The stack trace at
the bottom of this email came from the following setup:
mdadm --create /dev/md0 --level=1 --raid-devices=4 --assume-clean /dev/sd[cdef]
mkfs.ext4dev /dev/md0 50000000
mount /dev/md0 /mnt
synctest -t 100 -F -f -u /mnt
synctest is an old benchmark from akpm that I dug up to test the btrfs
fsync code. google doesn't seem to know much about it anymore, so I've
tossed it up here:
http://oss.oracle.com/~mason/synctest/synctest.c
The important part is that I have a software raid1 volume with 4 drives
and that I'm hammering on it has hard as I can with synchronous writes
from 100 procs.
MD uses bio_clone to make copies of bios for each device in the mirror
set. So, using 4 devices means each bio is cloned 3 times, greatly
increases the chances that I'll send down the same page in different
bios to different devices.
Ext4 needs about 10 minutes to trigger on top of MD. Btrfs needs about
30 seconds when it controls the 4 devices itself.
I've been told this BUG in the io-mmu code comes when someone tries to
map a page into the iommu that has already been mapped. It seems like
that is a natural result of bio_clone, and not an inherent race in the
code. But, I've just said everything I know about the iommu code, so my
guesses don't mean much.
-chris
kernel BUG at drivers/pci/intel-iommu.c:1373!
invalid opcode: 0000 [1] SMP
CPU 5
Modules linked in: ext4dev jbd2 crc16 netconsole configfs raid1 md_mod loop 3w_9xxx
Pid: 0, comm: swapper Not tainted 2.6.27-rc5-hgac1744ddb3a6 #78
RIP: 0010:[<ffffffff803a4ec3>] [<ffffffff803a4ec3>] domain_page_mapping+0x195/0x1e8
RSP: 0018:ffff88015fb7faa0 EFLAGS: 00010006
RAX: 00000000000001d0 RBX: 0000000000000012 RCX: ffff88000000000c
RDX: 0000000151c08001 RSI: 0000000000000006 RDI: ffff88015b46d3c8
RBP: ffff88015fb7fb10 R08: 0000000000000001 R09: ffff8801217bf380
R10: ...
