linux-kernel - Re: [Bug #14375] Intel(R) I/OAT DMA Engine init failed

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: <1256595182.19520.5.camel@dwillia2-linux.ch.intel.com>
Date:	Mon, 26 Oct 2009 15:13:02 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Alexander Beregalov <a.beregalov@...il.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [Bug #14375] Intel(R) I/OAT DMA Engine init failed

On Mon, 2009-10-26 at 14:57 -0700, Alexander Beregalov wrote:
> 2009/10/26 Rafael J. Wysocki <rjw@...k.pl>:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.31.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> > Subject         : Intel(R) I/OAT DMA Engine init failed
> > Submitter       : Alexander Beregalov <a.beregalov@...il.com>
> > Date            : 2009-10-02 9:46 (25 days old)
> > References      : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> > Handled-By      : Dan Williams <dan.j.williams@...el.com>
> > Patch           : http://patchwork.kernel.org/patch/51808/
> 
> When I patch reiserfs the bug goes to libata, it means ioatdma works
> and libata does not. It looks like inaccurate work with memory
> somewhere, but I do not know how to find it.
> I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.

If it helps the debug, the symptom seems to be that all interrupts get
turned off.  Neither the normal device completion interrupt nor the
completion watchdog timer fire before the self test timeout.  It seems
something else re-enables interrupts eventually, but we know they were
at least disabled for 3 seconds.  An unmatched spin_unlock_irq in an
async initialization path perhaps?

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