followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?

followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?

[Robert P. J. Day]

  apologies for the constant pleas for assistance, but i think i'm
zeroing in on the problem that started all this. recap: custom
FPGA-based linux box with multiple ports, where the current symptom is
that there is no userspace notification when someone simply unplugs
one of the ports ("ifconfig" shows that interface still RUNNING).

  as i read it, an active ethernet interface should be both UP (the
administrative state) and RUNNING (the RFC 2863-defined operational
state). if i unplug, i've verified on a standard net port on my laptop
that the interface is still UP, but no longer RUNNING, which makes
perfect sense. i plug back in, interface starts RUNNING again. so
where's the problem?

  i can see that whether ifconfig shows an interface RUNNING is
defined in net/core/dev.c:

  unsigned int dev_get_flags(const struct net_device *dev)
  {
        unsigned int flags;

        flags = (dev->flags & ~(IFF_PROMISC |
                                IFF_ALLMULTI |
                                IFF_RUNNING |
                                IFF_LOWER_UP |
                                IFF_DORMANT)) |
                (dev->gflags & (IFF_PROMISC |
                                IFF_ALLMULTI));

        if (netif_running(dev)) {
                if (netif_oper_up(dev))
                        flags |= IFF_RUNNING;  <---- THERE
                if (netif_carrier_ok(dev))
                        flags |= IFF_LOWER_UP;
                if (netif_dormant(dev))
                        flags |= IFF_DORMANT;
        }

        return flags;
  }

