Michael Buesch wrote:
On Wednesday 24 January 2007 23:59, Jory A. Pratt wrote:
Michael Buesch wrote:
On Wednesday 24 January 2007 20:08, Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 24 January 2007 19:39, Larry Finger wrote:
switch (led_index
Michael Buesch wrote:
On Thursday 25 January 2007 00:16, Steve Brown wrote:
My understanding of the proposed behavior is:
Radio on: led on
Radio off: led off
Activity: flash on-off-on ...
This is the same behavior as my Buffalo WHR-HP-G54 and seems reasonable.
That's not
Gene Heskett wrote:
On Thursday 25 January 2007 10:36, Larry Finger wrote:
Gene Heskett wrote:
On Thursday 25 January 2007 07:50, Jiri Benc wrote:
On Thu, 25 Jan 2007 12:47:08 +0100, Ivo Van Doorn wrote:
Correct, similar problems have been detected in rt2x00. The
temporary solution
Gene Heskett wrote:
On Thursday 25 January 2007 07:50, Jiri Benc wrote:
On Thu, 25 Jan 2007 12:47:08 +0100, Ivo Van Doorn wrote:
Correct, similar problems have been detected in rt2x00. The temporary
solution in there is to demand a scanning operation after the
interface has been brought up.
Jörg Sommer wrote:
Good morning,
I want to connect to a WPA-EPA-TTLS encrypted network, but wpasupplicant
(0.5.7) says: Driver did not support SIOCSIWENCODEEXT. What does he mean?
Can someone read the wpa_supplicant log and see why it can't connect to
the network?
Could we please have more
Matthew Garrett wrote:
The dscape driver requires v4 firmware, while the mainline driver
prefers v3. Giving the two different names makes it easier to support
parallel installation. This patches fwcutter to dump v4 firmware with a
different name - the second patch alters the dscape driver
Matthew Garrett wrote:
On Fri, Jan 26, 2007 at 09:49:15AM -0600, Larry Finger wrote:
NACK. The --postfix switch for fwcutter, and the postfix option for
bcm43xx-d80211 driver handle
this case perfectly well.
It would be helpful to standardise - the default behaviour at the moment
makes
roucaries bastien wrote:
On 1/26/07, Larry Finger [EMAIL PROTECTED] wrote:
roucaries bastien wrote:
Do you have the log stuff that precedes this part? In particular, was
there a assertion that failed?
It is oops on resume and no asseertion failled this boot. However I
have usually
roucaries bastien wrote:
On 1/26/07, Larry Finger [EMAIL PROTECTED] wrote:
roucaries bastien wrote:
On 1/26/07, Larry Finger [EMAIL PROTECTED] wrote:
roucaries bastien wrote:
Do you have the log stuff that precedes this part? In
particular, was
there a assertion that failed
roucaries bastien wrote:
On 1/26/07, Larry Finger [EMAIL PROTECTED] wrote:
Does it help to down the wifi card before the s2disk?
Yes no oops but I can't associate to the network after suspend. But at
least no oops.
Did you use an ifup after resuming?
Please send me the log information
Paul Marks wrote:
On 1/26/07, Larry Finger [EMAIL PROTECTED] wrote:
Paul Marks wrote:
I have a BCM4311 card, and ever since the PCI-E interrupts patch,
I've been
able to associate just fine with my own WPA2-PSK access point, using
wpa_supplicant with ap_scan=1.
However, the access
Paul Marks wrote:
0: 00:16:01:11:42:11 ssid='hidden' wpa_ie_len=26 rsn_ie_len=22 caps=0x11
skip - SSID mismatch
That's definitely my access point, but as you can see, the driver
never inserted the correct SSID.
According to Dan Williams at RedHat, the insertion of hidden by ieee80211
Igor Korot wrote:
Hi, Larry,
In the patch ftp://lwfinger.dynalias.org/patches/patch_2.6.18.1_for_PCI-E,
there is a following code:
+ core_rev = (sb_id_hi 0x7000) 8;
+ core_rev |= (sb_id_hi 0xF);
+ core_rev = ((sb_id_hi 0xF) | ((sb_id_hi 0x7000) 8));
Notice
transition from softmac to d80211.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
--
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net
-softmac, this
module parameter is only enabled when debugging is on. This patch
makes the module parameter available unconditionaly, and should
ease the future transition from softmac to d80211.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
--
Index
Jim McCloskey wrote:
Hello. I am the owner of a card (a LinkSys Wireless-G WPC54GS (ver.2))
which has a 4318 chip:
kernel: bcm43xx: Chip ID 0x4318, rev 0x2kernel: bcm43xx: Number of cores: 4
kernel: bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243, enabled
kernel: bcm43xx: Core 1: ID
Igor Korot wrote:
Hi, Larry,
I found another strange thing with the driver.
I was able to successfully establish the connection using wireless tools.
I just installed wpa_supplicant, and here is what happened:
IgorsGentooOnNetwork igor # ifconfig eth1 up
SIOCSIFFLAGS: Protocol error
Matthew Garrett wrote:
On Mon, Jan 29, 2007 at 01:55:41PM +0100, roucaries bastien wrote:
- return 0;
+ return bcm43xx_init_one(pdev, NULL);
}
While this may well work (it's basically equivalent to unloading and
reloading the module), it's not a long-term fix - userspace is
Michael Buesch wrote:
On Monday 29 January 2007 04:18, Larry Finger wrote:
Although we have not made any progress on the transmit strength problem with
4318, 4311 and 4312
That's not true. We are doing progress, but we didn't solve the
issue completely, yet. It's a complicated issue. ;)
I
Igor Korot wrote:
Larry,
-Original Message-
From: Igor Korot [EMAIL PROTECTED]
Sent: Jan 28, 2007 8:14 PM
To: Larry Finger [EMAIL PROTECTED]
Cc: Michael Buesch [EMAIL PROTECTED], Bcm43xx-dev@lists.berlios.de
Subject: Re: Problem with the lid closing event
Larry,
-Original
wy wrote:
Hi,
I just joined the list. Recently, I upgraded to Fedora Core 6 from
Redhat 9. My wireless card works fine on Redhat 9 after I went with
Linuxant drivers.
With Fedora Core 6, bcm43xx-fwcutter is available and performing the
same function as Linuxant was providing. I was
Michael,
I think the patch below is needed. On my 4311 system, including this change
improves throughput at
least by a factor of 5 at 1 Mb/s. It also matches the old specifications where
txctl1 was multiplied
by 0x10.
Larry
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_lo.c
Asil Jinn wrote:
I tried again to run the wireless-dev on my dual core machine, but it
still crashes on bootup.. Is there any progress on smp with wireless-dev?
There is lots of progress. I have an AMD 64 X2 (dual core) system running an
SMP x86_64 system. I am
unable to authenticate with a
wy wrote:
Hi,
I currently running on kernel 2.6.19-1.2895.fc6. Let me know if some
information is needed.
Your lspci -v output tells me that your device is a BCM4303, which is an
802.11b interface. Your
kernel should be OK for that device. From the dmesg output, the bcm43xx driver
has not
Michael Buesch wrote:
I need some real-life data to estimate what the
ITSSI value usually is on different cards.
(ITSSI is called savedpctlreg in softmac driver).
Please run this patch on your machine, bring up
the interface and send dmesg back to me. Thanks.
Index:
Pavel Roskin wrote:
On Wed, 2007-01-31 at 10:00 -0600, Larry Finger wrote:
wy wrote:
Hi,
I currently running on kernel 2.6.19-1.2895.fc6. Let me know if some
information is needed.
Your lspci -v output tells me that your device is a BCM4303, which is an
802.11b interface. Your
kernel
Asil Jinn wrote:
Micheal.. but my email was not a bug report, which you will also notice
if you read it again. It was a simple status check of how it was going
with the smp part.
However it is a good idea to add the logs either way, but I have checked
kernel.log, and other log messages in
Igor Korot wrote:
Hi,
I have very strange problem. Maybe it's because I'm running 2.6.18 kernel,
but I think I saw somebody connected and worked with this version.
I have run a 4311 with a 2.6.18 kernel with the patches you are using.
I do have some questions:
1. Is wpa_supplicant running?
Rafael J. Wysocki wrote:
That pretty much reflects what I'm observing with BCM4311 on HPC nx6325, plus
D-Link access points are not listed by iwlist eth2 scan (I wonder what's so
special about D-Link access points ...).
I have another machine with a bcm43xx here, but it has the 4306 chip
Igor Korot wrote:
Thank you for the reply, Larry.
I will try to install Kismet along with the Ethereal.
What output do you want? Just the Kismet log file?
Or something from Ethreal?
You can send me (privately) the kismet file. I'll run Ethereal on it.
Larry
Igor Korot wrote:
Hi, guys,
I just did a little test yesterday, and today.
The problem below occur when on the dual-boot laptop, you boot Windows first,
suspend it to disk, then boot Linux.
I have a Dell Inspiron E1505 with WinXP and Gentoo installed.
And this is exactly what happened.
John W. Linville wrote:
On Wed, Jan 31, 2007 at 06:50:19PM -0600, Larry Finger wrote:
Sparse issues the warning warning: symbol 'crypt' shadows an earlier one
in net/ieee80211/ieee80211_tx.c.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/net/ieee80211/ieee80211_tx.c
Sparse issues the warning warning: symbol 'crypt' shadows an earlier one
in net/ieee80211/ieee80211_tx.c.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/net/ieee80211/ieee80211_tx.c
===
--- wireless-2.6.orig
Rafael J. Wysocki wrote:
Hi,
Some good news here. :-)
I've finally managed to make the 4311 in my nx6325 work.
Well, it turns out that new D-Link routers (at least DI-524 and DI-624)
are recognized by it (still older ones are not).
The transfer rates are rather low (20 - 25 KB/s
If you are having trouble with communications after a suspend/resume cycle,
please try the patch
below. The patch was made against wireless-2.6, but should apply to any 2.6.18
or later kernel. I
cannot test this one as my video driver refuses to suspend.
Thanks,
Larry
=
Two bit-field values are extracted from the sprom data and never used.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless
Michael Buesch wrote:
On Saturday 03 February 2007 18:50, Larry Finger wrote:
If you are having trouble with communications after a suspend/resume cycle,
please try the patch
below. The patch was made against wireless-2.6, but should apply to any
2.6.18 or later kernel. I
cannot test
hang or crash an SMP
version of Linux and
offers usable wireless service for such a complicated piece of totally
undocumented hardware is a
real tribute to those two groups. Thanks guys.
Larry Finger
bcm43xx Maintainer
___
Bcm43xx-dev mailing list
Bcm43xx
roucaries bastien wrote:
Sorry for the delay it works. This time I can use iwlist eth scan.
I have some difficulties to associate and I need to rmmod/modprobe in
order to associate but it is another problem linked to a really weak
power.
Bastien,
Please try this patch instead.
Thanks,
Rafael J. Wysocki wrote:
On Sunday, 4 February 2007 18:42, Larry Finger wrote:
roucaries bastien wrote:
Sorry for the delay it works. This time I can use iwlist eth scan.
I have some difficulties to associate and I need to rmmod/modprobe in
order to associate but it is another problem linked
Rafael J. Wysocki wrote:
On Monday, 5 February 2007 04:20, Larry Finger wrote:
Rafael J. Wysocki wrote:
On Saturday, 3 February 2007 23:30, Rafael J. Wysocki wrote:
On Saturday, 3 February 2007 02:03, Larry Finger wrote:
Rafael J. Wysocki wrote:
Hi,
Some good news here. :-)
I've finally
Rafael J. Wysocki wrote:
Okay, so perhaps I can hack the driver to use 1M by default?
This patch will do it.
Larry
==
Index: linux-2.6/net/ieee80211/softmac/ieee80211softmac_module.c
===
---
[EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2007-01-28 15:33
Erik Chakravarty wrote:
Apple PowerBook 5,4
BCM4306
Linux 2.6.20-6
After my machine resumes from suspend, I can see that the wireless
interface eth11 is up, but it is not connected.
iwconfig shows that all the settings are as they were before - the essid
is correctly set etc.
Erik Chakravarty wrote:
Apple PowerBook 5,4
BCM4306
Linux 2.6.20-6
After my machine resumes from suspend, I can see that the wireless
interface eth11 is up, but it is not connected.
iwconfig shows that all the settings are as they were before - the essid
is correctly set etc.
Erik Chakravarty wrote:
no, I don't see any oopses in my logs after a suspend - I don't have
debugging compiled in this kernel though... not sure if these would
still be coming through to the kernel logs if they were happening.
If, as Johannes suggested, this is a problem in softmac is there
There is a kernel oops on bcm43xx when resuming due to an overly tight timeout
loop.
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- linux-2.6.orig/drivers/net
I have really _GOOD_ news! While reviewing the latest changes in the V4
specs, I found an
interchange of the PHY version and PHY revision fields, relative to the current
V3 specs. Of the
three cards that I have, the 4306 had the same value for the PHY version and
revision. In addition,
it
Rafael J. Wysocki wrote:
On Tuesday, 6 February 2007 23:18, Pavel Roskin wrote:
On Tue, 2007-02-06 at 14:34 -0600, Larry Finger wrote:
I have really _GOOD_ news! While reviewing the latest changes in the V4
specs, I found an
interchange of the PHY version and PHY revision fields
I was a bit too enthusiastic. The patch I sent earlier actually breaks the
4318. It does make 4311
and 4312's work for the wrong reason. If you have that card, you can use it in
the meantime while we
find out just why it helps there.
Sorry for the false alarm, but we are making progress.
Larry
The patch I sent out earlier was wrong; however, it provided a clue as to what
was wrong in the
specs and in the code. As it turned out, the mistake I made earlier only
affected 4 places in the
code and it was easy to test them in turn. According to Murphy's law, the wrong
one was the last one
Rafael J. Wysocki wrote:
On Wednesday, 7 February 2007 07:34, Pavel Roskin wrote:
On Wed, 2007-02-07 at 00:02 -0600, Larry Finger wrote:
The patch below will only affect cards with PHY revision 8, which I think
are only BCM4311 and
BCM4312. At least those are the only ones in the database
Jörg Sommer wrote:
Hi,
the code in bcm43xx_wc.c:bcm43xx_wx_set_channelfreq() passes the value
unchanged to bcm43xx_freq_to_channel() which leads to mistakes, because
bcm43xx_freq_to_channel() expects the frequency in MHz, but the value
given to bcm43xx_wx_set_channelfreq() might be scaled
Johannes Berg wrote:
On Tue, 2007-02-06 at 11:39 -0600, Larry Finger wrote:
There is a kernel oops on bcm43xx when resuming due to an overly tight
timeout loop.
Come to think of it... Is there any chance of fixing the actual oops
that happens in this case? I can imagine broken hardware
Fernando Toledo wrote:
Pavel Roskin escribió:
rate: iperf reports:
1 928 Kbits/sec
2 1.69 Mbits/sec
5.53.92 Mbits/sec
6 4.78 Mbits/sec
9 6.55 Mbits/sec
11 5.97 Mbits/sec
12 8.18 Mbits/sec
18 10.4 Mbits/sec
24 13.0 Mbits/sec
36 15.1
Jochen Puchalla wrote:
this sounds wonderful! However, I applied this patch and
radio_enable_2.6.20 to my 2.6.20-rc7 on an HP nx6325 (I know you have
one as well), but still I only get 100kB/s at 1M 2M 5.5M and 11M. Do I
need the combined-patch for 2.6.20? I only have 1GB RAM and don't do
Pavel Roskin wrote:
On Wed, 2007-02-07 at 19:49 -0600, Larry Finger wrote:
+This driver has been developend using a clean-room technique that is
described
developed
+Since the release of the 2.6.17 kernel, the bcm43xx driver has been
dstributed
distributed
Please make sure
Although a number of bcm43xx chips now work at rates above 11 Mbs, I know of at
least one that does
not. It will help me in debugging the code if I know of the status of the
others. Please help me
fill in this table. If your results are not in agreement with my results, or
your chip is not in
Richard wrote:
torsdag 08 februari 2007 19:00 skrev Larry Finger:
chip/revisionphy revisionradio rev. status
==
4306/2 1 2 Fails
4306/3 2 2
Jim McCloskey wrote:
With this card:
LinkSys Wireless-G WPC54GS (ver.2))
Chip ID 0x4318, rev 0x2
Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243, enabled
bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243, disabled
bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243,
Michael,
Michael Buesch wrote:
On Friday 09 February 2007 17:32, Larry Finger wrote:
The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters
Michael Buesch wrote:
On Friday 09 February 2007 23:22, Joseph Jezak wrote:
Well, I don't review the rest until you say to which specs you did the
changes. ;)
http://bcm-specs.sipsolutions.net/B5PHY
Larry was working from the old specs, so when I updated it, I only
updated the old specs.
Rafael,
Rafael J. Wysocki wrote:
I'm running with this patch applied right now, but the association is lost
after the resume anyway. I have to reload bcm43xx to make it associate with
the AP again (no big deal).
Please send me the output of iwconfig and ifconfig after the resume, but
Miles Lane wrote:
I am testing this patch applied to the wireless-net git tree.
The card is a Linksys WPC54G. The card is still getting very
weak signal strength and the connection seems unresponsive
most of the time.
As the subject says, the patch was for 4311 and 4312 cards. The 4318's are
Michael Buesch wrote:
On Sunday 11 February 2007 15:02, Rafael J. Wysocki wrote:
PM: Removing info for No Bus::30:00.0
bcm43xx: IRQ_READY timeout
bcm43xx: core_up for active 802.11 core failed (-19)
I never tried suspend to disk with the driver.
This implies that suspend to RAM works.
Michael Buesch wrote:
On Sunday 11 February 2007 16:59, Larry Finger wrote:
Michael Buesch wrote:
On Sunday 11 February 2007 15:02, Rafael J. Wysocki wrote:
PM: Removing info for No Bus::30:00.0
bcm43xx: IRQ_READY timeout
bcm43xx: core_up for active 802.11 core failed (-19)
I never
Rafael J. Wysocki wrote:
It doesn't help in my case. The behavior is similar to that without the
patch,
but also with the patch it loses the association entirely.
Thanks for trying.
Do you have this patch installed? If you do, please try increasing the 100 to
200.
Larry
---
Index:
Rafael J. Wysocki wrote:
On Monday, 12 February 2007 02:18, Larry Finger wrote:
Rafael J. Wysocki wrote:
It doesn't help in my case. The behavior is similar to that without the
patch,
but also with the patch it loses the association entirely.
Thanks for trying.
Do you have this patch
Rafael J. Wysocki wrote:
On Monday, 12 February 2007 23:20, Larry Finger wrote:
Rafael J. Wysocki wrote:
On Monday, 12 February 2007 02:18, Larry Finger wrote:
Rafael J. Wysocki wrote:
It doesn't help in my case. The behavior is similar to that without the
patch,
but also with the patch
Rafael J. Wysocki wrote:
On Tuesday, 13 February 2007 00:24, Michael Buesch wrote:
On Tuesday 13 February 2007 00:08, Rafael J. Wysocki wrote:
On Monday, 12 February 2007 23:20, Larry Finger wrote:
Rafael J. Wysocki wrote:
On Monday, 12 February 2007 02:18, Larry Finger wrote:
Rafael J
Johannes Berg wrote:
On Tue, 2007-02-13 at 09:25 -0600, Larry Finger wrote:
The problem is that i can't get this card to work in HP or Compaq
notebooks, so what i wanted to do is to modify the subsystem id to match
the whitelist stored in HP and Compaq notebooks, so this card can work
John W. Linville wrote:
On Sat, Feb 10, 2007 at 05:41:06PM -0600, Larry Finger wrote:
Miles Lane wrote:
I am testing this patch applied to the wireless-net git tree.
The card is a Linksys WPC54G. The card is still getting very
weak signal strength and the connection seems unresponsive
most
.
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
John,
I hope this fix makes it into 2.6.21. It is the main one that makes 4311 and
4312 cards work.
Larry
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless
an ilt_write32
routine that receives a 32-bit quantity and writes it to the appropriate
locations.
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
Nearly all of the writes to the bcm43xx internal lookup tables (ilt)
involve 16-bit quantities. Accordingly, the ilt_write routine was coded to
pass a u16 value
an assert
that is no longer needed.
Once the cards are capable of full OFDM speeds, the 24 Mbs rate will be changed
to 54 Mbs.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_module.c
Michael Buesch wrote:
To summerize it.
We have different kinds of initialization problems in the
bcm43xx-softmac tree on resuming.
These usually don't show up if you suspend to ram.
But if you suspend to disk, you end up completely reloading
the driver through the resume routine. You
Michael Buesch wrote:
On Wednesday 14 February 2007 16:42, Larry Finger wrote:
marco wrote:
Hi all,
i have recently upgraded my ibook G4 from ubuntu edgy to feisty.
While on edgy bcm43xx was running fine, on feisty i am not able to have
it anymore.
When i try to load the module
Michael Buesch wrote:
So, where's the problem? What doesn't work for you with d80211?
The mb tree cannot authenticate using wpa. When I run wpa_supplicant in debug,
non-daemon mode, it
generates the following:
...
State: 4WAY_HANDSHAKE - 4WAY_HANDSHAKE
WPA: RX message 1 of 4-Way Handshake
My BCM4306 cards are among the oldest 802.11g varieties as they were actually
pre-G versions. They
have a 0x812 core rev of 4 and firmware4.fw was extracted from my V4 driver.
Therefore, it seems
safe to conclude that all GPHY varieties will be supported by d80211. Thus only
the BPHY chips
Michael Buesch wrote:
On Thursday 15 February 2007 16:23, Larry Finger wrote:
Michael Buesch wrote:
On Thursday 15 February 2007 02:22, Larry Finger wrote:
Michael Buesch wrote:
So, where's the problem? What doesn't work for you with d80211?
The mb tree cannot authenticate using wpa
Johannes Berg wrote:
On Thu, 2007-02-15 at 10:32 -0600, Larry Finger wrote:
Yes, but that testing just got more difficult. My old laptop that was used
for the purpose died, and
my new one has an ExpressCard slot. No place for PCMCIA cards. To do testing
with 4306 and 4318
varieties, I
Erik Mouw wrote:
On Thu, Feb 15, 2007 at 08:28:37PM +0100, Michael Buesch wrote:
https://launchpad.net/bugs/85404
It turns out that they ship a heavily obsolete,
deprecated and unsupported piece of bcm43xx junk.
Isn't that true for any distro?
Certainly not with openSUSE, which is my
Gene Heskett wrote:
On Monday 19 February 2007, Michael Buesch wrote:
I just want to mention that Ad-Hoc works fine
with the bcm43xx-d80211 driver in my tree.
I didn't have to do any code changes, but simply try it once. ;)
So, well. As the question has been asked several times
if adhoc is
The in-kernel documentation of the bcm43xx driver is out of date.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/Documentation/networking/bcm43xx.txt
===
--- wireless-2.6.orig/Documentation/networking
Pavel Roskin wrote:
Hello!
I'm getting assertion failure in bcm43xx_interrupt_handler() when I
unload bcm43xx without bringing the interface down first.
bcm43xx: ASSERTION FAILED (bcm43xx_status(bcm) ==
BCM43xx_STAT_INITIALIZED)
at:
Pavel Roskin wrote:
Quoting Larry Finger [EMAIL PROTECTED]:
I wish I could implement the first solution, but since the interrupts
are disabled in a loop involving core switches, things are not trivial.
What kernel, SMP/UP, PREEMPTION option, architecture and patch level of
bcm43xx, please
There are three errors in the transcription of the latest revision to the
B6PHY init specifications.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch should be applied to wireless-2.6 and sent upstream to 2.6.21-rcX.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx
The in-kernel documentation of the bcm43xx driver is out of date.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/Documentation/networking/bcm43xx.txt
===
--- wireless-2.6.orig/Documentation/networking
There are three errors in the transcription of the latest revision to the
B6PHY init specifications.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch should be applied to wireless-2.6 and sent upstream to 2.6.21-rcX.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx
Pavel Roskin wrote:
Hello!
Sorry, another look at the assert issue in bcm43xx has taken some time.
That's the complete kernel messages from the point where the driver is
inserted to the first assertion failure.
--snip--
bcm43xx: DMA-32 0x0200 (RX) max used slots: 1/64
bcm43xx: DMA-32
John W. Linville wrote:
It is in linux-2.6, wireless-2.6, and wireless-dev. If you don't
want to use those trees, you should be able to apply the patch to
the tree you are using.
If you wish to run bcm43xx-softmac from either the mb (Michael Buesch) or the
wireless-dev trees,
you can get a
There was an error in the B5PHY init specifications.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch is meant for wireless-2.6, 'upstream', and 'upstream-fixes'.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
From: Joerg Sommer [EMAIL PROTECTED]
The frequency to channel routine in bcm43xx requires that the frequency
be in MHz, but that condition is not always met. This patch does the
necessary conversion.
Signed-off-by: Joerg Sommer [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED
Dustin Souers wrote:
Hi bcm43xx developers,
I own a bcm4311 card on my laptop (HP Pavilion dv2120us). Is there
anything I can do to help get make this card work? I know the card
works under ndiswrapper. And I wish I could afford to buy you a
bcm4311 but I'm just a college student. I am
Ethtool is useless for bcm43xx - remove it.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/Makefile
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/Makefile
+++ wireless
Jeff Garzik wrote:
Larry Finger wrote:
Ethtool is useless for bcm43xx - remove it.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
How is GDRVINFO useless? Where does mac80211 provide equivalent
information?
I cannot speak for mac80211, but the current implementation for SoftMAC only
As the removal of ethtool capability from bcm43xx has been NACKed,
some useful functionality should be added. This patch changes it
so that the firmware version is output.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_ethtool.c
John,
Please pull the patch referenced in the subject. It completely kills my BCM4306
with phy-revision == 1.
Joe Jezak and I will have to sort this one out.
Thanks,
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
As many of you know, my old laptop that I was using to test PCMCIA versions of
the bcm43xx hardware
died a few weeks ago. Thanks to the generosity of the contributors to the
project, I was able to
replace it with a modest computer purchased on EBay. It is an M-Tech eSlate
400k, which has an AMD
From: Pavel Roskin [EMAIL PROTECTED]
In the bcm43xx interrupt handler, sanity checks are wrongly done before the
verification that the interrupt is for the bcm43xx.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
drivers/net/wireless/bcm43xx
301 - 400 of 1483 matches
Mail list logo
