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. What am I missing? Many thanks, Cheers, -FG > > >> What looks strange to me is that, if the error is somewhere in the >> tx_header definition, every transmission will result in an error from >> the b43_dma_handle_txstatus. If a field is not in the correct >> position, it is always wrong: it can't be sometimes right and >> sometimes wrong, don't you agree? >> I had similar problem beacause of the wrong header offsets >> definitions, but that made every transmission generate a BUG >> report... >> I don't understand how it is possible that almost always things went >> fine and sometimes report status was not correct... > > Well, you should probably patch the driver to print the cookie when > the WARN_ON happens > and reproduce. > >> Please Michael, if you can, can you please check shm.inc header >> definition? > > Not yet. Maybe later. > > > -- > Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
