On Tuesday 27 November 2007 22:22:22 Larry Finger wrote:
> > I'm wondering who causes this deadlock. "registered" should be false if
> > we are called back from rfkill_initialize, so it should return early before
> > the lock.
>
> The following code has the competing lock:
>
> static int rfkill_t
On Nov 28, 2007 4:25 AM, Larry Finger <[EMAIL PROTECTED]> wrote:
> In SoftMAC, the regulatory domain code defaulted to the Japanese standard and
> allowed channels 1-14.
> As I said earlier, mac80211 defaults to the FCC standard with channels 1-11.
> If you want to use
> channels 12 or 13, you n
Michael Buesch wrote:
>
> So it's a lock dependency between rfkill->mutex and wl->mutex?
> So, now comes the question that really matters. Who is the caller
> of rfkill_toggle_radio, in the case where it crashes?
>
Here is the full dump. It looks to me as if b43_rfkill_soft_toggle() calls
rfkill
Since addition of the rfkill callback, the LED associated with the off/on
switch on the radio has not worked because essential data in the rfkill
structure is missing. When that problem was fixed, difficulties in circular
locking surfaced. This patch fixes part of the regression in that the LED
is
On Wednesday 28 November 2007 16:05:35 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > So it's a lock dependency between rfkill->mutex and wl->mutex?
> > So, now comes the question that really matters. Who is the caller
> > of rfkill_toggle_radio, in the case where it crashes?
> >
>
> Here is
On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
> Since addition of the rfkill callback, the LED associated with the off/on
> switch on the radio has not worked because essential data in the rfkill
> structure is missing. When that problem was fixed, difficulties in circular
> locking su
Michael Buesch wrote:
> On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
>> Since addition of the rfkill callback, the LED associated with the off/on
>> switch on the radio has not worked because essential data in the rfkill
>> structure is missing. When that problem was fixed, difficulti
On Wednesday 28 November 2007 17:18:53 Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
> >> Since addition of the rfkill callback, the LED associated with the off/on
> >> switch on the radio has not worked because essential data in the rfki
Michael Buesch wrote:
>
> I think it's a different bug. The backtrace seems corrupted.
>
> Can you try this patch? There is some circular locking in rfkill.
I still get circular locking. The dump is
b43-phy0: Radio hardware status changed to DISABLED
b43-phy0: Radio hardware status changed to E
On Wednesday 28 November 2007 17:41:42 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > I think it's a different bug. The backtrace seems corrupted.
> >
> > Can you try this patch? There is some circular locking in rfkill.
>
> I still get circular locking. The dump is
Ok.
b43 init:
Michael Buesch wrote:
> On Wednesday 28 November 2007 17:41:42 Larry Finger wrote:
>> Michael Buesch wrote:
>>> I think it's a different bug. The backtrace seems corrupted.
>>>
>>> Can you try this patch? There is some circular locking in rfkill.
>> I still get circular locking. The dump is
>
> Ok
Shawn Tan wrote:
> Hi Larry,
>
> I found on the list archives that you were interested in SSB SPROM rev 3
> codes.
>
013871133C100800BE1D0087C42B642A6429642CE73CFF257FC7FF
FF12430080021000183C3CDF1A6FFC45FF3A1A89FC4
1FF1A005F73A8A1
this messages are when i try to connect to the ap,
the log say associted, but i cant get ip:
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27)
bcm43xx: Radio turned on
bcm43xx: Radio disabled by hardware
bcm43xx: Chip initialized
bcm43xx: 32-bit DMA initialized
bcm43xx: Keys cleared
bcm4
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked for several reasons:
(1) Essential data in the rfkill structure were missing.
(2) The rfkill structure was initialized after the LED initialization.
(3) There was a minor memory leak if the ra
This does not correct the LED issue in my Dell Latitude 620.
Let me know how I can help debug this. I'm available all night and I
can build a new kernel in about 5 minutes...
Ehud
[EMAIL PROTECTED] leds]# ls
b43-phy0:radio b43-phy0:rx b43-phy0:tx
[EMAIL PROTECTED] leds]# cat */uevent
PHYSDEV
Ehud Gavron wrote:
>
> This does not correct the LED issue in my Dell Latitude 620.
>
> Let me know how I can help debug this. I'm available all night and I
> can build a new kernel in about 5 minutes...
When you turn the radio off/on, do you see the following messages?
b43-phy0: Radio hardwar
Yes. See below. The USB device is the BT radio.
Ehud
usb 1-2.4: USB disconnect, address 4
b43-phy0: Radio hardware status changed to DISABLED
usb 1-2.4: new full speed USB device using ehci_hcd and address 7
usb 1-2.4: configuration #1 chosen from 1 choice
b43-phy0: Radio hardware status changed
Fix calc_nrssi_slope() which caused PHY TX errors on devices containing a
802.11a PHY. The code is synced to v4 specs and relevant registers are
renamed accordingly.
Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]>
---
Michael, John,
this fixes a not-so-fatal error with bcm4309 and possibly ot
Ehud Gavron wrote:
> Yes. See below. The USB device is the BT radio.
>
> Ehud
> usb 1-2.4: USB disconnect, address 4
> b43-phy0: Radio hardware status changed to DISABLED
> usb 1-2.4: new full speed USB device using ehci_hcd and address 7
> usb 1-2.4: configuration #1 chosen from 1 choice
> b43-
[EMAIL PROTECTED] ~]# SSB_SPROM=$(find /sys -name ssb_sprom)
[EMAIL PROTECTED] ~]# sudo cat $SSB_SPROM > ssb_sprom_copy
[EMAIL PROTECTED] ~]# more ssb_sprom_copy
0130070028100800BE0D00FF1143008002100018
Ehud Gavron wrote:
> [EMAIL PROTECTED] ~]# SSB_SPROM=$(find /sys -name ssb_sprom)
> [EMAIL PROTECTED] ~]# sudo cat $SSB_SPROM > ssb_sprom_copy
> [EMAIL PROTECTED] ~]# more ssb_sprom_copy
> 0130070028100800BE0D00FF1143008002100018
>
>
>
Just as a reminder in the hopes it triggers some thought, Fedora
2.6.23.1-42.fc8 worked... but 1-49.fc9 didn't, and none of everything or
wireless-2.6 worked.
If you think of anything I can test... let me know. It's early. :)
Ehud
Larry Finger wrote:
> Ehud Gavron wrote:
>> [EMAIL PROTECTED]
Ehud Gavron wrote:
> Just as a reminder in the hopes it triggers some thought, Fedora
> 2.6.23.1-42.fc8 worked... but 1-49.fc9 didn't, and none of everything or
> wireless-2.6 worked.
>
> If you think of anything I can test... let me know. It's early. :)
Kernels without the new LED handling wi
23 matches
Mail list logo
