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. > 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 Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
