Back On-line

I'm back on-line and will be processing my way through my backlog of bcm43xx information. My quick trip to visit my aging parents unexpectedly turned into a week-long ordeal while we got them moved from their house to a graduated living arrangement. During that time, I did not have any access

Re: [SOFTMAC] - level of verbosity

[EMAIL PROTECTED] wrote: Hi. I'd just like to know whether it is be possible to reduce the verbosity level of softmac. My wireless is working fine, but my logs are polluted by: /* LOG */ .. snip.. It's kinda polluting the interesting parts of logs, and furthermore, when it's actually written

Re: Driver problem (2.6.18 kernel) and Stauts of 4318

Karsten Jähnigen wrote: > Hello, > > additionally to my last information i would report the following state: > > Bevor the wireless 2.6.18.1 patch btw. the 2.6.18.1 kernel the card > only can receive data. The patch includes some changes in the PHY handling for 4318 chips. Good to know that t

Re: [SOFTMAC] - level of verbosity

[EMAIL PROTECTED] wrote: > That's much better, but I still receive some: > > ieee80211: eth1: IEEE80211_ASSOC_REQ received > ieee80211: eth1: IEEE80211_ASSOC_REQ received > ieee80211: eth1: IEEE80211_ASSOC_REQ received > ieee80211: eth1: IEEE80211_ASSOC_REQ received > ieee80211: eth1: IEEE80211_RE

Re: bcm43xx dscape

Jory A. Pratt wrote: > I took the plunge to see if Michael's fix to null pointer fixed the > problem I was expierencing. > > I got the device to come up and everything but device never makes an > attempt to auth with AP. > > bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 5, MAC: >

[PATCH] bcm43xx: Fix low-traffic netdev watchdog TX timeouts

than 5secs (which is the case for low or no traffic), it will fire a TX timeout. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, Please apply this patch to wireless-2.6, and push it upstream to 2.6.19. It seems to have cured _

Re: [PATCH] bcm43xx: Fix low-traffic netdev watchdog TX timeouts

Hendrik Sattler wrote: Am Sonntag 29 Oktober 2006 00:52 schrieb Larry Finger: From: Michael Buesch <[EMAIL PROTECTED]> This fixes a netdev watchdog timeout problem. The software needs to call netif_tx_disable before running the hardware calibration code. The problem condition can be sh

Re: ASSERTION FAILED

nfrench wrote: > I have been tring to get my bcm43xx working with the following system > > amd_x64 > kernel 2.6.18.1 > > patches > > patch_2.6.18.1_fix_leds > patch_2.6.18.1_signal_quality > patch_2.6.18.1_for_PCI-E Of the above patches, only signal quality has any effect on your system. If you

Re: System deaf after 6 hours

nfrench wrote: > Hi all > > just to report the following after 6 hours > > Oct 31 07:46:47 localhost kernel: NETDEV WATCHDOG: eth1: transmit timed out > Oct 31 07:46:47 localhost kernel: bcm43xx: Controller RESET (TX timeout) ... > Oct 31 07:46:47 localhost kernel: bcm43xx: select_wireless_core:

Re: [PATCH] bcm43xx: fix unexpected LED control values in BCM4303 sprom

John, I had not responded to Michael's comments as I heard from another user with thousands of these assertions in his logs, and I have been waiting for his sprom values and hoped to make a single patch. It is good, however, that you pushed the patch upstream. John W. Linville wrote: > On Wed

[RFC] bcm43xx: Removal of "badness" variable

Michael, The "badness" variable and the concept of BADNESS_LIMIT were useful during the debugging of the preemptible periodic work routines, but now that those problems seem to be fixed, I propose simplifying that section of the code according to the patch below. I believe the functionality to

[PATCH] bcm43xx: remove badness variable and related routine

was quite useful while debugging of periodic work was in progress. Now that this routine seems to be working correctly, it is time to simplify the code. This patch keeps the functionality intact, but simplifies the code. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, Plea

Re: [PATCH] bcm43xx: Drain TX status before starting IRQs

