<p>[replying from phone]</p>
<p>WARN_ON may work, but then kernel may be subject random hangs from missed i/o completions.  Is xen32 using vt-d?  Just wondering if writes from ioat device are getting misdirected.</p>
<p>--<br>
Dan</p>
<div class="gmail_quote">On Mar 1, 2012 9:57 PM, "Jonathan Nieder" <<a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Dan,<br>
<br>
Thomas and William (cc-ed) have been having trouble loading the<br>
ioatdma driver on a 32-bit Xen dom0.  The module loads automatically<br>
at boot time and trips<br>
<br>
        BUG_ON(active && !seen_current); /* no active descs have written a completion? */<br>
<br>
from drivers/dma/ioat/dma_v2.c.  That check has been present since<br>
5cbafa65b92e (ioat2,3: convert to a true ring buffer, 2009-08-26).<br>
The bug is probably in Xen code and seems to be a regression (the bug<br>
is present in 3.2 but not 3.1.8).<br>
<br>
Thomas Goirand wrote:<br>
> On 03/01/2012 11:53 PM, Bastian Blank wrote:<br>
>> On Thu, Mar 01, 2012 at 06:02:15PM +0800, Thomas Goirand wrote:<br>
<br>
>>>                     Any clue why I don't see crashes without Xen, with a<br>
>>> 64 bits kernel, or with earlier versions of Linux (eg: 3.1 for example)?<br>
>><br>
>> xen/i386 uses a different memory model to anything else, this may be a<br>
>> problem.<br>
[...]<br>
> Replacing BUG_ON by a WARN_ON, and adding #define DEBUG 1 on top of<br>
> dma_v2.c, my kernel booted, and I had the attached dmesg output.<br>
><br>
> Blacklisting the ioatdma kernel module of course, solved the issue.<br>
><br>
> I hope that helps, please let me know if I should do more to help. If<br>
> you need access to my server, that's possible (I use it only for<br>
> packaging XCP and some tests...).<br>
<br>
I don't expect you to debug this Xen-specific bug, but I'm wondering:<br>
is there any reason this check has to be a BUG_ON instead of a<br>
WARN_ON?  If there is some way to recover when the impossible happens,<br>
that would make using and debugging the kernel a little easier.<br>
<br>
Curious,<br>
Jonathan<br>
</blockquote></div>