This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
Inami-san reported that this commit breaks bridge support in a Xen
environment, and that reverting it fixes this.
During system resume, bridge ports are no longer enabled, as that relies
on the receipt of the NETDEV_CHANGE notification
From: Geert Uytterhoeven
Date: Tue, 1 Sep 2020 17:02:37 +0200
> This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
>
> Inami-san reported that this commit breaks bridge support in a Xen
> environment, and that reverting it fixes this.
>
> During system resume, bridge ports are no lo
Hi David,
On Thu, Sep 10, 2020 at 9:20 PM David Miller wrote:
> From: Geert Uytterhoeven
> Date: Tue, 1 Sep 2020 17:02:37 +0200
>
> > This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
> >
> > Inami-san reported that this commit breaks bridge support in a Xen
> > environment, and tha
From: Geert Uytterhoeven
Date: Fri, 11 Sep 2020 08:32:55 +0200
> Hi David,
>
> On Thu, Sep 10, 2020 at 9:20 PM David Miller wrote:
>> From: Geert Uytterhoeven
>> Date: Tue, 1 Sep 2020 17:02:37 +0200
>>
>> > This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
>> >
>> > Inami-san repo
Hi David,
On Sat, Sep 12, 2020 at 2:44 AM David Miller wrote:
> From: Geert Uytterhoeven
> Date: Fri, 11 Sep 2020 08:32:55 +0200
>
> > On Thu, Sep 10, 2020 at 9:20 PM David Miller wrote:
> >> From: Geert Uytterhoeven
> >> Date: Tue, 1 Sep 2020 17:02:37 +0200
> >>
> >> > This reverts commit 12
From: Geert Uytterhoeven
Date: Sat, 12 Sep 2020 14:33:59 +0200
> "dev" is not the bridge device, but the physical Ethernet interface, which
> may already be suspended during s2ram.
Hmmm, ok.
Looking more deeply NETDEV_CHANGE causes br_port_carrier_check() to run which
exits early if netif_runni
Hi David,
CC bridge
On Sun, Sep 13, 2020 at 3:34 AM David Miller wrote:
> From: Geert Uytterhoeven
> Date: Sat, 12 Sep 2020 14:33:59 +0200
>
> > "dev" is not the bridge device, but the physical Ethernet interface, which
> > may already be suspended during s2ram.
>
> Hmmm, ok.
>
> Looking more d
From: Geert Uytterhoeven
Date: Tue, 1 Sep 2020 17:02:37 +0200
> This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
Heiner, please review this.
Thank you.
> Inami-san reported that this commit breaks bridge support in a Xen
> environment, and that reverting it fixes this.
>
> Durin
On Mon, 2020-09-14 at 09:40 +0200, Geert Uytterhoeven wrote:
> Hi David,
>
> CC bridge
>
> On Sun, Sep 13, 2020 at 3:34 AM David Miller wrote:
> > From: Geert Uytterhoeven
> > Date: Sat, 12 Sep 2020 14:33:59 +0200
> >
> > > "dev" is not the bridge device, but the physical Ethernet interface, w
On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
> This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
>
> Inami-san reported that this commit breaks bridge support in a Xen
> environment, and that reverting it fixes this.
>
> During system resume, bridge ports are no longer
From: Nikolay Aleksandrov
Date: Fri, 18 Sep 2020 12:35:02 +
> Thanks for the analysis, I don't see any issues with checking if the device
> isn't present. It will have to go through some testing, but no obvious
> objections/issues. Have you tried if it fixes your case?
> I have briefly gone o
From: Saeed Mahameed
Date: Fri, 18 Sep 2020 10:58:49 -0700
> On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
>> @@ -158,7 +158,7 @@ static void linkwatch_do_dev(struct net_device
>> *dev)
>> clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state);
>>
>> rfc2863_policy(dev)
On 18.09.2020 19:58, Saeed Mahameed wrote:
> On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
>> This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
>>
>> Inami-san reported that this commit breaks bridge support in a Xen
>> environment, and that reverting it fixes this.
>>
>>
On Wed, 2020-09-23 at 13:49 +0200, Heiner Kallweit wrote:
> On 18.09.2020 19:58, Saeed Mahameed wrote:
> > On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
> > > This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
> > >
> > > Inami-san reported that this commit breaks bridge
On 23.09.2020 20:35, Saeed Mahameed wrote:
> On Wed, 2020-09-23 at 13:49 +0200, Heiner Kallweit wrote:
>> On 18.09.2020 19:58, Saeed Mahameed wrote:
>>> On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
Inami-sa
From: Heiner Kallweit
Date: Wed, 23 Sep 2020 21:58:59 +0200
> On 23.09.2020 20:35, Saeed Mahameed wrote:
>> Why would a driver detach the device on ndo_stop() ?
>> seems like this is the bug you need to be chasing ..
>> which driver is doing this ?
>>
> Some drivers set the device to PCI D3hot
On 23.09.2020 22:15, David Miller wrote:
> From: Heiner Kallweit
> Date: Wed, 23 Sep 2020 21:58:59 +0200
>
>> On 23.09.2020 20:35, Saeed Mahameed wrote:
>>> Why would a driver detach the device on ndo_stop() ?
>>> seems like this is the bug you need to be chasing ..
>>> which driver is doing this
On Wed, 2020-09-23 at 22:44 +0200, Heiner Kallweit wrote:
> On 23.09.2020 22:15, David Miller wrote:
> > From: Heiner Kallweit
> > Date: Wed, 23 Sep 2020 21:58:59 +0200
> >
> > > On 23.09.2020 20:35, Saeed Mahameed wrote:
> > > > Why would a driver detach the device on ndo_stop() ?
> > > > seems
From: Saeed Mahameed
Date: Wed, 23 Sep 2020 15:42:17 -0700
> Maybe we need to clear IFF_UP before calling ops->ndo_stop(dev),
> instead of after on __dev_close_many(). Assuming no driver is checking
> IFF_UP state on its own ndo_stop(), other than this, the order
> shouldn't really matter, since
From: David Miller
Date: Wed, 23 Sep 2020 17:21:25 -0700 (PDT)
> If an async code path tests 'present', gets true, and then the RTNL
> holding synchronous code path puts the device into D3hot immediately
> afterwards, the async code path will still continue and access the
> chips registers and fa
On Wed, 2020-09-23 at 17:23 -0700, David Miller wrote:
> From: David Miller
> Date: Wed, 23 Sep 2020 17:21:25 -0700 (PDT)
>
> > If an async code path tests 'present', gets true, and then the RTNL
> > holding synchronous code path puts the device into D3hot
> immediately
> > afterwards, the async
On Wed, 23 Sep 2020 22:49:37 -0700 Saeed Mahameed wrote:
> 2) Another problematic scenario which i see is repeated in many
> drivers:
>
> shutdown/suspend()
> rtnl_lock()
> netif_device_detach()//Mark !present;
> stop()->carrier_off()->linkwatch_event()
> // at this point device is
On Thu, 2020-09-24 at 09:03 -0700, Jakub Kicinski wrote:
> On Wed, 23 Sep 2020 22:49:37 -0700 Saeed Mahameed wrote:
> > 2) Another problematic scenario which i see is repeated in many
> > drivers:
> >
> > shutdown/suspend()
> > rtnl_lock()
> > netif_device_detach()//Mark !present;
> >
23 matches
Mail list logo
