On Sunday 01 February 2009 00:47:35 Michael Buesch wrote: > On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote: > > On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: > > > > > On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: > > >>> I think that's rather unlikely, however. The DMA code is basically > > >>> unchanged > > >>> for months and especially the slot handling hasn't changed in years. > > >>> > > >> > > >> Yes, but I didn't mean that the code has some bug. Let's say, for > > >> example, that all the DMA slots were filled; when the firmware will > > >> try to report a tx status it will send the informations to the DMA. > > >> The DMA won't have enough space to store it and so it will drop the > > >> message. In your opinion is it possible that something like that > > >> happened? > > > > > > No. TX status isn't passed through DMA in >=rev5 cores. > > > It's passed through MMIO registers which access an internal hardware > > > queue. > > Michael, > > > > sorry, I have a question, there is a piece of code I do not > > understand. I see from specs that this queue (that is filled by the > > firmware to report status to host) _seems_ to be 16 positions long. I > > would say that this value should be taken as an upper limit in the > > number of frames sent on the dma and still not acked (positively or > > not, depending on tx success) by the firmware. Is this correct? I did > > some tests and I saw that the number of frames sent through > > op32_poke_tx before corresponding status being reported greatly > > exceeds 16. > > The driver just puts the stuff into the DMA ring. It can put as much stuff > into the ring as it wants, as it allocated the ring. > > The _firmware_ must make sure to accept new packets from dma _only_ if > its buffers are not filled. That includes the tx status report buffer.
The tx-status-queue-full condition most likely is an external condition in the firmware. Don't ask me which one, however. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
