Netdev List
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Phillip Michael Jordan <phil@philjordan.eu>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] skge: Fix/workaround for DMA mask quirk on ASUS P5NSLI/Marvell Yukon-Lite
Date: Tue, 10 Feb 2009 14:45:23 -0800	[thread overview]
Message-ID: <20090210144523.6f1e98e1@extreme> (raw)
In-Reply-To: <f1a0791a0902101415n47a825d9gf83d6908d6a8646a@mail.gmail.com>

On Tue, 10 Feb 2009 23:15:43 +0100
Phillip Michael Jordan <phil@philjordan.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...

  reply	other threads:[~2009-02-10 22:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10 18:56 [PATCH] skge: Fix/workaround for DMA mask quirk on ASUS P5NSLI/Marvell Yukon-Lite Phillip Michael Jordan
2009-02-10 19:14 ` Stephen Hemminger
2009-02-10 22:15   ` Phillip Michael Jordan
2009-02-10 22:45     ` Stephen Hemminger [this message]
2009-02-11  0:19       ` Phillip Michael Jordan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090210144523.6f1e98e1@extreme \
    --to=shemminger@linux-foundation.org \
    --cc=netdev@vger.kernel.org \
    --cc=phil@philjordan.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox