Re: Anyone got a 4306 working properly?
On Mon, 2006-06-12 at 14:19 -0500, Larry Finger wrote: Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. FWIW, now that I found the problem associating with a Linksys WRT54G V5, I have been able to run my Linksys WPC54G again using WPA-PSK. At startup, the following details are reported: bcm43xx: Chip ID 0x4306, rev 0x2 bcm43xx: Number of cores: 6 bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled bcm43xx: Ignoring additional 802.11 core. bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) With the June 5 versions of the bcm43xx: redesign locking and bcm43xx: preemptible periodic work patches applied to the 2.6.17-rc6 kernel, I am running with no problems. I ran 50,000 pings to my AP with no losses and no duplicates. The only thing being logged is an occasional TKIP: replay detected message, but they don't seem to do any harm. That's interesting. I applied the latest patches here (redesign locking, preemptible periodic work, the 2 softmac patches by joe and MAC suspending) and still have DUPs and losses. This is even though my revision numbers are exactly the same as yours. I even had one lockup that forced me to reboot. However, I don't have any log information (I was in X when the machine locked up). Anyway, my new airport extreme card has arrived, I'm gonna try it the next days. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. FWIW, now that I found the problem associating with a Linksys WRT54G V5, I have been able to run my Linksys WPC54G again using WPA-PSK. At startup, the following details are reported: bcm43xx: Chip ID 0x4306, rev 0x2 bcm43xx: Number of cores: 6 bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled bcm43xx: Ignoring additional 802.11 core. bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) With the June 5 versions of the bcm43xx: redesign locking and bcm43xx: preemptible periodic work patches applied to the 2.6.17-rc6 kernel, I am running with no problems. I ran 50,000 pings to my AP with no losses and no duplicates. The only thing being logged is an occasional TKIP: replay detected message, but they don't seem to do any harm. Thanks for your efforts. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 18:06 -0400, Tim Shepard wrote: In the middle of last month (May 2006) while running Debian sarge and linux-2.6.17-rc3 (or maybe -rc4) I was traveling and staying in a home that had an access point, and I discovered that it would barely work (if at all) from my bedroom there (about 10 or 15 meters away on the same floor), but would work just fine if I sat on the couch next to the access point. When anywhere other than within 2 or 3 meters of the access pont, the symptoms were much like what Mattias is describing. Within 2 or 3 meters from the access point, it would work very well. Well, tried that. I sat directly near the access point (1.5 meters between the antennas). But that didn't change anything for me, same problem as before. The 15-inch PowerBook has two antennas, one on either side of the screen. I noticed that covering the left one with my hand would completely prevent it from working, while covering the right antenna with my hand never had any effect. Tried that but I'm not sure whether it had effect or not. At least no strong correlation. Also note that the airport card in the powerbook has only one antenna connector. This makes me doubt that you can actually influence which antenna is used from within the driver. Maybe you just blocked the antenna that was better positioned and the other one was only getting an unusable signal. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Monday 05 June 2006 12:20, Mattias Nissler wrote: On Sun, 2006-06-04 at 18:06 -0400, Tim Shepard wrote: In the middle of last month (May 2006) while running Debian sarge and linux-2.6.17-rc3 (or maybe -rc4) I was traveling and staying in a home that had an access point, and I discovered that it would barely work (if at all) from my bedroom there (about 10 or 15 meters away on the same floor), but would work just fine if I sat on the couch next to the access point. When anywhere other than within 2 or 3 meters of the access pont, the symptoms were much like what Mattias is describing. Within 2 or 3 meters from the access point, it would work very well. Well, tried that. I sat directly near the access point (1.5 meters between the antennas). But that didn't change anything for me, same problem as before. The 15-inch PowerBook has two antennas, one on either side of the screen. I noticed that covering the left one with my hand would completely prevent it from working, while covering the right antenna with my hand never had any effect. Tried that but I'm not sure whether it had effect or not. At least no strong correlation. Also note that the airport card in the powerbook has only one antenna connector. This makes me doubt that you can actually influence which antenna is used from within the driver. Maybe you just blocked the antenna that was better positioned and the other one was only getting an unusable signal. Some people also confuse how two antennas are actually used. They are never used in parallel. You can always use only one antenna to send/receive. The bcm43xx driver defaults to selecting the best antenna for TX. That is the antenna, that received the last PLCP at best signal strength. This selection is done at firmware level in the bcm43xx. You can also force the usage of a specific antenna, but that does not really make sense. I never opened the powerbook, so I can't say how the antennas are connected. But if there is really only one antenna connected, it will always select this one, as that is the only one able to receive a good PLCP. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 10:55, Richard Harman wrote: Ok, how about this :) I'll compile up the latest kernel +bcm/softmac and pull out my debugging stuff to see what revision my 4306 card is. If it's one you want, I'll buy myself a replacement one, and ship you mine. What exactly do I need to look for when I insmod with debugging turned on? Well, that depends on what you want to get working. ;) The problem which is discussed in this thread seems to be related to a wireless core revision 5. Note that I am not 100% sure here, but there is definately much untested code in the driver for wlcore 5 cards. You can find out which revisions are on your card by looking at insmod dmesg: Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled ^ ^^^ 0x812 is a wireless core and 0x4 is the revision here. As you can see it is 5. Jun 3 00:56:29 thirtytwo bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Ignoring additional 802.11 core. Jun 3 00:56:29 thirtytwo bcm43xx: PHY connected Jun 3 00:56:29 thirtytwo bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 3 00:56:29 thirtytwo bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off There might be other revisions accounting here, too. For example, we often check radio and PHY revisions. And as you can see PHY and radio revisions are also very low numbers here. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 12:14 +0200, Michael Buesch wrote: On Sunday 04 June 2006 10:55, Richard Harman wrote: Ok, how about this :) I'll compile up the latest kernel +bcm/softmac and pull out my debugging stuff to see what revision my 4306 card is. If it's one you want, I'll buy myself a replacement one, and ship you mine. What exactly do I need to look for when I insmod with debugging turned on? Well, that depends on what you want to get working. ;) The problem which is discussed in this thread seems to be related to a wireless core revision 5. Note that I am not 100% sure here, but there is definately much untested code in the driver for wlcore 5 cards. You can find out which revisions are on your card by looking at insmod dmesg: Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled ^ ^^^ 0x812 is a wireless core and 0x4 is the revision here. As you can see it is 5. Jun 3 00:56:29 thirtytwo bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Ignoring additional 802.11 core. Jun 3 00:56:29 thirtytwo bcm43xx: PHY connected Jun 3 00:56:29 thirtytwo bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 3 00:56:29 thirtytwo bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off There might be other revisions accounting here, too. For example, we often check radio and PHY revisions. And as you can see PHY and radio revisions are also very low numbers here. Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. I don't find any other bcm card at ebay, yet. But your local computer distributor should also sell those cards. A good list of bcm cards is here: http://bcm43xx.berlios.de/?go=Devices -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. I have a spare Linksys WPC54G with the following revision numbers. Jun 4 14:56:13 larrylap kernel: bcm43xx: Chip ID 0x4306, rev 0x2 Jun 4 14:56:13 larrylap kernel: bcm43xx: Number of cores: 6 Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Ignoring additional 802.11 core. Jun 4 14:56:13 larrylap kernel: bcm43xx: PHY connected Jun 4 14:56:13 larrylap kernel: bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 4 14:56:13 larrylap kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 4 14:56:13 larrylap kernel: bcm43xx: Radio turned off Jun 4 14:56:13 larrylap kernel: bcm43xx: Radio turned off I am willing to donate this device to the project. It has had an accident and the LEDs don't work, but the rest is OK. Please send me the mailing address of the location where you want it. I am located in Kansas City, MO USA. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: A good list of bcm cards is here: http://bcm43xx.berlios.de/?go=Devices Actually my card (as listed by lspci): 0001:10:12.0 0280: 14e4:4320 (rev 02) Subsystem: 106b:004e is listed on that page, but is obviously not working properly. So you might want to mark it as possibly non-working. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 21:52 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. I'll order one of the newer airport extreme cards (as these are probably the only ones to fit into the powerbook) and see how it works out. That will probably also be a 0x4318. What issues do these have? Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 23:01, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:52 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. I'll order one of the newer airport extreme cards (as these are probably the only ones to fit into the powerbook) and see how it works out. That will probably also be a 0x4318. What issues do these have? Ah, you have a powerbook. Well, that makes choice narrow. ;) The newest Airports are 4318, afaik. (Or are they atheros now?) 4318 has some issues, but often works. We know where the issues are and are working to fix them. It's a matter of time. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
Michael, I have a 4306 in a 15-inch PowerBook G4 (purchased new, in the US, in the last week of June 2005). I'm running vanilla linux-2.6.17-rc5 obtained from kernel.org which I built myself. The system is Debian etch now, though more than a week ago I was running Debian sarge, and earlier kernel versions in the linux-2.6.17-rc? series. I've not tried to use the wireless much in the last few weeks, for I do not yet have an access point at home. In the middle of last month (May 2006) while running Debian sarge and linux-2.6.17-rc3 (or maybe -rc4) I was traveling and staying in a home that had an access point, and I discovered that it would barely work (if at all) from my bedroom there (about 10 or 15 meters away on the same floor), but would work just fine if I sat on the couch next to the access point. When anywhere other than within 2 or 3 meters of the access pont, the symptoms were much like what Mattias is describing. Within 2 or 3 meters from the access point, it would work very well. In my bedroom (10 or 15 meters away), if I carefully positioned it on the table moving it a centimeter or three in various directions until I found a spot that worked better, then I could use it from the bedroom, but I would still see some outages and when I tried pinging the default router I would see DUPs like Mattias reports. The 15-inch PowerBook has two antennas, one on either side of the screen. I noticed that covering the left one with my hand would completely prevent it from working, while covering the right antenna with my hand never had any effect. iwlist eth1 scan always reported that it had seen the access point beacon recently (50 to 100 ms). So I came to the conclusion that the access point is having trouble hearing my computer's transmissions (since my computer can apparently hear the access point reliably). If I booted MacOS X it would work just fine from anywhere in the house, including much further away. And while I could sometimes interfere with pinging a little bit by gripping the screen with both hands (covering both antennas), leaving either antenna uncovered while covering the other as best I could with my hand would always leave the pinging solid. I believe the access point was supporting both 802.11B and 802.11G. I did not think to try restricting the bcm43xx to one mode or the other, or set it to a lower speed (which sometimes helps with madwifi interfaces). I'm not sure yet how to do that with this driver. I think the problem is feeble transmissions (or transmissions that for some reason only work when I'm very near the access point), and perhaps not making use of both antennas (since only covering the left antenna had any effect at all). Below is some more info about my computer and kernel. I cannot really do any more experiments until I get an access point, or unless I'm away from home and have one nearby that I can use. I hope this report helps with improving the bcm43xx driver. Thanks to everyone who has contributed to this driver. -Tim Shepard [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - bash5$ lspci :00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 0001:10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller 0001:10:17.0 ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O 0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 0002:24:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI 0002:24:0d.0 ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100 0002:24:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 81) 0002:24:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80) bash6$ dmesg | grep bcm43xx bcm43xx driver bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Number of cores: 5 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off bash7$ lsmod Module Size Used by snd_powermac 50908 0 snd_pcm_oss
Re: Anyone got a 4306 working properly?
||-|| || Cuando: Sun, Jun 04, 2006 at 06:06:29PM -0400 || || Quién: Tim Shepard || || Què: Re: Anyone got a 4306 working properly? ||-|| I have one in a powerbook 17' working with diferent kernels , now 2.6.17-rc3 , and no problem with it , i discover that sometimes its disconnect from AP , and the RTS help a lot to resolve it iwconfig eth0 rts 250 . ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Monday 05 June 2006 00:28, linuxx wrote: ||-|| || Cuando: Sun, Jun 04, 2006 at 06:06:29PM -0400 || || Quién: Tim Shepard || || Què: Re: Anyone got a 4306 working properly? ||-|| I have one in a powerbook 17' working with diferent kernels , now 2.6.17-rc3 , and no problem with it , i discover that sometimes its disconnect from AP , and the RTS help a lot to resolve it iwconfig eth0 rts 250 . You know that RTS is not supported out of the box on softmac? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Ignoring additional 802.11 core. Jun 3 00:56:29 thirtytwo bcm43xx: PHY connected Jun 3 00:56:29 thirtytwo bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 3 00:56:29 thirtytwo bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:30 thirtytwo net.agent[11449]: add event not handled A few things: You didn't say which kernel you're using, that makes a pretty big difference. Right now, 2.6.17_rc5 would be the kernel of choice. You haven't brought the card up with ifconfig in the listing above. Can you bring the card up with ifconfig, then configure your wireless settings with iwconfig? You need to make sure that you have SoftMAC debugging enabled as well. Then, use your card until it disconnects and re-send the whole log. Hopefully a clue will turn up. :) - -Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEggWswGq7BLLARfoRAt1tAKDGbZhel0k7aUjUcGF0b4XtAHfDGwCgkGTS F6D+z56RJ899OGQaMEgUg5k= =2nRk -END PGP SIGNATURE- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Saturday 03 June 2006 23:42, Mattias Nissler wrote: Hey all, I've got a 4306 in my October 2003 Apple albook. I finally had a try with the driver and it worked partially. The behaviour I have here is that it works fine for some time (say 10 secs) and then it just fails for the next few secs (something like 5 seconds). At least this is what Does it recover again? I see in the network traffic monitor and what I can hear trying to listen to a webradio stream ;-) Then I thought maybe it works better when I have a better signal, so I moved the machine to the room where the access point is located, but that didn't help (the access point however showed my host with a better signal quality). So I'm asking you whether anyone has got a chip revision like mine working? If not, any ideas what I should try? Mattias Here is the relevant syslog information: Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled ^^^ Seems like the txstatus DMA queue is b0rked. I will have a look. But I can't test this, as I don't have such hardware (neither does any other developer). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 00:04 +0200, Michael Buesch wrote: On Saturday 03 June 2006 23:42, Mattias Nissler wrote: Hey all, I've got a 4306 in my October 2003 Apple albook. I finally had a try with the driver and it worked partially. The behaviour I have here is that it works fine for some time (say 10 secs) and then it just fails for the next few secs (something like 5 seconds). At least this is what Does it recover again? It does. That is the funny thing. The webradio stream stops for some seconds, then it continues :-) I see in the network traffic monitor and what I can hear trying to listen to a webradio stream ;-) Then I thought maybe it works better when I have a better signal, so I moved the machine to the room where the access point is located, but that didn't help (the access point however showed my host with a better signal quality). So I'm asking you whether anyone has got a chip revision like mine working? If not, any ideas what I should try? Mattias Here is the relevant syslog information: Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled ^^^ Seems like the txstatus DMA queue is b0rked. I will have a look. But I can't test this, as I don't have such hardware (neither does any other developer). Well, this is not my first contact with kernel code, so I'm happy to do some debugging/testing if you tell me what to look for... Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sat, 2006-06-03 at 17:57 -0400, Joseph Jezak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Ignoring additional 802.11 core. Jun 3 00:56:29 thirtytwo bcm43xx: PHY connected Jun 3 00:56:29 thirtytwo bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 3 00:56:29 thirtytwo bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:30 thirtytwo net.agent[11449]: add event not handled A few things: You didn't say which kernel you're using, that makes a pretty big difference. Right now, 2.6.17_rc5 would be the kernel of choice. I'm on 2.6.17_rc5 vanilla. You haven't brought the card up with ifconfig in the listing above. Can you bring the card up with ifconfig, then configure your wireless settings with iwconfig? You need to make sure that you have SoftMAC debugging enabled as well. Then, use your card until it disconnects and re-send the whole log. Hopefully a clue will turn up. :) Ok, here is a detailed log of what I did the last few minutes: thirtytwo linux # ifconfig eth1 up thirtytwo linux # iwconfig eth1 channel 1 thirtytwo linux # iwconfig eth1 rate 11M thirtytwo linux # iwconfig eth1 essid 't22kl fb' thirtytwo linux # ifconfig eth1 192.168.0.32 netmask 255.255.0.0 up thirtytwo linux # route add default gw 192.168.2.34 thirtytwo linux # ping www.google.com PING www.l.google.com (66.249.85.99) 56(84) bytes of data. 64 bytes from 66.249.85.99: icmp_seq=1 ttl=251 time=53.2 ms 64 bytes from 66.249.85.99: icmp_seq=2 ttl=251 time=50.1 ms 64 bytes from 66.249.85.99: icmp_seq=3 ttl=251 time=51.7 ms 64 bytes from 66.249.85.99: icmp_seq=4 ttl=251 time=50.9 ms 64 bytes from 66.249.85.99: icmp_seq=5 ttl=251 time=51.5 ms 64 bytes from 66.249.85.99: icmp_seq=6 ttl=251 time=102 ms 64 bytes from 66.249.85.99: icmp_seq=7 ttl=251 time=52.5 ms 64 bytes from 66.249.85.99: icmp_seq=8 ttl=251 time=53.7 ms 64 bytes from 66.249.85.99: icmp_seq=8 ttl=251 time=56.7 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=9 ttl=251 time=53.1 ms 64 bytes from 66.249.85.99: icmp_seq=10 ttl=251 time=50.3 ms 64 bytes from 66.249.85.99: icmp_seq=11 ttl=251 time=52.3 ms 64 bytes from 66.249.85.99: icmp_seq=12 ttl=251 time=57.8 ms 64 bytes from 66.249.85.99: icmp_seq=13 ttl=251 time=52.2 ms 64 bytes from 66.249.85.99: icmp_seq=14 ttl=251 time=48.7 ms 64 bytes from 66.249.85.99: icmp_seq=15 ttl=251 time=49.6 ms 64 bytes from 66.249.85.99: icmp_seq=16 ttl=251 time=253 ms 64 bytes from 66.249.85.99: icmp_seq=16 ttl=251 time=258 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=16 ttl=251 time=268 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=16 ttl=251 time=271 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=21 ttl=251 time=193 ms 64 bytes from 66.249.85.99: icmp_seq=21 ttl=251 time=195 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=21 ttl=251 time=201 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=21 ttl=251 time=209 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=21 ttl=251 time=220 ms (DUP!) 64 bytes from 66.249.85.99: icmp_seq=23 ttl=251 time=53.1 ms 64 bytes from 66.249.85.99: icmp_seq=24 ttl=251 time=56.2 ms 64 bytes from 66.249.85.99: icmp_seq=25 ttl=251 time=56.8 ms 64 bytes from 66.249.85.99: icmp_seq=26 ttl=251 time=50.7 ms 64 bytes from 66.249.85.99: icmp_seq=27 ttl=251 time=49.9 ms 64 bytes from 66.249.85.99: icmp_seq=28 ttl=251 time=52.8 ms 64 bytes from 66.249.85.99: icmp_seq=29 ttl=251 time=50.3 ms 64 bytes from 66.249.85.99: icmp_seq=30 ttl=251 time=52.0 ms 64 bytes from 66.249.85.99: icmp_seq=31 ttl=251 time=49.6 ms 64 bytes from 66.249.85.99: icmp_seq=32 ttl=251 time=49.7 ms --- www.l.google.com ping statistics --- 32 packets transmitted, 27 received, +8 duplicates, 15% packet loss, time 57922ms rtt min/avg/max/mdev = 48.716/99.502/271.630/79.014 ms, pipe 2 thirtytwo linux # ifconfig eth0 down thirtytwo linux # ifconfig eth1 down The ping output is very typical. Everything is ok for some time until it gets stuck. The DUPS are coming in in a rush just before the thing seems to recover to normal operation. Syslog output is as follows: Jun 4 00:14:36 thirtytwo bcm43xx: Radio turned on Jun 4 00:14:36 thirtytwo bcm43xx: Chip
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 00:46, Michael Buesch wrote: On Sunday 04 June 2006 00:35, Mattias Nissler wrote: Jun 4 00:17:44 thirtytwo bcm43xx: DMA 0x0260 (RX) max used slots: 1/64 Jun 4 00:17:44 thirtytwo bcm43xx: DMA 0x0200 (RX) max used slots: 1/64 Jun 4 00:17:44 thirtytwo bcm43xx: DMA 0x0260 (TX) max used slots: 0/512 Jun 4 00:17:44 thirtytwo bcm43xx: DMA 0x0240 (TX) max used slots: 0/512 Jun 4 00:17:44 thirtytwo bcm43xx: DMA 0x0220 (TX) max used slots: 221/512 ^^^ TX queue overrun. Jun 4 00:17:44 thirtytwo bcm43xx: DMA 0x0200 (TX) max used slots: 0/512 From the log I can't see what is wrong. But is it normal that the chip needs to be reset? No, it is a TX timeout, because the queue overruns. (see above). I think xmit status reports are not delivered (handled). At least not 100% of them. But it seems like the handler ran, as we had max one used slot on it (DMA 0x260). I am looking at the code, but I can't see yet what's wrong. Just to begin with. Could you test the following patch, please. Please provide full dmesg after testing, again. Thanks. diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c index bbecba0..1e00eb3 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c @@ -840,6 +840,8 @@ static void dma_rx(struct bcm43xx_dmarin struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb-data; struct bcm43xx_xmitstatus stat; +udelay(100); +mb(); stat.cookie = le16_to_cpu(hw-cookie); stat.flags = hw-flags; stat.cnt1 = hw-cnt1; -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
Just to begin with. Could you test the following patch, please. Please provide full dmesg after testing, again. Thanks. diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c index bbecba0..1e00eb3 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c @@ -840,6 +840,8 @@ static void dma_rx(struct bcm43xx_dmarin struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb-data; struct bcm43xx_xmitstatus stat; +udelay(100); +mb(); stat.cookie = le16_to_cpu(hw-cookie); stat.flags = hw-flags; stat.cnt1 = hw-cnt1; Well, I think it didn't change anything. At least the experienced behaviour was the same as before. Anyway, here is what I did: thirtytwo mattias 01:15:49 $ modprobe bcm43xx thirtytwo mattias 01:15:53 $ ifconfig eth1 up thirtytwo mattias 01:15:57 $ iwconfig eth1 channel 1 thirtytwo mattias 01:16:00 $ iwconfig eth1 rate 11M thirtytwo mattias 01:16:04 $ iwconfig eth1 essid 't22kl fb' thirtytwo mattias 01:16:10 $ ifconfig eth1 192.168.0.32 netmask 255.255.0.0 up thirtytwo mattias 01:16:25 $ ping 192.168.2.34 PING 192.168.2.34 (192.168.2.34) 56(84) bytes of data. 64 bytes from 192.168.2.34: icmp_seq=1 ttl=255 time=15.7 ms 64 bytes from 192.168.2.34: icmp_seq=2 ttl=255 time=6.28 ms 64 bytes from 192.168.2.34: icmp_seq=3 ttl=255 time=5.40 ms 64 bytes from 192.168.2.34: icmp_seq=4 ttl=255 time=5.17 ms 64 bytes from 192.168.2.34: icmp_seq=5 ttl=255 time=6.17 ms 64 bytes from 192.168.2.34: icmp_seq=6 ttl=255 time=11.4 ms 64 bytes from 192.168.2.34: icmp_seq=7 ttl=255 time=6.34 ms 64 bytes from 192.168.2.34: icmp_seq=8 ttl=255 time=6.04 ms 64 bytes from 192.168.2.34: icmp_seq=9 ttl=255 time=6.99 ms 64 bytes from 192.168.2.34: icmp_seq=9 ttl=255 time=16.3 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=10 ttl=255 time=9.43 ms 64 bytes from 192.168.2.34: icmp_seq=10 ttl=255 time=13.5 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=11 ttl=255 time=5.31 ms 64 bytes from 192.168.2.34: icmp_seq=11 ttl=255 time=7.28 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=12 ttl=255 time=7.17 ms 64 bytes from 192.168.2.34: icmp_seq=13 ttl=255 time=5.59 ms 64 bytes from 192.168.2.34: icmp_seq=14 ttl=255 time=17.4 ms 64 bytes from 192.168.2.34: icmp_seq=15 ttl=255 time=8.75 ms 64 bytes from 192.168.2.34: icmp_seq=16 ttl=255 time=6.82 ms 64 bytes from 192.168.2.34: icmp_seq=17 ttl=255 time=3.71 ms 64 bytes from 192.168.2.34: icmp_seq=18 ttl=255 time=6.28 ms 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=6.51 ms 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=8.74 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=20.3 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=25.8 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=20 ttl=255 time=11.5 ms 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=6.87 ms 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=9.70 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=20.7 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=39.1 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=22 ttl=255 time=78.3 ms 64 bytes from 192.168.2.34: icmp_seq=22 ttl=255 time=83.7 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=22 ttl=255 time=88.1 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=17.3 ms 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=19.9 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=27.3 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=45.4 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=29 ttl=255 time=125 ms 64 bytes from 192.168.2.34: icmp_seq=29 ttl=255 time=141 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=32 ttl=255 time=6.24 ms 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=7.01 ms 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=8.28 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=14.8 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=35.6 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=58.9 ms 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=63.7 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=72.0 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=90.6 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=66.1 ms 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=67.4 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=74.0 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=77.4 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=48 ttl=255 time=45.5 ms 64 bytes from 192.168.2.34: icmp_seq=49 ttl=255 time=5.37 ms 64 bytes from 192.168.2.34: icmp_seq=49 ttl=255 time=6.50 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=50 ttl=255 time=6.35 ms 64 bytes from 192.168.2.34: icmp_seq=51 ttl=255 time=4.58 ms 64 bytes from 192.168.2.34: icmp_seq=51 ttl=255 time=6.84 ms (DUP!) 64
Re: Anyone got a 4306 working properly?
Just to begin with. Could you test the following patch, please. Please provide full dmesg after testing, again. Thanks. diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c index bbecba0..1e00eb3 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c @@ -840,6 +840,8 @@ static void dma_rx(struct bcm43xx_dmarin struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb-data; struct bcm43xx_xmitstatus stat; +udelay(100); +mb(); stat.cookie = le16_to_cpu(hw-cookie); stat.flags = hw-flags; stat.cnt1 = hw-cnt1; Well, I think it didn't change anything. At least the experienced behaviour was the same as before. Anyway, here is what I did: thirtytwo mattias 01:15:49 $ modprobe bcm43xx thirtytwo mattias 01:15:53 $ ifconfig eth1 up thirtytwo mattias 01:15:57 $ iwconfig eth1 channel 1 thirtytwo mattias 01:16:00 $ iwconfig eth1 rate 11M thirtytwo mattias 01:16:04 $ iwconfig eth1 essid 't22kl fb' thirtytwo mattias 01:16:10 $ ifconfig eth1 192.168.0.32 netmask 255.255.0.0 up thirtytwo mattias 01:16:25 $ ping 192.168.2.34 PING 192.168.2.34 (192.168.2.34) 56(84) bytes of data. 64 bytes from 192.168.2.34: icmp_seq=1 ttl=255 time=15.7 ms 64 bytes from 192.168.2.34: icmp_seq=2 ttl=255 time=6.28 ms 64 bytes from 192.168.2.34: icmp_seq=3 ttl=255 time=5.40 ms 64 bytes from 192.168.2.34: icmp_seq=4 ttl=255 time=5.17 ms 64 bytes from 192.168.2.34: icmp_seq=5 ttl=255 time=6.17 ms 64 bytes from 192.168.2.34: icmp_seq=6 ttl=255 time=11.4 ms 64 bytes from 192.168.2.34: icmp_seq=7 ttl=255 time=6.34 ms 64 bytes from 192.168.2.34: icmp_seq=8 ttl=255 time=6.04 ms 64 bytes from 192.168.2.34: icmp_seq=9 ttl=255 time=6.99 ms 64 bytes from 192.168.2.34: icmp_seq=9 ttl=255 time=16.3 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=10 ttl=255 time=9.43 ms 64 bytes from 192.168.2.34: icmp_seq=10 ttl=255 time=13.5 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=11 ttl=255 time=5.31 ms 64 bytes from 192.168.2.34: icmp_seq=11 ttl=255 time=7.28 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=12 ttl=255 time=7.17 ms 64 bytes from 192.168.2.34: icmp_seq=13 ttl=255 time=5.59 ms 64 bytes from 192.168.2.34: icmp_seq=14 ttl=255 time=17.4 ms 64 bytes from 192.168.2.34: icmp_seq=15 ttl=255 time=8.75 ms 64 bytes from 192.168.2.34: icmp_seq=16 ttl=255 time=6.82 ms 64 bytes from 192.168.2.34: icmp_seq=17 ttl=255 time=3.71 ms 64 bytes from 192.168.2.34: icmp_seq=18 ttl=255 time=6.28 ms 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=6.51 ms 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=8.74 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=20.3 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=19 ttl=255 time=25.8 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=20 ttl=255 time=11.5 ms 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=6.87 ms 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=9.70 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=20.7 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=21 ttl=255 time=39.1 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=22 ttl=255 time=78.3 ms 64 bytes from 192.168.2.34: icmp_seq=22 ttl=255 time=83.7 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=22 ttl=255 time=88.1 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=17.3 ms 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=19.9 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=27.3 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=25 ttl=255 time=45.4 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=29 ttl=255 time=125 ms 64 bytes from 192.168.2.34: icmp_seq=29 ttl=255 time=141 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=32 ttl=255 time=6.24 ms 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=7.01 ms 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=8.28 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=14.8 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=34 ttl=255 time=35.6 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=58.9 ms 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=63.7 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=72.0 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=38 ttl=255 time=90.6 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=66.1 ms 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=67.4 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=74.0 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=44 ttl=255 time=77.4 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=48 ttl=255 time=45.5 ms 64 bytes from 192.168.2.34: icmp_seq=49 ttl=255 time=5.37 ms 64 bytes from 192.168.2.34: icmp_seq=49 ttl=255 time=6.50 ms (DUP!) 64 bytes from 192.168.2.34: icmp_seq=50 ttl=255 time=6.35 ms 64 bytes from 192.168.2.34: icmp_seq=51 ttl=255 time=4.58 ms 64 bytes from 192.168.2.34: icmp_seq=51 ttl=255 time=6.84 ms (DUP!) 64
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 01:51, Mattias Nissler wrote: 0x00: cookie: 0x1043, flags: 0x01, cnt1: 0x01, cnt2: 0x00, seq: 0x0044, unk: 0x 0x01: cookie: 0x1042, flags: 0x01, cnt1: 0x01, cnt2: 0x00, seq: 0x0043, unk: 0x 0x02: cookie: 0x1041, flags: 0x01, cnt1: 0x01, cnt2: 0x00, seq: 0x0042, unk: 0x 0x03: cookie: 0x1040, flags: 0x01, cnt1: 0x01, cnt2: 0x00, seq: 0x0041, unk: 0x 0x04: cookie: 0x103f, flags: 0x01, cnt1: 0x01, cnt2: 0x00, seq: 0x0040, unk: 0x 0x05: cookie: 0x103e, flags: 0x00, cnt1: 0x07, cnt2: 0x00, seq: 0x003f, unk: 0x 0x06: cookie: 0x103d, flags: 0x00, cnt1: 0x07, cnt2: 0x00, seq: 0x003e, unk: 0x 0x07: cookie: 0x103c, flags: 0x00, cnt1: 0x07, cnt2: 0x00, seq: 0x003d, unk: 0x 0x08: cookie: 0x103b, flags: 0x00, cnt1: 0x07, cnt2: 0x00, seq: 0x003c, unk: 0x 0x09: cookie: 0x103a, flags: 0x01, cnt1: 0x01, cnt2: 0x00, seq: 0x003b, unk: 0x Yeah, we are loosing lots of TX packets. (That's why we receive DUPs. We don't always get the ICMP replies out and the sender resends the packet). So, why do we often fail to transmit? That's a good question. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
