Dai, > I am not so sure about your PHY, but if you access to PHY while packet > transmission through MDIO bus, the packet might be corrupted. Do you > have "phy_interrupt" in the /proc/interrupts? What is your dmesg around > the eTSEC look like (there is phy driver info surrounded).
With some printks, I did confirm that the kernel is polling the phy every second or so. So, I modified the routine which reads the phy status to hardcode the link state, speed, and duplex without actually performing any reads and the driver still bug checks with a truncated packet. I also dropped a printk in phy_read() and phy_write(), but neither function is getting called with the hard-coded link information. In gfar_clean_tx_ring() I printed out the tx descriptor data length field when I detected that the descriptor had the TR bit set. For 5 bug checks in a row, the data length field was set to 1960 (which would definitely cause the packet truncation). I then went back into gfar_start_xmit() and added some additional BUG_ON() checks of the data length field before the descriptor is handed off to the TSEC and none of them fire. I am wondering if somehow the descriptor is getting corrupted, perhaps by some code with an errant pointer. Scott ___________________________________________________________________ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A. Web: http://www.cyclone.com ___________________________________________________________________ _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
