date:20080425

Re: [PATCH] b43: Fix some TX/RX locking issues

2008-04-25 Thread Larry Finger

Michael Buesch wrote:
> This fixes some TX/RX related locking issues.
> With this patch applied, some of the PHY transmission errors are fixed.
> 
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> 
> ---
> 
> John, this is for 2.6.26.
> 
> 

This patch cures the single PHY transmission error that always 
occurred when enabling DMA for BCM4311/2.

Emphatic ACK.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Larry Finger

Richard Jonsson wrote:
> Larry Finger skrev:
>> Richard Jonsson wrote:
>>> flipping switch a few times, led unchanged
>>> [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED
>>> [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED
>>> [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED
>>> [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED
>> This sounds like an rfkill/led configuration problem. In your .config, 
>> you should have
>>
>> CONFIG_MAC80211_LEDS=y
>> CONFIG_RFKILL=m
>> CONFIG_RFKILL_INPUT=m
>> CONFIG_RFKILL_LEDS=y
>> CONFIG_B43_LEDS=y
>> CONFIG_B43_RFKILL=y
>>
> Confirmed, but the problem for me is how to select MAC80211_LEDS and 
> B43_LEDS. Searching in menuconfig I found this:
> 
> Symbol: B43_LEDS [=n]
> Symbol: RFKILL_LEDS [=n]
> 
> with no more info below them. 
>  Then MAC80211_LEDS turned up this:
> 
> Symbol: MAC80211_LEDS [=n] 
>  
>Prompt: Enable LED triggers 
>  
>Defined at net/mac80211/Kconfig:74 
>  
>   Depends on: NET && !S390 && MAC80211 && LEDS_TRIGGERS 
>  
> 
> Location:
>-> Networking 
> 
>  -> Networking support (NET [=y]) 
> 
>-> Wireless 
> 
>  -> Generic IEEE 802.11 Networking Stack (mac80211) (MAC80211 
> [=y])
> Selected by: IWL4965_LEDS && NETDEVICES && !S390 && IWL4965 || 
> IWL3945_LEDS && NETDEVICES && !S390 && IWL3945
> 
> So without IWL4965 / IWL3945 MAC80211_LEDS can't be selected!!
> 
> Selecting IWL3945 and IWL3945_LEDS and reloading menuconfig gives me:

I duplicate your results from menuconfig; however, the appropriate 
stanza in net/mac80211/Kconfig is

config MAC80211_LEDS
 bool "Enable LED triggers"
 depends on MAC80211 && LEDS_TRIGGERS
 ---help---
   This option enables a few LED triggers for different
   packet receive/transmit events.

There is no mention of IWL3945, etc, and only MAC80211 and 
LEDS_TRIGGERS (discussed below) are needed.

> 
> CONFIG_MAC80211_LEDS=y
> CONFIG_RFKILL=m
> CONFIG_RFKILL_INPUT=m
> CONFIG_RFKILL_LEDS=n
> CONFIG_B43_LEDS=y
> CONFIG_B43_RFKILL=y
> 
> I still can't enable RFKILL_LEDS because I have no clue as to what else 
> needs to be enabled :/

You get CONFIG_RFKILL_LEDS from Networking -> RF Switch subsystem 
support, which has an M, and the "Input layer to RF switch connector" 
in the sub-menu, which also should be M. This section is the one that 
has LEDS_TRIGGERS.

I only use menuconfig for systems that don't run X, and have never 
noticed that the dependencies in the help are messed up there. AFAIK, 
the Kconfig files are OK, and the problem is in menuconfig's parsing 
of those files.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH] b43: Don't disable IRQs in mac_suspend

2008-04-25 Thread Michael Buesch

This patch removes the IRQ-disable from mac_suspend.
The main advantage of this is to get rid of the IRQ-sync call in mac_suspend.
We need to remove the MAC suspend bit from the IRQ service mask, as otherwise
the IRQ handler would race with us.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

---

John, this is for 2.6.27


Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2008-04-25 
19:28:42.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/b43.h 2008-04-25 
21:05:29.0 +0200
@@ -407,14 +407,13 @@ enum {
 #define B43_IRQ_RFKILL 0x1000
 #define B43_IRQ_TX_OK  0x2000
 #define B43_IRQ_PHY_G_CHANGED  0x4000
 #define B43_IRQ_TIMEOUT0x8000
 
 #define B43_IRQ_ALL0x
-#define B43_IRQ_MASKTEMPLATE   (B43_IRQ_MAC_SUSPENDED | \
-B43_IRQ_TBTT_INDI | \
+#define B43_IRQ_MASKTEMPLATE   (B43_IRQ_TBTT_INDI | \
 B43_IRQ_ATIM_END | \
 B43_IRQ_PMQ | \
 B43_IRQ_MAC_TXERR | \
 B43_IRQ_PHY_TXERR | \
 B43_IRQ_DMA | \
 B43_IRQ_TXFIFO_FLUSH_OK | \
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c   2008-04-25 
18:47:08.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c2008-04-25 
21:05:29.0 +0200
@@ -2319,17 +2319,12 @@ void b43_mac_enable(struct b43_wldev *de
b43_write32(dev, B43_MMIO_GEN_IRQ_REASON,
B43_IRQ_MAC_SUSPENDED);
/* Commit writes */
b43_read32(dev, B43_MMIO_MACCTL);
b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
b43_power_saving_ctl_bits(dev, 0);
-
-   /* Re-enable IRQs. */
-   spin_lock_irq(&dev->wl->irq_lock);
-   b43_interrupt_enable(dev, dev->irq_savedstate);
-   spin_unlock_irq(&dev->wl->irq_lock);
}
 }
 
 /* http://bcm-specs.sipsolutions.net/SuspendMAC */
 void b43_mac_suspend(struct b43_wldev *dev)
 {
@@ -2337,20 +2332,12 @@ void b43_mac_suspend(struct b43_wldev *d
u32 tmp;
 
might_sleep();
B43_WARN_ON(dev->mac_suspended < 0);
 
if (dev->mac_suspended == 0) {
-   /* Mask IRQs before suspending MAC. Otherwise
-* the MAC stays busy and won't suspend. */
-   spin_lock_irq(&dev->wl->irq_lock);
-   tmp = b43_interrupt_disable(dev, B43_IRQ_ALL);
-   spin_unlock_irq(&dev->wl->irq_lock);
-   b43_synchronize_irq(dev);
-   dev->irq_savedstate = tmp;
-
b43_power_saving_ctl_bits(dev, B43_PS_AWAKE);
b43_write32(dev, B43_MMIO_MACCTL,
b43_read32(dev, B43_MMIO_MACCTL)
& ~B43_MACCTL_ENABLED);
/* force pci to flush the write */
b43_read32(dev, B43_MMIO_MACCTL);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Larry Finger skrev:
> Richard Jonsson wrote:
>> flipping switch a few times, led unchanged
>> [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED
>> [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED
>> [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED
>> [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED
> 
> This sounds like an rfkill/led configuration problem. In your .config, 
> you should have
> 
> CONFIG_MAC80211_LEDS=y
> CONFIG_RFKILL=m
> CONFIG_RFKILL_INPUT=m
> CONFIG_RFKILL_LEDS=y
> CONFIG_B43_LEDS=y
> CONFIG_B43_RFKILL=y
> 
Confirmed, but the problem for me is how to select MAC80211_LEDS and 
B43_LEDS. Searching in menuconfig I found this:

Symbol: B43_LEDS [=n]
Symbol: RFKILL_LEDS [=n]

with no more info below them. 
 Then MAC80211_LEDS turned up this:

Symbol: MAC80211_LEDS [=n] 
 
   Prompt: Enable LED triggers 
 
   Defined at net/mac80211/Kconfig:74 
 
  Depends on: NET && !S390 && MAC80211 && LEDS_TRIGGERS 
 

Location:
   -> Networking 

 -> Networking support (NET [=y]) 

   -> Wireless 

 -> Generic IEEE 802.11 Networking Stack (mac80211) (MAC80211 
[=y])
Selected by: IWL4965_LEDS && NETDEVICES && !S390 && IWL4965 || 
IWL3945_LEDS && NETDEVICES && !S390 && IWL3945

So without IWL4965 / IWL3945 MAC80211_LEDS can't be selected!!

Selecting IWL3945 and IWL3945_LEDS and reloading menuconfig gives me:

CONFIG_MAC80211_LEDS=y
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=n
CONFIG_B43_LEDS=y
CONFIG_B43_RFKILL=y

I still can't enable RFKILL_LEDS because I have no clue as to what else 
needs to be enabled :/

> I think those are all the configuration parameters relating to operation 
> of the LED.
> 
> If you had the problem related to the HP recall, your interface wouldn't 
> show up in the lspci output. It might be intermittent. Furthermore, if 
> it were present at boot time so that b43 got loaded, and then 
> disappeared, the kernel would abort with the "caps lock" light flashing 
> at 1 Hz.
> 
Thanks for the clarification. Will probably flash the bios at least to 
prevent a future failure.

> If Linus's latest git still has the problem, please do a bisection. I 
> had a problem with interrupt routing on my other laptop, which kept it 
> from booting. That problem is now fixed. I thought it only affected the 
> PCMCIA bridges, but there could have been other side affects. I built 
> other kernels in the 2.6.25-git sequence, but never booted any of them 
> till this morning.
> 
I will do a bisection then, as the problem is still present.

regards, Richard
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Here comes a slice of dmesg with debugging turned on. This is from 
v2.6.25-4571-g87322bc of mainline. Same as before.

Richard Jonsson skrev:
 >> OK, after bootup with v2.5.25-rc3-git I get this, looks sane to me:
 >>
 >> [   32.474786] b43-phy0: Loading firmware version 351.126 (2006-07-29
 >> 05:54:02)
 >> [   32.474797] b43-phy0 warning: You are using an old firmware image.
 >> Support for old firmware will be removed in July 2008.
 >> [   32.474802] b43-phy0 warning: You must go to
 >> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and
 >> download the latest firmware (version 4).
 >> [   30.137115] warning: `avahi-daemon' uses 32-bit capabilities (legacy
 >> support in use)
 >> [   32.774279] PM: Adding info for No Bus:vcs7
 >> [   32.774317] PM: Adding info for No Bus:vcsa7
 >> [   31.049445] PM: Adding info for No Bus:hw_random
 >> [   31.062460] b43-phy0: Radio hardware status changed to DISABLED
 >> [   31.773470] b43-phy0: Radio turned on by software
 >> [   31.773475] b43-phy0: The hardware RF-kill button still turns the
 >> radio physically off. Press the button to turn it on.
 >> [   45.919959] NET: Registered protocol family 17
 >> [   54.874707] NET: Registered protocol family 10
 >> [   54.875253] lo: Disabled Privacy Extensions
 >> [   54.878600] ADDRCONF(NETDEV_UP): wlan0: link is not ready
 >> [   67.096841] eth0: no IPv6 routers present
 >>
 >> As for the original question I had, interrupts seem sane too.
 >>
 >> [EMAIL PROTECTED]:~$ cat /proc/interrupts|grep "19:"
 >>   19:  0185   IO-APIC-fasteoi   b43
 >>
 >
 > Forgot to mension that rfkill-led is behaving as I described earlier,
 > and has been for as long as I can remember. I don't have specific kernel
 > versions, sorry.
 >
 > It is always blue, as in wlan active, except if I disable wireless in
 > knetworkmanager. Killswitch doesn't affect the led.
 >
 > disable wireless in knetworkmanager, radio hw disabled, led turns red
 > [ 1333.692522] PM: Removing info for No Bus:event7
 > [ 1333.716523] PM: Removing info for No Bus:input7
 > [ 1333.716600] PM: Removing info for No Bus:rfkill0
 > [ 1333.728542] PM: Removing info for No Bus:hw_random
 > [ 1378.346660] PM: Adding info for No Bus:rfkill1
 > [ 1378.708529] PM: Adding info for No Bus:input8
 > [ 1378.708568] input: b43-phy0 as /class/input/input8
 > [ 1378.757574] PM: Adding info for No Bus:event7
 > [ 1378.949550] b43-phy0: Loading firmware version 351.126 (2006-07-29
 > 05:54:02)
 > [ 1378.949563] b43-phy0 warning: You are using an old firmware image.
 > Support for old firmware will be removed in July 2008.
 > [ 1378.949567] b43-phy0 warning: You must go to
 > http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and
 > download the latest firmware (version 4).
 >
 > enable wireless again, radio hw still disabled, led turns blue
 > [ 1380.606214] PM: Adding info for No Bus:hw_random
 > [ 1380.685925] b43-phy0: Radio hardware status changed to DISABLED
 > [ 1380.698005] ADDRCONF(NETDEV_UP): wlan0: link is not ready
 >
 > flipping switch a few times, led unchanged
 > [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED
 > [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED
 > [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED
 > [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED
 >
 > regards, Richard
 > ___
 > Bcm43xx-dev mailing list
 > Bcm43xx-dev@lists.berlios.de
 > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Larry Finger

Richard Jonsson wrote:
> flipping switch a few times, led unchanged
> [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED
> [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED
> [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED
> [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED

This sounds like an rfkill/led configuration problem. In your .config, 
you should have

CONFIG_MAC80211_LEDS=y
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y
CONFIG_B43_LEDS=y
CONFIG_B43_RFKILL=y

I think those are all the configuration parameters relating to 
operation of the LED.

If you had the problem related to the HP recall, your interface 
wouldn't show up in the lspci output. It might be intermittent. 
Furthermore, if it were present at boot time so that b43 got loaded, 
and then disappeared, the kernel would abort with the "caps lock" 
light flashing at 1 Hz.

If Linus's latest git still has the problem, please do a bisection. I 
had a problem with interrupt routing on my other laptop, which kept it 
from booting. That problem is now fixed. I thought it only affected 
the PCMCIA bridges, but there could have been other side affects. I 
built other kernels in the 2.6.25-git sequence, but never booted any 
of them till this morning.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

> 
> OK, after bootup with v2.5.25-rc3-git I get this, looks sane to me:
> 
> [   32.474786] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [   32.474797] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [   32.474802] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [   30.137115] warning: `avahi-daemon' uses 32-bit capabilities (legacy 
> support in use)
> [   32.774279] PM: Adding info for No Bus:vcs7
> [   32.774317] PM: Adding info for No Bus:vcsa7
> [   31.049445] PM: Adding info for No Bus:hw_random
> [   31.062460] b43-phy0: Radio hardware status changed to DISABLED
> [   31.773470] b43-phy0: Radio turned on by software
> [   31.773475] b43-phy0: The hardware RF-kill button still turns the 
> radio physically off. Press the button to turn it on.
> [   45.919959] NET: Registered protocol family 17
> [   54.874707] NET: Registered protocol family 10
> [   54.875253] lo: Disabled Privacy Extensions
> [   54.878600] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [   67.096841] eth0: no IPv6 routers present
> 
> As for the original question I had, interrupts seem sane too.
> 
> [EMAIL PROTECTED]:~$ cat /proc/interrupts|grep "19:"
>   19:  0185   IO-APIC-fasteoi   b43
> 

Forgot to mension that rfkill-led is behaving as I described earlier, 
and has been for as long as I can remember. I don't have specific kernel 
versions, sorry.

It is always blue, as in wlan active, except if I disable wireless in 
knetworkmanager. Killswitch doesn't affect the led.

disable wireless in knetworkmanager, radio hw disabled, led turns red
[ 1333.692522] PM: Removing info for No Bus:event7
[ 1333.716523] PM: Removing info for No Bus:input7
[ 1333.716600] PM: Removing info for No Bus:rfkill0
[ 1333.728542] PM: Removing info for No Bus:hw_random
[ 1378.346660] PM: Adding info for No Bus:rfkill1
[ 1378.708529] PM: Adding info for No Bus:input8
[ 1378.708568] input: b43-phy0 as /class/input/input8
[ 1378.757574] PM: Adding info for No Bus:event7
[ 1378.949550] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[ 1378.949563] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[ 1378.949567] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).

enable wireless again, radio hw still disabled, led turns blue
[ 1380.606214] PM: Adding info for No Bus:hw_random
[ 1380.685925] b43-phy0: Radio hardware status changed to DISABLED
[ 1380.698005] ADDRCONF(NETDEV_UP): wlan0: link is not ready

flipping switch a few times, led unchanged
[ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED
[ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED
[ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED
[ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED

regards, Richard
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

[PATCH] b43: Fix some TX/RX locking issues

2008-04-25 Thread Michael Buesch

This fixes some TX/RX related locking issues.
With this patch applied, some of the PHY transmission errors are fixed.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

---

John, this is for 2.6.26.


Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2008-04-24 
19:42:55.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/b43.h 2008-04-25 
19:28:42.0 +0200
@@ -688,12 +688,16 @@ struct b43_wl {
struct b43_wldev *current_dev;
/* Pointer to the ieee80211 hardware data structure */
struct ieee80211_hw *hw;
 
struct mutex mutex;
spinlock_t irq_lock;
+   /* R/W lock for data transmission.
+* Transmissions on 2+ queues can run concurrently, but somebody else
+* might sync with TX by write_lock_irqsave()'ing. */
+   rwlock_t tx_lock;
/* Lock for LEDs access. */
spinlock_t leds_lock;
/* Lock for SHM access. */
spinlock_t shm_lock;
 
/* We can only have one operating interface (802.11 core)
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c   2008-04-24 
19:42:55.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c2008-04-25 
18:47:08.0 +0200
@@ -726,12 +726,13 @@ static void b43_synchronize_irq(struct b
 
 /* DummyTransmission function, as documented on
  * http://bcm-specs.sipsolutions.net/DummyTransmission
  */
 void b43_dummy_transmission(struct b43_wldev *dev)
 {
+   struct b43_wl *wl = dev->wl;
struct b43_phy *phy = &dev->phy;
unsigned int i, max_loop;
u16 value;
u32 buffer[5] = {
0x,
0x00D4,
@@ -752,12 +753,15 @@ void b43_dummy_transmission(struct b43_w
break;
default:
B43_WARN_ON(1);
return;
}
 
+   spin_lock_irq(&wl->irq_lock);
+   write_lock(&wl->tx_lock);
+
for (i = 0; i < 5; i++)
b43_ram_write(dev, i * 4, buffer[i]);
 
/* Commit writes */
b43_read32(dev, B43_MMIO_MACCTL);
 
@@ -792,12 +796,15 @@ void b43_dummy_transmission(struct b43_w
if (!(value & 0x0100))
break;
udelay(10);
}
if (phy->radio_ver == 0x2050 && phy->radio_rev <= 0x5)
b43_radio_write16(dev, 0x0051, 0x0037);
+
+   write_unlock(&wl->tx_lock);
+   spin_unlock_irq(&wl->irq_lock);
 }
 
 static void key_write(struct b43_wldev *dev,
  u8 index, u8 algorithm, const u8 * key)
 {
unsigned int i;
@@ -2821,30 +2828,37 @@ static int b43_rng_init(struct b43_wl *w
 static int b43_op_tx(struct ieee80211_hw *hw,
 struct sk_buff *skb,
 struct ieee80211_tx_control *ctl)
 {
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl->current_dev;
-   int err = -ENODEV;
+   unsigned long flags;
+   int err;
 
if (unlikely(skb->len < 2 + 2 + 6)) {
/* Too short, this can't be a valid frame. */
-   return -EINVAL;
+   dev_kfree_skb_any(skb);
+   return NETDEV_TX_OK;
}
B43_WARN_ON(skb_shinfo(skb)->nr_frags);
-
if (unlikely(!dev))
-   goto out;
-   if (unlikely(b43_status(dev) < B43_STAT_STARTED))
-   goto out;
-   /* TX is done without a global lock. */
-   if (b43_using_pio_transfers(dev))
-   err = b43_pio_tx(dev, skb, ctl);
-   else
-   err = b43_dma_tx(dev, skb, ctl);
-out:
+   return NETDEV_TX_BUSY;
+
+   /* Transmissions on seperate queues can run concurrently. */
+   read_lock_irqsave(&wl->tx_lock, flags);
+
+   err = -ENODEV;
+   if (likely(b43_status(dev) >= B43_STAT_STARTED)) {
+   if (b43_using_pio_transfers(dev))
+   err = b43_pio_tx(dev, skb, ctl);
+   else
+   err = b43_dma_tx(dev, skb, ctl);
+   }
+
+   read_unlock_irqrestore(&wl->tx_lock, flags);
+
if (unlikely(err))
return NETDEV_TX_BUSY;
return NETDEV_TX_OK;
 }
 
 /* Locking: wl->irq_lock */
@@ -3457,23 +3471,23 @@ static void b43_wireless_core_stop(struc
spin_lock_irqsave(&wl->irq_lock, flags);
dev->irq_savedstate = b43_interrupt_disable(dev, B43_IRQ_ALL);
b43_read32(dev, B43_MMIO_GEN_IRQ_MASK); /* flush */
spin_unlock_irqrestore(&wl->irq_lock, flags);
b43_synchronize_irq(dev);
 
+   write_lock_irqsave(&wl->tx_lock, flags);
b43_set_status(dev, B43_STAT_INITIALIZED);
+   write_unlock_irqrestore(&wl->tx_lock, flags);
 
b43_pio_stop(dev);
mutex_unlock(

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Richard Jonsson skrev:
> Larry Finger skrev:
>> Richard Jonsson wrote:
>>> [10493.303801] b43-phy0 warning: You are using an old firmware image. 
>>> Support for old firmware will be removed in July 2008.
>>> [10493.303807] b43-phy0 warning: You must go to 
>>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>>> download the latest firmware (version 4).
>>> [10494.452216] PM: Adding info for No Bus:hw_random
>>>
>>> -- Restoring the switch to disabled again --
>>>
>>> [10506.472673] b43-phy0: Radio hardware status changed to DISABLED
>>>
>>>
>>> and then it goes on as before..
>>>
>>> To add, I thought that my hardware had died judging by the messages 
>>> above, so I temporarily connected to an access point in the area and 
>>> could successfully load a few webpages before I disconnected.
>> I'm trying to duplicate your setup as closely as possible. I'm running 
>> kernel 2.6.25-Linus-git-04569-gb69d398, which is Linus's current git 
>> tree. My interface is a BCM4311 rev 2. When I boot up with a wire in 
>> eth0 and the rfkill switch off, the dmesg output for networking contains
>>
>> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
>> ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0D, vendor 0x4243)
>> ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
>> ssb: Core 3 found: PCI-E (cc 0x820, rev 0x05, vendor 0x4243)
>> input: Power Button (FF) as /class/input/input4
>> ssb: SPROM revision 3 detected.
>> ssb: Sonics Silicon Backplane found on PCI device :04:00.0
>> ACPI: Power Button (FF) [PWRF]
>> input: Lid Switch as /class/input/input5
>> ACPI: Lid Switch [LID0]
>> input: Sleep Button (CM) as /class/input/input6
>> ACPI: Sleep Button (CM) [SLPB]
>> input: Power Button (CM) as /class/input/input7
>> ACPI: Power Button (CM) [PWRB]
>> forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
>> ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 21
>> ACPI: PCI Interrupt :00:0a.0[A] -> Link [LMAC] -> GSI 21 (level, 
>> low) -> IRQ 21
>> PCI: Setting latency timer of device :00:0a.0 to 64
>> mm/memory.c:127: bad pmd 81207808(9090909090909090).
>> b43-phy0: Broadcom 4311 WLAN found
>> b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 9
>> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
>> phy0: Selected rate control algorithm 'pid'
>> --snip--
>> Broadcom 43xx driver loaded [ Features: PLR, Firmware-ID: FW13 ]
>> forcedeth :00:0a.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 
>> 00:1d:72:4c:a5:52
>> forcedeth :00:0a.0: highdma pwrctl mgmt timirq lnktim msi desc-v3
>> --snip--
>> udev: renamed network interface wlan0 to eth1
>> --snip--
>> input: b43-phy0 as /class/input/input8
>> b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
>> b43-phy0 debug: Chip initialized
>> b43-phy0 debug: 64-bit DMA initialized
>> Registered led device: b43-phy0::tx
>> Registered led device: b43-phy0::rx
>> Registered led device: b43-phy0::radio
>> b43-phy0 debug: Wireless interface started
>> b43-phy0 ERROR: PHY transmission error
>> b43-phy0: Radio hardware status changed to DISABLED
>> b43-phy0 debug: Adding Interface type 2
>> b43-phy0: Radio turned on by software
>> b43-phy0: The hardware RF-kill button still turns the radio physically 
>> off. Press the button to turn it on.
>>
>> Note that I get one PHY ERROR - that is something that shows up for the 
>> 64-bit DMA of this card. We don't know if your 4311 is rev 1 or 2. If it 
>> is rev 1, then it has 32-bit DMA, and shouldn't get even this one PHY 
>> error.
>>
>> When I change the rfkill switch, the radio LED changes from red to blue, 
>> and one line is added to the dmesg output
>>
>> b43-phy0: Radio hardware status changed to ENABLED
>>
>> Nothing else happens. When I cause the NM applet to switch from the 
>> wired to the wireless interface, I then get the following:
>>
>> eth1: Initial auth_alg=0
>> eth1: authenticate with AP 00:1a:70:46:ba:b1
>> eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 
>> status=0)
>> eth1: authenticated
>> eth1: associate with AP 00:1a:70:46:ba:b1
>> eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x411 status=0 aid=1)
>> eth1: associated
>> eth1: switched to short barker preamble (BSSID=00:1a:70:46:ba:b1)
>>
>> Could you please switch on the debug options for ssb and b43? It will 
>> make sorting out this problem a lot easier.
>>
>> Thanks,
>>
>> Larry
>>
> 
> OK so maybe my card is getting bad after all. It's from a HP DV2140 
> laptop, and I noticed you message to this list some time ago about HP 
> repair program, I actually got a mail from HP the other day, regarding this.
> 
> [EMAIL PROTECTED]:~$ lspci -vv -d :4312
> 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g 
> (rev 01)
>  Subsystem: Hewlett-Packard Company Unknown device 1361
>  Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
>  Status: Cap+ 66M

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Larry Finger skrev:
> Richard Jonsson wrote:
>> [10493.303801] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [10493.303807] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [10494.452216] PM: Adding info for No Bus:hw_random
>>
>> -- Restoring the switch to disabled again --
>>
>> [10506.472673] b43-phy0: Radio hardware status changed to DISABLED
>>
>>
>> and then it goes on as before..
>>
>> To add, I thought that my hardware had died judging by the messages 
>> above, so I temporarily connected to an access point in the area and 
>> could successfully load a few webpages before I disconnected.
> 
> I'm trying to duplicate your setup as closely as possible. I'm running 
> kernel 2.6.25-Linus-git-04569-gb69d398, which is Linus's current git 
> tree. My interface is a BCM4311 rev 2. When I boot up with a wire in 
> eth0 and the rfkill switch off, the dmesg output for networking contains
> 
> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
> ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0D, vendor 0x4243)
> ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
> ssb: Core 3 found: PCI-E (cc 0x820, rev 0x05, vendor 0x4243)
> input: Power Button (FF) as /class/input/input4
> ssb: SPROM revision 3 detected.
> ssb: Sonics Silicon Backplane found on PCI device :04:00.0
> ACPI: Power Button (FF) [PWRF]
> input: Lid Switch as /class/input/input5
> ACPI: Lid Switch [LID0]
> input: Sleep Button (CM) as /class/input/input6
> ACPI: Sleep Button (CM) [SLPB]
> input: Power Button (CM) as /class/input/input7
> ACPI: Power Button (CM) [PWRB]
> forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
> ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 21
> ACPI: PCI Interrupt :00:0a.0[A] -> Link [LMAC] -> GSI 21 (level, 
> low) -> IRQ 21
> PCI: Setting latency timer of device :00:0a.0 to 64
> mm/memory.c:127: bad pmd 81207808(9090909090909090).
> b43-phy0: Broadcom 4311 WLAN found
> b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 9
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> phy0: Selected rate control algorithm 'pid'
> --snip--
> Broadcom 43xx driver loaded [ Features: PLR, Firmware-ID: FW13 ]
> forcedeth :00:0a.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 
> 00:1d:72:4c:a5:52
> forcedeth :00:0a.0: highdma pwrctl mgmt timirq lnktim msi desc-v3
> --snip--
> udev: renamed network interface wlan0 to eth1
> --snip--
> input: b43-phy0 as /class/input/input8
> b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
> b43-phy0 debug: Chip initialized
> b43-phy0 debug: 64-bit DMA initialized
> Registered led device: b43-phy0::tx
> Registered led device: b43-phy0::rx
> Registered led device: b43-phy0::radio
> b43-phy0 debug: Wireless interface started
> b43-phy0 ERROR: PHY transmission error
> b43-phy0: Radio hardware status changed to DISABLED
> b43-phy0 debug: Adding Interface type 2
> b43-phy0: Radio turned on by software
> b43-phy0: The hardware RF-kill button still turns the radio physically 
> off. Press the button to turn it on.
> 
> Note that I get one PHY ERROR - that is something that shows up for the 
> 64-bit DMA of this card. We don't know if your 4311 is rev 1 or 2. If it 
> is rev 1, then it has 32-bit DMA, and shouldn't get even this one PHY 
> error.
> 
> When I change the rfkill switch, the radio LED changes from red to blue, 
> and one line is added to the dmesg output
> 
> b43-phy0: Radio hardware status changed to ENABLED
> 
> Nothing else happens. When I cause the NM applet to switch from the 
> wired to the wireless interface, I then get the following:
> 
> eth1: Initial auth_alg=0
> eth1: authenticate with AP 00:1a:70:46:ba:b1
> eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 
> status=0)
> eth1: authenticated
> eth1: associate with AP 00:1a:70:46:ba:b1
> eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x411 status=0 aid=1)
> eth1: associated
> eth1: switched to short barker preamble (BSSID=00:1a:70:46:ba:b1)
> 
> Could you please switch on the debug options for ssb and b43? It will 
> make sorting out this problem a lot easier.
> 
> Thanks,
> 
> Larry
> 

OK so maybe my card is getting bad after all. It's from a HP DV2140 
laptop, and I noticed you message to this list some time ago about HP 
repair program, I actually got a mail from HP the other day, regarding this.

[EMAIL PROTECTED]:~$ lspci -vv -d :4312
01:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g 
(rev 01)
 Subsystem: Hewlett-Packard Company Unknown device 1361
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 

I will boot into an older kernel and see if I see the same behavior.
Next step w

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Michael Buesch skrev:
> On Friday 25 April 2008 18:09:27 Richard Jonsson wrote:
>> To add, I thought that my hardware had died judging by the messages 
>> above, so I temporarily connected to an access point in the area and 
>> could successfully load a few webpages before I disconnected.
> 
> You really need to be a bit more descriptive with your explanations.
> How, with which driver on which operating system did you connect
> to which AP?
> You need to _talk_ to us and show _logs_.
> 

cut'n'paste from earlier in the thread:

This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2
(1600MHz), kubuntu 8.04
broadcom flavor: 4311
$ uname -a
Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux

Kernel pulled from mainline git yesterday.

I use the b43 driver exclusively.

The wireless works despite the messages about phy transmission errors 
the driver prints out.

Below is dmesg from moment of killswitch disabled to killswitch enabled, 
when connecting to an AP.

[10738.487135] b43-phy0: Radio hardware status changed to ENABLED
[10751.323930] PM: Removing info for No Bus:hw_random
[10751.567928] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10751.567940] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10751.567946] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10752.348174] PM: Adding info for No Bus:hw_random
[10752.348229] b43-phy0 ERROR: PHY transmission error
[10752.391990] b43-phy0 ERROR: PHY transmission error
[10752.404023] b43-phy0 ERROR: PHY transmission error
[10753.144094] PM: Removing info for No Bus:hw_random
[10753.388042] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10753.388053] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10753.388058] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10754.560488] PM: Adding info for No Bus:hw_random
[10781.409821] PM: Removing info for No Bus:hw_random
[10781.658044] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10781.658057] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10781.658061] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10782.438219] PM: Adding info for No Bus:hw_random
[10782.438285] b43-phy0 ERROR: PHY transmission error
[10782.481915] b43-phy0 ERROR: PHY transmission error
[10782.493957] b43-phy0 ERROR: PHY transmission error
[10783.246016] PM: Removing info for No Bus:hw_random
[10783.489928] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10783.489940] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10783.489946] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10784.639743] PM: Adding info for No Bus:hw_random
[10811.427696] PM: Removing info for No Bus:hw_random
[10811.671684] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10811.671695] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10811.671699] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10812.455923] PM: Adding info for No Bus:hw_random
[10812.455976] b43-phy0 ERROR: PHY transmission error
[10812.499746] b43-phy0 ERROR: PHY transmission error
[10812.511780] b43-phy0 ERROR: PHY transmission error
[10813.255854] PM: Removing info for No Bus:hw_random
[10813.499798] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10813.499808] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10813.499813] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10814.672249] PM: Adding info for No Bus:hw_random
[10826.700977] eth0: link down.
[10830.532898] PM: Removing info for No Bus:hw_random
[10830.772881] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[10830.772894] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[10830.772900] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[10831.561285] PM: Adding info for No Bus:hw_random
[10831.561353] b43-phy0 ERROR: PHY transmission error
[10831.604949] b43-phy0 ERROR: PHY transmission error
[10831.6170

Re: Tons of interrupts on driver load

2008-04-25 Thread Larry Finger

Richard Jonsson wrote:
> [10493.303801] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [10493.303807] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [10494.452216] PM: Adding info for No Bus:hw_random
> 
> -- Restoring the switch to disabled again --
> 
> [10506.472673] b43-phy0: Radio hardware status changed to DISABLED
> 
> 
> and then it goes on as before..
> 
> To add, I thought that my hardware had died judging by the messages 
> above, so I temporarily connected to an access point in the area and 
> could successfully load a few webpages before I disconnected.

I'm trying to duplicate your setup as closely as possible. I'm running 
kernel 2.6.25-Linus-git-04569-gb69d398, which is Linus's current git 
tree. My interface is a BCM4311 rev 2. When I boot up with a wire in 
eth0 and the rfkill switch off, the dmesg output for networking contains

ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0D, vendor 0x4243)
ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
ssb: Core 3 found: PCI-E (cc 0x820, rev 0x05, vendor 0x4243)
input: Power Button (FF) as /class/input/input4
ssb: SPROM revision 3 detected.
ssb: Sonics Silicon Backplane found on PCI device :04:00.0
ACPI: Power Button (FF) [PWRF]
input: Lid Switch as /class/input/input5
ACPI: Lid Switch [LID0]
input: Sleep Button (CM) as /class/input/input6
ACPI: Sleep Button (CM) [SLPB]
input: Power Button (CM) as /class/input/input7
ACPI: Power Button (CM) [PWRB]
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 21
ACPI: PCI Interrupt :00:0a.0[A] -> Link [LMAC] -> GSI 21 (level, 
low) -> IRQ 21
PCI: Setting latency timer of device :00:0a.0 to 64
mm/memory.c:127: bad pmd 81207808(9090909090909090).
b43-phy0: Broadcom 4311 WLAN found
b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 9
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
phy0: Selected rate control algorithm 'pid'
--snip--
Broadcom 43xx driver loaded [ Features: PLR, Firmware-ID: FW13 ]
forcedeth :00:0a.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 
00:1d:72:4c:a5:52
forcedeth :00:0a.0: highdma pwrctl mgmt timirq lnktim msi desc-v3
--snip--
udev: renamed network interface wlan0 to eth1
--snip--
input: b43-phy0 as /class/input/input8
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 debug: Chip initialized
b43-phy0 debug: 64-bit DMA initialized
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0 debug: Wireless interface started
b43-phy0 ERROR: PHY transmission error
b43-phy0: Radio hardware status changed to DISABLED
b43-phy0 debug: Adding Interface type 2
b43-phy0: Radio turned on by software
b43-phy0: The hardware RF-kill button still turns the radio physically 
off. Press the button to turn it on.

