From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Tom Psyborg <pozega.tomislav@gmail.com>
Cc: linux-wireless@vger.kernel.org,
Randy Oostdyk <linux-kernel@oostdyk.com>,
Daniel Golle <daniel@makrotopia.org>,
Felix Fietkau <nbd@nbd.name>, Mathias Kresin <dev@kresin.me>
Subject: Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full
Date: Sat, 9 Feb 2019 12:03:00 +0100 [thread overview]
Message-ID: <20190209110259.GA14900@redhat.com> (raw)
In-Reply-To: <20190102081934.GA5300@redhat.com>
On Wed, Jan 02, 2019 at 09:19:34AM +0100, Stanislaw Gruszka wrote:
> On Fri, Dec 28, 2018 at 01:45:27AM +0100, Tom Psyborg wrote:
> > >
> > > I move prints to debug level for for "arrived at non-free entry" from
> > > "Dropping frame due to full tx queue" . For some users those 5 patches
> > > improve things, they fix problem of router connection hung completely.
> > > Printk problem is connection stall due to CPU being busy, but
> > > is possible to reconnect to AP after that. It's different issue.
> > >
> > yes they fix hung. same hung that does this single patch fix by moving
> > to dbg so they're not printed at all. FYI "Dropping frame due to full
> > tx queue" causes "arrived at non-free entry" eventually that freezes
> > interface so only reboot helps, removing "Dropping frame due to full
> > tx queue" from printing to logs prevents this kind of hung and is
> > better solution than 5 patches.
>
> I wonder why are you confident about this ? And also why 5 patches
> fixed the hung if there were still "Dropping frame ..." prints ?
>
> Anyway I'll ask people on the bz for confirmation, if stop printing
> is sufficient to fix the wifi hung.
>
> > oh and don't forget to add note that
> > rt2x00_err/rt2x00_dbg prints can cause serious bug so you don't
> > acidentally enable them again in a year or two!
>
> I think I will remember that, for others git changelog should
> be sufficient.
>
> > > Also 'result in lower throughput' is over-generalized statement. More
> > > precise would be 'it lower throughput on some test cases', but even
> > > in those specific cases, throughput vary randomly with and without
> > > patches.
> > >
> >
> > 100Mbps TX 70Mbps RX without and 80Mbps TX 55 Mbps RX with 5
> > patches--> EA2750 HT40 CH2 4.14.82+4.19-rc5-1-1
>
> Ok, this is different case that you presented before on USB devices.
> And I'm more concerned about it, because changes with MMIO ware
> much bigger (for USB only some code was moved and some flush
> changed were done). Please check attached patch, if it fixes
> throughput regression for you ?
So what is the point complaining that I do not provide patches for
testing and when I do, ignore that ?
Anyway I have now MT7620A device and was capable to reproduce the
performance regression. Will provide patches to fix it and still
prevent tx queues hungs.
Stanislaw
next prev parent reply other threads:[~2019-02-09 11:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 15:16 [PATCH v2 1/3] rt2x00: use ratelimited variants dev_warn/dev_err Stanislaw Gruszka
2018-12-20 15:16 ` [PATCH v2 2/3] rt2x00: check number of EPROTO errors Stanislaw Gruszka
2019-01-07 12:47 ` Jeroen Roovers
2019-01-07 15:09 ` Stanislaw Gruszka
2019-01-08 9:30 ` Jeroen Roovers
2019-01-08 10:09 ` Jeroen Roovers
2019-01-08 11:04 ` Tom Psyborg
2019-01-09 6:17 ` Jeroen Roovers
2019-01-09 11:33 ` Stanislaw Gruszka
2019-01-10 7:49 ` Jeroen Roovers
2019-01-10 14:29 ` Jeroen Roovers
2019-01-16 11:11 ` Stanislaw Gruszka
2019-01-22 17:32 ` Jeroen Roovers
2019-02-12 15:02 ` Stanislaw Gruszka
2018-12-20 15:16 ` [PATCH v2 3/3] rt2x00: do not print error when queue is full Stanislaw Gruszka
2018-12-20 17:52 ` Tom Psyborg
2018-12-21 9:59 ` Stanislaw Gruszka
2018-12-22 13:12 ` Tom Psyborg
2018-12-25 22:43 ` Tom Psyborg
2018-12-27 10:32 ` Stanislaw Gruszka
2018-12-27 10:25 ` Stanislaw Gruszka
2018-12-28 0:45 ` Tom Psyborg
2019-01-02 8:19 ` Stanislaw Gruszka
2019-02-09 11:03 ` Stanislaw Gruszka [this message]
2019-02-09 11:11 ` Tom Psyborg
2019-02-09 11:56 ` Stanislaw Gruszka
2019-02-09 12:28 ` Tom Psyborg
2019-02-09 15:38 ` Daniel Golle
2019-02-09 16:29 ` Tom Psyborg
2019-02-09 17:28 ` Daniel Golle
2019-03-19 2:37 ` Tom Psyborg
2019-02-10 9:57 ` Stanislaw Gruszka
2018-12-21 11:19 ` [PATCH v2 1/3] rt2x00: use ratelimited variants dev_warn/dev_err Joe Perches
2018-12-21 11:57 ` Stanislaw Gruszka
2018-12-21 12:48 ` Joe Perches
2018-12-21 12:51 ` Stanislaw Gruszka
2019-01-29 12:30 ` Kalle Valo
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=20190209110259.GA14900@redhat.com \
--to=sgruszka@redhat.com \
--cc=daniel@makrotopia.org \
--cc=dev@kresin.me \
--cc=linux-kernel@oostdyk.com \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=pozega.tomislav@gmail.com \
/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).