* 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-08-01 13:46 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, 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 2.6.34,
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 2.6.34, 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
----------------------------------------
2010-08-01 100 27 23
2010-07-23 94 33 25
2010-07-09 79 45 37
2010-06-21 46 37 26
2010-06-09 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channels 12/13
Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
Date : 2010-07-25 17:06 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16458
Subject : Bluetooth disabled after resume
Submitter : AttilaN <attila123456@gmail.com>
Date : 2010-07-25 09:33 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16450
Subject : MTD drivers cannot be unloaded
Submitter : Ben Hutchings <bhutchings@solarflare.com>
Date : 2010-07-24 00:17 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16448
Subject : 2.6.35-rc5 panic at __br_deliver+0x64/0xe0 with kvm bridge networking
Submitter : caiqian@redhat.com
Date : 2010-07-23 3:25 (10 days old)
Message-ID : <198123598.1050221279855515402.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References : http://marc.info/?l=linux-kernel&m=127985553916052&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16423
Subject : netfilter/iptables stopped logging 2.6.35-rc
Submitter : auto401300@hushmail.com
Date : 2010-07-17 10:20 (16 days old)
Message-ID : <20100717072036.1BBE52804B@smtp.hushmail.com>
References : http://lkml.indiana.edu/hypermail/linux/kernel/1007.2/00440.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16406
Subject : Badness with the kernel version 2.6.35-rc1-git1 running on P6 box
Submitter : divya <dipraksh@linux.vnet.ibm.com>
Date : 2010-07-16 8:50 (17 days old)
Message-ID : <4C401D56.3070108@linux.vnet.ibm.com>
References : http://marc.info/?l=linux-kernel&m=127927024906085&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
Subject : 2.6.35-rc5 inconsistent lock state
Submitter : Martin Pirker <lkml.collector@gmail.com>
Date : 2010-07-14 20:33 (19 days old)
Message-ID : <AANLkTikDF0TL6OyPVCzPlUTwxFehcrETn3ysgSSeTq92@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16399
Subject : perf failed with kernel 2.6.35-rc
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-07-13 8:14 (20 days old)
First-Bad-Commit: http://git.kernel.org/linus/1ac62cfff252fb668405ef3398a1fa7f4a0d6d15
Message-ID : <1279008849.2096.913.camel@ymzhang.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=127900880212470&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16396
Subject : [bisected] resume from suspend freezes system
Submitter : tomas m <tmezzadra@gmail.com>
Date : 2010-07-15 02:32 (18 days old)
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <20100714135217.GA1797@arch.tripp.de>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16383
Subject : Regression with e1000e from 2.6.34.1 to 2.6.35-rc5
Submitter : Stefan Behte <craig@haquarter.de>
Date : 2010-07-14 00:44 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16380
Subject : Loop devices act strangely in 2.6.35
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2010-07-13 23:21 (20 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <terraluna977@gmail.com>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <4C373084.8000503@gmail.com>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <201007081627.24654.johannes.hirte@fem.tu-ilmenau.de>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16337
Subject : general protection fault: 0000 [#1] SMP
Submitter : Justin P. Mattock <justinmattock@gmail.com>
Date : 2010-07-03 22:59 (30 days old)
Message-ID : <4C2FC0E3.6050101@gmail.com>
References : http://marc.info/?l=linux-kernel&m=127819798215589&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16322
Subject : WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()
Submitter : boris64 <bugzilla.kernel.org@boris64.net>
Date : 2010-07-01 13:54 (32 days old)
Handled-By : H. Peter Anvin <hpa@zytor.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16307
Subject : i915 in kernel 2.6.35-rc3, high number of wakeups
Submitter : Enrico Bandiello <enban@postal.uv.es>
Date : 2010-06-26 16:57 (37 days old)
Message-ID : <<4C26317A.5070309@postal.uv.es>>
References : http://marc.info/?l=linux-kernel&m=127757403404259&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265
Subject : Why is kslowd accumulating so much CPU time?
Submitter : Theodore Ts'o <tytso@mit.edu>
Date : 2010-06-09 18:36 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c
Message-ID : <E1OMQ88-0002a1-Gb@closure.thunk.org>
References : http://marc.info/?l=linux-kernel&m=127610857819033&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <phunge0@hotmail.com>
Date : 2010-06-16 17:57 (47 days old)
Handled-By : Bjorn Helgaas <bjorn.helgaas@hp.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-06-11 20:31 (52 days old)
Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
Submitter : Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Date : 2010-06-15 14:55 (48 days old)
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16184
Subject : Container, X86-64, i386, iptables rule
Submitter : Jean-Marc Pigeon <jmp@safe.ca>
Date : 2010-06-12 04:17 (51 days old)
Handled-By : Patrick McHardy <kaber@trash.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16173
Subject : After uncompressing the kernel, at boot time, the server hangs.
Submitter : David Hill <hilld@binarystorm.net>
Date : 2010-06-09 23:25 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/cf7500c0ea133d66f8449d86392d83f840102632
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16405
Subject : Brightness Adjustment on Toshiba nb305 Netbooks is non-functional.
Submitter : John Mesmon <jmesmon@gmail.com>
Date : 2010-07-15 23:40 (18 days old)
First-Bad-Commit: http://git.kernel.org/linus/74a365b3f354fafc537efa5867deb7a9fadbfe27
Handled-By : Matthew Garrett <mjg59-kernel@srcf.ucam.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=27236
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2010-06-28 9:40 (35 days old)
Message-ID : <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
Handled-By : Jan Kara <jack@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16310
Subject : arm omap invalid module format
Submitter : Robert Nelson <robertcnelson@gmail.com>
Date : 2010-06-28 17:30 (35 days old)
First-Bad-Commit: http://git.kernel.org/linus/d0679c730395d0bde9a46939e7ba255b4ba7dd7c
Handled-By : Michal Marek <mmarek@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=26999
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16278
Subject : lvm snapshot causes deadlock in 2.6.35
Submitter : Phillip Susi <psusi@cfl.rr.com>
Date : 2010-06-23 16:55 (40 days old)
Handled-By : Eric Sandeen <sandeen@redhat.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=26933
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 2.6.34,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16055
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
* 2.6.35-rc6-git6: Reported regressions 2.6.33 -> 2.6.34
From: Rafael J. Wysocki @ 2010-08-01 14:27 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTE: This is the last summary report of regressions introduced between
2.6.33 and 2.6.34. Thanks for helping us with tracking these bugs!]
This message contains a list of some post-2.6.33 regressions introduced before
2.6.34, 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.33 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
----------------------------------------
2010-08-01 129 17 16
2010-07-23 128 27 25
2010-07-10 122 25 24
2010-06-21 114 36 28
2010-06-13 111 40 34
2010-05-09 80 27 24
2010-05-04 76 26 22
2010-04-20 64 35 34
2010-04-07 48 35 33
2010-03-21 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16431
Subject : does not seem to shut down one of two md raid-1 arrays on hibernation
Submitter : Martin Steigerwald <ms@teamix.de>
Date : 2010-07-21 13:08 (12 days old)
Handled-By : Neil Brown <neilb@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16388
Subject : i915 drm BUG: unable to handle kernel paging request at a5e89046
Submitter : <lists@clanduggan.org>
Date : 2010-07-14 16:59 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16377
Subject : X.org crash while running a OpenGL composited KDE 4.4.4 session with Radeon KMS
Submitter : Martin Steigerwald <Martin@Lichtvoll.de>
Date : 2010-07-13 12:41 (20 days old)
Handled-By : Alex Deucher <alexdeucher@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16376
Subject : random - possibly Radeon DRM KMS related - freezes
Submitter : Martin Steigerwald <Martin@Lichtvoll.de>
Date : 2010-07-13 09:24 (20 days old)
Handled-By : Alex Deucher <alexdeucher@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16320
Subject : iwl3945 crashes, seems to be disconnecting from the PCI bus
Submitter : Satish <eerpini@gmail.com>
Date : 2010-07-01 08:24 (32 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16300
Subject : [2.6.34 regression] mplayer gets out of sync due to problems with ALSA
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2010-06-26 20:39 (37 days old)
Handled-By : Takashi Iwai <tiwai@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16270
Subject : Image is a hit-or-a-miss. Often displayed green+purple
Submitter : Vish <drkvi-a@yahoo.com>
Date : 2010-06-22 10:47 (41 days old)
First-Bad-Commit: http://git.kernel.org/linus/acef4a407ed6e0a9ed87a2747be592fe49e64bdd
Handled-By : Jean-Francois Moine <moinejf@free.fr>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16206
Subject : PROBLEM: PPP and other serial port related application hangs in kernel space
Submitter : Ales Teska <ales.teska@gmail.com>
Date : 2010-06-09 20:46 (54 days old)
Message-ID : <900E3B14-5B92-4A37-9581-049DB40F4D1C@gmail.com>
References : http://marc.info/?l=linux-kernel&m=127611640301071&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16170
Subject : Leadtek Winfast DTV Dongle (STK7700P based) is not working in 2.6.34
Submitter : <macjariel@gmail.com>
Date : 2010-06-09 11:11 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16139
Subject : wait_even_interruptible_timeout(), signal, spin_lock() = system hang
Submitter : Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Date : 2010-05-28 16:44 (66 days old)
Message-ID : <AANLkTiliRFydAhxH2-Dp1RKuz6sq7vgWIcMvLMi68ftg@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127506510328758&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15977
Subject : WARNING: at lib/dma-debug.c:866 check_for_stack
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2010-05-14 8:56 (80 days old)
Message-ID : <AANLkTikyx2eaxaiUCFDSfpmn1UG0t2GOxArz6F4wp1LJ@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127382742729825&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15912
Subject : Audio/video sync and crackling issues with snd-hda-intel (AD1981 codec)
Submitter : Øyvind Stegard <oyvinst@ifi.uio.no>
Date : 2010-05-05 16:20 (89 days old)
Handled-By : Jaroslav Kysela <perex@perex.cz>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15862
Subject : 2.6.34-rc4/5: iwlagn unusable until reload
Submitter : Nico Schottelius <nico-linux-20100427@schottelius.org>
Date : 2010-04-27 7:49 (97 days old)
Message-ID : <20100427074934.GB3261@ikn.schottelius.org>
References : http://marc.info/?l=linux-kernel&m=127235784004839&w=2
Handled-By : Johannes Berg <johannes@sipsolutions.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704
Subject : [r8169] WARNING: at net/sched/sch_generic.c
Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date : 2010-03-31 10:21 (124 days old)
Message-ID : <20100331102142.GA3294@swordfish.minsk.epam.com>
References : http://marc.info/?l=linux-kernel&m=127003090406108&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15673
Subject : 2.6.34-rc2: "ima_dec_counts: open/free imbalance"?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2010-03-28 11:31 (127 days old)
Message-ID : <1269775909.5301.4.camel@localhost.localdomain>
References : http://marc.info/?l=linux-kernel&m=126977593326800&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15664
Subject : Graphics hang and kernel backtrace when starting Azureus with Compiz enabled
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2010-04-01 01:09 (123 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16007
Subject : x86/pci Oops with CONFIG_SND_HDA_INTEL
Submitter : Graham Ramsey <ramsey.graham@ntlworld.com>
Date : 2010-05-19 17:09 (75 days old)
Handled-By : Yinghai Lu <yinghai@kernel.org>
Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch : https://patchwork.kernel.org/patch/105662/
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.33 and 2.6.34, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=15310
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] nf_nat: no IP_NAT_RANGE_MAP_IPS flags when alloc_null_binding()
From: Changli Gao @ 2010-08-01 14:45 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
when alloc_null_binding(), no IP_NAT_RNAGE_MAP_IPS in flags means no IP address
translation is needed. It isn't necessary to specify the address explicitly.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/ipv4/netfilter/nf_nat_rule.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/netfilter/nf_nat_rule.c b/net/ipv4/netfilter/nf_nat_rule.c
index ebbd319..21c3042 100644
--- a/net/ipv4/netfilter/nf_nat_rule.c
+++ b/net/ipv4/netfilter/nf_nat_rule.c
@@ -106,16 +106,15 @@ alloc_null_binding(struct nf_conn *ct, unsigned int hooknum)
{
/* Force range to this IP; let proto decide mapping for
per-proto parts (hence not IP_NAT_RANGE_PROTO_SPECIFIED).
- Use reply in case it's already been mangled (eg local packet).
*/
- __be32 ip
- = (HOOK2MANIP(hooknum) == IP_NAT_MANIP_SRC
- ? ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip
- : ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip);
- struct nf_nat_range range
- = { IP_NAT_RANGE_MAP_IPS, ip, ip, { 0 }, { 0 } };
-
- pr_debug("Allocating NULL binding for %p (%pI4)\n", ct, &ip);
+ struct nf_nat_range range;
+
+ range.flags = 0;
+ pr_debug("Allocating NULL binding for %p (%pI4)\n", ct,
+ HOOK2MANIP(hooknum) == IP_NAT_MANIP_SRC ?
+ &ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip :
+ &ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip);
+
return nf_nat_setup_info(ct, &range, HOOK2MANIP(hooknum));
}
^ permalink raw reply related
* Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Linus Torvalds @ 2010-08-01 18:01 UTC (permalink / raw)
To: Rafael J. Wysocki, Jens Axboe, Tejun Heo
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <2dWFdr9kTFM.A.P0D.spXVMB@chimera>
On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
> Subject : 2.6.35-rc5 inconsistent lock state
> Submitter : Martin Pirker <lkml.collector-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2010-07-14 20:33 (19 days old)
> Message-ID : <AANLkTikDF0TL6OyPVCzPlUTwxFehcrETn3ysgSSeTq92@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2
This has a proposed patch. I don't know what the status of it is, though. Jens?
http://marc.info/?l=linux-kernel&m=127950018204029&w=2
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
> Subject : kernel BUG at fs/block_dev.c:765!
> Submitter : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
> Date : 2010-07-14 13:52 (19 days old)
> Message-ID : <20100714135217.GA1797-joY5NpejW+Hx3b7vapvTcQ@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2
This one is interesting. And I think I perhaps see where it's coming from.
bd_start_claiming() (through bd_prepare_to_claim()) has two separate
success cases: either there was no holder (bd_claiming is NULL) or the
new holder was already claiming it (bd_claiming == holder).
Note in particular the case of the holder _already_ holding it. What happens is:
- bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder
- then some error happens, and we call bd_abort_claiming(), which
does whole->bd_claiming = NULL;
- the original holder thinks it still holds the bd, but it has been released!
- a new claimer comes in, and succeeds because bd_claiming is now NULL.
- we now have two "owners" of the bd, but bd_claiming only points to
the second one.
I think bd_start_claiming() needs to do some kind of refcount for the
nested holder case, and bd_abort_claiming() needs to decrement the
refcount and only clear the bd_claiming field when it goes down to
zero.
I dunno. Maybe there's something else going on, but it does look
suspicious, and the above would explain the BUG_ON().
Tejun, Jens?
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
> Subject : Yet another 2.6.35 regression (AGP)?
> Submitter : Woody Suwalski <terraluna977-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2010-07-09 14:21 (24 days old)
> Message-ID : <4C373084.8000503-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2
Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the
correct mask to detect i830 aperture size.")
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
> Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
> Submitter : Johannes Hirte <johannes.hirte-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB@public.gmane.org>
> Date : 2010-07-08 14:27 (25 days old)
> Message-ID : <201007081627.24654.johannes.hirte-3kN+8DYepx7zMJDuovMtMA@public.gmane.orge>
> References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2
This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
simplify the write back thread queue")
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
> Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
> Submitter : Janusz Krzysztofik <jkrzyszt-NCk8gXQAEuFz6jiHbVrK7g@public.gmane.org>
> Date : 2010-06-15 14:55 (48 days old)
> Handled-By : Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.
Linus
^ permalink raw reply
* Re: [PATCH 05/11] pcmcia: do not use io_req_t when calling pcmcia_request_io()
From: Marcel Holtmann @ 2010-08-01 18:04 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial,
Michael Buesch
In-Reply-To: <1280667550-3040-5-git-send-email-linux@dominikbrodowski.net>
Hi Dominik,
> Instead of io_req_t, drivers are now requested to fill out
> struct pcmcia_device *p_dev->resource[0,1] for up to two ioport
> ranges. After a call to pcmcia_request_io(), the ports found there
> are reserved, after calling pcmcia_request_configuration(), they may
> be used.
>
> CC: netdev@vger.kernel.org
> CC: linux-wireless@vger.kernel.org
> CC: linux-ide@vger.kernel.org
> CC: linux-usb@vger.kernel.org
> CC: laforge@gnumonks.org
> CC: linux-mtd@lists.infradead.org
> CC: linux-bluetooth@vger.kernel.org
> CC: alsa-devel@alsa-project.org
> CC: linux-serial@vger.kernel.org
> CC: Michael Buesch <mb@bu3sch.de>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
for the drivers/bluetooth/ pieces.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 04/11] pcmcia: do not use io_req_t after call to pcmcia_request_io()
From: Marcel Holtmann @ 2010-08-01 18:04 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-pcmcia-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, laforge-TgoAw6mPHtdg9hUCZPvPmw,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1280667550-3040-4-git-send-email-linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org>
Hi Dominik,
> After pcmcia_request_io(), do not make use of the values stored in
> io_req_t, but instead use those found in struct pcmcia_device->resource[].
>
> CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> CC: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> CC: linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> CC: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> CC: laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org
> CC: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> CC: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> CC: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org
> CC: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Dominik Brodowski <linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org>
for the drivers/bluetooth/ pieces.
Acked-by: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: e1000e crashes with 2.6.34.x and ThinkPad T60
From: Marc Haber @ 2010-08-01 19:14 UTC (permalink / raw)
To: Allan, Bruce W
Cc: Linux Kernel Developers, Linux Kernel Network Developers,
e1000-devel@lists.sourceforge.net
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9001649C4653@orsmsx509.amr.corp.intel.com>
On Fri, Jul 30, 2010 at 10:42:03AM -0700, Allan, Bruce W wrote:
> Please also provide an eeprom dump from the wired LOM via 'ethtool -e ethX'.
Offset Values
------ ------
0x0000 00 16 41 aa be 37 30 0b b2 ff 51 00 ff ff ff ff
0x0010 53 00 03 01 6b 02 01 20 aa 17 9a 10 86 80 df 80
0x0020 00 00 00 20 54 7e 00 00 14 00 da 00 04 00 00 27
0x0030 c9 6c 50 31 3e 07 0b 04 8b 29 00 00 00 f0 02 0f
0x0040 08 10 00 00 04 0f ff 7f 01 4d ff ff ff ff ff ff
0x0050 14 00 1d 00 14 00 1d 00 af aa 1e 00 00 00 1d 00
0x0060 00 01 00 40 1f 12 07 40 ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7a a7
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* [PATCH] nf_nat_core: don't check if the tuple is used if there is no other choice
From: Changli Gao @ 2010-08-01 19:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
Eliminate nf_nat_used_tuple() to save some CPU cycles when there is no other
choice.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/ipv4/netfilter/nf_nat_core.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index 037a3a6..c370b21 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -262,11 +262,17 @@ get_unique_tuple(struct nf_conntrack_tuple *tuple,
proto = __nf_nat_proto_find(orig_tuple->dst.protonum);
/* Only bother mapping if it's not already in range and unique */
- if (!(range->flags & IP_NAT_RANGE_PROTO_RANDOM) &&
- (!(range->flags & IP_NAT_RANGE_PROTO_SPECIFIED) ||
- proto->in_range(tuple, maniptype, &range->min, &range->max)) &&
- !nf_nat_used_tuple(tuple, ct))
- goto out;
+ if (!(range->flags & IP_NAT_RANGE_PROTO_RANDOM)) {
+ if (range->flags & IP_NAT_RANGE_PROTO_SPECIFIED) {
+ if (proto->in_range(tuple, maniptype, &range->min,
+ &range->max) &&
+ (range->min.all == range->max.all ||
+ !nf_nat_used_tuple(tuple, ct)))
+ goto out;
+ } else if (!nf_nat_used_tuple(tuple, ct)) {
+ goto out;
+ }
+ }
/* Last change: get protocol to try to obtain unique tuple. */
proto->unique_tuple(tuple, range, maniptype, ct);
^ permalink raw reply related
* Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Larry Finger @ 2010-08-01 19:39 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <2dWFdr9kTFM.A.P0D.spXVMB@chimera>
On 08/01/2010 08:46 AM, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.34,
> 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 2.6.34, 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.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
> Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
> Submitter : Zdenek Kabelac <zdenek.kabelac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2010-06-28 9:40 (35 days old)
> Message-ID : <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
> Handled-By : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272
I am beginning to think that Bug 16312 is not the same as Bug 16122. Even with
the patches from 16312, I still get warnings as below:
[ 11.728776] ------------[ cut here ]------------
[ 11.728787] WARNING: at fs/fs-writeback.c:964 __mark_inode_dirty+0x10f/0x1a0()
[ 11.728790] Hardware name: HP Pavilion dv2700 Notebook PC
[ 11.728792] Modules linked in: loop(+) dm_mod ide_cd_mod cdrom
snd_hda_codec_conexant ide_pci_generic arc4 ecb b43 rng_core mac80211
snd_hda_intel r8712u(C) cfg80211 snd_hda_codec amd74xx snd_pcm sg ide_core
rfkill led_class snd_timer ssb mmc_core pcmcia snd joydev k8temp hwmon
i2c_nforce2 pcmcia_core forcedeth serio_raw snd_page_alloc i2c_core battery ac
button ext4 mbcache jbd2 crc16 ohci_hcd sd_mod ehci_hcd usbcore fan processor
ahci libahci libata scsi_mod thermal
[ 11.728854] Pid: 2449, comm: udisks-part-id Tainted: G C
2.6.35-rc6-realtek+ #15
[ 11.728857] Call Trace:
[ 11.728865] [<ffffffff8104608a>] warn_slowpath_common+0x7a/0xb0
[ 11.728869] [<ffffffff810460d5>] warn_slowpath_null+0x15/0x20
[ 11.728874] [<ffffffff81129d5f>] __mark_inode_dirty+0x10f/0x1a0
[ 11.728879] [<ffffffff8111e07d>] touch_atime+0x12d/0x170
[ 11.728885] [<ffffffff810cab91>] generic_file_aio_read+0x5c1/0x720
[ 11.728890] [<ffffffff81107ca2>] do_sync_read+0xd2/0x110
[ 11.728896] [<ffffffff81077e7d>] ? trace_hardirqs_on+0xd/0x10
[ 11.728900] [<ffffffff811083c3>] vfs_read+0xb3/0x170
[ 11.728906] [<ffffffff81002d1c>] ? sysret_check+0x27/0x62
[ 11.728909] [<ffffffff811084cc>] sys_read+0x4c/0x80
[ 11.728914] [<ffffffff81002ceb>] system_call_fastpath+0x16/0x1b
[ 11.728917] ---[ end trace 32e16cacad33229f ]---
[ 11.728919] bdi-block not registered
The warnings do not occur with every boot and appear to be some kind of race
condition.
Larry
^ permalink raw reply
* Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-08-01 21:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Tejun Heo, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <AANLkTimcH7+Bq1UEbaSU7SQpzArPgmSLegiqE13V8=CF-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sunday, August 01, 2010, Linus Torvalds wrote:
> On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
> > Subject : Yet another 2.6.35 regression (AGP)?
> > Submitter : Woody Suwalski <terraluna977-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-07-09 14:21 (24 days old)
> > Message-ID : <4C373084.8000503-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2
>
> Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the
> correct mask to detect i830 aperture size.")
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
> > Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
> > Submitter : Johannes Hirte <johannes.hirte-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB@public.gmane.org>
> > Date : 2010-07-08 14:27 (25 days old)
> > Message-ID : <201007081627.24654.johannes.hirte-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2
>
> This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
> simplify the write back thread queue")
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
> > Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
> > Submitter : Janusz Krzysztofik <jkrzyszt-NCk8gXQAEuFz6jiHbVrK7g@public.gmane.org>
> > Date : 2010-06-15 14:55 (48 days old)
> > Handled-By : Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>
> Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.
Closed.
Thanks,
Rafael
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2010-08-02 1:04 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Herbert Xu
Hi all,
Today's linux-next merge of the net tree got a conflict in
net/bridge/br_device.c between commit
6d1d1d398cb7db7a12c5d652d50f85355345234f ("bridge: Fix skb leak when
multicast parsing fails on TX") from the net-current tree and commit
91d2c34a4eed32876ca333b0ca44f3bc56645805 ("bridge: Fix netpoll support")
from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix for
a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/bridge/br_device.c
index f49bcd9,075c435..0000000
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@@ -46,12 -48,13 +48,16 @@@ netdev_tx_t br_dev_xmit(struct sk_buff
skb_reset_mac_header(skb);
skb_pull(skb, ETH_HLEN);
+ rcu_read_lock();
if (is_multicast_ether_addr(dest)) {
+ if (unlikely(netpoll_tx_running(dev))) {
+ br_flood_deliver(br, skb);
+ goto out;
+ }
- if (br_multicast_rcv(br, NULL, skb))
+ if (br_multicast_rcv(br, NULL, skb)) {
+ kfree_skb(skb);
goto out;
+ }
mdst = br_mdb_get(br, skb);
if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb))
^ permalink raw reply
* [PATCH net-next] drivers/net/wan/farsync.c: Use standard pr_<level>
From: Joe Perches @ 2010-08-02 3:20 UTC (permalink / raw)
To: Kevin Curtis; +Cc: David S. Miller, netdev, LKML
Remove locally defined equivalents
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wan/farsync.c | 111 +++++++++++++++++++++-----------------------
1 files changed, 53 insertions(+), 58 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index 43b7727..06965a0 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -15,6 +15,8 @@
* Maintainer: Kevin Curtis <kevin.curtis@farsite.co.uk>
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/version.h>
@@ -511,21 +513,19 @@ static int fst_debug_mask = { FST_DEBUG };
* support variable numbers of macro parameters. The inverted if prevents us
* eating someone else's else clause.
*/
-#define dbg(F,fmt,A...) if ( ! ( fst_debug_mask & (F))) \
- ; \
- else \
- printk ( KERN_DEBUG FST_NAME ": " fmt, ## A )
-
+#define dbg(F, fmt, args...) \
+do { \
+ if (fst_debug_mask & (F)) \
+ printk(KERN_DEBUG pr_fmt(fmt), ##args); \
+} while (0)
#else
-#define dbg(X...) /* NOP */
+#define dbg(F, fmt, args...) \
+do { \
+ if (0) \
+ printk(KERN_DEBUG pr_fmt(fmt), ##args); \
+} while (0)
#endif
-/* Printing short cuts
- */
-#define printk_err(fmt,A...) printk ( KERN_ERR FST_NAME ": " fmt, ## A )
-#define printk_warn(fmt,A...) printk ( KERN_WARNING FST_NAME ": " fmt, ## A )
-#define printk_info(fmt,A...) printk ( KERN_INFO FST_NAME ": " fmt, ## A )
-
/*
* PCI ID lookup table
*/
@@ -961,7 +961,7 @@ fst_issue_cmd(struct fst_port_info *port, unsigned short cmd)
spin_lock_irqsave(&card->card_lock, flags);
if (++safety > 2000) {
- printk_err("Mailbox safety timeout\n");
+ pr_err("Mailbox safety timeout\n");
break;
}
@@ -1241,8 +1241,8 @@ fst_intr_rx(struct fst_card_info *card, struct fst_port_info *port)
* This seems to happen on the TE1 interface sometimes
* so throw the frame away and log the event.
*/
- printk_err("Frame received with 0 length. Card %d Port %d\n",
- card->card_no, port->index);
+ pr_err("Frame received with 0 length. Card %d Port %d\n",
+ card->card_no, port->index);
/* Return descriptor to card */
FST_WRB(card, rxDescrRing[pi][rxp].bits, DMA_OWN);
@@ -1486,9 +1486,8 @@ fst_intr(int dummy, void *dev_id)
*/
dbg(DBG_INTR, "intr: %d %p\n", card->irq, card);
if (card->state != FST_RUNNING) {
- printk_err
- ("Interrupt received for card %d in a non running state (%d)\n",
- card->card_no, card->state);
+ pr_err("Interrupt received for card %d in a non running state (%d)\n",
+ card->card_no, card->state);
/*
* It is possible to really be running, i.e. we have re-loaded
@@ -1614,8 +1613,7 @@ fst_intr(int dummy, void *dev_id)
break;
default:
- printk_err("intr: unknown card event %d. ignored\n",
- event);
+ pr_err("intr: unknown card event %d. ignored\n", event);
break;
}
@@ -1637,13 +1635,13 @@ check_started_ok(struct fst_card_info *card)
/* Check structure version and end marker */
if (FST_RDW(card, smcVersion) != SMC_VERSION) {
- printk_err("Bad shared memory version %d expected %d\n",
- FST_RDW(card, smcVersion), SMC_VERSION);
+ pr_err("Bad shared memory version %d expected %d\n",
+ FST_RDW(card, smcVersion), SMC_VERSION);
card->state = FST_BADVERSION;
return;
}
if (FST_RDL(card, endOfSmcSignature) != END_SIG) {
- printk_err("Missing shared memory signature\n");
+ pr_err("Missing shared memory signature\n");
card->state = FST_BADVERSION;
return;
}
@@ -1651,11 +1649,11 @@ check_started_ok(struct fst_card_info *card)
if ((i = FST_RDB(card, taskStatus)) == 0x01) {
card->state = FST_RUNNING;
} else if (i == 0xFF) {
- printk_err("Firmware initialisation failed. Card halted\n");
+ pr_err("Firmware initialisation failed. Card halted\n");
card->state = FST_HALTED;
return;
} else if (i != 0x00) {
- printk_err("Unknown firmware status 0x%x\n", i);
+ pr_err("Unknown firmware status 0x%x\n", i);
card->state = FST_HALTED;
return;
}
@@ -1665,9 +1663,10 @@ check_started_ok(struct fst_card_info *card)
* existing firmware etc so we just report it for the moment.
*/
if (FST_RDL(card, numberOfPorts) != card->nports) {
- printk_warn("Port count mismatch on card %d."
- " Firmware thinks %d we say %d\n", card->card_no,
- FST_RDL(card, numberOfPorts), card->nports);
+ pr_warning("Port count mismatch on card %d. "
+ "Firmware thinks %d we say %d\n",
+ card->card_no,
+ FST_RDL(card, numberOfPorts), card->nports);
}
}
@@ -2090,9 +2089,8 @@ fst_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
*/
if (card->state != FST_RUNNING) {
- printk_err
- ("Attempt to configure card %d in non-running state (%d)\n",
- card->card_no, card->state);
+ pr_err("Attempt to configure card %d in non-running state (%d)\n",
+ card->card_no, card->state);
return -EIO;
}
if (copy_from_user(&info, ifr->ifr_data, sizeof (info))) {
@@ -2384,8 +2382,8 @@ fst_init_card(struct fst_card_info *card)
err = register_hdlc_device(card->ports[i].dev);
if (err < 0) {
int j;
- printk_err ("Cannot register HDLC device for port %d"
- " (errno %d)\n", i, -err );
+ pr_err("Cannot register HDLC device for port %d (errno %d)\n",
+ i, -err);
for (j = i; j < card->nports; j++) {
free_netdev(card->ports[j].dev);
card->ports[j].dev = NULL;
@@ -2395,10 +2393,10 @@ fst_init_card(struct fst_card_info *card)
}
}
- printk_info("%s-%s: %s IRQ%d, %d ports\n",
- port_to_dev(&card->ports[0])->name,
- port_to_dev(&card->ports[card->nports - 1])->name,
- type_strings[card->type], card->irq, card->nports);
+ pr_info("%s-%s: %s IRQ%d, %d ports\n",
+ port_to_dev(&card->ports[0])->name,
+ port_to_dev(&card->ports[card->nports - 1])->name,
+ type_strings[card->type], card->irq, card->nports);
}
static const struct net_device_ops fst_ops = {
@@ -2417,19 +2415,17 @@ static const struct net_device_ops fst_ops = {
static int __devinit
fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
- static int firsttime_done = 0;
static int no_of_cards_added = 0;
struct fst_card_info *card;
int err = 0;
int i;
- if (!firsttime_done) {
- printk_info("FarSync WAN driver " FST_USER_VERSION
- " (c) 2001-2004 FarSite Communications Ltd.\n");
- firsttime_done = 1;
- dbg(DBG_ASS, "The value of debug mask is %x\n", fst_debug_mask);
- }
-
+ printk_once(KERN_INFO
+ pr_fmt("FarSync WAN driver " FST_USER_VERSION
+ " (c) 2001-2004 FarSite Communications Ltd.\n"));
+#if FST_DEBUG
+ dbg(DBG_ASS, "The value of debug mask is %x\n", fst_debug_mask);
+#endif
/*
* We are going to be clever and allow certain cards not to be
* configured. An exclude list can be provided in /etc/modules.conf
@@ -2441,8 +2437,8 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
*/
for (i = 0; i < fst_excluded_cards; i++) {
if ((pdev->devfn) >> 3 == fst_excluded_list[i]) {
- printk_info("FarSync PCI device %d not assigned\n",
- (pdev->devfn) >> 3);
+ pr_info("FarSync PCI device %d not assigned\n",
+ (pdev->devfn) >> 3);
return -EBUSY;
}
}
@@ -2451,20 +2447,19 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* Allocate driver private data */
card = kzalloc(sizeof (struct fst_card_info), GFP_KERNEL);
if (card == NULL) {
- printk_err("FarSync card found but insufficient memory for"
- " driver storage\n");
+ pr_err("FarSync card found but insufficient memory for driver storage\n");
return -ENOMEM;
}
/* Try to enable the device */
if ((err = pci_enable_device(pdev)) != 0) {
- printk_err("Failed to enable card. Err %d\n", -err);
+ pr_err("Failed to enable card. Err %d\n", -err);
kfree(card);
return err;
}
if ((err = pci_request_regions(pdev, "FarSync")) !=0) {
- printk_err("Failed to allocate regions. Err %d\n", -err);
+ pr_err("Failed to allocate regions. Err %d\n", -err);
pci_disable_device(pdev);
kfree(card);
return err;
@@ -2475,14 +2470,14 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
card->phys_mem = pci_resource_start(pdev, 2);
card->phys_ctlmem = pci_resource_start(pdev, 3);
if ((card->mem = ioremap(card->phys_mem, FST_MEMSIZE)) == NULL) {
- printk_err("Physical memory remap failed\n");
+ pr_err("Physical memory remap failed\n");
pci_release_regions(pdev);
pci_disable_device(pdev);
kfree(card);
return -ENODEV;
}
if ((card->ctlmem = ioremap(card->phys_ctlmem, 0x10)) == NULL) {
- printk_err("Control memory remap failed\n");
+ pr_err("Control memory remap failed\n");
pci_release_regions(pdev);
pci_disable_device(pdev);
kfree(card);
@@ -2492,7 +2487,7 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* Register the interrupt handler */
if (request_irq(pdev->irq, fst_intr, IRQF_SHARED, FST_DEV_NAME, card)) {
- printk_err("Unable to register interrupt %d\n", card->irq);
+ pr_err("Unable to register interrupt %d\n", card->irq);
pci_release_regions(pdev);
pci_disable_device(pdev);
iounmap(card->ctlmem);
@@ -2523,7 +2518,7 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!dev) {
while (i--)
free_netdev(card->ports[i].dev);
- printk_err ("FarSync: out of memory\n");
+ pr_err("FarSync: out of memory\n");
free_irq(card->irq, card);
pci_release_regions(pdev);
pci_disable_device(pdev);
@@ -2587,7 +2582,7 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_alloc_consistent(card->device, FST_MAX_MTU,
&card->rx_dma_handle_card);
if (card->rx_dma_handle_host == NULL) {
- printk_err("Could not allocate rx dma buffer\n");
+ pr_err("Could not allocate rx dma buffer\n");
fst_disable_intr(card);
pci_release_regions(pdev);
pci_disable_device(pdev);
@@ -2600,7 +2595,7 @@ fst_add_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_alloc_consistent(card->device, FST_MAX_MTU,
&card->tx_dma_handle_card);
if (card->tx_dma_handle_host == NULL) {
- printk_err("Could not allocate tx dma buffer\n");
+ pr_err("Could not allocate tx dma buffer\n");
fst_disable_intr(card);
pci_release_regions(pdev);
pci_disable_device(pdev);
@@ -2672,7 +2667,7 @@ fst_init(void)
static void __exit
fst_cleanup_module(void)
{
- printk_info("FarSync WAN driver unloading\n");
+ pr_info("FarSync WAN driver unloading\n");
pci_unregister_driver(&fst_driver);
}
^ permalink raw reply related
* Re: [PATCH] net: wl12xx: do not use kfree'd memory
From: Juuso Oikarinen @ 2010-08-02 5:04 UTC (permalink / raw)
To: ext Kulikov Vasiliy
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Coelho Luciano (Nokia-MS/Helsinki), John W. Linville,
Paasikivi Teemu.3 (EXT-Ixonos/Tampere),
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1280594039-3246-1-git-send-email-segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, 2010-07-31 at 18:33 +0200, ext Kulikov Vasiliy wrote:
> wl1271_dump() uses cmd after kfree(cmd). Move kfree() just after
> wl1271_dump().
>
> Signed-off-by: Kulikov Vasiliy <segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/wl12xx/wl1271_spi.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c b/drivers/net/wireless/wl12xx/wl1271_spi.c
> index 96d25fb..4cb99c5 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_spi.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
> @@ -160,9 +160,8 @@ static void wl1271_spi_init(struct wl1271 *wl)
> spi_message_add_tail(&t, &m);
>
> spi_sync(wl_to_spi(wl), &m);
> - kfree(cmd);
> -
> wl1271_dump(DEBUG_SPI, "spi init -> ", cmd, WSPI_INIT_CMD_LEN);
> + kfree(cmd);
> }
>
> #define WL1271_BUSY_WORD_TIMEOUT 1000
Whoops ;) Good catch, thanks.
Acked-by: Juuso Oikarinen <juuso.oikarinen-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
-Juuso
--
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: shape traffic on tun interfaces
From: Franchoze Eric @ 2010-08-02 7:46 UTC (permalink / raw)
To: alex; +Cc: lartc, netdev
In-Reply-To: <301941280614170@web105.yandex.ru>
>Do the QoS on your next hop router
There is no next router. And QoS should be on the same machine.
>or on the interface all your de-encapsulated VPN traffic flows over (ie. 'eth0') instead.
It is not a problem to find interface with de-encapsulated traffic. The problem is that tc rules should be written accoring to network device.
And it is really uncinvinient clone this rules which are differ only with destination IP.
For example look here. It's needed to create subclass for each destination IP.
#class
tc class add dev $DEV parent 1: classid 1:1 htb rate ${SPEED}kbit
#subclass
# high priority traffic (where we get money, http for example)
tc class add dev $DEV parent 1:1 classid 1:2 htb rate ${SPEED}kbit ceil ${SPEED}kbit prio 0
# low priority trafic - no adds - now money - low speed
tc class add dev $DEV parent 1:1 classid 1:3 htb rate ${SPEED}/2kbit ceil ${SPEED}kbit prio 1
#handle
tc qdisc add dev $DEV parent 1:2 handle 2: sfq perturb 10
tc qdisc add dev $DEV parent 1:3 handle 3: sfq perturb 10
#connect with
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 2 fw flowid 1:1001
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 3 fw flowid 1:1002
^ permalink raw reply
* [PATCH] tc: make symbols loaded from tc action modules global.
From: Andreas Henriksson @ 2010-08-02 7:30 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Fixes problems with xtables based MARK target ("ipt" module).
When tc loads the "ipt" (xt) module it kept the symbols local,
this made loading of libxtables not find the required struct.
currently ipt/xt is the only tc action module.
iproute2 never seem to do dlclose.
hopefully the modules doesn't export more symbols then needed.
In this situation hopefully the RTLD_GLOBAL flag won't hurt us.
I've been using this patch in the Debian package of iproute for
the last 3 weeks and noone has complained.
( This fixes http://bugs.debian.org/584898 )
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
tc/m_action.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tc/m_action.c b/tc/m_action.c
index a198158..6464b2e 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -99,7 +99,7 @@ restart_s:
}
snprintf(buf, sizeof(buf), "%s/m_%s.so", get_tc_lib(), str);
- dlh = dlopen(buf, RTLD_LAZY);
+ dlh = dlopen(buf, RTLD_LAZY | RTLD_GLOBAL);
if (dlh == NULL) {
dlh = aBODY;
if (dlh == NULL) {
--
1.7.1
^ permalink raw reply related
* why do we need printk on sending syn flood cookie?
From: Franchoze Eric @ 2010-08-02 7:58 UTC (permalink / raw)
To: netdev
Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
Something like this:
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index fe193e5..5574adc 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1230,8 +1230,10 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
__u32 isn = TCP_SKB_CB(skb)->when;
#ifdef CONFIG_SYN_COOKIES
int want_cookie = 0;
+ int want_cookie_no_warn = 0;
#else
#define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
+#define want_cookie_no_warn 0
#endif
/* Never answer to SYNs send to broadcast or multicast */
@@ -1246,7 +1248,10 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
#ifdef CONFIG_SYN_COOKIES
if (sysctl_tcp_syncookies) {
want_cookie = 1;
- } else
+ if (sysctl_tcp_syncookies == 2)
+ want_cookie_no_warn = 1;
+ }
+ else
#endif
goto drop;
}
@@ -1296,6 +1301,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
#ifdef CONFIG_SYN_COOKIES
want_cookie = 0; /* not our kind of cookie */
+ want_cookie_no_warn = 0; /* no printk on syn flood */
#endif
tmp_ext.cookie_out_never = 0; /* false */
tmp_ext.cookie_plus = tmp_opt.cookie_plus;
@@ -1328,7 +1334,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
if (want_cookie) {
#ifdef CONFIG_SYN_COOKIES
- syn_flood_warning(skb);
+ if (!want_cookie_no_warn)
+ syn_flood_warning(skb);
req->cookie_ts = tmp_opt.tstamp_ok;
#endif
isn = cookie_v4_init_sequence(sk, skb, &req->mss);
^ permalink raw reply related
* Re: why do we need printk on sending syn flood cookie?
From: Florian Westphal @ 2010-08-02 8:17 UTC (permalink / raw)
To: Franchoze Eric; +Cc: netdev
In-Reply-To: <480391280735894@web102.yandex.ru>
Franchoze Eric <franchoze@yandex.ru> wrote:
> Just sirious why do we need printk each 1 second (60*HZ) about possible syn-flood? It really floods dmesg. Is there something dengerous? I have suggestion to turn off printk about sending tcp cookie each 1 second.
It is handled exactly like other printks in the networking path,
e.g. receipt of tcp wscale == 15.
Why does this need special treatment?
^ permalink raw reply
* Re: shape traffic on tun interfaces
From: Changli Gao @ 2010-08-02 8:36 UTC (permalink / raw)
To: Franchoze Eric; +Cc: alex, lartc, netdev
In-Reply-To: <474381280735172@web82.yandex.ru>
On Mon, Aug 2, 2010 at 3:46 PM, Franchoze Eric <franchoze@yandex.ru> wrote:
>>Do the QoS on your next hop router
> There is no next router. And QoS should be on the same machine.
>
>>or on the interface all your de-encapsulated VPN traffic flows over (ie. 'eth0') instead.
>
> It is not a problem to find interface with de-encapsulated traffic. The problem is that tc rules should be written accoring to network device.
try ifb:
config IFB
tristate "Intermediate Functional Block support"
depends on NET_CLS_ACT
---help---
This is an intermediate driver that allows sharing of
resources.
To compile this driver as a module, choose M here: the module
will be called ifb. If you want to use more than one ifb
device at a time, you need to compile this driver as a module.
Instead of 'ifb', the devices will then be called 'ifb0',
'ifb1' etc.
Look at the iproute2 documentation directory for usage etc
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: Is it a possible bug in dev_gro_receive()?
From: Jarek Poplawski @ 2010-08-02 10:29 UTC (permalink / raw)
To: Xin Xiaohui; +Cc: netdev, herbert, davem
In-Reply-To: <1280454855-7893-1-git-send-email-xiaohui.xin@intel.com>
Xin Xiaohui wrote:
> I looked into the code dev_gro_receive(), found the code here:
> if the frags[0] is pulled to 0, then the page will be released,
> and memmove() frags left.
> Is that right? I'm not sure if memmove do right or not, but
> frags[0].size is never set after memove at least. what I think
> a simple way is not to do anything if we found frags[0].size == 0.
> The patch is as followed.
>
> Or am I missing something here?
I think, you're right, but fixing memmove looks nicer to me:
- --skb_shinfo(skb)->nr_frags);
+ --skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
Jarek P.
>
> ---
> net/core/dev.c | 7 -------
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 264137f..28cdbbf 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2730,13 +2730,6 @@ pull:
>
> skb_shinfo(skb)->frags[0].page_offset += grow;
> skb_shinfo(skb)->frags[0].size -= grow;
> -
> - if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
> - put_page(skb_shinfo(skb)->frags[0].page);
> - memmove(skb_shinfo(skb)->frags,
> - skb_shinfo(skb)->frags + 1,
> - --skb_shinfo(skb)->nr_frags);
> - }
> }
>
> ok:
^ permalink raw reply
* Re: Is it a possible bug in dev_gro_receive()?
From: Herbert Xu @ 2010-08-02 11:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Xin Xiaohui, netdev, davem
In-Reply-To: <20100802102906.GA8439@ff.dom.local>
On Mon, Aug 02, 2010 at 10:29:06AM +0000, Jarek Poplawski wrote:
> Xin Xiaohui wrote:
> > I looked into the code dev_gro_receive(), found the code here:
> > if the frags[0] is pulled to 0, then the page will be released,
> > and memmove() frags left.
> > Is that right? I'm not sure if memmove do right or not, but
> > frags[0].size is never set after memove at least. what I think
> > a simple way is not to do anything if we found frags[0].size == 0.
> > The patch is as followed.
> >
> > Or am I missing something here?
>
> I think, you're right, but fixing memmove looks nicer to me:
>
> - --skb_shinfo(skb)->nr_frags);
> + --skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
I agree with the diagnosis and your proposed fix.
Thanks for catching this Xiaohui!
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RFC: New BGF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-02 11:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]
---
Proposal: Create a new BPF instruction, "LOOP", which can implement a
specific time-bounded kind of while() loop over packet contents
---
IPv6 packets contain a linked-list of headers. Some other network
protocols may also contain linked-list structure.
BPF cannot implement loops.
Currently therefore, it is impossible to efficiently parse IPv6 packets
without resorting to such annoying tricks as statically unrolling a loop
into a long list of instructions. In IPv6's case this gets very large
very quickly, as different header types have different lengths, or
structure layouts.
I propose to add a new instruction, "LOOP", with the following
semantics:
BPF_JMP|BPF_LOOP, jt
If A == 0, fallthrough to the next instruction.
(TODO: Or perhaps this should be considered a hard error which
immediately aborts the filter, similar to divide by zero?)
Otherwise:
X += A.
If X < len, jump backwards jt instructions.
Otherwise, fallthrough to the next instruction
The following static checks would be enforced:
None of the 'jt' preceeding instructions before the LOOP instruction
(i.e. the body of the loop) may themselves be LOOP instructions, nor may
they be STX.
The intention of this instruction is to be able to implement a loop in
which successive iterations advance the index register along the packet
buffer. By comparing X to the packet length, we can bound the running
time of the loop instruction, avoiding it locking up the kernel. By
banning STX instructions within the body of the loop, we can ensure that
X must be a strictly monotonically increasing sequence. At absolute
worst, X is increased by 1 each time, meaning at worst the body of the
loop must execute for every byte in the packet. By banning further
nested LOOP instructions, we can ensure at worst a linear running time.
I believe this addition should have minimal impact on existing users of
the filter layer, as it simply adds a new instruction and does not
otherwise change the semantics of any existing code. I also believe it
to be useful in writing filters that process IPv6 packets. I also
believe that the semantics and static checks are sufficient to preserve
the termination guarantee of BPF filter programs, ensuring each packet's
fate is decided in a timely fashion to avoid locking up the kernel.
Any comments on this, while I proceed? Barring any major complaints,
I'll have a hack at some code and present a patch in due course...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-02 11:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100802110334.GK11110@cel.leo>
[-- Attachment #1: Type: text/plain, Size: 195 bytes --]
*ahem* Typo in the subject line there, sorry. I meant "BPF".
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] pcmcia: use pcmica_{read,write}_config_byte
From: Komuro @ 2010-08-02 11:59 UTC (permalink / raw)
To: Dominik Brodowski
Cc: Michael Buesch, netdev, linux-pcmcia, linux-wireless,
Dominik Brodowski, linux-serial
In-Reply-To: <1280667550-3040-1-git-send-email-linux@dominikbrodowski.net>
Hi,
>--- a/drivers/net/pcmcia/xirc2ps_cs.c
>+++ b/drivers/net/pcmcia/xirc2ps_cs.c
>+ if (err)
> goto config_error;
>- reg.Action = CS_WRITE;
>- reg.Offset = CISREG_IOBASE_1;
>- reg.Value = (link->io.BasePort2 >> 8) & 0xff;
>- if ((err = pcmcia_access_configuration_register(link, ®)))
>+
>+ err = pcmcia_write_config_byte(link, CISREG_IOBASE_1,
>+ link->io.BasePort2 & 0xff);
It should be
err = pcmcia_write_config_byte(link, CISREG_IOBASE_1,
(link->io.BasePort2 >> 8) & 0xff);
^ permalink raw reply
* Re: [PATCH] net: Add getsockopt support for TCP thin-streams
From: Andreas Petlund @ 2010-08-02 11:46 UTC (permalink / raw)
To: Josh Hunt; +Cc: davem, kuznet, jmorris, kaber, netdev, linux-kernel, juhlenko
In-Reply-To: <1280533775-7700-1-git-send-email-johunt@akamai.com>
On 07/31/2010 01:49 AM, Josh Hunt wrote:
> Initial TCP thin-stream commit did not add getsockopt support for the new
> socket options: TCP_THIN_LINEAR_TIMEOUTS and TCP_THIN_DUPACK. This adds support
> for them.
>
> Signed-off-by: Josh Hunt <johunt@akamai.com>
> ---
> net/ipv4/tcp.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 65afeae..3ed3525 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2591,6 +2591,12 @@ static int do_tcp_getsockopt(struct sock *sk, int level,
> return -EFAULT;
> return 0;
> }
> + case TCP_THIN_LINEAR_TIMEOUTS:
> + val = tp->thin_lto;
> + break;
> + case TCP_THIN_DUPACK:
> + val = tp->thin_dupack;
> + break;
> default:
> return -ENOPROTOOPT;
> }
Thanks for noticing and fixing this :)
Tested-by: Andreas Petlund <apetlund@simula.no>
Acked-by: Andreas Petlund <apetlund@simula.no>
-Andreas
^ permalink raw reply
* Re: [PATCH] Multiqueue macvtap driver
From: Krishna Kumar2 @ 2010-08-02 12:37 UTC (permalink / raw)
To: David Miller; +Cc: arnd, bhutchings, mst, netdev
In-Reply-To: <20100801.003406.02275545.davem@davemloft.net>
Thanks Ben & Dave. A question though - which of the following
is preferable for the macvtap driver:
1. Calculate flow and use that to find a queue; or
2. First check if skb_rx_queue_recorded is true and if so use
that; otherwise calculate the flow as in #1.
I guess #1 is better, since packets for a single flow will go to the
same queue even if they arrive on different rxqs of a mq driver.
But I want to make sure.
Thanks,
- KK
David Miller <davem@davemloft.net> wrote on 08/01/2010 01:04:06 PM:
> David Miller <davem@davemloft.net>
> 08/01/2010 01:04 PM
>
> To
>
> bhutchings@solarflare.com
>
> cc
>
> Krishna Kumar2/India/IBM@IBMIN, arnd@arndb.de,
> netdev@vger.kernel.org, mst@redhat.com
>
> Subject
>
> Re: [PATCH] Multiqueue macvtap driver
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Sat, 31 Jul 2010 20:18:27 +0100
>
> > On Sat, 2010-07-31 at 19:27 +0530, Krishna Kumar wrote:
> > [...]
> >> @@ -136,39 +158,68 @@ static void macvtap_put_queue(struct mac
> >> }
> >>
> >> /*
> >> - * Since we only support one queue, just dereference the pointer.
> >> + * Select a queue based on the rxq of the device on which this packet
> >> + * arrived. If the incoming device is not mq, then use our cpu number
> >> + * to select a queue. vlan->numvtaps is cached in case it changes
> >> + * during the execution of this function.
> >> */
> > [...]
> >
> > This can result in reordering if a single-queue device's RX interrupt's
> > CPU affinity is changed. We generally try to avoid that. You should
> > really use or generate a flow hash. There is code for this in
> > net/core/dev.c:get_rps_cpu() which could be factored out into a
separate
> > function.
>
> Agreed.
^ 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