* [PATCH 2/2 v2] iwlegacy: change IWL_ERR to IWL_DEBUG_HT in iwl4965_rs_tl_turn_on_agg_for_tid
From: y @ 2011-08-28 13:32 UTC (permalink / raw)
To: sgruszka-H+wXaHxf7aLQT0dZR+AlfA, linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Dietsche
In-Reply-To: <1314537977-20097-2-git-send-email-Gregory.Dietsche-5+R7UueiBCQ@public.gmane.org>
From: Greg Dietsche <Gregory.Dietsche-5+R7UueiBCQ@public.gmane.org>
This message should be a debug message and not an error. So
change it from IWL_ERR to IWL_DEBUG_HT.
Signed-off-by: Greg Dietsche <Gregory.Dietsche-5+R7UueiBCQ@public.gmane.org>
---
drivers/net/wireless/iwlegacy/iwl-4965-rs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/iwl-4965-rs.c b/drivers/net/wireless/iwlegacy/iwl-4965-rs.c
index 9b65153..a0b60ee 100644
--- a/drivers/net/wireless/iwlegacy/iwl-4965-rs.c
+++ b/drivers/net/wireless/iwlegacy/iwl-4965-rs.c
@@ -373,7 +373,7 @@ static int iwl4965_rs_tl_turn_on_agg_for_tid(struct iwl_priv *priv,
ieee80211_stop_tx_ba_session(sta, tid);
}
} else {
- IWL_ERR(priv, "Aggregation not enabled for tid %d "
+ IWL_DEBUG_HT(priv, "Aggregation not enabled for tid %d "
"because load = %u\n", tid, load);
}
return ret;
--
1.7.5.4
--
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 related
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Eric Dumazet @ 2011-08-28 14:09 UTC (permalink / raw)
To: HAYASAKA Mitsuo
Cc: Herbert Xu, Stephen Hemminger, Patrick McHardy, David S. Miller,
MichałMirosław, Tom Herbert, Jesse Gross, netdev,
linux-kernel, yrl.pp-manager.tt
In-Reply-To: <4E5A40A9.2000404@hitachi.com>
Le dimanche 28 août 2011 à 22:20 +0900, HAYASAKA Mitsuo a écrit :
> Hi Stephen and Herbert
>
> Thank you for your comments.
>
> (2011/08/26 15:08), Stephen Hemminger wrote:
> > I don't think this is the right way to solve the problem.
> >
> > The flags are supposed to propagate back from real device to vlan
> > via network notifications.
> >
> > Just doing this for ioctl is not enough, API's other than user space depend on this.
> > Also the user may have manually set different flags on vlan than on
> > the real device.
>
> I agreed.
> I will try another way to solve this problem, as you said.
>
>
> (2011/08/26 15:45), Herbert Xu wrote:
> > On Thu, Aug 25, 2011 at 11:08:59PM -0700, Stephen Hemminger wrote:
> >> Just doing this for ioctl is not enough, API's other than user space depend on this.
> >> Also the user may have manually set different flags on vlan than on
> >> the real device.
> > Right, anything that tests netif_carrier_ok directly on the VLAN
> > device will still be delayed.
> >
> > Now I remember discussing this issue in Japan. However, I can't
> > recall the exact scenario in which the delay occured.
> >
> > Is the issue with the link status going down on the real device,
> > or the real device coming up?
> >
> > IIRC we already have mechanisms in place to ensure that down events
> > are not delayed by linkwatch. Of course it is possible that this
> > isn't working for some reason, or some other part of the system is
> > causing the delay.
> >
> > So please clarify the scenario for us Hayasaka-san. Also please
> > let us know how you measured the delay.
> >
> > Thanks,
>
> This issue happens when the link status is going down on the real
> device.
>
> ex) A cable is broken, or is unplugged from a NIC.
>
> I measured the delay using ioctl with SIOCGIFFLAGS from userspace
> in order to check if there is a time-lag of the flag between vlan
> and real devices.
>
> Also, you can check it using a script below.
>
> -------------------------
> #!/bin/sh
> t=0
> while :
> do
> echo $t; t=$((t+1))
> echo -n real; ifconfig RealDev | grep UP
> echo -n vlan; ifconfig VlanDev | grep UP
> sleep 0.2
> done
> -------------------------
>
> The result is shown as follows.
> It is observed that there is a time-lag of RUNNING status between
> real and vlan devices.
>
>
Hi !
This reminds me some work done in linkwatch
Please take a look at commit e014debecd3ee3832e647 (linkwatch:
linkwatch_forget_dev() to speedup device dismantle)
And more generally, code in net/core/link_watch.c
^ permalink raw reply
* Re: [PATCH net-next v2 05/10] headers, net: Define struct __kernel_sockaddr, replacing struct sockaddr
From: Ben Hutchings @ 2011-08-28 16:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110826.122024.278846592642798982.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Fri, 2011-08-26 at 12:20 -0400, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Fri, 26 Aug 2011 12:04:51 -0400 (EDT)
>
> > From: Ben Hutchings <ben@decadent.org.uk>
> > Date: Fri, 26 Aug 2011 16:42:48 +0100
> >
> >> This #define is in the #ifdef __KERNEL__ section. I don't want t
> >> change all the in-kernel users to say __kernel_sockaddr. This is
> >> just the same as the preceding 'typedef __kernel_sa_family_t
> >> sa_family_t' except that you can't create struct aliases that way.
> >
> > Aha, I didn't catch that part. Then this is fine, thanks for
> > explaining Ben.
>
> Actually, this patch breaks the build, specifically of ifenslave.c
>
> I'll leave the other patches in, but you'll need to respin this one.
[...]
Right, it looks like this will have to wait for a proper resolution of
the conflicts between kernel and libc types.
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* 3.1-rc3-git6: Reported regressions from 3.0
From: Rafael J. Wysocki @ 2011-08-28 18:22 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: 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
This message contains a list of some regressions from 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 regressions from 3.0, 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-28 8 4 4
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
Subject : duplicate filename for intel_backlight with the i915 driver
Submitter : François Valenduc <francois.valenduc-bmtTS95sd5BUM80lpFwj4w@public.gmane.org>
Date : 2011-08-25 18:51 (4 days old)
First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41512
Subject : 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds
Submitter : Carlos R. Mafra <crmafra2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-08-16 9:42 (13 days old)
Message-ID : <20110816094245.GA2042-VVqtEBlnRoHN0uC3ymp8PA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=131348782017435&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41502
Subject : cfq-iosched: a regression
Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2011-08-16 2:47 (13 days old)
Message-ID : <1313462826.27321.22.camel@sli10-conroe>
References : http://marc.info/?l=linux-kernel&m=131346279329911&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41442
Subject : rcu_sched_state detected stall on CPU 0, when booting on Xen
Submitter : Witold Baryluk <baryluk-W6Hso+/wx31C2Nf1M/Lcnw@public.gmane.org>
Date : 2011-08-21 04:06 (8 days old)
Regressions with patches
------------------------
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 3.0,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=40982
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
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
* 3.1-rc3-git6: Reported regressions 2.6.39 -> 3.0
From: Rafael J. Wysocki @ 2011-08-28 18:58 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: 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
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-28 71 21 17
2011-08-14 63 22 19
2011-07-10 38 16 13
2011-06-26 22 14 12
2011-06-12 8 7 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41562
Subject : acer-wmi: acer aspire 721 bluetooth control doesn't work with kernel 3.0.0
Submitter : sbraz <hi.sbraz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-08-22 18:32 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41102
Subject : BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
Submitter : Paul Bolle <pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>
Date : 2011-08-13 22:29 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41092
Subject : INFO: trying to register non-static key (sync_inodes_sb)
Submitter : Paul Bolle <pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>
Date : 2011-08-13 22:07 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40442
Subject : cpuinfo_max_freq lost 500MHz
Submitter : Harald Dunkel <harri-z+8oq0O/ijmzQB+pC5nmwQ@public.gmane.org>
Date : 2011-08-02 20:31 (27 days old)
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 (35 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=40262
Subject : PROBLEM: I/O storm from hell on kernel 3.0.0 when touch swap (swapfile or partition)
Submitter : g0re <g0re-ifvz4xmYPRU@public.gmane.org>
Date : 2011-07-28 12:40 (32 days old)
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 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40072
Subject : suspend/resume problems w/ kernel 3.0 and a *docked* ThinkPad T400, unless iwlagn unloaded
Submitter : Toralf Förster <toralf.foerster-Mmb7MZpHnFY@public.gmane.org>
Date : 2011-07-23 19:27 (37 days old)
Message-ID : <201107232127.34255.toralf.foerster-Mmb7MZpHnFY@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=131144928023465&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39922
Subject : WIFI becomes EXTREMELY slow ( ath9k ) making the connection unusable
Submitter : Lukasz Olszewski <lcpak-tIkWECEXGi3VItvQsEIGlw@public.gmane.org>
Date : 2011-07-24 09:20 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39912
Subject : WARNING: at drivers/tty/tty_ldisc.c:766 tty_ldisc_reinit+0x7d/0x90()
Submitter : Vegard Nossum <vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-07-19 11:33 (41 days old)
Message-ID : <CAOMGZ=HS2EPkYD=5HfkSPpwPqHB5V3q0vaFmoZ8Hh+pMM9phrQ@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=131107522914558&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39832
Subject : HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
Submitter : Andreas Steinmetz <ast-sy9/ueDX/ME@public.gmane.org>
Date : 2011-07-23 01:36 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39732
Subject : JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a risk of filesystem corruption in case of system crash.
Submitter : Witold Baryluk <baryluk-W6Hso+/wx31C2Nf1M/Lcnw@public.gmane.org>
Date : 2011-07-22 04:22 (38 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39412
Subject : Win Vista and Win2K8 guests' network breaks down
Submitter : Jay Ren <yongjie.ren-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2011-07-15 15:31 (45 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39192
Subject : firmware_install fails with parallel make
Submitter : Ambroz Bizjak <ambrop7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-07-12 09:35 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38922
Subject : Lenovo T420 (Sandy Bridge) Crashes on SD Card gpt partition writing and io errors on insert
Submitter : Peter Vollmer <vollmerpeter-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date : 2011-07-07 17:33 (53 days old)
First-Bad-Commit: http://git.kernel.org/linus/a3c7778f8153b9e4eceea6738973280b9e63c618
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38622
Subject : [radeon cayman regresion] artefacts on screen
Submitter : Marek Hobler, 'neutrinus' <kernellist@neutrinus.com>
Date : 2011-07-01 09:35 (59 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38582
Subject : T510 43495KG won't resume with 32bit installation
Submitter : Marc Koschewski <marc-e1Wt+8K1Ta8ZEwqihLH0+Q@public.gmane.org>
Date : 2011-06-30 22:39 (60 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41262
Subject : Terracted T5 does no more work
Submitter : Eric Valette <eric.valette-GANU6spQydw@public.gmane.org>
Date : 2011-08-16 20:45 (13 days old)
Patch : https://bugzilla.kernel.org/attachment.cgi?id=69382
https://bugzilla.kernel.org/attachment.cgi?id=69392
https://bugzilla.kernel.org/attachment.cgi?id=69402
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41232
Subject : Channel switching on Hauppauge Nova-T stick fails randomly
Submitter : <q222-KK0ffGbhmjU@public.gmane.org>
Date : 2011-08-16 11:33 (13 days old)
Patch : http://git.linuxtv.org/pb/media_tree.git/commitdiff/aeb2d456b746164a4bd19e53de0a6678ca63fcad
http://git.linuxtv.org/pb/media_tree.git/commitdiff/45cbff13693d645fa5dcbba964e802e1746b2e57
http://git.linuxtv.org/pb/media_tree.git/commitdiff/45cbff13693d645fa5dcbba964e802e1746b2e57
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40062
Subject : USB related "unable to handle kernel paging request" in 3.0.0-rc7
Submitter : Tino Keitel <tino.keitel-rAwCM5oiXHA@public.gmane.org>
Date : 2011-07-22 19:27 (38 days old)
Message-ID : <20110722192722.GA9369-dW8JlKMZij8@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=131136334621623&w=2
Patch : https://lkml.org/lkml/2011/8/2/174
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39882
Subject : Kernel oops when turning bluetooth mouse on
Submitter : Lamarque V. Souza <lamarque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-07-24 02:09 (36 days old)
Patch : https://bugzilla.kernel.org/attachment.cgi?id=70342
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.39 and 3.0, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=36912
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: 3.1-rc3-git6: Reported regressions from 3.0
From: Dave Jones @ 2011-08-28 19:35 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: <lx6sezwGldO.A.IhF.UBpWOB@chimera>
On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> Subject : duplicate filename for intel_backlight with the i915 driver
> Submitter : François Valenduc <francois.valenduc-bmtTS95sd5BUM80lpFwj4w@public.gmane.org>
> Date : 2011-08-25 18:51 (4 days old)
> First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
Dave
^ permalink raw reply
* Re: 3.1-rc3-git6: Reported regressions from 3.0
From: Rafael J. Wysocki @ 2011-08-28 19:39 UTC (permalink / raw)
To: Dave Jones
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: <20110828193519.GA14132-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sunday, August 28, 2011, Dave Jones wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> > Subject : duplicate filename for intel_backlight with the i915 driver
> > Submitter : François Valenduc <francois.valenduc-bmtTS95sd5BUM80lpFwj4w@public.gmane.org>
> > Date : 2011-08-25 18:51 (4 days old)
> > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
>
> this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
Thanks, closing.
Rafael
^ permalink raw reply
* Re: 3.1-rc3-git6: Reported regressions from 3.0
From: Linus Torvalds @ 2011-08-28 19:49 UTC (permalink / raw)
To: Dave Jones, Rafael J. Wysocki, Linux Kernel Mailing List,
Maciej Rutecki, Florian
In-Reply-To: <20110828193519.GA14132@redhat.com>
On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones <davej@redhat.com> wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41742
> > Subject : duplicate filename for intel_backlight with the i915 driver
> > Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
> > Date : 2011-08-25 18:51 (4 days old)
> > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
>
> this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
Actually, by a2cc797d2d1a ("i915: do not setup intel_backlight ").
That b727d20269e is just my merge commit that brings in the fix (and
the bogus initialization of 'locked') into mainline.
Linus
^ permalink raw reply
* Re: [PATCH] net/mac80211/debugfs: Convert to kstrou8_from_user
From: Peter Hüwe @ 2011-08-28 19:52 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, David S. Miller, linux-wireless, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <1307478974-32727-1-git-send-email-peterhuewe@gmx.de>
Am Dienstag 07 Juni 2011, 22:36:14 schrieb Peter Huewe:
> This patch replaces the code for getting an number from a
> userspace buffer by a simple call to kstrou8_from_user.
> This makes it easier to read and less error prone.
>
> Since the old buffer was only 10 bytes long and the value is masked by a
> nibble-mask anyway, we don't need to use kstrtoul but rather kstrtou8.
>
> Kernel Version: v3.0-rc2
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Any updates on this one?
Still applies to the latest linus' tree
Thanks,
Peter
^ permalink raw reply
* [PATCH iproute2] tc: man: add man page for choke scheduler
From: Florian Westphal @ 2011-08-28 20:35 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
---
man/man8/tc-red.8 | 3 +-
man/man8/tc.8 | 1 +
3 files changed, 65 insertions(+), 1 deletions(-)
create mode 100644 man/man8/tc-choke.8
diff --git a/man/man8/tc-choke.8 b/man/man8/tc-choke.8
new file mode 100644
index 0000000..7b213be
--- /dev/null
+++ b/man/man8/tc-choke.8
@@ -0,0 +1,62 @@
+.TH TC 8 "August 2011" "iproute2" "Linux"
+.SH NAME
+choke \- choose and keep scheduler
+.SH SYNOPSIS
+.B tc qdisc ... choke
+.B limit
+bytes
+.B min
+bytes
+.B max
+bytes
+.B avpkt
+bytes
+.B burst
+packets
+.B [ ecn ] [ bandwidth
+rate
+.B ] probability
+chance
+
+.SH DESCRIPTION
+
+CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for unresponsive flows)
+is a classless qdisc designed to both identify and penalize flows that monopolize the
+queue. CHOKe is a variation of RED, and the configuration is the same as RED.
+
+.SH ALGORITHM
+Once the queue hits a certain average length, a random packet is drawn from the
+queue. If both the to-be-queued and the drawn packet belong to the same flow,
+both packets are dropped. Otherwise, if the queue length is still below the maximum length,
+the new packet has a configurable chance of being marked (which may mean dropped).
+If the queue length exceeds
+.B max
+, the new packet will always be marked (or dropped).
+If the queue length exceeds
+.B limit
+, the new packet is always dropped.
+
+The marking probability computation is the same as used by the RED qdisc.
+
+.SH PARAMETERS
+The parameters are the same as for RED, see
+.BR tc-red (8)
+for a description.
+
+.SH SOURCE
+.TP
+o
+R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+IEEE INFOCOM, 2000.
+.TP
+o
+A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-red (8)
+
+.SH AUTHOR
+sched_choke was contributed by Stephen Hemminger.
diff --git a/man/man8/tc-red.8 b/man/man8/tc-red.8
index fa83675..32a47b8 100644
--- a/man/man8/tc-red.8
+++ b/man/man8/tc-red.8
@@ -112,7 +112,8 @@ queue size hits
bytes. Needs a tc binary with RED support compiled in. Recommended.
.SH SEE ALSO
-.BR tc (8)
+.BR tc (8),
+.BR tc-choke (8)
.SH SOURCES
.TP
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index e17ce68..bfc7f26 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -367,6 +367,7 @@ print rates in IEC units (ie. 1K = 1024).
was written by Alexey N. Kuznetsov and added in Linux 2.2.
.SH SEE ALSO
.BR tc-cbq (8),
+.BR tc-choke (8),
.BR tc-drr (8),
.BR tc-htb (8),
.BR tc-sfq (8),
--
1.7.3.4
^ permalink raw reply related
* TX watchdog warning for sis900
From: Ben Hutchings @ 2011-08-28 20:38 UTC (permalink / raw)
To: Simon L'nu; +Cc: 635770, Daniele Venzano, netdev
In-Reply-To: <CAPC6j9mg7vuOtVWQf-SyuQjaDQ3zD2Oz5AUFmP26S8CsHUw_0Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
[Bug log is at <http://bugs.debian.org/635770>.]
On Tue, 2011-08-02 at 16:25 -0400, Simon L'nu wrote:
> On Sun, Jul 31, 2011 at 1:25 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > On Thu, 2011-07-28 at 13:42 -0400, Simon L'nu wrote:
> >> Package: linux-2.6
> >> Version: 3.0.0-1
> >> Severity: important
> >> Tags: experimental
> >>
> >> hi,
> >>
> >> so at random times, the driver will just oops with (below), and then the
> >> network just conks out, unable to do anything. when i remove it (modprobe -r) after bringing
> >> it down, and back up, it's extremely slow (see below kernel oops message).
> > [...]
> >
> > Did this happen with any previous version of the kernel package? What
> > is the last version where this did not happen?
> >
> > Ben.
> >
> >
>
> no, and only started happening recently. i also tried 2.6.39.2, and it
> started happening there. made me suspect an hardware or firmware
> issue. the PXE firmware option was enabled in BIOS (it's the built-in
> NIC).
Do you mean that you recently enabled PXE boot and that this has started
happening since then?
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi: iwl-agn-rs.c: remove old comment
From: Guy, Wey-Yi @ 2011-08-28 21:07 UTC (permalink / raw)
To: Greg Dietsche
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1314537758-19159-1-git-send-email-Gregory.Dietsche-5+R7UueiBCQ@public.gmane.org>
On Sun, 2011-08-28 at 06:22 -0700, Greg Dietsche wrote:
> this comment refers to some code that was removed.
>
> Signed-off-by: Greg Dietsche <Gregory.Dietsche-5+R7UueiBCQ@public.gmane.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
Thank you
Wey
--
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 1/3 net-next] cnic, bnx2fc: Increase maximum FCoE sessions.
From: David Miller @ 2011-08-28 21:08 UTC (permalink / raw)
To: mchan; +Cc: netdev, bprakash
In-Reply-To: <1314387941-2126-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 26 Aug 2011 12:45:39 -0700
> Increase it to NVRAM configured limit or 1024 whichever is less.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3 net-next] cnic: Add timeout for ramrod replies.
From: David Miller @ 2011-08-28 21:08 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1314387941-2126-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 26 Aug 2011 12:45:40 -0700
> If the bnx2x device has encountered parity errors, the chip will not DMA
> any replies. Using wait_event_timeout() will allow us to make forward
> progress and let bnx2x reset the chip.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3 net-next] net: Define NETDEV_FCOE_WWNN, NETDEV_FCOE_WWPN only when CONFIG_LIBFCOE is enabled
From: David Miller @ 2011-08-28 21:09 UTC (permalink / raw)
To: mchan; +Cc: netdev, yi.zou, bprakash
In-Reply-To: <1314387941-2126-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 26 Aug 2011 12:45:41 -0700
> From: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
>
> bnx2fc driver calls netdev->netdev_ops->ndo_fcoe_get_wwn() and it may not
> be defined with the current Kconfig dependencies. ndo_fcoe_get_wwn is
> dependent on CONFIG_FCOE, but bnx2fc does not select CONFIG_FCOE, as it does
> not depend on fcoe driver. Since both fcoe and bnx2fc drivers select
> CONFIG_LIBFCOE, define NETDEV_FCOE_WWNN and NETDEV_FCOE_WWPN when
> CONFIG_LIBFCOE is defined.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: David Miller @ 2011-08-28 21:11 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, yoshfuji, ek, lorenzo
In-Reply-To: <1314395788-20179-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Fri, 26 Aug 2011 14:56:28 -0700
> diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
> index f3caf1b..a896987 100644
> --- a/net/ipv6/ip6_flowlabel.c
> +++ b/net/ipv6/ip6_flowlabel.c
> @@ -360,7 +360,7 @@ fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
> msg.msg_control = (void*)(fl->opt+1);
> memset(&flowi6, 0, sizeof(flowi6));
>
> - err = datagram_send_ctl(net, &msg, &flowi6, fl->opt, &junk,
> + err = datagram_send_ctl(net, NULL, &msg, &flowi6, fl->opt, &junk,
> &junk, &junk);
> if (err)
> goto done;
There is a socket associated with this fl_create() request, please
pass it into fl_create() from it's caller, and thus down into
datagram_send_ctl(), instead of just passing NULL.
Then, since a valid sk is always passed in, you can elide the NULL
check on 'sk' down at the bottom of these code paths.
Thanks.
^ permalink raw reply
* Re: [patch net-next-2.6] benet: remove bogus "unlikely" on vlan check
From: David Miller @ 2011-08-28 21:14 UTC (permalink / raw)
To: jpirko
Cc: netdev, eric.dumazet, sathya.perla, subbu.seetharaman,
ajit.khaparde, ivecera
In-Reply-To: <1314276651-9138-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 25 Aug 2011 14:50:51 +0200
> Use of unlikely in this place is wrong. Remove it.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
I'll apply this, thanks Jiri.
^ permalink raw reply
* Re: [RFC PATCH] caif: Remove OOM messages, use kzalloc
From: David Miller @ 2011-08-28 21:16 UTC (permalink / raw)
To: joe; +Cc: akpm, sjur.brandeland, linux-kernel, eric.dumazet, netdev
In-Reply-To: <1314314545.4637.19.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 25 Aug 2011 16:22:24 -0700
> Remove per site OOM messages because they duplicate
> the generic mm subsystem OOM message.
>
> Use kzalloc instead of kmalloc/memset
> when next to the OOM message removals.
>
> Reduces object size (allyesconfig ~2%)
>
> $ size -t drivers/net/caif/built-in.o.old net/caif/built-in.o.old
> text data bss dec hex filename
> 32297 700 8224 41221 a105 drivers/net/caif/built-in.o.old
> 72159 1317 20552 94028 16f4c net/caif/built-in.o.old
> 104456 2017 28776 135249 21051 (TOTALS)
> $ size -t drivers/net/caif/built-in.o.new net/caif/built-in.o.new
> text data bss dec hex filename
> 31975 700 8184 40859 9f9b drivers/net/caif/built-in.o.new
> 70748 1317 20152 92217 16839 net/caif/built-in.o.new
> 102723 2017 28336 133076 207d4 (TOTALS)
>
> Signed-off-by: Joe Perches <joe@perches.com>
Looks good to me, applied, thanks Joe.
^ permalink raw reply
* [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: Maciej Żenczykowski @ 2011-08-28 22:35 UTC (permalink / raw)
To: Maciej Żenczykowski, David S. Miller
Cc: netdev, Maciej Żenczykowski, Erik Kline, Lorenzo Colitti
In-Reply-To: <20110828.171154.1746224796788156557.davem@davemloft.net>
From: Maciej Żenczykowski <maze@google.com>
Allow transparent sockets to be less restrictive about
the source ip of ipv6 udp packets being sent.
Google-Bug-Id: 5018138
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: "Erik Kline" <ek@google.com>
CC: "Lorenzo Colitti" <lorenzo@google.com>
---
include/net/transp_v6.h | 1 +
net/ipv6/datagram.c | 5 +++--
net/ipv6/ip6_flowlabel.c | 8 ++++----
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/raw.c | 4 ++--
net/ipv6/udp.c | 4 ++--
6 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 5271a74..498433d 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -39,6 +39,7 @@ extern int datagram_recv_ctl(struct sock *sk,
struct sk_buff *skb);
extern int datagram_send_ctl(struct net *net,
+ struct sock *sk,
struct msghdr *msg,
struct flowi6 *fl6,
struct ipv6_txoptions *opt,
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 9ef1831..b46e9f8 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -599,7 +599,7 @@ int datagram_recv_ctl(struct sock *sk, struct msghdr *msg, struct sk_buff *skb)
return 0;
}
-int datagram_send_ctl(struct net *net,
+int datagram_send_ctl(struct net *net, struct sock *sk,
struct msghdr *msg, struct flowi6 *fl6,
struct ipv6_txoptions *opt,
int *hlimit, int *tclass, int *dontfrag)
@@ -658,7 +658,8 @@ int datagram_send_ctl(struct net *net,
if (addr_type != IPV6_ADDR_ANY) {
int strict = __ipv6_addr_src_scope(addr_type) <= IPV6_ADDR_SCOPE_LINKLOCAL;
- if (!ipv6_chk_addr(net, &src_info->ipi6_addr,
+ if (!inet_sk(sk)->transparent &&
+ !ipv6_chk_addr(net, &src_info->ipi6_addr,
strict ? dev : NULL, 0))
err = -EINVAL;
else
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index f3caf1b..5430394 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -322,8 +322,8 @@ static int fl6_renew(struct ip6_flowlabel *fl, unsigned long linger, unsigned lo
}
static struct ip6_flowlabel *
-fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
- int optlen, int *err_p)
+fl_create(struct net *net, struct sock *sk, struct in6_flowlabel_req *freq,
+ char __user *optval, int optlen, int *err_p)
{
struct ip6_flowlabel *fl = NULL;
int olen;
@@ -360,7 +360,7 @@ fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
msg.msg_control = (void*)(fl->opt+1);
memset(&flowi6, 0, sizeof(flowi6));
- err = datagram_send_ctl(net, &msg, &flowi6, fl->opt, &junk,
+ err = datagram_send_ctl(net, sk, &msg, &flowi6, fl->opt, &junk,
&junk, &junk);
if (err)
goto done;
@@ -528,7 +528,7 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
if (freq.flr_label & ~IPV6_FLOWLABEL_MASK)
return -EINVAL;
- fl = fl_create(net, &freq, optval, optlen, &err);
+ fl = fl_create(net, sk, &freq, optval, optlen, &err);
if (fl == NULL)
return err;
sfl1 = kmalloc(sizeof(*sfl1), GFP_KERNEL);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 147ede38..2fbda5f 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -475,7 +475,7 @@ sticky_done:
msg.msg_controllen = optlen;
msg.msg_control = (void*)(opt+1);
- retv = datagram_send_ctl(net, &msg, &fl6, opt, &junk, &junk,
+ retv = datagram_send_ctl(net, sk, &msg, &fl6, opt, &junk, &junk,
&junk);
if (retv)
goto done;
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index f34902f..3486f62 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -817,8 +817,8 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk,
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(struct ipv6_txoptions);
- err = datagram_send_ctl(sock_net(sk), msg, &fl6, opt, &hlimit,
- &tclass, &dontfrag);
+ err = datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt,
+ &hlimit, &tclass, &dontfrag);
if (err < 0) {
fl6_sock_release(flowlabel);
return err;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 35bbdc4..f4ca0a5 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1090,8 +1090,8 @@ do_udp_sendmsg:
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(*opt);
- err = datagram_send_ctl(sock_net(sk), msg, &fl6, opt, &hlimit,
- &tclass, &dontfrag);
+ err = datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt,
+ &hlimit, &tclass, &dontfrag);
if (err < 0) {
fl6_sock_release(flowlabel);
return err;
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: David Miller @ 2011-08-29 1:06 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, ek, lorenzo
In-Reply-To: <1314570931-6233-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Sun, 28 Aug 2011 15:35:31 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> Allow transparent sockets to be less restrictive about
> the source ip of ipv6 udp packets being sent.
>
> Google-Bug-Id: 5018138
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Stephen Hemminger @ 2011-08-29 6:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Herbert Xu, Patrick McHardy, David S. Miller,
MichałMirosław, Tom Herbert, Jesse Gross, netdev,
linux-kernel, yrl pp-manager tt, HAYASAKA Mitsuo
In-Reply-To: <1314540589.3036.12.camel@edumazet-laptop>
----- Original Message -----
> Le dimanche 28 août 2011 à 22:20 +0900, HAYASAKA Mitsuo a écrit :
> > Hi Stephen and Herbert
> >
> > Thank you for your comments.
> >
> > (2011/08/26 15:08), Stephen Hemminger wrote:
> > > I don't think this is the right way to solve the problem.
> > >
> > > The flags are supposed to propagate back from real device to vlan
> > > via network notifications.
> > >
> > > Just doing this for ioctl is not enough, API's other than user
> > > space depend on this.
> > > Also the user may have manually set different flags on vlan than
> > > on
> > > the real device.
> >
> > I agreed.
> > I will try another way to solve this problem, as you said.
> >
> >
> > (2011/08/26 15:45), Herbert Xu wrote:
> > > On Thu, Aug 25, 2011 at 11:08:59PM -0700, Stephen Hemminger
> > > wrote:
> > >> Just doing this for ioctl is not enough, API's other than user
> > >> space depend on this.
> > >> Also the user may have manually set different flags on vlan than
> > >> on
> > >> the real device.
> > > Right, anything that tests netif_carrier_ok directly on the VLAN
> > > device will still be delayed.
> > >
> > > Now I remember discussing this issue in Japan. However, I can't
> > > recall the exact scenario in which the delay occured.
> > >
> > > Is the issue with the link status going down on the real device,
> > > or the real device coming up?
> > >
> > > IIRC we already have mechanisms in place to ensure that down
> > > events
> > > are not delayed by linkwatch. Of course it is possible that this
> > > isn't working for some reason, or some other part of the system
> > > is
> > > causing the delay.
> > >
> > > So please clarify the scenario for us Hayasaka-san. Also please
> > > let us know how you measured the delay.
> > >
> > > Thanks,
> >
> > This issue happens when the link status is going down on the real
> > device.
> >
> > ex) A cable is broken, or is unplugged from a NIC.
> >
> > I measured the delay using ioctl with SIOCGIFFLAGS from userspace
> > in order to check if there is a time-lag of the flag between vlan
> > and real devices.
> >
> > Also, you can check it using a script below.
> >
> > -------------------------
> > #!/bin/sh
> > t=0
> > while :
> > do
> > echo $t; t=$((t+1))
> > echo -n real; ifconfig RealDev | grep UP
> > echo -n vlan; ifconfig VlanDev | grep UP
> > sleep 0.2
> > done
> > -------------------------
> >
> > The result is shown as follows.
> > It is observed that there is a time-lag of RUNNING status between
> > real and vlan devices.
> >
> >
>
> Hi !
>
> This reminds me some work done in linkwatch
>
> Please take a look at commit e014debecd3ee3832e647 (linkwatch:
> linkwatch_forget_dev() to speedup device dismantle)
>
> And more generally, code in net/core/link_watch.c
Maybe the problem is specific to a ethernet driver. Some devices poll
for link changes, and also do a manual check when ioctl was done.
This was mostly typical of older hardware that did not have a PHY
interrupt.
^ permalink raw reply
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Eric Dumazet @ 2011-08-29 6:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Herbert Xu, Patrick McHardy, David S. Miller,
MichałMirosław, Tom Herbert, Jesse Gross, netdev,
linux-kernel, yrl pp-manager tt, HAYASAKA Mitsuo
In-Reply-To: <f6ded72b-346d-43af-af47-4edae5060406@tahiti.vyatta.com>
Le dimanche 28 août 2011 à 23:06 -0700, Stephen Hemminger a écrit :
>
> ----- Original Message -----
> > Le dimanche 28 août 2011 à 22:20 +0900, HAYASAKA Mitsuo a écrit :
> > > Hi Stephen and Herbert
> > >
> > > Thank you for your comments.
> > >
> > > (2011/08/26 15:08), Stephen Hemminger wrote:
> > > > I don't think this is the right way to solve the problem.
> > > >
> > > > The flags are supposed to propagate back from real device to vlan
> > > > via network notifications.
> > > >
> > > > Just doing this for ioctl is not enough, API's other than user
> > > > space depend on this.
> > > > Also the user may have manually set different flags on vlan than
> > > > on
> > > > the real device.
> > >
> > > I agreed.
> > > I will try another way to solve this problem, as you said.
> > >
> > >
> > > (2011/08/26 15:45), Herbert Xu wrote:
> > > > On Thu, Aug 25, 2011 at 11:08:59PM -0700, Stephen Hemminger
> > > > wrote:
> > > >> Just doing this for ioctl is not enough, API's other than user
> > > >> space depend on this.
> > > >> Also the user may have manually set different flags on vlan than
> > > >> on
> > > >> the real device.
> > > > Right, anything that tests netif_carrier_ok directly on the VLAN
> > > > device will still be delayed.
> > > >
> > > > Now I remember discussing this issue in Japan. However, I can't
> > > > recall the exact scenario in which the delay occured.
> > > >
> > > > Is the issue with the link status going down on the real device,
> > > > or the real device coming up?
> > > >
> > > > IIRC we already have mechanisms in place to ensure that down
> > > > events
> > > > are not delayed by linkwatch. Of course it is possible that this
> > > > isn't working for some reason, or some other part of the system
> > > > is
> > > > causing the delay.
> > > >
> > > > So please clarify the scenario for us Hayasaka-san. Also please
> > > > let us know how you measured the delay.
> > > >
> > > > Thanks,
> > >
> > > This issue happens when the link status is going down on the real
> > > device.
> > >
> > > ex) A cable is broken, or is unplugged from a NIC.
> > >
> > > I measured the delay using ioctl with SIOCGIFFLAGS from userspace
> > > in order to check if there is a time-lag of the flag between vlan
> > > and real devices.
> > >
> > > Also, you can check it using a script below.
> > >
> > > -------------------------
> > > #!/bin/sh
> > > t=0
> > > while :
> > > do
> > > echo $t; t=$((t+1))
> > > echo -n real; ifconfig RealDev | grep UP
> > > echo -n vlan; ifconfig VlanDev | grep UP
> > > sleep 0.2
> > > done
> > > -------------------------
> > >
> > > The result is shown as follows.
> > > It is observed that there is a time-lag of RUNNING status between
> > > real and vlan devices.
> > >
> > >
> >
> > Hi !
> >
> > This reminds me some work done in linkwatch
> >
> > Please take a look at commit e014debecd3ee3832e647 (linkwatch:
> > linkwatch_forget_dev() to speedup device dismantle)
> >
> > And more generally, code in net/core/link_watch.c
>
> Maybe the problem is specific to a ethernet driver. Some devices poll
> for link changes, and also do a manual check when ioctl was done.
> This was mostly typical of older hardware that did not have a PHY
> interrupt.
Hmm, I just tried the script on my laptop, and reproduced the problem
with a tg3 driver, considered as a reference one ;)
the 'carrier is on' event is immediately present on both devices, but
the 'carrier is off' is delayed by one second.
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M
Gigabit Ethernet PCI Express (rev 02)
Subsystem: Dell Device 01f9
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f1ef0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at <ignored> [disabled]
Capabilities: <access denied>
Kernel driver in use: tg3
Kernel modules: tg3
^ permalink raw reply
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: David Miller @ 2011-08-29 6:34 UTC (permalink / raw)
To: stephen.hemminger
Cc: eric.dumazet, herbert, kaber, mirq-linux, therbert, jesse, netdev,
linux-kernel, yrl.pp-manager.tt, mitsuo.hayasaka.hu
In-Reply-To: <f6ded72b-346d-43af-af47-4edae5060406@tahiti.vyatta.com>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Sun, 28 Aug 2011 23:06:28 -0700 (PDT)
> This was mostly typical of older hardware that did not have a PHY
> interrupt.
Many have to poll because the PHY interrupt is simply unreliable.
^ permalink raw reply
* [PATCH] Always initialize fw_entry with NULL
From: Thomas Jarosch @ 2011-08-29 7:39 UTC (permalink / raw)
To: netdev
Otherwise the exit code path might try to release
a non-existing firmware object on an error condition.
Issue detected by cppcheck.
Resending to netdev as orionco-devel seems to be sleeping.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
---
drivers/net/wireless/orinoco/orinoco_usb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/orinoco/orinoco_usb.c
b/drivers/net/wireless/orinoco/orinoco_usb.c
index 811e87f..973a55f 100644
--- a/drivers/net/wireless/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/orinoco/orinoco_usb.c
@@ -1579,7 +1579,7 @@ static int ezusb_probe(struct usb_interface
*interface,
struct ezusb_priv *upriv = NULL;
struct usb_interface_descriptor *iface_desc;
struct usb_endpoint_descriptor *ep;
- const struct firmware *fw_entry;
+ const struct firmware *fw_entry = NULL;
int retval = 0;
int i;
--
1.7.4.4
^ permalink raw reply related
* [net-next 00/10][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-08-29 8:40 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains updates to ixgbe only. Many are cleanup's
and fixes.
The following are changes since commit 7ac2ed0ceeafa130f85aa947b271b571c68b9e75:
caif: Remove OOM messages, use kzalloc
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander Duyck (2):
ixgbe: Add support for setting CC bit when SR-IOV is enabled
ixgbe: Always tag VLAN tagged packets
Don Skidmore (2):
ixgbe: cleanup feature flags in ixgbe_probe
ixgbe: fix ixgbe_fc_autoneg_fiber bug
Emil Tantilov (2):
ixgbe: add check for supported modes
ixgbe: clear RNBC only for 82598
John Fastabend (4):
ixgbe: fixup remaining call sites for arbitrary TCs
ixgbe: remove unneeded fdir pb alloc case
ixgbe: consolidate, setup for multiple traffic classes
ixgbe: PFC not cleared on X540 devices
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 87 --------------------
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 9 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c | 46 +----------
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 10 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 53 +++++++++---
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
8 files changed, 63 insertions(+), 150 deletions(-)
--
1.7.6
^ 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