* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Stephen Hemminger @ 2011-08-15 18:25 UTC (permalink / raw)
To: Nick Carter; +Cc: David Lamparter, netdev, Michał Mirosław, davem
In-Reply-To: <CAEJpZP3PHC32i8m74-ML6DDGii8ojJ6v12CqQ+v2MKEMSDU=7A@mail.gmail.com>
On Mon, 15 Aug 2011 17:27:12 +0100
Nick Carter <ncarter100@gmail.com> wrote:
> On 28 July 2011 16:41, Stephen Hemminger
> <shemminger@linux-foundation.org> wrote:
> > On Wed, 27 Jul 2011 13:17:15 +0200
> > David Lamparter <equinox@diac24.net> wrote:
> >
> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> >> > > > >> I am still undecided on this. Understand the need, but don't like idea
> >> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
> >> > > > >> has any input.
> >> > > > >
> >> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
> >> > > > > is 0, which just keeps the old behaviour.
> >> >
> >> > P.S.: I'd like to once more stress this. In my opinion the patch should
> >> > be merged because it provides desireable functionality at a small cost
> >> > (one test, one knob) and __does not change any default behaviour__.
> >>
> >> Stephen, anything new on this?
> >
> > No.
> > Don't like adding yet another hack user visible API which will have
> > to be maintained for too long. But on the other hand I don't have
> > a better solution at my finger tips. If better idea doesn't come
> > along, then we can go with yours.
> >
> I have not noticed any other proposals and this thread has been open
> for quite a while. Have we waited long enough ? If so can this patch
> be taken ?
>
I am testing an alternative. The problem with your proposal is that
it relies on the multicast address. It turns out there are people using
other addresses for the STP group address, so using that as a identifier
is incorrect.
^ permalink raw reply
* Re: igb transmit queue timed out, rcu_sched_state detected stall
From: Ben Hutchings @ 2011-08-15 18:07 UTC (permalink / raw)
To: Peter Neal; +Cc: netdev
In-Reply-To: <CALJvf+qGt=GkD2oV8GEz7DWLzpCZGaAE5Gpse8HvPjgpT2Wmxw@mail.gmail.com>
On Mon, 2011-08-15 at 15:33 +0100, Peter Neal wrote:
> I have updated the BIOS, iproute2, e1000e and igb drivers, but am
> still seeing issues, any thoughts?
[...]
This issue doesn't seem network-related. However it might be related to
this regression that I saw discussed just a few minutes ago:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
Subject : RCU stall in linux-3.0.0
Submitter : Philip Armstrong <phil@kantaka.co.uk>
Date : 2011-07-25 21:44 (21 days old)
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: 3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0
From: Rafael J. Wysocki @ 2011-08-15 17:43 UTC (permalink / raw)
To: paulmck
Cc: Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Linus Torvalds, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <20110815153759.GF2389@linux.vnet.ibm.com>
On Monday, August 15, 2011, Paul E. McKenney wrote:
> On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote:
> > [NOTE:
> > We already have a bug entry for tracking regressions from 3.0:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=40982
> >
> > but there are no reports linked to it, mostly because Maciej is on vacation,
> > but also because the frequency of reporting regressions has been low
> > recently. So, if you're seeing a regression from 3.0, please let us know.]
> >
> > This message contains a list of some post-2.6.39 regressions introduced before
> > 3.0, for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved post-2.6.39 regressions, please let us know
> > either and we'll add them to the list. Also, please let us know if any
> > of the entries below are invalid.
> >
> > Each entry from the list will be sent additionally in an automatic reply to
> > this message with CCs to the people involved in reporting and handling the
> > issue.
> >
> >
> > Listed regressions statistics:
> >
> > Date Total Pending Unresolved
> > ----------------------------------------
> > 2011-08-14 63 22 19
> >
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40282
> > Subject : IP forwarding regression since 3.0-rc6
> > Submitter : Stephan Seitz <stse+lkml@fsing.rootsland.net>
> > Date : 2011-07-25 12:51 (21 days old)
> > Message-ID : <20110725T141145.GA.2ae38.stse@fsing.rootsland.net>
> > References : http://marc.info/?l=linux-kernel&m=131159880004908&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40172
> > Subject : lockdep trace from post 3.0.
> > Submitter : Dave Jones <davej@redhat.com>
> > Date : 2011-07-24 1:32 (22 days old)
> > Message-ID : <20110724013257.GA6777@redhat.com>
> > References : http://marc.info/?l=linux-kernel&m=131147120206819&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
> > Subject : RCU stall in linux-3.0.0
> > Submitter : Philip Armstrong <phil@kantaka.co.uk>
> > Date : 2011-07-25 21:44 (21 days old)
>
> This one was due the the CPU's idea of the current time getting way
> out of sync (as in more than a minute's worth of disagreement, which is
> pretty impressive when you think about it). So what happened is that
> one CPU decided that the current grace period was a full minute old
> immediately, and thus started screaming piteously. John Stultz provided
> a configuration workaround, and he and Thomas Gleixner would be working
> out the long-term fix.
Thanks for the update!
Rafael
^ permalink raw reply
* Re: invalid requirement from ethtool?
From: Ben Hutchings @ 2011-08-15 17:24 UTC (permalink / raw)
To: Eli Cohen, David Miller; +Cc: netdev
In-Reply-To: <20110726124222.GA4842@mtldesk30>
On Tue, 2011-07-26 at 15:42 +0300, Eli Cohen wrote:
> Hi,
> I see the following text in include/linux/ethtool.h and wonder what is
> the reasoning for requiring that both params cannot be zero. I could
> not track when and who inserted this text as it dates before git was
> used to track kernel code, but my feeling is that is related to a
> specific hardware limitation.
>
> /* How many packets to delay an RX interrupt after
> * a packet arrives. If 0, only rx_coalesce_usecs is
> * used. It is illegal to set both usecs and max frames
> * to zero as this would cause RX interrupts to never be
> * generated.
> */
> __u32 rx_max_coalesced_frames;
>
> /* How many packets to delay a TX interrupt after
> * a packet is sent. If 0, only tx_coalesce_usecs is
> * used. It is illegal to set both usecs and max frames
> * to zero as this would cause TX interrupts to never be
> * generated.
> */
> __u32 tx_max_coalesced_frames;
>
> I found this in tg3 driver:
> /* No rx interrupts will be generated if both are zero */
> if ((ec->rx_coalesce_usecs == 0) &&
> (ec->rx_max_coalesced_frames == 0))
> return -EINVAL;
>
> However, bnx2 for example allows setting both to zero.
>
> I think both params zero should be allowed and mean coalescing is not
> operational, thus we can remove these comments from ethtool.h
If coalescing is not operational, the maximum number of completions
before an interrupt is 1. So logically {rx,tx}_max_coalesced_frames
should be 1, right? Although the comment does say 'How many packets ...
after ...' which implies that the value of the field must be 1 less than
the wanted maximum, i.e. 0, which is supposedly invalid.
The first implementation of ethtool coalescing control was in tg3, so it
should be a useful reference.
David, I know you maintained tg3 for some time so I assume you have a
hardware reference. Can you confirm whether a value of 1 in
HOSTCC_{RX,TX}MAX_FRAMES results in an interrupt after 1 completion or
after 2 completions?
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 2/2] net: minor update to Documentation/networking/scaling.txt
From: Rick Jones @ 2011-08-15 16:56 UTC (permalink / raw)
To: Will de Bruijn; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <CA+FuTScsrN5=NLeHgyNP+TXL+_auU6p80Lb5JUaMb_o5aGGqww@mail.gmail.com>
On 08/15/2011 09:11 AM, Will de Bruijn wrote:
>> I'd suggest simply "share a particular level in the memory hierarchy (Cache,
>> NUMA node, etc)" and that way you get away from people asking nitpicky
>> questions about where cache hierarchy counting starts, and at what level
>> caches might be shared :)
>>
>> Apart from that, looks fine.
>
> Thanks. It is already applied, so if you don't feel strongly about
> this, I'll leave it as is (and take any nitpicky flak if that comes ;)
Sounds like a plan.
rick
^ permalink raw reply
* Kindly read and reply through my private email... inna.patarkat3@qatar.io
From: Enquiries @ 2011-08-15 15:26 UTC (permalink / raw)
Kindly read and reply through my private email... inna.patarkat3@qatar.io
An Emergency from Mrs. Inna Patarkatsishvil
Greetings in the name of the Lord, I am Mrs. Inna Patarkatsishvili, the widow of late Georgian business tycoon Mr. Badri Patarkatsishvili, I have a business proposal which will be of great benefit to you and myself. I will send you further details once i receive your response back. Please for security reason, i will strongly recommend that you write me through my private email account only.Thanks for your understanding.
Yours truly,
Mrs. Inna Patarkatsishvili
Private Email: inna.patarkat4@qatar.io
-------------------------------------------------------------------------
DISCLAIMER:-
Matheson & Co., Limited is a company registered in England and Wales.
Company Registration Number: 100295.
Registered Office: 3 Lombard Street, London EC3V 9AQ, UK
Matheson & Co., Limited, established in London in 1848, is a wholly owned
subsidiary of Jardine Matheson Holdings Limited.
This email is confidential and intended only for the use
of the individual or entity named above and may contain
information that is privileged. If you are not the intended
recipient, you are notified that any dissemination, distribution
or copying of this email is strictly prohibited.
If you have received this email in error, please notify us immediately by
return email or telephone 020 7816 8100 and destroy the original message.
Thank you.
-------------------------------------------------------------------------
^ permalink raw reply
* [PATCH] dm9000: control debug level of the driver
From: Vladimir Zapolskiy @ 2011-08-15 16:38 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Vladimir Zapolskiy, Ben Dooks
This change allows to get driver specific debug messages output
setting a default value for db->debug_level. As far as the maximum
level of verbosity is too high, it is demoted by default.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/net/Kconfig | 2 +-
drivers/net/dm9000.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8d0314d..20e7936 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -988,7 +988,7 @@ config DM9000
config DM9000_DEBUGLEVEL
int "DM9000 maximum debug level"
depends on DM9000
- default 4
+ default 0
help
The maximum level of debugging code compiled into the DM9000
driver.
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 8ef31dc..b8509a8 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -138,8 +138,7 @@ typedef struct board_info {
/* debug code */
#define dm9000_dbg(db, lev, msg...) do { \
- if ((lev) < CONFIG_DM9000_DEBUGLEVEL && \
- (lev) < db->debug_level) { \
+ if ((lev) < db->debug_level) { \
dev_dbg(db->dev, msg); \
} \
} while (0)
@@ -1381,6 +1380,7 @@ dm9000_probe(struct platform_device *pdev)
db->dev = &pdev->dev;
db->ndev = ndev;
+ db->debug_level = CONFIG_DM9000_DEBUGLEVEL;
spin_lock_init(&db->lock);
mutex_init(&db->addr_lock);
--
1.7.5.1
^ permalink raw reply related
* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Nick Carter @ 2011-08-15 16:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Lamparter, netdev, Michał Mirosław, davem
In-Reply-To: <20110728084106.22166324@nehalam.ftrdhcpuser.net>
On 28 July 2011 16:41, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> On Wed, 27 Jul 2011 13:17:15 +0200
> David Lamparter <equinox@diac24.net> wrote:
>
>> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
>> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
>> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
>> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
>> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
>> > > > >> I am still undecided on this. Understand the need, but don't like idea
>> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
>> > > > >> has any input.
>> > > > >
>> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
>> > > > > is 0, which just keeps the old behaviour.
>> >
>> > P.S.: I'd like to once more stress this. In my opinion the patch should
>> > be merged because it provides desireable functionality at a small cost
>> > (one test, one knob) and __does not change any default behaviour__.
>>
>> Stephen, anything new on this?
>
> No.
> Don't like adding yet another hack user visible API which will have
> to be maintained for too long. But on the other hand I don't have
> a better solution at my finger tips. If better idea doesn't come
> along, then we can go with yours.
>
I have not noticed any other proposals and this thread has been open
for quite a while. Have we waited long enough ? If so can this patch
be taken ?
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH net-2.6] bonding:restore backup and inactive flag of slave
From: WANG Cong @ 2011-08-15 16:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <13dbe805d13bba461e50483c0162ce8bc1366204.1313403625.git.panweiping3@gmail.com>
On Mon, 15 Aug 2011 18:25:16 +0800, Weiping Pan wrote:
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c index 38a83ac..3ed9827 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3419,9 +3419,27 @@ static int bond_xmit_hash_policy_l2(struct
sk_buff *skb, int count)
> static int bond_open(struct net_device *bond_dev) {
> struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + int i;
>
> bond->kill_timers = 0;
>
> + // restore slave->backup and slave->inactive
Please use C-style comment.
> + read_lock(&bond->lock);
> + read_lock(&bond->curr_slave_lock);
> + if (bond->slave_cnt > 0) {
You can move the second read_lock() under this if().
^ permalink raw reply
* [PATCH net-next] ipv4: one more case for non-local saddr in ICMP
From: Julian Anastasov @ 2011-08-15 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Herbert Xu
May be there is one more case that we can avoid using
non-local source for ICMP errors: xfrm_lookup, num_xfrms = 0 when
reverse "Flow passes untransformed". Avoid using the input route
if xfrm_lookup returns same dst.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
In fact, should we use local IP in all cases when
sending ICMP? I'm asking it for the following case:
Large packet is forwarded but is rejected with ICMP FRAG
NEEDED. We usually send ICMP with local saddr instead of the
original non-local destination. What is the role of
this reverse check? May be after xfrm_decode_session_reverse
we should use 'fl4_dec.saddr = fl4->saddr;' so that xfrm_lookup
works with ICMP from local IP? What is right thing to do here?
I don't see code that looks in the embedded header...
--- net-next/net/ipv4/icmp.c 2011-08-15 18:42:21.289899686 +0300
+++ linux/net/ipv4/icmp.c 2011-08-15 18:38:25.816244111 +0300
@@ -379,7 +379,7 @@ static struct rtable *icmp_route_lookup(
int type, int code,
struct icmp_bxm *param)
{
- struct rtable *rt, *rt2;
+ struct rtable *rt, *rt2, *rt3;
struct flowi4 fl4_dec;
int err;
@@ -440,13 +440,18 @@ static struct rtable *icmp_route_lookup(
if (err)
goto relookup_failed;
+ rt3 = rt2;
rt2 = (struct rtable *) xfrm_lookup(net, &rt2->dst,
flowi4_to_flowi(&fl4_dec), NULL,
XFRM_LOOKUP_ICMP);
if (!IS_ERR(rt2)) {
- dst_release(&rt->dst);
- memcpy(fl4, &fl4_dec, sizeof(*fl4));
- rt = rt2;
+ if (rt2 == rt3 && rt) {
+ dst_release(&rt2->dst);
+ } else {
+ dst_release(&rt->dst);
+ memcpy(fl4, &fl4_dec, sizeof(*fl4));
+ rt = rt2;
+ }
} else if (PTR_ERR(rt2) == -EPERM) {
if (rt)
dst_release(&rt->dst);
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Marc Kleine-Budde @ 2011-08-15 16:13 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, Grant Likely, Scott Wood, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110815150357.GM4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --]
On 08/15/2011 05:03 PM, Robin Holt wrote:
> Earlier, you had asked for a more specific name for the compatible
> property of the Freescale flexcan device. I still have not gotten a
> more specific answer. Hopefully Marc can give you more details about
> the flexcan implementations.
There are at least 2 versions of the flexcan ip core in the wild. Due to
lack of version numbers or other names I call them old and new here :).
The newer one supports rx fifo mode, whereas the older one doesn't. The
mainline flexcan driver just supports the new core [1]. The older core
is found on coldfire processors. I don't know if there are coldfire cpus
with the new flexcan core, too. The driver can be adopted to the old
core if needed.
The first cpus with the new core I got in touch with was the mx35
(arm11) and mx25 (arm9) both at the same time. Ask fsl which one was
released first. After this there was mx28 (arm9) and there should be an
mx53 (coretexa8) with flexcan too.
> Other than an agreement on the compatible property, I believe we have
> agreement on all the other code changes in these patches. Is this change
> acceptable as is and if we get a better resolution on the fsl,flexcan
> name later, we can update the documentation and driver then?
cheers, Marc
[1] http://lxr.linux.no/linux+v3.0.1/drivers/net/can/flexcan.c#L871
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 2/2] net: minor update to Documentation/networking/scaling.txt
From: Will de Bruijn @ 2011-08-15 16:11 UTC (permalink / raw)
To: Rick Jones; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <4E45B810.3000501@hp.com>
> I'd suggest simply "share a particular level in the memory hierarchy (Cache,
> NUMA node, etc)" and that way you get away from people asking nitpicky
> questions about where cache hierarchy counting starts, and at what level
> caches might be shared :)
>
> Apart from that, looks fine.
Thanks. It is already applied, so if you don't feel strongly about
this, I'll leave it as is (and take any nitpicky flak if that comes ;)
^ permalink raw reply
* Re: [PATCH] ethtool: RX NFC - Convert ip address to big endian.
From: Ben Hutchings @ 2011-08-15 16:00 UTC (permalink / raw)
To: nirmu; +Cc: netdev, Nir Muchtar
In-Reply-To: <1313422846-6550-1-git-send-email-nirmu@dev.mellanox.co.il>
On Mon, 2011-08-15 at 18:40 +0300, nirmu@dev.mellanox.co.il wrote:
> From: Nir Muchtar <nirmu@dev.mellanox.co.il>
>
> Signed-off-by: Nir Muchtar <nirmu@mellanox.com>
> ---
> Unless there's a reason that I'm missing to why the user
> is expected to specify ip addresses in big endian format.
>
> rxclass.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/rxclass.c b/rxclass.c
> index b227901..98d035b 100644
> --- a/rxclass.c
> +++ b/rxclass.c
> @@ -704,7 +704,7 @@ static int rxclass_get_ulong(char *str, unsigned long long *val, int size)
> return 0;
> }
>
> -static int rxclass_get_ipv4(char *str, __be32 *val)
> +static int rxclass_get_ipv4(char *str, u32 *val)
> {
> if (!inet_pton(AF_INET, str, val))
> return -1;
[...]
inet_pton() does the conversion to big-endian format.
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
* [PATCH] ethtool: RX NFC - Convert ip address to big endian.
From: nirmu @ 2011-08-15 15:40 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, Nir Muchtar, Nir Muchtar
From: Nir Muchtar <nirmu@dev.mellanox.co.il>
Signed-off-by: Nir Muchtar <nirmu@mellanox.com>
---
Unless there's a reason that I'm missing to why the user
is expected to specify ip addresses in big endian format.
rxclass.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/rxclass.c b/rxclass.c
index b227901..98d035b 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -704,7 +704,7 @@ static int rxclass_get_ulong(char *str, unsigned long long *val, int size)
return 0;
}
-static int rxclass_get_ipv4(char *str, __be32 *val)
+static int rxclass_get_ipv4(char *str, u32 *val)
{
if (!inet_pton(AF_INET, str, val))
return -1;
@@ -828,11 +828,11 @@ static int rxclass_get_val(char *str, unsigned char *p, u32 *flags,
break;
}
case OPT_IP4: {
- __be32 val;
+ u32 val;
err = rxclass_get_ipv4(str, &val);
if (err)
return -1;
- *(__be32 *)&p[opt->offset] = val;
+ *(__be32 *)&p[opt->offset] = htonl((u32)val);
if (opt->moffset >= 0)
*(__be32 *)&p[opt->moffset] = (__be32)mask;
break;
@@ -929,11 +929,11 @@ static int rxclass_get_mask(char *str, unsigned char *p,
break;
}
case OPT_IP4: {
- __be32 val;
+ u32 val;
err = rxclass_get_ipv4(str, &val);
if (err)
return -1;
- *(__be32 *)&p[opt->moffset] = ~val;
+ *(__be32 *)&p[opt->moffset] = ~htonl((u32)val);
break;
}
case OPT_MAC: {
--
1.7.1
^ permalink raw reply related
* Re: 3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0
From: Paul E. McKenney @ 2011-08-15 15:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Linus Torvalds, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <xuTC4jRtHbB.A.l4H.gMCSOB@chimera>
On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote:
> [NOTE:
> We already have a bug entry for tracking regressions from 3.0:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=40982
>
> but there are no reports linked to it, mostly because Maciej is on vacation,
> but also because the frequency of reporting regressions has been low
> recently. So, if you're seeing a regression from 3.0, please let us know.]
>
> This message contains a list of some post-2.6.39 regressions introduced before
> 3.0, for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved post-2.6.39 regressions, please let us know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2011-08-14 63 22 19
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40282
> Subject : IP forwarding regression since 3.0-rc6
> Submitter : Stephan Seitz <stse+lkml-S0d6l+6kcjrOGKtSYHEJQ9HuzzzSOjJt@public.gmane.org>
> Date : 2011-07-25 12:51 (21 days old)
> Message-ID : <20110725T141145.GA.2ae38.stse-S0d6l+6kcjrOGKtSYHEJQ9HuzzzSOjJt@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=131159880004908&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40172
> Subject : lockdep trace from post 3.0.
> Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date : 2011-07-24 1:32 (22 days old)
> Message-ID : <20110724013257.GA6777-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=131147120206819&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
> Subject : RCU stall in linux-3.0.0
> Submitter : Philip Armstrong <phil-awZZuG094qgqdlJmJB21zg@public.gmane.org>
> Date : 2011-07-25 21:44 (21 days old)
This one was due the the CPU's idea of the current time getting way
out of sync (as in more than a minute's worth of disagreement, which is
pretty impressive when you think about it). So what happened is that
one CPU decided that the current grace period was a full minute old
immediately, and thus started screaming piteously. John Stultz provided
a configuration workaround, and he and Thomas Gleixner would be working
out the long-term fix.
Thanx, Paul
^ permalink raw reply
* [PATCH] net_sched: fix port mirror/redirect stats reporting
From: jamal @ 2011-08-15 15:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
commit 6a51508a01671114c236602d071d4bff53422c60
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon Aug 15 11:17:06 2011 -0400
[PATCH] net_sched: fix port mirror/redirect stats reporting
When a redirected or mirrored packet is dropped by the target
device we need to record statistics.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 961386e..d5ef6ec 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -196,8 +196,7 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
skb2->skb_iif = skb->dev->ifindex;
skb2->dev = dev;
- dev_queue_xmit(skb2);
- err = 0;
+ err = dev_queue_xmit(skb2);
out:
if (err) {
^ permalink raw reply related
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-15 15:25 UTC (permalink / raw)
To: Grant Likely
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <CACxGe6vafc6mYyKCAO+HqkRPsZ3GmeVJnK+z8=BX_wQQMG4LmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 15, 2011 at 09:13:50AM -0600, Grant Likely wrote:
> On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt-sJ/iWh9BUns@public.gmane.org> wrote:
> > Grant,
> >
> > Earlier, you had asked for a more specific name for the compatible
> > property of the Freescale flexcan device. I still have not gotten a
> > more specific answer. Hopefully Marc can give you more details about
> > the flexcan implementations.
>
> If there is no ip core version, then just stick with the
> fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
> flexcan is flexcan, but hardware engineers like to change things.
> Trying to be too generic in compatible values will just lead to
> problems in the future.
Thanks,
Robin
^ permalink raw reply
* Re: Fw: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be broken.
From: Julian Anastasov @ 2011-08-15 15:27 UTC (permalink / raw)
To: David Hill; +Cc: Florian Mickler, netdev, David Miller, bugzilla-daemon
In-Reply-To: <8A188C9C23A54337A5A276BAE29DC6E0@delorimier>
Hello,
On Fri, 5 Aug 2011, David Hill wrote:
> Hello Julian,
>
> I'm not using TPROXY and I've used a blank firewall with only masquerading
> and reproduced the issue.
> Nothing is in NAT/mangle nor OUTPUT but the rules mentionned in the attached
> files to this bug.
>
> Francis Whittle (Comment #18) has the same issue.
>
> > Hello,
> >
> > On Thu, 4 Aug 2011, Florian Mickler wrote:
> >
> > > Can someone take a look at this regression?
> > >
> > > Begin forwarded message:
> > >
> > > Date: Thu, 28 Jul 2011 04:51:12 GMT
> > > From: bugzilla-daemon@bugzilla.kernel.org
> > > To: florian@mickler.org
> > > Subject: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be
> > > broken.
> > >
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=39132
> >
> > So, problem points again to
> > "Fix ip_route_me_harder triggering ip_rt_bug" ? May be
> > David C. Hill or Florian can provide some information, eg. is
> > tproxy used, what NAT rules are used, any rules in OUTPUT
> > hooks (NAT/mangle) and which packets are dropped.
May be it is a sequence of two problems. I now
checked the tcpdump log from Francis Whittle. The
"seq 352:1792" packet at 18:44:29.235154 that is not
SNAT-ed is long, can it be some PMTU event that triggers
ICMP response to the internal host? Because I see changes
in MSS. May be rc5 triggers ICMP FRAG NEEDED while rc6
does not. It can happen because:
1. ICMP uses non-local iph->saddr when XFRM is compiled,
reverse lookup fails with ENOENT but fl4->saddr is
already damaged with the original daddr (non-local).
Fix is here: http://marc.info/?t=131118984300003&r=1&w=2
2. The patched ip_route_me_harder between 3.0-rc5 and
3.0-rc6 expects that sockets always provide local address.
This is wrong for some cases such as TCP (uses different
SOCK_RAW socket for some packets and can cause problem
for tproxy), RAW (can use spoofed sources) and now the
ICMP code that incorrectly provides non-local address.
Fix is here: http://marc.info/?t=131274411600001&r=1&w=2
I hope (any of) these two fixes should solve the
masquerading problems. If that is not true, tcpdump from rc5
would be helpful for comparison.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Grant Likely @ 2011-08-15 15:13 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <20110815150357.GM4926-sJ/iWh9BUns@public.gmane.org>
On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt-sJ/iWh9BUns@public.gmane.org> wrote:
> Grant,
>
> Earlier, you had asked for a more specific name for the compatible
> property of the Freescale flexcan device. I still have not gotten a
> more specific answer. Hopefully Marc can give you more details about
> the flexcan implementations.
If there is no ip core version, then just stick with the
fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
flexcan is flexcan, but hardware engineers like to change things.
Trying to be too generic in compatible values will just lead to
problems in the future.
g.
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-15 15:13 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313411585.31417.35.camel@lb-tlvb-eilong.il.broadcom.com>
On 08/15/2011 02:33 PM, Eilon Greenstein wrote:
> On Mon, 2011-08-15 at 04:59 -0700, Michal Schmidt wrote:
>> and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
>> VN, so it seems that the warning can be produced for a non-current VN.
>
> You are right, only one function (the PMF) will call this code for all
> functions. But I suspect that if you have zero values, you will have
> them for all VNs - is that the case?
A tester reported getting only these 4 messages with the patch applied:
[bnx2x_extract_max_cfg:1074(eth4)]Illegal configuration detected for Max
BW on vn 2 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth5)]Illegal configuration detected for Max
BW on vn 2 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth6)]Illegal configuration detected for Max
BW on vn 3 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth7)]Illegal configuration detected for Max
BW on vn 3 - using 100 instead
This suggests that VNs 0 and 1 had non-zero Max BW configuration.
Michal
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-15 15:03 UTC (permalink / raw)
To: Grant Likely, Marc Kleine-Budde
Cc: Robin Holt, Kumar Gala, Wolfgang Grandegger, U Bhaskar-B22300,
Scott Wood, socketcan-core, netdev, PPC list, devicetree-discuss
In-Reply-To: <1313138752-24006-4-git-send-email-holt@sgi.com>
Grant,
Earlier, you had asked for a more specific name for the compatible
property of the Freescale flexcan device. I still have not gotten a
more specific answer. Hopefully Marc can give you more details about
the flexcan implementations.
Other than an agreement on the compatible property, I believe we have
agreement on all the other code changes in these patches. Is this change
acceptable as is and if we get a better resolution on the fsl,flexcan
name later, we can update the documentation and driver then?
Thanks,
Robin
On Fri, Aug 12, 2011 at 03:45:49AM -0500, Robin Holt wrote:
> This patch cleans up the documentation of the device-tree binding for
> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> properties are not used by the driver so we are removing them.
>
> Signed-off-by: Robin Holt <holt@sgi.com>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>,
> To: Wolfgang Grandegger <wg@grandegger.com>,
> To: U Bhaskar-B22300 <B22300@freescale.com>
> To: Scott Wood <scottwood@freescale.com>
> To: Grant Likely <grant.likely@secretlab.ca>
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: socketcan-core@lists.berlios.de,
> Cc: netdev@vger.kernel.org,
> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ++++----------------
> arch/powerpc/boot/dts/p1010rdb.dts | 10 +---
> arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
> 3 files changed, 17 insertions(+), 64 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> index 1a729f0..80a78a9 100644
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> @@ -1,61 +1,22 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> +Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
>
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> +Required properties:
>
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> +- compatible : Should be "fsl,<processor>-flexcan" and "fsl,flexcan"
>
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> + An implementation should also claim any of the following compatibles
> + that it is fully backwards compatible with:
>
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> + - fsl,p1010-flexcan
>
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> +- reg : Offset and length of the register set for this device
> +- interrupts : Interrupt tuple for this device
>
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> +Example:
>
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + can@1c000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divider = <2>;
> - clock-frequency = <fixed by u-boot>;
> };
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index 6b33b73..d6c669c 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -23,6 +23,8 @@
> ethernet2 = &enet2;
> pci0 = &pci0;
> pci1 = &pci1;
> + can0 = &can0;
> + can1 = &can1;
> };
>
> memory {
> @@ -169,14 +171,6 @@
> };
> };
>
> - can0@1c000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> - can1@1d000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> index 7f51104..f00076b 100644
> --- a/arch/powerpc/boot/dts/p1010si.dtsi
> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> @@ -140,20 +140,18 @@
> interrupt-parent = <&mpic>;
> };
>
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + can0: can@1c000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> - can1@1d000 {
> - compatible = "fsl,flexcan-v1.0";
> + can1: can@1d000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1d000 0x1000>;
> interrupts = <61 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> L2: l2-cache-controller@20000 {
> --
> 1.7.2.1
^ permalink raw reply
* Re: igb transmit queue timed out, rcu_sched_state detected stall
From: Peter Neal @ 2011-08-15 14:33 UTC (permalink / raw)
To: netdev
In-Reply-To: <CALJvf+qLZyXpxfDR-3aJVn2Qf558SKPc85NpQOosafqxCUC46w@mail.gmail.com>
I have updated the BIOS, iproute2, e1000e and igb drivers, but am
still seeing issues, any thoughts?
Thanks,
Pete
[ 7765.881893] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Up, 1000
Mbps full duplex, receive & transmit flow control ON
[ 7767.395912] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Down
[ 7769.832448] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Up, 1000
Mbps full duplex, receive & transmit flow control ON
[ 7778.124580] igb: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7783.001120] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7783.900216] igb: eth4 NIC Link is Down
[ 7786.204560] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7788.168523] igb: eth18 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7789.414458] igb: eth18 NIC Link is Down
[ 7791.702958] igb: eth18 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7794.188210] igb: eth12 NIC Link is Down
[ 7796.432599] igb: eth12 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7826.864941] e1000e: eth21 NIC Link is Up 1000 Mbps Full Duplex,
Flow Control: Rx/Tx
[ 7836.544159] igb: eth17 NIC Link is Down
[ 7864.112307] igb: eth6 NIC Link is Down
[ 7917.072196] igb: eth16 NIC Link is Down
[ 7919.356618] igb: eth16 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7920.848574] igb: eth10 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7926.272173] igb: eth4 NIC Link is Down
[ 7965.212587] igb: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7966.200164] igb: eth6 NIC Link is Down
[ 7968.742002] igb: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7971.112151] e1000e: eth20 NIC Link is Down
[ 7973.084709] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7973.452998] e1000e: eth20 NIC Link is Up 1000 Mbps Full Duplex,
Flow Control: Rx/Tx
[ 7974.300193] igb: eth4 NIC Link is Down
[ 7976.616567] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 8041.200005] INFO: rcu_sched_state detected stall on CPU 2 (t=15000 jiffies)
[ 8041.835999] INFO: rcu_bh_state detected stall on CPU 2 (t=15000 jiffies)
[ 8060.251724] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Down
[ 8096.268889] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Up, 1000
Mbps full duplex, receive & transmit flow control ON
[ 8161.920070] INFO: task irqbalance:1777 blocked for more than 120 seconds.
[ 8162.001213] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8162.094833] irqbalance D ffff88042e9abd50 0 1777 1 0x00000000
[ 8162.179119] ffff88042e9abd50 0000000000000086 ffff88042e9abd50
ffff88042ec6a8e0
[ 8162.267569] 0000000000012680 ffff88042b5fdfd8 ffff88042b5fdfd8
0000000000012680
[ 8162.356047] ffff88042e9abd50 ffff88042b5fc010 0000000100000000
ffff88042b995f60
[ 8162.444498] Call Trace:
[ 8162.473641] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8162.548540] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8162.611996] [<ffffffff81269ca6>] ? dev_load+0x9/0x70
[ 8162.672333] [<ffffffff8126b017>] ? dev_ioctl+0x4ad/0x62e
[ 8162.736839] [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[ 8162.803415] [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[ 8162.868959] [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[ 8162.937616] [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[ 8163.005235] [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[ 8163.074938] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8163.138393] [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[ 8163.200810] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8163.274672] INFO: task snmpd:1797 blocked for more than 120 seconds.
[ 8163.350609] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8163.444228] snmpd D ffff88042aa4d890 0 1797 1 0x00000000
[ 8163.528516] ffff88042aa4d890 0000000000000086 ffff88042aa4d890
ffff88042ec6a8e0
[ 8163.616962] 0000000000012680 ffff88042d7b7fd8 ffff88042d7b7fd8
0000000000012680
[ 8163.705415] ffff88042aa4d890 ffff88042d7b6010 0000000100000000
ffff88042b995f60
[ 8163.793870] Call Trace:
[ 8163.823001] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8163.897900] [<ffffffff810fa4b3>] ? dget+0x12/0x1e
[ 8163.955115] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8164.018572] [<ffffffff8126aba4>] ? dev_ioctl+0x3a/0x62e
[ 8164.082034] [<ffffffff81103734>] ? dput+0x29/0xe9
[ 8164.139253] [<ffffffff810eb735>] ? get_partial_node+0x15/0x7b
[ 8164.208949] [<ffffffff810f3cfa>] ? get_empty_filp+0x69/0x12b
[ 8164.277606] [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[ 8164.344186] [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[ 8164.409721] [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[ 8164.478377] [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[ 8164.545996] [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[ 8164.615696] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8164.679156] [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[ 8164.741574] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8164.815438] INFO: task sshd:806 blocked for more than 120 seconds.
[ 8164.889300] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8164.982918] sshd D ffff88042d62e630 0 806 1814 0x00000000
[ 8165.067195] ffff88042d62e630 0000000000000086 ffff88042d62e630
ffff88042edb5890
[ 8165.155645] 0000000000012680 ffff8803fa8fffd8 ffff8803fa8fffd8
0000000000012680
[ 8165.244109] ffff88042d62e630 ffff8803fa8fe010 0000000100000000
ffff88042b995f60
[ 8165.332561] Call Trace:
[ 8165.361699] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8165.436600] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8165.500064] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8165.565602] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8165.635298] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8165.706044] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8165.779901] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8165.845439] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8165.907854] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8165.975475] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8166.048289] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8166.112785] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8166.176242] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8166.250105] INFO: task sshd:807 blocked for more than 120 seconds.
[ 8166.323964] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8166.417581] sshd D ffff88042a491470 0 807 1814 0x00000000
[ 8166.501865] ffff88042a491470 0000000000000086 ffff88042a491470
ffff88042edb73d0
[ 8166.590321] 0000000000012680 ffff8803e7e37fd8 ffff8803e7e37fd8
0000000000012680
[ 8166.678785] ffff88042a491470 ffff8803e7e36010 0000000100000000
ffff88042b995f60
[ 8166.767243] Call Trace:
[ 8166.796385] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8166.871289] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8166.934748] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8167.000284] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8167.069987] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8167.140727] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8167.214584] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8167.280121] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8167.342543] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8167.410162] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8167.482978] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8167.547477] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8167.610937] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8167.684797] INFO: task sshd:808 blocked for more than 120 seconds.
[ 8167.758654] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8167.852272] sshd D ffff88042a494420 0 808 1814 0x00000000
[ 8167.936556] ffff88042a494420 0000000000000082 ffff88042a494420
ffff88042e9a8000
[ 8168.025020] 0000000000012680 ffff88042daa9fd8 ffff88042daa9fd8
0000000000012680
[ 8168.113482] ffff88042a494420 ffff88042daa8010 0000000100000000
ffff88042b995f60
[ 8168.201947] Call Trace:
[ 8168.231085] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8168.305981] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8168.369438] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8168.434979] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8168.504672] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8168.575409] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8168.649267] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8168.714811] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8168.777228] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8168.844848] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8168.917663] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8168.982164] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8169.045621] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8169.119480] INFO: task sshd:809 blocked for more than 120 seconds.
[ 8169.193337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8169.286959] sshd D ffff88042b8186d0 0 809 1814 0x00000000
[ 8169.371232] ffff88042b8186d0 0000000000000086 ffff88042b8186d0
ffff88042e9a8da0
[ 8169.459683] 0000000000012680 ffff8803ef68bfd8 ffff8803ef68bfd8
0000000000012680
[ 8169.548141] ffff88042b8186d0 ffff8803ef68a010 0000000100000000
ffff88042b995f60
[ 8169.636603] Call Trace:
[ 8169.665736] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8169.740634] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8169.804095] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8169.869632] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8169.939330] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8170.010066] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8170.083929] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8170.149469] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8170.211886] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8170.279502] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8170.352323] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8170.416818] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8170.480274] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8170.554131] INFO: task smtpserver.pl:815 blocked for more than 120 seconds.
[ 8170.637354] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8170.730974] smtpserver.pl D ffff88042b81caf0 0 815 31144 0x00000004
[ 8170.815252] ffff88042b81caf0 0000000000000082 ffff88042b81caf0
ffff88042ee03d50
[ 8170.903706] 0000000000012680 ffff88042e929fd8 ffff88042e929fd8
0000000000012680
[ 8170.992174] ffff88042b81caf0 ffff88042e928010 0000000100000000
ffff88042b995f60
[ 8171.080630] Call Trace:
[ 8171.109767] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8171.184668] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8171.248126] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8171.313665] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8171.383361] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8171.454104] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8171.527962] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8171.593500] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8171.655915] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8171.723538] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8171.796356] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8171.860854] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8171.924311] [<ffffffff81259f56>] ? sock_map_fd+0x24/0x2d
[ 8171.988812] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8172.062672] INFO: task sshd:823 blocked for more than 120 seconds.
[ 8172.136527] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8172.230147] sshd D ffff88042a496d00 0 823 1814 0x00000000
[ 8172.314431] ffff88042a496d00 0000000000000082 ffff88042a496d00
ffff88042edb73d0
[ 8172.402881] 0000000000012680 ffff88042a9cdfd8 ffff88042a9cdfd8
0000000000012680
[ 8172.491319] ffff88042a496d00 ffff88042a9cc010 0000000100000000
ffff88042b995f60
[ 8172.579783] Call Trace:
[ 8172.608922] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8172.683819] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8172.747277] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8172.812815] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8172.882512] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8172.953247] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8173.027105] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8173.092645] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8173.155065] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8173.222680] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8173.295499] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8173.360015] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8173.423471] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8173.497329] INFO: task sshd:872 blocked for more than 120 seconds.
[ 8173.571185] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8173.664810] sshd D ffff88042d6286d0 0 872 1814 0x00000000
[ 8173.749088] ffff88042d6286d0 0000000000000082 ffff88042d6286d0
ffff88042edb5890
[ 8173.837545] 0000000000012680 ffff8803eabf3fd8 ffff8803eabf3fd8
0000000000012680
[ 8173.926005] ffff88042d6286d0 ffff8803eabf2010 0000000100000000
ffff88042b995f60
[ 8174.014447] Call Trace:
[ 8174.043585] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8174.118483] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8174.181943] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8174.247482] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8174.317178] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8174.387918] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8174.461779] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8174.527317] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8174.589734] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8174.657352] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8174.730176] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8174.794674] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8174.858132] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8174.931986] INFO: task sshd:873 blocked for more than 120 seconds.
[ 8175.005847] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8175.099461] sshd D ffff88042a494af0 0 873 1814 0x00000000
[ 8175.183739] ffff88042a494af0 0000000000000082 ffff88042a494af0
ffff88042edb73d0
[ 8175.272197] 0000000000012680 ffff8804084f7fd8 ffff8804084f7fd8
0000000000012680
[ 8175.360649] ffff88042a494af0 ffff8804084f6010 0000000100000000
ffff88042b995f60
[ 8175.449106] Call Trace:
[ 8175.478243] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8175.553145] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8175.616602] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8175.682139] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8175.751838] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8175.822579] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8175.896438] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8175.961976] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8176.024393] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8176.092023] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8176.164846] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8176.229343] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8176.292800] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8221.320008] INFO: rcu_sched_state detected stall on CPU 2 (t=60030 jiffies)
[ 8221.955999] INFO: rcu_bh_state detected stall on CPU 2 (t=60030 jiffies)
[ 8401.440001] INFO: rcu_sched_state detected stall on CPU 2 (t=105060 jiffies)
[ 8402.076002] INFO: rcu_bh_state detected stall on CPU 2 (t=105060 jiffies)
^ permalink raw reply
* Re: [RFC PATCH v2] net: dm9000: add support for device tree probing
From: Jamie Iles @ 2011-08-15 14:21 UTC (permalink / raw)
To: Daniel Morsing
Cc: devicetree-discuss, netdev, Mark Brown, Ben Dooks,
David S. Miller
In-Reply-To: <1313343252-19634-1-git-send-email-daniel.morsing@gmail.com>
Hi Daniel,
On Sun, Aug 14, 2011 at 07:34:12PM +0200, Daniel Morsing wrote:
> This patch adds support for probing the dm9000 driver through device
> trees.
>
> The patch works by supplying its own platform_data struct when probed
> via device tree. This allows us to rely on the existing options parsing
> in the driver and avoid ifdeffery in the probe function.
>
> Signed-off-by: Daniel Morsing <daniel.morsing@gmail.com>
> ---
> Currently there are no users of this functionality, but once support for
> DT on OMAP3 matures, I plan to migrate the devkit8000 board to DT.
>
> Changes since v1:
> - Changed the binding with input from Grant Likely.
> - Make explicit what the bindings do instead of refering
> to linux specific flags.
> - Length check the mac address read so we don't copy random data.
> - simplify parsing of the device tree.
> - Add relevant driver maintainers to CC (sorry about that)
>
> Documentation/devicetree/bindings/net/dm9000.txt | 42 +++++++++++
> drivers/net/dm9000.c | 83 +++++++++++++++++++++-
> 2 files changed, 122 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/dm9000.txt
>
> diff --git a/Documentation/devicetree/bindings/net/dm9000.txt b/Documentation/devicetree/bindings/net/dm9000.txt
> new file mode 100644
> index 0000000..cbbdb3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dm9000.txt
> @@ -0,0 +1,42 @@
> +Davicom DM9000 ethernet controller
> +
> +Required properties:
> +
> + - compatible : Should be "davicom,dm9000"
> +
> + - interrupts : Interrupt controller specific encoding, which specifies 1
> + or 2 interrupts. The first interrupt is for rx/tx and is required by the
> + driver to function. The second interrupt is for wake on lan support
> + and is optional.
> +
> + - reg : 2 Physical address specifiers, where the first specifies the address
> + register of device, and the second specifies the data register of the device
> +
> +Optional properties:
> +
> + - local-mac-address : Binary data specifying a mac address override
> +
> + - reg-io-width : one cell specifying the width of IO operations in bits.
> + valid values are 8, 16, and 32. If this property is not specified, or has
> + an invalid value, the driver will default to 32 bits.
Minor nit, but rightly or wrongly, the of-serial binding that uses
reg-io-width specifies this in bytes and it would be nice to be
consistent here.
Jamie
^ permalink raw reply
* Re: Move interface across network namespaces
From: Renato Westphal @ 2011-08-15 13:10 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, kaber, David Lamparter
In-Reply-To: <CAChaegm2d3LywMAcq66PgPZwF5Fu=_zuqcTh8VdCG6zvhyPJXQ@mail.gmail.com>
2011/8/11 Renato Westphal <renatowestphal@gmail.com>:
> 2011/8/11 Eric W. Biederman <ebiederm@xmission.com>:
>> Renato Westphal <renatowestphal@gmail.com> writes:
>>
>>> Hello,
>>>
>>> I have two questions regarding the process of moving a network
>>> interface across different network namespaces:
>>>
>>> * When I move an interface, all the virtual interfaces attached to it
>>> are deleted. Is there any reason for such odd behavior? I would like
>>> to move some network interfaces and keep the attached vlans untouched.
>>
>> The defined semantics are that a network device is unregistered from
>> the networking stack in one network namespace and then registered
>> with the networking stack in another. It is an unfortunate fact
>> that when vlan devices see their underlying device being unregistered
>> they decide to delete themselves.
>>
>> A different vlan implementation might be able to have different
>> properties but I can't think of any obvious solution other than
>> don't do move the device that you have your vlans on top of.
>>
>
> Thanks for the info, I can handle with that by modifying my quagga-vrf patches.
I forgot to mention that I'm using kernel v2.6.35 (with a lot of
backports). For future reference, the commit 3b27e105550f7c4a ("netns:
keep vlan slaves on master netns move", merged into v2.6.37-rc1) fixes
this problem.
>>> * The target network namespace sends a RTM_NEWLINK netlink message
>>> when an interface is moved to it. In the other hand, the source
>>> network namespace doesn't sends a RTM_DELLINK message when an
>>> interface is moved from it. This is very annoying because user space
>>> applications (such as zebra) can't detect some interface moving
>>> operations and then get into an inconsistent state. Anyone knows if
>>> there's a workaround for this?
>>
>> Not getting RTM_DELLINK is a bug. The device registration and
>> unregistration code has changed since dev_change_net_namespace was
>> written and apparently one of the changes failed to update
>> dev_change_net_namespace.
>>
>
> Good, that makes a lot more sense. In the kernel 2.6.32.43 the
> RTM_DELLINK netlink message is sent when a network interface is moved
> from a network namespace. The same doesn't happens in the kernel
> 2.6.35.13. I'll try to isolate the problem some more.
Well, this regression was introduced by commit a2835763e130c343ac,
which was merged into v2.6.34. Reverting parts of this commit makes
the problem go away but breaks the support of "specifying device flags
during device creation". I don't know the best way to fix this... any
ideas?
--
Renato Westphal
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Eilon Greenstein @ 2011-08-15 12:33 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <4E490A1E.3060209@redhat.com>
On Mon, 2011-08-15 at 04:59 -0700, Michal Schmidt wrote:
> On 08/15/2011 12:54 PM, Eilon Greenstein wrote:
> > On Fri, 2011-08-12 at 07:33 -0700, Michal Schmidt wrote:
> >> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> >> index c423504..648e165 100644
> >> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> >> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> >> @@ -1220,6 +1220,7 @@ struct bnx2x {
> >> struct cmng_struct_per_port cmng;
> >> u32 vn_weight_sum;
> >> u32 mf_config[E1HVN_MAX];
> >> + bool prev_max_cfg_invalid[E1HVN_MAX];
> > The warning is always for the current VN, so if you insist on showing a
> > warning only once on a board with invalid configuration, you can use a
> > single boolean.
>
> bnx2x_cmng_fns_init() iterates over VNs:
>
> for (vn = VN_0; vn < E1HVN_MAX; vn++)
> bnx2x_init_vn_minmax(bp, vn);
>
> and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
> VN, so it seems that the warning can be produced for a non-current VN.
You are right, only one function (the PMF) will call this code for all
functions. But I suspect that if you have zero values, you will have
them for all VNs - is that the case? If so, you can still warn only
once. Adding 4 boolean variables to the bnx2x structure just to overcome
a bad configuration seems excessive to me.
^ 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