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
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
> 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
> 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
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
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
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
>
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
>
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.
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
> 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
> 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
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
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
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.
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
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
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
>>>
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
> 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.
> 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.
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.
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
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
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
>>
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
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
> 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
> 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
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
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
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
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
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
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
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
Hi John,
Is it possible to try the attached patch?
I am not sure if it actually fixes the issue. But I think it is worth a try.
Also, could you get me all the ipv6 routes when you plug in the usb
using "ip -6 route show"? (If you have multiple routing tables
configured, could you dump them all?)
Hi John,
Is it possible to try the attached patch?
I am not sure if it actually fixes the issue. But I think it is worth a try.
Also, could you get me all the ipv6 routes when you plug in the usb
using "ip -6 route show"? (If you have multiple routing tables
configured, could you dump them all?)
On Wed, Aug 9, 2017 at 6:26 PM, John Stultz wrote:
> On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
>> On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
>>> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang
On Wed, Aug 9, 2017 at 6:26 PM, John Stultz wrote:
> On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
>> On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
>>> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
(Cc'ing Wei whose commit was blamed)
On Mon, Aug 7, 2017 at 2:15 PM,
On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
> On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
>> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
>>> (Cc'ing Wei whose commit was blamed)
>>>
>>> On Mon, Aug 7, 2017 at
On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
> On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
>> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
>>> (Cc'ing Wei whose commit was blamed)
>>>
>>> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
On Mon, Aug 7, 2017 at 2:05 PM, John
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
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
On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
>> (Cc'ing Wei whose commit was blamed)
>>
>> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
>>> On Mon, Aug 7,
On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
>> (Cc'ing Wei whose commit was blamed)
>>
>> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
>>> On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote:
So, with recent testing with my
On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
> (Cc'ing Wei whose commit was blamed)
>
> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
>> On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote:
>>> So, with recent
On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
> (Cc'ing Wei whose commit was blamed)
>
> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
>> On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote:
>>> So, with recent testing with my HiKey board, I've been noticing some
>>> quirky behavior with
(Cc'ing Wei whose commit was blamed)
On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
> On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote:
>> So, with recent testing with my HiKey board, I've been noticing some
>> quirky behavior with my USB eth
(Cc'ing Wei whose commit was blamed)
On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
> On Mon, Aug 7, 2017 at 2:05 PM, John Stultz 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
On Mon, Aug 7, 2017 at 2:05 PM, John Stultz 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 it, when
> plugging it back in I often find
On Mon, Aug 7, 2017 at 2:05 PM, John Stultz 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 it, when
> plugging it back in I often find that its not detected,
54 matches
Mail list logo