Note that I get one PHY ERROR - that is something that shows up for 
the 64-bit DMA of this card. We don't know if your 4311 is rev 1 or 2. 
If it is rev 1, then it has 32-bit DMA, and shouldn't get even this 
one PHY error.

When I change the rfkill switch, the radio LED changes from red to 
blue, and one line is added to the dmesg output

b43-phy0: Radio hardware status changed to ENABLED

Nothing else happens. When I cause the NM applet to switch from the 
wired to the wireless interface, I then get the following:

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:1a:70:46:ba:b1
eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 
status=0)
eth1: authenticated
eth1: associate with AP 00:1a:70:46:ba:b1
eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x411 status=0 aid=1)
eth1: associated
eth1: switched to short barker preamble (BSSID=00:1a:70:46:ba:b1)

Could you please switch on the debug options for ssb and b43? It will 
make sorting out this problem a lot easier.

Thanks,

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Michael Buesch

On Friday 25 April 2008 18:09:27 Richard Jonsson wrote:
> To add, I thought that my hardware had died judging by the messages 
> above, so I temporarily connected to an access point in the area and 
> could successfully load a few webpages before I disconnected.

You really need to be a bit more descriptive with your explanations.
How, with which driver on which operating system did you connect
to which AP?
You need to _talk_ to us and show _logs_.

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Michael Buesch skrev:
> On Friday 25 April 2008 17:21:00 Richard Jonsson wrote:
>> I use a custom kernel, but I think I turned off b43/ssb debugging some 
>> time ago. Anyway dmesg is drowning in this:
> 
> Oh, finally something useful. Great!
> 
>> [ 7389.533848] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7390.282233] PM: Adding info for No Bus:hw_random
>> [ 7390.993977] PM: Removing info for No Bus:hw_random
>> [ 7391.193935] b43-phy0: Loading firmware version 351.126 (2006-07-29 
>> 05:54:02)
>> [ 7391.193947] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [ 7391.193953] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7392.151174] PM: Adding info for No Bus:hw_random
>> [ 7518.285906] PM: Removing info for No Bus:hw_random
>> [ 7518.485886] b43-phy0: Loading firmware version 351.126 (2006-07-29 
>> 05:54:02)
>> [ 7518.485898] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [ 7518.485904] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7519.254126] PM: Adding info for No Bus:hw_random
>> [ 7519.254195] printk: 2250 messages suppressed.
>> [ 7519.254200] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254255] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254266] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254275] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254285] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254295] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254304] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254313] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254323] b43-phy0 ERROR: PHY transmission error
>> [ 7519.254332] b43-phy0 ERROR: PHY transmission error
>> [ 7519.294071] b43-phy0: Radio hardware status changed to DISABLED
>> [ 7519.294131] PM: Removing info for No Bus:hw_random
>> [ 7519.493955] b43-phy0: Loading firmware version 351.126 (2006-07-29 
>> 05:54:02)
>> [ 7519.493968] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [ 7519.493973] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7520.230371] PM: Adding info for No Bus:hw_random
>> [ 7520.974090] PM: Removing info for No Bus:hw_random
>> [ 7521.174058] b43-phy0: Loading firmware version 351.126 (2006-07-29 
>> 05:54:02)
>> [ 7521.174069] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [ 7521.174074] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7522.058469] PM: Adding info for No Bus:hw_random
>> [ 7648.318039] PM: Removing info for No Bus:hw_random
>> [ 7648.518013] b43-phy0: Loading firmware version 351.126 (2006-07-29 
>> 05:54:02)
>> [ 7648.518025] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [ 7648.518030] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7649.266421] PM: Adding info for No Bus:hw_random
>> [ 7649.306162] printk: 2287 messages suppressed.
>> [ 7649.306170] b43-phy0 ERROR: PHY transmission error
>> [ 7649.410123] b43-phy0: Radio hardware status changed to DISABLED
>> [ 7650.006181] PM: Removing info for No Bus:hw_random
>> [ 7650.206122] b43-phy0: Loading firmware version 351.126 (2006-07-29 
>> 05:54:02)
>> [ 7650.206133] b43-phy0 warning: You are using an old firmware image. 
>> Support for old firmware will be removed in July 2008.
>> [ 7650.206138] b43-phy0 warning: You must go to 
>> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
>> download the latest firmware (version 4).
>> [ 7651.110535] PM: Adding info for No Bus:hw_random
>> [ 7651.122202] b43-phy0: Radio hardware status changed to DISABLED
> 
> The device is throwing too many PHY errors and the driver decides to restart 
> it.
> What does happen when you press rfkill?
> 
Actually rfkill is on all the time, as in radio disabled. Since you ask 
about rfkill I should say that the led says wireless enabled (blue 
light), briefly flashes red twice while the driver reloads. Afaik it 
should be red as in disabled all the time when disabled.

