Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On Tue, Mar 23, 2010 at 11:23 PM, Chris Lopes clo...@gmail.com wrote: I didn't try a cold reboot that did not involve the removal of battery and power supply, so maybe it would work. Honestly I am still perplexed (given modern hardware and software), as to why/how: 1) Hibernate and un-hibernate, regardless of what happens in between with the wireless card, could somehow result in it stopping working 2) Rebooting (warm), regardless of how the wireless card is messed up in my situation does not fix the problem 3) Cold rebooting and warm rebooting are different in any way whatsoever (all of the above involve zero changes on the hard disk during the time when the OS is not running) Is this behavior some sort of feature with unintuitive results, or is it a bug? And what is the buggy component, exactly? It seems like something that would happen with early 1990's technology. Also, are you saying that there is some sort of known problem that results in you having to recover the wireless via a cold-reboot? What is this problem and is it similar to my situation? Well, the following sequence can easily happen: 1. You boot Vista. The Broadcom official driver initializes the card (writing a complete register setup) with the embedded firmware. 2. You hibernate Vista. The card is un-initialized and prepared for restore upon return from hibernation. Some registers are left in the state they were originally, to aid in quicker restore. 3. You boot Linux. b43 finds the Broadcom card, and, seeing that it is un-initialized, quickly initializes it (again, overwriting all registers, including the ones left intact by hibernation) with your installed firmware. Due to a known bug, the driver misses some part of the initialization routine; we are working on fixing this,. 4. With the card only partially initialized, DMA TX is broken. (On 2.6.33, b43 works around this by falling back to PIO.) 5. You leave Linux. b43 either doesn't uninitialize the card at all, or does a full uninit, in preparation for a shutdown (as opposed to hibernate) 6. You restore Vista. The Broadcom driver expects the card to be in the state it left it during hibernation; but it is really either in the (broken) init state produced by Linux, or completely uninitialized. The driver does a resume routine, assuming the card is prepared for it. The result of this operation is completely undefined; as my college programming professor once said: even if it becomes self-aware and nukes the world, it is still operating correctly. 7. You scan for wireless networks. The card is in an undefined state, so this obviously doesn't work! -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM 43
On Sat, Mar 13, 2010 at 7:48 PM, Michael Buesch m...@bu3sch.de wrote: On Saturday 13 March 2010 19:38:01 Gábor Stefanik wrote: I know this one it is compatible with aircrack supporting injection Thank you for your invaluable help .. thank As a general rule, do not bug Michael with injection-related questions; the only one in the team who cares about injection is me. Exception: when an injection-related problem also affects hostapd, feel free to contact Michael. WTF? Injection is not my business at all. It doesn't have _anything_ to do with the driver. It's purely a mac80211 stack feature. (So _any_ mac80211 based driver is supported by aircrack-ng, btw) So feel free to contact anybody but me, because I can't help you at all. -- Greetings, Michael. Well, it can definitely happen (and has happened in the past, though not in b43) that a driver bug hindered injection. See iwlagn for an example. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM 43
On Sat, Mar 13, 2010 at 7:05 PM, mic cat micac...@gmail.com wrote: Hi all i have 2 Broadcom network controller : BCM4312 802.11 B/G 14E4:4315 This is supported in 2.6.32 and newer; though you may need to compile with CONFIG_B43_FORCE_PIO if you have a netbook and/or a machine with PhoenixBIOS. (The latest compat-wireless package handles DMA/PIO selection automatically, no need to tinker with config options anymore.) Note that the kernel in BT4 is older than 2.6.32 - you need to compile install compat-wireless to gain support for this card. (Remember to apply any mac80211 patches that were present in the kernel to compat-wireless!) bcm 43XX 1.0 14e4:432b This is a BCM4322 (N-PHY). Work on it is ongoing. I know this one it is compatible with aircrack supporting injection Thank you for your invaluable help .. thank As a general rule, do not bug Michael with injection-related questions; the only one in the team who cares about injection is me. Exception: when an injection-related problem also affects hostapd, feel free to contact Michael. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On Mon, Mar 8, 2010 at 11:28 AM, Marc Haber mh+bcm43xx-...@zugschlus.de wrote: Hi Larry, On Sat, Mar 06, 2010 at 07:57:57AM -0600, Larry Finger wrote: On 03/06/2010 04:07 AM, Marc Haber wrote: On Fri, Mar 05, 2010 at 05:54:24PM +, Chris Vine wrote: You can get the Ideapad to work by forcing use of the PIO however. How exactly do I do this? I remember trying by adding some options to /etc/modprobe.d/b43, but the module didn't seem to understand this. I don't have the ideapad at hand at the moment, so I cannot look, but I can try tonight. Unless you are getting the DMA error, choosing PIO will not help. If you are getting that error, it will say so in the dmesg output. I have looked again, and the fatal DMA error is indeed there. It suggested setting CONFIG_B43_FORCE_PIO=y, which I did despite of the very clear warnings given in the make menuconfig help. However, the DMA error has vanished, but my B43 still says that the interface doesn't support scanning. That message sounds like you are using iwlist to scan - try iw instead. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things. Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
2010/3/8 Marc Haber mh+bcm43xx-d...@zugschlus.de: Hi, On Mon, Mar 08, 2010 at 12:54:44PM +0100, Gábor Stefanik wrote: That message sounds like you are using iwlist to scan - try iw instead. Yes, I am using iwlist. Has this changed? Have the tools like wicd and/or network-manager already adapted to use the new tools/API? AFAIK not, but iw gives more meaningful error messages in case of a failure. On the box that I am currently using (which has a ipw2200, oh wonderful old times), iw list returns nl80211 not found. Which option is my kernel missing? Probably nothing - rather, your libnl is too old (older than 1.0-pre8). However, you can't use iw with ipw2200 - it only supports drivers that use cfg80211. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things. Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). I have nearly finished the update on the code section of the specs page at http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the sections that read an address from the SPROM and perform operations on that address. I found that the chip common registers Do you mean the ChipCommon registers or the Backplane common registers? are mapped at 12K for newer cores on PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX. Larry -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On Thu, Mar 4, 2010 at 11:36 PM, Marc Haber mh+bcm43xx-...@zugschlus.de wrote: On Thu, Mar 04, 2010 at 01:49:14PM -0500, William Bourque wrote: Silly question, but did you try to up (ifconfig wlan0 up) the interface before scanning? I tried ip link set dev wlan0 up, which gave me a few more dmesg lines: b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy0: Loading firmware version 478.108 (2008-07-01 00.50:23) ADDRCONF(NETDEV_UP): wlan0: link is not ready iwlist scan wlan0 still says 'doesn't support scanning Is your kernel compiled with WEXT scanning support? AFAIK it is deprecated in 2.6.33 in favor of nl80211 (i.e. iw dev wlan0 scan), so it is not auto-selected. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things. Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Mailing list test, please ignore
Mailing list test, please ignore. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: On Sat, Feb 27, 2010 at 7:03 PM, Nathan Schulte rekl...@gmail.com wrote: 2010/2/27 Larry Finger larry.fin...@lwfinger.net: The printk's I sent yesterday can have timing info, but the timestamps would not be exactly coordinated - printk values seem to be generated when logged, not when requested. I modified mmiotrace to log via printk as well, which should give the desired results. I will post the same mmiotraces as requested before, once I complete them. http://vulcan.ist.unomaha.edu/~nmschulte/mmiotraces_syslog.tar.bz2 *_syslog contains mmiotrace and pci read/write synchronously merged via printk to syslog. The log messages were prefixed with ~~, and are in context with the rest of syslog. A simple awk should be able to remove the context, but there's not much of it (and what there is is relevant to the drivers in question), so I left it in. -Nate OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE, active. So, it is indeed probably the PCIE misc configuration routine. Why it's 0x280a is still a mystery to me, it should be 0x100a according to the specs. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque william.bour...@polymtl.ca wrote: Chris Vine wrote: This doesn't help on my netbook, I am afraid. I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... - William The documentation is available @ bcm-v4.sipsolutions.net - however, this doesn't yet contain the SSB specs. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque william.bour...@polymtl.ca wrote: I confirm, it still crashes on my notebook as well. However the new fallback to PIO behavior introduced earlier do a fine job getting it back on track. Btw, you are often refering to some documentation that document the register for this device, where could I find it? I probably won't be able to do much, but I'm curious to see... - William Thanks! New test patch attached. Please CC linux-wirel...@vger.kernel.org on further e-mails, bcm43xx-dev appears to be having problems. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) lpphy-test.patch Description: Binary data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/28 Gábor Stefanik netrolller...@gmail.com: OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE, active. So, it is indeed probably the PCIE misc configuration routine. Why it's 0x280a is still a mystery to me, it should be 0x100a according to the specs. Unless I'm reading the logs wrong, isn't wl setting bit 0x8000 when core 1 is mapped (0 indexed cores, 0x18001000 mapped to space 0)? And b43 appears to do it when core 0 is mapped (0x1800 mapped to space 0). b43 also reads from 0x100a after writing to 0x280a, and it reads as 0x8000 not set (while the 0x280a check show it is set). This is when comparing the wl_cold and b43_cold logs. -Nate The latest patch, which is a partial success according to some testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon). -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Sat, Feb 27, 2010 at 5:37 PM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/27/2010 10:08 AM, Michael Buesch wrote: On Saturday 27 February 2010 17:05:41 Larry Finger wrote: On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. *HINT HINT HINT* ;) Please make sure the PMU code really is correct. Where are the specs that were used to write the original code? I cannot find them in either the V3 or V4 pages. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev So, a quick status update, from what I've found yesterday: 1. We get the PMU setup wrong. Bit 0x200 is being set, despite the PMU being rev1. Also, PMU setup is done too early - at least wl reads the SPROM before setting up the PMU. A write of 0xcbb to offset 0x618 is also missing - I seem to remember that this change has been tried already, to no avail; but it may be a prerequisite of the real fix. 2. Just before the SPROM readout, we are missing a Set 0x8000 in MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and indeed, the value read out from 0x280a is identical to offset 0xa in my SPROM. So, the right thing to do here is probably Switch to the PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch back to ChipCommon. I don't know what core is active during this write, as mmiotrace doesn't catch pci_read/write_config_dword calls. Larry, do you know a way to monitor PCI config space access in a way that can be matched (e.g. using timestamps) to the MMIO trace? 3. Right after the SPROM is read, wl writes zeros to MMIO offsets 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid registers for ChipCommon and PCIE, but for 802.11, they fall directly into the DMA area! So, if these writes happened with the 802.11 core active, they are probably significant. I second Larry's question: where are the specs for the PMU init code? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/27 Nathan Schulte rekl...@gmail.com: I've been following along with the linux-wireless thread, and wanted to bring up a few points. 1) If the report in reference by Gábor: Well, we have a report from someone with an Intel T7250, ... is mine, note that my processor is actually a T5670 @ 1.8GHz, not a T7250 @ 2.0GHz. Just for the record. I was referring to Lucas, he has a T7250 AFAIK. 2) My BIOS setup has only one option related to the chip: WLAN control: enabled/disabled, which just enables or disables the card. That's basically RFKILL, were it misconfigured, you wouldn't even get to the point where a DMA error can occur. 2) In regard to Michael's statement about having someone with the hardware who can do some real debug work; I have the hardware, I like to think I've got a fairly good idea of what's going on (I'm able to follow along), I can read and understand the src (but as mentioned, there is a lot of indirection, I have little idea what is actually happening when). I'm more than willing to help, but learning the ssb and b43 drivers in and out is quite a large task. Just my thoughts, hope I'm not just getting in the way. -Nate Thanks - but currently I'm still trying to find out how you can trace PCI config space accesses (pci_config_read/write_(d)word - if you have an idea on this, please post it). However, I will probably have a few test patches for you soon. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/27 Gábor Stefanik netrolller...@gmail.com: OK, I whipped up a quick test patch with changes found so far implemented. Please test if this improves the situation. Where can I find this patch? -Nate Oops... yes, I forgot it. Here it is! -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) lpphy-test.patch Description: Binary data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/28 Nathan Schulte rekl...@gmail.com: 2010/2/27 Gábor Stefanik netrolller...@gmail.com: Oops... yes, I forgot it. Here it is! No luck from me either. And by the way, Lucas and I have the exact same hardware, so his is indeed a T5670 as well. -Nate Are you sure it is exactly the same? There are usually multiple configurations of the same laptop model available, e.g. I have an Acer 5720ZG with Pentium E2330, but it is also available with e.g. Pentium E2370. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, Feb 26, 2010 at 8:33 AM, Nathan Schulte rekl...@gmail.com wrote: 2010/1/25 Gábor Stefanik netrolller...@gmail.com A few things to check: -Is this on PhoenixBios? I have the same laptop as Lucas, a Dell Vostro 1510. As Lucas has mentioned, this is indeed a PhoenixBIOS -Does loading wl, doing a warm reboot and loading b43 make b43 work? I am running Debian Squeeze with the latest stock kernel (linux 2.6.32-5). I cold booted with b43 and ssb blacklisted, and loaded the wl module. I confirmed that it operated correctly, unloaded the wl module, and loaded b43 (and subsequently required modules). This did indeed make b43 work, contrary to Lucas's claim, at least for me. -Try updating the firmware to v478. (AFAIK there was someone on the list before with a DMA error on a non-ULV, and it was solved by updating the firmware. Broadcom's wl.ko uses a v5xx firmware for the record.) I am using the 4.178.10.4 driver as suggested on the linuxwireless page (http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2), which it claims is actually 4.174.64.19. My logs state -- Loading firmware version 478.104. The firmware version included in 4.174.64.19 is 478.104 (notice that is is not 4178.104, but 478.104 - the driver and firmware versions are not related!). snip And the Fatal DMA error: 0x400 repeats from there. -Nate Hi! Could you post an mmiotrace of the following? - ssb+b43 failing on cold boot - wl loaded on cold boot - wl loaded on warm boot (with wl having been loaded prior to reboot) - ssb+b43 working on warm boot (same as above) Thanks, Gábor -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, Feb 26, 2010 at 12:12 PM, rekl...@gmail.com wrote: On Feb 26, 2010 3:23am, Gábor Stefanik netrolller...@gmail.com wrote: The firmware version included in 4.174.64.19 is 478.104 (notice that is is not 4178.104, but 478.104 - the driver and firmware versions are not related!). Ah yes, sorry for my confusion. Hi! Hello there! Thanks for the speedy reply, hopefully I can help get to the bottom of this. Could you post an mmiotrace of the following? Certainly. As the stock Debian kernel doesn't appear to have the MMIO tracer enabled, these are from a fresh linux 2.6.33 mainline build (with CONFIG_B43_DEBUG=y and CONFIG_B43_FORCE_PIO=n) (some time passes) Err... I seem to be having issues getting the driver to fail as before. I have had the driver fail on a 2.6.33 build just hours ago, but with my new configuration, it is not. Make sure to actually cut power to the system discharge any stray voltages by pressing the Power On button with the powrer still cut before cold boot tests. The effect of wl seems to survive reboots. I will test using the stock kernel config with mmiotracer enabled. Thanks, Gábor -Nate -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/26 Nathan Schulte rekl...@gmail.com: I apologize for so many messages. I wanted to note that the reasoning for lsmod only showing the ntfs module, is due the fact that ntfs (and b43 and ssb) are the only drivers compiled as modules. When loading b43 without mmiotrace running, I receive a Fatal DMA error: 0x800 within a few seconds. I receive no other errors following, but I am unable to associate with an access point. If I then unload b43 and ssb, and reload it, I receive a Fatal DMA error: 0x400 (and can generate one for every ifconfig wlan0 down/up I perform). The archive http://vulcan.ist.unomaha.edu/~nmschulte/traces.tar.bz2 contains two traces. The first trace (one) is after a cold boot, loading b43, associating with an access point, issuing ifconfig wlan0 down, ifconfig wlan0 up, and then stopping the trace. Immediately after stopping the trace, I receive a 0x800 error in my logs. I then unloaded b43 and ssb, and started a new mmiotrace (two). I then loaded b43, issued ifconfig wlan0 down, ifconfig wlan0 up, and again issued ifconfig wlan0 down/up (preceeded by trace markers denoting such), and then stopped the trace. It is expected that you only get a single DMA error with 2.6.33, as the driver was modified in 2.6.33 to give up after a single failure. The controller restart mechanism has yet to show a successful error recovery for any card, OTOH the repeated retries had nasty side effects on some machines (including lockups and crashes), so the entire retry mechanism was removed. However, you did not do what I requested - before the 2nd mmiotrace, load and unload wl (the hybrid driver), not b43 - it is wl that appears to make the card work. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Re: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Fri, Feb 26, 2010 at 4:04 PM, rekl...@gmail.com wrote: On Feb 26, 2010 8:49am, Gábor Stefanik netrolller...@gmail.com wrote: However, you did not do what I requested - before the 2nd mmiotrace, load and unload wl (the hybrid driver), not b43 - it is wl that appears to make the card work. Correct, I did not do this. This is because (the current available version of) the hybrid driver does not build against 2.6.33. I need to build 2.6.32 vanilla, or the stock kernel. I will do that now. However, I thought it significant that using b43 from a cold boot works, so long as one is performing an mmiotrace. This is why I linked the tracers.tar.gz. That's odd... the error only occurs when you stop the mmiotrace?! BTW no need to load wl and b43 on the same kernel - the effect of loading wl survives a reboot or a kexec. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/26 Larry Finger larry.fin...@lwfinger.net: On 02/26/2010 09:27 AM, Gábor Stefanik wrote: On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote: On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote: That's odd... the error only occurs when you stop the mmiotrace?! Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if I load b43 outside of an mmiotrace. BTW no need to load wl and b43 on the same kernel - the effect of loading wl survives a reboot or a kexec. But then I cannot get you the mmiotrace as you requested. If all you're after is the mmiotrace of b43 from cold and b43 from warm with wl magic, I can do that now. I don't know how helpful this will be given that b43 appears to work so long as an mmiotrace is being performed. The differences will still be there in the dump, even if something related to mmiotrace seemingly works around the bug. However, the most helpful logs would be the ones produced by wl itself, on a cold boot. This thread is most interesting. Thanks for keeping it on the list, even though the OP doesn't seem to know about Reply All. The fact that the 4315 doesn't get the DMA errors until MMIO tracing is turned off suggests some kind of subtle timing difference. I'll look at the Broadcom code to see if there are some delay statements in the interrupt handling, or if their processing does things in a different order. Larry Note that enabling MMIO trace touches quite a few areas of the kernel rather hard - for example, it AFAIK disables SMP. I wonder if acpi=off or blacklisting processor would have an effect here... -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
2010/2/26 Chris Vine ch...@cvine.freeserve.co.uk: On Fri, 26 Feb 2010 18:22:26 +0100 Gábor Stefanik netrolller...@gmail.com wrote: Note that enabling MMIO trace touches quite a few areas of the kernel rather hard - for example, it AFAIK disables SMP. I wonder if acpi=off or blacklisting processor would have an effect here... I have reported previously (some months ago) that this delays the onset of DMA errors, but it just masks the problem. It has the same effect as the earlier pm_qos patch. The real issue appears to lie somewhere else: it is noise introduced by timing differences. Chris I suspect that timing is not the true reason for the problem, rather, there is a race condition between PhoenixBIOS and b43, for which wl probably uses a (firmware?) workaround. BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register. Larry, do you have any info on this? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct way to fix this, but should be enough for a test. The correct fix would be special-casing for both 4312 and 4325, at least according to the MMIO trace produced using wl. Or maybe the if-branch is the wrong-way around - only Larry can tell.) BTW does anyone know of a way to trace pci_read/write_config_dword calls? Mmiotrace doesn't capture these. 2010/2/26 Chris Vine ch...@cvine.freeserve.co.uk: On Fri, 26 Feb 2010 23:03:28 +0100 Gábor Stefanik netrolller...@gmail.com wrote: I suspect that timing is not the true reason for the problem, rather, there is a race condition between PhoenixBIOS and b43, for which wl probably uses a (firmware?) workaround. I meant that it is the reason for the masking of the DMA errors, rather than their cause. (That is not to say that your diagnosis of the problem may not be right.) Chris -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling
2010/2/21 Rafał Miłecki zaj...@gmail.com: 2010/2/20 Larry Finger larry.fin...@lwfinger.net: Some of the N PHYs need a revision in the handling of the PMU. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, This will be needed for some of the N PHY devices - 2.6.34 amterial. Larry --- V2 - Fix typo in subject line of commit message. amterial you say? ;) Taht's not prat of the cimmot megasse, it is olny a ntoe to Jhon. Deons't mtater eevn if it is cmolpelety jmulbed up. -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Add PCI ID 0x4322 to PHU handling
On Fri, Feb 19, 2010 at 7:02 PM, Larry Finger larry.fin...@lwfinger.net wrote:
Some of the N PHYs need a revision in the handling of the PMU.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
This will be needed for some of the N PHY devices - 2.6.34 amterial.
Larry
---
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -332,6 +332,12 @@ static void ssb_pmu_pll_init(struct ssb_
case 0x5354:
ssb_pmu0_pllinit_r0(cc, crystalfreq);
break;
+ case 0x4322:
+ if (cc-pmu.rev == 2) {
+ chipco_write32(cc, SSB_CHIPCO_PLLCTL_ADDR,
0x000A);
+ chipco_write32(cc, SSB_CHIPCO_PLLCTL_DATA,
0x380005C0);
+ }
+ break;
default:
ssb_printk(KERN_ERR PFX
ERROR: PLL init unknown for device %04X\n,
@@ -417,6 +423,7 @@ static void ssb_pmu_resources_init(struc
switch (bus-chip_id) {
case 0x4312:
+ case 0x4322:
/* We keep the default settings:
* min_msk = 0xCBB
* max_msk = 0x7
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Typo in title - PHU should be PMU.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On Sat, Feb 6, 2010 at 1:06 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/05/2010 10:27 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? The new routines are described in http://bcm-v4.sipsolutions.net/802.11/PHY/LP/TxFilterInit http://bcm-v4.sipsolutions.net/802.11/PHY/LP/TxDigFiltUcodeRev2 The revised routines are: http://bcm-v4.sipsolutions.net/802.11/PHY/LP/SetChanSpecLPPHY http://bcm-v4.sipsolutions.net/802.11/PHY/LP/PR41573 Larry Note to implementors: Chanspec is broadcrap, please do NOT use in b43. Use a struct if you need the extra parameters contained in chanspec. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: test
Why would it be misconfigured? On Sat, Feb 6, 2010 at 8:11 PM, strk s...@keybit.net wrote: Is it me or this list is misconfigured ? --srrk; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: N-PHY: handle allocation fail in samples generation
2010/2/4 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
b/drivers/net/wireless/b43/phy_n.c
index 074b34c..795bb1e 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -1069,6 +1069,10 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
}
samples = kzalloc(len * sizeof(struct b43_c32), GFP_KERNEL);
+ if (!samples) {
+ b43err(dev-wl, allocation for samples generation failed\n);
+ return 0;
return -ENOMEM;
+ }
rot = (((freq * 36) / bw) 16) / 100;
angle = 0;
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On Fri, Feb 5, 2010 at 7:09 PM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/05/2010 10:41 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? It was in the 4.174.64.19 driver that I RE'd when you wrote the LP PHY code. That as changed in 5.10.56.46, which I am now doing. It will take me a while to complete the new routine LP PHY TX Filter Init and a routine that it calls. Certainly, there is no hurry that these changes be made. Whenever you or Rafał have time. There is no guarantee that these changes will have any effect on the LP PHY operations. Hitting a moving target is not easy. Larry Just out of curiosity, is 5.10.56.46 available anywhere (for firmware reasons)? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: N-PHY: handle allocation fail in samples generation
2010/2/5 Rafał Miłecki zaj...@gmail.com:
W dniu 5 lutego 2010 18:34 użytkownik Gábor Stefanik
netrolller...@gmail.com napisał:
2010/2/4 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
b/drivers/net/wireless/b43/phy_n.c
index 074b34c..795bb1e 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -1069,6 +1069,10 @@ static u16 b43_nphy_gen_load_samples(struct
b43_wldev *dev, u32 freq, u16 max,
}
samples = kzalloc(len * sizeof(struct b43_c32), GFP_KERNEL);
+ if (!samples) {
+ b43err(dev-wl, allocation for samples generation
failed\n);
+ return 0;
return -ENOMEM;
Function was somehow designed to return unsigned only. Returning 0
means error (see place where we call b43_nphy_gen_load_samples, we
check result for 0 there.
Is that OK then?
In that case, OK - I thought this could be passed up to userspace handlers.
+ }
rot = (((freq * 36) / bw) 16) / 100;
angle = 0;
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--
Rafał
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On Mon, Jan 25, 2010 at 9:15 PM, Lucas Thode ljth...@gmail.com wrote: ---start dmesg snippet--- [17189.121003] b43-pci-bridge :06:00.0: PCI INT A disabled [17192.494272] cfg80211: Using static regulatory domain info [17192.494279] cfg80211: Regulatory domain: US [17192.494283] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp ) [17192.494292] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [17192.494299] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494306] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494314] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494321] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [17192.494328] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [17192.494418] cfg80211: Calling CRDA for country: US [17192.658174] b43-pci-bridge :06:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [17192.658206] b43-pci-bridge :06:00.0: setting latency timer to 64 [17192.724352] ssb: Sonics Silicon Backplane found on PCI device :06:00.0 [17192.769108] b43-phy0: Broadcom 4312 WLAN found (core revision 15) [17192.843094] phy0: Selected rate control algorithm 'minstrel' [17192.844206] Registered led device: b43-phy0::tx [17192.84] Registered led device: b43-phy0::rx [17192.844500] Registered led device: b43-phy0::radio [17192.844859] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ] [17196.776755] b43 ssb0:0: firmware: requesting b43/ucode15.fw [17196.780967] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw [17196.784551] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw [17196.921708] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [17202.497881] ADDRCONF(NETDEV_UP): wlan0: link is not ready [17202.934136] b43-phy0 ERROR: Fatal DMA error: 0x0800, 0x, 0x, 0x, 0x, 0x [17202.934153] b43-phy0: Controller RESET (DMA error) ... [17203.148369] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [17208.681254] b43-phy0: Controller restarted [17208.696481] b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x [17208.696490] b43-phy0: Controller RESET (DMA error) ... [17208.914882] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [17214.461361] b43-phy0: Controller restarted [17214.461610] b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x [17214.461626] b43-phy0: Controller RESET (DMA error) ... [17214.676285] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) ---end dmesg snippet---...and on and on the dma errors go. This occured about (sorry, not sure exactly, but I don't think it quite matters with this particular error) when I used iwlist scan to search for wireless networks after I used the b43-fwcutter from Debian testing to install the firmware and re-inserted the driver with 'modprobe -r b43; modprobe b43'. kb...@kb1rd-mobroost:~$ uname -a Linux kb1rd-mobroost 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64 GNU/Linux kb...@kb1rd-mobroost:~$ lspci -vvn | grep 43 -A7 06:00.0 0280: 14e4:4315 (rev 01) Subsystem: 1028:000b 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 f400 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: b43-pci-bridge extraneous output having to do with my Ethernet chip snipped kb...@kb1rd-mobroost:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz stepping : 13 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida bogomips : 3590.43 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: output for core 1 snipped As you can tell, this processor is neither an Atom nor a ULV Core 2 Duo. The WLAN card is the Dell Wireless 1395 that came with the laptop (a Vostro 1510). I can build a custom kernel based on the Debian kernel sources if need be; just tell me
Re: [PATCH 0/5] b43: more N-PHY stuff
2010/1/22 Rafał Miłecki zaj...@gmail.com: John, I hope to have patch submission fixed, please let me know if there is anything wrong still. Nope, it is still base64-encoded. I personally use Thunderbird 2 for patch submission (had weird problems with Thunderbird 3 beta - not sure about the final version). Rafał Miłecki (5): b43: check band width b43: N-PHY: implement overriding RF control b43: N-PHY: add running samples b43: N-PHY: add setting power amplifier filters b43: N-PHY: add TX tone drivers/net/wireless/b43/main.c | 6 + drivers/net/wireless/b43/phy_common.h | 3 + drivers/net/wireless/b43/phy_n.c | 253 ++-- drivers/net/wireless/b43/tables_nphy.c | 61 drivers/net/wireless/b43/tables_nphy.h | 22 +++ 5 files changed, 330 insertions(+), 15 deletions(-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/5 V2] b43: N-PHY: implement and add multi-dimensional table writing
You don't even need to mention it, as Git handles offset/fuzzy patches automatically. 2010/1/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 stycznia 2010 01:28 użytkownik Gábor Stefanik netrolller...@gmail.com napisał: 2010/1/18 Rafał Miłecki zaj...@gmail.com: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- V2: updated to apply without fuzz Actually, you do not need to do that - offset or fuzzy patches will still be applied cleanly AFAIK, without any intervention. (John, correct me if I'm wrong here...) That's right, it actually did. I just wanted to don't bother John with wondering if everything gone correctly. I guess I could just mention it instead of sending patch :) -- Rafał -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/7] b43: N-PHY: implement TX PHY cleanup and setup
2010/1/17 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 112
+-
1 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
b/drivers/net/wireless/b43/phy_n.c
index 4a1853b..34dd4a2 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -1505,6 +1505,114 @@ static struct nphy_txgains
b43_nphy_get_tx_gains(struct b43_wldev *dev)
return target;
}
+/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/TxCalPhyCleanup */
+static void b43_nphy_tx_cal_phy_cleanup(struct b43_wldev *dev)
+{
+ u16 *regs = dev-phy.n-tx_rx_cal_phy_saveregs;
+
+ if (dev-phy.rev = 3) {
+ b43_phy_write(dev, B43_NPHY_AFECTL_C1, regs[0]);
+ b43_phy_write(dev, B43_NPHY_AFECTL_C2, regs[1]);
+ b43_phy_write(dev, B43_NPHY_AFECTL_OVER1, regs[2]);
+ b43_phy_write(dev, B43_NPHY_AFECTL_OVER, regs[3]);
+ b43_phy_write(dev, B43_NPHY_BBCFG, regs[4]);
+ /* TODO: Write an N PHY Table with ID 8, length 1, offset 3,
+ width 16, and data from regs[5] */
+ /* TODO: Write an N PHY Table with ID 8, length 1, offset
19,
While you are at it, why aren't you programming these table writes?
The table handling functions are AFAIK already in place...
+ width 16, and data from regs[6] */
+ b43_phy_write(dev, B43_NPHY_RFCTL_INTC1, regs[7]);
+ b43_phy_write(dev, B43_NPHY_RFCTL_INTC2, regs[8]);
+ b43_phy_write(dev, B43_NPHY_PAPD_EN0, regs[9]);
+ b43_phy_write(dev, B43_NPHY_PAPD_EN1, regs[10]);
+ b43_nphy_reset_cca(dev);
+ } else {
+ b43_phy_maskset(dev, B43_NPHY_AFECTL_C1, 0x0FFF, regs[0]);
+ b43_phy_maskset(dev, B43_NPHY_AFECTL_C2, 0x0FFF, regs[1]);
+ b43_phy_write(dev, B43_NPHY_AFECTL_OVER, regs[2]);
+ /* TODO: Write an N PHY Table with ID 8, length 1, offset 2,
+ width 16, and data from regs[3] */
+ /* TODO: Write an N PHY Table with ID 8, length 1, offset
18,
+ width 16, and data from regs[4] */
+ b43_phy_write(dev, B43_NPHY_RFCTL_INTC1, regs[5]);
+ b43_phy_write(dev, B43_NPHY_RFCTL_INTC2, regs[6]);
+ }
+}
+
+/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/TxCalPhySetup */
+static void b43_nphy_tx_cal_phy_setup(struct b43_wldev *dev)
+{
+ u16 *regs = dev-phy.n-tx_rx_cal_phy_saveregs;
+ u16 tmp;
+
+ regs[0] = b43_phy_read(dev, B43_NPHY_AFECTL_C1);
+ regs[1] = b43_phy_read(dev, B43_NPHY_AFECTL_C2);
+ if (dev-phy.rev = 3) {
+ b43_phy_maskset(dev, B43_NPHY_AFECTL_C1, 0xF0FF, 0x0A00);
+ b43_phy_maskset(dev, B43_NPHY_AFECTL_C2, 0xF0FF, 0x0A00);
+
+ tmp = b43_phy_read(dev, B43_NPHY_AFECTL_OVER1);
+ regs[2] = tmp;
+ b43_phy_write(dev, B43_NPHY_AFECTL_OVER1, tmp | 0x0600);
+
+ tmp = b43_phy_read(dev, B43_NPHY_AFECTL_OVER);
+ regs[3] = tmp;
+ b43_phy_write(dev, B43_NPHY_AFECTL_OVER, tmp | 0x0600);
+
+ regs[4] = b43_phy_read(dev, B43_NPHY_BBCFG);
+ b43_phy_mask(dev, B43_NPHY_BBCFG, ~B43_NPHY_BBCFG_RSTRX);
+
+ /* TODO: Read an N PHY Table with ID 8, length 1, offset 3,
+ width 16, and data pointing to tmp */
+ regs[5] = tmp;
+
+ /* TODO: Write an N PHY Table with ID 8, length 1, offset 3,
+ width 16, and data 0 */
+ /* TODO: Read an N PHY Table with ID 8, length 1, offset 19,
+ width 16, and data pointing to tmp */
+ regs[6] = tmp;
+
+ /* TODO: Write an N PHY Table with ID 8, length 1, offset
19,
+ width 16, and data 0 */
+ regs[7] = b43_phy_read(dev, B43_NPHY_RFCTL_INTC1);
+ regs[8] = b43_phy_read(dev, B43_NPHY_RFCTL_INTC2);
+
+ /* TODO: Call N PHY RF Ctrl Intc Override with 2, 1, 3 */
+ /* TODO: Call N PHY RF Ctrl Intc Override with 1, 2, 1 */
+ /* TODO: Call N PHY RF Ctrl Intc Override with 1, 8, 2 */
+
+ regs[9] = b43_phy_read(dev, B43_NPHY_PAPD_EN0);
+ regs[10] = b43_phy_read(dev, B43_NPHY_PAPD_EN1);
+ b43_phy_mask(dev, B43_NPHY_PAPD_EN0, ~0x0001);
+ b43_phy_mask(dev, B43_NPHY_PAPD_EN1, ~0x0001);
+ } else {
+ b43_phy_maskset(dev, B43_NPHY_AFECTL_C1, 0x0FFF, 0xA000);
+ b43_phy_maskset(dev, B43_NPHY_AFECTL_C2, 0x0FFF, 0xA000);
+ tmp = b43_phy_read(dev, B43_NPHY_AFECTL_OVER);
+ regs[2] = tmp;
+
Re: [PATCH 2/5 V2] b43: N-PHY: implement and add multi-dimensional table writing
2010/1/18 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: updated to apply without fuzz
Actually, you do not need to do that - offset or fuzzy patches will
still be applied cleanly AFAIK, without any intervention.
(John, correct me if I'm wrong here...)
---
drivers/net/wireless/b43/phy_n.c | 58
++--
drivers/net/wireless/b43/tables_nphy.c | 40 ++
drivers/net/wireless/b43/tables_nphy.h | 2 +
3 files changed, 67 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
b/drivers/net/wireless/b43/phy_n.c
index 16f1f9b..6b200e5 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -1699,8 +1699,7 @@ static void b43_nphy_restore_cal(struct b43_wldev
*dev)
loft = nphy-cal_cache.txcal_coeffs_5G[5];
}
- /* TODO: Write an N PHY table with ID 15, length 4, offset 80,
- width 16, and data from table */
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 80), 4, table);
for (i = 0; i 4; i++) {
if (dev-phy.rev = 3)
@@ -1709,12 +1708,9 @@ static void b43_nphy_restore_cal(struct b43_wldev
*dev)
coef[i] = 0;
}
- /* TODO: Write an N PHY table with ID 15, length 4, offset 88,
- width 16, and data from coef */
- /* TODO: Write an N PHY table with ID 15, length 2, offset 85,
- width 16 and data from loft */
- /* TODO: Write an N PHY table with ID 15, length 2, offset 93,
- width 16 and data from loft */
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 88), 4, coef);
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 85), 2, loft);
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 93), 2, loft);
if (dev-phy.rev 2)
b43_nphy_tx_iq_workaround(dev);
@@ -1782,8 +1778,8 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev
*dev,
b43_nphy_iq_cal_gain_params(dev, i, target, params[i]);
gain[i] = params[i].cal_gain;
}
- /* TODO: Write an N PHY Table with ID 7, length 2, offset 0x110,
- width 16, and data pointer gain */
+
+ b43_ntab_write_bulk(dev, B43_NTAB16(7, 0x110), 2, gain);
b43_nphy_tx_cal_radio_setup(dev);
b43_nphy_tx_cal_phy_setup(dev);
@@ -1833,8 +1829,7 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev
*dev,
}
}
- /* TODO: Write an N PHY Table with ID 15, length from above,
- offset 64, width 16, and the data pointer from above
*/
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 64), length, table);
if (full) {
if (dev-phy.rev = 3)
@@ -1902,9 +1897,8 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev
*dev,
/* TODO: Read an N PHY Table with ID 15,
length table_length, offset 96, width 16,
and data pointer buffer */
- /* TODO: Write an N PHY Table with ID 15,
- length table_length, offset 64, width 16,
- and data pointer buffer */
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 64), length,
+ buffer);
if (type == 1 || type == 3 || type == 4)
buffer[0] = diq_start;
@@ -1916,8 +1910,7 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev
*dev,
last = (dev-phy.rev 3) ? 6 : 7;
if (!mphase || nphy-mphase_cal_phase_id == last) {
- /* TODO: Write an N PHY Table with ID 15, length 4,
- offset 96, width 16, and data pointer buffer
*/
+ b43_ntab_write_bulk(dev, B43_NTAB16(15, 96), 4,
buffer);
/* TODO: Read an N PHY Table with ID 15, length 4,
offset 80, width 16, and data pointer buffer
*/
if (dev-phy.rev 3) {
@@ -1926,14 +1919,14 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev
*dev,
buffer[2] = 0;
buffer[3] = 0;
}
- /* TODO: Write an N PHY Table with ID 15, length 4,
- offset 88, width 16, and data pointer buffer
*/
- /* TODO: Read an N PHY Table with ID 15, length 2,
- offset 101, width 16, and data pointer
buffer*/
- /* TODO: Write an N PHY Table with ID 15, length 2,
- offset 85, width 16, and data pointer buffer
*/
- /* TODO: Write an N PHY Table with ID 15, length 2,
-
Re: No probe response from AP address after 500ms, disconnecting.
On Fri, Jan 15, 2010 at 2:12 AM, Miklos Vajna vmik...@frugalware.org wrote: Hi, I tried asking on #bcm-users, then found the wiki where it's suggested to report to this list, so I'm doing so. Sorry for the noise on IRC. A description of the problem at hand: My card works fine when I use it with WPA, however when I try to use it without any encryption (actually the provider uses MAC-based filtering, but that's not important), then after the iwconfig eth0 essid essid, iwconfig shows the MAC of the AP, and after about 5 secs iwconfig says it's Not-Associated. If I run iwconfig eth0 essid again, then it's usable again for ~5 secs and so on. When the AP goes unassociated, I see this in dmesg: No probe response from AP 00:12:17:d3:87:f5 after 500ms, disconnecting. When it happens: It happens only in case not using encryption. An other laptop with ipw2200 driver works fine, so I guess this will be a b43 or firmware problem. The same card works under Windows XP as well, so I guess it's not a hardware problem. How to reproduce: Run iwconfig eth0 essid essid, wait ~5 secs and run iwconfig again. Result: it's unassociated. Expected: to show the MAC of the AP, etc. $ uname -a Linux s12 2.6.32-fw2 #1 SMP PREEMPT Sat Dec 19 13:56:14 CET 2009 x86_64 GNU/Linux $ sudo lspci -vvn|grep 43 -A7 00:00.4 0600: 1106:4353 Subsystem: 17aa:3889 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes 00:00.5 0800: 1106:5353 (prog-if 20 [IO(X)-APIC]) Subsystem: 17aa:388a -- 02:00.0 0280: 14e4:4315 (rev 01) Subsystem: 14e4:04b5 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: 32 bytes Interrupt: pin A routed to IRQ 28 Region 0: Memory at f520 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 -- Kernel driver in use: b43-pci-bridge Kernel modules: ssb dmesg: http://frugalware.org/~vmiklos/files/dmesg-s12 Wlan configuration, authentication/encryption type: b43 from vanilla kernel, no encryption. Firmware is installed as described at http://linuxwireless.org/en/users/Drivers/b43#fw-b43-lp kernel is a distro-packaged vanilla 2.6.32.1. Any ideas? Thanks! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev 14E4:4315 is an LP-PHY (specifically, for most people,, it is the LP-PHY), for which 2.6.32 contains no calibration support, so performance/range problems can be expected. 2.6.33 should have improvements (part of calibration done), and 2.6.34 will (if I have time to do it) have full calibration support. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_in_carrier_search and it's calls (V2)
2010/1/6 Gábor Stefanik netrolller...@gmail.com: 2010/1/6 Rafał Miłecki zaj...@gmail.com: V2: fix typo in deaf_count counting, improve b43_mac_[sr] calls, rename function. Thanks Michael! Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 58 ++ drivers/net/wireless/b43/phy_n.h | 3 ++ 2 files changed, 61 insertions(+), 0 deletions(-) snip Typo in title (it's vs. its) Note that you don't need to resubmit for this, I posted this so the committer (John AFAIK) will notice and fix it before committing. --Gábor -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_in_carrier_search and it's calls (V2)
2010/1/6 Rafał Miłecki zaj...@gmail.com: W dniu 6 stycznia 2010 23:35 użytkownik Gábor Stefanik netrolller...@gmail.com napisał: 2010/1/6 Rafał Miłecki zaj...@gmail.com: V2: fix typo in deaf_count counting, improve b43_mac_[sr] calls, rename function. Thanks Michael! Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 58 ++ drivers/net/wireless/b43/phy_n.h | 3 ++ 2 files changed, 61 insertions(+), 0 deletions(-) snip Typo in title (it's vs. its) My gramma is far from perfect, thanks. I've yet to see a perfect grandmother... :-) -- Rafał -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY: Some fixes, notices
On Wed, Jan 6, 2010 at 11:55 PM, Rafał Miłecki zaj...@gmail.com wrote: 2010/1/6 Rafał Miłecki zaj...@gmail.com: I've decided to made LP-PHY init code review for compatibility with specs and found some issues. We lack some code for higher PHY revisions (up from 2/3) and for some specific boards. Also I've found little mistake in specs which Larry just corrected. Gábor: could you care for this parts of LP-PHY code? So far I've only checked lpphy_read_band_sprom(dev); and lpphy_baseband_init(dev); I check for all conditions and operations (registers, masks, values). So far didn't notice anything more serious than what's exposed by patch, so good work Gábor :) There was actually one part I wasn't able to understand yesterday (it was late) and it still looks weird for me today... Could you verify my doubts, please? Specs: http://bcm-v4.sipsolutions.net/802.11/PHY/LP/ReadBandSrom Instead of tmp2 we use ofdmpo (that's totally fine). However we do following read: ofdmpo = bus-sprom.ofdm2gpo; before 2 - k condition visible in specs. So we use sprom.ofdm2gpo for both conditions and we do not care for opo. That is fine for rev. 8 as both: ofdm2gpo and opo are 0x142: http://bcm-v4.sipsolutions.net/SPROM However if we would meet LP-PHY on SSB with lower SPROM we wouldn't have ofdm2gpo and we should really use opo then. Am I right? Should we add opo reading for SPROM? Or maybe it's impossible to find LP-PHY on SSB with lower SPROM and we can keep using this work around? It has been determined that the presence of opo in the LP-PHY part of the code is Broadcrap resulting from the automated processes Broadcom uses for generating their driver. There is no LP-PHY with SPROM v8. -- Rafał -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_in_carrier_search and it's calls (V2)
On Thu, Jan 7, 2010 at 12:12 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 6 stycznia 2010 23:59 użytkownik Larry Finger larry.fin...@lwfinger.net napisał: On 01/06/2010 04:49 PM, Gábor Stefanik wrote: 2010/1/6 Rafał Miłecki zaj...@gmail.com: W dniu 6 stycznia 2010 23:35 użytkownik Gábor Stefanik netrolller...@gmail.com napisał: 2010/1/6 Rafał Miłecki zaj...@gmail.com: V2: fix typo in deaf_count counting, improve b43_mac_[sr] calls, rename function. Thanks Michael! Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 58 ++ drivers/net/wireless/b43/phy_n.h | 3 ++ 2 files changed, 61 insertions(+), 0 deletions(-) snip Typo in title (it's vs. its) My gramma is far from perfect, thanks. I've yet to see a perfect grandmother... :-) My wife thinks she is perfect! What a one latter can change ;) -- Rafał The the impotence of proofreading Has this ever happened to you? You work very very horde on a paper for English clash And you still get a very glow raid on it (like a D or even a D=) and all because you are the liverwurst spoiler in the whale wide word. Yes, proofreading your peppers is a matter of the the utmost impotence. Now, this is a problem that affects manly, manly students, all over the world. I myself was such a bed spiller once upon a term that my English torturer in my sophomoric year, Mrs. Myth, she said that I would never get into a good colleague. And that's all I wanted, that's all any kid wants at that age, just to get into a good colleague! And not just anal community colleague either, because I am not the kind of guy who would be happy at just anal community colleague. I need to be challenged. Challenged, menstrually. I needed a place that can offer me intellectual simulation. So I know this probably makes me sound like a stereo, but I really felt that I could get into an ivory legal colleague. So if I did not improvement then gone would be my dream of going to Harvard, Jail, or Prison (you know, in Prison, New Jersey). So I got myself a spell checker and figured I was on Sleazy Street. But there are several missed aches that a spell chukker can't can't catch catch. For instant, if you accidentally leave out word, your spell checker won't put it in you. And God for billing purposes only you should have serial problems with Tori Spelling your spell Chekhov might replace a word with one you had absolutely no detention of using. Because, I mean, what do you want it to douche? You know... No, it only does what you tell it to douche. You're the one who's sitting in front of the computer scream, with your hand on the mouth going clit, clit, clit. It just goes to show you how embargo one careless little clit of the mouth can be. Which reminds me of this one time during my Junior Mint. The teacher took the paper that I have written on A Sale of Two Titties. No, I'm cereal, I'm cereal. She read it out loud in front of all of my assmates. It was quite possibly one of the most humidifying experiences I've ever had, being laughed at, like that, pubicly. So do yourself a flavor and follow these two Pisces of advice: One: There is no prostitute for careful editing of your own work. No prostitute, whatsoever. And three: When it comes to proofreading, the red penis your friend. Spank you! (Credits go to Taylor Mali for this one.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: must set qos=0 on to connect
On Wed, Jan 6, 2010 at 12:00 AM, John Daiker daikerj...@gmail.com wrote: I have a BCM4312 rev 01 (14e4:4315) card in my HP Mini netbook. I am having troubles connecting to any WEP secured AP. I know the trick about having to load with pio=1 for the device to stay happy (and forget about using DMA), so no issues there, I hope. With qos=1 (by default, IIRC), I am unable to establish a connection with said WEP connection, and notice many 'PHY transmission error' messages in my dmesg output. With qos=1, I can successfully connect to my WEP connection without issue, and without any error messages or warnings. I have a BCM4318 rev 02 (14e4:4318) in a desktop that works with enabled/disabled qos not matter what. Also, a RT2500-based card works fine on the connection as well. Both card are using the 478.104 firmware. Please advise what steps I should take to further debug this issue. Thanks, John Daiker -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi! Is this the new 4312 (BCM94312HMGB AKA 575920-001), with integrated Bluetooth? I haven't seen this issue on my machines with a regular 4312, so it is probably related to the DMA error, or maybe it is specific to the new 4312. If you can, please check whether the actual model number printed on the card is the new one. Thanks, Gábor -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: must set qos=0 on to connect
2010/1/6 John Daiker daikerj...@gmail.com: On 01/05/2010 03:48 PM, Gábor Stefanik wrote: On Wed, Jan 6, 2010 at 12:00 AM, John Daikerdaikerj...@gmail.com wrote: I have a BCM4312 rev 01 (14e4:4315) card in my HP Mini netbook. I am having troubles connecting to any WEP secured AP. I know the trick about having to load with pio=1 for the device to stay happy (and forget about using DMA), so no issues there, I hope. With qos=1 (by default, IIRC), I am unable to establish a connection with said WEP connection, and notice many 'PHY transmission error' messages in my dmesg output. With qos=1, I can successfully connect to my WEP connection without issue, and without any error messages or warnings. I have a BCM4318 rev 02 (14e4:4318) in a desktop that works with enabled/disabled qos not matter what. Also, a RT2500-based card works fine on the connection as well. Both card are using the 478.104 firmware. Please advise what steps I should take to further debug this issue. Thanks, John Daiker -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi! Is this the new 4312 (BCM94312HMGB AKA 575920-001), with integrated Bluetooth? I haven't seen this issue on my machines with a regular 4312, so it is probably related to the DMA error, or maybe it is specific to the new 4312. If you can, please check whether the actual model number printed on the card is the new one. Thanks, Gábor Gábor, I just pulled the card, and it's not the chip you mention. It's a BCM94312HMG (Notice that it doesn't have the B at the end. I would assume that indicates the Bluetooth integration.) I've taken few photos of the front and back of the card. Let me know if you want to see them... I can post 'em on my website or flickr for your viewing pleasure. Thanks, John Daiker Weird... I also have a 94312HMG, and it doesn't show this error (at least not in DMA mode). Maybe this is a PIO-specific issue... I'll try to test that. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: The newest Macbook 13.3 wireless
2010/1/4 Rafał Miłecki zaj...@gmail.com: 2010/1/3 Daniel Kuehn enha...@gmail.com: I am the (un)lucky owner of a Macbook of late 2009 model, which has a Broadcom combo card (BT + WLAN sharing 3 antennas) but neither the b43 or broadcom-sta support it, I just get invalid parameters or the interface disappears. Is there anyway I could help you guys with getting this wlan card to work? I could test experimental drivers or try to bash it to work or such, it would just be awesome if I could get it to work. The chip PCI ID is 14e4:4353 if that helps you any, its a wireless N card as I have understod it, but there exist no info that either confirm or discard the PCI ID as a WLAN card. I havent been able to get any info of which card this is supposed to be from broadcoms sortiment, I cannot find any of the cards listen on broadcoms homepage to match with this card. Could you check what chipset is it? I think you should see something like: b43-phy0: Broadcom 43** WLAN found where 43** is number I ask for. Gábor: do you have still access to this 14e4:4353 device? If Daniel won't able to check chipset, could you do this? I don't think that BCM43224 you noted is correct. Could you double check that? I just would like to fill table on http://wireless.kernel.org/en/users/Drivers/b43 with this device. The wireless card in the late-2009 MacBook is a BCM943224PCIEBT (as stated on the exterior shell of the actual MacBook), which is a custom (but Broadcom-made) BCM43224 (basically a dual-band BCM4322 plus a BCM2070 for Bluetooth). A picture of the card can be seen at http://images.weiphone.com/attachments/Day_091021/68_294416_286a2478633560a.jpg - note that this is an official Apple replacement part, and may look slightly different from a generic Broadcom version. Pictures of the Broadcom reference version will be available on FCC's site after February 20, when the temporary confidentality grant expires. The description for BCM943224HMB (the same card in a different form factor) can be viewed at http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM943224HMB (note Broadcom's odd usage of the word SoC, which is used in the sense single-chip transceiver - the 43224 is not a SOC in the true sense of the word). I do not currently have either type of BCM43224 at hand, but the information found on the web looks convincing. -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: The newest Macbook 13.3 wireless
On Sun, Jan 3, 2010 at 3:41 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 01/02/2010 08:11 PM, Daniel Kuehn wrote: Hi, I am the (un)lucky owner of a Macbook of late 2009 model, which has a Broadcom combo card (BT + WLAN sharing 3 antennas) but neither the b43 or broadcom-sta support it, I just get invalid parameters or the interface disappears. Is there anyway I could help you guys with getting this wlan card to work? I could test experimental drivers or try to bash it to work or such, it would just be awesome if I could get it to work. The chip PCI ID is 14e4:4353 if that helps you any, its a wireless N card as I have understod it, but there exist no info that either confirm or discard the PCI ID as a WLAN card. I havent been able to get any info of which card this is supposed to be from broadcoms sortiment, I cannot find any of the cards listen on broadcoms homepage to match with this card. The Broadcom 5.10.56.46 that is the basis for my current reverse engineering effort supports that card. To the best of my knowledge, it is an 802.11n dual-band card. The coding effort to support N PHYs has just started. Of course, it could be an SSLPN PHY and the RE for them is not yet started. In any case, who knows when any code will be ready. Watch this mailing list for patches. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev It is a BCM43224, N-PHY+Bluetooth. It is not an SSLPN- or QN-PHY. (BTW, these PHY names are somehow just keep getting longer and longer... I believe in 2020, we will see the first ALLURBASERBELONG2US-PHY... though maybe PSEUDOPNEUMONOULTRAMICROSCOPICSILICOVOLCANOCONIOSIS-PHY is a better guess.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 disconnects on 2.6.32
Update your pci.ids file - what you have is a BCM4311/02 ABG. Also, could you check a few more kernels in-between .29 and .32? On Sat, Dec 26, 2009 at 8:01 PM, yha...@yhager.com wrote: Hi, First, some adminstrativa.. $ uname -srvmip Linux 2.6.29 #4 Fri Aug 28 13:17:05 IDT 2009 i686 VIA C7-M Processor 1600MHz CentaurHauls $ lspci -vnn |grep 14e4 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11a/b/g [14e4:4312] (rev 02) 07:03.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet [14e4:169c] (rev 03) $ dmesg|grep b43-phy | head -1 [ 7.461364] b43-phy0: Broadcom 4311 WLAN found This same machine works fine when I use the 2.6.29 kernel, but when I use 2.6.32, I get Carrier lost disconnection after a couple of minutes (exact times vary between 30 seconds to about 2-3 minutes). Before filling everyone's inbox with large kernel logs, here's a snippet from dmesg: # dmesg | egrep b43|wlan|AP [ 0.00] ACPI: APIC 6feb0390 00060 (v02 HP APIC2203 20080820 MSFT 0097) [ 0.00] #5 [008000 - 00f000] BOOTMAP == [008000 - 00f000] [ 0.121705] ACPI: Power Resource [APMF] (off) [ 4.608781] b43-pci-bridge :02:00.0: PCI INT A - Link[LNKH] - GSI 10 (level, low) - IRQ 10 [ 4.608809] b43-pci-bridge :02:00.0: setting latency timer to 64 [ 4.807626] b43-phy0: Broadcom 4311 WLAN found (core revision 13) [ 4.900090] b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 9 [ 4.900120] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 [ 4.960151] b43-phy0 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config [ 4.966071] Registered led device: b43-phy0::tx [ 4.966125] Registered led device: b43-phy0::rx [ 4.966179] Registered led device: b43-phy0::radio [ 5.048461] fuse init (API version 7.13) [ 34.990139] b43 ssb0:0: firmware: requesting b43/ucode13.fw [ 35.080855] b43 ssb0:0: firmware: requesting b43/b0g0initvals13.fw [ 35.250092] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) [ 35.360376] b43-phy0 debug: Chip initialized [ 35.360441] b43-pci-bridge :02:00.0: PCI: Disallowing DAC for device [ 35.360452] b43-phy0: DMA mask fallback from 64-bit to 32-bit [ 35.360809] b43-phy0 debug: 64-bit DMA initialized [ 35.360893] b43-phy0 debug: QoS enabled [ 35.400721] b43-phy0 debug: Wireless interface started [ 35.400741] b43-phy0 debug: Adding Interface type 2 [ 45.267169] b43-phy0 debug: Removing Interface type 2 [ 45.267283] b43-phy0 debug: Wireless interface stopped [ 45.267295] b43-phy0 debug: DMA-64 rx_ring: Used slots 1/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 45.267421] b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 45.280097] b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 45.300151] b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 45.320064] b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 2/256, Failed frames 0/22 = 0.0%, Average tries 1.00 [ 45.340060] b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 45.620280] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) [ 45.730312] b43-phy0 debug: Chip initialized [ 45.730374] b43-pci-bridge :02:00.0: PCI: Disallowing DAC for device [ 45.730383] b43-phy0: DMA mask fallback from 64-bit to 32-bit [ 45.730623] b43-phy0 debug: 64-bit DMA initialized [ 45.730703] b43-phy0 debug: QoS enabled [ 45.770718] b43-phy0 debug: Wireless interface started [ 45.770732] b43-phy0 debug: Adding Interface type 2 [ 45.858474] wlan0: direct probe to AP 00:22:3f:18:89:5e (try 1) [ 45.860542] wlan0: direct probe responded [ 45.860551] wlan0: authenticate with AP 00:22:3f:18:89:5e (try 1) [ 45.862212] wlan0: authenticated [ 45.862250] wlan0: associate with AP 00:22:3f:18:89:5e (try 1) [ 45.864940] wlan0: RX AssocResp from 00:22:3f:18:89:5e (capab=0x401 status=0 aid=2) [ 45.864948] wlan0: associated [ 45.88] wlan0: deauthenticating from 00:22:3f:18:89:5e by local choice (reason=3) [ 45.866797] wlan0: direct probe to AP 00:22:3f:18:89:5e (try 1) [ 45.869397] wlan0: direct probe responded [ 45.869406] wlan0: authenticate with AP 00:22:3f:18:89:5e (try 1) [ 45.871106] wlan0: authenticated [ 45.871141] wlan0: associate with AP 00:22:3f:18:89:5e (try 1) [ 45.873524] wlan0: RX ReassocResp from 00:22:3f:18:89:5e (capab=0x401 status=0 aid=2) [ 45.873532] wlan0: associated [ 45.874266] wlan0: deauthenticating from 00:22:3f:18:89:5e by local choice (reason=3) [ 45.874364] wlan0: direct probe to AP 00:22:3f:18:89:5e (try 1) [ 45.876965] wlan0: direct probe responded [ 45.876975] wlan0:
Re: ssb: ERROR: PLL init unknown for device 4322
On Fri, Dec 18, 2009 at 11:53 AM, Erik esi...@gmail.com wrote: I just bought a new laptop and installed Gentoo on it: # dmesg|grep -i error [ 4.113200] ssb: ERROR: PLL init unknown for device 4322 [ 4.113201] ssb: ERROR: PMU resource config unknown for device 4322 [ 4.702250] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 8, Type 4, Revision 4) [ 4.702308] b43: probe of ssb0:0 failed with error -95 # lspci|grep 43 0e:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01) Is there anything that I can try or any information that I can provide to make it work? BCM4322 is an N-PHY device, which is not yet supported; it will probably be the next thing I will implement, once Larry completes the reverse engineering for this PHY. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Notebooks compatibility with Broadcom cards
On Tue, Dec 1, 2009 at 8:11 PM, Peter Stuge pe...@stuge.se wrote: Rafał Miłecki wrote: I know there were some series of notebooks accepting only one kind of wireless cards. Not sure what vendor was that... Dell or HP maybe? HP and IBM/Lenovo both have BIOS checks for particular PCI IDs and only allow cards with certain IDs to be plugged in. Do you have any idea if I should be somehow careful when changing wireless card in my Acer? Sorry, no idea. Not sure about the 5024, but the 5720G has freely-interchangeable wireless cards. (However, it also comes with 2 full miniPCIE slots, something not many Acers have.) Also is this possible my notebook is just too old to handle new wireless 802.11n card? Maybe too old mini pcie, or something like that? Check that the expansion socket is compatible. The 4318 is probably a mini-PCI card and .11n cards are usually mini-PCIe which is very different and not at all compatible. The card you buy must fit your socket. I've bought an Atheros miniPCI .11n card off eBay for my X40: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=400078624952 But I haven't received it yet so I can't review. It's supposed to be supported by ath9k. I expect that I have to fiddle with the EEPROM on this card to get my ThinkPad to boot with it. Also check the antenna situation. .11n often uses MIMO so it might need an extra antenna to be installed in your laptop. Note how the above card has three connectors, and comes shipped with one antenna. Also note the MIMO arrangement so that it fits your needs. (In simplified terms it can be optimized for receive or transmit.) //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I need to see some wl output
On Sun, Nov 29, 2009 at 9:44 PM, Andrew Benton b3n...@gmail.com wrote:
On 29/11/09 18:41, Larry Finger wrote:
It seems that none of the special things that the wl driver does on my
system has any affect on the DMA errors. I would appreciate if one of
you would do the following:
1. Set CONFIG_MMIOTRACE=y in .config.
I can't find that option. I have
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
That's the only instance of MMIO in my .config
How do I set CONFIG_MMIOTRACE=y?
Do not edit your config directly, use {menu|x|g}config. You need to
enable the tracing framework to see mmiotrace.
Andy
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: III. Does this help b43 DMA errors?
??? This only adds a printk...
On Sun, Nov 29, 2009 at 12:43 AM, Larry Finger
larry.fin...@lwfinger.net wrote:
Sorry about the problem with the previous try. This one does write the
PCI configuration the same as wl does.
Please see if this one helps.
Larry
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -567,6 +567,8 @@ static int sprom_extract(struct ssb_bus
const u16 *in, u16 size)
{
pci_write_config_dword(bus-host_pci, 0x40, 0x6030001);
+ printk(KERN_DEBUG ssb: Set PCI Configuration word 0x40 to
+ 0x6030001\n);
memset(out, 0, sizeof(*out));
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Wed, Nov 18, 2009 at 6:15 PM, Larry Finger larry.fin...@lwfinger.net wrote:
On 11/18/2009 08:34 AM, Oncaphillis wrote:
The first ioread16 actually succeeds, only the second one fails.
My lspci -vnn tells me that the memory is:
Memory at 5710 (64-bit, non-prefetchable) [size=16K]
Could it be that one has to make a ioread32 here since the
memory is 64-bit ? I remember very very remotely that
in older days it was impossible or even forbidden to read
data from addresses which are not a multiple of 2/4/8 what
so ever. But that was pre-PCI.
As long as a 16-bit read is aligned on an even address, it should be OK;
however, to check completely, please try this patch:
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -251,10 +251,16 @@ static int sprom_check_crc(const u16 *sp
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
{
int i;
+ u32 buf;
- for (i = 0; i bus-sprom_size; i++)
- sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
-
+ printk(KERN_INFO ssb: Entering %s\n, __func__);
+ for (i = 0; i bus-sprom_size; i = i + 2) {
I know this is just a debugging patch, but we use i+=2 or i += 2
in such cases.
+ buf = ioread32(bus-mmio + SSB_SPROM_BASE + (i * 2));
+ printk(KERN_INFO ssb: Read 0x%.8X from SPROM\n, buf);
+ sprom[i] = buf 0x;
+ sprom[i+1] = (buf 16) 0x;
+ }
+ printk(KERN_INFO ssb: Leaving %s\n, __func__);
return 0;
}
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Thu, Nov 19, 2009 at 12:39 AM, Michael Buesch m...@bu3sch.de wrote: Please keep it on-list. This is really important to get this debugged properly. On Thursday 19 November 2009 00:23:18 Oncaphillis wrote: On 11/18/2009 11:59 PM, Michael Buesch wrote: What kind of device is that? Some laptop? I only knew about embedded devices using these wireless cards without sprom. Is the card connected via (mini)pci? Or is it on-board? What we need is a way to identify the card so we avoid accessing the dangling bus to the sprom. I'd like to avoid the read-the-first-word- and-check-if-its-all-ones approach, because accesses a dangling bus. That's obviously no good and can hang the CPU due to missing bus acks. What's the lspci -vvnn output for the card? Note that the chipcommon revision on the card is 0x16. That's a pretty high number. I wonder if they changed something and there actually _is_ an sprom on the card, but there's just a new way to access it (or the shadow area has to be mapped through chipcommon first or something like that)... It's an acer aspire one d250 netbook Nice. Is it possible to open the device and take a picture of the card? It's trivial to find out this way whether it has a SPROM or not, because it's a separate chip. Hmm... this kinda reminds me of when the SPROM died on my Asus 4318, causing it to display as a 14e4:0008, and freeze immediately upon any SPROM read/write attempt. Quite possibly we have something similar here (there is an SPROM, but it's broken - without an SPROM, the card AFAIK can't even produce a valid PCI ID). Is it this device? http://hax0rpedia.com/index.php/Disassembeling_the_AAO_D250 Can you open the lower-right cover shown here: http://hax0rpedia.com/index.php/File:Aao_d250_step2.jpg and take a closeup picture of the wireless card? Also probably a picture of the backside of the card. That'd require removing the card, though. We really need to find out somehow if there is a SPROM chip on the device and if that's the case how to access it. You may have a look at the full lspci -vvnn output at: Nice, thanks. I did a read the first word. Surprisingly it succeeds the first time. After that I may still read 32bit words. When the module tries to read the sprom the second time looking for a larger sprom the first read16 fails. Well, my guess is that _any_ subsequent 16bit read would fail from then on, because it was still waiting for the bus-ack of the first one. If the bus really is dangling, we must avoid to access it in the first place. Should I try to dump out the full 16k area reported for the device ? I don't think that would be useful. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43-phy0 ERROR: Fatal DMA error: 0x00000400
On Fri, Nov 13, 2009 at 5:05 PM, Larry Finger larry.fin...@lwfinger.net wrote: On 11/13/2009 05:16 AM, Michael Buesch wrote: Ok, so my guess is that the DMA allocator simply returned high memory that was unusable to the device. My new code explicitly checks for that (and a few other things) and retries with GFP_DMA in case the address has illegal bits set. That's the same thing we do for the frame buffers, so I don't see anything wrong with it. Yeah, the new code is big and scary, but I think it makes a whole lot more sense than what we have now. Especially if I add some comments and do more cleanups. I agree that the new code makes a lot of sense. I'm also beginning to believe that the problem lies outside b43, and that it is merely triggered by some interaction with ACPI and/or the BIOS. From what I found in looking back through the DMA error reports, most (if not all) people with the problem have netbook computers with Intel ATOM processors. I am considering posting on LKML and the ACPI mailing lists to see if we can get any ideas from those experts. Please comment on the draft text below: A number of users are experiencing DMA descriptor or data errors using 64-bit DMA with the Broadcom BCM4312 wireless device. After careful review and a rewrite of the DMA code in the driver, we have not been able to fix the problem, but we have determined the following: (1) The problem is much more likely to occur on netbook systems. Several of the developers have this card in regular notebook systems. None of us have the problem, thus it may occur only on netbooks, but several brand/model combinations are affected including Dell Inspiron 910 and Acer Aspire One A150. Linus has also reported this issue on a Core 2 ULV. I suspect that the key part is deep-sleep support in the CPU. Also, PhoenixBIOS seems to play part in the problem. (2) If CONFIG_ACPI_PROCESSOR is not set on affected systems, the error rate is much lower. (3) When a DMA descriptor error occurs, a dump of the descriptors does not reveal any obvious problems. I do not know enough about either the ACPI or DMA code to begin debugging in either of those regions. Any suggestions on debugging strategies, or links to similar problems would be appreciated. Larry -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
2009/10/28 Linus Torvalds torva...@linux-foundation.org: On Sun, 25 Oct 2009, Gábor Stefanik wrote: Also, is there any reference to a failed channel switch in the log? I've been debugging this some more, and it looks like there are more issues at play than just the DMA problem. With the b43 driver enabled, I seem to be unable to reliably suspend and resume. Sometimes the machine just locks up hard, but sometimes I get something like this on the resume path: b43-phy0 debug: Resuming... b43-phy0 debug: Device resumed. ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5 b43-phy0 debug: Chip initialized b43-phy0 debug: PIO initialized b43-phy0 debug: QoS disabled b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 and when that happens, it appears that then the _next_ suspend/resume cycle will fail with a hard lockup. And sometimes the hard lockup happens on the very first resume. But maybe that Failed to switch to channel 7 error is entirely unrelated to the Locks up hard on resume problem. But the lock-up seems to be tied to the b43 driver too - the machine seems stable if I don't load that module at all. What seems a bit odd is how the b43_lpphy_op_init() seems to try to switch to channel 7 _twice_. It does: ... lpphy_radio_init(dev); lpphy_calibrate_rc(dev); err = b43_lpphy_op_switch_channel(dev, 7); ... and that lpphy_calibrate_rc() call will already have done the channel switch for the lpphy_rev0_1_rc_calib() case. Maybe it should just switch to channel 7 unconditionally before doing the lpphy_calibrate_rc()? What we do is exactly what the spec calls for - specifically, rev.2+ cards don't switch to channel 7 during RC calibration, while rev.0/1 SoCs can have an NVRAM variable specifying a predetermined RC-Cap value, in which case the actual RC calibration doesn't even run (though the latter is not yet implemented). However, just switching to channel 7 at the beginning looks saner - Larry, what do you think about it? I dunno. I don't know the code, I don't know the hardware, the above is just a random musing based on looking at the code around that warning case. Linus -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: LP-PHY: Begin implementing calibration software RFKILL support
This implements the following calibration functions:
-Set TX IQCC
-Set TX Power by Index
-PR41573 workaround (incomplete, needs PHY reset)
-Calc RX IQ Comp
-PHY Cordic
-Run Samples
-Start/Stop TX Tone
-part of PAPD Cal TX Power
-RX I/Q Calibration
-The basic structure of the periodic calibration wrapper
Software RFKILL (required by calibration) is also implemented in
this round.
Signed-off-by: Gábor Stefanik netrolller...@gmail.com
---
Michael, could you please do the PHY reset part? I can't seem to
understand its relationship to wireless_core_reset... also, it's
heavily ssb-speak, which I am not good at.
drivers/net/wireless/b43/phy_lp.c | 783 ++---
drivers/net/wireless/b43/phy_lp.h | 11 +-
2 files changed, 658 insertions(+), 136 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 07d9d03..9dcb39c 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -67,6 +67,7 @@ static void b43_lpphy_op_prepare_structs(struct b43_wldev
*dev)
struct b43_phy_lp *lpphy = phy-lp;
memset(lpphy, 0, sizeof(*lpphy));
+ lpphy-antenna = B43_ANTENNA_DEFAULT;
//TODO
}
@@ -379,8 +380,6 @@ static void lpphy_save_dig_flt_state(struct b43_wldev *dev)
}
}
-/* lpphy_restore_dig_flt_state is unused but kept as a reference */
-#if 0
static void lpphy_restore_dig_flt_state(struct b43_wldev *dev)
{
static const u16 addr[] = {
@@ -401,7 +400,6 @@ static void lpphy_restore_dig_flt_state(struct b43_wldev
*dev)
for (i = 0; i ARRAY_SIZE(addr); i++)
b43_phy_write(dev, addr[i], lpphy-dig_flt_state[i]);
}
-#endif
static void lpphy_baseband_rev2plus_init(struct b43_wldev *dev)
{
@@ -754,11 +752,17 @@ static void lpphy_clear_deaf(struct b43_wldev *dev, bool
user)
}
}
+static void lpphy_set_trsw_over(struct b43_wldev *dev, bool tx, bool rx)
+{
+ u16 trsw = (tx 1) | rx;
+ b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, trsw);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+}
+
static void lpphy_disable_crs(struct b43_wldev *dev, bool user)
{
lpphy_set_deaf(dev, user);
- b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, 0x1);
- b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+ lpphy_set_trsw_over(dev, false, true);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFB);
b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x4);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFF7);
@@ -793,6 +797,60 @@ static void lpphy_restore_crs(struct b43_wldev *dev, bool
user)
struct lpphy_tx_gains { u16 gm, pga, pad, dac; };
+static void lpphy_disable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFFE);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFEF);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFBF);
+ if (dev-phy.rev = 2) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFBFF);
+ b43_phy_mask(dev, B43_PHY_OFDM(0xE5), 0xFFF7);
+ }
+ } else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFDFF);
+ }
+}
+
+static void lpphy_enable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x1);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x10);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x40);
+ if (dev-phy.rev = 2) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x400);
+ b43_phy_set(dev, B43_PHY_OFDM(0xE5), 0x8);
+ }
+ } else {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x200);
+ }
+}
+
+static void lpphy_disable_tx_gain_override(struct b43_wldev *dev)
+{
+ if (dev-phy.rev 2)
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFF7F);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xBFFF);
+ }
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFBF);
+}
+
+static void lpphy_enable_tx_gain_override(struct b43_wldev *dev)
+{
+ if (dev-phy.rev 2)
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
+ else {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x80);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x4000);
+ }
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x40);
+}
+
static struct lpphy_tx_gains lpphy_get_tx_gains(struct b43_wldev *dev)
{
struct lpphy_tx_gains gains;
@@ -822,6 +880,17 @@ static void
[PATCH] b43: LP-PHY: Begin implementing calibration software RFKILL support
This implements the following calibration functions:
-Set TX IQCC
-Set TX Power by Index
-PR41573 workaround (incomplete, needs PHY reset)
-Calc RX IQ Comp
-PHY Cordic
-Run Samples
-Start/Stop TX Tone
-part of PAPD Cal TX Power
-RX I/Q Calibration
-The basic structure of the periodic calibration wrapper
Software RFKILL (required by calibration) is also implemented in
this round.
Signed-off-by: Gábor Stefanik netrolller...@gmail.com
---
(Mail re-sent as my mailer seems to have dropped it; apologies if
you receive it twice.)
Michael, could you please do the PHY reset part? I can't seem to
understand its relationship to wireless_core_reset... also, it's
heavily ssb-speak, which I am not good at.
drivers/net/wireless/b43/phy_lp.c | 783 ++---
drivers/net/wireless/b43/phy_lp.h | 11 +-
2 files changed, 658 insertions(+), 136 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 07d9d03..9dcb39c 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -67,6 +67,7 @@ static void b43_lpphy_op_prepare_structs(struct b43_wldev
*dev)
struct b43_phy_lp *lpphy = phy-lp;
memset(lpphy, 0, sizeof(*lpphy));
+ lpphy-antenna = B43_ANTENNA_DEFAULT;
//TODO
}
@@ -379,8 +380,6 @@ static void lpphy_save_dig_flt_state(struct b43_wldev *dev)
}
}
-/* lpphy_restore_dig_flt_state is unused but kept as a reference */
-#if 0
static void lpphy_restore_dig_flt_state(struct b43_wldev *dev)
{
static const u16 addr[] = {
@@ -401,7 +400,6 @@ static void lpphy_restore_dig_flt_state(struct b43_wldev
*dev)
for (i = 0; i ARRAY_SIZE(addr); i++)
b43_phy_write(dev, addr[i], lpphy-dig_flt_state[i]);
}
-#endif
static void lpphy_baseband_rev2plus_init(struct b43_wldev *dev)
{
@@ -754,11 +752,17 @@ static void lpphy_clear_deaf(struct b43_wldev *dev, bool
user)
}
}
+static void lpphy_set_trsw_over(struct b43_wldev *dev, bool tx, bool rx)
+{
+ u16 trsw = (tx 1) | rx;
+ b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, trsw);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+}
+
static void lpphy_disable_crs(struct b43_wldev *dev, bool user)
{
lpphy_set_deaf(dev, user);
- b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, 0x1);
- b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+ lpphy_set_trsw_over(dev, false, true);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFB);
b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x4);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFF7);
@@ -793,6 +797,60 @@ static void lpphy_restore_crs(struct b43_wldev *dev, bool
user)
struct lpphy_tx_gains { u16 gm, pga, pad, dac; };
+static void lpphy_disable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFFE);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFEF);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFBF);
+ if (dev-phy.rev = 2) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFBFF);
+ b43_phy_mask(dev, B43_PHY_OFDM(0xE5), 0xFFF7);
+ }
+ } else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFDFF);
+ }
+}
+
+static void lpphy_enable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x1);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x10);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x40);
+ if (dev-phy.rev = 2) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x400);
+ b43_phy_set(dev, B43_PHY_OFDM(0xE5), 0x8);
+ }
+ } else {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x200);
+ }
+}
+
+static void lpphy_disable_tx_gain_override(struct b43_wldev *dev)
+{
+ if (dev-phy.rev 2)
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFF7F);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xBFFF);
+ }
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFBF);
+}
+
+static void lpphy_enable_tx_gain_override(struct b43_wldev *dev)
+{
+ if (dev-phy.rev 2)
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
+ else {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x80);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x4000);
+ }
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x40);
+}
+
static struct lpphy_tx_gains lpphy_get_tx_gains(struct
Re: [PATCH] b43: LP-PHY: Begin implementing calibration software RFKILL support
2009/10/25 Michael Buesch m...@bu3sch.de: On Sunday 25 October 2009 16:26:36 Gábor Stefanik wrote: Michael, could you please do the PHY reset part? I can't seem to understand its relationship to wireless_core_reset... also, it's heavily ssb-speak, which I am not good at. Where are the specifications? -- Greetings, Michael. They are @ http://bcm-v4.sipsolutions.net/802.11/PHY/Reset - it shows some similarity to wireless_core_reset, but it is not an exact match. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, Oct 25, 2009 at 7:17 PM, Linus Torvalds torva...@linux-foundation.org wrote: Ok, so I got myself (or rather, Patricia) a new Dell 11 inspiron laptop, and everything seems to work, except for the wireless. It's a Broadcom BCM4312b/g LP-PHY. In fact, even the wireless works at least to _some_ degree, because I saw the wireless networks listed once (but I can't seem to recreate that now), but: - I get a _lot_ of noise in dmesg: b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0: Controller restarted - the 'phy0' kernel thread seems to spend all its time presumably doing that firmware reloading (looks like 20% CPU time in top) - the wireless doesn't seem to actually ever succeed in connecting even the one time it saw something, and 'rmmod b43' just hangs. The network I'm trying to connect to is just a random 128-bit WEP thing. But while I once got far enough to see it (I think that was with the 4.150.10.5 firmware - I started out using the wrong one by mistake), now I can't even see the networks, so I doubt that matters. Maybe it's all as simple as me just having the wrong firmware version or something. But it's the version documented at http://linuxwireless.org/en/users/Drivers/b43 for the LP-PHY case. This is with current -git (v2.6.32-rc5-81-g964fe08), and lspci reports 08:00.0 0280: 14e4:4315 (rev 01) Subsystem: 1028:000c 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 17 Region 0: Memory at f060 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: b43-pci-bridge Kernel modules: ssb 00: e4 14 15 43 06 00 10 00 01 00 80 02 10 00 00 00 10: 04 00 60 f0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 0c 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 with dmesg saying b43-pci-bridge :08:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 b43-pci-bridge :08:00.0: setting latency timer to 64 ... cfg80211: Calling CRDA to update world regulatory domain ... cfg80211: World regulatory domain updated: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) b43-phy0: Broadcom 4312 WLAN found (core revision 15) ... phy0: Selected rate control algorithm 'minstrel' Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] ... cfg80211: Calling CRDA for country: US cfg80211: Regulatory domain changed to country: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2700 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 1700 mBm) (525 KHz - 533 KHz @ 4 KHz), (300 mBi, 2000 mBm) (549 KHz - 571 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm) ... b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) ... b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0 ERROR: b43-phy0: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... Controller restarted b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET
Re: b43 fatal DMA errors
2009/10/25 Linus Torvalds torva...@linux-foundation.org: On Sun, 25 Oct 2009, Gábor Stefanik wrote: Could you please test the tag master-2009-08-26 from wireless-testing? That one was the first version that worked, and in that specific build, my card (exactly the same as yours) worked perfectly, leading me to suspect a regression (probably not in the b43 driver, but in something else interfering with b43). Will try. Are you using that same firmware version? Yes, I have v478 also. However, I tried to build the latest wireless-testing tree, but I can't reproduce the error here. One thing I have noticed is that everyone so far with this error appears to have a HP or Dell laptop - I have tested with a custom-built desktop with an Asus motherboard. I will test my other 4312 in my Acer laptop later (I don't own a Dell or a HP). Could you describe the exact HW configuration of your system (including the BIOS type - my Acer has InsydeH2O, while my desktop is AMI-based)? Does the wl_hybrid driver work for you? (If it does work, please try building the latest compat-wireless for the kernel on which wl_hybrid worked, and post the results. Try the compat-wireless driver both on a cold boot and after wl_hybrid has been unloaded.) Also try apic=off acpi=off (IIRC another DMA error victim, but with error code 0x0800 had ACPI clobbering his DMA). Ok, will try that separately. Also, is there any reference to a failed channel switch in the log? Nope. Then it's a different bug than the 0x0800 one, which also caused channel switching to fail. Linus -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
On Sun, Oct 25, 2009 at 10:39 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Linus Torvalds wrote: Ok, this machine is a 1.3GHz Core 2 Duo, so no Atom crap. Oh, and I compile for x86-64, in case anybody cares. But I assume all sane developers have long since abandoned 32-bit mode, so I can't imagine that there is some 32-vs-64-bit issue. Btw, here's the dmesg from a few seconds after loading that driver with CONFIG_B43_DEBUG enabled. Just for fun, I'll also try what FORCE_PIO results in.. Linus 0x0400 is DMA PCI Descriptor Error - not sure what it actually means. BTW your dmidecode reveals that this is a modified PhoenixBIOS (non-Award) - I wonder if others with this error are also PhoenixBios users... Another thing to test: boot into Windows (or any other OS where the card works), initialize the card, reboot (not cold-boot) into Linux, try to load b43. If this succeeds, then we are missing something in the init routine. --- b43-phy1: Broadcom 4312 WLAN found (core revision 15) b43-phy1 debug: Found PHY: Analog 6, Type 5, Revision 1 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 phy1: Selected rate control algorithm 'minstrel' Registered led device: b43-phy1::tx Registered led device: b43-phy1::rx Registered led device: b43-phy1::radio Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy1 debug: Chip initialized b43-phy1 debug: 64-bit DMA initialized b43-phy1 debug: QoS enabled b43-phy1 debug: Wireless interface started b43-phy1 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 debug: Adding Interface type 2 b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy1 debug: Chip initialized b43-phy1 debug: 64-bit DMA initialized b43-phy1 debug: QoS enabled b43-phy1 debug: Wireless interface started b43-phy1: Controller restarted b43-phy1 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy1 debug: Chip initialized b43-phy1 debug: 64-bit DMA initialized b43-phy1 debug: QoS enabled b43-phy1 debug: Wireless interface started b43-phy1 ERROR: b43-phy1: Controller restarted Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy1: Controller RESET (DMA error) ... b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 ADDRCONF(NETDEV_UP): wlan0: link is not ready b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed
Re: b43 fatal DMA errors
On Sun, Oct 25, 2009 at 11:08 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. I don't know of such a method; however I have previously succeeded in using mmiotrace to find differences between wl and b43, so it might be of help in this case. However, this might be completely irrelevant, as I suspect that PhoenixBIOS is interfering with the DMA mappings of the card, which wl (and the Windows driver) works around somehow. (Is this PR41573? In that case, it's possible that the calibration patch - maybe in conjunction with a proper PHY reset - will fix it.) Larry: what BIOS are you testing on? And Chris, just out of interest - does FORCE_PIO work for you too? Linus -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fatal DMA errors
2009/10/25 Larry Finger larry.fin...@lwfinger.net: On 10/25/2009 05:28 PM, Gábor Stefanik wrote: On Sun, Oct 25, 2009 at 11:08 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 25 Oct 2009, Chris Vine wrote: On Sun, 25 Oct 2009 22:40:50 +0100 Gábor Stefanik netrolller...@gmail.com suggested: Another thing to test: boot into Windows (or any other OS where the [..] You already know that this eliminates the DMA errors. I have reported twice that if I boot up with the 2.6.27 kernel and install the broadcom b43 driver to intialise the wireless device, and then do a warm reboot to 2.6.32-rc5, then b43 works correctly. Is there some way to dump all the device registers behind the SSB bridge? If so, dumping them for the warm-boot and cold-boot cases, and seeing where they are different might be an obvious clue, and point to something that isn't initialized correctly. I don't know of such a method; however I have previously succeeded in using mmiotrace to find differences between wl and b43, so it might be of help in this case. However, this might be completely irrelevant, as I suspect that PhoenixBIOS is interfering with the DMA mappings of the card, which wl (and the Windows driver) works around somehow. (Is this PR41573? In that case, it's possible that the calibration patch - maybe in conjunction with a proper PHY reset - will fix it.) Larry: what BIOS are you testing on? The splash screen shows it to be a Phoenix BIOS. Kinda odd - apparently not all Phoenix BIOS versions are affected. (Or is this Phoenix AwardBIOS, Award Modular BIOS's successor? That would explain why it doesn't reproduce the error.) With dmidecode I see the following: BIOS Information Vendor: Hewlett-Packard Version: F.21 Release Date: 02/28/2008 Address: 0xE7060 Runtime Size: 102304 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported AGP is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 15.33 Firmware Revision: 81.81 Is this all that dmidecode outputs? There is an important element towards the end of the dump that identifies a PhoenixBIOS, even if it is cloaked. Larry -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43/BCM4312 fails with DMA errors
On Sun, Oct 18, 2009 at 1:44 AM, Charles Moschel fre...@carolina.rr.com wrote: On Sat, 17 Oct 2009 14:10:19 -0500 Larry Finger larry.fin...@lwfinger.net wrote: On 10/17/2009 01:12 PM, Charles Moschel wrote: Also, what I noticed is that everyone with this problem appears to have an Intel Atom CPU... weird. Maybe something weird is going on with the Atom chipset's DMA handling. No, it's not only Atom. I see it on Intel T4200 (dual core Pentium, 45nm, 800MHz FSB, GL40/GM45 chipset). Lenovo G530 laptop. Is this with the same wireless card moved from computer to computer? No, it came with the laptop and has never been removed. I reported earlier that it fails with 2.6.31 (Fedora rawhide kernel) + compat-wireless, but works with 2.6.32-rc[12] wireless-testing pulled from git: [https://lists.berlios.de/pipermail/bcm43xx-dev/2009-October/006132.html] What happens with 2.6.31-rc[12] + compat-wireless? And with just 2.6.32-rc[12] (without compat-wireless)? (My guess is that it will fail, but I need to know this before we move on.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43/BCM4312 fails with DMA errors
On Fri, Oct 16, 2009 at 6:01 PM, Chris Vine ch...@cvine.freeserve.co.uk wrote: On Fri, 16 Oct 2009 9:45:40 -0400 fre...@carolina.rr.com wrote: 2.6.32-rc? and wireless-compat was thought to work as well as wireless-testing ... hmmm Ah right. I had been trying 2.6.32-rc4 by itself and compat-wireless with 2.6.31. If I build compat-wireless on top of 2.6.32-rc.4 the dma errors appear to go away but the encryption modules won't load so it is not usable. I think I will try again in a few months time when things have settled down a bit. (Or possibly pull wireless-testing from git once 2.6.32 comes out.) Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev Could you please try the real wireless-testing tree (as opposed to compat-wireless)? Also, what I noticed is that everyone with this problem appears to have an Intel Atom CPU... weird. Maybe something weird is going on with the Atom chipset's DMA handling. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom cards for free
Sounds interesting... especially now that N-PHY is actually being reverse-engineered (or is it?). The modded 4320 is an attempt to replace the built-in OS and use it with b43 as a softmac device... am I right? On 10/9/09, Michael Buesch m...@bu3sch.de wrote: Hi, I've currently got two Broadcom cards to offer for free. http://bu3sch.de/misc/bcmcards.JPG The cardbus one is a WPC300N V1 802.11n card. It can be used for development of the b43 N-PHY code. The USB one is BCM4320 which works over RNDIS-WLAN. This device is disassembled and the EEPROM, which contains the on-board operating system, is unsoldered and connected through a pinheader. That means it can be read and/or reprogrammed outside of the device. The RF-shield on the RF-side of the board was removed. The device should work properly. It properly registers to the kernel, but I did not try if it works with the rndis-wlan driver. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broken patch for b43
On Fri, Oct 9, 2009 at 6:22 PM, Michael Buesch m...@bu3sch.de wrote: On Friday 09 October 2009 18:17:20 Larry Finger wrote: On 10/09/2009 10:41 AM, Gábor Stefanik wrote: G-PHY revision =2 is handled by b43legacy, not b43, so it shouldn't be a problem. That is not true. -- Greetings, Michael. Oops... yes, I confused the PHY vs. MAC revisions. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 DMA Errors (still)
2009/10/6 Lance Hepler nlhep...@gmail.com: 2009/10/6 Gábor Stefanik netrolller...@gmail.com: So, this error happens specifically on suspend/resume? No, it'll happen pretty frequently the first time I try to connect, but always after I suspend+resume. And once the DMA error pops up, It just keeps happening.. By far, the rarest occurrence is the device actually working. Lance One thing I can see from the log is that you have both wl and ssb (b43's backend) loaded at the same time. Remember to also unload ssb when you unload b43. Also, could you try the real wireless-testing? (BTW, your card is a Dell 1397, which was one of the development cards I used; so the problem is not a new variant.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 DMA Errors (still)
On Fri, Oct 2, 2009 at 11:04 PM, fre...@carolina.rr.com wrote: Hi Folks -- I've read in the archives about DMA errors with the LP-PHY, but there didn't seem to be any conclusion. Any guidance on what I can test to get it working? It's reproducable on my Lenovo G530 laptop. (Yes, I know forcing PIO works for others, and it works for me too, but I'd like to help testing if I can). Any guidance on which tests would be most likely to work? AFAIK, options to test include: * 64bit kernel (and userland?) * Hack b43/dma.c to force fallback to 32bit DMA (as a trial datapoint only) Won't work - LP-PHY only supports 64bit DMA. * Boot with Mem=2G. Currently 4G ram is installed. * Firmware 5xx Or is this a HW design error in the laptop, and I should just live with forcing PIO? My system details: * Compat-wireless-2009-09-30 (and also back to 9-21) * Fedora Rawhide 32-bit, kernel 2.6.31.1-56.fc12.i686 * Firmware 478.104 * Fatal DMA error soon after heavy traffic starts Try installing a proper wireless-testing kernel (not just compat-wireless). This issue seems to specifically affect 2.6.31+compat-wireless users (probably something needs to be backported). 2.6.32-rc1+compat-wireless shoud also work. dmesg extract: ssb: Sonics Silicon Backplane found on PCI device :04:00.0 b43-phy0: Broadcom 4312 WLAN found (core revision 15) b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 phy0: Selected rate control algorithm 'minstrel' Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] b43 ssb0:0: firmware: requesting b43/ucode15.fw cfg80211: Calling CRDA for country: US cfg80211: Regulatory domain changed to country: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2700 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 1700 mBm) (525 KHz - 533 KHz @ 4 KHz), (300 mBi, 2000 mBm) (549 KHz - 571 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm) b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5 b43-phy0 debug: Chip initialized b43-phy0 debug: 64-bit DMA initialized b43-phy0 debug: QoS enabled b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: deauthenticating from 00:0c:41:e2:f9:81 by local choice (reason=3) wlan0: direct probe to AP 00:0c:41:e2:f9:81 (try 1) wlan0: direct probe responded wlan0: authenticate with AP 00:0c:41:e2:f9:81 (try 1) wlan0: authenticated wlan0: associate with AP 00:0c:41:e2:f9:81 (try 1) wlan0: RX AssocResp from 00:0c:41:e2:f9:81 (capab=0x411 status=0 aid=2) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 NOHZ: local_softirq_pending 08 wlan0: no IPv6 routers present CE: hpet increasing min_delta_ns to 15000 nsec b43-phy0 ERROR: Fatal DMA error: 0x, 0x0400, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... b43-phy0 debug: Wireless interface stopped b43-phy0 debug: DMA-64 rx_ring: Used slots 8/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 256/256, Failed frames 0/7742 = 0.0%, Average tries 1.37 b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 2/256, Failed frames 0/555 = 0.0%, Average tries 1.01 b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz. b43-phy0 debug: Chip initialized b43-phy0 debug: 64-bit DMA initialized b43-phy0 debug: QoS enabled b43-phy0 debug: Wireless interface started b43-phy0: Controller restarted b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0:
Re: b43 LP PHY status
2009/9/29 Ed Spiridonov edo@gmail.com: what is current LP PHY status? Working in 2.6.32-rc1, though no calibration yet; so performance is probably not on par with wl_hybrid or ndiswrapper. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 LP PHY status
2009/9/29 Ed Spiridonov edo@gmail.com: 2009/9/29 Gábor Stefanik netrolller...@gmail.com: 2009/9/29 Ed Spiridonov edo@gmail.com: what is current LP PHY status? Working in 2.6.32-rc1, though no calibration yet; so performance is probably not on par with wl_hybrid or ndiswrapper. i will use it on bcm5354 (mips cpu + b43), so i cannot use ndiswrapper. BCM5354 might need some extra fixes from wireless-testing - not sure if they made into 2.6.32. I know nothing about wl_hybrid, it is close-source too? It's semi-closed-source. (There is an open-source part that handles the card as if it were a fullmac, while the actual code controlling the HW is closed-source.) now i use 2.4 kernel on my dlink dir-320 (with binary drivers from broadcom). -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 LP PHY status
2009/9/29 Ed Spiridonov edo@gmail.com: 2009/9/29 Gábor Stefanik netrolller...@gmail.com: 2009/9/29 Ed Spiridonov edo@gmail.com: 2009/9/29 Gábor Stefanik netrolller...@gmail.com: 2009/9/29 Ed Spiridonov edo@gmail.com: what is current LP PHY status? Working in 2.6.32-rc1, though no calibration yet; so performance is probably not on par with wl_hybrid or ndiswrapper. i will use it on bcm5354 (mips cpu + b43), so i cannot use ndiswrapper. BCM5354 might need some extra fixes from wireless-testing - not sure if they made into 2.6.32. did you need help with testing on bcm5354? Yes; it's still a WIP. (BTW, please keep the CC to Broadcom-Wireless.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4322 development status
On Thu, Sep 17, 2009 at 1:32 PM, Christian Schoenebeck c...@users.sf.net wrote: Hi! What is the current development status for the BCM4322 chip? Is it working in the meantime? If not, I can also try to hack the b43 driver for supporting it, at least if I get the necessary informations. CU Christian ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev It is completely unsupported - not even specs are available for it. (The reverse-engineering team has set a requirement for working LP-PHY code before they start working on N-PHY cards like 4322; and we have only gotten LP-PHY to work a few weeks ago.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY status?
2009/9/17 Thomas Ilnseher il...@gmx.de: Am Donnerstag, den 17.09.2009, 18:02 +0200 schrieb Rafał Miłecki: Hi, I would like to ask about status of LP-PHY status. Could you explain to simple end-user what is missing in current implementation? Is this just calibration for performance, or something more? Did someone make some tests for AP mode? Or is this /stupid/ idea without calibration done? The LP PHY code works for me since compat-wireless-02-09-09. I can't use newer versions because of some IRQ_THREAD stuff. Maybe my device crashes here then, but hat could be due to other stuff as well (It's an embedded system, ASUS WL-520gU) I have written a (very small) patch that implements proper analog switch support for the LP PHY, and that seems to improve throughput on my device. Stefanik is there change you find some time to finish calibration part before .32 merge window? Don't want to rush you, you already have done great work, just would like to know. I don't know how difficult this calibration stuff is. If it's as simple as the analog switch patch (or the other two useless patches I wrote), You (Stefanik) can drop me a note that I should do it. If you think my patches are crap, and I'm only wasting your time, just inform me. Calibration is quite hard to do; but I have already posted an incomplete patch about it on the list, which was rejected due to a huge error, and my VMware installation died next day before I could fix the patch up. Fixing the remaining issues on that should be easy - you need to implement PHY reset (and use it instead of put_phy_into_reset, which should actually be called disable_phy) and replace the inline implementation of PHY anacore with a proper call to the switch_analog op. (When I wrote the code, I didn't realize that PHY anacore actually means switch analog core.) Note that my patch doesn't contain all 3 calibration routines, only one of them. BTW your useless patches will probably become useful when writing calibration. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
You are essentially implementing dead code at this point - this will
only ever be called if hardware-accelerated TX power control is
enabled - and HW TX power control is unsupported, even for G-PHYs.
On Wed, Sep 16, 2009 at 9:37 PM, Thomas Ilnseher il...@gmx.de wrote:
This patch adds the lpphy_clear_tx_power_offsets to b43.
Signed-off-by: Thomas Ilnseher il...@gmx.de
---
diff -uNr a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
--- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
+++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
@@ -1125,6 +1125,18 @@
dev-phy.lp-tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT)
0x7F00) 8;
}
+static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
+{
+ int i;
+ int id = 7;
+ if (dev-phy.rev 2)
+ id = 10;
+ for (i = 0; i 12; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
+ for (i = 0; i 64; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
+}
+
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
enum b43_lpphy_txpctl_mode mode)
{
@@ -1139,7 +1151,7 @@
if (oldmode == B43_LPPHY_TXPCTL_HW) {
lpphy_update_tx_power_npt(dev);
- //TODO Clear all TX Power offsets
+ lpphy_clear_tx_power_offsets(dev);
} else {
if (mode == B43_LPPHY_TXPCTL_HW) {
//TODO Recalculate target TX power
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
2009/9/16 Thomas Ilnseher il...@gmx.de:
Am Mittwoch, den 16.09.2009, 21:40 +0200 schrieb Gábor Stefanik:
You are essentially implementing dead code at this point - this will
only ever be called if hardware-accelerated TX power control is
enabled - and HW TX power control is unsupported, even for G-PHYs.
Then the question remains, why this brings my device to 54 MBit/s ?
I did double check again with the old driver:
wlan0 IEEE 802.11bg ESSID:tommy
Mode:Managed Frequency:2.412 GHz Access Point:
Bit Rate=9 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=5 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Patched driver:
wlan0 IEEE 802.11bg ESSID:tommy
Mode:Managed Frequency:2.412 GHz Access Point: XXX
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=10 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Signed-off-by: Thomas Ilnseher il...@gmx.de
---
diff -uNr a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
--- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
+++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
@@ -1125,6 +1125,18 @@
dev-phy.lp-tssi_idx = (b43_phy_read(dev,
B43_LPPHY_TX_PWR_CTL_STAT) 0x7F00) 8;
}
+static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
+{
+ int i;
+ int id = 7;
+ if (dev-phy.rev 2)
+ id = 10;
+ for (i = 0; i 12; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
+ for (i = 0; i 64; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
+}
+
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
enum b43_lpphy_txpctl_mode mode)
{
@@ -1139,7 +1151,7 @@
if (oldmode == B43_LPPHY_TXPCTL_HW) {
lpphy_update_tx_power_npt(dev);
- //TODO Clear all TX Power offsets
+ lpphy_clear_tx_power_offsets(dev);
Put a printk here to see if this branch is getting hit.
(BTW, are you loading b43 with the hwpctl modparam? That enables
experimental HW TX power control support, which might explain what you
were seeing.)
} else {
if (mode == B43_LPPHY_TXPCTL_HW) {
//TODO Recalculate target TX power
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 crashes on IPX4XX and works on x86 ?!?
On Mon, Sep 14, 2009 at 7:42 PM, Michael Buesch m...@bu3sch.de wrote: On Monday 14 September 2009 18:56:08 Daniel Schmitt wrote: well, same issue: ssb: Sonics Silicon Backplane found on PCI device :00:02.0 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243) ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243) ssb: Core 4 found: PCI (cc 0x804, rev 0x07, vendor 0x4243) ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) ssb: Ignoring additional 802.11 core ssb: Using different timing for ioread 16. udelay(10) ssb: Using different timing for ioread 16. udelay(10) ssb: WARNING: Invalid SPROM CRC (corrupt SPROM) ssb: SPROM revision 91 detected. ssb: Unsupported SPROM revision 91 detected. Will extract v1 ssb: Sonics Silicon Backplane found on PCI device :00:04.0 I tried udelay(5) and udelay(10). Something strange happens there that ssb isn't able to access SPROM ... well, are you sure that there actually is an sprom on the card? Probably, since it is read out perfectly on an x86 machine. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: LP-PHY: Fix analog core switching
The generic analog switch routine is not correct for LP-PHY according
to the latest specs. Implement the proper analog core switch routine.
Signed-off-by: Gábor Stefanik netrolller...@gmail.com
---
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 80da9c7..b0e127a 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -2160,6 +2160,16 @@ static int lpphy_b2063_tune(struct b43_w
return 0;
}
+static void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
+{
+ if (on) {
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x7);
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x7);
+ } else {
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFF8);
+ }
+}
+
static int b43_lpphy_op_switch_channel(struct b43_wldev *dev,
unsigned int new_channel)
{
@@ -2239,7 +2249,7 @@ const struct b43_phy_operations b43_phyo
.radio_read = b43_lpphy_op_radio_read,
.radio_write= b43_lpphy_op_radio_write,
.software_rfkill= b43_lpphy_op_software_rfkill,
- .switch_analog = b43_phyop_switch_analog_generic,
+ .switch_analog = b43_lpphy_op_switch_analog,
.switch_channel = b43_lpphy_op_switch_channel,
.get_default_chan = b43_lpphy_op_get_default_chan,
.set_rx_antenna = b43_lpphy_op_set_rx_antenna,
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 crashes on IPX4XX and works on x86 ?!?
On Sun, Sep 13, 2009 at 7:05 PM, Daniel Schmitt dan...@schmitt-united.de wrote: Hello Group, I posted a few days ago my problems with this WLAN minipci card: Linux OpenWrt 2.6.28.10 #5 Thu Sep 10 20:36:33 CEST 2009 armv5teb unknown 00:02.0 0280: 14e4:4325 (rev 02) Subsystem: 1414:0004 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- Interrupt: pin A routed to IRQ 27 Region 0: Memory at 4802 (32-bit, non-prefetchable) [disabled] [size=8K] If I use them (2 pieces) in a WP188 from compex, I don't get ssb.ko running. Here is the dmesg if I try to load ssb.ko and b43legacy.ko PCI: enabling device :00:02.0 (0140 - 0142) ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243) ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243) ssb: Core 4 found: PCI (cc 0x804, rev 0x07, vendor 0x4243) ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) ssb: Ignoring additional 802.11 core ssb: WARNING: Invalid SPROM CRC (corrupt SPROM) ssb: SPROM revision 251 detected. ssb: Unsupported SPROM revision 251 detected. Will extract v1 ssb: Sonics Silicon Backplane found on PCI device :00:02.0 PCI: enabling device :00:04.0 (0140 - 0142) ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243) ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243) ssb: Core 4 found: PCI (cc 0x804, rev 0x07, vendor 0x4243) ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) ssb: Ignoring additional 802.11 core ssb: WARNING: Invalid SPROM CRC (corrupt SPROM) ssb: SPROM revision 251 detected. ssb: Unsupported SPROM revision 251 detected. Will extract v1 What endianness is the IXP4xx? ssb: Sonics Silicon Backplane found on PCI device :00:04.0 cfg80211: Using static regulatory domain info cfg80211: Regulatory domain: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) cfg80211: Calling CRDA for country: US b43legacy-phy0: Broadcom 4306 WLAN found phy0: Failed to initialize wep: -2 b43legacy: probe of ssb0:0 failed with error -2 -2 is No such file or directory - maybe some crypto options are disabled? Does the ARC4 module get built? b43legacy-phy1: Broadcom 4306 WLAN found phy1: Failed to initialize wep: -2 b43legacy: probe of ssb1:0 failed with error -2 Broadcom 43xx-legacy driver loaded [ Features: PLID, Firmware-ID: FW10 ] One time I managed it to run for half an hour. I think it is a PCI problem of IPX4XX? Because running the same cards in my ALIX works without problems! cfg80211: Using static regulatory domain info cfg80211: Regulatory domain: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) cfg80211: Calling CRDA for country: US b43-pci-bridge :00:0c.0: setting latency timer to 64 ssb: Sonics Silicon Backplane found on PCI device :00:0c.0 b43-pci-bridge :00:0e.0: setting latency timer to 64 ssb: Sonics Silicon Backplane found on PCI device :00:0e.0 Please enable SSB B43 debugging on this platform, too. b43legacy-phy0: Broadcom 4306 WLAN found phy0: Selected rate control algorithm 'minstrel' b43legacy-phy1: Broadcom 4306 WLAN found phy1: Selected rate control algorithm 'minstrel' Broadcom 43xx-legacy driver loaded [ Features: PLID, Firmware-ID: FW10 ] ip_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (4096 buckets, 16384 max) Registered led device: alix:1 Registered led device: alix:2 Registered led device: alix:3 via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker via-rhine :00:09.0: setting latency timer to 64 eth0: VIA Rhine III (Management Adapter) at 0xe000, 00:0d:b9:12:83:b8, IRQ 10. eth0: MII PHY
Re: 5354 + B43 = Instant Crash
On Fri, Sep 11, 2009 at 10:54 PM, Thomas Ilnseher il...@gmx.de wrote: Hi List, I installed the latest version of OpenWRT on a ASUS WL-520GU. I compiles a few kernel patches to make the OpenWRT kernel (2.6.28.10) compatible with compat wireless. Than I patched OpenWRT to build compat-wireless-09-02 As said, It yields an instant crash: cfg80211: World regulatory domain updated: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) b43-phy0: Broadcom 5354 WLAN found (core revision 13) Decompressing..done == CFE Again, no usefull stuff on teh RS232 port FWIW, I add the patches for the kernel. These patches are probably not enough - there were more changes to the ssb module since 2.6.28. You will probably need to compile a new kernel from wireless-testing or net-next-2.6 (linux-next linux-2.6 may also work). (God luck doing that in the OpenWRT build system...) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 5354 + B43 = Instant Crash
2009/9/12 Gábor Stefanik netrolller...@gmail.com: On Fri, Sep 11, 2009 at 10:54 PM, Thomas Ilnseher il...@gmx.de wrote: Hi List, I installed the latest version of OpenWRT on a ASUS WL-520GU. I compiles a few kernel patches to make the OpenWRT kernel (2.6.28.10) compatible with compat wireless. Than I patched OpenWRT to build compat-wireless-09-02 As said, It yields an instant crash: cfg80211: World regulatory domain updated: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) b43-phy0: Broadcom 5354 WLAN found (core revision 13) Decompressing..done == CFE Again, no usefull stuff on teh RS232 port FWIW, I add the patches for the kernel. These patches are probably not enough - there were more changes to the ssb module since 2.6.28. You will probably need to compile a new kernel from wireless-testing or net-next-2.6 (linux-next linux-2.6 may also work). (God luck doing that in the OpenWRT build system...) Oops... that was Good's hand. :) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 rev2 kernel segfault and reboot
On Thu, Sep 10, 2009 at 8:43 PM, Daniel Schmitt dan...@schmitt-united.de wrote: Hello bcm43xx developers, I have problems using a bcm4306 rev 2 minipci card. I got the card out of Microsoft mn700. I also have 2 atheros cards. They work. Here is output of uname -a: Linux OpenWrt 2.6.28.10 #5 Thu Sep 10 20:36:33 CEST 2009 armv5teb unknown lspci -vvn|grep 43 -A7: 00:02.0 0280: 14e4:4325 (rev 02) Subsystem: 1414:0004 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- Interrupt: pin A routed to IRQ 27 Region 0: Memory at 4802 (32-bit, non-prefetchable) [disabled] [size=8K] 00:03.0 0200: 168c:001b (rev 01) -- 00:04.0 0280: 14e4:4325 (rev 02) Subsystem: 1414:0004 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- Interrupt: pin A routed to IRQ 25 Region 0: Memory at 48022000 (32-bit, non-prefetchable) [disabled] [size=8K] When I use latest trunk openwrt on my Compes WP188 ipx4xx board with latest compat-wireless 2009-09-09 and with the ssb.ko inside the compat-wireless I get the following kernel panic: r...@openwrt:/lib/modules/2.6.28.10# insmod ssb.ko PCI: enabling device :00:02.0 (0140 - 0142) Bad mode in data abort handler detected Internal error: Oops - bad mode: 0 [#1] Modules linked in: ssb(+) CPU: 0 Not tainted (2.6.28.10 #2) pc : [01fc] lr : [bf002d94] psr: a092 sp : c392bb5c ip : 0001 fp : c392bbcc r10: c0230184 r9 : bf009000 r8 : r7 : c3ad4248 r6 : c393b000 r5 : 0025 r4 : r3 : c48c9048 r2 : c392bba4 r1 : 0001 r0 : 9048 Flags: NzCv IRQs off FIQs on Mode IRQ_32 ISA ARM Segment user Control: 39ff Table: 03968000 DAC: 0015 Process insmod (pid: 1508, stack limit = 0xc392a260) Stack: (0xc392bb5c to 0xc392c000) bb40: 9048 bb60: 0001 c392bba4 c48c9048 0025 c393b000 c3ad4248 bb80: bf009000 c0230184 c392bbcc 0001 c392bb5c bf002d94 01fc a092 bba0: c392bbb0 ffb9 c392bbfc c3ad4200 c393b000 c392bbf4 bf0067c0 bbc0: c392bbf0 c392bbd0 bf002d94 bf002624 c392bbf4 c393b000 c393b31c bbe0: bf002bdc c392bc98 c392bbf4 bf000eb0 bf002be8 bc00: bc20: bc40: bc60: c3811400 c393b000 bc80: c02409cc c0228a60 c392bca8 c392bc9c bf000fd8 bf000ddc c392bcc4 bca0: c392bcac bf003dfc bf000fb8 bf006634 c3811400 c392bce4 c392bcc8 bcc0: c0115d30 bf003d70 c3811458 bf006668 bf006668 c012ef64 c392bd08 c392bce8 bce0: c012ee60 c0115cd4 c3811458 bf006668 c3811504 c012ef64 c39532a0 c392bd24 bd00: c392bd0c c012eff0 c012edc4 c392bd28 bf006668 c392bd4c c392bd28 bd20: c012e498 c012ef70 c382d598 c38114a0 bf006668 bf006668 bd40: c392bd5c c392bd50 c012ecc8 c012e44c c392bd88 c392bd60 c012e950 c012ecb4 bd60: bf006328 bf006634 bf006668 bf006668 c392a000 befe9e98 c392bdac bd80: c392bd8c c012f198 c012e8b0 bf006634 bf006668 c392a000 bda0: c392bdc8 c392bdb0 c0115fa4 c012f150 bf0066a0 00075028 c392bdd8 bdc0: c392bdcc bf003d10 c0115f64 c392bde8 c392bddc bf009080 bf003ce8 c392bdfc bde0: c392bdec bf00905c bf009078 c392bf80 c392be00 c00212b0 bf00900c be00: c0033640 c38f5c00 c392be5c c392be20 c017de80 c0033620 be20: 0001 0010 c3a3ec20 0004 be40: c02b5700 c022f280 c022f268 c392be80 c392be60 c0067940 c006618c be60: 0009 c48b9000 0001 bf0066a0 c392be90 c392be84 c0067a44 be80: c0067840 c392bea4 c392be94 c3a16ec0 000a c48b9000 c392bec4 c392bea8 bea0: c007b774 c008466c c392a000 c392bed4 c392bec8 bec0: c007b844 c007b6e8 c392bf80 c392bed8 c005d188 c007b820 c392bf50 bee0: c392bf48 c392bef0 bf0066ac c48bff50 c48bfca8 c48bfbd0 c3a16ca0 bf00: c48c0c68 0016 0017 000d 00c0 00c0 c48c0068 bf20: c48c0c58 c012e64c c48c0040 c48c0068 bf006338 0017 bf40: 9980 bf0066a0 00075028 9980 bf0066a0 bf60: 00075028 c0021f84 c392a000 befe9e98 c392bfa4 c392bf84 c005d4c4 bf80: c0021284 c00864d8 9980 00075028 0002 0080 c392bfa8 bfa0: c0021de0 c005d440 9980 00075028 00075028 9980 00075018 00075028
Re: [PATCH] b43: Add Soft-MAC SDIO device support
On Thu, Sep 10, 2009 at 7:34 PM, Michael Buesch m...@bu3sch.de wrote:
From: Albert Herranz albert_herr...@yahoo.es
This adds support for Soft-MAC SDIO devices to b43.
The driver still lacks some fixes for SDIO devices, so it's currently
marked as BROKEN.
Is it actually completely broken; or already testable, just incomplete?
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Depends on the SSB SDIO patch.
Index: wireless-testing/drivers/net/wireless/b43/Kconfig
===
--- wireless-testing.orig/drivers/net/wireless/b43/Kconfig 2009-09-10
19:23:09.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/Kconfig 2009-09-10
19:33:24.0 +0200
@@ -61,11 +61,28 @@ config B43_PCMCIA
If unsure, say N.
+config B43_SDIO
+ bool Broadcom 43xx SDIO device support (EXPERIMENTAL)
+ depends on B43 SSB_SDIOHOST_POSSIBLE EXPERIMENTAL BROKEN
+ select SSB_SDIOHOST
+ ---help---
+ Broadcom 43xx device support for Soft-MAC SDIO devices.
+
+ With this config option you can drive Soft-MAC b43 cards with a
+ Secure Digital I/O interface.
+ This includes the WLAN daughter card found on the Nintendo Wii
+ video game console.
+ Note that this does not support Broadcom 43xx Full-MAC devices.
+
+ It's safe to select Y here, even if you don't have a B43 SDIO
device.
+
+ If unsure, say N.
+
# Data transfers to the device via PIO
-# This is only needed on PCMCIA devices. All others can do DMA properly.
+# This is only needed on PCMCIA and SDIO devices. All others can do DMA
properly.
config B43_PIO
bool
- depends on B43 (B43_PCMCIA || B43_FORCE_PIO)
+ depends on B43 (B43_SDIO || B43_PCMCIA || B43_FORCE_PIO)
select SSB_BLOCKIO
default y
Index: wireless-testing/drivers/net/wireless/b43/Makefile
===
--- wireless-testing.orig/drivers/net/wireless/b43/Makefile 2009-09-10
19:23:09.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/Makefile 2009-09-10
19:23:20.0 +0200
@@ -16,6 +16,7 @@ b43-$(CONFIG_B43_PIO) += pio.o
b43-y += rfkill.o
b43-$(CONFIG_B43_LEDS) += leds.o
b43-$(CONFIG_B43_PCMCIA) += pcmcia.o
+b43-$(CONFIG_B43_SDIO) += sdio.o
b43-$(CONFIG_B43_DEBUG) += debugfs.o
obj-$(CONFIG_B43) += b43.o
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-09-10
19:23:09.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-10
19:23:20.0 +0200
@@ -8,6 +8,9 @@
Copyright (c) 2005 Danny van Dyk kugelf...@gentoo.org
Copyright (c) 2005 Andreas Jaggi andreas.ja...@waterwave.ch
+ SDIO support
+ Copyright (c) 2009 Albert Herranz albert_herr...@yahoo.es
+
Some parts of the code in this file are derived from the ipw2200
driver Copyright(c) 2003 - 2004 Intel Corporation.
@@ -53,6 +56,8 @@
#include xmit.h
#include lo.h
#include pcmcia.h
+#include sdio.h
+#include linux/mmc/sdio_func.h
MODULE_DESCRIPTION(Broadcom B43 wireless driver);
MODULE_AUTHOR(Martin Langer);
@@ -1587,7 +1592,7 @@ static void b43_beacon_update_trigger_wo
mutex_lock(wl-mutex);
dev = wl-current_dev;
if (likely(dev (b43_status(dev) = B43_STAT_INITIALIZED))) {
- if (0 /*FIXME dev-dev-bus-bustype == SSB_BUSTYPE_SDIO*/) {
+ if (dev-dev-bus-bustype == SSB_BUSTYPE_SDIO) {
/* wl-mutex is enough. */
b43_do_beacon_update_trigger_work(dev);
mmiowb();
@@ -1905,6 +1910,27 @@ static irqreturn_t b43_interrupt_handler
return ret;
}
+/* SDIO interrupt handler. This runs in process context. */
+static void b43_sdio_interrupt_handler(struct b43_wldev *dev)
+{
+ struct b43_wl *wl = dev-wl;
+ struct sdio_func *func = dev-dev-bus-host_sdio;
+ irqreturn_t ret;
+
+ if (unlikely(b43_status(dev) B43_STAT_STARTED))
+ return;
+
+ mutex_lock(wl-mutex);
+ sdio_release_host(func);
+
+ ret = b43_do_interrupt(dev);
+ if (ret == IRQ_WAKE_THREAD)
+ b43_do_interrupt_thread(dev);
+
+ sdio_claim_host(func);
+ mutex_unlock(wl-mutex);
+}
+
void b43_do_release_fw(struct b43_firmware_file *fw)
{
release_firmware(fw-data);
@@ -3828,7 +3854,7 @@ redo:
/* Disable interrupts on the device. */
b43_set_status(dev, B43_STAT_INITIALIZED);
- if (0 /*FIXME dev-dev-bus-bustype == SSB_BUSTYPE_SDIO*/) {
+ if (dev-dev-bus-bustype ==
Re: b43 dma error
Do you have the threaded-IRQ patches applied? Also, what card is this? (BCM4312?) Try upgrading your firmare (use v478 or the new v5xx one). ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 dma error
On Tue, Sep 8, 2009 at 7:50 PM, John Daikerdaikerj...@gmail.com wrote: On 09/08/2009 07:54 AM, Larry Finger wrote: Michael Buesch wrote: On Tuesday 08 September 2009 15:47:32 Dave Young wrote: I tested wireless-testing b43 driver, but got Fatal DMA error then the controller keep restarting... Please tell what I can provide or test, Thanks. Is this a regression? If so, please bisect. It is something specific to his system as I don't see anything like this. In addition, there are some users on the openSUSE forums that have implemented the latest compat-wireless and switched away from Broadcom wl to b43 on their LP PHY devices. So far, no complaints from them. Please reboot so that we see the ssb output as well. Use the command dmesg | egrep ssb|b43 That way we will be able to see exactly what kind of device you have and what revisions are in it. AFAIK, the testing to date has been limited to Rev 1 PHYs and Rev 2 radios. Larry I can confirm the same issue. I have a HP Mini 1116NR with a Broadcom 4312. Looks to be a PHY 1, Radio 2: --snip-- [ 456.165296] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1 [ 456.165364] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 --snip-- I've attached the output of 'dmesg | egrep ssb|b43', my kernel config, and lspci -vv and lspci -nn Note: With the dmesg output, I had unloaded the b43 module previous 'modprobe -r b43' and then loaded it again with debug output: 'modprobe b43 verbose=3' John Daiker Again, please test with v478 or v5xx firmware. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 dma error
On Tue, Sep 8, 2009 at 8:16 PM, Larry Fingerlarry.fin...@lwfinger.net wrote: John Daiker wrote: On 09/08/2009 07:54 AM, Larry Finger wrote: Michael Buesch wrote: On Tuesday 08 September 2009 15:47:32 Dave Young wrote: I tested wireless-testing b43 driver, but got Fatal DMA error then the controller keep restarting... Please tell what I can provide or test, Thanks. Is this a regression? If so, please bisect. It is something specific to his system as I don't see anything like this. In addition, there are some users on the openSUSE forums that have implemented the latest compat-wireless and switched away from Broadcom wl to b43 on their LP PHY devices. So far, no complaints from them. Please reboot so that we see the ssb output as well. Use the command dmesg | egrep ssb|b43 That way we will be able to see exactly what kind of device you have and what revisions are in it. AFAIK, the testing to date has been limited to Rev 1 PHYs and Rev 2 radios. Larry I can confirm the same issue. I have a HP Mini 1116NR with a Broadcom 4312. Looks to be a PHY 1, Radio 2: --snip-- [ 456.165296] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1 [ 456.165364] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 --snip-- I've attached the output of 'dmesg | egrep ssb|b43', my kernel config, and lspci -vv and lspci -nn Note: With the dmesg output, I had unloaded the b43 module previous 'modprobe -r b43' and then loaded it again with debug output: 'modprobe b43 verbose=3' Your PHY and your radio are the same as mine. In fact, the one thing I noticed is that you are using i386 architecture, whereas mine is x86_64. I have not tested with i386. Has anyone run the LP PHY modifications with 32-bit architecture? Yes, me. (With the exact same card as John.) Larry -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 dma error
2009/9/8 Larry Finger larry.fin...@lwfinger.net: Gábor Stefanik wrote: On Tue, Sep 8, 2009 at 8:16 PM, Larry Fingerlarry.fin...@lwfinger.net wrote: Your PHY and your radio are the same as mine. In fact, the one thing I noticed is that you are using i386 architecture, whereas mine is x86_64. I have not tested with i386. Has anyone run the LP PHY modifications with 32-bit architecture? Yes, me. (With the exact same card as John.) Is it a maximum memory issue? How much for you? John and Dave: Same question. Larry 2GB here. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: PCMCIA is not experimental anymore
2009/9/6 Michael Buesch m...@bu3sch.de: On Sunday 06 September 2009 20:42:00 Gábor Stefanik wrote: On Sun, Sep 6, 2009 at 2:49 PM, Michael Bueschm...@bu3sch.de wrote: PCMCIA support works well and is not experimental anymore. Signed-off-by: Michael Buesch m...@bu3sch.de --- drivers/net/wireless/b43/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- wireless-testing.orig/drivers/net/wireless/b43/Kconfig +++ wireless-testing/drivers/net/wireless/b43/Kconfig @@ -42,8 +42,8 @@ config B43_PCICORE_AUTOSELECT default y config B43_PCMCIA - bool Broadcom 43xx PCMCIA device support (EXPERIMENTAL) - depends on B43 SSB_PCMCIAHOST_POSSIBLE EXPERIMENTAL + bool Broadcom 43xx PCMCIA device support + depends on B43 SSB_PCMCIAHOST_POSSIBLE select SSB_PCMCIAHOST ---help--- Broadcom 43xx PCMCIA device support. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev This should be auto-selected depending on SSB_PCMCIAHOST_POSSIBLE (at least if !EMBEDDED). There is no need for a separate config prompt if it's not EXPERIMENTAL anymore. Patch please -- Greetings, Michael. I need to fix my virtual machine first. (That's also why LP-PHY development is stalled - I carelessly installed the VMware 7 beta build I have been invited to, so that I can use all 4 CPU cores in the VM - and the new VMware crashes on startup. Again, the VHD was not lost, but I don't currently have the tools to read it.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43-fwcutter patch for new firmware versions (508.1107 and 508.102)
On Fri, Sep 4, 2009 at 12:02 AM, Daniel Lenskidlen...@gmail.com wrote: On Thu, 2009-09-03 at 16:37 -0500, Larry Finger wrote: Daniel Lenski wrote: Larry, I agree on the ridiculously poor packaging... did I mention they're 1gb+ extracted? I didn't look at what is contained within that package, but we certainly don't need it. It appears to be the complete toolchain used to build the firmware, complete with a bunch of random binaries floating around. I have not found any other source of these, unfortunately. I am happy to send the extracted firmware to developers off-list if desired. Linksys's less-than-helpful GPL source code page gives no indication of the age or date of the various files, so it's hard for me to tell which might be newer without downloading many Gb and extracting many firmwares. I have half a mind to write a Python script... Not necessary to send the extracted software. If and when I want to see the new firmware, I'm perfectly happy to download that big file; however, it does not make sense for some user who is using the openSUSE script to wait through a large download just to install firmware. Good point. I'm not really familiar with the legal intricacies of the licensing issues involved. The LICENSE files strewn throughout the tarball *seem* to indicate that it'd be permissible to cut out the relevant binaries and distribute them, but I'm in way over my head here... I notice in your extraction that there are now ucode files for revisions 16, 17, 19, 20, and 21. Yes, indeed. So are these the source of the FW12/13/14/... numbering? No. Michael assigns a new number whenever he releases a new version. All the new files are supposed to be listed with that number. At least I think that is the way it works. Version 12 is the last one released. Hmm... I think we might be talking about two different things. I'm wondering about the source of the .id = FWxx tags in fwcutter_list.h. They have no source - everytime a new version is added to fwcutter, it's FWxx ID is incremented. E.g. if the most recent version is FW15, then adding a new entry should be done as FW16. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help again please
(CCing bcm43xx-dev.) Could you post the dmesg output when this happens? (Enable debugging in b43 before taking the log.) 2009/9/2 Brian J. Mc Hugh bjmch...@aya.yale.edu: Hi Gábor, I seem to remember you explaining there was a bluetooth problem and it couldn't coexist. Is that right? Brian 2009/9/2 Brian J. Mc Hugh bjmch...@aya.yale.edu sorry. And everything worked. Now it doesn't. Am I missing a command? Brian 2009/9/2 Brian J. Mc Hugh bjmch...@aya.yale.edu Hi Stefanik, My wireless Broadcom control transmit problem occurs when my Gateway Solo 9300 experiences a hard sthudown, when it loses power. I think you instructed me to issue the following commands: sudo modprobe b43 btcoex=0 sudo /etc/init.d/networking restart -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Appreciate help
On Wed, Sep 2, 2009 at 11:57 PM, Brian J. Mc Hughbjmch...@aya.yale.edu wrote: Hi Gábor and Broadcom, In essense, my card seems to be receiving signal but transmitting none. I was appreciate your help, Thanks, Brian Here are the diagnostics; #uname -r 2.6.26-2-686 #dmesg | grep b43 [ 30.415512] b43-pci-bridge :02:00.0: enabling device ( - 0002) [ 32.618331] b43-phy0: Broadcom 4318 WLAN found [ 40.118466] input: b43-phy0 as /class/input/input6 [ 40.204186] firmware: requesting b43/ucode5.fw [ 40.493492] firmware: requesting b43/pcm5.fw [ 40.677031] firmware: requesting b43/b0g0initvals5.fw [ 40.763606] firmware: requesting b43/b0g0bsinitvals5.fw [ 41.036083] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [ 42.308852] Registered led device: b43-phy0::tx [ 42.308934] Registered led device: b43-phy0::rx [ 42.309022] Registered led device: b43-phy0::radio #lspci -vnn | grep 14e4 02:00.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02) #lspci -nnv | grep -A1 14e4 02:00.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02) Subsystem: Linksys WPC54G-EU version 3 [Wireless-G Notebook Adapter] [1737:0048] #iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:17:9A:52:34:2D ESSID:dlink Mode:Master Channel:11 Frequency:2.462 GHz (Channel 11) Quality=73/100 Signal level=-42 dBm Noise level=-63 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=0017b3fcb180 #ifdown wlan0 There is already a pid file /var/run/dhclient.wlan0.pid with pid 1949 killed old client process, removed PID file Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 wmaster0: unknown hardware address type 801 Listening on LPF/wlan0/00:18:f8:e2:1c:71 Sending on LPF/wlan0/00:18:f8:e2:1c:71 Sending on Socket/fallback #ifup wlan0 Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 wmaster0: unknown hardware address type 801 Listening on LPF/wlan0/00:18:f8:e2:1c:71 Sending on LPF/wlan0/00:18:f8:e2:1c:71 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18 No DHCPOFFERS received. No working leases in persistent database - sleeping. What's visible in dmesg after dhclient? Also, to rule out hardware failures - does the card work under Windows? (4318s break rather easily.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Appreciate help
2009/9/3 Brian J. Mc Hugh bjmch...@aya.yale.edu: I went in the file /var/log/dmesg and didn't find dhclient. Does that signify failure? You don't need to find dhclient in dmesg - the question is, what shows up in dmesg after ifup calls dhclient? About the Windows machine problem - try the Windows driver in ndiswrapper. 2009/9/2 Gábor Stefanik netrolller...@gmail.com On Wed, Sep 2, 2009 at 11:57 PM, Brian J. Mc Hughbjmch...@aya.yale.edu wrote: Hi Gábor and Broadcom, In essense, my card seems to be receiving signal but transmitting none. I was appreciate your help, Thanks, Brian Here are the diagnostics; #uname -r 2.6.26-2-686 #dmesg | grep b43 [ 30.415512] b43-pci-bridge :02:00.0: enabling device ( - 0002) [ 32.618331] b43-phy0: Broadcom 4318 WLAN found [ 40.118466] input: b43-phy0 as /class/input/input6 [ 40.204186] firmware: requesting b43/ucode5.fw [ 40.493492] firmware: requesting b43/pcm5.fw [ 40.677031] firmware: requesting b43/b0g0initvals5.fw [ 40.763606] firmware: requesting b43/b0g0bsinitvals5.fw [ 41.036083] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [ 42.308852] Registered led device: b43-phy0::tx [ 42.308934] Registered led device: b43-phy0::rx [ 42.309022] Registered led device: b43-phy0::radio #lspci -vnn | grep 14e4 02:00.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02) #lspci -nnv | grep -A1 14e4 02:00.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02) Subsystem: Linksys WPC54G-EU version 3 [Wireless-G Notebook Adapter] [1737:0048] #iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:17:9A:52:34:2D ESSID:dlink Mode:Master Channel:11 Frequency:2.462 GHz (Channel 11) Quality=73/100 Signal level=-42 dBm Noise level=-63 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=0017b3fcb180 #ifdown wlan0 There is already a pid file /var/run/dhclient.wlan0.pid with pid 1949 killed old client process, removed PID file Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 wmaster0: unknown hardware address type 801 Listening on LPF/wlan0/00:18:f8:e2:1c:71 Sending on LPF/wlan0/00:18:f8:e2:1c:71 Sending on Socket/fallback #ifup wlan0 Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 wmaster0: unknown hardware address type 801 Listening on LPF/wlan0/00:18:f8:e2:1c:71 Sending on LPF/wlan0/00:18:f8:e2:1c:71 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18 No DHCPOFFERS received. No working leases in persistent database - sleeping. What's visible in dmesg after dhclient? Also, to rule out hardware failures - does the card work under Windows? (4318s break rather easily.) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Is there a b43 dev who needs an N-PHY card?
On Thu, Sep 3, 2009 at 1:55 AM, Alex Elsayedeternal...@gmail.com wrote: I just recently got a new laptop with an Intel 5350, which means my 4328 [PCI-ID] (4321 official Broadcom designation) is not in use any longer. I am in the Seattle area, but can send it by post if needed. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev We are still not ready to actually start implementing N-PHY support (the specs are incomplete), so unless someone in the reverse-engineering team needs one, then probably noone will be able to use it at this point. However, it will be useful at a later time. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: same problem with card
On Thu, Sep 3, 2009 at 2:37 AM, Brian J. Mc Hughbjmch...@aya.yale.edu wrote: Hi Larry and Gabor, Here is the file. Sorry about contacting both of you independently Brian Hmm, this SPROM has the BT coexistence bit unset - in that case, BT is not the reason behind the bug. Do you know the exact kernel that introduced this bug? On Wed, Sep 2, 2009 at 7:08 PM, Larry Finger larry.fin...@lwfinger.net wrote: Brian J. Mc Hugh wrote: Hi Larry, I just did a clean install and have the same problem you help me solve before. DIdn't you recommend that I issue: sudo modprobe b43? I don't remember the circumstances; however, your driver b43 is already loaded and this command would do nothing. There is a possibility that your board suffers from a Bluetooth coexistence problem as does one other 4318. The only way to tell would be to rewrite the SPROM data. As I read the code, the btcoex module parameter does not accomplish the same thing. If you want to try that approach and are not using Bluetooth on that computer, do the following commands: SSB_SPROM=$(find /sys/devices -name ssb_sprom) echo $SSB_SPROM sudo cat $SSB_SPROM ssb_sprom_copy The echo command should list only a single line. If it does, E-mail me the file ssb_sprom_copy, and I will modify it and mail it back. BTW, I have been following the thread with Gabor. It is bad form to open a second interchange on the same problem. Larry -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: same problem with card
2009/9/3 Brian J. Mc Hugh bjmch...@aya.yale.edu: I use Debian. Etch was 2.18. Lenny is 2.26. But I did already issue the commands to disable the bluetooth, i.e., #sudo modprobe -rv b43 #sudo modprobe -v b43 btcoex=0 #sudo /etc/init.d/networking restart Unfortunately, I still don't have wireless. Brian Could you try compiling equivalent kernels from Kernel.org? Just so that we can rule out a Debian bug (e.g. in a distro-specific kernel patch). 2009/9/2 Gábor Stefanik netrolller...@gmail.com On Thu, Sep 3, 2009 at 2:37 AM, Brian J. Mc Hughbjmch...@aya.yale.edu wrote: Hi Larry and Gabor, Here is the file. Sorry about contacting both of you independently Brian Hmm, this SPROM has the BT coexistence bit unset - in that case, BT is not the reason behind the bug. Do you know the exact kernel that introduced this bug? On Wed, Sep 2, 2009 at 7:08 PM, Larry Finger larry.fin...@lwfinger.net wrote: Brian J. Mc Hugh wrote: Hi Larry, I just did a clean install and have the same problem you help me solve before. DIdn't you recommend that I issue: sudo modprobe b43? I don't remember the circumstances; however, your driver b43 is already loaded and this command would do nothing. There is a possibility that your board suffers from a Bluetooth coexistence problem as does one other 4318. The only way to tell would be to rewrite the SPROM data. As I read the code, the btcoex module parameter does not accomplish the same thing. If you want to try that approach and are not using Bluetooth on that computer, do the following commands: SSB_SPROM=$(find /sys/devices -name ssb_sprom) echo $SSB_SPROM sudo cat $SSB_SPROM ssb_sprom_copy The echo command should list only a single line. If it does, E-mail me the file ssb_sprom_copy, and I will modify it and mail it back. BTW, I have been following the thread with Gabor. It is bad form to open a second interchange on the same problem. Larry -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration software RFKILL support
On Mon, Aug 31, 2009 at 9:17 PM, Michael Bueschm...@bu3sch.de wrote:
On Monday 31 August 2009 19:53:31 John W. Linville wrote:
On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
static void lpphy_pr41573_workaround(struct b43_wldev *dev)
{
struct b43_phy_lp *lpphy = dev-phy.lp;
@@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct
b43_wldev *dev)
b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
saved_tab_size, saved_tab);
}
+ b43_put_phy_into_reset(dev);
Are you sure you really want this?
This function completely disables the PHY on the backplane and keeps
the physical
PHY reset pin asserted (even after return from the function).
So the PHY will physically be powered down from this point on. The
following
PHY accesses could even hang the machine, because the PHY won't
respond to
register accesses anymore.
We currently only use this function on A/G Multi-PHY devices to
permanently
hard-disable the PHY that's not used.
The PHY reset routine in
http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
for the latest N PHY changes, appears to be a different routine than
b43_put_phy_into_reset(). The names are confusing.
b43_put_phy_into_reset() is opencoded in the specifications in various init
routines. There's no separate specs page for that function.
But I think the code is straightforward and easy to understand.
So is this patch right or not? Should I hold onto it for 2.6.33
(i.e. after the 2.6.32 merge window)?
I'm pretty sure it's incorrect.
--
Greetings, Michael.
Do we have the correct reset routine implemented somewhere, or is it a
new routine to add?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Test message, please ignore.
I suspect that this will trigger a response from a spambot. reset ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: LP-PHY: Begin implementing calibration software RFKILL support
This implements the following calibration functions:
-Set TX IQCC
-Set TX Power by Index
-PR41573 workaround
-Calc RX IQ Comp
-PHY Cordic
-Run Samples
-Start/Stop TX Tone
-part of PAPD Cal TX Power
-RX I/Q Calibration
-The basic structure of the periodic calibration wrapper
Software RFKILL (required by calibration) is also implemented in
this round.
Signed-off-by: Gábor Stefanik netrolller...@gmail.com
---
Larry, please check if I got the math in PHY Cordic right!
drivers/net/wireless/b43/main.c |2 +-
drivers/net/wireless/b43/main.h |2 +
drivers/net/wireless/b43/phy_lp.c | 684 -
drivers/net/wireless/b43/phy_lp.h | 11 +-
4 files changed, 611 insertions(+), 88 deletions(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index f2c5b2d..59bee02 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -3345,7 +3345,7 @@ static void b43_op_set_tsf(struct ieee80211_hw *hw, u64
tsf)
mutex_unlock(wl-mutex);
}
-static void b43_put_phy_into_reset(struct b43_wldev *dev)
+void b43_put_phy_into_reset(struct b43_wldev *dev)
{
struct ssb_device *sdev = dev-dev;
u32 tmslow;
diff --git a/drivers/net/wireless/b43/main.h b/drivers/net/wireless/b43/main.h
index 0406e06..fdbea9a 100644
--- a/drivers/net/wireless/b43/main.h
+++ b/drivers/net/wireless/b43/main.h
@@ -129,6 +129,8 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32
flags);
void b43_controller_restart(struct b43_wldev *dev, const char *reason);
+void b43_put_phy_into_reset(struct b43_wldev *dev);
+
#define B43_PS_ENABLED (1 0)/* Force enable hardware power saving */
#define B43_PS_DISABLED(1 1)/* Force disable hardware power
saving */
#define B43_PS_AWAKE (1 2)/* Force device awake */
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 5fff30a..60e8f6f 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -67,6 +67,7 @@ static void b43_lpphy_op_prepare_structs(struct b43_wldev
*dev)
struct b43_phy_lp *lpphy = phy-lp;
memset(lpphy, 0, sizeof(*lpphy));
+ lpphy-antenna = B43_ANTENNA_DEFAULT;
//TODO
}
@@ -751,11 +752,17 @@ static void lpphy_clear_deaf(struct b43_wldev *dev, bool
user)
}
}
+static void lpphy_set_trsw_over(struct b43_wldev *dev, bool tx, bool rx)
+{
+ u16 trsw = (tx 1) | rx;
+ b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, trsw);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+}
+
static void lpphy_disable_crs(struct b43_wldev *dev, bool user)
{
lpphy_set_deaf(dev, user);
- b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, 0x1);
- b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+ lpphy_set_trsw_over(dev, false, true);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFB);
b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x4);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFF7);
@@ -790,6 +797,60 @@ static void lpphy_restore_crs(struct b43_wldev *dev, bool
user)
struct lpphy_tx_gains { u16 gm, pga, pad, dac; };
+static void lpphy_disable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFFE);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFEF);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFBF);
+ if (dev-phy.rev = 2) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFBFF);
+ b43_phy_mask(dev, B43_PHY_OFDM(0xE5), 0xFFF7);
+ }
+ } else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFDFF);
+ }
+}
+
+static void lpphy_enable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x1);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x10);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x40);
+ if (dev-phy.rev = 2) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x400);
+ b43_phy_set(dev, B43_PHY_OFDM(0xE5), 0x8);
+ }
+ } else {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x200);
+ }
+}
+
+static void lpphy_disable_tx_gain_override(struct b43_wldev *dev)
+{
+ if (dev-phy.rev 2)
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFF7F);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xBFFF);
+ }
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFBF);
+}
+
+static void
[PATCH v2] b43: LP-PHY: Begin implementing calibration software RFKILL support
This implements the following calibration functions:
-Set TX IQCC
-Set TX Power by Index
-PR41573 workaround
-Calc RX IQ Comp
-PHY Cordic
-Run Samples
-Start/Stop TX Tone
-part of PAPD Cal TX Power
-RX I/Q Calibration
-The basic structure of the periodic calibration wrapper
Software RFKILL (required by calibration) is also implemented in
this round.
Signed-off-by: Gábor Stefanik netrolller...@gmail.com
---
V2: Fix a mistake I made in the PHY Cordic routine.
drivers/net/wireless/b43/main.c |2 +-
drivers/net/wireless/b43/main.h |2 +
drivers/net/wireless/b43/phy_lp.c | 686 -
drivers/net/wireless/b43/phy_lp.h | 11 +-
4 files changed, 613 insertions(+), 88 deletions(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index f2c5b2d..59bee02 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -3345,7 +3345,7 @@ static void b43_op_set_tsf(struct ieee80211_hw *hw, u64
tsf)
mutex_unlock(wl-mutex);
}
-static void b43_put_phy_into_reset(struct b43_wldev *dev)
+void b43_put_phy_into_reset(struct b43_wldev *dev)
{
struct ssb_device *sdev = dev-dev;
u32 tmslow;
diff --git a/drivers/net/wireless/b43/main.h b/drivers/net/wireless/b43/main.h
index 0406e06..fdbea9a 100644
--- a/drivers/net/wireless/b43/main.h
+++ b/drivers/net/wireless/b43/main.h
@@ -129,6 +129,8 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32
flags);
void b43_controller_restart(struct b43_wldev *dev, const char *reason);
+void b43_put_phy_into_reset(struct b43_wldev *dev);
+
#define B43_PS_ENABLED (1 0)/* Force enable hardware power saving */
#define B43_PS_DISABLED(1 1)/* Force disable hardware power
saving */
#define B43_PS_AWAKE (1 2)/* Force device awake */
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 5fff30a..c13385b 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -67,6 +67,7 @@ static void b43_lpphy_op_prepare_structs(struct b43_wldev
*dev)
struct b43_phy_lp *lpphy = phy-lp;
memset(lpphy, 0, sizeof(*lpphy));
+ lpphy-antenna = B43_ANTENNA_DEFAULT;
//TODO
}
@@ -751,11 +752,17 @@ static void lpphy_clear_deaf(struct b43_wldev *dev, bool
user)
}
}
+static void lpphy_set_trsw_over(struct b43_wldev *dev, bool tx, bool rx)
+{
+ u16 trsw = (tx 1) | rx;
+ b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, trsw);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+}
+
static void lpphy_disable_crs(struct b43_wldev *dev, bool user)
{
lpphy_set_deaf(dev, user);
- b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, 0x1);
- b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
+ lpphy_set_trsw_over(dev, false, true);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFB);
b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x4);
b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFF7);
@@ -790,6 +797,60 @@ static void lpphy_restore_crs(struct b43_wldev *dev, bool
user)
struct lpphy_tx_gains { u16 gm, pga, pad, dac; };
+static void lpphy_disable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFFE);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFEF);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFBF);
+ if (dev-phy.rev = 2) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFBFF);
+ b43_phy_mask(dev, B43_PHY_OFDM(0xE5), 0xFFF7);
+ }
+ } else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFDFF);
+ }
+}
+
+static void lpphy_enable_rx_gain_override(struct b43_wldev *dev)
+{
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x1);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x10);
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x40);
+ if (dev-phy.rev = 2) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x400);
+ b43_phy_set(dev, B43_PHY_OFDM(0xE5), 0x8);
+ }
+ } else {
+ b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x200);
+ }
+}
+
+static void lpphy_disable_tx_gain_override(struct b43_wldev *dev)
+{
+ if (dev-phy.rev 2)
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
+ else {
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFF7F);
+ b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xBFFF);
+ }
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFBF);
+}
+
+static void
[PATCH] b43: Refactor and update antenna diversity for A/G-PHY
-Make use of the b43_phy_set/mask/maskset helpers.
-Fix a few errors in the code.
-Make the code more readable.
Signed-off-by: Gábor Stefanik netrolller...@gmail.com
---
The phy-analog == 3 to phy-rev == 3 change in A-PHY is intentional,
it's a bugfix/spec conformance fix.
drivers/net/wireless/b43/phy_a.c | 48 ++--
drivers/net/wireless/b43/phy_g.c | 55 +++--
2 files changed, 37 insertions(+), 66 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_a.c b/drivers/net/wireless/b43/phy_a.c
index 809ec97..d90217c 100644
--- a/drivers/net/wireless/b43/phy_a.c
+++ b/drivers/net/wireless/b43/phy_a.c
@@ -518,58 +518,40 @@ static unsigned int b43_aphy_op_get_default_chan(struct
b43_wldev *dev)
static void b43_aphy_op_set_rx_antenna(struct b43_wldev *dev, int antenna)
{//TODO
struct b43_phy *phy = dev-phy;
- u64 hf;
u16 tmp;
int autodiv = 0;
if (antenna == B43_ANTENNA_AUTO0 || antenna == B43_ANTENNA_AUTO1)
autodiv = 1;
- hf = b43_hf_read(dev);
- hf = ~B43_HF_ANTDIVHELP;
- b43_hf_write(dev, hf);
+ b43_hf_write(dev, b43_hf_read(dev) ~B43_HF_ANTDIVHELP);
- tmp = b43_phy_read(dev, B43_PHY_BBANDCFG);
- tmp = ~B43_PHY_BBANDCFG_RXANT;
- tmp |= (autodiv ? B43_ANTENNA_AUTO1 : antenna)
-B43_PHY_BBANDCFG_RXANT_SHIFT;
- b43_phy_write(dev, B43_PHY_BBANDCFG, tmp);
+ b43_phy_maskset(dev, B43_PHY_BBANDCFG, ~B43_PHY_BBANDCFG_RXANT,
+ (autodiv ? B43_ANTENNA_AUTO1 : antenna)
+ B43_PHY_BBANDCFG_RXANT_SHIFT);
if (autodiv) {
tmp = b43_phy_read(dev, B43_PHY_ANTDWELL);
- if (antenna == B43_ANTENNA_AUTO0)
+ if (antenna == B43_ANTENNA_AUTO1)
tmp = ~B43_PHY_ANTDWELL_AUTODIV1;
else
tmp |= B43_PHY_ANTDWELL_AUTODIV1;
b43_phy_write(dev, B43_PHY_ANTDWELL, tmp);
}
- if (phy-rev 3) {
- tmp = b43_phy_read(dev, B43_PHY_ANTDWELL);
- tmp = (tmp 0xFF00) | 0x24;
- b43_phy_write(dev, B43_PHY_ANTDWELL, tmp);
- } else {
- tmp = b43_phy_read(dev, B43_PHY_OFDM61);
- tmp |= 0x10;
- b43_phy_write(dev, B43_PHY_OFDM61, tmp);
- if (phy-analog == 3) {
- b43_phy_write(dev, B43_PHY_CLIPPWRDOWNT,
- 0x1D);
- b43_phy_write(dev, B43_PHY_ADIVRELATED,
- 8);
+ if (phy-rev 3)
+ b43_phy_maskset(dev, B43_PHY_ANTDWELL, 0xFF00, 0x24);
+ else {
+ b43_phy_set(dev, B43_PHY_OFDM61, 0x10);
+ if (phy-rev == 3) {
+ b43_phy_write(dev, B43_PHY_CLIPPWRDOWNT, 0x1D);
+ b43_phy_write(dev, B43_PHY_ADIVRELATED, 8);
} else {
- b43_phy_write(dev, B43_PHY_CLIPPWRDOWNT,
- 0x3A);
- tmp =
- b43_phy_read(dev,
-B43_PHY_ADIVRELATED);
- tmp = (tmp 0xFF00) | 8;
- b43_phy_write(dev, B43_PHY_ADIVRELATED,
- tmp);
+ b43_phy_write(dev, B43_PHY_CLIPPWRDOWNT, 0x3A);
+ b43_phy_maskset(dev, B43_PHY_ADIVRELATED, 0xFF00, 8);
}
}
- hf |= B43_HF_ANTDIVHELP;
- b43_hf_write(dev, hf);
+ b43_hf_write(dev, b43_hf_read(dev) | B43_HF_ANTDIVHELP);
}
static void b43_aphy_op_adjust_txpower(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/b43/phy_g.c b/drivers/net/wireless/b43/phy_g.c
index c6d639d..4b6154b 100644
--- a/drivers/net/wireless/b43/phy_g.c
+++ b/drivers/net/wireless/b43/phy_g.c
@@ -2638,65 +2638,54 @@ static unsigned int b43_gphy_op_get_default_chan(struct
b43_wldev *dev)
static void b43_gphy_op_set_rx_antenna(struct b43_wldev *dev, int antenna)
{
struct b43_phy *phy = dev-phy;
- u64 hf;
u16 tmp;
int autodiv = 0;
if (antenna == B43_ANTENNA_AUTO0 || antenna == B43_ANTENNA_AUTO1)
autodiv = 1;
- hf = b43_hf_read(dev);
- hf = ~B43_HF_ANTDIVHELP;
- b43_hf_write(dev, hf);
-
- tmp = b43_phy_read(dev, B43_PHY_BBANDCFG);
- tmp = ~B43_PHY_BBANDCFG_RXANT;
- tmp |= (autodiv ? B43_ANTENNA_AUTO1 : antenna)
-B43_PHY_BBANDCFG_RXANT_SHIFT;
- b43_phy_write(dev, B43_PHY_BBANDCFG, tmp);
+ b43_hf_write(dev, b43_hf_read(dev) ~B43_HF_ANTDIVHELP);
+ b43_phy_maskset(dev, B43_PHY_BBANDCFG, ~B43_PHY_BBANDCFG_RXANT,
+ (autodiv ? B43_ANTENNA_AUTO1 : antenna)
+ B43_PHY_BBANDCFG_RXANT_SHIFT