Michael Buesch wrote: > Drain the Microcode TX-status-FIFO before we enable IRQs. > This is required, because the FIFO may still have entries left > from a previous run. Those would immediately fire after enabling > IRQs and would lead to an oops in the DMA TXstatus handling code. > > Signed-off-b

Re: bcm43xx_d80211 and network-manager

Johannes Berg wrote: > On Thu, 2006-11-02 at 16:32 +0100, Hendrik Sattler wrote: > >> Note that I send this email via bcm43xx and dscape (using WPA). However, the >> wext support in dscape seems to be incomplete. > > Alright, I'll explain... > > d80211 isn't assigning any wireless stats so the

Re: bcm43xx_d80211 and network-manager

Johannes Berg wrote: > On Thu, 2006-11-02 at 10:47 -0600, Larry Finger wrote: > >> Jiri has them. They all passed his technical review, but he didn't push them >> forward due to an >> uncertainty about the user interface. I can push them to John directly if

[PATCH 0/4] d80211: Add wireless statistics

This set of patches modifies the d80211 stack and the drivers that use it to support wireless statistics. 1. Adds the necessary data and code to the d80211 routines. 2. Modifies bcm43xx-d80211 to conform. 3. Modifies adm8211-d80211 to conform. 4. Modifies the rt2x00-d80211 drivers to conform.

[PATCH 1/4] d80211: Add wireless statistics

This patch modifies d80211 to support wireless statistics. Signed-Off-By: Larry Finger <[EMAIL PROTECTED]> --- John, Please add to wireless-dev. Larry Index: wireless-dev/include/net/d80211.h === --- wireless-dev.orig/inclu

[PATCH 2/4] bcm43xx-d80211: Add wireless statistics

These patches modify bcm43xx-d80211 to use the wireless statics added in patch 1. Signed-Off-By: Larry [EMAIL PROTECTED]> --- Please apply to wireless-dev Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h === --- w

[PATCH 3/4] adm8211-d80211: Add wireless statistics (compile tested only)

