AR6000 netif_queue_stop non stop, Bug?

[Ivan Petrov]

Hi Werner,

----- Original Message ----- 
From: "Werner Almesberger"
To: "Ivan Petrov"
Cc: <openmoko-kernel at lists.openmoko.org>
Sent: Friday, March 27, 2009 5:04 PM
Subject: Re: AR6000 netif_queue_stop non stop, Bug?

>
> Ivan Petrov wrote:
>> Changed: prevent rescheduling network queue at interface 
>> opened/connected.
>
> Why is this a problem ?
This is no problem, simle i think it not right start Queue and call 
rescheduling, when Queue not have actual data. If I not right, always 
posible remove it.

>> Removed: wake network queue at transmit complete.
>> Added: wake network queue at packet queue limit not reached.
>
> Thanks a lot ! The logic of your patch looks quite good and I like
> it that you eliminated the redundant arNetQueueStopped mechanism.
> What I haven't quite understood yet is why the old logic didn't work.
> Or was the problem you hit a race condition ?
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009643.html
I put this post yesterday, why it not in thread, i not know.
On old logic I have problems, netif_queue_stop realy not stop tx_queue. I 
make stress test for transmit, multiply UDP packets 32k size.

Btw, on my original sources, queue length reducted to 1, and all load lay on 
Kerner queue. But I remove it from patch, becouse not know how it will work 
on control endpoint.

> Also,
>
> +static void ar6000_tx_queue_avail(void *Context, HTC_ENDPOINT_ID 
> Endpoint)
> [...]
> +        if (((ar->arConnected == TRUE) || (bypasswmi))
> +         && netif_queue_stopped (ar->arNetDev)) {
> +            netif_wake_queue (ar->arNetDev);
> +        }
>
> Why not simply
>
> if ((ar->arConnected == TRUE) || (bypasswmi))
> netif_wake_queue(ar->arNetDev);
>
> ? (Minus the Pascalian parentheses, of course.)
Soryy, not fully read Kernel source :) of course rescheduling not will call 
on waked queue, you are right

>> I have transfer speed limit, from Dev board APP to network,
>> 760-800kbytes/sec (6.0 - 6.4 mbit/sec) on AT91SAM9260, and can't
>> understand - it limit of card, driver, or it limit of AT91SAM9260...
>
> That's roughly what I got as well. My test framework is described
> here:
>
> http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009549.html
>
> Does your SDIO driver support the SDIO interrupt or does it fall back
> to polling ? The latter may limit performance. (However, let me add
> that also Samuel's driver for the original Atheros SDIO stack that
> does SDIO interrupts and even DMA is only marginally faster than what
> we have now.)

Driver stop interrupt retriving after multi-block transfer :-(
I alpply patch for AT91 host contorller, now it depended at clockwork.

==================
diff -urN linux-2.6.28.8.orig/drivers/mmc/host/at91_mci.c 
linux-2.6.28.8/drivers/mmc/host/at91_mci.c
--- linux-2.6.28.8.orig/drivers/mmc/host/at91_mci.c 2009-03-17 
03:50:03.000000000 +0300
+++ linux-2.6.28.8/drivers/mmc/host/at91_mci.c 2009-03-22 01:08:53.000000000 
+0300
@@ -1007,7 +1007,7 @@
  mmc->f_min = 375000;
  mmc->f_max = 25000000;
  mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
- mmc->caps = MMC_CAP_SDIO_IRQ;
+ mmc->caps = 0; // MMC_CAP_SDIO_IRQ;

  mmc->max_blk_size = 4095;
  mmc->max_blk_count = mmc->max_req_size;
==================

--
Regards, Ivan.