| Message ID | 56E28B5D.6000708@st.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On 11 March 2016 at 10:09, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote: > On 3/10/2016 5:47 PM, Dinh Nguyen wrote: >> >> On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO >> <peppe.cavallaro@st.com> wrote: >>> >>> On 3/9/2016 5:31 PM, Dinh Nguyen wrote: >>>> >>>> >>>> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO >>>> <peppe.cavallaro@st.com> wrote: >>>>> >>>>> >>>>> Hi Tomeu, Dinh, Andreas >>>>> >>>>> I need a sum and help from you to go ahead on the >>>>> tx timeout. >>>>> >>>>> The "stmmac: MDIO fixes" seems to be the candidate to >>>>> fix the phy connection and I will send the V2 asap (Andreas' comment). >>>>> >>>>> So, supposing the probe is ok and phy is connected, >>>>> I need your input ... >>>>> >>>>> Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame >>>>> prep at the end of xmit routine) the network is >>>>> not stable and there is a timeout after a while. >>>>> The box has 3.50 with normal desc settings. >>>>> >>>>> Dinh: the network is ok, I wonder if you can share a boot >>>>> log just to understand if the normal or enhanced >>>>> descriptors are used. >>>>> >>>> >>>> Here it is: >>> >>> >>> ... >>>> >>>> >>>> [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 >>>> [ 0.855570] Ring mode enabled >>>> [ 0.858611] DMA HW capability register supported >>>> [ 0.863128] Enhanced/Alternate descriptors >>>> [ 0.867482] Enabled extended descriptors >>>> [ 0.871482] RX Checksum Offload Engine supported (type 2) >>>> [ 0.876948] TX Checksum insertion supported >>>> [ 0.881204] Enable RX Mitigation via HW Watchdog Timer >>>> [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode >>>> found >>>> [ 0.899090] libphy: stmmac: probed >>>> [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active >>> >>> >>> >>> Thx Dinh, so you are using the Enhanced/Alternate descriptors >>> I am debugging on my side on a setup with normal descriptors, I let you >>> know >>> >> >> Doesn't the printout "Enhanced/Alternate descriptors" mean that I'm using >> Enhanced/Alternate descriptors? > > > yes this means that you have the Databook 3.70a and, from the HW > capability register, the driver will use the Enhanced/Alternate > descriptors. This is the same HW I am using on my side where the > stmmac is working fine. > > In the case where it is failing on net-next, although on Databook 3.50a, > the HW capability register says that there is no enhanced descriptors > and the driver uses the normal ones. > > Tomeu, I kindly ask you to try the patch attached. I found a bug on Tx > path for normal descriptors. Please let me know if this help. > Also let me know if we actually need to revert the 0e80bdc9a72d. Hi Peppe, with that patch I don't see any difference at all in my setup. So to be clear, with these commits on top of next-20160314, I still get the hang during boot: 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine" b5e08e810c63 stmmac: fix tx prepare for normal desc 37c15a31d850 i2c: immediately mark ourselves as registered 4342eec3c5a2 Add linux-next specific files for 20160314 [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x284/0x288 [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2 > I am trying to find some HW where test the normal descriptors to > speed-up the tests on my side directly. Maybe get your tree in kernelci.org? I'm not sure if it's currently doing any nfsroot boots, though. Regards, Tomeu > Let me know and thx in advance. > > Regards, > Peppe > >> >> Dinh >> >
Hi Tomeu On 3/14/2016 12:43 PM, Tomeu Vizoso wrote: > Hi Peppe, > > with that patch I don't see any difference at all in my setup. > > So to be clear, with these commits on top of next-20160314, I still > get the hang during boot: > > 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node > 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine" > b5e08e810c63 stmmac: fix tx prepare for normal desc > 37c15a31d850 i2c: immediately mark ourselves as registered > 4342eec3c5a2 Add linux-next specific files for 20160314 > > [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 > dev_watchdog+0x284/0x288 > [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out I do not reproduce the WATCHDOG but i am continuing to look at the code to understand if normal descriptor management is ok or not. I keep you informed. Just an info, did you test with 2315acc6cf7f included? Just to understand if it is introducing a problem. It works in case of enhanced descriptors are used instead of. > > https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2 thx I will take a look at this Regards Peppe
On 14 March 2016 at 17:20, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote: > Hi Tomeu > > On 3/14/2016 12:43 PM, Tomeu Vizoso wrote: >> >> Hi Peppe, >> >> with that patch I don't see any difference at all in my setup. >> >> So to be clear, with these commits on top of next-20160314, I still >> get the hang during boot: >> >> 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node >> 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine" >> b5e08e810c63 stmmac: fix tx prepare for normal desc >> 37c15a31d850 i2c: immediately mark ourselves as registered >> 4342eec3c5a2 Add linux-next specific files for 20160314 >> >> [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 >> dev_watchdog+0x284/0x288 >> [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 >> timed out > > > I do not reproduce the WATCHDOG but i am continuing to look at the code > to understand if normal descriptor management is ok or not. I keep you > informed. > > Just an info, did you test with 2315acc6cf7f included? Just to > understand if it is introducing a problem. It works in case of > enhanced descriptors are used instead of. > >> >> >> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2 > > > thx I will take a look at this Thanks. Btw, I have rebased on top of 4.5 this morning and I have noticed that 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in there, so I guess we have now a bunch of boards with broken network on that release :( Regards, Tomeu > Regards > Peppe > >
From ed3e38befc5500e05f46e1d52ea20a0b8d3829f3 Mon Sep 17 00:00:00 2001 From: Giuseppe Cavallaro <peppe.cavallaro@st.com> Date: Thu, 10 Mar 2016 14:57:48 +0100 Subject: [PATCH (linux-sti-4.1)] stmmac: fix tx prepare for normal desc This patch fixes a bug inside when use the normal descriptors. While preparing the tx descriptor the frame size was not properly set. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> --- drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c index e13228f..432b3f1 100644 --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c @@ -197,13 +197,15 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, bool csum_flag, int mode, bool tx_own, bool ls) { - unsigned int tdes1 = p->des1; + unsigned int tdes1; if (mode == STMMAC_CHAIN_MODE) norm_set_tx_desc_len_on_chain(p, len); else norm_set_tx_desc_len_on_ring(p, len); + tdes1 = p->des1; + if (is_fs) tdes1 |= TDES1_FIRST_SEGMENT; else -- 1.7.4.4