From: Jason Wang <jasowang@redhat.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: David Miller <davem@davemloft.net>,
dwmw2@infradead.org, netdev@vger.kernel.org
Subject: Re: [PATCH] 8139cp: set ring address after enabling C+ mode
Date: Fri, 23 Nov 2012 11:53:55 +0800 [thread overview]
Message-ID: <50AEF353.8000601@redhat.com> (raw)
In-Reply-To: <50ADAFB7.7070704@pobox.com>
On 11/22/2012 12:53 PM, Jeff Garzik wrote:
> On 11/21/2012 11:39 PM, David Miller wrote:
>> From: Jeff Garzik <jgarzik@pobox.com>
>> Date: Wed, 21 Nov 2012 22:47:39 -0500
>>
>>> State A: pre-b01af457, known working
>>> State B: b01af457, known broken
>>
>> State A is also known buggy on the largest consumer of this driver,
>> the emulated hardware.
>>
>> Please evaluate this realistically.
>
> If the simulator fails to match the hardware, that is a simulator bug.
Resend the mail because it's fail to post to the list yesterday.
CC realtek linux driver mainter (nic_swsd@realtek.com)
The problem the behaviour of the hardware is subtle, and we could not
just infer it from the datasheet. Another issue is in some situation,
the datasheet is conflict with what real hardware does, one example is
the cfg9364 issue mentioned by David ( I also meet it during qemu
development).
If the hardware always fit garbage into the TxRingAddr register when
"plus mode" were enabled, it may send something from memory to the wire
unexpectedly which looks really strange. If it does not change the
RxRingAddr when enabling C+, another method is to keep setting the rx
address before C+ enabling but does the tx after.
>
> It is disappointing to work around someone else's software bug in the
> kernel.
>
Qemu also has some workarounds for the buggy kernels and even in this
case: it initialize RxRingAddr to 0 and check it during receiving, it
check whether the addr is still zero ( which may mean the rx ring addr
were set after the c+ is enabled), it won't do the receiving to prevent
the corruption. So reverting is safe for rx now.
> Jeff
>
>
>
next prev parent reply other threads:[~2012-11-23 3: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
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 [this message]
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=50AEF353.8000601@redhat.com \
--to=jasowang@redhat.com \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--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).