linux-netdev mailing list

FromSubjectsort iconDate
Michael Marineau Jan 1, 4:12 pm 2009
Jason
Happy New Year 2009!
Jason sent you a New Year ecard. It is waiting for you at our card site, go ahead and see it! http://cardnewyear.com/?cardid=ce4c0a19ed1c0d89a25 Brought to you by Christmas-Egreetings.Com! --
Jan 1, 2:46 pm 2009
Laura
Laura has sent you an E-Card!
Laura posted a New Year ECard. You may pick-up your card by visiting our home page at: http://superyearcard.com/?code=26b57313d063a11e Enjoy! --
Jan 1, 2:09 pm 2009
Eric Sesterhenn
[BUG] icmpv6fuzz creates bad paging request
Hi, running "icmpv6fuzz -r 2187" gives me the following oops with current -git [ 4320.851654] BUG: unable to handle kernel paging request at c9527000 [ 4320.851749] IP: [<c04e5668>] __copy_from_user_ll+0x8c/0xd8 [ 4320.851898] *pde = 0001f067 *pte = 09527160 [ 4320.851977] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC [ 4320.852011] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource [ 4320.852011] Modules linked in: [ 4320.852011] [ 4320.852011] Pid: 5065, comm: ...
Jan 1, 1:13 pm 2009
Ilpo Järvinen Jan 1, 7:28 am 2009
Alexander Beregalov Jan 1, 7:50 am 2009
Ilpo Järvinen
Re: 2.6.28-03117: WARNING: at net/ipv4/tcp_input.c:2504 ...
On Thu, 1 Jan 2009, Alexander Beregalov wrote: > 2009/1/1 Ilpo J
Jan 1, 12:30 pm 2009
Alexander Beregalov
2.6.28-03117: WARNING: at net/ipv4/tcp_input.c:2504 tcp_ ...
WARNING: at net/ipv4/tcp_input.c:2504 tcp_mark_head_lost+0x1df/0x200() Modules linked in: w83627hf hwmon_vid i2c_nforce2 Pid: 0, comm: swapper Not tainted 2.6.28-03117-g6a94cb7 #1 Call Trace: [<c040f321>] ? printk+0x18/0x1f [<c0128354>] warn_on_slowpath+0x54/0x80 [<c014bd25>] ? __lock_acquire+0x2c5/0x1000 [<c014b74c>] ? trace_hardirqs_on_caller+0x7c/0x160 [<c0399041>] ? dev_queue_xmit+0xe1/0x5d0 [<c014bd25>] ? __lock_acquire+0x2c5/0x1000 [<c014862b>] ? ...
Jan 1, 5:41 am 2009
Gerrit Renker
[Patch 1/1] tun: signedness warning
tun: Eliminate sparse signedness warning register_pernet_gen_device() expects 'int*', found via sparse. CHECK drivers/net/tun.c drivers/net/tun.c:1245:36: warning: incorrect type in argument 1 (different signedness) drivers/net/tun.c:1245:36: expected int *id drivers/net/tun.c:1245:36: got unsigned int static [toplevel] *<noident> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> --- tun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- ...
Jan 1, 3:55 am 2009
Andi Kleen
hang after "registering protocol family 2" in linux-next
FYI, I booted today's linux-next and I got a hang somewhere in inet_init (according to initcalL_debug) after Registering protocol family 2 Haven't investigated further. -Andi -- ak@linux.intel.com --
Dec 31, 9:33 pm 2008
Mark Smith Dec 31, 5:24 pm 2008
Christoph Lameter
Re: [RFC] cpualloc: improvements to per-cpu allocation
Ok so this is going to be merged for 2.6.29? Its a good cleanup and a step forward to our goals. --
Dec 31, 6:03 pm 2008
Rusty Russell
Re: [RFC] cpualloc: improvements to per-cpu allocation
Yes, doing an audit of actual and potential local_t-like users is on my todo list (after the merge frenzy). I like your variable types, but it make a trival implementation difficult/impossible, which is optimal for sparc64 and similar to what SNMP counters currently use. We might not Yes, and this is a hack. Eventually we want to grow the percpu area, but that may not be done for 2.6.30. Most allocations are tiny, so we'd need thousands to overflow. Those are the kind of people who do ...
Dec 31, 5:26 pm 2008
Rusty Russell
Re: [RFC] cpualloc: improvements to per-cpu allocation
I'm on the fence, but you've convinced me. I'll put this in linux-next, and if there's no damage, I'll push to Linus. The actual conversions I'll send via the maintainers though. These patches have been around for a while, and though they've been polished a little more in the last week or so the changes were mainly cosmetic. Thanks, Rusty. --
Dec 31, 8:12 pm 2008
Gerrit Renker
Re: [RFC] [Patch 2/4] dccp: Lockless use of CCID blocks
| | > + for (i = 0; i < ARRAY_SIZE(ccids); i++) | | > + if (ccids[i]->ccid_id == id) | | > + return ccids[i]; | | > + return NULL; | | | | Why the we searching? Can't we just do: | | | | { | | if (id > ARRAY_SIZE(ccids) - 2) | | return NULL; | | return ccids[id - 2]; | | } | | | Agree 100%, I don't like the routine myself and have been thinking about | how to rewrite it. Current idea is to go back to the original and use | | static struct ccid_operations *ccids[CCIDS_MAX] = ...
Jan 1, 3:49 am 2009
previous daytodaynext day
December 31, 2008January 1, 2009January 2, 2009