Jory, thank you for helping convince Michael I was not hallucinating!
Larry, thank you for finding the difference in the kernel output!
Michael, thank you for finding the part of the code affected by the
underlying changes caused by the patch but not changed by the patch!
It works.
I've got
On Friday 10 August 2007 17:02:15 Larry Finger wrote:
Jory A. Pratt wrote:
Larry Finger wrote:
What encryption method are you using?
Larry
I use wep encryption on a WRT54G V3 with dd-wrt. I will work on it later
tonight and see what I can come up with.
Your answer confirms my
Jory A. Pratt wrote:
Larry Finger wrote:
What encryption method are you using?
Larry
I use wep encryption on a WRT54G V3 with dd-wrt. I will work on it later
tonight and see what I can come up with.
Your answer confirms my latest result in which I have been able to reproduce
the problem
Larry Finger wrote:
Jory A. Pratt wrote:
Yes I am able to reproduce it. I have done upgraded and downgraded my
enitre toolchain. exact same problem is present on my system when I
try my 4306 and 4318.
What encryption method are you using?
Larry
I use wep encryption on a WRT54G V3
On Friday 10 August 2007 04:27:33 Ehud Gavron wrote:
I have spent eight hours on this today and I can't find a way to do a
subset of the patches. I haven't quite given up, but I'm reaching a
point where I could use some insight. I didn't copy the list... but
feel free to if you think it of
That change is already built on my kernel (now wireless-dev with two
patches). I'm assuming it's correct, but if you'd like to confirm it,
please let me know which packet(s) to craft in order to test it.
Thanks again,
Ehud
Larry Finger wrote:
Michael Buesch wrote:
On Friday 10 August
Jory A. Pratt wrote:
Yes I am able to reproduce it. I have done upgraded and downgraded my
enitre toolchain. exact same problem is present on my system when I try
my 4306 and 4318.
What encryption method are you using?
Larry
___
Bcm43xx-dev
Michael Buesch wrote:
On Friday 10 August 2007 04:27:33 Ehud Gavron wrote:
I have spent eight hours on this today and I can't find a way to do a
subset of the patches. I haven't quite given up, but I'm reaching a
point where I could use some insight. I didn't copy the list... but
feel
On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote:
The spec is telling us to lookup an invalid index in the LO table.
I see. Thanks for your explanation!
I think the way to solve it would be to see how the table is used in the
proprietary driver. Either the data from the extra entries is
To the list: The beginnings of this thread were done off-list, but I want to
let everyone know about
the problem, and to discover if anyone else has it. Since 2.6.23-rc1, Ehud has
a problem in that the
information his interface is transmitting is garbled. He did a bisection and
discovered that
I had hoped this would be the cure so I don't have to undo the 85a83d26
commit patch by patch.
However, while this did not solve the problem it DID show a new error:
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
On Wednesday 08 August 2007 18:11:03 Larry Finger wrote:
[EMAIL PROTECTED] test]# patch -p1 patch-2007-aug-08-lfinger.txt
patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
Hunk #1 FAILED at 1503.
Hunk #2 FAILED at 1512.
2 out of 2 hunks FAILED -- saving rejects to file
[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
# (use git add file... to include in what will be committed)
#
# arch/x86_64/vdso/vdso.lds
nothing added to commit but untracked files present (use git add to track)
[EMAIL PROTECTED] test]# git diff
[EMAIL
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
# (use git add file... to include in what will be committed)
#
# arch/x86_64/vdso/vdso.lds
nothing added to commit but untracked files present (use git
Michael Buesch wrote:
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
# (use git add file... to include in what will be committed)
#
# arch/x86_64/vdso/vdso.lds
nothing added to commit but untracked
The corrected patch shows the same results. I have a 2.6.23-rc2 kernel
where bcm43xx_mac80211 receives garbage.
Ehud
Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
#
Ehud Gavron wrote:
The corrected patch shows the same results. I have a 2.6.23-rc2 kernel
where bcm43xx_mac80211 receives garbage.
Mumble, mumble, swear words,.
OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off?
Larry
On Wednesday 08 August 2007 19:46:33 Ehud Gavron wrote:
The corrected patch shows the same results. I have a 2.6.23-rc2 kernel
where bcm43xx_mac80211 receives garbage.
Please enable almost every option under Kernel Hacking.
Especially those to detect memory corruption.
But also the lock
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm -rf'd both and re git clone'd them)
[EMAIL PROTECTED] test]# patch -p1
~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch
patching file
Ehud Gavron wrote:
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm -rf'd both and re git clone'd them)
It works here. Again there must be a white-space problem with the patch. A
working version is attached.
On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote:
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm -rf'd both and re git clone'd them)
[EMAIL PROTECTED] test]# patch -p1
Ehud Gavron wrote:
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm -rf'd both and re git clone'd them)
[EMAIL PROTECTED] test]# patch -p1
Re git checkout -f... that's what I thought but when I kept getting the
patch was previously applied... I figured I'd just clean it out. Costs
me 30 minutes of compile/link time, but it's nice'd out of the way.
The new patch (that was attached by you, and that Michael re-referenced)
applied,
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
Ehud
Michael Buesch wrote:
On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote:
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm
On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
What about enabling the Kernel Hacking options I suggested?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote:
On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
What about enabling the Kernel Hacking options I suggested?
On IRC was suggested that this might be a
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote:
On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
What about enabling the Kernel Hacking options I suggested?
On IRC was suggested that this might be a
Pavel Roskin wrote:
On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote:
The spec is telling us to lookup an invalid index in the LO table.
I see. Thanks for your explanation!
I think the way to solve it would be to see how the table is used in the
proprietary driver. Either the data
Ehud,
I was just reviewing the complete dmesg output that you sent earlier, which I
think was for a bad
case. I use WPA encryption, which cannot be done in hardware, and I have not
seen messages that look
like this:
bcm43xx-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
Ehud Gavron wrote:
good: rc1 git test tree with the commit in question reversed. Works fine.
bad: rc2 git wireless-dev tree with Michael's latest patch. Does not
work.
full dmesg, iwconfig, and ifconfigs included.
Like I said, I am happy to do this all day long so that I don't have to
Understood. Files attached. This time I set the channel so that
bcm43xx_mac80211(noworkie) would associate with the same AP that
bcm43xx_mac80211(workie) does.
For infrastructure reference there are two APs on the LAN, and one has a
WDS with a third AP. All are Buffalo Airstations 54G.
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:
Well, it's not that easy. Current code just doesn't make any sense.
I do not understand how hardware power control works exactly, so I
can't write some detailed message or something.
That's probably a chicken and egg problem ;)
OK, the
On Monday 06 August 2007, Pavel Roskin wrote:
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:
Well, it's not that easy. Current code just doesn't make any sense.
I do not understand how hardware power control works exactly, so I
can't write some detailed message or something.
On Mon, 2007-08-06 at 08:42 -0400, Joseph Jezak wrote:
The problem is that the reverse engineering team (myself and
Johannes) don't understand the code in the original driver well
enough. The power control code is certainly the most confusing and
incomplete part of our specs. While I'd
Pavel Roskin wrote:
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:
Well, it's not that easy. Current code just doesn't make any sense.
I do not understand how hardware power control works exactly, so I
can't write some detailed message or something.
That's probably a chicken and
On Monday 06 August 2007, John W. Linville wrote:
On Sat, Aug 04, 2007 at 06:47:29PM +0200, Michael Buesch wrote:
On Saturday 04 August 2007, Larry Finger wrote:
Pavel Roskin wrote:
On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote:
The size of LO array message is not fatal.
Michael Buesch wrote:
Well, without a stacktrace you don't know who caused the error.
We can remove that. But I still don't know what we gain from
removing useful debug messages. If you don't care about bcm43xx bugs, simply
disable bcm43xx debugging.
Michael, I agree with you in general,
On Monday 06 August 2007, Larry Finger wrote:
Michael Buesch wrote:
Well, without a stacktrace you don't know who caused the error.
We can remove that. But I still don't know what we gain from
removing useful debug messages. If you don't care about bcm43xx bugs, simply
disable bcm43xx
On 8/6/07, Pavel Roskin [EMAIL PROTECTED] wrote:
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:
Well, it's not that easy. Current code just doesn't make any sense.
I do not understand how hardware power control works exactly, so I
can't write some detailed message or something.
On Saturday 04 August 2007, Larry Finger wrote:
Pavel Roskin wrote:
On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote:
The size of LO array message is not fatal.
I'll really appreciate if it's removed or at least the stack dump is
suppressed. We know already that it's a
On 8/4/07, Michael Buesch [EMAIL PROTECTED] wrote:
So any suggestions on how to fix this?
The problem is that I'm not sure why we calibrate the LO by these strange
tables. Maybe we can fix this by dropping the tables and simply
calibrate it for every possible attenuation.
These tables have
On Sat, 2007-08-04 at 18:47 +0200, Michael Buesch wrote:
Yeah, I'd like to get rid of this message, too. But by fixing the
bug and not by hiding it.
So any suggestions on how to fix this?
I think you could try to write a detailed explanation of the problem, in
particular, what those tables
Ehud Gavron wrote:
The bcm43xx_mac80211 code associates fine and has good signal strength.
However, the stuff coming out of it on eth1 is not Ethernet...
The same setup worked in 2.6.22-wireless-dev.
A simple unload of the two modules, a reload of bcm43xx with v3 fw, and
it all works...
I have received a private reply from another user with *exactly* the
same symptoms. That user also uses x86_64.
I just got the tree from scratch, built it, booted without any tainting
modules (nvidia) and got _exactly_ the same results.
What am I doing wrong? I've build these before... and I
On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote:
The size of LO array message is not fatal.
I'll really appreciate if it's removed or at least the stack dump is
suppressed. We know already that it's a problem, so why scare users
more than they need to? We know where it happens, why show
Ehud Gavron wrote:
I have received a private reply from another user with *exactly* the
same symptoms. That user also uses x86_64.
I just got the tree from scratch, built it, booted without any tainting
modules (nvidia) and got _exactly_ the same results.
What am I doing wrong? I've
Pavel Roskin wrote:
On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote:
The size of LO array message is not fatal.
I'll really appreciate if it's removed or at least the stack dump is
suppressed. We know already that it's a problem, so why scare users
more than they need to? We know
47 matches
Mail list logo