To answer your question:

[10364.180078] PM: Adding info for No Bus:hw_random
[10364.252000] b43-phy0: Radio hardware status changed to DISABLED

-- Flipping the switch --

[10481.471061] b43-phy0: Radio h

Re: Tons of interrupts on driver load

2008-04-25 Thread Michael Buesch

On Friday 25 April 2008 17:21:00 Richard Jonsson wrote:
> I use a custom kernel, but I think I turned off b43/ssb debugging some 
> time ago. Anyway dmesg is drowning in this:

Oh, finally something useful. Great!

> [ 7389.533848] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7390.282233] PM: Adding info for No Bus:hw_random
> [ 7390.993977] PM: Removing info for No Bus:hw_random
> [ 7391.193935] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [ 7391.193947] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [ 7391.193953] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7392.151174] PM: Adding info for No Bus:hw_random
> [ 7518.285906] PM: Removing info for No Bus:hw_random
> [ 7518.485886] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [ 7518.485898] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [ 7518.485904] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7519.254126] PM: Adding info for No Bus:hw_random
> [ 7519.254195] printk: 2250 messages suppressed.
> [ 7519.254200] b43-phy0 ERROR: PHY transmission error
> [ 7519.254255] b43-phy0 ERROR: PHY transmission error
> [ 7519.254266] b43-phy0 ERROR: PHY transmission error
> [ 7519.254275] b43-phy0 ERROR: PHY transmission error
> [ 7519.254285] b43-phy0 ERROR: PHY transmission error
> [ 7519.254295] b43-phy0 ERROR: PHY transmission error
> [ 7519.254304] b43-phy0 ERROR: PHY transmission error
> [ 7519.254313] b43-phy0 ERROR: PHY transmission error
> [ 7519.254323] b43-phy0 ERROR: PHY transmission error
> [ 7519.254332] b43-phy0 ERROR: PHY transmission error
> [ 7519.294071] b43-phy0: Radio hardware status changed to DISABLED
> [ 7519.294131] PM: Removing info for No Bus:hw_random
> [ 7519.493955] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [ 7519.493968] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [ 7519.493973] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7520.230371] PM: Adding info for No Bus:hw_random
> [ 7520.974090] PM: Removing info for No Bus:hw_random
> [ 7521.174058] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [ 7521.174069] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [ 7521.174074] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7522.058469] PM: Adding info for No Bus:hw_random
> [ 7648.318039] PM: Removing info for No Bus:hw_random
> [ 7648.518013] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [ 7648.518025] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [ 7648.518030] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7649.266421] PM: Adding info for No Bus:hw_random
> [ 7649.306162] printk: 2287 messages suppressed.
> [ 7649.306170] b43-phy0 ERROR: PHY transmission error
> [ 7649.410123] b43-phy0: Radio hardware status changed to DISABLED
> [ 7650.006181] PM: Removing info for No Bus:hw_random
> [ 7650.206122] b43-phy0: Loading firmware version 351.126 (2006-07-29 
> 05:54:02)
> [ 7650.206133] b43-phy0 warning: You are using an old firmware image. 
> Support for old firmware will be removed in July 2008.
> [ 7650.206138] b43-phy0 warning: You must go to 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
> download the latest firmware (version 4).
> [ 7651.110535] PM: Adding info for No Bus:hw_random
> [ 7651.122202] b43-phy0: Radio hardware status changed to DISABLED

