* Simon Wunderlich [19.09.2012 11:25]:
> just to bump again - isn't there anyone who can give us some hint or
> clue regarding these 0xdeadbeef entries in the registers? Couldn't find
> a connection to other reports deadbeef on the mailing list so far.
it doesnt make sense to debug such an old fi
Did this mean we need poll something when do the external reset?
I check the https://dev.openwrt.org/changeset/27083,found it's check the
AR933X_BOOTSTRAP_EEPBUSY when do reset,but the latest code have remove it.
2012/8/24 Gabor Juhos
> 2012.08.23. 11:28 keltezéssel, Simon Wunderlich írta:
> > H
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
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 wh
Shafi,
On Mon, Sep 03, 2012 at 07:23:26PM +0530, Mohammed Shafi wrote:
> seems we are getting beacon stuck, though its not sufficient for triggering
> chip reset (or) atleast start noise floor calibration. Is this is in a
> congested
> environment ? we can dump cycle counters . I think we need to
Hey guys,
now, finally after approx. 9 days the problem hit us again, this time with
debug enabled.
The symptoms are the same as described before. I'm pasting part of the syslog
of routers
200 and 201 where the calibrating output changes - this is the only thing I
could find
which was really d
2012.08.23. 11:28 keltezéssel, Simon Wunderlich írta:
> Hello Adrian,
>
> thanks for your comments!
>
> On Wed, Aug 22, 2012 at 11:57:04AM -0700, Adrian Chadd wrote:
>> Yeah. The deadbeef means "something's turned off."
>>
>> I'd start with the SoC reset register and see if the MAC/WMAC bits are
Hello Adrian,
thanks for your comments!
On Wed, Aug 22, 2012 at 11:57:04AM -0700, Adrian Chadd wrote:
> Yeah. The deadbeef means "something's turned off."
>
> I'd start with the SoC reset register and see if the MAC/WMAC bits are
> correctly set. Ie, that something hasn't gone and reset the wire
Hi Simon:
I think you need creat a ticket at OpenWrt,which trunk revison code do you
use?
I have a wr703n(ar9331) and also have some stable issue(stops beaconing)
,but i did not do any debug yet.
Mips
2012/8/20 Simon Wunderlich
> Hello,
>
> just to bump again - isn't there anyone who can give
Hello,
just to bump again - isn't there anyone who can give us some hint or
clue regarding these 0xdeadbeef entries in the registers? Couldn't find
a connection to other reports deadbeef on the mailing list so far.
Thanks!
Simon
On Mon, Aug 13, 2012 at 06:53:40PM +0200, Simon Wunderlich
10 matches
Mail list logo
