* Re: [Xen-devel] [PATCH] xen: do not disable netfront in dom0
From: Konrad Rzeszutek Wilk @ 2012-05-22 19:43 UTC (permalink / raw)
To: David Miller
Cc: jeremy, Ian.Campbell, netdev, marmarek, virtualization, xen-devel,
linux-kernel
In-Reply-To: <20120522.153847.2107186222464601466.davem@davemloft.net>
On Tue, May 22, 2012 at 03:38:47PM -0400, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@citrix.com>
> Date: Tue, 22 May 2012 20:30:28 +0100
>
> > On Tue, 2012-05-22 at 20:13 +0100, David Miller wrote:
> >> From: Marek Marczykowski <marmarek@invisiblethingslab.com>
> >> Date: Sun, 20 May 2012 13:45:10 +0200
> >>
> >> > Netfront driver can be also useful in dom0, eg when all NICs are assigned to
> >> > some domU (aka driver domain). Then using netback in domU and netfront in dom0
> >> > is the only way to get network access in dom0.
> >> >
> >> > Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
> >>
> >> Someone please review this and I can merge it in via the 'net' tree if
> >> it looks OK to XEN folks.
> >
> > Konrad is "Xen folks" and has acked it already but FWIW:
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Ok, but this patch doesn't appply cleanly at all to Linus's
> current tree nor my 'net' tree (which are equal right now).
Oh no! Marek, can you repin it please (along with all the Ack's on it).
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen: do not disable netfront in dom0
From: David Miller @ 2012-05-22 19:38 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, konrad.wilk, netdev, marmarek, virtualization, xen-devel,
linux-kernel
In-Reply-To: <1337715028.3991.2.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 22 May 2012 20:30:28 +0100
> On Tue, 2012-05-22 at 20:13 +0100, David Miller wrote:
>> From: Marek Marczykowski <marmarek@invisiblethingslab.com>
>> Date: Sun, 20 May 2012 13:45:10 +0200
>>
>> > Netfront driver can be also useful in dom0, eg when all NICs are assigned to
>> > some domU (aka driver domain). Then using netback in domU and netfront in dom0
>> > is the only way to get network access in dom0.
>> >
>> > Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
>>
>> Someone please review this and I can merge it in via the 'net' tree if
>> it looks OK to XEN folks.
>
> Konrad is "Xen folks" and has acked it already but FWIW:
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ok, but this patch doesn't appply cleanly at all to Linus's
current tree nor my 'net' tree (which are equal right now).
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen: do not disable netfront in dom0
From: Ian Campbell @ 2012-05-22 19:30 UTC (permalink / raw)
To: David Miller
Cc: jeremy@goop.org, konrad.wilk@oracle.com, netdev@vger.kernel.org,
marmarek@invisiblethingslab.com,
virtualization@lists.linux-foundation.org,
xen-devel@lists.xen.org, linux-kernel@vger.kernel.org
In-Reply-To: <20120522.151354.2131168749992255398.davem@davemloft.net>
On Tue, 2012-05-22 at 20:13 +0100, David Miller wrote:
> From: Marek Marczykowski <marmarek@invisiblethingslab.com>
> Date: Sun, 20 May 2012 13:45:10 +0200
>
> > Netfront driver can be also useful in dom0, eg when all NICs are assigned to
> > some domU (aka driver domain). Then using netback in domU and netfront in dom0
> > is the only way to get network access in dom0.
> >
> > Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
>
> Someone please review this and I can merge it in via the 'net' tree if
> it looks OK to XEN folks.
Konrad is "Xen folks" and has acked it already but FWIW:
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* RE: [PATCH] xen/netback: calculate correctly the SKB slots.
From: Ian Campbell @ 2012-05-22 19:28 UTC (permalink / raw)
To: Simon Graham
Cc: Konrad Rzeszutek Wilk, Ben Hutchings,
xen-devel@lists.xensource.com, netdev@vger.kernel.org,
davem@davemloft.net, linux-kernel@vger.kernel.org, Adnan Misherfi
In-Reply-To: <F02ED76F3FCF8C468AD22A7618C05BBBB18DBFFE61@FTLPMAILBOX01.citrite.net>
On Tue, 2012-05-22 at 20:01 +0100, Simon Graham wrote:
> > >
> > > > > int i, copy_off;
> > > > >
> > > > > count = DIV_ROUND_UP(
> > > > > - offset_in_page(skb->data)+skb_headlen(skb),
> > PAGE_SIZE);
> > > > > + offset_in_page(skb->data + skb_headlen(skb)),
> > PAGE_SIZE);
> > > >
> > > > The new version would be equivalent to:
> > > > count = offset_in_page(skb->data + skb_headlen(skb)) != 0;
> > > > which is not right, as netbk_gop_skb() will use one slot per page.
> > >
> > > Just outside the context of this patch we separately count the frag
> > > pages.
> > >
> > > However I think you are right if skb->data covers > 1 page, since the
> > > new version can only ever return 0 or 1. I expect this patch papers
> > over
> > > the underlying issue by not stopping often enough, rather than
> > actually
> > > fixing the underlying issue.
> >
> > Ah, any thoughts? Have you guys seen this behavior as well?
>
> We ran into this same problem and the fix we've been running with for
> a while now (been meaning to submit it!) is:
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index c2669b8..7925bd3 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -312,8 +312,7 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> unsigned int count;
> int i, copy_off;
>
> - count = DIV_ROUND_UP(
> - offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
> + count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
>
> copy_off = skb_headlen(skb) % PAGE_SIZE;
>
> The rationale for this is that if the header spanned a page boundary,
> you would calculate that it needs 2 slots for the header BUT
> netback_gop_skb copies the header into the start of the page so only
> needs one slot (and only decrements the count of inuse entries by 1).
That sounds very plausible indeed!
Please can format this as a commit message and resend with a
Signed-off-by.
many thanks,
Ian.
>
> We found this running with a VIF bridged to a USB 3G Modem where
> skb->data started near the end of a page so the header would always
> span the page boundary.
>
> It was very easy to get the VIF to stop processing frames with the old
> code and we have not seen any problems since applying this patch.
>
> Simon
>
^ permalink raw reply
* [README] Two merges pending...
From: David Miller @ 2012-05-22 19:28 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: pablo-Cap9r6Oaw4JrovVCs/uTlw, linville-2XuSBdqkA4R54TAoqtyWWQ,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
After some discussion with John Linville I'm going to let him do
one more wireless merge to me.
I only decided to do this because the changes in his tree were in
his tree before he went away for a week, and therefore have gotten
lots of exposure in -next before the merge window even openned.
Which is more than I can say for some of this shit landing in Linus's
tree the past few days.
Pablo also has a prearranged netfilter merge pending.
DO NOT use this as some sort of sign that if you have some last minute
thing you want merged I can be coaxed into allowing it too. I very
nearly told John no, and I'm going to tell you no too.
The rest of you stick to bug fixes and maybe a few device ID
additions.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 5/5] netdev/phy: Add driver for Cortina cs4321 quad 10G PHY.
From: David Daney @ 2012-05-22 19:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Daney, devicetree-discuss@lists.ozlabs.org, Grant Likely,
Rob Herring, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
Fleming Andy-AFLEMING
In-Reply-To: <20120522185032.GR4038@decadent.org.uk>
On 05/22/2012 11:50 AM, Ben Hutchings wrote:
> On Tue, May 22, 2012 at 10:59:52AM -0700, David Daney wrote:
> [...]
>> --- /dev/null
>> +++ b/drivers/net/phy/cs4321-ucode.h
>> @@ -0,0 +1,4378 @@
>> +/*
>> + * Copyright (C) 2011 by Cortina Systems, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
> [...]
>
> So where's the real source code for it?
I wish I knew. The vendor released the array of random numbers as GPL
to us. :-(
>
> If you won't (or can't) provide source code for the microcode then it
> should instead be submitted to linux-firmware with a binary
> redistribution licence, and the driver should load it with
> request_firmware().
I will attempt to do that.
The .c file contains plenty of other pseudo-random numbers, but those
cannot really be considered 'firmware'
David Daney
^ permalink raw reply
* CODEL et al.
From: David Miller @ 2012-05-22 19:24 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Stephen, could you please provide a tree (if you don't already)
that has all of the CODEL et al. iproute2 feature patches applied
and mark the patchwork patches as applied??
Otherwise people have to do unreasonable things to test the new
features that are in Linus's tree already.
Thanks.
^ permalink raw reply
* Re: [PATCH] xen/netback: calculate correctly the SKB slots.
From: Adnan Misherfi @ 2012-05-22 19:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ian Campbell, Ben Hutchings, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org
In-Reply-To: <20120522180901.GC22488@phenom.dumpdata.com>
Konrad Rzeszutek Wilk wrote:
>>>> wrong, which caused the RX ring to be erroneously declared full,
>>>> and the receive queue to be stopped. The problem shows up when two
>>>> guest running on the same server tries to communicates using large
>>>>
> .. snip..
>
>>> The function name is xen_netbk_count_skb_slots() in net-next. This
>>> appears to depend on the series in
>>> <http://lists.xen.org/archives/html/xen-devel/2012-01/msg00982.html>.
>>>
>> Yes, I don't think that patchset was intended for prime time just yet.
>> Can this issue be reproduced without it?
>>
>
> It was based on 3.4, but the bug and work to fix this was done on top of
> a 3.4 version of netback backported in a 3.0 kernel. Let me double check
> whether there were some missing patches.
>
>
>>>> int i, copy_off;
>>>>
>>>> count = DIV_ROUND_UP(
>>>> - offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
>>>> + offset_in_page(skb->data + skb_headlen(skb)), PAGE_SIZE);
>>>>
>>> The new version would be equivalent to:
>>> count = offset_in_page(skb->data + skb_headlen(skb)) != 0;
>>> which is not right, as netbk_gop_skb() will use one slot per page.
>>>
>> Just outside the context of this patch we separately count the frag
>> pages.
>>
>> However I think you are right if skb->data covers > 1 page, since the
>> new version can only ever return 0 or 1. I expect this patch papers over
>> the underlying issue by not stopping often enough, rather than actually
>> fixing the underlying issue.
>>
>
> Ah, any thoughts? Have you guys seen this behavior as well?
>
>>> The real problem is likely that you're not using the same condition to
>>> stop and wake the queue.
>>>
>> Agreed, it would be useful to see the argument for this patch presented
>> in that light. In particular the relationship between
>> xenvif_rx_schedulable() (used to wake queue) and
>> xen_netbk_must_stop_queue() (used to stop queue).
>>
>
> Do you have any debug patches to ... do open-heart surgery on the
> rings of netback as its hitting the issues Adnan has found?
>
>
>> As it stands the description describes a setup which can repro the
>> problem but doesn't really analyse what actually happens, nor justify
>> the correctness of the fix.
>>
>
> Hm, Adnan - you dug in to this and you got tons of notes. Could you
> describe what you saw that caused this?
>
The problem is that the function xen_netbk_count_skb_slots() returns two
different counts for same type packets of same size (ICMP,3991). At the
start of the test
the count is one, later on the count changes to two, soon after the
counts becomes two, the condition ring full becomes true, and queue get
stopped, and never gets
started again.There are few point to make here:
1- It takes less that 128 ping packets to reproduce this
2- What is interesting here is that it works correct for many packet
sizes including 1500,400,500 9000, (3990, but not 3991)
3- The inconsistent count for the same packet size and type
4- I do not believe the ring was actually full when it was declared
full, I think the consumer pointer was wrong. (vif->rx_req_cons_peek in
function xenvif_start_xmit())
5- After changing the code the count returned from
xen_netbk_count_skb_slots() was always consistent, and worked just fine,
I let it runs for at least 12 hours.
^ permalink raw reply
* Re: [PATCH] phy/micrel: Fix ID of KSZ9021
From: David Miller @ 2012-05-22 19:21 UTC (permalink / raw)
To: nobuhiro.iwamatsu.yj; +Cc: netdev, david.choi
In-Reply-To: <1337646008-24568-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date: Tue, 22 May 2012 09:20:08 +0900
> Right ID of KSZ9021 is 0x00221610.
> Because lower 4bit is a revision number, it varies according to a chip.
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Applied, but this shouldn't matter and it should not have any
effect on functionality.
All of the code knows how to properly mask out the revision because
of MICRL_PHY_ID_MASK and the the .phy_id_mask specified in the
ksz9021_driver entry.
^ permalink raw reply
* Re: [PATCH] gianfar:don't add FCB length to hard_header_len
From: David Miller @ 2012-05-22 19:18 UTC (permalink / raw)
To: b06378; +Cc: netdev, linuxppc-dev
In-Reply-To: <1337677248-27792-1-git-send-email-b06378@freescale.com>
From: Jiajun Wu <b06378@freescale.com>
Date: Tue, 22 May 2012 17:00:48 +0800
> FCB(Frame Control Block) isn't the part of netdev hard header.
> Add FCB to hard_header_len will make GRO fail at MAC comparision stage.
>
> Signed-off-by: Jiajun Wu <b06378@freescale.com>
Applied, thanks.
Someone needs to go through this driver when net-next opens up
and fix all of the indentation in this driver.
^ permalink raw reply
* Re: [PATCH] mISDN: Add X-Tensions USB ISDN TA XC-525
From: David Miller @ 2012-05-22 19:19 UTC (permalink / raw)
To: keil; +Cc: netdev
In-Reply-To: <1337670854-7008-1-git-send-email-keil@b1-systems.de>
From: Karsten Keil <keil@b1-systems.de>
Date: Tue, 22 May 2012 09:14:14 +0200
> According to http://www.ip-phone-forum.de/showthread.php?t=225313 this
> HW works. Thanks to Lars Immisch for pointing to this thread.
>
> Signed-off-by: Karsten Keil <keil@b1-systems.de>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: David Miller @ 2012-05-22 19:15 UTC (permalink / raw)
To: kunx.jiang; +Cc: netdev, linux-kernel, yanmin_zhang
In-Reply-To: <4FBB6105.2060808@intel.com>
From: "kun.jiang" <kunx.jiang@intel.com>
Date: Tue, 22 May 2012 17:48:53 +0800
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
>
> We hit a kernel OOPS.
...
> In function free_fib_info, we don't reset nexthop_nh->nh_dev to NULL before releasing
> nh_dev. kfree_rcu(fi, rcu) would release the whole area.
>
> Signed-off-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Signed-off-by: Kun Jiang <kunx.jiang@intel.com>
This isn't a fix. You're keeping around a pointer to a completely
released object, which is therefore illegal to dereference.
That's why we must set it to NULL, to catch such illegal accesses.
^ permalink raw reply
* Re: [PATCH] xen: do not disable netfront in dom0
From: David Miller @ 2012-05-22 19:13 UTC (permalink / raw)
To: marmarek
Cc: jeremy, konrad.wilk, netdev, linux-kernel, virtualization,
xen-devel
In-Reply-To: <20120522130558.D828E6C7@duch.mimuw.edu.pl>
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
Date: Sun, 20 May 2012 13:45:10 +0200
> Netfront driver can be also useful in dom0, eg when all NICs are assigned to
> some domU (aka driver domain). Then using netback in domU and netfront in dom0
> is the only way to get network access in dom0.
>
> Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
Someone please review this and I can merge it in via the 'net' tree if
it looks OK to XEN folks.
^ permalink raw reply
* RE: [PATCH] xen/netback: calculate correctly the SKB slots.
From: Simon Graham @ 2012-05-22 19:01 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Ian Campbell
Cc: Ben Hutchings, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, Adnan Misherfi
In-Reply-To: <20120522180901.GC22488@phenom.dumpdata.com>
> >
> > > > int i, copy_off;
> > > >
> > > > count = DIV_ROUND_UP(
> > > > - offset_in_page(skb->data)+skb_headlen(skb),
> PAGE_SIZE);
> > > > + offset_in_page(skb->data + skb_headlen(skb)),
> PAGE_SIZE);
> > >
> > > The new version would be equivalent to:
> > > count = offset_in_page(skb->data + skb_headlen(skb)) != 0;
> > > which is not right, as netbk_gop_skb() will use one slot per page.
> >
> > Just outside the context of this patch we separately count the frag
> > pages.
> >
> > However I think you are right if skb->data covers > 1 page, since the
> > new version can only ever return 0 or 1. I expect this patch papers
> over
> > the underlying issue by not stopping often enough, rather than
> actually
> > fixing the underlying issue.
>
> Ah, any thoughts? Have you guys seen this behavior as well?
We ran into this same problem and the fix we've been running with for a while now (been meaning to submit it!) is:
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index c2669b8..7925bd3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -312,8 +312,7 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
unsigned int count;
int i, copy_off;
- count = DIV_ROUND_UP(
- offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
+ count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
copy_off = skb_headlen(skb) % PAGE_SIZE;
The rationale for this is that if the header spanned a page boundary, you would calculate that it needs 2 slots for the header BUT netback_gop_skb copies the header into the start of the page so only needs one slot (and only decrements the count of inuse entries by 1).
We found this running with a VIF bridged to a USB 3G Modem where skb->data started near the end of a page so the header would always span the page boundary.
It was very easy to get the VIF to stop processing frames with the old code and we have not seen any problems since applying this patch.
Simon
^ permalink raw reply related
* Re: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
From: Ben Hutchings @ 2012-05-22 18:59 UTC (permalink / raw)
To: Christer Ekholm; +Cc: Stephen Hemminger, netdev, Allan, Bruce W, e1000-devel
In-Reply-To: <20411.56693.728125.121309@ender.chrekh.se>
On Tue, 2012-05-22 at 20:39 +0200, Christer Ekholm wrote:
> Stephen Hemminger writes:
> > On Tue, 22 May 2012 11:19:50 -0700
> > Stephen Hemminger <shemminger@vyatta.com> wrote:
> >
> >
> > I believe the problem is detected here. Check system console log (dmesg).
> > The hardware does not allow receive hashing and checksum offload together
> > in Jumbo mode.
> >
> > /*
> > * IP payload checksum (enabled with jumbos/packet-split when
> > * Rx checksum is enabled) and generation of RSS hash is
> > * mutually exclusive in the hardware.
> > */
> > if ((netdev->features & NETIF_F_RXCSUM) &&
> > (netdev->features & NETIF_F_RXHASH)) {
> > e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.\n");
> > return -EINVAL;
> > }
>
> Yes you are right.
>
> e1000e 0000:05:00.1: eth1: Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.
>
> How stupid of me to not see that.
>
> After turning rxhash of, setting of mtu to 9000 is possible again.
>
> $ sudo ethtool -K eth1 rxhash off
>
> $ sudo ip link set eth1 mtu 9000
>
>
> Sorry to have wasted your time.
It's not a waste of time.
I think this behaviour is broken: NETIF_F_RXHASH is turned on by default
and user and distribution scripts that set MTU will now be broken until
they know that they need to work around this hardware limitation. And
why should they ever need to know that?
I think the proper thing to do is to automatically turn off
NETIF_F_RXHASH when the MTU is too high for it to work. The netdev
still keeps track of whether it is 'wanted'.
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 0/5] netdev/phy: 10G PHY support.
From: David Miller @ 2012-05-22 18:57 UTC (permalink / raw)
To: ddaney.cavm
Cc: devicetree-discuss, grant.likely, rob.herring, netdev,
linux-kernel, linux-mips, afleming, david.daney
In-Reply-To: <1337709592-23347-1-git-send-email-ddaney.cavm@gmail.com>
As mentioned the other day in my announement, right now it is
inappropriate to submit new feature patches.
You will need to resend these changes when the net-next tree opens
back up, please monitor the netdev list to learn when that has
happened.
^ permalink raw reply
* Re: [PATCH 5/5] netdev/phy: Add driver for Cortina cs4321 quad 10G PHY.
From: Ben Hutchings @ 2012-05-22 18:50 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss, Grant Likely, Rob Herring, David S. Miller,
netdev, linux-kernel, linux-mips, Andy Fleming, David Daney
In-Reply-To: <1337709592-23347-6-git-send-email-ddaney.cavm@gmail.com>
On Tue, May 22, 2012 at 10:59:52AM -0700, David Daney wrote:
[...]
> --- /dev/null
> +++ b/drivers/net/phy/cs4321-ucode.h
> @@ -0,0 +1,4378 @@
> +/*
> + * Copyright (C) 2011 by Cortina Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
[...]
So where's the real source code for it?
If you won't (or can't) provide source code for the microcode then it
should instead be submitted to linux-firmware with a binary
redistribution licence, and the driver should load it with
request_firmware().
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
* Re: [PATCH] rfkill: Add handling when rfkill's type is RFKILL_TYPE_ALL.
From: Johannes Berg @ 2012-05-22 18:46 UTC (permalink / raw)
To: Alex Hung
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1337589439-14605-1-git-send-email-alex.hung-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
On Mon, 2012-05-21 at 16:37 +0800, Alex Hung wrote:
> This rfkill type is supposed to be able to toggles the status of all wireless
> devices; however, no wireless devices will register itself with type
> RFKILL_TYPE_ALL and thus it was previously ignored in __rfkill_switch_all.
>
> Signed-off-by: Alex Hung <alex.hung-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> net/rfkill/core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index 5be1957..84dd71a 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -324,7 +324,7 @@ static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
>
> rfkill_global_states[type].cur = blocked;
> list_for_each_entry(rfkill, &rfkill_list, node) {
> - if (rfkill->type != type)
> + if (rfkill->type != type && type != RFKILL_TYPE_ALL)
> continue;
Sorry, I accidentally replied to this in private and then Alex replied
but it all got lost.
He said he was going to change the eeepc use KEY_RFKILL instead of
KEY_WLAN to switch all types...
So I guess what this change really does is make __rfkill_switch_all() be
able to not only switch all devices of a given type, but also be able to
switch all devices of all types.
Alex, can you please rewrite the commit log to make that clearer?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
From: Christer Ekholm @ 2012-05-22 18:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Allan, Bruce W, e1000-devel
In-Reply-To: <20120522112518.70294c0e@nehalam.linuxnetplumber.net>
Stephen Hemminger writes:
> On Tue, 22 May 2012 11:19:50 -0700
> Stephen Hemminger <shemminger@vyatta.com> wrote:
>
>
> I believe the problem is detected here. Check system console log (dmesg).
> The hardware does not allow receive hashing and checksum offload together
> in Jumbo mode.
>
> /*
> * IP payload checksum (enabled with jumbos/packet-split when
> * Rx checksum is enabled) and generation of RSS hash is
> * mutually exclusive in the hardware.
> */
> if ((netdev->features & NETIF_F_RXCSUM) &&
> (netdev->features & NETIF_F_RXHASH)) {
> e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.\n");
> return -EINVAL;
> }
Yes you are right.
e1000e 0000:05:00.1: eth1: Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.
How stupid of me to not see that.
After turning rxhash of, setting of mtu to 9000 is possible again.
$ sudo ethtool -K eth1 rxhash off
$ sudo ip link set eth1 mtu 9000
Sorry to have wasted your time.
--
Christer
^ permalink raw reply
* Re: [PATCH 4/5] netdev/phy: Add driver for Broadcom BCM87XX 10G Ethernet PHYs
From: Joe Perches @ 2012-05-22 18:34 UTC (permalink / raw)
To: David Daney
Cc: David Daney, devicetree-discuss@lists.ozlabs.org, Grant Likely,
Rob Herring, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
Fleming Andy-AFLEMING
In-Reply-To: <4FBBDA70.8020307@cavium.com>
On Tue, 2012-05-22 at 11:26 -0700, David Daney wrote:
> On 05/22/2012 11:17 AM, Joe Perches wrote:
> > On Tue, 2012-05-22 at 10:59 -0700, David Daney wrote:
> >> From: David Daney<david.daney@cavium.com>
> >
> > trivia:
>
> As long as we are splitting hairs...
and zooming in and enhancing...
> >
> >> diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/bcm87xx.c
> > []
> >> @@ -0,0 +1,237 @@
> >
> >> +static int bcm87xx_of_reg_init(struct phy_device *phydev)
> >> +{
> >> + const __be32 *paddr;
> >> + int len, i, ret;
> >> +
> >> + if (!phydev->dev.of_node)
> >> + return 0;
> >> +
> >> + paddr = of_get_property(phydev->dev.of_node,
> >> + "broadcom,c45-reg-init",&len);
> >> + if (!paddr || len< (4 * sizeof(*paddr)))
> >> + return 0;
> >> +
> >> + ret = 0;
> >> + len /= sizeof(*paddr);
> >> + for (i = 0; i< len - 3; i += 4) {
> >> + u16 devid = be32_to_cpup(paddr + i);
> >> + u16 reg = be32_to_cpup(paddr + i + 1);
> >> + u16 mask = be32_to_cpup(paddr + i + 2);
> >> + u16 val_bits = be32_to_cpup(paddr + i + 3);
> >> + int val;
> >
> > These might read better as
> >
> > len /= 4;
>
> Where did the magic value of 4 come from?
equivalence to the original for loop
for (i = 0; i < len - 3; i += 4) {
> > for (i = 0; i< len; i++) {
> > u16 devid = be32_to_cpu(*paddr++);
> > u16 reg = be32_to_cpu(*paddr++);
> > u16 mask = be32_to_cpu(*paddr++);
> > u16 val_bits = be32_to_cpu(*paddr++);
>
> Is the main problem that they didn't align, or that the index was
> explicit instead of implicit?
There's no real problem, it's just that
i++, be32_to_cpu and *addr++ is a bit
more common and perhaps more easily read.
The alignment's just a visual nicety.
Ignore it if you choose.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] xen: do not disable netfront in dom0
From: Konrad Rzeszutek Wilk @ 2012-05-22 18:34 UTC (permalink / raw)
To: Marek Marczykowski, davem
Cc: netdev, Jeremy Fitzhardinge, virtualization, linux-kernel,
xen-devel
In-Reply-To: <20120522130558.D828E6C7@duch.mimuw.edu.pl>
On Sun, May 20, 2012 at 01:45:10PM +0200, Marek Marczykowski wrote:
> Netfront driver can be also useful in dom0, eg when all NICs are assigned to
> some domU (aka driver domain). Then using netback in domU and netfront in dom0
> is the only way to get network access in dom0.
>
> Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> drivers/net/xen-netfront.c | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 698b905..e31ebff 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1953,9 +1953,6 @@ static int __init netif_init(void)
> if (!xen_domain())
> return -ENODEV;
>
> - if (xen_initial_domain())
> - return 0;
> -
> printk(KERN_INFO "Initialising Xen virtual ethernet driver.\n");
>
> return xenbus_register_frontend(&netfront_driver);
> @@ -1965,9 +1962,6 @@ module_init(netif_init);
>
> static void __exit netif_exit(void)
> {
> - if (xen_initial_domain())
> - return;
> -
> xenbus_unregister_driver(&netfront_driver);
> }
> module_exit(netif_exit);
> --
> 1.7.4.4
^ permalink raw reply
* RE: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
From: Allan, Bruce W @ 2012-05-22 18:28 UTC (permalink / raw)
To: Stephen Hemminger, che@chrekh.se
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net
In-Reply-To: <20120522112518.70294c0e@nehalam.linuxnetplumber.net>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Stephen Hemminger
> Sent: Tuesday, May 22, 2012 11:25 AM
> To: che@chrekh.se
> Cc: netdev@vger.kernel.org; e1000-devel@lists.sf.net
> Subject: Re: [Bug 43277] New: net/e1000e set mtu larger than 1500
> fails
>
> On Tue, 22 May 2012 11:19:50 -0700
> Stephen Hemminger <shemminger@vyatta.com> wrote:
>
> >
> >
> > Begin forwarded message:
> >
> > Date: Tue, 22 May 2012 18:13:21 +0000 (UTC)
> > From: bugzilla-daemon@bugzilla.kernel.org
> > To: shemminger@linux-foundation.org
> > Subject: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
> >
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=43277
> >
> > Summary: net/e1000e set mtu larger than 1500 fails
> > Product: Networking
> > Version: 2.5
> > Kernel Version: 3.4
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: IPV4
> > AssignedTo: shemminger@linux-foundation.org
> > ReportedBy: che@chrekh.se
> > Regression: Yes
> >
> >
> > In kernel 3.4 I can no longer use jumbo-frames with my e1000e
> network
> > interface.
> >
> > $ sudo ip link set eth1 mtu 9000
> > RTNETLINK answers: Invalid argument
>
> I believe the problem is detected here. Check system console log
> (dmesg).
> The hardware does not allow receive hashing and checksum offload
> together
> in Jumbo mode.
>
> /*
> * IP payload checksum (enabled with jumbos/packet-split when
> * Rx checksum is enabled) and generation of RSS hash is
> * mutually exclusive in the hardware.
> */
> if ((netdev->features & NETIF_F_RXCSUM) &&
> (netdev->features & NETIF_F_RXHASH)) {
> e_err("Jumbo frames cannot be enabled when both receive
> checksum offload and receive hashing are enabled. Disable one of the
> receive offload features before enabling jumbos.\n");
> return -EINVAL;
> }
That is correct.
^ permalink raw reply
* Re: [PATCH 4/5] netdev/phy: Add driver for Broadcom BCM87XX 10G Ethernet PHYs
From: David Daney @ 2012-05-22 18:26 UTC (permalink / raw)
To: Joe Perches
Cc: David Daney, devicetree-discuss@lists.ozlabs.org, Grant Likely,
Rob Herring, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
Fleming Andy-AFLEMING
In-Reply-To: <1337710660.3432.8.camel@joe2Laptop>
On 05/22/2012 11:17 AM, Joe Perches wrote:
> On Tue, 2012-05-22 at 10:59 -0700, David Daney wrote:
>> From: David Daney<david.daney@cavium.com>
>
> trivia:
As long as we are splitting hairs...
>
>> diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/bcm87xx.c
> []
>> @@ -0,0 +1,237 @@
>
>> +static int bcm87xx_of_reg_init(struct phy_device *phydev)
>> +{
>> + const __be32 *paddr;
>> + int len, i, ret;
>> +
>> + if (!phydev->dev.of_node)
>> + return 0;
>> +
>> + paddr = of_get_property(phydev->dev.of_node,
>> + "broadcom,c45-reg-init",&len);
>> + if (!paddr || len< (4 * sizeof(*paddr)))
>> + return 0;
>> +
>> + ret = 0;
>> + len /= sizeof(*paddr);
>> + for (i = 0; i< len - 3; i += 4) {
>> + u16 devid = be32_to_cpup(paddr + i);
>> + u16 reg = be32_to_cpup(paddr + i + 1);
>> + u16 mask = be32_to_cpup(paddr + i + 2);
>> + u16 val_bits = be32_to_cpup(paddr + i + 3);
>> + int val;
>
> These might read better as
>
> len /= 4;
Where did the magic value of 4 come from?
> for (i = 0; i< len; i++) {
> u16 devid = be32_to_cpu(*paddr++);
> u16 reg = be32_to_cpu(*paddr++);
> u16 mask = be32_to_cpu(*paddr++);
> u16 val_bits = be32_to_cpu(*paddr++);
Is the main problem that they didn't align, or that the index was
explicit instead of implicit?
^ permalink raw reply
* Re: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
From: Stephen Hemminger @ 2012-05-22 18:25 UTC (permalink / raw)
To: che; +Cc: netdev, e1000-devel
In-Reply-To: <20120522111950.4548747c@nehalam.linuxnetplumber.net>
On Tue, 22 May 2012 11:19:50 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
>
>
> Begin forwarded message:
>
> Date: Tue, 22 May 2012 18:13:21 +0000 (UTC)
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=43277
>
> Summary: net/e1000e set mtu larger than 1500 fails
> Product: Networking
> Version: 2.5
> Kernel Version: 3.4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: che@chrekh.se
> Regression: Yes
>
>
> In kernel 3.4 I can no longer use jumbo-frames with my e1000e network
> interface.
>
> $ sudo ip link set eth1 mtu 9000
> RTNETLINK answers: Invalid argument
I believe the problem is detected here. Check system console log (dmesg).
The hardware does not allow receive hashing and checksum offload together
in Jumbo mode.
/*
* IP payload checksum (enabled with jumbos/packet-split when
* Rx checksum is enabled) and generation of RSS hash is
* mutually exclusive in the hardware.
*/
if ((netdev->features & NETIF_F_RXCSUM) &&
(netdev->features & NETIF_F_RXHASH)) {
e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.\n");
return -EINVAL;
}
^ permalink raw reply
* Fw: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
From: Stephen Hemminger @ 2012-05-22 18:19 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel
Begin forwarded message:
Date: Tue, 22 May 2012 18:13:21 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
https://bugzilla.kernel.org/show_bug.cgi?id=43277
Summary: net/e1000e set mtu larger than 1500 fails
Product: Networking
Version: 2.5
Kernel Version: 3.4
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: che@chrekh.se
Regression: Yes
In kernel 3.4 I can no longer use jumbo-frames with my e1000e network
interface.
$ sudo ip link set eth1 mtu 9000
RTNETLINK answers: Invalid argument
Card-info (from kernel-log)
e1000e 0000:05:00.1: eth1: (PCI Express:2.5GT/s:Width x4) 00:1b:78:59:84:25
e1000e 0000:05:00.1: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:05:00.1: eth1: MAC: 0, PHY: 4, PBA No: D51930-003
I have bisected and found:
70495a500d787c0c90a136acf454cb7d0eecd82e is the first bad commit
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ 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