netdev - Re: [PATCH net-next 5/7] net:fec: add support for dumping transmit ring on timeout

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140429143828.GB26756@n2100.arm.linux.org.uk>
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