On Sunday 01 February 2009 12:25:20 Francesco Gringoli wrote: > > 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
Yes it is. You need two slots per data packet. > 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? Well I'm not completely sure what's going on exactly. I only know that we get bad cookies that the driver doesn't expect. > It seems that the firmware is reporting status for not all > packets that have been sent through the dma, Whoopsy, it is _required_ to report status for every single packet. That's a basic assumption that must not be violated, as it's used for freeing the DMA memory in the driver. However, it should not corrupt anything. It will just grind the DMA to a halt 64 packets after a status report was missed. I never tried this, however. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
