| From | Subject | Date |
|---|---|---|
| Michael Marineau | [PATCH] fix for initial link state in 2.6.28
[Empty message]
| 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 | Re: 2.6.28-03117: WARNING: at net/ipv4/tcp_input.c:2504 ...
...snip...
Can you reproduce it?
--
i.
--
| Jan 1, 7:28 am 2009 |
| Alexander Beregalov | Re: 2.6.28-03117: WARNING: at net/ipv4/tcp_input.c:2504 ...
No, I do not know how to reproduce it.
| 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 | Correct use of NET_RX_SUCCESS, NET_RX_DROP or NET_RX_BAD?
[Empty message]
| 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 day | today | next day |
|---|---|---|
| December 31, 2008 | January 1, 2009 | January 2, 2009 |
