lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Apr 2014 15:38:28 +0100 From: Russell King - ARM Linux <linux@....linux.org.uk> To: David Laight <David.Laight@...LAB.COM> Cc: 'Frank Li' <lznuaa@...il.com>, Frank Li <Frank.Li@...escale.com>, "shawn.guo@...aro.org" <shawn.guo@...aro.org>, "B38611@...escale.com" <B38611@...escale.com>, "davem@...emloft.net" <davem@...emloft.net>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [PATCH net-next 5/7] net:fec: add support for dumping transmit ring on timeout On Tue, Apr 29, 2014 at 02:23:09PM +0000, David Laight wrote: > From: Frank Li [mailto:lznuaa@...il.com] > > On Tue, Apr 29, 2014 at 9:01 AM, David Laight <David.Laight@...lab.com> wrote: > > > From: Frank ... > > >> > You probably want the read and write indexes as well. > > >> > > >> bdp == fep->cur_tx ? 'S' : ' ', > > >> bdp == fep->dirty_tx ? 'H' : ' ', > > >> > > >> Above code already print read and write index. 'S', 'H' > > > > > > Gah I must be asleep! > > > Something made be think that was to do with the ring ownership bit! > > > > I think it is same thing. If I am wrong, please tell me difference. > > The ownership bit in the ring flags - that the hardware uses. > Which are printed in the next field. > > I'm guessing that the reason the tx ring is 'interesting' is that there > have been bugs where the driver and hardware disagree about which entry > each should process next. > Otherwise the full tx ring is likely to be very very boring. There have been several bugs. One is where the ring is completely owned by software (because all the entries have been transmitted) but the driver is buggy and hasn't reaped the ring at all, leading to a tx timeout. The second one is where the ring appears to be completely full, because the hardware hasn't been transmitting for various reasons (eg, there are bugs in the way the transmitter is started.) The third one is where the transmitter skips a ring entry on earlier iMX hardware. However, those are specific bugs. The point of dumping the whole ring is to allow bugs to be diagnosed, because we can then see the state of the ring, and start looking for likely causes of the symptoms that are visible. With the driver as it currently is, the only thing we know is "oops, the transmit seemed to stop for some reason" and we hope that resetting the device gets it going again - after many seconds of it being non-responsive. This is how I've sorted out many issues with this driver. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists