lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120302055715.GA692@burratino>
Date:	Thu, 1 Mar 2012 23:57:16 -0600
From:	Jonathan Nieder <jrnieder@...il.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Thomas Goirand <thomas@...rand.fr>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>,
	xen-devel@...ts.xensource.com, William Dauchy <wdauchy@...il.com>,
	Maciej Sosnowski <maciej.sosnowski@...el.com>,
	pkg-xen-devel@...ts.alioth.debian.org, linux-kernel@...r.kernel.org
Subject: Re: ioatdma: Boot process hangs then reboots when using Xen + Linux
 3.2

Hi Dan,

Thomas and William (cc-ed) have been having trouble loading the
ioatdma driver on a 32-bit Xen dom0.  The module loads automatically
at boot time and trips

	BUG_ON(active && !seen_current); /* no active descs have written a completion? */

from drivers/dma/ioat/dma_v2.c.  That check has been present since
5cbafa65b92e (ioat2,3: convert to a true ring buffer, 2009-08-26).
The bug is probably in Xen code and seems to be a regression (the bug
is present in 3.2 but not 3.1.8).

Thomas Goirand wrote:
> On 03/01/2012 11:53 PM, Bastian Blank wrote:
>> On Thu, Mar 01, 2012 at 06:02:15PM +0800, Thomas Goirand wrote:

>>>                     Any clue why I don't see crashes without Xen, with a
>>> 64 bits kernel, or with earlier versions of Linux (eg: 3.1 for example)?
>>
>> xen/i386 uses a different memory model to anything else, this may be a
>> problem.
[...]
> Replacing BUG_ON by a WARN_ON, and adding #define DEBUG 1 on top of
> dma_v2.c, my kernel booted, and I had the attached dmesg output.
>
> Blacklisting the ioatdma kernel module of course, solved the issue.
>
> I hope that helps, please let me know if I should do more to help. If
> you need access to my server, that's possible (I use it only for
> packaging XCP and some tests...).

I don't expect you to debug this Xen-specific bug, but I'm wondering:
is there any reason this check has to be a BUG_ON instead of a
WARN_ON?  If there is some way to recover when the impossible happens,
that would make using and debugging the kernel a little easier.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