From: "Michael Chan" <mchan@broadcom.com>
To: "Andy Gospodarek" <andy@greyhouse.net>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Matt Carlson" <mcarlson@broadcom.com>,
bugme-daemon@bugzilla.kernel.org, netdev <netdev@vger.kernel.org>,
ralf.hildebrandt@charite.de
Subject: Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
Date: Thu, 14 Feb 2008 16:03:09 -0800 [thread overview]
Message-ID: <1203033789.13495.49.camel@dell> (raw)
In-Reply-To: <20080214232103.GM856@gospo.usersys.redhat.com>
On Thu, 2008-02-14 at 18:21 -0500, Andy Gospodarek wrote:
> On Thu, Feb 14, 2008 at 02:48:09PM -0800, Michael Chan wrote:
> > Andy, I think you still missed my point. I don't believe this problem
> > was caused by the bridge or the chipset at all. Some corruption caused
> > us to not find the SKB in the TX ring where it was expected. So the
> > driver assumed it was the bridge re-ordering I/O and printed that
> > warning message and took recovery action. The recovery action had no
> > effect in this case since apparently it was caused by something else and
> > the corruption happened again later. This 2nd time, we hit the BUG_ON()
> > seeing that the recovery action did not work.
> >
> >
>
> Ah, I see. Due to at leat a 2 second delay between the message and the
> panic, I figured it would be good data to gather....
>
>
>
Yeah, 2 seconds for the link to come up after chip reset to recover. It
then panicked sometime later and rebooted about 90 seconds after the
initial warning message.
It was also running at the slower 100Mbps link speed. Tx packets stay
longer in the TX ring at this slower speed, increasing the window of
time that the nr_frags in the SKB can be corrupted.
Ralf, please try the debug patch that I sent out earlier. Thanks.
prev parent reply other threads:[~2008-02-15 0:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-9990-10286@http.bugzilla.kernel.org/>
2008-02-14 18:24 ` [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles Andrew Morton
2008-02-14 18:56 ` Andy Gospodarek
2008-02-14 21:25 ` Michael Chan
2008-02-14 22:12 ` Andy Gospodarek
2008-02-14 22:48 ` Michael Chan
2008-02-14 23:21 ` Andy Gospodarek
2008-02-15 0:03 ` Michael Chan [this message]
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=1203033789.13495.49.camel@dell \
--to=mchan@broadcom.com \
--cc=akpm@linux-foundation.org \
--cc=andy@greyhouse.net \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=mcarlson@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=ralf.hildebrandt@charite.de \
/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).