where netif_oper_up() is defined as:

  static inline bool netif_oper_up(const struct net_device *dev)
  {
        return (dev->operstate == IF_OPER_UP ||
                dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
  }

so i am simply assuming that the underlying problem is that,
somewhere down below, the unplugging of a port is somehow not setting
dev->operstate to its proper value of IF_OPER_DOWN.

  that would clearly explain everything, and i'm about to dig even
further to see where the event of unplugging a port *should* be
recognized, but does this sound like a reasonable diagnosis? there
have been other problems with the programming of the FPGA, so it would
surprise absolutely no one to learn that this aspect was
misprogrammed.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?

[Andrew Lunn]

On Sun, Aug 26, 2018 at 11:14:33AM -0400, Robert P. J. Day wrote:
> 
>   apologies for the constant pleas for assistance, but i think i'm
> zeroing in on the problem that started all this. recap: custom
> FPGA-based linux box with multiple ports, where the current symptom is
> that there is no userspace notification when someone simply unplugs
> one of the ports ("ifconfig" shows that interface still RUNNING).

What are you using for a PHY? Are you using phylib or phylink?  I
strongly suggest you do, and then you don't need to care about any of
this.

	Andrew

Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?

[Robert P. J. Day]

On Sun, 26 Aug 2018, Andrew Lunn wrote:

> On Sun, Aug 26, 2018 at 11:14:33AM -0400, Robert P. J. Day wrote:
> >
> >   apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
> > FPGA-based linux box with multiple ports, where the current
> > symptom is that there is no userspace notification when someone
> > simply unplugs one of the ports ("ifconfig" shows that interface
> > still RUNNING).
>
> What are you using for a PHY? Are you using phylib or phylink?  I
> strongly suggest you do, and then you don't need to care about any
> of this.

  i'm not sure i'm even allowed to talk about that given the NDA --
i'll just muddle through following the code until i figure out what is
failing to notify userspace. le *sigh*.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?

[Stephen Hemminger]

On Sun, 26 Aug 2018 11:14:33 -0400 (EDT)
"Robert P. J. Day" <rpjday@crashcourse.ca> wrote:

>   apologies for the constant pleas for assistance, but i think i'm
> zeroing in on the problem that started all this. recap: custom
> FPGA-based linux box with multiple ports, where the current symptom is
> that there is no userspace notification when someone simply unplugs
> one of the ports ("ifconfig" shows that interface still RUNNING).
> 
>   as i read it, an active ethernet interface should be both UP (the
> administrative state) and RUNNING (the RFC 2863-defined operational
> state). if i unplug, i've verified on a standard net port on my laptop
> that the interface is still UP, but no longer RUNNING, which makes
> perfect sense. i plug back in, interface starts RUNNING again. so
> where's the problem?
> 
>   i can see that whether ifconfig shows an interface RUNNING is
> defined in net/core/dev.c:
> 
>   unsigned int dev_get_flags(const struct net_device *dev)
>   {
>         unsigned int flags;
> 
>         flags = (dev->flags & ~(IFF_PROMISC |
>                                 IFF_ALLMULTI |
>                                 IFF_RUNNING |
>                                 IFF_LOWER_UP |
>                                 IFF_DORMANT)) |
>                 (dev->gflags & (IFF_PROMISC |
>                                 IFF_ALLMULTI));
> 
>         if (netif_running(dev)) {
>                 if (netif_oper_up(dev))
>                         flags |= IFF_RUNNING;  <---- THERE
>                 if (netif_carrier_ok(dev))
>                         flags |= IFF_LOWER_UP;
>                 if (netif_dormant(dev))
>                         flags |= IFF_DORMANT;
>         }
> 
>         return flags;
>   }
> 
> where netif_oper_up() is defined as:
> 
>   static inline bool netif_oper_up(const struct net_device *dev)
>   {
>         return (dev->operstate == IF_OPER_UP ||
>                 dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
>   }
> 
> so i am simply assuming that the underlying problem is that,
> somewhere down below, the unplugging of a port is somehow not setting
> dev->operstate to its proper value of IF_OPER_DOWN.
> 
>   that would clearly explain everything, and i'm about to dig even
> further to see where the event of unplugging a port *should* be
> recognized, but does this sound like a reasonable diagnosis? there
> have been other problems with the programming of the FPGA, so it would
> surprise absolutely no one to learn that this aspect was
> misprogrammed.
> 
> rday
> 

There is no reason drivers should ever muck with flags directly.
You probably are looking for netif_detach

Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?

[Robert P. J. Day]

On Sun, 26 Aug 2018, Stephen Hemminger wrote:

> On Sun, 26 Aug 2018 11:14:33 -0400 (EDT)
> "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
> >   apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
> > FPGA-based linux box with multiple ports, where the current symptom is
> > that there is no userspace notification when someone simply unplugs
> > one of the ports ("ifconfig" shows that interface still RUNNING).
> >
> >   as i read it, an active ethernet interface should be both UP (the
> > administrative state) and RUNNING (the RFC 2863-defined operational
> > state). if i unplug, i've verified on a standard net port on my laptop
> > that the interface is still UP, but no longer RUNNING, which makes
> > perfect sense. i plug back in, interface starts RUNNING again. so
> > where's the problem?
> >
> >   i can see that whether ifconfig shows an interface RUNNING is
> > defined in net/core/dev.c:
> >
> >   unsigned int dev_get_flags(const struct net_device *dev)
> >   {
> >         unsigned int flags;
> >
> >         flags = (dev->flags & ~(IFF_PROMISC |
> >                                 IFF_ALLMULTI |
> >                                 IFF_RUNNING |
> >                                 IFF_LOWER_UP |
> >                                 IFF_DORMANT)) |
> >                 (dev->gflags & (IFF_PROMISC |
> >                                 IFF_ALLMULTI));
> >
> >         if (netif_running(dev)) {
> >                 if (netif_oper_up(dev))
> >                         flags |= IFF_RUNNING;  <---- THERE
> >                 if (netif_carrier_ok(dev))
> >                         flags |= IFF_LOWER_UP;
> >                 if (netif_dormant(dev))
> >                         flags |= IFF_DORMANT;
> >         }
> >
> >         return flags;
> >   }
> >
> > where netif_oper_up() is defined as:
> >
> >   static inline bool netif_oper_up(const struct net_device *dev)
> >   {
> >         return (dev->operstate == IF_OPER_UP ||
> >                 dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
> >   }
> >
> > so i am simply assuming that the underlying problem is that,
> > somewhere down below, the unplugging of a port is somehow not setting
> > dev->operstate to its proper value of IF_OPER_DOWN.
> >
> >   that would clearly explain everything, and i'm about to dig even
> > further to see where the event of unplugging a port *should* be
> > recognized, but does this sound like a reasonable diagnosis? there
> > have been other problems with the programming of the FPGA, so it would
> > surprise absolutely no one to learn that this aspect was
> > misprogrammed.
> >
> > rday
> >
>
> There is no reason drivers should ever muck with flags directly.
> You probably are looking for netif_detach

  i assume you mean netif_device_detach; i'll check into that.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================