These patches modify adm8211-d80211 to use the wireless statics added in patch 1. Signed-Off-By: Larry [EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c === --- wireless-dev.orig/drivers/net/wireles

[PATCH 4/4] rt2x00-d80211: Add wireless statistics (compile tested only)

These patches modify the rt2x00-d80211 family of drivers to use the wireless statics added in patch 1. Signed-Off-By: Larry [EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c === --- wireless-dev.ori

Re: [PATCH 1/4] d80211: Add wireless statistics

Hendrik Sattler wrote: > Am Donnerstag 02 November 2006 19:45 schrieb Larry Finger: >> This patch modifies d80211 to support wireless statistics. > > Just a short question, since git is quite a bit different than e.g. > subversion: > How do I correctly apply those patche

Re: [PATCH 2/4] bcm43xx-d80211: Add wireless statistics

Hendrik Sattler wrote: > Am Donnerstag 02 November 2006 19:46 schrieb Larry Finger: >> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c >> === >> --- wireless-dev.orig/drivers/net/wi

Re: BCM driver issues with ACPI / IRQ routing

Karl-Heinz wrote: > Hello, > > first of all: this driver rocks, kudos to everyone involved. After some > problems, it runs like a charm on opensuse 10.1 installed on a Sony Vaio > Z600TEK laptop (oldish PIII/700 subnote but still moving strong :-)), and > using a Buffalo WLI-CB-54L (4306, Ca

Re: bcm43xx-dev 4311 testing

Andrew Wienecke wrote: > i am currently testing the bcm43xx development driver for functionality > with the 4311 chipset, softmac is completely non functional, dscape > recognizes the card, but produces errors. > attached is the dmesg output as a .txt You do not say which version of the kernel y

[PATCH] bcm43xx: Remove useless core enable/disable messages

In the softmac version of bcm43xx, the core scan logs whether each core is enabled or disabled. This information is useless as one of the next steps is to enable all cores. This patch removes this output from the log. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, These ar

Re: [PATCH] bcm43xx: Drain TX status before starting IRQs

Jouni Malinen wrote: > On Thu, Nov 02, 2006 at 09:45:46AM +0100, Johannes Berg wrote: >> On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote: >>> Has anyone used this patch, particularly with WPA encryption? When I try >>> it, wpa_supplicant >>> immedi

[PATCH] bcm43xx: Drain TX status before starting IRQs

g code. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, Please apply this to wireless-2.6 and push it to 2.6.19. It has already been sent to -stable for inclusion in 2.6.18.3. This patch replaces one with the same name that was

[PATCH] bcm43xx: Add error checking in bcm43xx_sprom_write()

From: Adrian Bunk <[EMAIL PROTECTED]> The Coverity checker noted that these "if (err)"'s couldn't ever be true. It seems the intention was to check the return values of the bcm43xx_pci_write_config32()'s? Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Re: bcm43xx stops passing traffic on FC6

Michael Buesch wrote: > On Sunday 29 October 2006 17:28, Gregory Gulik wrote: >> I recently updated a compaq notebook to Fedora Core 6 which has the >> bcm43xx driver in the 2.6.18 kernel. I followed the instructions here: >> Installing Fedora Core 6 on Compaq Presario R3000Z >>

Re: bcm43xx stops passing traffic on FC6

Gregory Gulik wrote: > I was hoping Fedora would come out with a 2.6.18.2 kernel soon but that > doesn't seem to be coming any time soon. > > Is there an easy way to rebuild a patched driver for the Fedora kernel > without creating a custom kernel? If I read your first E-mail correctly, you hav

Any problems with bcm43xx-softmac?

As of this morning, the last two bug fixes on my list were pushed from Jeff Garzik to Andrew Morton and Linus Torvalds for inclusion in -mainline (2.6.19-rcX). In addition, all but one of the enhancements that I have sent to Linville are now in wireless-2.6.git. Fixes for the worst bugs are a

rfkill switch

Is there any indication that the appropriate bit in BCM43xx_MMIO_RADIO_HWENABLED is read/write from our side? If so, perhaps this patch would turn the radio on at startup. Compile tested only as I have no suitable hardware. Larry Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c ==

Re: Strange behavior on bcm4311

Vadim Khusainov wrote: > Hello. > > I've got a very strange behavior of bcm4311card. I can start it, I can > search for networks, but after connetcting to it I can surf only for > 5-10 seconds. After it I'm staying connected but can do nothing. > I've got dell 1390 card. I've got 2.6.18.2 kerne

Re: Any problems with bcm43xx-softmac?

Will Dyson wrote: > On 11/13/06, Larry Finger <[EMAIL PROTECTED]> wrote: > >> Please try booting with "mem=1024M" added to the kernel load line. >> This will restrict the RAM to 1 >> GB and will remove any possibility of the DMA problem wit RAM > 1 G

Re: 2.6.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)

y Daniel Drake under the title "[PATCH] ieee80211: Move IV/ICV stripping into ieee80211_rx", a needed line was accidentally removed. As my current copy of wireless-2.6.git does not contain this line, I am (re)submitting a patch to restore that line. Signed-off-by: Larry Finger <[EMAIL PRO

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

Ray Lee wrote: > Michael Buesch wrote: >> On Wednesday 15 November 2006 20:01, Ray Lee wrote: >>> Suggestions? Requests for even more info? >> Yeah, enable bcm43xx debugging. > > Sigh, didn't even think to look for that. Okay, enabled and compiling a new > kernel. This will take a few days to tri

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

Ray Lee wrote: > Larry Finger wrote: >> Ray Lee wrote: >>> Michael Buesch wrote: >>>> On Wednesday 15 November 2006 20:01, Ray Lee wrote: >>>>> Suggestions? Requests for even more info? >>>> Yeah, enable bcm43xx debugging. >>> Sig

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

ROTECTED]> > date:Wed Nov 01 08:15:40 2006 +0500 > summary: [PATCH] bcm43xx: Fix low-traffic netdev watchdog TX timeouts > > changeset: 40965:f5021f3521c2 > user:Larry Finger <[EMAIL PROTECTED]> > date:Wed Nov 01 08:15:41 2006 +0500 >

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

Ray Lee wrote: > First off, thanks for all your help. > > Second off, > > On 11/16/06, Larry Finger <[EMAIL PROTECTED]> wrote: >> Ray Lee wrote: >> > >> > If I could figure out a way to make it repeatable, I'd happily do a >> blind >

Re: Any problems with bcm43xx-softmac?

Will Dyson wrote: On 11/15/06, Larry Finger <[EMAIL PROTECTED]> wrote: My records show a patch sent for testing on 9/22/06, but I have no record of when it went to wireless-2.6; however, on my system it is in wireless-2.6 (Linville) and 2.6.19-rc5 (Torvalds). Please check your sources

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

Johannes Berg wrote: > > No, wireless-dev supports v4 firmware only and mainline v3 firmware only > (but mainline will reject v4 firmware and not screw up like earlier > versions) This seems a good point to interject a question. Should mainline (i.e. bcm43xx-SoftMAC) support v4 firmware, or is

Re: Broadcom 4318 card?

Johannes Berg wrote: > Does anyone know of a cardbus 4318? > > Also, any ideas what Linksys's products > * WPC54GX4 > * WPC54GS > * WPC54GX > * WPC54GR > * WPC54G Old WPC54G's (V1) have a 4306. I don't know about later versions. > * WPC55AG > > contain? Larry

Re: Broadcom 4318 card?

Johannes Berg wrote: > On Fri, 2006-11-17 at 11:05 -0600, Larry Finger wrote: > >> Old WPC54G's (V1) have a 4306. I don't know about later versions. > > Hm, Eric says that V3 have 4318... That wouldn't be easy to get the > right one I guess unless I

Re: Broadcom 4318 card?

Erik Mouw wrote: > On Fri, Nov 17, 2006 at 11:53:42AM -0600, Larry Finger wrote: >> Johannes Berg wrote: >>> On Fri, 2006-11-17 at 11:05 -0600, Larry Finger wrote: >>> >>>> Old WPC54G's (V1) have a 4306. I don't know about later versions. >&g

Re: Any problems with bcm43xx-softmac?

Will Dyson wrote: > On 11/17/06, Larry Finger <[EMAIL PROTECTED]> wrote: >> Will Dyson wrote: >> > On 11/15/06, Larry Finger <[EMAIL PROTECTED]> wrote: >> > >> >> My records show a patch sent for testing on 9/22/06, but I have no >> rec

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

Johannes Berg wrote: > On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote: > >> This sounds like what my laptop was doing in -rc5, though mine >> didn't take hours to start acting up. >> >> I *think* it was the MSI troubles, causing interrupts to get >> lost forever. Anyway, it went a

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

Ray Lee wrote: > Larry Finger wrote: >> Johannes Berg wrote: >>> Hah, that's a lot more plausible than bcm43xx's drain patch actually >>> causing this. So maybe somehow interrupts for bcm43xx aren't routed >>> properly or something... >>&

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

Johannes Berg wrote: > On Fri, 2006-11-17 at 21:11 -0500, Joseph Jezak wrote: > >>> v4 firmware only > >> Note that this means we should drop support for bcm4301 and bcm4303 >> devices (which have been reported working in the past) since the >> firmware is incompatible with those models. Is that

Re: BCM4318, come on guys :-)

