Larry Finger wrote:
Pavel Roskin wrote:
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
With this patch installed, and the DEBUG configuration set as above, I get a
kernel panic on an
x86_64 SMP
Sorry work has been calling (very late nights from server migration),
I will try to get the script going soon, as i need to upgrade to the
new tree anyway.
On 8/7/07, John H. [EMAIL PROTECTED] wrote:
Did I misunderstand something? I thought some script was available or
some easy way to use
On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote:
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
Thanks, queued.
Larry, this might also apply to bcm4301.
On Sat, 2007-08-04 at 00:56 -0700, Brennan Ashton wrote:
the trace overflows dmesg buffer, but here is what is left in the log:
[...]
Not very understandable unfortunately. Somewhere there must be a missing
dev_put but I can't pinpoint it.
johannes
signature.asc
Description: This is a
On Wednesday 08 August 2007 07:52:21 Larry Finger wrote:
Pavel Roskin wrote:
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
With this patch installed, and the DEBUG configuration set as
On Wednesday 08 August 2007 08:02:29 Larry Finger wrote:
Larry Finger wrote:
Pavel Roskin wrote:
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
With this patch installed, and the DEBUG
On Wednesday 08 August 2007 05:27:13 Jhonie Walker wrote:
Hello, I tried to use the tool with the drivers
working ok, but this is what I get in the console:
./sprommod.sh eth0
./sprommod.sh: line 31: bcm43xx-sprom: command not
found
Could not modify SPROM data (127)
I noticed that the
On Saturday 04 August 2007 07:12:46 Brennan Ashton wrote:
When the bcm43xx_mac80211 driver stops communicating, and needs to be
reset (this seems to happens when coming from strong to week to strong
signal area quickly) i have been rmmod and then modprobing it. this
Can you test if you still
Michael Buesch wrote:
On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote:
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
Thanks, queued.
Larry, this might also apply to bcm4301.
Yes it will.
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.
-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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,
On Monday 06 August 2007 03:21:11 you wrote:
Richard Jonsson wrote:
Isn't Desired TX power supposed to adapt so that higher bitrates are
possible, with Bit Rate going lower if that is not enough to keep a good
connection?
Richard,
Please grab a new copy of the port_to_mac80211 patch,
Hi John,
This patch series catches wireless-dev up to my
current wireless-development patchset.
Please merge this into wireless-dev.
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
From: Pavel Roskin [EMAIL PROTECTED]
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Debugging message added by Michael Buesch.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index:
Reorder the starting of the wireless core.
First set the we are ready to go status and then poke operation.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
Remove our own assert() definition and use the standard kernel WARN_ON().
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
---
Cleanup.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:17:10.0
To: Andrew Morton [EMAIL PROTECTED]
This makes the verbose printk on every coreswitch dependent
on a default-off debugging variable.
Verbose coreswitch messages are only needed when debugging
strange crashes or machine check exceptions.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index:
People won't read it, but hey. Let's do our best :)
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
---
Fix uninitialized-var warnings in lo.c
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
===
---
power.c is not needed anymore. Move the only function
included in power.c into main.c.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/Makefile
===
---
Richard Jonsson wrote:
On Monday 06 August 2007 03:21:11 you wrote:
Richard Jonsson wrote:
Isn't Desired TX power supposed to adapt so that higher bitrates are
possible, with Bit Rate going lower if that is not enough to keep a good
connection?
Richard,
Please grab a new copy of the
the IRQ patch upstream.
Please try my patch that I just sent.
This one:
http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch
smime.p7s
Description: S/MIME Cryptographic Signature
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
I am using larry's .bz2 of bcm43xx and I get this ...
wlan0 IEEE 802.11b/g ESSID:Network4Home Nickname:Broadcom 4311
Mode:Managed Frequency=2.437 GHz Access Point:blah
Bit Rate=24 Mb/s Tx-Power=18 dBm
RTS thr:off Fragment thr:off
Link
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
John H. wrote:
I am using larry's .bz2 of bcm43xx and I get this ...
wlan0 IEEE 802.11b/g ESSID:Network4Home Nickname:Broadcom 4311
Mode:Managed Frequency=2.437 GHz Access Point:blah
Bit Rate=24 Mb/s Tx-Power=18 dBm
RTS thr:off Fragment thr:off
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.
45 matches
Mail list logo
