> i'm sorry i haven't been able to completely follow this
> thread. could you or
> joerg give us a short overview: what chipset and platform
> are we talking
ath_info gives:
sleep_ctl reg reset_ctl reg
-==Device Information==-
MAC Revision: 5213A (0x59)
Device type: 3
5GHz
On Friday 23 April 2010 22:05:34 Bob Copeland wrote:
> On Fri, Apr 23, 2010 at 09:14:04AM +0900, Bruno Randolf wrote:
> > On Thursday 22 April 2010 17:42:39 Joerg Pommnitz wrote:
> > > Bob,
> > > I just tested a recent wireless-testing snapshot. Unfortunately the
> > > problem still persists.
> > >
On Fri, Apr 23, 2010 at 09:14:04AM +0900, Bruno Randolf wrote:
> On Thursday 22 April 2010 17:42:39 Joerg Pommnitz wrote:
> > Bob,
> > I just tested a recent wireless-testing snapshot. Unfortunately the problem
> > still persists.
> > Please consider the following patch for inclusion. For me it mak
Bruno Randolf writes:
>
> sorry, i have to object! if this patch goes in, it will be less likely that
> anyone cares enough to find a real solution, so this is not good.
>
> we have to find out which part of reset fails and fix the problem there.
>
> bruno
Bruno,
I understand and partially sh
On Thursday 22 April 2010 17:42:39 Joerg Pommnitz wrote:
> Bob,
> I just tested a recent wireless-testing snapshot. Unfortunately the problem
> still persists.
> Please consider the following patch for inclusion. For me it makes the
> difference between "freezes in minutes" and "works stable". I kn
Bob,
I just tested a recent wireless-testing snapshot. Unfortunately the problem
still persists.
Please consider the following patch for inclusion. For me it makes the
difference between "freezes in minutes" and "works stable". I know it's at
best a workaround and at worst a bad hack, but until th
On Thu, Mar 25, 2010 at 4:53 AM, Joerg Pommnitz wrote:
> From 3) and 4) I would conclude the bug is more likely to trigger when the
> card is both, sending *AND* receiving. Does this narrow the problem down?
That sounds like a good clue. I have some time today
and a few cards, let me see if I ca
Bob,
there are some new data points to help narrowing down the cause of the bug.
1) Bruno's ANI patches are *not* to blame. I can reproduce the bug with or
without the ANI patches applied.
2) Your patches from Bug 14342 do *not* solve the problem. I can reproduce
the error with or without yo
Bob,
a recent wireless-testing kernel with both of your patches from Kernel Bug
#14342 run for two days now without the failed reset error message.
However, different from my previous tries I did not include Bruno's ANI
patch, so the success might be either because of your patchset or the
omission
On Mon, Mar 22, 2010 at 7:35 AM, Joerg Pommnitz wrote:
>> Wrt to my workaround patches -- if you could try the first
>> one as
>> well which has to do with concurrent calibration, that
>> would be a useful
>> data point.
>
> Bob,
> look at this:
> ~/system/wireless-testing$ grep -e SMP -e PREEMPT
> Wrt to my workaround patches -- if you could try the first
> one as
> well which has to do with concurrent calibration, that
> would be a useful
> data point.
Bob,
look at this:
~/system/wireless-testing$ grep -e SMP -e PREEMPT .config
CONFIG_BROKEN_ON_SMP=y
# CONFIG_TREE_PREEMPT_RCU is not set
> Wrt to my workaround patches -- if you could try the first
> one as
> well which has to do with concurrent calibration, that
> would be a useful
> data point.
>
> --
> Bob Copeland %% www.bobcopeland.com
Bob,
I run your second patch ("[PATCH] ath5k: pray to the cargo cult" from
18 Mar 2010) o
On Fri, Mar 19, 2010 at 08:43:54AM -0700, Joerg Pommnitz wrote:
> Bob,
> to identify the problem I had a printk in ath5k_hw_register_timeout
> printing the remaining loops. Normally it took only very few loops
> for the register to change to the target value (loops remaining in the
> range of 2
--- Bob Copeland schrieb am Fr, 19.3.2010:
> If you get a chance I would like to know if my workarounds
> also work.
> I'm trying to figure out the underlying problem with this
> and it would
> be a nice clue. Not all hardware can replicate these
> problems.
Bob,
I'm right now running your worka
let it over the weekend.
--
Regards
Joerg
--- Bob Copeland schrieb am Fr, 19.3.2010:
> Von: Bob Copeland
> Betreff: Re: [ath5k-devel] ATH5K in AP mode and "ath5k phy0: failed to warm
> reset the MAC Chip" errors
> An: "Joerg Pommnitz"
> CC: ath5k-devel@
On Fri, Mar 19, 2010 at 01:58:22AM -0700, Joerg Pommnitz wrote:
> Bob,
> I have cooked up a workaround myself. With the following patch applied
> I have been running iperf with good performance for over 20 hours now
> without interruption).
>
> And yes, the debug log was triggered quite often:
S
hrieb am Do, 18.3.2010:
> Von: Bob Copeland
> Betreff: Re: [ath5k-devel] ATH5K in AP mode and "ath5k phy0: failed to warm
> reset the MAC Chip" errors
> An: "Joerg Pommnitz"
> CC: ath5k-devel@lists.ath5k.org
> Datum: Donnerstag, 18. März, 2010 20:22 Uhr
> On
On Wed, Mar 17, 2010 at 5:57 AM, Joerg Pommnitz wrote:
> My suspiction is, that the reset fails as long as somebody keeps a
> reference to the interface open (either hostapd or dhcpd).
>
> Attached is a log file.
I'm not sure what you mean by keeping a reference open.
We do resets all the time wh
Hello all,
I gave Bruno's recent patches (including ANI) a try and was pleasantly
surprised that I got AP mode working for the first time.
Unfortunately all is not well, yet. After some time of heavy use I get the
error message from the subject. Heavy use means TCP iperf with ath5k
running on t
19 matches
Mail list logo
