netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Jason Wang <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: 8139cp: set ring address before enabling receiver
Date: Wed, 21 Nov 2012 19:51:21 +0000	[thread overview]
Message-ID: <1353527481.26346.150.camel@shinybook.infradead.org> (raw)
In-Reply-To: <50AD1972.5080403@pobox.com>

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Wed, 2012-11-21 at 13:12 -0500, Jeff Garzik wrote:
> 
> What sticks out at me from the commit message?
> 
> It was not tested on the famously quirky 8139 hardware at all.
> 
> While I have not looked at the 8139C+ data sheet in a while, sometimes 
> the hardware _did_ have a strange init order.
> 
> As this works in a simulator but fails on real hardware, it seems like 
> an obvious regression caused by an untested [on read hardware] patch.

The data sheet (v1.6, from http://realtek.info/pdf/rtl8139cp.pdf ) says
in §6.33 (C+ Command Register):
 "Enable C+ mode functions in C+CR register first,
 => Enable transmit/receive in Command register (offset 37h),
 => Configure other related registers (ex. Descriptor start address,
    TCR, RCR, ...)."

I understand the concern expressed in the offending commit message about
DMA happening to invalid addresses, and I'll look at the data sheet
harder to see when the DMA actually starts happening. But it definitely
seems that our current code isn't doing what the data sheet says.

I wonder if I can find one of these lying around and stick it in a
machine with an IOMMU...

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

  reply	other threads:[~2012-11-21 19:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120602235020.2C0A57C006C@ra.kernel.org>
2012-11-21 16:57 ` 8139cp: set ring address before enabling receiver David Woodhouse
2012-11-21 18:12   ` Jeff Garzik
2012-11-21 19:51     ` David Woodhouse [this message]
2012-11-21 20:18       ` Ben Hutchings
2012-11-21 20:40         ` Jeff Garzik
2012-11-21 21:00           ` David Woodhouse
2012-11-21 21:10           ` Ben Hutchings
2012-11-21 20:27     ` [PATCH] 8139cp: set ring address after enabling C+ mode David Woodhouse
2012-11-21 20:40       ` Francois Romieu
2012-11-21 22:32         ` David Woodhouse
2012-11-21 22:40           ` David Miller
2012-11-21 22:52             ` David Woodhouse
2012-11-21 23:12               ` David Miller
2012-11-22  3:47       ` Jeff Garzik
2012-11-22  4:39         ` David Miller
2012-11-22  4:53           ` Jeff Garzik
2012-11-22  5:30             ` Jason Wang
2012-11-22 21:39             ` Francois Romieu
2012-11-22 23:12               ` David Woodhouse
2012-11-23 12:37               ` Gilboa Davara
2012-11-23  3:53             ` Jason Wang
2012-11-25 20:54       ` David Miller

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=1353527481.26346.150.camel@shinybook.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=jgarzik@pobox.com \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).