From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030451Ab2CBR53 (ORCPT ); Fri, 2 Mar 2012 12:57:29 -0500 Received: from wavehammer.waldi.eu.org ([82.139.201.20]:51080 "EHLO wavehammer.waldi.eu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758689Ab2CBR5Y (ORCPT ); Fri, 2 Mar 2012 12:57:24 -0500 Date: Fri, 2 Mar 2012 18:57:19 +0100 From: Bastian Blank To: Dan Williams Cc: Jonathan Nieder , xen-devel@lists.xensource.com, pkg-xen-devel@lists.alioth.debian.org, Maciej Sosnowski , linux-kernel@vger.kernel.org, William Dauchy , Konrad Rzeszutek Wilk , Dave Jiang Subject: Re: [Pkg-xen-devel] ioatdma: Boot process hangs then reboots when using Xen + Linux 3.2 Message-ID: <20120302175719.GA1468@wavehammer.waldi.eu.org> Mail-Followup-To: Dan Williams , Jonathan Nieder , xen-devel@lists.xensource.com, pkg-xen-devel@lists.alioth.debian.org, Maciej Sosnowski , linux-kernel@vger.kernel.org, William Dauchy , Konrad Rzeszutek Wilk , Dave Jiang References: <20120127144737.GA27750@andromeda.dapyr.net> <20120219223125.GA820@burratino> <20120220181618.GD17566@burratino> <4F4891B8.9050008@goirand.fr> <20120302055715.GA692@burratino> <20120302162159.GB31683@wavehammer.waldi.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 02, 2012 at 08:44:00AM -0800, Dan Williams wrote: > On Fri, Mar 2, 2012 at 8:21 AM, Bastian Blank wrote: > > On Thu, Mar 01, 2012 at 10:42:44PM -0800, Dan Williams wrote: > >> WARN_ON may work, but then kernel may be subject random hangs from missed > >> i/o completions. > ...actually descriptors completing too early. The interrupt happens while the module is still loading, so most likely directly after enabling them. There should be no request in flight yet. What puzzles me is the mix of different data types in the ioatdma driver: | u64 completion = *chan->completion; | unsigned long phys_complete = completion & ~0x3f; The state is 64bit long, but is down converted to a 32bit value without anything. phys_complete (a 32 bit value) gets compared to struct dma_async_tx_descriptor.phys, which is defined as dma_addr_t, a _64_ bit value. Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5