Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Understood. Files attached. This time I set the channel so that bcm43xx_mac80211(noworkie) would associate with the same AP that bcm43xx_mac80211(workie) does. For infrastructure reference there are two APs on the LAN, and one has a WDS with a third AP. All are Buffalo Airstations 54G. All work fine with bcm43xx & ndiswrapper with bcmwl5. See attached. Ehud Larry Finger wrote: Ehud Gavron wrote: good: rc1 "git test" tree with the commit in question reversed. Works fine. bad: rc2 "git wireless-dev" tree with Michael's latest patch. Does not work. full dmesg, iwconfig, and ifconfigs included. Like I said, I am happy to do this all day long so that I don't have to personally revert that long patch. With xconfig, select the "Kernel hacking" section, and turn off the "Show timing info on printks". In addition, turn off "Kobject debugging" in that section. The latter option generates a lot of messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make modules_install install'. You do not need to clean out the object files, or any other make options. Boot that kernel and send me it's dmesg. One further question - Are you trying to connect to the same AP in both cases? The reason I'm asking is that the MAC address of the AP is different for the two cases. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev Linux version 2.6.23-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #2 SMP Wed Aug 8 20:36:34 MST 2007 Command line: ro root=LABEL=/ rhgb quiet BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 7fe81400 (usable) BIOS-e820: 7fe81400 - 7ff0 (reserved) BIOS-e820: f000 - f4007000 (reserved) BIOS-e820: f4008000 - f400c000 (reserved) BIOS-e820: fed2 - feda (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 523905) 1 entries of 3200 used end_pfn_map = 1043872 DMI 2.4 present. ACPI: RSDP 000FC0B0, 0014 (r0 DELL ) ACPI: RSDT 7FE8198A, 0044 (r1 DELLM07 27D60A0D ASL61) ACPI: FACP 7FE82800, 0074 (r1 DELLM07 27D60A0D ASL61) ACPI: DSDT 7FE83400, 4D7D (r1 INT430 SYSFexxx 1001 INTL 20050624) ACPI: FACS 7FE91C00, 0040 ACPI: HPET 7FE82F00, 0038 (r1 DELLM071 ASL61) ACPI: APIC 7FE83000, 0068 (r1 DELLM07 27D60A0D ASL47) ACPI: ASF! 7FE82C00, 005B (r16 DELLM07 27D60A0D ASL61) ACPI: MCFG 7FE82FC0, 003E (r16 DELLM07 27D60A0D ASL61) ACPI: SLIC 7FE8309C, 0176 (r1 DELLM07 27D60A0D ASL61) ACPI: TCPA 7FE83300, 0032 (r1 DELLM07 27D60A0D ASL61) ACPI: SSDT 7FE81A11, 04DC (r1 PmRefCpuPm 3000 INTL 20050624) No NUMA configuration found Faking a node at -7fe81000 Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 523905) 1 entries of 3200 used Bootmem setup node 0 -7fe81000 No mptable found. Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 523905 On node 0 totalpages: 523808 DMA zone: 96 pages used for memmap DMA zone: 2524 pages reserved DMA zone: 1379 pages, LIFO batch:0 DMA32 zone: 12183 pages used for memmap DMA32 zone: 507626 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:7010) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 435320 bytes of per cpu data Built 1 zonelists in Node order. Total pages: 509005 Policy zone: DMA32 Kernel command line: ro root=LABEL=/ rhgb quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Marking TSC unstable due to TSCs unsynchronized time.c:
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Ehud Gavron wrote: > good: rc1 "git test" tree with the commit in question reversed. Works fine. > bad: rc2 "git wireless-dev" tree with Michael's latest patch. Does not > work. > > full dmesg, iwconfig, and ifconfigs included. > > Like I said, I am happy to do this all day long so that I don't have to > personally revert that long patch. With xconfig, select the "Kernel hacking" section, and turn off the "Show timing info on printks". In addition, turn off "Kobject debugging" in that section. The latter option generates a lot of messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make modules_install install'. You do not need to clean out the object files, or any other make options. Boot that kernel and send me it's dmesg. One further question - Are you trying to connect to the same AP in both cases? The reason I'm asking is that the MAC address of the AP is different for the two cases. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Ehud, I was just reviewing the complete dmesg output that you sent earlier, which I think was for a "bad" case. I use WPA encryption, which cannot be done in hardware, and I have not seen messages that look like this: bcm43xx-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff eth1: Initial auth_alg=0 eth1: authenticate with AP 00:0d:88:ac:b2:2a eth1: RX authentication from 00:0d:88:ac:b2:2a (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:0d:88:ac:b2:2a eth1: RX AssocResp from 00:0d:88:ac:b2:2a (capab=0x431 status=0 aid=1) eth1: associated eth1: switched to short barker preamble (BSSID=00:0d:88:ac:b2:2a) ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready In particular, I mean the "hardware based encryption", and the "short barker preamble" messages. Please boot a "good" kernel and save the dmesg output. Do the same for a "bad" kernel. Send the two sets of dmesg output, and iwconfig and ifconfig output for the bad one. In the meantime, I'll configure my spare AP for WEP encryption and see what I get in my logs. Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 works with fedora 7 but only at 1mb/s
John H. wrote: > I am using larry's .bz2 of bcm43xx and I get this ... > > wlan0 IEEE 802.11b/g ESSID:"Network4Home" Nickname:"Broadcom 4311" > Mode:Managed Frequency=2.437 GHz Access Point:blah > Bit Rate=24 Mb/s Tx-Power=18 dBm > RTS thr:off Fragment thr:off > Link Quality=50/100 Signal level=-69 dBm Noise level=-71 dBm > Rx invalid nwid:0 Rx invalid crypt:11 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > Is it possible to get 54mb/s? Should I care if it's mainly for > residential cable modem right now? To get a setting of 54M, look at 'man iwconfig'. To get throughput at 54M, you need a different driver, and much better signal to noise! The highest residential cable rates in my area are 8Mbs down and 512Kbs up. Business rates ate 10 Mbs down and 2 Mbs up, but that costs a lot more. Your 24M setting should give you something in the range of 12Mbs throughput. You do the math. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Pavel Roskin wrote: > On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote: > >> The spec is telling us to lookup an invalid index in the LO table. > > I see. Thanks for your explanation! > > I think the way to solve it would be to see how the table is used in the > proprietary driver. Either the data from the extra entries is used, and > we need to find out where it comes from, or there is an algorithm to > limit the index to only access valid entries. > > I hope the reverse engineering team knows that. I wish them good luck. > Oh, we're aware of the problem. It's like I said before, it's one of the most complex parts of the driver and it's tough to document properly without just copying code to the documentation. We'll get to it, but my time is kind of limited right now. Sorry, -Joe ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
They were *ALL* enabled, even the modules for testing that I didn't load. They're still there in the built kernel... so if you want something from it, I can easily reboot into it and get it. From another message: n IRC was suggested that this might be a compiler bug generating corrupt code. Which compiler do you use? Can you upgrade or downgrade? [EMAIL PROTECTED] Download]# cc --version cc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I use Yum with F7 Repos, but yes, if need be I can erase the RPM and install another. Ehud Michael Buesch wrote: On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote: It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n. What about enabling the Kernel Hacking options I suggested? smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 works with fedora 7 but only at 1mb/s
I am using larry's .bz2 of bcm43xx and I get this ... wlan0 IEEE 802.11b/g ESSID:"Network4Home" Nickname:"Broadcom 4311" Mode:Managed Frequency=2.437 GHz Access Point:blah Bit Rate=24 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Link Quality=50/100 Signal level=-69 dBm Noise level=-71 dBm Rx invalid nwid:0 Rx invalid crypt:11 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Is it possible to get 54mb/s? Should I care if it's mainly for residential cable modem right now? On 8/8/07, John W. Linville <[EMAIL PROTECTED]> wrote: > On Tue, Aug 07, 2007 at 07:57:03PM -0500, Larry Finger wrote: > > John H. wrote: > > > Did I misunderstand something? I thought some script was available or > > > some easy way to use either bcm43xx or the new one. brennan says he > > > has a script to just let you use the newer driver with higher mbps, > > > but I have never heard back from him. > > > > > > > I have no idea what he is/was talking about. Until late yesterday, the best > > performance was with the > > unaltered bcm43xx, or the port of that driver to mac80211. Today, the > > changes now propagating > > through the system make bcm43xx-mac80211 into the preferred driver. You > > should ask Fedora how soon > > those will make it into their development kernels (called Rawhide?). > > Probably tonight. Maybe earlier if you watch Koji. > > John > -- > John W. Linville > [EMAIL PROTECTED] > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote: > On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote: > > It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n. > > What about enabling the Kernel Hacking options I suggested? On IRC was suggested that this might be a compiler bug generating corrupt code. Which compiler do you use? Can you upgrade or downgrade? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote: > On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote: > > It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n. > > What about enabling the Kernel Hacking options I suggested? On IRC was suggested that this might be a compiler bug generating corrupt code. Which compiler do you use? Can you upgrade or downgrade? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote: > It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n. What about enabling the Kernel Hacking options I suggested? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n. Ehud Michael Buesch wrote: On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote: Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) [EMAIL PROTECTED] test]# patch -p1 < ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] John just pushed the IRQ patch upstream. Please try my patch that I just sent. This one: http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote: > On Monday 06 August 2007 03:21:11 you wrote: >> Richard Jonsson wrote: >>> Isn't Desired TX power supposed to adapt so that higher bitrates are >>> possible, with Bit Rate going lower if that is not enough to keep a good >>> connection? >> Richard, >> >> Please grab a new copy of the port_to_mac80211 patch, and try the patch >> below. It boosts the desired power by up to 5 dBm as signal - noise >> decreases from 20 to 0. >> >> Larry > > Hard to say if there is a difference. I've noticed that signal quality > changes > between reboots. When I first tried this patch I couldn't get above 36M even > at the AP, so I loaded the version without the patch. Same thing. > So I rebooted and then all rates worked, even 11M. Even for the driver > version > that didn't work a few days ago. That is scary! That may mean that something is not being reset. The real question is whether warm reboots are intrinsically different than cold (power-off) reboots. > New/updated observations: > Rate scaling seems to work, but if it gets down to 1M it will not rise again > unless I force it to a higher bitrate and run iperf for a few seconds before > setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I > get a feeling it's a bit to sensitive as it will drop quickly at a few meters > away. At this distance forced 54M still works well. > Maybe this is due to small dips (0.5sec) in traffic flow?! I'm surprised that you get signal values as high as -5 dBm. My maximum is about -35. I'm usually in the -40 range, even at 2 m from the AP. > With the patch applied power is reported as 27dB in debugfs. With > debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This > is max when I manually set power through debugfs. After a while it's down to > 10dB, even though only 1M works where I sit. > > Range seems to be higher for B-rates. Maybe this is just how things are, I > lack experience. The CCCK (B) encoding is much different than OFDM (G) transmissions. I would not be surprised to learn that its range were longer. The power setting that comes from mac80211 is 27 dBm, which is completely bogus for what is supposed to be the FCC table. The regulatory limit is 20 dBm EIRP (a fancy acronym that means take the antenna into account). I've sent a fix for comment, but as is the usual case for mac80211, it will take several days or weeks to get a response. The maximum power that a bcm43xx device can use is encoded in the sprom. For most of them that quantity is 18.5 dBm, corresponding to the regulatory limit of 20 minus a safety factor of 1.5. I think that is there to prevent setting the power too high and flunking the certification tests. The output that goes to the radio is thus 18.5 less the gain of the antenna, which is also in the sprom with a usual value of 2 dBm. That is why you see the code setting a Desired power of 16.5 dBm. Initially, I thought that the performance of my BCM4311 fell off as the power increased; however, that no longer happens. As a result, we can push full power at all times and there seems to be no need to use the kind of algorithm that you were testing. Don't tell the FCC, but we could relax that upper power limit as we will never try to get the device certified, but then we would use extra power, and run the risk of burning out the radio. If you decide to do that, please tell me the power setting at which it fried! With the patches that were pushed into wireless-dev a few minutes ago, I suggest that you try bcm43xx-mac80211. It is getting at least as good, if not better, performance than the BCM4301 or the softmac port to mac80211 drivers do. We would also appreciate as much testing as possible as it will help getting it merged into mainstream. That driver will require V4 firmware. Thanks for your report, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 7/9] bcm43xx-mac80211: Remove power.c
power.c is not needed anymore. Move the only function
included in power.c into main.c.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/Makefile
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/Makefile
2007-08-08 22:09:47.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/Makefile 2007-08-08
22:17:24.0 +0200
@@ -10,7 +10,6 @@ bcm43xx-mac80211-obj-$(CONFIG_BCM43XX_MA
bcm43xx-mac80211-objs := bcm43xx_main.o \
bcm43xx_tables.o \
bcm43xx_phy.o \
-bcm43xx_power.o \
bcm43xx_sysfs.o \
bcm43xx_leds.o \
bcm43xx_xmit.o \
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-08 22:17:10.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-08 22:17:24.0 +0200
@@ -31,7 +31,6 @@
#include "bcm43xx_dma.h"
#include "bcm43xx_main.h"
#include "bcm43xx_debugfs.h"
-#include "bcm43xx_power.h"
#include "bcm43xx_xmit.h"
#include
@@ -1499,7 +1498,7 @@ static void bcm43xx_dma_tx_resume_ring(s
void bcm43xx_dma_tx_suspend(struct bcm43xx_wldev *dev)
{
- bcm43xx_power_saving_ctl_bits(dev, -1, 1);
+ bcm43xx_power_saving_ctl_bits(dev, BCM43xx_PS_AWAKE);
bcm43xx_dma_tx_suspend_ring(dev->dma.tx_ring0);
bcm43xx_dma_tx_suspend_ring(dev->dma.tx_ring1);
bcm43xx_dma_tx_suspend_ring(dev->dma.tx_ring2);
@@ -1516,5 +1515,5 @@ void bcm43xx_dma_tx_resume(struct bcm43x
bcm43xx_dma_tx_resume_ring(dev->dma.tx_ring2);
bcm43xx_dma_tx_resume_ring(dev->dma.tx_ring1);
bcm43xx_dma_tx_resume_ring(dev->dma.tx_ring0);
- bcm43xx_power_saving_ctl_bits(dev, -1, -1);
+ bcm43xx_power_saving_ctl_bits(dev, 0);
}
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
2007-08-08 22:17:20.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
2007-08-08 22:17:24.0 +0200
@@ -46,7 +46,6 @@
#include "bcm43xx_phy.h"
#include "bcm43xx_dma.h"
#include "bcm43xx_pio.h"
-#include "bcm43xx_power.h"
#include "bcm43xx_sysfs.h"
#include "bcm43xx_xmit.h"
#include "bcm43xx_sysfs.h"
@@ -874,6 +873,66 @@ static void bcm43xx_clear_keys(struct bc
}
}
+void bcm43xx_power_saving_ctl_bits(struct bcm43xx_wldev *dev,
+ unsigned int ps_flags)
+{
+ u32 macctl;
+ u16 ucstat;
+ bool hwps;
+ bool awake;
+ int i;
+
+ BCM43xx_WARN_ON((ps_flags & BCM43xx_PS_ENABLED) &&
+ (ps_flags & BCM43xx_PS_DISABLED));
+ BCM43xx_WARN_ON((ps_flags & BCM43xx_PS_AWAKE) &&
+ (ps_flags & BCM43xx_PS_ASLEEP));
+
+ if (ps_flags & BCM43xx_PS_ENABLED) {
+ hwps = 1;
+ } else if (ps_flags & BCM43xx_PS_DISABLED) {
+ hwps = 0;
+ } else {
+ //TODO: If powersave is not off and FIXME is not set and we are
not in adhoc
+ // and thus is not an AP and we are associated, set bit 25
+ }
+ if (ps_flags & BCM43xx_PS_AWAKE) {
+ awake = 1;
+ } else if (ps_flags & BCM43xx_PS_ASLEEP) {
+ awake = 0;
+ } else {
+ //TODO: If the device is awake or this is an AP, or we are
scanning, or FIXME,
+ // or we are associated, or FIXME, or the latest PS-Poll
packet sent was
+ // successful, set bit26
+ }
+
+/* FIXME: For now we force awake-on and hwps-off */
+hwps = 0;
+awake = 1;
+
+ macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+ if (hwps)
+ macctl |= BCM43xx_MACCTL_HWPS;
+ else
+ macctl &= ~BCM43xx_MACCTL_HWPS;
+ if (awake)
+ macctl |= BCM43xx_MACCTL_AWAKE;
+ else
+ macctl &= ~BCM43xx_MACCTL_AWAKE;
+ bcm43xx_write32(dev, BCM43xx_MMIO_MACCTL, macctl);
+ /* Commit write */
+ bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+ if (awake && dev->dev->id.revision >= 5) {
+ /* Wait for the microcode to wake up. */
+ for (i = 0; i < 100; i++) {
+ ucstat = bcm43xx_shm_read16(dev, BCM43xx_SHM_SHARED,
+ BCM43xx_SHM_SH_UCODESTAT);
+ if (ucstat != BCM43xx_SHM_SH_UCODESTAT_SLEEP)
+ break;
+ udelay(10);
+ }
+ }
+}
+
/*
[patch 9/9] bcm43xx-mac80211: Fix uninit-var warnings in lo.c
Fix uninitialized-var warnings in lo.c
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
2007-08-08 22:32:08.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
2007-08-08 22:32:43.0 +0200
@@ -1028,7 +1028,7 @@ static inline void validate_all_loctls(s
void bcm43xx_lo_g_measure(struct bcm43xx_wldev *dev)
{
struct bcm43xx_phy *phy = &dev->phy;
- struct lo_g_saved_values sav;
+ struct lo_g_saved_values uninitialized_var(sav);
BCM43xx_WARN_ON((phy->type != BCM43xx_PHYTYPE_B) &&
(phy->type != BCM43xx_PHYTYPE_G));
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 3/9] bcm43xx-mac80211: Add more help text for firmware failure
People won't read it, but hey. Let's do our best :) Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 22:11:25.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 22:17:06.0 +0200 @@ -1679,6 +1679,9 @@ static int bcm43xx_request_firmware(stru out: return err; error: + bcmerr(dev->wl, "You must go to " + "http://linuxwireless.org/en/users/Drivers/bcm43xx#devicefirmware " + "and download the correct firmware (version 4)\n"); bcm43xx_release_firmware(dev); goto out; err_noinitval: -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 5/9] ssb: Remove verbose coreswitch printk
To: Andrew Morton <[EMAIL PROTECTED]>
This makes the verbose printk on every coreswitch dependent
on a default-off debugging variable.
Verbose coreswitch messages are only needed when debugging
strange crashes or machine check exceptions.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/ssb/pci.c
===
--- wireless-dev.orig/drivers/ssb/pci.c 2007-08-08 22:09:48.0 +0200
+++ wireless-dev/drivers/ssb/pci.c 2007-08-08 22:17:16.0 +0200
@@ -23,6 +23,10 @@
#include "ssb_private.h"
+/* Define the following to 1 to enable a printk on each coreswitch. */
+#define SSB_VERBOSE_PCICORESWITCH_DEBUG0
+
+
/* Lowlevel coreswitching */
int ssb_pci_switch_coreidx(struct ssb_bus *bus, u8 coreidx)
{
@@ -61,10 +65,12 @@ int ssb_pci_switch_core(struct ssb_bus *
int err;
unsigned long flags;
- ssb_dprintk(KERN_INFO PFX
- "Switching to %s core, index %d\n",
- ssb_core_name(dev->id.coreid),
- dev->core_index);
+#if SSB_VERBOSE_PCICORESWITCH_DEBUG
+ ssb_printk(KERN_INFO PFX
+ "Switching to %s core, index %d\n",
+ ssb_core_name(dev->id.coreid),
+ dev->core_index);
+#endif
spin_lock_irqsave(&bus->bar_lock, flags);
err = ssb_pci_switch_coreidx(bus, dev->core_index);
Index: wireless-dev/drivers/ssb/pcmcia.c
===
--- wireless-dev.orig/drivers/ssb/pcmcia.c 2007-08-08 22:09:48.0
+0200
+++ wireless-dev/drivers/ssb/pcmcia.c 2007-08-08 22:17:16.0 +0200
@@ -21,6 +21,10 @@
#include "ssb_private.h"
+/* Define the following to 1 to enable a printk on each coreswitch. */
+#define SSB_VERBOSE_PCMCIACORESWITCH_DEBUG 0
+
+
int ssb_pcmcia_switch_coreidx(struct ssb_bus *bus,
u8 coreidx)
{
@@ -91,10 +95,12 @@ int ssb_pcmcia_switch_core(struct ssb_bu
int err;
unsigned long flags;
- ssb_dprintk(KERN_INFO PFX
- "Switching to %s core, index %d\n",
- ssb_core_name(dev->id.coreid),
- dev->core_index);
+#if SSB_VERBOSE_PCMCIACORESWITCH_DEBUG
+ ssb_printk(KERN_INFO PFX
+ "Switching to %s core, index %d\n",
+ ssb_core_name(dev->id.coreid),
+ dev->core_index);
+#endif
spin_lock_irqsave(&bus->bar_lock, flags);
err = ssb_pcmcia_switch_coreidx(bus, dev->core_index);
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 6/9] bcm43xx-mac80211: Remove unneeded stuff from bcm43xx.h
Cleanup.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:17:10.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:17:20.0 +0200
@@ -1,20 +1,11 @@
#ifndef BCM43xx_H_
#define BCM43xx_H_
-#include
#include
#include
#include
-#include
-#include
-#include
-#include
-#include
-
+#include
#include
-#include
-
-#include
#include
#include "bcm43xx_debugfs.h"
@@ -30,10 +21,6 @@
#endif
-#define BCM43xx_IRQWAIT_MAX_RETRIES50
-
-#define BCM43xx_IO_SIZE8192
-
#define BCM43xx_RX_MAX_SSI 60
/* MMIO offsets */
@@ -50,7 +37,6 @@
#define BCM43xx_MMIO_DMA5_REASON 0x48
#define BCM43xx_MMIO_DMA5_IRQ_MASK 0x4C
#define BCM43xx_MMIO_MACCTL0x120
-#define BCM43xx_MMIO_STATUS_BITFIELD 0x120//TODO replace all instances by
MACCTL
#define BCM43xx_MMIO_STATUS2_BITFIELD 0x124
#define BCM43xx_MMIO_GEN_IRQ_REASON0x128
#define BCM43xx_MMIO_GEN_IRQ_MASK 0x12C
@@ -336,25 +322,6 @@ enum {
#define BCM43xx_MACCTL_DISCPMQ 0x4000 /* Discard Power Management
Queue */
#define BCM43xx_MACCTL_GMODE 0x8000 /* G Mode */
-/* StatusBitField *///FIXME rename these all
-#define BCM43xx_SBF_MAC_ENABLED0x0001
-#define BCM43xx_SBF_2 0x0002 /*FIXME: fix name*/
-#define BCM43xx_SBF_CORE_READY 0x0004
-#define BCM43xx_SBF_4000x0400 /*FIXME: fix name*/
-#define BCM43xx_SBF_4000 0x4000 /*FIXME: fix name*/
-#define BCM43xx_SBF_8000 0x8000 /*FIXME: fix name*/
-#define BCM43xx_SBF_XFER_REG_BYTESWAP 0x0001
-#define BCM43xx_SBF_MODE_NOTADHOC 0x0002
-#define BCM43xx_SBF_MODE_AP0x0004
-#define BCM43xx_SBF_RADIOREG_LOCK 0x0008
-#define BCM43xx_SBF_MODE_MONITOR 0x0040
-#define BCM43xx_SBF_MODE_PROMISC 0x0100
-#define BCM43xx_SBF_PS10x0200
-#define BCM43xx_SBF_PS20x0400
-#define BCM43xx_SBF_NO_SSID_BCAST 0x0800
-#define BCM43xx_SBF_TIME_UPDATE0x1000
-#define BCM43xx_SBF_8000 0x8000 /*FIXME: fix name*/
-
/* 802.11 core specific TM State Low flags */
#define BCM43xx_TMSLOW_GMODE 0x2000 /* G Mode Enable */
#define BCM43xx_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency Reference
Select */
@@ -441,8 +408,6 @@ enum {
};
-struct net_device;
-struct pci_dev;
struct bcm43xx_dmaring;
struct bcm43xx_pioqueue;
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
2007-08-08 22:17:10.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
2007-08-08 22:17:20.0 +0200
@@ -263,12 +263,12 @@ void bcmdbg(struct bcm43xx_wl *wl, const
static void bcm43xx_ram_write(struct bcm43xx_wldev *dev, u16 offset, u32 val)
{
- u32 status;
+ u32 macctl;
BCM43xx_WARN_ON(offset % 4 != 0);
- status = bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
- if (status & BCM43xx_SBF_XFER_REG_BYTESWAP)
+ macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+ if (macctl & BCM43xx_MACCTL_BE)
val = swab32(val);
bcm43xx_write32(dev, BCM43xx_MMIO_RAM_CONTROL, offset);
@@ -462,21 +462,24 @@ void bcm43xx_tsf_read(struct bcm43xx_wld
static void bcm43xx_time_lock(struct bcm43xx_wldev *dev)
{
- u32 status;
+ u32 macctl;
- status = bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
- status |= BCM43xx_SBF_TIME_UPDATE;
- bcm43xx_write32(dev, BCM43xx_MMIO_STATUS_BITFIELD, status);
- mmiowb();
+ macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+ macctl |= BCM43xx_MACCTL_TBTTHOLD;
+ bcm43xx_write32(dev, BCM43xx_MMIO_MACCTL, macctl);
+ /* Commit the write */
+ bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
}
static void bcm43xx_time_unlock(struct bcm43xx_wldev *dev)
{
- u32 status;
+ u32 macctl;
- status = bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
- status &= ~BCM43xx_SBF_TIME_UPDATE;
- bcm43xx_write32(dev, BCM43xx_MMIO_STATUS_BITFIELD, status);
+ macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+ macctl &= ~BCM43xx_MACCTL_TBTTHOLD;
+ bcm43xx_write32(dev, BCM43xx_MMIO_MACCTL, macctl);
+ /* Commit the write */
+ bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
}
static void bcm43xx_tsf_write_locked(struct bcm43xx_wldev *dev, u64 tsf)
@@ -674,7 +677,8 @@ void bcm43xx_dummy_transmission(
[patch 4/9] bcm43xx-mac80211: Remove assert() define and use WARN_ON()
Remove our own assert() definition and use the standard kernel WARN_ON().
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:16:56.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:17:10.0 +0200
@@ -23,6 +23,13 @@
#include "bcm43xx_phy.h"
+#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
+# define BCM43xx_DEBUG 1
+#else
+# define BCM43xx_DEBUG 0
+#endif
+
+
#define BCM43xx_IRQWAIT_MAX_RETRIES50
#define BCM43xx_IO_SIZE8192
@@ -434,25 +441,6 @@ enum {
};
-#ifdef assert
-# undef assert
-#endif
-#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
-# define assert(expr) \
- do {\
- if (unlikely(!(expr))) {\
- printk(KERN_ERR KBUILD_MODNAME ": " \
- "ASSERTION FAILED (%s) at: %s:%d:%s()\n",\
- #expr, __FILE__, __LINE__, __FUNCTION__); \
- } \
- } while (0)
-# define BCM43xx_DEBUG 1
-#else
-# define assert(expr) do { /* nothing */ } while (0)
-# define BCM43xx_DEBUG 0
-#endif
-
-
struct net_device;
struct pci_dev;
struct bcm43xx_dmaring;
@@ -853,6 +841,15 @@ void bcmdbg(struct bcm43xx_wl *wl, const
# define bcmdbg(wl, fmt...) do { /* nothing */ } while (0)
#endif /* DEBUG */
+/* A WARN_ON variant that vanishes when bcm43xx debugging is disabled.
+ * This _also_ evaluates the arg with debugging disabled. */
+#if BCM43xx_DEBUG
+# define BCM43xx_WARN_ON(x)WARN_ON(x)
+#else
+static inline bool __bcm43xx_warn_on_dummy(bool x) { return x; }
+# define BCM43xx_WARN_ON(x)__bcm43xx_warn_on_dummy(unlikely(!!(x)))
+#endif
+
/** Limit a value between two limits */
#ifdef limit_value
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
2007-08-08 22:17:03.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
2007-08-08 22:17:10.0 +0200
@@ -448,7 +448,7 @@ void bcm43xx_debugfs_add_device(struct b
struct bcm43xx_txstatus_log *log;
char devdir[16];
- assert(dev);
+ BCM43xx_WARN_ON(!dev);
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
bcmerr(dev->wl, "debugfs: add device OOM\n");
@@ -535,7 +535,7 @@ void bcm43xx_debugfs_log_txstat(struct b
if (!e)
return;
log = &e->txstatlog;
- assert(irqs_disabled());
+ BCM43xx_WARN_ON(!irqs_disabled());
spin_lock(&log->lock);
i = log->end + 1;
if (i == BCM43xx_NR_LOGGED_TXSTATUS)
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-08 22:09:48.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-08 22:17:10.0 +0200
@@ -67,7 +67,7 @@ static void op32_fill_descriptor(struct
u32 addrext;
slot = (int)(&(desc->dma32) - descbase);
- assert(slot >= 0 && slot < ring->nr_slots);
+ BCM43xx_WARN_ON(!(slot >= 0 && slot < ring->nr_slots));
addr = (u32)(dmaaddr & ~SSB_DMA_TRANSLATION_MASK);
addrext = (u32)(dmaaddr & SSB_DMA_TRANSLATION_MASK)
@@ -164,7 +164,7 @@ static void op64_fill_descriptor(struct
u32 addrext;
slot = (int)(&(desc->dma64) - descbase);
- assert(slot >= 0 && slot < ring->nr_slots);
+ BCM43xx_WARN_ON(!(slot >= 0 && slot < ring->nr_slots));
addrlo = (u32)(dmaaddr & 0x);
addrhi = (((u64)dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
@@ -245,7 +245,7 @@ static inline int free_slots(struct bcm4
static inline int next_slot(struct bcm43xx_dmaring *ring, int slot)
{
- assert(slot >= -1 && slot <= ring->nr_slots - 1);
+ BCM43xx_WARN_ON(!(slot >= -1 && slot <= ring->nr_slots - 1));
if (slot == ring->nr_slots - 1)
return 0;
return slot + 1;
@@ -253,7 +253,7 @@ static inline int next_slot(struct bcm43
static inline int prev_slot(struct bcm43xx_dmaring *ring, int slot)
{
- assert(slot >= 0 && slot <= ring->nr_slots - 1);
+ BCM43xx_WARN_ON(!(slot >= 0 && slot <= ring->nr_slots - 1));
if (slot == 0)
return ring->nr_slots - 1;
return slot - 1;
@@ -287,9 +287,9 @@ int request_slot(struct bcm43xx_dmaring
{
int slot;
- assert(ring->tx);
-
[patch 8/9] bcm43xx-mac80211: Reorder starting of wireless core.
Reorder the starting of the wireless core. First set the "we are ready to go" status and then poke operation. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 22:17:24.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 22:17:29.0 +0200 @@ -3086,13 +3086,18 @@ static int bcm43xx_wireless_core_start(s dev->dev->irq); goto out; } + + /* We are ready to run. */ + bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); + + /* Start data flow (TX/RX). */ bcm43xx_mac_enable(dev); + bcm43xx_interrupt_enable(dev, dev->irq_savedstate); + ieee80211_start_queues(dev->wl->hw); + /* Start maintainance work */ bcm43xx_periodic_tasks_setup(dev); - ieee80211_start_queues(dev->wl->hw); - bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); - bcm43xx_interrupt_enable(dev, dev->irq_savedstate); bcmdbg(dev->wl, "Wireless interface started\n"); out: return err; -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 2/9] bcm43xx-mac80211: Fix handling of failure to create debugfs directory
From: Pavel Roskin <[EMAIL PROTECTED]>
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.
Debugging message added by Michael Buesch.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
2007-08-08 22:09:48.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
2007-08-08 22:17:03.0 +0200
@@ -408,7 +408,7 @@ static struct file_operations restart_fo
int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
{
- return !!(dev->dfsentry->dyn_debug[feature]);
+ return !!(dev->dfsentry && dev->dfsentry->dyn_debug[feature]);
}
static void bcm43xx_remove_dynamic_debug(struct bcm43xx_wldev *dev)
@@ -472,7 +472,14 @@ void bcm43xx_debugfs_add_device(struct b
snprintf(devdir, sizeof(devdir), "%s", wiphy_name(dev->wl->hw->wiphy));
e->subdir = debugfs_create_dir(devdir, fs.root);
if (!e->subdir || IS_ERR(e->subdir)) {
- e->subdir = NULL;
+ if (e->subdir == ERR_PTR(-ENODEV)) {
+ bcmdbg(dev->wl, "DebugFS (CONFIG_DEBUG_FS) not "
+ "enabled in kernel config\n");
+ } else {
+ bcmerr(dev->wl, "debugfs: cannot create %s directory\n",
+ devdir);
+ }
+ dev->dfsentry = NULL;
kfree(log->log);
kfree(e);
return;
@@ -525,6 +532,8 @@ void bcm43xx_debugfs_log_txstat(struct b
struct bcm43xx_txstatus *cur;
int i;
+ if (!e)
+ return;
log = &e->txstatlog;
assert(irqs_disabled());
spin_lock(&log->lock);
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 1/9] bcm43xx-mac80211: Add comments to the attenuation value calculation
No functional change.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:11:25.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:16:56.0 +0200
@@ -870,8 +870,12 @@ void bcmdbg(struct bcm43xx_wl *wl, const
__value;\
})
+/* Convert an integer to a Q5.2 value */
+#define INT_TO_Q52(i) ((i) << 2)
+/* Convert a Q5.2 value to an integer (precision loss!) */
+#define Q52_TO_INT(q52)((q52) >> 2)
/* Macros for printing a value in Q5.2 format */
#define Q52_FMT"%u.%u"
-#define Q52_ARG(q52) ((q52) / 4), q52) & 3) * 100) / 4)
+#define Q52_ARG(q52) Q52_TO_INT(q52), q52) & 0x3) * 100) / 4)
#endif /* BCM43xx_H_ */
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
2007-08-08 22:11:25.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
2007-08-08 22:16:56.0 +0200
@@ -2098,18 +2098,33 @@ void bcm43xx_phy_xmitpower(struct bcm43x
where REG is the max power as per the regulatory domain
*/
- desired_pwr = phy->power_level;
- /* Convert the desired_pwr to Q5.2 and limit it. */
- desired_pwr = limit_value((desired_pwr << 2), 0, max_pwr);
+ /* Get desired power (in Q5.2) */
+ desired_pwr = INT_TO_Q52(phy->power_level);
+ /* And limit it. max_pwr already is Q5.2 */
+ desired_pwr = limit_value(desired_pwr, 0, max_pwr);
if (bcm43xx_debug(dev, BCM43xx_DBG_XMITPOWER)) {
bcmdbg(dev->wl, "Current TX power output: " Q52_FMT "
dBm, "
"Desired TX power output: " Q52_FMT " dBm\n",
Q52_ARG(estimated_pwr), Q52_ARG(desired_pwr));
}
+ /* Calculate the adjustment delta. */
pwr_adjust = desired_pwr - estimated_pwr;
- rfatt_delta = -((pwr_adjust + 7) >> 3);
- bbatt_delta = (-(pwr_adjust >> 1)) - (4 * rfatt_delta);
+
+ /* RF attenuation delta. */
+ rfatt_delta = ((pwr_adjust + 7) / 8);
+ /* Lower attenuation => Bigger power output. Negate it. */
+ rfatt_delta = -rfatt_delta;
+
+ /* Baseband attenuation delta. */
+ bbatt_delta = pwr_adjust / 2;
+ /* Lower attenuation => Bigger power output. Negate it. */
+ bbatt_delta = -bbatt_delta;
+ /* RF att affects power level 4 times as much as
+* Baseband attennuation. Subtract it. */
+ bbatt_delta -= 4 * rfatt_delta;
+
+ /* So do we finally need to adjust something? */
if ((rfatt_delta == 0) && (bbatt_delta == 0)) {
bcm43xx_lo_g_ctl_mark_cur_used(dev);
return;
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 0/9] New patch series for merge
Hi John, This patch series catches wireless-dev up to my current wireless-development patchset. Please merge this into wireless-dev. -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Monday 06 August 2007 03:21:11 you wrote: > Richard Jonsson wrote: > > Isn't Desired TX power supposed to adapt so that higher bitrates are > > possible, with Bit Rate going lower if that is not enough to keep a good > > connection? > > Richard, > > Please grab a new copy of the port_to_mac80211 patch, and try the patch > below. It boosts the desired power by up to 5 dBm as signal - noise > decreases from 20 to 0. > > Larry Hard to say if there is a difference. I've noticed that signal quality changes between reboots. When I first tried this patch I couldn't get above 36M even at the AP, so I loaded the version without the patch. Same thing. So I rebooted and then all rates worked, even 11M. Even for the driver version that didn't work a few days ago. New/updated observations: Rate scaling seems to work, but if it gets down to 1M it will not rise again unless I force it to a higher bitrate and run iperf for a few seconds before setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I get a feeling it's a bit to sensitive as it will drop quickly at a few meters away. At this distance forced 54M still works well. Maybe this is due to small dips (0.5sec) in traffic flow?! With the patch applied power is reported as 27dB in debugfs. With debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This is max when I manually set power through debugfs. After a while it's down to 10dB, even though only 1M works where I sit. Range seems to be higher for B-rates. Maybe this is just how things are, I lack experience. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Re git checkout -f... that's what I thought but when I kept getting the patch was previously applied... I figured I'd just clean it out. Costs me 30 minutes of compile/link time, but it's nice'd out of the way. The new patch (that was attached by you, and that Michael re-referenced) applied, and it is now building. Should have results in 35m. Thanks Ehud Larry Finger wrote: Ehud Gavron wrote: Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) [EMAIL PROTECTED] test]# patch -p1 < ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 < ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c No, you got the wrong patch. That one was previously applied, which is what the error message is saying. In any case, apply the one I just sent. BTW, it isn't necessart to repull the tree to get a clean version. That is what 'git checkout -f' does. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Ehud Gavron wrote: > Patch with debug on or off both fail. > > I'm unable to apply Michael's patch to either a virgin test or virgin > wireless-dev tree (I rm -rf'd both and re git clone'd them) > > [EMAIL PROTECTED] test]# patch -p1 < > ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch > patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] y > Hunk #1 FAILED at 3018. > 1 out of 1 hunk FAILED -- saving rejects to file > drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej > [EMAIL PROTECTED] test]# cd ../wireless-dev > [EMAIL PROTECTED] wireless-dev]# patch -p1 < > ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch > patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c No, you got the wrong patch. That one was previously applied, which is what the error message is saying. In any case, apply the one I just sent. BTW, it isn't necessart to repull the tree to get a clean version. That is what 'git checkout -f' does. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote: > Patch with debug on or off both fail. > > I'm unable to apply Michael's patch to either a virgin test or virgin > wireless-dev tree (I rm -rf'd both and re git clone'd them) > > [EMAIL PROTECTED] test]# patch -p1 < > ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch > patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > Reversed (or previously applied) patch detected! Assume -R? [n] John just pushed the IRQ patch upstream. Please try my patch that I just sent. This one: http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Ehud Gavron wrote: Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) It works here. Again there must be a white-space problem with the patch. A working version is attached. Larry Subject: bcm43xx-mac80211: Reorder starting of wireless core. Reorder the starting of the wireless core. First set the "we are ready to go" status and then poke operation. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 19:32:05.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-08 20:10:36.0 +0200 @@ -3086,13 +3086,18 @@ static int bcm43xx_wireless_core_start(s dev->dev->irq); goto out; } + + /* We are ready to run. */ + bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); + + /* Start data flow (TX/RX). */ bcm43xx_mac_enable(dev); + bcm43xx_interrupt_enable(dev, dev->irq_savedstate); + ieee80211_start_queues(dev->wl->hw); + /* Start maintainance work */ bcm43xx_periodic_tasks_setup(dev); - ieee80211_start_queues(dev->wl->hw); - bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); - bcm43xx_interrupt_enable(dev, dev->irq_savedstate); bcmdbg(dev->wl, "Wireless interface started\n"); out: return err; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Patch with debug on or off both fail. I'm unable to apply Michael's patch to either a virgin test or virgin wireless-dev tree (I rm -rf'd both and re git clone'd them) [EMAIL PROTECTED] test]# patch -p1 < ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej [EMAIL PROTECTED] test]# cd ../wireless-dev [EMAIL PROTECTED] wireless-dev]# patch -p1 < ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 3018. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej I can do this all day long. It's much more fun than dissecting the original commit and doing it step by step. Ehud Larry Finger wrote: Ehud Gavron wrote: The corrected patch shows the same results. I have a 2.6.23-rc2 kernel where bcm43xx_mac80211 receives garbage. Mumble, mumble, swear words,. OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 19:54:30 Larry Finger wrote: > Ehud Gavron wrote: > > The corrected patch shows the same results. I have a 2.6.23-rc2 kernel > > where bcm43xx_mac80211 receives garbage. > > Mumble, mumble, swear words,. > > OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off? Ehud, Can you try the following patch? I have no idea how that could prevent data corruption, but give it a try :) It should apply with Hunk #1 succeeded at 3014 (offset -72 lines). http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 19:46:33 Ehud Gavron wrote: > The corrected patch shows the same results. I have a 2.6.23-rc2 kernel > where bcm43xx_mac80211 receives garbage. Please enable almost every option under "Kernel Hacking". Especially those to detect memory corruption. But also the lock debugging stuff. When done, reproduce. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Ehud Gavron wrote: > The corrected patch shows the same results. I have a 2.6.23-rc2 kernel > where bcm43xx_mac80211 receives garbage. Mumble, mumble, swear words,. OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
The corrected patch shows the same results. I have a 2.6.23-rc2 kernel where bcm43xx_mac80211 receives garbage. Ehud Larry Finger wrote: Michael Buesch wrote: On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote: [EMAIL PROTECTED] test]# git status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # arch/x86_64/vdso/vdso.lds nothing added to commit but untracked files present (use "git add" to track) [EMAIL PROTECTED] test]# git diff [EMAIL PROTECTED] test]# Larry, your patch is broken [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Hunk #1 FAILED at 1503. Hunk #2 FAILED at 1512. 2 out of 2 hunks FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The white space must have been garbled. When it didn't apply, Ehud contacted me privately and I sent him the patch file as an attachment. It has applied cleanly and is now compiling. Larry smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Michael Buesch wrote: > On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote: >> [EMAIL PROTECTED] test]# git status >> # On branch master >> # Untracked files: >> # (use "git add ..." to include in what will be committed) >> # >> # arch/x86_64/vdso/vdso.lds >> nothing added to commit but untracked files present (use "git add" to track) >> [EMAIL PROTECTED] test]# git diff >> [EMAIL PROTECTED] test]# >> > > > Larry, your patch is broken > > [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > Hunk #1 FAILED at 1503. > Hunk #2 FAILED at 1512. > 2 out of 2 hunks FAILED -- saving rejects to file > drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej > The white space must have been garbled. When it didn't apply, Ehud contacted me privately and I sent him the patch file as an attachment. It has applied cleanly and is now compiling. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote: > [EMAIL PROTECTED] test]# git status > # On branch master > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # arch/x86_64/vdso/vdso.lds > nothing added to commit but untracked files present (use "git add" to track) > [EMAIL PROTECTED] test]# git diff > [EMAIL PROTECTED] test]# > Larry, your patch is broken [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
[EMAIL PROTECTED] test]# git status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # arch/x86_64/vdso/vdso.lds nothing added to commit but untracked files present (use "git add" to track) [EMAIL PROTECTED] test]# git diff [EMAIL PROTECTED] test]# Michael Buesch wrote: On Wednesday 08 August 2007 18:11:03 Larry Finger wrote: [EMAIL PROTECTED] test]# patch -p1 < patch-2007-aug-08-lfinger.txt patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c Hunk #1 FAILED at 1503. Hunk #2 FAILED at 1512. 2 out of 2 hunks FAILED -- saving rejects to file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej The patch failed, but it shouldn't have. Have you done a 'git bisect reset' since we finished the bisecting? That would be a problem. Just in case, do the following: git bisect reset git checkout -f git pull Then apply the patch. If you get any REJECTS, please let me know. I'll hold off on analyzing those assertions until the code is in a known state. Yeah, your tree is still unclean. After cleaning it you can verify if it's clean by inspecting the output of git status and git diff status should _not_ talk about "modified" files or something like that. diff should output nothing. A clean tree looks like this: [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status nothing to commit [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff [EMAIL PROTECTED]:~/develop/git/wireless-dev$ smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Wednesday 08 August 2007 18:11:03 Larry Finger wrote: > > [EMAIL PROTECTED] test]# patch -p1 < patch-2007-aug-08-lfinger.txt > > patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > > Hunk #1 FAILED at 1503. > > Hunk #2 FAILED at 1512. > > 2 out of 2 hunks FAILED -- saving rejects to file > > drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej > > The patch failed, but it shouldn't have. Have you done a 'git bisect reset' > since we finished the > bisecting? That would be a problem. Just in case, do the following: > > git bisect reset > git checkout -f > git pull > > Then apply the patch. If you get any REJECTS, please let me know. I'll hold > off on analyzing those > assertions until the code is in a known state. Yeah, your tree is still unclean. After cleaning it you can verify if it's clean by inspecting the output of git status and git diff status should _not_ talk about "modified" files or something like that. diff should output nothing. A clean tree looks like this: [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status nothing to commit [EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff [EMAIL PROTECTED]:~/develop/git/wireless-dev$ -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Ehud Gavron wrote:
> I had hoped this would be the cure so I don't have to undo the 85a83d26
> commit patch by patch.
>
> However, while this did not solve the problem it DID show a new error:
> bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
> BCM43xx_STAT_STARTED) at:
> drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
>
>
>
> Is that a clue to bigger things, or a problem with this patch? dmesg and
> tcpdump (of garbage) included along with a log of what I did with the
> git "test" tree to get there.
>
> [EMAIL PROTECTED] test]# git checkout -f
> [EMAIL PROTECTED] test]# cat > patch-2007-aug-08-lfinger.txt
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
> /* Interrupt handler top-half */
> static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
> {
> -irqreturn_t ret = IRQ_NONE;
> +irqreturn_t ret = IRQ_HANDLED;
> struct bcm43xx_wldev *dev = dev_id;
> u32 reason;
>
> @@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han
>
> spin_lock(&dev->wl->irq_lock);
>
> -if (bcm43xx_status(dev) < BCM43xx_STAT_STARTED)
> -goto out;
> reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
> -if (reason == 0x) /* shared IRQ */
> +if (reason == 0x) { /* shared IRQ */
> +ret = IRQ_NONE;
> goto out;
> -ret = IRQ_HANDLED;
> +}
> reason &= bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
> if (!reason)
> goto out;
> [EMAIL PROTECTED] test]# patch -p1 < patch-2007-aug-08-lfinger.txt
> patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> Hunk #1 FAILED at 1503.
> Hunk #2 FAILED at 1512.
> 2 out of 2 hunks FAILED -- saving rejects to file
> drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej
The patch failed, but it shouldn't have. Have you done a 'git bisect reset'
since we finished the
bisecting? That would be a problem. Just in case, do the following:
git bisect reset
git checkout -f
git pull
Then apply the patch. If you get any REJECTS, please let me know. I'll hold off
on analyzing those
assertions until the code is in a known state.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
I had hoped this would be the cure so I don't have to undo the 85a83d26
commit patch by patch.
However, while this did not solve the problem it DID show a new error:
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
Is that a clue to bigger things, or a problem with this patch?
dmesg and tcpdump (of garbage) included along with a log of what I did
with the git "test" tree to get there.
Ehud
Larry Finger wrote:
To the list: The beginnings of this thread were done off-list, but I
want to let everyone know about
the problem, and to discover if anyone else has it. Since 2.6.23-rc1,
Ehud has a problem in that the information his interface is
transmitting is garbled. He did a bisection and discovered that the
problem is involved with commit 85a83d26 "bcm43xx-mac80211: Rewrite
and simplify handling of the initialization status.". Neither Michael
nor I can reproduce the problem, nor is anything obviously wrong with
the patch, other than this patch exposes an error in the location of
the initial interrupt. I found this error on my old/slow notebook.
Fixing that error did not resolve Ehud's problem. That fix is now in
Linville's tree.
Ehud - please make your test tree current with a 'git checkout -f'
command, and do a 'git pull' to
make certain you have the latest code. Then apply the trial patch
below, which reverts a small part of Michael's patch, and see if it
fixes the problem.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
---
wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
/* Interrupt handler top-half */
static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
-irqreturn_t ret = IRQ_NONE;
+irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_wldev *dev = dev_id;
u32 reason;
@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han
spin_lock(&dev->wl->irq_lock);
-if (bcm43xx_status(dev) < BCM43xx_STAT_STARTED)
-goto out;
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
-if (reason == 0x) /* shared IRQ */
+if (reason == 0x) { /* shared IRQ */
+ret = IRQ_NONE;
goto out;
-ret = IRQ_HANDLED;
+}
reason &= bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
if (!reason)
goto out;
bcm43xx-phy0: Broadcom 4311 WLAN found
bcm43xx-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy0 debug: Radio turned off
bcm43xx driver
bcm43xx-phy1: Broadcom 4311 WLAN found
bcm43xx-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy1 debug: Radio turned off
bcm43xx-phy1 debug: Adding Interface type 2
bcm43xx-phy1 debug: Loading firmware version 371.1061 (2006-10-04 21:02:04)
bcm43xx-phy1 debug: Radio turned on
bcm43xx-phy1 debug: Radio enabled by hardware
bcm43xx-phy1 debug: bbatt(11) >= size of LO array
[] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x65/0xa8
[] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x36/0x3b
[] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x9/0x15
[] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x338/0x6a6
[] :bcm43xx_mac80211:bcm43xx_phy_read+0x5c/0x63
[] :bcm43xx_mac80211:bcm43xx_phy_initg+0xc85/0xd0a
[] :bcm43xx_mac80211:bcm43xx_phy_init+0x582/0x5a7
[] :bcm43xx_mac80211:bcm43xx_chip_init+0x68c/0x9a3
[] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x288/0x73e
[] :bcm43xx_mac80211:bcm43xx_add_interface+0x5f/0xf4
bcm43xx-phy1 debug: Chip initialized
bcm43xx-phy1 debug: 32-bit DMA initialized
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1525:bcm43xx_interrupt_handler()
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
bcm43xx-phy1 debug: Wireless interface started
08:47:25.934468 00:a0:c8:0e:c0:e5 > 00:1a:92:0e:40:1f, 802.3, length 78: LLC,
dsap Unknown (0xd0) Group, ssap Unknown (0x1e) Command, ctrl 0x007c:
Information, send seq 62, rcv seq 0, Flags [Command], length 64
0x: 001a 920e 401f 00a0 c80e c0e5 0040 d11e
0x0010: 7c00 d33d 7497 de0e 21e6 f6fe 8382 bf04
0x0020: e081 7838 36f2 114a 3ee3 9c19 e3fc 402c
0x0030: 8746 083d 4fb9 0b86 4965 f272 86e1 963b
0x0040: 2efe a2c5 c3ac f6ca 4363 eb91 a233
08:47:29.497365 00:a0:c8:0e:c0:e5 > 00:1a:92:0e:40:1f, 802.3, length 76: LLC,
dsap Unknown (0xd2) Individual, ssap Unknown (0x1e) Command, ctrl 0x007c:
Informa
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
To the list: The beginnings of this thread were done off-list, but I want to
let everyone know about
the problem, and to discover if anyone else has it. Since 2.6.23-rc1, Ehud has
a problem in that the
information his interface is transmitting is garbled. He did a bisection and
discovered that the
problem is involved with commit 85a83d26 "bcm43xx-mac80211: Rewrite and
simplify handling of the
initialization status.". Neither Michael nor I can reproduce the problem, nor
is anything obviously
wrong with the patch, other than this patch exposes an error in the location of
the initial
interrupt. I found this error on my old/slow notebook. Fixing that error did
not resolve Ehud's
problem. That fix is now in Linville's tree.
Ehud - please make your test tree current with a 'git checkout -f' command, and
do a 'git pull' to
make certain you have the latest code. Then apply the trial patch below, which
reverts a small part
of Michael's patch, and see if it fixes the problem.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
/* Interrupt handler top-half */
static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
- irqreturn_t ret = IRQ_NONE;
+ irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_wldev *dev = dev_id;
u32 reason;
@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han
spin_lock(&dev->wl->irq_lock);
- if (bcm43xx_status(dev) < BCM43xx_STAT_STARTED)
- goto out;
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
- if (reason == 0x) /* shared IRQ */
+ if (reason == 0x) { /* shared IRQ */
+ ret = IRQ_NONE;
goto out;
- ret = IRQ_HANDLED;
+ }
reason &= bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
if (!reason)
goto out;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote: > The spec is telling us to lookup an invalid index in the LO table. I see. Thanks for your explanation! I think the way to solve it would be to see how the table is used in the proprietary driver. Either the data from the extra entries is used, and we need to find out where it comes from, or there is an algorithm to limit the index to only access valid entries. I hope the reverse engineering team knows that. I wish them good luck. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 works with fedora 7 but only at 1mb/s
On Tue, Aug 07, 2007 at 07:57:03PM -0500, Larry Finger wrote: > John H. wrote: > > Did I misunderstand something? I thought some script was available or > > some easy way to use either bcm43xx or the new one. brennan says he > > has a script to just let you use the newer driver with higher mbps, > > but I have never heard back from him. > > > > I have no idea what he is/was talking about. Until late yesterday, the best > performance was with the > unaltered bcm43xx, or the port of that driver to mac80211. Today, the changes > now propagating > through the system make bcm43xx-mac80211 into the preferred driver. You > should ask Fedora how soon > those will make it into their development kernels (called Rawhide?). Probably tonight. Maybe earlier if you watch Koji. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Fix handling of failure to create debugfs directory
Michael Buesch wrote: > On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote: >> This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but >> CONFIG_DEBUG_FS is not. >> >> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> >> --- > > Thanks, queued. > Larry, this might also apply to bcm4301. Yes it will. Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Odd network locking
On Saturday 04 August 2007 07:12:46 Brennan Ashton wrote: > When the bcm43xx_mac80211 driver stops communicating, and needs to be > reset (this seems to happens when coming from strong to week to strong > signal area quickly) i have been rmmod and then modprobing it. this Can you test if you still have that "stop communication" problem, if you pull latest wireless-dev and apply these patches on top of it? http://bu3sch.de/patches/wireless-dev/LATEST/patches/ > works most of the time, but some times (~20%), it will lock up the > network with this error that repeats. > > Message from [EMAIL PROTECTED] at Fri Aug 3 00:55:41 2007 ... > localhost kernel: [19316.256549] unregister_netdevice: waiting for eth1 to > becom > e free. Usage count = 5 Most likely a bug in mac80211. But it _could_ be related to the ieee80211_stop_queues() call we do when stopping the wireless core. I think it's still not race free. But I don't know if that can cause something like this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Usage of bcm43xx-sprom tool
On Wednesday 08 August 2007 05:27:13 Jhonie Walker wrote: > Hello, I tried to use the tool with the drivers > working ok, but this is what I get in the console: > ./sprommod.sh eth0 > ./sprommod.sh: line 31: bcm43xx-sprom: command not > found > Could not modify SPROM data (127) > > I noticed that the file bcm43xx-sprom does not exist. > Instead it is a ssb-sprom binary file. Ah, it was renamed. That's a bug in that script. I think I will simply remove that script, as it's just a hack that only works on the old non-ssb based driver. > I installed the tool in Fedora 7 using the 'make > install' command. I was using the last version > available throug svn. > > I think I need more information on how to use this > tool (i.e. a short tutorial). In general you don't want to use it. What are you trying to do? Doing the wrong things with this tool can make it very difficult to recover to a properly working device. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Fix handling of failure to create debugfs directory
On Wednesday 08 August 2007 08:02:29 Larry Finger wrote: > Larry Finger wrote: > > Pavel Roskin wrote: > >> This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but > >> CONFIG_DEBUG_FS is not. > >> > >> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> > >> --- > >> > > With this patch installed, and the DEBUG configuration set as above, I get > > a kernel panic on an > > x86_64 SMP system. The reason for the panic scrolled off the screen, but > > the complete stack dump > > (hand copied) is as follows: > > > > lock_acquire+0x85/0x31 > > bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/099 > > _spin_lock+0x25/0x31 > > Ignore the noise above. I had failed to get the right patch. The crash > confirms the problem > _without_ the patch. Getting it in properly fixes the problem > > Acked-by: Larry Finger <[EMAIL PROTECTED]> Yeah, I just noticed that, too :) So, I applied it to my queue and it will soon go upstream. http://bu3sch.de/patches/wireless-dev/LATEST/patches/ -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Fix handling of failure to create debugfs directory
On Wednesday 08 August 2007 07:52:21 Larry Finger wrote: > Pavel Roskin wrote: > > This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but > > CONFIG_DEBUG_FS is not. > > > > Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> > > --- > > > With this patch installed, and the DEBUG configuration set as above, I get a > kernel panic on an > x86_64 SMP system. The reason for the panic scrolled off the screen, but the > complete stack dump > (hand copied) is as follows: > > lock_acquire+0x85/0x31 > bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/099 > _spin_lock+0x25/0x31 > bcm43xx_mac80211: bcm43xx_interrupt_tasklet+0x21/0x723 > bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/0x99 > bcm43xx_mac80211: bcm43xx_handle_txstatsus+0x12/0x72 > bcm43xx_mac80211: bcm43xx_interrupt_tasklet+0x699/0x723 > __lock_acquire+0xca2/0xcf0 > bcm43xx_mac80211: bcm43xx_interrupt_handler+0x296/0x723 > tasklet_action+0x5e/0xb2 > __do_softirq+0x5f/0xe3 > call_softirq+0x1c/0x28 > do_softirq+0x39/0x9f > irq_exit+0x4e/0x50 > do_IRQ+0xba/0xd8 > default_idle+0x35/0x51 > cpu_idle+0xce/0xf1 > start_secondary+0x2e0/0x2f2 Ah crap. I missed this. I'll do a patch. But first some lunch :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Odd network locking
On Sat, 2007-08-04 at 00:56 -0700, Brennan Ashton wrote: > the trace overflows dmesg buffer, but here is what is left in the log: > > [...] Not very understandable unfortunately. Somewhere there must be a missing dev_put but I can't pinpoint it. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Fix handling of failure to create debugfs directory
On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote:
> This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
> CONFIG_DEBUG_FS is not.
>
> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
> ---
Thanks, queued.
Larry, this might also apply to bcm4301.
> .../wireless/bcm43xx-mac80211/bcm43xx_debugfs.c|8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> index 9ca4625..aded2b3 100644
> --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> @@ -408,7 +408,7 @@ static struct file_operations restart_fops = {
>
> int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
> {
> - return !!(dev->dfsentry->dyn_debug[feature]);
> + return !!(dev->dfsentry && dev->dfsentry->dyn_debug[feature]);
> }
>
> static void bcm43xx_remove_dynamic_debug(struct bcm43xx_wldev *dev)
> @@ -472,7 +472,9 @@ void bcm43xx_debugfs_add_device(struct bcm43xx_wldev *dev)
> snprintf(devdir, sizeof(devdir), "%s", wiphy_name(dev->wl->hw->wiphy));
> e->subdir = debugfs_create_dir(devdir, fs.root);
> if (!e->subdir || IS_ERR(e->subdir)) {
> - e->subdir = NULL;
> + bcmerr(dev->wl, "debugfs: cannot create %s directory\n",
> +devdir);
> + dev->dfsentry = NULL;
> kfree(log->log);
> kfree(e);
> return;
> @@ -525,6 +527,8 @@ void bcm43xx_debugfs_log_txstat(struct bcm43xx_wldev *dev,
> struct bcm43xx_txstatus *cur;
> int i;
>
> + if (!e)
> + return;
> log = &e->txstatlog;
> assert(irqs_disabled());
> spin_lock(&log->lock);
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
