linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Cc: John W Linville <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org, bcm43xx-dev@lists.berlios.de
Subject: Re: [PATCH] b43: Mask PHY TX error interrupt, if not debugging
Date: Thu, 19 Mar 2009 21:10:08 +0100	[thread overview]
Message-ID: <200903192110.08437.mb@bu3sch.de> (raw)
In-Reply-To: <35D36C55-6CB3-443C-A916-D5771B68DD9A@ing.unibs.it>

On Thursday 19 March 2009 20:56:52 Francesco Gringoli wrote:
> I would agree with you, but there is this bizarre issue with PHY  
> errors in monitoring mode that makes me thinking about what we call  
> PHY errors. I would say they are not only due to transmission, they  
> are general PHY errors, could they be? One last test I could try, is  

No the interrupt indicates a PHY TX error.
This name is from the broadcom headers, so we can trust that it's correct.

As I said, I never saw the error with the proprietary firmware in monitor mode.
If you know a way how to trigger them, please tell me.

> to put again the broken minipci to pci adapter in one pci slot and put  
> on the next slot the adapter that does not trigger these errors. If  
> the interference caused by the broken adapter induces the wifi boards  
> on top of it in errors, it should induce the same error on the board  
> mounted on the right adapter.

Well, the question is what can we learn from this test? ;)
What we really need is a way to find out which part of the PHY triggers
this error. We have a dozen of methods to trigger the error. But we _still_
do not know the lowlevel PHY conditions that result in an error.

Probably somebody with lots of time should randomly go through the code
and set various PHY thresholds to big/small values. Maybe that'll point us into
some direction. The problem is that the code basically is undocumented and we
only write blob values to the registers. So from reading the code you won't even
know where these values are written. But the specs give some useful hints. ;)

-- 
Greetings, Michael.

  reply	other threads:[~2009-03-19 20:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-19 18:27 [PATCH] b43: Mask PHY TX error interrupt, if not debugging Michael Buesch
2009-03-19 18:32 ` Michael Buesch
2009-03-19 19:00 ` Francesco Gringoli
2009-03-19 19:13   ` Michael Buesch
2009-03-19 19:56     ` Francesco Gringoli
2009-03-19 20:10       ` Michael Buesch [this message]
2009-03-19 20:15         ` Francesco Gringoli
2009-03-19 20:53         ` Larry Finger

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=200903192110.08437.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=francesco.gringoli@ing.unibs.it \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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).