Ramanalinarivo Sandrinah Vonisoa Annie wrote: > Hi, > I just post this to encourage guys to fix problems on 4318 chipset. > I have a 32bit (Celeron M) Acer 3630 (notebook), and "lspci": > > 00:0b.0 Network controller: Broadcom Corporation BCM4318 > [AirForce One 54g] 802.11g Wireless

[RFT] bcm43xx-softmac: match specifications change in rssi processing

processing. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c === --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c +++ wireless-2.6/drivers/net/wi

[PATCH] softmac: remove netif_tx_disable when scanning

nsmits, it may override the wishes of a driver that may have very good reasons for disabling transmits. No specific problems can be blamed directly on this bug, but it may be responsible for some unexplained behavior. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Signed-off-by: Larry Fi

[PATCH] softmac: reduce scan debug output

When scanning in debug mode, softmac is very chatty in that it puts 3 lines in the logs for each time it scans. This patch has only one line containing all the information previously reported. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, Please apply this to wireless-2.6.

Re: [PATCH] softmac: remove netif_tx_disable when scanning

Michael Buesch wrote: > On Sunday 26 November 2006 11:03, Johannes Berg wrote: >> On Sat, 2006-11-25 at 23:05 -0500, Daniel Drake wrote: >> >>> Surely disabling the queue actually makes sense, in order to avoid >>> frames designated for the "current session" being transmitted on >>> different cha

