On Thu, 2012-11-22 at 22:39 +0100, Francois Romieu wrote:
Btw David W., could consider adding artificial delays between the
writes and see if / when things start to fail (CpCmd write in
cp_start_hw is an unflushed posted write for instance).
That's how I tracked it down to the CpCmd write. I littered the whole of
the init path with
printk("at line %d TxRingAddr %08x%08 (sb %08x)\n", __LINE__,
cpr32(TxRingAddr+4), cpr32(TxRingAddr), cp->ring_dma + whatever);
... until the output looked something like this:
root@geos:~# insmod ./8139cp.ko
[ 1331.492486] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[ 1331.500388] 8139cp 0000:00:0a.0: eth0: RTL-8139Cx at 0xd10a6000, 00:0a:fa:22:
00:96, IRQ 10
[ 1331.509608] 8139cp 0000:00:0b.0: eth1: RTL-8139Cx at 0xd10a8100, 00:0a:fa:22:
00:97, IRQ 11
root@geos:~# [ 1331.644393] at line 995 TxRingAddr 000000000f3c6400 (sb f3c6400)
[ 1331.650579] at line 960 TxRingAddr 000000000f3c6400 (sb f3c6400)
[ 1331.656820] at line 962 TxRingAddr 000000000f3e4400 (sb f3c6400)
[ 1331.663020] at line 964 TxRingAddr 000000000f3e4400 (sb f3c6400)
[ 1331.669205] at line 998 TxRingAddr 000000000f3e4400 (sb f3c6400)
[ 1331.675412] at line 1001 TxRingAddr 000000000f3e4400 (sb f3c6400)
[ 1331.681706] at line 1003 TxRingAddr 000000000f3e4400 (sb f3c6400)
[ 1331.687977] at line 1005 TxRingAddr 000000000f3e4400 (sb f3c6400)
Each of those printks will have effectively flushed any prior posted
writes... not that this AMD Geode platform actually *does* post writes,
to my knowledge. And at 115200 baud, each one was about a 6ms delay.
--
dwmw2