All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [OpenWrt-Devel] AR9330 hornet board stops beaconing after a few days (0xdeadbeef)
Date: Thu, 13 Sep 2012 19:55:14 +0200	[thread overview]
Message-ID: <50521E02.4030809@openwrt.org> (raw)
In-Reply-To: <20120913165124.GA13877@pandem0nium>

On 2012-09-13 6:51 PM, Simon Wunderlich wrote:
> ath9k fellows,
> 
> as it seems no one could find the cause for this problem so far. I'd therefore
> like to create a workaround by checking one/some registers for 0xdeadbeef and
> reset the chip if this is found.
> 
> Can anyone recommend a register which should never go 0xdeadbeef in a normal case?
> 
> From what i've seen, AR_CFG (0x0014) might be a good choice. My regdumps say:
> 
> bad regdump:  0x000014 0xdeadbeef    
> good regdump: 0x000014 0x0008010a
> 
> Unfortunately I don't have documentation to find out if this register can ever
> go deadbeef in a normal case. :)
> 
> What do you think? (of course, a proper solution is still appreciated ...)
If ah->power_mode == ATH9K_PM_AWAKE, then no regularly used register may
return 0xdeadbeef. You can use a combination of the register and the
power mode as an indicator.

- Felix

WARNING: multiple messages have this Message-ID (diff)
From: Felix Fietkau <nbd@openwrt.org>
To: OpenWrt Development List <openwrt-devel@lists.openwrt.org>
Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>,
	Sven Eckelmann <sven@narfation.org>,
	Adrian Chadd <adrian.chadd@gmail.com>,
	ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org,
	Mohammed Shafi <shafi.wireless@gmail.com>,
	Marek Lindner <lindner_marek@yahoo.de>
Subject: Re: [OpenWrt-Devel] AR9330 hornet board stops beaconing after a few days (0xdeadbeef)
Date: Thu, 13 Sep 2012 19:55:14 +0200	[thread overview]
Message-ID: <50521E02.4030809@openwrt.org> (raw)
In-Reply-To: <20120913165124.GA13877@pandem0nium>

On 2012-09-13 6:51 PM, Simon Wunderlich wrote:
> ath9k fellows,
> 
> as it seems no one could find the cause for this problem so far. I'd therefore
> like to create a workaround by checking one/some registers for 0xdeadbeef and
> reset the chip if this is found.
> 
> Can anyone recommend a register which should never go 0xdeadbeef in a normal case?
> 
> From what i've seen, AR_CFG (0x0014) might be a good choice. My regdumps say:
> 
> bad regdump:  0x000014 0xdeadbeef    
> good regdump: 0x000014 0x0008010a
> 
> Unfortunately I don't have documentation to find out if this register can ever
> go deadbeef in a normal case. :)
> 
> What do you think? (of course, a proper solution is still appreciated ...)
If ah->power_mode == ATH9K_PM_AWAKE, then no regularly used register may
return 0xdeadbeef. You can use a combination of the register and the
power mode as an indicator.

- Felix


  parent reply	other threads:[~2012-09-13 17:55 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-13 16:53 AR9330 hornet board stops beaconing after a few days (0xdeadbeef) Simon Wunderlich
2012-08-19 22:04 ` Simon Wunderlich
2012-08-22  5:20   ` Mohammed Shafi
2012-08-22 18:57     ` Adrian Chadd
2012-08-23  9:28       ` Simon Wunderlich
2012-08-23 17:10         ` Gabor Juhos
2012-08-23 19:26           ` Adrian Chadd
2012-08-23 14:59     ` Mohammed Shafi
2012-08-23 15:19       ` Sven Eckelmann
2012-08-23 15:27         ` Sven Eckelmann
2012-09-02 20:01       ` [ath9k-devel] " Simon Wunderlich
2012-09-02 20:01         ` Simon Wunderlich
2012-09-03 13:53         ` [ath9k-devel] " Mohammed Shafi
2012-09-03 13:53           ` Mohammed Shafi
2012-09-03 14:34           ` [ath9k-devel] " Sven Eckelmann
2012-09-03 14:34             ` Sven Eckelmann
2012-09-04 17:12           ` [ath9k-devel] " Simon Wunderlich
2012-09-04 17:12             ` Simon Wunderlich
2012-09-05  5:12             ` [ath9k-devel] " Mohammed Shafi
2012-09-05  5:12               ` Mohammed Shafi
2012-09-05 14:08               ` [ath9k-devel] " Adrian Chadd
2012-09-05 14:08                 ` Adrian Chadd
2012-09-05 14:20                 ` [ath9k-devel] " Sven Eckelmann
2012-09-05 14:20                   ` Sven Eckelmann
2012-09-13 16:51                   ` [ath9k-devel] " Simon Wunderlich
2012-09-13 16:51                     ` Simon Wunderlich
2012-09-13 16:59                     ` [ath9k-devel] " Adrian Chadd
2012-09-13 16:59                       ` Adrian Chadd
2012-09-13 17:55                     ` Felix Fietkau [this message]
2012-09-13 17:55                       ` [OpenWrt-Devel] " Felix Fietkau
2012-09-14  9:47                       ` [ath9k-devel] [RFC] ath9k: Work around complete stuck of hw Sven Eckelmann
2012-09-14  9:47                         ` Sven Eckelmann
2012-09-14 11:33                         ` [ath9k-devel] " Felix Fietkau
2012-09-14 11:33                           ` Felix Fietkau
2012-09-23 10:04                           ` [ath9k-devel] " Sven Eckelmann
2012-09-23 10:04                             ` Sven Eckelmann
2013-11-20 20:57   ` [ath9k-devel] [OpenWrt-Devel] AR9330 hornet board stops beaconing after a few days (0xdeadbeef) Bastian Bittorf
2013-11-20 20:57     ` Bastian Bittorf
2013-11-20 21:00     ` [ath9k-devel] " Sven Eckelmann
2013-11-20 21:00       ` Sven Eckelmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50521E02.4030809@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.