On 8/13/17 2:56 PM, Wei Wang wrote:
>> Looking at my patch to move host routes from loopback to device with the
>> address, I have this:
>>
>> @@ -2789,7 +2808,8 @@ static int fib6_ifdown(struct rt6_info *rt, void *arg)
>> const struct arg_dev_net *adn = arg;
>> const struct net_dev
> Looking at my patch to move host routes from loopback to device with the
> address, I have this:
>
> @@ -2789,7 +2808,8 @@ static int fib6_ifdown(struct rt6_info *rt, void *arg)
> const struct arg_dev_net *adn = arg;
> const struct net_device *dev = adn->dev;
>
> - if ((rt->
On 8/12/17 1:42 PM, Wei Wang wrote:
> Hi Ido,
>
>>> - if ((rt->dst.dev == dev || !dev) &&
>>> + if ((rt->dst.dev == dev || !dev ||
>>> + rt->rt6i_idev->dev == dev) &&
>>
>> Can you please explain why this line is needed? While host routes aren't
>> removed from the FIB by rt6_ifdo
Hi Ido,
>> - if ((rt->dst.dev == dev || !dev) &&
>> + if ((rt->dst.dev == dev || !dev ||
>> + rt->rt6i_idev->dev == dev) &&
>
> Can you please explain why this line is needed? While host routes aren't
> removed from the FIB by rt6_ifdown() (when dst.dev goes down), they are
> remo
On Fri, Aug 11, 2017 at 8:37 PM, David Ahern wrote:
> On 8/11/17 6:25 PM, Wei Wang wrote:
>> By "a patch to fix that" do you mean after your patch, for every rt6,
>> rt6->rt6i_idev will be the same as rt6->dst.dev?
>
> FIB entries should have them the same device with my patch.
>
> The copies done
On Fri, Aug 11, 2017 at 8:07 PM, John Stultz wrote:
> On Fri, Aug 11, 2017 at 5:31 PM, John Stultz wrote:
>> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang wrote:
If after Cong's fix, the issue still happens, could you help try the
patch attached and collect all logs when you try the reprod
> Looks good so far! I've not hit the issue yet.
>
Great. I will prepare an official patch then.
> Thanks so much for sorting out a fix!
>
> If its useful:
> Tested-by: John Stultz
Sure will do.
Thanks.
Wei
On Fri, Aug 11, 2017 at 8:07 PM, John Stultz wrote:
> On Fri, Aug 11, 2017 at 5:31 PM
Hi Wei,
On Fri, Aug 11, 2017 at 05:10:02PM -0700, Wei Wang wrote:
> I think we have a potential fix for this issue.
> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
> possible that rt6->dst.dev points to loopback device while
> rt6->rt6i_idev->dev points to a real device.
>
On 8/11/17 6:25 PM, Wei Wang wrote:
> By "a patch to fix that" do you mean after your patch, for every rt6,
> rt6->rt6i_idev will be the same as rt6->dst.dev?
FIB entries should have them the same device with my patch.
The copies done (ip6_rt_cache_alloc and ip6_rt_pcpu_alloc) will have to
set ds
On Fri, Aug 11, 2017 at 5:31 PM, John Stultz wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>
Great. Thank
On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang wrote:
>> If after Cong's fix, the issue still happens, could you help try the
>> patch attached and collect all logs when you try the reproduce the
>> issue? It would be great to have logs for both success case and the
>> failure case.
>>
>> Thanks so muc
On Fri, Aug 11, 2017 at 5:19 PM, David Ahern wrote:
> On 8/11/17 6:10 PM, Wei Wang wrote:
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->de
On 8/11/17 6:10 PM, Wei Wang wrote:
> I think we have a potential fix for this issue.
> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
> possible that rt6->dst.dev points to loopback device while
> rt6->rt6i_idev->dev points to a real device.
> When the real device goes down
> If after Cong's fix, the issue still happens, could you help try the
> patch attached and collect all logs when you try the reproduce the
> issue? It would be great to have logs for both success case and the
> failure case.
>
> Thanks so much for your help.
>
I think we have a potential fix for
On Fri, Aug 11, 2017 at 9:48 AM, Cong Wang wrote:
> Hi,
>
> On Thu, Aug 10, 2017 at 11:12 AM, John Stultz wrote:
>> On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang wrote:
>>> Hi John,
>>>
>>> Is it possible to try the attached patch?
>>
>> Thanks so much for the quick turn around!
>>
>> So I dropped a
Hi,
On Thu, Aug 10, 2017 at 11:12 AM, John Stultz wrote:
> On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang wrote:
>> Hi John,
>>
>> Is it possible to try the attached patch?
>
> Thanks so much for the quick turn around!
>
> So I dropped all the reverts you suggested, and applied this one
> against 4.1
On Thu, Aug 10, 2017 at 11:12 AM, John Stultz wrote:
> On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang wrote:
>> Hi John,
>>
>> Is it possible to try the attached patch?
>
> Thanks so much for the quick turn around!
>
> So I dropped all the reverts you suggested, and applied this one
> against 4.13-rc4
On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang wrote:
> Hi John,
>
> Is it possible to try the attached patch?
Thanks so much for the quick turn around!
So I dropped all the reverts you suggested, and applied this one
against 4.13-rc4, but I'm still seeing the problematic behavior.
> I am not sure i
;>> wrote:
>>>>>>> So, with recent testing with my HiKey board, I've been noticing some
>>>>>>> quirky behavior with my USB eth adapter.
>>>>>>>
>>>>>>> Basically, pluging the usb eth adapter in and then removing
t;> quirky behavior with my USB eth adapter.
>>>>>>
>>>>>> Basically, pluging the usb eth adapter in and then removing it, when
>>>>>> plugging it back in I often find that its not detected, and the system
>>>>>> slowly spit
eth adapter in and then removing it, when
>>>>> plugging it back in I often find that its not detected, and the system
>>>>> slowly spits out the following message over and over:
>>>>> unregister_netdevice: waiting for eth0 to become free. Usage count = 1
On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
>
> Does your USB adapter get an IPv6 address?
Yes, it does.
> If you see the problem starts to happen on commit
> 9514528d92d4cbe086499322370155ed69f5d06c, could you try reverting all
> the following commits:
> (from new to old)
> 1eb04e7c9e63 net
find that its not detected, and the system
>>>> slowly spits out the following message over and over:
>>>> unregister_netdevice: waiting for eth0 to become free. Usage count = 1
>>>
>>> The other bit is that after this starts printing, the board will no
>>&
cing some
>>> quirky behavior with my USB eth adapter.
>>>
>>> Basically, pluging the usb eth adapter in and then removing it, when
>>> plugging it back in I often find that its not detected, and the system
>>> slowly spits out the following message ov
t;> Basically, pluging the usb eth adapter in and then removing it, when
>> plugging it back in I often find that its not detected, and the system
>> slowly spits out the following message over and over:
>> unregister_netdevice: waiting for eth0 to become free. Usage count =
hat its not detected, and the system
> slowly spits out the following message over and over:
> unregister_netdevice: waiting for eth0 to become free. Usage count = 1
The other bit is that after this starts printing, the board will no
longer reboot (it hangs continuing to occasionally print
r and over:
unregister_netdevice: waiting for eth0 to become free. Usage count = 1
I've tried to go through and bisect it, but apparently the issue isn't
always reproducible, as I'm apparently getting lots of false negatives
(where I can't always reproduce boot to boot the
28 matches
Mail list logo