The device is throwing too many PHY errors and the driver decides to restart it.
What does happen when you press rfkill?

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Larry Finger skrev:
> Richard Jonsson wrote:
>> Pavel Roskin skrev:
>>> On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote:
 Hello,

 First some background:
 I am currently running latest mainline from git. This kernel suffers 
 from a scheduler?
>>> I think this question is more suited for LKML.
>>>
>> I'm sorry for being a bit vague. I'm just trying to describe the
>> circumstances surrounding the issue. I and others have reported the
>> scheduler oddity to LKML and it's being dealt with.
>>
>> My question to this list could be condensed to:
>>
>> Is it normal that over 25000 interrupts are generated when loading 
>> b43, or is the driver or something else broken?
>>
>> I believe you guys are the best suited to answer this question.
>>
 While trying to find what these hickups come from I ran watch 
 --interval .1 "cat /proc/interrupts". I can see there that the b43 
 disappears, gets unloaded probably, and then reappears.
>>> You should probably show the exact contents of /proc/interrupts and
>>> provide some details about the systems (architecture, CPU speed,
>>> contents of /proc/sched_debug, lspci output, dmesg output).
>>>
 When b43 reappears in the interrupt listing, that line generates 
 some 25000 irq's within a fraction of a second. Is this a bug 
 somewhere or by design?
