netdev - Re: [PATCH] skge: Fix/workaround for DMA mask quirk on ASUS P5NSLI/Marvell Yukon-Lite

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]

Date:	Tue, 10 Feb 2009 23:15:43 +0100
From:	Phillip Michael Jordan <phil@...ljordan.eu>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] skge: Fix/workaround for DMA mask quirk on ASUS 
	P5NSLI/Marvell Yukon-Lite

Stephen Hemminger wrote:
> This looks like a good start to a workable workaround.

Thanks,

> I wonder if other PCI devices in same system have the same problem?
> If so, it should be move to PCI quirk.

This is the odd part: everything else works, and has done so with
rock-solid stability for months of fairly heavy use, during which time I
used a replacement PCI network card while the Marvell chip wasn't working.

The other devices include: 2 soundcards (onboard:
snd_hda_intel/snd_ac97_codec and PCI: snd_ca0106), graphics (PCIe:
nvidia or nv), PATA (pata_amd), SATA (sata_nv), USB and the
aforementioned network card (r8169).

However, looking deeper I've been grepping through the kernel source for
DMA_64BIT_MASK. The only drivers that can even handle 64-bit DMA and
also happen to be used in this system are r8169: only if the module
parameter use_dac is set. (described as "Unsafe on 32 bit PCI slot."
which doesn't sound good - my 8169 card has
a 32-bit PCI connector and is therefore probably unsuitable for
testing in this case) and hda_intel: if the capability bit is set by
the hardware, which it is on mine, I printk'd it.

The sound chip in question resides on a different bus though (00 vs
06) as it's integrated into the chipset, so that might it useless for
comparison?

So the skge module is the only one for devices on the external bus
that currently even attempts to use 64-bit DMA addresses, and
unfortunately, I don't happen to own any other
pluggable hardware on that 64-bit list.

> Also, since the problem is almost certainly in the PCI bridge to
> skge connection, the quirk should identify based on the upstream bridge,
> rather than the Marvell chip and DMI.

After all that, I now agree that it's probably purely a motherboard
issue, even if I can't verify it with another device.

Sorry to waste your (and the rest of linux-netdev's) time on this. I'll
try and cook up a patch against pci-dma.c and try my luck on linux-pci
instead.

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