Re: [OT] Git trouble
On Tue, 2008-09-02 at 20:20 -0400, Celejar wrote: [This is off topic, but my entire reason for struggling with git is to help test patches to b43, so I beg the list's pardon for asking here.] I'm trying to maintain a git repository of wireless-testing, to test Michael's patches to b43. The initial git-clone went fine, and I tested several patches successfully. I'm currently having a great deal of trouble trying to update my local repository via git-pull. I've spent a while with the various git manpages (git-pull, git-clean, git-checkout, git-reset, git-tutorial, etc.), as well as with the wireless.kernel.org git-guide and with google, but I just can't seem to grok basic git operation. All I want to do is dump any changes I've made to the code, and then pull in an updated version, but I just can't make git do that. I am getting all kinds of errors; google turns up other instances of them, but no straightforward solution. You may be better off writing to linux-wireless about it. As far as I know, there was some botched update made to the tree made in the recent days, but it have been fixed. Anyway, many trees are updated in a non-linear way. This means that you may need to reset the tree to the remote tip: git-reset --hard wireless-testing/master This will lose your uncommitted changes. If you have your changes in a separate branch, you should be able to rebase your branch on top on the newly updated version. I recommend that you use StGIT for local patches. While not strictly required, it's a tool that is primarily designed to working with patchsets. It will pop all patches before updates, so that you should be able to do any dangerous git commands and then push your patches on top of the result. If you have any advanced questions about git, please ask them in the git list. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom's own driver: firmware?
On Mon, 2008-08-25 at 11:08 -0700, Adam Williamson wrote: The license this driver is under is not F/OSS, but it's not as restrictive as the license on the Windows driver. The instructions at http://wireless.kernel.org/en/users/Drivers/b43 don't refer to any Windows drivers. They already refer to distributable files. It explicitly allows redistribution, in unmodified form. So it wouldn't be okay to extract the firmware from this driver and just package that, but distros *could* package the entire driver (without ever actually using it) and then automatically extract the firmware from it when setting up b43. This would finally solve the Firmware Minefield issue caused by distros not being able to ship firmware for b43 in any way. That's a question to distros. I think they have good reasons not to ship non-free software with restrictive licenses. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 with 2.6.25 on Fedora
On Sun, 2008-07-27 at 05:59 +, Greg Matheson wrote: I seem to be only able to get a bcm4306 chip to work when I power on, but powering on does not seem to be a sufficient condition for it to work. I am wondering if powering on after some time off is necessary and sufficient? You mean it doesn't work after reboot? This is with 2.6.25-14.fc9.i686 or 2.6.25.10-86.fc9.i686. And I can only get this result with 4.150.10.5 firmware. With 3.130.20.0 firmware, ie b43legacy. after associating with the AP, it disassociates with reason=3. That is, it disassociates of its own accord. That is, I haven't been able to get it working with 3.130.20.0. You should not be able to use b43 and b43legacy with the same device. Perhaps you patched one of those drivers to support your card? Then please be specific. I wasn't able to get 4.80.53.0 working either, though I haven't tried as much. Actually, I think b43legacy is the track this chip should be working with, rather than b43, because I think it has a 'MAC core revision' of 2, ie less than 4. b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 What matters is the 802.11 core revision reported by the ssb driver when SSB debugging is enabled. b43 doesn't report it. Perhaps ssb is too quiet without debugging. b43-phy0: Broadcom 4306 WLAN found b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 I have a bcm4306 card with the same PHY and radio, and it's supported by b43 only. b43legacy can be patched to support it. I have no problems with that card, even with reboots. The output of uname -a: Linux pl757.nas921.nara.nttpc.ne.jp 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 20:46:03 EDT 2008 i686 i686 i386 GNU/Linux Fedora is known to pull some experimental stuff into its kernels. Anyway, it's not the latest Fedora kernel, please upgrade if you can. And all real wireless work is done on the wireless-testing kernel. [EMAIL PROTECTED] ~]# dhclient wlan0 -v Internet Systems Consortium DHCP Client 4.0.0 Copyright 2004-2007 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/wlan0/00:07:40:c4:f5:d6 Sending on LPF/wlan0/00:07:40:c4:f5:d6 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 No DHCPOFFERS received. No working leases in persistent database - sleeping. dhclient on Fedora brings the interface down briefly. b43 is very susceptible to disassociation if it happens (but sometimes the connection survives). A workaround it to avoid dhclient. If you have to use it, you'll need to set essid in another session while dhclient is waiting, or run wpa_cli -i wlan0 reassociate It is a known problem, but I think dhclient is entirely to blame. Bringing the interface down goes well beyond the zone of responsibility of dhclient, as it affects the lower layers that need to stay connected and keep their state. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Regression (FC8 to FC9)
On Wed, 2008-06-25 at 11:06 -0400, Frank Middleton wrote: Updated FC8 kernel that worked fine 2.6.25.6-27.fc8 FC9 kernel (that has the regression) 2.6.25.6-55.fc9.x86_64 I would probably try to bisect it. I realize that it's a lot of work. The breakage is caused either by patches or by configuration changes. Finding out is the first step. Then look for the patch or for configuration change that affects the problem. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ssb-sprom application issues.
On Wed, 2008-06-25 at 01:18 -0400, Dale Walsh wrote: As I stated, since I do not have anything concrete to work from I am guessing at the expected locations and registers (bits) but after close examination, I concluded the bytes are at SPROM_BOARDREV + 2 as seen in the html post and now this more legible post. It overlaps with SPROM_PA0B0, so I'm not sure it's correct. I would be more willing to agree with you if you were restoring incorrectly changed code, or fixing an inconsistency between reading and writing. However, I cannot support assertions not based on the (pre-)existing code or reverse engineering. I would like to note that there should be 3 antenna entries in rev 4 as reported to me by Broadcom however they did not provide a decode of the bytes or the sprom data. That's a valuable piece of information. But I think the first priority should be restructuring of ssb-eeprom to make inconsistencies unlikely and to allow accumulating information about new SPROM formats without having to change the code too much. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More discrepancies in ssb-sprom
On Wed, 2008-06-25 at 15:07 -0400, Dale Walsh wrote: On Jun 25, 2008, at 08:35 AM, Michael Buesch wrote: On Wednesday 25 June 2008 13:51:54 Dale Walsh wrote: The problem with your statement is that as far as I could locate, this is the only tool that allows you to modify the subsystem vend/ prod ID's and to tweak antenna gains to improve performance of a card. You should read a good book about antenna physics. I can assure you I know something about antenna design, gain and wavelength versus overall length, loading, termination, resistance, balancing, corona, directional versus omni-directional, resonance, multi-elements, arrays, yagi's, quad's and the antenna is only as good as the transmitter or receiver attached to it. If the transmitter power is supplied at 70% of the available power then the distance that the transmitter is effective is diminished exponentially by the amount of power being generated. I suggest that you introduce a new field in ssb-sprom, call it antenna-shape and put yagi there. That would greatly help with both reception and transmission :-) -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM 4325 support
On Tue, 2008-06-24 at 12:36 -0700, Ram kumar wrote: Please guide us whether this can achieved by using BCM4325 module ? I have gone through the http://linuxwireless.org/en/users/Drivers/b43 website which says that broadcomm modules can be configured to access point modeWe want to know whether this module BCM4325 can be configured to work as an access point ? Please try and tell others whether it's working for you. Nobody is going to research it for you, especially if it requires buying extra hardware. You may get better replies if you post in plain text without HTML, don't quote whole messages and answer the questions you are asked. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ssb-sprom application issues.
On Mon, 2008-06-23 at 20:39 -0400, Dale Walsh wrote:
I have been trying to modify antenna and antenna gain values and it
appears that the wrong data is being modified.
I confirm it's still a problem with the current version in git.
SPROM(0x04, Subsytem product ID) = 0x0453
But you are not using the latest version, because I fixed that typo.
Anyway, as I understand it, the original ssb-sprom as committed to the
git repository assumed that the A gain comes first at and the BG gain is
second.
The later changes for SPROM revision 4 assumed that the BG gain is
first, and the A gain is second. But those changes broke support for
older SPROM revisions. Also, the use of sprom[offset + 1] meant that
the incorrect offset would be printed. And the worst thing is that
modify_value() would modify wrong values for SPROM revision 4.
I actually don't know if the antenna gain order was changed in SPROM 4.
I just assume it from the history of the changes.
This patch should restore the original behavior for the old SPROM, and
it shouldn't break SPROM4 more than it's already broken.
diff --git a/ssb_sprom/ssb_sprom.c b/ssb_sprom/ssb_sprom.c
index ee56d38..9f182ef 100644
--- a/ssb_sprom/ssb_sprom.c
+++ b/ssb_sprom/ssb_sprom.c
@@ -293,10 +293,16 @@ static int modify_value(uint8_t *sprom,
sprom[SPROM_BOARDREV + 1] |= (1 5);
break;
case VALUE_ANTGA:
- sprom[SPROM_ANTENNA_GAIN + 0] = (v 0xFF);
+ if (sprom_rev == 4)
+ sprom[SPROM4_ANTENNA_GAIN + 1] = (v 0xFF);
+ else
+ sprom[SPROM_ANTENNA_GAIN] = (v 0xFF);
break;
case VALUE_ANTGBG:
- sprom[SPROM_ANTENNA_GAIN + 1] = (v 0xFF);
+ if (sprom_rev == 4)
+ sprom[SPROM4_ANTENNA_GAIN] = (v 0xFF);
+ else
+ sprom[SPROM_ANTENNA_GAIN + 1] = (v 0xFF);
break;
case VALUE_PA0B0:
sprom[SPROM_PA0B0 + 0] = (v 0x00FF);
@@ -577,14 +583,14 @@ static void display_value(const uint8_t *sprom,
offset = SPROM_ANTENNA_GAIN;
} else {
desc = Antenna 1 Gain;
- offset = SPROM4_ANTENNA_GAIN;
+ offset = SPROM4_ANTENNA_GAIN + 1;
}
- value = sprom[offset + 1];
+ value = sprom[offset];
break;
case VALUE_ANTGBG:
if (sprom_rev != 4) {
desc = B/G PHY antenna gain;
- offset = SPROM_ANTENNA_GAIN;
+ offset = SPROM_ANTENNA_GAIN + 1;
} else {
desc = Antenna 0 Gain;
offset = SPROM4_ANTENNA_GAIN;
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ssb-sprom application issues.
Hello, Dale!
It would be great if you write in plain text without HTML. It would
make it easier to quote your message.
On Tue, 2008-06-24 at 17:14 -0400, Dale Walsh wrote:
Since I can't be sure which version I actually have I started with
what I had with the fix for the subsystem product code and moved
forward from there.
Please don't do it this way. In general case, it would be dangerous to
integrate your changes in nobody, even you, knows what was changed by
you and what was present in the base code. That's why patches are used
to send code changes.
Other than adding some checking that seemed to be going on with the
sprom_rev 4, (I added similar checking in a couple of places) the
sprom_rev 4 is still broken but sprom_rev 2 appears to now works
properly.
I understand you are talking about your code, not about my patch?
case VALUE_ANTGA:
if (sprom_rev == 4)
sprom[SPROM4_ANTENNA_GAIN + 2] = (v 0xFF);
else
sprom[SPROM_ANTENNA_GAIN + 2] = (v 0xFF);
break;
Do you have any reason to believe that antenna gain for 802.11a is
located there? That's a separate 16-bit register.
case VALUE_ANTGBG:
if (sprom_rev == 4)
sprom[SPROM4_ANTENNA_GAIN + 0] = (v 0xFF);
else
sprom[SPROM_ANTENNA_GAIN + 0] = (v 0xFF);
break;
The same question about 802.11bg. Do you actually see any changes if
you modify SPROM?
case VALUE_ANTGA:
if (sprom_rev != 4) {
desc = A PHY antenna gain;
offset = SPROM_ANTENNA_GAIN + 1;
} else {
desc = Antenna 1 Gain;
offset = SPROM4_ANTENNA_GAIN;
}
value = sprom[offset + 1];
That's misleading. You are telling users that the data is at offset
0x75, but you are reading it at 0x76.
Your code is consistent, but I don't see any evidence that it's correct.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
More discrepancies in ssb-sprom
Hello! VALUE_ANTA0, VALUE_ANTA1, VALUE_ANTBG0 and VALUE_ANTBG1 are all read at SPROM_BOARDREV + 2 for non-rev4 SPROM. SPROM_BOARDREV + 2 is equal SPROM_PA0B0, which means that the same data is displayed twice. The same values are written to SPROM_BOARDREV + 1. For VALUE_ANTA1, VALUE_ANTBG0 and VALUE_ANTBG1 there is no special handling for rev4 SPROM, which must be wrong. Likewise, there is no special treatment for rev4 for VALUE_MAXPA and VALUE_MAXPBG in modify_value(), but display_value() treats them separately. It seems to me that ssb-sprom should be rewritten. I think the SPROM structure should be described as a table for every SPROM revision in a format like this: ID, name, byte offset, bit offset, bit size That should solve the problem of synchronization between read and write functions. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More discrepancies in ssb-sprom
On Tue, 2008-06-24 at 22:07 -0500, Larry Finger wrote: I agree that ssb-sprom should be rewritten; however, before that is done, we need to think carefully as to what variables should be exposed for a user. For instance, should antenna gains be brought out? What about antenna enable variables? Is there any reason for a user to change these? The reason would be to fix wrong values. I believe everything should be available. If there are any specific concerns about specific fields, there should be warnings. If there are chances to brick the device, there should be big warnings, or perhaps the entries should have a read-only flag. Anyway, ssb-sprom is not for casual users. In addition, it might be useful to know about new revisions. We now have an instance of revision 8, where the only locations that have been identified are the usual ID stuff at the start and the MAC address. Everything else is unknown. What about revs 5, 6 and 7? That's where having a table with entry descriptions would be helpful. Tables for unknown revisions could start with just a few entries and get populated with entries from other revisions. If there is anything unusual about the unknown fields (e.g. they are big endian or read-only), it could be represented as additional flags. If the firmware was described as a C structure covering the whole firmware, copying entries could shift everything. And the current approach would lead to unmaintainable growth of the code. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy kernel warning
On Tue, 2008-06-17 at 16:59 -0400, David Ellingsworth wrote: I ran into this error today from a kernel I built last night based on the latest wireless-testing branch. Correct me if I'm wrong, but it looks to be b43legacy related. I'm a bit new to kernel debugging but can try to provide additional information if instructions on how to do so are provided. ... WARNING: at kernel/softirq.c:141 local_bh_enable+0x1f/0x59() ... [c0117477] local_bh_enable+0x1f/0x59 [dcf44045] __sta_info_unlink+0xa9/0x134 [mac80211] [dcf4453f] sta_info_unlink+0x9/0xd [mac80211] It looks like __sta_info_unlink() from net/mac80211/sta_info.c tries to enable softirqs while hardirqs are disabled. That doesn't appear to be specific to the driver. Perhaps it should be reported to linux-wireless. b43legacy-phy0 warning: Unexpected value for chanstat (0x7C00) That is b43legacy related. The driver only expects B43legacy_PHYTYPE_B (1) or B43legacy_PHYTYPE_G (2) in the lower two bytes of chanstat, but it's 0. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43-tools typos
diff --git a/ssb_sprom/ssb_sprom.c b/ssb_sprom/ssb_sprom.c index 2b05e9f..facacab 100644 --- a/ssb_sprom/ssb_sprom.c +++ b/ssb_sprom/ssb_sprom.c @@ -16,7 +16,7 @@ You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to - the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, + the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ @@ -398,7 +398,7 @@ static void display_value(const uint8_t *sprom, value = sprom[offset]; break; case VALUE_SUBP: - desc = Subsytem product ID; + desc = Subsystem product ID; if (sprom_rev == 4) offset = SPROM4_SUBP; else @@ -937,7 +937,7 @@ static void print_usage(int argc, char *argv[]) prdata( -g|--rawget OFF Get a value at a byte-OFFset\n); prdata(\n); prdata(Predefined values (for displaying (GET) or modification):\n); - prdata( --subp [0x] Subsytem product ID for PCI\n); + prdata( --subp [0x] Subsystem product ID for PCI\n); prdata( --subv [0x] Subsystem vendor ID for PCI\n); prdata( --ppid [0x] Product ID for PCI\n); prdata( --bflhi [0x] High 16 bits of boardflags (only if spromversion 1)\n); diff --git a/ssb_sprom/ssb_sprom.h b/ssb_sprom/ssb_sprom.h index 4b44e95..68d690f 100644 --- a/ssb_sprom/ssb_sprom.h +++ b/ssb_sprom/ssb_sprom.h @@ -16,7 +16,7 @@ You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to - the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, + the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ diff --git a/ssb_sprom/utils.c b/ssb_sprom/utils.c index 5d3189e..b57b415 100644 --- a/ssb_sprom/utils.c +++ b/ssb_sprom/utils.c @@ -16,7 +16,7 @@ You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to - the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, + the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: hybrid-wl compilation
On Thu, 2008-06-12 at 16:39 -0400, Felipe Maya wrote: Hi, it was my results of the compilation of http://www.broadcom.com/support/802.11/linux_sta.php on openwrt ... /opt/openwrt-2.6.25/build_dir/linux-brcm47xx/compat-wireless-2008-06-10/hybrid-wl/lib/wlc_hybrid.o_shipped: could not read symbols: File in wrong format I guess you are trying to link an i386 object file into a mips kernel. Binaries are for one architecture only. Welcome to the closed source world. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 opensource firmware for monitor mode
On Mon, 2008-06-09 at 14:08 +0200, Michael Buesch wrote: You can try the latest firmware from git, btw. It should be (partially) fixed there. I've tried the today's version. It's working in monitor mode. Moreover, it scans in managed mode! The only problem is that it fails to associate, even to an AP with no security. But there are no hangs whatsoever. That's core rev5 (bcm4306). -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 opensource firmware for monitor mode
On Fri, 2008-06-13 at 01:20 +0200, Michael Buesch wrote: On Friday 13 June 2008 00:22:39 Pavel Roskin wrote: On Mon, 2008-06-09 at 14:08 +0200, Michael Buesch wrote: You can try the latest firmware from git, btw. It should be (partially) fixed there. I've tried the today's version. It's working in monitor mode. Moreover, it scans in managed mode! The only problem is that it fails to associate, even to an AP with no security. But there are no hangs whatsoever. That's core rev5 (bcm4306). Thanks for testing. TX is not implemented. No wonder it fails to assoc ;) No wonder even the big 7 dBi antenna didn't help :) Anyway, it's great news. It turns out bcm4318 with rev9 code is working in monitor mode too! -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 and card recognition.
On Sun, 2008-06-08 at 20:56 +0200, Michael Buesch wrote: Would donating a card speed up the process??? No. Donating a Reverse Engineer would help. :-) I suggest that you write to [EMAIL PROTECTED] Reverse engineering could be a fun project for somebody, especially since bcm4328 is modern hardware with many potential users. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
RE: b43legacy: Problems with dhclient
On Wed, 2008-06-04 at 15:49 -0400, David Ellingsworth wrote: For a while now, I've been experiencing connection stability issues which from what I can tell seem to stem from the use of dhclient. After upgrading to the latest wireless-testing kernel, I noticed the output from wpa_supplicant and iwconfig regarding association status differed as well as an inability to use dhclient to receive an ip address. In an attempt to resolve the issue, I first eliminated the use of dhclient by issuing a static ip address for the interface after it was associated with the AP. Doing so resulted in a very stable and reliable connection. This led me to believe the issues were a result of using dhclient. To verify, I tried dhcpcd in place of dhclient, which once again resulted in a stable and reliable connection. Thus confirming my suspicion. The problem with dhclient is that it brings the interface down temporarily, thus breaking the WPA connection. You can see hostap archives for a recent discussion about it: http://lists.shmoo.com/pipermail/hostap/ It's a complicated problem, involving a lot of software, including distribution specific scripts. It's entirely possible that simply different timing can break the behavior. Jouni Malinen mentioned that the driver is supposed to tell wpa_supplicant to renegotiate the connection after the interface goes down and up. It's possible that the kernel is not doing it right, but the code is not in b43legacy, it's in mac80211. My solution is either to use static addresses with WPA or use a dhclient script that brings the interface up and tell wpa_supplicant to renegotiate the connection. In any case, I'm quite sure that discussing the problem here is not going to be useful because it's not specific to the particular driver. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 opensource firmware for monitor mode
On Wed, 2008-06-04 at 17:16 +0200, Michael Buesch wrote: Release early, release often. Here's the first testing release of the b43 opensource firmware. http://bu3sch.de/misc/b43-openfw-20080604.tar.bz2 Currently only the receive path is partially implemented. So that means we can only run it in monitor mode for now. This firmware is able to receive packets and push them without special handling (like decrypting) to the driver. There are lots of bugs, of course. Sometimes the PLCP header is corrupted. That will result in a kernel driver warning in xmit.c. This firmware does _only_ work on wireless core revisions 5, 6, 7, 8 or 10. That's great news! Having distributable firmware would simplify installation, placing b43 to the same league as Intel devices. But having free firmware would be unique to Broadcom card and extremely attractive for research in wireless communications and development of novel devices using non-standard protocol extensions. As a short term goal, maybe bcm4328 could be dumbed down to work with b43? I've tried it with bcm4318 first, and it hung hard on module load. Even Alt-SysRq would not work. It turns out it was revision 9 missing in your list. Then I tries a bcm4306 device with rev 5 core. The module loaded. I brought it up in managed mode first. Scanning didn't work. I brought the device down and set monitor mode. But the system hung when I tried to bring the interface back up. Anyway, I'm glad to see progress in that direction. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] mac80211: fix panic when using hardware WEP
57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99 misplaced code for setting
hardware WEP keys. Move it back. This fixes kernel panic in b43 if WEP
is used and hardware encryption is enabled.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
net/mac80211/wep.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index c9fd129..e7b6344 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -335,10 +335,10 @@ static int wep_encrypt_skb(struct ieee80211_tx_data *tx,
struct sk_buff *skb)
info-control.icv_len = WEP_ICV_LEN;
if (!(tx-key-flags KEY_FLAG_UPLOADED_TO_HARDWARE)) {
- info-control.hw_key = tx-key-conf;
if (ieee80211_wep_encrypt(tx-local, skb, tx-key))
return -1;
} else {
+ info-control.hw_key = tx-key-conf;
if (tx-key-conf.flags IEEE80211_KEY_FLAG_GENERATE_IV) {
if (!ieee80211_wep_add_iv(tx-local, skb, tx-key))
return -1;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit
Quoting Johannes Berg [EMAIL PROTECTED]: info-control.hw_key is NULL. Is a NULL pointer supposed to tell do not encrypt, or is this a mac80211 bug? It's probably a bug. I've bisected it to commit 57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99: mac80211: move TX info into skb-cb It turns out that commit introduces two sparse warnings in net/mac80211/wpa.c: net/mac80211/wpa.c:202:10: warning: incorrect type in return expression (different base types) net/mac80211/wpa.c:202:10:expected int net/mac80211/wpa.c:202:10:got restricted ieee80211_tx_result [usertype] noident net/mac80211/wpa.c:448:10: warning: incorrect type in return expression (different base types) net/mac80211/wpa.c:448:10:expected int net/mac80211/wpa.c:448:10:got restricted ieee80211_tx_result [usertype] noident That's returning TX_CONTINUE from tkip_encrypt_skb() and ccmp_encrypt_skb(), where an integer should be returned. Both times it happens after info-control.hw_key is set. The callers of those functions check for negative numbers only, but TX_CONTINUE is 0, and TX_DROP is 1. Something must be wrong there. wep_encrypt_skb() in wep.c would not return TX_CONTINUE. But most importantly, there is a suspicious change in wep_encrypt_skb() - the key is set in the other branch of the condition. I'll try to restore the original logic in wep.c. I'll post a patch if it works. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit
On Mon, 2008-06-02 at 00:08 -0400, Pavel Roskin wrote:
wep_encrypt_skb() in wep.c would not return TX_CONTINUE. But most
importantly, there is a suspicious change in wep_encrypt_skb() - the
key is set in the other branch of the condition.
I'll try to restore the original logic in wep.c. I'll post a patch if
it works.
That was it! Here's the patch (I'll submit it to John tomorrow if nobody
objects).
mac80211: fix hardware WEP support
Setting hardware WEP key was accidentally moved to a wrong place in
57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99. Move it back. This fixes
kernel panic in b43 if WEP is used.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
net/mac80211/wep.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index c9fd129..e7b6344 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -335,10 +335,10 @@ static int wep_encrypt_skb(struct ieee80211_tx_data *tx,
struct sk_buff *skb)
info-control.icv_len = WEP_ICV_LEN;
if (!(tx-key-flags KEY_FLAG_UPLOADED_TO_HARDWARE)) {
- info-control.hw_key = tx-key-conf;
if (ieee80211_wep_encrypt(tx-local, skb, tx-key))
return -1;
} else {
+ info-control.hw_key = tx-key-conf;
if (tx-key-conf.flags IEEE80211_KEY_FLAG_GENERATE_IV) {
if (!ieee80211_wep_add_iv(tx-local, skb, tx-key))
return -1;
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit
Hello!
You beat me at reporting it. I was about to report the same thing.
Basically, my laptop with bcm4311 started crashing when using WEP in the
last weeks. Its runs the current wireless-testing.
On Sat, 2008-05-31 at 16:23 +0200, Stefanik Gábor wrote:
#4 [c04619c8] b43_generate_txhdr at f8dd3a99
Yes, that's where it happens. This patch prevents the panic, but it's
almost certainly not the right fix.
diff --git a/drivers/net/wireless/b43/xmit.c
b/drivers/net/wireless/b43/xmit.c
index f9e1cff..5ec8d86 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -234,11 +234,14 @@ int b43_generate_txhdr(struct b43_wldev *dev,
plcp_fragment_len = fragment_len + FCS_LEN;
if (use_encryption) {
- u8 key_idx = info-control.hw_key-hw_key_idx;
+ u8 key_idx;
struct b43_key *key;
int wlhdr_len;
size_t iv_len;
+ if (!info-control.hw_key)
+ return -ENOKEY;
+ key_idx = info-control.hw_key-hw_key_idx;
B43_WARN_ON(key_idx = dev-max_nr_keys);
key = (dev-key[key_idx]);
Another workaround is to use nohwcrypt=1 in the module options.
It's strange that other drivers (b43legacy, ath5k) use
info-control.hw_key-hw_key_idx under the same conditions (see how
use_encryption is calculated), but don't have any problems on the same
network (but I need to recheck).
I'm using 40-bit WEP with wpa_supplicant (because it's configured to
recognize many networks, some of which are with WPA). I don't know if
it's relevant. It's Fedora 9 for x86_64, but NetworkManager is
disabled.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit
On Sat, 2008-05-31 at 18:54 +0200, Stefanik Gábor wrote: On Sat, May 31, 2008 at 6:48 PM, Pavel Roskin [EMAIL PROTECTED] wrote: It's strange that other drivers (b43legacy, ath5k) use info-control.hw_key-hw_key_idx under the same conditions (see how use_encryption is calculated), but don't have any problems on the same network (but I need to recheck). Hmm... does ath5k use hardware crypto? No, it doesn't, at least with WEP, if I understand ath5k_set_key() correctly. B43 does (but not with nohwcrypt - and that appears to be a valid workaround), b43legacy doesn't AFAIK. Although the code with use_encryption is present in b43legacy, it don't see any references to set_key, so I guess you are right. Well, that explains something. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: cancel_work_sync() question
On Sat, 2008-05-31 at 16:05 -0400, Clyde McPherson wrote: I am trying to port the Broadcom drivers to an ARM archicture (Linux version 2.6.21) and it appears that cancel_work_sync() is missing from its kernel. Is there any other function that I can replace it with? It's present in newer kernels, and you can look at the implementation and reimplement it. Better yet, switch to a newer kernel. In any case, I don't think you should be asking b43 developers about backporting a standard kernel function to an older kernel. There should be places more suitable for such questions. Also, compat-wireless aims to bring newer wireless drivers to older kernels. It may work for you. If it doesn't, and if compat-wireless still aims to support Linux 2.6.21, you can report the failure as a bug in compat-wireless. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix controller restart crash
On Wed, 2008-05-28 at 15:12 -0400, John W. Linville wrote: Stefano, this is untested. Please test by doing echo -n 1 /debug/b43legacy/phy*/restart rmmod b43legacy It should not crash anymore at the rmmod (actually the restart should also hang in b43legacy, as it has a deadlock, which this patch also fixes). Anyone get a chance to test this one? Yes, the patch is fine. Unloading b43legacy hangs without the patch and works properly with the patch. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: no scan results BCM94311MCG
On Wed, 2008-05-21 at 20:11 +0200, Sandro Hannemann wrote: Dear list members, yesterday I wasted quite some time trying to get the wireless to work without success. The situation is: linux-2.6.24-gentoo-r7 (gentoo flavoured linux kernel). lspci gives: 0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) I used b43-fwcutter-011 to install firmware version broadcom-wl-4.80.53.0 into /lib/firmware. iwlist wlan0 scan yields only wlan0 No scan results. As far as I can tell, you installed the firmware correctly. But it's possible that the driver you are using doesn't have some fixes needed for your hardware. I suggest that you try the driver from compat-wireless, which is the latest driver backported to the recent kernels: http://linuxwireless.org/en/users/Download If it doesn't help, check the antenna connectors on the card if they are accessible. Also try ndiswrapper to rule out problems unrelated to the b43 driver. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: no scan results BCM94311MCG
On Thu, 2008-05-22 at 01:25 +0200, Sandro Hannemann wrote: First, thanks for your reply. I suggest that you try the driver from compat-wireless, which is the latest driver backported to the recent kernels: http://linuxwireless.org/en/users/Download I did that. The thing is only, I get compile issues, which wouldn't bother me too much, as long as b43 would be working fine... Still, you may want to report it to [EMAIL PROTECTED] The reaction on modprobe: # modprobe -f b43 WARNING: Error inserting ssb (/lib/modules/2.6.24-gentoo-r7/kernel/drivers/ssb/ssb.ko): Invalid module format It means the replacement ssb module failed to install. It would be under updates instead of kernel. Well, I don't have pcmcia in my kernel config, because I don't need it. Is there a certain kernel setting requirement that I miss? I believe there is no such requirement (although I haven't tried that). If such requirement exists, the build system should report it. I only see one reference to PCMCIA on the download page: Additionally, the kernel you're building for needs a valid .config file, if it isn't present compat will assume you have PCI, USB and PCMCIA built into your kernel and if not, fail building. So, maybe your .config file wasn't found. Then I found a command b43load somewhere in the wireless-compat tree, but b43load complains about the same error as above and eventually loads the module b43legacy... well... which doesn't work... It confirms that the installation was incomplete. If it doesn't help, check the antenna connectors on the card if they are accessible. It's a laptop from my work. I am not planning to open it and fiddle around with any connectors. Let's say, it is built-in and just not accessable. OK, chances are it's OK if you didn't touch it. Also try ndiswrapper to rule out problems unrelated to the b43 driver. ndiswrapper acts weired as well. I installed version 1.52. I did blacklist these guys: b43, b43legacy, ccb. I downloaded the windows driver and installed it. ndiswrapper seems to be happy: # ndiswrapper -l bcmwl5 : driver installed device (14E4:4311) present (alternate driver: ssb) however, iwconfig says: # iwconfig lono wireless extensions. eth0 no wireless extensions. basically, no wireless device showing up here (also the LED stays off). modprobe ndiswrapper Summary: The wifi here did work some time ago. It is only recently that it rendered that broken. I used to use ndiswrapper one year ago, at some point I switched to b43. So, I guess b43 stopped working one day? Just one restriction: I'd like to stick to 2.6.24 for the time being, as the vmware-modules don't compile against 2.6.25 kernels yet. compat-wireless supports 2.6.22 and newer. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Upload both beacon templates on initial load
On Tue, 2008-05-20 at 12:16 +0200, Michael Buesch wrote: This updates the beacon template code to upload both templates, if we never uploaded one before. ... + bool beacon_templates_virgin; /* Never wrote the templates? */ ... @@ -4164,12 +4191,15 @@ static int b43_op_start(struct ieee80211 * and mac80211 reconfiguring it. */ memset(wl-bssid, 0, ETH_ALEN); memset(wl-mac_addr, 0, ETH_ALEN); wl-filter_flags = 0; wl-radiotap_enabled = 0; b43_qos_clear(wl); + wl-beacon0_uploaded = 0; + wl-beacon1_uploaded = 0; + wl-beacon_templates_virgin = 1; Just a hint. You may want to revert the logic, so that you start with 0 and set the variable to 1 as something substantial happens. You can introduce more states later if required, or count the upload events. This way, it would be beacon_templates_loaded or beacon_templates_touched. The human brain is better at understanding positive meanings. virgin means that something did _not_ happen, and it's not like it's very valuable per se, at least for beacon templates :-) I worked on code full of things like HAVE_NO_CURSES_H and DISABLE_COLOR, and it wasn't fun. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix typo in firmware file name for 802.11 cores with rev 13
On Thu, 2008-05-15 at 21:39 +0200, Michael Buesch wrote: This is 2.6.27 material. Although it is a bug in 2.6.25 and .26, it seems to have zero effect on the performance of the device and can be delayed. Exactly. That's why I decided to delay it :P Actually, it it's a bug and there is a simple fix unlikely to break anything, it should go to 2.6.26. The whole point of having release candidates is fixing bugs. If nothing else, the fix should be applied out of respect to the users of 2.6.26 who will be wondering where to get lp0initvals13. It's just a suggestion, I'm not trying to start a flamewar :-) -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
On Tue, 2008-05-13 at 09:19 +0100, Daniel wrote: buffer size7wlan0: wrong buffer size The missing newlines are fixed in today's wireless-testing repository. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
On Wed, 2008-05-14 at 01:27 +0200, Michael Buesch wrote: Where does this wrong buffer size message come from, and what does it mean? net/mac80211/rx.c There are two instances of that message, both in ieee80211_rx_h_amsdu(), and both in the code path that returns RX_DROP_UNUSABLE. I guess the code complains about some invalid frames and drops them. Somebody with a better knowledge of the code should write better descriptions and make the messages different. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: sucess with HP-laptop dv6057ea
On Mon, 2008-05-12 at 09:44 -0700, Alan wrote: I have a HP dv6000 that was custom built. It has a Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03). This is a b43xx chipset, but does not work correctly with the b43 driver (as far as I know). To get it to work I had to use the ndiswrapper hack. bcm4328 is not supported and is not expected to be supported soon unless more people help with reverse engineering efforts. The driver page mentions that bcm4328 is not supported: http://linuxwireless.org/en/users/Drivers/b43 -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Ubuntu systems
On Sat, 2008-05-10 at 21:38 -0500, Larry Finger wrote: The short version of my results is that patches have been submitted and accepted to fix all known problems with b43legacy when using 802.11b devices. I also submitted the patches needed for implementation of 4311/2 and 4312/2 cards including the disabling of A-PHY's on 802.11a/b/g units. The 4311/2 patch had been in trial versions of the Hardy kernel and reportedly caused a regression for a 4312/1 user. I don't understand that problem. If anyone reading this list knows of a similar problem, please let me know. Because of this history, they are being careful with the 4311/2 changes. Sorry for getting this thread in a slightly different direction, but it seems to me that 4311/4312 don't get as much testing as 4306/4318 among the core developers, which is unfortunate, as the former are used in more modern systems. I think we need to get developers a laptop with PCI Express Mini Card support. A modern Dell Inspiron would be fine. I know that it can be opened relatively easy to replace the card. I did it twice - first to change bcm4328 to iwl4965, and then to bcm4311 (without 802.11a support, so I cannot test this case). In fact, there is another empty slot in my Dell Inspiron 1420, reserved for WAN, so it should be possible to put the second card there. I'm actually going to try it. Dell Vostro shouldn't be much different. I contributed my part to the funds (no idea why it's not shown, I forwarded my receipt to Stefano), and there is more than enough for a minimal Dell Inspiron or Vostro. Vostro 1000 with 64-bit AMD CPU and bcm4312 (1490) is $434 now in the US (plus shipping and tax). -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Ubuntu systems
On Sat, 2008-05-10 at 23:58 -0500, Larry Finger wrote: At present, I have a BCM4311 rev 2 in my laptop so that device gets lots of testing. I used to have a 4311/1, but that laptop was recalled and replaced. To help debug this particular issue, I just bought a D1490 on E-bay. I also have a BCM4310, which has an LP-PHY and is the reason I'm working on the RE for that device. If the developers feel that a new laptop would be desirable, I certainly would not object; however, we do have coverage for these devices. I see, good to know. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4308 rev 3 owner, willing to help (want to make an access point)
On Mon, 2008-04-28 at 11:50 +0200, Francis Galiegue wrote: Hello everyone, Here is my setup: - Gentoo 2007.0, x86; - a Broadcom BCM4308 rev 3 chipset (PCI card), PCI ID 14e4:4320; Actually, according my /usr/share/hwdata/pci.ids file, which came with Fedora development, and should be recent, 14e4:4320 is BCM4306 802.11b/g Wireless LAN Controller. Is BCM4308 written on the chip? - making this card an AP, using hostapd (with the nl80211 driver, I guess); - including the Ethernet card and the BCM in a bridge setup (it works already, but no access point yet). My main gripe right now is that I cannot iwconfig wlan0 mode master. The b43 page says it doesn't work, lacking proper support in mac80211 and hostapd. I'm quite a rookie with AP setups. This card otherwise works fine in managed and ad-hoc mode. The AP functionality is still experimental. Please check archives of [EMAIL PROTECTED] for messages from Johannes Berg with hostap in the subject. You'll find the description of what is missing. There are some patches to enable AP functionality at http://johannes.sipsolutions.net/patches/ I haven't tried it myself and I don't know any details. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote: Hello, First some background: I am currently running latest mainline from git. This kernel suffers from a scheduler? I think this question is more suited for LKML. While trying to find what these hickups come from I ran watch --interval .1 cat /proc/interrupts. I can see there that the b43 disappears, gets unloaded probably, and then reappears. You should probably show the exact contents of /proc/interrupts and provide some details about the systems (architecture, CPU speed, contents of /proc/sched_debug, lspci output, dmesg output). When b43 reappears in the interrupt listing, that line generates some 25000 irq's within a fraction of a second. Is this a bug somewhere or by design? It's possible that the interrupt count is not shown when the driver disappears, but is not reset to 0. Once the interrupt has a handler, the original count is shown. Note that I wouldn't ever see this if the kernel was behaving as normal. I have no idea if the b43 driver has always behaved like this. I could of course test an older kernel on request. That's probably a good idea, as the LKML folks would suspect something they know least about, i.e. the hardware. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Success with bcm4311 and rewrite-lo-calibration
Quoting Michael Buesch [EMAIL PROTECTED]: On Sunday 20 April 2008 05:43:18 Pavel Roskin wrote: Hello! It looks like all tests with the experimental LO calibration code were for bcm4306 and bcm4318. So I downgraded my Dell laptop from bcm4328 to bcm4311 (PCIe Mini Card), so that I can cover this gap and finally switch to a free driver. Everything seems to be OK. I'm using the current linux-wireless repository plus mm-only-b43-rewrite-lo-calibration.patch from http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/broken-out/ Can you also give this a try? http://bu3sch.de/patches/wireless-testing/20080419-1646/patches/005-b43-calibrate-lo-on-demand.patch Just fine. Downloads, uploads, flood ping - everything is OK on 4311. Very little packet loss (through a wall with real live conditions): 231827 packets transmitted, 231210 received, 0% packet loss, time 358086ms rtt min/avg/max/mdev = 1.167/1.395/81.565/0.571 ms, pipe 5, ipg/ewma 1.544/1.214 ms -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Success with bcm4311 and rewrite-lo-calibration
Hello! It looks like all tests with the experimental LO calibration code were for bcm4306 and bcm4318. So I downgraded my Dell laptop from bcm4328 to bcm4311 (PCIe Mini Card), so that I can cover this gap and finally switch to a free driver. Everything seems to be OK. I'm using the current linux-wireless repository plus mm-only-b43-rewrite-lo-calibration.patch from http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/broken-out/ # lspci -nnv -s 0c:00.0 0c:00.0 Network controller [0280]: Broadcom Corporation BCM94311MCG wlan mini-PCI [14e4:4311] (rev 01) Subsystem: Dell Unknown device [1028:0007] Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fe8fc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting ? Capabilities: [13c] Virtual Channel ? Kernel driver in use: b43-pci-bridge Kernel modules: ssb ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 b43-phy0: Broadcom 4311 WLAN found phy0: Selected rate control algorithm 'pid' Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) I'm using WEP to an AP on another floor. The connection is reliable. I don't see any disconnects at all. I downloaded several videos, uploaded a lot of pictures, talked on Skype (for more than 120 seconds :)), ran an X application over ssh, and now writing this e-mail - all things that an ordinary user would do. Everything is fine. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Sun, 2008-04-13 at 19:36 -0500, Larry Finger wrote: Do you have any PCI (not Cardbus) devices that work with b43? Do you know of anyone that does? I have MiniPCI cards with bcm4306 and bcm4318, and both are working fine with the latest b43. I tired them in a PCI adapter and in a Thinkpad T30 laptop, which has a MiniPCI slot. No problems whatsoever. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: 1 second freeze every 2 minutes - works with bcm43xx
On Sun, 2008-04-06 at 15:51 +0200, Julien Muchembled wrote: Pavel Roskin a écrit : If you don't see in in the kernel log, then it's the ssb module that doesn't want to work with your PCI card. Indeed the problem is in ssb: no alias at all. There is a missing option in config.mk I've added the following line and it works: CONFIG_SSB_B43_PCI_BRIDGE=y Thanks! Patch forwarded to Luis Rodriguez. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: 1 second freeze every 2 minutes - works with bcm43xx
On Sun, 2008-04-06 at 01:27 +0200, [EMAIL PROTECTED] wrote: Pavel Roskin a écrit : You may want to use compat-wireless then: http://linuxwireless.org/en/users/Download It's a backport of the current wireless drivers for the older kernels. The patch Michael asked us to test applies to it cleanly. Thank you. I didn't know compat-wireless. Unfortunately I haven't been able to make it work: b43 doesn't recognize my wifi card. I tried compat-wireless-2008-04-05 without the b43 patch. On boot, b43 isn't loaded automatically (by udev) as usual. If I load it with modprobe, I just get the following message: Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] No card appears. I've never been that. I suggest that you unload b43 and ssb modules, then load ssb and look for messages. There should be a message like: ssb: Sonics Silicon Backplane found on PCI device :02:02.0 If you don't see in in the kernel log, then it's the ssb module that doesn't want to work with your PCI card. If you see that message but loading b43 doesn't result in recognizing your card, then we should be looking why the wi-fi device one the ssb bus doesn't match any entry in b43. # With compat-wireless: $ grep b43 modules.* modules.alias:alias ssb:v4243id0812rev0D* b43 It's better to use modinfo: modinfo ssb modinfo b43 -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: We need lots of regression testing
On Sat, 2008-04-05 at 11:09 +0200, Johannes Berg wrote: Another unrelated bug (sorry, testing often finds unrelated bugs) is that scanning with specific ESSID was returning non-matching APs. I mean iwlist wlan0 scan my_essid, which would still report many different ESSIDs. It's inconvenient when the driver can sense 22 APs at once :) Heh. I'm not sure what the desired behaviour is, if you do that scan we'll give you everything we found but will scan actively for that particular SSID. The man page (sigh) only says: This command take optional arguments, however most drivers will ignore those. The option essid is used to specify a scan on a specific ESSID. The option last do not trigger a scan and read left-over scan results. Which isn't quite clear, but seems to match what we do. Maybe iwlist should filter it? I tried scanning for ESSID that no AP has. Most time I only get response from one AP, which is an old Linksys BEFW11S4 v4 (802.11b only). Sometimes one or two other APs appear. But it some cases, all 22 or 23 APs in range appear in the list. The easiest way to reproduce it is to scan without ESSID and then with ESSID. Then the second scan will return all APs found in the first scan. But run the scan with the ESSID several times, and at some point the list goes down to that dumb Linksys. I'm fine with scanning without filtering. It's more important that we let users control what probe requests are being sent. But I think we should be consistent and avoid returning results of scans with different parameters. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: We need lots of regression testing
On Fri, 2008-04-04 at 23:06 -0400, Pavel Roskin wrote: I'll try to get 4318 tested over the weekend. It's just as good as bcm4306. b43-phy0: Broadcom 4318 WLAN found b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 It was the same laptop in the same place, and I could even go a couple of steps further than with bcm4306. It's a place with 22 APs in range, and the AP I was connecting to is installed in a brick building away from any windows. Yet I could maintain connection at the far end of the paring lot nearby. I realize that the unpatched drive could probably perform as well. But I wanted to use this opportunity to test the driver and the patch at once in some real life conditions, and the results are great! Another thing I noticed today is that the quality next to the AP is normally from 65/100 to 75/100. But sometimes it jumps to a higher number momentarily, up to 130/100. Yet I don't see corresponding changes in the signal and noise when it happens. Signal level is jumping randomly from -55 dBm to -15 dBm, and noise level is always -72 dBm (rarely -71 dBm). When at the place when the connection breaks, the quality is 30/100, the signal level is -84 dBm and the noise level is still -72 dBm. Perhaps the quality could be calibrated so that 30 becomes 0 and 70 becomes 100 (and we should never get quality over 100). The noise level is probably too high. And the signal jumping 40 dBm without me even touching anything may indicate that the driver probably fails to make some adjustments in the signal value. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: 1 second freeze every 2 minutes - works with bcm43xx
On Sat, 2008-04-05 at 00:45 +0200, Julien Muchembled wrote: Hmm... There's a misunderstanding somewhere. My laptop appears to be a real nightmare. I've spent too much time hacking the DSDT, having TuxOnIce work (yes, I would also like to test Nigel's git tree if I had time), getting around various hardware and BIOS bugs, etc. I'm tired of updating the kernel so often. You may want to use compat-wireless then: http://linuxwireless.org/en/users/Download It's a backport of the current wireless drivers for the older kernels. The patch Michael asked us to test applies to it cleanly. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Urgent help needed: Broadcom 4318 SPROM corruption
On Mon, 2008-03-31 at 17:39 +0200, Stefanik Gábor wrote: I have a weird problem with my 4318: its SPROM got corrupted (power outage, whatever, I don't know, as I haven't messed with it), and now it appears in my LSPCI output as a Broadcom 4218 (device ID changed to 0x4218 from 0x4318). I can't even flash my SPROM back to the right values, because the SSB driver doesn't pick up my card, and thus no ssb_sprom file appears. My question is: what do I have to modify in the kernel to make SSB threat my BCM4218 as a proper BCM4318, or at least to pick it up to the point where ssb_sprom shows up and I can flash it back to the proper BCM4318? Look for 4318 in drivers/ssb/b43_pci_bridge.c and add a similar value for 4218. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4328 latest GIT driver.
On Mon, 2008-03-31 at 16:09 +0200, Michael Buesch wrote: On Monday 31 March 2008 15:15:03 Subodh Shrivastava wrote: [ 2056.834017] b43-phy1 ERROR: FOUND UNSUPPORTED PHY (Analog 5, Type 4, Revision 1) I am aware that support for this chipset is work in progress, I would be happy to help in testing. Help in reverse engineering is needed ;) I prefer to stay on the software part of things, but I have a BCM4328 in my laptop. I just ordered an Intel card (iwl4965), so once I get it, I can offer that BCM4328 for free (plus free shipping and handling :)) to whoever is going to reverse engineer it. Last time I did it with an Atheros card, and the result exceeded all my expectations - we have functional ath5k now :) -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with a bcm4306 (03) and b43/b43legacy
On Wed, 2008-03-26 at 13:46 +0100, Stefanik Gábor wrote: An idea: Are you using a kernel with SMP and/or PAE enabled? I suspect an SMP-related issue (I got this problem with OpenSUSE kernels, which are all SMP-enabled), or maybe HPET/high-resolution timer/tickless system related. I'm not sure why you are asking me, since I'm not experiencing any major problems now. bcm4318 is working for me with or without SMP. PAE is not enabled. That's the latest wireless-testing kernel. Both the old and the new 4.x firmware is working fine. I tried removing the antenna, but it's still working (the link quality is lower, of course). If you have kernels that work and those that don't work, it's a good starting point. I would try to capture packets going in both directions on a separate machine, note the signal strength, then load ndiswrapper with Windows drivers, capture the packets and compare the results. It's very important that you don't even touch any antenna between measurements or reorient anything. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with a bcm4306 (03) and b43/b43legacy
On Mon, 2008-03-24 at 19:49 -0700, Larry Finger wrote: The problem is with authentication. The interface is actively scanning, thus transmit is working. How do you know that? Receiving beacons doesn't require transmission. Just trying to understand your logic. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No Access to https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Tue, 2008-02-26 at 20:44 +0100, Guillaume wrote: Hi every one. https://lists.berlios.de/mailman/listinfo/bcm43xx-dev return me a Secure Connection Failed... How can i do to unsuscribe ? Firefox says Your certificate contains the same serial number as another certificate issued by the certificate authority. One solution would be to remove the certificates for berlios.de. In Firefox, go to Edit-Preferences-Advanced-Encryption-View Certificates-Web Sites. Remove all certificates issued by berlios.de. Alternatively, you can use another browser that doesn't know of a certificate with the same number. Konqueror, lynx or links should work fine. If everything fails, you can write a message to [EMAIL PROTECTED] with unsubscribe in the subject. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Cannot associate (4318 on HP laptop)
On Fri, 2008-02-22 at 14:45 +0200, Alberto Mardegan wrote: ext Alberto Mardegan wrote: wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authentication with AP 00:13:49:68:98:85 timed out A short follow-up: a user suggested me to move closer to the AP. That made it to work (and NetworkManager reported full signal power, which is hard to believe since I moved only one metre aside). The problem is, this driver is written only from reverse engineered data, but the device needs a lot of attention from the host software. Many things just cannot be implemented without a good understanding of the hardware registers. The driver is getting better, but it not perfect. I do appreciate that you have tested it and that we know that the physical layer is likely suspect. But unfortunately that's not a feasible setup for me, and I had to switch back to ndiswrapper. It's kind of strange to me though, since I'm only 4 metres away from the AP! You may want to try a different channel or bigger antennas. And if you go to ndiswrapper, it would be great to see you back once the driver handles your setup better. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Cannot associate (4318 on HP laptop)
On Mon, 2008-02-18 at 09:52 +0200, Alberto Mardegan wrote: Hi, yesterday I installed the kernel version 2.6.24, and tried to get rid of ndiswrapper. But I could get the wlan to work. wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authentication with AP 00:13:49:68:98:85 timed out From my experience with bcm4318, you need a bigger antenna, and the range will be shorter than with ndiswrapper. I realize that you may not be able to change the antenna, but try getting close to the AP to see if that's the case. iwconfig reports that we are associated with the AP, but if I manually assign an IP to wlan0 with ifconfig and try to ping the AP, I get destination unreachable. If the link quality is shown as 0, you are not associated. Yes, it's misleading to the see AP if the association didn't complete. You can try setting the ESSID again. That should retry the association. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help with bcm4328 revision 5
On Tue, 2008-02-12 at 14:38 -0200, Alan Carvalho de Assis wrote:
Hi,
I am testing kernel 2.6.25-rc1 to get my Broadcom Corporation BCM4328
802.11a/b/g/n (rev 03) working.
You probably want to be on the everything branch of the wireless-2.6
repository to help with this. Not all patches go into 2.6.25-rc1.
ssb: SPROM revision 5 detected. -
From what I see in drivers/ssb/pci.c, even though 5 is printed, it is
later set to 4 for BCM4328:
} else if (bus-chip_id == 0x4321) {
/* the BCM4328 has a chipid == 0x4321 and a rev 4 SPROM */
out-revision = 4;
sprom_extract_r4(out, in);
Otherwise, you would also see Unsupported SPROM revision in the kernel
log.
ssb: Sonics Silicon Backplane found on PCI device :03:00.0
Although ssb module is loaded automatically and correctly, the module
b43 is not loaded automatically, even if I create a
/etc/modprobe.d/b43 (alias wlan0 b43).
Issuing modprobe b43 loads the module but don't raises wlan0 and
don't show any log info.
Try adding revision 12 to the device table.
diff --git a/drivers/net/wireless/b43/main.c
b/drivers/net/wireless/b43/main.c
index afb1094..aa174da 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -82,6 +82,7 @@ static const struct ssb_device_id b43_ssb_tbl[] = {
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 9),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 10),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 11),
+ SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 12),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 13),
SSB_DEVTABLE_END
};
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems b43 driver and bcm4318
Quoting [EMAIL PROTECTED]: Hi, I tried the new b43 driver from kernel 2.6.24 hoping I could get rid of ndiswrapper, but something is wrong. Can you please give me advice as how to troubleshoot this? Below follows the output from dmesg after I modprobe'd the b43 driver. I can't connect to the access point (WEP), but iwlist wlan0 scan actually works. I'm quite sure your case is described in the mail archives: https://lists.berlios.de/pipermail/bcm43xx-dev/2008-February/006779.html It looks like you are using firmware for the git version of the driver, not for Linux 2.6.24.x and older. And by the way, Linux 2.6.24.1 would give you are better message about firmware compatibility. And you probably want to go to the latest 2.6.24.x anyway to avoid a major security issue with the kernel. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Possible problem on b43 driver's init
On Sun, 2008-02-10 at 17:28 -0400, David Cohen wrote: Hi all, I'm here again reporting another possible problem with my wireless card and b43 driver. Please don't bite me this time, I promise I'm sending all useful inputs :D Well, the problem is: - After boot my laptop, the wireless card is not connected to my wifi network. But if I just type sudo iwlist scan, then it connects. - The same problem does not occur if I use ndiswrapper or another laptops. I believe it's a feature of mac80211. It only scans for APs under some circumstances. Setting ESSID triggers scanning. I suggest that you do it in this order: bring the interface up set the WEP key set the ESSID By the way, your AP is set for shared key authentication. It delays authentication because mac80211 tries open system first and fails. Even without that step, shared key authentication needs 4 packets to be sent, rather than 2 for open system authentication. It's believed that shared key is even less secure than open system. See e.g. http://www.networkworld.com/research/2002/0909wepprimer.html -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add support for new firmware
On Sun, 2008-01-13 at 14:20 +0100, Michael Buesch wrote: This patch adds support for new firmware. Old firmware is still supported until July 2008. To get new firmware, go to ftp://ftp.linksys.com/opensourcecode/wrt150nv11/1.51.3/ and download the tarball. We don't have a smaller tarball, yet. That will be fixed later. I have finally found some time and hardware to test it, but the tarball is overwhelming at its 186M. And the worst thing, the server disconnected after 30M and appears to be down right now. P.S. It's up, ETA is 48 minutes. There were two files there. I hope either is fine. I'm trying to download WRT150NV11_v1.51.3_ETSI.tgz Cannot we petition Linksys to put wl_ap.o outside the tarball? Or maybe Broadcom could do it? Even a zip file would be better. It's possible to cut a part of the zip file and uncompress it with gzip. It's really a travesty of open source. The file is available, but you have do download 186M of useless (for me at least) mips compilers and other stuff. And I have a relatively good connection. You can extract firmware out of the wl_ap.o file contained in this tarball using latest fwcutter. You must pass the option --unsupported to fwcutter. Fwcutter-010 with official support for a new firmware image will be released soon. Do you know that the Subversion repository of fwcutter has no files at all? I mean svn://svn.berlios.de/bcm43xx/trunk Yes, I will try --unsupported, with version 009. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? It was bad at the bcm43xx/bcm43xx_mac80211 time, but it's going to be a bigger annoyance this time, because the driver with the same name b43 will need a different fwprefix for different kernel versions. I don't think modprobe.conf can be written to use different options for different kernel versions. And if it can, I don't want to force everyone to figure it out. The driver knows which firmware is needs. It's the driver's responsibility to express its requirements, rather that the users' responsibility to figure out which firmware this particular version of the driver wants. iwlwifi changed the firmware name when a different firmware was needed. And that's a good example, in my opinion. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
Quoting Michael Buesch [EMAIL PROTECTED]: On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. Mind you, there is nothing fundamentally wrong with changing firmware or changing its API. Sure, Broadcom firmware is not under GPL, so we have to keep it in separate files rather than link it into the kernel. But the same situation exists for many other drivers, even those where the vendors are much more cooperative, such as Intel. If the firmware is kept outside the kernel, we have a problem of synchronization between the driver and the firmware. It can be addressed gracefully, or not so gracefully. The choice is entirely ours, and Broadcom is not to blame for our choice. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
Quoting Rafael J. Wysocki [EMAIL PROTECTED]: People don't want N-PHY support? Well, as it sometimes is said the better is an enemy of the good. If they feel comfortable without the N-PHY, why would they want it? Still, if you can add the support for it as a feature that doesn't affect the people's working configurations, no one will complain. I really want N-PHY and I have hardware to test it on. It's just the word fwprefix that makes me allergic. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: Fix for broken transmission
Quoting Larry Finger [EMAIL PROTECTED]: Michael Buesch wrote: Here's an updated version that should fix even more bugs: http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/005-b43-fix-init-rewrite-breakage.patch I had to omit the last part (for tables.c) - it's unrelated, cosmetic and doesn't apply to wireless-2.6/everything. This patch (and its predecessor) seem to make transmission at the OFDM rates a bit more reliable on my BCM4311/2 card. It's working fine on BCM4318 on PowerPC. I haven't done any specific comparisons, but it used to disconnect a lot (at least one an hour) with a small antenna, so I installed a bigger antenna, but then gave up and switched to using another wireless device (rtl8185). Right now, it's been working for over 2 hours with a small antenna (although it's a different antenna borrowed from rtl8185) and no disconnects. Scanning finds 5 APs, which is the most I have seen here. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Off-line for now
On Thu, 2007-11-29 at 07:44 -0600, Larry Finger wrote: Today is the day I start my winter migration to a warmer clime. Until April, my full-time access to a broadband line is limited, which is the reason I resigned as maintainer for bcm43xx and b43legacy. I will not be leaving the bcm43xx community completely as I have joined the reverse engineering group. Larry, I think it's a very good decision after you put the driver on the firm foundation of mac80211. Better understanding of the hardware is essential for further improvements. Good luck with your migration and with reverse engineering! In fact, my BCM4311 has higher throughput with the b43 driver than it does when I'm running Windows (Yes, my machine does dual-boot, but that is mainly for testing!). That's impressive indeed. I hope it would be true for 4318, and eventually for 4328. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, 2007-11-22 at 08:26 -0500, John W. Linville wrote: As it stands, setting the SSID is the closest thing we have to an associate now trigger. I would have to advise distros and users to always set it last in the wireless init, just before running dhclient or whatever. Maybe mac80211 should have a grace period of 0.5 seconds or so to allow other settings to be set before the scanning starts? The same applies to other events causing scanning, such as bringing up the interface. It's too short to be noticeable, yet long enough for the next command to run even on slow systems. I think setting the key should not cause reassociation if there is an association. It can break some schemes where the WEP key changes periodically on both sides. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, 2007-11-22 at 18:18 -0700, Ehud Gavron wrote: 2. dmesg repeats: wlan0: authentication with AP 00:50:bf:b1:da:64 timed out I think it's an unrelated hardware specific issue. mac80211 tried to associate but failed. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM94311MCG
On Thu, 2007-11-08 at 17:36 +0100, Ruggiero wrote: i just installed fedora7 and the firmware 4 by bcm43xx_fwcutter,it's a bit different by ubuntu because i don't have the command iwconfig and iwlist scan,how can i verify the card is working properly?here there is some informations: i have a b44ethernet card in the laptop [EMAIL PROTECTED] ~]$ dmesg|grep bcm bcm43xx_mac80211: Broadcom 4311 WLAN found You should upgrade your system with yum upgrade. The current Fedora 7 kernel is 2.6.23.1 with b43 and b43legacy drivers, which work much better. You'll need b43-fwcutter to prepare firmware for the updated drivers. It creates firmware files in subdirectories and avoids conflict between v23 and v4 firmware. Just in case, today may not be the best day to upgrade Fedora, and Fedora 8 was released, and the pipes are likely saturated. Try upgrading just the kernel: yum upgrade kernel On the other hand, Fedora updates are so massive, that you may prefer to join the torrent and download Fedora 8. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Kubuntu on an Acer
On Sun, 2007-10-28 at 19:23 -0500, Robert Easter wrote: Here's one for the scrapbook, though hopefully not for the scrap yard- New install of Kubuntu 7.10- has a gui install set up for the Broadcom drivers, etc. Very nice, if it worked. Any suggestions on how to find the glitch, or best ways to totally replace the dead code with some that works? Details: Most likely you don't have the firmware. Please try: aptitude install bcm43xx-fwcutter That should download and install the firmware upon install. If you cannot get that system online at all, you can get bcm43xx-fwcutter from http://linuxwireless.org/en/users/Drivers/b43 and follow the instructions how to extract the firmware. Then transfer it to the laptop. If the problems persist, please check the kernel messages with dmesg. You may also want to find out which driver you are using by running: lsmod |grep -E '(b43|bcm43)' If you are using b43 or b43legacy, you'll need b43-fwcutter, which creates slightly different firmware files. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote: - macstat = le32_to_cpu(rxhdr-mac_status); + macstat = le16_to_cpu(rxhdr-mac_status); mactime = le16_to_cpu(rxhdr-mac_time); chanstat = le16_to_cpu(rxhdr-channel); But I think in this case this also didn't change the actual result in macstat. I don't think so. Suppose rxhdr-mac_status is 1. le32_to_cpu() will return 0x100, which would turn into 0 on conversion to u16. le16_to_cpu() will return 0x100. Since rxhdr-mac_status is accessed by value (not by pointer), it will be 1 whether it's treated as 32-bit or 16-bit. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
Quoting Michael Buesch [EMAIL PROTECTED]: I don't think so. Suppose rxhdr-mac_status is 1. le32_to_cpu() will return 0x100, How would it return 0x100? if mac_status is 1 in the lowest byte, le32_to_cpu would not put that 1 into the highest byte of the result. Actually, it would. On big-endian systems, conversion from little-endian to CPU order swaps bytes. Please note that referring to the lowest byte can be confusing. The least significant byte and the byte with the least address are not the same on big-endian systems. Besides, mac_status has a meaning for the CPU that is different from its meaning for the hardware in the hardware is little-endian but the CPU is not. What the hardware sees as 0x100, the CPU sees as 1 before the conversion. What is least significant for one is most significant for another, until the conversion is done. which would turn into 0 on conversion to u16. le16_to_cpu() will return 0x100. Since rxhdr-mac_status is accessed by value (not by pointer), it will be 1 whether it's treated as 32-bit or 16-bit. Ok, I didn't know it's passed by value. I thought it was casted to pointer inline. If it's passed to leX_to_cpu by value, of course it's a different story. OK. I'll leave my explanation anyway for benefit of other readers. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, fwcutter] add support for DragonFlyBSD
Hello! On Sat, 2007-09-08 at 15:08 +0800, Sepherosa Ziehau wrote: Following patch make b43-fwcutter work on DragonFlyBSD: http://leaf.dragonflybsd.org/~sephe/fwcutter.diff Please review it. If you folks think it is OK, please commit it to your svn repos. It was reviewed by johill and mb on #bcm-specs I suggest that you remove all references to DragonFlyBSD and use some symbol that is defined on all BSD systems. This way, the program will compile and work with no changes on all BSD systems as long as the headers are compatible. And if there are any incompatibilities, they would likely be minor and fixable without adding too many ifdefs. The patch as it is just encourages adding more preprocessor conditionals if the program is ported to more OSes. Also, I suggest that you reconsider calling the firmware directories v3 and v4. Such names are too generic and don't provide information about the hardware, unlike b43 and b43legacy. It would be easier if b43-fwcutter just worked the same way on any OS. You may prefer to do renaming in a wrapper that installs the firmware. I would put definitions for bswap_16 and bswap_32 immediately below #include sys/endian.h, but it's a mater of taste. Also, I would use definitions with arguments, as they are more robust and would indicate use with a wrong number of arguments. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Thanks...!
Hello! Please don't start new threads for the same topic. Next time please use reply on the appropriate message in the thread. It's just easier to read this way. On Fri, 2007-09-07 at 13:24 -0700, Arne Chr. Jorgensen wrote: (3) For Broadcom wireless, look for BCM4311 or BCM4312 cards. Stay away from pre-N stuff. pre..802.11n - is that what you meant ? Just to avoid possible confusion, this refers only to the devices implementing any preliminary 802.11n specifications (whether it's pre-N or draft N), not to the devices implementing standard protocols that predate 802.11n, such as 802.11g and 802.11b. Basically, support for bcm4306 and bcm4311 are quite good, bcm4318 is getting there, support for anything newer is not even under development. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
An idea about Kconfig issue
Hello! [I'm sorry I'm on vacation on a very slow connection, so I may not be able to reply soon, but I'll post anyway] I think we could rename CONFIG_SSB to CONFIG_BROADCOM_SSB. This way, everybody running make oldconfig will be asked whether to enable this option. The help text could explain which devices need it. I believe it's at least as good as the hacks that have been suggested so far. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301 - bcm43xx-legacy
On Thu, 2007-08-09 at 15:41 +0200, Michael Buesch wrote: So, that said, I want to rename all the drivers. My plan was to rename bcm43xx-mac80211 to b43, so you could probably rename bcm4301 to b43-legacy or something shorter like b43-leg or maybe even b43-old. I think if bcm43xx will be replaced with its mac80211 port, it should stay bcm43xx to preserve users' .config and fwpostfix settings. If the softmac and the mac80211 drivers are going to coexist at least in one released kernel, then b43old seems to be a good name for the new driver. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301 - bcm43xx-legacy
On Thu, 2007-08-09 at 16:07 +0200, Michael Buesch wrote: On Thursday 09 August 2007 16:00:47 Pavel Roskin wrote: On Thu, 2007-08-09 at 15:41 +0200, Michael Buesch wrote: So, that said, I want to rename all the drivers. My plan was to rename bcm43xx-mac80211 to b43, so you could probably rename bcm4301 to b43-legacy or something shorter like b43-leg or maybe even b43-old. I think if bcm43xx will be replaced with its mac80211 port, it should stay bcm43xx to preserve users' .config and fwpostfix settings. No it should not. bcm43xx-mac80211 requires different firmware. I think you misread me. its mac80211 port refers to bcm4301. I just tried to avoid the bcm4301 name because it wasn't exposed in Linux releases yet. Anyway, it's up to Larry, and he doesn't seem to dislike legacy. -- 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 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: Dell Inspirson 9400 with Dell 1390 wireless card
Hello! On Tue, 2007-08-07 at 08:25 -0400, Rob Lewis wrote: I apologize if this has been covered already, but i have a few questions, as i am lost as where to begin to get this driver to work. I have a Dell 1390 Wireless card with bcm4311 chipset. I believe it is v4 firmware. I have been reading the lists and Larry mentioned that this driver only works with v3. As far as I know, the firmware is never stored in the device permanently. It is loaded by the driver into device RAM. The firmware has to be extracted by bcm43xx-fwcutter, which can process both v3 and v4 firmware. How do i find out my firmware revision? It will be reported by bcm43xx-fwcutter Will there be support for v4? It is is a separate driver, bcm43xx_mac80211. It's already supported. Can i flash the rom to v3 to get support for this driver, and in doing so, will it affect the hardware functionality at all? As far as I know, you cannot flash ROM. I did not see a bcm4311 driver in the kernel (.22 and .23rc1), do i need to patch to get it? If you mean bcm4301, yes, you need to patch the kernel. But bcm43xx is already in the driver, and it works with v3 firmware. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Dell Inspirson 9400 with Dell 1390 wireless card
On Tue, 2007-08-07 at 10:41 -0400, Rob Lewis wrote: 1) Use fwcutter to find out firmware revision, if v4 patch kernel enable 4301, if v3 enable bcm4311 driver. 2) Use normally? You can use fwcutter to extract any firmware. bcm43xx and bcm4301 use v3 firmware. bcm43xx_mac80211 uses v4 firmware. There is no such thing as bcm4311 driver. When the interface is brought up, the driver will load the firmware. If the firmware version is wrong, there will be a message in the kernel log, which can be seen with the dmesg command. I will be looking for 'tutorials online' as to how to do this, though if you can point me to something you can recommend, that would be great. I'm not aware of any tutorials. bcm43xx-fwcutter can be found here: http://developer.berlios.de/project/showfiles.php?group_id=4547 -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Dell Inspirson 9400 with Dell 1390 wireless card
On Tue, 2007-08-07 at 11:34 -0400, Rob Lewis wrote: Without broadcom releasing drivers or source, will we always have to use fwcutter? All that's needed is to make it legal to copy the firmware, and most distributions will be able to package it. That's what Atmel and Intel did. They didn't release sources of the firmware. The best thing Broadcom could do would be to release the detailed specifications, but releasing the firmware under a free-to-copy license would be helpful too, as it would allow using the existing Linux drivers out-of-box. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] Fix handling of failure to create debugfs directory
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---
.../wireless/bcm43xx-mac80211/bcm43xx_debugfs.c|8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
index 9ca4625..aded2b3 100644
--- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
@@ -408,7 +408,7 @@ static struct file_operations restart_fops = {
int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
{
- return !!(dev-dfsentry-dyn_debug[feature]);
+ return !!(dev-dfsentry dev-dfsentry-dyn_debug[feature]);
}
static void bcm43xx_remove_dynamic_debug(struct bcm43xx_wldev *dev)
@@ -472,7 +472,9 @@ void bcm43xx_debugfs_add_device(struct bcm43xx_wldev *dev)
snprintf(devdir, sizeof(devdir), %s, wiphy_name(dev-wl-hw-wiphy));
e-subdir = debugfs_create_dir(devdir, fs.root);
if (!e-subdir || IS_ERR(e-subdir)) {
- e-subdir = NULL;
+ bcmerr(dev-wl, debugfs: cannot create %s directory\n,
+ devdir);
+ dev-dfsentry = NULL;
kfree(log-log);
kfree(e);
return;
@@ -525,6 +527,8 @@ void bcm43xx_debugfs_log_txstat(struct bcm43xx_wldev *dev,
struct bcm43xx_txstatus *cur;
int i;
+ if (!e)
+ return;
log = e-txstatlog;
assert(irqs_disabled());
spin_lock(log-lock);
___
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 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 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
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: I will switch to quilt based development
On Fri, 2007-08-03 at 09:36 +0200, Holger Schurig wrote: I see. One thing I didn't like in quilt is that I have to decide what I'm going to do before actually changing the sources. All I have to decide beforehand is the name of patch. In stgit this is the same. However, stg is worse, because there I even have to enter a description of what I'm about to do beforehand. *) But unlike quilt, you don't have to do anything before editing the sources. You can create a patch after the changes are done. Or you can revert the changes. Having to do anything before editing reeks of version control systems predating CVS, where files had to be checked out for editing. My complaint about stgit is that I have to write the description without seeing the changes. I just noticed stg new -s, but it's broken. Generally, stgit follows quilt too closely here. stg new and stg refresh should be merged, or one of them should be optional. Sometimes, I just make patches in quilt, then I do quilt refresh, quilt pop -a, cd patches and modify the patches and series file manually, e.g. by moving one patch from one file into the other. The cd .., quilt push -a and off I am. That the database of quilt is in a known format and I can hack on it with an editor is a plus for me :-) That's a very cool feature that stgit should learn. That said: once I'm finished with quilt-things, I'm using stg import to import this into git and use git to send it off to the mailing list. I'm not working with stg on the first place, because quilt is noticably faster than stg. Perhaps periodic repacking with git-gc could speed up things a bit. But the search for changed files is actually for your protection, and should be appreciated IMHO. *) in stgit I can do stg refresh -e to edit the description afterwards stg refresh -es and stg export -np are my favorite commands. I'm going to post all my ideas to the git list right now. -- 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 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: I will switch to quilt based development
Hello, Michael! On Thu, 2007-08-02 at 22:47 +0200, Michael Buesch wrote: Hey guys, I will drop my git tree and switch to much more lightweight quilt based workflow. My latest patchsets will be published at http://bu3sch.de/patches/wireless-dev/ My scripts do upload the plain patchfiles (plus quilt series file) and additionally a .tar.bz2 file. Please consider StGIT (http://www.procode.org/stgit/), which works on top of git. I really like that StGIT makes it possible to go back to old patches and adjust them. And it works with qgit. Patches can be exported and published. It should be possible to make a build system that would compile SSB and bcm43xx_mac80211 outside the kernel tree. The lightweight tree could still use the usual path under drivers/ssb and drivers/net/wireless for the drivers, so that the patches won't need to be adjusted. If you have any specific problems with git, it would be great if you report them to the git mailing list. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I will switch to quilt based development
On Fri, 2007-08-03 at 00:22 +0200, Michael Buesch wrote: No, I don't want git. It's too heavy. And it has major problems when John rebases his tree upstream. I'm sure you can help git development if you post your observations to the git list. With quilt and my scripts I can easily push them upstream to linville, easily publish them on my server. All a matter of typing one command. stg export -np stg mail --all Going back to old patches works perfect with quilt. I see. One thing I didn't like in quilt is that I have to decide what I'm going to do before actually changing the sources. And it's impossible to revert changes made before the patch is created. But I understand it's a question of habits, and everybody has different preferences when it comes to the tools. And I am not going to maintain out of tree stuff anyway. :) That's why I suggested the lightweight tree: Makefile drivers/ ssb/ ssb sources net/ wireless/ bcm43xx_mac80211/ bcm43xx_mac80211 sources The top-level Makefile finds the kernel sources and compiles against them. It can also have maintenance targets, such as indent. Yes, I looked at stgit before writing my own set of scripts on top of quilt. And I found out that it doesn't quite fit my needs. OK, it's getting off-topic, but if you need help with stgit, please feel free to ask. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
On Fri, 2007-07-20 at 09:44 -0400, John W. Linville wrote: On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote: Actually, the common practice is that the new driver that doesn't supplant the old driver immediately and for the whole range of hardware gets a new name. Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100. Yes, this preserves stability for happy bcm43xx users. Still taking suggestions for the new name for bcm43xx-mac80211... :-) b43 bcm43 bcm4k3 bcmwifi bcmwlan bcm80211 brcm43xx broadcom I really like the minimalism of b43, which plays well with b44 and p54 :) Also, we could introduce a kernel option to enable support for new devices in your driver. Yes, this is probably worthwhile for those wishing to avoid PCI ID conflicts between the drivers. I have also been speculating that perhaps we need an option for a secondary PCI ID table, so that a driver could support a large range of PCI IDs but then gracefully bow-out if another driver had a certain ID in its primary table. Does that make any sense? It would seem to be applicable to a number of drivers in the kernel. Yes, I used to hearing complains that orinoco steals IDs from hostap. Then it became popular to blacklist orinoco modules. Quite a disgrace for the driver! Having weak IDs for Prism based cards would have avoided it. But please realize that the problem goes far beyond PCI. Perhaps you have heard of CONFIG_USB_LIBUSUAL, which selects the best driver for USB storage devices, either the slow but reliable ub, or the SCSI based usb-storage, which it too fast for some cheap sticks. It even has a parameter called bias, which allows to control how conservative the algorithm should be. That would be hard to emulate with weak entries, but I hope that bias is an overkill. Yes, we should probably start using a default value for fwpostfix. As dwmw2 suggested, it would also be nice to fall back to an empty fwpostfix if the firmware is not found w/ the default extension. Yes, that sounds good. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
Hello, Ehud! On Fri, 2007-07-20 at 09:33 -0700, Ehud Gavron wrote: The USERs don't want to know what card they have or what driver they need or PCI IDs. That's all stuff that makes them say Linux Bad, *s good. (Yeah I know, there's the whole driver moreass there and PCI VENs too) but anyway... Agreed. The driver should have a name that reflects its use and capabilities. Not necessarily. End users should be shielded from such details by distributions. Do you know the name of the Windows driver for your network card? Does it reflect its use and capabilities? Now, if we are talking about power users, who can occasionally recompile the kernel or install a program not from the distribution, they would be helped by reasonable names of the drivers. Also, distribution maintainers would feel better if the drivers are not renamed, so that /etc/modprobe.d/ doesn't need to be scanned for the old names on kernel upgrade. For example, bcm43xx is a reasonable name. I don't like it personally because the google links to the site (berlios.de) that tell me that's why I need took a while to find but that's just semantics. That's not a problem with the name. If the first hit on Google was some vomit inducing picture, then maybe. bcm43xx_mac80211 is a less reasonable name. With respect to the coders who have put time into making this usable on by 4306 and almost usable on my 4311 I can say that I appreciate the effort... but the name needs work. If I was king of driver package naming, the driver that works with v3 and v4 firmware and supports crypto functions would be... broadcom80211bg or bcm80211g The driver that only works with v3 (aka bcm43xx) broadcomv3 The driver that only works with v4 (aka bcm43xx_mac80211) broadcomv4 You take just one aspect (firmware version) and put it into the name. The original name was also taking just one aspect (802.11 stack). I fail to see why your approach it better. I don't know any other Linux (or _any_) driver that puts the firmware version into its name. I believe you are implying that the firmware selection will be a problem, so you prefer a name that would make it easy to solve that problem. But then you are not writing as a user, you are writing as somebody who has been exposed to some internals. Ask a random user if the firmware version should be part of the driver name, and you'll get a blank stare. By the way, more information could be put into the module description, which is shown by modinfo. As time advances and bcb43xx_mac80211/broadcomv4 is brought to spec so it works great... its code would be integrated into broadcom80211g/bcm80211g. Now you put the name of the protocol into the driver, which is again inconsistent with the existing naming and doesn't scale. Suppose 802.11a support is fixed, would we need to rename the driver again? And that if the driver supports only 802.11b on some card? Would not the 80211g part be misleading? That's my thinking. As a USER. As a linux advocate and zealot. See above. Users should not care about driver names. If they do, we have a bigger problem. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
Hello, Larry! First of all, many thanks for porting the v3 driver to mac80211! On Thu, 2007-07-19 at 20:38 -0500, Larry Finger wrote: 1. For more general testing, I'll distribute my driver as a patch to be applied to wireless-dev as it needs ssb, which is not yet in mainline. If we are still in testing when ssb is merged, I'll change to making patches against mainline. Sounds good. 2. Once the problems have been cleared and ssb is in -mm, it gets sent there as a port from softmac to mac80211 for the current bcm43xx. An additional consideration is that a port from softmac to mac80211 will be more easily merged than if it looks like a new driver. I would prefer if the name stayed the same, but it shouldn't be a big deal. 3. If the port of softmac to mac80211 is merged before Michael's driver, it will be known as bcm43xx with bcm43xx-mac80211 remaining in wireless-dev. Yes, that's what I mean, keep it bcm43xx unless renaming it is the condition for acceptance. 4. Once bcm43xx-mac80211 gets merged to mainline, then Michael's driver should become bcm43xx and my driver gets its PCI IDs stripped to the 802.11b-only devices and once again becomes bcm4301. This name change for Michael's driver would cause some disruption for current users as their firmware would have the wrong name/version. That might be too much of a problem. Actually, the common practice is that the new driver that doesn't supplant the old driver immediately and for the whole range of hardware gets a new name. Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100. Also, we could introduce a kernel option to enable support for new devices in your driver. I think this is a path that always has a stable driver with at least moderate performance in mainline throughout the entire transformation. That's a very good goal. I would also consider the option to use different names for v3 and v4 firmware. I have a file /etc/modprobe.d/bcm43xx that reads options bcm43xx fwpostfix=.3 options bcm43xx_mac80211 fwpostfix=.4 but we cannot expect every distro (let alone every user) to take care of the naming conflict. Users don't expect the need to rename firmware, and we shouldn't create a problem for them. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: dell e1505 bcm43xx driver, bcm4311 chipset?
On Fri, 2007-07-06 at 13:00 -0500, Larry Finger wrote: John H. wrote: I was wondering if, on fedora 7 now with 2.6.21 kernel, it is possible to use bcm43xx driver with this device and get 54mb/s and wpa support? I have the firmware installed, etc. I just had many problems last time, as it wouldn't get 54mb/s, etc. With 2.6.21 or later kernels, the bcm43xx driver works quite well without any patching. It still doesn't do 54 Mbs, but my 4311 gets an Iperf throughput of over 15 Mbs. FYI, Windows using exactly the same configuration and hardware gets 19 Mbs, thus we are close. Actually, bcm43xx seems to be patched in the stock Fedora kernel to only support 4301. At least it fails to pick 4318 on my desktop machine. See alias below: $ modinfo bcm43xx filename: /lib/modules/2.6.21-1.3228.fc7/kernel/drivers/net/wireless/bcm43xx/bcm43xx.ko license:GPL author: Michael Buesch author: Stefano Brivio author: Martin Langer description:Broadcom BCM43xx wireless driver srcversion: F29014CCD786A001B1A577A alias: pci:v14E4d4301sv*sd*bc*sc*i* depends:ieee80211,ieee80211softmac ... The standalone version from ftp://lwfinger.dynalias.org/patches compiles fine though and has a whole bunch of aliases. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Unauthorized Network card (ERROR 104)
On Wed, 2007-07-04 at 16:49 -0700, Jhonie Walker wrote: Whathever I tried it didn't gave any results. no value, etc. [skip] I hope someone can help me. Maybe I am using the tool in a wrong way. Then maybe you should give the exact command line and the exact error messages? -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.22-rc6, dhcp, promiscuous mode, and other things
Hello! On Tue, 2007-06-26 at 18:58 -0700, Ehud Gavron wrote: I've been alternately switching between 2.6.22-rc3 (Linville git tree) and 2.5.22-rc6 (Linville git tree as of today), henceforth rc3 and rc6 respectively. There have been significant changes in bcm43xx_mac80211 in its own git repository (http://bu3sch.de/git/wireless-dev.git), which improved things a lot. As far as I know, the changes are not in 2.6.22-rc6 yet, or you would have seen a backtrace. I've been alternately switching between bcm43xx and bcm43xx_mac80211, henceforth soft and hard respectively. There is nothing specifically hard in mac80211. You may need to use another convention. About the only thing I've found strange that I hope someone else can confirm, is that running a tcpdump simultaneously with the DHCP client causes more success than failure. I understand you mean tcpdump on the same machine as the driver. I think I may have seen it. Perhaps the promiscuous mode would speed up recalibration, or something like that. Anyway, the current git version of bcm43xx_mac80211 is working much better and should not need such tricks. If I had to do a matrix it would look like this: rc6 hard - works but stuck at 1Mbps rc6 soft - works rc6 hard - unable to communicate, but associates fine rc6 soft - works You may want to use another convention for kernel versions as well. They look too similar to me. Encryption key:896A-0055-AE77-5E80-ED86-4E38-3A I hope you understand you cannot reuse this key after having exposed it in a public forum. On the other hand, WEP is considered generally unsafe these days, so it's more an polite request to leave your network alone than actual security. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [bcm43xx-users] 4311 still not receiving
On Fri, 2007-06-22 at 00:54 -0400, Chuckk Hubbard wrote: I worked through some things with Ehud, but it was inconclusive. I just recompiled using the advice at http://forums.gentoo.org/viewtopic-t-547687.html as far as kernel options, and I did this with the 2.6.22-rc4 patched kernel, and uname -r indeed tells me 2.6.22-rc4_etc. eth1 will scan, picking up several APs, and the command iwconfig eth1 essid frank key blahblahbl, after doing it twice, does cause a valid access point in the output of ifconfig eth1. The network GUI dialog shows the available ap's, several of them, and shows eth1 as being active and the WEP key is in and everything. Yet the command 'dhclient eth1' still tells me the network is down, and I still cannot access the internet. I remember that I had to specify open when setting the WEP key to force open system authentication. Even though the algorithm was already shown as open, setting it would probably fix something in softmac. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [bcm43xx-users] 4311 still not receiving
On Fri, 2007-06-22 at 04:06 -0400, Chuckk Hubbard wrote: Thanks for the suggestion; I tried several times in a row, it didn't change anything. I went ahead and copied a bunch of commands, the dmesg output afterwards, and the results of ifconfig and iwconfig... Did I miss something (also plz tell me if I just published all someone needs to hack into my comp!): #: ifconfig eth1 down #: ifconfig eth1 up #: iwconfig eth1 essid frank #: iwconfig eth1 key open #: iwconfig eth1 key 74b571f1c9 My situation is that I don't use iwconfig eth1 key open initially. The interface goes up and works enough time for dhclinet to get an address. Then it's stops working, although iwconfig still shows the association. And then iwconfig eth1 key open restores the connection permanently. It's one of those little irritating bugs in softmac. Other little bugs are incorrect display of ESSID when the interface is down and duplicate packets when pinging another station connected to the same AP. Oh, another one is that the code becomes confused when it re-associates. It sends packets to the new AP through the old AP. Maybe you have an open AP around? Then I suggest that you set ESSID before bringing the interface up to avoid reassociation. And please don't be surprised if ESSID looks a bit too short before the interface is up. Anyway. maybe you have something different. It's quite frustrating to have two drivers for the hardware, one of which is pretty bad with the 802.11 implementation, and the other cannot setup the hardware (although I need to give bcm43xx_mac80211 another try). Both should be fixable. I just need to get some other stuff off my plate first. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [bcm43xx-users] 4311 still not receiving
On Fri, 2007-06-22 at 14:53 -0500, Larry Finger wrote: Pavel Roskin wrote: It's quite frustrating to have two drivers for the hardware, one of which is pretty bad with the 802.11 implementation, and the other cannot setup the hardware (although I need to give bcm43xx_mac80211 another try). Both should be fixable. I just need to get some other stuff off my plate first. It is also frustrating to have put as much effort into a project as we have and then get the kind of backbiting that you are exhibiting!! Larry, it must be a misunderstanding. I realize that softmac is not your code. You are doing a great job. I only regret that I don't have time to make patches for softmac, so that your driver can work better. The only two fixes that will have any future are (1) get bcm43xx-softmac switched over to mac80211 (which I am working on) or (2) fix bcm43xx-mac80211. We are not spending any time on SoftMAC. It is gone as soon as either of the steps above are working well enough. That's all great, and I don't want to discourage you from that. I was just trying to help somebody who is using the driver with softmac now. Maybe it was just a coincidence that I started hitting various softmac bugs as I saw that e-mail. Don't give me that SH*T about how much you have on your plate. In the past, I have dropped everything to help you get bcm43xx working. Obviously, that was a bad decision on my part. I should have just let you use ndiswrapper!!! I only mean I regret that I cannot accompany my complains with patches right now. Although I think I should. I do appreciate your help. I absolutely didn't mean anything bad towards you or the approach you are taking. Perhaps I should keep my frustrations to myself. Sorry if I offended you. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: TX power stuff confusion
Hello Brennan, Brennan Ashton wrote: I have the same card (on fedora), it is working great now that i used the new kernel and firmware code. kernel 2.6.22-rc4, dont use the 2.6.21.4kernel. It's the version from git, which should be newer than 2.6.22-rc4 and should include the new TX power adjustment code. When you update, make shure you go in menuconfig and select to install as a module, it's placement has changed and will not load with your old config file (third time compiling tonight). It is a module. And it's bcm43xx_mac80211, it case I was unclear. Hope you get that card working. It is working with bcm43xx. It was also working with bcm43xx_mac80211 is older kernels, but only with some APs and only with patches limiting the Tx rate. On 6/10/07, Pavel Roskin [EMAIL PROTECTED] wrote: On Sun, 2007-06-10 at 19:13 +0200, Michael Buesch wrote: I implemented the new stuff for the TX power adjustment and it seems to work fine. Good work on the specs! :) Please don't top post. If you put the original message to the bottom, it makes you miss important points. I was testing the new TX power adjustment, and my point was that the new code was emitting some messages. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: TX power stuff confusion
On Sun, 2007-06-10 at 19:13 +0200, Michael Buesch wrote: I implemented the new stuff for the TX power adjustment and it seems to work fine. Good work on the specs! :) I'm very glad about it! I checked out the current code http://bu3sch.de/git/wireless-dev.git and compiled it. First time the kernel would not even boot (Fedora is too smart to load all modules on startup), but I saw debugfs in the stck track. CONFIG_DEBUG_FS was disabled, so I enabled it. This time I could boot, but I saw some stack traces and messages you may want to see. This is the part of the kernel log starting with wireless initialization. It's going to be a busy week for me, so I don't expect to participate in debugging much, but I'm ready to send more information if needed. This is Fedora 7 x86_64 on Dell D-520 laptop with PCIe BCM4311. Thanks to everybody involved! Even if it's not working for me now, I'm sure it will work really soon. -- Regards, Pavel Roskin ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 244k freed Write protecting the kernel read-only data: 4124k ACPI: PCI Interrupt :0c:00.0[A] - GSI 17 (level, low) - IRQ 17 PCI: Setting latency timer of device :0c:00.0 to 64 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) ssb: Switching to ChipCommon core, index 0 ssb: Switching to PCI-E core, index 3 ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 bcm43xx_mac80211: Broadcom 4311 WLAN found ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Found PHY: Analog 4, Type 2, Revision 8 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_mac80211: Radio turned off wmaster0: Selected rate control algorithm 'simple' bcm43xx driver EXT3 FS on sda3, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. NTFS volume version 3.1. NTFS-fs warning (device sda2): load_system_files(): Unsupported volume flags 0x4000 encountered. NTFS-fs warning (device sda2): load_system_files(): Volume has unsupported flags set. Will not be able to remount read-write. Run chkdsk and mount in Windows. Adding 1020088k swap on /dev/sda5. Priority:-1 extents:1 across:1020088k bcm43xx_mac80211: Adding Interface type 2 ssb: Switching to PCI-E core, index 3 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Loading firmware version 371.1122 (2006-11-08 22:02:13) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: ERROR: invalid bband_att: 11 Call Trace: [8020a13c] restore_args+0x0/0x30 [88050b2d] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x4d/0xd0 [88050bef] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x3f/0x50 [88050d01] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x11/0x30 [88049f48] :bcm43xx_mac80211:bcm43xx_set_txpower_g+0x1c8/0x200 [8804a50a] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x10a/0x730 [88044aef] :bcm43xx_mac80211:bcm43xx_phy_write+0x6f/0x80 [8804ddfe] :bcm43xx_mac80211:bcm43xx_phy_initg+0xbfe/0xe70 [8804e5e1] :bcm43xx_mac80211:bcm43xx_phy_init+0x2a1/0x620 [8803f2b8] :bcm43xx_mac80211:bcm43xx_chip_init+0x448/0xa70 [8804e0e3] :bcm43xx_mac80211:bcm43xx_phy_early_init+0x73/0x2d0 [8804114f] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x26f/0x900 [8800c0a8] :mac80211:ieee80211_open+0x48/0x450 [880430a8] :bcm43xx_mac80211:bcm43xx_add_interface+0x108/0x140 [8800c23a] :mac80211:ieee80211_open+0x1da/0x450 [804861a0] dev_open+0x40/0x90 [8048406d] dev_change_flags+0x6d/0x160 [804c53d7] devinet_ioctl+0x587/0x750 [80485f39] dev_ioctl+0x2b9/0x390 [804c5a1d] inet_ioctl+0x5d/0x80 [80477dbf] sock_ioctl+0xbf/0x240 [8029b9c8] do_ioctl+0x38/0xe0 [8029bae3] vfs_ioctl+0x73/0x2c0 [8029bd7a] sys_ioctl+0x4a/0x80 [80209b9e] system_call+0x7e/0x83 bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 32-bit DMA initialized bcm43xx_mac80211: Wireless interface started bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0f:66:2f:ef
Re: Belkin Wireless PCMCIA F5D7010.
On Tue, 2007-05-29 at 21:42 +0200, Vincent Blondel wrote: Hello all, I am trying to make my brand new Belkin Wireless PCMCIA F5D7010 (Ver.7000df) working on a Debian/Etch distro with my laptop HP Omnibook 6000 but this goes wrong. There is a Windows driver on the Belkin site for this device, called F5D7010v7000.exe. In can be unpacked with unzip. The actual driver, called BLKWGNv7.sys has this string inside: Realtek RTL8185 driver I already tried lots of modules like rt2500, ndiswrapper, bcm43xx but it seems my card is not recognized. I think next stop should be http://rtl8180-sa2400.sourceforge.net/ There are also Linux hardware compatibility database(s). There are also mailing lists for all Linux wireless issues. Please avoid asking for help with identification in a mailing list for one specific driver without a good reason to assume that it's the driver you need. Can somebody help troubleshoot this problem, say me if this problem is solved by a new version ??? Not me. And not in this list. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.21.1 works with ifconfig; fails with ifup
Hello!
On Mon, 2007-05-07 at 19:04 -0700, Ehud Gavron wrote:
2.6.21.1 ifup eth1 panics and is repeatable.
I understand it's Fedora Core 6. /sbin/ifup should be a script. You
can trace it by running it as
bash -x /sbin/ifup eth1
Unfortunately I can't get netconsole working because the 2.6.21.1 kernel
doesn't like my hardwired Ethernet card for no good reason. TXcount
increases, RXcount does not. tcpdump shows nothing. Rebooting in
2.6.20-1.2948.fc6 restores full functionality.
That should go to netdev list or to a list specifically about that
driver. But I don't think netconsole is the best tool to debug other
networking drivers.
Please see Documentation/oops-tracing.txt in the Linux sources. If you
have serial console, please use it. If you can use local console,
that's the second best choice. Use dmesg -n 8 to enable all messages
on the console. Switch to the first virtual console by Ctrl-Alt-F1 if X
Window System is running. To maximize the number of lines, set the
smallest font, e.g.
setfont drdos8x8
Reproduce the panic and write down the messages. Or you can make a
photograph of the screen.
Documentation/oops-tracing.txt also suggests kdump. I haven't tried it,
but I think it would work.
If I do the following it works flawlessly:
ifconfig eth1 up
iwconfig eth1 key wep-key-here
iwconfig eth1 essid any (or real-essid-here)
ifconfig eth1 10.1.1.5 netmask 255.255.255.0
route add -net 0.0.0.0/0 gw 10.1.1.1
If I do the following I get a kernel panic:
ifup eth1
That's a clear sign that it's caused by something other that bringing
the interface up.
[EMAIL PROTECTED] ~]# more /etc/sysconfig/network-scripts/ifcfg-eth1
# Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller
TYPE=wireless
DEVICE=eth1
ONBOOT=no
BOOTPROTO=static
ADDRESS=10.1.1.5
NETMASK=255.255.255.255
GATEWAY=10.1.1.1
ESSID=wetwork
KEY=xxxa0055ae775e80fd864e
#RATE=24
#CHANNEL=6
This looks good.
While I can't use netconsole, I can use strace. Accordingly attached is
the output from
strace ifup eth1 nothing.txt 2output.txt
That's not very useful. The interesting stuff is done in other
processes. You could try to follow them by adding -f and -F flags.
But I think the first priority should be getting the kernel messages.
If anyone has any ideas what's wrong with the wired ethernet...
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752
Gigabit Ethernet PCI Express (rev 02)
Please ask in netdev.
If I don't get any better suggestions I'll remake oldconfig but answer N
to all the new stuff and see if that makes a difference. There are a
couple of new GE drivers, some experimental, and I'm guessing (with no
basis for the guess) that there may be interference there.
I would not change anything unless all possibilities for tracking down
the bug are exhausted. The bug can just disappear temporarily to appear
later.
access(/sbin/ip, X_OK)= 0
access(/sbin/ip, R_OK)= 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
_llseek(255, -1124, [9428], SEEK_CUR) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|
SIGCHLD, child_tidptr=0xb7f5d918) = 3400
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x807a8c0, [], 0}, {SIG_DFL}, 8) = 0
waitpid(-1,
Either it was /sbin/ip that triggered the crash, or the end of the log
wasn't written to the hard drive. Generally, the console is designed to
be more survivable than the storage devices in case of a panic, so using
the console is preferred.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Is mac80211 generally available for use with bcm43xx?
Hello! On Thu, 2007-05-03 at 13:53 -0600, Oscar A. Valdez wrote: Sorry to post to this list, but the support forum at http://bcm43xx.spugna.org/ is never up. I understand that the 11Mb/s limitation is imposed by softmac, and that the mac80211 module removes that limitation. I'm afraid you are wrong about it. In fact, the softmac based driver is supporting rates up to 54 Mbps, although 48 and 54 Mbps rates are not working well. 24 Mbps is working really well for me. There is no speed limitation in softmac. The limitations are hardware specific. The mac80211 based driver has some issues with power calibration, so it works better if the rate is limited. Larry posted a patch recently that makes the rate start at 1 Mbps and then go up if the connection is good. That helps a lot. Is the mac80211 module generally available for use with bcm43xx? If so, how? I've researched the matter, but haven't figured it out. Yes, the module is present in the wireless-dev git repository. It's not yet in any released version of Linux. I think it may go to 2.6.22, but I'm not sure. It's entirely possible that only those drivers will be submitted that are more stable and offer support to the hardware not supported otherwise. We'll find out very soon, when Linux 2.6.22-rc1 is released. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
PowerPC machine checks confirmed fixed
Hello! I've checked the sources from the mb branch, and I'm not getting the machine check on PowerPC anymore with the old bcm4306 card and bcm43xx_mac80211. Many thanks for fixing that! I also put a much bigger antenna on the card, and now it connects to the Linksys router. I wrote about that AP before. My x86_64 laptop with bcm4311 could connect to it with bcm43xx, but not with bcm43xx_mac80211. Now it's clear that the power is the issue, and not WEP, the maker of the router or anything else (although I did upgrade the firmware on the AP just in case - it's WRT54G rev 6). Automatic association code in mac80211 was another pleasant surprise. Perhaps I'll use bcm43xx_mac80211 by default - it seems quite stable now. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ieee80211: Output frequency rather than channel in scan results
Quoting Larry Finger [EMAIL PROTECTED]: In ieee80211, the output of scan results lists channels rather than frequencies; however, NetworkManager needs frequency. This patch changes the output from channel to frequency. The driver can report both, and I think it should. This would make the iwlist output a bit longer, but kernel drivers shouldn't be written to make userspace program generate pretty output. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
