Re: [Acx100-devel] Testing new acx code

[Oliver W. <oli...@ol...>]

Hello Rasjid,

What we could try out, is to put back the radio recalib, 
which is currently deactivated (see below). 

... I'll see to put this back in the coming days.

Cheers, Ol

common.c
---
	/* we see lotsa tx errors */
	if (adev->after_interrupt_jobs & ACX_AFTER_IRQ_CMD_RADIO_RECALIB) {
		printk("acx: too many TX errors?\n");
		printk("acx: %s: TODO: ACX_AFTER_IRQ_CMD_RADIO_RECALIB\n", __func__);
//		acx_s_after_interrupt_recalib(adev);
	}
---

pci.c
---
	case 0x20:
		err = "excessive Tx retries due to either distance "
		    "too high or unable to Tx or Tx frame error - "
		    "try changing 'iwconfig txpower XXX' or "
		    "'sens'itivity or 'retry'";
/*		adev->wstats.discard.retries++; */
		/* Tx error 0x20 also seems to occur on
		 * overheating, so I'm not sure whether we
		 * actually want to do aggressive radio recalibration,
		 * since people maybe won't notice then that their hardware
		 * is slowly getting cooked...
		 * Or is it still a safe long distance from utter
		 * radio non-functionality despite many radio recalibs
		 * to final destructive overheating of the hardware?
		 * In this case we really should do recalib here...
		 * I guess the only way to find out is to do a
		 * potentially fatal self-experiment :-\
		 * Or maybe only recalib in case we're using Tx
		 * rate auto (on errors switching to lower speed
		 * --> less heat?) or 802.11 power save mode?
		 *
		 * ok, just do it. */
---


On 03/07/2010 01:30 AM, Rasjid Wilcox wrote:
> On 5 March 2010 06:42, Oliver Winker <oli...@ol...> wrote:
>> While doing this, you can also observe a bit what the Rx,Tx buffers of
>> the card are doing. There is an /prov/driver entry that gives
>> information on the internal state of the driver:
>>
>> cat /proc/driver/acx0/acx_diag
>>
>> You can see the buffer moving cyclically and animated like this:
>>
>> while true; do clear; cat /proc/driver/acx0/acx_diag |head -35; perl -e
>> "select(undef, undef, undef, 0.05);"; done
>>
> 
> There doesn't seem to be any issues with scanning or joining an access
> point, with the output of cat /proc/driver/acx/acx_diag | head -35
> jumping around as it should.
> 
> But part-way through a longer download it all stops.  The output at
> that point is:
> 
> Every 0.1s:  cat /proc/driver/acx0/acx_diag |head -35
>       Sun Mar  7 00:25:58 2010
> 
> ** Rx buf **
> 00 empty
> 01 empty [tail]
> 02 empty
> 03 empty
> 04 empty
> 05 empty
> 06 empty
> 07 empty
> 08 empty
> 09 empty
> 10 empty
> 11 empty
> 12 empty
> 13 empty
> 14 empty
> 15 empty
> 00 free (C0)
> 01 free (C0)
> 02 free (C0)
> 03 free (C0)
> 04 free (C0)
> 05 free (C0)
> 06 free (C0)
> 07 free (C0)
> 08 free (C0)
> 09 free (C0)
> 10 free (C0)
> 11 free (C0)
> 12 free (C0)
> 13 tx   (80) [head]
> 14 tx   (80)
> 15 free (C0) [tail]
> 
> ** PCI data **
> 
> where the [tail] on the Rx buf is still jumping around, but the head
> and tail in the tx part is no longer moving, and the entries are
> mostly free (C0) rather than tx.
> 
> Does this help at all?
> 
> Cheers,
> 
> Rasjid.
>