Hi Werner,
----- Original Message -----
From: "Werner Almesberger"
To: "Ivan Petrov"
Cc: <[email protected]>
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.
