On Sunday 01 February 2009 12:24:23 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. > Well, the handler that reports status to host waits for a couple of > external conditions, looping until they are satisfied: we left that > about crypto because all times we removed something about crypto > everything went bad, even if it seemed useless, do not consider it > now. The other condition, instead, is the same that is checked before > sending a received frame to host through _dma_, isn't it strange? > There is no conditioning instead that prevents the IRQ about tx status > reporting to be raised once we entered the reporting handler, and we > jump into it after each sending. So each time we enter the report > status handler, the IRQ is raised. So I think that the conditions you > are talking can only be those two I said here above, no other bit is > checked, and your bet was right :)
I think you're looking at the wrong place. The check for the tx status queue must be a _lot_ earlier. It must be even before we route the frame from the DMA engine to the TXE. I bet it's one of the very first conditions that start the TX operation. The basic idea is that we must check all buffers, including the tx status report buffer, before we start the TX operation. Because if we started it and we notice right in the middle of the operation that we lack bufferspace somewhere, we're screwed. That's my theory. I cannot back it up with facts, but it sounds sane to me. But, why do we talk about this, actually? Do we actually know what went wrong, yet? Larry, did you dump a cookie of a frame that would trigger the crash? What does the ring memory allocation look like at the time the crash would trigger? Are there holes in the ring memory? What does the crashing cookie point to? The end of the ring (aprox) or somewhere completely different. printk printk printk printk... :) -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