>>> It's possible that the interrupt count is not shown when the driver
>>> "disappears", but is not reset to 0.  Once the interrupt has a handler,
>>> the original count is shown.
>>>
>>
>> This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 
>> (1600MHz), kubuntu 8.04
>> broadcom flavor: 4311
>> $ uname -a
>> Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 
>> GNU/Linux
>>
>> I was trying to make a testcase, but can't find how to disable 
>> networkmanager, nor how to control if from a terminal. Just 
>> inactivating knetworkmanager and "rmmod b43" results in a segfault.
>>
>> Anyway networkmanager seems to reload the driver periodically for some 
>> reason. Probably because it's stupid and unaware that the radio is 
>> disabled by hardware button.
>>
>> b43 is loaded, not associated since wired networking is used.
>>
>> $ date && cat /proc/interrupts |grep "19:"
>> fre apr 25 15:12:50 CEST 2008
>>   19:813 210843   IO-APIC-fasteoi   b43
>>
>> a few moments later:
>>
>> $ date && cat /proc/interrupts |grep "19:"
>> fre apr 25 15:13:15 CEST 2008
>>   19:813 210843   IO-APIC-fasteoi   b43
>> $ date && cat /proc/interrupts |grep "19:"
>> fre apr 25 15:13:16 CEST 2008
>>   19:813 210851   IO-APIC-fasteoi   b43
>> $ date && cat /proc/interrupts |grep "19:"
>> fre apr 25 15:13:17 CEST 2008
>>   19:813 210854   IO-APIC-fasteoi <-- b43 reloaded by nm
> 
> I'm a little confused. Why do you think that b43 was reloaded? Is there 

