* Re: [PATCH] veth: remove hardware checksum feature
From: Eric Dumazet @ 2013-08-08 20:16 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <5203F4E6.1010701@candelatech.com>
On Thu, 2013-08-08 at 12:43 -0700, Ben Greear wrote:
> So, the question is: Is there any time that I *should* be mucking with
> skb->ip_summed when bridging pkts from one device to another on modern
> kernels? I'm using the ptype_all hook to grab packets, and ndo_start_xmit
> to send them, in case that matters.
ndo_start_xmit() is likely bypassing the core network fallbacks.
You might try dev_hard_start_xmit() instead
^ permalink raw reply
* DO YOU NEED A LEGIT LOAN OF 3%? E-MAIL US lewisharrylending@aol.com
From: pd.patel @ 2013-08-08 19:42 UTC (permalink / raw)
DO YOU NEED A LEGIT LOAN OF 3%? E-MAIL US lewisharrylending@aol.com WITH
FULL DETAILS:1.Name:2.Age:3.Phone Number:4.Country:5.Loan
Amount.6.Duration.7.Sex
Disclaimer: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Tega Industries Ltd, its subsidiaries or affiliates, is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Hannes Frederic Sowa @ 2013-08-08 20:16 UTC (permalink / raw)
To: Debabrata Banerjee, Jiri Pirko, mleitner, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <20130808194702.GH14001@order.stressinduktion.org>
On Thu, Aug 08, 2013 at 09:47:02PM +0200, Hannes Frederic Sowa wrote:
> On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
> > On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > > From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > >
> > > They will be created at output, if ever needed. This avoids creating
> > > empty neighbor entries when TPROXYing/Forwarding packets for addresses
> > > that are not even directly reachable.
> > >
> > > Note that IPv4 already handles it this way. No neighbor entries are
> > > created for local input.
> > >
> > > Tested by myself and customer.
> > >
> > > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> > > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > > ---
> > > net/ipv6/route.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > > index e229a3b..363d8b7 100644
> > > --- a/net/ipv6/route.c
> > > +++ b/net/ipv6/route.c
> > > @@ -928,7 +928,7 @@ restart:
> > > dst_hold(&rt->dst);
> > > read_unlock_bh(&table->tb6_lock);
> > >
> > > - if (!rt->n && !(rt->rt6i_flags & RTF_NONEXTHOP))
> > > + if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
> > > nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
> > > else if (!(rt->dst.flags & DST_HOST))
> > > nrt = rt6_alloc_clone(rt, &fl6->daddr);
> >
> >
> >
> > I'm not sure this patch is doing the right thing. It seems to break
> > IPv6 loopback functionality, it is no longer equivalent to IPv4, as
> > stated above. It doesn't just stop neighbor creation but it stops
> > cached route creation. Seems like a scary change for a stable tree.
> > See below:
> >
> > $ ip -4 route show local
> > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> >
> > This local route enables us to use the whole loopback network, any
> > address inside 127.0.0.0/8 will work.
> >
> > $ ping -c1 127.0.0.9
> > PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
> > 64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
> >
> > --- 127.0.0.9 ping statistics ---
> > 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> > rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
> >
> > This also used to work equivalently for IPv6 local loopback routes:
> >
> > $ ip -6 route add local 2001:::/64 dev lo
> > $ ping6 -c1 2001::9
> > PING 2001::9(2001::9) 56 data bytes
> > 64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
> >
> > --- 2001::9 ping statistics ---
> > 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> > rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
> >
> > However with this patch, this is very broken:
> >
> > $ ip -6 route add local 2001::/64 dev lo
> > $ ping6 -c1 2001::9
> > PING 2001::9(2001::9) 56 data bytes
> > ping: sendmsg: Invalid argument
>
> I do think that the patch above is fine. I wonder why you get a blackhole
> route back here. Maybe backtracking in ip6_pol_route or in fib6_lookup_1 was
> way too aggressive?
Ah sorry, before rt->n removal everything worked a bit
different. rt6_alloc_cow did fill rt->n back then. To fix both things
we would have to bind a neighbour towards the loopback interface into
the non-cloned rt6_info if it feeds packets towards lo. Pretty big change for
old stable kernels, I guess. :/
Marcelo, any idea how to deal with this? My guess would be a revert, but I
don't know the impact on the tproxy issue.
Greetings,
Hannes
^ permalink raw reply
* DO YOU NEED A LEGIT LOAN OF 3%? E-MAIL US lewisharrylending@aol.com
From: pd.patel @ 2013-08-08 19:42 UTC (permalink / raw)
DO YOU NEED A LEGIT LOAN OF 3%? E-MAIL US lewisharrylending@aol.com WITH
FULL DETAILS:1.Name:2.Age:3.Phone Number:4.Country:5.Loan
Amount.6.Duration.7.Sex
Disclaimer: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Tega Industries Ltd, its subsidiaries or affiliates, is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Hannes Frederic Sowa @ 2013-08-08 19:47 UTC (permalink / raw)
To: Debabrata Banerjee
Cc: Jiri Pirko, mleitner, davem@davemloft.net, netdev@vger.kernel.org,
Alexey Kuznetsov, jmorris@namei.org, yoshfuji@linux-ipv6.org,
Patrick McHardy, Banerjee, Debabrata, Joshua Hunt
In-Reply-To: <CAATkVEzJgb+J-TAkTZCUbxLPj=b=wbOmsKbgNNimEfNaC8d0Aw@mail.gmail.com>
On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
> On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >
> > They will be created at output, if ever needed. This avoids creating
> > empty neighbor entries when TPROXYing/Forwarding packets for addresses
> > that are not even directly reachable.
> >
> > Note that IPv4 already handles it this way. No neighbor entries are
> > created for local input.
> >
> > Tested by myself and customer.
> >
> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > ---
> > net/ipv6/route.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index e229a3b..363d8b7 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -928,7 +928,7 @@ restart:
> > dst_hold(&rt->dst);
> > read_unlock_bh(&table->tb6_lock);
> >
> > - if (!rt->n && !(rt->rt6i_flags & RTF_NONEXTHOP))
> > + if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
> > nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
> > else if (!(rt->dst.flags & DST_HOST))
> > nrt = rt6_alloc_clone(rt, &fl6->daddr);
>
>
>
> I'm not sure this patch is doing the right thing. It seems to break
> IPv6 loopback functionality, it is no longer equivalent to IPv4, as
> stated above. It doesn't just stop neighbor creation but it stops
> cached route creation. Seems like a scary change for a stable tree.
> See below:
>
> $ ip -4 route show local
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>
> This local route enables us to use the whole loopback network, any
> address inside 127.0.0.0/8 will work.
>
> $ ping -c1 127.0.0.9
> PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
> 64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
>
> --- 127.0.0.9 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
>
> This also used to work equivalently for IPv6 local loopback routes:
>
> $ ip -6 route add local 2001:::/64 dev lo
> $ ping6 -c1 2001::9
> PING 2001::9(2001::9) 56 data bytes
> 64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
>
> --- 2001::9 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
>
> However with this patch, this is very broken:
>
> $ ip -6 route add local 2001::/64 dev lo
> $ ping6 -c1 2001::9
> PING 2001::9(2001::9) 56 data bytes
> ping: sendmsg: Invalid argument
I do think that the patch above is fine. I wonder why you get a blackhole
route back here. Maybe backtracking in ip6_pol_route or in fib6_lookup_1 was
way too aggressive?
^ permalink raw reply
* Re: [PATCH] veth: remove hardware checksum feature
From: Ben Greear @ 2013-08-08 19:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1375930325.4004.88.camel@edumazet-glaptop>
On 08/07/2013 07:52 PM, Eric Dumazet wrote:
> On Wed, 2013-08-07 at 18:54 -0700, Ben Greear wrote:
>
>> Maybe we should just do the csum calc in the kernel if packet is
>> about to be sent up to user-space via af_packet? I think that
>> would keep the expected behaviour, and hopefully not loose any of the performance
>> benefits for cases where the packet never leaves the kernel?
>
> I think you are rephrasing what I suggested ;)
>
> I'll send a patch asap, unless someone beats me.
I'll be happy to test.
And a slightly related question if you have the time:
My kernel-mode bridge was breaking as well, but this appears to
be a bug in my code. I had this code (since 2009, at least):
// Evidently this fixes issues with sending between NICs
// that support and do not support hw-csum.
skb->ip_summed = CHECKSUM_NONE;
It seems that at some point, this fixed some problem I saw, but it was long
ago. If I remove this, then the 3.9 kernel bridges just fine between
the VETH and a physical interface.
I do not see any modification of the ip_summed in the bridge code.
So, the question is: Is there any time that I *should* be mucking with
skb->ip_summed when bridging pkts from one device to another on modern
kernels? I'm using the ptype_all hook to grab packets, and ndo_start_xmit
to send them, in case that matters.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net/usb: rtl8150: allocate URB transfer_buffer and setup_packet separately
From: Jussi Kivilinna @ 2013-08-08 19:43 UTC (permalink / raw)
To: Petko Manolov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA, David S. Miller
In-Reply-To: <alpine.DEB.2.10.1308081809120.4258-WOI+tvYbpdBn9MRfDTB0XAC/G2K4zDHf@public.gmane.org>
On 08.08.2013 18:14, Petko Manolov wrote:
> On Wed, 7 Aug 2013, Jussi Kivilinna wrote:
>
>> rtl8150 allocates URB transfer_buffer and setup_packet as part of same
>> structure 'struct async_req'. This can cause same cacheline to be
>> DMA-mapped twice with same URB. This can lead to memory corruption on
>> some systems.
>
> I can see performance impact due to the double mapping. However, memory
> corruption seems a bit too much for sane cache and DMA controllers. Out
> of interest - which is the architecture that will potentially corrupt the
> memory.
rtlwifi driver had similar structure to allocate both setup_packet and transfer_buffer in single go (overlapping dma-mapping cachelines) and this caused problems on ARM/sunxi. Problems means: memory corruptions at random locations, device freezes and lock-ups.
-Jussi
>
>
> cheers,
> Petko
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Marcelo Ricardo Leitner @ 2013-08-08 19:23 UTC (permalink / raw)
To: Debabrata Banerjee, Jiri Pirko, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <20130808191653.GG14001@order.stressinduktion.org>
Em 08-08-2013 16:16, Hannes Frederic Sowa escreveu:
> On Thu, Aug 08, 2013 at 04:11:28PM -0300, Marcelo Ricardo Leitner wrote:
>> Em 08-08-2013 16:06, Hannes Frederic Sowa escreveu:
>>> On Thu, Aug 08, 2013 at 04:02:36PM -0300, Marcelo Ricardo Leitner wrote:
>>>> Em 08-08-2013 16:01, Hannes Frederic Sowa escreveu:
>>>>> On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
>>>>>> On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>>> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>>>> I'm not sure this patch is doing the right thing. It seems to break
>>>>>> IPv6 loopback functionality, it is no longer equivalent to IPv4, as
>>>>>> stated above. It doesn't just stop neighbor creation but it stops
>>>>>> cached route creation. Seems like a scary change for a stable tree.
>>>>>> See below:
>>>>>>
>>>>>> $ ip -4 route show local
>>>>>> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>>>>>>
>>>>>> This local route enables us to use the whole loopback network, any
>>>>>> address inside 127.0.0.0/8 will work.
>>>>>>
>>>>>> $ ping -c1 127.0.0.9
>>>>>> PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
>>>>>> 64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
>>>>>>
>>>>>> --- 127.0.0.9 ping statistics ---
>>>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>>>> rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
>>>>>>
>>>>>> This also used to work equivalently for IPv6 local loopback routes:
>>>>>>
>>>>>> $ ip -6 route add local 2001:::/64 dev lo
>>>>>> $ ping6 -c1 2001::9
>>>>>> PING 2001::9(2001::9) 56 data bytes
>>>>>> 64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
>>>>>>
>>>>>> --- 2001::9 ping statistics ---
>>>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>>>> rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
>>>>>>
>>>>>> However with this patch, this is very broken:
>>>>>>
>>>>>> $ ip -6 route add local 2001::/64 dev lo
>>>>>> $ ping6 -c1 2001::9
>>>>>> PING 2001::9(2001::9) 56 data bytes
>>>>>> ping: sendmsg: Invalid argument
>>>>>>
>>>>>> --- 2001::9 ping statistics ---
>>>>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>>>>>
>>>>> Which kernel version are you using? Perhaps you miss another fix? It
>>>>> works
>>>>> for
>>>>> me. Also I cannot find this patch in net-next?
>>>>
>>>> It wasn't needed/applied as the route cache was removed.
>>>
>>> Do you mean the rt->n(eighbour) removal? There was no removal of a route
>>> cache
>>> in IPv6 land. The cache is merely in the routing table itself.
>>
>> Yes, my bad, sorry. s/route/neighour/. It was discussed on this thread:
>> http://article.gmane.org/gmane.linux.network/255318
>>
>> "Note also that YOSHIFUJI Hideaki's patches to remove the cached neighbour
>> entirely from ipv6 routes will have the same effect, so your patch won't
>> be needed."
>
> Ok, thanks!
>
> But it somehow managed to get into stable kernels, nor? Kernels after rt->n
> removal should not be affected. At least the example above works on my
> net-next kernel correctly.
Yes, it did, as a intermediate fix, let's say. As we wouldn't remove the cache
for -stable tree, this patch seems reasonable to avoid creating a flood of
non-wanted entries. Without it, when using TPROXY, it was creating neighbor
entries for IP addresses that were behind a gateway.
In case it helps:
http://thread.gmane.org/gmane.linux.network/255234/focus=257293
http://article.gmane.org/gmane.linux.network/257433 (this thread, actually)
Thanks,
Marcelo
^ permalink raw reply
* [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Kumar Gaurav @ 2013-08-08 19:20 UTC (permalink / raw)
To: davem, emilio, mugunthanvnm, jg1.han, hsweeten
Cc: netdev, kernel-janitors, Kumar Gaurav
Removed IRQF_DISABLED as it's no-op and should be removed
Signed-off-by: Kumar Gaurav <kumargauravgupta3@gmail.com>
---
drivers/net/ethernet/korina.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 270e65f..a36fa80 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -996,14 +996,14 @@ static int korina_open(struct net_device *dev)
* that handles the Done Finished
* Ovr and Und Events */
ret = request_irq(lp->rx_irq, korina_rx_dma_interrupt,
- IRQF_DISABLED, "Korina ethernet Rx", dev);
+ 0, "Korina ethernet Rx", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get Rx DMA IRQ %d\n",
dev->name, lp->rx_irq);
goto err_release;
}
ret = request_irq(lp->tx_irq, korina_tx_dma_interrupt,
- IRQF_DISABLED, "Korina ethernet Tx", dev);
+ 0, "Korina ethernet Tx", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get Tx DMA IRQ %d\n",
dev->name, lp->tx_irq);
@@ -1012,7 +1012,7 @@ static int korina_open(struct net_device *dev)
/* Install handler for overrun error. */
ret = request_irq(lp->ovr_irq, korina_ovr_interrupt,
- IRQF_DISABLED, "Ethernet Overflow", dev);
+ 0, "Ethernet Overflow", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get OVR IRQ %d\n",
dev->name, lp->ovr_irq);
@@ -1021,7 +1021,7 @@ static int korina_open(struct net_device *dev)
/* Install handler for underflow error. */
ret = request_irq(lp->und_irq, korina_und_interrupt,
- IRQF_DISABLED, "Ethernet Underflow", dev);
+ 0, "Ethernet Underflow", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get UND IRQ %d\n",
dev->name, lp->und_irq);
--
1.7.9.5
^ permalink raw reply related
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Debabrata Banerjee @ 2013-08-08 19:19 UTC (permalink / raw)
To: Debabrata Banerjee, Jiri Pirko, mleitner, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <20130808190136.GE14001@order.stressinduktion.org>
On Thu, Aug 8, 2013 at 3:01 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
>
> Which kernel version are you using? Perhaps you miss another fix? It works for
> me. Also I cannot find this patch in net-next?
>
Just pulled and tried longterm 3.2.50, behavior is the same, broken.
-Debabrata
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Hannes Frederic Sowa @ 2013-08-08 19:16 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Debabrata Banerjee, Jiri Pirko, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <5203ED60.30108@redhat.com>
On Thu, Aug 08, 2013 at 04:11:28PM -0300, Marcelo Ricardo Leitner wrote:
> Em 08-08-2013 16:06, Hannes Frederic Sowa escreveu:
> >On Thu, Aug 08, 2013 at 04:02:36PM -0300, Marcelo Ricardo Leitner wrote:
> >>Em 08-08-2013 16:01, Hannes Frederic Sowa escreveu:
> >>>On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
> >>>>On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >>>>>From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >>>>I'm not sure this patch is doing the right thing. It seems to break
> >>>>IPv6 loopback functionality, it is no longer equivalent to IPv4, as
> >>>>stated above. It doesn't just stop neighbor creation but it stops
> >>>>cached route creation. Seems like a scary change for a stable tree.
> >>>>See below:
> >>>>
> >>>>$ ip -4 route show local
> >>>>local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> >>>>
> >>>>This local route enables us to use the whole loopback network, any
> >>>>address inside 127.0.0.0/8 will work.
> >>>>
> >>>>$ ping -c1 127.0.0.9
> >>>>PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
> >>>>64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
> >>>>
> >>>>--- 127.0.0.9 ping statistics ---
> >>>>1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>>>rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
> >>>>
> >>>>This also used to work equivalently for IPv6 local loopback routes:
> >>>>
> >>>>$ ip -6 route add local 2001:::/64 dev lo
> >>>>$ ping6 -c1 2001::9
> >>>>PING 2001::9(2001::9) 56 data bytes
> >>>>64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
> >>>>
> >>>>--- 2001::9 ping statistics ---
> >>>>1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>>>rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
> >>>>
> >>>>However with this patch, this is very broken:
> >>>>
> >>>>$ ip -6 route add local 2001::/64 dev lo
> >>>>$ ping6 -c1 2001::9
> >>>>PING 2001::9(2001::9) 56 data bytes
> >>>>ping: sendmsg: Invalid argument
> >>>>
> >>>>--- 2001::9 ping statistics ---
> >>>>1 packets transmitted, 0 received, 100% packet loss, time 0ms
> >>>
> >>>Which kernel version are you using? Perhaps you miss another fix? It
> >>>works
> >>>for
> >>>me. Also I cannot find this patch in net-next?
> >>
> >>It wasn't needed/applied as the route cache was removed.
> >
> >Do you mean the rt->n(eighbour) removal? There was no removal of a route
> >cache
> >in IPv6 land. The cache is merely in the routing table itself.
>
> Yes, my bad, sorry. s/route/neighour/. It was discussed on this thread:
> http://article.gmane.org/gmane.linux.network/255318
>
> "Note also that YOSHIFUJI Hideaki's patches to remove the cached neighbour
> entirely from ipv6 routes will have the same effect, so your patch won't
> be needed."
Ok, thanks!
But it somehow managed to get into stable kernels, nor? Kernels after rt->n
removal should not be affected. At least the example above works on my
net-next kernel correctly.
Greetings,
Hannes
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Marcelo Ricardo Leitner @ 2013-08-08 19:11 UTC (permalink / raw)
To: Debabrata Banerjee, Jiri Pirko, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <20130808190624.GF14001@order.stressinduktion.org>
Em 08-08-2013 16:06, Hannes Frederic Sowa escreveu:
> On Thu, Aug 08, 2013 at 04:02:36PM -0300, Marcelo Ricardo Leitner wrote:
>> Em 08-08-2013 16:01, Hannes Frederic Sowa escreveu:
>>> On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
>>>> On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>> I'm not sure this patch is doing the right thing. It seems to break
>>>> IPv6 loopback functionality, it is no longer equivalent to IPv4, as
>>>> stated above. It doesn't just stop neighbor creation but it stops
>>>> cached route creation. Seems like a scary change for a stable tree.
>>>> See below:
>>>>
>>>> $ ip -4 route show local
>>>> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>>>>
>>>> This local route enables us to use the whole loopback network, any
>>>> address inside 127.0.0.0/8 will work.
>>>>
>>>> $ ping -c1 127.0.0.9
>>>> PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
>>>> 64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
>>>>
>>>> --- 127.0.0.9 ping statistics ---
>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>> rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
>>>>
>>>> This also used to work equivalently for IPv6 local loopback routes:
>>>>
>>>> $ ip -6 route add local 2001:::/64 dev lo
>>>> $ ping6 -c1 2001::9
>>>> PING 2001::9(2001::9) 56 data bytes
>>>> 64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
>>>>
>>>> --- 2001::9 ping statistics ---
>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>> rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
>>>>
>>>> However with this patch, this is very broken:
>>>>
>>>> $ ip -6 route add local 2001::/64 dev lo
>>>> $ ping6 -c1 2001::9
>>>> PING 2001::9(2001::9) 56 data bytes
>>>> ping: sendmsg: Invalid argument
>>>>
>>>> --- 2001::9 ping statistics ---
>>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>>>
>>> Which kernel version are you using? Perhaps you miss another fix? It works
>>> for
>>> me. Also I cannot find this patch in net-next?
>>
>> It wasn't needed/applied as the route cache was removed.
>
> Do you mean the rt->n(eighbour) removal? There was no removal of a route cache
> in IPv6 land. The cache is merely in the routing table itself.
Yes, my bad, sorry. s/route/neighour/. It was discussed on this thread:
http://article.gmane.org/gmane.linux.network/255318
"Note also that YOSHIFUJI Hideaki's patches to remove the cached neighbour
entirely from ipv6 routes will have the same effect, so your patch won't
be needed."
Thanks,
Marcelo
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Hannes Frederic Sowa @ 2013-08-08 19:06 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Debabrata Banerjee, Jiri Pirko, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <5203EB4C.5020905@redhat.com>
On Thu, Aug 08, 2013 at 04:02:36PM -0300, Marcelo Ricardo Leitner wrote:
> Em 08-08-2013 16:01, Hannes Frederic Sowa escreveu:
> >On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
> >>On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >>>From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >>I'm not sure this patch is doing the right thing. It seems to break
> >>IPv6 loopback functionality, it is no longer equivalent to IPv4, as
> >>stated above. It doesn't just stop neighbor creation but it stops
> >>cached route creation. Seems like a scary change for a stable tree.
> >>See below:
> >>
> >>$ ip -4 route show local
> >>local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> >>
> >>This local route enables us to use the whole loopback network, any
> >>address inside 127.0.0.0/8 will work.
> >>
> >>$ ping -c1 127.0.0.9
> >>PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
> >>64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
> >>
> >>--- 127.0.0.9 ping statistics ---
> >>1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
> >>
> >>This also used to work equivalently for IPv6 local loopback routes:
> >>
> >>$ ip -6 route add local 2001:::/64 dev lo
> >>$ ping6 -c1 2001::9
> >>PING 2001::9(2001::9) 56 data bytes
> >>64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
> >>
> >>--- 2001::9 ping statistics ---
> >>1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
> >>
> >>However with this patch, this is very broken:
> >>
> >>$ ip -6 route add local 2001::/64 dev lo
> >>$ ping6 -c1 2001::9
> >>PING 2001::9(2001::9) 56 data bytes
> >>ping: sendmsg: Invalid argument
> >>
> >>--- 2001::9 ping statistics ---
> >>1 packets transmitted, 0 received, 100% packet loss, time 0ms
> >
> >Which kernel version are you using? Perhaps you miss another fix? It works
> >for
> >me. Also I cannot find this patch in net-next?
>
> It wasn't needed/applied as the route cache was removed.
Do you mean the rt->n(eighbour) removal? There was no removal of a route cache
in IPv6 land. The cache is merely in the routing table itself.
Greetings,
Hannes
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Marcelo Ricardo Leitner @ 2013-08-08 19:02 UTC (permalink / raw)
To: Debabrata Banerjee, Jiri Pirko, davem@davemloft.net,
netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <20130808190136.GE14001@order.stressinduktion.org>
Em 08-08-2013 16:01, Hannes Frederic Sowa escreveu:
> On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
>> On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>
>>> They will be created at output, if ever needed. This avoids creating
>>> empty neighbor entries when TPROXYing/Forwarding packets for addresses
>>> that are not even directly reachable.
>>>
>>> Note that IPv4 already handles it this way. No neighbor entries are
>>> created for local input.
>>>
>>> Tested by myself and customer.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>
>>> [...]
>>
>> I'm not sure this patch is doing the right thing. It seems to break
>> IPv6 loopback functionality, it is no longer equivalent to IPv4, as
>> stated above. It doesn't just stop neighbor creation but it stops
>> cached route creation. Seems like a scary change for a stable tree.
>> See below:
>>
>> $ ip -4 route show local
>> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>>
>> This local route enables us to use the whole loopback network, any
>> address inside 127.0.0.0/8 will work.
>>
>> $ ping -c1 127.0.0.9
>> PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
>> 64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
>>
>> --- 127.0.0.9 ping statistics ---
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
>>
>> This also used to work equivalently for IPv6 local loopback routes:
>>
>> $ ip -6 route add local 2001:::/64 dev lo
>> $ ping6 -c1 2001::9
>> PING 2001::9(2001::9) 56 data bytes
>> 64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
>>
>> --- 2001::9 ping statistics ---
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
>>
>> However with this patch, this is very broken:
>>
>> $ ip -6 route add local 2001::/64 dev lo
>> $ ping6 -c1 2001::9
>> PING 2001::9(2001::9) 56 data bytes
>> ping: sendmsg: Invalid argument
>>
>> --- 2001::9 ping statistics ---
>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>
> Which kernel version are you using? Perhaps you miss another fix? It works for
> me. Also I cannot find this patch in net-next?
It wasn't needed/applied as the route cache was removed.
Regards,
Marcelo
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Hannes Frederic Sowa @ 2013-08-08 19:01 UTC (permalink / raw)
To: Debabrata Banerjee
Cc: Jiri Pirko, mleitner, davem@davemloft.net, netdev@vger.kernel.org,
Alexey Kuznetsov, jmorris@namei.org, yoshfuji@linux-ipv6.org,
Patrick McHardy, Banerjee, Debabrata, Joshua Hunt
In-Reply-To: <CAATkVEzJgb+J-TAkTZCUbxLPj=b=wbOmsKbgNNimEfNaC8d0Aw@mail.gmail.com>
On Thu, Aug 08, 2013 at 02:45:40PM -0400, Debabrata Banerjee wrote:
> On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >
> > They will be created at output, if ever needed. This avoids creating
> > empty neighbor entries when TPROXYing/Forwarding packets for addresses
> > that are not even directly reachable.
> >
> > Note that IPv4 already handles it this way. No neighbor entries are
> > created for local input.
> >
> > Tested by myself and customer.
> >
> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >
> > [...]
>
> I'm not sure this patch is doing the right thing. It seems to break
> IPv6 loopback functionality, it is no longer equivalent to IPv4, as
> stated above. It doesn't just stop neighbor creation but it stops
> cached route creation. Seems like a scary change for a stable tree.
> See below:
>
> $ ip -4 route show local
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>
> This local route enables us to use the whole loopback network, any
> address inside 127.0.0.0/8 will work.
>
> $ ping -c1 127.0.0.9
> PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
> 64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
>
> --- 127.0.0.9 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
>
> This also used to work equivalently for IPv6 local loopback routes:
>
> $ ip -6 route add local 2001:::/64 dev lo
> $ ping6 -c1 2001::9
> PING 2001::9(2001::9) 56 data bytes
> 64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
>
> --- 2001::9 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
>
> However with this patch, this is very broken:
>
> $ ip -6 route add local 2001::/64 dev lo
> $ ping6 -c1 2001::9
> PING 2001::9(2001::9) 56 data bytes
> ping: sendmsg: Invalid argument
>
> --- 2001::9 ping statistics ---
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
Which kernel version are you using? Perhaps you miss another fix? It works for
me. Also I cannot find this patch in net-next?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 2/2][net-next] gianfar: Add ethtool -A support for pause frame
From: Ben Hutchings @ 2013-08-08 18:45 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <5203D0E8.8050809@freescale.com>
On Thu, 2013-08-08 at 20:10 +0300, Claudiu Manoil wrote:
> Hi Ben,
>
> On 8/7/2013 10:12 PM, Ben Hutchings wrote:
> > On Wed, 2013-08-07 at 13:24 +0300, Claudiu Manoil wrote:
> >> Allow Rx/Tx pause frame configuration via ethtool.
> >> The gfar devices feature link autonegotioation by default.
> >
> > So the MAC configuration bits are actually copied to the PHY autoneg
> > basic page, and then the PHY autoneg result is automatically used by the
> > MAC?
> >
> > This is of course possible to do in hardware, but... since this MAC is
> > not smart enough to ignore pause settings when running in half-duplex
> > mode, I seriously doubt it is doing all this by itself.
> >
>
> I just wanted to say actually that the pause->autoneg parameter is not
> needed by the gianfar driver, but I didn't know what to do with it in
> get_pauseparam(), apparently pause->autoneg needs a value (or can
> simply ignore this param?).
>
> I don't see what autonegotiation has to do with enabling/disabling
> pause frame generation in this case. My understanding is that link
> autonegotiation is taken care somewhere else, by the phy state machine.
> Each time this happens, the gianfar driver gets notified via the
> adjust_link() hook that it implements and makes the necessary configs
> in the mac registers.
That's what it *should* be doing. But it's not; it's using
priv->rx_pause and priv->tx_pause, not phydev->pause and
phydev->asym_pause. I.e. pause autoneg is really always *disabled*.
> Besides, autoneg info is already being displayed by ethtool (see
> print below).
> So I don't understand the use of pause->autoneg. What should I do with
> it?
[...]
Pause frame generation may be forced even though autonegotiation is
enabled. I don't think this is a good idea but many drivers do support
it.
And gianfar does appear to allow autonegotiation to be disabled, anyway,
so in any case you have to support both forced and autonegotiated cases.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch net] ipv6: do not create neighbor entries for local delivery
From: Debabrata Banerjee @ 2013-08-08 18:45 UTC (permalink / raw)
To: Jiri Pirko, mleitner, davem@davemloft.net
Cc: netdev@vger.kernel.org, Alexey Kuznetsov, jmorris@namei.org,
yoshfuji@linux-ipv6.org, Patrick McHardy, Banerjee, Debabrata,
Joshua Hunt
In-Reply-To: <20130130082608.GA1604@minipsycho.orion>
On Wed, Jan 30, 2013 at 3:26 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>
> They will be created at output, if ever needed. This avoids creating
> empty neighbor entries when TPROXYing/Forwarding packets for addresses
> that are not even directly reachable.
>
> Note that IPv4 already handles it this way. No neighbor entries are
> created for local input.
>
> Tested by myself and customer.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> ---
> net/ipv6/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index e229a3b..363d8b7 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -928,7 +928,7 @@ restart:
> dst_hold(&rt->dst);
> read_unlock_bh(&table->tb6_lock);
>
> - if (!rt->n && !(rt->rt6i_flags & RTF_NONEXTHOP))
> + if (!rt->n && !(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_LOCAL)))
> nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
> else if (!(rt->dst.flags & DST_HOST))
> nrt = rt6_alloc_clone(rt, &fl6->daddr);
I'm not sure this patch is doing the right thing. It seems to break
IPv6 loopback functionality, it is no longer equivalent to IPv4, as
stated above. It doesn't just stop neighbor creation but it stops
cached route creation. Seems like a scary change for a stable tree.
See below:
$ ip -4 route show local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
This local route enables us to use the whole loopback network, any
address inside 127.0.0.0/8 will work.
$ ping -c1 127.0.0.9
PING 127.0.0.9 (127.0.0.9) 56(84) bytes of data.
64 bytes from 127.0.0.9: icmp_seq=1 ttl=64 time=0.012 ms
--- 127.0.0.9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
This also used to work equivalently for IPv6 local loopback routes:
$ ip -6 route add local 2001:::/64 dev lo
$ ping6 -c1 2001::9
PING 2001::9(2001::9) 56 data bytes
64 bytes from 2001::9: icmp_seq=1 ttl=64 time=0.010 ms
--- 2001::9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.010/0.010/0.010/0.000 ms
However with this patch, this is very broken:
$ ip -6 route add local 2001::/64 dev lo
$ ping6 -c1 2001::9
PING 2001::9(2001::9) 56 data bytes
ping: sendmsg: Invalid argument
--- 2001::9 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Thanks,
Debabrata
^ permalink raw reply
* Re: [PATCH ethtool]: Add strings to display Supported Ports for Backplane Ethernet
From: Ben Hutchings @ 2013-08-08 18:27 UTC (permalink / raw)
To: Somnath Kotur; +Cc: netdev
In-Reply-To: <ac83fc1a-a967-4035-bfed-a8deff029ace@CMEXHTCAS2.ad.emulex.com>
On Thu, 2013-08-01 at 17:39 +0530, Somnath Kotur wrote:
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
> ---
> ethtool.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index 3544f0e..b24b572 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -485,6 +485,9 @@ static void dump_supported(struct ethtool_cmd *ep)
> fprintf(stdout, "MII ");
> if (mask & SUPPORTED_FIBRE)
> fprintf(stdout, "FIBRE ");
> + if ((mask & SUPPORTED_10000baseKR_Full) ||
> + (mask & SUPPORTED_10000baseKX4_Full))
> + fprintf(stdout, "BACKPLANE ");
> fprintf(stdout, "]\n");
>
> dump_link_caps("Supported", "Supports", mask, 0);
No, I don't think so. This is redundant information. It's also
pointless to add any new port types to the advertised and supported
masks unless we have hardware that can switch port type at run-time like
some old 10M boards.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v3 1/2] realtek: convert to per-chip mask
From: Ben Hutchings @ 2013-08-08 18:25 UTC (permalink / raw)
To: Peter Wu; +Cc: netdev, Francois Romieu
In-Reply-To: <1374759391-16916-2-git-send-email-lekensteyn@gmail.com>
On Thu, 2013-07-25 at 15:36 +0200, Peter Wu wrote:
[...]
> @@ -35,36 +32,62 @@ enum chip_type {
> RTL8100E2,
> };
>
> -enum {
> - chip_type_mask = HW_REVID(1, 1, 1, 1, 1, 1, 1, 1)
> +static const char * const chip_names[] = {
> + [RTL8139] = "8139",
> + [RTL8139_K] = "8139-K",
> + [RTL8139A] = "8139A",
> + [RTL8139A_G] = "8139A-G",
> + [RTL8139B] = "8139B",
> + [RTL8130] = "8130",
> + [RTL8139C] = "8139C",
> + [RTL8100] = "8100",
> + [RTL8100B_8139D] = "8100B/8139D",
> + [RTL8139C] = "8139C+",
Shouldn't the index here be RTL8139Cp?
[...]
> static struct chip_info {
> - const char *name;
> u32 id_mask;
> + u32 id_val;
> + int mac_version;
> } rtl_info_tbl[] = {
[...]
> - { "RTL-8169/8110SCe", HW_REVID(1, 0, 0, 1, 1, 0, 0, 0) },
[...]
> + { 0xfcc00000, 0x68000000, RTL8169_8110SCe },
[...]
The old value would be converted to 0x98000000; is this a fix or a
mistake?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Regression from [PATCH] DM9000B: driver initialization upgrade
From: Andrew Ruder @ 2013-08-08 18:18 UTC (permalink / raw)
To: netdev, Joseph CHANG, Allen Huant; +Cc: Jonathan Corbet
My DM9000A based board broke (no longer getting any PHY interrupts so
never determines that it has established a link) as a result of this
patch (6741f40d198c). This email is partially a call for help to the
Davicom guys who introduced this change and partially a probe to see if
anyone else has had any luck with the DM9000A or DM9000B post this
patch.
For the purpose of clarity/discussion, the patch shown at the bottom of
this email is not the actual patch applied because the patch applied
moved around functions, reformatted comments, and other things which
kind of obscures the actual changes being made so I went through and put
together a minimal patch with the same overall effect on the code.
There's really two changes being introduced by this patch: initial reset
turns on the MAC loopback and internal PHY reset.
===
On the subject of the initial reset:
This doesn't seem to be the source of my issues and I have noticed that
a similar change has already been introduced to the U-Boot dm9000
driver. I will eventually be submitting a follow-up patch that fixes
this to Jonathan Corbet's initial suggestion
( https://lkml.org/lkml/2013/3/25/481 ) because the bare iow() ignores
the reset timing requirements of the DM9000 and consequently always hits
the following error message as it attempts to read the ID before the
part has come out of reset.
dev_err(db->dev, "read wrong id 0x%08x\n", id_val);
===
On the subject of the PHY reset:
Removing just this portion of the patch gets me up and working again.
Unfortunately there is little documentation on these registers available
in the datasheet and the "DSP Control Register" in particular is
actually not even shown in the memory map of the DM9000A or DM9000B in
the datasheet. I have even modified the driver to properly wait for the
PHY reset to finish (which was also omitted from this patch series)
before writing more to the PHY but I'm still out of luck.
Any thoughts, experiences?
Thanks,
Andy
From: Joseph CHANG <josright123@gmail.com>
Date: Thu, 28 Mar 2013 23:13:42 +0000
Subject: [PATCH] DM9000B: driver initialization upgrade
Fix bug for DM9000 revision B which contain a DSP PHY
DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY,
So need extra change in initialization, For
explicity PHY Reset and PHY init parameter, and
first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe().
Following DM9000_NCR reset cause by dm9000_open() clear the
NCR_MAC_LBK bit.
Without this fix, Power-up FIFO pointers error happen around 2%
rate among Davicom's customers' boards. With this fix, All above
cases can be solved.
Signed-off-by: Joseph CHANG <josright123@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/davicom/dm9000.c | 16 +++++++++++++++-
drivers/net/ethernet/davicom/dm9000.h | 11 ++++++++++-
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index d084d17..9937095 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -143,6 +143,12 @@ typedef struct board_info {
int ip_summed;
} board_info_t;
+/* declarations */
+
+static void
+dm9000_phy_write(struct net_device *dev,
+ int phyaddr_unused, int reg, int value);
+
/* debug code */
#define dm9000_dbg(db, lev, msg...) do { \
@@ -790,6 +796,9 @@ dm9000_init_dm9000(struct net_device *dev)
iow(db, DM9000_GPCR, GPCR_GEP_CNTL); /* Let GPIO0 output */
+ dm9000_phy_write(dev, 0, MII_BMCR, BMCR_RESET); /* PHY RESET */
+ dm9000_phy_write(dev, 0, MII_DM_DSPCR, DSPCR_INIT_PARAM); /* Init */
+
ncr = (db->flags & DM9000_PLATF_EXT_PHY) ? NCR_EXT_PHY : 0;
/* if wol is needed, then always set NCR_WAKEEN otherwise we end
@@ -1528,7 +1537,12 @@ dm9000_probe(struct platform_device *pdev)
db->flags |= DM9000_PLATF_SIMPLE_PHY;
#endif
- dm9000_reset(db);
+ /* Fixing bug on dm9000_probe, takeover dm9000_reset(db),
+ * Need 'NCR_MAC_LBK' bit to indeed stable our DM9000 fifo
+ * while probe stage.
+ */
+
+ iow(db, DM9000_NCR, NCR_MAC_LBK | NCR_RST);
/* try multiple times, DM9000 sometimes gets the read wrong */
for (i = 0; i < 8; i++) {
diff --git a/drivers/net/ethernet/davicom/dm9000.h b/drivers/net/ethernet/davicom/dm9000.h
index 55688bd..9ce058a 100644
--- a/drivers/net/ethernet/davicom/dm9000.h
+++ b/drivers/net/ethernet/davicom/dm9000.h
@@ -69,7 +69,9 @@
#define NCR_WAKEEN (1<<6)
#define NCR_FCOL (1<<4)
#define NCR_FDX (1<<3)
-#define NCR_LBK (3<<1)
+
+#define NCR_RESERVED (3<<1)
+#define NCR_MAC_LBK (1<<1)
#define NCR_RST (1<<0)
#define NSR_SPEED (1<<7)
@@ -167,5 +169,12 @@
#define ISR_LNKCHNG (1<<5)
#define ISR_UNDERRUN (1<<4)
+/* Davicom MII registers.
+ */
+
+#define MII_DM_DSPCR 0x1b /* DSP Control Register */
+
+#define DSPCR_INIT_PARAM 0xE100 /* DSP init parameter */
+
#endif /* _DM9000X_H_ */
--
1.8.3.1.377.g4d1c565
^ permalink raw reply related
* pull request: wireless 2013-08-08
From: John W. Linville @ 2013-08-08 17:29 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 12537 bytes --]
Dave,
This is a batch of fixes intended for the 3.11 queue...
Regarding the mac80211 (and related) bits, Johannes says:
"I have a fix from Chris for an infinite loop along with fixes from
myself to prevent it entering the loop to start with (continue using
disabled channels, many thanks to Chris for his debug/test help) and a
workaround for broken APs that advertise a bad HT primary channel in
their beacons. Additionally, a fix for another attrbuf race in mac80211
and a fix to clean up properly while P2P GO interfaces go down."
Along with that...
Solomon Peachy corrects a range check in cw1200 that would lead to
a BUG_ON when starting AP mode.
Stanislaw Gruszka provides an iwl4965 patch to power-up the device
earlier (avoiding microcode errors), and another iwl4965 fix that
resets the firmware after turning rfkill off (resolving a bug in the
Red Hat Bugzilla).
Please let me know if there are problems!
John
---
The following changes since commit 3e3be275851bc6fc90bfdcd732cd95563acd982b:
ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match (2013-08-07 17:17:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 1826ff2357d69d3a2627df51e4ba07d24087b698:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-08-08 13:12:42 -0400)
----------------------------------------------------------------
Chris Wright (1):
mac80211: fix infinite loop in ieee80211_determine_chantype
Johannes Berg (5):
nl80211: fix another nl80211_fam.attrbuf race
mac80211: don't wait for TX status forever
mac80211: ignore HT primary channel while connected
cfg80211: fix P2P GO interface teardown
mac80211: continue using disabled channels while connected
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Solomon Peachy (1):
cw1200: Fix spurious BUG_ON() trigger when starting AP mode.
Stanislaw Gruszka (2):
iwl4965: set power mode early
iwl4965: reset firmware after rfkill off
drivers/net/wireless/cw1200/sta.c | 7 ++---
drivers/net/wireless/iwlegacy/4965-mac.c | 16 +++++-----
drivers/net/wireless/iwlegacy/common.c | 1 +
net/mac80211/mlme.c | 54 +++++++++++++++++++++-----------
net/wireless/core.c | 1 +
net/wireless/nl80211.c | 6 ++--
6 files changed, 52 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/cw1200/sta.c b/drivers/net/wireless/cw1200/sta.c
index 7365674..010b252 100644
--- a/drivers/net/wireless/cw1200/sta.c
+++ b/drivers/net/wireless/cw1200/sta.c
@@ -1406,11 +1406,8 @@ static void cw1200_do_unjoin(struct cw1200_common *priv)
if (!priv->join_status)
goto done;
- if (priv->join_status > CW1200_JOIN_STATUS_IBSS) {
- wiphy_err(priv->hw->wiphy, "Unexpected: join status: %d\n",
- priv->join_status);
- BUG_ON(1);
- }
+ if (priv->join_status == CW1200_JOIN_STATUS_AP)
+ goto done;
cancel_work_sync(&priv->update_filtering_work);
cancel_work_sync(&priv->set_beacon_wakeup_period_work);
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index b9b2bb5..f2ed62e 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -4460,12 +4460,12 @@ il4965_irq_tasklet(struct il_priv *il)
* is killed. Hence update the killswitch state here. The
* rfkill handler will care about restarting if needed.
*/
- if (!test_bit(S_ALIVE, &il->status)) {
- if (hw_rf_kill)
- set_bit(S_RFKILL, &il->status);
- else
- clear_bit(S_RFKILL, &il->status);
+ if (hw_rf_kill) {
+ set_bit(S_RFKILL, &il->status);
+ } else {
+ clear_bit(S_RFKILL, &il->status);
wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
+ il_force_reset(il, true);
}
handled |= CSR_INT_BIT_RF_KILL;
@@ -5334,6 +5334,9 @@ il4965_alive_start(struct il_priv *il)
il->active_rate = RATES_MASK;
+ il_power_update_mode(il, true);
+ D_INFO("Updated power mode\n");
+
if (il_is_associated(il)) {
struct il_rxon_cmd *active_rxon =
(struct il_rxon_cmd *)&il->active;
@@ -5364,9 +5367,6 @@ il4965_alive_start(struct il_priv *il)
D_INFO("ALIVE processing complete.\n");
wake_up(&il->wait_command_queue);
- il_power_update_mode(il, true);
- D_INFO("Updated power mode\n");
-
return;
restart:
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index 3195aad..b03e22e 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -4660,6 +4660,7 @@ il_force_reset(struct il_priv *il, bool external)
return 0;
}
+EXPORT_SYMBOL(il_force_reset);
int
il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ae31968..cc9e02d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,10 +31,12 @@
#include "led.h"
#define IEEE80211_AUTH_TIMEOUT (HZ / 5)
+#define IEEE80211_AUTH_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_AUTH_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_AUTH_WAIT_ASSOC (HZ * 5)
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
+#define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_ASSOC_MAX_TRIES 3
@@ -209,8 +211,9 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel *channel,
const struct ieee80211_ht_operation *ht_oper,
const struct ieee80211_vht_operation *vht_oper,
- struct cfg80211_chan_def *chandef, bool verbose)
+ struct cfg80211_chan_def *chandef, bool tracking)
{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct cfg80211_chan_def vht_chandef;
u32 ht_cfreq, ret;
@@ -229,7 +232,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan,
channel->band);
/* check that channel matches the right operating channel */
- if (channel->center_freq != ht_cfreq) {
+ if (!tracking && channel->center_freq != ht_cfreq) {
/*
* It's possible that some APs are confused here;
* Netgear WNDR3700 sometimes reports 4 higher than
@@ -237,11 +240,10 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
* since we look at probe response/beacon data here
* it should be OK.
*/
- if (verbose)
- sdata_info(sdata,
- "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
- channel->center_freq, ht_cfreq,
- ht_oper->primary_chan, channel->band);
+ sdata_info(sdata,
+ "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
+ channel->center_freq, ht_cfreq,
+ ht_oper->primary_chan, channel->band);
ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
goto out;
}
@@ -295,7 +297,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
channel->band);
break;
default:
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT operation IE has invalid channel width (%d), disable VHT\n",
vht_oper->chan_width);
@@ -304,7 +306,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_valid(&vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information is invalid, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -317,7 +319,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information doesn't match HT, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -333,18 +335,27 @@ out:
if (ret & IEEE80211_STA_DISABLE_VHT)
vht_chandef = *chandef;
+ /*
+ * Ignore the DISABLED flag when we're already connected and only
+ * tracking the APs beacon for bandwidth changes - otherwise we
+ * might get disconnected here if we connect to an AP, update our
+ * regulatory information based on the AP's country IE and the
+ * information we have is wrong/outdated and disables the channel
+ * that we're actually using for the connection to the AP.
+ */
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
- IEEE80211_CHAN_DISABLED)) {
+ tracking ? 0 :
+ IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
- goto out;
+ break;
}
ret |= chandef_downgrade(chandef);
}
- if (chandef->width != vht_chandef.width && verbose)
+ if (chandef->width != vht_chandef.width && !tracking)
sdata_info(sdata,
"capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n");
@@ -384,7 +395,7 @@ static int ieee80211_config_bw(struct ieee80211_sub_if_data *sdata,
/* calculate new channel (type) based on HT/VHT operation IEs */
flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper,
- vht_oper, &chandef, false);
+ vht_oper, &chandef, true);
/*
* Downgrade the new channel if we associated with restricted
@@ -3394,10 +3405,13 @@ static int ieee80211_probe_auth(struct ieee80211_sub_if_data *sdata)
if (tx_flags == 0) {
auth_data->timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- ifmgd->auth_data->timeout_started = true;
+ auth_data->timeout_started = true;
run_again(sdata, auth_data->timeout);
} else {
- auth_data->timeout_started = false;
+ auth_data->timeout =
+ round_jiffies_up(jiffies + IEEE80211_AUTH_TIMEOUT_LONG);
+ auth_data->timeout_started = true;
+ run_again(sdata, auth_data->timeout);
}
return 0;
@@ -3434,7 +3448,11 @@ static int ieee80211_do_assoc(struct ieee80211_sub_if_data *sdata)
assoc_data->timeout_started = true;
run_again(sdata, assoc_data->timeout);
} else {
- assoc_data->timeout_started = false;
+ assoc_data->timeout =
+ round_jiffies_up(jiffies +
+ IEEE80211_ASSOC_TIMEOUT_LONG);
+ assoc_data->timeout_started = true;
+ run_again(sdata, assoc_data->timeout);
}
return 0;
@@ -3829,7 +3847,7 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
cbss->channel,
ht_oper, vht_oper,
- &chandef, true);
+ &chandef, false);
sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss),
local->rx_chains);
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4f9f216..a8c29fa 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -765,6 +765,7 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,
cfg80211_leave_mesh(rdev, dev);
break;
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_P2P_GO:
cfg80211_stop_ap(rdev, dev);
break;
default:
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25d217d..3fcba69 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -441,10 +441,12 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
goto out_unlock;
}
*rdev = wiphy_to_dev((*wdev)->wiphy);
- cb->args[0] = (*rdev)->wiphy_idx;
+ /* 0 is the first index - add 1 to parse only once */
+ cb->args[0] = (*rdev)->wiphy_idx + 1;
cb->args[1] = (*wdev)->identifier;
} else {
- struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0]);
+ /* subtract the 1 again here */
+ struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0] - 1);
struct wireless_dev *tmp;
if (!wiphy) {
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH net-next] pptp: fix sparse pointer warning
From: Stephen Hemminger @ 2013-08-08 17:27 UTC (permalink / raw)
To: Dmitry Kozlov, David Miller; +Cc: netdev
callid_sock array is referenced via rcu_dereference and
sparse rcu checks complains about address space mismatch.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/ppp/pptp.c 2013-05-11 15:58:52.472353116 -0700
+++ b/drivers/net/ppp/pptp.c 2013-07-30 14:40:52.602172742 -0700
@@ -47,7 +47,7 @@
#define MAX_CALLID 65535
static DECLARE_BITMAP(callid_bitmap, MAX_CALLID + 1);
-static struct pppox_sock **callid_sock;
+static struct pppox_sock __rcu **callid_sock;
static DEFINE_SPINLOCK(chan_lock);
^ permalink raw reply
* Re: [PATCH v3 4/4] USBNET: ax88179_178a: enable tso if usb host supports sg dma
From: Grant Grundler @ 2013-08-08 17:25 UTC (permalink / raw)
To: Ming Lei
Cc: Eric Dumazet, David S. Miller, Greg Kroah-Hartman, Oliver Neukum,
Sarah Sharp, netdev, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Ben Hutchings, Alan Stern, Freddy Xin
In-Reply-To: <CACVXFVOOQZ8mtDXtCE669vEo=jA56g-ADzTZkGLLupZ5D4Z==A@mail.gmail.com>
On Tue, Aug 6, 2013 at 5:41 PM, Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> On Wed, Aug 7, 2013 at 1:09 AM, Grant Grundler <grundler-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
...
>> Following that logic, shouldn't all the features/hw_features settings
>> be removed from reset code path?
>
> This patch won't touch other settings because that isn't related with
> this patch.
Sorry - I didn't mean to imply your patch should do this. I was hoping
for a yes/no answer from you, Eric, or Dave.
...
>> I'll note that any "hiccup" in the USB side that causes the device to
>> get dropped and re-probed will cause the same symptom. There is
>
> I am afraid that PCI network devices' setting still won't survive unbound&
> re-probed, will they?
Correct - but PCI isn't as prone to "dropping off the bus" like USB
is. Master aborts on some PCI systems is a "Fatal Exception" and AFAIK
that's never been true for any USB device.
>> nothing the driver can do about it in this case. Perhaps add some udev
>> rules to preserve ethtool settings the same way I've seen udev rules
>> to record MAC address to enumerate devices (eth0, eth1, etc.)
>
> Some usbnet devices may have random MAC address assigned in every
> probe().
Ugh - ok. Then those scripts are broken for those devices. C'est la Vie.
My point is the mechanism (udev) exists to preserve any settings
ethtool can read/record the state of.
cheers,
grant
ps. thanks again for posting the USBNET sg dma series - I will likely
back port those to our chromeos-3.8 tree in the near future.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2][net-next] gianfar: Add ethtool -A support for pause frame
From: Claudiu Manoil @ 2013-08-08 17:10 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David S. Miller
In-Reply-To: <1375902775.2644.98.camel@deadeye.wl.decadent.org.uk>
Hi Ben,
On 8/7/2013 10:12 PM, Ben Hutchings wrote:
> On Wed, 2013-08-07 at 13:24 +0300, Claudiu Manoil wrote:
>> Allow Rx/Tx pause frame configuration via ethtool.
>> The gfar devices feature link autonegotioation by default.
>
> So the MAC configuration bits are actually copied to the PHY autoneg
> basic page, and then the PHY autoneg result is automatically used by the
> MAC?
>
> This is of course possible to do in hardware, but... since this MAC is
> not smart enough to ignore pause settings when running in half-duplex
> mode, I seriously doubt it is doing all this by itself.
>
I just wanted to say actually that the pause->autoneg parameter is not
needed by the gianfar driver, but I didn't know what to do with it in
get_pauseparam(), apparently pause->autoneg needs a value (or can
simply ignore this param?).
I don't see what autonegotiation has to do with enabling/disabling
pause frame generation in this case. My understanding is that link
autonegotiation is taken care somewhere else, by the phy state machine.
Each time this happens, the gianfar driver gets notified via the
adjust_link() hook that it implements and makes the necessary configs
in the mac registers.
Besides, autoneg info is already being displayed by ethtool (see
print below).
So I don't understand the use of pause->autoneg. What should I do with
it?
Thanks,
Claudiu
____
root@p1020rdb-pd:~# ethtool eth2
Settings for eth2:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
>> The device is being configured with the new pause frame
>> parameters if the link is up, depending on link duplex (no
>> pause frames for half-duplex links), or during link autoneg
>> (see adjust_link()).
> [...]
>> --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
>> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
>> @@ -535,6 +535,34 @@ static int gfar_sringparam(struct net_device *dev,
>> return err;
>> }
>>
>> +static void gfar_gpauseparam(struct net_device *dev,
>> + struct ethtool_pauseparam *pause)
>> +{
>> + struct gfar_private *priv = netdev_priv(dev);
>> +
>> + pause->autoneg = AUTONEG_ENABLE;
>> + if (priv->rx_pause)
>> + pause->rx_pause = 1;
>> + if (priv->tx_pause)
>> + pause->tx_pause = 1;
>> +}
>> +
>> +static int gfar_spauseparam(struct net_device *dev,
>> + struct ethtool_pauseparam *pause)
>> +{
>> + struct gfar_private *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phydev;
>
> You need to reject an unsupported setting of pause->autoneg here.
>
> Ben.
>
>> + priv->rx_pause = !!pause->rx_pause;
>> + priv->tx_pause = !!pause->tx_pause;
>> +
>> + /* update h/w settings, if link is up */
>> + if (phydev && phydev->link)
>> + gfar_configure_pause(priv, !!phydev->duplex);
>> +
>> + return 0;
>> +}
>> +
>> int gfar_set_features(struct net_device *dev, netdev_features_t features)
>> {
>> struct gfar_private *priv = netdev_priv(dev);
> [...]
>
^ permalink raw reply
* [PATCH net-next v2 0/6] bonding: remove bond->vlan_list
From: Veaceslav Falico @ 2013-08-08 16:57 UTC (permalink / raw)
To: netdev
Cc: Jay Vosburgh, Andy Gospodarek, Patrick McHardy, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico
RFC -> v1: Got some feedback from Nikolay Aleksandrov (privately), tried to
address it, also fixed some bugs that I've found on the way. I
think it's ready to be considered a patchset for
review/inclusion in net-next.
v1 -> v2: Remove ASSERT_RTNL() from vlan_uses_dev(), cause it can be
already called under rcu, without rtnl. Don't check for master
device in __vlan_find_dev_next(), otherwise we won't be able to
work in situations when a device has both vlans and master
device. Properly init vlan_dev in bond_has_this_ip() before
using (sigh). There was a proposal of making a macro
"dev_for_each_vlan_from(dev, vlan_dev, i, from)", which would
use __vlan_find_dev_deep() inside, with its strong and weak
parts, but I've decided to stick to the "while (dev = next())"
scheme currently - it might be added anytime, and now the only
user (bonding) doesn't really need it.
The aim of this patchset is to remove bond->vlan_list completely, and use
8021q's standard functions instead of it.
The patchset is on top of Nik's latest two patches:
[net-next,v2,1/2] bonding: change the bond's vlan syncing functions with
the standard ones
[net-next,v2,2/2] bonding: unwind on bond_add_vlan failure
First two patches add two helper functions to vlan code:
bonding: add rcu to vlan_uses_dev() and make bond_vlan_used() use it
Here we change vlan_uses_dev() to be able to work under both rtnl
and rcu, and use it under rcu_read_lock() in bond_vlan_used().
vlan: add __vlan_find_dev_next()
This function takes dev and vlan_dev and returns the next vlan dev
that uses this dev. It can be used to cycle through the vlan list,
and not only by bonding - but by any network driver that uses its
private vlan list.
Next four patches actually convert bonding to use the new
functions/approach and remove the vlan_list completely.
This patchset solves several issues with bonding, simplify it overall,
RCUify further and add infrastructure to anyone else who'd like to use
8021q standard functions instead of their own vlan_list, which is quite
common amongst network drivers currently.
I'm testing it continuously currently, no issues found, will update on
anything.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Patrick McHardy <kaber@trash.net>
CC: "David S. Miller" <davem@davemloft.net>
CC: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_alb.c | 48 ++++++++----
drivers/net/bonding/bond_alb.h | 2 +-
drivers/net/bonding/bond_main.c | 163 ++++++---------------------------------
drivers/net/bonding/bonding.h | 16 ++--
include/linux/if_vlan.h | 8 ++
net/8021q/vlan.h | 6 +-
net/8021q/vlan_core.c | 36 ++++++++-
7 files changed, 115 insertions(+), 164 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox