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 14:45:23 -0800
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Phillip Michael Jordan <phil@...ljordan.eu>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] skge: Fix/workaround for DMA mask quirk on ASUS 
 P5NSLI/Marvell Yukon-Lite

On Tue, 10 Feb 2009 23:15:43 +0100
Phillip Michael Jordan <phil@...ljordan.eu> wrote:

> 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

I also want to know if it is a skge driver bug or Marvell only hardware
problem. Unfortunately, you are kind of far away for me to lend you hardware...
--
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