[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201009111154.42171.caglarakyuz@gmail.com>
Date: Sat, 11 Sep 2010 11:54:41 +0300
From: Caglar Akyuz <caglarakyuz@...il.com>
To: cyril@...com
Cc: Michael Williamson <michael.williamson@...ticallink.com>,
Kevin Hilman <khilman@...prootsystems.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davinci-linux-open-source@...ux.davincidsp.com"
<davinci-linux-open-source@...ux.davincidsp.com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
On Friday 10 September 2010 06:23:52 pm Caglar Akyuz wrote:
> On Friday 10 September 2010 12:25:40 am Michael Williamson wrote:
> > Hi Cyril,
> >
> > On 09/09/2010 03:51 PM, Cyril Chemparathy wrote:
> > > Hi Mike,
> > >
> > > [...]
> > >
> > >> The hang is in wait_for_user_access() in the davinci_mdio_read() call.
> > >> Looks like the state machine got put back into IDLE somewhere between
> > >> the MDIO probe and the EMAC probe. Seems like there should be some
> > >> sort of time-out and error message in the wait_for_user_access()
> > >> method.... (maybe even a check for IDLE??)
> > >>
> > >> If I add a patch to check the state machine for IDLE and then
> > >> re-enable it in the davinci_mdio_read() call, it is able to press on
> > >> and come up. I don't see any calls to the davinci_mdio_suspend() call,
> > >> so I am wondering if the EMAC probe routine, particularly the
> > >> application of the SOFTRESET, is causing the MDIO to drop back to IDLE
> > >> / disabled.
> > >>
> > >> I can post the patch if you like, but it is a bit of a hack...
> > >
> > > An EMAC soft-reset clobbering the MDIO controller state is a
> > > possibility. I will poll TI designers to see if this could be the
> > > case.
> > >
> > > In any case, a couple of unanswered questions remain:
> > >
> > > 1. Why don't other davinci devices display similar behavior?
> > >
> > > 2. If the answer to #1 above is that the timing window is pretty slim
> > > (i.e., only if an MDIO read/write is in progress during EMAC
> > > soft-reset), why do we hit this situation consistently on
> > > mityomap?
> >
> > Has it been confirmed that this only happens on mityomap? Has anyone had
> > success using a da850 evm or other da850 platform? The configuration
> > for
>
> Same problem exists on another DA850 board, Hawkboard.(Sorry no support in
> mainline yet)
>
> > the mityomap, wrt to the EMAC/MII/MDIO, is pretty much identical to the
> > da850 evm using the MII interface. The only difference I am aware of is
> > the assigned address to the PHY chip. The reference clocks and rates
> > are identical, AFAIK, to the evm.
> >
> > > I have put together a quick patch (tested dm365). See attached.
> >
> > Your patch doesn't work with my board. It does attempt to reset the bus
> > on
>
> This patch fixes the problem here. I'm using kernel IP auto configuration
> and mounting fs over NFS. My system boots and I can login to my board.
>
> Regards,
> Caglar
>
Unfortunately emac driver is not stable after this series. I face lock-ups
time to time, followed by attached kernel trace.
Regards,
Caglar
_________________________________________________________________
[ 1651.440000] nfs: server 192.168.2.34 not responding, still trying
[ 1859.010000] ------------[ cut here ]------------
[ 1859.010000] WARNING: at net/sched/sch_generic.c:258
dev_watchdog+0x184/0x294()
[ 1859.020000] NETDEV WATCHDOG: eth0 (davinci_emac): transmit queue 0 timed
out
[ 1859.020000] Modules linked in:
[ 1859.030000] Backtrace:
[ 1859.030000] [<c0030444>] (dump_backtrace+0x0/0x10c) from [<c02d9820>]
(dump_stack+0x18/0x1c)
[ 1859.040000] r7:c03b5de8 r6:c025a13c r5:c039045c r4:00000102
[ 1859.040000] [<c02d9808>] (dump_stack+0x0/0x1c) from [<c0042e44>]
(warn_slowpath_common+0x58/0x70)
[ 1859.050000] [<c0042dec>] (warn_slowpath_common+0x0/0x70) from [<c0042f00>]
(warn_slowpath_fmt+0x38/0x40)
[ 1859.060000] r8:c03b4000 r7:00000030 r6:c0437564 r5:c7bbc000 r4:00000000
[ 1859.070000] [<c0042ec8>] (warn_slowpath_fmt+0x0/0x40) from [<c025a13c>]
(dev_watchdog+0x184/0x294)
[ 1859.080000] r3:c7bbc000 r2:c0390474
[ 1859.080000] [<c0259fb8>] (dev_watchdog+0x0/0x294) from [<c004e918>]
(run_timer_softirq+0x1c4/0x29c)
[ 1859.090000] [<c004e754>] (run_timer_softirq+0x0/0x29c) from [<c0048b94>]
(__do_softirq+0x98/0x12c)
[ 1859.100000] [<c0048afc>] (__do_softirq+0x0/0x12c) from [<c0048c70>]
(irq_exit+0x48/0x9c)
[ 1859.110000] [<c0048c28>] (irq_exit+0x0/0x9c) from [<c002c080>]
(asm_do_IRQ+0x80/0xa0)
[ 1859.120000] [<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb2c>]
(__irq_svc+0x4c/0x9c)
[ 1859.120000] Exception stack(0xc03b5f38 to 0xc03b5f80)
[ 1859.130000] 5f20:
00000000 0005317f
[ 1859.140000] 5f40: 0005217f 60000013 c03b4000 c03b8ba0 c03b89d4 c03dcc50
c0023e04 41069265
[ 1859.150000] 5f60: c0023d94 c03b5f8c 600000d3 c03b5f80 c002da6c c002da78
60000013 ffffffff
[ 1859.150000] r5:febfd000 r4:ffffffff
[ 1859.160000] [<c002da48>] (default_idle+0x0/0x34) from [<c002dff0>]
(cpu_idle+0x74/0xdc)
[ 1859.170000] [<c002df7c>] (cpu_idle+0x0/0xdc) from [<c02d59d4>]
(rest_init+0xa4/0xbc)
[ 1859.170000] r7:c03b89c8 r6:c0026018 r5:c03dcc1c r4:00000002
[ 1859.180000] [<c02d5930>] (rest_init+0x0/0xbc) from [<c0008bc4>]
(start_kernel+0x270/0x2d0)
[ 1859.190000] r4:c042d70c
[ 1859.190000] [<c0008954>] (start_kernel+0x0/0x2d0) from [<c0008034>]
(__enable_mmu+0x0/0x2c)
[ 1859.200000] r6:c002641c r5:c03dcc78 r4:00053175
[ 1859.200000] ---[ end trace d278f645c502dc20 ]---
--
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