Re: [PATCH] softmac: remove netif_tx_disable when scanning

Johannes Berg wrote: > On Sun, 2006-11-26 at 13:25 -0500, Daniel Drake wrote: > >> No, we could stick with our existing setup if the stack did something >> different. > > But you do need full refcounting I guess. > >>> Because for >>> the stack it wouldn't be required if it'd simply not start s

Patch to update 2.6.19-rc5 for Michael's d80211 tree

The patch file "patch_2.6.19-rc5_to_mb_wdev" has been added to ftp://lwfinger.dynalias.org/patches. This patch will update vanilla 2.6.19-rc5 to have the d80211 code of Michael Buesch's development tree. With this patch, you can run a d80211 kernel without using git. Please note that this vers

[PATCH take2] softmac: remove netif_tx_disable when scanning

igned-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, I assume you have seen the discussion on this matter in the netdev mailing list. I agree with Michael that this patch should be applied despite the intoduction of a new bug. Please apply this to wireless-2.6 and push it upstream for i

Re: [PATCH] bcm43xx-softmac: Fix system hang for x86-64 with >1GB RAM

Andrew Fuller wrote: Larry This looks like the same patch that I tried that didn't work for me (with the photographed kernel panics which I sent to you off-list). I'm not saying it shouldn't go in -- in fact I think it should if it helps somebody. It certainly doesn't make anything worse for m

Re: [PATCH] bcm43xx-softmac: Fix system hang for x86-64 with >1GB RAM

Andrew Fuller wrote: I applied the patch to a fresh git clone wireless-2.6 and booted it up. Unfortunately it's still a no-go on my machine. I logged /var/log/messages via SSH (see below). I got a kernel panic, but since I didn't have console output, I didn't take a picture. If the panic wou

Patch for > 1 GB RAM (11/28 version)

Andrew and Will, Attached is another patch to try. I found a section that I previously missed, but I don't think this one triggers. In addition, I fixed up the printk's in the section where dma memory is mapped. I should be able to tell more about what is happening. Thanks again guys for your

Progress report

I got my BCM4318 card and the RF receiver. I have not had much time to experiment; however, I can report why speeds above 11 Mbs are dicey. When using the standard bcm43xx-softmac software and transmitting with CCK modulation at 11 Mbs, I get TX power at my receiver of -36 dBm. When transmittin

Re: Progress report

Erik Mouw wrote: > On Wed, Nov 29, 2006 at 12:00:49PM +0100, Florian Fainelli wrote: >> Le mercredi 29 novembre 2006 07:54, Larry Finger a écrit : >>> When using the standard bcm43xx-softmac software and transmitting with CCK >>> modulation at 11 Mbs, I get TX power at m

Re: git and 4311

