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
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
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
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
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 =
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
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
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
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
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
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
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
Will poke at it more when I get home at the end of the week...
Sep 12 08:17:22 shinybook NetworkManager: info 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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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: ::
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
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
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
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
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 :)
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
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
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.
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
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
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
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
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
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
$
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
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
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 somekernelrpm shinybook:' -- it's not a particularly
good test.
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
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
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
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
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 BlueWhite
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
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
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
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
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
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
-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
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?br
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
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:
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
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
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
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
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
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
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 +
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
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.
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,
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
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
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
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
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 +
+++
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
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
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
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
On Sun, 2006-01-01 at 08:54 -0600, Matteo Frigo wrote:
I would appreciate if other people could confirm whether
handle_irq_transmit_status() is called on their system, so that I can
try to further diagnose the problem.
It's not being called here -- I see precisely the same as you. It stops
On Sat, 2005-12-31 at 02:37 +, David Woodhouse wrote:
At that point I can use dhclient successfully and Legacy IP works.
Hm, almost. If I leave a ping running, I see an occasional TX timeout,
followed by a reset -- and then I have to manually set the ESSID again
before it'll work any more
I've just tried the current (20051230) snapshot on the 2.6.15-rc7-git4
(Fedora Rawhide) kernel on a PowerBook. I also used the patch from
http://marc.theaimsgroup.com/?l=linux-netdevm=113591302004639w=2
The resulting kernel package (which also installs on FC4 with --nodeps)
is at
80 matches
Mail list logo
