Re: kernel BUG at drivers/pci/intel-iommu.c:1373!

[Chris Mason]

On Tue, 2008-09-09 at 09:19 -0700, mark gross wrote:
> On Mon, Sep 08, 2008 at 10:26:04AM -0400, Chris Mason wrote:
> > 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.
> 
> I have a bad feeling about this.  Can you retest booting with a kernel
> parrameter "intel_iommu=strict"?

Sorry, I'm going to have to try this again after the plumber's conf.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/