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/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: [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: 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: 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 cutpaste 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
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 you say: If I'd written a book you're illiterate I would expect Your expectations clearly are tantamount to garbage. Glad to be able to fix a problem quickly. Well I did't do it. You didn't do it. There should be no glad smile off our face. As for
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
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: 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
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
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
Movable zone: 0 pages
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
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
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
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
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
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
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: 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
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
*conf)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
- struct b43_wldev *dev;
+ struct b43_rfkill *rfk = (wl-rfkill);
+
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
[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
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: [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: 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- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at c300 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=2 PME- Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [d0] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 4us, L1 64us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel -- 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
$ 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: bcm43xx-dev@lists.berlios.de 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: 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
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: 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-wirelessm=119152616425736w=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
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 rllt01
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: 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
Re: Broadcom 4311 WLAN card...
FYI Suspend/Resume is iffy. Sometimes it works, sometimes it does not. When it does not, sometimes it unloads fine, sometimes it says it's waiting for a reference (or 3) to be cleared before unloading. Only a reboot will cure that one... as the message repeats but the reference count never decreases. In all cases the unload is preceded by an ifconfig eth1 down unload = rmmod b43 Ehud dell 1390 (4311) 2.6.23-rc3 (wireless dev everything 29-aug-2007) Larry Finger wrote: Dr. techn. Alexander K. Seewald wrote: Hi Larry, When resuming from suspend-to-disk, I get the following message -- Aug 30 18:22:41 localhost kernel: b43 ssb0:0: resuming Aug 30 18:22:41 localhost kernel: b43-phy0 ERROR: Microcode not responding Aug 30 18:22:41 localhost kernel: b43-phy0 ERROR: You must go to http://linuxwireless.org/en/users/Drivers/bcm43xx#devicefirmware and download the correct firmware (version 4). Aug 30 18:22:41 localhost kernel: b43-phy0 ERROR: Resume failed at core init -- Would this be easy to fix, e.g. by re-uploading the firmware in b43_resume? This does not seem to be done or it does not work correctly. Michael, Have you done any tests with suspend/resume? I have not. 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
B43 deassociates a lot, especially after an ARP request
Synopsis: With everything tree and b43, loses AP association but then reassociates, usually on ARP request. I realize there's a tcpdump in there and that doesn't really provide any useful info... the key is the iwevent and generating traffic. Duplicating: 1. Use a 4311 2. Load b43 (autoloads on this kernel - Linux egdell.wetwork.net 2.6.23-rc3 #1 SMP Tue Aug 14 14:00:46 MST 2007 x86_64 x86_64 x86_64 GNU/Linux) 3. iwevent 4. Ping a nonexistent local address (EG if your local network is 192.168.1.1-254 just ping 192.168.1.X where X doesn't exist or isn't in the ARP table.) Removing hardware and other factors: 1. I removed the other Buffalo Airstation 54G so that only one would be possibly in range with which to associate 2. After taking this log, I replaced the b43 driver with the bcmwl5.sys for testing purposes (yeah). No such errors resulted. One more thing: In removing the W driver, I got MANY MORE association/deassociations than should be necessary. That log is included LAST. Contents: 1. This summary 2. Following five octothorpes the first summary 3. Following five octothorpes, the removal of the W driver, the insertion of B43 driver, and way too many assoc/deassocs. Ehud PS Michael, if you think my tree is unclean, kindly let me know which one you want me to build from scratch and I will. Right now I'm using the everything git tree. # [EMAIL PROTECTED] ~]# lsmod | grep b43 b43 121516 0 ssb40836 1 b43 mac80211 165512 2 rc80211_simple,b43 [EMAIL PROTECTED] ~]# tcpdump -i eth1 [2] 3357 [EMAIL PROTECTED] ~]# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes lsmod | grep b4313:40:26.965437 IP 4dtvpc.wetwork.net.fatpipe 239.255.255.250.ssdp: UDP, length 101 13:40:26.968671 IP 4dtvpc.wetwork.net.fatpipe 239.255.255.250.ssdp: UDP, length 101 13:40:26.994962 IP 10.1.1.5.32780 dns1.login.com.domain: 40335+ PTR? 250.255.255.239.in-addr.arpa. (46) 13:40:27.046379 IP dns1.login.com.domain 10.1.1.5.32780: 40335 NXDomain 0/1/0 (103) 13:40:27.046657 IP 10.1.1.5.32780 dns1.login.com.domain: 55638+ PTR? 105.1.1.10.in-addr.arpa. (41) 13:40:27.070857 IP dns1.login.com.domain 10.1.1.5.32780: 55638* 1/1/1 PTR[|domain] 13:40:27.071169 IP 10.1.1.5.32780 dns1.login.com.domain: 13656+ PTR? 1.240.195.192.in-addr.arpa. (44) 13:40:27.090836 IP dns1.login.com.domain 10.1.1.5.32780: 13656* 1/1/1 (102) 13:40:27.091056 IP 10.1.1.5.32780 dns1.login.com.domain: 30069+ PTR? 5.1.1.10.in-addr.arpa. (39) 13:40:27.120824 IP dns1.login.com.domain 10.1.1.5.32780: 30069 NXDomain* 0/1/0 (88) ping 10.1.1.15 PING 10.1.1.15 (10.1.1.15) 56(84) bytes of data. 13:40:30.966090 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:30.966252 IP 10.1.1.5.32780 dns1.login.com.domain: 28088+ PTR? 15.1.1.10.in-addr.arpa. (40) 13:40:30.982932 IP dns1.login.com.domain 10.1.1.5.32780: 28088 NXDomain* 0/1/0 (89) 13:40:31.061021 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:32.967744 eth1 New Access Point/Cell address:Not-Associated From 10.1.1.5 icmp_seq=2 Destination Host Unreachable From 10.1.1.5 icmp_seq=3 Destination Host Unreachable From 10.1.1.5 icmp_seq=4 Destination Host Unreachable 13:40:33.970465 eth1 Custom driver event:ASSOCINFO(ReqIEs=0007776574776f726b010802040b160c12182432043048606c RespIEs=010c82848b8c929698a4b0c8e0ecdd050010180103) 13:40:33.970497 eth1 New Access Point/Cell address:00:07:40:9F:5B:52 13:40:35.967199 eth1 New Access Point/Cell address:Not-Associated 13:40:36.970352 eth1 Custom driver event:ASSOCINFO(ReqIEs=0007776574776f726b010802040b160c12182432043048606c RespIEs=010c82848b8c929698a4b0c8e0ecdd050010180103) 13:40:36.970386 eth1 New Access Point/Cell address:00:07:40:9F:5B:52 From 10.1.1.5 icmp_seq=6 Destination Host Unreachable From 10.1.1.5 icmp_seq=7 Destination Host Unreachable From 10.1.1.5 icmp_seq=8 Destination Host Unreachable 13:40:39.967917 eth1 New Access Point/Cell address:Not-Associated 13:40:40.971636 eth1 Custom driver event:ASSOCINFO(ReqIEs=0007776574776f726b010802040b160c12182432043048606c RespIEs=010c82848b8c929698a4b0c8e0ecdd050010180103) 13:40:40.971675 eth1 New Access Point/Cell address:00:07:40:9F:5B:52 13:40:31.266138 arp who-has 4dtvpc.wetwork.net tell gw.wetwork.net 13:40:31.266373 IP 10.1.1.5.32780 dns1.login.com.domain: 20811+ PTR? 1.1.1.10.in-addr.arpa. (39) 13:40:31.267087 arp who-has 4dtvpc.wetwork.net tell gw.wetwork.net 13:40:31.965991 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:31.981684 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:31.983505 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:32.965836 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:34.965529 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:35.054230 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:35.055199 arp who-has 10.1.1.15 tell 10.1.1.5 13:40:35.965379 arp who-has 10.1.1.15 tell 10.1.1.5
Re: Dell 1390 not detecting AP
ifconfig eth1 up E Andrew McGuinness wrote: I'm not able to detect my AP with a Dell 1390 mini-pci using bcm43xx I appreciate that the driver is under very heavy development at the moment, and I'm willing to try the bcm43 if that will help. Details follow: The Acer Aspire 3680 contains the following (lspci -v) 03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01) Subsystem: AMBIT Microsystem Corp. Unknown device 0422 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at 3410 (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 and from lspci -n 03:00.0 0280: 14e4:4311 (rev 01) I built a 2.6.21 kernel from debian, with the combined_2.6.21.patch from lwfinger.dynalias.org I got the v3 firmware wl_apsta-3.130.20.0.o and used fwcutter to create the .fw files in /lib/firmware $ dmesg | grep bcm bcm43xx driver bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off bcm43xx: PHY connected bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27) bcm43xx: Radio turned on bcm43xx: Radio disabled by hardware bcm43xx: Chip initialized bcm43xx: 32-bit DMA initialized bcm43xx: Keys cleared bcm43xx: Selected 802.11 core (phytype 2) bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0 $ iwconfig eth1 essid arobeia $ iwconfig eth1 Warning: Driver for device eth1 has been compiled with version 22 of Wireless Extension, while this program supports up to version 20. Some things may be broken... eth1 IEEE 802.11b/g ESSID:arobeia Nickname:Broadcom 4311 Mode:Managed Frequency=2.472 GHz Access Point: Invalid Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 $ iwlist eth1 scan eth1 no scan results The radio disabled by hardware looks like a problem to me ? smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Linksys N card (4329)... is this an RE project...
I have a Linksys PCMCIA N card which IDs as a BCM43XG, but unfortunately is model 0x4329 rev 01, which is not on the hardware list as a supported device. Is this something that requires RE effort... and am I tainted because I've looked at the Linux driver (reverse tainted) or am I clear... but if I start doing RE I can never contribute to the driver code? Thanks, Ehud Latest everything kernel. dmesg with b43 and normal firmware: [nothing] dmesg with b43 and firmware from the Linksys file that came with it: [nothing] dmesg with bcm43xx fwpostfix=.fw3 (I didn't expect it to work, but tried for completeness: bcm43xx driver uname -a: Linux techeg.login.com 2.6.23-rc3 #1 SMP Tue Aug 14 17:28:00 MST 2007 1686 1686 i386 GNU/Linux lspci: 06:00.0 0280: 14e4:4329 (rev 01) smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
newbie question
I've git clone'd the wireless-dev tree, and the test tree, and there ain't* not bcm43xx_mac80211 or b43 or b44 or anything similar in the .config. 1) How can I get access to update the berlios.de wiki? I'd like to contribute, and I think I can help other newbies because I can relate (being one) but I can also talk technical to a point. 2) Where can I download the *latest* kernel with the *latest* changes? I want to help the development process, and while you guys are clear on the RE and the Driver Development teams you also need testers. Well. I'm one :) Ehud * not a real word 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: newbie question
Off list... but your eventual reply may want to be there. When John gets his tree so we [those of us who use this code] can test it, let us [same group] know. Best regards, Ehud Tucson Larry Finger wrote: Ehud Gavron wrote: I've git clone'd the wireless-dev tree, and the test tree, and there ain't* not bcm43xx_mac80211 or b43 or b44 or anything similar in the .config. 1) How can I get access to update the berlios.de wiki? I'd like to contribute, and I think I can help other newbies because I can relate (being one) but I can also talk technical to a point. 2) Where can I download the *latest* kernel with the *latest* changes? I want to help the development process, and while you guys are clear on the RE and the Driver Development teams you also need testers. Well. I'm one :) Linville reorganized his tree. The default clone gets you only a copy of Linus's tree on branch master. I don't know how to get the rest - he is planning on sending an email about this. Larry smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Jory, thank you for helping convince Michael I was not hallucinating!
Larry, thank you for finding the difference in the kernel output!
Michael, thank you for finding the part of the code affected by the
underlying changes caused by the patch but not changed by the patch!
It works.
I've got the latest wireless-dev tree (2.6.23-rc2, git checkout -f) with
the change below IT WORKS!!!
Have I thanked everyone yet? Because it sure as heck feels like I want to.
Ehud
Michael Buesch wrote:
On Friday 10 August 2007 17:02:15 Larry Finger wrote:
Jory A. Pratt wrote:
Larry Finger wrote:
What encryption method are you using?
Larry
I use wep encryption on a WRT54G V3 with dd-wrt. I will work on it later
tonight and see what I can come up with.
Your answer confirms my latest result in which I have been able to reproduce
the problem here.
I bisected the wireless-dev kernel to an arbitrary point before the change in status handling
(commit 85a83d26). That version could connect successfully using WEP and WPA encryption. I then
added the status-handling patch and tried again. This kernel could still do WPA encryption and it
could authenticate and associate with the WEP-using AP, but it could not get an IP number using DHCP.
I then did a diff between the dmesg output for the driver that works (dmesg.good) and the one that
does not (dmesg.bad). There are the usual number of differences due to slight timing difference,
etc, but the following difference stands out:
--- dmesg.good 2007-08-10 09:40:23.0 -0500
+++ dmesg.bad 2007-08-10 09:41:23.0 -0500
..snip..
@@ -569,7 +569,6 @@
bcm43xx_mac80211: 32-bit DMA initialized
bcm43xx_mac80211: Wireless interface started
NET: Registered protocol family 17
-bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
The good version is using hardware encryption, and the bad one is not. I have no idea why, but it
seems to be the critical difference. I'm ready to test any trial patch.
Larry
Ok, I see the bug in set_key.
if (bcm43xx_status(dev) != BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
We didn't have a chance to spot the bug in the patch that introduced
it, because it did not touch this function.
This should be changed to
if (bcm43xx_status(dev) BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
That change is already built on my kernel (now wireless-dev with two
patches). I'm assuming it's correct, but if you'd like to confirm it,
please let me know which packet(s) to craft in order to test it.
Thanks again,
Ehud
Larry Finger wrote:
Michael Buesch wrote:
On Friday 10 August 2007 17:02:15 Larry Finger wrote:
Jory A. Pratt wrote:
Larry Finger wrote:
What encryption method are you using?
Larry
I use wep encryption on a WRT54G V3 with dd-wrt. I will work on it later
tonight and see what I can come up with.
Your answer confirms my latest result in which I have been able to reproduce
the problem here.
I bisected the wireless-dev kernel to an arbitrary point before the change in status handling
(commit 85a83d26). That version could connect successfully using WEP and WPA encryption. I then
added the status-handling patch and tried again. This kernel could still do WPA encryption and it
could authenticate and associate with the WEP-using AP, but it could not get an IP number using DHCP.
I then did a diff between the dmesg output for the driver that works (dmesg.good) and the one that
does not (dmesg.bad). There are the usual number of differences due to slight timing difference,
etc, but the following difference stands out:
--- dmesg.good 2007-08-10 09:40:23.0 -0500
+++ dmesg.bad 2007-08-10 09:41:23.0 -0500
..snip..
@@ -569,7 +569,6 @@
bcm43xx_mac80211: 32-bit DMA initialized
bcm43xx_mac80211: Wireless interface started
NET: Registered protocol family 17
-bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
The good version is using hardware encryption, and the bad one is not. I have no idea why, but it
seems to be the critical difference. I'm ready to test any trial patch.
Larry
Ok, I see the bug in set_key.
if (bcm43xx_status(dev) != BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
We didn't have a chance to spot the bug in the patch that introduced
it, because it did not touch this function.
This should be changed to
if (bcm43xx_status(dev) BCM43xx_STAT_INITIALIZED) {
err = -ENODEV;
goto out_unlock;
}
This part of set_multicast_list also was not touched by the patch
if (wl-promisc != !!(netflags IFF_PROMISC)) {
wl-promisc = !!(netflags IFF_PROMISC);
if (bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED)
bcm43xx_adjust_opmode(dev);
}
Is that correct? My thinking is that it should be = BCM43xx_STAT_INITIALIZED.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
I had hoped this would be the cure so I don't have to undo the 85a83d26
commit patch by patch.
However, while this did not solve the problem it DID show a new error:
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
Is that a clue to bigger things, or a problem with this patch?
dmesg and tcpdump (of garbage) included along with a log of what I did
with the git test tree to get there.
Ehud
Larry Finger wrote:
To the list: The beginnings of this thread were done off-list, but I
want to let everyone know about
the problem, and to discover if anyone else has it. Since 2.6.23-rc1,
Ehud has a problem in that the information his interface is
transmitting is garbled. He did a bisection and discovered that the
problem is involved with commit 85a83d26 bcm43xx-mac80211: Rewrite
and simplify handling of the initialization status.. Neither Michael
nor I can reproduce the problem, nor is anything obviously wrong with
the patch, other than this patch exposes an error in the location of
the initial interrupt. I found this error on my old/slow notebook.
Fixing that error did not resolve Ehud's problem. That fix is now in
Linville's tree.
Ehud - please make your test tree current with a 'git checkout -f'
command, and do a 'git pull' to
make certain you have the latest code. Then apply the trial patch
below, which reverts a small part of Michael's patch, and see if it
fixes the problem.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
---
wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
/* Interrupt handler top-half */
static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
-irqreturn_t ret = IRQ_NONE;
+irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_wldev *dev = dev_id;
u32 reason;
@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han
spin_lock(dev-wl-irq_lock);
-if (bcm43xx_status(dev) BCM43xx_STAT_STARTED)
-goto out;
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
-if (reason == 0x) /* shared IRQ */
+if (reason == 0x) { /* shared IRQ */
+ret = IRQ_NONE;
goto out;
-ret = IRQ_HANDLED;
+}
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
if (!reason)
goto out;
bcm43xx-phy0: Broadcom 4311 WLAN found
bcm43xx-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy0 debug: Radio turned off
bcm43xx driver
bcm43xx-phy1: Broadcom 4311 WLAN found
bcm43xx-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy1 debug: Radio turned off
bcm43xx-phy1 debug: Adding Interface type 2
bcm43xx-phy1 debug: Loading firmware version 371.1061 (2006-10-04 21:02:04)
bcm43xx-phy1 debug: Radio turned on
bcm43xx-phy1 debug: Radio enabled by hardware
bcm43xx-phy1 debug: bbatt(11) = size of LO array
[8817daaf] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x65/0xa8
[8817db28] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x36/0x3b
[8817dc0c] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x9/0x15
[8817824b] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x338/0x6a6
[88172ae4] :bcm43xx_mac80211:bcm43xx_phy_read+0x5c/0x63
[8817b52e] :bcm43xx_mac80211:bcm43xx_phy_initg+0xc85/0xd0a
[8817bd61] :bcm43xx_mac80211:bcm43xx_phy_init+0x582/0x5a7
[8816fcce] :bcm43xx_mac80211:bcm43xx_chip_init+0x68c/0x9a3
[8817026d] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x288/0x73e
[881712bb] :bcm43xx_mac80211:bcm43xx_add_interface+0x5f/0xf4
bcm43xx-phy1 debug: Chip initialized
bcm43xx-phy1 debug: 32-bit DMA initialized
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1525:bcm43xx_interrupt_handler()
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
bcm43xx-phy1 debug: Wireless interface started
08:47:25.934468 00:a0:c8:0e:c0:e5 00:1a:92:0e:40:1f, 802.3, length 78: LLC,
dsap Unknown (0xd0) Group, ssap Unknown (0x1e) Command, ctrl 0x007c:
Information, send seq 62, rcv seq 0, Flags [Command], length 64
0x: 001a 920e 401f 00a0 c80e c0e5 0040 d11e
0x0010: 7c00 d33d 7497 de0e 21e6 f6fe 8382 bf04
0x0020: e081 7838 36f2 114a 3ee3 9c19 e3fc 402c
0x0030: 8746 083d 4fb9 0b86 4965 f272 86e1 963b
0x0040: 2efe a2c5 c3ac f6ca 4363 eb91 a233
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
[EMAIL PROTECTED] test]# git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # arch/x86_64/vdso/vdso.lds nothing added to commit but untracked files present (use git add to track) [EMAIL PROTECTED] test]# git diff [EMAIL PROTECTED] test]# Michael Buesch wrote: On Wednesday 08 August 2007 18:11:03 Larry Finger wrote: [EMAIL PROTECTED] test]# patch -p1 patch-2007-aug-08-lfinger.txt patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Hunk #1 FAILED at 1503. Hunk #2 FAILED at 1512. 2 out of 2 hunks FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The patch failed, but it shouldn't have. Have you done a 'git bisect reset' since we finished the bisecting? That would be a problem. Just in case, do the following: git bisect reset git checkout -f git pull Then apply the patch. If you get any REJECTS, please let me know. I'll hold off on analyzing those assertions until the code is in a known state. Yeah, your tree is still unclean. After cleaning it you can verify if it's clean by inspecting the output of git status and git diff status should _not_ talk about modified files or something like that. diff should output nothing. A clean tree looks like this: [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status nothing to commit [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff [EMAIL PROTECTED]:~/develop/git/wireless-dev$ smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
The corrected patch shows the same results. I have a 2.6.23-rc2 kernel where bcm43xx_mac80211 receives garbage. Ehud Larry Finger wrote: Michael Buesch wrote: On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote: [EMAIL PROTECTED] test]# git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # arch/x86_64/vdso/vdso.lds nothing added to commit but untracked files present (use git add to track) [EMAIL PROTECTED] test]# git diff [EMAIL PROTECTED] test]# Larry, your patch is broken [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Hunk #1 FAILED at 1503. Hunk #2 FAILED at 1512. 2 out of 2 hunks FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The white space must have been garbled. When it didn't apply, Ehud contacted me privately and I sent him the patch file as an attachment. It has applied cleanly and is now compiling. Larry smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) [EMAIL PROTECTED] test]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej I can do this all day long. It's much more fun than dissecting the original commit and doing it step by step. Ehud Larry Finger wrote: Ehud Gavron wrote: The corrected patch shows the same results. I have a 2.6.23-rc2 kernel where bcm43xx_mac80211 receives garbage. Mumble, mumble, swear words,. OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Re git checkout -f... that's what I thought but when I kept getting the patch was previously applied... I figured I'd just clean it out. Costs me 30 minutes of compile/link time, but it's nice'd out of the way. The new patch (that was attached by you, and that Michael re-referenced) applied, and it is now building. Should have results in 35m. Thanks Ehud Larry Finger wrote: Ehud Gavron wrote: Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) [EMAIL PROTECTED] test]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c No, you got the wrong patch. That one was previously applied, which is what the error message is saying. In any case, apply the one I just sent. BTW, it isn't necessart to repull the tree to get a clean version. That is what 'git checkout -f' does. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n. Ehud Michael Buesch wrote: On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote: Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) [EMAIL PROTECTED] test]# patch -p1 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] John just pushed the IRQ patch upstream. Please try my patch that I just sent. This one: http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Understood. Files attached. This time I set the channel so that bcm43xx_mac80211(noworkie) would associate with the same AP that bcm43xx_mac80211(workie) does. For infrastructure reference there are two APs on the LAN, and one has a WDS with a third AP. All are Buffalo Airstations 54G. All work fine with bcm43xx ndiswrapper with bcmwl5. See attached. Ehud Larry Finger wrote: Ehud Gavron wrote: good: rc1 git test tree with the commit in question reversed. Works fine. bad: rc2 git wireless-dev tree with Michael's latest patch. Does not work. full dmesg, iwconfig, and ifconfigs included. Like I said, I am happy to do this all day long so that I don't have to personally revert that long patch. With xconfig, select the Kernel hacking section, and turn off the Show timing info on printks. In addition, turn off Kobject debugging in that section. The latter option generates a lot of messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make modules_install install'. You do not need to clean out the object files, or any other make options. Boot that kernel and send me it's dmesg. One further question - Are you trying to connect to the same AP in both cases? The reason I'm asking is that the MAC address of the AP is different for the two cases. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev Linux version 2.6.23-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #2 SMP Wed Aug 8 20:36:34 MST 2007 Command line: ro root=LABEL=/ rhgb quiet BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 7fe81400 (usable) BIOS-e820: 7fe81400 - 7ff0 (reserved) BIOS-e820: f000 - f4007000 (reserved) BIOS-e820: f4008000 - f400c000 (reserved) BIOS-e820: fed2 - feda (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 523905) 1 entries of 3200 used end_pfn_map = 1043872 DMI 2.4 present. ACPI: RSDP 000FC0B0, 0014 (r0 DELL ) ACPI: RSDT 7FE8198A, 0044 (r1 DELLM07 27D60A0D ASL61) ACPI: FACP 7FE82800, 0074 (r1 DELLM07 27D60A0D ASL61) ACPI: DSDT 7FE83400, 4D7D (r1 INT430 SYSFexxx 1001 INTL 20050624) ACPI: FACS 7FE91C00, 0040 ACPI: HPET 7FE82F00, 0038 (r1 DELLM071 ASL61) ACPI: APIC 7FE83000, 0068 (r1 DELLM07 27D60A0D ASL47) ACPI: ASF! 7FE82C00, 005B (r16 DELLM07 27D60A0D ASL61) ACPI: MCFG 7FE82FC0, 003E (r16 DELLM07 27D60A0D ASL61) ACPI: SLIC 7FE8309C, 0176 (r1 DELLM07 27D60A0D ASL61) ACPI: TCPA 7FE83300, 0032 (r1 DELLM07 27D60A0D ASL61) ACPI: SSDT 7FE81A11, 04DC (r1 PmRefCpuPm 3000 INTL 20050624) No NUMA configuration found Faking a node at -7fe81000 Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 523905) 1 entries of 3200 used Bootmem setup node 0 -7fe81000 No mptable found. Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 523905 On node 0 totalpages: 523808 DMA zone: 96 pages used for memmap DMA zone: 2524 pages reserved DMA zone: 1379 pages, LIFO batch:0 DMA32 zone: 12183 pages used for memmap DMA32 zone: 507626 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:7010) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 435320 bytes of per cpu data Built 1 zonelists in Node order. Total pages: 509005 Policy zone: DMA32 Kernel command line: ro root=LABEL=/ rhgb quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Marking TSC unstable due to TSCs unsynchronized time.c: Detected
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
I have received a private reply from another user with *exactly* the same symptoms. That user also uses x86_64. I just got the tree from scratch, built it, booted without any tainting modules (nvidia) and got _exactly_ the same results. What am I doing wrong? I've build these before... and I think I have the procedure right. Thanks, Ehud 1060 cd /usr/src 1061 ls 1062 rm -rf wireless-dev/ 1063 ./git.sh 1064 sed -e s/\(EXTRAVERSION.*\)/\1-wireless-dev-EG2/g -i wireless-dev/Makefile 1065 cd wireless-dev/ 1066 make mrproper 1067 cp ../2.6.22-EG1/.config . 1068 make oldconfig /dev/null /dev/null 1069 grep -i bcm43xx .config 1073 make finished WAY TOO SOON with error in asus_laptop.c 1075 sed -e s/CONFIG_ASUS_LAPTOP=\(.*\)/CONFIG_ASUS_LAPTOP=n/g -i .config 1076 make 1077 time nice make modules_install 1078 time nice make install 1079 history 1080 history ~root/build_history.txt (and here you have it) Larry Finger wrote: Ehud Gavron wrote: The bcm43xx_mac80211 code associates fine and has good signal strength. However, the stuff coming out of it on eth1 is not Ethernet... The same setup worked in 2.6.22-wireless-dev. A simple unload of the two modules, a reload of bcm43xx with v3 fw, and it all works... You'll note I attached entire dmesg and not just dmesg|grep bcm so that you could also see: bcm43xx-phy0 debug: bbatt(11) = size of LO array The size of LO array message is not fatal. I pulled the latest system from wireless-dev and built it. On my 4311, it connects just fine. The maximum transmit and receive rates are 2.2 and 3.2 Mbs, respectively. I don't know what happened to your system. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
bcm43xx_mac80211 unhappy
I'm bored, and I don't leave for the Champ Car Grand Prix of San Jose until Thursday. Developers - if there's something you need from my system, ask away. Ehud bcm43xx_mac80211: Adding Interface type 2 ssb: Switching to PCI-E core, index 3 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Loading firmware version 371.1061 (2006-10-04 21:02:04) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: ERROR: bbatt(11) = size of LO array Call Trace: [8824883a] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x54/0x93 [882488af] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x36/0x3b [8824898a] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x9/0x15 [882430c3] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x338/0x6a2 [8823dc29] :bcm43xx_mac80211:bcm43xx_phy_read+0x58/0x60 [88246367] :bcm43xx_mac80211:bcm43xx_phy_initg+0xc85/0xd0a [88246b9a] :bcm43xx_mac80211:bcm43xx_phy_init+0x582/0x5a3 [88239105] :bcm43xx_mac80211:bcm43xx_chip_init+0x675/0x984 [8823a7a1] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x27d/0x70a [8823bfff] :bcm43xx_mac80211:bcm43xx_add_interface+0x5c/0xf1 [881f65c6] :mac80211:ieee80211_open+0x222/0x34c [811e05bb] dev_open+0x2f/0x6e [811de783] dev_change_flags+0x5a/0x118 [8122284b] devinet_ioctl+0x235/0x597 [8124be1e] do_page_fault+0x476/0x7b4 [811d415f] sock_ioctl+0x1c8/0x1e5 [8109f87b] do_ioctl+0x2b/0xb6 [8109fb49] vfs_ioctl+0x243/0x25c [8109fbbb] sys_ioctl+0x59/0x7a [81009b5e] system_call+0x7e/0x83 [EMAIL PROTECTED] ~]# uname -a Linux egdell.wetwork.net 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]# lsmod | grep bcm bcm43xx_mac80211 418849 0 ssb43461 1 bcm43xx_mac80211 mac80211 164809 2 rc80211_simple,bcm43xx_mac80211 [EMAIL PROTECTED] ~]# iwconfig lono wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. eth1 IEEE 802.11g ESSID:wetwork Mode:Managed Frequency:2.437 GHz Access Point: 00:0D:0B:11:5C:1B Bit Rate=1 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:wep-key-goes-here Link Quality=43/100 Signal level=-55 dBm Noise level=-85 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 1000 iwconfig eth1 is there... but not connected (ONBOOT=NO in /etc/sysconfig/network-scripts/ifup-eth1) 1001 dmesg the firmware WAS loaded, cores detected, etc. 1002 lsmod | grep bcm yup, the bcm stuff is there 1003 lsmod | grep ndis no, no wrapper 1004 iwconfig not associated 1006 iwlist eth1 scan can't list while it's not up 1007 ifconfig eth1 up 1008 iwlist eth1 scan now I get a list 1009 iwconfig not associated tho... let's let ifup do it... 1010 ifup eth1 there we go... no errors 1011 ifconfig eth1 it's got an address 1012 ping 10.1.1.1 it can ping the gateway 1013 lsmod | grep bcm 1014 lsmod | grep ndis yes one one and no on two 1015 dmesg weird error. 1016 uname -a 1017 lsmod | grep bcm 1018 iwconfig 1019 history 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: bcm4301: A mac80211 driver using V3 firmware
Not a developer, just a tester, and not a very good one... but I am a _USER_ so here's my take. The USERs don't want to know what card they have or what driver they need or PCI IDs. That's all stuff that makes them say Linux Bad, *s good. (Yeah I know, there's the whole driver moreass there and PCI VENs too) but anyway... The driver should have a name that reflects its use and capabilities. For example, bcm43xx is a reasonable name. I don't like it personally because the google links to the site (berlios.de) that tell me that's why I need took a while to find but that's just semantics. bcm43xx_mac80211 is a less reasonable name. With respect to the coders who have put time into making this usable on by 4306 and almost usable on my 4311 I can say that I appreciate the effort... but the name needs work. If I was king of driver package naming, the driver that works with v3 and v4 firmware and supports crypto functions would be... broadcom80211bg or bcm80211g The driver that only works with v3 (aka bcm43xx) broadcomv3 The driver that only works with v4 (aka bcm43xx_mac80211) broadcomv4 As time advances and bcb43xx_mac80211/broadcomv4 is brought to spec so it works great... its code would be integrated into broadcom80211g/bcm80211g. That's my thinking. As a USER. As a linux advocate and zealot. I can tell you there are three things that are the #1 hindrance to massive Linux adoption 1. proprietary video cards 2. proprietary network cards 3. the various sundry and astonishingly in-the-way and annoying network-managers. If you can solve #2... you've eliminated 33% of the problem and maybe even helped with #3. Go Lewis Hamilton @ Nurbugring Go Paul Tracy @ Edmonton Ehud Pavel Roskin wrote: On Fri, 2007-07-20 at 09:44 -0400, John W. Linville wrote: On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote: Actually, the common practice is that the new driver that doesn't supplant the old driver immediately and for the whole range of hardware gets a new name. Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100. Yes, this preserves stability for happy bcm43xx users. Still taking suggestions for the new name for bcm43xx-mac80211... :-) b43 bcm43 bcm4k3 bcmwifi bcmwlan bcm80211 brcm43xx broadcom I really like the minimalism of b43, which plays well with b44 and p54 :) Also, we could introduce a kernel option to enable support for new devices in your driver. Yes, this is probably worthwhile for those wishing to avoid PCI ID conflicts between the drivers. I have also been speculating that perhaps we need an option for a secondary PCI ID table, so that a driver could support a large range of PCI IDs but then gracefully bow-out if another driver had a certain ID in its primary table. Does that make any sense? It would seem to be applicable to a number of drivers in the kernel. Yes, I used to hearing complains that orinoco steals IDs from hostap. Then it became popular to blacklist orinoco modules. Quite a disgrace for the driver! Having weak IDs for Prism based cards would have avoided it. But please realize that the problem goes far beyond PCI. Perhaps you have heard of CONFIG_USB_LIBUSUAL, which selects the best driver for USB storage devices, either the slow but reliable ub, or the SCSI based usb-storage, which it too fast for some cheap sticks. It even has a parameter called bias, which allows to control how conservative the algorithm should be. That would be hard to emulate with weak entries, but I hope that bias is an overkill. Yes, we should probably start using a default value for fwpostfix. As dwmw2 suggested, it would also be nice to fall back to an empty fwpostfix if the firmware is not found w/ the default extension. Yes, that sounds good. smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
2.6.22(linville git) bcm4306 unhappy with bbat(11)...
Interestingly neither bcm43xx nor bcm43xx_mac80211 automatically load. However, when I modprobe bcm43xx_mac80211 the following happens. I would love to know how to fix the module won't load automatically issue. However, here ya go: bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Loading firmware version 371.1061 (2006-10-04 21:02:04) bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: ERROR: bbatt(11) = size of LO array [e4a50cf4] bcm43xx_get_lo_g_ctl+0x51/0x8d [bcm43xx_mac80211] [e4a50d6b] bcm43xx_lo_g_ctl_current+0x3b/0x3e [bcm43xx_mac80211] [e4a50e4f] bcm43xx_lo_g_adjust+0x8/0x12 [bcm43xx_mac80211] [e4a4b97a] bcm43xx_phy_init_pctl+0x2ed/0x5fc [bcm43xx_mac80211] [e4a466f0] bcm43xx_phy_write+0x5c/0x64 [bcm43xx_mac80211] [e4a4e998] bcm43xx_phy_initg+0xbe2/0xc44 [bcm43xx_mac80211] [e4a4f125] bcm43xx_phy_init+0x518/0x534 [bcm43xx_mac80211] [e4a4254b] bcm43xx_chip_init+0x639/0x904 [bcm43xx_mac80211] [e4a43509] bcm43xx_wireless_core_init+0x21e/0x67a [bcm43xx_mac80211] [e4a44cd1] bcm43xx_add_interface+0x56/0xe1 [bcm43xx_mac80211] bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 30-bit DMA initialized bcm43xx_mac80211: Wireless interface started 06:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) Subsystem: Linksys WPC54G Flags: bus master, fast devsel, latency 64, IRQ 11 Memory at 3c00 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 [EMAIL PROTECTED] ~]# lspci -n 00:00.0 0600: 8086:7190 (rev 03) 00:01.0 0604: 8086:7191 (rev 03) 00:04.0 0607: 104c:ac1b (rev 03) 00:04.1 0607: 104c:ac1b (rev 03) 00:07.0 0680: 8086:7110 (rev 02) 00:07.1 0101: 8086:7111 (rev 01) 00:07.2 0c03: 8086:7112 (rev 01) 00:07.3 0680: 8086:7113 (rev 03) 00:08.0 0401: 125d:1978 (rev 10) 00:09.0 0200: 8086:1229 (rev 09) 00:09.1 0700: 11c1:0445 01:00.0 0300: 1002:4c4d (rev 64) 06:00.0 0280: 14e4:4320 (rev 03) [EMAIL PROTECTED] ~]# uname -a Linux techeg.login.com 2.6.22 #1 SMP Tue Jul 10 15:27:15 MST 2007 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]# dmesg | grep bcm bcm43xx_mac80211: Broadcom 4306 WLAN found bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_mac80211: Radio turned off bcm43xx driver bcm43xx driver bcm43xx driver bcm43xx driver bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Loading firmware version 371.1061 (2006-10-04 21:02:04) bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: ERROR: bbatt(11) = size of LO array [e4a50cf4] bcm43xx_get_lo_g_ctl+0x51/0x8d [bcm43xx_mac80211] [e4a50d6b] bcm43xx_lo_g_ctl_current+0x3b/0x3e [bcm43xx_mac80211] [e4a50e4f] bcm43xx_lo_g_adjust+0x8/0x12 [bcm43xx_mac80211] [e4a4b97a] bcm43xx_phy_init_pctl+0x2ed/0x5fc [bcm43xx_mac80211] [e4a466f0] bcm43xx_phy_write+0x5c/0x64 [bcm43xx_mac80211] [e4a4e998] bcm43xx_phy_initg+0xbe2/0xc44 [bcm43xx_mac80211] [e4a4f125] bcm43xx_phy_init+0x518/0x534 [bcm43xx_mac80211] [e4a4254b] bcm43xx_chip_init+0x639/0x904 [bcm43xx_mac80211] [e4a43509] bcm43xx_wireless_core_init+0x21e/0x67a [bcm43xx_mac80211] [e4a44cd1] bcm43xx_add_interface+0x56/0xe1 [bcm43xx_mac80211] bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 30-bit DMA initialized bcm43xx_mac80211: Wireless interface started bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_mac80211: Removing Interface type 2 bcm43xx_mac80211: Wireless interface stopped bcm43xx_mac80211: DMA-32 0x0200 (RX) max used slots: 1/64 bcm43xx_mac80211: DMA-32 0x02A0 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0280 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0260 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0240 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0220 (TX) max used slots: 2/128 bcm43xx_mac80211: DMA-32 0x0200 (TX) max used slots: 0/128 bcm43xx_mac80211: Radio turned off bcm43xx_mac80211: Radio turned off bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Loading firmware version 371.1061 (2006-10-04 21:02:04) bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 30-bit DMA initialized bcm43xx_mac80211: Wireless interface started bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_mac80211: Removing Interface type 2 bcm43xx_mac80211: Wireless interface stopped bcm43xx_mac80211: DMA-32 0x0200 (RX) max used slots: 1/64 bcm43xx_mac80211: DMA-32 0x02A0 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0280 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0260 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0240 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0220 (TX) max used slots: 2/128 bcm43xx_mac80211: DMA-32 0x0200 (TX) max used slots: 0/128
Re: Ferrari 3400 device?
Note: I am not a developer, just a user with different sleeping habits, and so responded first. Don't take the FIRST response as the BEST response, just the first. First, the 4306 is an older car and certainly is well supported by the bcm43xx code, much better so than the 4318. Second, the original bcm43xx code uses v.3 of the virmware. Thew new bcm43xx_mac80211 code (default in F7) uses v.4 of the firmware. The original works best in kernel 2.6.21-rc3 or better (other than F7). The new works best in the wireless-dev tree available via git. Lastly, there is a known POWER problem, which results in better transmission if the transmission rates are reduced. Please include: 1. root# uname -a 2. root# dmesg | grep bcm 3. root# iwconfig and if you're not actually connected it sometimes helps to add 4. root# iwlist eth1 scan (or iwlist wlan0 scan or whatever your interface is called) I hope this information has helped rather than hurt, Kind regards, Ehud Gavron Tucson AZ USA Toronto: Paul Tracy. Silverstone: Lewis Hamilton: Lime Rock: McNish/Capello or Pirro/Werner Daytone: JPM IndyOvalDoodle: WTFC Andreas Peer wrote: I don't know if this matters, but I have a Acer Ferrari 3400 notebook, and according to the device list on the web site, the wireless chip should be the following: - chip id: 4318 - product id: 0x4318 - subsystem vendor id: 0x1468 - subsystem product id 0x0312, but instead lspci shows me that the notebook contains a chip with - chip id: 4306 - product id: 0x4320 - subsystem vendor id: 0x185f - subsystem product id 0x1220. It is to original chip that was contained when I bought the notebook. Maybe the information on the device site is not accurate, or Acer put different chips inside their Ferrari 3400 notebooks? Another question: The driver works, but it has a much lower range than the Windows driver, i.e. I am not able to get a connection in places where on Windows I can connect with 36 MB/s and a good signal quality. Is this a known limitation? I think some time ago I read that bcm43xx uses firmware version 2.x, while the Windows drivers are already using version 3.x. Is that the problem, and is there a hope that the receiving quality will improve in the future? Last, but not least I want to say that i appreciate your work and I want to thank you for what you have than for the Open Source community! Andreas ___ 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: Ferrari 3400 device?
Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK Extra: Last beacon: 40ms ago I have to add that I am sitting just in front of the wireless router. The distance between router and notebook is at max half a meter. I find it also interesting, that iwlist and iwconfig show different quality percentages. Kind regards, Andreas Note: I am not a developer, just a user with different sleeping habits, and so responded first. Don't take the FIRST response as the BEST response, just the first. First, the 4306 is an older car and certainly is well supported by the bcm43xx code, much better so than the 4318. Second, the original bcm43xx code uses v.3 of the virmware. Thew new bcm43xx_mac80211 code (default in F7) uses v.4 of the firmware. The original works best in kernel 2.6.21-rc3 or better (other than F7). The new works best in the wireless-dev tree available via git. Lastly, there is a known POWER problem, which results in better transmission if the transmission rates are reduced. Please include: 1. root# uname -a 2. root# dmesg | grep bcm 3. root# iwconfig and if you're not actually connected it sometimes helps to add 4. root# iwlist eth1 scan (or iwlist wlan0 scan or whatever your interface is called) I hope this information has helped rather than hurt, Kind regards, Ehud Gavron Tucson AZ USA Toronto: Paul Tracy. Silverstone: Lewis Hamilton: Lime Rock: McNish/Capello or Pirro/Werner Daytone: JPM IndyOvalDoodle: WTFC Andreas Peer wrote: I don't know if this matters, but I have a Acer Ferrari 3400 notebook, and according to the device list on the web site, the wireless chip should be the following: - chip id: 4318 - product id: 0x4318 - subsystem vendor id: 0x1468 - subsystem product id 0x0312, but instead lspci shows me that the notebook contains a chip with - chip id: 4306 - product id: 0x4320 - subsystem vendor id: 0x185f - subsystem product id 0x1220. It is to original chip that was contained when I bought the notebook. Maybe the information on the device site is not accurate, or Acer put different chips inside their Ferrari 3400 notebooks? Another question: The driver works, but it has a much lower range than the Windows driver, i.e. I am not able to get a connection in places where on Windows I can connect with 36 MB/s and a good signal quality. Is this a known limitation? I think some time ago I read that bcm43xx uses firmware version 2.x, while the Windows drivers are already using version 3.x. Is that the problem, and is there a hope that the receiving quality will improve in the future? Last, but not least I want to say that i appreciate your work and I want to thank you for what you have than for the Open Source community! Andreas ___ 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: bcm4312 on again, off again
You know, people read this list TO HELP PEOPLE. That's right. I'm up at 2307 my time hoping that I can provide some information that will help you get your bcm43xx device functional, or that failing that I can help you provide information so the folks that work between the firmware, the reverse-engineered speficiations, and the driver can make it work. NOTHING would please me more than to see your device work. I feel I would not be happy if it were not to work. And yet, unfortunately, in this imperfect world I must work with some imperfections... like Zero diagnostic information. Ndiswrapper typically works in about 5 seconds, so not only no diagnostic information, but your BS programmer is 4 hours 59 minutes and 55 seconds full of BS. You don't mention your kernel version. You don't include a uname -a or a dmesg | grep bcm43 Now let's talk English chip talking -- meaningless a kernel build -- meaningless wireless was showing -- meaningless wifi switch light -- meaningless not making up to -- meaningless actually use the signal -- meaningless it suddenly stops -- almost meaningless. SOmething that might have been previously defined (but wasn't) no longer words. it's on again -- same comment as above Any clues -- no, you don't have any SO... I'd say good luck but it looks like you don't have any of that either. Ehud Robert Easter wrote: It took a BS programmer over five hours, but he got my bcm4318 chip talking to my computer with the NDISWrapper and a kernel build. Before that the wireless was showing on the laptop's wifi switch light but not making up to the computer to actually use the signal. Now, after six days, it suddenly stops. Give it a few days, and it's on again. Any clues? ___ 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: Broadcom 4318 with newer bcm43xxfirmware doesn't works
Right. E Florian Erfurth wrote: Von: Ehud Gavron [EMAIL PROTECTED] One of the things I did is put the v3 firmware in /lib/firmware only I renamed the files from *.fw to *.fw3.fw I then can do modprobe bcm43xx fwpostfix=.fw3 to load the bcm43xx module with the old firmware. If I modprobe without parameters, then the *.fw files are loaded. Am I right? If yes, then I don't need to do that, because I already replaced the V4 firmware by V3 ones. And in the future (if bcm4318 works well with V4) I'll switch back to V4. Thank you! Floh smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
F7 with newer kernel
I use F7, and having had the same disappointing results upgraded my kernel. IF YOU USE NVIDIA VIDEO DRIVERS DO THIS ONLY AFTER FOLLOWING THE PROCEDURE BELOW MY SIGNATURE Building the latest Larry Linville kernel on F7 systems: # cd /usr/src # git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git # ln wireless-dev linux # cd /usr/src/linux # cp /usr/src/kernels/2.6.21-1.3228.fc7-x86_64/.config ./.config # make clean # make oldconfig (Answer the questions any way you like... hitting enter a bunch of times works.) # grep -i bcm43xx .config (mine is included below) # time nice make bzImage(mine takes 9 min) # time nice make modules(mine takes 44 min) # time nice make modules_install (mine takes 1 min) # time nice make install(mine takes 1 min) # sed -i -e s/default=1/default=0/g /etc/grub.conf Note that in the future you'll want to do yum update --exclude=kernel --exclude=kmod-nvidia --exclude=xorg-x11-drv-nvidia until F7 releases a kernel which postdates 2.6.22-rc6 (likely that would be 2.6.22 ;-) Then reboot... your new kernel will work much better with your wireless driver. If you're using a proprietary driver for your graphics card, see the note below. Ehud Here's my .config section, and for future searches F7 .config for kernel 2.6.22-rc6 wireless-dev # grep -i bcm43xx .config CONFIG_BCM43XX=m CONFIG_BCM43XX_DEBUG=y CONFIG_BCM43XX_DMA=y CONFIG_BCM43XX_PIO=y CONFIG_BCM43XX_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_DMA_MODE is not set # CONFIG_BCM43XX_PIO_MODE is not set CONFIG_BCM43XX_MAC80211=m CONFIG_BCM43XX_MAC80211_PCI=y CONFIG_BCM43XX_MAC80211_PCMCIA=y CONFIG_BCM43XX_MAC80211_DEBUG=y CONFIG_BCM43XX_MAC80211_DMA=y CONFIG_BCM43XX_MAC80211_PIO=y CONFIG_BCM43XX_MAC80211_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_MAC80211_DMA_MODE is not set # CONFIG_BCM43XX_MAC80211_PIO_MODE is not set Note on proprietary graphics card drivers and F7 the Livna and the AT people are really nice about packaging these for the specific F7 releases. However, when you switch off to your own kernel you need to build those packages from source. Unfortunately the packages from the vendors (mine's Nvidia) put files in different places than the livna ones. So what I had to do was... Nvidia Drivers on F7 with alternate kernel, hard work the first time, only one script to run after future kernel upgrades. 1. rpm -e kmod-nvidia 2. bring in the nvidia stuff and put it somewhere (I chose /usr/local/src/nvidia) 3. the first time run the whole thing and let it install its version of libraries, build a kernel module, etc. (Answer no to precompiled module and answer no to search website for precompiled module.) 4. make sure X works, and if you had Desktop Effects (compiz) enabled, check to make sure that works. The problems I encountered were on my 64-bit system the Nvidia installer wants to place the files in /usr/lib64/X11R6 but the Xorg stuff wants it in /usr/lib64/xorg/modules... 5. make sure that the whole Nvidia startup in /etc/rc.d/init.d is gone. It will munge your /etc/X11/xorg.conf every boot. 6. ONCE YOU GET VIDEO WORKING JUST FINE, AND SURVIVING A REBOOT, only then do the procedure above to upgrade your kernel. 7. Once you reboot with the new kernel, you'll want to run this script: #/bin/sh # If the kernel version has changed, rebuild the Nvidia package... NVDIR=/usr/local/src/nvidia # if [ ! -f $NVDIR/kernel_version.txt ]; then echo No previous kernel configured $NVDIR/kernel_version.txt fi oldkern=`cat $NVDIR/kernel_version.txt newkern=`uname -r` if [ $oldkern != $newkern ]; then # The kernels differ ... build a new one... arch=`arch` file=`ls -C1 $NVDIR/*$arch*.run | tail -1` $NVDIR/$file -sKN $NVDIR/build.out 21 uname -r $NVDIR/kernel_version.txt fi #end Florian Erfurth wrote: Von: Larry Finger [EMAIL PROTECTED] Florian Erfurth wrote: [EMAIL PROTECTED] ~]# dmesg [snip] bcm43xx driver Hm... what could be wrong? Did I forgot somewhat? Did you switch back to V3 firmware? Check dmesg for any diagnostic messages. Yes, I switched back to V3 firmware. In dmesg only 'bcm43xx driver' appears. O_o Ok, I should try to reboot, but I can't do that now. I'll try rebooting later (maybe tommorow in the morning). Thank you for your great help. cu Floh 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: Broadcom 4318 with newer bcm43xxfirmware doesn't works
One of the things I did is put the v3 firmware in /lib/firmware only I
renamed the files from *.fw to *.fw3.fw
I then can do modprobe bcm43xx fwpostfix=.fw3 to load the bcm43xx
module with the old firmware.
put all v3 firmware files in /lib/firmware/v3
# cd /lib/firmware/v3
# ls -C1 *.fw | awk -F\. '{print $1}' | xargs -i$ cp $.fw $.fw3.fw
# mv *.fw3.fw /lib/firmware/
Ehud
Larry Finger wrote:
Did you switch back to V3 firmware? Check dmesg for any diagnostic messages.
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
2.6.22-rc6, dhcp, promiscuous mode, and other things
I've been alternately switching between 2.6.22-rc3 (Linville git tree) and 2.5.22-rc6 (Linville git tree as of today), henceforth rc3 and rc6 respectively. I've been alternately switching between bcm43xx and bcm43xx_mac80211, henceforth soft and hard respectively. About the only thing I've found strange that I hope someone else can confirm, is that running a tcpdump simultaneously with the DHCP client causes more success than failure. Oh yeah, here's another aside. My DHCP server is actually an Adtran Netvanta 1224STR, so it is kind enough to supply debugging messages. When running rc3 hard, here's what I see dhclient - reports it's asking for an address tcpdump - shows the bootpc request router - shows it received the request and sent back a reply otherpc-running-tcpdump - shows the reply coming back tcpdump - never shows the reply coming back!!! tcpdump - shows 802.1d and other frames coming from the router dhclient - times out So clearly the router and the laptop ARE successfully exchanging traffic, but yet for some reason the laptop is not seeing the bootps reply on the initial request under rc3 hard. If I had to do a matrix it would look like this: rc6 hard - works but stuck at 1Mbps rc6 soft - works rc6 hard - unable to communicate, but associates fine rc6 soft - works More data follows. I hope some of this rings a bell in someone's mind. If anyone wants me to do testing, I'm in that mood again, and I've got 2.6.21 (F7), 2.6.22-rc3(linville) and 2.6.22-rc6(linville) all ready to go. OH YEAH for full disclosure... my kernel is tainted by the Nvidia module... Ehud rc6 and hard works but not very well. the rate is stuck at 1Mbps, and dhcp client only works if I simultaneously open a tcpdump session on that interface. eth1 IEEE 802.11g ESSID:wetwork Mode:Managed Frequency:2.437 GHz Access Point: 00:0D:0B:11:5C:1B Bit Rate=1 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:896A-0055-AE77-5E80-ED86-4E38-3A Link Quality=55/100 Signal level=-36 dBm Noise level=-84 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 that's hard mac 1 meter away from the access point. Note that the driver will not allow me to set the rate... says that's unsupported. Here's what the kernel spit out: 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 driver bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Loading firmware version 371.1061 (2006-10-04 21:02:04) bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: !WARNING! Idle-TSSI phy-cur_idle_tssi measuring failed. (cur= 30, tgt=62). Disabling TX power adjustment. bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 32-bit DMA initialized bcm43xx_mac80211: Wireless interface started bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:f f:ff:ff bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:f f:ff:ff rc3 hard does not work at all in the sense that both dhcp fails, and setting a hard address fails to successfully communicate. eth1 IEEE 802.11g ESSID:wetwork Mode:Managed Frequency:2.437 GHz Access Point: 00:0D:0B:11:5C:1B Bit Rate=48 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:896A-0055-AE77-5E80-ED86-4E38-3A Link Quality=219/146 Signal level=-201 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 rc3 soft works tho: eth1 IEEE 802.11b/g ESSID:wetwork Nickname:egdell.wetwork.net Mode:Managed Frequency=2.437 GHz Access Point: 00:0D:0B:11:5C:1B Bit Rate=24 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:896A-0055-AE77-5E80-FD86-4E38-6B Security mode:open Link Quality=86/100 Signal level=-48 dBm Noise level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 NOTE: the softmac driver will allow me to change rates. 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.22-rc6, dhcp, promiscuous mode, and other things
Pavel, thank you for your note:) Please let me know which kernel you recommend I try, and I will happily download and try it. FYI while I have left the SSID unchanged (WHY do people munge that???) I did munge the keys, so you can safely ignore that. ON the other hand should you ever be anywhere near my house in Tucson Arizona USA, please do let me know, and I'll happily provide you the real credentials for authenticating on the network. *cheers* Ehud PS Ok, I thought bcm43xx vs bcm43xx_mac80211 was soft because it used softmac and bcm43xx_mac80211 used the old devicescape-stack which is alternately the non-soft (or hard) stack. If there's a better terminology, I look forward to being educated. In reference, I used 2.6.22-rc3 (linville git tree) 2.6.22-rc6 (linville git tree) and not included but previously tested 2.6.21-1.3228.fc7 Fedora kernel. All built from source and ready for changes if need be. Pavel Roskin wrote: Hello! On Tue, 2007-06-26 at 18:58 -0700, Ehud Gavron wrote: I've been alternately switching between 2.6.22-rc3 (Linville git tree) and 2.5.22-rc6 (Linville git tree as of today), henceforth rc3 and rc6 respectively. There have been significant changes in bcm43xx_mac80211 in its own git repository (http://bu3sch.de/git/wireless-dev.git), which improved things a lot. As far as I know, the changes are not in 2.6.22-rc6 yet, or you would have seen a backtrace. I've been alternately switching between bcm43xx and bcm43xx_mac80211, henceforth soft and hard respectively. There is nothing specifically hard in mac80211. You may need to use another convention. About the only thing I've found strange that I hope someone else can confirm, is that running a tcpdump simultaneously with the DHCP client causes more success than failure. I understand you mean tcpdump on the same machine as the driver. I think I may have seen it. Perhaps the promiscuous mode would speed up recalibration, or something like that. Anyway, the current git version of bcm43xx_mac80211 is working much better and should not need such tricks. If I had to do a matrix it would look like this: rc6 hard - works but stuck at 1Mbps rc6 soft - works rc6 hard - unable to communicate, but associates fine rc6 soft - works You may want to use another convention for kernel versions as well. They look too similar to me. Encryption key:896A-0055-AE77-5E80-ED86-4E38-3A I hope you understand you cannot reuse this key after having exposed it in a public forum. On the other hand, WEP is considered generally unsafe these days, so it's more an polite request to leave your network alone than actual security. 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: [bcm-users]
Is it possible your update killed fwcutter? I would try this 1. download a known good fwcutter 2. download a known good firmware 3. modprobe -r bcm43xx 4. modprobe -r bcm43xx_mac80211 5. modproble bcm43xx 6. dmesg and make sure it loaded the firmware, saw the cores, activated, etc. 7. resume normal life. If that doesn't work, I would also go back to the 2.6.22-rc4 tree and do make modules_install Ehud Chuckk Hubbard wrote: Hi. I have a 4311 on a Gateway MX6447. I am running 64studio, an offshoot of Debian. I downloaded kernel 2.6.21 and patched it to 2.6.22-rc4 (for my soundcard), copied the configuration, and made sure all the bcm43xx options were selected. I compiled the kernel, installed bcm43xx-fwcutter, and ran it on wl_apsta.o from http://boredklink.googlepages.com/wl_apsta.o I entered my wep code and was online for a while. I had added Debian unstable to my repositories, and did an update/upgrade, and immediately after it finished the wireless went down. However, I doublechecked that bcm43xx and /lib/firmware weren't involved in any of the upgraded packages, and the kernel is still my custom kernel. The network dialog still shows eth1 active, still shows the list of APs, and still has the passcode; iwlist eth1 scan still shows a list of APs, including mine. The access point was showing as invalid, but after I turned the radio LED off and on, it showed as an address. I've rebooted the system a few times, rechecked everything. Still no errors, still shows as connected, but nothing received. I did try modprobe bcm43xx just in case, no difference. I did try re-cutting the firmware, and now bcm43xx-fwcutter /lib/firmware ./wl_apsta.o says that wl_apsta.o has an invalid checksum; however, when I checked the sum under Windows, it told me a different number than what fwcutter said. Can anyone help me? -Chuckk -- http://www.badmuthahubbard.com ___ 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: wlan 1390, broadcom bcm4311
Ndiswrapper works fine, ignore the 4k stacks warning. Your firmware seems fine. Here's my 4311 (Dell 1390): bcm43xx_mac80211: Loading firmware version 371.1061 (2006-10-04 21:02:04) The fact that you see APs in the scan means it works. You didn't include the iwlist, so we can't tell if it's a weak reception under bcm43xx_mac80211 (but I suspect it is) that's causing the dissassociation. As for the Mode and the Rate remove the extraneous parameters from your /etc/sysconfig/network-scripts/ifup-eth1.cfg Ehud John Pierce wrote: Hello and greetings to the list members. I have been using opensuse 10.2 with the ndiswrapper on a 2.6.18 kernel and this worked. I just recently converted this laptop to fedora 7 with a 2.6.21 kernel. I have found that ndiswrapper will not drive the card because of the 4k stacks. I have been trying to figure out the bcm43xx_mac80211 and I keep coming up short. Here is what I have tried and some of the responses; I have read that I need the ver 4 firmware so I downloaded it from here, http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o. and when I modprobe the driver I find this line in the dmesg output bcm43xx_mac80211: Loading firmware version 351.126 (2006-07-29 05:54:02) Does this look like the correct firmware version? I am not sure! Here is the interesting part, if I bring up wlan0 and do a iwlist scanning I see my cell along with about 6 others in the neighborhood, but I keep getting these messages in the dmesg output: bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Loading firmware version 351.126 (2006-07-29 05:54:02) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: !WARNING! Idle-TSSI phy-cur_idle_tssi measuring failed. (cur=26, tgt=62). Disabling TX power adjustment. bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 32-bit DMA initialized bcm43xx_mac80211: Wireless interface started ADDRCONF(NETDEV_UP): wlan0: link is not ready bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:11:95:2c:26:02 wlan0: RX authentication from 00:11:95:2c:26:02 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:11:95:2c:26:02 wlan0: RX ReassocResp from 00:11:95:2c:26:02 (capab=0x431 status=0 aid=3) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present wlan0: No ProbeResp from current AP 00:11:95:2c:26:02 - assume out of range wlan0: No STA entry for own AP 00:11:95:2c:26:02 wlan0: No STA entry for own AP 00:11:95:2c:26:02 wlan0: No STA entry for own AP 00:11:95:2c:26:02 wlan0: No STA entry for own AP 00:11:95:2c:26:02 Also, when I bring up the link I get the following messages from the ifup command: Error for wireless request Set Mode (8B06) : SET failed on device wlan0 ; Invalid argument. Error for wireless request Set Bit Rate (8B20) : SET failed on device wlan0 ; Operation not supported. This is the output of lspci -vn 03:00.0 0280: 14e4:4311 (rev 01) Subsystem: 103c:1363 Flags: fast devsel, IRQ 21 Memory at b800 (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 I know that I am close, I can get a scanning of the cells around my area. Just not quite there yet. Oh, I tried the router with encryption off and the system wide open, as well as my usual wep encryption. Still no joy. The system is an HP Pavillion DV9208NR and the pcie card is listed a dell wlan 1390. Any thoughts, suggestions, or hints would be greatly appreciated. If I can supply any further information I will be glad to. I am also will to help with the debugging and correction of any potential problems. It would not be the first time I have torn down and put back together a system. 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: wlan 1390, broadcom bcm4311
In your private reply you show great progress (but you didn't CC the list on that one so make reference to it only). Since I didn't know where you were going (ndiswrapper or bcm43xx) I also didn't mention that you are running the F7 2.6.21 kernel... and that kernel needs patching from Larry's stuff at ftp://lwfinger.dynalias.org/patches/. You might try downloading the kernel source RPM... patching it... and then building that. It IS a pain (and no I haven't done it for this one). I did try 2.6.22-rc3 but it lacks the bcm43xx_mac80211 out of the box and I didn't want to revert to softmac. Ehud John Pierce wrote: Ok, I spoke to soon. The system slowed down to a crawl and then finally the connection was lost. I will continue to try and capture pertinent information. I will post back when I find something that may be useful. smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
bcm43xx with 2.6.21 vanilla and larry's combined patch loops; with the bcm-softmac-sa fails to associate [4311]
Ok, so I was bored... and installed the 2.6.21 kernel. I then patch -p1 combined_2.6.21.patch make make modules_install make install sync reboot -f The bcm43xx modules reports associated... scanning... associated... with another message in the middle, about once every half second without stopping. The dmesg shows radio on, link not ready, link associated, radio off, [repeats] At this point it appears to be a race condition to unload the bcm43xx module. A simple ifdown eth1 rmmod bcm43xx will either succeed, or crash (and crash is either the system is frozen, or a kernel panic). An rmmod bcm43xx without the ifdown triggers similar responses. tar -jxvf bcm-softmac-sa.tar.bz2 cd bcm-softmac-sa make make install sync reboot -f At this point the adapter behaves much like it did back in the 2.6.18 days. The essid I give it via iwconfig only shows the first letter, and eventually switches to Broadcom 4311 or the like. The WEP key remains as programmed. It never associates. The log shows scanning... scanning... never associates. -- One more note. Prior to installing bcm-softmac-sa the bcm43xx scan identifies 13 channels. After installing bcm-softw=mac-ca the scan identifies 14 channels. I hope I'm not wasting everyone's time with a known issue. If I'm not, kindly let me know what I'm doing wrong so that I can build it correctly and get it working to help further the testing process... Thanks Ehud PS I am running the nvidia video driver... but the same symptoms were occurring prior to its installation. [EMAIL PROTECTED] lfinger]# uname -a Linux egdell.login.com 2.6.21 #1 SMP Thu May 3 22:12:46 MST 2007 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] lfinger]# lspci -n 00:00.0 0600: 8086:27a0 (rev 03) 00:01.0 0604: 8086:27a1 (rev 03) 00:1b.0 0403: 8086:27d8 (rev 01) 00:1c.0 0604: 8086:27d0 (rev 01) 00:1c.1 0604: 8086:27d2 (rev 01) 00:1c.2 0604: 8086:27d4 (rev 01) 00:1d.0 0c03: 8086:27c8 (rev 01) 00:1d.1 0c03: 8086:27c9 (rev 01) 00:1d.2 0c03: 8086:27ca (rev 01) 00:1d.3 0c03: 8086:27cb (rev 01) 00:1d.7 0c03: 8086:27cc (rev 01) 00:1e.0 0604: 8086:2448 (rev e1) 00:1f.0 0601: 8086:27b9 (rev 01) 00:1f.2 0101: 8086:27c4 (rev 01) 00:1f.3 0c05: 8086:27da (rev 01) 01:00.0 0300: 10de:01d7 (rev a1) 03:01.0 0607: 1217:6972 (rev 40) 09:00.0 0200: 14e4:1600 (rev 02) 0c:00.0 0280: 14e4:4311 (rev 01) 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: bcm43xx with 2.6.21 vanilla and larry's combined patch loops; with the bcm-softmac-sa fails to associate [4311]
Just to be precise, I repeated everything. Here it is in gory detail, except that I don't know how to capture the panic attack info because the system is stuck and I think a camera screenshot would be lame ;) tar -zxvf linux-2.6.21.tar.gz mv linux-2.6.21 /usr/src ln -s /usr/src/linux-2.6.21 /usr/src/linux cd /usr/src/linux patch -p1 ../combined_2.6.21.patch [all patches applied. No errors. No reversed patches. No failure to find chunks, etc.] cp /usr/src/kernels/2.6.20-1.2948.fc6-i686/.config . make mrproper make make modules_install make sync reboot -f - On reboot, it associates immediately. It even succeeds in getting a DHCP address. I am excited. But then. It doesn't work. Symptom: RX count increases. tcpdump shows normal incoming packets on the wireless... 802.1d, announcements, UPnP, traffic. TX count does not increase. Even if I explicitly ping it does not increase. Moved to within 2ft (.66M) from the xcvr. Still TX count not increasing. ifdown/ifup. Radio off/radio on. Associated. Still no TXcount increase. - Larry since it works for you out of the box with the composite patch, it must be something else vestigially left over from my Zod installation. Any thoughts on what I can try / what diagnostics I can run to figure out where the problem is? E PS Can't load bcm43xx_mac80211 (no such module) Diagnostic information: - arp shows the original info from the DHCP request/response. Can't arp for anything else. - Larry Finger wrote: Ehud Gavron wrote: Ok, so I was bored... and installed the 2.6.21 kernel. I then patch -p1 combined_2.6.21.patch make make modules_install make install sync reboot -f The bcm43xx modules reports associated... scanning... associated... with another message in the middle, about once every half second without stopping. The dmesg shows radio on, link not ready, link associated, radio off, [repeats] At this point it appears to be a race condition to unload the bcm43xx module. A simple ifdown eth1 rmmod bcm43xx will either succeed, or crash (and crash is either the system is frozen, or a kernel panic). An rmmod bcm43xx without the ifdown triggers similar responses. I cannot reproduce your problem using my 4311. I downloaded a fresh copy of 2.6.21 and patched it with the combined-2.6.21.patch from my FTP site. When I rebooted it came up just fine. In addition, I never see the kernel panics when removing the module. I use NetworkManager, which prevents an ifdown command, thus I just issue a 'modprobe -r bcm43xx' command. When you get a panic rather than a frozen system, please post the kernel panic dump. I have sometimes seen a problem when switching between bcm43xx-mac80211 and bcm43xx-softmac. The symptoms are 'bcm43xx: IRQ_READY timeout' and 'bcm43xx: core_up for active 802.11 core failed (-19)' messages, which indicate that the firmware is not running correctly. Sometimes unloading and reloading the module will fix this, but it may require powering the system off (cold reboot). -- One more note. Prior to installing bcm-softmac-sa the bcm43xx scan identifies 13 channels. After installing bcm-softw=mac-ca the scan identifies 14 channels. The standalone version does not have the recent patch that properly sets the channel range based on the locale setting. Thanks for noting this. 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: bcm43xx with 2.6.21 vanilla and larry's combined patch loops; with the bcm-softmac-sa fails to associate [4311]
Ehud Gavron wrote: Just to be precise, I repeated everything. Here it is in gory detail, except that I don't know how to capture the panic attack info because the system is stuck and I think a camera screenshot would be lame ;) tar -zxvf linux-2.6.21.tar.gz mv linux-2.6.21 /usr/src ln -s /usr/src/linux-2.6.21 /usr/src/linux cd /usr/src/linux patch -p1 ../combined_2.6.21.patch [all patches applied. No errors. No reversed patches. No failure to find chunks, etc.] cp /usr/src/kernels/2.6.20-1.2948.fc6-i686/.config . make mrproper make make modules_install make er, that's make install sync reboot -f - On reboot, it associates immediately. It even succeeds in getting a DHCP address. I am excited. But then. It doesn't work. Symptom: RX count increases. tcpdump shows normal incoming packets on the wireless... 802.1d, announcements, UPnP, traffic. TX count does not increase. Even if I explicitly ping it does not increase. Moved to within 2ft (.66M) from the xcvr. Still TX count not increasing. ifdown/ifup. Radio off/radio on. Associated. Still no TXcount increase. - Larry since it works for you out of the box with the composite patch, it must be something else vestigially left over from my Zod installation. Any thoughts on what I can try / what diagnostics I can run to figure out where the problem is? E PS Can't load bcm43xx_mac80211 (no such module) Diagnostic information: - arp shows the original info from the DHCP request/response. Can't arp for anything else. - Larry Finger wrote: Ehud Gavron wrote: Ok, so I was bored... and installed the 2.6.21 kernel. I then patch -p1 combined_2.6.21.patch make make modules_install make install sync reboot -f The bcm43xx modules reports associated... scanning... associated... with another message in the middle, about once every half second without stopping. The dmesg shows radio on, link not ready, link associated, radio off, [repeats] At this point it appears to be a race condition to unload the bcm43xx module. A simple ifdown eth1 rmmod bcm43xx will either succeed, or crash (and crash is either the system is frozen, or a kernel panic). An rmmod bcm43xx without the ifdown triggers similar responses. I cannot reproduce your problem using my 4311. I downloaded a fresh copy of 2.6.21 and patched it with the combined-2.6.21.patch from my FTP site. When I rebooted it came up just fine. In addition, I never see the kernel panics when removing the module. I use NetworkManager, which prevents an ifdown command, thus I just issue a 'modprobe -r bcm43xx' command. When you get a panic rather than a frozen system, please post the kernel panic dump. I have sometimes seen a problem when switching between bcm43xx-mac80211 and bcm43xx-softmac. The symptoms are 'bcm43xx: IRQ_READY timeout' and 'bcm43xx: core_up for active 802.11 core failed (-19)' messages, which indicate that the firmware is not running correctly. Sometimes unloading and reloading the module will fix this, but it may require powering the system off (cold reboot). -- One more note. Prior to installing bcm-softmac-sa the bcm43xx scan identifies 13 channels. After installing bcm-softw=mac-ca the scan identifies 14 channels. The standalone version does not have the recent patch that properly sets the channel range based on the locale setting. Thanks for noting this. 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 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: Vmware install on Mandriva 2007.0 kills bcm43 wireless
You can't used bridged networking on wireless. Use NAT. Ehud Gary Radford wrote: New install on Athlonx64 Emachines M6809 with Mandriva x86-32 2007.0 with all current updates. I had my wireless bcm43 working for a couple of hours and a few reboots (x86-64 2007, the wireless is not working). I installed vmware (using all the defaults and with bridged networks on the wireless)and now the network is not working. Is this a possible cause of the loss of wireless? When I use network manager to run the wizard NetworkInternet configuration on the Broadcom Corp BCM94306 802.11g NIC and select Advanced there are no values in the NetworkID,Operating frequency,. iwconfig. Should these normally be empty/blank. When I select the Manage Wireless Networks my network signal strength is red with 2 bars, but when I disconnect the signal strength is green with 5 bars Many thanks to all for the effort on this driver. Having wireless and virtual machines are my last steps to get off dual booting. ___ 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: Vmware install on Mandriva 2007.0 kills bcm43 wireless
Trimmed. You can't used bridged networking for wireless. You don't do this on Windoze and it won't work on Linux. http://www.extremetech.com/article2/0,1697,1156371,00.asp If that isn't clear try http://www.google.com/search?sourceid=mozclientie=utf-8oe=utf-8q=vmware+bridged+wireless Either way this is NOT a BCM43xx issue. Ehud Igor Korot wrote: Hi, -Original Message- From: Ehud Gavron [EMAIL PROTECTED] ... Subject: Re: Vmware install on Mandriva 2007.0 kills bcm43 wireless You can't used bridged networking on wireless. Use NAT. On Windows, I run VMware-player over the wireless network. So, it is possible However, it looks like Linux do not support this? 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: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
Possibly. I'll ensure an ifdown before rmmod in the future. Upon my return to home it associated and wep'ized but was still unable to exchange traffic (rxcount and txcount incrementing on if, wireshark sees traffic, but the interface refuses to stay ifconfig'd up with an ip. Turns radio off. Makes ip go away. Solid 85/100 on the iwconfig. rmmod bcm43xx; ndiswrapper works.) Removed new modules from the ftp download, make modules_install in the kernel source tree from 03/30, modprobe bcm43xx... works ok. Plain iwconfig/ifconfig not even using network-scripts. Various APs at the Golden Nugget, McCarran, and now my house. Work fine with older code. Work with ndiswrapper. Did not work with newer code, although like I said it wasn't that it failed but rather wouldn't stay up long enough to pass IP packets or keep the address on the interface. Let me know what other diagnostics/tests I can run... I just got back from five days in Vegas, so I need a drink and some debugging to unwind ;) Ehud Larry Finger wrote: Ehud Gavron wrote: Feedback: the make files work. However... this version of the driver is unusable. It's worse than the one I downloaded March 30th (latest 2.6.20). Dell 1390 (BCM4311). By worse I mean that I won't stay associated with an AP; it reverts to previous ESSID even after associating with new AP new ESSID, and it reverts to having previous WEP key set even with explicit iwconfig eth1 key off. It also keeps turning the interface off (dmesg: bcm43xx: Radio turned off) and requires ifconfig eth1 up to get it refired. Most important: an rmmod bcm43xx hung the system completely and it needed a cold-start to continue. Tested at the Golden Nugget and McCarran airport... so I know it's not any idosyncracy of MY networks ;) Perhaps that is your penalty for computing rather than gambling. :-) I'm a resident of Nevada and we need the gaming tax income. I don't know about the system hang when rmmod'ing the driver. I do that all the time here without any problems. There probably is some time window that you were unlucky enough to hit. Issuing an ifdown before the rmmod should fix that. I have not tested trying to change AP's. What support software were you using? Was it just plain ifup/ifdown or something else like NetworkManager? Have you been able to associate with several AP's with the older version? I don't know of anything in either bcm43xx or softmac that would cause it to try automatic roaming or change the ESSID. Perhaps someone else in the list knows better. 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: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
Removed module.symvers. Make; make install. rmmod bcm43xx hung (yes I forgot to ifconfig down ;) reboot... module now works perfectly. I am unable to see the behavior I saw before: namely ifconfig rxcount goes to 0, txcount goes low, radio off, radio on, rxcount+, txcount+++, dhcp works, give it a second, down again. repeats. Right now what I'm seeing is a perfectly working system. I have moved different APs within the same ESSID (WEP enabled) and no problems are evident. I'm getting TCP throughput of 7Mbps (on my Comcast 6Mbps link) and I haven't configured any in-LAN testing facilities (yet. The night is young.) Ehud PS I know that newbies get the respect of somewhere between Peter who cried Wolf and zero. I swear it really (repeatedly) didn't work, and now with that one (insignificant...) change it works perfectly. The reboot is not a factor as I'd done three on the old system. (Golden Nugget. Overnight. McCarran. Home.) Pavel Roskin wrote: On Mon, 2007-04-09 at 10:08 -0500, Larry Finger wrote: John H. wrote: I ended up just using the following... http://www.howtoforge.com/kernel_compilation_fedora Can I get a patched version of the bcm43xx source and just compile that? I just put a standalone tarball for the latest version of bcm43xx-softmac onto my FTP site at ftp://lwfinger.dynalias.org/patches/bcm43xx-softmac-sa.tar.bz2. You should download it, unpack it, cd to bcm43xx-softmac-sa, issue a make command, and finish with a 'sudo make install'. That should build and install new versions of bcm43xx.ko and the various parts of ieee80211 and ieee80211-softmac. The make files have not been thoroughly tested, and I welcome your comments and/or difficulties. Just a quick feedback on that package. Please don't include Module.symvers, your version is not useful for anyone else. It will be generated is needed. I'm getting a compile error: /home/proski/src/bcm43xx-softmac-sa/bcm43xx/bcm43xx.h:896:3: error: #error Using neither DMA nor PIO? Confused... I think the best solution would be to define both CONFIG_BCM43XX_DMA and CONFIG_BCM43XX_PIO. You make want to make it configurable, but then don't compile bcm43xx_pio.c and bcm43xx_dma.c unconditionally. The debugfs requirement seems to defeat the whole purpose of the standalone distribution. BCM43xx_NR_LOGGED_XMITSTATUS is defined only if CONFIG_BCM43XX_DEBUG is defined, but bcm43xx_debugfs.c uses it unconditionally. There may be more compile problems, but I gave up at this point. Speaking of the build system, you may want to have a warning in case if anything that is compiled as a module (either bcm43xx or softmac) is already available and linked into the kernel. Make sure the checks don't affect make clean and similar maintenance commands. 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: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
Yes, it's a kernel from source, renamed to the current fc6 uname-r for a closed video driver. [EMAIL PROTECTED] linux]# cd /usr/src/linux grep -i bcm .config | grep -i debug CONFIG_BCM43XX_DEBUG=y CONFIG_BCM43XX_MAC80211_DEBUG=y Ehud Pavel Roskin wrote: On Mon, 2007-04-09 at 17:52 -0700, Ehud Gavron wrote: Removed module.symvers. Make; make install. rmmod bcm43xx hung (yes I forgot to ifconfig down ;) reboot... module now works perfectly. This means that you already have CONFIG_BCM43XX_DEBUG defined in .config, right? I guess you had to recompile the kernel anyway, or at least reconfigure it. That's not how a _standalone_ driver should work, in my opinion. I am unable to see the behavior I saw before: namely ifconfig rxcount goes to 0, txcount goes low, radio off, radio on, rxcount+, txcount+++, dhcp works, give it a second, down again. repeats. Right now what I'm seeing is a perfectly working system. I have moved different APs within the same ESSID (WEP enabled) and no problems are evident. I'm getting TCP throughput of 7Mbps (on my Comcast 6Mbps link) and I haven't configured any in-LAN testing facilities (yet. The night is young.) Yes, the current bcm43xx is pretty good at data transfer. And it doesn't crash my Mac anymore, even though I put my oldest card there, just to make things harder. And it works with a bizarre Linksys AP to which bcm43xx_mac80211 won't connect. Just be careful with rates of 48 and 54 Mbps, they are still unstable. The default 24 Mbps is a good default for me. 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: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
I am also unable to get bcm43xx to connect to my WRT54G (which I pulled out of the network kit to do this test). It connects just fine to the Buffalo WBR54Gs. (The case does not have any ID other than WRT54G... no version number or anything.) Ehud Larry Finger wrote: Do you think that is a Linksys AP problem? I cannot get mac80211 to connect to my WRT54G V5 AP? 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: dell wireless 1390 802.11 b/g Mini PCI support?
Since those changes are in the fedora-netdev repo, I downloaded that kernel* and performance jumped to over 7Mbps to outside testing places. Wow! Nice job guys! Thanks for the advice, Larry, and thanks for the hard work from the development and spec teams! Ehud *ok, it wasn't quite that simple because I have an Nvidia video card. First I downloaded kernel 2.6.20-1.2933.4.4.netdev.8.fc6, which replaced my 2.6.20-1.2933.fc6 (from fedora-updates repo). No more usable video because of the Nvidia kernel module, but I could verify that bcm43xx worked like a charm. Downloaded the kernel source RPM. Changed the kernel ID from -prep to -1.2933.fc6, built, installed, and now everything works like a charm... the bcm4311 card is running like a rocket... my Nvidia proprietary kernel module binary is loading... and life is good. In short, again, THANKS! I only mention the story so that other people tempted to just download the kernel will consider whether they too have to put up with vendors who are so shortsighted as to release binary-only modules requiring those of us who want to use their product (or have no choice, depending on circumstance) with the latest and greatest kernel... Larry Finger wrote: ... Use the very latest set of patches. The stuff that is coming with 2.6.21 changed my interface from working best at 1 Mbs to having the best throughput at 36 Mbs. It doesn't do as well as the Windows driver (ndiswrapper), but it isn't too far from it. My downlink from Time Warner is rated at Mbs, but I have not yet found an external site that can saturate it. I get almost as good a throughput as my wired interface on a 100 Mps link. All of the changes that are in 2.6.21 can be found at the ftp site in the previous messages. 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
