* Re: [Bugme-new] [Bug 15091] New: starfire causes kernel BUG when interface goes up
From: Andrew Morton @ 2010-01-26 1:51 UTC (permalink / raw)
To: Michael; +Cc: netdev, bugzilla-daemon, bugme-daemon, Alan Cox
In-Reply-To: <4B5E48FF.2050406@moffatt.org.nz>
On Tue, 26 Jan 2010 14:44:31 +1300 Michael <michael@moffatt.org.nz> wrote:
> Hi Andrew,
>
> I believe that this is a regression, yes.
>
> I will attempt to compile up some kernels this week and provide more
> info. Should I start at 26 and go up or at 31 and go down?
>
> I can't use anything lower than 26 according to udev. I was running 24
> but compiled 32 when I upgraded udev.
>
Thanks.
Starfire is a pretty rarely-used driver, I suspect. Hopefully someone
who understands the NAPI stuff can look at the code and go "ah-hah",
and save you all that work.
But if that doesn't happen then yup, a bisection would be good, thanks.
The best way to do it really is with git.
http://landley.net/writing/git-quick.html has an explanation.
^ permalink raw reply
* Re: [PATCH v2]IP: Send an ICMP "Fragment Reassembly Timeout" message when enabling connection track
From: Shan Wei @ 2010-01-26 1:25 UTC (permalink / raw)
To: Yasuyuki KOZAKAI
Cc: kaber, davem, kuznet, pekkas, jmorris, yoshfuji, eric.dumazet,
david, jorge, opurdila, netdev, netfilter-devel
In-Reply-To: <201001250057.o0P0v76J005243@toshiba.co.jp>
Yasuyuki KOZAKAI wrote, at 01/25/2010 08:57 AM:
> It sounds good. Please take care that IPv6 router does not reassemble
> fragmented packets.
I don't know the details about IPv6 router implement.
Did you mean that we can not directly use ip6_route_input(skb) to find Routing type(host/router)?
> IIRC the current nf_conntrack_{ipv6,reasm}.c
> reassembles the cloned skbs for tracking, discard the cloned skbs after
> tracking and forward the original skbs to IPv6 stack to keep the size of
> fragmented packets.
Indeed, after assembling fragments successfully in IPv6 connection track, original fragments are forwarded to IPv6 stack. And then IPv6 stack also assembles those received fragments again.
Thus fragments are assembled twice.
But IPv4 only assembly once. IPv4 connection track assembles fragments successfully and then just forwards assembled intact packet to IPv4 stack.
Do you know why is IPv6 designed like that?
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Tejun Heo @ 2010-01-26 1:19 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <20100126010239.GK5087@nowhere>
Hello,
On 01/26/2010 10:02 AM, Frederic Weisbecker wrote:
> Well, sorry I must be missing something obvious, but is it impossible
> to make per_cpu(var, cpu) returning something cast in:
>
> (typeof(var) __force)
>
> Or I guess you did that already and it is not working with static
> arrays, or?
Yeap, the definition looks like
#define SHIFT_PERCPU_PTR(__p, __offset) ({ \
__verify_pcpu_ptr((__p)); \
RELOC_HIDE((typeof(*(__p)) __kernel __force *)(__p), (__offset)); \
})
#define per_cpu(var, cpu) \
(*SHIFT_PERCPU_PTR(&(var), per_cpu_offset(cpu)))
but it just ends up putting the __force at the wrong layer. It seems
that (typeof(var) __kernel __force) tell sparse var is in the kernel
address space but not its members.
> Is there a patch that shows per_cpu() macro changes in the batch?
Sorry I forgot to write about this. It's in the percpu tree.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-next
The related commits are 545695fb41da117928ab946067a42d9e15fd009d and
e0fdb0e050eae331046385643618f12452aa7e73.
Thanks.
--
tejun
^ permalink raw reply
* Re: Netlink usage question (for bonding comm with userspace)
From: Jay Vosburgh @ 2010-01-26 1:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100125.165152.132891922.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
[...]
>> I could, for this project, use a netlink_kernel_create and
>> socket(AF_NETLINK) pair to perform the communication (presumably adding
>> a NETLINK_BONDING or the like to <linux/netlink.h>).
>
>This is no longer done, so that we don't have an issue with
>running out of netlink sub-protocol numbers.
>
>Instead use generic netlink, the IDs are allocated dynamically
>and looked up via text strings which provides a better scheme
>for namespace allocation.
Thanks for the response.
Just so I'm clear, though: use generic netlink for the needs of
this particular project, and then later it's acceptable to have both
generic and rtnetlink co-existing for their respective uses?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Frederic Weisbecker @ 2010-01-26 1:12 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Tejun Heo, linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <4B5E401D.2020809@zytor.com>
On Mon, Jan 25, 2010 at 05:06:37PM -0800, H. Peter Anvin wrote:
> On 01/25/2010 04:19 PM, Frederic Weisbecker wrote:
> > On Tue, Jan 26, 2010 at 12:22:14AM +0900, Tejun Heo wrote:
> >> Add __percpu sparse annotations to hw_breakpoint.
> >>
> >> These annotations are to make sparse consider percpu variables to be
> >> in a different address space and warn if accessed without going
> >> through percpu accessors. This patch doesn't affect normal builds.
> >>
> >> per_cpu(nr_task_bp_pinned, cpu) is replaced with
> >> &per_cpu(nr_task_bp_pinned[0], cpu). This is the same to the compiler
> >> but allows per_cpu() macro to correctly drop __percpu designation for
> >> the returned pointer.
> >
> > Ouch... It's unpleasant to see such workaround that messes up the
> > code just to make sparse happy.
> >
> > I guess __percpu is an address_space attribute? Is there no
> > way to force the address space change directly from the
> > per_cpu() macro?
> >
>
> Hmm... thinking more about it, we should be able to just move the & and
> [0] into the per_cpu() macro, addressing the situation, or does that
> cause problems elsewhere?
>
> -hpa
That would work only with arrays. per_cpu() can access either pointers
or direct values. Well that can be worked around with fake casts, but
I would except the (typeof(x) __force) to work and then offer a more
elegant solution.
^ permalink raw reply
* Re: [Bugme-new] [Bug 15091] New: starfire causes kernel BUG when interface goes up
From: Andrew Morton @ 2010-01-26 1:08 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, michael, Alan Cox
In-Reply-To: <bug-15091-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 20 Jan 2010 04:29:20 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15091
>
> Summary: starfire causes kernel BUG when interface goes up
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.32
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: michael@moffatt.org.nz
> Regression: No
>
>
> Created an attachment (id=24651)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=24651)
> ls -l /dev (before crash)
>
> I formerly used 2.6.20 and 2.6.24 with a couple of starfire 4 port ethernet
> cards. On 2.6.32 the interfaces don't start on boot and when I issue "ifconfig
> ethX up" (where X is a starfire port).
>
> Sometimes the exception causes the whole kernel to freeze. Sometimes the kernel
> keeps going. On the occasion that the kernel kept going I was able to retrieve
> syslog, which has the full kernel information.
>
> Note that in syslog, you can see that I inserted a USB memory stick in order to
> copy off the attached files. The kernel oops happens without the USB memory
> stick inserted.
>
> I can reproduce this at will. At the moment I simply can't use my two four port
> starfire network cards.
>
> This PC is a root-over-NFS system.
>
Starfire is triggering the BUG_ON(!test_bit(NAPI_STATE_SCHED,
&n->state)); in napi_enable().
This is a regression somewhere between 2.6.24 and 2.6.32(!).
^ permalink raw reply
* Re: 2.6.33-rc5: (e1000): transmit queue 0 timed out
From: Brandeburg, Jesse @ 2010-01-26 1:07 UTC (permalink / raw)
To: Alexander Beregalov
Cc: e1000-devel@lists.sourceforge.net, netdev, Rafael J. Wysocki
In-Reply-To: <a4423d671001230737i3b3c7da1q6cd4ce615888b36e@mail.gmail.com>
On Sat, 23 Jan 2010, Alexander Beregalov wrote:
> It is x86_32, UP
>
> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> Tx Queue <0>
> TDH <0>
The queue seems to have not been started... what test are you running?
what kind of traffic and system? (lspci -vvv please)
> TDT <1f>
> next_to_use <1f>
> next_to_clean <30>
> buffer_info[next_to_clean]
> time_stamp <12d519>
> next_to_watch <30>
> jiffies <12da92>
> next_to_watch.status <0>
> WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1c5/0x1d0()
> Hardware name:
> NETDEV WATCHDOG: eth0 (e1000): transmit queue 0 timed out
> Modules linked in: hwmon_vid sata_sil i2c_nforce2
> Pid: 0, comm: swapper Not tainted 2.6.33-rc5 #1
> Call Trace:
> [<c102a49d>] warn_slowpath_common+0x6d/0xa0
> [<c12ea885>] ? dev_watchdog+0x1c5/0x1d0
> [<c12ea885>] ? dev_watchdog+0x1c5/0x1d0
> [<c102a516>] warn_slowpath_fmt+0x26/0x30
> [<c12ea885>] dev_watchdog+0x1c5/0x1d0
> [<c1033bb7>] ? run_timer_softirq+0xd7/0x240
> [<c1033c31>] run_timer_softirq+0x151/0x240
> [<c1033bb7>] ? run_timer_softirq+0xd7/0x240
> [<c12ea6c0>] ? dev_watchdog+0x0/0x1d0
> [<c102f40a>] __do_softirq+0x7a/0x110
> [<c102f4ed>] do_softirq+0x4d/0x60
> [<c102f625>] irq_exit+0x65/0x70
> [<c1015fe7>] smp_apic_timer_interrupt+0x47/0x80
> [<c11d6904>] ? trace_hardirqs_off_thunk+0xc/0x18
> [<c1350e63>] apic_timer_interrupt+0x2f/0x34
> [<c10088fd>] ? default_idle+0x2d/0x60
> [<c1001b19>] cpu_idle+0x39/0x60
> [<c13451e8>] rest_init+0x48/0x50
> [<c16196b4>] start_kernel+0x26d/0x274
> [<c1619275>] ? unknown_bootoption+0x0/0x19c
> [<c1619068>] i386_start_kernel+0x68/0x6e
> ---[ end trace 828c510cca9472df ]---
> BUG: unable to handle kernel paging request at 2e8ca4f3
> IP: [<c1071c51>] put_page+0x11/0x120
hm, put_page panic, are you running with jumbo frames enabled? Does your
network have jumbo frame traffic on it?
> *pde = 00000000
> Oops: 0000 [#1]
> last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> Modules linked in: hwmon_vid sata_sil i2c_nforce2
>
> Pid: 5, comm: events/0 Tainted: G W 2.6.33-rc5 #1
> NF7-S/NF7,NF7-V (nVidia-nForce2)/
> EIP: 0060:[<c1071c51>] EFLAGS: 00010282 CPU: 0
> EIP is at put_page+0x11/0x120
> EAX: 2e8ca4f3 EBX: 2e8ca4f3 ECX: 00000000 EDX: ee960640
> ESI: f6482620 EDI: 000016b0 EBP: f7065ea8 ESP: f7065e98
> DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> Process events/0 (pid: 5, ti=f7064000 task=f70553c0 task.ti=f7064000)
> Stack:
> 00000206 00000001 f6482620 000016b0 f7065eb8 c12d3100 f6482620 f71d9f50
> <0> f7065ec4 c12d2e32 f80376b0 f7065ecc c12d2ec5 f7065f00 c1276970 cccccccd
> <0> f7065f00 f711fafc f711fafc f711faa0 00000000 f702b440 000000f2 f702b440
> Call Trace:
> [<c12d3100>] ? skb_release_data+0x90/0xa0
> [<c12d2e32>] ? __kfree_skb+0x12/0x90
> [<c12d2ec5>] ? consume_skb+0x15/0x30
> [<c1276970>] ? e1000_clean_rx_ring+0x80/0x150
> [<c127c743>] ? e1000_down+0x1b3/0x1d0
> [<c127cf60>] ? e1000_reset_task+0x0/0x10
> [<c127cd3b>] ? e1000_reinit_locked+0x4b/0x70
> [<c127cf6d>] ? e1000_reset_task+0xd/0x10
> [<c103a9ea>] ? worker_thread+0x14a/0x230
> [<c103a989>] ? worker_thread+0xe9/0x230
> [<c103e160>] ? autoremove_wake_function+0x0/0x40
> [<c103a8a0>] ? worker_thread+0x0/0x230
> [<c103de6c>] ? kthread+0x6c/0x80
> [<c103de00>] ? kthread+0x0/0x80
> [<c100303a>] ? kernel_thread_helper+0x6/0x1c
> Code: 00 00 00 8d bc 27 00 00 00 00 55 b8 e0 1f 07 c1 89 e5 e8 83 93
> fc ff c9 c3 90 55 89 e5 83 ec 10 89 5d f4 89 75 f8 89 c3 89 7d fc <66>
> f7 00 00 c0 0f 85 e4 00 00 00 8b 40 04 85 c0 0f 84 e3 00 00
> EIP: [<c1071c51>] put_page+0x11/0x120 SS:ESP 0068:f7065e98
> CR2: 000000002e8ca4f3
> ---[ end trace 828c510cca9472e0 ]---
Thanks for the report, do you believe it to be new to e1000 in 2.6.33-rc5?
Have you had failure like this before and/or can you see the same failure
on 2.6.32?
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: H. Peter Anvin @ 2010-01-26 1:06 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Tejun Heo, linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <20100126001901.GI5087@nowhere>
On 01/25/2010 04:19 PM, Frederic Weisbecker wrote:
> On Tue, Jan 26, 2010 at 12:22:14AM +0900, Tejun Heo wrote:
>> Add __percpu sparse annotations to hw_breakpoint.
>>
>> These annotations are to make sparse consider percpu variables to be
>> in a different address space and warn if accessed without going
>> through percpu accessors. This patch doesn't affect normal builds.
>>
>> per_cpu(nr_task_bp_pinned, cpu) is replaced with
>> &per_cpu(nr_task_bp_pinned[0], cpu). This is the same to the compiler
>> but allows per_cpu() macro to correctly drop __percpu designation for
>> the returned pointer.
>
> Ouch... It's unpleasant to see such workaround that messes up the
> code just to make sparse happy.
>
> I guess __percpu is an address_space attribute? Is there no
> way to force the address space change directly from the
> per_cpu() macro?
>
Hmm... thinking more about it, we should be able to just move the & and
[0] into the per_cpu() macro, addressing the situation, or does that
cause problems elsewhere?
-hpa
^ permalink raw reply
* Re: [PATCH 5/8] percpu: add __percpu sparse annotations to x86
From: H. Peter Anvin @ 2010-01-26 1:06 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
fweisbec, dan.j.williams, borislav.petkov, ying.huang, lenb,
neilb, cl, Thomas Gleixner
In-Reply-To: <1264432935-10453-6-git-send-email-tj@kernel.org>
On 01/25/2010 07:22 AM, Tejun Heo wrote:
>
> In arch/x86/kernel/cpu/common.c, per_cpu(exception_stacks, cpu) is
> replaced with &per_cpu(exception_stacks[0], cpu) which is equivalent
> except that it allows per_cpu() macro to correctly drop percpu
> designation during sparse pass.
>
Same comment as Frederic's about this... this kind of uglification
really is unacceptable and needs to be addressed.
Other than that, it looks good.
-hpa
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Frederic Weisbecker @ 2010-01-26 1:02 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <4B5E3BED.6030705@kernel.org>
On Tue, Jan 26, 2010 at 09:48:45AM +0900, Tejun Heo wrote:
> Hello, Frederic.
>
> On 01/26/2010 09:19 AM, Frederic Weisbecker wrote:
> > On Tue, Jan 26, 2010 at 12:22:14AM +0900, Tejun Heo wrote:
> >> Add __percpu sparse annotations to hw_breakpoint.
> >>
> >> These annotations are to make sparse consider percpu variables to be
> >> in a different address space and warn if accessed without going
> >> through percpu accessors. This patch doesn't affect normal builds.
> >>
> >> per_cpu(nr_task_bp_pinned, cpu) is replaced with
> >> &per_cpu(nr_task_bp_pinned[0], cpu). This is the same to the compiler
> >> but allows per_cpu() macro to correctly drop __percpu designation for
> >> the returned pointer.
> >
> > Ouch... It's unpleasant to see such workaround that messes up the
> > code just to make sparse happy.
> >
> > I guess __percpu is an address_space attribute? Is there no
> > way to force the address space change directly from the
> > per_cpu() macro?
>
> Yeah, per_cpu() macro does that but when things get a bit complicated
> with static percpu arrays. In the above case, the variable is defined
> as
>
> static DEFINE_PER_CPU(unsigned int, nr_task_bp_pinned[HBP_NUM]);
>
> which gets translated to
>
> static __attribute__((noderef, address_space(3))) \
> __attribute__((section(.data.percpu))) \
> __typeof__(unsigned int) nr_task_bp_pinned[HBP_NUM];
>
> The above tells sparse that the members of nr_task_bp_pinned array are
> in address space 3 which is correct. The problematic dereference was
>
> unsigned int *task_pinned = per_cpu(nr_task_bp_pinned, cpu)
>
> per_cpu() macro changes the address space of the resulting address but
> it does so assuming that the parameter it got passed is the one which
> got declared to be in the percpu address space. It casts
> nr_task_bp_pinned itself, which to the sparse isn't in the percpu
> address space, to the kernel address space. So, the workaround is
> basically to give per_cpu() macro the same thing that was defined.
>
> This type of usage (define as array, dereference the array as address)
> was the only place where I needed to work around to make address space
> change explicit. There are two places which needed this and hwbreak
> was one. The options were...
>
> * Leave it alone. We can live with a few additional sparse warnings.
>
> * Make the proposed change. It is slightly ugly but not cryptic or
> difficult.
>
> * Somehow teach per_cpu() macro or sparse how to handle the above
> right.
>
> I tried to improve per_cpu() macro but couldn't do it in any sane way.
> Leaving it alone isn't too bad either but given that the workaround is
> not horribly unreadable, I think it's best to use the slightly less
> elegant form in the few places where they are needed.
Ok.
Well, sorry I must be missing something obvious, but is it impossible
to make per_cpu(var, cpu) returning something cast in:
(typeof(var) __force)
Or I guess you did that already and it is not working with static
arrays, or?
Is there a patch that shows per_cpu() macro changes in the batch?
Thanks.
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: H. Peter Anvin @ 2010-01-26 1:02 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Tejun Heo, linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <20100126001901.GI5087@nowhere>
On 01/25/2010 04:19 PM, Frederic Weisbecker wrote:
> On Tue, Jan 26, 2010 at 12:22:14AM +0900, Tejun Heo wrote:
>> Add __percpu sparse annotations to hw_breakpoint.
>>
>> These annotations are to make sparse consider percpu variables to be
>> in a different address space and warn if accessed without going
>> through percpu accessors. This patch doesn't affect normal builds.
>>
>> per_cpu(nr_task_bp_pinned, cpu) is replaced with
>> &per_cpu(nr_task_bp_pinned[0], cpu). This is the same to the compiler
>> but allows per_cpu() macro to correctly drop __percpu designation for
>> the returned pointer.
>
> Ouch... It's unpleasant to see such workaround that messes up the
> code just to make sparse happy.
>
> I guess __percpu is an address_space attribute? Is there no
> way to force the address space change directly from the
> per_cpu() macro?
>
A cast (using __typeof__) combined with an address space override?
-hpa
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2010-01-26 0:56 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) SKY2 revert to fix a resume regression, from Stephem Hemminger
2) We can end up trying to remove/proc/net/rt_acct when exiting
a namespace even when we didn't create it in the first place.
Fix from Alexey Dobriyan.
3) IPSEC in namespaces can wedge if IPSEC route creation hits the
garbage collection threshold, it'll wedge until the initial
namespace happens to hit GC limits and garbage collect.
Fix from Alexey Dobriyan.
4) igb/igbvg test for DMA mapping failures incorrectly in TX
path, from Alexander Duyck.
5) qlge tries to free resources never allocated, fix from Breno Leitao
6) vlan_skb_recv() references wrong device for statistics bumping,
resulting in OOPS. Regression fixed by Eric Dumazet.
7) virtio_net refilling is unreliable when OOM and can wedge,
fix from Herbert Xu
8) Intel drivers test for ipv6 GRO incorrectly, fix from Sridhar
Samudrala.
9) tcp_probe reports available space incorrectly (off by one) and
does many unnecessary expensive modulus operations, from Stephen
Hemminger.
10) Add ID for Microsoft MN-120 PCMCIA card, from Ron Murray.
11) Appletalk's aarp_recv() references wrong foo.s_net, from Roel Kluin.
12) INET_DIAG_BC_S_LE compares wrong TCP port, also from Roel Kluin.
13) Fix two branches of an if() in S2IO which erroneously program the
chip identically, noticed by Roel Kluin and fixed by Ram Vepa.
14) Fix dccp_probe/dccp module dependencies, and cure crashes on
dccp module unload. From Neil Horman.
15) SKY2 needs to enable/disable WOL per card, not per port. Fix
from Mike McCormack.
16) SFC bug fixes (bad MMD checks at init, GMAC bug workaround fix,
BUG() and hang due to misaligned MCDI NVRAM requests, etc.) from
Matthew Slattery, Guido Barzini, and Ben Hutchings.
17) Fix regression by moving phylib's workqueue init to the proper
place, from Anton Vorontsov.
18) I/O AT maintainership update.
19) Wireless fixes via John Linville and co.
Please pull, thanks a lot!
The following changes since commit f6760aa024199cfbce564311dc4bc4d47b6fb349:
Linus Torvalds (1):
Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Abhijeet Kolekar (1):
cfg80211: fix channel setting for wext
Alexander Duyck (1):
igb/igbvf: cleanup exception handling in tx_map_adv
Alexey Dobriyan (3):
ipv4: don't remove /proc/net/rt_acct
netns xfrm: fix "ip xfrm state|policy count" misreport
netns xfrm: deal with dst entries in netns
Anton Vorontsov (1):
phylib: Move workqueue initialization to a proper place
Ben Hutchings (1):
sfc: Use fixed-size buffers for MCDI NVRAM requests
Benoit Papillault (1):
mac80211: check that ieee80211_set_power_mgmt only handles STA interfaces.
Bob Copeland (1):
mac80211: fix sign error in pid controller
Breno Leitao (1):
qlge: Only free resources if they were allocated
Christian Lamparter (1):
p54pci: rx frame length check
Dan Williams (1):
MAINTAINERS: transfer maintainership of I/OAT
David S. Miller (3):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Merge branch 'linux-2.6.33.y' of git://git.kernel.org/.../inaky/wimax
Eric Dumazet (1):
vlan: fix vlan_skb_recv()
Guido Barzini (1):
sfc: Add workspace for GMAC bug workaround to MCDI MAC_STATS buffer
Herbert Xu (1):
virtio_net: Make delayed refill more reliable
Hin-Tak Leung (1):
zd1211rw: adding 0409:0248 to supported device list
Inaky Perez-Gonzalez (1):
wimax/i2400m: Add support for more i6x50 SKUs
Jarek Poplawski (1):
ax25: netrom: rose: Fix timer oopses
Jeff Kirsher (1):
MAINTAINERS: Add Intel igbvf maintainer
Jesse Brandeburg (3):
e1000: enhance frame fragment detection
e1000e: enhance frame fragment detection
e1000/e1000e: don't use small hardware rx buffers
Jiajun Wu (1):
ucc_geth: Fix full TX queue processing
Ken Kawasaki (1):
fmvj18x_cs: add new id (Panasonic lan & modem card)
Matthew Slattery (1):
sfc: QT202x: Remove unreliable MMD check at initialisation
Mike Frysinger (1):
bfin_mac: use the newer CLKBUFOE bit name via asm/dpmc.h
Mike McCormack (1):
sky2: Enable/disable WOL per hardware device
Neil Horman (2):
dccp_probe: Fix module load dependencies between dccp and dccp_probe
dccp: fix dccp rmmod when kernel configured to use slub
Ram Vepa (1):
S2io: two branches the same in wait_for_cmd_complete()
Reinette Chatre (1):
iwlwifi: add license to tracing files
Roel Kluin (3):
appletalk:: da.s_net not copied but assigned to itself in aarp_rcv()
netlink: With opcode INET_DIAG_BC_S_LE dport was compared in inet_diag_bc_run()
e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()
Ron Murray (1):
Please add support for Microsoft MN-120 PCMCIA network card
Samuel Ortiz (1):
iwmc3200wifi: Add UMAC wifi headers to the pmkid command
Sathya Perla (2):
be2net: fix bug in rx page posting
be2net: swap only first 2 fields of mcc_wrb
Sridhar Samudrala (1):
net: Fix IPv6 GSO type checks in Intel ethernet drivers
Stephen Hemminger (1):
tcp_probe: avoid modulus operation and wrap fix
Wey-Yi Guy (1):
iwlwifi: Fix throughput stall issue in HT mode for 5000
stephen hemminger (1):
sky2: revert config space change
MAINTAINERS | 8 ++--
drivers/net/benet/be_cmds.c | 2 +-
drivers/net/benet/be_main.c | 8 ++-
drivers/net/bfin_mac.c | 5 +-
drivers/net/e1000/e1000.h | 2 +
drivers/net/e1000/e1000_main.c | 43 ++++++---------
drivers/net/e1000e/e1000.h | 1 +
drivers/net/e1000e/netdev.c | 57 ++++++++++----------
drivers/net/igb/igb_main.c | 4 +-
drivers/net/igbvf/netdev.c | 14 +++---
drivers/net/ixgb/ixgb_main.c | 10 ++--
drivers/net/ixgbe/ixgbe_main.c | 12 ++--
drivers/net/pcmcia/fmvj18x_cs.c | 1 +
drivers/net/phy/phy.c | 4 +-
drivers/net/phy/phy_device.c | 1 +
drivers/net/qlge/qlge_main.c | 15 +++---
drivers/net/s2io.c | 2 +-
drivers/net/sfc/mcdi.c | 7 ++-
drivers/net/sfc/mcdi.h | 1 +
drivers/net/sfc/mcdi_pcol.h | 4 +-
drivers/net/sfc/mtd.c | 5 +-
drivers/net/sfc/qt202x_phy.c | 6 --
drivers/net/sky2.c | 42 ++++++++++++---
drivers/net/tulip/tulip_core.c | 1 +
drivers/net/ucc_geth.c | 5 +-
drivers/net/virtio_net.c | 3 +-
drivers/net/wimax/i2400m/i2400m-usb.h | 2 +
drivers/net/wimax/i2400m/usb.c | 12 ++++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 5 ++
drivers/net/wireless/iwlwifi/iwl-devtrace.c | 26 +++++++++
drivers/net/wireless/iwlwifi/iwl-devtrace.h | 26 +++++++++
drivers/net/wireless/iwmc3200wifi/commands.c | 4 ++
drivers/net/wireless/iwmc3200wifi/commands.h | 1 +
drivers/net/wireless/p54/p54pci.c | 8 +++
drivers/net/wireless/zd1211rw/zd_usb.c | 1 +
drivers/serial/serial_cs.c | 1 +
include/linux/phy.h | 1 +
include/net/netns/xfrm.h | 6 ++
include/net/netrom.h | 2 +
include/net/xfrm.h | 4 +-
net/8021q/vlan_dev.c | 2 +-
net/appletalk/aarp.c | 2 +-
net/ax25/ax25_out.c | 6 ++
net/dccp/ccid.c | 18 ++-----
net/dccp/ccid.h | 2 +
net/dccp/probe.c | 3 +-
net/ipv4/inet_diag.c | 2 +-
net/ipv4/route.c | 2 +
net/ipv4/tcp_probe.c | 19 ++++---
net/ipv4/xfrm4_policy.c | 14 +++--
net/ipv6/xfrm6_policy.c | 25 +++++----
net/mac80211/cfg.c | 3 +
net/mac80211/rc80211_pid_algo.c | 2 +-
net/netrom/nr_route.c | 11 ++--
net/rose/rose_link.c | 8 +++
net/rose/rose_route.c | 5 ++
net/wireless/sme.c | 1 +
net/xfrm/xfrm_policy.c | 75 ++++++++++++++++++++++----
net/xfrm/xfrm_state.c | 6 +-
net/xfrm/xfrm_user.c | 14 +++--
60 files changed, 389 insertions(+), 193 deletions(-)
^ permalink raw reply
* Re: Netlink usage question (for bonding comm with userspace)
From: David Miller @ 2010-01-26 0:51 UTC (permalink / raw)
To: fubar; +Cc: netdev
In-Reply-To: <15914.1264466901@death.nxdomain.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Mon, 25 Jan 2010 16:48:21 -0800
> I could, for this project, use a netlink_kernel_create and
> socket(AF_NETLINK) pair to perform the communication (presumably adding
> a NETLINK_BONDING or the like to <linux/netlink.h>).
This is no longer done, so that we don't have an issue with
running out of netlink sub-protocol numbers.
Instead use generic netlink, the IDs are allocated dynamically
and looked up via text strings which provides a better scheme
for namespace allocation.
^ permalink raw reply
* Netlink usage question (for bonding comm with userspace)
From: Jay Vosburgh @ 2010-01-26 0:48 UTC (permalink / raw)
To: netdev
Could any netlink gurus comment on my questions? I'm hoping to
figure out the right way to do what I need without working up patches
that end up being excellent examples of the wrong way. I've looked
through the kernel, and it's almost a cases of too many choices (private
netlink, rtnetlink, connector, genetlink) to sort through.
Background: I'm working on a bonding mode that involves two-way
communication between bonding itself and a user-space daemon, and I'm
trying to determine the best way to utilize netlink for this project
with an eye towards forwards compatibility with future expansion (e.g.,
general bonding setup via netlink). For purposes of discussion, the
communication requires that bonding-specific requests, responses and
asynchronous events flow in both directions.
I could, for this project, use a netlink_kernel_create and
socket(AF_NETLINK) pair to perform the communication (presumably adding
a NETLINK_BONDING or the like to <linux/netlink.h>).
That, however, wouldn't dovetail with moving control of bonding
into iproute2 ("ip link add link bond0 type bond mode whatever"), and it
seems suboptimal to have two independent netlink gizmos in bonding. I'm
not planning to implement full bonding control via netlink at this time,
but I don't want to do anything that would cause difficulty for doing so
in the future.
I've done some prototyping with working through the existing
rtnetlink infrastructure, adding an RTNLGRP_BONDING, AF_BONDING, etc,
vaguely paralleling how the bridge code is architected. What's unclear
to me is how to insert the bonding-specific request / response message
types into the rtnetlink infrastructure, or, indeed, if this is simply
not the right way to go about this.
So, in summary:
For user / kernel communications via netlink: private socket,
add to rtnetlink API, or something else (connector, genetlink, ...)?
Is having private socket netlink and rtnetlink in the same
module a reasonable methodology?
If rtnetlink is suitable, basic "do this" or "don't do this"
thoughts? The various HOWTOs google finds for me concentrate on the
mechanisms, less so on interface selection / design.
Thoughts?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Tejun Heo @ 2010-01-26 0:48 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <20100126001901.GI5087@nowhere>
Hello, Frederic.
On 01/26/2010 09:19 AM, Frederic Weisbecker wrote:
> On Tue, Jan 26, 2010 at 12:22:14AM +0900, Tejun Heo wrote:
>> Add __percpu sparse annotations to hw_breakpoint.
>>
>> These annotations are to make sparse consider percpu variables to be
>> in a different address space and warn if accessed without going
>> through percpu accessors. This patch doesn't affect normal builds.
>>
>> per_cpu(nr_task_bp_pinned, cpu) is replaced with
>> &per_cpu(nr_task_bp_pinned[0], cpu). This is the same to the compiler
>> but allows per_cpu() macro to correctly drop __percpu designation for
>> the returned pointer.
>
> Ouch... It's unpleasant to see such workaround that messes up the
> code just to make sparse happy.
>
> I guess __percpu is an address_space attribute? Is there no
> way to force the address space change directly from the
> per_cpu() macro?
Yeah, per_cpu() macro does that but when things get a bit complicated
with static percpu arrays. In the above case, the variable is defined
as
static DEFINE_PER_CPU(unsigned int, nr_task_bp_pinned[HBP_NUM]);
which gets translated to
static __attribute__((noderef, address_space(3))) \
__attribute__((section(.data.percpu))) \
__typeof__(unsigned int) nr_task_bp_pinned[HBP_NUM];
The above tells sparse that the members of nr_task_bp_pinned array are
in address space 3 which is correct. The problematic dereference was
unsigned int *task_pinned = per_cpu(nr_task_bp_pinned, cpu)
per_cpu() macro changes the address space of the resulting address but
it does so assuming that the parameter it got passed is the one which
got declared to be in the percpu address space. It casts
nr_task_bp_pinned itself, which to the sparse isn't in the percpu
address space, to the kernel address space. So, the workaround is
basically to give per_cpu() macro the same thing that was defined.
This type of usage (define as array, dereference the array as address)
was the only place where I needed to work around to make address space
change explicit. There are two places which needed this and hwbreak
was one. The options were...
* Leave it alone. We can live with a few additional sparse warnings.
* Make the proposed change. It is slightly ugly but not cryptic or
difficult.
* Somehow teach per_cpu() macro or sparse how to handle the above
right.
I tried to improve per_cpu() macro but couldn't do it in any sane way.
Leaving it alone isn't too bad either but given that the workaround is
not horribly unreadable, I think it's best to use the slightly less
elegant form in the few places where they are needed.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCHSET] percpu: add __percpu sparse annotations
From: Tejun Heo @ 2010-01-26 0:30 UTC (permalink / raw)
To: Al Viro
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, davem, netdev, x86, mingo, fweisbec,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <20100125231411.GA19799@ZenIV.linux.org.uk>
Hello,
On 01/26/2010 08:14 AM, Al Viro wrote:
> Um. Where *is* the definition of __percpu? Presumably, that'd be
> something like __attribute__((noderef,address_space(4)) under ifdef
> __CHECKER__ and empty otherwise? If so, I'm fine with that patchset,
> provided that it does grow that #define and becomes self-contained...
Ah... sorry, I forgot about the base tree. The definition has been in
the percpu tree for some time now. The patchset is on top of the
following branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-next
and the series is available as git tree in the following branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git percpu-sparse-review
The definition is in include/linux/compiler.h.
# define __percpu __attribute__((noderef, address_space(3)))
which gets replaced by dummy def if !__CHECKER__.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Frederic Weisbecker @ 2010-01-26 0:19 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <1264432935-10453-8-git-send-email-tj@kernel.org>
On Tue, Jan 26, 2010 at 12:22:14AM +0900, Tejun Heo wrote:
> Add __percpu sparse annotations to hw_breakpoint.
>
> These annotations are to make sparse consider percpu variables to be
> in a different address space and warn if accessed without going
> through percpu accessors. This patch doesn't affect normal builds.
>
> per_cpu(nr_task_bp_pinned, cpu) is replaced with
> &per_cpu(nr_task_bp_pinned[0], cpu). This is the same to the compiler
> but allows per_cpu() macro to correctly drop __percpu designation for
> the returned pointer.
Ouch... It's unpleasant to see such workaround that messes up the
code just to make sparse happy.
I guess __percpu is an address_space attribute? Is there no
way to force the address space change directly from the
per_cpu() macro?
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] sfc: Use fixed-size buffers for MCDI NVRAM requests
From: David Miller @ 2010-01-25 23:50 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1264447852.2793.4.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 25 Jan 2010 19:30:52 +0000
> The low-level MCDI code always uses 32-bit MMIO operations, and
> callers must pad input and output buffers to multiples of 4 bytes.
> The MCDI NVRAM functions are not doing this. Also, their buffers are
> declared as variable-length arrays with no explicit maximum length.
>
> Switch to a fixed buffer size based on the chunk size used by the
> MTD driver (which is a multiple of 4).
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] sfc: Add workspace for GMAC bug workaround to MCDI MAC_STATS buffer
From: David Miller @ 2010-01-25 23:50 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1264447680.2793.0.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 25 Jan 2010 19:28:00 +0000
> From: Guido Barzini <gbarzini@solarflare.com>
>
> Due to a hardware bug in the SFC9000 family, the firmware must
> transfer raw GMAC statistics to host memory before aggregating them
> into the cooked (speed-independent) MAC statistics. Extend the stats
> buffer to support this.
>
> The length of the buffer is explicit in the MAC_STATS command, so this
> change is backward-compatible on both sides.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp_probe: avoid modulus operation and wrap fix
From: David Miller @ 2010-01-25 23:48 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100125083006.47fd2f7e@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 25 Jan 2010 08:30:06 -0800
> On Sun, 24 Jan 2010 22:41:22 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Sun, 24 Jan 2010 21:50:01 -0800
>>
>> > @@ -75,12 +75,12 @@ static struct {
>> >
>> > static inline int tcp_probe_used(void)
>> > {
>> > - return (tcp_probe.head - tcp_probe.tail) % bufsize;
>> > + return (tcp_probe.head - tcp_probe.tail) & (bufsize - 1);
>> > }
>> >
>> > static inline int tcp_probe_avail(void)
>> > {
>> > - return bufsize - tcp_probe_used();
>> > + return bufsize - tcp_probe_used() - 1;
>> > }
>> >
>> > /*
>>
>> Hmmm... When the ring is full head==tail, which means
>> tcp_probe_used() returns 0. Which would now make tcp_probe_avail()
>> return "bufsize - 0 - 1".
>>
>> Is that right?
>
> Yes. in this ring; empty is head == tail, and full needs to
> be tail == head - 1.
Ok, that makes sense, thanks for explaining.
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH] qlge: Only free resources if they were allocated
From: David Miller @ 2010-01-25 23:47 UTC (permalink / raw)
To: leitao; +Cc: ron.mercer, netdev
In-Reply-To: <1264436252-3740-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Mon, 25 Jan 2010 10:17:32 -0600
> Currently qlge tries to release regions even if they were not allocated.
> This causes messages like the following in the kernel log
>
> Trying to free nonexistent resource <00000000006af400-00000000006af4ff>
> Trying to free nonexistent resource <00003c04ff9f4000-00003c04ff9f7fff>
> Trying to free nonexistent resource <00003c04ffc00000-00003c04ffcfffff>
>
> This patch fixes the goto logic in order to not release the resources
> if they were not allocated.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCHSET] percpu: add __percpu sparse annotations
From: Al Viro @ 2010-01-25 23:14 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, davem, netdev, x86, mingo, fweisbec,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <1264432935-10453-1-git-send-email-tj@kernel.org>
On Tue, Jan 26, 2010 at 12:22:07AM +0900, Tejun Heo wrote:
> This patchset adds __percpu sparse annotations to all percpu users
> covered by x86_64 allmodconfig. __percpu annotation teaches sparse
> that percpu variables live in a separate address space and can't be
> accessed directly without going through percpu accessors. This allows
> detection of most percpu access mistakes involving both static and
> dyanmic percpu variables.
>
> This patchset contains the following eight patches.
>
> 0001-percpu-add-__percpu-sparse-annotations-to-core-kerne.patch
> 0002-percpu-add-__percpu-sparse-annotations-to-fs.patch
> 0003-percpu-add-__percpu-sparse-annotations-to-net.patch
> 0004-percpu-add-__percpu-sparse-annotations-to-net-driver.patch
> 0005-percpu-add-__percpu-sparse-annotations-to-x86.patch
> 0006-percpu-add-__percpu-sparse-annotations-to-trace.patch
> 0007-percpu-add-__percpu-sparse-annotations-to-hw_breakpo.patch
> 0008-percpu-add-__percpu-sparse-annotations-to-what-s-lef.patch
>
> As these annotations are for sparse, none of the above patches affects
> normal kernel build and most of the conversions are straight-forward
> and trivial. There are a few places where the conversion isn't
> completely straight-forward (but still fairly trivial). Those are
> mentioned in each patch description.
>
> I can route the patch through percpu and conflict resolution, if
> necessary, wouldn't be difficult at all for these changes. If anyone
> wants to route one of these patches through a different tree, please
> let me know. All that's necessary would be adding dummy __percpu
> definition to the patch.
>
> If nobody objects, I'll push these into percpu tree in three or four
> days.
Um. Where *is* the definition of __percpu? Presumably, that'd be
something like __attribute__((noderef,address_space(4)) under ifdef
__CHECKER__ and empty otherwise? If so, I'm fine with that patchset,
provided that it does grow that #define and becomes self-contained...
^ permalink raw reply
* Re: [PATCH 1/8] percpu: add __percpu sparse annotations to core kernel subsystems
From: Christoph Lameter @ 2010-01-25 21:58 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
fweisbec, dan.j.williams, borislav.petkov, ying.huang, lenb,
neilb, linux-mm, Dipankar Sarma, Paul E. McKenney, Peter Zijlstra
In-Reply-To: <1264432935-10453-2-git-send-email-tj@kernel.org>
Reviewed-by: Christoph Lameter <cl@linux-foundation.org>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] IPv6: Update documentation for better built-in help with params
From: Randy Dunlap @ 2010-01-25 21:43 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, greg, nhorman, netdev
In-Reply-To: <20100125.133411.191160829.davem@davemloft.net>
On Mon, 25 Jan 2010 13:34:11 -0800 (PST) David Miller wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> Date: Mon, 25 Jan 2010 13:31:33 -0800
>
> > On Mon, 25 Jan 2010 13:21:42 -0800 (PST) David Miller wrote:
> >
> >> From: Brian Haley <brian.haley@hp.com>
> >> Date: Mon, 25 Jan 2010 12:28:15 -0500
> >>
> >> > I guess Documentation/kernel-parameters.txt is where such things
> >> > live, can I send you a patch for that or does it need to go
> >> > through someone else?
> >>
> >> I think lkml is a suitable place to submit something like
> >> that.
> >> --
> >
> > Sure, but if it's networking parameters, you (David) could still merge it...
>
> It's not about networking parameters.
OK, I didn't see the patch itself, sorry.
> It's about adding a generic mention somewhere central that you can set
> "module parameters" on the kernel command line when a module is built
> statically into the kernel.
Maybe like this, from that same file:
Module parameters for modules that are built into the kernel image
are specified on the kernel command line with the module name plus
'.' plus parameter name, with '=' and value if appropriate, such as:
usbcore.blinkenlights=1
I'll search for the patch...
---
~Randy
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: use helpers to access uc list V2
From: David Miller @ 2010-01-25 21:36 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100125210543.GB6746@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Mon, 25 Jan 2010 22:05:45 +0100
> This patch introduces three macros to work with uc list from net drivers.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
This looks better, applied, thanks!
^ 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