I took it for granted since it disappears from the interrupt listing.

> a corresponding output in dmesg. Oh, I forgot - Ubuntu doesn't enable 
> the ssb or b43 debug output!
> 
> Larry

I use a custom kernel, but I think I turned off b43/ssb debugging some 
time ago. Anyway dmesg is drowning in this:

[ 7389.533848] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[ 7390.282233] PM: Adding info for No Bus:hw_random
[ 7390.993977] PM: Removing info for No Bus:hw_random
[ 7391.193935] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[ 7391.193947] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[ 7391.193953] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[ 7392.151174] PM: Adding info for No Bus:hw_random
[ 7518.285906] PM: Removing info for No Bus:hw_random
[ 7518.485886] b43-phy0: Loading firmware version 351.126 (2006-07-29 
05:54:02)
[ 7518.485898] b43-phy0 warning: You are using an old firmware image. 
Support for old firmware will be removed in July 2008.
[ 7518.485904] b43-phy0 warning: You must go to 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and 
download the latest firmware (version 4).
[ 7519.254126] PM: Adding info for No Bus:hw_random
[ 7519.254195] printk: 2250 messages suppressed.
[ 7519.254200] b43-phy0 ERROR: PHY transmission error
[ 7519.254255] b43-phy0 ERROR: PHY transmission error
[ 7519.254266] b43-phy0 ERROR: PHY transmission error
[ 7519.254275] b43-phy0 ERROR: PHY transmission error
[ 7519.254285] b43-phy0 ERROR: PHY transmission error
[ 7519.254295] b43-phy0 ERROR: PHY transmission error
[ 7519.254304] b43-phy0 ERROR: PHY transmission error
[ 7519.254313] b43-phy0 ERROR: PHY transmission error
[ 7519.254323] b43-phy0 ERROR: PHY transmission error
[ 7519.254332] b43-phy0 ERROR: PHY transmission error
[ 7519.294071] b43-phy0: Radio hardware status changed to DISABLED
[ 7519.2941

Re: Tons of interrupts on driver load

2008-04-25 Thread Larry Finger

Richard Jonsson wrote:
> Pavel Roskin skrev:
>> On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote:
>>> Hello,
>>>
>>> First some background:
>>> I am currently running latest mainline from git. This kernel suffers 
>>> from a scheduler?
>> I think this question is more suited for LKML.
>>
> I'm sorry for being a bit vague. I'm just trying to describe the
> circumstances surrounding the issue. I and others have reported the
> scheduler oddity to LKML and it's being dealt with.
> 
> My question to this list could be condensed to:
> 
> Is it normal that over 25000 interrupts are generated when loading b43, 
> or is the driver or something else broken?
> 
> I believe you guys are the best suited to answer this question.
> 
>>> While trying to find what these hickups come from I ran watch --interval 
>>> .1 "cat /proc/interrupts". I can see there that the b43 disappears, gets 
>>> unloaded probably, and then reappears.
>> You should probably show the exact contents of /proc/interrupts and
>> provide some details about the systems (architecture, CPU speed,
>> contents of /proc/sched_debug, lspci output, dmesg output).
>>
>>> When b43 reappears in the interrupt listing, that line generates some 
>>> 25000 irq's within a fraction of a second. Is this a bug somewhere or by 
>>> design?
>> It's possible that the interrupt count is not shown when the driver
>> "disappears", but is not reset to 0.  Once the interrupt has a handler,
>> the original count is shown.
>>
> 
> This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 
> (1600MHz), kubuntu 8.04
> broadcom flavor: 4311
> $ uname -a
> Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux
> 
> I was trying to make a testcase, but can't find how to disable 
> networkmanager, nor how to control if from a terminal. Just inactivating 
> knetworkmanager and "rmmod b43" results in a segfault.
> 
> Anyway networkmanager seems to reload the driver periodically for some 
> reason. Probably because it's stupid and unaware that the radio is 
> disabled by hardware button.
> 
> b43 is loaded, not associated since wired networking is used.
> 
> $ date && cat /proc/interrupts |grep "19:"
> fre apr 25 15:12:50 CEST 2008
>   19:813 210843   IO-APIC-fasteoi   b43
> 
> a few moments later:
> 
> $ date && cat /proc/interrupts |grep "19:"
> fre apr 25 15:13:15 CEST 2008
>   19:813 210843   IO-APIC-fasteoi   b43
> $ date && cat /proc/interrupts |grep "19:"
> fre apr 25 15:13:16 CEST 2008
>   19:813 210851   IO-APIC-fasteoi   b43
> $ date && cat /proc/interrupts |grep "19:"
> fre apr 25 15:13:17 CEST 2008
>   19:813 210854   IO-APIC-fasteoi <-- b43 reloaded by nm

I'm a little confused. Why do you think that b43 was reloaded? Is 
there a corresponding output in dmesg. Oh, I forgot - Ubuntu doesn't 
enable the ssb or b43 debug output!

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Inconsistency in handling board revision

2008-04-25 Thread gavron



Larry Finger wrote:
> Michael Buesch wrote:
>   
>> On Friday 25 April 2008 06:55:54 Larry Finger wrote:
>> 
>>> Michael,
>>>
>>> I have discovered that both sprom_extract_r123() in the ssb driver, 
>>> and ssb-sprom use a two-byte quantity to extract the board revision. 
>>> In the specifications detailed in 
>>> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this 
>>> parameter.
>>>
>>> It is unlikely that this causes any serious difficulties; however, at 
>>> least one fixup depends on the board revision, and I wanted to be 
>>> certain that you were aware of the situation.
>>>   
>> I'm not sure what you're talking about.
>>
>> #define  SSB_SPROM1_BINF_BREV   0x00FF  /* Board Revision */
>> SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);
>>
>> 
>
> Yes - 2 bytes in the code above, but the spec says bits 0-7!
>
> Larry
>   
Whoops, ignore previous message.
0xFF is one byte.  Bits 0-7 are 0xFF. 
Bits 0-7 = 0-255 = 0x00-0xFF

