On 2/4/21 1:13 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210203:
>
on x86_64:
Still seeing 2 unrelated issues:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [
Hi all,
Changes since 20210203:
The net-next tree gained a build failure, so I used the version from
next-20210203.
The tip tree still had its boot failure so I reverted a commit.
The drivers-x86 tree gained conflicts against the drm-misc tree.
Non-merge commits (relative to Linus' tree): 7615
Hi all,
Changes since 20190201:
The vfs tree still had its build failure for which I applied a patch.
The net-next tree gained a build failure for which I applied a fix patch.
The drm-tegra tree gained a build failure so I used the version from
next-20190201.
The driver-core tree lost its buil
Hi all,
Changes since 20160203:
The gpio tree still had its build failure so I used the version from
next-20160128.
The aio tree still had a build failure so I used the version from
next-20160111.
The akpm-current tree lost its build failures.
Non-merge commits (relative to Linus' tree): 2245
On Thu, Feb 5, 2015 at 8:46 PM, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 4:17 AM, Martin K. Petersen
> wrote:
>>> "Sedat" == Sedat Dilek writes:
>>
>> Sedat> No, but I am here on a so-called WUBI installation which
>> Sedat> triggered some bugs being an exotic installation. My
>> Sedat>
On Fri, Feb 6, 2015 at 1:12 AM, Steven Rostedt wrote:
> On Fri, 6 Feb 2015 00:53:41 +0100
> Sedat Dilek wrote:
>
>> > See that if (IS_ENABLED(CONFIG_LOCKDEP))?
>> >
>>
>> I have here...
>>
>> CONFIG_LOCKDEP=y
>
> Yep, I knew that (you wouldn't get splats without it).
>
>
>> Which old patch?
>> "t
On Fri, 6 Feb 2015 00:53:41 +0100
Sedat Dilek wrote:
> > See that if (IS_ENABLED(CONFIG_LOCKDEP))?
> >
>
> I have here...
>
> CONFIG_LOCKDEP=y
Yep, I knew that (you wouldn't get splats without it).
> Which old patch?
> "tlb: Don't do trace_tlb_flush() on offline CPUs" ?
Yeah, that one. In o
[...]
>> That said, let's add this (on top of the old patch):
>>
>
> Which old patch?
> "tlb: Don't do trace_tlb_flush() on offline CPUs" ?
>
Or did you mean "x86/mm: Omit switch_mm() tracing for offline CPUs"
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, Feb 6, 2015 at 12:11 AM, Steven Rostedt wrote:
> On Thu, 5 Feb 2015 23:16:21 +0100
> Sedat Dilek wrote:
>
>> On Thu, Feb 5, 2015 at 11:09 PM, Steven Rostedt wrote:
>> > On Thu, 5 Feb 2015 22:45:59 +0100
>> > Sedat Dilek wrote:
>> >
>> >> Steve, this was a typo it's called tlb_flush not
On Thu, 5 Feb 2015 23:16:21 +0100
Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 11:09 PM, Steven Rostedt wrote:
> > On Thu, 5 Feb 2015 22:45:59 +0100
> > Sedat Dilek wrote:
> >
> >> Steve, this was a typo it's called tlb_flush not tlb_flush*ed*:
> >
> > Heh, yeah, I typed that entire line in by h
On Thu, Feb 5, 2015 at 11:09 PM, Steven Rostedt wrote:
> On Thu, 5 Feb 2015 22:45:59 +0100
> Sedat Dilek wrote:
>
>> Steve, this was a typo it's called tlb_flush not tlb_flush*ed*:
>
> Heh, yeah, I typed that entire line in by hand. Just be lucky that was
> the only typo ;-)
>
>>
>> # cat /sys/ke
On Thu, 5 Feb 2015 22:45:59 +0100
Sedat Dilek wrote:
> Steve, this was a typo it's called tlb_flush not tlb_flush*ed*:
Heh, yeah, I typed that entire line in by hand. Just be lucky that was
the only typo ;-)
>
> # cat /sys/kernel/debug/tracing/events/tlb/tlb_flush/enable
> 1
>
> [ 391.090381
[...]
>>> >> Unfortunately, the call-trace remains when doing an offlining of cpu1.
>>> >> ( It's good to see it's reproducible. )
>>> >
>>> > Was the tracepoint enabled? Or was there some other rcu call that
>>> > triggered this. Or would cpu_online(smp_processor_id()) return true at
>>> > this po
On Thu, Feb 5, 2015 at 9:22 PM, Steven Rostedt wrote:
> On Thu, 5 Feb 2015 21:07:27 +0100
> Sedat Dilek wrote:
>
>> > Is this Paul's version of the patch or mine? If it is just mine, do you
>> > know if Paul's version triggers this too?
>> >
>>
>> This one which entered Pauls rcu-next tree.
>>
>>
On Thu, 5 Feb 2015 21:07:27 +0100
Sedat Dilek wrote:
> > Is this Paul's version of the patch or mine? If it is just mine, do you
> > know if Paul's version triggers this too?
> >
>
> This one which entered Pauls rcu-next tree.
>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/paulmck/linux
On Thu, Feb 5, 2015 at 8:58 PM, Steven Rostedt wrote:
> On Thu, 5 Feb 2015 20:25:21 +0100
> Sedat Dilek wrote:
>
>> On Thu, Feb 5, 2015 at 7:45 PM, Paul E. McKenney
>> wrote:
>> > On Thu, Feb 05, 2015 at 10:35:33AM -0800, Dave Hansen wrote:
>> >> On 02/05/2015 10:34 AM, Paul E. McKenney wrote:
>
On Thu, 5 Feb 2015 20:25:21 +0100
Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 7:45 PM, Paul E. McKenney
> wrote:
> > On Thu, Feb 05, 2015 at 10:35:33AM -0800, Dave Hansen wrote:
> >> On 02/05/2015 10:34 AM, Paul E. McKenney wrote:
> >> >> > Did I actually need to be
On Thu, Feb 5, 2015 at 4:17 AM, Martin K. Petersen
wrote:
>> "Sedat" == Sedat Dilek writes:
>
> Sedat> No, but I am here on a so-called WUBI installation which
> Sedat> triggered some bugs being an exotic installation. My
> Sedat> Ubuntu/precise is a 18GiB image laying on my Win7 partition
>
On Thu, Feb 5, 2015 at 8:33 PM, Paul E. McKenney
wrote:
> On Thu, Feb 05, 2015 at 08:25:21PM +0100, Sedat Dilek wrote:
>> On Thu, Feb 5, 2015 at 7:45 PM, Paul E. McKenney
>> wrote:
>> > On Thu, Feb 05, 2015 at 10:35:33AM -0800, Dave Hansen wrote:
>> >> On 02/05/2015 10:34 AM, Paul E. McKenney wro
On Thu, Feb 05, 2015 at 08:25:21PM +0100, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 7:45 PM, Paul E. McKenney
> wrote:
> > On Thu, Feb 05, 2015 at 10:35:33AM -0800, Dave Hansen wrote:
> >> On 02/05/2015 10:34 AM, Paul E. McKenney wrote:
> >> >> > Did I actually need
On Thu, Feb 05, 2015 at 10:35:33AM -0800, Dave Hansen wrote:
> On 02/05/2015 10:34 AM, Paul E. McKenney wrote:
> >> > Did I actually need to be
> >> > onlining/offlining CPUs to hit the splat that Sedat was reporting?
> > Yep, you do need to offline at least one CPU to
On 02/05/2015 10:34 AM, Paul E. McKenney wrote:
>> > Did I actually need to be
>> > onlining/offlining CPUs to hit the splat that Sedat was reporting?
> Yep, you do need to offline at least one CPU to hit that splat.
Heh, do we need a debugging mode that will randomly
On Thu, Feb 05, 2015 at 10:11:31AM -0800, Dave Hansen wrote:
> On 02/05/2015 10:08 AM, Steven Rostedt wrote:
> > --- a/include/trace/events/tlb.h
> > +++ b/include/trace/events/tlb.h
> > @@ -13,11 +13,13 @@
> > { TLB_LOCAL_SHOOTDOWN, "local shootdown" },\
> > { TLB_LOCA
On 02/05/2015 10:08 AM, Steven Rostedt wrote:
> --- a/include/trace/events/tlb.h
> +++ b/include/trace/events/tlb.h
> @@ -13,11 +13,13 @@
> { TLB_LOCAL_SHOOTDOWN, "local shootdown" },\
> { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" }
>
> -TRACE_EVENT(tlb_f
On Thu, 5 Feb 2015 13:03:43 -0500
Steven Rostedt wrote:
> (not tested)
>
> Signed-off-by: Steven Rostedt
> ---
> diff --git a/include/trace/events/tlb.h b/include/trace/events/tlb.h
> index 13391d288107..040c1cdfe6d1 100644
> --- a/include/trace/events/tlb.h
> +++ b/include/trace/events/tlb.h
>
On Wed, 04 Feb 2015 23:14:55 -0800
Dave Hansen wrote:
> On 02/04/2015 05:53 PM, Sedat Dilek wrote:
> > The architecture-specific switch_mm() function can be called by offline
> > CPUs, but includes event tracing, which cannot be legally carried out
> > on offline CPUs. This results in a lockdep-
On Thu, Feb 05, 2015 at 03:57:12PM +0100, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 8:14 AM, Dave Hansen wrote:
> > On 02/04/2015 05:53 PM, Sedat Dilek wrote:
> >> The architecture-specific switch_mm() function can be called by offline
> >> CPUs, but includes event tracing, which cannot be legal
On Wed, Feb 04, 2015 at 11:14:55PM -0800, Dave Hansen wrote:
> On 02/04/2015 05:53 PM, Sedat Dilek wrote:
> > The architecture-specific switch_mm() function can be called by offline
> > CPUs, but includes event tracing, which cannot be legally carried out
> > on offline CPUs. This results in a loc
On Thu, Feb 5, 2015 at 8:14 AM, Dave Hansen wrote:
> On 02/04/2015 05:53 PM, Sedat Dilek wrote:
>> The architecture-specific switch_mm() function can be called by offline
>> CPUs, but includes event tracing, which cannot be legally carried out
>> on offline CPUs. This results in a lockdep-RCU spl
On 02/04/2015 05:53 PM, Sedat Dilek wrote:
> The architecture-specific switch_mm() function can be called by offline
> CPUs, but includes event tracing, which cannot be legally carried out
> on offline CPUs. This results in a lockdep-RCU splat. This commit fixes
> this splat by omitting the traci
On Thu, Feb 05, 2015 at 03:12:20AM +0100, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 2:53 AM, Sedat Dilek wrote:
> > On Thu, Feb 5, 2015 at 2:51 AM, Paul E. McKenney
> > wrote:
> >> On Thu, Feb 05, 2015 at 02:18:01AM +0100, Sedat Dilek wrote:
> >>> On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenne
On Thu, Feb 5, 2015 at 4:17 AM, Martin K. Petersen
wrote:
>> "Sedat" == Sedat Dilek writes:
>
> Sedat> No, but I am here on a so-called WUBI installation which
> Sedat> triggered some bugs being an exotic installation. My
> Sedat> Ubuntu/precise is a 18GiB image laying on my Win7 partition
>
> "Sedat" == Sedat Dilek writes:
Sedat> No, but I am here on a so-called WUBI installation which
Sedat> triggered some bugs being an exotic installation. My
Sedat> Ubuntu/precise is a 18GiB image laying on my Win7 partition
Sedat> (/dev/sda2).
I've been mulling over this for a while and can
On Thu, Feb 5, 2015 at 2:53 AM, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 2:51 AM, Paul E. McKenney
> wrote:
>> On Thu, Feb 05, 2015 at 02:18:01AM +0100, Sedat Dilek wrote:
>>> On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
>>> wrote:
>>> > On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dil
On Thu, Feb 5, 2015 at 2:51 AM, Paul E. McKenney
wrote:
> On Thu, Feb 05, 2015 at 02:18:01AM +0100, Sedat Dilek wrote:
>> On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
>> wrote:
>> > On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dilek wrote:
>> >> On Thu, Feb 5, 2015 at 1:10 AM, Paul E. McKe
On Thu, Feb 05, 2015 at 02:18:01AM +0100, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
> wrote:
> > On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dilek wrote:
> >> On Thu, Feb 5, 2015 at 1:10 AM, Paul E. McKenney
> >> wrote:
> >> > On Wed, Feb 04, 2015 at 03:51:15PM -08
On Thu, Feb 5, 2015 at 1:57 AM, Paul E. McKenney
wrote:
> On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dilek wrote:
>> On Thu, Feb 5, 2015 at 1:10 AM, Paul E. McKenney
>> wrote:
>> > On Wed, Feb 04, 2015 at 03:51:15PM -0800, Paul E. McKenney wrote:
>> >> On Wed, Feb 04, 2015 at 11:59:31PM +010
On Thu, Feb 05, 2015 at 01:30:45AM +0100, Sedat Dilek wrote:
> On Thu, Feb 5, 2015 at 1:10 AM, Paul E. McKenney
> wrote:
> > On Wed, Feb 04, 2015 at 03:51:15PM -0800, Paul E. McKenney wrote:
> >> On Wed, Feb 04, 2015 at 11:59:31PM +0100, Rafael J. Wysocki wrote:
> >> > On Wednesday, February 04, 2
On Thu, Feb 5, 2015 at 1:10 AM, Paul E. McKenney
wrote:
> On Wed, Feb 04, 2015 at 03:51:15PM -0800, Paul E. McKenney wrote:
>> On Wed, Feb 04, 2015 at 11:59:31PM +0100, Rafael J. Wysocki wrote:
>> > On Wednesday, February 04, 2015 01:53:58 PM Paul E. McKenney wrote:
>> > > On Wed, Feb 04, 2015 at
On Wed, Feb 04, 2015 at 03:51:15PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 04, 2015 at 11:59:31PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, February 04, 2015 01:53:58 PM Paul E. McKenney wrote:
> > > On Wed, Feb 04, 2015 at 10:54:07PM +0100, Rafael J. Wysocki wrote:
> > > > On Wednesda
On Thu, Feb 5, 2015 at 12:51 AM, Paul E. McKenney
wrote:
> On Wed, Feb 04, 2015 at 11:59:31PM +0100, Rafael J. Wysocki wrote:
>> On Wednesday, February 04, 2015 01:53:58 PM Paul E. McKenney wrote:
>> > On Wed, Feb 04, 2015 at 10:54:07PM +0100, Rafael J. Wysocki wrote:
>> > > On Wednesday, February
On Thu, Feb 5, 2015 at 12:25 AM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 11:38:40 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki
>> wrote:
>> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> >> On Wed, Feb 4, 2015 at 9:35 AM, Ste
On Wed, Feb 04, 2015 at 11:59:31PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 01:53:58 PM Paul E. McKenney wrote:
> > On Wed, Feb 04, 2015 at 10:54:07PM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
> > > > On Wed, Feb 4,
On Thu, Feb 5, 2015 at 12:30 AM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 11:46:32 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki
>> wrote:
>> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> >> On Wed, Feb 4, 2015 at 9:35 AM, Ste
On Wednesday, February 04, 2015 11:46:32 PM Sedat Dilek wrote:
> On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki wrote:
> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
> >> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
> >> wrote:
> >> > Hi all,
> >> >
> >> > The next re
On Wednesday, February 04, 2015 11:38:40 PM Sedat Dilek wrote:
> On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki wrote:
> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
> >> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
> >> wrote:
> >> > Hi all,
> >> >
> >> > The next re
On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> wrote:
>> > Hi all,
>> >
>> > The next release I will be making will be next-20150209 - which will
>> > probably be af
On Wed, Feb 4, 2015 at 10:54 PM, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
>> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> wrote:
>> > Hi all,
>> >
>> > The next release I will be making will be next-20150209 - which will
>> > probably be af
On Wednesday, February 04, 2015 01:53:58 PM Paul E. McKenney wrote:
> On Wed, Feb 04, 2015 at 10:54:07PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
> > > On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
> > > wrote:
> > > > Hi all,
> > > >
>
On Wed, Feb 04, 2015 at 10:54:07PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
> > On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
> > wrote:
> > > Hi all,
> > >
> > > The next release I will be making will be next-20150209 - which will
> > >
On Wednesday, February 04, 2015 09:18:03 PM Sedat Dilek wrote:
> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > The next release I will be making will be next-20150209 - which will
> > probably be after the v3.19 release.
> >
> > Changes since 20150203:
> >
> > The
On Wed, Feb 4, 2015 at 4:58 PM, Martin K. Petersen
wrote:
>> "Sedat" == Sedat Dilek writes:
>
>> I am seeing the following in my logs several times...
>>
>> Feb 4 02:53:13 fambox kernel: [15507.397482] blk_update_request:
>> I/O error, dev loop0, sector 21261344 Feb 4 02:53:13
> "Sedat" == Sedat Dilek writes:
> I am seeing the following in my logs several times...
>
> Feb 4 02:53:13 fambox kernel: [15507.397482] blk_update_request:
> I/O error, dev loop0, sector 21261344 Feb 4 02:53:13 fambox
> kernel: [15507.397531] loop0: DISCARD failed. Man
On Wed, Feb 4, 2015 at 4:31 PM, Jens Axboe wrote:
> On 02/04/2015 08:21 AM, Sedat Dilek wrote:
>>
>> On Wed, Feb 4, 2015 at 4:16 PM, Jens Axboe wrote:
>>>
>>> On 02/04/2015 05:26 AM, Sedat Dilek wrote:
On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
wrote:
>
>
>
On 02/04/2015 08:21 AM, Sedat Dilek wrote:
On Wed, Feb 4, 2015 at 4:16 PM, Jens Axboe wrote:
On 02/04/2015 05:26 AM, Sedat Dilek wrote:
On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
wrote:
Hi all,
The next release I will be making will be next-20150209 - which will
probably be after th
On Wed, Feb 4, 2015 at 4:16 PM, Jens Axboe wrote:
> On 02/04/2015 05:26 AM, Sedat Dilek wrote:
>>
>> On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell
>> wrote:
>>>
>>> Hi all,
>>>
>>> The next release I will be making will be next-20150209 - which will
>>> probably be after the v3.19 release.
>>>
On 02/04/2015 05:26 AM, Sedat Dilek wrote:
On Wed, Feb 4, 2015 at 9:35 AM, Stephen Rothwell wrote:
Hi all,
The next release I will be making will be next-20150209 - which will
probably be after the v3.19 release.
Changes since 20150203:
The sound-asoc tree gained a conflict against the sound
Hi all,
The next release I will be making will be next-20150209 - which will
probably be after the v3.19 release.
Changes since 20150203:
The sound-asoc tree gained a conflict against the sound tree.
The scsi tree gained a build failure caused by an interaction with the
driver-core tree. I app
Hi all,
On Tue, 4 Feb 2014 16:07:04 +1100 Stephen Rothwell
wrote:
>
> This tree fails (more than usual) the powerpc allyesconfig build.
>
> Changes since 20140203:
I forgot to mention the addition of the file-private-locks tree.
--
Cheers,
Stephen Rothwells...@canb.auug.o
Hi Paul,
On Tue, 4 Feb 2014 16:18:28 -0500 Paul Gortmaker
wrote:
>
> > The init tree lost a patch.
>
> I've sent the pull request to Linus for this, so you can drop it from next
> at your leisure.
Done.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpuBsjjFclNf.pgp
On 02/03/2014 09:07 PM, Stephen Rothwell wrote:
> Hi all,
>
> This tree fails (more than usual) the powerpc allyesconfig build.
>
> Changes since 20140203:
>
on i386:
# CONFIG_I2C is not set
CC [M] drivers/media/radio/si4713/radio-usb-si4713.o
drivers/media/radio/si4713/radio-usb-si4713.c:
Hi all,
This tree fails (more than usual) the powerpc allyesconfig build.
Changes since 20140203:
Dropped tree: parisc-hd
Undropped tree: btrfs
The parisc-hd tree gained conflicts against its rebased version in Linus'
tree, so I dropped it for today.
The powerpc tree still had its build failu
Hi James,
On Mon, 4 Feb 2013 13:56:32 + James Hogan wrote:
>
> On 4 February 2013 07:39, Stephen Rothwell wrote:
> > Merging signal/for-next (9005965 x86: convert to ksignal)
> > CONFLICT (content): Merge conflict in arch/x86/Kconfig
>
> I think this conflict has been resolved incorrectly.
Hi Stephen,
On 4 February 2013 07:39, Stephen Rothwell wrote:
> Merging signal/for-next (9005965 x86: convert to ksignal)
> CONFLICT (content): Merge conflict in arch/x86/Kconfig
I think this conflict has been resolved incorrectly.
Al's commit 1820f96 "burying unused conditionals" removed
GENER
Hi all,
Changes since 20130202:
The powerpc tree still had a build failure.
The nfsd tree still had its build failure so I used the version from
next-20130128.
The security tree gained a conflict against Linus' tree.
The tip tree lost its build failure.
The xen-two tree gained a build failure
65 matches
Mail list logo
