From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8671C43381 for ; Thu, 7 Mar 2019 05:32:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A743820652 for ; Thu, 7 Mar 2019 05:32:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726264AbfCGFcd (ORCPT ); Thu, 7 Mar 2019 00:32:33 -0500 Received: from mail-oi1-f181.google.com ([209.85.167.181]:46331 "EHLO mail-oi1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726024AbfCGFcd (ORCPT ); Thu, 7 Mar 2019 00:32:33 -0500 Received: by mail-oi1-f181.google.com with SMTP id j10so11927208oij.13 for ; Wed, 06 Mar 2019 21:32:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8F9go8xzjjybIZK09hxVT12Gb5puwJp58leogTvC0wI=; b=k6k7ys4CSi9lxJQRqQtPmtQ16vlPpUW61pt8WOnt2qAaXHpKWF1SP7ozJYOSncKdEc 8NfF5r0C7dJEdOyzE25YxJePDZjRngzBZ5UhXRs/3DZu2S8s9HmvNulVX8IFzh8TII8q WA+NVt0TwPxaWPZ0A7xGOvdGx6TBOJ3RhFSjjmAe3Ws7UyOLp8casOpsi4m8wR2w1iCg Mv0KY4MPFUPs9cwFeLHJT+FdOt1hLCMF0/RMBhjopXymlQE++507wb5K70JEgLIDEJ9H KRmQEJV9fBmvexePa3wPGPqg+jFvG+HL/tBrrpnIIY/wVgxZA2w8iTMLr34qmy6CSNcg KZNQ== X-Gm-Message-State: APjAAAXP3GTQaC/1VLIEtELemXbFPms0+3Xp4vkw7BCuBkWmaF3RM2Mq UVAYsaXFS1n8fNK+cPlhkf2umDHn9iMkWbdX4m4= X-Google-Smtp-Source: APXvYqxAepzK6vxe0VRTPKDT8v5G9GxJvvl0fb5NnbKSH6LTwfq6k6Iou4xQt7Xmx1v3OVdMi0G3IkeZW4c/UT19FOM= X-Received: by 2002:aca:c085:: with SMTP id q127mr4048132oif.27.1551936752015; Wed, 06 Mar 2019 21:32:32 -0800 (PST) MIME-Version: 1.0 References: <20190228185758.6f37i2sfnr2mdrce@localhost> In-Reply-To: From: Harini Katakam Date: Thu, 7 Mar 2019 11:02:21 +0530 Message-ID: Subject: Re: [Linuxptp-devel] strangeness To: Paul Thomas Cc: Richard Cochran , "linuxptp-devel@lists.sourceforge.net" , netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Paul, On Thu, Mar 7, 2019 at 4:38 AM Paul Thomas wrote: > > On Fri, Mar 1, 2019 at 1:24 AM Harini Katakam wrote: > > > > +netdev > > > > Hi Paul, > > On Fri, Mar 1, 2019 at 12:29 AM Richard Cochran > > wrote: > > > > > > On Thu, Feb 28, 2019 at 12:33:26PM -0500, Paul Thomas wrote: > > > > Yes changing it to TSTAMP_ALL_PTP_FRAMES instead of TSTAMP_ALL_FRAMES > > > > does seem to fix the ssh issue. My worry is that there is still a bug > > > > somewhere in the network stack that this is just masking. > > > > Ok thanks. > > One place to check in the driver will be: > > if (gem_ptp_do_txstamp(queue, skb, desc) == 0) { > > /* skb now belongs to timestamp buffer > > * and will be removed later > > */ > > tx_skb->skb = NULL; > > } > > When all TX packets are timestamped, the skb always belongs to the > > timestamp buffer. > > > > > > > > Or the HW isn't sending the frames in the first place. > > > > > > Check that first! > > > > To check this, the statistics registers in MAC will be one way. > > But if there is no TX completion interrupt, then I wouldn't expect > > these statistics to increase either. The used bit status in BD dump > > might be of more use. > > > > I will also try to reproduce (with TX timestamp ALL) and see if any of > > the above gives some clue. > > > > Regards, > > Harini > > Hi Harini, any luck looking at this? I'm sorry, I was not able to debug this further. > > I didn't get very far, even in the "broken" state I see plenty of tx_frames: > root@xu5:/opt/linuxptp# ethtool -S eth0 > NIC statistics: > ... > tx_frames: 39763 > ... > > When you said "registers in the MAC" is ethtool -S displaying that? Yes, ethtool does display these statistics. I was referring to the registers starting offset 0xFF0B0108 (for GEM0) here: https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html If you see this value increasing, then the MAC is transmitting successfully. Although, I realize it could be other traffic. To see if specific packets (for the failed SSH connection) are not being queued, a BD dump might help. Regards, Harini