On Sunday 01 February 2009 16:58:33 Larry Finger wrote: > Michael Buesch wrote: > > > > 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... :) > > > > Now that I'm not crashing Linux when it happens, I know a little more > about what happens. My last test with 5.1 firmware ran nearly 7 hours > before it died. At that point, ifconfig reported 25,407,000 packets > received for a total of 1,944 MB, and 36,843,000 packets transmitted > for a total of 596 MB. Those numbers for the MB transferred are not > what I expected - the flood ping should TX and RX equal numbers of > small packets, and the tcpperf run should TX large packets and RX only > ACKs. > > In my latest run, I froze the TX queue when the first error occurred. > When that happened, there were still 6 more entries in the TX queue. > The cookies were all in the same sequence: 0x204A, 0x204E, 0x2050, > 0x2052, 0x2054, 0x2056, and 0x205A. What happened to 0x2058?
And 4C The DMA implementation requires slots on one DMA queue to be reported in the correct sequencial order. And it also requires them all to be reported. Otherwise the slot counts (used_slots, current_slot) go wrong. If you don't keep the strict order it will result in memory leaks and/or double-frees. The double-free is detected by the BUG_ON in question. There's no leak detection, so it will silently leak. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
