ath5k gets lost with eeepc-laptop removal

ath5k gets lost with eeepc-laptop removal

[Luiz Fernando N. Capitulino]

 Hi guys,

 If I do a 'rmmod eeepc-laptop', while connected to my AP, I get the
following error messages from ath5k:

"""
ath5k phy0: noise floor calibration timeout (2417MHz)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
wlan0: No ProbeResp from current AP 00:1d:0f:e9:c7:c0 - assume out of range
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz)
wlan0: failed to set freq to 2412 MHz for scan
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: ath5k_chan_set: unable to reset channel (2417 Mhz)
wlan0: failed to set freq to 2417 MHz for scan
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: ath5k_chan_set: unable to reset channel (2422 Mhz)
wlan0: failed to set freq to 2422 MHz for scan
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: ath5k_chan_set: unable to reset channel (2427 Mhz)
wlan0: failed to set freq to 2427 MHz for scan
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: ath5k_chan_set: unable to reset channel (2432 Mhz)
wlan0: failed to set freq to 2432 MHz for scan
wlan0: failed to set freq to 2437 MHz for scan
wlan0: failed to set freq to 2442 MHz for scan
wlan0: failed to set freq to 2447 MHz for scan
wlan0: failed to set freq to 2452 MHz for scan
wlan0: failed to set freq to 2457 MHz for scan
wlan0: failed to set freq to 2462 MHz for scan
wlan0: failed to set freq to 2467 MHz for scan
wlan0: failed to set freq to 2472 MHz for scan
wlan0: failed to set freq to 2484 MHz for scan
wlan0: failed to restore operational channel after scan
wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
wlan0: authentication with AP 00:1d:0f:e9:c7:c0 timed out
"""

 Then I lost my wireless connection.

 I'm running latest Linus git tree (2.6.28-rc2) on a Eeepc 701.

 The problem doesn't happen on 2.6.27.4, but as 2.6.28-rc1 doesn't
boot on this machine, it would be a bit difficult to bisect it.

 Thanks.

-- 
Luiz Fernando N. Capitulino

Re: ath5k gets lost with eeepc-laptop removal

[Alan Jenkins]

Luiz Fernando N. Capitulino wrote:
>  Hi guys,
> 
>  If I do a 'rmmod eeepc-laptop', while connected to my AP, I get the
> following error messages from ath5k:
> 
> """
> ath5k phy0: noise floor calibration timeout (2417MHz)
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: can't reset hardware (-5)
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: can't reset hardware (-5)
> wlan0: No ProbeResp from current AP 00:1d:0f:e9:c7:c0 - assume out of range
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz)
> wlan0: failed to set freq to 2412 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2417 Mhz)
> wlan0: failed to set freq to 2417 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2422 Mhz)
> wlan0: failed to set freq to 2422 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2427 Mhz)
> wlan0: failed to set freq to 2427 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2432 Mhz)
> wlan0: failed to set freq to 2432 MHz for scan
> wlan0: failed to set freq to 2437 MHz for scan
> wlan0: failed to set freq to 2442 MHz for scan
> wlan0: failed to set freq to 2447 MHz for scan
> wlan0: failed to set freq to 2452 MHz for scan
> wlan0: failed to set freq to 2457 MHz for scan
> wlan0: failed to set freq to 2462 MHz for scan
> wlan0: failed to set freq to 2467 MHz for scan
> wlan0: failed to set freq to 2472 MHz for scan
> wlan0: failed to set freq to 2484 MHz for scan
> wlan0: failed to restore operational channel after scan
> wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
> wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
> wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
> wlan0: authentication with AP 00:1d:0f:e9:c7:c0 timed out
> """
> 
>  Then I lost my wireless connection.
> 
>  I'm running latest Linus git tree (2.6.28-rc2) on a Eeepc 701.
> 
>  The problem doesn't happen on 2.6.27.4, but as 2.6.28-rc1 doesn't
> boot on this machine, it would be a bit difficult to bisect it.
> 
>  Thanks.
> 

The trick with bisection is to identify the fix, use "git cherry-pick" to apply it before testing, and then "git reset --hard HEAD^" to unapply the fix before "git bisect {good|bad}".

But you shouldn't need to bisect.  It'll be the addition of rfkill support (see below).

Matthew: I nagged you twice about different consequences of this commit, so here's a third :).  You said rfkill no longer automatically frobs on suspend/resume, which was what I was worried about last time.  Should the core code also  be modified so it doesn't do anything when the rfkill device is unregistered?

Thanks
Alan

---

commit a195dcdcff33b8ef01a23cbc489fdfcdfa28c88e
Author: Matthew Garrett <mjg59@srcf.ucam.org>
Date:   Tue Aug 19 12:13:20 2008 +0100

    eeepc-laptop: Use standard interfaces

    eeepc-laptop currently only sends key events via ACPI and has
    non-standard rfkill control. Add an input device and use the rfkill
    infrastructure.

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

Re: ath5k gets lost with eeepc-laptop removal

[Matthew Garrett]

