From: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
To: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
John Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
Stefano Brivio <st3-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
Subject: Re: [PATCH] bcm43xx: further fix for periodic work errors
Date: Sat, 23 Sep 2006 22:22:30 +0200 [thread overview]
Message-ID: <200609232222.31126.mb@bu3sch.de> (raw)
In-Reply-To: <451593A0.8030104-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Saturday 23 September 2006 22:05, Larry Finger wrote:
> Michael Buesch wrote:
> >
> > Well, even _if_ mac_suspend takes a few milliseconds (which it
> > does not), it would not trigger the watchdog.
> > I measured the time it takes to execute the various works
> > and based the badness selection on the results.
> >
> > If the 15 or 30 second work is really able to trigger a watchdog
> > timeout, it's a _bug_ that needs to be fixed and not to be
> > papered over.
> > It won't trigger the watchdog, because it is running too long
> > uninterruptible (it won't run 5sec...). If it triggers, it's
> > triggered by something else (like the synchronize_net thingie
> > in the past).
>
> Even the synchronize_net problem wasn't taking 5 seconds to complete, it was messing up the transmit
> process.
That's what I am saying. There must be another similiar bug.
> I went back to check my logs again, and the actual error was "BCM43xx_IRQ_XMIT_ERROR", which is
> always preceded by a MAC suspend failed. These never happened all the time I was running with
> MAXIMUM_BADNESS of 0.
We can debug with the recently spec'ed reason and error registers why
this is triggered. See v4 specs.
> I think the _bug_ is letting the transmit process run while doing the periodic work,
No. We don't let TX run while doing any periodic work (slow or fast).
Same for the IRQ handler.
We take the IRQ lock, which protects against IRQ and TX path (and everything else).
The _only_ difference between slowpath and fastpath periodic work is
that slowpath (long) periodic work is preemptible. This is gained
by not taking the IRQ lock, but protecting it otherwise (disabling IRQs and TX).
So what you are doing by your patch is: _never_ taking the lock.
> which is why
> I'm testing with the tx_disable before all periodic work. I'll let you know in 2 or 3 days if it
It is not needed. tx_disable is only needed for long periodic work.
--
Greetings Michael.
prev parent reply other threads:[~2006-09-23 20:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-23 4:08 [PATCH] bcm43xx: further fix for periodic work errors Larry Finger
[not found] ` <4514B322.mail1K91A36N8-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-23 7:56 ` Michael Buesch
[not found] ` <200609230956.05475.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
2006-09-23 19:06 ` Larry Finger
[not found] ` <451585D1.3080102-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-23 19:41 ` Michael Buesch
2006-09-23 20:05 ` Larry Finger
[not found] ` <451593A0.8030104-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-23 20:22 ` Michael Buesch [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=200609232222.31126.mb@bu3sch.de \
--to=mb-fseuscv1ubazqb+pc5nmwq@public.gmane.org \
--cc=Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org \
--cc=bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org \
--cc=linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=st3-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.