netdev - Re: [RFC] r8169 DMA failure with iommu=off

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: <20150501121236.GA13214@electric-eye.fr.zoreil.com>
Date:	Fri, 1 May 2015 14:12:36 +0200
From:	Francois Romieu <romieu@...zoreil.com>
To:	Stephen Hemminger <shemming@...cade.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: [RFC] r8169 DMA failure with iommu=off

Stephen Hemminger <shemming@...cade.com> :
> This only fixes the Rx side, what about Tx?
> 
> I think maybe just removing the whole use_dac flag completely ?

Something simple would be welcome but I doubt it should be that simple.

The problems that the use_dac comment (MODULE_PARM_DESC) relates to
are 2003 ~ 2004, plain old PCI 8169 stuff. I see no problem exchanging
the use_dac test for something else (Config2.BIT(3) test for bus width
or old PCI chipsets blacklist).

I lack explicit reports to tell if high dma is safe with the PCI-E
chipsets but it's worth testing. The DAC bit in the CPlusCmd register
is indirectly documented in my old 8168c datasheet through the 64 bit
address capable bit of the MSI message control word (it's missing in
the section dedicated to the CPlusCmd register :o/). Expect it to
initially mirror some eeprom value.

Other than that I am mostly unqualified when it comes to high DMA paths
in the upper parts of the transmit stack.

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html