Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 the latest wireless-dev tree (2.6.23-rc2, git checkout -f) with
the change below IT WORKS!!!
Have I thanked everyone yet? Because it sure as heck feels like I want to.
Ehud
Michael Buesch wrote:
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 latest result in which I have been able to reproduce
the problem here.
I bisected the wireless-dev kernel to an arbitrary point before the change in status handling
(commit 85a83d26). That version could connect successfully using WEP and WPA encryption. I then
added the status-handling patch and tried again. This kernel could still do WPA encryption and it
could authenticate and associate with the WEP-using AP, but it could not get an IP number using DHCP.
I then did a diff between the dmesg output for the driver that works (dmesg.good) and the one that
does not (dmesg.bad). There are the usual number of differences due to slight timing difference,
etc, but the following difference stands out:
--- dmesg.good 2007-08-10 09:40:23.0 -0500
+++ dmesg.bad 2007-08-10 09:41:23.0 -0500
..snip..
@@ -569,7 +569,6 @@
bcm43xx_mac80211: 32-bit DMA initialized
bcm43xx_mac80211: Wireless interface started
NET: Registered protocol family 17
-bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
The good version is using hardware encryption, and the bad one is not. I have no idea why, but it
seems to be the critical difference. I'm ready to test any trial patch.
Larry
Ok, I see the bug in set_key.
if (bcm43xx_status(dev) != BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
We didn't have a chance to spot the bug in the patch that introduced
it, because it did not touch this function.
This should be changed to
if (bcm43xx_status(dev) BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 latest result in which I have been able to reproduce
the problem here.
I bisected the wireless-dev kernel to an arbitrary point before the change in
status handling
(commit 85a83d26). That version could connect successfully using WEP and WPA
encryption. I then
added the status-handling patch and tried again. This kernel could still do
WPA encryption and it
could authenticate and associate with the WEP-using AP, but it could not get
an IP number using DHCP.
I then did a diff between the dmesg output for the driver that works
(dmesg.good) and the one that
does not (dmesg.bad). There are the usual number of differences due to slight
timing difference,
etc, but the following difference stands out:
--- dmesg.good 2007-08-10 09:40:23.0 -0500
+++ dmesg.bad 2007-08-10 09:41:23.0 -0500
..snip..
@@ -569,7 +569,6 @@
bcm43xx_mac80211: 32-bit DMA initialized
bcm43xx_mac80211: Wireless interface started
NET: Registered protocol family 17
-bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2
status=0)
The good version is using hardware encryption, and the bad one is not. I have
no idea why, but it
seems to be the critical difference. I'm ready to test any trial patch.
Larry
Ok, I see the bug in set_key.
if (bcm43xx_status(dev) != BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
We didn't have a chance to spot the bug in the patch that introduced
it, because it did not touch this function.
This should be changed to
if (bcm43xx_status(dev) BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 here. I bisected the wireless-dev kernel to an arbitrary point before the change in status handling (commit 85a83d26). That version could connect successfully using WEP and WPA encryption. I then added the status-handling patch and tried again. This kernel could still do WPA encryption and it could authenticate and associate with the WEP-using AP, but it could not get an IP number using DHCP. I then did a diff between the dmesg output for the driver that works (dmesg.good) and the one that does not (dmesg.bad). There are the usual number of differences due to slight timing difference, etc, but the following difference stands out: --- dmesg.good 2007-08-10 09:40:23.0 -0500 +++ dmesg.bad 2007-08-10 09:41:23.0 -0500 ..snip.. @@ -569,7 +569,6 @@ bcm43xx_mac80211: 32-bit DMA initialized bcm43xx_mac80211: Wireless interface started NET: Registered protocol family 17 -bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff eth1: Initial auth_alg=0 eth1: authenticate with AP 00:1a:70:46:ba:b1 eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0) The good version is using hardware encryption, and the bad one is not. I have no idea why, but it seems to be the critical difference. I'm ready to test any trial patch. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 with dd-wrt. I will work on it later tonight and see what I can come up with. -Jory ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 public value.
The only things that don't make obvious sense (TO ME) are
1. all the changes to bcm43xx_interrupt_handler I don't
understand what it NEEDS to be or why it WAS one way and IS another
2. @@ -2314,7 +2310,6 @@ static void bcm43xx_periodic_tasks_setup
{
struct delayed_work *work = dev-periodic_work;
-assert(bcm43xx_status(dev) ==
BCM43xx_STAT_INITIALIZED); this is a
removal with no insertion to replace it
It's an assertion. That doesn't generate code.
3. -if (likely(bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED)) {
+if (likely(bcm43xx_status(dev) = BCM43xx_STAT_STARTED))
{ -- shouldn't this be
BCM43xx_STAT_STARTED ???
(That's in bcm43xx_get_tx_stats() right?)
No, we are checking for Are we at least started here?.
So we need =STARTED. ==STARTED would do it, too, but that's
the same with the current code. STARTED would clearly be wrong.
I have other questions, but the code is blurring in front of my eyes.
Yeah, well. I think it does for everybody. ;)
I'm pretty sure that it's a bug in the toolchain (gcc or binutils
or maybe something else) that's triggered by this patch.
So the toolchain generating bad code and corrupting the data.
The weird thing, however, is that you said you were able to associate,
but not able to send that packet (it was a ping, or something like that?).
From the driver point of view it doesn't matter if we TX/RX an
association packet or some other packet. The codepaths are _exactly_
the same.
That is all _very_ strange. I never had such a weird bug
in my whole life.
Michael, I know you are busy. Could you please re-look at your patch,
and note the cases where you change
bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED
I think in the other cases you change them to
bcm43xx_status(dev) BCM43xx_STAT_STARTED
which makes sense to me... so I can't understand #3 above.
The patch looks absolutely correct to me, except the tiny tiny
part in the core-starting, where I already sent a patch to
you (you said it wouldn't help).
Any input would be appreciated.
PS No, I don't know this code. No I've never written a Linux driver.
I'm a newbie. I just happen to have a laptop that doesn't like the new
code and likes the old code for bcm43xx-mac80211. I'm not the only
one.
Huh? Someone else able to reproduce it??
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 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 latest result in which I have been able to reproduce
the problem here.
I bisected the wireless-dev kernel to an arbitrary point before the change in status handling
(commit 85a83d26). That version could connect successfully using WEP and WPA encryption. I then
added the status-handling patch and tried again. This kernel could still do WPA encryption and it
could authenticate and associate with the WEP-using AP, but it could not get an IP number using DHCP.
I then did a diff between the dmesg output for the driver that works (dmesg.good) and the one that
does not (dmesg.bad). There are the usual number of differences due to slight timing difference,
etc, but the following difference stands out:
--- dmesg.good 2007-08-10 09:40:23.0 -0500
+++ dmesg.bad 2007-08-10 09:41:23.0 -0500
..snip..
@@ -569,7 +569,6 @@
bcm43xx_mac80211: 32-bit DMA initialized
bcm43xx_mac80211: Wireless interface started
NET: Registered protocol family 17
-bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
The good version is using hardware encryption, and the bad one is not. I have no idea why, but it
seems to be the critical difference. I'm ready to test any trial patch.
Larry
Ok, I see the bug in set_key.
if (bcm43xx_status(dev) != BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
We didn't have a chance to spot the bug in the patch that introduced
it, because it did not touch this function.
This should be changed to
if (bcm43xx_status(dev) BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
This part of set_multicast_list also was not touched by the patch
if (wl-promisc != !!(netflags IFF_PROMISC)) {
wl-promisc = !!(netflags IFF_PROMISC);
if (bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED)
bcm43xx_adjust_opmode(dev);
}
Is that correct? My thinking is that it should be = BCM43xx_STAT_INITIALIZED.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 free to if you think it of public value.
The only things that don't make obvious sense (TO ME) are
1. all the changes to bcm43xx_interrupt_handler I don't
understand what it NEEDS to be or why it WAS one way and IS another
2. @@ -2314,7 +2310,6 @@ static void bcm43xx_periodic_tasks_setup
{
struct delayed_work *work = dev-periodic_work;
-assert(bcm43xx_status(dev) ==
BCM43xx_STAT_INITIALIZED); this is a
removal with no insertion to replace it
It's an assertion. That doesn't generate code.
3. -if (likely(bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED)) {
+if (likely(bcm43xx_status(dev) = BCM43xx_STAT_STARTED))
{ -- shouldn't this be
BCM43xx_STAT_STARTED ???
(That's in bcm43xx_get_tx_stats() right?)
No, we are checking for Are we at least started here?.
So we need =STARTED. ==STARTED would do it, too, but that's
the same with the current code. STARTED would clearly be wrong.
I have other questions, but the code is blurring in front of my eyes.
Yeah, well. I think it does for everybody. ;)
I'm pretty sure that it's a bug in the toolchain (gcc or binutils
or maybe something else) that's triggered by this patch.
So the toolchain generating bad code and corrupting the data.
The weird thing, however, is that you said you were able to associate,
but not able to send that packet (it was a ping, or something like that?).
From the driver point of view it doesn't matter if we TX/RX an
association packet or some other packet. The codepaths are _exactly_
the same.
That is all _very_ strange. I never had such a weird bug
in my whole life.
Michael, I know you are busy. Could you please re-look at your patch,
and note the cases where you change
bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED
I think in the other cases you change them to
bcm43xx_status(dev) BCM43xx_STAT_STARTED
which makes sense to me... so I can't understand #3 above.
The patch looks absolutely correct to me, except the tiny tiny
part in the core-starting, where I already sent a patch to
you (you said it wouldn't help).
Any input would be appreciated.
PS No, I don't know this code. No I've never written a Linux driver.
I'm a newbie. I just happen to have a laptop that doesn't like the new
code and likes the old code for bcm43xx-mac80211. I'm not the only
one.
Huh? Someone else able to reproduce it??
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.
-Jory
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 used, and we need to find out where it comes from, or there is an algorithm to limit the index to only access valid entries. I hope the reverse engineering team knows that. I wish them good luck. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 the
problem is involved with commit 85a83d26 bcm43xx-mac80211: Rewrite and
simplify handling of the
initialization status.. Neither Michael nor I can reproduce the problem, nor
is anything obviously
wrong with the patch, other than this patch exposes an error in the location of
the initial
interrupt. I found this error on my old/slow notebook. Fixing that error did
not resolve Ehud's
problem. That fix is now in Linville's tree.
Ehud - please make your test tree current with a 'git checkout -f' command, and
do a 'git pull' to
make certain you have the latest code. Then apply the trial patch below, which
reverts a small part
of Michael's patch, and see if it fixes the problem.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
/* Interrupt handler top-half */
static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
- irqreturn_t ret = IRQ_NONE;
+ irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_wldev *dev = dev_id;
u32 reason;
@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han
spin_lock(dev-wl-irq_lock);
- if (bcm43xx_status(dev) BCM43xx_STAT_STARTED)
- goto out;
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
- if (reason == 0x) /* shared IRQ */
+ if (reason == 0x) { /* shared IRQ */
+ ret = IRQ_NONE;
goto out;
- ret = IRQ_HANDLED;
+ }
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
if (!reason)
goto out;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
Is that a clue to bigger things, or a problem with this patch?
dmesg and tcpdump (of garbage) included along with a log of what I did
with the git test tree to get there.
Ehud
Larry Finger wrote:
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 the
problem is involved with commit 85a83d26 bcm43xx-mac80211: Rewrite
and simplify handling of the initialization status.. Neither Michael
nor I can reproduce the problem, nor is anything obviously wrong with
the patch, other than this patch exposes an error in the location of
the initial interrupt. I found this error on my old/slow notebook.
Fixing that error did not resolve Ehud's problem. That fix is now in
Linville's tree.
Ehud - please make your test tree current with a 'git checkout -f'
command, and do a 'git pull' to
make certain you have the latest code. Then apply the trial patch
below, which reverts a small part of Michael's patch, and see if it
fixes the problem.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
---
wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
/* Interrupt handler top-half */
static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
-irqreturn_t ret = IRQ_NONE;
+irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_wldev *dev = dev_id;
u32 reason;
@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han
spin_lock(dev-wl-irq_lock);
-if (bcm43xx_status(dev) BCM43xx_STAT_STARTED)
-goto out;
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
-if (reason == 0x) /* shared IRQ */
+if (reason == 0x) { /* shared IRQ */
+ret = IRQ_NONE;
goto out;
-ret = IRQ_HANDLED;
+}
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
if (!reason)
goto out;
bcm43xx-phy0: Broadcom 4311 WLAN found
bcm43xx-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy0 debug: Radio turned off
bcm43xx driver
bcm43xx-phy1: Broadcom 4311 WLAN found
bcm43xx-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy1 debug: Radio turned off
bcm43xx-phy1 debug: Adding Interface type 2
bcm43xx-phy1 debug: Loading firmware version 371.1061 (2006-10-04 21:02:04)
bcm43xx-phy1 debug: Radio turned on
bcm43xx-phy1 debug: Radio enabled by hardware
bcm43xx-phy1 debug: bbatt(11) = size of LO array
[8817daaf] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x65/0xa8
[8817db28] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x36/0x3b
[8817dc0c] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x9/0x15
[8817824b] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x338/0x6a6
[88172ae4] :bcm43xx_mac80211:bcm43xx_phy_read+0x5c/0x63
[8817b52e] :bcm43xx_mac80211:bcm43xx_phy_initg+0xc85/0xd0a
[8817bd61] :bcm43xx_mac80211:bcm43xx_phy_init+0x582/0x5a7
[8816fcce] :bcm43xx_mac80211:bcm43xx_chip_init+0x68c/0x9a3
[8817026d] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x288/0x73e
[881712bb] :bcm43xx_mac80211:bcm43xx_add_interface+0x5f/0xf4
bcm43xx-phy1 debug: Chip initialized
bcm43xx-phy1 debug: 32-bit DMA initialized
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1525:bcm43xx_interrupt_handler()
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
bcm43xx-phy1 debug: Wireless interface started
08:47:25.934468 00:a0:c8:0e:c0:e5 00:1a:92:0e:40:1f, 802.3, length 78: LLC,
dsap Unknown (0xd0) Group, ssap Unknown (0x1e) Command, ctrl 0x007c:
Information, send seq 62, rcv seq 0, Flags [Command], length 64
0x: 001a 920e 401f 00a0 c80e c0e5 0040 d11e
0x0010: 7c00 d33d 7497 de0e 21e6 f6fe 8382 bf04
0x0020: e081 7838 36f2 114a 3ee3 9c19 e3fc 402c
0x0030: 8746 083d 4fb9 0b86 4965 f272 86e1 963b
0x0040: 2efe a2c5 c3ac f6ca 4363 eb91 a233
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The patch failed, but it shouldn't have. Have you done a 'git bisect reset' since we finished the bisecting? That would be a problem. Just in case, do the following: git bisect reset git checkout -f git pull Then apply the patch. If you get any REJECTS, please let me know. I'll hold off on analyzing those assertions until the code is in a known state. Yeah, your tree is still unclean. After cleaning it you can verify if it's clean by inspecting the output of git status and git diff status should _not_ talk about modified files or something like that. diff should output nothing. A clean tree looks like this: [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status nothing to commit [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff [EMAIL PROTECTED]:~/develop/git/wireless-dev$ -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
[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 PROTECTED] test]# Michael Buesch wrote: 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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The patch failed, but it shouldn't have. Have you done a 'git bisect reset' since we finished the bisecting? That would be a problem. Just in case, do the following: git bisect reset git checkout -f git pull Then apply the patch. If you get any REJECTS, please let me know. I'll hold off on analyzing those assertions until the code is in a known state. Yeah, your tree is still unclean. After cleaning it you can verify if it's clean by inspecting the output of git status and git diff status should _not_ talk about modified files or something like that. diff should output nothing. A clean tree looks like this: [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status nothing to commit [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff [EMAIL PROTECTED]:~/develop/git/wireless-dev$ smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 add to track) [EMAIL PROTECTED] test]# git diff [EMAIL PROTECTED] test]# Larry, your patch is broken [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch 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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 files present (use git add to track) [EMAIL PROTECTED] test]# git diff [EMAIL PROTECTED] test]# Larry, your patch is broken [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch 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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The white space must have been garbled. When it didn't apply, Ehud contacted me privately and I sent him the patch file as an attachment. It has applied cleanly and is now compiling. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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: # (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 PROTECTED] test]# Larry, your patch is broken [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch 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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The white space must have been garbled. When it didn't apply, Ehud contacted me privately and I sent him the patch file as an attachment. It has applied cleanly and is now compiling. Larry smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 debugging stuff. When done, reproduce. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej I can do this all day long. It's much more fun than dissecting the original commit and doing it step by step. Ehud Larry Finger wrote: 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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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. Larry Subject: bcm43xx-mac80211: Reorder starting of wireless core. 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 === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 19:32:05.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 20:10:36.0 +0200 @@ -3086,13 +3086,18 @@ static int bcm43xx_wireless_core_start(s dev-dev-irq); goto out; } + + /* We are ready to run. */ + bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); + + /* Start data flow (TX/RX). */ bcm43xx_mac_enable(dev); + bcm43xx_interrupt_enable(dev, dev-irq_savedstate); + ieee80211_start_queues(dev-wl-hw); + /* Start maintainance work */ bcm43xx_periodic_tasks_setup(dev); - ieee80211_start_queues(dev-wl-hw); - bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); - bcm43xx_interrupt_enable(dev, dev-irq_savedstate); bcmdbg(dev-wl, Wireless interface started\n); out: return err; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] John just pushed 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 -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c No, you got the wrong patch. That one was previously applied, which is what the error message is saying. In any case, apply the one I just sent. BTW, it isn't necessart to repull the tree to get a clean version. That is what 'git checkout -f' does. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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, and it is now building. Should have results in 35m. Thanks Ehud Larry Finger wrote: 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 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c No, you got the wrong patch. That one was previously applied, which is what the error message is saying. In any case, apply the one I just sent. BTW, it isn't necessart to repull the tree to get a clean version. That is what 'git checkout -f' does. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 -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 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] John just pushed 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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 compiler bug generating corrupt code. Which compiler do you use? Can you upgrade or downgrade? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 compiler bug generating corrupt code. Which compiler do you use? Can you upgrade or downgrade? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 from the extra entries is used, and we need to find out where it comes from, or there is an algorithm to limit the index to only access valid entries. I hope the reverse engineering team knows that. I wish them good luck. Oh, we're aware of the problem. It's like I said before, it's one of the most complex parts of the driver and it's tough to document properly without just copying code to the documentation. We'll get to it, but my time is kind of limited right now. Sorry, -Joe ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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: ff:ff:ff:ff:ff:ff eth1: Initial auth_alg=0 eth1: authenticate with AP 00:0d:88:ac:b2:2a eth1: RX authentication from 00:0d:88:ac:b2:2a (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:0d:88:ac:b2:2a eth1: RX AssocResp from 00:0d:88:ac:b2:2a (capab=0x431 status=0 aid=1) eth1: associated eth1: switched to short barker preamble (BSSID=00:0d:88:ac:b2:2a) ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready In particular, I mean the hardware based encryption, and the short barker preamble messages. Please boot a good kernel and save the dmesg output. Do the same for a bad kernel. Send the two sets of dmesg output, and iwconfig and ifconfig output for the bad one. In the meantime, I'll configure my spare AP for WEP encryption and see what I get in my logs. Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 personally revert that long patch. With xconfig, select the Kernel hacking section, and turn off the Show timing info on printks. In addition, turn off Kobject debugging in that section. The latter option generates a lot of messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make modules_install install'. You do not need to clean out the object files, or any other make options. Boot that kernel and send me it's dmesg. One further question - Are you trying to connect to the same AP in both cases? The reason I'm asking is that the MAC address of the AP is different for the two cases. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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. All work fine with bcm43xx ndiswrapper with bcmwl5. See attached. Ehud Larry Finger wrote: 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 personally revert that long patch. With xconfig, select the Kernel hacking section, and turn off the Show timing info on printks. In addition, turn off Kobject debugging in that section. The latter option generates a lot of messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make modules_install install'. You do not need to clean out the object files, or any other make options. Boot that kernel and send me it's dmesg. One further question - Are you trying to connect to the same AP in both cases? The reason I'm asking is that the MAC address of the AP is different for the two cases. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev Linux version 2.6.23-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #2 SMP Wed Aug 8 20:36:34 MST 2007 Command line: ro root=LABEL=/ rhgb quiet BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 7fe81400 (usable) BIOS-e820: 7fe81400 - 7ff0 (reserved) BIOS-e820: f000 - f4007000 (reserved) BIOS-e820: f4008000 - f400c000 (reserved) BIOS-e820: fed2 - feda (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 523905) 1 entries of 3200 used end_pfn_map = 1043872 DMI 2.4 present. ACPI: RSDP 000FC0B0, 0014 (r0 DELL ) ACPI: RSDT 7FE8198A, 0044 (r1 DELLM07 27D60A0D ASL61) ACPI: FACP 7FE82800, 0074 (r1 DELLM07 27D60A0D ASL61) ACPI: DSDT 7FE83400, 4D7D (r1 INT430 SYSFexxx 1001 INTL 20050624) ACPI: FACS 7FE91C00, 0040 ACPI: HPET 7FE82F00, 0038 (r1 DELLM071 ASL61) ACPI: APIC 7FE83000, 0068 (r1 DELLM07 27D60A0D ASL47) ACPI: ASF! 7FE82C00, 005B (r16 DELLM07 27D60A0D ASL61) ACPI: MCFG 7FE82FC0, 003E (r16 DELLM07 27D60A0D ASL61) ACPI: SLIC 7FE8309C, 0176 (r1 DELLM07 27D60A0D ASL61) ACPI: TCPA 7FE83300, 0032 (r1 DELLM07 27D60A0D ASL61) ACPI: SSDT 7FE81A11, 04DC (r1 PmRefCpuPm 3000 INTL 20050624) No NUMA configuration found Faking a node at -7fe81000 Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 523905) 1 entries of 3200 used Bootmem setup node 0 -7fe81000 No mptable found. Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 523905 On node 0 totalpages: 523808 DMA zone: 96 pages used for memmap DMA zone: 2524 pages reserved DMA zone: 1379 pages, LIFO batch:0 DMA32 zone: 12183 pages used for memmap DMA32 zone: 507626 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:7010) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 435320 bytes of per cpu data Built 1 zonelists in Node order. Total pages: 509005 Policy zone: DMA32 Kernel command line: ro root=LABEL=/ rhgb quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Marking TSC unstable due to TSCs unsynchronized time.c: Detected
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. Somehow, it doesn't sound right. Nobody knows the code better than you. I think communication is essential for development. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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. That's probably a chicken and egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. So? Somehow, it doesn't sound right. Nobody knows the code better than you. I think communication is essential for development. I know that this is broken (So we don't hide the bug by removing the message), but I don't know how to fix it. Is that such an unusual condition? I simply don't understand how the hardware works. Sure, we can simply hide the bug by changing the code so that it doesn't complain anymore. That's not the issue here. The problem is, that I don't know how to fix this _correctly_. So, that said, I'm not sure which lack of communication you are talking about. I do _not_ know how that stuff works. So, if you want to try understanding it, read the code and specs and try to make sense out of it. I am working on this stuff. I have limited time and I'm not Merlin the magician. So I have to try understanding this stuff. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 love to spend the time figuring it out, I just can't spend that time right now. Well, this reminds me The Mad Hatter's Tea Party with me being Alice :) Anyway, good luck with the driver work! -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. Somehow, it doesn't sound right. Nobody knows the code better than you. I think communication is essential for development. Pavel, 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 love to spend the time figuring it out, I just can't spend that time right now. -Joe ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
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. 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 the stack? I don't think we want to make users ignore stack traces in the kernel logs, because we may not hear about unknown problems. IMHO there are better places for TODO notes than innocent users' kernel logs. I agree completely; however, I've had my hands slapped in the past for removing that kind of message. As a result, I leave them alone. Well, there are good reasons for not removing this. The resons include that this message is only shown for the debug build. So if you want it to shut up, don't compile a debug build. Is there a real need for the call to dump_stack on err? Isn't the printk (bcmdbg) good enough? 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. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
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, but in this case we know that the line
bbatt.att = 11 in
bcm43xx_phy_init_pctl leads to this error message. Why don't we change it to
'bbatt.att = 8' to
eliminate this particular error message? That way the debugging info can stay
in without polluting
everyone's log.
Larry
The patch is:
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
@@ -725,7 +725,7 @@ static void bcm43xx_phy_init_pctl(struct
memcpy(old_bbatt, phy-bbatt, sizeof(old_bbatt));
old_tx_control = phy-tx_control;
- bbatt.att = 11;
+ bbatt.att = 8;
if (phy-radio_rev == 8) {
rfatt.att = 15;
rfatt.with_padmix = 1;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
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 debugging. Michael, I agree with you in general, but in this case we know that the line bbatt.att = 11 in bcm43xx_phy_init_pctl leads to this error message. Why don't we change it to 'bbatt.att = 8' to eliminate this particular error message? That way the debugging info can stay in without polluting everyone's log. Because that would simply be plain wrong. The specs says we have to write 11. So we write 11 and not something else to workaround bugs in other parts of the code. I don't feel comfortable with introducing bugs to hide other bugs. Someone must reverse engineer all that stuff again. But currently we have nobody with enough time to do this. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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. That's probably a chicken and egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. I will attempt an explanation of the issue, since I've been trying to wrap my own head around it lately. It boils down to a contradiction in the specs. For a G phy, the power control is set by 2 attenuation values. The chip wants the values themselves, and also the results of looking up these values in the LO table (which we build at device init and periodically refresh). The specs tell us how to build the LO table by looping over a list of values and measuring hardware parameters for each (http://bcm-v4.sipsolutions.net/802.11/LO/GPHY/BuildingTheTable). The list of values is supplied (http://bcm-v4.sipsolutions.net/802.11/LO/Tables). We make the LO lookup table large enough to hold all these values, but no larger than that (since anything else should not be initialized according to specs). Then the specs tell us to initialize the power control by setting the TX power variables to a known state and measuring power output (http://bcm-v4.sipsolutions.net/802.11/PHY/G/Power_Control). Here is the problem: One of the TX power values the spec tells us to use for this is larger than the max value used when building the LO lookup table. To set the TX power, we need to index into the LO table with these values. The spec is telling us to lookup an invalid index in the LO table. Currently, the driver deals with this by catching invalid LO table indexes and returning the value at the zero index. But this cannot possibly be the right thing to do; it merely avoids an oops in the driver. When high-level code tells low-level code to do something stupid, printing a warning seems appropriate (even if a stack trace is not needed any more). -- Will Dyson ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 problem, so why scare users more than they need to? We know where it happens, why show the stack? I don't think we want to make users ignore stack traces in the kernel logs, because we may not hear about unknown problems. IMHO there are better places for TODO notes than innocent users' kernel logs. I agree completely; however, I've had my hands slapped in the past for removing that kind of message. As a result, I leave them alone. Well, there are good reasons for not removing this. The resons include that this message is only shown for the debug build. So if you want it to shut up, don't compile a debug build. It's the task of a debug build to show problems. If you don't care about problems, disable it. This message is not fatal in the sense that is prevents the device from working, but it is very well fatal in the sense that the LO is not adjusted properly. Which means you are probably radiating frequencies that you are not licensed to. 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? 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 some relation to the hardware power control. So maybe we don't need to adjust the LO from the txpower routines at all, when using hwpctl? (Only on demand of the power vector). ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 some relation to the hardware power control.
So maybe we don't need to adjust the LO from the txpower routines
at all, when using hwpctl? (Only on demand of the power vector).
I certainly can't claim to understand how the LO calibration is
supposed to work. I'm especially having a hard time understanding how
these LO tables (lo-with_padmix and lo-no_padmix) get built.
With that in mind, why can't we just make the table large enough for
an RFATT of 11?
It seems to work for me on a 4306
Gmail-mangled patch follows (just to show what I'm talking about)
diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
b/drivers/net/wireless/bcm43xx-mac80211/b
index 377bda4..1d89fdd 100644
--- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
+++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
@@ -26,7 +26,7 @@ struct bcm43xx_loctl {
* Use bcm43xx_get_lo_g_ctl() to retrieve a value from the lists.
*/
struct bcm43xx_txpower_lo_control {
-#define BCM43xx_NR_BB 9
+#define BCM43xx_NR_BB 12
#define BCM43xx_NR_RF 16
/* LO Control values, with PAD Mixer */
struct bcm43xx_loctl with_padmix[ BCM43xx_NR_BB ][ BCM43xx_NR_RF ];
diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
b/drivers/net/wireless/bcm43xx-mac80211/
index 4db7c5c..8f35d33 100644
--- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
+++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
@@ -181,12 +181,15 @@ static void generate_bbatt_list(struct bcm43xx_wldev *dev,
{ .att = 6, },
{ .att = 7, },
{ .att = 8, },
+ { .att = 9, },
+ { .att = 10, },
+ { .att = 11, },
};
list-list = bbatt_0;
list-len = ARRAY_SIZE(bbatt_0);
list-min_val = 0;
- list-max_val = 8;
+ list-max_val = 11;
}
static void bcm43xx_shm_clear_tssi(struct bcm43xx_wldev *dev)
--
Will Dyson
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 do, where the numbers come from, what hardware is affected, what the driver does now, what it should do, and how to find out the right solution from reverse engineering data. After all, there are working drivers for the chipset, and they can be reverse engineered. It cannot be a problem with no solution. Chances are that you will have some ideas before you finish writing the message. It happened to me many times. But even if it doesn't happen, you will make it easy for others to suggest solutions. And you will give the reverse engineering team some ideas what to look for. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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... You'll note I attached entire dmesg and not just dmesg|grep bcm so that you could also see: bcm43xx-phy0 debug: bbatt(11) = size of LO array The size of LO array message is not fatal. I pulled the latest system from wireless-dev and built it. On my 4311, it connects just fine. The maximum transmit and receive rates are 2.2 and 3.2 Mbs, respectively. I don't know what happened to your system. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 think I have the procedure right. Thanks, Ehud 1060 cd /usr/src 1061 ls 1062 rm -rf wireless-dev/ 1063 ./git.sh 1064 sed -e s/\(EXTRAVERSION.*\)/\1-wireless-dev-EG2/g -i wireless-dev/Makefile 1065 cd wireless-dev/ 1066 make mrproper 1067 cp ../2.6.22-EG1/.config . 1068 make oldconfig /dev/null /dev/null 1069 grep -i bcm43xx .config 1073 make finished WAY TOO SOON with error in asus_laptop.c 1075 sed -e s/CONFIG_ASUS_LAPTOP=\(.*\)/CONFIG_ASUS_LAPTOP=n/g -i .config 1076 make 1077 time nice make modules_install 1078 time nice make install 1079 history 1080 history ~root/build_history.txt (and here you have it) Larry Finger wrote: 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... You'll note I attached entire dmesg and not just dmesg|grep bcm so that you could also see: bcm43xx-phy0 debug: bbatt(11) = size of LO array The size of LO array message is not fatal. I pulled the latest system from wireless-dev and built it. On my 4311, it connects just fine. The maximum transmit and receive rates are 2.2 and 3.2 Mbs, respectively. I don't know what happened to your system. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 the stack? I don't think we want to make users ignore stack traces in the kernel logs, because we may not hear about unknown problems. IMHO there are better places for TODO notes than innocent users' kernel logs. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 build these before... and I think I have the procedure right. Thanks, Ehud 1060 cd /usr/src 1061 ls 1062 rm -rf wireless-dev/ 1063 ./git.sh 1064 sed -e s/\(EXTRAVERSION.*\)/\1-wireless-dev-EG2/g -i wireless-dev/Makefile 1065 cd wireless-dev/ 1066 make mrproper 1067 cp ../2.6.22-EG1/.config . 1068 make oldconfig /dev/null /dev/null 1069 grep -i bcm43xx .config 1073 make finished WAY TOO SOON with error in asus_laptop.c 1075 sed -e s/CONFIG_ASUS_LAPTOP=\(.*\)/CONFIG_ASUS_LAPTOP=n/g -i .config 1076 make 1077 time nice make modules_install 1078 time nice make install 1079 history 1080 history ~root/build_history.txt (and here you have it) The commands look fine and I think you said the 2.6.22-EG1 config was OK. When I looked at your dmesg, I noticed the following messages: eth1: switched to short barker preamble (BSSID=00:0d:0b:11:5c:1b) ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready eth1: no IPv6 routers present device eth1 entered promiscuous mode What is that all about? On my system IPv6 is disabled. Will that make any difference for you? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
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 where it happens, why show the stack? I don't think we want to make users ignore stack traces in the kernel logs, because we may not hear about unknown problems. IMHO there are better places for TODO notes than innocent users' kernel logs. I agree completely; however, I've had my hands slapped in the past for removing that kind of message. As a result, I leave them alone. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