A nibble which I thought was cute because I could rhyme against it
is half a byte, or 4 bits, or one hex digit.

E (it's 0730 and I've been up 33hrs ;)
> ___
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>   
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Inconsistency in handling board revision

2008-04-25 Thread Larry Finger

Michael Buesch wrote:
> On Friday 25 April 2008 16:16:49 Larry Finger wrote:
>> Michael Buesch wrote:
>>> On Friday 25 April 2008 06:55:54 Larry Finger wrote:
 Michael,

 I have discovered that both sprom_extract_r123() in the ssb driver, 
 and ssb-sprom use a two-byte quantity to extract the board revision. 
 In the specifications detailed in 
 http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this 
 parameter.

 It is unlikely that this causes any serious difficulties; however, at 
 least one fixup depends on the board revision, and I wanted to be 
 certain that you were aware of the situation.
>>> I'm not sure what you're talking about.
>>>
>>> #define  SSB_SPROM1_BINF_BREV   0x00FF  /* Board Revision */
>>> SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);
>>>
>> Yes - 2 bytes in the code above, but the spec says bits 0-7!
> 
> I really really don't understand that.
> The code quoted above does use a mask of 0xFF, which is one byte.
> And it uses a shift of 0. Which results on bits 0-7.
> 

You're right. It must be too early for me! Sorry for the noise.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Inconsistency in handling board revision

