From: Pavel Roskin <proski@gnu.org>
To: Michael Buesch <mb@bu3sch.de>
Cc: bcm43xx-dev@lists.berlios.de, netdev@vger.kernel.org
Subject: Re: Can someone please try...
Date: Mon, 22 Jan 2007 15:44:36 -0500 [thread overview]
Message-ID: <1169498676.4453.14.camel@dv> (raw)
In-Reply-To: <200701222106.24329.mb@bu3sch.de>
Hello, Michael!
On Mon, 2007-01-22 at 21:06 +0100, Michael Buesch wrote:
> It's obviously some stack/memory corruption. But I'm not
> sure if this is a stackoverflow. I'd rather say no, it isn't.
>
> Could probably be triggered by something like kfree()ing
> a dangling pointer or something...
Yes. That's what my patch was for ("Fix major memory corruption bug").
It was pretty hard to catch because I would find the consequences rather
than to the offending code. I got lucky after I enabled some weird
options, such as 64Gb support and highmem debugging. Whether it played
any role or not, the oops finally happened where the driver tried to
erase memory pointed to by the stale phy->lo_control pointer.
Now the situation is following.
No more random crashes. There is still a crash if I rmmod the driver
while wlan0 is up, but it's a separate issue, and it's easy to avoid
(unlike the interface going down). I hope to look at it soon.
The driver connects to a 802.11b Linksys router just fine. I can send
and receive data. The driver is fully functional. 128-bit WEP is
supported.
There are periodic bursts of assertion failures. Looking at the driver,
I see three places where lna a.k.a. phy->lo_gain[0] is assigned the
value of 32 (written as 0x20 in one place). It's not surprising that it
exceeds 7 in lo_measure_feedthrough().
I think the assert() should be replaced with a FIXME, which would not
annoy end users so much. And while at that, it would be great to
replace phy->lo_gain with four fields with descriptive names.
phy->lo_gain is never used as an array. Alternatively, you could make
it a structure within bcm43xx_phy.
The problems with a MadWifi based AP turn out to be related to 802.11g.
If the AP is configured for 802.11b only, everything is working. If
802.11g is enabled, strange things are happening. Judging by what's on
the air, it looks like the driver loses the data frames is receives.
wpa_supplicant connects instantly, but ARP and ping packets from AP to
STA are lost. The frames are even acknowledged, but not seen on the
station side. It takes from one to ten minutes util ping suddenly
starts working.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2007-01-22 20:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-16 17:06 Can someone please try Michael Buesch
2007-01-16 18:29 ` Pavel Roskin
2007-01-16 19:23 ` Michael Buesch
2007-01-16 21:50 ` Pavel Roskin
2007-01-16 22:07 ` Michael Buesch
2007-01-16 23:51 ` Pavel Roskin
2007-01-17 9:52 ` Michael Buesch
2007-01-18 9:41 ` Pavel Roskin
2007-01-19 7:54 ` Pavel Roskin
2007-01-22 20:06 ` Michael Buesch
2007-01-22 20:44 ` Pavel Roskin [this message]
2007-01-22 21:00 ` Michael Buesch
2007-01-22 22:04 ` Larry Finger
2007-01-23 6:14 ` Pavel Roskin
2007-01-23 9:21 ` Michael Buesch
[not found] ` <200701231021.34995.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
2007-01-24 5:43 ` Pavel Roskin
2007-01-24 8:43 ` Michael Buesch
2007-01-16 19:00 ` Andreas Schwab
2007-01-16 19:24 ` Michael Buesch
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=1169498676.4453.14.camel@dv \
--to=proski@gnu.org \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=mb@bu3sch.de \
--cc=netdev@vger.kernel.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 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).