Hello, recently I was doing a lot of tracing/profiling to understand
an issue we were having. Anyway, during this I ran across
__napi_schedule_irqoff() where the comment in dev.c says "Variant of
__napi_schedule() assuming hard irqs are masked".
It looks like the queue_writel(queue, IDR, bp->rx_in
On Mon, Jan 11, 2021 at 4:35 PM Heiner Kallweit wrote:
>
> On 11.01.2021 20:45, Paul Thomas wrote:
> > Hello, recently I was doing a lot of tracing/profiling to understand
> > an issue we were having. Anyway, during this I ran across
> > __napi_schedule_irqoff() where t
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
On Thu, Mar 7, 2019 at 12:32 AM Harini Katakam wrote:
>
> 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,
> >
Hi Harini,
On Fri, Mar 8, 2019 at 1:08 AM Harini Katakam wrote:
>
> Hi Paul,
> On Fri, Mar 8, 2019 at 12:33 AM Paul Thomas wrote:
> >
> > On Thu, Mar 7, 2019 at 12:32 AM Harini Katakam wrote:
> > >
> > > Hi Paul,
> > > On Thu, Mar 7, 2019 at 4:
On Fri, Mar 8, 2019 at 1:07 PM Paul Thomas wrote:
>
> Hi Harini,
>
> On Fri, Mar 8, 2019 at 1:08 AM Harini Katakam wrote:
> >
> > Hi Paul,
> > On Fri, Mar 8, 2019 at 12:33 AM Paul Thomas wrote:
> > >
> > > On Thu, Mar 7, 2019 at 12:32 A
Hi Harini,
On Sat, Mar 9, 2019 at 12:38 AM Harini Katakam wrote:
>
> Hi Paul,
> On Sat, Mar 9, 2019 at 3:13 AM Paul Thomas wrote:
> >
> > On Fri, Mar 8, 2019 at 1:07 PM Paul Thomas wrote:
> > >
> > > Hi Harini,
> > >
> >
Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been enabled
for this skb
This is a concept for discussion, more testing is needed.
It does fix the issue where normal socks that aren't expecting a timestamp will
not wake
up on select.
---
drivers/net/ethernet/cadence/macb_main.
On Tue, Mar 12, 2019 at 3:51 PM Paul Thomas wrote:
>
> Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been
> enabled for this skb
> This is a concept for discussion, more testing is needed.
> It does fix the issue where normal socks that aren't expecting
Hi Jake, thanks for all the help and for looking at this!
>
> You have two conditionals inside, and I misread where you were doing the
> checking of the SKBTX_HW_TSTAMP flag.
>
> I would do the following :
>
> if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HWTSTAMP) &&
> gem_ptp_do_txstamp(qu
On Tue, Mar 12, 2019 at 7:07 PM Keller, Jacob E
wrote:
>
>
>
> > -Original Message-
> > From: Paul Thomas [mailto:pthomas8...@gmail.com]
> > Sent: Tuesday, March 12, 2019 3:05 PM
> > To: Keller, Jacob E
> > Cc: netdev@vger.kernel.org
> > Subj
Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been
enabled for this skb It does fix the issue where normal socks that
aren't expecting a timestamp will not wake up on select. And when a
user does want a SOF_TIMESTAMPING_TX_HARDWARE this does work.
Signed-off-by: Paul T
Oh I notice that this is in the xilnx github repo so if it makes it in
from there that works too.
-Paul
On Tue, Mar 19, 2019 at 1:07 PM Paul Thomas wrote:
>
> Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been
> enabled for this skb It does fix the issue where normal socks that
> aren't expecting a timestamp will not wake up on select. And when a
&
> Could you please resend the patch addressing Dave's review comments
> about subject line and Fixes tag?
Yup, sorry about that. I'm not subscribed to netdev, but I thought
replies would have me in the to:line, but I see the comments on the
archive. I'll send this out shortly.
-Paul
On Thu, Apr 4, 2019 at 9:23 AM Paul Thomas wrote:
>
> > Could you please resend the patch addressing Dave's review comments
> > about subject line and Fixes tag?
> Yup, sorry about that. I'm not subscribed to netdev, but I thought
> replies would have me in the to:
Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been
enabled for this skb. It does fix the issue where normal socks that
aren't expecting a timestamp will not wake up on select, but when a
user does want a SOF_TIMESTAMPING_TX_HARDWARE it does work.
Signed-off-by: Paul T
Make sure SKBTX_HW_TSTAMP (i.e. SOF_TIMESTAMPING_TX_HARDWARE) has been
enabled for this skb. It does fix the issue where normal socks that
aren't expecting a timestamp will not wake up on select, but when a
user does want a SOF_TIMESTAMPING_TX_HARDWARE it does work.
Signed-off-by: Paul T
On Mon, Apr 8, 2019 at 1:04 PM David Miller wrote:
>
> From: Paul Thomas
> Date: Mon, 8 Apr 2019 09:20:47 -0400
>
> > + if (unlikely(skb_shinfo(skb)->tx_flags &
> > SKBTX_HW_TSTAMP) &&
> > +
Hello,
I think I'm seeing an issue with the PHY hardware or PHY driver. What
happens is sometimes (but not always) when I do 'ip link set eth0
down' followed by 'ip link set eth0 up' I don't ever see an
auto-negotiation again. LEDs don't come on, ethtool reports 'Link
detected: no'. Even physicall
Hi Andrew,
I did some more investigation, and what seems to be happening is the
device get's stuck in auto-negotiation. I looked at this using
phytool:
https://github.com/wkz/phytool
When it is in the good state I see that reg 0x01 is 0x796d where bit
1.2 reports 'Link is up' and bit 1.5 reports
On Mon, Sep 16, 2019 at 11:13 AM Andrew Lunn wrote:
>
> > When it is in the good state I see that reg 0x01 is 0x796d where bit
> > 1.2 reports 'Link is up' and bit 1.5 reports 'Auto-negotiation process
> > complete'. However, once I get to the bad state (it may take several
> > tries of ifdown, if
22 matches
Mail list logo
