kala mazoo wrote:
Date: Wed, 7 May 2008 22:18:32 -0500
From: [EMAIL PROTECTED]
Apparently there's more than just these bits in the sprom controlling the
LED
behaviour? Does anyone know what that might be?
I'm not sure
On Thu, May 8, 2008 at 8:11 AM, Ehud Gavron [EMAIL PROTECTED] wrote:
kala mazoo wrote:
Date: Wed, 7 May 2008 22:18:32 -0500
From: [EMAIL PROTECTED]
Apparently there's more than just these bits in the sprom controlling
the LED
Stefanik Gábor wrote:
...
Ehud Gavron: are you sure this discussion belongs to bcm43xx-dev?!
AFAIK the microcode doesn't really care about American vs. British
spellings.
Also, a good rule of thumb about which spelling to use: if you are
writing about US subjects, use US English. If
Greets,
Date: Tue, 6 May 2008 22:33:52 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: bcm43xx-dev@lists.berlios.de
Subject: Re: ASUS WL-138G v2 / 64bit x86 / b43 working much better
SPROM(0x64, LED 0 behaviour) = 0xFF
SPROM(0x65, LED 1
kala mazoo wrote:
Greets,
Date: Tue, 6 May 2008 22:33:52 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: bcm43xx-dev@lists.berlios.de
Subject: Re: ASUS WL-138G v2 / 64bit x86 / b43 working much better
SPROM(0x64, LED 0 behaviour
Date: Wed, 7 May 2008 22:18:32 -0500
From: [EMAIL PROTECTED]
Apparently there's more than just these bits in the sprom controlling the
LED
behaviour? Does anyone know what that might be?
I'm not sure what you should expect from the 0xFF values;
Greets,
Apologies for previous noise about 2.6.24 ooopsing. It wasn't
relevant..
As queried, I grabbed the (then) latest wireless-testing tree, and that
compiled
loaded modules without the noted errors. The asus card worked, although in this
case the rx/tx LED remains off the
kala mazoo wrote:
Greets,
Apologies for previous noise about 2.6.24 ooopsing. It wasn't
relevant..
As queried, I grabbed the (then) latest wireless-testing tree, and that
compiled
loaded modules without the noted errors. The asus card worked, although in
this
case the
