* Re: [PATCH] dummy: add support for ethtool get_drvinfo
From: David Miller @ 2014-12-09 21:07 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <1417824804-20634-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Fri, 5 Dec 2014 22:13:24 -0200
> The command 'ethtool -i' is useful to find details
> about the interface like the device driver being used.
> This was missing for dummy driver.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
Applied, thank you.
Consider adding a MODULE_VERSION instance since you've added an
explicit version.
Thanks.
^ permalink raw reply
* Re: [PATCH net] bnx2x: Implement ndo_gso_check()
From: David Miller @ 2014-12-09 21:05 UTC (permalink / raw)
To: joestringer; +Cc: netdev, ariel.elior, jesse, therbert, linux-kernel
In-Reply-To: <1417808146-3436-1-git-send-email-joestringer@nicira.com>
From: Joe Stringer <joestringer@nicira.com>
Date: Fri, 5 Dec 2014 11:35:46 -0800
> Use vxlan_gso_check() to advertise offload support for this NIC.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Applied, thanks.
^ permalink raw reply
* Re: the next chunk of iov_iter-net stuff for review
From: Al Viro @ 2014-12-09 21:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20141209.150732.158834258918114526.davem@davemloft.net>
On Tue, Dec 09, 2014 at 03:07:32PM -0500, David Miller wrote:
> From: Al Viro <viro@ZenIV.linux.org.uk>
> Date: Fri, 5 Dec 2014 05:56:23 +0000
>
> > OK, here's the tentative next batch (covers most of the ->recvmsg()
> > side of conversion). That's on top of merge of net-next#master with
> > vfs#iov_iter (the latter had been posted earlier today, Cc'd to netdev among
> > other places). This series corresponds to vfs#for-davem. Review and comments
> > would be very welcome...
>
> Al, what's the state of this? The iov_iter rewrite had some changes
> recently.
Well, I've got no comments whatsoever on the networking side of things;
might mean that everything's fine, might mean that everyone had been too
polite to say it's shite, might be something in between... FWIW, changes
in iov_iter do not affect any of those patches, so the stuff posted
for review is unchanged by those.
> Also, never assume I just know what GIT url to pull from, always
> explicitly state where you want me to pull changes from.
Sure, but that was just a call for review. _If_ you think that those patches
are OK, the URL is
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-davem
(and it pulls the fixed variant of iov_iter, otherwise it's exactly the same
as when I posted those).
FWIW, this stuff seems to work here, but I'd really like to hear at least
something before asking to pull. As it is, your mail is the first reply of
any kind...
^ permalink raw reply
* Re: [PATCH] tipc: fix broadcast link wakeup after congestion
From: David Miller @ 2014-12-09 21:03 UTC (permalink / raw)
To: richard.alpe; +Cc: netdev, tipc-discussion, erik.hugne
In-Reply-To: <1417802360-5383-1-git-send-email-richard.alpe@ericsson.com>
From: <richard.alpe@ericsson.com>
Date: Fri, 5 Dec 2014 18:59:20 +0100
> From: Richard Alpe <richard.alpe@ericsson.com>
>
> commit 908344cdda80 ("tipc: fix bug in multicast congestion
> handling") introduced two bugs in the bclink wakeup function.
>
> This patch fixes the missing spinlock init for the broadcast link
> waiting_sks list and eliminates a broadcast link wakeup race caused
> by operation on the wakeup list without proper locking.
>
> Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Acked-by: Tero Aho <Tero.Aho@coriant.com>
This patch does not apply to the current 'net' tree.
^ permalink raw reply
* Re: [PATCH net-next ] Documentation (ixgbe.txt): use a decimal address.
From: David Miller @ 2014-12-09 21:02 UTC (permalink / raw)
To: ramirose; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1417800943-4429-1-git-send-email-ramirose@gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Fri, 5 Dec 2014 19:35:43 +0200
> This patch fixes the erronous usage of an hexadecimal address in the
> example, by replacing it with a decimal address.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: set correct protocol on route lookup
From: David Miller @ 2014-12-09 21:01 UTC (permalink / raw)
To: jbenc; +Cc: netdev, dev, pshelar, wenyuz
In-Reply-To: <0ead411e38bc57a8971ffd9826f7bf9bfdc6ccf1.1417796557.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Fri, 5 Dec 2014 17:24:28 +0100
> Respect what the caller passed to ovs_tunnel_get_egress_info.
>
> Fixes: 8f0aad6f35f7e ("openvswitch: Extend packet attribute for egress tunnel info")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] macvlan: allow setting LRO independently of lower device
From: David Miller @ 2014-12-09 21:00 UTC (permalink / raw)
To: mkubecek; +Cc: kaber, netdev, linux-kernel
In-Reply-To: <20141205190937.99BD6A0BB0@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Fri, 5 Dec 2014 17:05:49 +0100
> Since commit fbe168ba91f7 ("net: generic dev_disable_lro() stacked
> device handling"), dev_disable_lro() zeroes NETIF_F_LRO feature flag
> first for a macvlan device and then for its lower device. As an attempt
> to set NETIF_F_LRO to zero is ignored, dev_disable_lro() issues a
> warning and taints kernel.
>
> Allowing NETIF_F_LRO to be set independently of the lower device
> consists of three parts:
>
> - add the flag to hw_features to allow toggling it
> - allow setting it to 0 even if lower device has the flag set
> - add the flag to MACVLAN_FEATURES to restore copying from lower
> device on macvlan creation
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: allow setting congctl via routing table
From: David Miller @ 2014-12-09 20:58 UTC (permalink / raw)
To: dborkman; +Cc: hannes, fw, netdev
In-Reply-To: <1417909163-19135-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sun, 7 Dec 2014 00:39:19 +0100
> This is the second part of our work and allows for setting the congestion
> control algorithm via routing table. For details, please see individual
> patches.
>
> Joint work with Florian Westphal, suggested by Hannes Frederic Sowa.
>
> Patch for iproute2: http://patchwork.ozlabs.org/patch/418149/
>
> Thanks!
>
> v1->v2:
> - Very sorry, I noticed I had decnet disabled during testing.
> Added missing header include in decnet, rest as is.
I don't like how you have to explicitly load the congestion control
module before asking for it to be used in the route entry metric.
It should request the module automatically just like the stack already
does for other cases.
You have run into this problem as a result of your design decision to
use that 32-bit key. Therefore, I think you seriously need to
reconsider that aspect of your change.
^ permalink raw reply
* [PATCH net-next] amd-xgbe: Use disable_irq_nosync when in IRQ context
From: Tom Lendacky @ 2014-12-09 20:54 UTC (permalink / raw)
To: netdev; +Cc: David Miller
The disable_irq_nosync function, not the disable_irq function, must be
used to disable the DMA channel interrupt from within the interrupt
service routine. Change the disable_irq call to disable_irq_nosync.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index bedfdb1..bf6bf11 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -396,7 +396,7 @@ static irqreturn_t xgbe_dma_isr(int irq, void *data)
*/
if (napi_schedule_prep(&channel->napi)) {
/* Disable Tx and Rx interrupts */
- disable_irq(channel->dma_irq);
+ disable_irq_nosync(channel->dma_irq);
/* Turn on polling */
__napi_schedule(&channel->napi);
^ permalink raw reply related
* Re: [patch net-next 2/2] net: sched: cls: use nla_nest_cancel instead of nlmsg_trim
From: David Miller @ 2014-12-09 20:48 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs
In-Reply-To: <20141209.154218.95904353076153825.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 09 Dec 2014 15:42:18 -0500 (EST)
> From: Jiri Pirko <jiri@resnulli.us>
> Date: Fri, 5 Dec 2014 15:50:23 +0100
>
>> To cancel nesting, this function is more convenient.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
> Applied.
This doesn't even compile, when you took away the local 'b' variable
it is still referenced by pr_debug() calls.
^ permalink raw reply
* Re: [patch net-next 2/2] net: sched: cls: use nla_nest_cancel instead of nlmsg_trim
From: David Miller @ 2014-12-09 20:42 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs
In-Reply-To: <1417791023-28124-2-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 5 Dec 2014 15:50:23 +0100
> To cancel nesting, this function is more convenient.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied.
^ permalink raw reply
* Re: [patch net-next 1/2] net: sched: cls_basic: fix error path in basic_change()
From: David Miller @ 2014-12-09 20:42 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs
In-Reply-To: <1417791023-28124-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 5 Dec 2014 15:50:22 +0100
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] net: macb: Remove obsolete comment from Kconfig
From: David Miller @ 2014-12-09 20:39 UTC (permalink / raw)
To: james.byrne; +Cc: nicolas.ferre, netdev
In-Reply-To: <1417784633-13360-1-git-send-email-james.byrne@origamienergy.com>
From: James Byrne <james.byrne@origamienergy.com>
Date: Fri, 5 Dec 2014 13:03:53 +0000
> The Kconfig file says that Gigabit mode is not supported, but it has been
> supported since commit 140b7552fdff04bbceeb842f0e04f0b4015fe97b ("net/macb:
> Add support for Gigabit Ethernet mode").
>
> Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] gianfar: handle map error in gfar_start_xmit()
From: David Miller @ 2014-12-09 20:39 UTC (permalink / raw)
To: asolokha; +Cc: claudiu.manoil, netdev, linux-kernel
In-Reply-To: <1417775874-17775-3-git-send-email-asolokha@kb.kras.ru>
From: Arseny Solokha <asolokha@kb.kras.ru>
Date: Fri, 5 Dec 2014 17:37:54 +0700
> @@ -2296,6 +2296,12 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> 0,
> frag_len,
> DMA_TO_DEVICE);
> + if (unlikely(dma_mapping_error(priv->dev, bufaddr))) {
> + /* As DMA mapping failed, pretend the TX path
> + * is busy to retry later
> + */
> + return NETDEV_TX_BUSY;
> + }
You are not "busy", you are dropping the packet due to insufficient system
resources.
Therefore the appropriate thing to do is to free the SKB, increment
the drop statistical counter, and return NETDEV_TX_OK.
^ permalink raw reply
* Re: [PATCH 1/2] gianfar: handle map error in gfar_new_rxbdp()
From: David Miller @ 2014-12-09 20:37 UTC (permalink / raw)
To: asolokha; +Cc: claudiu.manoil, netdev, linux-kernel
In-Reply-To: <1417775874-17775-2-git-send-email-asolokha@kb.kras.ru>
From: Arseny Solokha <asolokha@kb.kras.ru>
Date: Fri, 5 Dec 2014 17:37:53 +0700
> @@ -2854,7 +2866,15 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
> rx_queue->rx_skbuff[rx_queue->skb_currx] = newskb;
>
> /* Setup the new bdp */
> - gfar_new_rxbdp(rx_queue, bdp, newskb);
> + rxbdpret = gfar_new_rxbdp(rx_queue, bdp, newskb);
> + if (unlikely(rxbdpret)) {
> + /* We drop the frame if we failed to map a new DMA
> + * buffer
> + */
> + count_errors(bdp->status, dev);
> + dev_kfree_skb(newskb);
> + continue;
> + }
>
> /* Update to the next pointer */
> bdp = next_bd(bdp, base, rx_queue->rx_ring_size);
You need to add much more sophisticated handling of this error.
Otherwise the chip will just stop when it gets to the first
descriptor for which a DMA mapping failed in this way.
What you need to do is allocate and attempt to map the new SKB
_first_, and only if that succeeds will you pass the original
SKB up into the networking stack.
If the DMA mapping fails, you leave the OLD skb in the RX ring
and advance the ring pointer, as if the received packet never
happened. You are essentially dropping it.
^ permalink raw reply
* Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.
From: Wolfgang Walter @ 2014-12-09 20:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Jarosch, netdev, Eric Dumazet, Herbert Xu,
Steffen Klassert
In-Reply-To: <1418135209.14835.17.camel@edumazet-glaptop2.roam.corp.google.com>
Am Dienstag, 9. Dezember 2014, 06:26:49 schrieb Eric Dumazet:
> On Tue, 2014-12-09 at 09:54 +0100, Thomas Jarosch wrote:
> > On Monday, 8. December 2014 23:20:42 Wolfgang Walter wrote:
> > > Am Freitag, 5. Dezember 2014, 05:26:25 schrieb Eric Dumazet:
> > > > On Fri, 2014-12-05 at 13:09 +0100, Wolfgang Walter wrote:
> > > > > Hello,
> > > > >
> > > > > as reverting this patch fixes this rather annoying problem: is it
> > > > > dangerous to revert it as a workaround until the root cause is
> > > > > found?
> > > >
> > > > Unfortunately no, this patch fixes a serious issue.
> > > >
> > > > We need to find the root cause of your problem instead of trying to
> > > > work
> > > > around it.
> > >
> > > I only wanted to use it as local workaround here.
> > >
> > >
> > > I looked a bit at at code. I'm not familiar with the network code,
> > > though
> > >
> > > :-).
> >
> > If it helps, I'm running the reverted patch on five production boxes
> > hitherto without a hiccup. As far as I understood the original commit
> > message, some packet counters might me wrong without it.
> >
> > @Eric: What could possibly go wrong(tm)? :)
>
> Crashes in TCP stack, because of packet count mismatches.
>
> The sk_can_gso() status is already tested in tcp_sendmsg() as a hint,
> since path behavior can dynamically be changed on existing flow :
>
> <start a TCP flow>
> ethtool -K eth0 tso off gso off
>
> In this case, core networking stack detects this and segments the
> packets _after_ TCP or IP stack, before they reach eth0.
>
> TCP stack does not have to know that something is changed right before
> giving a GSO packet to core networking stack, this would be racy by
> nature, as TCP does not know or control full path. Hopefully we do not
> take RTNL for every packet we send in TCP !
>
> It seems XFRM triggers in a slow path something which is not correctly
> handled.
>
> It is not correct to add a racy kludge in TCP fast path for this very
> unlikely case.
>
> I would disable TSO/GSO on xfrm, and problem should disappear.
How would that be done? I found no way to disable it especially for xfrm. I
disabled gso for the interface which serves the ipsec traffic but this does
not help. tcp still uses gso for the esp tunnel.
I put a view printk's in net/xfrm/xfrm_output.c and net/ipv4/tcp_output.c. (I
try to understand where in the xfrm transformation gso is handeled).
What I can say yet is:
xfrm_output() is used with ipsec (esp) tunnel mode but at I never see gso
packets here. xfrm_output_gso() is never called.
Everytime tcp_set_skb_tso_segs() is called for a tcp connection over the esp-
tunnel and it is a gso case then the tcp connection hangs. Those packets
always have skb->len 1398 and mss_now is 1374. I see a call of xfrm_output()
afterwards but for a packet of skb->len 52 (maybe ACK from other direction?).
As long as the tcp-connection over the ipsec-tunnel works and if I send bulk
traffic xfrm_output() is called 3 times with packet skb->len 1426 and then one
time with 78 (maybe other direction?), don't know if that is of any interest.
With non-ipsec-traffic gso works fine: in this case the skb->len() varies a
lot and mss_now is always 1288.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates 2014-12-09
From: Jeff Kirsher @ 2014-12-09 20:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20141209.121329.1709164468915251848.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On Tue, 2014-12-09 at 12:13 -0500, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 9 Dec 2014 03:22:37 -0800
>
> > This series contains updates to i40e and i40evf.
>
> Please address Sergei's feecback on patch #5 and resubmit.
>
> Thank you.
re-spinning now...
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 06/10] net/mlx4: Add mlx4_bitmap zone allocator
From: Or Gerlitz @ 2014-12-09 20:29 UTC (permalink / raw)
To: David Miller
Cc: Linux Netdev List, Matan Barak, Amir Vadai, talal@mellanox.com,
Jack Morgenstein, Or Gerlitz
In-Reply-To: <20141209.144210.1356501987854068706.davem@davemloft.net>
On Tue, Dec 9, 2014 at 9:42 PM, David Miller <davem@davemloft.net> wrote:
> From: Or Gerlitz <ogerlitz@mellanox.com>
> Date: Thu, 4 Dec 2014 15:13:51 +0200
>
>> +static u32 mlx4_bitmap_max(struct mlx4_bitmap *bitmap)
>> +{
>> + return bitmap->max;
>> +}
>> +
>> +static u32 mlx4_bitmap_effective_len(struct mlx4_bitmap *bitmap)
>> +{
>> + return bitmap->effective_len;
>> +}
>
> Using functions for just accessing structure members is excessive, please
> just open code this.
sure, we will fix that, I see now that we have two fixes to apply, so
will respin the series and send it to you tomorrow.
^ permalink raw reply
* Re: [PATCH net-next 02/10] net/mlx4_core: Mask out host side virtualization features for guests
From: Or Gerlitz @ 2014-12-09 20:25 UTC (permalink / raw)
To: David Miller
Cc: Or Gerlitz, Linux Netdev List, Matan Barak, Amir Vadai,
talal@mellanox.com, Jack Morgenstein
In-Reply-To: <20141209.144046.110046237866554513.davem@davemloft.net>
On Tue, Dec 9, 2014 at 9:40 PM, David Miller <davem@davemloft.net> wrote:
> From: Or Gerlitz <ogerlitz@mellanox.com>
> Date: Thu, 4 Dec 2014 15:13:47 +0200
>
>> @@ -1053,6 +1053,11 @@ int mlx4_QUERY_DEV_CAP_wrapper(struct mlx4_dev *dev, int slave,
>> field &= ~0x80;
>> MLX4_PUT(outbox->buf, field, QUERY_DEV_CAP_FLOW_STEERING_IPOIB_OFFSET);
>>
>> + /* turn off host side virt features (VST, FSM, etc) for guests */
>> + MLX4_GET(field32, outbox->buf, QUERY_DEV_CAP_EXT_2_FLAGS_OFFSET);
>> + field32 &= ~((1 << 26) | (1 << 21) | (1 << 20));
>> + MLX4_PUT(outbox->buf, field32, QUERY_DEV_CAP_EXT_2_FLAGS_OFFSET);
>> +
>
> Please use mnenomics instead of magic constants for this, thanks.
OK, will do, if possible, I will be happy to send this as small fix in
a later (tomorrow!!) patch, thanks, Or.
^ permalink raw reply
* Re: [RESEND PATCH] net/socket.c : introduce helper function do_sock_sendmsg to replace reduplicate code
From: David Miller @ 2014-12-09 20:24 UTC (permalink / raw)
To: guz.fnst; +Cc: netdev, linux-kernel
In-Reply-To: <54815B4F.50408@cn.fujitsu.com>
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date: Fri, 5 Dec 2014 15:14:23 +0800
> Introduce helper function do_sock_sendmsg() to simplify sock_sendmsg{_nosec},
> and replace reduplicate code.
>
> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Applied, thanks.
^ permalink raw reply
* Re: [RESEND PATCH] net: introduce helper macra CMSG_FOREACH_HDR
From: David Miller @ 2014-12-09 20:23 UTC (permalink / raw)
To: guz.fnst; +Cc: joe, netdev, linux-kernel
In-Reply-To: <54816CD3.90107@cn.fujitsu.com>
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date: Fri, 5 Dec 2014 16:29:07 +0800
> Hi Joe,
> Thanks for your comment.
> On 12/05/2014 04:02 PM, Joe Perches wrote:
>
>> On Fri, 2014-12-05 at 15:14 +0800, Gu Zheng wrote:
>>> Introduce helper macra
>>
>> macro
>
> Ah~, it's a typo.
>
>>
>>> CMSG_FOREACH_HDR as a wrapper of the enumerating
>>> cmsghdr from msghdr, just cleanup.
>>
>> maybe better to use lower case "for_each_cmsg_hdr"
>> or some such.
>
> But this will make it out of the ordinary, as the existed ones
> are all upper.
>
> David, what's your opinion?
I think lowercase looks much better.
^ permalink raw reply
* Re: the next chunk of iov_iter-net stuff for review
From: David Miller @ 2014-12-09 20:07 UTC (permalink / raw)
To: viro; +Cc: netdev, linux-kernel
In-Reply-To: <20141205055623.GQ29748@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Fri, 5 Dec 2014 05:56:23 +0000
> OK, here's the tentative next batch (covers most of the ->recvmsg()
> side of conversion). That's on top of merge of net-next#master with
> vfs#iov_iter (the latter had been posted earlier today, Cc'd to netdev among
> other places). This series corresponds to vfs#for-davem. Review and comments
> would be very welcome...
Al, what's the state of this? The iov_iter rewrite had some changes
recently.
Also, never assume I just know what GIT url to pull from, always
explicitly state where you want me to pull changes from.
Thanks.
^ permalink raw reply
* smsc911x: loopback test causing oops
From: Chris Conley @ 2014-12-09 19:33 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello all,
I'm trying to find out what the USE_PHY_WORK_AROUND ifdef is for. I looked in the git logs and this workaround was introduced with the initial checkin of the driver files, and not explained.
What was the hardware problem it was meant to handle? And is it valid for only certain chips? (i.e. the SMSC9221I, which is what we're using on this platform).
We are seeing the loopback test fail w/ invalid packet size, and at some point during the loopback test after that, we get a kernel oops for invalid address. And the address is very invalid (e.g. 48fa0569, fa65a8c4). We were seeing this and another problem with irq_spinlocks after the probe returned for the 2nd instance of the phy, but that was fixed by backporting the current 3.18 driver to the linux-fslc_3.14.14 kernel. Initially it looked like the backport fixed all of the problems, but one remained after over the weekend testing. If the platform is direct-connect plugged into another platform, the oops happens in loopback again.
The driver seems fine w/ the loopback disabled (no data xfer problems, etc), but I wanted to find out why it was there in the first place before forcing it off in a production environment.
Thanks,
//Chris
^ permalink raw reply
* Re: [PATCH 4/4 net-next] net: bcmgenet: rename bcmgenet_hw_params->bds_cnt and GENET_DEFAULT_BD_CNT
From: Florian Fainelli @ 2014-12-09 20:05 UTC (permalink / raw)
To: Petri Gynther, netdev; +Cc: davem
In-Reply-To: <20141204041200.8AB8A2200C7@puck.mtv.corp.google.com>
On 03/12/14 20:12, Petri Gynther wrote:
> bcmgenet_hw_params->bds_cnt and GENET_DEFAULT_BD_CNT are used only in Tx init.
> Rename them accordingly:
> - bcmgenet_hw_params->bds_cnt => bcmgenet_hw_params->tx_bds_per_q
> - GENET_DEFAULT_BD_CNT => GENET_Q16_TX_BD_CNT
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 3/4 net-next] net: bcmgenet: precalculate TxCB->bd_addr
From: Florian Fainelli @ 2014-12-09 20:05 UTC (permalink / raw)
To: Petri Gynther, netdev; +Cc: davem
In-Reply-To: <20141204041150.A54952200C7@puck.mtv.corp.google.com>
On 03/12/14 20:11, Petri Gynther wrote:
> There is 1-to-1 mapping between TxCBs and TxBDs. Precalculate TxCB->bd_addr
> once in bcmgenet_init_dma() instead of doing it over and over needlessly in
> bcmgenet_get_txcb().
Nice cleanup, thanks!
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
> ---
--
Florian
^ 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