* Re: [PATCH net-next 0/2] Move hwmon support out of switch and into PHYs.
From: Florian Fainelli @ 2017-01-11 17:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: David Miller, netdev, Guenter Roeck
In-Reply-To: <20170111173741.GB13033@lunn.ch>
On 01/11/2017 09:37 AM, Andrew Lunn wrote:
> On Wed, Jan 11, 2017 at 12:06:11PM -0500, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>>> Marvell Ethernet switches contain temperature sensors. They are inside
>>> the embedded PHYs. Move the code into the PHY driver, so that discrete
>>> PHY drivers also export there temperature sensor.
>>
>> This message is not correct. The Marvell Ethernet switches contain only
>> one temperature sensor for the entire chip (please adjust the cover
>> letter and commit messages when you respin.)
>
> Agreed.
>
>> The temperature and threshold are accessed through the embedded PHY
>> registers of any port, as long as the port is not disabled.
>
> This is not correct. Each PHY has its own threshold registers. They
> can be different, even if they are applied to one shared sensor. One
> PHY can be in alarm state, while others are not, due to different
> thresholds.
>
>> Even unlikely to be used, an interrupt can be generated when the
>> temperature exceeds a certain threshold. It should be enabled on only
>> one port at a time since there is only one temperature sensor.
>
> Actually, since each PHY can have a different threshold, it would in
> theory be possible to have different PHYs generating interrupts at
> different thresholds.
>
> However, at the moment, there is no code to enable interrupts for
> temperature alarms. I also don't see any need to add such code, since
> there is nowhere in HWMON to actively report such an alarm condition.
Are not the *_alarm attributes specifically designed to report such
things? See Documentation/hwmon/sysfs-interface
>
> There is potentially an issue sometime down the road, if we were to
> enable the temperature threshold interrupt. It is not clear what
> happens if two PHYs have the same threshold conditions and this
> threshold is crossed. Do all PHYs trigger an interrupt? Does only one?
> Do none? I would prefer investigating and solving such issues if and
> when it is decided to enable the interrupt.
>
>> To sum up briefly, the temperature chip is physically inside the switch
>> chip, but its access is via the embedded PHYs of the switch.
>
> There is one temperature sensor in the chip, which each embedded PHY
> shares for reporting the current temperature. It appears that
> everything but the sensor is duplicated in each embedded PHY.
If that is the case, should we have a way to make the HWMON attributes
be associated with the switch device while still calling into the PHY
driver to do the actual temperature readings and such? Right now, it
sounds like we will have a duplication of HWMON attributes created for
every port of the switch that is connecting to the Marvell PHY driver.
--
Florian
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2017-01-11 17:53 UTC (permalink / raw)
To: David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20170111.102208.1500085515205459622.davem@davemloft.net>
Thanks. Pulled, going through my usual allmodconfig test-build before
being pushed out,
Linus
On Wed, Jan 11, 2017 at 7:22 AM, David Miller <davem@davemloft.net> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
^ permalink raw reply
* Re: [PATCH net-next 0/2] Move hwmon support out of switch and into PHYs.
From: Andrew Lunn @ 2017-01-11 17:37 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, netdev, Florian Fainelli, Guenter Roeck
In-Reply-To: <87vatljzlo.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Wed, Jan 11, 2017 at 12:06:11PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > Marvell Ethernet switches contain temperature sensors. They are inside
> > the embedded PHYs. Move the code into the PHY driver, so that discrete
> > PHY drivers also export there temperature sensor.
>
> This message is not correct. The Marvell Ethernet switches contain only
> one temperature sensor for the entire chip (please adjust the cover
> letter and commit messages when you respin.)
Agreed.
> The temperature and threshold are accessed through the embedded PHY
> registers of any port, as long as the port is not disabled.
This is not correct. Each PHY has its own threshold registers. They
can be different, even if they are applied to one shared sensor. One
PHY can be in alarm state, while others are not, due to different
thresholds.
> Even unlikely to be used, an interrupt can be generated when the
> temperature exceeds a certain threshold. It should be enabled on only
> one port at a time since there is only one temperature sensor.
Actually, since each PHY can have a different threshold, it would in
theory be possible to have different PHYs generating interrupts at
different thresholds.
However, at the moment, there is no code to enable interrupts for
temperature alarms. I also don't see any need to add such code, since
there is nowhere in HWMON to actively report such an alarm condition.
There is potentially an issue sometime down the road, if we were to
enable the temperature threshold interrupt. It is not clear what
happens if two PHYs have the same threshold conditions and this
threshold is crossed. Do all PHYs trigger an interrupt? Does only one?
Do none? I would prefer investigating and solving such issues if and
when it is decided to enable the interrupt.
> To sum up briefly, the temperature chip is physically inside the switch
> chip, but its access is via the embedded PHYs of the switch.
There is one temperature sensor in the chip, which each embedded PHY
shares for reporting the current temperature. It appears that
everything but the sensor is duplicated in each embedded PHY.
Andrew
^ permalink raw reply
* Re: TCP using IPv4-mapped IPv6 address as source
From: Jonathan T. Leighton @ 2017-01-11 17:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <1484151607.21472.55.camel@edumazet-glaptop3.roam.corp.google.com>
On 1/11/17 11:20 AM, Eric Dumazet wrote:
> On Thu, 2017-01-05 at 16:25 -0500, Jonathan T. Leighton wrote:
>> I've observed TCP using an IPv4-mapped IPv6 address as the source
>> address, which I believe contradicts
>> https://tools.ietf.org/html/rfc6890#page-14 (BCP 153). This occurs when
>> an IPv6 TCP socket, bound to a local IPv4-mapped IPv6 address, attempts
>> to connect to a remote IPv6 address. Presumable connect() should return
>> EAFNOSUPPORT in this case. Please advise me if this is not to
>> appropriate list to report this.
> Hi Jonathan
>
> I believe your concern makes sense.
> Do you have a patch to address this issue ?
Thanks for responding Eric. I have limited experience with kernel
patches. Nevertheless, unless there's someone with the experience and
time to jump on this, I'm interested in taking a crack at it. I think
the issue certainly warrants attention: instead of returning immediately
with EAFNOSUPPPORT, connect() retransmits its SYN 6 times, ultimately
returning ETIMEDOUT after 127 sec (1+2+4+...+64).
> Thanks
>
>
^ permalink raw reply
* Re: probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo
From: Denys Fedoryshchenko @ 2017-01-11 17:31 UTC (permalink / raw)
To: Guillaume Nault
Cc: Linux Kernel Network Developers, linux-kernel, Pablo Neira Ayuso,
netfilter-devel
In-Reply-To: <20170111172243.5yqliuverfhchlju@alphalink.fr>
On 2017-01-11 19:22, Guillaume Nault wrote:
> Cc: netfilter-devel@vger.kernel.org, I'm afraid I'll need some help
> for this case.
>
> On Sat, Dec 17, 2016 at 09:48:13PM +0200, Denys Fedoryshchenko wrote:
>> Hi,
>>
>> I posted recently several netfilter related crashes, didn't got any
>> answers,
>> one of them started to happen quite often on loaded NAT (17Gbps),
>> so after trying endless ways to make it stable, i found out that in
>> backtrace i can often see timers, and this bug probably appearing on
>> older
>> releases,
>> i've seen such backtrace with timer fired for conntrack on them.
>> I disabled Intel turbo for cpus on this loaded NAT, and voila, panic
>> disappeared for 2nd day!
>> * by wrmsr -a 0x1a0 0x4000850089
>> I am not sure timers is the reason, but probably turbo creating some
>> condition for bug.
>>
>
> Re-formatting the stack-trace for easier reference:
>
> [28904.162607] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000008
> [28904.163210] IP: [<ffffffffa00ab07d>]
> nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
> [28904.163745] PGD 0
> [28904.164058] Oops: 0002 [#1] SMP
> [28904.164323] Modules linked in: nf_nat_pptp nf_nat_proto_gre
> xt_TCPMSS xt_connmark ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat
> xt_rateest xt_RATEEST nf_conntrack_pptp nf_conntrack_proto_gre xt_CT
> xt_set xt_hl xt_tcpudp ip_set_hash_net ip_set nfnetlink iptable_raw
> iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables
> netconsole configfs 8021q garp mrp stp llc bonding ixgbe dca
> [28904.168132] CPU: 27 PID: 0 Comm: swapper/27 Not tainted
> 4.8.14-build-0124 #2
> [28904.168398] Hardware name: Intel Corporation S2600WTT/S2600WTT,
> BIOS SE5C610.86B.01.01.1008.031920151331 03/19/2015
> [28904.168853] task: ffff885fa42e8c40 task.stack: ffff885fa42f0000
> [28904.169114] RIP: 0010:[<ffffffffa00ab07d>] [<ffffffffa00ab07d>]
> nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
> [28904.169643] RSP: 0018:ffff885fbccc3dd8 EFLAGS: 00010246
> [28904.169901] RAX: 0000000000000000 RBX: ffff885fbccc0000 RCX:
> ffff885fbccc0010
> [28904.170169] RDX: ffff885f87a1c150 RSI: 0000000000000142 RDI:
> ffff885fbccc0000
> [28904.170437] RBP: ffff885fbccc3de8 R08: 00000000cbdee177 R09:
> 0000000000000100
> [28904.170704] R10: ffff885fbccc3dd0 R11: ffffffff820050c0 R12:
> ffff885f87a1c140
> [28904.170971] R13: 000000000005d948 R14: 00000000000ea942 R15:
> ffff885f87a1c160
> [28904.171237] FS: 0000000000000000(0000) GS:ffff885fbccc0000(0000)
> knlGS:0000000000000000
> [28904.171688] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [28904.171964] CR2: 0000000000000008 CR3: 000000607f006000 CR4:
> 00000000001406e0
> [28904.172231] Stack:
> [28904.172482] ffff885f87a1c140 ffffffff820a1405 ffff885fbccc3e28
> ffffffffa00abb30
> [28904.173182] 00000002820a1405 ffff885f87a1c140 ffff885f99a28201
> 0000000000000000
> [28904.173884] 0000000000000000 ffffffff820050c8 ffff885fbccc3e58
> ffffffffa00abc62
> [28904.174585] Call Trace:
> [28904.174835] <IRQ>
> [28904.174912] [<ffffffffa00abb30>] nf_ct_delete_from_lists+0xc9/0xf2
> [nf_conntrack]
> [28904.175613] [<ffffffffa00abc62>] nf_ct_delete+0x109/0x12c
> [nf_conntrack]
> [28904.175894] [<ffffffffa00abc85>] ? nf_ct_delete+0x12c/0x12c
> [nf_conntrack]
> [28904.176169] [<ffffffffa00abc92>] death_by_timeout+0xd/0xf
> [nf_conntrack]
> [28904.176443] [<ffffffff81109922>] call_timer_fn.isra.5+0x17/0x6b
> [28904.176714] [<ffffffff811099e5>] expire_timers+0x6f/0x7e
> [28904.176975] [<ffffffff81109add>] run_timer_softirq+0x69/0x8b
> [28904.177238] [<ffffffff811141bb>] ?
> clockevents_program_event+0xd0/0xe8
> [28904.177504] [<ffffffff810d000c>] __do_softirq+0xbd/0x1aa
> [28904.177765] [<ffffffff810d0240>] irq_exit+0x37/0x7c
> [28904.178026] [<ffffffff8102c519>]
> smp_trace_apic_timer_interrupt+0x7b/0x88
> [28904.178300] [<ffffffff8102c52f>] smp_apic_timer_interrupt+0x9/0xb
> [28904.178565] [<ffffffff818f4f1c>] apic_timer_interrupt+0x7c/0x90
> [28904.178835] <EOI>
> [28904.178907] [<ffffffff8101b929>] ? mwait_idle+0x64/0x7a
> [28904.179436] [<ffffffff810e3d8f>] ?
> atomic_notifier_call_chain+0x13/0x15
> [28904.179712] [<ffffffff8101bd04>] arch_cpu_idle+0xa/0xc
> [28904.179976] [<ffffffff810f7c3d>] default_idle_call+0x27/0x29
> [28904.180244] [<ffffffff810f7d5c>] cpu_startup_entry+0x11d/0x1c7
> [28904.180508] [<ffffffff8102af13>] start_secondary+0xe8/0xeb
> [28904.180767] Code: 80 2f 0b 82 48 89 df e8 da 90 84 e1 48 8b 43 10
> 49 8d 54 24 10 48 8d 4b 10 49 89 4c 24 18 a8 01 49 89 44 24 10 48 89
> 53 10 75 04 <89> 50 08 c6 03 00 5b 41 5c 5d c3 48 8b 05 10 be 00 00 89
> f6
> [28904.185546] RIP [<ffffffffa00ab07d>]
> nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
> [28904.186065] RSP <ffff885fbccc3dd8>
> [28904.186319] CR2: 0000000000000008
> [28904.186593] ---[ end trace 35cbc6c885a5c2d8 ]---
> [28904.186860] Kernel panic - not syncing: Fatal exception in interrupt
> [28904.187155] Kernel Offset: disabled
> [28904.187419] Rebooting in 5 seconds..
> [28909.193662] ACPI MEMORY or I/O RESET_REG.
>
> And here's decodecode's output:
>
> All code
> ========
> 0: 80 2f 0b subb $0xb,(%rdi)
> 3: 82 (bad)
> 4: 48 89 df mov %rbx,%rdi
> 7: e8 da 90 84 e1 callq 0xffffffffe18490e6
> c: 48 8b 43 10 mov 0x10(%rbx),%rax
> 10: 49 8d 54 24 10 lea 0x10(%r12),%rdx
> 15: 48 8d 4b 10 lea 0x10(%rbx),%rcx
> 19: 49 89 4c 24 18 mov %rcx,0x18(%r12)
> 1e: a8 01 test $0x1,%al
> 20: 49 89 44 24 10 mov %rax,0x10(%r12)
> 25: 48 89 53 10 mov %rdx,0x10(%rbx)
> 29: 75 04 jne 0x2f
> 2b:* 89 50 08 mov %edx,0x8(%rax) <--
> trapping instruction
> 2e: c6 03 00 movb $0x0,(%rbx)
> 31: 5b pop %rbx
> 32: 41 5c pop %r12
> 34: 5d pop %rbp
> 35: c3 retq
> 36: 48 8b 05 10 be 00 00 mov 0xbe10(%rip),%rax #
> 0xbe4d
> 3d: 89 f6 mov %esi,%esi
>
>
> Fortunately, nf_ct_add_to_dying_list() is small:
>
> static void nf_ct_add_to_dying_list(struct nf_conn *ct)
> {
> struct ct_pcpu *pcpu;
>
> /* add this conntrack to the (per cpu) dying list */
> ct->cpu = smp_processor_id();
> pcpu = per_cpu_ptr(nf_ct_net(ct)->ct.pcpu_lists, ct->cpu);
>
> spin_lock(&pcpu->lock);
> hlist_nulls_add_head(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
> &pcpu->dying);
> spin_unlock(&pcpu->lock);
> }
>
>
> So "callq 0xffffffffe18490e6" probably refers to the
> "spin_lock(&pcpu->lock)" call, which means RBX == pcpu.
> Considering the offsets used, we certainly have R12 == ct.
>
> From there, we can interpret the assembly code as follow:
> Original register values:
> rbx: pcpu
> 0x10(%rbx): &pcpu->dying.first
>
> r12: ct
> 0x10(%r12): &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
> 0x18(%r12): &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev
>
> Code:
> mov %rbx,%rdi ; RBX == pcpu
> callq 0xffffffffe18490e6 ; spin_lock(&pcpu->lock)
>
> mov 0x10(%rbx),%rax ; rax = pcpu->dying.first
> lea 0x10(%r12),%rdx ; rdx =
> &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
> lea 0x10(%rbx),%rcx ; rcx = &pcpu->dying.first
>
> mov %rcx,0x18(%r12) ;
> ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = &pcpu->dying.first
>
> test $0x1,%al ; test: is_a_nulls(pcpu->dying.first)
>
> mov %rax,0x10(%r12) ;
> &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next = pcpu->dying.first
> mov %rdx,0x10(%rbx) ; pcpu->dying.first =
> &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode
>
> jne 0x2f ; jump if is_a_nulls(pcpu->dying.first)
>
> mov %edx,0x8(%rax) <-- trapping instruction, RAX == 0
>
>
> So RAX, which has been set to pcpu->dying.first, is NULL. The
> pcpu->dying list is thus corrupted.
>
> I'm not familiar with nf_conntrack_core.c and I still can't figure out
> how we could end up with pcpu->dying.first being a NULL pointer.
>
> Probably there's a race somewhere and activating turbo mode makes it
> more likely to happen. But still, I'd expect a locking or RCU issue to
> give us garbage here, not a plain NULL pointer.
>
> Does anyone have a clue?
Maybe it will give any hints, and why not that many people facing
This server is NUMA (2xE5 cpu), with dual ixgbe cards (2x10G), with rps
enabled
I tried to change timers from TSC to HPET, didnt helped at all.
I noticed similar (but not same place) error happen on this load on
older kernel as well, latest stable 4.4 on that moment.
If i will gain a bit stability for few days, i will try to turn off one
of CPU to make it single NUMA node, for testing, if NUMA affects anyhow,
but it might just increase chance of race condition as turbo.
^ permalink raw reply
* Re: [PATCH net-next 6/7] net: ipv4: return route match in GETROUTE request
From: David Ahern @ 2017-01-11 17:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170110.204034.925090776724245879.davem@davemloft.net>
On 1/10/17 6:40 PM, David Miller wrote:
> From: David Ahern <dsa@cumulusnetworks.com>
> Date: Mon, 9 Jan 2017 13:32:50 -0800
>
>> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
>> index 8c93ad1ef9ab..471384b72cea 100644
>> --- a/include/uapi/linux/rtnetlink.h
>> +++ b/include/uapi/linux/rtnetlink.h
>> @@ -319,6 +319,8 @@ enum rtattr_type_t {
>> RTA_EXPIRES,
>> RTA_PAD,
>> RTA_UID,
>> + RTA_ROUTE_GET, /* nested attribute; route spec for RTM_GETROUTE */
>> + RTA_ROUTE_GET_RTM, /* struct rtmsg for nested spec */
>> __RTA_MAX
>> };
>
> The nested attribute and the attributes within that nested attribute
> live in two different attribute number namespaces.
>
> So usually we allocate the nested attribute at the top level in the
> main enumeration. Then the elements within the nested attribute
> get allocated with a new enumeration created specifically for items
> inside that nested attribute.
>
> For example, RTA_METRICS --> RTAX_*
>
> So please arrange things this way.
ok. I did it this way for code re-use since the nested attribute is a route spec. If separate attributes for the nest are desired I'll do that.
^ permalink raw reply
* Re: probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo
From: Guillaume Nault @ 2017-01-11 17:22 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Linux Kernel Network Developers, linux-kernel, Pablo Neira Ayuso,
netfilter-devel
In-Reply-To: <9be92e4dc7d83096cbcdaae1a3f77bd3@nuclearcat.com>
Cc: netfilter-devel@vger.kernel.org, I'm afraid I'll need some help
for this case.
On Sat, Dec 17, 2016 at 09:48:13PM +0200, Denys Fedoryshchenko wrote:
> Hi,
>
> I posted recently several netfilter related crashes, didn't got any answers,
> one of them started to happen quite often on loaded NAT (17Gbps),
> so after trying endless ways to make it stable, i found out that in
> backtrace i can often see timers, and this bug probably appearing on older
> releases,
> i've seen such backtrace with timer fired for conntrack on them.
> I disabled Intel turbo for cpus on this loaded NAT, and voila, panic
> disappeared for 2nd day!
> * by wrmsr -a 0x1a0 0x4000850089
> I am not sure timers is the reason, but probably turbo creating some
> condition for bug.
>
Re-formatting the stack-trace for easier reference:
[28904.162607] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[28904.163210] IP: [<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[28904.163745] PGD 0
[28904.164058] Oops: 0002 [#1] SMP
[28904.164323] Modules linked in: nf_nat_pptp nf_nat_proto_gre xt_TCPMSS xt_connmark ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat xt_rateest xt_RATEEST nf_conntrack_pptp nf_conntrack_proto_gre xt_CT xt_set xt_hl xt_tcpudp ip_set_hash_net ip_set nfnetlink iptable_raw iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables netconsole configfs 8021q garp mrp stp llc bonding ixgbe dca
[28904.168132] CPU: 27 PID: 0 Comm: swapper/27 Not tainted 4.8.14-build-0124 #2
[28904.168398] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.1008.031920151331 03/19/2015
[28904.168853] task: ffff885fa42e8c40 task.stack: ffff885fa42f0000
[28904.169114] RIP: 0010:[<ffffffffa00ab07d>] [<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[28904.169643] RSP: 0018:ffff885fbccc3dd8 EFLAGS: 00010246
[28904.169901] RAX: 0000000000000000 RBX: ffff885fbccc0000 RCX: ffff885fbccc0010
[28904.170169] RDX: ffff885f87a1c150 RSI: 0000000000000142 RDI: ffff885fbccc0000
[28904.170437] RBP: ffff885fbccc3de8 R08: 00000000cbdee177 R09: 0000000000000100
[28904.170704] R10: ffff885fbccc3dd0 R11: ffffffff820050c0 R12: ffff885f87a1c140
[28904.170971] R13: 000000000005d948 R14: 00000000000ea942 R15: ffff885f87a1c160
[28904.171237] FS: 0000000000000000(0000) GS:ffff885fbccc0000(0000) knlGS:0000000000000000
[28904.171688] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[28904.171964] CR2: 0000000000000008 CR3: 000000607f006000 CR4: 00000000001406e0
[28904.172231] Stack:
[28904.172482] ffff885f87a1c140 ffffffff820a1405 ffff885fbccc3e28 ffffffffa00abb30
[28904.173182] 00000002820a1405 ffff885f87a1c140 ffff885f99a28201 0000000000000000
[28904.173884] 0000000000000000 ffffffff820050c8 ffff885fbccc3e58 ffffffffa00abc62
[28904.174585] Call Trace:
[28904.174835] <IRQ>
[28904.174912] [<ffffffffa00abb30>] nf_ct_delete_from_lists+0xc9/0xf2 [nf_conntrack]
[28904.175613] [<ffffffffa00abc62>] nf_ct_delete+0x109/0x12c [nf_conntrack]
[28904.175894] [<ffffffffa00abc85>] ? nf_ct_delete+0x12c/0x12c [nf_conntrack]
[28904.176169] [<ffffffffa00abc92>] death_by_timeout+0xd/0xf [nf_conntrack]
[28904.176443] [<ffffffff81109922>] call_timer_fn.isra.5+0x17/0x6b
[28904.176714] [<ffffffff811099e5>] expire_timers+0x6f/0x7e
[28904.176975] [<ffffffff81109add>] run_timer_softirq+0x69/0x8b
[28904.177238] [<ffffffff811141bb>] ? clockevents_program_event+0xd0/0xe8
[28904.177504] [<ffffffff810d000c>] __do_softirq+0xbd/0x1aa
[28904.177765] [<ffffffff810d0240>] irq_exit+0x37/0x7c
[28904.178026] [<ffffffff8102c519>] smp_trace_apic_timer_interrupt+0x7b/0x88
[28904.178300] [<ffffffff8102c52f>] smp_apic_timer_interrupt+0x9/0xb
[28904.178565] [<ffffffff818f4f1c>] apic_timer_interrupt+0x7c/0x90
[28904.178835] <EOI>
[28904.178907] [<ffffffff8101b929>] ? mwait_idle+0x64/0x7a
[28904.179436] [<ffffffff810e3d8f>] ? atomic_notifier_call_chain+0x13/0x15
[28904.179712] [<ffffffff8101bd04>] arch_cpu_idle+0xa/0xc
[28904.179976] [<ffffffff810f7c3d>] default_idle_call+0x27/0x29
[28904.180244] [<ffffffff810f7d5c>] cpu_startup_entry+0x11d/0x1c7
[28904.180508] [<ffffffff8102af13>] start_secondary+0xe8/0xeb
[28904.180767] Code: 80 2f 0b 82 48 89 df e8 da 90 84 e1 48 8b 43 10 49 8d 54 24 10 48 8d 4b 10 49 89 4c 24 18 a8 01 49 89 44 24 10 48 89 53 10 75 04 <89> 50 08 c6 03 00 5b 41 5c 5d c3 48 8b 05 10 be 00 00 89 f6
[28904.185546] RIP [<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[28904.186065] RSP <ffff885fbccc3dd8>
[28904.186319] CR2: 0000000000000008
[28904.186593] ---[ end trace 35cbc6c885a5c2d8 ]---
[28904.186860] Kernel panic - not syncing: Fatal exception in interrupt
[28904.187155] Kernel Offset: disabled
[28904.187419] Rebooting in 5 seconds..
[28909.193662] ACPI MEMORY or I/O RESET_REG.
And here's decodecode's output:
All code
========
0: 80 2f 0b subb $0xb,(%rdi)
3: 82 (bad)
4: 48 89 df mov %rbx,%rdi
7: e8 da 90 84 e1 callq 0xffffffffe18490e6
c: 48 8b 43 10 mov 0x10(%rbx),%rax
10: 49 8d 54 24 10 lea 0x10(%r12),%rdx
15: 48 8d 4b 10 lea 0x10(%rbx),%rcx
19: 49 89 4c 24 18 mov %rcx,0x18(%r12)
1e: a8 01 test $0x1,%al
20: 49 89 44 24 10 mov %rax,0x10(%r12)
25: 48 89 53 10 mov %rdx,0x10(%rbx)
29: 75 04 jne 0x2f
2b:* 89 50 08 mov %edx,0x8(%rax) <-- trapping instruction
2e: c6 03 00 movb $0x0,(%rbx)
31: 5b pop %rbx
32: 41 5c pop %r12
34: 5d pop %rbp
35: c3 retq
36: 48 8b 05 10 be 00 00 mov 0xbe10(%rip),%rax # 0xbe4d
3d: 89 f6 mov %esi,%esi
Fortunately, nf_ct_add_to_dying_list() is small:
static void nf_ct_add_to_dying_list(struct nf_conn *ct)
{
struct ct_pcpu *pcpu;
/* add this conntrack to the (per cpu) dying list */
ct->cpu = smp_processor_id();
pcpu = per_cpu_ptr(nf_ct_net(ct)->ct.pcpu_lists, ct->cpu);
spin_lock(&pcpu->lock);
hlist_nulls_add_head(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
&pcpu->dying);
spin_unlock(&pcpu->lock);
}
So "callq 0xffffffffe18490e6" probably refers to the
"spin_lock(&pcpu->lock)" call, which means RBX == pcpu.
Considering the offsets used, we certainly have R12 == ct.
>From there, we can interpret the assembly code as follow:
Original register values:
rbx: pcpu
0x10(%rbx): &pcpu->dying.first
r12: ct
0x10(%r12): &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
0x18(%r12): &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev
Code:
mov %rbx,%rdi ; RBX == pcpu
callq 0xffffffffe18490e6 ; spin_lock(&pcpu->lock)
mov 0x10(%rbx),%rax ; rax = pcpu->dying.first
lea 0x10(%r12),%rdx ; rdx = &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
lea 0x10(%rbx),%rcx ; rcx = &pcpu->dying.first
mov %rcx,0x18(%r12) ; ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = &pcpu->dying.first
test $0x1,%al ; test: is_a_nulls(pcpu->dying.first)
mov %rax,0x10(%r12) ; &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next = pcpu->dying.first
mov %rdx,0x10(%rbx) ; pcpu->dying.first = &ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode
jne 0x2f ; jump if is_a_nulls(pcpu->dying.first)
mov %edx,0x8(%rax) <-- trapping instruction, RAX == 0
So RAX, which has been set to pcpu->dying.first, is NULL. The
pcpu->dying list is thus corrupted.
I'm not familiar with nf_conntrack_core.c and I still can't figure out
how we could end up with pcpu->dying.first being a NULL pointer.
Probably there's a race somewhere and activating turbo mode makes it
more likely to happen. But still, I'd expect a locking or RCU issue to
give us garbage here, not a plain NULL pointer.
Does anyone have a clue?
^ permalink raw reply
* Re: [PATCH net-next 5/6] bnxt_en: Pass RoCE app priority to firmware.
From: Michael Chan @ 2017-01-11 17:17 UTC (permalink / raw)
To: David Miller, Doug Ledford, Selvin Xavier; +Cc: Netdev
In-Reply-To: <20170111.104624.1616254027007040020.davem@davemloft.net>
On Wed, Jan 11, 2017 at 7:46 AM, David Miller <davem@davemloft.net> wrote:
> From: Michael Chan <michael.chan@broadcom.com>
> Date: Tue, 10 Jan 2017 20:12:38 -0500
>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
>> index 35a0d28..f2630cc 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
>> @@ -36,6 +36,9 @@ struct bnxt_cos2bw_cfg {
>>
>> #define HWRM_STRUCT_DATA_SUBTYPE_HOST_OPERATIONAL 0x0300
>>
>> +#define ETH_P_ROCE 0x8915
>
> There's also a similar define in the qedr infiniband driver, this doesn't
> make much sense.
>
> Please add this to if_ether.h, and reference it from there in the drivers.
>
My colleague informed me that he has submitted a patch to do that
through the rdma tree:
http://marc.info/?l=linux-rdma&m=148217575500983&w=2
But it hasn't been merged yet. I can drop this patch now and wait for
the RDMA patch to show up on net-next. Or I make the change later to
use the common define when the RDMA patch is merged. Thanks.
^ permalink raw reply
* [PATCH net v2] netvsc: add rcu_read locking to netvsc callback
From: Stephen Hemminger @ 2017-01-11 17:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
The receive callback (in tasklet context) is using RCU to get reference
to associated VF network device but this is not safe. RCU read lock
needs to be held. Found by running with full lockdep debugging
enabled.
Fixes: f207c10d9823 ("hv_netvsc: use RCU to protect vf_netdev")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
v2 - fix commit message
drivers/net/hyperv/netvsc_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index c9414c054852..fcab8019dda0 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -659,6 +659,7 @@ int netvsc_recv_callback(struct hv_device *device_obj,
* policy filters on the host). Deliver these via the VF
* interface in the guest.
*/
+ rcu_read_lock();
vf_netdev = rcu_dereference(net_device_ctx->vf_netdev);
if (vf_netdev && (vf_netdev->flags & IFF_UP))
net = vf_netdev;
@@ -667,6 +668,7 @@ int netvsc_recv_callback(struct hv_device *device_obj,
skb = netvsc_alloc_recv_skb(net, packet, csum_info, *data, vlan_tci);
if (unlikely(!skb)) {
++net->stats.rx_dropped;
+ rcu_read_unlock();
return NVSP_STAT_FAIL;
}
@@ -696,6 +698,7 @@ int netvsc_recv_callback(struct hv_device *device_obj,
* TODO - use NAPI?
*/
netif_rx(skb);
+ rcu_read_unlock();
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [net-next PATCH 2/3] net: reduce cycles spend on ICMP replies that gets rate limited
From: Eric Dumazet @ 2017-01-11 17:15 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, xiyou.wangcong
In-Reply-To: <1483983850.5846.4.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2017-01-09 at 09:44 -0800, Eric Dumazet wrote:
> On Mon, 2017-01-09 at 16:04 +0100, Jesper Dangaard Brouer wrote:
> > This patch split the global and per (inet)peer ICMP-reply limiter
> > code, and moves the global limit check to earlier in the packet
> > processing path. Thus, avoid spending cycles on ICMP replies that
> > gets limited/suppressed anyhow.
> >
> > The global ICMP rate limiter icmp_global_allow() is a good solution,
> > it just happens too late in the process. The kernel goes through the
> > full route lookup (return path) for the ICMP message, before taking
> > the rate limit decision of not sending the ICMP reply.
> >
> > Details: The kernels global rate limiter for ICMP messages got added
> > in commit 4cdf507d5452 ("icmp: add a global rate limitation"). It is
> > a token bucket limiter with a global lock. It brilliantly avoids
> > locking congestion by only updating when 20ms (HZ/50) were elapsed. It
> > can then avoids taking lock when credit is exhausted (when under
> > pressure) and time constraint for refill is not yet meet.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
>
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Remaining problem :
A moderate load (1000 packets per second) of UDP packets from a rogue
source (not even spoofing source IP) to a closed port will consume all
the (global) budget, even if the per destination budget allows one ICMP
per second.
Meaning that single UDP message sent by other sources are not able to
get an ICMP in response.
This makes ICMP much less useful (unlikely to be sent by a host)
In my commit (4cdf507d5452 : icmp: add a global rate limitation) I gave
this hint :
<quote>
Note that if we really want to send millions of ICMP messages per
second, we might extend idea and infra added in commit 04ca6973f7c1a
("ip: make IP identifiers less predictable") :
add a token bucket in the ip_idents hash and no longer rely on inetpeer.
</quote>
The idea would be to use a hash table to quickly filter elephant flows,
preventing them from stealing all the global ICMP credits.
Or if you prefer, no longer use control variables stored in inetpeer.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Move hwmon support out of switch and into PHYs.
From: Vivien Didelot @ 2017-01-11 17:06 UTC (permalink / raw)
To: Andrew Lunn, David Miller
Cc: netdev, Florian Fainelli, Andrew Lunn, Guenter Roeck
In-Reply-To: <1484096604-25033-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> Marvell Ethernet switches contain temperature sensors. They are inside
> the embedded PHYs. Move the code into the PHY driver, so that discrete
> PHY drivers also export there temperature sensor.
This message is not correct. The Marvell Ethernet switches contain only
one temperature sensor for the entire chip (please adjust the cover
letter and commit messages when you respin.)
The temperature and threshold are accessed through the embedded PHY
registers of any port, as long as the port is not disabled.
Even unlikely to be used, an interrupt can be generated when the
temperature exceeds a certain threshold. It should be enabled on only
one port at a time since there is only one temperature sensor.
To sum up briefly, the temperature chip is physically inside the switch
chip, but its access is via the embedded PHYs of the switch.
I'd prefer to see the temperature code in the PHY driver as well, but I
prefer we make sure that privileging the data access over the physical
representation is the correct thing to do before moving code around.
Thanks,
Vivien
^ permalink raw reply
* [PATCH net-next v2] net: thunderx: Make hfunc variable const type in nicvf_set_rxfh()
From: Robert Richter @ 2017-01-11 17:04 UTC (permalink / raw)
To: David Miller; +Cc: Sunil Goutham, Robert Richter, netdev, Robert Richter
>From struct ethtool_ops:
int (*set_rxfh)(struct net_device *, const u32 *indir,
const u8 *key, const u8 hfunc);
Change function arg of hfunc to const type.
V2: Fixed indentation.
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
index 2e74bbaa38e1..5ac474683c98 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
@@ -635,7 +635,7 @@ static int nicvf_get_rxfh(struct net_device *dev, u32 *indir, u8 *hkey,
}
static int nicvf_set_rxfh(struct net_device *dev, const u32 *indir,
- const u8 *hkey, u8 hfunc)
+ const u8 *hkey, const u8 hfunc)
{
struct nicvf *nic = netdev_priv(dev);
struct nicvf_rss_info *rss = &nic->rss_info;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: Lorenzo Colitti @ 2017-01-11 16:46 UTC (permalink / raw)
To: David Miller; +Cc: Andrey Jr. Melnikov, netdev@vger.kernel.org
In-Reply-To: <20170111.091139.1754139535517451753.davem@davemloft.net>
On Wed, Jan 11, 2017 at 11:11 PM, David Miller <davem@davemloft.net> wrote:
> I understand what you're saying, but if you look at how apps can be
> put into hierarchical control groups, and automatically bind to VRF's
> based upon where they are in that cgroup hierarchy, it matches your
> use case precisely.
I think whether an app is in bound to a certain VRF or not is not
directly related to this patch. What this patch does is provide a way
to ensure that routes learned via autoconf go into a specific routing
table, so that policy routing rules can select them.
Without this patch, and without VRFs, the routes for all networks and
all interfaces all go into the same routing table (main). That doesn't
work well on a multinetwork device. As David A. points out, with VRFs
this can be done - since each VRF has its own routing table, the
routes are isolated and ip rules can be applied to determine which
ones are used. However, I'm not convinced that VRFs are a great
solution to this problem. A couple of problems I see here are:
1. When an interface is created on the fly, the system must guarantee
that a VRF for it exists, and the interface is put into it, before it
comes up and receives an RA. This is not insurmountable - for example,
you can set net.conf.default.disable_ipv6 to 1, and set it to 0 on the
interface once it's in a VRF. Not sure this is feasible on a
mainstream distribution, but it could be done on something like
Android that's more tightly integrated.
2. I'm not sure it's possible to use routing policy to select between
interfaces in the same VRF. For example, if you have a carrier that
provides the user with the same IP address and similar connectivity on
both cellular data and a carrier-operated wifi network, and you put
those two in the same VRF, I don't see a way to say via routing policy
"prefer wifi over cellular", because the routes for both are in the
same table and AIUI the only discriminator between the two - the oif -
has to be set to the VRF ifindex. I suppose it might be possible to
alter the metrics of routes that were previously created by autoconf
but that sounds desperately hacky.
I suppose both of these could also be resolved by ensuring that each
interface is its own VRF at creation time. But if every VRF only
contains exactly one interface, the VRF construct doesn't really seem
useful.
That said, we've maintained this patch out of tree for a few years now
and we can continue to do so for a while longer. When the VRF code
rolls into enough SoC kernels we can make an attempt to use it and see
what issues we find.
^ permalink raw reply
* Re: [PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors
From: Tom Lendacky @ 2017-01-11 16:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-pci, Mauro Carvalho Chehab, netdev, linux-media
In-Reply-To: <20170111090357.GB7350@lst.de>
On 1/11/2017 3:03 AM, Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:40:10PM -0600, Tom Lendacky wrote:
>> On 1/9/2017 2:37 PM, Christoph Hellwig wrote:
>>> The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
>>> and pci_enable_msix_range interfaces. Switch it to use
>>> pci_irq_alloc_vectors instead.
>>
>> I was just working on switching over to this API with some additional
>> changes / simplification. I'm ok with using this patch so that you get
>> the API removal accomplished. Going through the PCI tree just means
>> it will probably be easier for me to hold off on the additional changes
>> I wanted to make until later.
>
> Hi Tom,
Hi Christoph,
>
> if you have a better patch I'd be more than happy to use that one instead,
> this one was intended as a stupid search and replace. The important
> part for me is to get the two conversions and the interface removal
> in together.
That sounds good, I'll send the patch to you in a separate email for use
in your series.
Thanks,
Tom
>
> E.g. I've alreayd wondered why the driver requires the exact vector
> number for MSI and a variable one for MSI-X, and there certainly is
> all kinds of opportunity for cosmetic cleanup.
>
^ permalink raw reply
* [PATCH net-next] net: thunderx: Fix error return code in nicvf_open()
From: Wei Yongjun @ 2017-01-11 16:32 UTC (permalink / raw)
To: Sunil Goutham, Robert Richter; +Cc: Wei Yongjun, linux-arm-kernel, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 712c31853440 ("net: thunderx: Program LMAC credits based on MTU")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 273eafd..a25bb6e 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1274,7 +1274,8 @@ int nicvf_open(struct net_device *netdev)
/* Configure receive side scaling and MTU */
if (!nic->sqs_mode) {
nicvf_rss_init(nic);
- if (nicvf_update_hw_max_frs(nic, netdev->mtu))
+ err = nicvf_update_hw_max_frs(nic, netdev->mtu);
+ if (err)
goto cleanup;
/* Clear percpu stats */
^ permalink raw reply related
* Re: [PATCH net-next 1/2] phy: marvell: Add support for temperature sensor
From: Sergei Shtylyov @ 2017-01-11 16:29 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20170111150931.GV22820@lunn.ch>
Hello!
On 01/11/2017 06:09 PM, Andrew Lunn wrote:
>> +static int marvell_hwmon_probe(struct phy_device *phydev,
>> + const struct hwmon_chip_info *chip)
>> +{
>> + struct marvell_priv *priv = phydev->priv;
>> + struct device *dev = &phydev->mdio.dev;
>> + int err;
>> +
>> + err = marvell_hwmon_name(phydev);
>> + if (err)
>> + return err;
>> +
>> + priv->hwmon_dev = devm_hwmon_device_register_with_info(
>> + dev, priv->hwmon_name, phydev, chip, NULL);
>> +
>> + if (IS_ERR(priv->hwmon_dev))
>> + return PTR_ERR(priv->hwmon_dev);
>> +
>> + return 0;
>> +}
>
> 0-day has pointed out this can be simplified to just
>
> return PTR_ERR(priv->hwmon_dev);
PTR_ERR_OR_ZERO() maybe?
[...]
MBR, Sergei
^ permalink raw reply
* Re: TCP using IPv4-mapped IPv6 address as source
From: Eric Dumazet @ 2017-01-11 16:20 UTC (permalink / raw)
To: Jonathan T. Leighton; +Cc: netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <87f4e2ec-22bf-2401-8401-57205f893289@udel.edu>
On Thu, 2017-01-05 at 16:25 -0500, Jonathan T. Leighton wrote:
> I've observed TCP using an IPv4-mapped IPv6 address as the source
> address, which I believe contradicts
> https://tools.ietf.org/html/rfc6890#page-14 (BCP 153). This occurs when
> an IPv6 TCP socket, bound to a local IPv4-mapped IPv6 address, attempts
> to connect to a remote IPv6 address. Presumable connect() should return
> EAFNOSUPPORT in this case. Please advise me if this is not to
> appropriate list to report this.
Hi Jonathan
I believe your concern makes sense.
Do you have a patch to address this issue ?
Thanks
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 16:19 UTC (permalink / raw)
To: David Miller, Joao.Pinto
Cc: alexandre.torgue, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <20170111.102000.1291650495305959047.davem@davemloft.net>
Às 3:20 PM de 1/11/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@synopsys.com>
> Date: Wed, 11 Jan 2017 15:06:55 +0000
>
>> The goal of this work is to improve code organization and future merge of other
>> Synopsys Ethernet IP driver that will be able to merge into this "synopsys
>> driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
>> stmmac.
>
> Then I want to see an ACK from Alexandre and Peppe for this renaming
> patch set.
>
Just a side question. My commits are assuming my username instead of my name.
Did you ever had a similar issue? My gitconfig:
> [user]
> email = jpinto@synopsys.com
> name = Joao Pinto
> [format]
> signoff = true
> thread = true
> [sendemail]
> smtpEncryption = tls
> smtpServer = <SERVER>
> smtpUser = <SERVER_USER>
> confirm = auto
> [core]
> excludesfile = /path/.gitignore [pack]
> windowMemory = 2048m
> [diff]
> renames = copy
Thanks,
Joao
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 16:17 UTC (permalink / raw)
To: David Miller, Joao.Pinto
Cc: alexandre.torgue, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <20170111.102000.1291650495305959047.davem@davemloft.net>
Às 3:20 PM de 1/11/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@synopsys.com>
> Date: Wed, 11 Jan 2017 15:06:55 +0000
>
>> The goal of this work is to improve code organization and future merge of other
>> Synopsys Ethernet IP driver that will be able to merge into this "synopsys
>> driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
>> stmmac.
>
> Then I want to see an ACK from Alexandre and Peppe for this renaming
> patch set.
>
Of course!
Alexandre and Peppe do you want a file / function rename as well?
Thanks.
Joao
^ permalink raw reply
* [PATCH net-next] sfc: efx_get_phys_port_id() can be static
From: Wei Yongjun @ 2017-01-11 16:16 UTC (permalink / raw)
To: Solarflare linux maintainers, Edward Cree, Bert Kenward
Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/net/ethernet/sfc/efx.c:2337:5: warning:
symbol 'efx_get_phys_port_id' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/sfc/efx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 543fa48..f2ec853 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -2334,8 +2334,8 @@ static int efx_set_features(struct net_device *net_dev, netdev_features_t data)
return 0;
}
-int efx_get_phys_port_id(struct net_device *net_dev,
- struct netdev_phys_item_id *ppid)
+static int efx_get_phys_port_id(struct net_device *net_dev,
+ struct netdev_phys_item_id *ppid)
{
struct efx_nic *efx = netdev_priv(net_dev);
^ permalink raw reply related
* Re: [PATCH net-next 0/2] net/sched: cls_flower: Support matching ARP
From: David Miller @ 2017-01-11 16:04 UTC (permalink / raw)
To: simon.horman; +Cc: jiri, dinan.gunawardena, netdev, oss-drivers
In-Reply-To: <1484139943-18199-1-git-send-email-simon.horman@netronome.com>
From: Simon Horman <simon.horman@netronome.com>
Date: Wed, 11 Jan 2017 14:05:41 +0100
> Add support for support matching on ARP operation, and hardware and
> protocol addresses for Ethernet hardware and IPv4 protocol addresses.
>
> Changes since RFC:
> * None other than dropping RFC designation after positive feedback from Jiri
Series applied, thanks Simon.
^ permalink raw reply
* Re: net: ti: cpsw-phy-sel: RGMII is not working on AM335x
From: Teresa Remmet @ 2017-01-11 15:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandru Gagniuc, David S. Miller, Mugunthan V N,
Grygorii Strashko, linux-omap, netdev
In-Reply-To: <20170111151407.GW22820@lunn.ch>
Hello Andrew,
Am Mittwoch, den 11.01.2017, 16:14 +0100 schrieb Andrew Lunn:
> >
> > So I wonder what is correct now? As for me the patch makes RGMII
> > unusable.
> > Has anyone an explanation?
> Hi Teresa
>
> In your device tree, what phy-mode do you have?
>
> And does your hardware require an RGMII delay in order that it works?
my device tree node for the RGMII looks like this:
&cpsw_emac1 {
phy-handle = <&phy1>;
phy-mode = "rgmii";
dual_emac_res_vlan = <2>;
status = "okay";
};
&davinci_mdio {
phy1: ethernet-phy@1 {
reg = <2>;
/* Register 260 (104h) – RGMII Clock and Control Pad Skew */ rxc-skew-ps = <1400>;
rxdv-skew-ps = <0>;
txc-skew-ps = <1400>;
txen-skew-ps = <0>;
/* Register 261 (105h) – RGMII RX Data Pad Skew */
rxd3-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd0-skew-ps = <0>;
/* Register 262 (106h) – RGMII TX Data Pad Skew */
txd3-skew-ps = <0>;
txd2-skew-ps = <0>;
txd1-skew-ps = <0>;
txd0-skew-ps = <0>;
};
};
The phy we use is a KSZ9021. And yes we add delays to the
phy, as you can see. When looking to the dts documentation I probably
need to set the phy-mode to "rgmii-id" instead, as the phy is providing
the delays.
I make a quick test with that change and it is working. So this seems
to solve my problem. Thank you for the hint.
Regards,
Teresa
>
> Andrew
^ permalink raw reply
* Re: [PATCH] bnxt_en: hide unused bnxt_get_max_func_{vnics,rss_ctxs} functions
From: David Miller @ 2017-01-11 15:51 UTC (permalink / raw)
To: arnd
Cc: michael.chan, prashant.sreedharan, sbaddipa, aduyck, netdev,
linux-kernel
In-Reply-To: <20170111143619.502495-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jan 2017 15:36:09 +0100
> There are lots of #ifdefs in this file, and a recent patch got one
> of them wrong, leading to a harmless warning in some randconfig
> builds:
>
> ethernet/broadcom/bnxt/bnxt.c:4956:21: error: 'bnxt_get_max_func_vnics' defined but not used [-Werror=unused-function]
> ethernet/broadcom/bnxt/bnxt.c:4947:21: error: 'bnxt_get_max_func_rss_ctxs' defined but not used [-Werror=unused-function]
>
> Ideally we'd just remove all of them and use 'if (IS_ENABLED())'
> checks instead, which don't have this problem, but for now, I'm
> adding one more #ifdef to shut up the new warning.
>
> Fixes: 8079e8f107bf ("bnxt_en: Refactor code that determines RFS capability.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Michael Chan has a fix for this coming my way.
^ permalink raw reply
* Re: [PATCH net-next] net: thunderx: Make hfunc variable const type in nicvf_set_rxfh()
From: David Miller @ 2017-01-11 15:51 UTC (permalink / raw)
To: rrichter; +Cc: sgoutham, rric, netdev
In-Reply-To: <20170111091702.6343-1-rrichter@cavium.com>
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Jan 2017 10:17:02 +0100
> @@ -635,7 +635,7 @@ static int nicvf_get_rxfh(struct net_device *dev, u32 *indir, u8 *hkey,
> }
>
> static int nicvf_set_rxfh(struct net_device *dev, const u32 *indir,
> - const u8 *hkey, u8 hfunc)
> + const u8 *hkey, const u8 hfunc)
Please do not change the indentation, it is currently correct.
^ permalink raw reply
* Re: [PATCH v2] net: netcp: correct netcp_get_stats function signature
From: David Miller @ 2017-01-11 15:48 UTC (permalink / raw)
To: j-keerthy
Cc: w-kwok2, m-karicheri2, netdev, linux-kernel, stephen, m-scherban
In-Reply-To: <1484105609-8647-1-git-send-email-j-keerthy@ti.com>
From: Keerthy <j-keerthy@ti.com>
Date: Wed, 11 Jan 2017 09:03:29 +0530
> Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function
> and
> Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits.
>
> The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old
> signature which causes compilation error:
>
> drivers/net/ethernet/ti/netcp_core.c:1951:28: error:
> initialization from incompatible pointer type
> .ndo_get_stats64 = netcp_get_stats,
>
> Hence correct netcp_get_stats function signature as per
> the latest definition.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Fixes: 6a8162e99ef344fc("net: netcp: store network statistics in 64 bits")
Applied, thanks.
^ 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