* Re: linux-next: v4l-dvb tree
From: Mauro Carvalho Chehab @ 2008-12-16 19:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20081216165734.98535728.sfr@canb.auug.org.au>
On Tue, 16 Dec 2008 16:57:34 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Mauro,
>
> The v4l-dvb tree has not been in linux-next since Nov 25 due to build
> problems. The tree I am fetching
> (git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git#master)
> has not been updated since Dec 2. (The current head of branch commit is
> 6e65a8a8f16144b0f092915c9f89c2beb957e14b "Merge branch 'next'
> of ../devel")
>
> Is there any progress in this?
I've just updated it today. Please let me know if you have any troubles.
Cheers,
Mauro
^ permalink raw reply
* Re: linux-next: scsi tree build warnings
From: James Smart @ 2008-12-16 18:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: James Bottomley, linux-next@vger.kernel.org
In-Reply-To: <20081212103057.714c6627.sfr@canb.auug.org.au>
fyi - patch for this was posted:
http://marc.info/?l=linux-scsi&m=122944234826143&w=2
-- james s
Stephen Rothwell wrote:
> Hi James,
>
> On Thu, 11 Dec 2008 09:35:48 -0500 James Smart <James.Smart@Emulex.Com> wrote:
>> we're cleaning this up now...
>
> Thanks.
>
^ permalink raw reply
* Re: linux-next: lblnet tree build failure
From: Paul Moore @ 2008-12-16 16:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Casey Schaufler
In-Reply-To: <20081216191419.43ae28af.sfr@canb.auug.org.au>
On Tuesday 16 December 2008 3:14:19 am Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> security/smack/smackfs.c: In function 'smk_netlabel_audit_set':
> security/smack/smackfs.c:118: error: 'struct task_struct' has no
> member named 'security'
>
> Caused by commit 2d22b59c5401e60c04e6258a245b8a99d103f55b ("smack:
> Add support for unlabeled network hosts and networks") interacting
> with commit b6dff3ec5e116e3af6f537d4caedcad6b9e5082a ("CRED: Separate
> task security context from task_struct") from the security-testing
> tree. This latter commit is also in the lblnet tree (since it merges
> the security testing tree).
>
> I have dropped the lblnet tree for today.
My mistake, it should be fixed now.
When I was updating the lblnet-2.6_next tree yesterday I made a mistake
and didn't refresh Casey's patch completely when merging it against the
security-testing tree as a result some of the necessary merges didn't
make it out of my local directory. Sorry guys.
--
paul moore
linux @ hp
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Mike Travis @ 2008-12-16 16:03 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Rusty Russell, linux-next, Yinghai Lu, Ingo Molnar
In-Reply-To: <20081216170940.3c74d4d0.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Mike,
>
> On Mon, 15 Dec 2008 22:02:25 -0800 Mike Travis <travis@sgi.com> wrote:
>> Yes, I did finally figure that out. Thanks for rebasing the part that Ingo needed
>> so maybe the rest can be pushed. There was a problem when the 'for-ingo' tree was
>> merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
>> x86 only patch. I wasn't sure of what else to do.
>
> You could have fixed them up as part of the actual merge commit. If each
> tree was correct on it own, then the merge is the place for such
> resolutions.
>
Thanks, I will try that next time.
Ingo - if you need a small patch to make the post-merge tree buildable, let me know.
I can extract that from the 1st patch (that modifies the smp api).
Thanks,
Mike
^ permalink raw reply
* Re: linux-next: cpu_alloc tree
From: Christoph Lameter @ 2008-12-16 14:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Rusty Russell
In-Reply-To: <20081216170521.8453f7e4.sfr@canb.auug.org.au>
On Tue, 16 Dec 2008, Stephen Rothwell wrote:
> The cpu_alloc tree has not been included in linux-next since Nov 21. Have
> your discussions with Rusty come to any conclusions? Should I remove
> this tree permanently or will it be updated?
I thought Rusty would be doing something. If not then I will bring things
up to snuff.
^ permalink raw reply
* Re: [BUG] linux-next: 20081209 - kernel bug at __rcu_process_callbacks, while booting up
From: Jens Axboe @ 2008-12-16 14:37 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Paul E. McKenney, Stephen Rothwell, linux-next, LKML, dm-devel,
tglx, mel
In-Reply-To: <20081216143001.GA4365@linux.vnet.ibm.com>
On Tue, Dec 16 2008, Kamalesh Babulal wrote:
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-12 14:16:11]:
>
> > On Sat, Dec 13, 2008 at 01:10:26AM +0530, Kamalesh Babulal wrote:
> > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-10 10:33:02]:
> > >
> > > > On Wed, Dec 10, 2008 at 11:39:36PM +0530, Kamalesh Babulal wrote:
> > > > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-10 09:53:38]:
> > > > >
> > > > > > On Wed, Dec 10, 2008 at 10:00:07PM +0530, Kamalesh Babulal wrote:
> > > > > > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-10 06:54:14]:
> > > > > > >
> > > > > > > > On Wed, Dec 10, 2008 at 05:27:21PM +0530, Kamalesh Babulal wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Kernel bug is hit while booting up the next-20081208/09 kernels over
> > > > > > > > > the x86_64 box. The IP is pointing to 0x0 and its stuck at
> > > > > > > > > __rcu_process_callbacks.
> > > > > > > >
> > > > > > > > Kernel config?
> > > > > > > >
> > > > > > > > Thanx, Paul
> > > > > > > >
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > I have attached the kernel config file.
> > > > > >
> > > > > > Hello, Kamalesh,
> > > > > >
> > > > > > No significant recent changes in this area. Is this consistent?
> > > > > > Any chance of "git bisect"?
> > > > > >
> > > > > > Thanx, Paul
> > > > > >
> > > > > Hi Paul,
> > > > >
> > > > > I tried reproducing it for three times and I was successfull in reproducing it thrice.
> > > > > I have already started the git bisect, will update the results soon.
> > > >
> > > > Very good, looking forward to seeing the result!
> > > >
> > > > Thanx, Paul
> > > >
> > > Hi Paul,
> > >
> > > After a Complete round of git bisect, I was not able to reproduce the oops,
> > > but when I tried again with complete next-20081209 patch, I am getting
> > > different warning message altogether this time
> >
> > Might be that the two oopses are different manifestations of the same
> > underlying problem, right?
> >
> > Thanx, Paul
> >
> Hi Paul,
>
> Your were right, those were the manifestation of the same
> problem. Adding to it another calltrace was commonly visible
> during the git-bisect.
Did you try with a newer version? Should be fixed since last week.
--
Jens Axboe
^ permalink raw reply
* Re: [BUG] linux-next: 20081209 - kernel bug at __rcu_process_callbacks, while booting up
From: Kamalesh Babulal @ 2008-12-16 14:30 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Stephen Rothwell, linux-next, LKML, dm-devel, tglx, mel,
jens.axboe
In-Reply-To: <20081212221611.GG6950@linux.vnet.ibm.com>
* Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-12 14:16:11]:
> On Sat, Dec 13, 2008 at 01:10:26AM +0530, Kamalesh Babulal wrote:
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-10 10:33:02]:
> >
> > > On Wed, Dec 10, 2008 at 11:39:36PM +0530, Kamalesh Babulal wrote:
> > > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-10 09:53:38]:
> > > >
> > > > > On Wed, Dec 10, 2008 at 10:00:07PM +0530, Kamalesh Babulal wrote:
> > > > > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [2008-12-10 06:54:14]:
> > > > > >
> > > > > > > On Wed, Dec 10, 2008 at 05:27:21PM +0530, Kamalesh Babulal wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Kernel bug is hit while booting up the next-20081208/09 kernels over
> > > > > > > > the x86_64 box. The IP is pointing to 0x0 and its stuck at
> > > > > > > > __rcu_process_callbacks.
> > > > > > >
> > > > > > > Kernel config?
> > > > > > >
> > > > > > > Thanx, Paul
> > > > > > >
> > > > > > Hi Paul,
> > > > > >
> > > > > > I have attached the kernel config file.
> > > > >
> > > > > Hello, Kamalesh,
> > > > >
> > > > > No significant recent changes in this area. Is this consistent?
> > > > > Any chance of "git bisect"?
> > > > >
> > > > > Thanx, Paul
> > > > >
> > > > Hi Paul,
> > > >
> > > > I tried reproducing it for three times and I was successfull in reproducing it thrice.
> > > > I have already started the git bisect, will update the results soon.
> > >
> > > Very good, looking forward to seeing the result!
> > >
> > > Thanx, Paul
> > >
> > Hi Paul,
> >
> > After a Complete round of git bisect, I was not able to reproduce the oops,
> > but when I tried again with complete next-20081209 patch, I am getting
> > different warning message altogether this time
>
> Might be that the two oopses are different manifestations of the same
> underlying problem, right?
>
> Thanx, Paul
>
Hi Paul,
Your were right, those were the manifestation of the same problem. Adding to it
another calltrace was commonly visible during the git-bisect.
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
INFO: task init:1 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
init D ffffffff805497a0 0 1 0
ffff88003fa31648 0000000000000086 ffff88003fa315c8 ffffffff80342d0f
ffff88003fa315c8 ffff88003fa2f850 ffff88003fad3310 ffff88003fa2fa90
000000033fa31628 00000000fffef3ea ffff88003fa315f8 ffff88003e489400
Call Trace:
[<ffffffff80342d0f>] ? generic_unplug_device+0x35/0x39
[<ffffffff805348a6>] ? _read_unlock+0x9/0xb
[<ffffffff8053333c>] io_schedule+0x28/0x33
[<ffffffff802b69b5>] sync_buffer+0x3e/0x42
[<ffffffff80533598>] __wait_on_bit+0x45/0x77
[<ffffffff802b6977>] ? sync_buffer+0x0/0x42
[<ffffffff802b6977>] ? sync_buffer+0x0/0x42
[<ffffffff80533638>] out_of_line_wait_on_bit+0x6e/0x7b
[<ffffffff8024a327>] ? wake_bit_function+0x0/0x2a
[<ffffffff802b6901>] __wait_on_buffer+0x1f/0x21
[<ffffffff802b8108>] __bread+0x9a/0xb0
[<ffffffff802eb558>] ext3_get_branch+0x6b/0xe0
[<ffffffff802eb802>] ext3_get_blocks_handle+0x9e/0x903
[<ffffffff8033f8aa>] ? elv_rq_merge_ok+0x8e/0x9c
[<ffffffff8033ff29>] ? elv_rqhash_reposition+0x3f/0x41
[<ffffffff8033ffb5>] ? elv_merged_request+0x39/0x46
[<ffffffff805349c3>] ? _spin_unlock_irq+0x9/0xc
[<ffffffff803430bd>] ? __make_request+0x388/0x399
[<ffffffff802ec2f0>] ext3_get_block+0xc4/0x102
[<ffffffff80343182>] ? submit_bio+0xb4/0xbe
[<ffffffff802bd80d>] do_mpage_readpage+0x18e/0x4d0
[<ffffffff805349c3>] ? _spin_unlock_irq+0x9/0xc
[<ffffffff8026bbfd>] ? add_to_page_cache_locked+0x98/0xa8
[<ffffffff802ec22c>] ? ext3_get_block+0x0/0x102
[<ffffffff802bdcb9>] mpage_readpages+0xa6/0xe6
[<ffffffff802ec22c>] ? ext3_get_block+0x0/0x102
[<ffffffff802717b2>] ? __alloc_pages_internal+0xe7/0x3b9
[<ffffffff802eb6e8>] ext3_readpages+0x1a/0x1c
[<ffffffff802733aa>] __do_page_cache_readahead+0xf7/0x189
[<ffffffff80273867>] do_page_cache_readahead+0x55/0x62
[<ffffffff8026d76f>] filemap_fault+0x163/0x340
[<ffffffff8027a224>] __do_fault+0x50/0x3b0
[<ffffffff8027bd10>] handle_mm_fault+0x1c0/0x6a2
[<ffffffff80536c4e>] do_page_fault+0x421/0x7cd
[<ffffffff80534b59>] error_exit+0x0/0x51
[<ffffffff80354acd>] ? copy_user_generic_string+0x2d/0x40
[<ffffffff8032bea6>] ? sel_write_load+0x97/0x664
[<ffffffff8032a2c2>] ? selinux_file_permission+0x59/0x104
[<ffffffff80321639>] ? security_file_permission+0x11/0x13
[<ffffffff80298cc0>] vfs_write+0xae/0x137
[<ffffffff80299169>] sys_write+0x47/0x6f
[<ffffffff8020be6b>] system_call_fastpath+0x16/0x1b
Reverting the commit below, the next-20081209 kernel bootup without the kernel oops.
commit 30e62ce1ce96ff01d4826b0e476941169c94041d
Author: Jens Axboe <jens.axboe@oracle.com>
Date: Fri Dec 5 13:58:19 2008 +0100
bio: add experimental support for inlining a number of bio_vecs inside the bio
> > INIT: version 2.86 booting
> > BUG: unable to handle kernel paging request at ffffffff0000000a
> > IP: [<ffffffff8033f4e4>] blk_recalc_rq_sectors+0x5c/0xd9
> > PGD 203067 PUD 0
> > Oops: 0000 [#1] SMP
> > last sysfs file: /sys/block/dm-3/removable
> > CPU 3
> > Modules linked in:
> > Pid: 0, comm: swapper Not tainted 2.6.28-rc7-next-20081209-autokern1 #1
> > RIP: 0010:[<ffffffff8033f4e4>] [<ffffffff8033f4e4>] blk_recalc_rq_sectors+0x5c/0xd9
> > RSP: 0018:ffff88003fae3e08 EFLAGS: 00010256
> > RAX: 0000000000000000 RBX: ffff88003e970338 RCX: ffff88000100b018
> > RDX: ffffffff00000002 RSI: 0000000000000008 RDI: ffff88003e970338
> > RBP: ffff88003e970338 R08: ffff88003e49d7c0 R09: ffff8800010472b0
> > R10: 0000000000000000 R11: 0000000000001000 R12: ffffe20000dfe080
> > R13: 0000000000000000 R14: 0000000000000008 R15: 0000000000000000
> > FS: 00007f149c33e6f0(0000) GS:ffff88003fa56840(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: ffffffff0000000a CR3: 000000003e4a2000 CR4: 00000000000006e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process swapper (pid: 0, threadinfo ffff88003fada000, task ffff88003fad72b0)
> > Stack:
> > 0000000000000000 ffffffff8033b3f5 0000000000000fe0 ffff88003e970338
> > 0000000000000000 0000000000000000 0000000000000000 ffff88003e970338
> > ffff88003eae2180 ffffffff8033b42d 0000000000000000 ffff88003e970338
> > Call Trace:
> > <IRQ> <0> [<ffffffff8033b3f5>] ? __end_that_request_first+0x231/0x24e
> > [<ffffffff8033b42d>] ? end_that_request_data+0x1b/0x4c
> > [<ffffffff8033bba7>] ? blk_end_io+0x1c/0x76
> > [<ffffffff803f6f61>] ? scsi_io_completion+0x1bc/0x452
> > [<ffffffff8033f9e2>] ? blk_done_softirq+0x5c/0x6a
> > [<ffffffff8023b895>] ? __do_softirq+0x76/0x136
> > [<ffffffff8021f88e>] ? ack_apic_level+0x66/0xe3
> > [<ffffffff8020d03c>] ? call_softirq+0x1c/0x28
> > [<ffffffff8020e091>] ? do_softirq+0x2c/0x6c
> > [<ffffffff8020e193>] ? do_IRQ+0xc2/0xdf
> > [<ffffffff8020c913>] ? ret_from_intr+0x0/0xa
> > <EOI> <0>Code: 8b 43 60 48 39 43 58 77 7f 48 89 53 68 48 8b 93 80 00 00 00 48 89 43 58 66 83 7a 28 00 74 12 0f b7 42 2a 48 8b 52 48 48 c1 e0 04 <8b> 44 10 08 eb 03 8b 42 30 48 8b 93 80 00 00 00 c1 e8 09 89 43
> > RIP [<ffffffff8033f4e4>] blk_recalc_rq_sectors+0x5c/0xd9
> > RSP <ffff88003fae3e08>
> > CR2: ffffffff0000000a
> > ---[ end trace 38c705e1b1fe7ae3 ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Pid: 0, comm: swapper Tainted: G D 2.6.28-rc7-next-20081209-autokern1 #1
> > Call Trace:
> > <IRQ> [<ffffffff80236e81>] panic+0x86/0x144
> > [<ffffffff8020e751>] show_registers+0x21d/0x228
> > [<ffffffff803b0511>] do_unblank_screen+0x2c/0x12c
> > [<ffffffff805207fa>] oops_end+0xa0/0xad
> > [<ffffffff80522010>] do_page_fault+0x748/0x801
> > [<ffffffff8022b44a>] __wake_up_common+0x3f/0x71
> > [<ffffffff8051fdff>] page_fault+0x1f/0x30
> > [<ffffffff8033f4e4>] blk_recalc_rq_sectors+0x5c/0xd9
> > [<ffffffff8033b3f5>] __end_that_request_first+0x231/0x24e
> > [<ffffffff8033b42d>] end_that_request_data+0x1b/0x4c
> > [<ffffffff8033bba7>] blk_end_io+0x1c/0x76
> > [<ffffffff803f6f61>] scsi_io_completion+0x1bc/0x452
> > [<ffffffff8033f9e2>] blk_done_softirq+0x5c/0x6a
> > [<ffffffff8023b895>] __do_softirq+0x76/0x136
> > [<ffffffff8021f88e>] ack_apic_level+0x66/0xe3
> > [<ffffffff8020d03c>] call_softirq+0x1c/0x28
> > [<ffffffff8020e091>] do_softirq+0x2c/0x6c
> > [<ffffffff8020e193>] do_IRQ+0xc2/0xdf
> > [<ffffffff8020c913>] ret_from_intr+0x0/0xa
> > <EOI> <4>------------[ cut here ]------------
> > WARNING: at kernel/smp.c:293 smp_call_function_many+0x37/0x220()
> > Hardware name: IBM eServer BladeCenter LS20 -[885055U]-
> > Modules linked in:
> > Pid: 0, comm: swapper Tainted: G D 2.6.28-rc7-next-20081209-autokern1 #1
> > Call Trace:
> > <IRQ> [<ffffffff80236dd4>] warn_slowpath+0xd8/0xf5
> > [<ffffffff8020c913>] ret_from_intr+0x0/0xa
> > [<ffffffff8020c913>] ret_from_intr+0x0/0xa
> > [<ffffffff8020c913>] ret_from_intr+0x0/0xa
> > [<ffffffff8020c913>] ret_from_intr+0x0/0xa
> > [<ffffffff80237a22>] printk+0x4e/0x56
> > [<ffffffff8020f1b9>] print_trace_address+0x1d/0x2d
> > [<ffffffff80253a01>] smp_call_function_many+0x37/0x220
> > [<ffffffff8020e525>] dump_trace+0x223/0x232
> > [<ffffffff8020f1b9>] print_trace_address+0x1d/0x2d
> > [<ffffffff80253c0a>] smp_call_function+0x20/0x24
> > [<ffffffff8021ccc1>] native_smp_send_stop+0x1a/0x26
> > [<ffffffff80236e95>] panic+0x9a/0x144
> > [<ffffffff8020e751>] show_registers+0x21d/0x228
> > [<ffffffff803b0511>] do_unblank_screen+0x2c/0x12c
> > [<ffffffff805207fa>] oops_end+0xa0/0xad
> > [<ffffffff80522010>] do_page_fault+0x748/0x801
> > [<ffffffff8022b44a>] __wake_up_common+0x3f/0x71
> > [<ffffffff8051fdff>] page_fault+0x1f/0x30
> > [<ffffffff8033f4e4>] blk_recalc_rq_sectors+0x5c/0xd9
> > [<ffffffff8033b3f5>] __end_that_request_first+0x231/0x24e
> > [<ffffffff8033b42d>] end_that_request_data+0x1b/0x4c
> > [<ffffffff8033bba7>] blk_end_io+0x1c/0x76
> > [<ffffffff803f6f61>] scsi_io_completion+0x1bc/0x452
> > [<ffffffff8033f9e2>] blk_done_softirq+0x5c/0x6a
> > [<ffffffff8023b895>] __do_softirq+0x76/0x136
> > [<ffffffff8021f88e>] ack_apic_level+0x66/0xe3
> > [<ffffffff8020d03c>] call_softirq+0x1c/0x28
> > [<ffffffff8020e091>] do_softirq+0x2c/0x6c
> > [<ffffffff8020e193>] do_IRQ+0xc2/0xdf
> > [<ffffffff8020c913>] ret_from_intr+0x0/0xa
> > <EOI> <4>---[ end trace 38c705e1b1fe7ae3 ]---
> >
> >
> > > > > > > > Activating logical volumes
> > > > > > > > 4 logical volume(s) in volume group "VolGroup00"BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> > > > > > > > IP: [<0000000000000000>] 0x0
> > > > > > > > PGD 3e8ad067 PUD 3e8ac067 PMD 0
> > > > > > > > Oops: 0010 [#1] SMP
> > > > > > > > last sysfs file: /sys/block/dm-1/removable
> > > > > > > > CPU 3
> > > > > > > > Modules linked in:
> > > > > > > > Pid: 0, comm: swapper Not tainted 2.6.28-rc7-next-20081209-autotest #1
> > > > > > > > RIP: 0010:[<0000000000000000>] [<0000000000000000>] 0x0
> > > > > > > > RSP: 0018:ffff88003fa73ef0 EFLAGS: 00010286
> > > > > > > > RAX: ffff88003eae0500 RBX: ffff880001047040 RCX: ffffffff80268f66
> > > > > > > > RDX: 0000000000000000 RSI: ffffe20000fab800 RDI: ffff88003eae0500
> > > > > > > > RBP: 0000000000000000 R08: ffff880001047040 R09: ffffffff80853950
> > > > > > > > R10: 0000000000000038 R11: ffffffff8032222d R12: 0000000000000005
> > > > > > > > R13: 0000000000000038 R14: 0000000000000009 R15: 0000000000000018
> > > > > > > > FS: 000000000066d870(0000) GS:ffff88003f803f00(0000) knlGS:0000000000000000
> > > > > > > > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > > > > > > > CR2: 0000000000000000 CR3: 000000003e8a9000 CR4: 00000000000006e0
> > > > > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > > > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > > > > > Process swapper (pid: 0, threadinfo ffff88003fa64000, task ffff88003f9dde00)
> > > > > > > > Stack:
> > > > > > > > ffffffff80268f66 ffff88003fa73ef8 0000000000000100 0000000000000001
> > > > > > > > ffffffff807400b8 0000000000000038 ffffffff80269001 0000000000000018
> > > > > > > > ffffffff8023b891 ffffffff8020e79e 0000000000000046 ffff88003fa73f80
> > > > > > > > Call Trace:
> > > > > > > > <IRQ> <0> [<ffffffff80268f66>] __rcu_process_callbacks+0x14e/0x1c3
> > > > > > > > [<ffffffff80269001>] rcu_process_callbacks+0x26/0x4a
> > > > > > > > [<ffffffff8023b891>] __do_softirq+0x76/0x136
> > > > > > > > [<ffffffff8020e79e>] profile_pc+0x21/0x5b
> > > > > > > > [<ffffffff8020d03c>] call_softirq+0x1c/0x28
> > > > > > > > [<ffffffff8020e091>] do_softirq+0x2c/0x6c
> > > > > > > > [<ffffffff8021e018>] smp_apic_timer_interrupt+0x93/0xac
> > > > > > > > [<ffffffff8020ca73>] apic_timer_interrupt+0x13/0x20
> > > > > > > > <EOI> <0>Code: Bad RIP value.
> > > > > > > > RIP [<0000000000000000>] 0x0
> > > > > > > > RSP <ffff88003fa73ef0>
> > > > > > > > CR2: 0000000000000000
> > > > > > > > ---[ end trace 69ecde41a682e571 ]---
> > > > > > > > Kernel panic - not syncing: Fatal exception in interrupt
> > > > > > > > Pid: 0, comm: swapper Tainted: G D 2.6.28-rc7-next-20081209-autotest #1
> > > > > > > > Call Trace:
> > > > > > > > Mounting root fi <IRQ> lesystem.
> > > > > > > > [<ffffffff80236e7d>] panic+0x86/0x144
> > > > > > > > [<ffffffff8020ca73>] apic_timer_interrupt+0x13/0x20
> > > > > > > > [<ffffffff8051fd57>] oops_end+0x61/0xad
> > > > > > > > [<ffffffff8051fd96>] oops_end+0xa0/0xad
> > > > > > > > [<ffffffff805215ac>] do_page_fault+0x748/0x801
> > > > > > > > [<ffffffff8051f3af>] page_fault+0x1f/0x30
> > > > > > > > [<ffffffff8032222d>] selinux_cred_free+0x0/0x14
> > > > > > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
> > > > > > > > IP: [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > PGD 3e8ad067 PUD 3e8ac067 PMD 0
> > > > > > > > Oops: 0000 [#2] SMP
> > > > > > > > last sysfs file: /sys/block/ram7/removable
> > > > > > > > CPU 2
> > > > > > > > Modules linked in:
> > > > > > > > Pid: 1, comm: init Tainted: G D 2.6.28-rc7-next-20081209-autotest #1
> > > > > > > > RIP: 0010:[<ffffffff802926da>] [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > RSP: 0018:ffff88003f9d7db8 EFLAGS: 00010002
> > > > > > > > RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000001
> > > > > > > > RDX: ffff880001037800 RSI: 0000000000000002 RDI: ffffffff80854f70
> > > > > > > > RBP: 0000000000000020 R08: 0000000000000000 R09: ffffffff80859a80
> > > > > > > > R10: 0000000000000001 R11: ffff88003f426018 R12: ffffffff80854f70
> > > > > > > > R13: ffffffff80253ab1 R14: 0000000000000080 R15: ffffffff802b4141
> > > > > > > > FS: 000000000066d870(0063) GS:ffff88003f803c80(0000) knlGS:0000000000000000
> > > > > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > > > > > > CR2: 0000000000000002 CR3: 000000003e8a9000 CR4: 00000000000006e0
> > > > > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > > > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > > > > > Process init (pid: 1, threadinfo ffff88003f9d6000, task ffff88003f9d8000)
> > > > > > > > Stack:
> > > > > > > > 00000000ffffffff ffff88003f426000 ffffffff80859a80 ffffffff80859a80
> > > > > > > > 0000000000000000 ffffffff80253ab1 00000000006f1db0 0000000000000000
> > > > > > > > ffff88003eb6a2f8 ffff88003f9d7e48 0000000000000000 01ff88003e97c400
> > > > > > > > Call Trace:
> > > > > > > > [<ffffffff80253ab1>] ? smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802704ca>] ? do_writepages+0x23/0x30
> > > > > > > > [<ffffffff802b4141>] ? invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff80253c16>] ? smp_call_function+0x20/0x24
> > > > > > > > [<ffffffff8023b483>] ? on_each_cpu+0x10/0x22
> > > > > > > > [<ffffffff802b919b>] ? kill_bdev+0x1b/0x30
> > > > > > > > [<ffffffff802b9892>] ? __blkdev_put+0x54/0x151
> > > > > > > > [<ffffffff8029899f>] ? __fput+0xe7/0x1b4
> > > > > > > > [<ffffffff802961ea>] ? filp_close+0x5e/0x66
> > > > > > > > [<ffffffff8029627f>] ? sys_close+0x8d/0xd1
> > > > > > > > [<ffffffff8020bf5b>] ? system_call_fastpath+0x16/0x1b
> > > > > > > > Code: 18 03 00 00 48 8b 32 44 8b 72 18 48 85 f6 75 18 49 89 d0 89 ee 4c 89 e9 83 ca ff 4c 89 e7 e8 57 f8 ff ff 48 89 c6 eb 0a 8b 42 14 <48> 8b 04 c6 48 89 02 53 9d 31 c0 c1 ed 0f 48 85 f6 0f 95 c0 85
> > > > > > > > RIP [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > RSP <ffff88003f9d7db8>
> > > > > > > > CR2: 0000000000000002
> > > > > > > > ---[ end trace 69ecde41a682e571 ]---
> > > > > > > > Kernel panic - not syncing: Attempted to kill init!
> > > > > > > > Pid: 1, comm: init Tainted: G D 2.6.28-rc7-next-20081209-autotest #1
> > > > > > > > Call Trace:
> > > > > > > > [<ffffffff80236e7d>] panic+0x86/0x144
> > > > > > > > [<ffffffff802abbfb>] mntput_no_expire+0x1e/0x139
> > > > > > > > [<ffffffff802961ea>] filp_close+0x5e/0x66
> > > > > > > > [<ffffffff8023870d>] exit_fs+0x35/0x46
> > > > > > > > [<ffffffff80239b7a>] do_exit+0x75/0x766
> > > > > > > > [<ffffffff8051fd9e>] oops_end+0xa8/0xad
> > > > > > > > [<ffffffff805215ac>] do_page_fault+0x748/0x801
> > > > > > > > [<ffffffff80253ab1>] smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802b4141>] invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff8051f3af>] page_fault+0x1f/0x30
> > > > > > > > [<ffffffff802b4141>] invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff80253ab1>] smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > [<ffffffff80253ab1>] smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802704ca>] do_writepages+0x23/0x30
> > > > > > > > [<ffffffff802b4141>] invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff80253c16>] smp_call_function+0x20/0x24
> > > > > > > > [<ffffffff8023b483>] on_each_cpu+0x10/0x22
> > > > > > > > [<ffffffff802b919b>] kill_bdev+0x1b/0x30
> > > > > > > > [<ffffffff802b9892>] __blkdev_put+0x54/0x151
> > > > > > > > [<ffffffff8029899f>] __fput+0xe7/0x1b4
> > > > > > > > [<ffffffff802961ea>] filp_close+0x5e/0x66
> > > > > > > > [<ffffffff8029627f>] sys_close+0x8d/0xd1
> > > > > > > > [<ffffffff8020bf5b>] system_call_fastpath+0x16/0x1b
> > > > > > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
> > > > > > > > IP: [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > PGD 0
> > > > > > > > Oops: 0000 [#3] SMP
> > > > > > > > last sysfs file: /sys/block/ram7/removable
> > > > > > > > CPU 2
> > > > > > > > Modules linked in:
> > > > > > > > Pid: 1, comm: init Tainted: G D 2.6.28-rc7-next-20081209-autotest #1
> > > > > > > > RIP: 0010:[<ffffffff802926da>] [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > RSP: 0018:ffff88003f9d7a58 EFLAGS: 00010002
> > > > > > > > RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000001
> > > > > > > > RDX: ffff880001037800 RSI: 0000000000000002 RDI: ffffffff80854f70
> > > > > > > > RBP: 0000000000000020 R08: ffffffff8052a5c0 R09: ffffffff80859a80
> > > > > > > > R10: 0000000000000000 R11: ffffffff8067c887 R12: ffffffff80854f70
> > > > > > > > R13: ffffffff80253ab1 R14: 0000000000000080 R15: ffffffff80211dd3
> > > > > > > > FS: 000000000066d870(0000) GS:ffff88003f803c80(0000) knlGS:0000000000000000
> > > > > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > > > > > > CR2: 0000000000000002 CR3: 0000000000201000 CR4: 00000000000006e0
> > > > > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > > > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > > > > > Process init (pid: 1, threadinfo ffff88003f9d6000, task ffff88003f9d8000)
> > > > > > > > Stack:
> > > > > > > > 00000000ffffffff ffff88003f9d8000 ffffffff80859a80 ffffffff80859a80
> > > > > > > > 0000000000000000 ffffffff80253ab1 ffffffff8052a5c0 ffff88003fa3bfc0
> > > > > > > > 0000000000000000 ffffffff8020e525 0000000000000010 000000003e943800
> > > > > > > > Call Trace:
> > > > > > > > [<ffffffff80253ab1>] ? smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff8020e525>] ? dump_trace+0x223/0x232
> > > > > > > > [<ffffffff80253c16>] ? smp_call_function+0x20/0x24
> > > > > > > > [<ffffffff8021ccc1>] ? native_smp_send_stop+0x1a/0x26
> > > > > > > > [<ffffffff80236e91>] ? panic+0x9a/0x144
> > > > > > > > [<ffffffff802abbfb>] ? mntput_no_expire+0x1e/0x139
> > > > > > > > [<ffffffff802961ea>] ? filp_close+0x5e/0x66
> > > > > > > > [<ffffffff8023870d>] ? exit_fs+0x35/0x46
> > > > > > > > [<ffffffff80239b7a>] ? do_exit+0x75/0x766
> > > > > > > > [<ffffffff8051fd9e>] ? oops_end+0xa8/0xad
> > > > > > > > [<ffffffff805215ac>] ? do_page_fault+0x748/0x801
> > > > > > > > [<ffffffff80253ab1>] ? smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802b4141>] ? invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff8051f3af>] ? page_fault+0x1f/0x30
> > > > > > > > [<ffffffff802b4141>] ? invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff80253ab1>] ? smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802926da>] ? kmem_cache_alloc+0x6a/0x99
> > > > > > > > [<ffffffff80253ab1>] ? smp_call_function_many+0xdb/0x220
> > > > > > > > [<ffffffff802704ca>] ? do_writepages+0x23/0x30
> > > > > > > > [<ffffffff802b4141>] ? invalidate_bh_lru+0x0/0x42
> > > > > > > > [<ffffffff80253c16>] ? smp_call_function+0x20/0x24
> > > > > > > > [<ffffffff8023b483>] ? on_each_cpu+0x10/0x22
> > > > > > > > [<ffffffff802b919b>] ? kill_bdev+0x1b/0x30
> > > > > > > > [<ffffffff802b9892>] ? __blkdev_put+0x54/0x151
> > > > > > > > [<ffffffff8029899f>] ? __fput+0xe7/0x1b4
> > > > > > > > [<ffffffff802961ea>] ? filp_close+0x5e/0x66
> > > > > > > > [<ffffffff8029627f>] ? sys_close+0x8d/0xd1
> > > > > > > > [<ffffffff8020bf5b>] ? system_call_fastpath+0x16/0x1b
> > > > > > > > Code: 18 03 00 00 48 8b 32 44 8b 72 18 48 85 f6 75 18 49 89 d0 89 ee 4c 89 e9 83 ca ff 4c 89 e7 e8 57 f8 ff ff 48 89 c6 eb 0a 8b 42 14 <48> 8b 04 c6 48 89 02 53 9d 31 c0 c1 ed 0f 48 85 f6 0f 95 c0 85
> > > > > > > > RIP [<ffffffff802926da>] kmem_cache_alloc+0x6a/0x99
> > > > > > > > RSP <ffff88003f9d7a58>
> > > > > > > > CR2: 0000000000000002
> > > > > > > > ---[ end trace 69ecde41a682e571 ]---
> > > > > > > > Fixing recursive fault but reboot is needed!
> > > > > > > > [<ffffffff80268f66>] __rcu_process_callbacks+0x14e/0x1c3
> > > > > > > > [<ffffffff80268f66>] __rcu_process_callbacks+0x14e/0x1c3
> > > > > > > > [<ffffffff80269001>] rcu_process_callbacks+0x26/0x4a
> > > > > > > > [<ffffffff8023b891>] __do_softirq+0x76/0x136
> > > > > > > > [<ffffffff8020e79e>] profile_pc+0x21/0x5b
> > > > > > > > [<ffffffff8020d03c>] call_softirq+0x1c/0x28
> > > > > > > > [<ffffffff8020e091>] do_softirq+0x2c/0x6c
> > > > > > > > [<ffffffff8021e018>] smp_apic_timer_interrupt+0x93/0xac
> > > > > > > > [<ffffffff8020ca73>] apic_timer_interrupt+0x13/0x20
> > > > > > > > <EOI>
> > > > > >
> > <snip the .config file>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: KOSAKI Motohiro @ 2008-12-16 12:58 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Yinghai Lu, LKML, linux-next
In-Reply-To: <20081216121815.GA25019@elte.hu>
>> or, following #ifdef ?
>>
>> #if defined(CONFIG_SPARSE_IRQ) || defined(CONFIG_TRACE_IRQFLAGS)
>>
>> /*
>> * lockdep: we want to handle all irq_desc locks as a single lock-class:
>> */
>> static struct lock_class_key irq_desc_lock_class;
>
> instead of increasing the #ifdef jungle, how about removing some? For
> example is this distinction:
>
>> > #ifndef CONFIG_SPARSE_IRQ
>
> really needed? We should use symmetric lock class annotations, regardless
> of how irq_desc[] is laid out.
it seems make much sense. I'll test your idea tommorow.
thanks.
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: Ingo Molnar @ 2008-12-16 12:18 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Andrew Morton, Yinghai Lu, LKML, linux-next
In-Reply-To: <2f11576a0812160345t1cca65eg34064dbbcafcd280@mail.gmail.com>
* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> >> > actually, this breaks the build on !SPARSEIRQ because we will use that
> >> > class in the non-sparseirq case. So we've converted a build warning to
> >> > a build failure ;-)
> >>
> >> Please give me your .config and tell me your arch. my ia64 box (ia64 is
> >> !SPARSEIRQ) can build the akpm patch.
> >
> > The expected build failure is obvious from reading the code:
> >
> > #ifdef CONFIG_TRACE_IRQFLAGS
> > void early_init_irq_lock_class(void)
> > {
> > #ifndef CONFIG_SPARSE_IRQ
> > struct irq_desc *desc;
> > int i;
> >
> > for_each_irq_desc(i, desc) {
> > if (!desc)
> > continue;
> >
> > lockdep_set_class(&desc->lock, &irq_desc_lock_class);
> >
> > Note that it's an #ifndef sparseirq, not an #ifdef sparseirq condition.
>
> I see. thanks.
> It seems my first proposal is better.
>
> or, following #ifdef ?
>
> #if defined(CONFIG_SPARSE_IRQ) || defined(CONFIG_TRACE_IRQFLAGS)
>
> /*
> * lockdep: we want to handle all irq_desc locks as a single lock-class:
> */
> static struct lock_class_key irq_desc_lock_class;
instead of increasing the #ifdef jungle, how about removing some? For
example is this distinction:
> > #ifndef CONFIG_SPARSE_IRQ
really needed? We should use symmetric lock class annotations, regardless
of how irq_desc[] is laid out.
Ingo
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: KOSAKI Motohiro @ 2008-12-16 11:45 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Yinghai Lu, LKML, linux-next
In-Reply-To: <20081216112019.GE4299@elte.hu>
>> > actually, this breaks the build on !SPARSEIRQ because we will use that
>> > class in the non-sparseirq case. So we've converted a build warning to
>> > a build failure ;-)
>>
>> Please give me your .config and tell me your arch. my ia64 box (ia64 is
>> !SPARSEIRQ) can build the akpm patch.
>
> The expected build failure is obvious from reading the code:
>
> #ifdef CONFIG_TRACE_IRQFLAGS
> void early_init_irq_lock_class(void)
> {
> #ifndef CONFIG_SPARSE_IRQ
> struct irq_desc *desc;
> int i;
>
> for_each_irq_desc(i, desc) {
> if (!desc)
> continue;
>
> lockdep_set_class(&desc->lock, &irq_desc_lock_class);
>
> Note that it's an #ifndef sparseirq, not an #ifdef sparseirq condition.
I see. thanks.
It seems my first proposal is better.
or, following #ifdef ?
#if defined(CONFIG_SPARSE_IRQ) || defined(CONFIG_TRACE_IRQFLAGS)
/*
* lockdep: we want to handle all irq_desc locks as a single lock-class:
*/
static struct lock_class_key irq_desc_lock_class;
#endif
^ permalink raw reply
* linux-next: Tree for December 16
From: Stephen Rothwell @ 2008-12-16 11:37 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 10353 bytes --]
Hi all,
Changes since 20081215:
Undropped tree:
rr
boot-params
Dropped trees (temporarily):
v4l-dvb (build problem)
lblnet (build failure)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
perfmon3 (concerns from the x86 team)
audit (difficult conflicts)
nommu (build problem)
The rr tree gained a conflict against the cpus4096 tree and lost 5 other
conflicts.
The lblnet tree gained a build failure and was dropped.
The boot-params tree lost its build failure.
I also applied "Define smp_call_function_many for UP" from Rusty Russell
(which is now in Linus' tree for tomorrow) and reverted 2 commits from the
scsi tree due to build problems.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 133 trees (counting Linus' and 15 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging audit-current/for-linus
Merging dwmw2/master
Applying: Define smp_call_function_many for UP
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
CONFLICT (content): Merge conflict in drivers/char/Makefile
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in arch/powerpc/platforms/85xx/mpc85xx_mds.c
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in scripts/recordmcount.pl
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pci-driver.c
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
$ git reset --hard HEAD^
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/xfs_rename.c
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in arch/x86/kernel/reboot.c
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (delete/modify): arch/sparc64/kernel/idprom.c deleted in HEAD and modified in net/master. Version net/master of arch/sparc64/kernel/idprom.c left in tree.
CONFLICT (content): Merge conflict in drivers/net/e1000e/ich8lan.c
CONFLICT (content): Merge conflict in fs/lockd/host.c
CONFLICT (content): Merge conflict in fs/lockd/mon.c
$ git rm -f arch/sparc64/kernel/idprom.c
Applying: net: async_tx merge fix
Merging mtd/master
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/corgi.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/poodle.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/spitz.c
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
CONFLICT (content): Merge conflict in sound/drivers/pcsp/pcsp.c
Applying: sound: fixup for timers tree interaction
Merging cpufreq/next
Merging v9fs/for-next
Merging rr_cpumask/master
CONFLICT (content): Merge conflict in arch/x86/kernel/io_apic.c
CONFLICT (content): Merge conflict in kernel/sched.c
CONFLICT (content): Merge conflict in kernel/sched_stats.h
Merging quilt/rr
CONFLICT (content): Merge conflict in kernel/sched.c
Merging cifs/master
CONFLICT (content): Merge conflict in fs/cifs/connect.c
Applying: cifs: update for new IP4/6 address printing
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
CONFLICT (content): Merge conflict in arch/arm/mach-lh7a40x/clocks.c
CONFLICT (content): Merge conflict in net/9p/trans_virtio.c
$ git reset --hard
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/ioctl.c
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/bio.c
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/net/tg3.c
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
CONFLICT (content): Merge conflict in fs/cifs/cifs_fs_sb.h
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_cred.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_globals.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_ioctl.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.h
Merging lblnet/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
$ git reset --hard HEAD^
Merging quilt/ttydev
CONFLICT (content): Merge conflict in fs/devpts/inode.c
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
CONFLICT (content): Merge conflict in drivers/watchdog/iTCO_wdt.c
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
Merging cpu_alloc/cpu_alloc
CONFLICT (content): Merge conflict in kernel/lockdep.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git reset --hard
Merging cputime/cputime
CONFLICT (content): Merge conflict in kernel/sched.c
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
CONFLICT (content): Merge conflict in Documentation/sysctl/vm.txt
CONFLICT (content): Merge conflict in kernel/fork.c
$ git reset --hard
Merging trivial/for-next
Merging audit/for-next
CONFLICT (content): Merge conflict in include/linux/audit.h
CONFLICT (content): Merge conflict in kernel/auditsc.c
CONFLICT (content): Merge conflict in kernel/capability.c
CONFLICT (content): Merge conflict in security/commoncap.c
$ git reset --hard
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/winbond/linux/wbusb.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/winbond/linux/wbusb.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211netdev.c
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211wext.c
$ git rm -f drivers/staging/winbond/linux/wbusb.c
Merging scsi-post-merge/master
Merging boot-params/master
CONFLICT (content): Merge conflict in arch/arm/kernel/setup.c
CONFLICT (content): Merge conflict in arch/parisc/kernel/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-migor/setup.c
CONFLICT (content): Merge conflict in init/main.c
Created commit fb7636d: Revert "[SCSI] fcoe: Fibre Channel over Ethernet"
Created commit 0360af7: Revert "[SCSI] libfc: A modular Fibre Channel library"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: Ingo Molnar @ 2008-12-16 11:20 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Andrew Morton, Yinghai Lu, LKML, linux-next
In-Reply-To: <2f11576a0812160315g3dea988ayfadba2117e172a2c@mail.gmail.com>
* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> Hi!
>
> >> > No, lockdep.h (which we forgot to include) already handles that:
> >> >
> >> > # define lockdep_set_class(lock, key) do { (void)(key); } while (0)
> >> >
> >> > the problem is that the code which references irq_desc_lock_class is
> >> > inside #ifdef CONFIG_SPARSE_IRQ, so this is a better fix:
> >>
> >> agreed that this is the better fix - applied to tip/irq/sparseirq,
> >> thanks!
> >
> > actually, this breaks the build on !SPARSEIRQ because we will use that
> > class in the non-sparseirq case. So we've converted a build warning to
> > a build failure ;-)
>
> Please give me your .config and tell me your arch. my ia64 box (ia64 is
> !SPARSEIRQ) can build the akpm patch.
The expected build failure is obvious from reading the code:
#ifdef CONFIG_TRACE_IRQFLAGS
void early_init_irq_lock_class(void)
{
#ifndef CONFIG_SPARSE_IRQ
struct irq_desc *desc;
int i;
for_each_irq_desc(i, desc) {
if (!desc)
continue;
lockdep_set_class(&desc->lock, &irq_desc_lock_class);
Note that it's an #ifndef sparseirq, not an #ifdef sparseirq condition.
Ingo
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: KOSAKI Motohiro @ 2008-12-16 11:15 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Yinghai Lu, LKML, linux-next
In-Reply-To: <20081216102340.GA1003@elte.hu>
Hi!
>> > No, lockdep.h (which we forgot to include) already handles that:
>> >
>> > # define lockdep_set_class(lock, key) do { (void)(key); } while (0)
>> >
>> > the problem is that the code which references irq_desc_lock_class is
>> > inside #ifdef CONFIG_SPARSE_IRQ, so this is a better fix:
>>
>> agreed that this is the better fix - applied to tip/irq/sparseirq,
>> thanks!
>
> actually, this breaks the build on !SPARSEIRQ because we will use that
> class in the non-sparseirq case. So we've converted a build warning to a
> build failure ;-)
Please give me your .config and tell me your arch.
my ia64 box (ia64 is !SPARSEIRQ) can build the akpm patch.
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: Ingo Molnar @ 2008-12-16 10:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: KOSAKI Motohiro, Yinghai Lu, LKML, linux-next
In-Reply-To: <20081216101827.GB27481@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> > > #include "internals.h"
> > >
> > > +#ifdef CONFIG_LOCKDEP
> > > /*
> > > * lockdep: we want to handle all irq_desc locks as a single lock-class:
> > > */
> > > static struct lock_class_key irq_desc_lock_class;
> > > +#endif
> > >
> > > /**
> > > * handle_bad_irq - handle spurious and unhandled irqs
> > >
> >
> > No, lockdep.h (which we forgot to include) already handles that:
> >
> > # define lockdep_set_class(lock, key) do { (void)(key); } while (0)
> >
> > the problem is that the code which references irq_desc_lock_class is
> > inside #ifdef CONFIG_SPARSE_IRQ, so this is a better fix:
>
> agreed that this is the better fix - applied to tip/irq/sparseirq,
> thanks!
actually, this breaks the build on !SPARSEIRQ because we will use that
class in the non-sparseirq case. So we've converted a build warning to a
build failure ;-)
Ingo
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: Ingo Molnar @ 2008-12-16 10:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: KOSAKI Motohiro, Yinghai Lu, LKML, linux-next
In-Reply-To: <20081216003428.43d37b6b.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 16 Dec 2008 17:08:43 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
> >
> >
> > Applied after: linux-next.patch
> >
> > ==
> > Subject: [mmotm][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
> >
> > commit 08678b0841267c1d00d771fe01548d86043d065e introduced
> > irq_desc_lock_class variable.
> > But it is used only if CONFIG_LOCKDEP=Y.
> > otherwise, following warnings happend.
> >
> > CC kernel/irq/handle.o
> > kernel/irq/handle.c:26: warning: 'irq_desc_lock_class' defined but not used
> >
> >
> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > CC: Yinghai Lu <yhlu.kernel@gmail.com>
> > CC: Ingo Molnar <mingo@elte.hu>
> > ---
> > kernel/irq/handle.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > Index: b/kernel/irq/handle.c
> > ===================================================================
> > --- a/kernel/irq/handle.c
> > +++ b/kernel/irq/handle.c
> > @@ -20,10 +20,12 @@
> >
> > #include "internals.h"
> >
> > +#ifdef CONFIG_LOCKDEP
> > /*
> > * lockdep: we want to handle all irq_desc locks as a single lock-class:
> > */
> > static struct lock_class_key irq_desc_lock_class;
> > +#endif
> >
> > /**
> > * handle_bad_irq - handle spurious and unhandled irqs
> >
>
> No, lockdep.h (which we forgot to include) already handles that:
>
> # define lockdep_set_class(lock, key) do { (void)(key); } while (0)
>
> the problem is that the code which references irq_desc_lock_class is
> inside #ifdef CONFIG_SPARSE_IRQ, so this is a better fix:
agreed that this is the better fix - applied to tip/irq/sparseirq, thanks!
Ingo
^ permalink raw reply
* Re: [PATCH] simnet: convert to net_device_ops
From: David Miller @ 2008-12-16 9:56 UTC (permalink / raw)
To: adobriyan; +Cc: a.beregalov, linux-next, netdev, linux-ia64
In-Reply-To: <20081209150827.GA8134@x200.localdomain>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 9 Dec 2008 18:08:27 +0300
> On Tue, Dec 09, 2008 at 05:11:17PM +0300, Alexander Beregalov wrote:
> > CC arch/ia64/hp/sim/simeth.o
> > arch/ia64/hp/sim/simeth.c: In function 'simeth_probe1':
> > arch/ia64/hp/sim/simeth.c:212: error: 'struct net_device' has no member named 'open'
>
> [PATCH] simeth: convert to net_device_ops
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Now that the kconfig badness has been fixed, I've applied
this.
Thanks Alexey.
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: Andrew Morton @ 2008-12-16 8:34 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Yinghai Lu, Ingo Molnar, LKML, linux-next
In-Reply-To: <20081216170635.DBB8.KOSAKI.MOTOHIRO@jp.fujitsu.com>
On Tue, 16 Dec 2008 17:08:43 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
>
> Applied after: linux-next.patch
>
> ==
> Subject: [mmotm][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
>
> commit 08678b0841267c1d00d771fe01548d86043d065e introduced
> irq_desc_lock_class variable.
> But it is used only if CONFIG_LOCKDEP=Y.
> otherwise, following warnings happend.
>
> CC kernel/irq/handle.o
> kernel/irq/handle.c:26: warning: 'irq_desc_lock_class' defined but not used
>
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yinghai Lu <yhlu.kernel@gmail.com>
> CC: Ingo Molnar <mingo@elte.hu>
> ---
> kernel/irq/handle.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: b/kernel/irq/handle.c
> ===================================================================
> --- a/kernel/irq/handle.c
> +++ b/kernel/irq/handle.c
> @@ -20,10 +20,12 @@
>
> #include "internals.h"
>
> +#ifdef CONFIG_LOCKDEP
> /*
> * lockdep: we want to handle all irq_desc locks as a single lock-class:
> */
> static struct lock_class_key irq_desc_lock_class;
> +#endif
>
> /**
> * handle_bad_irq - handle spurious and unhandled irqs
>
No, lockdep.h (which we forgot to include) already handles that:
# define lockdep_set_class(lock, key) do { (void)(key); } while (0)
the problem is that the code which references irq_desc_lock_class is
inside #ifdef CONFIG_SPARSE_IRQ, so this is a better fix:
--- a/kernel/irq/handle.c~irq-enclose-irq_desc_lock_class-in-config_lockdep
+++ a/kernel/irq/handle.c
@@ -13,6 +13,7 @@
#include <linux/irq.h>
#include <linux/module.h>
#include <linux/random.h>
+#include <linux/lockdep.h>
#include <linux/interrupt.h>
#include <linux/kernel_stat.h>
#include <linux/rculist.h>
@@ -20,11 +21,6 @@
#include "internals.h"
-/*
- * lockdep: we want to handle all irq_desc locks as a single lock-class:
- */
-static struct lock_class_key irq_desc_lock_class;
-
/**
* handle_bad_irq - handle spurious and unhandled irqs
* @irq: the interrupt number
@@ -61,6 +57,12 @@ void __init __attribute__((weak)) arch_e
}
#ifdef CONFIG_SPARSE_IRQ
+
+/*
+ * lockdep: we want to handle all irq_desc locks as a single lock-class:
+ */
+static struct lock_class_key irq_desc_lock_class;
+
static struct irq_desc irq_desc_init = {
.irq = -1,
.status = IRQ_DISABLED,
_
^ permalink raw reply
* linux-next: lblnet tree build failure
From: Stephen Rothwell @ 2008-12-16 8:14 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-next, Casey Schaufler
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
Hi Paul,
Today's linux-next build (x86_64 allmodconfig) failed like this:
security/smack/smackfs.c: In function 'smk_netlabel_audit_set':
security/smack/smackfs.c:118: error: 'struct task_struct' has no member named 'security'
Caused by commit 2d22b59c5401e60c04e6258a245b8a99d103f55b ("smack: Add
support for unlabeled network hosts and networks") interacting with
commit b6dff3ec5e116e3af6f537d4caedcad6b9e5082a ("CRED: Separate task
security context from task_struct") from the security-testing tree. This
latter commit is also in the lblnet tree (since it merges the security
testing tree).
I have dropped the lblnet tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: KOSAKI Motohiro @ 2008-12-16 8:08 UTC (permalink / raw)
To: Yinghai Lu, Ingo Molnar, LKML, Andrew Morton, linux-next; +Cc: kosaki.motohiro
Applied after: linux-next.patch
==
Subject: [mmotm][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
commit 08678b0841267c1d00d771fe01548d86043d065e introduced
irq_desc_lock_class variable.
But it is used only if CONFIG_LOCKDEP=Y.
otherwise, following warnings happend.
CC kernel/irq/handle.o
kernel/irq/handle.c:26: warning: 'irq_desc_lock_class' defined but not used
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Yinghai Lu <yhlu.kernel@gmail.com>
CC: Ingo Molnar <mingo@elte.hu>
---
kernel/irq/handle.c | 2 ++
1 file changed, 2 insertions(+)
Index: b/kernel/irq/handle.c
===================================================================
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -20,10 +20,12 @@
#include "internals.h"
+#ifdef CONFIG_LOCKDEP
/*
* lockdep: we want to handle all irq_desc locks as a single lock-class:
*/
static struct lock_class_key irq_desc_lock_class;
+#endif
/**
* handle_bad_irq - handle spurious and unhandled irqs
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Stephen Rothwell @ 2008-12-16 6:09 UTC (permalink / raw)
To: Mike Travis; +Cc: Rusty Russell, linux-next, Yinghai Lu, Ingo Molnar
In-Reply-To: <49474471.2090409@sgi.com>
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
Hi Mike,
On Mon, 15 Dec 2008 22:02:25 -0800 Mike Travis <travis@sgi.com> wrote:
>
> Yes, I did finally figure that out. Thanks for rebasing the part that Ingo needed
> so maybe the rest can be pushed. There was a problem when the 'for-ingo' tree was
> merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
> x86 only patch. I wasn't sure of what else to do.
You could have fixed them up as part of the actual merge commit. If each
tree was correct on it own, then the merge is the place for such
resolutions.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: cpu_alloc tree
From: Stephen Rothwell @ 2008-12-16 6:05 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-next, Rusty Russell
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
Hi Christoph,
The cpu_alloc tree has not been included in linux-next since Nov 21. Have
your discussions with Rusty come to any conclusions? Should I remove
this tree permanently or will it be updated?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Mike Travis @ 2008-12-16 6:02 UTC (permalink / raw)
To: Rusty Russell; +Cc: Stephen Rothwell, linux-next, Yinghai Lu, Ingo Molnar
In-Reply-To: <200812161610.58496.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Tuesday 16 December 2008 02:57:09 Mike Travis wrote:
>> Rusty Russell wrote:
>>> On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
>>>> Hi Rusty,
>>>>
>>>> Today's linux-next merge of the rr_cpumask tree got a conflict in
>>>> arch/x86/kernel/io_apic.c between commit
>>>> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
>>>> irq_desc") from the sparseirq tree and commit
>>>> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
>>>> () take a const struct cpumask") from the rr_cpumask tree.
>>>>
>>>> There are lots of overlapping changes. I fixed it up (see below) and can carry the
>>>> fix as necessary.
>>> I have performed this merge before. The results are in
>>> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
>>>
>>> Ingo, can you pull these into cpus4096? It's just the cpumask/cpus4096 merge.
>>>
>>> Thanks,
>>> Rusty.
>> Hi Rusty,
>>
>> Did you update your tip/cpus4096 branch?
>
> No. As I said, I just did a merge of ingo's 4096 tree with the cpumask tree.
> He should pull that, and then the rest of the x86 patches can go on top.
>
> Cheers,
> Rusty.
Hi Rusty,
Yes, I did finally figure that out. Thanks for rebasing the part that Ingo needed
so maybe the rest can be pushed. There was a problem when the 'for-ingo' tree was
merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
x86 only patch. I wasn't sure of what else to do.
All the x86 patches build and boot (and test! ;-) on x86_64. My 32-bit box has gone
into a coma until I can figure out what's up (and the 64-bit box lost it's 32-bit
root partition.) Since they are pretty much exactly as you had tested last week,
I not expecting any problems.
I'm working through the remainder of your cpumask patches now.
Thanks!
Mike
^ permalink raw reply
* linux-next: v4l-dvb tree
From: Stephen Rothwell @ 2008-12-16 5:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Hi Mauro,
The v4l-dvb tree has not been in linux-next since Nov 25 due to build
problems. The tree I am fetching
(git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git#master)
has not been updated since Dec 2. (The current head of branch commit is
6e65a8a8f16144b0f092915c9f89c2beb957e14b "Merge branch 'next'
of ../devel")
Is there any progress in this?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: semaphore-removal tree
From: Stephen Rothwell @ 2008-12-16 5:49 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
Hi Willy,
Is anything in this tree destined for 2.6.29? It has been not been in
linux-next since Oct 31 due to unresolved conflicts with Linus' tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Rusty Russell @ 2008-12-16 5:40 UTC (permalink / raw)
To: Mike Travis; +Cc: Stephen Rothwell, linux-next, Yinghai Lu, Ingo Molnar
In-Reply-To: <4946855D.7070403@sgi.com>
On Tuesday 16 December 2008 02:57:09 Mike Travis wrote:
> Rusty Russell wrote:
> > On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
> >> Hi Rusty,
> >>
> >> Today's linux-next merge of the rr_cpumask tree got a conflict in
> >> arch/x86/kernel/io_apic.c between commit
> >> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
> >> irq_desc") from the sparseirq tree and commit
> >> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
> >> () take a const struct cpumask") from the rr_cpumask tree.
> >>
> >> There are lots of overlapping changes. I fixed it up (see below) and can carry the
> >> fix as necessary.
> >
> > I have performed this merge before. The results are in
> > git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
> >
> > Ingo, can you pull these into cpus4096? It's just the cpumask/cpus4096 merge.
> >
> > Thanks,
> > Rusty.
>
> Hi Rusty,
>
> Did you update your tip/cpus4096 branch?
No. As I said, I just did a merge of ingo's 4096 tree with the cpumask tree.
He should pull that, and then the rest of the x86 patches can go on top.
Cheers,
Rusty.
^ 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