On Fri, Oct 31, 2008 at 01:51:49PM +0000, Alan Jenkins wrote:

> Matthew: I nagged you twice about different consequences of this 
> commit, so here's a third :).  You said rfkill no longer automatically 
> frobs on suspend/resume, which was what I was worried about last time.  
> Should the core code also be modified so it doesn't do anything when 
> the rfkill device is unregistered?

I think there's definitely an argument in favour of that, though I 
suspect that's a design feature - if you remove the control mechanism 
for a radio, the safe state for that radio to be in is not transmitting.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ath5k gets lost with eeepc-laptop removal

[Nick Kossifidis]

2008/10/31 Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>:
>
>  Hi guys,
>
>  If I do a 'rmmod eeepc-laptop', while connected to my AP, I get the
> following error messages from ath5k:
>
> """
> ath5k phy0: noise floor calibration timeout (2417MHz)
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: can't reset hardware (-5)
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: can't reset hardware (-5)
> wlan0: No ProbeResp from current AP 00:1d:0f:e9:c7:c0 - assume out of range
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz)
> wlan0: failed to set freq to 2412 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2417 Mhz)
> wlan0: failed to set freq to 2417 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2422 Mhz)
> wlan0: failed to set freq to 2422 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2427 Mhz)
> wlan0: failed to set freq to 2427 MHz for scan
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: ath5k_chan_set: unable to reset channel (2432 Mhz)
> wlan0: failed to set freq to 2432 MHz for scan
> wlan0: failed to set freq to 2437 MHz for scan
> wlan0: failed to set freq to 2442 MHz for scan
> wlan0: failed to set freq to 2447 MHz for scan
> wlan0: failed to set freq to 2452 MHz for scan
> wlan0: failed to set freq to 2457 MHz for scan
> wlan0: failed to set freq to 2462 MHz for scan
> wlan0: failed to set freq to 2467 MHz for scan
> wlan0: failed to set freq to 2472 MHz for scan
> wlan0: failed to set freq to 2484 MHz for scan
> wlan0: failed to restore operational channel after scan
> wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
> wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
> wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
> wlan0: authentication with AP 00:1d:0f:e9:c7:c0 timed out
> """
>
>  Then I lost my wireless connection.
>
>  I'm running latest Linus git tree (2.6.28-rc2) on a Eeepc 701.
>
>  The problem doesn't happen on 2.6.27.4, but as 2.6.28-rc1 doesn't
> boot on this machine, it would be a bit difficult to bisect it.
>
>  Thanks.
>

After this does ath_info work ?


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: ath5k gets lost with eeepc-laptop removal

[Luiz Fernando N. Capitulino]

Em Fri, 31 Oct 2008 18:26:28 +0200
"Nick Kossifidis" <mickflemm@gmail.com> escreveu:

| 2008/10/31 Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>:
| >
| >  Hi guys,
| >
| >  If I do a 'rmmod eeepc-laptop', while connected to my AP, I get the
| > following error messages from ath5k:
| >
| > """
| > ath5k phy0: noise floor calibration timeout (2417MHz)
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: can't reset hardware (-5)
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: can't reset hardware (-5)
| > wlan0: No ProbeResp from current AP 00:1d:0f:e9:c7:c0 - assume out of range
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz)
| > wlan0: failed to set freq to 2412 MHz for scan
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: ath5k_chan_set: unable to reset channel (2417 Mhz)
| > wlan0: failed to set freq to 2417 MHz for scan
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: ath5k_chan_set: unable to reset channel (2422 Mhz)
| > wlan0: failed to set freq to 2422 MHz for scan
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: ath5k_chan_set: unable to reset channel (2427 Mhz)
| > wlan0: failed to set freq to 2427 MHz for scan
| > ath5k phy0: failed to wakeup the MAC Chip
| > ath5k phy0: ath5k_chan_set: unable to reset channel (2432 Mhz)
| > wlan0: failed to set freq to 2432 MHz for scan
| > wlan0: failed to set freq to 2437 MHz for scan
| > wlan0: failed to set freq to 2442 MHz for scan
| > wlan0: failed to set freq to 2447 MHz for scan
| > wlan0: failed to set freq to 2452 MHz for scan
| > wlan0: failed to set freq to 2457 MHz for scan
| > wlan0: failed to set freq to 2462 MHz for scan
| > wlan0: failed to set freq to 2467 MHz for scan
| > wlan0: failed to set freq to 2472 MHz for scan
| > wlan0: failed to set freq to 2484 MHz for scan
| > wlan0: failed to restore operational channel after scan
| > wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
| > wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
| > wlan0: authenticate with AP 00:1d:0f:e9:c7:c0
| > wlan0: authentication with AP 00:1d:0f:e9:c7:c0 timed out
| > """
| >
| >  Then I lost my wireless connection.
| >
| >  I'm running latest Linus git tree (2.6.28-rc2) on a Eeepc 701.
| >
| >  The problem doesn't happen on 2.6.27.4, but as 2.6.28-rc1 doesn't
| > boot on this machine, it would be a bit difficult to bisect it.
| >
| >  Thanks.
| >
| 
| After this does ath_info work ?

 No, it doesn't. It says:

