On Thursday, 8 February 2007 01:10, Larry Finger wrote:
> 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 Mb
Hello!
This patch to bcm43xx_d80211 makes my bcm4312 associate with 802.11g
access points immediately:
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index e101ed5..1470c5b 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm4
On Thursday, 8 February 2007 02:17, Larry Finger wrote:
> 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
>>> +with the kernel source, and is prebuilt in most, if not all, distributions.
>>> +There is, however, additional software that is required. Because the
>>> firmware
>>> +used by the processor in the Broadcom chip is copyrighted, it is not
>>> possible
>>> +for any third party to distribute it.
Hello, Larry!
Thanks for clarification.
On Wed, 2007-02-07 at 23:09 -0600, Larry Finger wrote:
> > Could you please rename those patches to add .diff ot .path to the
> > names? Many editors would highlight the patches nicely if they are
> > maned like this. Not to mention that files ending with
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
>
> Pleas
Hello!
Maybe this could be incorporated into fwcutter README. Maybe it could
even turned into scripts.
The latest V4 firmware (driver version 4.102.15.61) can be obtained by:
wget
http://www.station-drivers.com/telechargement/broadcom/broadcom%20bcm-43x-4.102.15.61-vista.exe
7za x "broadcom bc
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 to spell check the final editi
On 2/7/07, Larry Finger <[EMAIL PROTECTED]> wrote:
[...]
> +http://developer.berlios.de/project/showfiles.php?group_id=4547.
-http://developer.berlios.de/project/showfiles.php?group_id=4547.
+http://developer.berlios.de/project/showfiles.php?group_id=4547
[...]
> +http://downloads.openwrt.org
I have rewritten Documentation/networking/bcm43xx.txt. I would appreciate your
comments.
Thanks,
Larry
=
Index: wireless-2.6/Documentation/networking/bcm43xx.txt
===
--- wireless-2.6.orig/Documentation/n
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
>
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Roskin escribió:
> Hello!
>
> I wanted to measure speeds in the softmac driver at all rates, but it
> looks like I have found something more interesting in process.
>
> The station is a BCM4312 in Dell Latitude with an antenna embedded into
> t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joseph Jezak escribió:
>> bcm43xx: Controller RESET (TX timeout) ...
>> bcm43xx: IRQ_READY timeout
>> bcm43xx: core_up for active 802.11 core failed (-19)
>> bcm43xx: Controller restart failed
>> bcm43xx: ASSERTION FAILED (!err)
>> at: /home/proski/src
> I use a BCM4318 on PPC. When I first boot, I get:
> bcm43xx: It took 16 tries to set IRQ_READY
>
> Then I suspend-to-RAM, and after wake-up, I get:
> bcm43xx: It took 65 tries to set IRQ_READY
Maybe the error is somewhere else.
AFAIK a PC-Card is handled like a PCI device. Therefore, from
pciu
Daniel Gryniewicz wrote:
> On Wed, 2007-02-07 at 03:17 -0500, Pavel Roskin wrote:
>> On Wed, 2007-02-07 at 03:03 -0500, Gene Heskett wrote:
>>
>>> And the 4318 is whats in my lappy. What does it break?
>> Oh, please, let's stop such questions. Does it really matter what some
>> knowingly wrong ch
On Wed, 2007-02-07 at 03:17 -0500, Pavel Roskin wrote:
> On Wed, 2007-02-07 at 03:03 -0500, Gene Heskett wrote:
>
> > And the 4318 is whats in my lappy. What does it break?
>
> Oh, please, let's stop such questions. Does it really matter what some
> knowingly wrong change does to particular har
On Wednesday 07 February 2007 04:31, Larry Finger wrote:
> There is a typographical error in the spefications that interchange the PHY
> version
> and revision. Fixing this error makes all BCM43xx varieties work at full CCCK
> rates.
>
> Signed-off-by: Larry Finger<[EMAIL PROTECTED]>
> ---
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Larry Finger wrote:
> Johannes Berg wrote:
>> On Wed, 2007-02-07 at 07:23 -0600, Larry Finger wrote:
>>
>>> As you suggested earlier, a slow clock setting in the bcm43xx device may be
>>> the cause of this
>>> difficulty. If my laptop would suspe
On Wed, 2007-02-07 at 07:50 -0600, Larry Finger wrote:
> Could you please apply this patch and tell me what gets printed after you
> resume, and whether you
> did a suspend to RAM or disk?
Oh and if anyone else does this please also let us know what it prints
on a regular freshly booted modprobe
On Wed, 2007-02-07 at 07:50 -0600, Larry Finger wrote:
> Could you please apply this patch and tell me what gets printed after you
> resume, and whether you
> did a suspend to RAM or disk?
Not a bad idea. I can test suspend to ram as well as to disk, just got
both working again.
The kernel I'm
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 sca
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
Johannes Berg wrote:
> On Wed, 2007-02-07 at 07:23 -0600, Larry Finger wrote:
>
>> As you suggested earlier, a slow clock setting in the bcm43xx device may be
>> the cause of this
>> difficulty. If my laptop would suspend/resume correctly, then I could test
>> various fixes based on
>> that hypo
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.
>
> BCM4312, old
On Wednesday, 7 February 2007 14:23, Larry Finger wrote:
> 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 th
On Wed, 2007-02-07 at 07:23 -0600, Larry Finger wrote:
> As you suggested earlier, a slow clock setting in the bcm43xx device may be
> the cause of this
> difficulty. If my laptop would suspend/resume correctly, then I could test
> various fixes based on
> that hypothesis.
Mine does suspend, b
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 hardw
> bcm43xx: Controller RESET (TX timeout) ...
> bcm43xx: IRQ_READY timeout
> bcm43xx: core_up for active 802.11 core failed (-19)
> bcm43xx: Controller restart failed
> bcm43xx: ASSERTION FAILED (!err)
> at: /home/proski/src/linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main
> .c:4057:bcm43xx_net_s
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 somehow different.
Also pa
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 or firmware
that causes thi
On Wed, 2007-02-07 at 03:03 -0500, Gene Heskett wrote:
> And the 4318 is whats in my lappy. What does it break?
Oh, please, let's stop such questions. Does it really matter what some
knowingly wrong change does to particular hardware? Just don't try the
old patch. Just forget that it existed.
On Tuesday 06 February 2007 23:40, Larry Finger wrote:
>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.
>
>
33 matches
Mail list logo