Fernando Toledo wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all , i have a 4311 (laptop hp nx7400) > 10:00.0 0280: 14e4:4311 (rev 01) > Subsystem: 103c:1364 > Flags: bus master, fast devsel, latency 0, IRQ 11 > Memory at f400 (32-bit, non-prefetchabl

Patch for > 1 GB RAM (12/01 version)

Will and Andrew, Attached is the next round of the > 1 GB RAM patch. The main change is to use pci_alloc_coherent rather than dma_alloc_consistent to get the proper memory. That was the only difference between our code and the b44 driver, which is supposed to work. Good luck and again my than

Re: 4311 and pcie patch results

Jochen Puchalla wrote: > [Freitag, 1. Dezember 2006 19:33] schrieb Fernando Toledo (wrote): > >> here can be the problem, the channel do not change to 11 (2.462 GHz) and >> still in 14 ( Frequency=2.484 GHz) >> >> i do not see the AP's too >> >> my notebook is a hp nx7400 that have a button to act

Re: 4311 and pcie patch results

Fernando Toledo wrote: > > hi! =( > im not using ndiswrapper.. > i have a realtek pcmcia with kismet a cant see anything The reason you don't see anything is that your radio is not turned on. At the moment, bcm43xx does not know what happens in the hardware when you push the RF KILL button on y

Patch for > 1 GB RAM (12/01 version #2)

Will and Andrew, The log from the 12/01 version looked encouraging; however, I wonder why allocating the RX buffer went well for a while, then crashed. Attached is the next round of the > 1 GB RAM patch. I found one other place where the dma rather than pci layer was invoked, and I cleaned up

Re: 4311 and pcie patch results

Michael Buesch wrote: > On Saturday 02 December 2006 00:51, Larry Finger wrote: >> Fernando Toledo wrote: >>> hi! =( >>> im not using ndiswrapper.. >>> i have a realtek pcmcia with kismet a cant see anything >> The reason you don't see anything

Re: 4311 and pcie patch results

Michael Buesch wrote: > On Saturday 02 December 2006 16:49, Larry Finger wrote: >> Michael Buesch wrote: >>> On Saturday 02 December 2006 00:51, Larry Finger wrote: >>>> Fernando Toledo wrote: >>>>> hi! =( >>>>> im not using ndiswr

HW enable patch

Does this patch make your radio come on without any special tricks? If it does, we will then be able to go for actually using the RF button. Larry Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c === --- wireless-2.6

HW enable patch (V2)

New version incorporates Michael's comments. Does this patch make your radio come on without any special tricks? If it does, we will then be able to go for actually using the RF button. Larry Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c ===

[PATCH] softmac: fix unbalanced mutex_lock/unlock in ieee80211softmac_wx_set_mlme

From: Maxime Austruy <[EMAIL PROTECTED]> Routine ieee80211softmac_wx_set_mlme has one return that fails to release a mutex acquired at entry. Signed-off-by: Maxime Austruy <[EMAIL PROTECTED]> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John and Chris, This error was

Re: HW enable patch (V2)

Johannes Berg wrote: > On Sat, 2006-12-02 at 12:06 -0600, Larry Finger wrote: > >> +bcm43xx_write32(bcm, BCM43xx_MMIO_RADIO_HWENABLED_HI, > >> +bcm43xx_write16(bcm, BCM43xx_MMIO_RADIO_HWENABLED_LO, > > I'm still convinced that these r

HW enable patch (V3)

This version of the patch will find out if the HW enable bit is r/w or ro. It attempts to hw disable the radio, saves the results, enables the radio, and returns the values off/on values found in the HW radio control word. Please try this and send me the log. Thanks, Larry Index: wireless-2.6

Re: HW enable patch (V3)

Fernando Toledo wrote: > > load and up the interface > > PCI: Enabling device :10:00.0 ( -> 0002) > ACPI: PCI Interrupt :10:00.0[A] -> GSI 17 (level, low) -> IRQ 177 > PCI: Setting latency timer of device :10:00.0 to 64 > bcm43xx: Chip ID 0x4311, rev 0x1 > bcm43xx: Number of cores

RFC/T: bcm43xx: report radio hardware status

The patch below implements a function to obtain the status of the hardware enable bit of the radio, and report this status to the log when the core is initialized. It also places code in the periodic work handler to report any changes in the status. One other change is to remove some unused code

Re: RFC/T: bcm43xx: report radio hardware status

Michael Buesch wrote: >> @@ -3254,6 +3258,12 @@ static void bcm43xx_periodic_work_handle >> spin_lock_irqsave(&bcm->irq_lock, flags); >> } >> >> +radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm); >> +if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) { >> +

Re: RFC/T: bcm43xx: report radio hardware status

Johannes Berg wrote: > On Tue, 2006-12-05 at 19:51 +0100, Michael Buesch wrote: > >> Ok, thanks. You can try to uncomment it. >> I think it will crash with a bus machinecheck. Because we already disabled >> something >> of the device before (crystal?). > > Be careful here. It will probably not c

Re: [PATCH] softmac: Fixed handling of deassociation from AP

Michael Buesch wrote: > On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote: >> On 06-12-06 21:52 Michael Buesch wrote: >> >>> On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: On 06-12-06 18:52 Michael Buesch wrote: > All data in mac->associnfo is protected by mac->assoc

Re: HW enable patch (V3)

Jochen Puchalla wrote: > [Donnerstag, 7. Dezember 2006 09:34] schrieb Igor Korot (wrote): > >> Larry, >> One small addition, but I think very important. >> This is a dual-boot laptop. If I boot the Windows first, and then boot >> Linux, the WiFi LED stays on. The driver loads on the boot, as the

Re: HW enable patch (V3)

Jochen Puchalla wrote: > [Montag, 4. Dezember 2006 18:46] schrieb Fernando Toledo (wrote): > >> bcm43xx: Radio HWenable on: off/on state 0x1 0x1 >> bcm43xx: Chip initialized >> bcm43xx: 32-bit DMA initialized >> bcm43xx: Keys cleared >> bcm43xx: Selected 802.11 core (phytype 2) >> >> >> i text pre

Re: RFC/T: bcm43xx: report radio hardware status

Carlo Marcelo Arenas Belon wrote: > >> Michael Buesch wrote: @@ -3254,6 +3258,12 @@ static void bcm43xx_periodic_work_handle spin_lock_irqsave(&bcm->irq_lock, flags); } + radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm); + if (unlikely(bcm->radio_hw_

Re: RFC/T: bcm43xx: report radio hardware status

Carlo Marcelo Arenas Belon wrote: > >> I think this change is a useful one, but one question remains. Will we be >> able to control the LED from this code? If so, I suspect that we will want >> a response that is faster than 15 seconds. In that case, the periodic work >> handler will need to be

Re: Lockups on Apple G4 PowerBooks/iBooks?

Erik Chakravarty wrote: > I take it that this is not a problem known to be associated with the > bcm43xx driver then, which means I will have to do some further testing. > > The problem in diagnosing this is that it's difficult to see log output > once the machine's locked - the first thing I noti

Re: is the SPEC wrong/inconsistent for the "check radio disable/enable in hardware" bit?

Carlo Marcelo Arenas Belon wrote: > Greetings, > > after playing a little further with Larry's code and re-reading the last > threads on the hardware enabled radio got the following doubts that I wonder > you guys could help solving (I volunteer to do the patches and the cleanup if > agreed) > >

Re: RFC/T: bcm43xx: report radio hardware statusa (V2)

Carlo Marcelo Arenas Belon wrote: > On Sun, Dec 10, 2006 at 04:12:45PM -0600, Larry Finger wrote: >> This version of the patch not only reports the status of the >> hardware-enabled flag, but it also sets >> the LED's 2 and 3 with opposite states. > > why?, isn&#x

Re: BCM43XG support?

Armijn Hemel wrote: > hi, > > as I said here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219045 > the BCM43XG card I have (NETGEAR WN511B) is not supported (there actually > seems to be a difference between BCM43xG and BCM43XG). > > After I added the PCI identifier to the Fedora Core 6

Re: ieee80211 sleeping in invalid context

Ray Lee wrote: > Michael Buesch wrote: >> Congratulations to your decision ;) > > Sometimes making decisions via Brownian motion has its advantages. > >> Which kernel are you using? > > Hmm, I'm using the mercurial repository, let me see if I can translate that > to a git > head... Looks like g

Re: BCM43XG support?

Armijn Hemel wrote: > On Tue, Dec 12, 2006 at 06:24:42PM -0600, Larry Finger wrote: > >>> as I said here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219045 >>> the BCM43XG card I have (NETGEAR WN511B) is not supported (there actually >>> seems to be

Re: BCM43XG support?

Armijn, In the initialization sequence, there were some reads of the PCI space that were not checked for returned errors. The attached patch implements these checks. Please install it and send me the logged output. The patch will not fix your problem, but it should avoid the oops. I would als

Re: BCM43XG support?

Imre Kaloz wrote: > Hello Armijn ;) > > > The 4329 is a draft-N device, and bcm43xx doesn't have support for the > MIMO stuff at all, yet. We do try to operate a draft-N device as a G PHY; however, the newer PHY's will likely have the same problems as 4318's. Full operation of N devices wil

Re: bcm4311: card up but scan fails

Fabian Förg wrote: Yes, it has a radio on/off button. The blue LED of the button is on and according to dmesg the radio is also on, but the card's unable to receive/transmit any packages. Each radio has a software turn-on method, which is what bcm43xx means when it says the radio is on. In ad

Re: bcm4311: card up but scan fails

Fabian Förg wrote: > Larry Finger wrote: >> Fabian Förg wrote: >>> Yes, it has a radio on/off button. The blue LED of the button is on >>> and according to dmesg the radio is also on, but the card's unable to >>> receive/transmit any packages. >&

Re: RFC/T: bcm43xx: report radio hardware statusa (V2)

Igor Korot wrote: > Jochen, > I just applied the patch to 2.6.18 gentoo kernel. This is a vanilla kernel > that's > include Gentoo specific patches. > It did apply cleanly, and I could even reboot. > Here are the output that I got with the 2 patches. > > The WiFi LED was not turned on in my case.

Re: 4311 led patch results radio button work

Fernando Toledo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i can not use the larry patch as is(dont work for me and get errors when aplied) but i patched manually my files to a fresh git wireless-2.6 i can announce that the radio button respond now i get the messages when press it

Re: bcm43xx working on Lenovo 3000 c100

AMD wrote: > Hi! > I've a laptop "Lenovo 3000 c100" which has this Broadcom wireless: > > $ lspci -nv -s 1:2 > 01:02.0 0280: 14e4:4319 (rev 02) > Subsystem: 14e4:044a > Flags: bus master, fast devsel, latency 128, IRQ 217 > Memory at c0002000 (32-bit, non-prefetchable) [siz

Re: iwlist scan -> no scan results with 2.6.19.1

t u wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I sent this before but looks like it didn't go through. > > I filed this to the bugzilla, but all the documentation I read about the > kernel recommends posting to the mailing lists so here I go: > > I'm using Ubuntu 6.06

Re: bcm43xx: iwlist scan: "no scan results" with 2.6.19.1

I read your message on LKML and the bugzilla entry. For best results with bcm43xx problems, please post to the bcm43xx mailing list or to the netdev mailing list (both are on the CC list here). Unfortunately, you built your 2.6.19.1 system with bcm43xx debugging disabled. It is impossible to

Re: [2.6.20 PATCH] Fix work_struct fallout in ieee80211softmac

David Woodhouse wrote: > 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

bcm43xx-softmac code to handle (at least one) iface with an rfkill switch

My wife's laptop, an HP zx5000, has a BCM4306 Rev 3 mini-pci card with an rfkill switch. Recently Windows decided to corrupt the partition data so that the Micr$oft OS [sic] couldn't mount the drive. Fortunately, Linux could mount the NTFS partition without any difficulty. While I was backing u

Re: bcm43xx-softmac code to handle (at least one) iface with an rfkill switch

Jory A. Pratt wrote: It would be nice if this would apply against 2.6.19.1 :) not too many of us are ready to jump all the way out to 2.6.20_rc1 as we know just how buggy it is with the new changes to workqueue Thanks For your work your doing an awsome job. Wireless-2.6 is a 2.6.19 kernel.

  1   2   3   4   5   6   7   8   9   10   >