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? I'm pretty busy today with the "Super Bowl", but I'm going to start a long run with 5.0 firmware. My last run showed that the failure can take a long time and that my previous tests may have missed an error. Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
