Re: [PATCH V2] ssb: Implement virtual SPROM on disk
Michael Buesch wrote: On Monday 22 March 2010 22:56:44 Larry Finger wrote: Does anyone have any suggestions on what characteristic could be used to generate a unique MAC address for a box in a udev rule? /dev/urandom Yeah, there's the chance of clashes. In practice there won't be any clashes, however. If you think there's a real risk, you should start playing the lottery tomorrow. You'll immediately win a million dollars so you don't have to worry about those questions anymore. ;) In fact, I think the risk for mac clashes is not really reduced by generating the mac address from serial numbers, whatever, etc... DEC used the L3 address to encode a new MAC at the time the [L3] address was set (DECnet v4). The advantage was they didn't need to use the equivalent of ARP. Of course this is a violation of strict layer separation. Octet1-Octet3 - Broadcom assigned MAC IDs. I found the following: 00-05-B5 00-10-18 00-1B-E9 18-C0-86 Octet4-octet6 - Lowest three octets of the unixtime. Advantages: for the local area network all TZ settings should be the same, so the MAC addresses *will* be different. Beyond the first router that won't matter. Also for the same machine different interfaces are GUARANTEED to have different MAC addresses. For two machines to have the same MAC they would have to be booted at (same time x processing factor) such that the B43 initialization will result in the same MAC address. I'd like to think those odds are even lower than your lottery. A million dollars? http://www.active-domain.com/resources/million-dollar-domains.htm Yeah got the t-shirt. E smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43/b43legacy driver
David Montero wrote: Hi Rafal, I am sorry, what do you mean with "*stop* using html for your mails"? I am using my gmail account from internet, could you recommend me another way to use it? Yes, stop using gmail. Use a real mailer (thunderbird, mutt, etc.) and set it to use plain-text. Bottom-post (add text on the bottom of the previous text). It makes what you say fully readable for everyone who sees it. Very few people on the developer lists use HTML-readers. Regards, Ehud smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFC] ssb: Generic SPROM override for devices without SPROM
Larry Finger wrote: > On 11/20/2009 05:12 AM, Michael Buesch wrote: > >> This patch adds a generic mechanism for overriding the SPROM mechanism >> on devices without SPROM hardware. >> >> There currently is a major problem with this: >> It tries to deduce a MAC address from various hardware parameters. But >> currently it will result in the same MAC address for machines of the same >> type. Does somebody have an idea of some device-instance specific serial >> number or something similar that could be hashed into the MAC? >> > > You might look at the "root=" part of /proc/cmdline. Mine says > "root=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part1". That disk serial > number would certainly be unique. Even if it just said "root=/dev/sda1", it > would be repeatable. > > Larry > > How does WL do it? Broadcom *has* to generate a MAC address that is both unique and in its assigned range. If we can do the same thing in B43 that would be ideal. E > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFC 1/3] sdio: recognize io card without powercycle
Michael Buesch wrote: > On Monday 07 September 2009 20:59:45 Chris Ball wrote: > >> Hi Michael, >> >>> Please submit this to the SDIO maintainer. >> >> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM >> S: Orphan >> L: linux-...@vger.kernel.org >> F: drivers/mmc/ >> F: include/linux/mmc/ >> >> So, these patches are in the right place. >> > > So who is going to pick it up? Just sending them to a random list is not > going to magically merge them into the kernel. > > This wouldn't happen if you were more human. Did you see Stefanik crying at the bottom the stairway last night? E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Card
Peter Stuge wrote: > Clyde McPherson wrote: > >> How complete is the 80211A code? >> > > AFAIK not there at all. > > > //Peter > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > gav...@egxps:/home/kernels/2.6.30/rc5/drivers/net/wireless/b43$ grep 802\.11a main.c b43err(wl, "IEEE 802.11a devices are unsupported\n"); -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: F10 nightmare under control
This has nothing to do with bcm43xx. Stop polluting this list with your nonsense ramblings. E Arne Chr. Jorgensen wrote: > hi, > > Some got upset by an earlier post I had about the Fedora-10 nightmare, as I > sent ( much more than I was aware of ) some dmi-decode pages. > > Different networks ( cable/wireless ) cause some conflicts with other IO, > because of some mode-setting in the kernel. The worst trouble came with > the ev-dev, where the network conflicts made a finger on the touchpad > stop/start processes running. > > The meaning of my post, was just to give a tip to others with similar > problems. Some have reported problems with PCI-express networking cards > because of the kernel code ( my is 2.6.27.21-170.2.56.fc10.x86_64). > > I installed under textmode, and everything went wild when I started X, > not knowing that X and kernel will tamper with the networks. If I am not > making sense, then forgive me. > > At the moment, some of the issue seem only to affect certain video cards, > but the plan seems to be to add more. So, networks and other I/O will be > placed under some new control. > > //ARNE > - hopefully this may clear up my input. > > > -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fedora-10 nighmare-dmidecode
Arne Chr. Jorgensen wrote: > (CC: bcm43xx list, hope to be forgiven - it is working without cable now ;) > ... Thank you for polluting the bcm43xx-dev list. Your posting had nothing to do with anything covered on this list. Have a nice day, and feel free to respond quickly trying to explain how you're not responsible, or how because you asked to be forgiven it makes it okay, or how netiquette is for other people, or how illiteracy is really a problem with the people who notice it. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with 2.6.30-rc1
I had the same problem on my iwlagn notebook. This patch successfully
fixed that as well!
Thanks, Larry :)
Ehud
Larry Finger wrote:
> If you are having problems with wireless networking using 2.6.30-rc1 from
> Linus's Linux-2.6 git tree, the fix is the following (Note: This is _NOT_
> needed
> for wireless-testing!!!):
>
> ---
> Fix try_then_request_module to use waiting __request_module again.
>
> Signed-off-by: Andreas Schwab
> ---
> include/linux/kmod.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.30-rc1/include/linux/kmod.h
> ===
> --- linux-2.6.30-rc1.orig/include/linux/kmod.h2009-04-08
> 12:47:54.0 +0200
> +++ linux-2.6.30-rc1/include/linux/kmod.h 2009-04-08 17:39:35.0
> +0200
> @@ -34,7 +34,7 @@ extern int __request_module(bool wait, c
> #define request_module(mod...) __request_module(true, mod)
> #define request_module_nowait(mod...) __request_module(false, mod)
> #define try_then_request_module(x, mod...) \
> - ((x) ?: (__request_module(false, mod), (x)))
> + ((x) ?: (__request_module(true, mod), (x)))
> #else
> static inline int request_module(const char *name, ...) { return -ENOSYS; }
> static inline int request_module_nowait(const char *name, ...) { return
> -ENOSYS; }
>
>
--
Legal Disclaimer that you are now contractually bound to under all laws with no
recourse:
http://attrition.org/security/rants/z/disclaimers.html
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4315
The b43 team has come up with the specs but hasn't yet coded the driver to support that one. In the meantime check out www.myehud.com/mini9. It includes links on building wl from source, and patching it for 2.6.28 / 2.6.29 as appropriate. The from-source version is a TAD more reliable than the pure-binary that Ubuntu Intrepid (8.10) ships with. Ehud Ronan Paixão wrote: > Hi, > I've just bought a Dell Vostro 1310 laptop which appears to include a > BCM4315 chipset: > > $ lspci|grep Broad > 06:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev > 01) > > $ lspci -n|grep 43 > 06:00.0 0280: 14e4:4315 (rev 01) > > $ uname -a > Linux tachion 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 > GNU/Linux > > > Obviously even their device strings Broadcom can mess up. > > Anyway, currently I'm having many kernel panics (which don't generate > logs) and I suspect the culprit is the wl driver that I have to use > (supplied by Ubuntu 8.10) in order to get the card running. > > The b43 driver doesn't appear to support my card, but I have no idea on > how to code drivers. Can I be of any help for someone who knows? > > Ronan > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY reverse engineering progress
pidgin :) (hands down) E Larry Finger wrote: > Michael Buesch wrote: > >> Thanks a lot. That's very nice. I'm interested in implementing the stuff >> and I already started to implement the existing specs stuff. >> I'm interested to get the Asus WL500Gv2 working, which has an LP-PHY. >> >> Thanks again for your hard work on the specs. >> It seems there are a few things I don't quite understand, yet. Is it best >> to use private mail to you to ask some questions, or are you planning to join >> the #bcm-specs IRC channel, so I can ask questions there. I prefer the IRC >> channel, but I fully accept, if you don't like that and prefer mail. >> The reason I prefer IRC is that it usually has less communication delays and >> allows "quick questions". >> > > > I've never used IRC, but I certainly am willing to try. What IRC > client do you recommend? > > Larry > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Lorenzo Nava wrote: > Yes, you're right. Actually there are 2 ways to make firmware works: > 1) Disable hw crypto with module parameter > 2) Remove pcm5.fw from your /lib/firmware/b43 directory > > When I run the firmware I never include pcm5.fw file. The only > initvals really necessary are b0g0bsinitvals.fw and b0g0bsinitvals.fw. > Pardon me, but those filenames are identical and contain no numbers. Did those get stripped off somewhere? > cheers > > Lorenzo > Larry Finger had written: >> Great job. >> >> Larry >> >> Absolutely Ehud -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [BCM4312][kernel 2.6.27] - wireless fails after X starts
Yuval Hager wrote: > Yes, It's a brand new HP Mini 2133 (HP product number FU346EA). > the power supply is ok, and this problem is recreated exactly the same every > time. wireless works correctly as long as I don't start X (or maybe it's KDE > trying to reset something when it loads?) > I booted Vista once (that came with the machine) and everything was working > fine, so I assume the hardware is ok (but I don't have vista anymore). > > Yuval, what happens if you # modprobe -r b43 && sleep 1 && modprobe b43 ? Ehud -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 STILL randomly and silently dropping connections...
KURT PETERS wrote: > I still have the same problem here as well... except that I just went to > 2.6.27.2 and still get the same problem. Last night, it seemed like my > laptop (with 4306 using the b43legacy driver) actually took down my entire > wireless network. What does "laptop actually took down my entire wireless network" mean? Does it mean that nothing could connect to your network? That sounds more like an AP issue to me. > It could have been a coincidence, but it was trying. > Yes you are very trying but what does it all mean? > Kurt > Ehud > Message: 2 > Date: Wed, 22 Oct 2008 08:51:43 -0400 > From: "John W. Linville" <[EMAIL PROTECTED]> > Subject: Re: B43 STILL randomly and silently dropping connections... > To: Jerry McBride <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], bcm43xx-dev@lists.berlios.de, > [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > I've seen this message a couple of times -- I'm a bit surprised that > you haven't been getting a response. I am Cc'ing Michael and the > bcm43xx mailing list just in case they haven't noticed this message. > > John > > On Wed, Oct 22, 2008 at 06:48:55AM -0400, Jerry McBride wrote: > > > > The story is... > > > > I've moved from 2.6.25.x using BCM43XX with a Broadcom 4306 (rev3) 802.11 > > chipset to 2.6.26.6 using the B43 and appropriate firmware. This on a > COMPAQ > > Presario R3000 P4 and a gig of memory and ATI graphics. > > > > I followed the install (upgrade) directions at linuxwireless.org. Piece > of > > cake! However... I find that I've gone from "bulletproof" BCM43XX wifi > > connections to "bullethole" connections with B43. > > > > Under the old BCM43XX the handshake and connections were flawless and > > unfaltering. Now with the new B43, handshakes with AP's are perfect, but > the > > connections randomly and silently fail. There are no debug messages, no > > complaints what-so-ever in /var/log/messages... > > > > To gt wireless back, I have to reinitialize the connection. I've gotten > so > > good at it, that I can recite by heart the appropriate commands... > > > > It's killling me! I've got to get this ironed out... it's not just my > laptop, > > it's happening quite regularly with people I know with similar chips and > > laptops. > > > > Trying 2.6.27-rc's and now 2.6.27 and the situation is no better. > > > > So I ask... Who is the B43/B43LEGACY maintainer and would you be > interested in > > debugging this mess? I'll bend over backward to help you... Email me > > direct... I'm very willing. > > > > SHORT STORY: > > -- Kernel 2.6.25.x with BCM43XX, firmware 4.80.53.0.. just perfect. > > > > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: huge softirq while using wlan0
Could you guys take it to a list that's relevant? Thanks E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: huge softirq while using wlan0
Brian J. Murrell wrote: > On Sat, 2008-10-18 at 19:24 -0700, [EMAIL PROTECTED] wrote: > >> Since you're running a custom distro for a particular branch of >> hardware, have you communicated on their lists about this issue? >> > > Not yet. I thought I would come to the source first. The larger > concentration of experience with b43 is likely here rather than the > OpenWrt developers don't you think? > No. > >> The standard b43 has no issues with it, but I have no idea which version >> of b43 they've picked to be their reference. >> > > http://www.orbit-lab.org/kernel/compat-wireless-2.6/2008/08/compat-wireless-2008-08-06.tar.bz2 > That's nice, thank you. > >> From the firmware rev I suspect it's not a fairly recent one meaning >> the codebase isn't the newest either. >> > > Firmware appears to be from broadcom-wl 4.150.10.5 > Looks correct according to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware > >> In any case, you're on an embedded device running a kernel you didn't >> compile >> > > I sure did! > > >> and whose version you don't mention >> > > 2.6.25.17 > Thanks :) > >> and a driver you didn't build in an environment which I'm guessing you >> also don't build. >> > > Wrong and wrong. All built from source here. > > Awesome. >> Let me know if I've erred on any of my assumptions. >> > > As above. > > Awesome. Thanks for the info. >> For instance if >> you're able to build your own drivers and install >> them on that Linksys, or if you're able to build your own kernels that >> work on that Linksys, those would be two good things >> to know. >> > > Indeed, I can. > > You've got the 2.6.25 code running with the latest firmware. There have been some changes. Can you try and pull the b43 code from the current 2.6.27.1 distro and see if it will run? There's also the wireless-compat tree, but I would try the vanilla 2.6.27.1 tree first. >> If not, talk to OpenWRT. >> > > I may end up doing that. My query here was merely to ascertain whether > what I am seeing is consistent with the current revision of the b43 > driver or not. I believe I am understanding that it is not and that > others are able to run the b43 driver in AP mode with WPA2 encryption > and not having the encryption done in software -- or have high level of > interrupts otherwise. > You are correct. > >> Regards and a good weekend to you, sir, >> > > And you. > > Cheers, > b. > I think you're on the right track. Just fyi (and please take this without insult) had you included your kernel (uname -a) as well as "I built this myself from source from ") it would have made it easier to provide more useful suggestions in the first cut. I think you can make it work. The hardware DOES does do what you want. I suspect either b43 or mac80211 is not as up to date as it ought to be in your newly built kernel. Others know more. I'm just waiting for Shanghai F1 ;) Cheers, Ehud > > > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: to few loop tries in do_dummy_tx
Michael Buesch wrote: > On Tuesday 30 September 2008 07:50:34 Peter Stuge wrote: > >> Larry Finger wrote: >> Which specs? >>> The ones generated by the reverse engineers. See >>> http://bcm-v4.sipsolutions.net/. >>> >> Nice work, but as it's a spec of another driver implementation rather >> than hardware (or even the firmware API) I don't think it should be >> so authoritative. If other values are clearly better why not use >> them? >> > > What crap are you smoking? > The b43 and b43-legacy driver are _based_ on these specifications. > There are no other specs available. > > If I understand him correctly he's suggesting that there could be BETTER values than those used by the reference driver. In other words, yes, B43/B43-Legacy are based on the RE of the Windows driver but perhaps there are better values that improve behavior beyond that of the original driver. He didn't say the following but I will: It's also true that there are edge cases that RE won't catch without repeated arduous testing in adverse conditions, and there may be code in the reference driver that will therefore won't end up in the specs. This means that behavioral improvements and/or performance gains in B43/B43-Legacy that can be gained without getting into those edge cases are worthy of consideration (or maybe specially labeled code). Just my two farthings worth. E -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [update] Asus 138G v2
Mark Hagger wrote: > On Thu, 2008-09-11 at 04:26 -0700, [EMAIL PROTECTED] wrote: > >> This is not about helicopters, but I just want you to know that I'm >> selling my TigerHawke Raptor 60, and it works out of the box (RTF). So >> I'm not interested in Bell 222 mockups that look like Airwolf Anymore ... > > I don't believe you, next you'll be saying that a helicopter that can do > Mach 2 isn't theoretically possible. > > Mark > > The differing speed between the leading edge and a trailing edge of a rotating aerofoil where not only is the difference in excess of the speed of Sound (sonic boom) but the Cyclick may encounter a sonic boom on the control surfaces during normal maneoeuvers depending on V-x where V is the absolete speed in a vector and x is the speed back or sideways such that the speed of Sound is crossed. A rotatry wing was not constructed for that. So to answer your comment, if you can get a rotary winng to Mach 1 you can get it to Mach 2. In fact if you have a SUFFICCIENTLY SLOW rotary wing, you SCRAMjet it to MACH2+, and then the trailing edge will still be higher than mach 1 so you'll be ok. Back to b43 it is. Ehud > > This email has been scanned for all known viruses by the MessageLabs SkyScan > service. > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [update] Asus 138G v2
> This is not about b43 drivers, but I just want you to know that I bought D- > Link DWA-520 and it work out of box with Kubunu8.04 hardy. So I'm not > interested in Asus 138G v2 anymore. This is not about helicopters, but I just want you to know that I'm selling my TigerHawke Raptor 60, and it works out of the box (RTF). So I'm not interested in Bell 222 mockups that look like Airwolf Anymore. Aw, who am I kidding. Yeah, bring on a turbine-powered Airwolf. Ehud P.S. There is no technical content relating to b43 in this posting. I apologize profusely in advance. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43legacy: Fix to enhance TX speed
Recent changes in the specifications have improved the performance
of the BCM4306/2 devices that use b43legacy as the driver. These
"errors" in the specs have been present from the very first implementation
of bcm43xx.
Signed-off-by: Ehud Gavron <[EMAIL PROTECTED]>
Tested-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This is 2.6.28.material.
Ehud
---
Index: linux-2.6/drivers/net/wireless/b43legacy/phy.c
===
--- linux-2.6.orig/drivers/net/wireless/b43legacy/phy.c
+++ linux-2.6/drivers/net/wireless/b43legacy/phy.c
@@ -595,12 +595,14 @@ static void b43legacy_phy_initb5(struct
0x0035) & 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x000A);
+ b43legacy_phy_write(dev, 0x5B, 0x);
+ b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev->bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
- B43legacy_PHY_RADIO_BITFIELD) | (1 << 11));
+ B43legacy_PHY_RADIO_BITFIELD) | (1 << 12));
if (phy->analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -753,7 +755,7 @@ static void b43legacy_phy_initb6(struct
b43legacy_radio_write16(dev, 0x0050, 0x0020);
}
if (phy->radio_rev <= 2) {
- b43legacy_radio_write16(dev, 0x007C, 0x0020);
+ b43legacy_radio_write16(dev, 0x0050, 0x0020);
b43legacy_radio_write16(dev, 0x005A, 0x0070);
b43legacy_radio_write16(dev, 0x005B, 0x007B);
b43legacy_radio_write16(dev, 0x005C, 0x00B0);
@@ -771,7 +773,7 @@ static void b43legacy_phy_initb6(struct
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
- if (phy->radio_rev <= 5)
+ if (phy->radio_rev == 4 || phy->radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x0003);
if (phy->radio_rev <= 2)
@@ -1010,7 +1012,7 @@ static void b43legacy_phy_initg(struct b
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
- if (phy->rev >= 2 || phy->gmode)
+ if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1025,18 +1027,22 @@ static void b43legacy_phy_initg(struct b
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
- if (phy->rev >= 2 || phy->gmode) {
+ if (phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
- if (tmp == 3 || tmp == 5) {
+ if (tmp == 3) {
+ b43legacy_phy_write(dev, 0x04C2, 0x1816);
+ b43legacy_phy_write(dev, 0x04C3, 0x8606);
+ }
+ if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
- if (tmp == 5)
- b43legacy_phy_write(dev, 0x04CC,
- (b43legacy_phy_read(dev,
-0x04CC) & 0x00FF) |
-0x1F00);
+ b43legacy_phy_write(dev, 0x04CC,
+ (b43legacy_phy_read(dev,
+0x04CC) & 0x00FF) |
+0x1F00);
}
- b43legacy_phy_write(dev, 0x047E, 0x0078);
+ if (phy->rev >= 2)
+ b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
b43legacy_phy_write(dev, 0x0801, b43legacy_phy_read(dev, 0x0801)
@@ -1078,7 +1084,7 @@ static void b43legacy_phy_initg(struct b
else
b43legacy_phy_write(dev, 0x002F, 0x0202);
}
- if (phy->gmode || phy->rev >= 2) {
+ if (phy->gmode) {
b43legacy_phy_lo_adjust(dev, 0);
b43legacy_phy_write(dev, 0x080F, 0x8078);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>>
>> Try #5:
>> # diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
>> --- /tmp/phy.c2008-09-06 15:13:33.0 -0700
>
> This one is pretty close, but I think you missed a change at line 16a
> of B6PHY.
>
> One other thing - use the -uNp switch for diff.
>
> Larry
>
T6:
# diff -uNp /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
17:40:20.0 -0700
@@ -595,12 +595,14 @@ static void b43legacy_phy_initb5(struct
0x0035) & 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x000A);
+b43legacy_phy_write(dev, 0x5B, 0x);
+b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev->bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
-B43legacy_PHY_RADIO_BITFIELD) | (1 << 11));
+B43legacy_PHY_RADIO_BITFIELD) | (1 << 12));
if (phy->analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -753,7 +755,7 @@ static void b43legacy_phy_initb6(struct
b43legacy_radio_write16(dev, 0x0050, 0x0020);
}
if (phy->radio_rev <= 2) {
-b43legacy_radio_write16(dev, 0x007C, 0x0020);
+b43legacy_radio_write16(dev, 0x0050, 0x0020);
b43legacy_radio_write16(dev, 0x005A, 0x0070);
b43legacy_radio_write16(dev, 0x005B, 0x007B);
b43legacy_radio_write16(dev, 0x005C, 0x00B0);
@@ -771,7 +773,7 @@ static void b43legacy_phy_initb6(struct
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
-if (phy->radio_rev <= 5)
+if (phy->radio_rev == 4 || phy->radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x0003);
if (phy->radio_rev <= 2)
@@ -1010,7 +1012,7 @@ static void b43legacy_phy_initg(struct b
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1025,17 +1027,22 @@ static void b43legacy_phy_initg(struct b
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev >= 2 || phy->gmode) {
+if (phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) & 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) & 0x00FF) |
+0x1F00);
}
+}
+if (phy->rev >= 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
@@ -1078,7 +1085,7 @@ static void b43legacy_phy_initg(struct b
else
b43legacy_phy_write(dev, 0x002F, 0x0202);
}
-if (phy->gmode || phy->rev >= 2) {
+if (phy->gmode) {
b43legacy_phy_lo_adjust(dev, 0);
b43legacy_phy_write(dev, 0x080F, 0x8078);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>>
>>
>> Larry Finger wrote:
>>> [EMAIL PROTECTED] wrote:
I haven't tried a build yet, but please let me know if I'm on the
right track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev > 5) {
+if (phy->rev >= 3) {
>>>
>>> AFAIK, this change is an error in the specs. I have since changed
>>> it. Sorry I didn't catch it earlier.
>>>
>>> Otherwise, this patch seems to be correct. All you need now are the
>>> fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
>>>
>>> Larry
>>
>> Ok, I've re-looked at the specs and made the appropriate
>> corrections. I've also gone through all of the PHY specs and found
>> one other correction. It's enclosed below for review.
>>
>> Where do I go to find the stuff for ...initb5() and ...initb6()?
>
> That one was also an error in the specs - fixed now.
>
> On the V3 specifications site, click on the RecentChanges button and
> select B5PHY and B6PHY to get the specs for the other routines. I
> rechecked the specs, and all agree with my current (revised) routines.
>
>
> Larry
Try #5:
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
17:24:29.0 -0700
@@ -595,12 +595,14 @@
0x0035) & 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x000A);
+b43legacy_phy_write(dev, 0x5B, 0x);
+b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev->bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
-B43legacy_PHY_RADIO_BITFIELD) | (1 << 11));
+B43legacy_PHY_RADIO_BITFIELD) | (1 << 12));
if (phy->analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -771,7 +773,7 @@
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
-if (phy->radio_rev <= 5)
+if (phy->radio_rev == 4 || phy->radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x0003);
if (phy->radio_rev <= 2)
@@ -1010,7 +1012,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1025,17 +1027,22 @@
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev >= 2 || phy->gmode) {
+if (phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) & 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) & 0x00FF) |
+0x1F00);
}
+}
+if (phy->rev >= 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
@@ -1078,7 +1085,7 @@
else
b43legacy_phy_write(dev, 0x002F, 0x0202);
}
-if (phy->gmode || phy->rev >= 2) {
+if (phy->gmode) {
b43legacy_phy_lo_adjust(dev, 0);
b43legacy_phy_write(dev, 0x080F, 0x8078);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>> I haven't tried a build yet, but please let me know if I'm on the
>> right track.
>>
>> E
>> # diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
>> --- /tmp/phy.c2008-09-06 15:13:33.0 -0700
>> +++ drivers/net/wireless/b43legacy/phy.c2008-09-06
>> 15:54:03.0 -0700
>> @@ -1010,7 +1010,7 @@
>> b43legacy_phy_initb5(dev);
>> else
>> b43legacy_phy_initb6(dev);
>> -if (phy->rev >= 2 || phy->gmode)
>> +if (phy->rev >= 2 && phy->gmode)
>> b43legacy_phy_inita(dev);
>>
>> if (phy->rev >= 2) {
>> @@ -1021,21 +1021,26 @@
>> b43legacy_phy_write(dev, 0x0811, 0x);
>> b43legacy_phy_write(dev, 0x0015, 0x00C0);
>> }
>> -if (phy->rev > 5) {
>> +if (phy->rev >= 3) {
>
> AFAIK, this change is an error in the specs. I have since changed it.
> Sorry I didn't catch it earlier.
>
> Otherwise, this patch seems to be correct. All you need now are the
> fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
>
> Larry
Ok, this one applies changes to the PHY, B5PHY, and B6PHY changes.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
17:13:31.0 -0700
@@ -595,12 +595,14 @@
0x0035) & 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x000A);
+b43legacy_phy_write(dev, 0x5B, 0x);
+b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev->bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
-B43legacy_PHY_RADIO_BITFIELD) | (1 << 11));
+B43legacy_PHY_RADIO_BITFIELD) | (1 << 12));
if (phy->analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -771,7 +773,7 @@
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
-if (phy->radio_rev <= 5)
+if (phy->radio_rev == 4 || phy->radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) & 0xFF80) | 0x0003);
if (phy->radio_rev <= 2)
@@ -1010,7 +1012,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1025,17 +1027,22 @@
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev >= 2 || phy->gmode) {
+if (phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) & 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) & 0x00FF) |
+0x1F00);
}
+}
+if (phy-->rev >= 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
@@ -1092,7 +1099,7 @@
*/
b43legacy_nrssi_hw_update(dev, 0x);
b43legacy_calc_nrssi_threshold(dev);
-} else if (phy->gmode || phy->rev >= 2) {
+} else if (phy->gmode) {
if (phy->nrssi[0] == -1000) {
B43legacy_WARN_ON(phy->nrssi[1] != -1000);
b43legacy_calc_nrssi_slope(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>> I haven't tried a build yet, but please let me know if I'm on the
>> right track.
>>
>> E
>> # diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
>> --- /tmp/phy.c2008-09-06 15:13:33.0 -0700
>> +++ drivers/net/wireless/b43legacy/phy.c2008-09-06
>> 15:54:03.0 -0700
>> @@ -1010,7 +1010,7 @@
>> b43legacy_phy_initb5(dev);
>> else
>> b43legacy_phy_initb6(dev);
>> -if (phy->rev >= 2 || phy->gmode)
>> +if (phy->rev >= 2 && phy->gmode)
>> b43legacy_phy_inita(dev);
>>
>> if (phy->rev >= 2) {
>> @@ -1021,21 +1021,26 @@
>> b43legacy_phy_write(dev, 0x0811, 0x);
>> b43legacy_phy_write(dev, 0x0015, 0x00C0);
>> }
>> -if (phy->rev > 5) {
>> +if (phy->rev >= 3) {
>
> AFAIK, this change is an error in the specs. I have since changed it.
> Sorry I didn't catch it earlier.
>
> Otherwise, this patch seems to be correct. All you need now are the
> fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
>
> Larry
Ok, I've re-looked at the specs and made the appropriate corrections.
I've also gone through all of the PHY specs and found one other
correction. It's enclosed below for review.
Where do I go to find the stuff for ...initb5() and ...initb6()?
Thanks
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
16:42:40.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1025,17 +1025,22 @@
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev >= 2 || phy->gmode) {
+if (phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) & 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) & 0x00FF) |
+0x1F00);
}
+}
+if (phy-->rev >= 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
@@ -1092,7 +1097,7 @@
*/
b43legacy_nrssi_hw_update(dev, 0x);
b43legacy_calc_nrssi_threshold(dev);
-} else if (phy->gmode || phy->rev >= 2) {
+} else if (phy->gmode) {
if (phy->nrssi[0] == -1000) {
B43legacy_WARN_ON(phy->nrssi[1] != -1000);
b43legacy_calc_nrssi_slope(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>>
>>
>>
>> Ok, here's try #2.
>> E
...
>
> This hunk does not match the specs. In addition, I think there are too
> many right-hand curly braces for it to compile.
>
> Larry
>
I haven't tried a build yet, but please let me know if I'm on the right
track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev > 5) {
+if (phy->rev >= 3) {
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy->rev >= 2 || phy->gmode) {
+if (phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) & 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) & 0x00FF) |
+0x1F00);
}
+}
+if (phy-->rev >= 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>>
>>
>>
>> Ok, here's try #2.
>> E
>> /home/2.6.27/rc4-wl/drivers/net/wireless/b43legacy# diff -uN
>> /tmp/phy.c phy.c
>> --- /tmp/phy.c2008-09-05 21:56:20.0 -0700
>> +++ phy.c2008-09-05 22:03:28.0 -0700
>
> For kernel patches, you need to be working in the base directory of
> the kernel sources. For your tree, that would be in
> /home/2.6.27/rc4-wl. That way the patches will apply with the
> effective command of 'patch -p1 < patch_file'. For kernel patches, I
> use quilt so that patches are easy to apply and remove.
>
>> @@ -1010,7 +1010,7 @@
>> b43legacy_phy_initb5(dev);
>> else
>> b43legacy_phy_initb6(dev);
>> -if (phy->rev >= 2 || phy->gmode)
>> +if (phy->rev >= 2 && phy->gmode)
>> b43legacy_phy_inita(dev);
>>
>> if (phy->rev >= 2) {
>
> The above hunk is correct.
>
>> @@ -1027,15 +1027,17 @@
>> }
>> if (phy->rev >= 2 || phy->gmode) {
>
> This does not match step 7 of the specs. It was not changed recently,
> but the code did not match what was on the web site. No, I don't know
> why.
>
>> tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
>> -if (tmp == 3 || tmp == 5) {
>> +if (tmp == 4 || tmp == 5) {
>> b43legacy_phy_write(dev, 0x04C2, 0x1816);
>> -b43legacy_phy_write(dev, 0x04C3, 0x8006);
>> +b43legacy_phy_write(dev, 0x04C3, 0x8606);
>> if (tmp == 5)
>> b43legacy_phy_write(dev, 0x04CC,
>> (b43legacy_phy_read(dev,
>> 0x04CC) & 0x00FF) |
>> 0x1F00);
>> }
>> +}
>> +if (phy->rev >= 2)
>> b43legacy_phy_write(dev, 0x047E, 0x0078);
>> }
>> if (phy->radio_rev == 8) {
>
> This hunk does not match the specs. In addition, I think there are too
> many right-hand curly braces for it to compile.
>
> Larry
>
I've been sitting on a git clone that refuses to proceed faster than 6
KiB/s (it's a problem here in Melbourne). Should it complete I will
correct these issues. I did see several other ways in which the code
does not match the specs. Should that be documented in the code or
should the code be conformed to the specs even if that ends up breaking
the driver?
Without getting into specifics it's cases where the specs will say "When
something=value" but the code says "when variable >=(value -1)".
Ehud
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Is this close?
E
--- /tmp/phy_g.c2008-09-05 21:06:57.0 -0700
+++ phy_g.c2008-09-05 21:36:18.0 -0700
@@ -2198,7 +2198,7 @@
else
b43_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43_phy_inita(dev);
if (phy->rev >= 2) {
@@ -2216,9 +2216,9 @@
if (phy->gmode || phy->rev >= 2) {
tmp = b43_phy_read(dev, B43_PHY_VERSION_OFDM);
tmp &= B43_PHYVER_VERSION;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 4 || tmp == 5) {
b43_phy_write(dev, B43_PHY_OFDM(0xC2), 0x1816);
-b43_phy_write(dev, B43_PHY_OFDM(0xC3), 0x8006);
+b43_phy_write(dev, B43_PHY_OFDM(0xC3), 0x8606);
}
if (tmp == 5) {
b43_phy_write(dev, B43_PHY_OFDM(0xCC),
@@ -2226,7 +2226,7 @@
& 0x00FF) | 0x1F00);
}
}
-if ((phy->rev <= 2 && phy->gmode) || phy->rev >= 2)
+if ((phy->rev >=2)
b43_phy_write(dev, B43_PHY_OFDM(0x7E), 0x78);
if (phy->radio_rev == 8) {
b43_phy_write(dev, B43_PHY_EXTG(0x01),
Larry Finger wrote:
> I recently found some places where the G-PHY initialization
> specifications were wrong. I updated the relevant parts of the V3
> specifications at http://bcm-specs.sipsolutions.net - the pages for
> GPHY, B6PHY and B5PHY were changed.
>
> When I prepared a patch containing these changes, the speed of the
> BCM4306/2 for OFDM rates more than doubled. As an example, when
> iwconfig is used to set the rate at 36M, the TX rate increased from
> 6.8 to 15.8 Mb/s.
>
> Unfortunately, direct submission of my patch would violate the
> clean-room rules. Michael Buesch has other things that are more
> important. As a result, we need someone to look at the changes on the
> web page and prepare a patch for submission. I will be happy to test
> your submission.
>
> Larry
> ___
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
> [EMAIL PROTECTED] wrote:
>> Is this close?
>> E
>>
>
> It is close, but I think you are working on b43. My changes are for
> b43legacy and all changes will be in drivers/net/wireless/b43legacy/phy.c
>
> Larry
Ok, here's try #2.
E
/home/2.6.27/rc4-wl/drivers/net/wireless/b43legacy# diff -uN /tmp/phy.c
phy.c
--- /tmp/phy.c2008-09-05 21:56:20.0 -0700
+++ phy.c2008-09-05 22:03:28.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy->rev >= 2 || phy->gmode)
+if (phy->rev >= 2 && phy->gmode)
b43legacy_phy_inita(dev);
if (phy->rev >= 2) {
@@ -1027,15 +1027,17 @@
}
if (phy->rev >= 2 || phy->gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) & 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
-b43legacy_phy_write(dev, 0x04C3, 0x8006);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
if (tmp == 5)
b43legacy_phy_write(dev, 0x04CC,
(b43legacy_phy_read(dev,
0x04CC) & 0x00FF) |
0x1F00);
}
+}
+if (phy->rev >= 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy->radio_rev == 8) {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add LP-PHY template
Michael Buesch wrote: > On Saturday 30 August 2008 11:28:05 [EMAIL PROTECTED] wrote: > >> Michael Buesch wrote: >> >>> ... >>> + >>> + THIS IS BROKEN AND DOES NOT WORK YET. >>> + >>> + SAY N. >>> + >>> # This config option automatically enables b43 LEDS support, >>> # if it's possible. >>> config B43_LEDS >>> bool >>> depends on B43 && MAC80211_LEDS && (LEDS_CLASS = y || LEDS_CLASS = B43) >>> default y >>> >> Michael, shouldn't >> >> default y >> be >> default n >> > > no. This option will be auto-yes, if the dependencies are fulfilled. > auto-no otherwise. > > > Thank you for the quick response. I will seek to discover how to never set "broken" ;) Regards Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add LP-PHY template
Michael Buesch wrote: > ... > + > + THIS IS BROKEN AND DOES NOT WORK YET. > + > + SAY N. > + > # This config option automatically enables b43 LEDS support, > # if it's possible. > config B43_LEDS > bool > depends on B43 && MAC80211_LEDS && (LEDS_CLASS = y || LEDS_CLASS = B43) > default y Michael, shouldn't default y be default n ? Ehud Melbourne Australia[r] P.S. I took John and linux-wireless off my reply because it's tangential and if you don't agree then the less that get hassled the better. I'm also in a bandwidth-limited hotel and didn't want to reproduce the whole post to comment on [something as tangential] Kconfig ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFC/RFT] b43: Improve TX power recalculation under load
Michael Buesch wrote: On Monday 25 August 2008 21:54:18 Michael Buesch wrote: The patch is available here: http://bu3sch.de/patches/wireless-testing/20080825-2146/patches/004-b43-NEW-rewrite-txpower-adjusting.patch Here's an updated version with a major bug fixed: http://bu3sch.de/patches/wireless-testing/20080825-2227/patches/004-b43-NEW-rewrite-txpower-adjusting.patch iperf, wget, speedtest.net, and sftp all show similar performance. Ehud 0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) Subsystem: Dell Wireless 1390 WLAN Mini-Card Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at ecffc000 (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 IRQ 0 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel [EMAIL PROTECTED]:~# uname -a Linux egdell 2.6.27-rc3-20080825-wl #1 SMP Mon Aug 25 14:08:15 MST 2008 x86_64 GNU/Linux [EMAIL PROTECTED]:~# dmesg | grep b43 b43-pci-bridge :0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 b43-pci-bridge :0c:00.0: setting latency timer to 64 b43-phy0: Broadcom 4311 WLAN found b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 input: b43-phy0 as /class/input/input8 firmware: requesting b43/ucode5.fw firmware: requesting b43/pcm5.fw firmware: requesting b43/b0g0initvals5.fw firmware: requesting b43/b0g0bsinitvals5.fw b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) b43-phy0 debug: Chip initialized b43-phy0 debug: 32-bit DMA initialized Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 b43-phy0: Radio turned on by software b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff b43-phy0 debug: Removing Interface type 2 b43-phy0 debug: Wireless interface stopped b43-phy0 debug: DMA-32 rx_ring: Used slots 32/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0 debug: DMA-32 tx_ring_AC_BE: Used slots 128/128, Failed frames 42/41538 = 0.1%, Average tries 1.24 b43-phy0 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0 debug: DMA-32 tx_ring_AC_VO: Used slots 2/128, Failed frames 0/86 = 0.0%, Average tries 1.00 b43-phy0 debug: DMA-32 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 input: b43-phy0 as /class/input/input9 b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) b43-phy0 debug: Chip initialized b43-phy0 debug: 32-bit DMA initialized Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Progress in open source firmware stopped?
What kind of things? Are they baked goods? Do they have sugar on top? Don't keep us in suspense. Ehud Michael Buesch wrote: > On Tuesday 19 August 2008 08:32:27 Rafał Miłecki wrote: > >> Checking your git Michael at >> http://bu3sch.de/gitweb?p=b43-ucode.git;a=summary >> I can see last update on 2008-07-22. >> >> Just wanted to ask about status of this open source firmware. Are you >> going to develop this anymore? Is there some problem stopping >> development? Or you are simply little busy to work on it? >> > > I'm busy with other things > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311
Works fine here. iperf same results as prior to patch. b43-phy0: Broadcom 4311 WLAN found b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 2.6.27-rc2-wl on Ubuntu 8.04 (don't even ask how long it takes to build a new kernel and create a debian package and install it...) Ehud Michael Buesch wrote: > This is the first part for the rewrite of the b43 PHY API. > This is needed in order to make development of N and LP code possible. > > PLEASE TEST TEST TEST TEST TEST > > Lots of testing on lots of different devices is needed to ensure this > doesn't introduce regressions due to typos. > 95% of the patch just moves large parts of the PHY code from one file > to another. More move-patches will follow. > 5% of the patch introduces an "ops" based PHY API. > > Please test on all of your devices. > > http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch > Apply against wireless-testing.git > > (Not attached to the mail, as it is really big) > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Some help with understanding iperf... please?
This isn't a strictly b43 thing, but since so many of the developers regularly use iperf for testing I thought I'd get some of your expertise on something which has been baffling me for two weeks, and which appears to make no sense. When testing a metropolitan-Ethernet link the following was repeatably observed. (Repeatably means over several test days with different test laptops and each test repeated 5+ times in either direction and bidirectionaly) This is supposed to be 100Mbps bridged Ethernet so numbers around 90Mbps are fine. Unidirectionally the links check out fine: A->B 90Mbps B->A 90Mbps Bidirectionally one of them is slow: A<-=>B (A: iperf -s B: iperf -c A -d) A->B 86MbpsB-A> 55Mbps B<-=>A (A: iperf -c B -dB: iperf -s) A->B 86MbpsB-A> 55Mbps (yes, that's right, with client/server flipped the B->A side is still the slow one) Thinking this clearly indicated a lack of bandwidth on the return leg (B->A) we've been working with the carrier. However, today, for the sake of further testing, I moved the testset to the local LAN separated only by gigabit switches and both A and B on 100Mbps FDX ports. I got the same test results. I then downloaded tcpperf, which claims to be a very simple test used for simulation modeling (perfect!) from http://wand.cs.waikato.ac.nz/~stj2/nsc/software.html and ran it. tcpperf showed 90Mbps A->B, B->A and A<->B This leaves me with two baffling questions: 1. What am I doing wrong with iperf? 2. Why is it the B->A path is always the one that suffers in the bidirectional test no matter who is acting as client and who is acting as server? I spent hours yesterday and today googling everything iperf and bidirectional, and then just plain iperf (which is how I found tcpperf) and got no information. Any ideas? Thanks in advance, Ehud PS iperf -r (instead of -d) performs the same as the unidirectional tests above. smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: F9 PPC on Airport Extreme / PB G4 Ti
Larry Finger wrote: > Richard Michael wrote: >> Hello, >> ... >> Has anyone got this card working? >> > ... > A BCM4306 rev 03 is used my Michael Buesch, the main developer of b43, ... > > This sounds like a problem in the PPC port of F9. I hope you have > looked at the Fedora forums. > > Larry > It seemed the original message was missing info from dmesg as well as a result of the iwlist wlan0 scan or even iwconfig... Ehud PS my living-room guest-laptop uses a PCMCIA 4306 card. Info below for comparison. Kernel from wireless-testing: Linux vaioz505 2.6.26-rc6-eg20080623-wl #6 SMP PREEMPT Tue Jun 24 14:43:05 MST 2008 i686 GNU/Linux Device: [EMAIL PROTECTED]:~# lspci -d 14e4:4320 -v 01:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) Subsystem: Linksys Device 4320 Flags: bus master, fast devsel, latency 64, IRQ 9 Memory at 1400 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 Kernel driver in use: b43-pci-bridge Kernel modules: ssb [EMAIL PROTECTED]:~# iwconfig lono wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11 ESSID:"wetwork" Mode:Managed Frequency:2.437 GHz Access Point: 00:16:01:B9:FE:8F Bit Rate=24 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:896A-0055-AE77-5E80-FD86-4E38-6B Link Quality=55/100 Signal level:-81 dBm Noise level=-69 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 [EMAIL PROTECTED]:~# lsmod | grep b43 b43 145952 0 ssb42372 1 b43 pcmcia 37420 2 b43,ssb firmware_class 11392 2 b43,pcmcia mac80211 145296 1 b43 led_class 7940 1 b43 input_polldev 7816 1 b43 rfkill 10260 3 b43,rfkill_input pcmcia_core39572 5 b43,ssb,pcmcia,yenta_socket,rsrc_nonstatic ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More discrepancies in ssb-sprom
Dale Walsh wrote: > Now it's an issue of literacy??? I don't know when you became illiterate. I only noticed it in the previous posting. > > What a putz you are, looking for something, anything to make you feel > better than everyone else by giving you something to complain about, I > could care less if it's "your" or "you're" as long as you shut up, get > a life dude. Calling people idiots, turds, and putzes does not appear to be effective in making friends or influencing people. > If you had kept your mouth shut in the first place then this > conversation wouldn't be happening, you really need to get laid As you can tell from your posts of 06/05, 06/06, 06/08, 06/11, 06/19, 06/21, 06/23, 06/25, and today, there IS NO CONVERSATION HAPPENING. It has nothing to do with my sex life, because you see, Dale, nobody loves you. Again, if you want to see the illiterate idiot putz who needs to get laid and step off -- look in the mirror. Nothing to see here. Move along now. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More discrepancies in ssb-sprom
Dale this is not a flame-war list or a place to show your illiteracy. Step off. Dale Walsh wrote: > > On Jun 27, 2008, at 12:41 PM, Ehud Gavron wrote: ... > What is your problem, maybe you should up your medication!!! I can't find you listed as a licensed physician. Are you dispensing medical advice without a license? > The fact that you make this response shows your not very bright, *LOL* Did you mean "You're" not very bright, because then "you're" right. If you meant "your not very bright" then perhaps remedial first grade English would be called for. I don't know -- English is my second language. > I'm not interested in a "high" and "mightier than thou" attitude of > turds like you when your response doesn't contribute to anything positive. Calling people idiots and then turds is further evidence that you need to MOVE ALONG NOW. Step off, eh. > > Is everyone on this list a moron Yes, we're all morons. You're the genius. Go to [EMAIL PROTECTED] > ... > I'll wait for someone intelligent to offer something of value Apparently your four postings over several weeks have gained you none of that. Step off, eh. > -- Dale > Perhaps instead of prescribing medications, calling people idiots and turds, and saying nothing of intelligence is being presented you should take a deep breath (go ahead, really), try not to be illiterate (you know, "your" vs "you're", "it's" vs "its" and so on), and MOVE ALONG. In case the message was unclear, let me assure you in the friendliest way, Step off, eh. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More discrepancies in ssb-sprom
Dale Walsh wrote: > ... > And in my opinion this comment makes you look like an idiot. And now that you're resorting to calling list members idiots this is your opportunity for a time-out. Go stand in the corner, post on this list no more, and stop lowering the S/N ratio. The idiot is the one staring at you from the mirror. > ... > I could really care less about what you do... Clearly you don't care about people here. This is reason number two for you to MOVE ALONG NOW. > ... > Discussing anything with me ... is a complete waste of time ... Yes, it is. So go sit in the corner, or move on. No need to reply. You've already called us idiots and told us you don't care and that discussing things with you is a waste of time. I'm just offering friendly advice. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: after 3 weeks of problems, should I go back to windows?
Celejar wrote: > On Sun, 22 Jun 2008 13:08:49 -0500 > Larry Finger <[EMAIL PROTECTED]> wrote: > > ... >> Having to go >> through the steps required to generate a .deb and installing it for >> every change would take 3-4 hours away from my productivity. >> > > I'm no expert, and maybe I'm missing something, but rebuilding a kernel > the Debian way is just: > > 1:make [menu|x|g|whatever]config] > 2:make-kpkg --revision=whatever kernel_image > 3:dpkg -i whatever.deb > > How does this add significant overhead to the standard methods for > building kernels? [I am perfectly willing to be educated; as I > mentioned, I'm no expert.] > > >> Larry >> > > Normal kernel, step 1 is the same. Normal kernel, step 2 is make && make modules_install Normal kernel, step 3 is make install For step 2 on a non Debian machine I can add -j3 and run three simultaneous processes. I can build an entire kernel tree from scratch in under 20 minutes. The make-kpkg takes 47 minutes. For step 3 on a non Debian system I can do it in 13 seconds. The "dpkg -i whatever" takes over 13 minutes. Here's how you can test this... 1. On a Debian system time nice make-kpkg... && time nice dpkg -i 2. On the same system time nice (make -j2 && make -j2 modules_install && make -j2 install) (If you only have a single threaded uniprocessor leave off the -j2) Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: after 3 weeks of problems, should I go back to windows?
Mike Mohr wrote: > Please don't misunderstand the following comments. English _is_ my second language but I will do my best to not misunderstand the following comments. I hope you do the same. > I am not > disparaging the great work done by the bcm43xx team, but the fact is > that a reverse engineered driver will never be as good as a driver for > which the original source code or specs are released by the > manufacturer. That is not a fact. That's an unproven assertion. > As a result, > support for their chips in Linux is just superb; Whatever subjective phrase "support...is...just superb" there's no such causality. That means, to use smaller words, that there's no indication that the "superb support" is BECAUSE they released open-source drivers. I'm sure that is a factor, but it's not a CAUSE. > If you want a card that will work > perfectly in all situations, go with a card that has a Ralink chipset. > If I wanted a commercial or spam I'd join another list. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: after 3 weeks of problems, should I go back to windows?
Age Jan (John) Stap wrote: > Hi, > I'm trying to understand Linux and since I was working with DOS and > Pascal since 1982, I thought that I had an advantage > Here is what I did: > upgraded with max memory my X22 ThinkPad and installed and uninstalled > all kinds of (k)unbutu, Mint, DSl etc. > My pcmcia linksys card with a broadcom 4306 (rev3) chip worked, did > not work, etc, > I tried fw-cutter with b43 and b43xx, I tried ndiswrapper, and always > the same outcome: sometimes it works sometimes it does not work. > I'm now back to the blue cable on eth0 but in my debian-lenny-beta2 > networkmanager I see my wireless card on wlan0 at only 45% but nothing > happens when I try to activate it. > Reading the forums, it is clear that I'm not the only one but since > I'm very hardheaded (originaly from the netherlands), I want this > thing to operate under the b43 and fw-cutter conditions. If I don't > manage, is there a single pcmcia card that is really Linux-friendly? > > thanks for any help > - > John > > > Age Jan Stap > 1565 Calixa-Lavallee > Trois-Rivieres, Qc. > G8Y3G1 - CANADA > > go visit Helene's site at http://www.helene-vermote.ca > > > > Funny you should mention that. I spent two hours last night trying to get a BCM4306 working under Deb 2.6.24.4 with no success. I've had no problems getting the same card to work under Fedora from 2.6.23 all the way through 2.6.26-rc6. You didn't mention which kernel you have (uname -a), but as the previous sentence will help confound the issue, there's something about the Debian distro that makes it not work [more on what "not work" below] and I haven't isolated what it is as of yet. 1. The firmware loads. sudo dmesg | grep b43shows that the chip is detected, the LEDs are connected, etc. 2. The interface shows up. sudo iwconfig shows wlan0 3. The interface turns on.sudo ifconfig wlan0 up no errors NOT WORK: 4. Unable to scan for networks. sudo iwlist wlan0 scan 5. Unable to associate with AP.sudo iwconfig wlan0 essid ehudssid key wepkeygoeshere open shows link quality 0 and no AP I'm currently hunting for more clues. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: vendor/product ID's
Dale Walsh wrote: I'm new to the list and new to firmware modification so hi everyone. I have a broadcom PCI card and *I need* to modify the vendor and product ID's, in case it matters it's a LinkSYS WMP300N. How on Earth did you come up with this idea? I've looked around for tools and came across something that looked promising but it gave a URL of "git clone http://git.bu3sch.de/git/b43-tools.git"; and I have no clue what git is or how to use it and cursory searches imply some kind of linux tool. Try this URL: http://tinyurl.com/161 I have a *semi *linux environment available that allows me to "configure/make" software so gnu related software can be built but rpm and git and the likes don't apply to the OS so suggesting them wouldn't be helpful since I can't use them. How on Earth did you come up with this idea? Since my everday OS isn't widely supported, I was hoping there was a windows app that would read the sprom allow me to change the ID's and write it back out to the card but I couldn't find anything (my search skills suck). I have no problems using a CLI utility and navigation is not an issue. Hopefully someone can provide a link for a windows utility that fits my needs or a GNU source package that can be built on the majority of *nix based OSes that doesn't have many obscure external dependancies (I have been know to compile things that don't normally compile on my OS). So, to get the laughing over with I'll mention my OS, Darwin, yes you heard it correctly, 5 different versions of it, Darwin7, Darwin8, Darwin9, Mac OS X 10.4.x and Mac OS X 10.5.x, Mac OS X is Darwin based so this explains why rpm's and git won't work for me. -- Dale I'm not laughing. I'm sad. I hope the b43 driver developers sleep a little while longer... for your sake. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
Johannes Berg wrote: > On Fri, 2008-05-30 at 16:06 +0200, Michael Buesch wrote: > >> On Friday 30 May 2008 14:31:53 Johannes Berg wrote: >> >>> Since a while ago I've had trouble resuming when b43 was connected to an >>> AP while suspended. >>> >>> I did a test today where this was the only difference, but I failed to >>> see whether ssb or b43 were causing the problem. >>> >>> Does anyone have a machine with b43 in it that can suspend and supports >>> the RTC-trace feature so we can narrow it down? Even reproducing might >>> help to make sure it's not just something weird with my powerbook. >>> >> Resume is pretty broken since some time for me. >> It sometimes works fine and sometimes just hangs with a black screen. >> I have no idea what's going on. >> > > Odd. Resume itself works just fine here, except when b43 is up. But then > again, you might not notice that this is the problem because by default, > nothing gets printed on the resume console and then it will indeed hang > with a black screen. > > johannes > > With NM disabled 2.6.25-wl 4311 after a suspend/resume I can: 1. Successfully scan for APs (ifconfig wlan0 up... iwlist wlan0 scan) 2. Associate with an AP (iwconfig ...essid...key...) 3. Get a DHCP address (dhclient... offer... bound to address such and such) but 4. NO FURTHER IP COMMUNICATIONS WORKS Let me know what other diags to run or if I should upgrade to the latest wl tree if you think that will change the symptoms. Things have been busy but there is a weekend coming up here shortly. Ehud > > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: sucess with HP-laptop dv6057ea
Rafal Milecki wrote: > Really, "HP-laptop dv6057ea" doesn't mean much for every one. It would > be nice to post proper part of > lspci -nnv Others have written: Please include dmesg Still others have said: It doesn't help anyone when you say "I have a problem" without giving us any information to allow us to help you. WORSE YET if the problem is fixed and you don't tell us how it was fixed or what you did, we can A) Not fix the software and B) Not tell new people with the same hardware how to fix the problem because we C) Still don't know what what the harware is and D) Don't know what was wrong and E) Don't know what was done to fix it. Don't look at me. I'm just an end-user with a good cut&paste key. Ehud [EMAIL PROTECTED] wrote: > Hi, > > after a long time I tryed again wlan with my dv6057ea laptop, and it > works perfect (but only with ssb and B43 as a module). If you are > interessted in further tests, please let me know. > > actual configuration: > > kernel: 2.6.25 > module: b43 > firmwareID: FW13 > > > Thanks a lot for your great work. > > All the best > > Robert > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ASUS WL-138G v2 / 64bit x86 / b43 working much better
Stefanik Gábor wrote: > ... > Ehud & Gavron: are you sure this discussion belongs to bcm43xx-dev?! > AFAIK the microcode doesn't really care about American vs. British > spellings. > > Also, a good rule of thumb about which spelling to use: if you are > writing about US subjects, use US English. If you are writing about > British subjects, use UK English. In general, use the most relevant > spelling rules. (This is what I call "Wikipedia English".) > > -- > Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) Stefanik, you are right, this does not belong on the list :) Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ASUS WL-138G v2 / 64bit x86 / b43 working much better
kala mazoo wrote: > > >> Date: Wed, 7 May 2008 22:18:32 -0500 >> From: [EMAIL PROTECTED] >> > > <> > > > Apparently there's more than just these bits in the sprom controlling the > LED > behaviour? Does anyone know what that might be? > I'm not sure what you should expect from the 0xFF values; however, you have not enabled the LED select stuff in your kernel. If you had, you would see lines like b43-phy0 debug: 64-bit DMA initialized >>> if it's supposed to say '64bit' , it doesn't here... >>> >> That is a function of your card, not your OS. Mine is 64-bit, yours is >> 32-bit, and others are 30-bit. >> >> > > i see... > > >> <> >> > > >>> Using kernel menuconfig, one will typically configure networking-->wireless >>> before they get to device drivers-->LED support. This is unfortunate if one >>> has started the kernel configuration with devices drivers-->led >>> support-->led trigger support >>> unset, as led trigger support isn't displayed in networking-->wireless with >>> this option unset. >>> >> Yes, configuration is not a straight-line process. In LKML, they are >> currently discussing changes that would gray out those options that do not >> have their prerequisites met. >> >> > > well, that might help...provided the option still works on a gray option, > and tells the user what the prerequisite actually is that's currently unset. > Otherwise, > a torrent of "what does it mean when an option is grayed out? How do I fix > this?" > questions are likely to be observed > > > >>> Still stupid human error, I know, but that's how a person gets led into it. >>> >>> Anyhow, thanks for pointing that out, now I get ; >>> >>> b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) >>> b43-phy0 debug: Chip initialized >>> b43-phy0 debug: 32-bit DMA initialized >>> Registered led device: b43-phy0::tx >>> Registered led device: b43-phy0::rx >>> Registered led device: b43-phy0::assoc >>> b43-phy0 debug: Wireless interface started >>> b43-phy0 debug: Adding Interface type 2 >>> ... >>> >>> The rx/tx LED behaviour is working as expected with the 0xFF sprom values >>> that come with this asus card typeafaict. >>> >> Glad to be able to fix a problem quickly. Lately, it has been taking a long >> time. Perhaps the bugs are getting more subtle. >> >> Once again, thanks for the ASUS PCI card. I didn't do very much toward >> fixing >> the problem, but I was able to confirm that there was really a problem, and >> your difficulties weren't due to your spelling of behavior, the sun being in >> the north, or any other geographic factors. >> >> > > Not a problem, if only to confirm the problem existed, it was worth it. As to > the speed finding & fixing the issue, I personally thought things happened > pretty fast to arrive at the eventual resolution. I think Stefanik deserves an > extra cookie of credit here for having the idea to substitute sprom images. > Everyone who helped out gets cookies as well for outstanding effort. (; > > ..next, I can move onto my original notion of using one of these cards in AP > mode... > > >> I'm particularly sensitive to the differences between British and American >> spelling. I once co-authored a book with another American. It was published >> by Wiley and Sons out of their UK office. The text went in with US spelling, >> but the galley proofs had UK spelling. We dutifully changed them all, but >> that had no effect. In the final version of the book, color was spelled >> colour, etc. >> >> Larry >> >> > > That is a disappointing outcome -- I'd understand you feeling you're like the > victim > of some form of nationalistic prejudice in such circumstance...ie; if I'd > written a book > adhering to the spelling examples contained in the Australian Macquarie > lexicon, I > would expect what was published still to be in that original form. I'm > typically > ambivalent of/to the spelling differences you speak of, so I am truly > apologetic > if that stance has upset/affronted you or anyone else on this list. > > Regards, > > Donald > > _ > It's simple! Sell your car for just $30 at CarPoint.com.au > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > What if the disappointment is that you're an idiot, and your name "kalamzoo" is an nonexistent place in Michigan, and your input thus far on this list has led to more false diagnostics than anyone else, and you're an idiot? So when
Re: Inconsistency in handling board revision
Larry Finger wrote: > Michael Buesch wrote: > >> On Friday 25 April 2008 06:55:54 Larry Finger wrote: >> >>> Michael, >>> >>> I have discovered that both sprom_extract_r123() in the ssb driver, >>> and ssb-sprom use a two-byte quantity to extract the board revision. >>> In the specifications detailed in >>> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this >>> parameter. >>> >>> It is unlikely that this causes any serious difficulties; however, at >>> least one fixup depends on the board revision, and I wanted to be >>> certain that you were aware of the situation. >>> >> I'm not sure what you're talking about. >> >> #define SSB_SPROM1_BINF_BREV 0x00FF /* Board Revision */ >> SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0); >> >> > > Yes - 2 bytes in the code above, but the spec says bits 0-7! > > Larry > Whoops, ignore previous message. 0xFF is one byte. Bits 0-7 are 0xFF. Bits 0-7 = 0-255 = 0x00-0xFF A nibble which I thought was cute because I could rhyme against it is half a byte, or 4 bits, or one hex digit. E (it's 0730 and I've been up 33hrs ;) > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Inconsistency in handling board revision
Larry Finger wrote: > Michael Buesch wrote: > >> On Friday 25 April 2008 06:55:54 Larry Finger wrote: >> >>> Michael, >>> >>> I have discovered that both sprom_extract_r123() in the ssb driver, >>> and ssb-sprom use a two-byte quantity to extract the board revision. >>> In the specifications detailed in >>> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this >>> parameter. >>> >>> It is unlikely that this causes any serious difficulties; however, at >>> least one fixup depends on the board revision, and I wanted to be >>> certain that you were aware of the situation. >>> >> I'm not sure what you're talking about. >> >> #define SSB_SPROM1_BINF_BREV 0x00FF /* Board Revision */ >> SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0); >> >> > > Yes - 2 bytes in the code above, but the spec says bits 0-7! > > Larry > > Larry - 1 byte but the spec says one nibble. So I quibble ;) E > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > On Thursday 17 April 2008 19:07:22 Larry Finger wrote: > >> I'm glad it is not working. >> > > Haha. And people call _me_ inhuman. :D > > No, _people_ did not call you inhuman. A non-human called you inhuman. E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 problem with wireless-testing 2.6.25-rc8 from APR 8 commit -- ARPs no longer go through
Johannes Berg wrote: >>> As you can see in the log, the WEP key is getting disabled. printk >>> timestamps would help to identify what really happens. >>> >>> >>> >> Missed that! >> > > No worries. I was just a bit confused because I couldn't tell whether > the enable/disable messages were directly after one another or not. > > >> I was going to but then you released the followup [PATCH] mac80211: fix >> key todo list order so I tried that. >> >> That fixed the problem :) >> > > Good to know, thanks for testing. We really want both patches, and the > previous one would have "fixed" the problem too because you were using > WEP, with WPA the problem might still have happened. > > johannes > Thanks :) FYI I didn't manually do anything for the sample I submitted. In that one I simply used NetworkManager and it "just Connected" and never did anything else. In previous tests I'd eliminated NetworkManager by manually setting the ESSID and WEP key*. Since that made no difference I went back to NM. Again, thanks for the quick response, and the quick fix :) Ehud * I know I put my WEP key out there, but I firmly believe if any of my neighbors read this list they are more than welcome to associate with my APs. (Or if they come up and ask me what the 4ft dish is all about...) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 problem with wireless-testing 2.6.25-rc8 from APR 8 commit -- ARPs no longer go through
Johannes Berg wrote: > ... > As you can see in the log, the WEP key is getting disabled. printk > timestamps would help to identify what really happens. > > Missed that! > ... > Can > you please try the patch > > [PATCH v2] mac80211: fix key hwaccel race > > > > johannes > I was going to but then you released the followup [PATCH] mac80211: fix key todo list order so I tried that. That fixed the problem :) Thank you :) Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
B43 problem with wireless-testing 2.6.25-rc8 from APR 8 commit -- ARPs no longer go through
I will describe the symptoms in detail below. The commit that broke it is: 9e3143b05cf4274dc5c5d4fc1e13ca6c13945587 is first bad commit commit 9e3143b05cf4274dc5c5d4fc1e13ca6c13945587 Author: Johannes Berg <[EMAIL PROTECTED]> Date: Tue Apr 8 17:56:52 2008 +0200 mac80211: fix key vs. sta locking problems Up to now, key manipulation is supposed to run under RTNL to avoid concurrent manipulations and also allow the set_key() hardware callback to sleep. This is not feasible because STA structs are rcu-protected and thus a lot of operations there cannot take the RTNL. Also, key references are rcu-protected so we cannot do things atomically. This patch changes key locking completely: * key operations are now atomic * hardware crypto offload is enabled and disabled from a workqueue, due to that key freeing is also delayed * debugfs code is also run from a workqueue * keys reference STAs (and vice versa!) so during STA unlink the STAs key reference is removed but not the keys STA reference, to avoid races key todo work is run before STA destruction. * fewer STA operations now need the RTNL which was required due to key operations This fixes the locking problems lockdep pointed out and also makes things more light-weight because the rtnl isn't required as much. Note that the key todo lock/key mutex are global locks, this is not required, of course, they could be per-hardware instead. Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> Signed-off-by: John W. Linville <[EMAIL PROTECTED]> :04 04 c3d24705019ce120163f8f1efe0afb8aebff58fa 41ad23e05abfe62298101ba1d27a1815471c68ba M net Git bisect log attached. The problem description is as follows: Anywhere from one second to 3-5 minutes after assocation the IP traffic fails to come through. Using wireshark on the laptop side I see STP packets and other Ethernet frames. The association is good. iwconfig is good. RX and TX count increment (iwconfig attached). Dmesg says nothing from the point before the failure to the point after. (dmesg attached) When the problem occurs, wireshark on the wlan (laptop) side shows ARP requests that are not responded to. When the problem occurs, wireshark on the LAN (wired) side does not show those ARP requests. I've tried pings in both directions which only serve to generate ARP requests. NONE make it to the wlan adapter. Other Ethernet traffic (e.g. STP and 802.1q stuff does). This network uses WEP. Please advise how I can better test. Thanks, Ehud PS A previous message to bcm43xx-dev has not yet appeared... so there may be an unrelated problem there. Initializing cgroup subsys cpuset Linux version 2.6.25-rc8-ehud-wl ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Sat Apr 12 13:45:30 MST 2008 Command line: ro root=LABEL=/ quiet BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - cfe81400 (usable) BIOS-e820: cfe81400 - d000 (reserved) BIOS-e820: f000 - f4007000 (reserved) BIOS-e820: f4008000 - f400c000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed2 - feda (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 851585) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000FC0C0, 0014 (r0 DELL ) ACPI: RSDT CFE8198A, 0044 (r1 DELLM07 27D8010B ASL61) ACPI: FACP CFE82800, 0074 (r1 DELLM07 27D8010B ASL61) ACPI: DSDT CFE83400, 519E (r1 INT430 SYSFexxx 1001 INTL 20050624) ACPI: FACS CFE91C00, 0040 ACPI: HPET CFE82F00, 0038 (r1 DELLM071 ASL61) ACPI: APIC CFE83000, 0068 (r1 DELLM07 27D8010B ASL47) ACPI: ASF! CFE82C00, 005B (r16 DELLM07 27D8010B ASL61) ACPI: MCFG CFE82FC0, 003E (r16 DELLM07 27D8010B ASL61) ACPI: TCPA CFE83300, 0032 (r1 DELLM07 27D8010B ASL61) ACPI: SLIC CFE8309C, 0176 (r1 DELLM07 27D8010B ASL61) ACPI: SSDT CFE81A11, 04DC (r1 PmRefCpuPm 3000 INTL 20050624) No NUMA configuration found Faking a node at -cfe81000 Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 851585) 1 entries of 3200 used Bootmem setup node 0 -cfe81000 NODE_DATA [d000 - 00014fff] bootmap [00015000 - 0002efd7] pages 1a early res: 0 [0-fff] BIOS data page early res: 1 [6000-7fff] SMP_TRAMPOLINE early res: 2 [20-bcf987] TEXT DATA BSS early res: 3 [37cc3000-37fef010] RA
wireless-testing issue - association good but no ARP requests go out. Between 04/04 and today.
I'm chasing a subtle bug and it takes it time to manifest, so the whole git bisect process will likely take days. The symptoms are that "after some period of time" the machine loses IP connectivity. I add detail below. It can be restored through either of the following: 1. NetworkManager click on the network. It disconnects and reconnects and works for a while. 2. modprobe -r b43 && modprobe b43. During the time of the symptom, iwconfig shows strong connectivity. dmesg shows nothing unusual or strange. The wlan0 network monitor shows RECEIVE and transmit increments. Wireshark shows broadcasts from the Adtran router that talks to the WiFi router on the wired network, so definitely wireless connectivity is there, and definitely wired from there. It shows ARP requests from the laptop that are never responded to (although the STP packets from the device that ought to be responding are received just fine.) Wireshark on the wired LAN fails to see the ARP requests at all. After a reset the Wireshark on the wired LAN can again see the ARP requests (and everything works). Does this ring any bells for anyone on anything that's changed in the last week? I took a quick look at the differences between the two source trees and there's a lot there (mostly the PIO+DMA changes). SO yes, I'm doing a git bisect. It just sometimes takes hours to manifest... Ehud ___ 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
I had a case of total disassociation last night, and it is unusual. NM was unable to reconnect (so we go to bash). A scan revealed no APs but after a module reload they are back... What further testing or other diagnostics can I run should this happen again to rest? Thanks E [EMAIL PROTECTED] ~]# iwlist wlan0 scan wlan0 No scan results [EMAIL PROTECTED] ~]# rmmod b43 [EMAIL PROTECTED] ~]# modprobe b43 [EMAIL PROTECTED] ~]# iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:16:01:B9:F9:3F ESSID:"wetwork" Mode:Master Frequency:2.437 GHz (Channel 6) Channel:6 Quality=71/100 Signal level=-64 dBm Noise level=-69 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=0266671a2b44 Cell 02 - Address: 00:16:01:B9:FE:8F ESSID:"wetwork" Mode:Master Frequency:2.437 GHz (Channel 6) Channel:6 Quality=98/100 Signal level=-36 dBm Noise level=-69 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=02cd08cbc1ce Cell 03 - Address: 00:16:01:B9:F5:1F ESSID:"wetwork" Mode:Master Frequency:2.437 GHz (Channel 6) Channel:6 Quality=61/100 Signal level=-74 dBm Noise level=-69 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=021011e7a0e7 [EMAIL PROTECTED] ~]# Pavel Roskin wrote: > On Fri, 2008-04-04 at 16:12 +0200, Michael Buesch wrote: > >> Hi b43 users, >> >> Please be so kind to run lots of regression tests on the following >> patch. This patch is supposed to make the LO calibration a _lot_ more >> lightweight and avoid a long MAC-disable period every 120 seconds. >> >> We need a lot of regression testing with this patch on lots of different >> devices to make sure we don't introduce regressions. >> >> I tested this on a 4306 and a 4318 card. So far it seems to work great >> on these cards. >> > > Tested on this: > > 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 > phy0: Selected rate control algorithm 'pid' > Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ] > > It's actually Fedora development kernel 2.6.25-0.195.rc8.git1.fc9.i686 > with patched compat-wireless installed. > > It's working better than I could possibly expect. The range is on the > par with another laptop with ipw3945 running Linux or Windows XP. It's > working through 4 walls and 30 meters on top of that. I understand that > there are many random factors involved, but my impression is very > positive. Basically, it's good enough to go outside with the laptop > without having an AP installed near a window. I haven't seen any > significant interruptions in the connection. > > Unfortunately, I hit that nasty circular lock dependency bug (already > discussed in another thread) when I killed wpa_supplicant to try another > AP. The CPU utilization went to 100%, but the driver kept working. > > 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 :) > > I'll try to get 4318 tested over the weekend. > > ___ 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
Julien Muchembled wrote: > Michael Buesch a écrit : > >> Can you try the following patch? >> http://bu3sch.de/patches/wireless-testing/20080404-1408/patches/010-b43-calibrate-lo-on-demand.patch >> > > I am really impatient to use it. However, I use vanilla 2.6.24.4 and it > doesn't apply. > > Against 2.6.25-rc8, there are 2 conflicts in main.c (2 occurrences of > 'static' keyword already removed). I think I can skip the 2 first hunks. > > I prefer to use stable versions and I'll wait that 2.6.25 is released. > > JM > > I know exactly what you mean! One time my car had a problem and the mechanic said I had to bring it in to get it fixed. I died laughing. What, me bring the car in? That's ridiculous. I'll wait for the new model to be released. Funny thing is my mechanic NEVER ASKED why I bothered to call if I didn't really want to do what needed to be done to fix the problem. I guess I won't either. Good on ya, mate, E ___ 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
Works great on my 4311 rev 01. E Michael Buesch wrote: > Hi b43 users, > > Please be so kind to run lots of regression tests on the following > patch. This patch is supposed to make the LO calibration a _lot_ more > lightweight and avoid a long MAC-disable period every 120 seconds. > > We need a lot of regression testing with this patch on lots of different > devices to make sure we don't introduce regressions. > > I tested this on a 4306 and a 4318 card. So far it seems to work great > on these cards. > > Thanks. > > > -- Forwarded Message -- > > Subject: Re: b43: 1 second "freeze" every 2 minutes - works with bcm43xx > Date: Friday 04 April 2008 > From: Michael Buesch <[EMAIL PROTECTED]> > > Can you try the following patch? > http://bu3sch.de/patches/wireless-testing/20080404-1408/patches/010-b43-calibrate-lo-on-demand.patch > > This patch is supposed to distribute the calibration bursts over time, > so that calibration only happens when it's actually needed. > So instead of disabling the MAC every 120 secs and recalibrating the > whole calibration tables, we assign a timeout to each calibration value > and only recalibrate it if it's > a) expired and > b) currently used. > Recalibration might also happen on TX power adjustment, if the corresponding > calibration item is no longer in the cache because it has expired. That > actually happens most of the time, but we can live with it, as power > adjustment > doesn't happen that often and calibration is a _lot_ cheaper. > > This patch also reduced overall memory consumption by nuking the > huge static calibration tables. > > Disclaimer: > The algorithms in this patch are completely redesigned and have nothing in > common with how broadcom does the stuff in the proprietary driver. So it's > highly experimental and I'm not responsible in case this patch eats your cat. > > --- > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Enable quantum cryptography support
I tried this patch against the 3.6 tree and I was unable to get it to
compile.
It kept saying my version of gcc is too old.
Is it my SPROM?
Ehud
gcc version 5.1.2 20090401 (Red Hat 5.1.2-33)
Michael Buesch wrote:
> This patch enables support for quantum cryptography on latest b43 devices.
> The quantum cryptography algorithm is 100% backward compatible with the
> standard CCMP algorithm, so no additional changes to the mac80211 stack
> are needed. While staying compatible, it makes the unbreakable(!) WLAN
> connection
> possible. Of course, that's only the case, if both ends use b43-qcrypto.
> In the case where one STA uses legacy encryption, the card will automatically
> detect this and switch back to plain old CCMP.
>
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
>
> ---
>
> John, please queue this patch for linux-3.6.26
>
>
> Index: wireless-testing/drivers/net/wireless/b43/b43.h
> ===
> --- wireless-testing.orig/drivers/net/wireless/b43/b43.h 2008-03-22
> 15:44:00.0 +0100
> +++ wireless-testing/drivers/net/wireless/b43/b43.h 2008-04-01
> 15:53:40.0 +0200
> @@ -270,6 +270,7 @@ enum {
> #define B43_HF_ANTSELMODE0x0002ULL /* Antenna selection mode
> (rev >= 13 only) */
> #define B43_HF_MLADVW0x0010ULL /* N PHY ML ADV
> workaround (rev >= 13 only) */
> #define B43_HF_PR45960W 0x0800ULL /* PR 45960
> workaround (rev >= 13 only) */
> +#define B43_HF_QUANTUMCRYPT 0x1000ULL /* Enable quantum
> cryptography in firmware. */
>
> /* MacFilter offsets. */
> #define B43_MACFILTER_SELF 0x
> @@ -439,6 +440,7 @@ enum {
> B43_SEC_ALGO_AES,
> B43_SEC_ALGO_WEP104,
> B43_SEC_ALGO_AES_LEGACY,
> + B43_SEC_ALGO_QUANTUM,
> };
>
> struct b43_dmaring;
> Index: wireless-testing/drivers/net/wireless/b43/main.c
> ===
> --- wireless-testing.orig/drivers/net/wireless/b43/main.c 2008-03-27
> 17:11:38.0 +0100
> +++ wireless-testing/drivers/net/wireless/b43/main.c 2008-04-01
> 15:53:41.0 +0200
> @@ -3215,6 +3215,13 @@ static int b43_op_set_key(struct ieee802
> break;
> case ALG_CCMP:
> algorithm = B43_SEC_ALGO_AES;
> + if (dev->dev->id.revision >= 20080401) {
> + /* Latest devices can do quantum cryptography
> + * to encrypt/decrypt the data stream.
> + * This is 100% backward compatible with the traditional
> + * CCMP algorithm. */
> + algorithm = B43_SEC_ALGO_QUANTUM;
> + }
> break;
> default:
> B43_WARN_ON(1);
> @@ -3254,6 +3261,10 @@ static int b43_op_set_key(struct ieee802
> b43_hf_write(dev,
>b43_hf_read(dev) & ~B43_HF_USEDEFKEYS);
> }
> + if (algorithm == B43_SEC_ALGO_QUANTUM) {
> + b43_hf_write(dev, b43_hf_read(dev)
> + | B43_HF_QUANTUMCRYPT);
> + }
> key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
> break;
> case DISABLE_KEY: {
>
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More on ASUS WL-138G V2
I'll happily pick up the cost of shipping his card to Larry if it will make him shut up. You can send it on my FedEx code or I'll PayPal you the cost. Ehud (less Human than Michael) kala mazoo wrote: > > >> Date: Sun, 23 Mar 2008 09:08:46 -0700 >> From: [EMAIL PROTECTED] >> To: [EMAIL PROTECTED] >> CC: [EMAIL PROTECTED]; bcm43xx-dev@lists.berlios.de >> Subject: Re: More on ASUS WL-138G V2 >> >> kala mazoo wrote: >> >>> >>> From: [EMAIL PROTECTED] Ok, the card does not transmit the data. A few people reported this and I have absolutely no idea what's going on. >>> well, there you go ...I am sane after all. Perhaps should someone put >>> up a little compatibility caveat on the b43 webpage, warning people that >>> there are issues with this brand/model of card that remain unresolved? Not >>> to worryI'll just backtrack all this on the 32bit P4 box to make sure >>> the situation with that older slower hardwareand I guess it's off to >>> the computer shop on tuesday to buy some different cards... >>> >>> ...does ebay run 'give away' ads? ..ie; "Give Away ASUS WL-138G V2 wireless >>> LAN cards, PCIsuit linux software driver developer.." (hehe) >>> >>>Thanks to all who replied and helped me out -- I'll monitor the list and >>> watch for developments. If you need me to try something out, just email me >>> - I'll be glad to help out if I can... >>> >> What format is this card. It is probably someplace in the thread, but I have >> developed bad habits by >> watching the behaviour (British spelling intentional!!) of others on this >> list. Perhaps there is a >> developer in AU that might be interested in looking at this card to solve >> the issue. If there is no >> one there, I would be willing to pay the shipping cost to the US if it will >> fit in one of my machines. >> >> Larry >> >> > > Hey there Larry, > The cards are PCI form. If there is someone > in .AU wanting to help with this, then they'd better speak up (here, on the > list),because otherwise I won't ever know they're out there... > > If you want a card to play with, get back to me with your > snail address and I'll pop one in the mail for you. Don't worry about > shipping costs, I'll pickup that tab (and the cost of the card itself) and > consider it my donation to the b43 development drive > > > Kind regards, > > Donald > _ > Search for local singles online @ Lavalife > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Invalid MAC address with B43 and Broadcom 4318
Do you have an equivalent of an /etc/sysconfig/network-scripts/ifup-wlan0 that has a line that specifies HWADDR=something? Ehud Dad wrote: > I have been trying to use my broadcom 4318. The B43 software finds the > card I am using but the MAC address is not correct. I am using Ubuntu > 7.10 using the 2.6.22-14 kernel and the compat-wireless-2.6.tar.bz > wireless distribution, with the broadcom-wl-4.150.10.5 firmware. The > true MAC address of the card is 00:0B:6B:1D:27:AD and the MAC address > reported by ifconfig varies each time I try to initialize it. I hope > someone can help me solve my problem. > > Here is the ifconfig: > wlan0 Link encap:Ethernet HWaddr 0E:C0:DB:7D:DC:10 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > The kern.log entries are (I built b43 with debug): > Mar 9 12:08:22 ubuntu kernel: [ 2776.884000] pccard: PCMCIA card > inserted into slot 0 > Mar 9 12:08:22 ubuntu kernel: [ 2776.884000] pcmcia: registering new > device pcmcia0.0 > Mar 9 12:08:22 ubuntu kernel: [ 2776.924000] b43-phy3: Broadcom 4318 > WLAN found > Mar 9 12:08:22 ubuntu kernel: [ 2776.972000] phy3: Selected rate > control algorithm 'pid' > Mar 9 12:08:22 ubuntu kernel: [ 2776.972000] ssb: Sonics Silicon > Backplane found on PCMCIA device pcmcia0.0 > Mar 9 12:08:23 ubuntu kernel: [ 2777.328000] b43-phy3: Loading firmware > version 410.2160 (2007-05-26 15:32:10) > Mar 9 12:08:24 ubuntu kernel: [ 2778.70] ADDRCONF(NETDEV_UP): > wlan0: link is not ready > > Here is what lshw sees for the network: > *-network >description: 802.11g SC CF >vendor: Broadcom >physical id: 0 >version: 4.0 >slot: Socket 0 >resources: irq:3 > *-network >description: Ethernet interface >product: 82801CAM (ICH3) PRO/100 VM (KM) Ethernet Controller >vendor: Intel Corporation >physical id: 8 >bus info: [EMAIL PROTECTED]:02:08.0 >logical name: eth0 >version: 42 >serial: 00:08:02:93:eb:7a >size: 10MB/s >capacity: 100MB/s >width: 32 bits >clock: 33MHz >capabilities: pm bus_master cap_list ethernet physical tp mii > 10bt 10bt-fd 100bt 100bt-fd autonegotiation >configuration: autonegotiation=on broadcast=yes driver=e100 > driverversion=3.5.17-k4-NAPI duplex=half firmware=N/A latency=66 link=no > maxlatency=56 mingnt=8 module=e100 multicast=yes port=MII speed=10MB/s > *-network >description: Wireless interface >physical id: 2 >logical name: wlan0 >serial: 0e:c0:db:7d:dc:10 >capabilities: ethernet physical wireless >configuration: broadcast=yes multicast=yes wireless=IEEE 802.11 > > Thanks for all your help > Tex > > > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wi-Fi interface intermittently missing on HP laptop
Larry Finger wrote: > Hans Henry von Tresckow wrote: > >> Larry, how do you get a warrenty replacement after you "void" the >> warranty by installing an alternate OS on your HP laptop? >> >> > > I only have to leave Windows on the machine. If I need to take it in, I > rewrite the master boot > record so that Linux doesn't show at boot time. So far no one has questioned > those extra unavailable > partitions. In addition, they only warranty the hardware - software problems > do not count. > > Larry Almost a year after I bought it my Dell Latitude D620 battery would only hold 20% charge. I contacted Dell Support who wanted screenshots from the Power Control Panel. I sent them a copy of /proc/acpi/battery/BAT0/info and told them I run linux. They immediately sent me a free new replacement battery. E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with BCM4318 (Wireless LAN PCI Adapter WL-138G V2 )
Awesome response. E PS There's the old tale about the monkeys in a cage. You put bananas up in the center and give them a chair. Eventually one gets on the chair, and you use a firehose on them. After a time as soon as any monkey goes toward the chair the others pull him down.. wanting to not get the firehose treatment. Replace some monkeys. Repeat. After a time NO monkey will let ANY monkey go for the bananas but they don't actually know why... they've learned that "all the other monkeys want to stop it" so "it must be a bad thing." That's human nature. It's an AWESOME THING when a person who earlier had issues with his driver and got them fixed is now able to help another person. That's the opposite of the monkey thing. Well done. Oh sorry for ranting, so I moved it to the PS in hopes I don't get flamed ;) David Cohen wrote: > Hi, > > You'll be glad I am the one who answers that :-D > > You need to send more accurate information about your system: > *Kernel version (just type 'uname -r' command) > > *There are 2 possible drivers for your wifi card: > - if your kernel version is <= 2.6.23, probably your are using "bcm43xx" > module > - if it is >= 2.6.24(-rc or not), problably you are using "b43" module > Type "lsmod | grep bcm43xx" or "lsmod | grep b43" (depending on your > module) and send the result > > *Type "dmesg" and capture the debug information your module has written > > *And finally: Did you install any bcm43xx-fwcutter or b43-fwcutter > package that downloaded any firmware? > > Br, > > David > > > On Feb 2, 2008 7:17 PM, Pedro P <[EMAIL PROTECTED]> wrote: > >> My name is Javier and I'm a new in Linux and I have a problem with my >> wireless card (Asus >> WL-138G V2) Chipset: BCM4318 PCI. >> I think that SUSE 10.30 must automaticly configure card but it can't make it. >> KNetwork Manager doesn't detect any wireless net. My router accept dchp and >> wireless need >> a password. >> Only I can navigate with cable USB and not with wireless card. >> >> Can you help me to configure wireless card?. >> Thanks, >> Javier >> >> Tecnichal information about my sistem: >> - >> Linux: openSUSE 10.30 >> >> My computer (Tower): >> >> AMIBIOS (American Megatrends, Inc) >> version: 0506 >> Build Date: 08/06/07 >> Processor: >> Type: Intel (R) Core (TM) 2 Quad CPU Q6600 @4 >> Speed: 2400 MHz >> Count: 4 >> System Memory: >> Usable Size: 2048 MB >> >> >> The technical especifications for my Wireless Card are: >> >> Card: Asus WL-138G V2, 54mbps >> Chipset: BCM4318 PCI >> PCI ID: 14e4:4318 >> >> >> Wireless LAN PCI Adapter WL-138G V2 >> Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN >> Controller >> [14e4:4318] (rev 02) >> - >> Ya.com ADSL 24h + Llamadas Nacionales y Locales 24h + Llamadas a MÓVILES. >> Desde 9,95 €/mes+IVA. http://acceso.ya.com/ADSLllamadas/3mbvoz/ >> >> ___ >> Bcm43xx-dev mailing list >> Bcm43xx-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev >> >> >> > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4318 problem on HP nx6110
Michael is making a reference to a different thread where he was called inhuman.* Truly it is an honor when he is suggesting I am less nice than he is :) Thank you for the beach scenery. My beach scenery would have a little more "eye candy". E * Ironically enough nobody thinks T is human but I'm not going to start that here. David Cohen wrote: Hi, On Feb 2, 2008 11:22 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: On Saturday 02 February 2008 04:52:59 [EMAIL PROTECTED] wrote: On the other hand, I'm going to go out on a limb and suggest that PERHAPS if you have ANY brainpower left, you include a full dmesg as well as an lsmod | grep b43 as well as an iwlist wlan0 scan ... or not. Ok, well. Seems like I'm not the most inhuman person on this list anymore. ;) Yayy!!! :D Unfortunately I couldn't see any answers from you yet. But for now you are not winning. I really appreciate your help and I know how hard some kind of question can be. But I think some guys are needing a bit of this: http://www.portodegalinhas.tur.br/apraia.htm ;D plz, don't be offended. Your work are great and I can get rid of ndiswrapper now. Thanks in advance, David David, you are using the wrong firmware version (too new). Downgrade please. The human readable warning for this got lost in the 2.6.24 merge process. 2.6.24.1 will include a human readable warning for this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4318 problem on HP nx6110
Messages sent: 3 Messages which include a dmesg: 0 Messages which include the output from anything:0 Here's where we differ. See Larry would tell you what you need to send. He's like a saint that way. I would say "Don't send anything else. We can't help you with no input, and you don't provide input." On the other hand, I'm going to go out on a limb and suggest that PERHAPS if you have ANY brainpower left, you include a full dmesg as well as an lsmod | grep b43 as well as an iwlist wlan0 scan ... or not. Cheers Ehud David Cohen wrote: Hi, See bellow: On Feb 1, 2008 9:23 PM, David Cohen <[EMAIL PROTECTED]> wrote: Hi, I figured out the b43 module can find my network (with iwlist scan) if I don't press the radio switch button. After turn it off and turn it on again, it doesn't work anymore. But even after find the network and configure the device with iwconfig, it doesn't work and I get this warning about DMA on dmesg: [ 141.275477] WARNING: at drivers/net/wireless/b43/dma.c:1098 parse_cookie() [ 141.275480] Pid: 0, comm: swapper Not tainted 2.6.24 #2 [ 141.275483] [] b43_dma_handle_txstatus+0xda/0x327 [b43] [ 141.275505] [] b43_interrupt_tasklet+0x63a/0x6b7 [b43] [ 141.275521] [] get_next_timer_interrupt+0x11e/0x18a [ 141.275531] [] tasklet_action+0x32/0x52 [ 141.275536] [] __do_softirq+0x35/0x75 [ 141.275541] [] do_softirq+0x22/0x26 [ 141.275545] [] irq_exit+0x29/0x58 [ 141.275549] [] do_IRQ+0x77/0x88 [ 141.275553] [] __update_rq_clock+0x1a/0xf3 [ 141.275559] [] common_interrupt+0x23/0x28 [ 141.275566] [] sys_delete_module+0xd1/0x18e [ 141.275571] [] handle_vm86_fault+0x38d/0x6c2 [ 141.275576] [] acpi_idle_enter_simple+0x124/0x180 [processor] [ 141.275589] [] acpi_idle_enter_bm+0xa5/0x241 [processor] [ 141.275599] [] cpuidle_idle_call+0x53/0x79 [ 141.275605] [] cpu_idle+0x4c/0x66 [ 141.275608] [] start_kernel+0x23c/0x241 [ 141.275613] [] unknown_bootoption+0x0/0x196 [ 141.275619] === So, I tried to not use DMA modprobing with pio=1 param, but I got this error: $> SIOCSIFFLAGS: Cannot allocate memory This error message was after if up, and not after modprobe. Br, David DMA seems to be necessary. Any idea about the problem? Br, David iwlist wlan0 scan ? output from same? You know the really nice thing about this list is I know no matter how much of a bastard I think I might be perceived as, if I answer before Michael I know it could have been worse ;-) (I'm human, you know...) Cheers, Ehud David Cohen wrote: I forgot to mention I'm using the firmware extracted from broadcom-wl-4.150.10.5.tar.bz2 and I got no error regarding to firmware on dmesg. David On Feb 1, 2008 1:47 PM, David Cohen <[EMAIL PROTECTED]> wrote: Hi, I have a HP nx6110 laptop with bcm4318 wireless card using wireless-2.6 tree (git-pulled: jan-31 2008). Unfortunately, the b43 module is not working well: - After if-up the wlan device, the radio is off (got from dmesg) but the radio led is on. - If I press the radio button, the radio turns on/off (got from dmesg also) but the ledsstays always on. - Even tuning the radio on, I can't find my home wireless network with 'iwlist scan' (but I can find from other laptop). Does anyone know if it is a known bug? Or does anyone can help me with that? Thanks in advance, David ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4318 problem on HP nx6110
dmesg ? iwlist wlan0 scan ? output from same? You know the really nice thing about this list is I know no matter how much of a bastard I think I might be perceived as, if I answer before Michael I know it could have been worse ;-) (I'm human, you know...) Cheers, Ehud David Cohen wrote: I forgot to mention I'm using the firmware extracted from broadcom-wl-4.150.10.5.tar.bz2 and I got no error regarding to firmware on dmesg. David On Feb 1, 2008 1:47 PM, David Cohen <[EMAIL PROTECTED]> wrote: Hi, I have a HP nx6110 laptop with bcm4318 wireless card using wireless-2.6 tree (git-pulled: jan-31 2008). Unfortunately, the b43 module is not working well: - After if-up the wlan device, the radio is off (got from dmesg) but the radio led is on. - If I press the radio button, the radio turns on/off (got from dmesg also) but the ledsstays always on. - Even tuning the radio on, I can't find my home wireless network with 'iwlist scan' (but I can find from other laptop). Does anyone know if it is a known bug? Or does anyone can help me with that? Thanks in advance, David ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Speed issue 2.6.24-rc5 after a few days. Reloading b43 corrects it.
After the system has been up a while -- in this case 5 days -- the data transfer rate appears slow and this is confirmed by various tools such as ftp and speedtest.net. Reassociating with the AP has no effect on this symptom. modprobe -r b43 && modprobe b43 corrects the symptom. What other diagnostics can I run next time I see this, so that I can provide better input as to what the problem is? Thanks, Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix rxheader channel parsing
Happy New Year, Michael!
:)
Ehud
Michael Buesch wrote:
> On Wednesday 02 January 2008 19:52:08 Larry Finger wrote:
>
>> Michael Buesch wrote:
>>
>>> This patch fixes the parsing of the RX data header channel field.
>>>
>>> The current code parses the header incorrectly and passes a wrong
>>> channel number and frequency for each frame to mac80211.
>>> The FIXMEs added by this patch don't matter for now as the code
>>> where they live won't get executed anyway. They will be fixed later.
>>>
>>> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
>>>
>>> ---
>>>
>>> John, as this is a bugfix, it should go into 2.6.24 if still possible.
>>>
>>> Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
>>> ===
>>> --- wireless-2.6.orig/drivers/net/wireless/b43/xmit.c 2007-12-30
>>> 20:30:03.0 +0100
>>> +++ wireless-2.6/drivers/net/wireless/b43/xmit.c2008-01-02
>>> 18:13:15.0 +0100
>>> @@ -549,21 +549,32 @@ void b43_rx(struct b43_wldev *dev, struc
>>> switch (chanstat & B43_RX_CHAN_PHYTYPE) {
>>> case B43_PHYTYPE_A:
>>> status.phymode = MODE_IEEE80211A;
>>> - status.freq = chanid;
>>> - status.channel = b43_freq_to_channel_a(chanid);
>>> - break;
>>> - case B43_PHYTYPE_B:
>>> - status.phymode = MODE_IEEE80211B;
>>> - status.freq = chanid + 2400;
>>> - status.channel = b43_freq_to_channel_bg(chanid + 2400);
>>> + B43_WARN_ON(1);
>>> + /* FIXME: We don't really know which value the "chanid"
>>> contains.
>>> +*So the following assignment might be wrong. */
>>> + status.channel = chanid;
>>> + status.freq = b43_channel_to_freq_5ghz(status.channel);
>>> break;
>>>
>> Shouldn't you just drop this case? No B PHY devices will ever use b43 and
>> the default branch will
>> issue the WARN_ON anyway.
>>
>
> I guess you misread the patch.
>
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Submitted. E Michael Buesch wrote: > On Tuesday 18 December 2007 22:09:24 Ehud Gavron wrote: > >> I did just check and you are right! It is a compiler bug despite the >> version being supposedly safe. >> two msleep(0); 's got inlined out of the way and the KEY_WLAN code ran >> as it's supposed to. >> >> I can't find gcc 4.3 on gnu's site and Fedora RPMs says 4.1.2 is the >> latest. Any clues as to how best to proceed ? >> > > Use an older one, maybe? 4.0 or 3.4. > 3.4 used to be pretty good, actually. > > >> Ehud >> PS Yes I realize this means it's not a b43 problem, but my problem with >> my compiler :) >> > > Cool. Can you please report this into the redhat bugzilla? > Maybe also quote the gcc bug I quoted, as it might be possible > that redhat backported this bug to their version (distributions > often backport stuff from newer upstream versions). > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Michael Buesch wrote:
> On Tuesday 18 December 2007 19:39:15 Ehud Gavron wrote:
>
>> Michael Buesch wrote:
>>
>>> On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
>>>
>>>
>>>> On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
>>>>
>>>>
>>>>>> And here's the code:
>>>>>>
>>>>>> if (unlikely(report_change)) {
>>>>>> b43info(wl,"EHUD: sleeping\n");
>>>>>> msleep(1);
>>>>>> b43info(wl,"EHUD: LED coming on\n);
>>>>>> input_report_key(poll_dev->input, KEY_WLAN, 1);
>>>>>> input_report_key(poll_dev->input, KEY_WLAN, 0);
>>>>>> }
>>>>>>
>>>>>> So my question (other than why do I need two messages and one msleep to
>>>>>> get my LED lit) is... what happened to the "EHUD: sleeping" debug
>>>>>> message? It never showed up on the console. I did this several times.
>>>>>> The full dmesg is attached.
>>>>>>
>>>>>> Ehud
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> This smells like a compiler bug.
>>>>> Can you try an older compiler version?
>>>>> (Most distros ship several versions)
>>>>>
>>>>>
>>>>>
>>>> Actually I do remember a gcc bug related to strict-aliasing.
>>>> What happens is that about two lines of source code are
>>>> skipped. So this might also apply here. We skip two lines.
>>>> But I don't remember the gcc bug #. :(
>>>>
>>>>
>>>>
>>> I think this is the one I was talking about:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
>>>
>>>
>>>
>> From Bugzilla:
>> Known to Work: 4.1.2 4.3.0
>> gcc --version
>> gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
>>
>>
>>
>>
>
> Please check this anyway. This really looks like a compiler bug.
> Why would it skip a printk otherwise?
>
>
I did just check and you are right! It is a compiler bug despite the
version being supposedly safe.
two msleep(0); 's got inlined out of the way and the KEY_WLAN code ran
as it's supposed to.
I can't find gcc 4.3 on gnu's site and Fedora RPMs says 4.1.2 is the
latest. Any clues as to how best to proceed ?
Thanks
Ehud
PS Yes I realize this means it's not a b43 problem, but my problem with
my compiler :)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Larry Finger wrote:
> Ehud Gavron wrote:
>
>> I've trimmed some of this.
>>
>> Michael Buesch wrote:
>>
>>>>> I have no idea. But I don't understand why waiting a random time up
>>>>> to 1000ms fails
>>>>> and a random time up to 1000ms + 1ms succeeds.
>>>>>
>>>>>
>> The patch I submitted had a newbie-error. Right before making the patch
>> I removed the debug messages. As it turns out it's not the msleep that
>> makes the difference. It's having TWO debug messages AND the msleep.
>>
>>
>> Yes, I know that sounds stupid. Here are the kernels I built to test
>> this stupid theory:
>> /boot/vmlinuz-2.6.24-rc5-1dm
>> /boot/vmlinuz-2.6.24-rc5-m1.dm
>> /boot/vmlinuz-2.6.24-rc5-dm.dm
>> /boot/vmlinuz-2.6.24-rc5-dm.m1
>> /boot/vmlinuz-2.6.24-rc5-duh
>>
>>
>> DM=display message
>> M1=msleep(1)
>> DUH=go back to square one, display message; msleep(1) ; display message.
>>
>>
>> This DOES WORK and DOES TURN ON THE LED. However...
>> Here's the really funny thing. Here are the messages:
>>
>> b43-phy0: Radio hardware status changed to ENABLED
>> b43-phy0: EHUD: LED coming on
>>
>> And here's the code:
>>
>>if (unlikely(report_change)) {
>>b43info(wl,"EHUD: sleeping\n");
>>msleep(1);
>>b43info(wl,"EHUD: LED coming on\n);
>>input_report_key(poll_dev->input, KEY_WLAN, 1);
>>input_report_key(poll_dev->input, KEY_WLAN, 0);
>>}
>>
>> So my question (other than why do I need two messages and one msleep to
>> get my LED lit) is... what happened to the "EHUD: sleeping" debug
>> message? It never showed up on the console. I did this several times.
>> The full dmesg is attached.
>>
>
> I do not understand the disappearance of the "sleeping" message.
>
> I have some questions. In the following excerpt from your dmesg, why do you
> get the USB disconnect
> and reconnect? Is that part of the Bluetooth hardware?
Yes.
> If you remove the debug messages and increase
> the msleep delay to 10, does it work?
>
I will try that once I get back home from work, as well as Michael's
suggestion for a different compiler.
Thanks,
Ehud
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Michael Buesch wrote:
On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,"EHUD: sleeping\n");
msleep(1);
b43info(wl,"EHUD: LED coming on\n);
input_report_key(poll_dev->input, KEY_WLAN, 1);
input_report_key(poll_dev->input, KEY_WLAN, 0);
}
So my question (other than why do I need two messages and one msleep to
get my LED lit) is... what happened to the "EHUD: sleeping" debug
message? It never showed up on the console. I did this several times.
The full dmesg is attached.
Ehud
This smells like a compiler bug.
Can you try an older compiler version?
(Most distros ship several versions)
Actually I do remember a gcc bug related to strict-aliasing.
What happens is that about two lines of source code are
skipped. So this might also apply here. We skip two lines.
But I don't remember the gcc bug #. :(
I think this is the one I was talking about:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
From Bugzilla:
Known to Work: 4.1.2 4.3.0
gcc --version
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
I've trimmed some of this.
Michael Buesch wrote:
I have no idea. But I don't understand why waiting a random time up to 1000ms
fails
and a random time up to 1000ms + 1ms succeeds.
The patch I submitted had a newbie-error. Right before making the patch
I removed the debug messages. As it turns out it's not the msleep that
makes the difference. It's having TWO debug messages AND the msleep.
Yes, I know that sounds stupid. Here are the kernels I built to test
this stupid theory:
/boot/vmlinuz-2.6.24-rc5-1dm
/boot/vmlinuz-2.6.24-rc5-m1.dm
/boot/vmlinuz-2.6.24-rc5-dm.dm
/boot/vmlinuz-2.6.24-rc5-dm.m1
/boot/vmlinuz-2.6.24-rc5-duh
DM=display message
M1=msleep(1)
DUH=go back to square one, display message; msleep(1) ; display message.
This DOES WORK and DOES TURN ON THE LED. However...
Here's the really funny thing. Here are the messages:
b43-phy0: Radio hardware status changed to ENABLED
b43-phy0: EHUD: LED coming on
And here's the code:
if (unlikely(report_change)) {
b43info(wl,"EHUD: sleeping\n");
msleep(1);
b43info(wl,"EHUD: LED coming on\n);
input_report_key(poll_dev->input, KEY_WLAN, 1);
input_report_key(poll_dev->input, KEY_WLAN, 0);
}
So my question (other than why do I need two messages and one msleep to
get my LED lit) is... what happened to the "EHUD: sleeping" debug
message? It never showed up on the console. I did this several times.
The full dmesg is attached.
Ehud
Linux version 2.6.24-rc5-1dm ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925
(Red Hat 4.1.2-33)) #11 SMP Tue Dec 18 08:32:21 MST 2007
Command line: ro root=LABEL=/ rhgb quiet
BIOS-provided physical RAM map:
BIOS-e820: - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
BIOS-e820: 0010 - 7fe81400 (usable)
BIOS-e820: 7fe81400 - 8000 (reserved)
BIOS-e820: f000 - f4007000 (reserved)
BIOS-e820: f4008000 - f400c000 (reserved)
BIOS-e820: fec0 - fec1 (reserved)
BIOS-e820: fed2 - feda (reserved)
BIOS-e820: fee0 - fee1 (reserved)
BIOS-e820: ffb0 - 0001 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 523905) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000FC0B0, 0014 (r0 DELL )
ACPI: RSDT 7FE8198A, 0044 (r1 DELLM07 27D60A0D ASL61)
ACPI: FACP 7FE82800, 0074 (r1 DELLM07 27D60A0D ASL61)
ACPI: DSDT 7FE83400, 4D7D (r1 INT430 SYSFexxx 1001 INTL 20050624)
ACPI: FACS 7FE91C00, 0040
ACPI: HPET 7FE82F00, 0038 (r1 DELLM071 ASL61)
ACPI: APIC 7FE83000, 0068 (r1 DELLM07 27D60A0D ASL47)
ACPI: ASF! 7FE82C00, 005B (r16 DELLM07 27D60A0D ASL61)
ACPI: MCFG 7FE82FC0, 003E (r16 DELLM07 27D60A0D ASL61)
ACPI: SLIC 7FE8309C, 0176 (r1 DELLM07 27D60A0D ASL61)
ACPI: TCPA 7FE83300, 0032 (r1 DELLM07 27D60A0D ASL61)
ACPI: SSDT 7FE81A11, 04DC (r1 PmRefCpuPm 3000 INTL 20050624)
No NUMA configuration found
Faking a node at -7fe81000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 523905) 1 entries of 3200 used
Bootmem setup node 0 -7fe81000
No mptable found.
[e200-e21f] PMD ->81000120 on node 0
[e220-e23f] PMD ->81000160 on node 0
[e240-e25f] PMD ->810001a0 on node 0
[e260-e27f] PMD ->810001e0 on node 0
[e280-e29f] PMD ->81000220 on node 0
[e2a0-e2bf] PMD ->81000260 on node 0
[e2c0-e2df] PMD ->810002a0 on node 0
[e2e0-e2ff] PMD ->810002e0 on node 0
[e2000100-e200011f] PMD ->81000320 on node 0
[e2000120-e200013f] PMD ->81000360 on node 0
[e2000140-e200015f] PMD ->810003a0 on node 0
[e2000160-e200017f] PMD ->810003e0 on node 0
[e2000180-e200019f] PMD ->81000420 on node 0
[e20001a0-e20001bf] PMD ->81000460 on node 0
Zone PFN ranges:
DMA 0 -> 4096
DMA324096 -> 1048576
Normal1048576 -> 1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0:0 -> 159
0: 256 -> 523905
On node 0 totalpages: 523808
DMA zone: 56 pages used for memmap
DMA zone: 1223 pages reserved
DMA zone: 2720 pages, LIFO batch:0
DMA32 zone: 7106 pages used for memmap
DMA32 zone: 512703 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Michael Buesch wrote: > On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote: > >> Michael Buesch wrote: >> >>> On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote: >>> >>> >>>> Ehud Gavron wrote: >>>> >>>> >>>>> If I manually turn the LED on (with the keyboard sequence for >>>>> KEY_WLAN), rfkill will turn the LED off when I turn the radio off >>>>> consistently but without the wait will never turn the LED back on. >>>>> >>>>> >>>> That makes no sense; let me rephrase. >>>> >>>> I can turn the LED on manually. Then when I turn the radio switch off, >>>> rfkill turns the LED off every time. >>>> So the "LED OFF by rfkill" works fine. >>>> >>>> No matter what I do... without that delay, rfkill will not turn the LED >>>> back on, despite the event clearly being called by code. >>>> >>>> >>>> >>>> >>>> >>> What happens if you completely remove the code that sends the two events? >>> >>> >>> >> The LED never comes on. >> >> I can make it come on/off with the key function, and if it's on and the >> radio is turned off the LED goes off. >> >> In other words I'm sure the hardware is turning the LED (and the BT LED) >> off. >> I'm also sure the hardware is not turning the LED back on. >> >> What other tests would you like me to do? >> > > I have no idea. But I don't understand why waiting a random time up to 1000ms > fails > and a random time up to 1000ms + 1ms succeeds. > You are right. Here are the tests I've done: 1. msleep(0) doesn't work. msleep(1) or higher does 2. remove msleep and set the poll interval to 3000ms, and I turn the radio on... and 2-3 seconds later b43 says "ENABLED" but the LED does not work. 3. the code in b43_rfkill_poll between the "ENABLED" message and where I'm putting the msleep() is one mutex unlock which was acquired ten lines previously so I can't see how that's relevant. Unless there's some weird race condition where releasing the mutex allows something else to happen which in its first 1msec prevents the keyboard event... I don't get it. Would there be any harm in moving the mutex to after the input_report_key sequence? Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Michael Buesch wrote: > On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote: > >> Ehud Gavron wrote: >> >>> If I manually turn the LED on (with the keyboard sequence for >>> KEY_WLAN), rfkill will turn the LED off when I turn the radio off >>> consistently but without the wait will never turn the LED back on. >>> >> That makes no sense; let me rephrase. >> >> I can turn the LED on manually. Then when I turn the radio switch off, >> rfkill turns the LED off every time. >> So the "LED OFF by rfkill" works fine. >> >> No matter what I do... without that delay, rfkill will not turn the LED >> back on, despite the event clearly being called by code. >> >> >> >> > > What happens if you completely remove the code that sends the two events? > > The LED never comes on. I can make it come on/off with the key function, and if it's on and the radio is turned off the LED goes off. In other words I'm sure the hardware is turning the LED (and the BT LED) off. I'm also sure the hardware is not turning the LED back on. What other tests would you like me to do? Thanks Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Ehud Gavron wrote: > > If I manually turn the LED on (with the keyboard sequence for > KEY_WLAN), rfkill will turn the LED off when I turn the radio off > consistently but without the wait will never turn the LED back on. That makes no sense; let me rephrase. I can turn the LED on manually. Then when I turn the radio switch off, rfkill turns the LED off every time. So the "LED OFF by rfkill" works fine. No matter what I do... without that delay, rfkill will not turn the LED back on, despite the event clearly being called by code. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Michael Buesch wrote: > On Tuesday 18 December 2007 10:39:14 Ehud Gavron wrote: > >> When the hardware switch is changed from OFF to ON there is a period of >> time before the hardware enables the LED to work at all. >> During this period of time the KEY_WLAN sequence has no effect. This >> means the LED is not turned on. >> >> With the delay, the hardware has time to enable the LED (but not turn it >> on), and then the KEY_WLAN sequence turns the LED on. >> >> > > >>>> + msleep(1); /* sleep 400usec to allow slow hardware >>>> to enable the LED */ >>>> > > Ok, but why the inconsistent comment? 400usec vs. 1msec > That came straight out of phy.c. I was looking for a method of doing a wait consistent with the rest of the code. > I'm not sure why this helps at all. We poll every 1000ms. > So why does it fix the LED to wait an additional microsecond? > I don't know. > Note that this function call is _not_ triggered by pressing the button. > It is polled, so completely asynchronous. > Ok. I do know that without the wait the function IS called, but the LED does not turn on. > Is it possible that we have some race condition in software somewhere > instead? > I can't see how. When I put debug messages in, I can see the KEY_WLAN going out and I've verified the pointer hasn't changed, but the LED does not turn on. The same sequence one second (or later) works every time and the LED goes on or off at will. If I manually turn the LED on (with the keyboard sequence for KEY_WLAN), rfkill will turn the LED off when I turn the radio off consistently but without the wait will never turn the LED back on. If I try the keyboard sequence while the radio is off the LED will not come on... leading me to suspect the hardware is preventing it from coming on, not anything in the software. BTW "I can't see how." also means "I don't know the code." E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
When the hardware switch is changed from OFF to ON there is a period of
time before the hardware enables the LED to work at all.
During this period of time the KEY_WLAN sequence has no effect. This
means the LED is not turned on.
With the delay, the hardware has time to enable the LED (but not turn it
on), and then the KEY_WLAN sequence turns the LED on.
Or, looking at it from a user's perspective:
1. Without this patch, SWITCH OFF, SWITCH ON, the LED stays off and
never comes back on without a modprobe -r b43 && modprobe b43
2. With this patch, SWITCH OFF, SWITCH ON, the LED comes back on and
works the way it's supposed to.
Ehud
Michael Buesch wrote:
> On Tuesday 18 December 2007 06:42:56 Ehud Gavron wrote:
>
>> A little test code answered my own question. I don't know if this is
>> the best way to do it, but this patch fixes the problem.
>>
>> Ehud
>>
>> --- drivers/net/wireless/b43/rfkill.c.orig 2007-12-17
>> 22:39:31.0 -0700
>> +++ drivers/net/wireless/b43/rfkill.c 2007-12-17 22:39:54.0 -0700
>> @@ -68,6 +68,7 @@ static void b43_rfkill_poll(struct input
>> /* send the radio switch event to the system - note both a key press
>> * and a release are required */
>> if (unlikely(report_change)) {
>> + msleep(1); /* sleep 400usec to allow slow hardware
>> to enable the LED */
>> input_report_key(poll_dev->input, KEY_WLAN, 1);
>> input_report_key(poll_dev->input, KEY_WLAN, 0);
>> }
>>
>
> I'm sorry, I did not understand your previous mail.
> What exactly does this fix? Can you explain in one or two sentences?
>
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
A little test code answered my own question. I don't know if this is
the best way to do it, but this patch fixes the problem.
Ehud
--- drivers/net/wireless/b43/rfkill.c.orig 2007-12-17
22:39:31.0 -0700
+++ drivers/net/wireless/b43/rfkill.c 2007-12-17 22:39:54.0 -0700
@@ -68,6 +68,7 @@ static void b43_rfkill_poll(struct input
/* send the radio switch event to the system - note both a key press
* and a release are required */
if (unlikely(report_change)) {
+ msleep(1); /* sleep 400usec to allow slow hardware
to enable the LED */
input_report_key(poll_dev->input, KEY_WLAN, 1);
input_report_key(poll_dev->input, KEY_WLAN, 0);
}
Ehud Gavron wrote:
> We worked out the SPROM is the same... but here are some interesting twists.
>
> When switched off
> 1. The LED is switched off by hardware, not b43
> 2. B43 does send the event as expected but the LED is already off
>
> When switch on
> 1. The LED is not switched on by hardware
> 2. B43 does send the event as expected but the LED does not turn on
>
> When the code to pop the LED is triggered more often as in
> When I changed in rfkill.c
> if (unlikely(report_change)) {
>
> to
> if (!unlikely(report_change)) {
>
> Then the LED came on and off every two seconds or so until I set the
> switch to OFF at which point the LED stayed off but the events kept
> happening. (I put debug messages before and after also spitting out
> poll_dev->input to check its value for corruption. It was all good).
>
> I can manually trigger the event (on or off) using setkeycodes, so I suspect
> a possible DELAY of the LED coming on after a B43 enable event... for
> hardware that needs it... would fix it.
>
> Thoughts?
>
> Ehud
>
>
> Larry Finger wrote:
>
>> Ehud,
>>
>> One possibility that I didn't think about before is that your LED mapping in
>> the SPROM has some
>> quirk that is not handled properly. Please run the following two commands
>>
>> SSB_SPROM=$(find /sys -name ssb_sprom)
>> sudo cat $SSB_SPROM > sprom.txt
>>
>> and mail me the file sprom.txt that results.
>>
>> Thanks,
>>
>> Larry
>>
>>
> ___
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
We worked out the SPROM is the same... but here are some interesting twists.
When switched off
1. The LED is switched off by hardware, not b43
2. B43 does send the event as expected but the LED is already off
When switch on
1. The LED is not switched on by hardware
2. B43 does send the event as expected but the LED does not turn on
When the code to pop the LED is triggered more often as in
When I changed in rfkill.c
if (unlikely(report_change)) {
to
if (!unlikely(report_change)) {
Then the LED came on and off every two seconds or so until I set the
switch to OFF at which point the LED stayed off but the events kept
happening. (I put debug messages before and after also spitting out
poll_dev->input to check its value for corruption. It was all good).
I can manually trigger the event (on or off) using setkeycodes, so I suspect
a possible DELAY of the LED coming on after a B43 enable event... for
hardware that needs it... would fix it.
Thoughts?
Ehud
Larry Finger wrote:
> Ehud,
>
> One possibility that I didn't think about before is that your LED mapping in
> the SPROM has some
> quirk that is not handled properly. Please run the following two commands
>
> SSB_SPROM=$(find /sys -name ssb_sprom)
> sudo cat $SSB_SPROM > sprom.txt
>
> and mail me the file sprom.txt that results.
>
> Thanks,
>
> Larry
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Larry Finger wrote: > Ehud Gavron wrote: > ... >> If I use the kill-switch both the WiFi and the BT LEDs go off. >> When I switch back on the BT LED lights but the WiFi does not. > As long as you are using the latest "everything" branch wireless-2.6, and > rfkill-input is built for > your system, it would seem that KEY_WLAN (238) is not the code needed to turn > your radio LED on. Is > it possible for you to check that out? > > The following corrects the problem: sudo setkeycodes e011 238 I'm not sure why it's not defined permanently or why I need to manually define it, but I can google that offlist. It's not a b43 issue. For reference on other Dell'isms: http://giel.operation0.org/keyboard-soft-release/hotkey-setup/dell.hk Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
Larry Finger wrote: > Ehud Gavron wrote: > >> First, thanks for making the LED light up again, Larry and Michael. >> >> If I use the kill-switch both the WiFi and the BT LEDs go off. >> When I switch back on the BT LED lights but the WiFi does not. >> Dmesg shows: >> Dec 16 17:43:30 egdell kernel: input: b43-phy0 as /class/input/input11 >> Dec 16 17:43:31 egdell kernel: Registered led device: b43-phy0:tx >> Dec 16 17:43:31 egdell kernel: Registered led device: b43-phy0:rx >> Dec 16 17:43:31 egdell kernel: Registered led device: b43-phy0:radio >> Dec 16 17:43:31 egdell kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready >> Dec 16 17:44:17 egdell kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link >> becomes ready >> Dec 16 17:44:45 egdell kernel: usb 1-2.4: USB disconnect, address 4 >> Dec 16 17:44:45 egdell kernel: b43-phy0: Radio hardware status changed >> to DISABLED >> Dec 16 17:44:49 egdell kernel: b43-phy0: Radio turned on by software >> Dec 16 17:44:49 egdell kernel: b43-phy0: The hardware RF-kill button >> still turns the radio physically off. Press the button to turn it on. >> Dec 16 17:44:58 egdell kernel: usb 1-2.4: new full speed USB device >> using ehci_hcd and address 6 >> Dec 16 17:44:58 egdell kernel: usb 1-2.4: configuration #1 chosen from 1 >> choice >> Dec 16 17:44:58 egdell kernel: b43-phy0: Radio hardware status changed >> to ENABLED >> Dec 16 17:45:01 egdell kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link >> becomes ready >> Dec 16 17:45:02 egdell kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link >> becomes ready >> >> Reloading b43 (modprobe -r b43 && modprobe b43) restores the WiFi LED. >> >> Having glanced at Michael's last patch to avoid the race condition... I >> know that code is beyond me. >> > > As long as you are using the latest "everything" branch wireless-2.6, and > rfkill-input is built for > your system, it would seem that KEY_WLAN (238) is not the code needed to turn > your radio LED on. Is > it possible for you to check that out? > > Larry > Larry, I'm using the latest "everything" branch. How do I find that code? E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
2.6.24-rc5 the LED does not come on after a switch-off switch-on
First, thanks for making the LED light up again, Larry and Michael. If I use the kill-switch both the WiFi and the BT LEDs go off. When I switch back on the BT LED lights but the WiFi does not. Dmesg shows: Dec 16 17:43:30 egdell kernel: input: b43-phy0 as /class/input/input11 Dec 16 17:43:31 egdell kernel: Registered led device: b43-phy0:tx Dec 16 17:43:31 egdell kernel: Registered led device: b43-phy0:rx Dec 16 17:43:31 egdell kernel: Registered led device: b43-phy0:radio Dec 16 17:43:31 egdell kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready Dec 16 17:44:17 egdell kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Dec 16 17:44:45 egdell kernel: usb 1-2.4: USB disconnect, address 4 Dec 16 17:44:45 egdell kernel: b43-phy0: Radio hardware status changed to DISABLED Dec 16 17:44:49 egdell kernel: b43-phy0: Radio turned on by software Dec 16 17:44:49 egdell kernel: b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. Dec 16 17:44:58 egdell kernel: usb 1-2.4: new full speed USB device using ehci_hcd and address 6 Dec 16 17:44:58 egdell kernel: usb 1-2.4: configuration #1 chosen from 1 choice Dec 16 17:44:58 egdell kernel: b43-phy0: Radio hardware status changed to ENABLED Dec 16 17:45:01 egdell kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Dec 16 17:45:02 egdell kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Reloading b43 (modprobe -r b43 && modprobe b43) restores the WiFi LED. Having glanced at Michael's last patch to avoid the race condition... I know that code is beyond me. Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix radio LED problem
Just as a reminder in the hopes it triggers some thought, Fedora 2.6.23.1-42.fc8 worked... but 1-49.fc9 didn't, and none of everything or wireless-2.6 worked. If you think of anything I can test... let me know. It's early. :) Ehud Larry Finger wrote: > Ehud Gavron wrote: >> [EMAIL PROTECTED] ~]# SSB_SPROM=$(find /sys -name ssb_sprom) >> [EMAIL PROTECTED] ~]# sudo cat $SSB_SPROM > ssb_sprom_copy >> [EMAIL PROTECTED] ~]# more ssb_sprom_copy >> 0130070028100800BE0D00FF1143008002100018 >> >> >> 1A000E921F40 >> >> >> 36303D15A0FA79FEFF834AFF3EFF494A02FF >> >> >> 0CFF021F > > Your SPROM contains the same LED data as mine does. I have no idea why > your LED doesn't toggle the way mine does. > > I have no idea what to try next. Sorry. > > Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix radio LED problem
[EMAIL PROTECTED] ~]# SSB_SPROM=$(find /sys -name ssb_sprom) [EMAIL PROTECTED] ~]# sudo cat $SSB_SPROM > ssb_sprom_copy [EMAIL PROTECTED] ~]# more ssb_sprom_copy 0130070028100800BE0D00FF1143008002100018 1A000E921F40 36303D15A0FA79FEFF834AFF3EFF494A02FF 0CFF021F Larry Finger wrote: > Ehud Gavron wrote: >> Yes. See below. The USB device is the BT radio. >> >> Ehud >> usb 1-2.4: USB disconnect, address 4 >> b43-phy0: Radio hardware status changed to DISABLED >> usb 1-2.4: new full speed USB device using ehci_hcd and address 7 >> usb 1-2.4: configuration #1 chosen from 1 choice >> b43-phy0: Radio hardware status changed to ENABLED > > OK, the system is reacting to the switch, but the LED is not. Could > you please run the following two commands and send me the file > ssb_sprom_copy? > > SSB_SPROM=$(find /sys -name ssb_sprom) > sudo cat $SSB_SPROM > ssb_sprom_copy > > Thanks, > > Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix radio LED problem
Yes. See below. The USB device is the BT radio. Ehud usb 1-2.4: USB disconnect, address 4 b43-phy0: Radio hardware status changed to DISABLED usb 1-2.4: new full speed USB device using ehci_hcd and address 7 usb 1-2.4: configuration #1 chosen from 1 choice b43-phy0: Radio hardware status changed to ENABLED Larry Finger wrote: > Ehud Gavron wrote: > >> This does not correct the LED issue in my Dell Latitude 620. >> >> Let me know how I can help debug this. I'm available all night and I >> can build a new kernel in about 5 minutes... >> > > When you turn the radio off/on, do you see the following messages? > > b43-phy0: Radio hardware status changed to DISABLED > b43-phy0: Radio hardware status changed to ENABLED > > Larry > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix radio LED problem
This does not correct the LED issue in my Dell Latitude 620.
Let me know how I can help debug this. I'm available all night and I
can build a new kernel in about 5 minutes...
Ehud
[EMAIL PROTECTED] leds]# ls
b43-phy0:radio b43-phy0:rx b43-phy0:tx
[EMAIL PROTECTED] leds]# cat */uevent
PHYSDEVPATH=/devices/pci:00/:00:1c.1/:0c:00.0/ssb0:0
PHYSDEVBUS=ssb
PHYSDEVDRIVER=b43
PHYSDEVPATH=/devices/pci:00/:00:1c.1/:0c:00.0/ssb0:0
PHYSDEVBUS=ssb
PHYSDEVDRIVER=b43
PHYSDEVPATH=/devices/pci:00/:00:1c.1/:0c:00.0/ssb0:0
PHYSDEVBUS=ssb
PHYSDEVDRIVER=b43
...
input: b43-phy0 as /class/input/input11
Registered led device: b43-phy0:tx
Registered led device: b43-phy0:rx
Registered led device: b43-phy0:radio
...
[EMAIL PROTECTED] input]# more input11/input\:event11/uevent
MAJOR=13
MINOR=75
[EMAIL PROTECTED] input]# more input11/uevent
PRODUCT=19/1028/0/0
NAME="b43-phy0"
EV==3
KEY==4000 0 0 0
MODALIAS=input:b0019v1028pe-e0,1,kEE,ramlsfw
Larry Finger wrote:
> Since addition of the rfkill callback, the LED associated with the off
> switch on the radio has not worked for several reasons:
>
> (1) Essential data in the rfkill structure were missing.
> (2) The rfkill structure was initialized after the LED initialization.
> (3) There was a minor memory leak if the radio LED structure was inited.
>
> Once the above problems were fixed, additional difficulties were noted:
>
> (4) The radio LED was in the wrong state at startup.
> (5) The radio switch had to be manipulated twice for each state change.
> (6) A circular mutex locking situation existed.
>
> This patch fixes all of the above.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John and Michael,
>
> These changes are mostly obvious. The most complicated is the fixing of the
> circular locking between the rfkill and wl_dev mutexes. This was acomplished
> by moving the rfkill_init() call to the beginning of b43_op_start() and the
> rfkill_exit() call to the end of b43_op_stop().
>
> Techically, these changes are fixes for the radio LED regression between
> bcm43xx and b43. It doesn't matter to me if they are pushed into 2.6.24, or
> left for 2.6.25.
>
> Larry
> ---
>
> leds.c |1 +
> main.c | 25 +++--
> rfkill.c | 14 --
> 3 files changed, 28 insertions(+), 12 deletions(-)
>
>
> Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c
> +++ wireless-2.6/drivers/net/wireless/b43/rfkill.c
> @@ -60,8 +60,12 @@ static void b43_rfkill_poll(struct input
> }
> mutex_unlock(&wl->mutex);
>
> - if (unlikely(report_change))
> - input_report_key(poll_dev->input, KEY_WLAN, enabled);
> + /* send the radio switch event to the system - note both a key press
> + * and a release are required */
> + if (unlikely(report_change)) {
> + input_report_key(poll_dev->input, KEY_WLAN, 1);
> + input_report_key(poll_dev->input, KEY_WLAN, 0);
> + }
> }
>
> /* Called when the RFKILL toggled in software. */
> @@ -133,6 +137,12 @@ void b43_rfkill_init(struct b43_wldev *d
> rfk->poll_dev->poll = b43_rfkill_poll;
> rfk->poll_dev->poll_interval = 1000; /* msecs */
>
> + rfk->poll_dev->input->name = rfk->name;
> + rfk->poll_dev->input->id.bustype = BUS_HOST;
> + rfk->poll_dev->input->id.vendor = dev->dev->bus->boardinfo.vendor;
> + rfk->poll_dev->input->evbit[0] = BIT(EV_KEY);
> + set_bit(KEY_WLAN, rfk->poll_dev->input->keybit);
> +
> err = rfkill_register(rfk->rfkill);
> if (err)
> goto err_free_polldev;
> Index: wireless-2.6/drivers/net/wireless/b43/main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/b43/main.c
> +++ wireless-2.6/drivers/net/wireless/b43/main.c
> @@ -2156,7 +2156,6 @@ static void b43_mgmtframe_txantenna(stru
> static void b43_chip_exit(struct b43_wldev *dev)
> {
> b43_radio_turn_off(dev, 1);
> - b43_leds_exit(dev);
> b43_gpio_cleanup(dev);
> /* firmware is released later */
> }
> @@ -2184,11 +2183,10 @@ static int b43_chip_init(struct b43_wlde
> err = b43_gpio_init(dev);
> if (err)
> goto out; /* firmware is released later */
> - b43_leds_init(dev);
>
> err = b43_upload_initvals(dev);
> if (err)
> - goto err_leds_exit;
> + goto err_gpio_clean;
> b43_radio_turn_on(dev);
>
> b43_write16(dev, 0x03E6, 0x);
> @@ -2267,8 +2265,7 @@ out:
>
> err_radio_off:
> b43_radio_turn_off(dev, 1);
> -err_leds_exit:
> - b43_leds_exit(dev);
> +err_gpio_clean:
> b43_gpio_cleanup(dev);
> return err;
> }
> @@ -2703,7 +2700,8 @@ static int b43_antenna_from_ieee80211(u8
> static int b43_op_config(struct ieee80211_hw *hw, struct ieee80211_conf
Re: [RFC/T] b43: Fix Radio On/Off LED action
Michael Buesch wrote: > On Tuesday 27 November 2007 17:28:33 Larry Finger wrote: > >> Michael Buesch wrote: >> >>> On Tuesday 27 November 2007 17:03:57 Larry Finger wrote: >>> This is not how led triggers work. >>> You are shortcutting the whole thing here. So you could as well >>> remove the whole rfkill and LEDs code. >>> >> It just plain doesn't work now. What I'm trying to do is get something to >> the users that will >> restore the behavior they want while we work out the details of the rfkill >> and LEDs code. >> > > Well, ok. But we don't apply this to mainline. As > a temporary patch for users it's OK. > Yes, it is! :) Works great! $ uname -a Linux egdell.wetwork.net 2.6.24-rc3-LF27NOV2007 #2 SMP Tue Nov 27 09:19:11 MST 2007 x86_64 x86_64 x86_64 GNU/Linux E > >>> Please properly register the LED in the leds code and >>> add a default LED trigger for the rfkill trigger. >>> This has several advantages to the user, among the possiblility to >>> reassign a LED to a different trigger. >>> >> How do I do that? >> > > Well, what you basically have to do it restore the old > mapping in b43_map_led(). > Look at the "case B43_LED_RADIO_ALL" (and below) statement. > It maps these LEDs to the rfkill trigger. > So you have to find out which behaviour value your LED has and > map that to the rfkill trigger in this function. > > So when the rfkill LED trigger triggers, it will enable/disable this LED. > That's all done behind the scenes. > > @@ -70,11 +75,13 @@ static int b43_rfkill_soft_toggle(void * struct b43_wldev *dev = data; struct b43_wl *wl = dev->wl; int err = 0; + int lock = mutex_is_locked(&wl->mutex); if (!wl->rfkill.registered) return 0; - mutex_lock(&wl->mutex); + if (!lock) + mutex_lock(&wl->mutex); >>> Nah, it shouldn't be locked by "current" in the first place, here. >>> (I guess that's what you are trying to check here). >>> That's what the !registered check above is for. >>> This !lock check is racy. >>> >> If you recall my message from yesterday, I got a locking error. That is what >> I'm trying to prevent. >> I know it is racy, but I don't know the correct way to do it. >> > > I think RFkill has a bad design regarding this. > It does synchronously call back into the driver from a call made by > the driver. That is broken by design. Maybe it's best to fix this > in rfkill and let it asynchronously call back on rfkill_init. > Synchronous callbacks from calls made by drivers are broken by design > and will lead to recursive lockings. We can not fix this in the driver, > nor work around it in a sane way. We can hack around it, though, which > is what the !registered flag tries to do. Though, it seems it doesn't > work. :) > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
LEDs work with Fedora Kernel 2.6.23.1-42.fc8. LEDs NOT with Fedora Kernel 2.6.23.1-49.fc8 LEDs NOT with everything/2.6.24-rc2 LEDs NOT with wireless-2.6/2.6.24-rc3 I have the same settings in dot config as Larry does below and I have the same info except for ...uevent has a power button but I didn't see anything in any ...uevent that looked related to B43. I'd post a uname -a but you have the kernel names above. I'd post a dmesg but they are unchanged. I'd post an iwconfig but they don't matter. EVERYTHING WORKS except for the LEDs except they do work with the earlier Fedora kernel but not the latter one. Ehud Larry Finger wrote: Michael Buesch wrote: Dunno. That's a poll-input-dev problem then. Do you have all poll-input options enabled? I think so. I have the following in .config: CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set CONFIG_INPUT_POLLDEV=m I also tried it with the three components built in rather than as modules. It did not make a difference. Because the log has the message "input: Unspecified device as /class/input/input7", I have looked at the contents of /sys/class. I find that "/sys/class/input/input7/uevent" contains PRODUCT=0/0/0/0 EV==1 MODALIAS=input:bvpe-e0,kramlsfw whereas /sys/class/input/input6/uevent has PRODUCT=19/0/1/0 NAME="Power Button (CM)" PHYS="PNP0C0C/button/input0" EV==3 KEY==10 0 MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw I have no idea how to interpret these data; however, #6 certainly has a lot more information than #7. I'm pretty sure #7 is associated with the BCM4311. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
Excellent suggestion. I'll test that upon my return home and get back here. Thanks! E Holger Schurig wrote: > Do you have any logs of the APs, e.g. do they log that somebody > tried to associate and failed? > > Did you try a workaround to put all 3 APs to the same frequency? > If you then observe the same problem, you could then use > wireshark to capture a log of what happens "in the air". If the > APs have different frequencies, then your monitoring WLAN card > can't follow the maybe-roaming-card in sync, therefore use > temporarily only one frequency. > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
I think this may be related. If it isn't, my apologies for thread crapping. If it is, I'm willing to do what I can to help find the problem and correct it. I've had occasional troubles with all sorts of association related issues, and the only solution I've found is to remove the b43 module and reinsert it. (modprobe -r b43 && sleep 1 && modprobe b43). Here are different scenarios that are 100% reproducable: FYI All of my house uses the same ESSID with the same WEP key and different channels (1,6,11 from one end to the other). If I move from the living room (Ch1) to the bedroom (Ch11) then I am still associated to the Living Room AP. ***SOMETIMES*** a "iwconfig wlan0 ap off" will make it reassociate with the bedroom AP ***NEVER*** does an "iwconfig wlan0 essid same-essid" do anything ***SOMETIMES*** does an "iwconfig wlan0 essid no-such-essid && sleep 1 && iwconfig wlan0 essid origina-essid" works ***ALWAYS*** "modprobe -r b43 && sleep 1 && modprobe b43" works If I move from the bedroom (Ch11) to the living room (Ch1) I DON'T NEED TO DO ANYTHING. All APs are buffalo airbridges with the same rev firmware. I find similar symptoms at my Las Vegas hotel where I am this weekend. Here are the exact symptoms: 1. Link quality reads 0. No iwconfig command will fix it (most of the time, sometimes the change of ESSID or ap off will fix it). 2. dmesg repeats: wlan0: authentication with AP 00:50:bf:b1:da:64 timed out 3. an iwlist wlan0 scan DOES show the active APs, but no matter which I choose none will associate 4. I just upgraded to F8 and am now using NM to manage the link (most of the time). Most of the time it does work but every now and then (like here at the hotel after I rebooted the laptop) it will fail to connect. Symptoms #1 and #2 appear in the log, and the "modprobe -4/modprobe" fixes it. I'm not sure if this is a mac80211 or a b43 bug... and if anyone has ideas to try I'm game. Ehud Pavel Roskin wrote: > 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. > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Request for information
Based on your problem description... there isn't one. Based on your uname -a ... there isn't one. Based on your dmesg... there isn't one. This is like a "locked room mystery", right, you want us to "solve the problem" without the problem being a. mentioned b. described c. error messages mentioned or even d. the environment described. Wow, you have a lot of faith. Ehud PS Good thing you have two whole web pages! Perhaps that way you can be famous in your genius. evan foss wrote: Sorry I meant to send this to the list. On Nov 10, 2007 6:12 PM, evan foss <[EMAIL PROTECTED]> wrote: I am not sure if this is correct as I still don't have the b43 driver working but here is my boxes data. 013063133C100800BE0D00FF11430080021000181400B7A5155442303D15A0FA79FEFF834AFF3EFF494A02FF53550CFF020A The box is a compaq v3019us the chip is a bcm4311. For some reason the lspci reads this instead of what it read under 2.6.20-r6. 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) Subsystem: Hewlett-Packard Company Unknown device 1363 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM94311MCG
I'm really not sure why you're ***'ing out your MAC addresses. At any rate your current problem is you're not associated with an AP. # iwlist wlan0 scan | grep Cell | sed -e "s/\(.*Address:\)\(.*\)/\2/g" | xargs -i$ iwconfig wlan0 ap $ See how annoying it gets when you leave out useful but not security-related information? Ehud Ruggiero wrote: thanks for informations,i followed your suggestions...but i think i'm missing something...here there are other informations: [EMAIL PROTECTED] ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:16:D4:DF:*:* UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:21 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8602 errors:0 dropped:0 overruns:0 frame:0 TX packets:8602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:69166424 (65.9 MiB) TX bytes:69166424 (65.9 MiB) wlan0 Link encap:Ethernet HWaddr 00:19:7E:84:*:* inet addr:192.168.1.80 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) wmaster0 Link encap:UNSPEC HWaddr *19-7E-84-*D3-D8-98-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [EMAIL PROTECTED] ~]# iwconfig lono wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11g ESSID:"* Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:** Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 [EMAIL PROTECTED] ~]# iwlist scan loInterface doesn't support scanning. eth0 Interface doesn't support scanning. wmaster0 Interface doesn't support scanning. wlan0 Scan completed : Cell 01 - Address: *0C:41:19:2D:* ESSID:"" Mode:Master Channel:11 Frequency:2.462 GHz Quality=204/146 Signal level=-206 dBm Noise level=-67 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=12e26229 thanks again for helping smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM94311MCG
$ su - and don't forget to ifconfig the interface up (in addition to all the iwconfigs, MUST ifconfig it up) Ehud 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 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 bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Loading firmware version 351.126 (2006-07-29 05:54:02) bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=5, tgt=62). Disabling TX power adjustment. bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 32-bit DMA initialized bcm43xx_mac80211: Wireless interface started thanks a lot for helping ruggiero - Original Message - From: "Larry Finger" <[EMAIL PROTECTED]> To: "Ruggiero" <[EMAIL PROTECTED]> Cc: Sent: Thursday, November 08, 2007 4:53 PM Subject: Re: BCM94311MCG Ruggiero wrote: could u suggest me any good distribution that i can use? regards ruggiero Fedora 7 has the configuration set properly. There are likely others as well. Larry smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43, b43legacy questions
dmesg | grep b43 The version with F7 wants the v4 microcode files with the *old* names (bcm43xx_*) instead of the new ones. dmesg will have the clues. Ehud Gene Heskett wrote: How do I tell which of these drivers to use with the 2.6.23.1-21.fc7 fedora kernel. I've removed the alias's from /etc/modprobe.conf that said wlan0 was ndiswrapper, and NM enables the radio but cannot connect. After a reboot with no aliases set its b43, mac80211, rc80211_simple and ssb that show in an lsmod|grep b43. NM and the dispatcher are enabled. Its an HP lappy, and lspci says its a "Broadcom Corporation BCM4318 [AirForce One 54G] 802-11g Wireless LAN Controller (rev 02) Whats next? smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Discussion of BCM43xx wireless mini-pc card on an HP Pavillion dv9012 series Laptop with Gutsy
As the son of a physicist and someone who appreciates GOOD DOCUMENTATION OF A PROBLEM AND SOLUTION I have to echo Larry's kudos. This was a well-documented analytical approach to solving the problem. Undoubtedly since the world is not perfect and we must deal with $40 APs we'll all see this at some point or another :) Thanks! Ehud Larry Finger wrote: Harry Wert wrote: If this is addressed to the wrong Forum, please feel free to forward same to any other Forum wherein it might be helpful. This commentary is intended to be of help to others who may be facing similar Wireless problems. I make no claim for originality. My HP Pavilion dv9012 series laptop with internal BCM94311MCG wlan mini-PCI card has worked flawlessly with VISTA, SuSE SLED10, Dapper, and Fiesty. When I upgraded to Gutsy, downloaded the Restricted Firmware, and went on-line it worked immediately but Download speeds ran from 20kbs to ~ 60kbs. This, with a DSL broadband line rated and tested for 7Mbs. I communicated with others via this and other Forums, and also did many Google searches attempting to resolve this problem, but to no avail. Finally, I was able to locate the cause and corrective action necessary to restore full 7mbs speeds by means of a systematic debug process which worked, and is 100% repeatable. My apologies in advance to the BCM43xx development group who were both helpful, and had the patience to stick with me, as the problem had nothing to do with the Firmware. To isolate the problem Vista was run on this dual-boot laptop, which also contains Gutsy. The BCM94311MCG wlan mini-PCI performance was identical to that of Gutsy. Conclusion: could be a defective BCM94311MCG wlan mini-PCI. Next I used a Thinkpad Laptop (Dual-boot) running Xp and Fiesty. Results were identical, low-speed identical to that above, but with Totally different hardware; ie, it does not use a BCM94311MCG wlan mini-PCI card. Conclusion: The BCM94311MCG wlan mini-PCI card and the firmware for same is not the problem. Next step was to disconnect my internal Linksys router from my internal Network, then connect directly to my DSL Modem via Ethernet cable to the HP Laptop. Result was full DSL 7Mbs speed. Conclusion: problem must be associated with the Linksys wireless "B" Broadband router. The Internal Network could not be the problem as it was previously checked for up to 100Mbs transfer rates. The Linksys router was next tested by bypassing the wireless part and connected to the Laptop via Ethernet cable. Result: Full DSL 7Mbs performance. Back to square One! To finally isolate where the Linksys problem was, everything was reconnected to it's initial state, rebooted and speed retested. It was unchanged at 20kbs to ~ 60kbs data rate. Using a wired connection to the Linksys router was still a full 7Mbs rate. Conclusion: The Linksys router in the wireless mode is clearly the problem. Finally, the Linksys router was given a Full reset. The procedure to setup from scratch was followed to completion by re-entering all the necessary information as necessary for operation with the DSL modem. Result: Problem solved. Full wireless operation with my HP Pavilion dv9012 and the BCM94311MCG wlan mini-PCI, now produces the identical 7Mbs data rate as the DSL Modem itself. How the Linksys Router lost it's mind is unknown, as it is on an active UPS system. Sorry for the long-winded update, but systematic thought processes are a necessary attribute for a Physicist! After nearly two weeks of intermittent investigation I felt compelled to tell someone! You did a good job of analyzing the problem. As a retired physicist and a former reviewer for Phys. Rev., I have to ask "What was the model and version of the Linksys wireless router?" These consumer-grade access points sometimes lose their minds for no reason. Usually a reboot or reset is all that is needed, but I have one Linksys BEW11S4 Ver. 4 that would not connect at all. It started working when the firmware was reflashed. The strange part is that the "new" version was identical to the "old" one. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: What is the right way to pull the wireless-dev + b43 from the git tree?
Thank you. I must have missed that note. The new tree works great. RIP wireless-dev. Long Live Everything. Ehud Johannes Berg wrote: > wireless-dev is dead, see > http://marc.info/?l=linux-wireless&m=119152616425736&w=2 > > johannes > > > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
What is the right way to pull the wireless-dev + b43 from the git tree?
Here's the script that used to work: #!/bin/sh git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git everything cd everything git checkout -b everything origin/everything Here's what the first git buys me yesterday and today: Initialized empty Git repository in /home/everything/.git/ fatal: The remote end hung up unexpectedly fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git' failed. What is the "right" way to pull the latest tree + the b43 drivers? Thanks! Ehud ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Can't get wireless working with bcm43xx driver
Ehud Gavron wrote: There are two drivers that support the hardware. The new one (the one you want) that works with mac80211 is b43. It uses v4 firmware. The older one (the one you don't want) works with ieee80211softmac is b43legacy. It uses v3 firmware. Disregard the rest of my answer... I missed: Larry Finger wrote: The above message is pretty clear. We don't support that 80211 core revision (yet). My bad. Your hardware is too new for my suggestion. Ehud smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Can't get wireless working with bcm43xx driver
There are two drivers that support the hardware. The new one (the one
you want) that works with mac80211 is b43. It uses v4 firmware.
The older one (the one you don't want) works with ieee80211softmac is
b43legacy. It uses v3 firmware.
I would download the latest wireless-dev kernel (2.6.23-rc6)... build it
and b43... and run that. It's what I do on a Dell Latitude with the
same 4311 card ("1390").
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.g
it everything
cd everything
git checkout -b everything origin/everything
nice make -j3
nice make -j3 modules_install
nice make -j3 install
[reboot and select kernel 2.6.23-rc6]
Works like a charm for me... has since 2.6.22something.
Ehud
Shocky wrote:
Hi,
I recently bought an HP Pavilion dv2412ca laptop, which came with Vista
pre-installed. I backed it up, then reformatted and installed Mandriva
2007.1.
The laptop has a builtin wireless card that lspci identifies as a "Broadcom
Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 02)". I couldn't get
it working with either bcm43xx or ndiswrapper using the Vista driver.
I got an XP driver for it from the HP support web site (sp34152.exe), and was
able to extract it using wine. I still couldn't get it to work with bcm43xx,
but I got it sort of working with ndiswrapper. I say "sort of" because it was
very flakey. It would usually connect when I first booted if the AP was
within reach, but if it lost the signal there was no way to make it reconnect
other than rebooting, and it wouldn't reconnect after suspend. This was with
Mandriva's 2.6.17-13 kernel, and wireless_tools version 28. I upgraded the
kernel to 2.6.17-15 (the latest available for 2007.1), but that didn't help.
Now I'm trying again with bcm43xx. I downloaded the source tarball for 2.6.22
from kernel.org and built a custom kernel (and I turned on wireless and
bcm43xx debugging while I was at it). I also got an SRPM from Mandriva cooker
for wireless_tools version 29 and built and installed it.
lspci -vn gives me:
01:00.0 0280: 14e4:4311 (rev 02)
Subsystem: 103c:1374
Flags: bus master, fast devsel, latency 0, IRQ 20
Memory at c300 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information
Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Capabilities: [d0] Express Endpoint IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities: [160] Device Serial Number 1a-00-5c-ff-ff-73-3d-b9
Capabilities: [16c] Power Budgeting
I was able to use bcm43xx-fwcutter (version 006) to extract the firmware from
the XP driver into /lib/firmware:
-rw-r--r-- 1 root root 3672 Sep 19 21:22 bcm43xx_initval01.fw
-rw-r--r-- 1 root root16 Sep 19 21:22 bcm43xx_initval02.fw
-rw-r--r-- 1 root root 3672 Sep 19 21:22 bcm43xx_initval03.fw
-rw-r--r-- 1 root root16 Sep 19 21:22 bcm43xx_initval04.fw
-rw-r--r-- 1 root root 2544 Sep 19 21:22 bcm43xx_initval05.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval06.fw
-rw-r--r-- 1 root root 2544 Sep 19 21:22 bcm43xx_initval07.fw
-rw-r--r-- 1 root root 2544 Sep 19 21:22 bcm43xx_initval08.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval09.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval10.fw
-rw-r--r-- 1 root root 2872 Sep 19 21:22 bcm43xx_initval17.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval18.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval19.fw
-rw-r--r-- 1 root root 2816 Sep 19 21:22 bcm43xx_initval20.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval21.fw
-rw-r--r-- 1 root root 2824 Sep 19 21:22 bcm43xx_initval22.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval23.fw
-rw-r--r-- 1 root root 2824 Sep 19 21:22 bcm43xx_initval24.fw
-rw-r--r-- 1 root root 248 Sep 19 21:22 bcm43xx_initval25.fw
-rw-r--r-- 1 root root 27360 Sep 19 21:22 bcm43xx_microcode11.fw
-rw-r--r-- 1 root root 26432 Sep 19 21:22 bcm43xx_microcode13.fw
-rw-r--r-- 1 root root 19912 Sep 19 21:22 bcm43xx_microcode4.fw
-rw-r--r-- 1 root root 21944 Sep 19 21:22 bcm43xx_microcode5.fw
-rw-r--r-- 1 root root 1312 Sep 19 21:22 bcm43xx_pcm4.fw
-rw-r--r-- 1 root root 1312 Sep 19 21:22 bcm43xx_pcm5.fw
I get the following syslog messages during boot:
Sep 20 15:46:33 rllt01 kernel: ieee80211_crypt: registered algorithm 'NULL'
Sep 20 15:46:33 rllt01 kernel: ieee80211: 802.11 data/management/control
stack, git-1.1.13
Sep 20 15:46:33 rllt01 kernel: ieee80211: Copyright (C) 2004-2005 Intel
Corporation <[EMAIL PROTECTED]>
Sep 20 15:46:33 rllt01 kernel: bcm43xx driver
...
Sep 20 15:46:33 rllt01 kernel: bcm43xx: Chip ID 0x4311, rev 0x2
Sep 20 15:46:33 rllt01 kernel: bcm43xx: Number of cores: 4
Sep 20 15:46:33 rllt01 kernel: bcm43xx: Core 0: ID 0x800, rev 0x13, vendor
0x4243
Sep 20 15:46:33 rl
Re: software powerup
Perhaps a couple of changes to the driver messages would help eliminate confusion and support repetition? Larry Finger wrote: > bcm43xx: Radio turned off Perhaps: bcm43xx: Radio turned off. Interface must be enabled (ifconfig up) ... > bcm43xx: Microcode rev 0xf5, p1 ox5a (2003-12-22 20:11:25) Perhaps if it can't load the microcode: bcm43xx: Microcode has not been located and loaded. (URL here) E smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 hardware death?
I have had this problem after moving from AP1 to AP2 (same ESSID, different channels, same WEP key). Try this: 1) Kill the network manager :) 2) sudo iwevent & 3) sudo modprobe -r b43 sudo moprobe b43 If it doesn't bring the interface up automatically: 4) sudo ifup [interface-name-here, like eth1 or wlan0 or whatever] Good luck :) Ehud Fernando Toledo wrote: Hi all i think that mi bcm4311 was death in this week =( i test with several kernels: debian stock, vanilla and wireless-dev i test with 2 access points too. i can scan good, i can connect a auth, but in few minutes die and stops ping the ap. the netwokmanager still show online , the dmesg (using the debug option) show all good. any test o another idea?.. i thiking go to the warranty =\ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: driver dis-associates on laptop lid close
iwconfig shows the last AP associated, even if there is no association. You can easily test this... associate, ping, then iwconfig INTFCNAME essid "this does not exist" iwconfig You'll see the AP MAC address is still there. What looks like is your power mode is set to suspend on lid close. If you fix that you'll find your problem goes away. In gnome on F7 I go to system->preferences->system->power management and change what lid-closed behavior is. Ehud Timo Reimann wrote: Hi all, I'm having the following issue with a Broadcom 4306 802.11b/g mini-PCI card running under Ubuntu Feisty (7.04) kernel 2.6.20 and 2.6.22 with the bcm43xx driver on an IBM Thinkpad T40. Whenever I close my laptop's lid, the wifi interface seems to stop working as I can tell by trying to ping the machine remotely: It works right before I close the lid, stops when it's shut, and *mostly* works again if I re-open. Same thing with any other network service, e.g. ssh. The *mostly*-part is what is giving me headaches. Although iwconfig shows that the association to my AP is never dropped and the interface is still configured in terms of IP address, netmask and such, every now and then I cannot connect to either LAN or WAN machines, and all I can do in such a case is re-load the driver and restart the interface. Apart from that, I'd prefer my laptop to stay connected even when the lid is closed. I have two reasons why I suspect the Broadcom driver to be responsible: First, I have tried my best to make sure no other mechanism may be blamed for the observed behavior, including disabling ACPI/APM/APIC on bootup; disabling acpid; making sure no hiberating/suspending takes place; and checking the BIOS power management settings. Second, I used to use ndiswrapper for this machine but choose to switch to the bcm43xx driver since the first would not reliably connect my box during start-up. If it did connect, however, the link would never fail during lid closure (while not changing anything else, i.e. same network configuration tools were used during, before, and after the switch). Therefore, I'd be glad if anyone has a hint what else I could try to fix this problem. Especially, I'm curious if any of the bcm43xx module parameters deal with some power management/suspend control part I could tweak. (I wasn't able to figure what every `modinfo'-listed argument means.) Thanks for any help. If I forgot some vital piece of information, please don't hesitate to ask. Cheers, --Timo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
