From: Ivo van Doorn <ivdoorn@gmail.com>
To: Mattias Nissler <mattias.nissler@gmx.de>
Cc: Will Dyson <will.dyson@gmail.com>,
"John W. Linville" <linville@tuxdriver.com>,
Florian Lohoff <flo@rfc822.org>, Marcus Better <marcus@better.se>,
linux-wireless@vger.kernel.org,
rt2400-devel <rt2400-devel@lists.sourceforge.net>
Subject: Re: rt2x00/rt2500 PCI unresponsive / sluggish response
Date: Thu, 15 Nov 2007 23:59:29 +0100 [thread overview]
Message-ID: <200711152359.31416.IvDoorn@gmail.com> (raw)
In-Reply-To: <1195156136.28648.84.camel@localhost>
Hi,
> > Perhaps we should test if clearing the ENTRY_TXD_ACK unconditionally
> > for cts and rts frames would help. (patch located at the bottom).
> > In fact I wonder if clearing that flag would fix the rt61pci to run txdone
> > for all frames (opposed to skipping an occasional entry).
>
> Hm, I would think we actually should *set* the flag for rts frames,
> cause we expected them to be acked by cts, right? IIRC, this actually is
> what the legacy driver does.
True we expect them to be acked, but we also set the RTS flag which
*could* mean that setting that flag tells the device to wait for the cts response.
So perhaps it is worth a shot to see if not setting the ACK flag actually
helps in the responsiveness.
> Concerning the rt61 problem, I've done an experiment: I changed the
> code to drop out of the interrupt handler on every second interrupt
> without doing anything. That way, the driver doesn't execute the txdone
> logic for some txdone interrupts. This change triggered the missing tx
> report messages. So the rt61 hardware probably proceeds to the next
> entry after the interrupt is handled by the host. Question now is
> whether it is possible that we actually miss an interrupt? This would be
> an explanation for the missing tx status reports. I plan to have a
> closer look at interrupt handling in the kernel to see whether I can
> find something.
Ivo
next prev parent reply other threads:[~2007-11-15 22:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-11 10:23 rt2x00/rt2500 PCI unresponsive / sluggish response Florian Lohoff
2007-11-12 22:59 ` Will Dyson
2007-11-13 19:23 ` Florian Lohoff
2007-11-14 8:58 ` Marcus Better
2007-11-14 12:17 ` Florian Lohoff
2007-11-14 12:19 ` Marcus Better
2007-11-15 1:20 ` John W. Linville
2007-11-14 15:33 ` Florian Lohoff
2007-11-14 18:57 ` Will Dyson
2007-11-14 21:13 ` John W. Linville
2007-11-15 2:40 ` Will Dyson
2007-11-15 10:11 ` Mattias Nissler
2007-11-15 19:58 ` Ivo van Doorn
2007-11-15 19:48 ` Mattias Nissler
2007-11-15 22:59 ` Ivo van Doorn [this message]
2007-11-15 8:48 ` Marcus Better
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=200711152359.31416.IvDoorn@gmail.com \
--to=ivdoorn@gmail.com \
--cc=flo@rfc822.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcus@better.se \
--cc=mattias.nissler@gmx.de \
--cc=rt2400-devel@lists.sourceforge.net \
--cc=will.dyson@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 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.