linux-kernel - Re: ATL1E 0000:02:00.0: swiotlb buffer is full (sz: 529461 bytes)

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>] [day] [month] [year] [list]

Date:	Fri, 18 Sep 2015 18:55:37 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Chris Snook <chris.snook@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Jay Cliburn <jcliburn@...il.com>, netdev@...r.kernel.org
Subject: Re: ATL1E 0000:02:00.0: swiotlb buffer is full (sz: 529461 bytes)

On 2015.09.18 at 16:42 +0000, Chris Snook wrote:
> I think atl1e is the victim here, not the cause. It's probably the last
> device being brought up that wants to use the swiotlb, so you haven't seen
> other devices failing for the same reason. Can you post your dmesg or boot
> log from both a boot where it works and one where it doesn't, as well as
> lspci -vvv? You may be able to work around it by passing swiotlb=32768 on
> the kernel command line, which doubles the size of that buffer from the
> default.
> 
> The size of that attempted allocation is strange though. It's slightly
> larger than 512K, and it's odd, which suggests we may have a bug in
> calculating the size of that allocation, though we may be faithfully
> working with what we get from the hardware.

The requested files are attached.

-- 
Markus

View attachment "dmesg_good" of type "text/plain" (36246 bytes)

View attachment "dmesg_bad" of type "text/plain" (37439 bytes)

View attachment "lspci" of type "text/plain" (20912 bytes)