Re: Very poor performances with bcm4306 rev. 3
Hi, It seems that I have not received any reply to my original post, so I'm trying again ;-) On Mon, Dec 22, 2008 at 1:47 PM, Olivier Fourdan wrote: > I am experiencing very poor network performance using the b34 module > with a Broadcom BCM4306 revision 3 (the system is a Compaq HP R3000 > laptop) > > The download transfer rate goes from a few bytes to 20Kb/s at max > whereas it commonly reached 200Kb under Windows or on the other > laptops in the hose (using Intel chipset under Linux, for example). > The connection is so unstable that it's causing timeouts during wget > downloads, and makes that system under Linux basically unusable... > > The problem is not exactly new and apparently been reported several > times on various forums (mostly Ubuntu) though the problem is not > distro specific (I switched from Ubuntu to Fedora, from x86_64 to i386 > and the problem remains). I checked in the archives and found some > similar problems but no solution. > > The connection is using basic WEP encryption, wpa_supplicant involved. It should read *no* wpa_supplicant involved > The router is a Netgear WGR614 v7. > > * uname -a > Linux r3000 2.6.27.7-134.fc10.i686 #1 SMP Mon Dec 1 22:42:50 EST > 2008 i686 athlon i386 GNU/Linux > > * lspci -vvn|grep 43 -A7 > 02:02.0 0280: 14e4:4320 (rev 03) > Subsystem: 103c:12fa > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR-Latency: 64 > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at e0104000 (32-bit, non-prefetchable) [size=8K] > Kernel driver in use: b43-pci-bridge > Kernel modules: ssb > > 02:04.0 0607: 104c:ac54 (rev 01) > Subsystem: 103c:006d > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR-Latency: 168, Cache Line Size: 128 bytes > > * dmesg > (attached) I should add that I can do testing as needed or report any missing information. I've tried disabling various options (starting with qos) w/out any noticeable improvement unfortunately. Any idea? Thanks in advance, Olivier. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Friday 16 January 2009 00:17:43 Kyle McMartin wrote: > On Thu, Jan 15, 2009 at 05:09:49PM +0100, Michael Buesch wrote: > > Already implemented here: > > http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch > > I just need to fix a leak in an error path before pushing that upstream. > > > > Groovy, I had cooked a similar patch for Fedora but haven't gotten > around to packaging up the fw yet. Will sub in yours. I think we can actually push my patch upstream. The remaining FIXME is not relevant for the common case and it only matters in rare circumstances (I think A-PHY only, which isn't implemented anyway). So we can fix it later. The patch should work properly as-is for G/N/LP-PHY. It probably needs a rediff against a current b43, however. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Friday 16 January 2009 00:01:41 Francesco Gringoli wrote: > On Jan 15, 2009, at 4:59 PM, Larry Finger wrote: > > > Michael Buesch wrote: > >> Yes, please introduce a feature-bitfield at some location in SHM > >> that's unused > >> by the proprietary firmware. This bitfields would contain a bit for > >> QoS and > >> a bit for hwcrypto. > >> Also change your firmware so the driver detects it as open-source > >> firmware. > >> I think that's done by writing 0x to the date/time field in > >> SHM. I don't > >> quite remember, but it's something like that. > >> Note that this might mean that the firmware watchdog in the driver > >> will trigger, > >> as that's enabled by the open-source-firmware-flag. We might want > >> to temporarly > >> disable the watchdog in the driver for the time being. > > > > I like the idea of encoding the capabilities in the firmware as it > > would be a self-documenting method as the firmware evolves. > > > > Is using the Broadcom names for the firmware the best course of > > action? What if the opensource firmware files were named something > > like "os-ucode5.fw", etc. and b43 were coded to check for those files > > first? It would then fall back to the standard firmware if the > > opensource version is not found. > > > > Larry > It could be interesting to also not separate the initvalues in two > different files, everything could be coded in a single file. Never > understood why original init values are split in two files. The normal initvalues have to be uploaded at init and the bandswitch init values have to be uploaded on bandswitch. That's a different thing. We currently implement bandswitch by re-initing, but that doesn't matter. We could easily change that in future. So don't put the initvals into one file. > Michael: SHM(0x0014) (16bit) is not used by the open source firmware, Eh no. You need to find an offset that's not used by the PROPRIETARY firmware. > A question: is the standard kernel aware that date set to > indicates an opensource firmware Yes. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
