Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #752 (assigned enhancement)

Opened 15 years ago

Last modified 15 years ago

"tx tasklet restart the queue" error message

Reported by: Thor Assigned to: mrenzmann (accepted)
Priority: minor Milestone:
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

When I try to send more than 350-400pkt/s (4-5Mbit/s, pkt len 1470bytes) I get many messages like this one:

"tx tasklet restart the queue" (hundreds of them...)

The result of this error is that I can't send more than 4-5Mbit/s with my atheros card.

The error is influenced by the number of the pkts/s I try to send.

I tried different cards, frequencies (2.4GHz 5GHz) but nothing change.

I'm using madwifi-ng r1683 with kernel 2.4.32 on x86. The device is configured in monitor mode.

Thor

Attachments

r1711-silent-queue-restart.patch (503 bytes) - added by mrenzmann on 09/15/06 03:41:38.
Make "tx queue restart" messages occur only when TX desc processing debug messages are enabled

Change History

07/15/06 17:26:37 changed by mrenzmann

  • version set to trunk.

07/15/06 23:20:30 changed by foodoc

how good is the link? (run iwconfig and post the output)

07/17/06 10:56:57 changed by Thor

The link is good, I'm testing two devices at 1m...with the old driver I get 15Mbit/s with same hardware and config. iwconfig is uneusefull in monitor mode, all value are 0.

I'm trying to read the code but it isn't so easy.

Thor

07/18/06 06:29:13 changed by mrenzmann

Try increasing the distance between the involved nodes. At distances of only 1m chances are that their receivers are overdriven, resulting in a very bad performance, lots of resents due to lost packets, and thus a low throughput.

07/18/06 17:04:40 changed by Thor

I tried also with devices at different distances (5-10 meters) but nothing changed. I also forced different modulation speeds, 6Mbit/s or 54Mbit/s. The resulting bandwith is always the same one: near 4 Mbit/s. I'm generating only UDP traffic to test the bandwith.

I can't understand the meaning of the error, If the device can't send pkts It should simply drop them. Why the tasklet restart the queue?

I tried to change the TX buffer 10 times bigger, now I don't get the error but I get the same bandwith limits.

Thor

07/20/06 12:55:35 changed by Thor

After many tests I found that the problem is in the modulation parameter passed to the driver in monitor mode. The driver modulated at only 6Mbit, my fault.

Just a suggestion: I'm working on a limited resouces system, like soekris, and all error messages "tx tasklet restart the queue" overflow the system and slow it down. Maybe is better to control the number of error messages.

I still can't understand why the error is generated, I have a queue before the driver that is pulled by the driver when it can handle a pkt. So if the device cannot send a pkt the driver shouldn't pull a pkt from the queue. Or not?

I think the ticket can be changed from defect to enhancement or closed.

Thor

09/14/06 22:18:58 changed by anonymous

does this error occur when you dont use wlanconfig to create a monitor mode device (i.e. only use iwconfig ath0 mode monitor and no wlanconfig ath0 destroy?) The reason i ask is because i heard that you could still inject packets in managed mode.

09/15/06 03:41:38 changed by mrenzmann

  • attachment r1711-silent-queue-restart.patch added.

Make "tx queue restart" messages occur only when TX desc processing debug messages are enabled

09/15/06 03:46:39 changed by mrenzmann

  • status changed from new to assigned.
  • summary changed from "tx tasklet restart the queue" error message and bandwidth limits. to "tx tasklet restart the queue" error message.
  • priority changed from critical to minor.
  • owner set to mrenzmann.
  • patch_attached set to 1.
  • type changed from defect to enhancement.

I attached a proposal patch that makes the mentioned message visible only in case that debugging messages for TX descriptor processing have been enabled (via athdebug -i ath0 +xmit_proc for example). However, probably other debugging flags would match better. Comments?

09/18/06 20:47:32 changed by anonymous

But doesn't this message mean that there is something wrong with the configuration? Have a look at the log:

Sep 18 20:02:19 mirissa kernel: tx tasklet restart the queue
Sep 18 20:02:50 mirissa last message repeated 70 times
Sep 18 20:03:51 mirissa last message repeated 90 times
Sep 18 20:04:40 mirissa last message repeated 25 times
Sep 18 20:06:15 mirissa last message repeated 25 times
Sep 18 20:06:42 mirissa last message repeated 84 times
Sep 18 20:06:42 mirissa kernel: ath_mgtstart: discard, no xmit buf
Sep 18 20:06:43 mirissa kernel: tx tasklet restart the queue
Sep 18 20:07:14 mirissa last message repeated 15 times
Sep 18 20:07:58 mirissa last message repeated 13 times

This messages were gone after restart, so I assume something got "improved". After this patch I would never know that something bad is happening, right?