linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mattias Nissler <mattias.nissler@gmx.de>
To: Ivo van Doorn <ivdoorn@gmail.com>
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 20:48:56 +0100	[thread overview]
Message-ID: <1195156136.28648.84.camel@localhost> (raw)
In-Reply-To: <200711152058.40520.IvDoorn@gmail.com>


On Thu, 2007-11-15 at 20:58 +0100, Ivo van Doorn wrote:
> 
> 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.

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.

Mattias


  reply	other threads:[~2007-11-15 19:49 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 [this message]
2007-11-15 22:59                     ` Ivo van Doorn
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=1195156136.28648.84.camel@localhost \
    --to=mattias.nissler@gmx.de \
    --cc=flo@rfc822.org \
    --cc=ivdoorn@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=marcus@better.se \
    --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 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).