On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote: > On Sunday 01 February 2009 11:16:29 Michael Buesch wrote: > > If it's not an external condition, it could possibly also be a bit > in the TXE or something > like that. I'm not completely sure on that one. But external > condition would be my > first bet, as we have lots of other external conditions for other > overflow conditions.
For my understanding of what's going on with Larry's adapter, may I kindly ask you if the following picture is correct? I simply put a printk just at the top of op32_poke_tx and another in handle_irq_transmit_status. I injected as mush traffic as I can by sending UDP style frames through a raw socket to the wireless interface, I send ten thousands packets so to enter a "regime" condition: after the first hundreds packets are sent, I see from dmesg a op32_poke_tx line followed by a handle_irq_transmit_status line, these two couple of lines repeated thousands times. More interesting is what happens at the end when I stop sending packets on the raw socket: the kernel stops filling the queue, and in dmesg we can see only handle_irq_transmit_status lines corresponding to frames still in the tx fifo. The firmware is removing these last packets and for each of them it will send a IRQ after sending. It always turn out that the queue had 64 packets inside, I always see 64 consecutive lines about handle_irq_transmit_stats. Is this number (64) due to the definition #define B43_TXRING_SLOTS 128 in dma.h? For what I understand a slot is used for tx header, the other for the actual packet, isn'it? So we have half of 128 slots for 64 packets. If this is correct, the condition observed by Larry could be due to some packets being lost during their travel in the fifo run by the dma system? It seems that the firmware is reporting status for not all packets that have been sent through the dma, but we know that the firmware always reports status _unless_ the mac ctl register is set to skip status reporting. Could we investigate on this or I'm completely wrong? Cheers, -Francesco _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
