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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABE8wwsPA2PUx45EbY3w3BAHaHbUMWo7+giK=uU8gx9mbBkRpQ@mail.gmail.com>
Date:	Tue, 6 Mar 2012 06:14:29 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Thomas Goirand <zigo@...ian.org>
Cc:	xen-devel@...ts.xensource.com, Dave Jiang <dave.jiang@...el.com>,
	pkg-xen-devel@...ts.alioth.debian.org,
	Maciej Sosnowski <maciej.sosnowski@...el.com>,
	linux-kernel@...r.kernel.org, Jonathan Nieder <jrnieder@...il.com>,
	William Dauchy <wdauchy@...il.com>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>
Subject: Re: [Pkg-xen-devel] ioatdma: Boot process hangs then reboots when
 using Xen + Linux 3.2

On Tue, Mar 6, 2012 at 1:20 AM, Thomas Goirand <zigo@...ian.org> wrote:
> On 03/05/2012 11:38 PM, Dan Williams wrote:
>> On Mon, Mar 5, 2012 at 7:26 AM, Thomas Goirand <zigo@...ian.org> wrote:
>>> I will do my best to provide it ASAP. Should I compile with BUG_ON so
>>> you see it crashing, as per the original code, or just with WARN_ON, so
>>> you also see further things in dmesg?
>>
>> Yes, replacing with a WARN_ON might allow it to skid after the crash
>> and give a bit more information.
>>
>> Thank you for grabbing this info.
>>
>> --
>> Dan
>
> Hi Dan,
>
> Please find attached the log that you asked me, with WARN_ON instead of
> BUG_ON, and with the 2 #define DEBUG in dma.c and dma_v2.c.
>

[    9.276817] ioatdma 0000:00:16.4: desc[0]:
(0x300cc7000->0x300cc7040) cookie: 0 flags: 0x2 ctl: 0x29 (op: 0
int_en: 1 compl: 1)
...
[    9.276832] ioatdma 0000:00:16.4: ioat_get_current_completion:
phys_complete: 0xcc7000

Thanks, this clearly shows that our descriptors are above 4GB and that
the driver truncates the completion word.

Is this new behavior for xen?

Before you had mentioned that non-xen 32-bit builds don't fail.  Can
you send me the .config from those two cases (offlist if they are too
large)?  I'm looking for what config option enables this so I can
quote it in the patch to increase the size of phys_complete.
Certainly this changes my assumptions of what address ranges
GFP_KERNEL memory will be located.

--
Dan
--
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