Re: [PATCH 0/5] b43: more N-PHY stuff
On Fri, 2010-01-22 at 20:16 -0500, John W. Linville wrote: > On Fri, Jan 22, 2010 at 11:33:40PM +0100, Michael Buesch wrote: > > > So while we are at it, I'd really like to migrate away from the berlios > > list. > > It's really just annoying. Does somebody have a good reliable mailinglist > > service > > we could migrate to? Does vger offer lists to driver projects? > > Probably -- I think davem is the person to ask? Infradead is probably > another option (dwmw2). Yeah, pick one and either of us can set up a new list at the drop of a hat. Strictly speaking I suspect it should be postmas...@vger rather than just davem, but the effect is much the same most of the time. Can you provide a list of existing subscribers? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix to enhance TX speed
On Sat, 2008-09-06 at 21:30 -0700, [EMAIL PROTECTED] wrote: > Recent changes in the specifications have improved the performance > of the BCM4306/2 devices that use b43legacy as the driver. These > "errors" in the specs have been present from the very first > implementation of bcm43xx. I haven't verified any speed improvement, but certainly this patch (when applied on top of the Fedora 9 kernel) doesn't make my shinybook get bus errors, which has been a common problem when updating this part of the code to match the specs. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: powerbook 4306 disassociate/reassociate 'bouncing' with b43/2.6.24.x
On Thu, 2008-02-28 at 17:13 -0700, David Wilk wrote: > I did some experimentation and discovered that the problem, although > appearing to be driver-based was actually being driven by > wpa_supplicant. I'm not sure exactly why the problem was occuring, > but apparently having a wpa_supplicant.conf file present while using > network-manager (NetworkManager) can result in the periodic bizaar > disconnect/reconnect loop problem I was experiencing. > > I'm hoping that the fix is not temporary, but I'll keep an eye on it > and report any changes to the list. I suspect if others are having > good success with their broadcom 4306 in their powerbooks with the b43 > driver in 2.6.24.x, that my problems were of my own making > (network-manager and wpa_supplicant). Hm, that's interesting. I've also seen such loops (disconnecting with reason=3), and usually have to 'fix' it by killing wpa_supplicant just once after booting -- after that it usually seems to work. I'll remove the config file and see what happens next time I reboot. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation "wpa_driver_wext_set_countermeasures" not supported
On Tue, 2007-12-18 at 12:36 +0100, Robert Allerstorfer wrote: > done. I have recompiled and replaced the original b43.ko from > 'kernel-2.6.23.9-90.fc8.src.rpm', with the modified 'phy.c' ["if > (B43_DEBUG)" changed to "if (0)" on line 741]. Using Fedora's build > mechanism, I had to built the entire (baseonly) kernel which took over > 2 hours. Er, why would you do such a thing? If you have the appropriate kernel-devel package installed, you only need to rebuild the driver itself, by putting it into a directory on its own and running make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules which has been the way to build out-of-tree modules for as long as I can remember. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Use input-polldev for the rfkill switch
On Sat, 2007-09-29 at 19:32 +0200, Michael Buesch wrote: > The patch is correct as-is. RF-kill was polled by the periodic work. OK, cool. Just checking. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Use input-polldev for the rfkill switch
On Sat, 2007-09-29 at 19:08 +0200, Michael Buesch wrote: > I'm not sure what you are trying to ask. The hunks I quoted don't seem relevant to the rfkill switch. They seem to be related to periodic work, which was the subject of the other patch you posted at about the same time. Did you get them mixed up? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Use input-polldev for the rfkill switch
On Fri, 2007-09-28 at 14:22 +0200, Michael Buesch wrote:
> This removes the direct call to rfkill on an rfkill event
> and replaces it with an input device. This way userspace is also
> notified about the event.
>
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
...
> static void do_periodic_work(struct b43_wldev *dev)
> {
> unsigned int state;
>
> state = dev->periodic_state;
> - if (state % 120 == 0)
> + if (state % 8 == 0)
> b43_periodic_every120sec(dev);
> - if (state % 60 == 0)
> + if (state % 4 == 0)
> b43_periodic_every60sec(dev);
> - if (state % 30 == 0)
> + if (state % 2 == 0)
> b43_periodic_every30sec(dev);
> - if (state % 15 == 0)
> - b43_periodic_every15sec(dev);
> - b43_periodic_every1sec(dev);
> + b43_periodic_every15sec(dev);
> }
>
> /* Estimate a "Badness" value based on the periodic work
> @@ -2429,13 +2400,11 @@ static int estimate_periodic_work_badnes
> {
> int badness = 0;
>
> - if (state % 120 == 0) /* every 120 sec */
> + if (state % 8 == 0) /* every 120 sec */
> badness += 10;
> - if (state % 60 == 0)/* every 60 sec */
> + if (state % 4 == 0) /* every 60 sec */
> badness += 5;
> - if (state % 30 == 0)/* every 30 sec */
> - badness += 1;
> - if (state % 15 == 0)/* every 15 sec */
> + if (state % 2 == 0) /* every 30 sec */
> badness += 1;
>
> #define BADNESS_LIMIT4
> @@ -2486,13 +2455,13 @@ static void b43_periodic_work_handler(st
> spin_unlock_irqrestore(&dev->wl->irq_lock, flags);
> }
> dev->periodic_state++;
> - out_requeue:
> +out_requeue:
> if (b43_debug(dev, B43_DBG_PWORK_FAST))
> delay = msecs_to_jiffies(50);
> else
> - delay = round_jiffies(HZ);
> + delay = round_jiffies(HZ * 15);
> queue_delayed_work(dev->wl->hw->workqueue, &dev->periodic_work, delay);
> - out:
> +out:
> mutex_unlock(&dev->wl->mutex);
> }
Does this bit belong to your other patch?
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote: > These are all false positives, except this one, where the wrong > converter function was used. > > @@ -442,7 +444,7 @@ void b43legacy_rx(struct b43legacy_wldev > phystat0 = le16_to_cpu(rxhdr->phy_status0); > phystat3 = le16_to_cpu(rxhdr->phy_status3); > jssi = rxhdr->jssi; > - macstat = le32_to_cpu(rxhdr->mac_status); > + macstat = le16_to_cpu(rxhdr->mac_status); > mactime = le16_to_cpu(rxhdr->mac_time); > chanstat = le16_to_cpu(rxhdr->channel); Did this one get committed yet? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 10:07 -0500, Larry Finger wrote: > The only way that b43legacy_rx() could generate a BUG_ON is if the > bitrate codes in the received > message are messed up. The attached patch will partially silence those > messages and let us see more. > Perhaps we can find the real cause. I certainly appreciate your > assistance in debugging these problems. With this patch and the later le16_to_cpu(rxhdr->mac_status) change, my device seems to be working with b43legacy: b43legacy-phy2: Broadcom 4306 WLAN found b43legacy-phy2 debug: Found PHY: Analog 1, Type 2, Revision 1 b43legacy-phy2 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43legacy-phy2 debug: Radio turned off wmaster0: Selected rate control algorithm 'simple' net eth1: device_rename: sysfs_create_symlink failed (-17) b43legacy-phy2 debug: Adding Interface type 2 b43legacy-phy2 debug: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy2 debug: Radio turned on b43legacy-phy2 debug: Radio enabled by hardware b43legacy-phy2 debug: Chip initialized b43legacy-phy2 debug: 30-bit DMA initialized b43legacy-phy2 debug: Wireless interface started ADDRCONF(NETDEV_UP): eth1: link is not ready b43legacy-phy2 debug: Using software based encryption for mac: ff:ff:ff:ff:ff:ff eth1: Initial auth_alg=0 eth1: authenticate with AP 00:06:25:4b:55:f8 eth1: RX authentication from 00:06:25:4b:55:f8 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:06:25:4b:55:f8 eth1: RX AssocResp from 00:06:25:4b:55:f8 (capab=0x411 status=0 aid=1) eth1: associated eth1: switched to short barker preamble (BSSID=00:06:25:4b:55:f8) ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 16:19 -0500, Larry Finger wrote:
> --- wireless-dev.orig/drivers/net/wireless/b43legacy/xmit.c
> +++ wireless-dev/drivers/net/wireless/b43legacy/xmit.c
> @@ -125,10 +125,12 @@ void b43legacy_generate_plcp_hdr(struct
> __u8 *raw = plcp->raw;
>
> if (b43legacy_is_ofdm_rate(bitrate)) {
> - *data = b43legacy_plcp_get_ratecode_ofdm(bitrate);
> + u16 d;
> +
> + d = b43legacy_plcp_get_ratecode_ofdm(bitrate);
> B43legacy_WARN_ON(octets & 0xF000);
> - *data |= (octets << 5);
> - *data = cpu_to_le32(*data);
> + d |= (octets << 5);
> + *data = cpu_to_le32(d);
> } else {
> u32 plen;
This one doesn't look like a false positive -- but isn't very clear on
whether it's a uint16_t or a uint32_t either.
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 14:05 -0500, Larry Finger wrote: > Are you using DMA or PIO? I did find some PIO endian problems, but > none with DMA so far. I don't know -- which probably means DMA, right? I don't have > 1GiB of RAM (I have precisely 1GiB). -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 10:07 -0500, Larry Finger wrote: > David Woodhouse wrote: > > On Thu, 2007-09-13 at 14:44 -0500, Larry Finger wrote: > >> David, > >> > >> Please try the patch below. > > > > Differently buggered... now we hit the B43legacy_BUG_ON() in > > b43legacy_rx() -- at least that's the _last_ trace I captured from the > > screen; there were more further up. > > > > This device is basically identical to the one I handed to John in > > Cambridge last week. How do I force the b43 driver to bind to it? > > > > As you saw from Michael's message, basically you cannot. The latest drivers > and V4 firmware from > Broadcom have abandoned this device and the BCM4301, which is why b43legacy > is needed. It may work > at the moment, but it could fail with any revisions in the specs based on a > new Broadcom driver or > with new firmware. OK, I'll concentrate on b43legacy then. > Too bad that the device behaves so differently with ppc architecture. None of > these problems happen > on my i386 platform. Performance is bad for OFDM rates, but otherwise the > interface is OK. The machine checks only don't show up because your PCI host bridge is more tolerant -- I bet you _could_ actually configure it to produce an NMI, if you really want that kind of behaviour when you poke at non-existent registers. I think that should be _encouraged_, in fact :) Or I can dust off the patch I used a while back to debug and recover from the machine checks. Unless it's endian-related I suspect the BUG() would probably occur on i386 too, with the CardBus card I gave away last week and the same revision of the kernel. Perhaps John can confirm that? (I'm using 2.6.23-0.181.rc6.git4.fc8 today) I'll poke at it some more when I get home this weekend. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 12:56 +0200, Michael Buesch wrote: > Revisions < 5 are not supported by the driver. So there's no way to use this device with v4 firmware any more? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 12:32 +0200, David Woodhouse wrote:
> This device is basically identical to the one I handed to John in
> Cambridge last week. How do I force the b43 driver to bind to it?
This (and copying b0g0initvals2 from the b43legacy/ directory to b43/)
didn't work... it seems it can't transmit.
http://david.woodhou.se/b43-not-working.txt
This card is working fine with bcm43xx-mac80211 right now though.
--- drivers/net/wireless/b43/main.c~2007-09-14 01:05:37.0 +0200
+++ drivers/net/wireless/b43/main.c 2007-09-14 12:41:32.0 +0200
@@ -109,6 +109,7 @@ module_param_named(nohwcrypt, modparam_n
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
static const struct ssb_device_id b43_ssb_tbl[] = {
+ SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 4),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 5),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 6),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 7),
@@ -1648,7 +1649,9 @@ static int b43_request_firmware(struct b
tmshigh = ssb_read32(dev->dev, SSB_TMSHIGH);
if (!fw->ucode) {
- if ((rev >= 5) && (rev <= 10))
+ if (rev == 4)
+ filename = "ucode4";
+ else if ((rev >= 5) && (rev <= 10))
filename = "ucode5";
else if ((rev >= 11) && (rev <= 12))
filename = "ucode11";
@@ -1661,7 +1664,9 @@ static int b43_request_firmware(struct b
goto err_load;
}
if (!fw->pcm) {
- if ((rev >= 5) && (rev <= 10))
+ if (rev == 4)
+ filename = "pcm4";
+ else if ((rev >= 5) && (rev <= 10))
filename = "pcm5";
else if (rev >= 11)
filename = NULL;
@@ -1683,7 +1688,9 @@ static int b43_request_firmware(struct b
goto err_no_initvals;
break;
case B43_PHYTYPE_G:
- if ((rev >= 5) && (rev <= 10))
+ if (rev == 4)
+ filename = "b0g0initvals2";
+ else if ((rev >= 5) && (rev <= 10))
filename = "b0g0initvals5";
else if (rev >= 13)
filename = "lp0initvals13";
@@ -1713,7 +1720,7 @@ static int b43_request_firmware(struct b
case B43_PHYTYPE_G:
if ((rev >= 5) && (rev <= 10))
filename = "b0g0bsinitvals5";
- else if (rev >= 11)
+ else if (rev == 4 || rev >= 11)
filename = NULL;
else
goto err_no_initvals;
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Thu, 2007-09-13 at 14:44 -0500, Larry Finger wrote: > > David, > > Please try the patch below. Differently buggered... now we hit the B43legacy_BUG_ON() in b43legacy_rx() -- at least that's the _last_ trace I captured from the screen; there were more further up. This device is basically identical to the one I handed to John in Cambridge last week. How do I force the b43 driver to bind to it? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Machine Check on Fedora rawhide kernel.
Will poke at it more when I get home at the end of the week... Sep 12 08:17:22 shinybook NetworkManager: starting... Sep 12 08:17:22 shinybook kernel: Machine check in kernel mode. Sep 12 08:17:22 shinybook kernel: Caused by (from SRR1=149030): Transfer error ack signal Sep 12 08:17:22 shinybook kernel: Oops: Machine check, sig: 7 [#1] Sep 12 08:17:22 shinybook kernel: PowerMac Sep 12 08:17:22 shinybook kernel: Modules linked in: hci_usb(U) rfcomm(U) l2cap(U) bluetooth(U) ipv6(U) nls_utf8(U) hfsplus(U) dm_mirror(U) dm_mod(U) therm_adt746x(U) sn d_aoa_i2sbus(U) arc4(U) ecb(U) blkcipher(U) snd_powermac(U) snd_seq_dummy(U) rc80211_simple(U) snd_seq_oss(U) snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) b43legac y(U) snd_pcm_oss(U) pmac_zilog(U) snd_mixer_oss(U) snd_pcm(U) mac80211(U) ide_cd(U) cfg80211(U) cdrom(U) snd_timer(U) snd_page_alloc(U) snd(U) soundcore(U) snd_aoa_sound bus(U) firewire_ohci(U) firewire_core(U) crc_itu_t(U) sungem(U) sungem_phy(U) ssb(U) ext3(U) jbd(U) mbcache(U) ehci_hcd(U) ohci_hcd(U) uhci_hcd(U) Sep 12 08:17:22 shinybook kernel: NIP: f208e9e8 LR: f2520a74 CTR: f208e994 Sep 12 08:17:22 shinybook kernel: REGS: ef35f8e0 TRAP: 0200 Not tainted (2.6.23-0.164.rc5.fc7) Sep 12 08:17:22 shinybook kernel: MSR: 00149030 CR: 42000482 XER: 2000 Sep 12 08:17:22 shinybook kernel: TASK = ee95[2238] 'NetworkManager' THREAD: ef35e000 Sep 12 08:17:22 shinybook kernel: GPR00: 003f ef35f990 ee95 efbd0430 efbd04ac 042b 0340 0015 Sep 12 08:17:22 shinybook kernel: GPR08: f2084000 2282 1032 1006ba46 100d Sep 12 08:17:22 shinybook kernel: GPR16: 100e04a8 100d 100a 100d 100dd530 100dff48 Sep 12 08:17:22 shinybook kernel: GPR24: efb430cc efb430c8 efbd0430 efb43078 efb43060 03fe efbd0430 Sep 12 08:17:22 shinybook kernel: NIP [f208e9e8] ssb_pci_read16+0x54/0x74 [ssb] Sep 12 08:17:22 shinybook kernel: LR [f2520a74] b43legacy_phy_read+0x48/0x60 [b43legacy] Sep 12 08:17:22 shinybook kernel: Call Trace: Sep 12 08:17:22 shinybook kernel: [ef35f990] [efb43060] 0xefb43060 (unreliable) Sep 12 08:17:22 shinybook kernel: [ef35f9a0] [f2520a74] b43legacy_phy_read+0x48/0x60 [b43legacy] Sep 12 08:17:22 shinybook kernel: [ef35f9c0] [f25211e4] b43legacy_phy_initb5+0x16c/0x4b0 [b43legacy] Sep 12 08:17:22 shinybook kernel: [ef35f9e0] [f2524030] b43legacy_phy_initg+0x28/0xd3c [b43legacy] Sep 12 08:17:22 shinybook kernel: [ef35fa50] [f2525350] b43legacy_phy_calibrate+0x68/0x94 [b43legacy] Sep 12 08:17:22 shinybook kernel: [ef35fa60] [f251db40] b43legacy_wireless_core_init+0x360/0x808 [b43legacy] Sep 12 08:17:22 shinybook kernel: [ef35fa90] [f251e88c] b43legacy_add_interface+0x6c/0x130 [b43legacy] Sep 12 08:17:22 shinybook kernel: [ef35fab0] [f24b0adc] ieee80211_open+0x2a4/0x440 [mac80211] Sep 12 08:17:22 shinybook kernel: [ef35faf0] [c026ae10] dev_open+0x60/0xc8 Sep 12 08:17:22 shinybook kernel: [ef35fb10] [c0268c14] dev_change_flags+0xcc/0x1a8 Sep 12 08:17:22 shinybook kernel: [ef35fb30] [c02738c4] do_setlink+0x1c8/0x2b8 Sep 12 08:17:22 shinybook kernel: [ef35fb70] [c0274b84] rtnl_setlink+0xf8/0x130 Sep 12 08:17:22 shinybook kernel: [ef35fbe0] [c027447c] rtnetlink_rcv_msg+0x214/0x240 Sep 12 08:17:23 shinybook kernel: [ef35fc00] [c0284fe4] netlink_run_queue+0x94/0x158 Sep 12 08:17:23 shinybook kernel: [ef35fc20] [c02741e0] rtnetlink_rcv+0x40/0x6c Sep 12 08:17:23 shinybook kernel: [ef35fc50] [c0285614] netlink_data_ready+0x28/0x84 Sep 12 08:17:23 shinybook kernel: [ef35fc60] [c028402c] netlink_sendskb+0x34/0x70 Sep 12 08:17:23 shinybook kernel: [ef35fc80] [c02855d0] netlink_sendmsg+0x2b0/0x2cc Sep 12 08:17:23 shinybook kernel: [ef35fcd0] [c025be9c] sock_sendmsg+0xd0/0x100 Sep 12 08:17:23 shinybook kernel: [ef35fdc0] [c025c094] sys_sendmsg+0x1c8/0x254 Sep 12 08:17:23 shinybook kernel: [ef35ff00] [c025d6b8] sys_socketcall+0x1c4/0x1fc Sep 12 08:17:23 shinybook kernel: [ef35ff40] [c0012c3c] ret_from_syscall+0x0/0x38 Sep 12 08:17:23 shinybook kernel: --- Exception: c01 at 0xfb2f91c Sep 12 08:17:23 shinybook kernel: LR = 0xfc03838 Sep 12 08:17:23 shinybook kernel: Instruction dump: Sep 12 08:17:23 shinybook kernel: 7fe3fb78 7f804800 41be0018 4b09 2f83 3860 6063 409e0020 Sep 12 08:17:23 shinybook kernel: 813f 7c09f214 7c0004ac 7c00062c <0c00> 4c00012c 5403043e 80010014 -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy woes
On Fri, 2007-08-31 at 17:26 -0500, Larry Finger wrote: > The poor performance of the BCM4306/2 (your chip/card) is known. There has > been a report that this > is a regression since 2.6.20, or so, has not been confirmed. With a 2.6.21 > kernel, I got an iperf > transmit rate of 4 Mbs, but that quickly dropped to 0.3 Mbs without me > changing anything - I just > repeated the iperf command. That reminds me... I accidentally invented a new wireless test. It's intended to stream the full OS images to OLPC laptops on the production line, and does so by multicast -- so there are no link-layer ACKs and retries compensating for your packet loss; it all gets reported. It's in git://git.infradead.org/mtd-utils.git; the tools are recv_image and serve_image. usage: recv_image usage: serve_image [] A $ dd if=/dev/urandom of=testfile bs=131072 count=50 A $ ./serve_image ff0f::114 12345 testfile 131072 85 Inter-packet delay (avg): 32858µs Transmit rate: 85 KiB/s Checking CRC85a0d369 Checking block CRCS 50/50 Image size 6400 KiB (0x0064). 50 blocks at 47 pkts/block Estimated transmit time per cycle: 77s Sending data block 004e packet 15/70(85 KiB/s) B $ ./recv_image ff0f::114 12345 foo MEMGETINFO: Inappropriate ioctl for device Receive to file bar with (assumed) erasesize 131072 Received 750/2350 (31%) in 25s @82KiB/s, 6 lost (0%), 0 dup/xs You can use it unicast too, and/or with Legacy IP instead of IPv6. If your AP sends all multicast at 1Mb/s, then 85 KiB/s is about all you'll get. If you can configure the Basic Rate set not to include the slower speeds, or if you can change the multicast rate (which could actually be _any_ rate in the Basic Rate set), then you can go faster. I find it works quite nicely at 24Mb/s. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom 4311 on HP 350 laptop
On Fri, 2007-08-31 at 18:25 +0100, Ed Davies wrote: > Yes, I did use fwcutter. The snippet you quoted was > part of a sequence where I deliberately renamed one of > the firmware files to show that the firmware was normally > being found OK. Oops, so it was. Sorry. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom 4311 on HP 350 laptop
On Fri, 2007-08-31 at 17:38 +0100, Ed Davies wrote: > [ 401.06] bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not > available or load failed. Did you use bcm43xx-fwcutter to extract firmware from one of the official drivers, and install it in /lib/firmware? I suspect not. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Which module
On Mon, 2007-08-27 at 10:56 -0500, Larry Finger wrote: > You may use either one. The driver supported by mainstream kernels is > bcm43xx, which uses SoftMAC as > its MAC layer. The driver named b43, which uses mac80211 as its MAC layer, > will be replacing bcm43xx > in mainstream in the coming months. If that F7 kernel offers b43 as an > option, use it. The > performance of the two drivers is essentially the same; however, the > stability and flexibility of > mac80211 is a great improvement over SoftMAC. The F7 kernel should currently use bcm43xx-mac80211 by default. If you fetch http://david.woodhou.se/bcm43xx-override and put it in /etc/modprobe.d then you'll use the softmac bcm43xx driver instead. That might be worth a try if you have problems with the mac80211 version. Note that each of those require firmware extracted from different versions of the 'official' drivers. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ALERT: firmware change for b43
On Sun, 2007-08-19 at 14:37 -0500, Larry Finger wrote: > It is recommended that you update fwcutter before these patches are > merged. If your version of fwcutter was obtained with subversion, a > simple 'svn update' in the fwcutter directory will suffice. > If you are using a version provided by your distro, you will need to > checkout the latest version with the command 'svn checkout > svn://svn.berlios.de/bcm43xx/trunk/fwcutter'. Ew, Subversion. Hasn't everyone abandoned that yet? I've set up a script to mirror it into git hourly: http://git.infradead.org/?p=b43-fwcutter.git git://git.infradead.org/b43-fwcutter.git -- dwmw2 ___ 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 Fri, 2007-08-03 at 10:19 +0300, John H. wrote: > So there's no way to use bcm43xx while using an rpm kernel? Yes, of course there is. You just have to add the PCI ID of your own card by echoing it to /sys/bus/pci/drivers/bcm43xx/new_id I just have this in /etc/rc.local: /sbin/modprobe bcm43xx echo "14e4 4320" > /sys/bus/pci/drivers/bcm43xx/new_id Failing that, you can just rebuild the bcm43xx module _without_ the PCI IDs removed -- there's no reason for you to rebuild the whole kernel. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Thu, 2007-08-02 at 20:55 -0400, John W. Linville wrote: > I hacked-up the (untested) patch below -- thoughts? I tried to test it. Today, I get no connectivity with bcm43xx-mac80211 (from Fedora 7 + your patch). It does manage to associate, but tcpdump shows it doesn't seem to receive any packets correctly -- http://david.woodhou.se/bcm43xx-bad.txt I tried taking the device down and back up, and setting the WEP key again (I think I've seen it screw up before and have to be told the WEP key again before it starts working), but that didn't help. Removing the module left rmmod and ksoftirqd both eating CPU, so I had to reboot. I don't have time to do any more right now; I might look at it again in a couple of weeks when I get home. But all this ought to be reproduceable elsewhere -- and if it isn't, I have a Cardbus card which seems to be exactly the same rev 4306 as my shinybook's internal device. Give me an address to ship it to :) -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Thu, 2007-08-02 at 18:30 -0400, Daniel Drake wrote: > This may be a stack-level issue. This is one of the issues holding back > zd1211rw-mac80211 going into mainline: we have a report that > zd1211rw-softmac works fine with IPv6 but mac80211 only works > occasionally with the same device on the same system. > > Does anyone have any ideas? It receives its own neighbour solicitation (multicast) packets when the AP sends them back out again. These packets... 23:41:56.046939 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor solicitation, who has fe80::20a:95ff:fef3:9992, length 24 You should be able to see this without _any_ IPv6 infrastructure -- and you'll see the link-local IPv6 address remains 'tentative'. Once you've fixed that, setting up a local route advertisement dæmon (radvd) to give you site-local addresses is fairly trivial too -- and then you can also check that Ethernet multicast is working properly. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211
On Thu, 2007-08-02 at 11:30 -0500, Larry Finger wrote: > I was hoping this would be your response, but I had to make the > effort. I'll wait for a couple of days to see if anyone else has any > comments and send it on to Linville and hope it ends up in -mm fairly > soon. It _DOES_ work on the hardware. My experience is that mac80211 is broken w.r.t IPv6 -- it receives its own packets. It would be suboptimal for me if the softmac version of bcm43xx were to go away before that got fixed. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Tue, 2007-07-31 at 20:26 -0700, Andrew Morton wrote: > Look. Kconfig's `select' Just. Does. Not. Work. If you find > yourself contemplating using it, please, don sackcloth, take a cold > shower and several analgesics, then have another go, OK? Amen. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix specs typo for baseband attenuation
On Thu, 2007-07-26 at 13:49 -0500, Larry Finger wrote: > No matter, the change is needed to make some older cards work. Now I > know why bcm43xx-mac80211 never worked on my BCM4306 until today. Hm, it has worked for me in the past, and your patch fixes it so it works again (at least as well as it ever did). I still get constant complaints of 'eth1: duplicate address detected' due to the fact that it sees its own outgoing packets, and IPv6 doesn't work. Then when unloading the module I get... bcm43xx_mac80211: Radio turned off Freeing alive inet6 address c1cefc80 unregister_netdevice: waiting for eth1 to become free. Usage count = 2 ... and I have to reboot before anything related to networking works again. When I unload the module from X rather than from a vt, the machine sometimes locks up hard -- which I suspect is a different problem, but I have no clue what. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix deviation from specifications in set_baseband_attenuation
On Mon, 2007-07-09 at 22:59 +, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=77548f58070894cf5970a110981e511ffe793369
> Commit: 77548f58070894cf5970a110981e511ffe793369
> Parent: aaf83d4fc4a596929306c894d341e17fbdfba758
> Author: Larry Finger <[EMAIL PROTECTED]>
> AuthorDate: Sat May 26 22:21:29 2007 -0500
> Committer: Jeff Garzik <[EMAIL PROTECTED]>
> CommitDate: Sun Jul 8 22:16:37 2007 -0400
>
> [PATCH] bcm43xx: Fix deviation from specifications in
> set_baseband_attenuation
>
> A disagreement between the specifications and the bcm43xx code has just
> been discovered and is hereby fixed.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
> ---
> drivers/net/wireless/bcm43xx/bcm43xx_phy.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> index b37f1e3..d779199 100644
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> @@ -1638,7 +1638,7 @@ void bcm43xx_phy_set_baseband_attenuation(struct
> bcm43xx_private *bcm,
> return;
> }
>
> - if (phy->analog > 1) {
> + if (phy->analog == 1) {
> value = bcm43xx_phy_read(bcm, 0x0060) & ~0x003C;
> value |= (baseband_attenuation << 2) & 0x003C;
> } else {
> -
This broke my shinybook. I seem to get absolutely _no_ outgoing packets,
although I can receive OK.
bcm43xx: Chip ID 0x4306, rev 0x2
bcm43xx: Number of cores: 6
bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243
bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243
bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243
bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243
bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243
bcm43xx: Detected PHY: Analog: 1, Type 2, Revision 1
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Microcode rev 0x122, pl 0x99 (2005-01-22 22:40:08)
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
On Fri, 2007-07-20 at 00:43 -0400, Pavel Roskin wrote: > > That's a very good goal. > > I would also consider the option to use different names for v3 and v4 > firmware. I have a file /etc/modprobe.d/bcm43xx that reads > > options bcm43xx fwpostfix=.3 > options bcm43xx_mac80211 fwpostfix=.4 > > but we cannot expect every distro (let alone every user) to take care > of the naming conflict. Users don't expect the need to rename > firmware, and we shouldn't create a problem for them. Yes. Please use a suitable postfix for v3 and v4 firmware so that they can coexist. You can always make each driver fall back to the old filename if it doesn't find the firmware with the postfix. We can make the fwcutter write out files with appropriate names too. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Multicast RX and TX both broken
On Fri, 2007-07-13 at 00:24 +0100, David Woodhouse wrote: > On Fri, 2007-07-13 at 00:15 +0100, David Woodhouse wrote: > > I'm going back to the softmac driver for now. Although I might follow up > > with a report of the crash which happens when I the remove > > bcm43xx-mac80211 module. > > Hm, I'm sure it locked the entire machine last time, but this time when > I did it from a console it 'only' did this... > > bcm43xx_mac80211: Radio turned off > unregister_netdevice: waiting for eth1 to become free. Usage count = 5 > unregister_netdevice: waiting for eth1 to become free. Usage count = 5 Accompanied by a bunch of complaints like this... Slab corruption (Not tainted): size-192 start=d8a21b88, len=192 Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [](inet6_ifa_finish_destroy+0x10c/0x120 [ipv6]) 020: 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Multicast RX and TX both broken
On Fri, 2007-07-13 at 11:48 +0100, David Woodhouse wrote: > On Fri, 2007-07-13 at 12:37 +0200, Michael Buesch wrote: > > On Friday 13 July 2007 01:15:28 David Woodhouse wrote: > > > If I run 'tcpdump -p' to refrain from putting it in promiscuous mode, I > > > don't see the RA packet to 33:33:00:00:00:01. And IPv6 autoconfiguration > > > doesn't work. > > > > So, what if you run promisc? > > Then tcpdump sees it, as I showed, but the kernel still doesn't actually > pick up the address it's advertising. [11:55] Where do you think the packet is rejected? At HW, driver or stack level? I'm not sure. Perhaps the macfilter filters it out when the device isn't in promiscuous mode? [11:56] Ah, tcpdump sees the packet. When the device is in promiscuous mode, yes. But not otherwise. So it's not being correctly delivered from mac80211 to the host stack. Maybe because the macfilter eats it, or maybe bcm43xx does receive it and mac80211 assigns it type PACKET_OTHERHOST so it gets ignored. But there's definitely _something_ wrong here. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Multicast RX and TX both broken
On Fri, 2007-07-13 at 12:37 +0200, Michael Buesch wrote: > On Friday 13 July 2007 01:15:28 David Woodhouse wrote: > > If I run 'tcpdump -p' to refrain from putting it in promiscuous mode, I > > don't see the RA packet to 33:33:00:00:00:01. And IPv6 autoconfiguration > > doesn't work. > > So, what if you run promisc? Then tcpdump sees it, as I showed, but the kernel still doesn't actually pick up the address it's advertising. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Multicast RX and TX both broken
Multicast receive is not working in bcm43xx-mac80211 (BCM4306 on
PowerBook G4); Fedora rawhide's 2.6.22-rc7-git3 kernel.
When I bring up the interface, tcpdump shows me these packets...
00:00:42.937394 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6 (0x86dd),
length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor solicitation, who has
fe80::20a:95ff:fef3:9992, length 24
00:00:43.091015 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6 (0x86dd),
length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor solicitation, who has
fe80::20a:95ff:fef3:9992, length 24
00:00:44.951285 00:40:f4:28:95:9d > 33:33:00:00:00:01, ethertype IPv6 (0x86dd),
length 118: fe80::240:f4ff:fe28:959d > ff02::1: ICMP6, router advertisement,
length 64
00:00:44.989337 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6 (0x86dd),
length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor solicitation, who has
2001:8b0:10b:1:20a:95ff:fef3:9992, length 24
If I run 'tcpdump -p' to refrain from putting it in promiscuous mode, I
don't see the RA packet to 33:33:00:00:00:01. And IPv6 autoconfiguration
doesn't work.
It _does_, however, see its own outgoing neighbour solicitation packet
as if it came from another host on the network, leading to messages
saying 'eth1: duplicate address detected!' and the IPv6 link-local
address being marked as 'tentative' and never actually working (until I
remove it and add it again manually, after which the reception of RA
packets _still_ doesn't work).
You can test this by just building with IPv6 support, and observing the
output of 'ip -6 addr list'. When it's seeing its own packets, it looks
like this:
5: eth1: mtu 1500 qlen 1000
inet6 fe80::20a:95ff:fef3:9992/64 scope link tentative
When it's working properly, that 'tentative' isn't there.
You can test multicast RX by running radvd on the network -- you don't
need proper IPv6 connectivity; you can do it with site-local addresses
with a configuration like the following (run this on _another_ machine
on the network; either on the wireless or bridged to it):
interface eth1
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix fec0::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
I'm going back to the softmac driver for now. Although I might follow up
with a report of the crash which happens when I the remove
bcm43xx-mac80211 module.
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Multicast RX and TX both broken
On Fri, 2007-07-13 at 00:15 +0100, David Woodhouse wrote: > I'm going back to the softmac driver for now. Although I might follow up > with a report of the crash which happens when I the remove > bcm43xx-mac80211 module. Hm, I'm sure it locked the entire machine last time, but this time when I did it from a console it 'only' did this... bcm43xx_mac80211: Radio turned off unregister_netdevice: waiting for eth1 to become free. Usage count = 5 unregister_netdevice: waiting for eth1 to become free. Usage count = 5 -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: F7 with newer kernel
On Thu, 2007-06-28 at 13:30 -0700, Ehud Gavron wrote: > # cd /usr/src > # git clone > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git > # ln wireless-dev linux > # cd /usr/src/linux > # cp /usr/src/kernels/2.6.21-1.3228.fc7-x86_64/.config ./.config > # make clean > # make oldconfig > (Answer the questions any way you like... hitting enter a bunch of times > works.) > # grep -i bcm43xx .config (mine is included below) > # time nice make bzImage(mine takes 9 min) > # time nice make modules(mine takes 44 min) > # time nice make modules_install (mine takes 1 min) > # time nice make install(mine takes 1 min) > # sed -i -e "s/default=1/default=0/g" /etc/grub.conf You shouldn't need to rebuild the whole kernel. Just make sure kernel-devel is installed and build the drivers you want. sudo yum install kernel-devel cd git-clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git cd wireless-dev/drivers/net/wireless/mac80211/bcm43xx make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules sudo rmmod bcm43xx-mac80211 \; insmod ./bcm43xx-mac80211.ko -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: IPV6 autoconf problems
On Fri, 2007-05-25 at 20:13 +0100, Steve Hill wrote:
> On Fri, 25 May 2007, Johannes Berg wrote:
>
> > I'd like to have packet dumps of the master interface, a monitor
> > interface and the actual interface that has the problem simultaneously,
>
> http://www.nexusuk.org/~steve/iwl3945-ipv6/ap.pcap
> http://www.nexusuk.org/~steve/iwl3945-ipv6/wlan0.pcap
>
> The set up I have is:
>
>Internet=Router=AccessPoint-Notebook
>
> (= is 100Mbps ethernet, - is 802.11g)
>
> The router is doing IPv6 router advertisements, the notebook is supposed
> to be using them to configure the IPv6 address on it's wlan0 interface (an
> iwl3945). The access point is a LinkSys WRT54GL running OpenWRT
> WhiteRussian and is just bridging the wired network to the wireless
> network.
>
> So, ap.pcap is a dump from the 802.11 interface on the access point.
> wlan0.pcap is a dump from the 802.11 interface on the notebook.
>
> The sequence of events is basically:
> 1. Router sends advertisement
> 2. Notebook receives advertisement
> 3. Notebook picks an IP address and sends a neighbor solicitation to see
> if anyone else is already using that address.
>
> (these 3 steps happen twice in these network dumps).
>
> The dump taken on the access point clearly shows that the notebook sends
> just one neighbor solicitation for each router advertisement it receives.
> However, the dump taken on the notebook shows two neighbor solicitation
> messages for each router advertisement.
>
> Seems reasonably conclusive - it looks like the notebook is sending a
> neighbor solicitation and is then receiving it's own data again.
Seems like a reasonable conclusion. Does this 'fix' it?
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index d8b3645..289375c 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -716,7 +716,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
if (dad) {
- if (dev->type == ARPHRD_IEEE802_TR) {
+ if (1) {
const unsigned char *sadr;
sadr = skb_mac_header(skb);
if (((sadr[8] ^ dev->dev_addr[0]) &
0x7f) == 0 &&
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: IPV6 autoconf problems
On Fri, 2007-05-18 at 19:51 +0200, Andrea Lusuardi - UoVoBW wrote: > May 18 16:08:24 electricmove kernel: wlan0: duplicate address detected! > May 18 16:10:19 electricmove kernel: wlan0: duplicate address detected! > May 18 16:11:45 electricmove kernel: wlan0: duplicate address detected! > -a lot of lines snipped- > > and it can go on for hours: sometimes the ipv6 is negotiated after 2 or > 3 "duoplicate address" messages, sometimes it will take the whole day, > sometimes it will never work. Steve (Cc'd) has reported something very similar on iwl3945, and has offered the sane-sounding hypothesis that it's seeing its own outgoing packets when it shouldn't. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: IPV6 autoconf problems
On Tue, 2007-05-22 at 20:38 +0200, Andrea Lusuardi - UoVoBW wrote: > On Tue, 22 May 2007 08:32:11 -0400 > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > If you can test it at a time the network is otherwise fairly idle, and > > just bring your bcm43xx up with 'ip link set eth1 up' rather than > > assigning it a Legacy IP address, > > with "legacy ip address" you mean not using dhclient nor static > configuration, i would just: > > modprobe bcm43xx-mac80211 > ifconfig wlan0 up > iwconfig SETTINGS > - in the log ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready - > ip link set wlan0 up > > right? or am i supposed to substitute the "ifconfig wlan0 up" with the > ip link command? They do the same thing. So you don't need to do it a second time after running iwconfig. > i noticed that, if i do not up the card _before_ iwconfig it, it wont > get any association/authentication. Hm, that's a bug. The softmac driver used to suffer that too, but it's fixed now. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: IPV6 autoconf problems
On Tue, 2007-05-22 at 09:08 +0200, Andrea Lusuardi - UoVoBW wrote: > The debian config of radvd was quite simple and yes, this is true.I set > this up on my access point and it behaved as you described. > How can this be fixed? Well, I'd start by showing the main developers how to reproduce it :) If you can test it at a time the network is otherwise fairly idle, and just bring your bcm43xx up with 'ip link set eth1 up' rather than assigning it a Legacy IP address, then there should be _very_ little traffic -- but it _should_ do router discovery and pick up an IPv6 address. Use tcpdump at both ends, and compare the results. I have a very strong suspicion that you'll find there are multicast Ethernet packets getting lost in transit. > is there a way to use radvd to talk to the other radvd - which i asked > and is used to configure ip6 connectivity at my university - ad force > it to send the configurations? No. radvd only advertises routes for a single subnet. It advertises the 'prefix' -- the upper 64 bits -- and the lower 64 bits are generated by the individual station, from a permutation of that station's MAC address. The station assumes the default route is out via the machine which was running radvd. If you want to run radvd with a 'real' global address and provide proper connectivity, then you have to have a subnet of your own for radvd to advertise. With '6to4' that's actually dead easy -- you get a whole /48 of IPv6 addresses for every public IPv4 address, which means 65536 separate /64 subnets of your own. It's better to get 'proper' IPv6 connectivity though, if you can -- either through a tunnel such as from somewhere like sixxs.net, or just ask the university to assign you some space and tunnel it to you. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: IPV6 autoconf problems
On Fri, 2007-05-18 at 19:51 +0200, Andrea Lusuardi - UoVoBW wrote:
>
> but that makes no difference.
> Any help would be highly appreciated, and i have no problem providing
> more debug - once i know what to write - or even ssh access to my
> laptop
> - ibook g4 with a bcm4306 card,
I've seen the same problem -- it'll be a generic problem with Ethernet
multicast.
Anyone can set up radvd to test this -- they don't even need proper IPv6
connectivity (although that's trivial to arrange too). They can just set
it up with site-local addresses (the fec0::/16 subnet).
On any machine on the subnet, just 'ip -6 addr add fec0::1/64 dev
eth0' (or whatever the equivalent is in your distribution's network
config scripts), install radvd and set up /etc/radvd.conf to look
something like this...
interface eth1
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix fec0::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
You'll find that with the softmac bcm43xx driver, you pick up an address
like fec0::20a:95ff:fef3:9992 automatically, fairly reliably. With the
mac80211 version, it works much more rarely, and slowly. You can tcpdump
and watch for the multicast traffic at both ends.
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs
On Thu, 2007-04-12 at 20:22 -0500, Larry Finger wrote:
> Your tester needs to get a copy of David's hack that prints out the address
> of the offending
> register. That is the only way to tell what is happening. Once we know the
> address, then it will be
> a matter of getting printk's into the code to tell which one is failing.
It's very simple... if we use inw instead of readw for the faulting I/O
access, then the machine check gets trapped. We can do this because on
PPC, PCI I/O is actually memory-mapped. The CPU doesn't have a separate
I/O space and instructions. So we just compensate for the address at
which PCI I/O is mapped, and abuse inw().
Then we make bcm43xx_phy_read() print the register it tried to access
whenever it gets 0x, and stick a WARN_ON(1) in the machine check
handler when it detects a machine check caused by an I/O access...
--- ../linux-2.6.20.ppc64/./drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
2007-04-14 21:51:02.0 +0100
+++ ./drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c 2007-04-16
01:39:44.0 +0100
@@ -269,10 +270,13 @@ static inline u16 adjust_phyreg_for_phyt
u16 bcm43xx_phy_read(struct bcm43xx_wldev *dev, u16 offset)
{
struct bcm43xx_phy *phy = &dev->phy;
-
+ uint16_t foo;
offset = adjust_phyreg_for_phytype(phy, offset);
bcm43xx_write16(dev, BCM43xx_MMIO_PHY_CONTROL, offset);
- return bcm43xx_read16(dev, BCM43xx_MMIO_PHY_DATA);
+ foo = bcm43xx_read16(dev, BCM43xx_MMIO_PHY_DATA);
+ if (foo == 0x)
+ printk(KERN_DEBUG "Read phy reg %x; got 0x.\n", offset);
+ return foo;
}
void bcm43xx_phy_write(struct bcm43xx_wldev *dev, u16 offset, u16 val)
--- ../linux-2.6.20.ppc64/./drivers/ssb/pci.c 2007-04-14 21:51:02.0
+0100
+++ ./drivers/ssb/pci.c 2007-04-15 23:44:27.0 +0100
@@ -475,6 +475,7 @@ static u16 ssb_pci_read16(struct ssb_dev
if (unlikely(ssb_pci_switch_core(bus, dev)))
return 0x;
}
+ return inw(bus->mmio + offset - isa_io_base);
return readw(bus->mmio + offset);
}
--- ../linux-2.6.20.ppc64/./arch/powerpc/kernel/traps.c 2007-04-14
21:50:40.0 +0100
+++ ./arch/powerpc/kernel/traps.c 2007-04-15 23:45:48.0 +0100
@@ -343,8 +343,10 @@ void machine_check_exception(struct pt_r
return;
}
- if (check_io_access(regs))
+ if (check_io_access(regs)) {
+ WARN_ON(1);
return;
+ }
#if defined(CONFIG_4xx) && !defined(CONFIG_440A)
if (reason & ESR_IMCP) {
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs
On Mon, 2007-04-16 at 01:06 +0100, David Woodhouse wrote: > On Fri, 2007-04-13 at 17:17 +0200, Johannes Berg wrote: > > With phy rev == 1, the gmode bit is assumed unset when initialising a > > G PHY. Maybe that is the crucial difference. David will send me some > > backtraces of this problem, once he does I'll look at it again. > > http://david.woodhou.se/bcm43xx-mac80211.dmesg-3.txt > > The module itself is at http://david.woodhou.se/bcm43xx-mac80211.ko so > you can find line numbers where they're not immediately obvious. That was without Larry's latest patch applied. If I apply Larry's patch, we get fewer machine checks... http://david.woodhou.se/bcm43xx-mac80211-lf.dmesg.txt http://david.woodhou.se/bcm43xx-mac80211-lf.ko Strange, I thought that when I'd tested Larry's patch I was left with _no_ machine checks. Perhaps at that point I still had a printk on every PHY read or write and the machine checks were lost in the noise. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs
On Fri, 2007-04-13 at 17:17 +0200, Johannes Berg wrote: > With phy rev == 1, the gmode bit is assumed unset when initialising a > G PHY. Maybe that is the crucial difference. David will send me some > backtraces of this problem, once he does I'll look at it again. http://david.woodhou.se/bcm43xx-mac80211.dmesg-3.txt The module itself is at http://david.woodhou.se/bcm43xx-mac80211.ko so you can find line numbers where they're not immediately obvious. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine checks with bcm43xx-mac80211
On Wed, 2007-04-11 at 00:13 -0500, Larry Finger wrote:
> David Woodhouse wrote:
> > I figured if people were going to start working more on the mac80211
> > driver than the softmac one, I probably ought to start reporting the
> > cases where it kills my machine. So I hacked up ssb_pci_{read,write}16
> > to use outw instead of readw and thus get their machine checks trapped.
> >
> > This is what I found...
>
> Please try the patch below to see if it fixes the machine checks. It is the
> equivalent of what we
> used in bcm43xx-softmac to get rid of them.
Yeah, that works -- at least, it avoids the machine checks. I still
don't get much connectivity though. Just running tcpdump isn't enough to
make it pick up and IPv6 address, and it's missing a lot of incoming
Legacy IP packets too. In fact I don't seem to get _any_ incoming
packets if I bring it up manually; it only works at all when I let
NetworkManager bring it up.
I'll investigate more in a nicer environment when I get home tomorrow --
testing it in the OLPC office sitting underneath a ceiling with about 20
XO machines running as mesh portals probably isn't fair :)
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine checks with bcm43xx-mac80211
On Wed, 2007-04-11 at 00:19 -0400, David Woodhouse wrote:
> I figured if people were going to start working more on the mac80211
> driver than the softmac one, I probably ought to start reporting the
> cases where it kills my machine. So I hacked up ssb_pci_{read,write}16
> to use outw instead of readw and thus get their machine checks
> trapped.
>
> This is what I found...
Then the performance was poor and NetworkManager kept getting
disconnected. I'd have tried forcing the rate down to 11Mb/s or lower,
but my iwconfig didn't seem to work because it was too old. I'll
investigate that later.
I saw this at one point too..
> <3>bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring
> failed. (cur=0, tgt=62). Disabling TX power adjustment.
I also didn't get IPv6 addresses by RA... at least until I tried to
investigate. Perhaps it was the tcpdump which made it work -- perhaps
multicast is broken and I only picked up the address when I put it in
promiscuous mode?
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Machine checks with bcm43xx-mac80211
I figured if people were going to start working more on the mac80211
driver than the softmac one, I probably ought to start reporting the
cases where it kills my machine. So I hacked up ssb_pci_{read,write}16
to use outw instead of readw and thus get their machine checks trapped.
This is what I found...
shinybook /home/dwmw2 # head -20 dmesg.txt
ssb: Sonics Silicon Backplane found on PCI device 0001:10:12.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: Switching to PCI core, index 4
bcm43xx_mac80211: Broadcom 4306 WLAN found
ssb: Switching to IEEE 802.11 core, index 1
phy_read (adjusted) 10...phy_write 10 to 161e...ok
phy_read (adjusted) 11...phy_write 11 to 198...ok
phy_write 15 to aa00...ok
bcm43xx_mac80211: Radio turned off
phy_write 15 to e300...ok
phy_write 812 to 2030...ok
phy_write 812 to 2032...ok
phy_write 812 to 2033...ok
phy_write 15 to f300...ok
shinybook /home/dwmw2 # grep bad dmesg.txt | sort -u
phy_read (adjusted) 429...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 814...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 47f...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 48a...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 4a0...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 4a1...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 4a2...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 814...<7>IN from bad port f54c53fe at f22b7dc0
phy_read (adjusted) 815...<7>IN from bad port f54c53fe at f22b7dc0'
There's also a _lot_ of 'eth1: received unknown management frame - stype=13'
Full(ish) log from /var/log/messages at
http://david.woodhou.se/mac80211-dmesg.txt
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
On Mon, 2007-04-09 at 01:18 -0500, Larry Finger wrote: > I have started a project to build an out-of-tree version of bcm43xx, > but it isn't ready for prime time. 'cp -r drivers/net/wireless/bcm43xx ~/bcm43xx-for-hacking-on' usually works for me. Then it's just $ cd ~/bcm43xx-for-hacking-on $ make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
On Mon, 2007-04-09 at 01:06 -0500, Larry Finger wrote: > I scanned the reference quickly, but I think you have downloaded the Fedora > kernel sources. If so, > in step 2.3 you should use the line 'wget > ftp://lwfinger.dynalias.org/patches/combined_2.6.20.2.patch' (I think I > recall that you were using > 2.6.20.2.). You will need to modify 'kernel-2.6.spec' to change the name of > the patch, then rebuild > as stated. This will get you a patched set of bcm43xx source files. But really, even if you _wanted_ to rebuild your kernel that reference is giving bad advice; you'd do better to check the RPM sources out from CVS and make them that way. It's doubly bad for not starting with "YOU REALLY DON'T WANT TO BUILD YOUR OWN KERNEL" in big letters. Just build bcm43xx as an out-of-tree module, to work against the kernel which is shipped with Fedora. You don't need to rebuild the kernel. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
On Sun, 2007-04-08 at 11:17 -0500, John H. wrote: > I was looking for some binary solution for now, as my fedora kernel is > Linux laptop 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 > i686 i686 i386 GNU/Linux > > And I have stopped compiling own kernels due to lack of time. Why would you rebuild the whole kernel and not just the bcm43xx driver? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Change initialization for 2050 radios
On Thu, 2007-03-29 at 13:11 -0500, Larry Finger wrote: > OK, you are measuring receive speed, which is nearly independent of > Bit Rate. Do you have access to any other host on your LAN that could > be an Iperf server, or that is an NFS server? That can be done. Need to get Fedora PS3 kernel working properly first though... -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Change initialization for 2050 radios
On Thu, 2007-03-29 at 12:57 -0500, Larry Finger wrote: > Is the better performance for 11M in transmitting or receiving? How is > it measured? My 4306's, which should be the same as yours, do better > at 24M than at 11M. It's for 'scp shinybook:' -- it's not a particularly good test. And in fact the 'normal' module seems to be performing quite well today too. I think the real performance problem comes when there are dropped packets. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Change initialization for 2050 radios
On Wed, 2007-03-28 at 11:07 -0500, Larry Finger wrote: > This patch implements the changes in the specifications for > 2050radio_init that were recently posted. That seems to help performance quite a lot -- although 'rate 11M' still runs a _lot_ faster than the 24M which the driver seems to settle at by default, when it's sitting 1m from the AP. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine checks on PPC with phy->rev == 1
On Wed, 2007-03-28 at 09:17 -0500, Larry Finger wrote:
>
> I have been working off-line with David Woodhouse and Pavel Roskin to sort
> out machine checks on PPC
> hardware with a phy->rev == 1 card. As you likely recall, we submitted a
> patch that fixed two
> distinct places in the code. One of them was a typo in the specs, but the
> other was found
> empirically by David. Those have been fixed with a patch now queued with
> Linus for 2.6.21.
>
> We did find an additional problem when I modified the phy_initg code to match
> the latest specs of
> 3/25/07. Now we get a problem in calc_loopback_gain, which David has
> localized to PHY registers
> 0x0814 and 0x0815. Based on earlier code in phy_initg (Step 4), it seems that
> those two registers
> should be touched in this section only if phy->rev >= 2. Is there anything in
> the bcom driver to
> support this?
FWIW this hack makes finding the machine checks _much_ easier...
--- bcm43xx_phy.c~ 2007-03-28 11:10:42.0 +0100
+++ bcm43xx_phy.c 2007-03-28 12:15:34.0 +0100
@@ -131,8 +131,13 @@ u16 bcm43xx_phy_read(struct bcm43xx_priv
{
uint16_t foo;
printk("phy_read %x...", offset);
+#if 0
bcm43xx_write16(bcm, BCM43xx_MMIO_PHY_CONTROL, offset);
foo = bcm43xx_read16(bcm, BCM43xx_MMIO_PHY_DATA);
+#else
+ outw(offset, bcm->mmio_addr + core_offset(bcm) +
BCM43xx_MMIO_PHY_CONTROL - isa_io_base);
+ foo = inw(bcm->mmio_addr + core_offset(bcm) + BCM43xx_MMIO_PHY_DATA -
isa_io_base);
+#endif
printk(" = %x\n", foo);
return foo;
}
Coupled with printks in bcm43xx_phy_{read,write} I get no crashes any
more; just helpful output like...
phy_read 1... = 0
phy_read 811... = 0
phy_read 812... = 3
phy_read 814...<7>IN from bad port f59f53fe at f22b57ec
=
phy_read 815...<7>IN from bad port f59f53fe at f22b57ec
=
phy_read 5a... = 0
phy_read 59... = 0
phy_read 58... = 4
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
On Sun, 2007-03-25 at 21:33 -0500, Larry Finger wrote: > Joseph has fixed the problem in initb5 (the first hunk), but the second hunk > is still not in the new > specs. It was in the previous version in a slightly different form, but was > found largely by trial > and error. > > I would prefer that this patch go forward as is so that we don't end up with > this bug in the > released version of 21.6.21. I am in the process of making the initg code > match the current specs, > but that will certainly require more testing than I think we have time to > complete before 2.6.21 is > released. FWIW I tried the mac80211 version (with v4 firmware) and saw very similar machine checks, even after trying to apply the same 'fixes'. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
On Sun, 2007-03-25 at 13:23 -0500, Larry Finger wrote: > There aren't any. Joseph is making the changes to the V4 specs, most > of which are valid for V3 as well. If I have any questions, I ask him > privately. There is an important difference between the v3 and v4 specs in this respect. Looking at http://bcm-v4.sipsolutions.net/802.11/PHY/Init/G I see in §7a that we're only supposed to set PHY register 0x4cc if the A PHY revision is 5. The v3 specs seem to suggest that we should do that whenever the revision is below 6 and not equal to 3. The A PHY revision in my case is 2, and it's the access to PHY register 0x4CC which triggers the machine check. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
On Sun, 2007-03-25 at 16:13 +0200, Michael Buesch wrote: > I'm not sure this patch is complete. > Joseph made changes to the specs that should fix the issue completely. > I didn't look at the changes, yet. I don't see relevant changes in the v3 specs. I was working empirically, reverting parts of the large patch which broke it. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix typo in B5PHY init specifications
On Mon, 2007-03-12 at 10:53 -0400, John W. Linville wrote: > > FWIW, by inspection it looks like the mac80211-based driver is > (trying?) to implement this change. > > David, have you tried the mac80211 version? Does it still have the > same crash? Should the one in 2.6.20-1.2982.fc7 be OK? I can try that relatively easily; anything else might need to wait till I get home. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix typo in B5PHY init specifications
On Fri, 2007-03-02 at 11:30 -0600, Larry Finger wrote: > There was an error in the B5PHY init specifications. This patch doesn't fix the machine check in bcm43xx_phy_initb5 which Pavel Roskin and I reported a couple of weeks ago. To get rid of that crash, I still have to revert an earlier 'spec update' patch (740ac4fb08866d702be90f167665d03759bd27d0). -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4306 of PowerPC: machine check in ssb_pci_read16
On Wed, 2007-02-21 at 12:22 -0500, Pavel Roskin wrote: > > I've got my hands on a 4306 MiniPCI card, and I put it into a Blue&White > G3 PowerMac though a MiniPCI to PCI adapter. I tried the current code > from wireless-dev.git. > > The softmac bcm43xx driver would load. The scanning works, but the > association times out (sorry, I forgot to save the logs). That's a > 802.11g AP that my 4311 card easily associates to with the same driver. > > The d80211 driver crashes when I try to bring the interface up: I see something very similar when I use wireless-dev.git (courtesy of the latest Fedora rawhide kernel package) on my PowerBook: http://david.woodhou.se/bcm43xx-d80211.dmesg I also see a similar crash with the ieee80211 driver: http://david.woodhou.se/bcm43xx.dmesg With older kernels (2.6.20-rc4-git4) it works fine: http://david.woodhou.se/bcm43xx-working.dmesg -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[2.6.20 PATCH] Fix work_struct fallout in ieee80211softmac
Change non-work invocations of ieee80211softmac_assoc_work() to use
'&mac->associnfo.work.work' instead of just passing the 'mac' structure
directly.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index e3f37fd..4d270ed 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work);
}
static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struct net_device *dev,
int event_type, void
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ibook issues
On Sat, 2006-11-18 at 19:29 +0100, Michael Buesch wrote: > > > Using kernel version 2.6.17, bcm43xx-fwcutter version 20060501 > > Upgrade the kernel. > We can only support current stable kernel. Well, with the exception that I still know of at least one Fedora user whose bcm43xx works fine with the original Fedora Core 5 kernel and the early version of bcm43xx which was in there, but doesn't work with any kernel after (or including) the first version that got merged to Linus' tree. :) -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Associate on 'ifconfig up'
On Sun, 2006-05-07 at 15:06 +0200, Michael Buesch wrote: > On Saturday 06 May 2006 20:24, David Woodhouse wrote: > > On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote: > > > I still need this hack to work around the fact that softmac doesn't > > > attempt to associate when we bring the device up... > > > > It'd be quite good to get this fixed in 2.6.17 too. Otherwise, the > > device doesn't manage to associate if you use the fairly common sequence > > of iwconfig then dhclient. > > > > It's a bit of an evil hack and it should really be fixed in softmac -- > > but it's only moving an _existing_ hack from one place in the driver to > > another. > > > > Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > John, please try to push this before 2.6.17. > Thanks. This didn't make it into the tree that Linus just pulled? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Associate on 'ifconfig up'
On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote: > I still need this hack to work around the fact that softmac doesn't > attempt to associate when we bring the device up... It'd be quite good to get this fixed in 2.6.17 too. Otherwise, the device doesn't manage to associate if you use the fairly common sequence of iwconfig then dhclient. It's a bit of an evil hack and it should really be fixed in softmac -- but it's only moving an _existing_ hack from one place in the driver to another. Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> --- linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c.orig 2006-05-05 17:14:26.0 +0100 +++ linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 17:15:19.0 +0100 @@ -3263,6 +3263,9 @@ static int bcm43xx_init_board(struct bcm bcm43xx_sysfs_register(bcm); //FIXME: check for bcm43xx_sysfs_register failure. This function is a bit messy regarding unwinding, though... + /*FIXME: This should be handled by softmac instead. */ + schedule_work(&bcm->softmac->associnfo.work); + assert(err == 0); out: return err; @@ -3937,9 +3940,6 @@ static int bcm43xx_resume(struct pci_dev netif_device_attach(net_dev); - /*FIXME: This should be handled by softmac instead. */ - schedule_work(&bcm->softmac->associnfo.work); - dprintk(KERN_INFO PFX "Device resumed.\n"); return 0; -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine check in bcm43xx_phy_initg
On Fri, 2006-05-05 at 19:42 +0200, Michael Buesch wrote: > > Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > John, please apply. I will also send a patch for d80211. Would be good to get this into 2.6.17 too. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine check in bcm43xx_phy_initg
On Fri, 2006-05-05 at 12:59 -0400, Joseph Jezak wrote:
> I fixed the specs, it should be bcm->chip_package == 2, sorry for the
> mistake.
Thanks. The correct patch should look like this then...
[BCM43xx] Fix access to non-existent PHY registers
Fix the conditions under which we poke at the APHY registers in
bcm43xx_phy_initg() to avoid a machine check on chips where they don't
exist.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- linux-2.6.16.ppc64/drivers/net/wireless/bcm43xx/bcm43xx_phy.c~
2006-05-04 19:16:09.0 +0100
+++ linux-2.6.16.ppc64/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
2006-05-05 17:22:57.0 +0100
@@ -1287,7 +1287,7 @@ static void bcm43xx_phy_initg(struct bcm
if (radio->revision == 8)
bcm43xx_phy_write(bcm, 0x0805, 0x3230);
bcm43xx_phy_init_pctl(bcm);
- if (bcm->chip_id == 0x4306 && bcm->chip_package != 2) {
+ if (bcm->chip_id == 0x4306 && bcm->chip_package == 2) {
bcm43xx_phy_write(bcm, 0x0429,
bcm43xx_phy_read(bcm, 0x0429) & 0xBFFF);
bcm43xx_phy_write(bcm, 0x04C3,
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Associate on 'ifconfig up'
I still need this hack to work around the fact that softmac doesn't attempt to associate when we bring the device up... --- linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c.orig 2006-05-05 17:14:26.0 +0100 +++ linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 17:15:19.0 +0100 @@ -3263,6 +3263,9 @@ static int bcm43xx_init_board(struct bcm bcm43xx_sysfs_register(bcm); //FIXME: check for bcm43xx_sysfs_register failure. This function is a bit messy regarding unwinding, though... + /*FIXME: This should be handled by softmac instead. */ + schedule_work(&bcm->softmac->associnfo.work); + assert(err == 0); out: return err; @@ -3937,9 +3940,6 @@ static int bcm43xx_resume(struct pci_dev netif_device_attach(net_dev); - /*FIXME: This should be handled by softmac instead. */ - schedule_work(&bcm->softmac->associnfo.work); - dprintk(KERN_INFO PFX "Device resumed.\n"); return 0; -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Machine check in bcm43xx_phy_initg
My PowerBook machine checks when we poke at PHY register 0x0429. Not
sure if this patch is entirely correct, but it seems to be sufficient,
and certainly serves to document the problem succinctly...
I'm guessing at 'phy->rev >= 2' just because we seem to use that to
check whether we should call bcm43xx_calc_loopback_gain(), which is the
only other code which pokes at this register.
--- linux-2.6.16.ppc64/drivers/net/wireless/bcm43xx/bcm43xx_phy.c~
2006-05-04 19:16:09.0 +0100
+++ linux-2.6.16.ppc64/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
2006-05-05 17:22:57.0 +0100
@@ -1287,7 +1287,7 @@ static void bcm43xx_phy_initg(struct bcm
if (radio->revision == 8)
bcm43xx_phy_write(bcm, 0x0805, 0x3230);
bcm43xx_phy_init_pctl(bcm);
- if (bcm->chip_id == 0x4306 && bcm->chip_package != 2) {
+ if (bcm->chip_id == 0x4306 && phy->rev >= 2) {
bcm43xx_phy_write(bcm, 0x0429,
bcm43xx_phy_read(bcm, 0x0429) & 0xBFFF);
bcm43xx_phy_write(bcm, 0x04C3,
bcm43xx: Chip ID 0x4306, rev 0x2
bcm43xx: Number of cores: 6
bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled
bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
bcm43xx: Ignoring additional 802.11 core.
bcm43xx: PHY connected
bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: link status and association
On Fri, 2006-04-14 at 11:06 +0200, Yves-Alexis Perez wrote: > iirc you -always- had to mount the interface *before* associating. When > you modprobe the module the radio is turned off, mounting the interface > does enable the radio. dmesg outputs are pretty clear on it: Yes, that's a bug. I fixed this in the Fedora Core 5 kernel -- I'm fairly sure I also sent the patch here. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: System Lockup
On Sun, 2006-04-02 at 01:43 -0800, Christopher Stone wrote: > I tried the bcm43xx drivers that come with Fedora Core 5, however my > system totally freezes and locks up when I modprobe bcm43xx Precisely which kernel version? The one which came with FC5, or the current updated kernel? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No NetworkManager
On Thu, 2006-03-30 at 02:52 -0700, Nix N. Nix wrote:
> Does the 2006-03-30 all-in-one snapshot contain these changes ? I have
> tried the latest snapshot with NetworkManager, but to no avail.
I think it should -- certainly everything was submitted. However, I was
testing with the NetworkManager from FC4, not the new one from FC5. With
_new_ versions of NetworkManager you need one more change, which Dan
Williams provided. It makes softmac produce a standard 'association'
event, rather than a custom event of its own.
This makes the new NetworkManager work for me with WEP, although WPA
still doesn't work (unless I use wpa_supplicant manually). That's in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183245
WPA doesn't work with a network which doesn't broadcast its SSID either
-- not even with wpa_supplicant, unless I use the evil hack at
http://david.woodhou.se/wpa_supplicant-hack.patch
---
[SOFTMAC] Send WEXT assoc/disassoc events to userspace
For whatever reason, softmac is sending custom events to userspace
already, but it should _really_ be sending the right WEXT events
instead.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- a/include/net/ieee80211softmac.h.assoc 2006-03-09 13:14:56.0
-0500
+++ b/include/net/ieee80211softmac.h2006-03-09 13:15:22.0 -0500
@@ -267,8 +267,9 @@
#define IEEE80211SOFTMAC_EVENT_AUTH_FAILED 5
#define IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT6
#define IEEE80211SOFTMAC_EVENT_ASSOCIATE_NET_NOT_FOUND 7
+#define IEEE80211SOFTMAC_EVENT_DISASSOCIATED 8
/* keep this updated! */
-#define IEEE80211SOFTMAC_EVENT_LAST7
+#define IEEE80211SOFTMAC_EVENT_LAST8
/*
* If you want to be notified of certain events, you can call
* ieee80211softmac_notify[_atomic] with
--- a/net/ieee80211/softmac/ieee80211softmac_event.c.assoc 2006-03-09
13:05:09.0 -0500
+++ b/net/ieee80211/softmac/ieee80211softmac_event.c2006-03-09
15:21:12.0 -0500
@@ -67,6 +67,7 @@
"authenticating failed",
"authenticating timed out",
"associating failed because no suitable network was found",
+ "disassociated",
};
@@ -128,13 +129,32 @@
ieee80211softmac_call_events_locked(struct ieee80211softmac_device *mac, int
event, void *event_ctx)
{
struct ieee80211softmac_event *eventptr, *tmp;
- union iwreq_data wrqu;
- char *msg;
if (event >= 0) {
- msg = event_descriptions[event];
- wrqu.data.length = strlen(msg);
- wireless_send_event(mac->dev, IWEVCUSTOM, &wrqu, msg);
+ union iwreq_data wrqu;
+ int we_event;
+ char *msg = NULL;
+
+ if (event == IEEE80211SOFTMAC_EVENT_ASSOCIATED) {
+ struct ieee80211softmac_network *network =
+ (struct ieee80211softmac_network *)event_ctx;
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memcpy(wrqu.ap_addr.sa_data, &network->bssid[0],
ETH_ALEN);
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ we_event = SIOCGIWAP;
+ } else if (event == IEEE80211SOFTMAC_EVENT_DISASSOCIATED) {
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memset(&wrqu, '\0', sizeof (union iwreq_data));
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ we_event = SIOCGIWAP;
+ } else {
+ msg = event_descriptions[event];
+ wrqu.data.length = strlen(msg);
+ we_event = IWEVCUSTOM;
+ }
+ wireless_send_event(mac->dev, we_event, &wrqu, msg);
}
if (!list_empty(&mac->events))
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c.assoc 2006-03-09
13:13:54.0 -0500
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c2006-03-09
13:21:00.0 -0500
@@ -104,6 +104,7 @@
/* Do NOT clear bssvalid as that will break
ieee80211softmac_assoc_work! */
mac->associated = 0;
mac->associnfo.associating = 0;
+ ieee80211softmac_call_events_locked(mac,
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
spin_unlock_irqrestore(&mac->lock, flags);
}
@@ -378,6 +379,7 @@
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.bssvalid = 0;
mac->associated = 0;
+ ieee80211softmac_call_events_locked(mac,
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: softmac interface naming
On Tue, 2006-03-28 at 08:46 -0600, Timothee Besset wrote: > Worse than naming the wireless interface eth%d, it also calls it eth0 > or eth1 randomly on my machine. That's reason enough to force a > specific name for me. Simon, check this thread in the forums: > http://bcm43xx.spugna.org/index.php?topic=18.0 That happens on my machine too, but the MAC address is consistent, the network scripts (and NetworkManager) cope with that, and it all works fine. The names just aren't that relevant. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: softmac interface naming
On Tue, 2006-03-28 at 02:11 -0500, Simon wrote: > Are there any plans to change softmac so that wireless interfaces > aren't tr= > eated as wired interfaces? Don't send HTML to public fora. The question doesn't make much sense. With the current code, I treat mine as a wireless interface -- surely that's just up to the user's policy? It doesn't need any changes in softmac. I suspect you're actually asking if there's an plan to assign bizarre _names_ to the device rather than using the standard 'eth%d'? I'm not aware of any plans, or any reason why anyone would want such a thing. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Starter guide needed
On Fri, 2006-03-24 at 22:10 -0500, Robert Wilkens wrote: > Can someone point me towards any documentation on how to get started > with the driver? (No hurry) > > I've been trying to get the bcm43xx standalone driver to work (Dell > Wireless 1450 card), and have been having some issues. > > This is on Fedora Core 5, which is said to also include a version of the > driver. I just don't know how to use it if it's there. http://lists.infradead.org/pipermail/fedora-ppc/2006-March/000804.html -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] Avoid lockup with ->set_channel() on card when it's down.
If the device is taken down during a scan, the bcm43xx driver can lock
up the system the next time ->set_channel() is called. This avoids the
lockup by checking whether the card is running before poking at it.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c~
2006-03-22 16:52:18.0 +
+++ linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-03-24 10:57:53.0 +
@@ -3937,9 +3937,13 @@ static void bcm43xx_ieee80211_set_chan(s
unsigned long flags;
spin_lock_irqsave(&bcm->lock, flags);
- bcm43xx_mac_suspend(bcm);
- bcm43xx_radio_selectchannel(bcm, channel, 0);
- bcm43xx_mac_enable(bcm);
+ if (likely(bcm->initialized)) {
+ bcm43xx_mac_suspend(bcm);
+ bcm43xx_radio_selectchannel(bcm, channel, 0);
+ bcm43xx_mac_enable(bcm);
+ } else {
+ bcm->current_core->radio->initial_channel = channel;
+ }
spin_unlock_irqrestore(&bcm->lock, flags);
}
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Default to 11Mbps.
On Thu, 2006-03-23 at 09:42 -0700, Hans Fugal wrote: > > > See > http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg00789.html > > The first 10-second sleep is the vital one, but 10 seconds is much oo > long for that as I have done it much faster than that by hand and it > worked. Works for me without any delays, and in fact without having the 'ip link set $iface up' in there at all. I use dhclient instead of udhcpc, so it goes like this... + modprobe bcm43xx + iwconfig eth1 essid 'Baythorne Wavelan' key $KEY + dhclient eth1 Internet Systems Consortium DHCP Client V3.0.2-RedHat Copyright 2004 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Listening on LPF/eth1/00:0a:95:f3:99:92 Sending on LPF/eth1/00:0a:95:f3:99:92 Sending on Socket/fallback DHCPREQUEST on eth1 to 255.255.255.255 port 67 DHCPREQUEST on eth1 to 255.255.255.255 port 67 DHCPACK from 81.187.2.163 bound to 81.187.2.165 -- renewal in 39714 seconds. It does take half a second or so to associate after dhclient brings the link up, hence the need to retransmit the DHCP request. I can avoid that by adding 'ip link set $iface up' immediately before the dhclient invocation -- although still with no sleep: + modprobe bcm43xx + iwconfig eth1 essid 'Baythorne Wavelan' key $KEY + ip link set eth1 up + dhclient eth1 Internet Systems Consortium DHCP Client V3.0.2-RedHat Copyright 2004 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Listening on LPF/eth1/00:0a:95:f3:99:92 Sending on LPF/eth1/00:0a:95:f3:99:92 Sending on Socket/fallback DHCPREQUEST on eth1 to 255.255.255.255 port 67 DHCPACK from 81.187.2.163 bound to 81.187.2.165 -- renewal in 41234 seconds. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Default to 11Mbps.
On Thu, 2006-03-23 at 09:42 -0700, Hans Fugal wrote: > See http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg00789.html > > The first 10-second sleep is the vital one, but 10 seconds is much too > long for that as I have done it much faster than that by hand and it > worked. That could well be the period it was taking for a scan, which is now less than a second. > I'll try with the latest snapshot when I get a chance and report back. I don't think my patches are in the snapshots yet. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Default to 11Mbps.
On Thu, 2006-03-23 at 08:11 -0700, Hans Fugal wrote: > I had difficulty associating with the same sequence of commands when put > in a script as opposed to doing it by hand. A well-placed 1-second sleep > did wonders. Interesting. Precisely where in your script did you need the sleep? Is it still required with the patches I posted yesterday? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Default to 11Mbps.
On Wed, 2006-03-22 at 21:08 -0700, Hans Fugal wrote: > I'm nobody special, but I have to wonder if people are really having > issues with rate. I thought I was having this problem, because people > indicated that might be the problem. All the circumstantial evidence > agreed. But when I got down and dirty and scientifically tested it, it > was just a matter of timing and basically boiled down to bringing up > the link then using iwconfig, and not doing that too fast. I'm not sure what you mean by the final sentence. Could you elaborate? Are you saying that your _problem_ was caused by not using iwconfig 'too fast'? Or fast enough? I believe there are people who can't associate, or can't do DHCP, until they reduce the rate from 54Mbps to something lower. I _can_ associate at 54Mbps and pick up both IPv6 and IPv4 addresses -- but even when I'm within a metre of the AP I see many lost packets at 54Mbps. Testing it with a large download from a local machine shows that in reality it's _much_ faster if I switch to 11Mbps. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Default to 11Mbps.
We don't make much of an attempt to fall back to lower rates, and 54M
just isn't working for many people. In fact, it's not clear we even set
it to 11M if we're trying to associate with an 802.11b AP.
This patch makes us default to 11M, which ought to work for most people.
When we actually handle dynamic adjustment of the RX rate, we can
reconsider the defaults -- but even then, it makes as much sense to
start at 11M and adjust it upwards as it does to start at 54M and reduce
it.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_module.c~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_module.c
2006-03-22 11:00:57.0 +
@@ -183,7 +183,10 @@ void ieee80211softmac_start(struct net_d
*/
if (mac->txrates_change)
oldrates = mac->txrates;
- if (ieee->modulation & IEEE80211_OFDM_MODULATION) {
+ /* FIXME: We don't correctly handle backing down to lower rates,
+ so start off at 11M for now. People can manually change it if
+ they really need to, but 11M is more reliable. */
+ if (0 && ieee->modulation & IEEE80211_OFDM_MODULATION) {
mac->txrates.default_rate = IEEE80211_OFDM_RATE_54MB;
change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
mac->txrates.default_fallback = IEEE80211_OFDM_RATE_24MB;
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_wx.c~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_wx.c
2006-03-22 12:11:58.0 +
@@ -136,7 +136,7 @@ ieee80211softmac_wx_set_rate(struct net_
if (in_rate == -1) {
/* automatic detect */
- if (ieee->modulation & IEEE80211_OFDM_MODULATION)
+ if (0 /* FIXME */ && ieee->modulation &
IEEE80211_OFDM_MODULATION)
in_rate = 5400;
else
in_rate = 1100;
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Associate on 'ifconfig up'
The Fedora initscripts will set essid and WEP keys before running 'dhclient', and the current driver doesn't bother to try to associate, so dhclient always fails. You need to bring the device up and then set the ESSID again in order for it to associate, and then you can use dhclient. We already fixed this for suspend/resume; this just moves the same hack into bcm43xx_init_board() so it happens on 'ifconfig up' and reset too. Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> --- linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c~ 2006-03-21 23:50:00.0 + +++ linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-03-22 10:32:11.0 + @@ -3429,6 +3429,9 @@ static int bcm43xx_init_board(struct bcm } bcm43xx_periodic_tasks_setup(bcm); + /*FIXME: This should be handled by softmac instead. */ + schedule_work(&bcm->softmac->associnfo.work); + assert(err == 0); out: return err; @@ -4326,9 +4329,6 @@ static int bcm43xx_resume(struct pci_dev netif_device_attach(net_dev); - /*FIXME: This should be handled by softmac instead. */ - schedule_work(&bcm->softmac->associnfo.work); - dprintk(KERN_INFO PFX "Device resumed.\n"); return 0; -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Reduce scan dwell time.
Even with the patch I sent last night, I still get outages of about 8
seconds when I scan. There's no need for us to be dwelling for half a
second on every channel; this changes it to 20ms instead.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h
2006-03-22 11:20:26.0 +
@@ -176,7 +176,7 @@ static inline int ieee80211softmac_scan_
) || ieee80211softmac_scan_handlers_check_self(sm);
}
-#define IEEE80211SOFTMAC_PROBE_DELAY HZ/2
+#define IEEE80211SOFTMAC_PROBE_DELAY HZ/50
#define IEEE80211SOFTMAC_WORKQUEUE_NAME_LEN(17 + IFNAMSIZ)
struct ieee80211softmac_network {
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Scan forces deassociation
On Tue, 2006-03-21 at 23:44 +, David Woodhouse wrote:
> After a scan, bcm43xx doesn't seem to switch back to the correct
> frequency. I have to set the ESSID again to prevent it from falling off
> the network.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_scan.c~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_scan.c
2006-03-22 00:31:31.0 +
@@ -232,6 +232,13 @@ void ieee80211softmac_scan_finished(stru
sm->scanning = 0;
spin_unlock_irqrestore(&sm->lock, flags);
+ if (sm->associnfo.bssvalid) {
+ struct ieee80211softmac_network *net;
+
+ net = ieee80211softmac_get_network_by_bssid(sm,
sm->associnfo.bssid);
+ if (net)
+ sm->set_channel(sm->dev, net->channel);
+ }
ieee80211softmac_call_events(sm, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED,
NULL);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_scan_finished);
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Scan forces deassociation
After a scan, bcm43xx doesn't seem to switch back to the correct frequency. I have to set the ESSID again to prevent it from falling off the network. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Driver on 64bit archs
On Mon, 2006-02-20 at 11:51 +0100, Johannes Berg wrote: > Debian does too, but I suppose *any* distro that runs on ppc64 has to > do this since it practically requires always cross-compiling your > kernel since userland is normally 32 bits (afaik there's nothing to be > gained from 64 bit userland unless you need large VM space). Or 64-bit arithmetic. I wasn't sure Debian had managed biarch yet; I thought you still had to have a full 64-bit install on x86_64, ppc64, etc. When did that get fixed? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Driver on 64bit archs
On Sat, 2006-02-18 at 09:42 -0500, Jason Lunz wrote: > I know you have plenty to do already, but keep in mind also that there's > no need for a 64-bit machine to test 64-bit compilation of your driver. > It's quite straightforward to build a 64-bit-arch-targeted toolchain and > do test compiles with that: > > http://www.kegel.com/crosstool/ If you're running on a PPC machine you might not even need to find a cross-compiler. At least Fedora ships with a toolchain which will compile for either ppc32 or ppc64 -- you can build ppc64 kernels on a ppc32 machine with the normal toolchain. Not sure about other distributions. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Link LED not working on cardbus Linksys WPC54G
On Tue, 2006-02-07 at 15:31 -0600, Larry Finger wrote: > I'm not quite sure where the patches are. The subversion tree is a lot > newer than the FC sources seem to be, but not current. Michael Buesch > has a private git tree, but I not comfortable giving you that URL. If > he is willing to publish it, he will see this e-mail and can reply to > it. He already Cc'd this list when asking John to pull from that tree, four days ago. Those patches are now in the Fedora rawhide kernel, as of 2.6.15-1.1913_FC5 or thereabouts. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Link LED not working on cardbus Linksys WPC54G
On Tue, 2006-02-07 at 12:50 -0600, Larry Finger wrote: > I wonder where Fedora is getting their source. The iwconfig errors you > report were fixed about a month ago. On my system, WPA started working > on Jan. 12 and that didn't work until most of the IOCTL links used by > iwconfig were working. > > As you are obviously in the FC test program, could you inquire where > they are downloading softmac and bcm43xx code? Originally from the daily snapshots, then from the softmac git tree and the bcm43xx daily snapshots, and now from the appropriate branches in John Linville's wireless git tree. I updated the Fedora kernel just before leaving for linux.conf.au almost a month ago -- just after WPA was allegedly supposed to work, but without testing that for myself. I got back to work yesterday and updated it again, pulling in the changes in Michael Buesch's git tree which John hasn't (or hadn't) yet taken. If there's still stuff missing, please let me know. I'm trying to keep on top of the _useful_ changes without just randomly updating it every day. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Re: [GIT PULL] bcm43xx: Update B6PHY initialization
On Wed, 2006-02-01 at 19:15 +0100, Stefano Brivio wrote: > If somebody relied on that for filtering, please use the List-Id or > X-BeenThere headers instead. It's actually more reliable to use the SMTP reverse-path, which is often seen in a Return-Path: header if it isn't available directly. If in some strange systems that's really not possible, then the Sender: header is also slightly more reliable than List-ID: or X-BeenThere: headers -- both of which which will get false positives and file the message into the list folder even when it was redirected to you _personally_ by another list subscriber, because they know you're not likely to be reading the folder very carefully (or indeed at all), and they knew you'd want to see the mail in question in your _inbox_. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: How to get WPA-Support with NetworkManager?
On Mon, 2006-01-30 at 07:53 -0500, Dan Williams wrote:
> On Mon, 2006-01-30 at 21:51 +1100, David Woodhouse wrote:
> > I believe the bcm43xx driver should support WPA.
>
> Technically, yes. However, it needs a patch like the one attached (from
> ipw2100) in bcm43xx_wx_get_rangeparams() to actually tell anything
> (including NM) what it supports. This patch is >= WE-18 only.
Thanks. Did that go to the bcm43xx-dev list?
--
dwmw2
--- a/drivers/net/wireless/ipw2100.c 2006-01-08 14:04:00.0 -0500
+++ b/drivers/net/wireless/ipw2100.c 2006-01-08 15:47:37.0 -0500
@@ -7236,7 +7236,7 @@
/* Set the Wireless Extension versions */
range->we_version_compiled = WIRELESS_EXT;
- range->we_version_source = 16;
+ range->we_version_source = 18;
// range->retry_capa; /* What retry options are supported */
// range->retry_flags; /* How to decode max/min retry limit */
@@ -7262,6 +7262,9 @@
}
range->num_frequency = val;
+ range->enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 |
+ IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP;
+
IPW_DEBUG_WX("GET Range\n");
return 0;
Re: [Bcm43xx-dev] bcm43xx doesn't restore channel after scan
On Fri, 2006-01-13 at 06:17 +, David Woodhouse wrote: > I find that every time NetworkManager scans for available networks or I > run 'iwlist scan' manually, I get disconnected from the network I was > on. > > This seems to be because we don't actually switch back to the channel we > _should_ be on, after we finish the scan... Strangely, this does work OK on the 2.6.15-based Fedora rawhide kernels. It goes back to the correct channel after the scan, and all is well. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[Bcm43xx-dev] bcm43xx doesn't restore channel after scan
Using the FC-4 netdev kernel from http://people.redhat.com/linville/kernels/fedora-netdev/ I find that every time NetworkManager scans for available networks or I run 'iwlist scan' manually, I get disconnected from the network I was on. This seems to be because we don't actually switch back to the channel we _should_ be on, after we finish the scan... it stops working when I scan, and _usually_ starts again when I set the channel back, although sometimes I also have to set the essid again. shinybook /home/dwmw2 # iwconfig eth1 eth1 IEEE 802.11b/g ESSID:"Baythorne Wavelan" Nickname:"Broadcom 4306" Mode:Managed Frequency=2.437 GHz Access Point: 00:06:25:4B:55:F8 Bit Rate:11 Mb/s Tx-Power=2346 dBm RTS thr:off Fragment thr:off shinybook /home/dwmw2 # iwlist eth1 scan eth1 Scan completed : Cell 01 - Address: 00:06:25:4B:55:F8 ESSID:"Baythorne Wavelan" Protocol:IEEE 802.11bg Mode:Master Channel:6 Bit Rate:54 Mb/s Extra: Rates (Mb/s): 1 2 5.5 6 9 11 12 18 24 36 48 54 Quality=100/100 Signal level=-45 dBm Extra: Last beacon: 276ms ago shinybook /home/dwmw2 # iwconfig eth1 eth1 IEEE 802.11b/g ESSID:"Baythorne Wavelan" Nickname:"Broadcom 4306" Mode:Managed Frequency=2.432 GHz Access Point: 00:06:25:4B:55:F8 Bit Rate:11 Mb/s Tx-Power=2346 dBm RTS thr:off Fragment thr:off shinybook /home/dwmw2 # iwconfig eth1 channel 6 shinybook /home/dwmw2 # iwconfig eth1 essid 'Baythorne Wavelan' -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Success report from PowerBook5,4
On Fri, 2006-01-06 at 09:53 -0800, Jesse Barnes wrote: > > No, that's needed because it doesn't reassociate if going down and > > up again. > > Will that be fixed at some point, or should I modify my scripts to do > it automatically? It'll get fixed in the end, yes. At all times while the device is up but not asssociated, we should probably be continuously trying to associate with something -- and trying different rates to do so. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[Bcm43xx-dev] Build fixes.
The svn trunk doesn't build against the current softmac git tree... or
indeed against itself.
--- linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx_main.c~ 2006-01-03
22:56:55.0 +
+++ linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx_main.c2006-01-03
23:00:15.0 +
@@ -4583,8 +4583,8 @@ static int bcm43xx_resume(struct pci_dev
netif_device_attach(net_dev);
/*FIXME: This should be handled by softmac instead. */
- queue_work(bcm->softmac->workqueue, &bcm->softmac->associnfo.work);
+ schedule_work(&bcm->softmac->associnfo.work);
dprintk(KERN_INFO PFX "Device resumed.\n");
--- linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx.h.orig2006-01-06
05:00:12.0 +
+++ linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-01-06
14:07:38.0 +
@@ -648,7 +648,8 @@ struct bcm43xx_private {
bad_frames_preempt:1, /* Use "Bad Frames Preemption" (default
off) */
reg124_set_0x4:1, /* Some variable to keep track of IRQ
stuff. */
powersaving:1, /* TRUE if we are in PowerSaving mode.
FALSE otherwise. */
- short_preamble:1; /* TRUE, if short preamble is enabled.
*/
+ short_preamble:1, /* TRUE, if short preamble is enabled.
*/
+ firmware_norelease:1; /* Do not release the firmware. Used on
suspend. */
struct bcm43xx_stats stats;
@@ -728,7 +729,13 @@ struct bcm43xx_private {
u16 security_offset;
struct bcm43xx_key key[54];
u8 default_key_idx;
-
+
+ /* Firmware. */
+ const struct firmware *ucode;
+ const struct firmware *pcm;
+ const struct firmware *initvals0;
+ const struct firmware *initvals1;
+
/* Debugging stuff follows. */
#ifdef BCM43xx_DEBUG
struct bcm43xx_dfsentry *dfsentry;
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Reassociate after resume.
On Wed, 2006-01-04 at 10:43 +1100, Benjamin Herrenschmidt wrote:
> Does that restore things like selected rate, essid, etc... ? We do
> lose those with ifdown/ifup ...
I haven't had to select a rate. I do have to manually set the essid when
I bring the device up because otherwise it refuses to consider my AP --
and that configuration does still seem to be present after resume.
Hm, thanks for the reminder...
We shouldn't discard networks with encryption in
network_matches_request() -- they might be all we have, and we might
have a key which matches, or something waiting to provide it (or
authenticate in other ways).
There's perhaps a justification for preferring a network without
encryption in the as-yet-unimplemented code which picks the 'best'
network from the list of available networks in
ieee80211softmac_assoc_work(), but we shouldn't just exclude it from
that list completely.
--- linux-2.6.15/net/ieee80211/softmac/ieee80211softmac_assoc.c~
2006-01-04 08:39:52.0 +
+++ linux-2.6.15/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-01-04
08:46:02.0 +
@@ -127,9 +127,7 @@ network_matches_request(struct ieee80211
if (!we_support_all_basic_rates(mac, net->rates_ex, net->rates_ex_len))
return 0;
- /* if 'ANY' network requested, take any that doesn't have privacy
enabled */
- if (mac->associnfo.req_essid.len == 0
- && !(net->capability & WLAN_CAPABILITY_PRIVACY))
+ if (mac->associnfo.req_essid.len == 0)
return 1;
if (net->ssid_len != mac->associnfo.req_essid.len)
return 0;
@@ -178,6 +176,7 @@ ieee80211softmac_assoc_work(void *d)
*
* We also should take into account the rateset
* here to find the best BSSID to try.
+* And also encryption.
*/
if (network_matches_request(mac, net)) {
if (!best) {
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[Bcm43xx-dev] Device table
This adds a device table to the bcm43xx module so that it gets
automatically loaded by hotplug.
--- linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c~ 2006-01-03
04:35:26.0 +
+++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-01-03
04:35:29.0 +
@@ -139,6 +139,7 @@ static struct pci_device_id bcm43xx_pci_
/* required last entry */
{ 0, },
};
+MODULE_DEVICE_TABLE(pci, bcm43xx_pci_tbl);
static void bcm43xx_recover_from_fatal(struct bcm43xx_private *bcm, const char
*error);
static void bcm43xx_free_board(struct bcm43xx_private *bcm);
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[Bcm43xx-dev] Reassociate after resume.
This isn't the right answer, but it's a hack which makes it reassociate after resume. Really, we should implement suspend/resume methods in softmac itself. --- linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx_main.c~ 2006-01-03 22:56:55.0 + +++ linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx_main.c2006-01-03 23:00:15.0 + @@ -4543,6 +4541,7 @@ static int bcm43xx_resume(struct pci_dev } netif_device_attach(net_dev); + queue_work(bcm->softmac->workqueue,&bcm->softmac->associnfo.work); dprintk(KERN_INFO PFX "Device resumed.\n"); -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Multicast/broadcast RX
On Mon, 2006-01-02 at 22:54 +, David Woodhouse wrote: > Sticking the device into promiscuous mode works around this, but it > obviously isn't ideal. The MAC filtering isn't yet sufficiently > documented for us to do any better. though. We shouldn't printk when we drop unwanted packets. --- linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx_main.c~ 2006-01-03 22:56:55.0 + +++ linux-2.6.15/drivers/net/wireless/bcm43xx/bcm43xx_main.c2006-01-03 22:57:24.0 + @@ -4176,8 +4176,6 @@ int fastcall bcm43xx_rx(struct bcm43xx_p case IEEE80211_FTYPE_DATA: if (is_packet_for_us) err = bcm43xx_rx_packet(bcm, skb, &stats); - else - dprintkl(KERN_ERR PFX "RX packet dropped (not for us)\n"); break; case IEEE80211_FTYPE_CTL: break; -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] Multicast/broadcast RX
On Mon, 2006-01-02 at 01:38 +, David Woodhouse wrote:
> It's not just multicast reception that isn't working -- I don't receive
> broadcast packets either.
>
> Sticking the device into promiscuous mode works around this, but it
> obviously isn't ideal. The MAC filtering isn't yet sufficiently
> documented for us to do any better. though.
>
> Since we get our own multi/broadcast packets back again from the AP,
> this also makes bcm43xx_rx() drop such packets if the source address is
> our own.
Updated patch without the 'if (1 ||' as requested...
Index: bcm43xx_main.c
===
--- bcm43xx_main.c (revision 1022)
+++ bcm43xx_main.c (working copy)
@@ -2681,10 +2681,8 @@
bcm43xx_mac_suspend(bcm);
status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
/* Reset status to infrastructured mode */
- status &= ~(BCM43xx_SBF_MODE_AP |
- BCM43xx_SBF_MODE_MONITOR |
- BCM43xx_SBF_MODE_PROMISC);
- status |= BCM43xx_SBF_MODE_NOTADHOC;
+ status &= ~(BCM43xx_SBF_MODE_AP | BCM43xx_SBF_MODE_MONITOR);
+ status |= BCM43xx_SBF_MODE_NOTADHOC | BCM43xx_SBF_MODE_PROMISC;
switch (iw_mode) {
case IW_MODE_MONITOR:
@@ -2783,14 +2781,15 @@
value32 = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
value32 |= BCM43xx_SBF_MODE_NOTADHOC;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value32);
+ /* For now, use promiscuous mode at all times; otherwise we don't
+ get broadcast or multicast packets */
+ value32 = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
+ value32 |= BCM43xx_SBF_MODE_PROMISC;
+ bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value32);
- if ((iw_mode == IW_MODE_MASTER) && (bcm->net_dev->flags & IFF_PROMISC))
{
+ if (iw_mode == IW_MODE_MONITOR) {
value32 = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
value32 |= BCM43xx_SBF_MODE_PROMISC;
- bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value32);
- } else if (iw_mode == IW_MODE_MONITOR) {
- value32 = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- value32 |= BCM43xx_SBF_MODE_PROMISC;
value32 |= BCM43xx_SBF_MODE_MONITOR;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value32);
}
@@ -4133,15 +4132,20 @@
if (memcmp(wlhdr->addr1, bcm->net_dev->dev_addr, ETH_ALEN) == 0
||
memcmp(wlhdr->addr3, bcm->ieee->bssid, ETH_ALEN) == 0 ||
is_broadcast_ether_addr(wlhdr->addr1) ||
- is_multicast_ether_addr(wlhdr->addr1))
+ is_multicast_ether_addr(wlhdr->addr1) ||
+ bcm->net_dev->flags & IFF_PROMISC)
is_packet_for_us = 1;
break;
case IW_MODE_INFRA:
default:
+ /* When receiving multicast or broadcast packets, filter out
+ the packets we send ourself; we shouldn't see those */
if (memcmp(wlhdr->addr3, bcm->ieee->bssid, ETH_ALEN) == 0 ||
memcmp(wlhdr->addr1, bcm->net_dev->dev_addr, ETH_ALEN) == 0
||
- is_broadcast_ether_addr(wlhdr->addr1) ||
- is_multicast_ether_addr(wlhdr->addr1))
+ (memcmp(wlhdr->addr3, bcm->net_dev->dev_addr, ETH_ALEN) &&
+(is_broadcast_ether_addr(wlhdr->addr1) ||
+ is_multicast_ether_addr(wlhdr->addr1) ||
+ bcm->net_dev->flags & IFF_PROMISC)))
is_packet_for_us = 1;
break;
}
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bcm43xx-dev] SIOCGWAP
On Mon, 2006-01-02 at 20:30 +0100, Danny van Dyk wrote: > Already part of softmac... Checkout latest driver (>r1020) and softmac > (>218) sources... Heh, thanks. It can wait until tomorrow's snapshot -- I don't need any more gratuitously different version control systems this week :) It would be a lot easier if bcm43xx and softmac trees were at least _mirrored_ into git repositories. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[Bcm43xx-dev] SIOCGWAP
The GNOME NetworkManager tool depends on SIOCGWAP to tell when it's
associated.
--- drivers/net/wireless/bcm43xx/bcm43xx_wx.c~ 2006-01-02 18:34:29.0
+
+++ drivers/net/wireless/bcm43xx/bcm43xx_wx.c 2006-01-02 18:31:11.0
+
@@ -346,8 +346,19 @@ static int bcm43xx_wx_get_apmac(struct n
union iwreq_data *data,
char *extra)
{
+ struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ struct sockaddr *d = (void *)data;
+ unsigned long flags;
+
wx_enter();
- /*TODO*/
+
+ if (!bcm->softmac->associated)
+ return -ENODEV;
+ spin_lock_irqsave(&bcm->lock, flags);
+ memcpy(d->sa_data, bcm->ieee->bssid, ETH_ALEN);
+ d->sa_family = ARPHRD_ETHER;
+ spin_unlock_irqrestore(&bcm->lock, flags);
+
return 0;
}
@@ -964,7 +975,7 @@ static const iw_handler bcm43xx_wx_handl
WX(SIOCGIWRANGE)= bcm43xx_wx_get_rangeparams,
/* Access Point manipulation */
//TODO WX(SIOCSIWAP) = bcm43xx_wx_set_apmac,
-//TODO WX(SIOCGIWAP) = bcm43xx_wx_get_apmac,
+ WX(SIOCGIWAP) = bcm43xx_wx_get_apmac,
WX(SIOCSIWSCAN) = ieee80211softmac_wx_trigger_scan,
WX(SIOCGIWSCAN) = ieee80211softmac_wx_get_scan_results,
/* 802.11 specific support */
--
dwmw2
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