"""
MAC revision 0xffff is not supported!
"""

 And I have realized that I get a flood of 'failed to wakeup'
and 'can't reset the hardware' error messages, just some seconds
after the eeepc-laptop module removal.

-- 
Luiz Fernando N. Capitulino

Re: ath5k gets lost with eeepc-laptop removal

[Nick Kossifidis]

2008/10/31 Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>:
>
>  No, it doesn't. It says:
>
> """
> MAC revision 0xffff is not supported!
> """
>
>  And I have realized that I get a flood of 'failed to wakeup'
> and 'can't reset the hardware' error messages, just some seconds
> after the eeepc-laptop module removal.
>

Well it seems that during module removal, card gets no power at all.
I don't see any reason for this behaviour. Do you have pci-e hotplug enabled ?


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: ath5k gets lost with eeepc-laptop removal

[Nick Kossifidis]

2008/10/31 Matthew Garrett <mjg59@srcf.ucam.org>:
> On Fri, Oct 31, 2008 at 01:51:49PM +0000, Alan Jenkins wrote:
>
>> Matthew: I nagged you twice about different consequences of this
>> commit, so here's a third :).  You said rfkill no longer automatically
>> frobs on suspend/resume, which was what I was worried about last time.
>> Should the core code also be modified so it doesn't do anything when
>> the rfkill device is unregistered?
>
> I think there's definitely an argument in favour of that, though I
> suspect that's a design feature - if you remove the control mechanism
> for a radio, the safe state for that radio to be in is not transmitting.
>

It doesn't leave the radio in a state that's not transmitting, it
leaves the card in a state that doesn't get any power at all. I don't
see any reason for this, how do you define "safe" ?



-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: ath5k gets lost with eeepc-laptop removal

[Luiz Fernando N. Capitulino]

Em Fri, 31 Oct 2008 20:33:43 +0200
"Nick Kossifidis" <mickflemm@gmail.com> escreveu:

| 2008/10/31 Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>:
| >
| >  No, it doesn't. It says:
| >
| > """
| > MAC revision 0xffff is not supported!
| > """
| >
| >  And I have realized that I get a flood of 'failed to wakeup'
| > and 'can't reset the hardware' error messages, just some seconds
| > after the eeepc-laptop module removal.
| >
| 
| Well it seems that during module removal, card gets no power at all.
| I don't see any reason for this behaviour. Do you have pci-e hotplug enabled ?

 Well, the pciehp module is not loaded and the eeepc's function keys
don't work anyway (this is the original problem I was looking at).

-- 
Luiz Fernando N. Capitulino

Re: ath5k gets lost with eeepc-laptop removal

[Luiz Fernando N. Capitulino]

Em Fri, 31 Oct 2008 16:43:51 -0200
"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> escreveu:

| Em Fri, 31 Oct 2008 20:33:43 +0200
| "Nick Kossifidis" <mickflemm@gmail.com> escreveu:
| 
| | 2008/10/31 Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>:
| | >
| | >  No, it doesn't. It says:
| | >
| | > """
| | > MAC revision 0xffff is not supported!
| | > """
| | >
| | >  And I have realized that I get a flood of 'failed to wakeup'
| | > and 'can't reset the hardware' error messages, just some seconds
| | > after the eeepc-laptop module removal.
| | >
| | 
| | Well it seems that during module removal, card gets no power at all.
| | I don't see any reason for this behaviour. Do you have pci-e hotplug enabled ?
| 
|  Well, the pciehp module is not loaded and the eeepc's function keys
| don't work anyway (this is the original problem I was looking at).

 Hmm. You think this could be related, Matthew?

 Actually 'they don't work' is not helpful, I have been looking at
the wireless one (fn2) which doesn't even turn the led off but the
driver seems to receive the event.

-- 
Luiz Fernando N. Capitulino

Re: ath5k gets lost with eeepc-laptop removal

[Matthew Garrett]

On Fri, Oct 31, 2008 at 04:48:59PM -0200, Luiz Fernando N. Capitulino wrote:

>  Hmm. You think this could be related, Matthew?

No, I think that's unrelated. But unloading eeepc-laptop will cause 
rfkill to shut down the platform radio, which on the eee triggers a PCIe 
unplug of the card and powers it down.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ath5k gets lost with eeepc-laptop removal

[Matthew Garrett]

On Fri, Oct 31, 2008 at 08:35:47PM +0200, Nick Kossifidis wrote:

> It doesn't leave the radio in a state that's not transmitting, it
> leaves the card in a state that doesn't get any power at all. I don't
> see any reason for this, how do you define "safe" ?

The rfkill core has no concept of what the underlying hardware 
implementation is. The fact that you can see the card at all is a bug 
triggered by the fact that we don't currently support PCIe hotplug on 
this type of machine (I've just sent a patch that adds a workaround for 
that), but the inherent reason for it happening this way is because Asus 
implemented it that way in their platform.

-- 
Matthew Garrett | mjg59@srcf.ucam.org