Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c as
follows:
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c
@@ -133,6 +133,16 @@ void b43_rfkill_init(struct b43_wldev *d
rfk->poll_dev->poll = b43_rfkill_poll;
rfk->poll_dev->poll_interval = 1000; /* msecs */
+ rfk->poll_dev->input = input_allocate_device();
+ if (!rfk->poll_dev->input)
+ goto err_free_polldev;
+
+ rfk->poll_dev->input->name = rfk->name;
+ rfk->poll_dev->input->id.bustype = BUS_HOST;
+ rfk->poll_dev->input->id.vendor = dev->dev->bus->boardinfo.vendor;
+ rfk->poll_dev->input->evbit[0] = BIT(EV_KEY);
+ set_bit(KEY_WLAN, rfk->poll_dev->input->keybit);
+
err = rfkill_register(rfk->rfkill);
if (err)
goto err_free_polldev;
With this change, the input device is attached to b43. The message now is
"input: b43-phy0 as
/class/input/input7" rather than the "input: Unspecified device as
/class/input/input7" that I had
before. When the radio switch is toggled, I see the expected output:
b43-phy0: Radio hardware status changed to DISABLED
eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out of range
eth1: No STA entry for own AP 00:1a:70:46:ba:b1
b43-phy0: Radio hardware status changed to ENABLED
We then get a locking problem:
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc3-L2.6-g65d438bf-dirty #24
---
events/0/9 is trying to acquire lock:
(&wl->mutex){--..}, at: [] b43_rfkill_soft_toggle+0x33/0xb2
[b43]
but task is already holding lock:
(&rfkill->mutex){--..}, at: [] rfkill_toggle_radio+0x1f/0x7d
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&rfkill->mutex){--..}:
[] __lock_acquire+0xb34/0xd47
[] rfkill_toggle_radio+0x1f/0x7d
[] lock_acquire+0x85/0xa9
[] rfkill_toggle_radio+0x1f/0x7d
[] mutex_lock_interruptible_nested+0x113/0x31e
[] rfkill_toggle_radio+0x1f/0x7d
[] rfkill_toggle_radio+0x1f/0x7d
[] rfkill_register+0x9b/0x107
[] b43_rfkill_init+0x15e/0x1cb [b43]
[] b43_wireless_core_init+0x682/0x784 [b43]
[] b43_op_start+0x33/0x74 [b43]
[] ieee80211_open+0x1c7/0x3dd [mac80211]
[] dev_open+0x4e/0x88
[] dev_change_flags+0xaf/0x16b
[] do_setlink+0x27a/0x346
[] _read_unlock+0x26/0x2b
[] rtnl_setlink+0xf9/0x11c
[] rtnetlink_rcv_msg+0x1b6/0x1d5
[] rtnetlink_rcv_msg+0x0/0x1d5
[] netlink_rcv_skb+0x3e/0xaa
[] rtnetlink_rcv+0x20/0x29
[] netlink_unicast+0x1d9/0x23a
[] __alloc_skb+0x8a/0x138
[] netlink_sendmsg+0x2aa/0x2bd
[] sock_sendmsg+0xdf/0xf8
[] autoremove_wake_function+0x0/0x38
[] autoremove_wake_function+0x0/0x38
[] __lock_acquire+0xd26/0xd47
[] move_addr_to_kernel+0x40/0x49
[] verify_iovec+0x4f/0x8e
[] sys_sendmsg+0x1e1/0x253
[] up_read+0x26/0x2a
[] do_page_fault+0x3bf/0x764
[] sys_getsockname+0x66/0x8c
[] trace_hardirqs_on+0x11c/0x147
[] trace_hardirqs_on_thunk+0x35/0x3a
[] system_call+0x7e/0x83
[] 0x
-> #1 (rfkill_mutex){--..}:
[] __lock_acquire+0xb34/0xd47
[] rfkill_register+0x87/0x107
[] lock_acquire+0x85/0xa9
[] rfkill_register+0x87/0x107
[] rfkill_register+0x87/0x107
[] mutex_lock_nested+0x10e/0x2b6
[] rfkill_register+0x87/0x107
[] b43_rfkill_init+0x15e/0x1cb [b43]
[] b43_wireless_core_init+0x682/0x784 [b43]
[] b43_op_start+0x33/0x74 [b43]
[] ieee80211_open+0x1c7/0x3dd [mac80211]
[] dev_open+0x4e/0x88
[] dev_change_flags+0xaf/0x16b
[] do_setlink+0x27a/0x346
[] _read_unlock+0x26/0x2b
[] rtnl_setlink+0xf9/0x11c
[] rtnetlink_rcv_msg+0x1b6/0x1d5
[] rtnetlink_rcv_msg+0x0/0x1d5
[] netlink_rcv_skb+0x3e/0xaa
[] rtnetlink_rcv+0x20/0x29
[] netlink_unicast+0x1d9/0x23a
[] __alloc_skb+0x8a/0x138
[] netlink_sendmsg+0x2aa/0x2bd
[] sock_sendmsg+0xdf/0xf8
[] autoremove_wake_function+0x0/0x38
[] autoremove_wake_function+0x0/0x38
[] __lock_acquire+0xd26/0xd47
[] move_addr_to_kernel+0x40/0x49
[] verify_iovec+0x4f/0x8e
[] sys_sendmsg+0x1e1/0x253
[] up_read+0x26/0x2a
[] do_page_fault+0x3bf/0x764
[] sys_getsockname+0x66/0x8c
[] trace_hardirqs_on+0x11c/0x147
[] trace_hardirqs_on_thunk+0x35/0x3a
[] system_call+0x7e/0x83
[] 0xf
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
LEDs work with Fedora Kernel 2.6.23.1-42.fc8. LEDs NOT with Fedora Kernel 2.6.23.1-49.fc8 LEDs NOT with everything/2.6.24-rc2 LEDs NOT with wireless-2.6/2.6.24-rc3 I have the same settings in dot config as Larry does below and I have the same info except for ...uevent has a power button but I didn't see anything in any ...uevent that looked related to B43. I'd post a uname -a but you have the kernel names above. I'd post a dmesg but they are unchanged. I'd post an iwconfig but they don't matter. EVERYTHING WORKS except for the LEDs except they do work with the earlier Fedora kernel but not the latter one. Ehud Larry Finger wrote: Michael Buesch wrote: Dunno. That's a poll-input-dev problem then. Do you have all poll-input options enabled? I think so. I have the following in .config: CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set CONFIG_INPUT_POLLDEV=m I also tried it with the three components built in rather than as modules. It did not make a difference. Because the log has the message "input: Unspecified device as /class/input/input7", I have looked at the contents of /sys/class. I find that "/sys/class/input/input7/uevent" contains PRODUCT=0/0/0/0 EV==1 MODALIAS=input:bvpe-e0,kramlsfw whereas /sys/class/input/input6/uevent has PRODUCT=19/0/1/0 NAME="Power Button (CM)" PHYS="PNP0C0C/button/input0" EV==3 KEY==10 0 MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw I have no idea how to interpret these data; however, #6 certainly has a lot more information than #7. I'm pretty sure #7 is associated with the BCM4311. Larry ___ 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: Patch for 4311/2 to work with mainline 2.6.24-rcX
On Mon, 2007-11-26 at 10:45 -0600, Larry Finger wrote: > I have created a patch that updates all the SPROM handling and the other code > needed to drive the > BCM4311 rev 02 with the mainline code in Linus's tree. Normally, I would have > placed this patch on > my FTP server, but that machine will go off-line in the next day, or so. Is > there some other > location where this could be made available? If you send me an ssh public key I can give you write access to the download dir on linuxwireless.org. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V5] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Monday 26 November 2007 17:29:47 Larry Finger wrote:
> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
> has not been supported until now. The changes include the following:
>
> (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
> (2) Add PHY revision 9 to the supported list.
> (3) Change the 2-bit routing code for address extensions to 0b10 rather
> than the 0b01 used for the 32-bit case.
> (4) Remove some magic numbers in the DMA setup.
>
> The DMA implementation for this chip supports full 64-bit addressing with
> one exception. Whenever the Descriptor Ring Buffer is in high memory, a
> fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
> to code to "Bias the placement of kernel pages at lower PFNs". When
> commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
> this problem is thought to arise from a hardware error.
>
> This patch has been tested on my system and by Cédric Caumont
> <[EMAIL PROTECTED]>.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> John,
>
> This patch is intended for the everything branch of wireless-2.6.
>
> Larry
> ---
>
> dma.c | 30 ++
> main.c |3 ++-
> wa.c |1 +
> 3 files changed, 25 insertions(+), 9 deletions(-)
>
> Index: wireless-2.6/drivers/net/wireless/b43/dma.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
> +++ wireless-2.6/drivers/net/wireless/b43/dma.c
> @@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
> addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
> addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
> >> SSB_DMA_TRANSLATION_SHIFT;
> - addrhi |= ssb_dma_translation(ring->dev->dev);
> + addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
> if (slot == ring->nr_slots - 1)
> ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
> if (start)
> @@ -426,9 +426,21 @@ static inline
> static int alloc_ringmemory(struct b43_dmaring *ring)
> {
> struct device *dev = ring->dev->dev->dev;
> + gfp_t flags = GFP_KERNEL;
>
> + /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
> + * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
> + * has shown that 4K is sufficient for the latter as long as the buffer
> + * does not cross an 8K boundary.
> + *
> + * For unknown reasons - possibly a hardware error - the BCM4311 rev
> + * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
> + * which accounts for the GFP_DMA flag below.
> + */
> + if (ring->dma64)
> + flags |= GFP_DMA;
> ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
> - &(ring->dmabase), GFP_KERNEL);
> + &(ring->dmabase), flags);
> if (!ring->descbase) {
> b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
> return -ENOMEM;
> @@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
> return 0;
> }
>
> -/* Reset the RX DMA channel */
> +/* Reset the TX DMA channel */
> int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int
> dma64)
> {
> int i;
> @@ -647,7 +659,7 @@ static int dmacontroller_setup(struct b4
> b43_dma_write(ring, B43_DMA64_TXRINGHI,
> ((ringbase >> 32) &
> ~SSB_DMA_TRANSLATION_MASK)
> - | trans);
> + | (trans << 1));
> } else {
> u32 ringbase = (u32) (ring->dmabase);
>
> @@ -680,8 +692,9 @@ static int dmacontroller_setup(struct b4
> b43_dma_write(ring, B43_DMA64_RXRINGHI,
> ((ringbase >> 32) &
> ~SSB_DMA_TRANSLATION_MASK)
> - | trans);
> - b43_dma_write(ring, B43_DMA64_RXINDEX, 200);
> + | (trans << 1));
> + b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
> + sizeof(struct b43_dmadesc64));
> } else {
> u32 ringbase = (u32) (ring->dmabase);
>
> @@ -695,11 +708,12 @@ static int dmacontroller_setup(struct b4
> b43_dma_write(ring, B43_DMA32_RXRING,
> (ringbase & ~SSB_DMA_TRANSLATION_MASK)
> | trans);
> - b43_dma_write(ring, B43_DMA32_RXINDEX, 200);
> + b43_dma_write(ring, B43_DMA32_RXIND
Patch for 4311/2 to work with mainline 2.6.24-rcX
I have created a patch that updates all the SPROM handling and the other code needed to drive the BCM4311 rev 02 with the mainline code in Linus's tree. Normally, I would have placed this patch on my FTP server, but that machine will go off-line in the next day, or so. Is there some other location where this could be made available? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V5] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Change the 2-bit routing code for address extensions to 0b10 rather
than the 0b01 used for the 32-bit case.
(4) Remove some magic numbers in the DMA setup.
The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to "Bias the placement of kernel pages at lower PFNs". When
commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.
This patch has been tested on my system and by Cédric Caumont
<[EMAIL PROTECTED]>.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch is intended for the everything branch of wireless-2.6.
Larry
---
dma.c | 30 ++
main.c |3 ++-
wa.c |1 +
3 files changed, 25 insertions(+), 9 deletions(-)
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
+++ wireless-2.6/drivers/net/wireless/b43/dma.c
@@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
>> SSB_DMA_TRANSLATION_SHIFT;
- addrhi |= ssb_dma_translation(ring->dev->dev);
+ addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
if (slot == ring->nr_slots - 1)
ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
if (start)
@@ -426,9 +426,21 @@ static inline
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring->dev->dev->dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+* alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
+* has shown that 4K is sufficient for the latter as long as the buffer
+* does not cross an 8K boundary.
+*
+* For unknown reasons - possibly a hardware error - the BCM4311 rev
+* 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+* which accounts for the GFP_DMA flag below.
+*/
+ if (ring->dma64)
+ flags |= GFP_DMA;
ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
- &(ring->dmabase), GFP_KERNEL);
+ &(ring->dmabase), flags);
if (!ring->descbase) {
b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
return -ENOMEM;
@@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
return 0;
}
-/* Reset the RX DMA channel */
+/* Reset the TX DMA channel */
int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
{
int i;
@@ -647,7 +659,7 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA64_TXRINGHI,
((ringbase >> 32) &
~SSB_DMA_TRANSLATION_MASK)
- | trans);
+ | (trans << 1));
} else {
u32 ringbase = (u32) (ring->dmabase);
@@ -680,8 +692,9 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA64_RXRINGHI,
((ringbase >> 32) &
~SSB_DMA_TRANSLATION_MASK)
- | trans);
- b43_dma_write(ring, B43_DMA64_RXINDEX, 200);
+ | (trans << 1));
+ b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc64));
} else {
u32 ringbase = (u32) (ring->dmabase);
@@ -695,11 +708,12 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA32_RXRING,
(ringbase & ~SSB_DMA_TRANSLATION_MASK)
| trans);
- b43_dma_write(ring, B43_DMA32_RXINDEX, 200);
+ b43_dma_write(ring, B43_DMA32_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc32));
}
}
- out:
+out:
return err;
}
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
Re: [PATCH V4] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Monday 26 November 2007 17:00:06 Larry Finger wrote:
> static int alloc_ringmemory(struct b43_dmaring *ring)
> {
> struct device *dev = ring->dev->dev->dev;
> + gfp_t flags = GFP_KERNEL;
>
> + /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
> + * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
> + * has shown that 4K is sufficient for the latter as long as the buffer
> + * does not cross an 8K boundary.
> + *
> + * For unknown reasons - possibly a hardware error - the BCM4311 rev
> + * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
> + * which accounts for the GFP_DMA flag below.
> + */
> + if (ring->dma64)
> + flags = GFP_DMA;
???
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V3] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
Cédric Caumont wrote: > Hello everyone > > I have just one question! > > I downloaded linux-2.6.24-rc3 > > cd /usr/src/ > ln -sfn linux-2.6.24-rc3 linux > cd linux > patch -p1 < patch_v3.patch > > * > can't find file to patch at input line 112 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |Index: wireless-2.6/drivers/net/wireless/b43/wa.c The patch is for the wireless-2.6 git tree. To use 2.6.24-rc3 from mainline, there are some additional patches needed. I will generate that patch and send it to you privately. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V4] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Change the 2-bit routing code for address extensions to 0b10 rather
than the 0b01 used for the 32-bit case.
(4) Remove some magic numbers in the DMA setup.
The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to "Bias the placement of kernel pages at lower PFNs". When
commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.
This patch has been tested on my system and by Cédric Caumont
<[EMAIL PROTECTED]>.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch is intended for the everything branch of wireless-2.6.
Larry
---
dma.c | 30 ++
main.c |3 ++-
wa.c |1 +
3 files changed, 25 insertions(+), 9 deletions(-)
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
+++ wireless-2.6/drivers/net/wireless/b43/dma.c
@@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
>> SSB_DMA_TRANSLATION_SHIFT;
- addrhi |= ssb_dma_translation(ring->dev->dev);
+ addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
if (slot == ring->nr_slots - 1)
ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
if (start)
@@ -426,9 +426,21 @@ static inline
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring->dev->dev->dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+* alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
+* has shown that 4K is sufficient for the latter as long as the buffer
+* does not cross an 8K boundary.
+*
+* For unknown reasons - possibly a hardware error - the BCM4311 rev
+* 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+* which accounts for the GFP_DMA flag below.
+*/
+ if (ring->dma64)
+ flags = GFP_DMA;
ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
- &(ring->dmabase), GFP_KERNEL);
+ &(ring->dmabase), flags);
if (!ring->descbase) {
b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
return -ENOMEM;
@@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
return 0;
}
-/* Reset the RX DMA channel */
+/* Reset the TX DMA channel */
int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
{
int i;
@@ -647,7 +659,7 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA64_TXRINGHI,
((ringbase >> 32) &
~SSB_DMA_TRANSLATION_MASK)
- | trans);
+ | (trans << 1));
} else {
u32 ringbase = (u32) (ring->dmabase);
@@ -680,8 +692,9 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA64_RXRINGHI,
((ringbase >> 32) &
~SSB_DMA_TRANSLATION_MASK)
- | trans);
- b43_dma_write(ring, B43_DMA64_RXINDEX, 200);
+ | (trans << 1));
+ b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc64));
} else {
u32 ringbase = (u32) (ring->dmabase);
@@ -695,11 +708,12 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA32_RXRING,
(ringbase & ~SSB_DMA_TRANSLATION_MASK)
| trans);
- b43_dma_write(ring, B43_DMA32_RXINDEX, 200);
+ b43_dma_write(ring, B43_DMA32_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc32));
}
}
- out:
+out:
return err;
}
Index: wireless-2.6/drivers/net/wireless/b43/main.c
RE: [PATCH V3] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
Hello everyone
I have just one question!
I downloaded linux-2.6.24-rc3
cd /usr/src/
ln -sfn linux-2.6.24-rc3 linux
cd linux
patch -p1 < patch_v3.patch
*
can't find file to patch at input line 112
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Index: wireless-2.6/drivers/net/wireless/b43/wa.c
|===
|--- wireless-2.6.orig/drivers/net/wireless/b43/wa.c
|+++ wireless-2.6/drivers/net/wireless/b43/wa.c
--
File to patch:
**
Where is the wa.c file? Why there is not in the kernel tree?
> Date: Mon, 26 Nov 2007 08:38:11 -0600
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PATCH V3] b43: Changes to enable BCM4311 rev 02 with wireless core
> revision 13
> CC: [EMAIL PROTECTED]; bcm43xx-dev@lists.berlios.de
>
> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
> has not been supported until now. The changes include the following:
>
> (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
> (2) Add PHY revision 9 to the supported list.
> (3) Change the 2-bit routing code for address extensions to 0b10 rather
> than the 0b01 used for the 32-bit case.
> (4) Remove some magic numbers in the DMA setup.
>
> The DMA implementation for this chip supports full 64-bit addressing with
> one exception. Whenever the Descriptor Ring Buffer is in high memory, a
> fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
> to code to "Bias the placement of kernel pages at lower PFNs". When
> commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
> this problem is thought to arise from a hardware error.
>
> This patch has been tested on my system, and by Cédric Caumont
> <[EMAIL PROTECTED]> and by Matthieu PATOU <[EMAIL PROTECTED]> on a BCM4312.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John,
>
> This patch is intended for the everything branch of wireless-2.6.
>
> Larry
> ---
>
> dma.c | 30 ++
> main.c |3 ++-
> wa.c |1 +
> 3 files changed, 25 insertions(+), 9 deletions(-)
>
> Index: wireless-2.6/drivers/net/wireless/b43/dma.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
> +++ wireless-2.6/drivers/net/wireless/b43/dma.c
> @@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
> addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
> addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
> >> SSB_DMA_TRANSLATION_SHIFT;
> - addrhi |= ssb_dma_translation(ring->dev->dev);
> + addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
> if (slot == ring->nr_slots - 1)
> ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
> if (start)
> @@ -426,9 +426,21 @@ static inline
> static int alloc_ringmemory(struct b43_dmaring *ring)
> {
> struct device *dev = ring->dev->dev->dev;
> + gfp_t flags = GFP_KERNEL;
>
> + /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
> + * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
> + * has shown that 4K is sufficient for the latter as long as the buffer
> + * does not cross an 8K boundary.
> + *
> + * For unknown reasons - possibly a hardware error - the BCM4311 rev
> + * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
> + * which accounts for the GFP_DMA flag below.
> + */
> + if (ring->dma64)
> + flags = GFP_DMA;
> ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
> - &(ring->dmabase), GFP_KERNEL);
> + &(ring->dmabase), flags);
> if (!ring->descbase) {
> b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
> return -ENOMEM;
> @@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
> return 0;
> }
>
> -/* Reset the RX DMA channel */
> +/* Reset the TX DMA channel */
> int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int
> dma64)
> {
> int i;
> @@ -647,7 +659,7 @@ static int dmacontroller_setup(struct b4
> b43_dma_write(ring, B43_DMA64_TXRINGHI,
> ((ringbase >> 32) &
> ~SSB_DMA_TRANSLATION_MASK)
> - | trans);
> + | (trans << 1));
> } else {
> u32 ringbase = (u32) (ring->dmabase);
>
> @
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
> > Do you have /sys/class/leds/b43-phyN:radio? If so, what does the trigger > File /sys/class/leds/b43-phy0\:rx/trigger contains > > none ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full [phy0rx] > phy0tx phy0assoc mmc0 rfkill0 > > and file /sys/class/leds/b43-phy0\:tx/trigger contains > > none ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full phy0rx > [phy0tx] phy0assoc mmc0 rfkill0 Right. No :radio LED though? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
Michael Buesch wrote: > > Dunno. That's a poll-input-dev problem then. Do you have all poll-input > options enabled? > I think so. I have the following in .config: CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set CONFIG_INPUT_POLLDEV=m I also tried it with the three components built in rather than as modules. It did not make a difference. Because the log has the message "input: Unspecified device as /class/input/input7", I have looked at the contents of /sys/class. I find that "/sys/class/input/input7/uevent" contains PRODUCT=0/0/0/0 EV==1 MODALIAS=input:bvpe-e0,kramlsfw whereas /sys/class/input/input6/uevent has PRODUCT=19/0/1/0 NAME="Power Button (CM)" PHYS="PNP0C0C/button/input0" EV==3 KEY==10 0 MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw I have no idea how to interpret these data; however, #6 certainly has a lot more information than #7. I'm pretty sure #7 is associated with the BCM4311. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V3] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Monday 26 November 2007 15:38:11 Larry Finger wrote:
> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
> has not been supported until now. The changes include the following:
>
> (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
> (2) Add PHY revision 9 to the supported list.
> (3) Change the 2-bit routing code for address extensions to 0b10 rather
> than the 0b01 used for the 32-bit case.
> (4) Remove some magic numbers in the DMA setup.
>
> The DMA implementation for this chip supports full 64-bit addressing with
> one exception. Whenever the Descriptor Ring Buffer is in high memory, a
> fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
> to code to "Bias the placement of kernel pages at lower PFNs". When
> commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
> this problem is thought to arise from a hardware error.
>
> This patch has been tested on my system, and by Cédric Caumont
> <[EMAIL PROTECTED]> and by Matthieu PATOU <[EMAIL PROTECTED]> on a BCM4312.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> static int alloc_ringmemory(struct b43_dmaring *ring)
> {
> struct device *dev = ring->dev->dev->dev;
> + gfp_t flags = GFP_KERNEL;
>
> + /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
> + * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
> + * has shown that 4K is sufficient for the latter as long as the buffer
> + * does not cross an 8K boundary.
> + *
> + * For unknown reasons - possibly a hardware error - the BCM4311 rev
> + * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
> + * which accounts for the GFP_DMA flag below.
> + */
> + if (ring->dma64)
> + flags = GFP_DMA;
Whoops, didn't notice this before. This needs to be
flags |= GFP_DMA;
> ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
> - &(ring->dmabase), GFP_KERNEL);
> + &(ring->dmabase), flags);
> if (!ring->descbase) {
> b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
> return -ENOMEM;
The rest is acked.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
Johannes Berg wrote: >> I have done a little looking into the problem of the radio LED not coming >> on, and have found the >> following: > > [...] > > Do you have /sys/class/leds/b43-phyN:radio? If so, what does the trigger > file contain? Maybe the LED is registered in the wrong order and the > default name was NULL? File /sys/class/leds/b43-phy0\:rx/trigger contains none ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full [phy0rx] phy0tx phy0assoc mmc0 rfkill0 and file /sys/class/leds/b43-phy0\:tx/trigger contains none ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full phy0rx [phy0tx] phy0assoc mmc0 rfkill0 Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V3] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Change the 2-bit routing code for address extensions to 0b10 rather
than the 0b01 used for the 32-bit case.
(4) Remove some magic numbers in the DMA setup.
The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to "Bias the placement of kernel pages at lower PFNs". When
commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.
This patch has been tested on my system, and by Cédric Caumont
<[EMAIL PROTECTED]> and by Matthieu PATOU <[EMAIL PROTECTED]> on a BCM4312.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch is intended for the everything branch of wireless-2.6.
Larry
---
dma.c | 30 ++
main.c |3 ++-
wa.c |1 +
3 files changed, 25 insertions(+), 9 deletions(-)
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
+++ wireless-2.6/drivers/net/wireless/b43/dma.c
@@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
>> SSB_DMA_TRANSLATION_SHIFT;
- addrhi |= ssb_dma_translation(ring->dev->dev);
+ addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
if (slot == ring->nr_slots - 1)
ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
if (start)
@@ -426,9 +426,21 @@ static inline
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring->dev->dev->dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+* alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
+* has shown that 4K is sufficient for the latter as long as the buffer
+* does not cross an 8K boundary.
+*
+* For unknown reasons - possibly a hardware error - the BCM4311 rev
+* 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+* which accounts for the GFP_DMA flag below.
+*/
+ if (ring->dma64)
+ flags = GFP_DMA;
ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
- &(ring->dmabase), GFP_KERNEL);
+ &(ring->dmabase), flags);
if (!ring->descbase) {
b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
return -ENOMEM;
@@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
return 0;
}
-/* Reset the RX DMA channel */
+/* Reset the TX DMA channel */
int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
{
int i;
@@ -647,7 +659,7 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA64_TXRINGHI,
((ringbase >> 32) &
~SSB_DMA_TRANSLATION_MASK)
- | trans);
+ | (trans << 1));
} else {
u32 ringbase = (u32) (ring->dmabase);
@@ -680,8 +692,9 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA64_RXRINGHI,
((ringbase >> 32) &
~SSB_DMA_TRANSLATION_MASK)
- | trans);
- b43_dma_write(ring, B43_DMA64_RXINDEX, 200);
+ | (trans << 1));
+ b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc64));
} else {
u32 ringbase = (u32) (ring->dmabase);
@@ -695,11 +708,12 @@ static int dmacontroller_setup(struct b4
b43_dma_write(ring, B43_DMA32_RXRING,
(ringbase & ~SSB_DMA_TRANSLATION_MASK)
| trans);
- b43_dma_write(ring, B43_DMA32_RXINDEX, 200);
+ b43_dma_write(ring, B43_DMA32_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc32));
}
}
- out:
+out:
return err;
}
Index:
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
On Monday 26 November 2007 02:26:38 Larry Finger wrote: > Michael and Ivo, > > I have done a little looking into the problem of the radio LED not coming on, > and have found the > following: > > 1. The call-back routine b43_rfkill_soft_toggle() is called once. When > called, rfkill.registered is > zero and the routine exits immediately. > > 2. The call-back routine b43_rfkill_poll() is never called, and the switch > that controls the radio > is never tested. > > 3. There is a log message "input: Unspecified device as /class/input/input7", > which I think arises > from the rfkill registration. > > I have the necessary hardware and am willing to test any suggested changes. > > Larry > > Dunno. That's a poll-input-dev problem then. Do you have all poll-input options enabled? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
crash with b43 wireless-2.6
Hi, I have a Belkin F5D7011 which contains a bcm4306 chip. Full lspci is attached. I'm using the wireless-2.6 tree, was last updated and recompiled on 7/11/2007. This card may suffer from Bug 9414, in that the LEDs don't come on at all but I'm not so pushed about that. Curiously my bcm4318 airforce one doesn't seem to have issues with LEDs. In the past few minutes I associated it with the open access point in our building here, then moved to a different room slightly further away from the access point. Network manager then seemed to indicate (with the swirling icon thing) that it had lost contact with the access point. My machine froze at this point, mouse not moving, nothing. I eventually hit s, b. I'm attaching the syslog information and lspci. I can report this on bugzilla but I just thought I'd try to ask first if this issue is known or fixed and if it is in fact a problem with b43 or with network-manager. Let me know if there's any more info which I should report too. I'm hoping to run a git-pull to update the tree shortly. Gavin = 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- Reset- FastB2B+ 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) Subsystem: Dell Unknown device 00dc Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) Subsystem: Belkin F5D7011 54g+ Wireless Network card Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- DHCP daemon state is now 1 (starting) for interface wlan0 Nov 26 10:14:26 tilly dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 Nov 26 10:14:28 tilly dhclient: DHCPOFFER from 192.168.1.1 Nov 26 10:14:28 tilly dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 Nov 26 10:14:29 tilly dhclient: DHCPACK from 192.168.1.1 Nov 26 10:14:29 tilly avahi-daemon[4769]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.4. Nov 26 10:14:29 tilly avahi-daemon[4769]: New relevant interface wlan0.IPv4 for mDNS. Nov 26 10:14:29 tilly avahi-daemon[4769]: Registering new address record for 192.168.1.4 on wlan0.IPv4. Nov 26 10:14:30 tilly NetworkManager: DHCP daemon state is now 2 (bound) for interface wlan0 Nov 26 10:14:30 tilly NetworkManager: Activation (wlan0) Stage 4 of 5 (IP Configure Get) scheduled... Nov 26 10:14:30 tilly NetworkManager: Activation (wlan0) Stage 4 of 5 (IP Configure Get) started... Nov 26 10:14:30 tilly dhclient: bound to 192.168.1.4 -- renewal in 37616 seconds. Nov 26 10:14:30 tilly dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.host_name Nov 26 10:14:30 tilly dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.domain_name Nov 26 10:14:30 tilly dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.nis_domain Nov 26 10:14:30 tilly dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.nis_servers Nov 26 10:14:30 tilly NetworkManager: Retrieved the following IP4 configuration from the DHCP daemon: Nov 26 10:14:30 tilly NetworkManager: address 192.168.1.4 Nov 26 10:14:30 tilly NetworkManager: netmask 255.255.255.0 Nov 26 10:14:30 tilly NetworkManager: broadcast 192.168.1.255 Nov 26 10:14:30 tilly NetworkManager: gateway 192.168.
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
> I have done a little looking into the problem of the radio LED not coming on, > and have found the > following: [...] Do you have /sys/class/leds/b43-phyN:radio? If so, what does the trigger file contain? Maybe the LED is registered in the wrong order and the default name was NULL? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