2008-04-25 Thread gavron



Larry Finger wrote:
> Michael Buesch wrote:
>   
>> On Friday 25 April 2008 06:55:54 Larry Finger wrote:
>> 
>>> Michael,
>>>
>>> I have discovered that both sprom_extract_r123() in the ssb driver, 
>>> and ssb-sprom use a two-byte quantity to extract the board revision. 
>>> In the specifications detailed in 
>>> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this 
>>> parameter.
>>>
>>> It is unlikely that this causes any serious difficulties; however, at 
>>> least one fixup depends on the board revision, and I wanted to be 
>>> certain that you were aware of the situation.
>>>   
>> I'm not sure what you're talking about.
>>
>> #define  SSB_SPROM1_BINF_BREV   0x00FF  /* Board Revision */
>> SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);
>>
>> 
>
> Yes - 2 bytes in the code above, but the spec says bits 0-7!
>
> Larry
>
>   
Larry - 1 byte but the spec says one nibble.
So I quibble ;)
E
> ___
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>   
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Inconsistency in handling board revision

2008-04-25 Thread Michael Buesch

On Friday 25 April 2008 16:16:49 Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 25 April 2008 06:55:54 Larry Finger wrote:
> >> Michael,
> >>
> >> I have discovered that both sprom_extract_r123() in the ssb driver, 
> >> and ssb-sprom use a two-byte quantity to extract the board revision. 
> >> In the specifications detailed in 
> >> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this 
> >> parameter.
> >>
> >> It is unlikely that this causes any serious difficulties; however, at 
> >> least one fixup depends on the board revision, and I wanted to be 
> >> certain that you were aware of the situation.
> > 
> > I'm not sure what you're talking about.
> > 
> > #define  SSB_SPROM1_BINF_BREV   0x00FF  /* Board Revision */
> > SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);
> > 
> 
> Yes - 2 bytes in the code above, but the spec says bits 0-7!

I really really don't understand that.
The code quoted above does use a mask of 0xFF, which is one byte.
And it uses a shift of 0. Which results on bits 0-7.

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Inconsistency in handling board revision

2008-04-25 Thread Larry Finger

Michael Buesch wrote:
> On Friday 25 April 2008 06:55:54 Larry Finger wrote:
>> Michael,
>>
>> I have discovered that both sprom_extract_r123() in the ssb driver, 
>> and ssb-sprom use a two-byte quantity to extract the board revision. 
>> In the specifications detailed in 
>> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this 
>> parameter.
>>
>> It is unlikely that this causes any serious difficulties; however, at 
>> least one fixup depends on the board revision, and I wanted to be 
>> certain that you were aware of the situation.
> 
> I'm not sure what you're talking about.
> 
> #define  SSB_SPROM1_BINF_BREV   0x00FF  /* Board Revision */
> SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);
> 

Yes - 2 bytes in the code above, but the spec says bits 0-7!

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V3] ssb-sprom: Update README

2008-04-25 Thread Michael Buesch

On Friday 25 April 2008 06:42:20 Larry Finger wrote:
> This version modifies the setting of the patch to ssb_sprom to handle
> systems with multiple SSB-based devices.

Applied, thanks.

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Inconsistency in handling board revision

2008-04-25 Thread Michael Buesch

On Friday 25 April 2008 06:55:54 Larry Finger wrote:
> Michael,
> 
> I have discovered that both sprom_extract_r123() in the ssb driver, 
> and ssb-sprom use a two-byte quantity to extract the board revision. 
> In the specifications detailed in 
> http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this 
> parameter.
> 
> It is unlikely that this causes any serious difficulties; however, at 
> least one fixup depends on the board revision, and I wanted to be 
> certain that you were aware of the situation.

I'm not sure what you're talking about.

#define  SSB_SPROM1_BINF_BREV   0x00FF  /* Board Revision */
SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: Tons of interrupts on driver load

2008-04-25 Thread Richard Jonsson

Pavel Roskin skrev:
> On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote:
>> Hello,
>>
>> First some background:
>> I am currently running latest mainline from git. This kernel suffers 
>> from a scheduler?
> 
> I think this question is more suited for LKML.
> 
I'm sorry for being a bit vague. I'm just trying to describe the
circumstances surrounding the issue. I and others have reported the
scheduler oddity to LKML and it's being dealt with.

My question to this list could be condensed to:

Is it normal that over 25000 interrupts are generated when loading b43, 
or is the driver or something else broken?

I believe you guys are the best suited to answer this question.

>> While trying to find what these hickups come from I ran watch --interval 
>> .1 "cat /proc/interrupts". I can see there that the b43 disappears, gets 
>> unloaded probably, and then reappears.
> 
> You should probably show the exact contents of /proc/interrupts and
> provide some details about the systems (architecture, CPU speed,
> contents of /proc/sched_debug, lspci output, dmesg output).
> 
>> When b43 reappears in the interrupt listing, that line generates some 
>> 25000 irq's within a fraction of a second. Is this a bug somewhere or by 
>> design?
> 
> It's possible that the interrupt count is not shown when the driver
> "disappears", but is not reset to 0.  Once the interrupt has a handler,
> the original count is shown.
> 

This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 
(1600MHz), kubuntu 8.04
broadcom flavor: 4311
$ uname -a
Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux

I was trying to make a testcase, but can't find how to disable 
networkmanager, nor how to control if from a terminal. Just inactivating 
knetworkmanager and "rmmod b43" results in a segfault.

Anyway networkmanager seems to reload the driver periodically for some 
reason. Probably because it's stupid and unaware that the radio is 
disabled by hardware button.

b43 is loaded, not associated since wired networking is used.

$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:12:50 CEST 2008
  19:813 210843   IO-APIC-fasteoi   b43

a few moments later:

$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:15 CEST 2008
  19:813 210843   IO-APIC-fasteoi   b43
$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:16 CEST 2008
  19:813 210851   IO-APIC-fasteoi   b43
$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:17 CEST 2008
  19:813 210854   IO-APIC-fasteoi <-- b43 reloaded by nm
$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:18 CEST 2008
  19:856 232101   IO-APIC-fasteoi   b43
$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:19 CEST 2008
  19:871 236961   IO-APIC-fasteoi
$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:20 CEST 2008
  19:871 236969   IO-APIC-fasteoi   b43
$ date && cat /proc/interrupts |grep "19:"
fre apr 25 15:13:26 CEST 2008
  19:871 236969   IO-APIC-fasteoi   b43

"within a fraction of a second" was a slight exaggregation by me, but 
most of the interrupts happens within a second.

regards, Richard
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH] b43: Fix some TX/RX locking issues

Re: Tons of interrupts on driver load

[PATCH] b43: Don't disable IRQs in mac_suspend

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

[PATCH] b43: Fix some TX/RX locking issues

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Tons of interrupts on driver load

Re: Inconsistency in handling board revision

Re: Inconsistency in handling board revision

Re: Inconsistency in handling board revision

Re: Inconsistency in handling board revision

Re: Inconsistency in handling board revision

Re: [PATCH V3] ssb-sprom: Update README

Re: Inconsistency in handling board revision

Re: Tons of interrupts on driver load

25 matches

Site Navigation

Mail list logo

Footer information