subject:"linux\-next\: Tree for Nov 14"

On 2014/11/16 11:22, Guenter Roeck wrote:
> On 11/15/2014 06:33 PM, Jiang Liu wrote:
>> Hi Guenter,
>> Could you please help to provide the config file and
>> error messages?
> 
> Config file:
> 
> https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig
> 
> 
> Error log:
> 
> http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio
> 
> 
> You can find the root file system used for the test as well as the test
> script at
> https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
> 
> There isn't really an error message, though - the boot stalls until the
> controlling daemon
> kills the qemu session.
Hi Guenter,
With the test suite at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
and configuration file qemu_x86_pc_nosmp_defconfig, I have
following findings:
1) disabling PCI_MSI, .
2) manually turning on X86_IO_APIC, .
3) with 3.16 kernel, disabling PCI_MSI, 
4) with 3.16 kernel, disabling PCI_MSI, enabling X86_UP_APIC, 

So the root cause is that KVM doesn't support the configuration with
LOCAL_APIC enabled but IO_APIC disabled, though this configuration
works with bare-metal machines.
There are two possible solutions here:
1) ALways enalbe IO_APIC if KVM is enabled.
2) Enhance KVM to support LOCAL_APIC when IOAPIC is disabled.

But I'm not familiar with KVM and don't know how to achieve solution 2.
Any suggestions?
Regards!
Gerry

> 
> Guenter
> 
>> Thanks!
>> Gerry
>>
>> On 2014/11/16 5:19, Guenter Roeck wrote:
>>> On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,

 Changes since 20141113:

 New tree: overlayfs

 The idle tree gained a conflict against Linus' tree.

 The scsi tree gained a conflict against the usb tree.

 Non-merge commits (relative to Linus' tree): 6264
   6509 files changed, 209171 insertions(+), 167101 deletions(-)

>>>
>>> I bisected the x86-nosmp qemu runtime failure I have seen for
>>> the last few days. Here is the result:
>>>
>>> bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
>>> commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
>>> Author: Jiang Liu 
>>> Date:   Mon Oct 27 16:12:06 2014 +0800
>>>
>>>  x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
>>>
>>> Detailed log:
>>>
>>> git bisect start 'HEAD' 'v3.18-rc4'
>>> # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge
>>> remote-tracking branch 'sound-asoc/for-next'
>>> git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
>>> # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge
>>> remote-tracking branch 'usb-serial/usb-next'
>>> git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
>>> # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge
>>> remote-tracking branch 'kvm/linux-next'
>>> git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
>>> # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge
>>> remote-tracking branch 'audit/next'
>>> git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
>>> # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch
>>> 'x86/vdso'
>>> git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
>>> # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch
>>> 'sched/urgent'
>>> git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
>>> # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch
>>> 'x86/boot'
>>> git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
>>> # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect
>>> __clear_irq_vector() with vector_lock
>>> git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
>>> # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use
>>> helpers to access irq_cfg data structure associated with IRQ
>>> git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
>>> # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT
>>> IRQ related code from io_apic.c into htirq.c
>>> git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
>>> # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI
>>> and HT_IRQ indepenent of X86_IO_APIC
>>> git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
>>> # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ
>>> initialization routines from io_apic.c into vector.c
>>> git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
>>> # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86,
>>> irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
>>>
>>> I'll be happy to provide the configuration if needed.
>>>
>>> Guenter
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: linux-next: Tree for Nov 14


On 11/16/2014 08:01 AM, Guenter Roeck wrote:

On 11/16/2014 12:24 AM, Jiang Liu wrote:

On 2014/11/16 14:56, Guenter Roeck wrote:

On 11/15/2014 08:20 PM, Jiang Liu wrote:


On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
  Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig


Hi Guenter,
 Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
  def_bool y
  depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
  select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?


I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran "make
savedefconfig".
"old" is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is "old".

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with "make savedefconfig", so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?


I can not turn on X86_IO_APIC manually. I have to enable one of the
following to do it.

 def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC

Since I want to build for 32 bit, I can not enable X86_64.
Since I want to build a uniprocessor image, I can not enable SMP.
X86_32_NON_STANDARD depends on SMP, so I can not enable it either.
X86_UP_IOAPIC depends on X86_UP_APIC which I can only enable by
disabling PCI_MSI.

So I disabled PCI_MSI and enabled X86_UP_IOAPIC as well as X86_IO_APIC.
The resulting image hangs completely with no console output whatsoever.



Additional data points: After reverting your patch on top of linux-next,
everything works fine. The working configuration has CONFIG_IRQ_DOMAIN,
CONFIG_X86_IO_APIC, CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS, and
CONFIG_ACPI_HOTPLUG_IOAPIC enabled. The non-working configuration
(with your patch applied) has all those disabled.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 11/16/2014 12:24 AM, Jiang Liu wrote:

On 2014/11/16 14:56, Guenter Roeck wrote:

On 11/15/2014 08:20 PM, Jiang Liu wrote:


On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
  Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig


Hi Guenter,
 Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
  def_bool y
  depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
  select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?


I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran "make
savedefconfig".
"old" is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is "old".

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with "make savedefconfig", so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?


I can not turn on X86_IO_APIC manually. I have to enable one of the
following to do it.

def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC

Since I want to build for 32 bit, I can not enable X86_64.
Since I want to build a uniprocessor image, I can not enable SMP.
X86_32_NON_STANDARD depends on SMP, so I can not enable it either.
X86_UP_IOAPIC depends on X86_UP_APIC which I can only enable by
disabling PCI_MSI.

So I disabled PCI_MSI and enabled X86_UP_IOAPIC as well as X86_IO_APIC.
The resulting image hangs completely with no console output whatsoever.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 11/16/2014 12:37 AM, Jiang Liu wrote:



On 2014/11/16 16:24, Jiang Liu wrote:

On 2014/11/16 14:56, Guenter Roeck wrote:

On 11/15/2014 08:20 PM, Jiang Liu wrote:

I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran "make
savedefconfig".
"old" is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is "old".

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with "make savedefconfig", so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?

Or could you please help to apply this patch?
http://patchwork.ozlabs.org/patch/408402/



That patch does not help, unfortunately. The problem is exactly the same
after applying it.

Guenter


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14



On 2014/11/16 16:24, Jiang Liu wrote:
> On 2014/11/16 14:56, Guenter Roeck wrote:
>> On 11/15/2014 08:20 PM, Jiang Liu wrote:
>>
>> I took the configuration file I had for the SMP case (located in the same
>> directory in the git repository), disabled SMP, and ran "make
>> savedefconfig".
>> "old" is relative in this context; I don't usually create new configuration
>> files for each new kernel release, so, yes, you could say that the file
>> I used is "old".
>>
>> CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
>> created with "make savedefconfig", so default settings are not included.
>> Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
>> surprising
>> since its dependencies are not met as far as I can see.
>>
>> Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
>> depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
>> set)
>> or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
>> depends on
>> !PCI_MSI).
>>
>> Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
>> support to work after your patch ?
> Hi Guenter,
>   Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
> With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
> If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
> should work theoretically. I remember it works on my HP laptop.
> Could you please help to check whether it solve the issue by manually
> turning on X86_IO_APIC?
Or could you please help to apply this patch?
http://patchwork.ozlabs.org/patch/408402/

> Thanks!
> Gerry
> 
>>
>> Thanks,
>> Guenter
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On 2014/11/16 14:56, Guenter Roeck wrote:
> On 11/15/2014 08:20 PM, Jiang Liu wrote:
>>
>> On 2014/11/16 11:22, Guenter Roeck wrote:
>>> On 11/15/2014 06:33 PM, Jiang Liu wrote:
 Hi Guenter,
  Could you please help to provide the config file and
 error messages?
>>>
>>> Config file:
>>> 
>>> https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig
>>>
>> Hi Guenter,
>> Thanks for help. According to the above configuration file:
>> CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
>> CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
>> is defined as:
>> config X86_LOCAL_APIC
>>  def_bool y
>>  depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
>> || PCI_MSI
>>  select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
>>
>> That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
>> enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
>> you using an old configuration file?
> 
> I took the configuration file I had for the SMP case (located in the same
> directory in the git repository), disabled SMP, and ran "make
> savedefconfig".
> "old" is relative in this context; I don't usually create new configuration
> files for each new kernel release, so, yes, you could say that the file
> I used is "old".
> 
> CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
> created with "make savedefconfig", so default settings are not included.
> Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
> surprising
> since its dependencies are not met as far as I can see.
> 
> Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
> depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
> set)
> or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
> depends on
> !PCI_MSI).
> 
> Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
> support to work after your patch ?
Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?
Thanks!
Gerry

> 
> Thanks,
> Guenter
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On 2014/11/16 14:56, Guenter Roeck wrote:
On 11/15/2014 08:20 PM, Jiang Liu wrote:

On 2014/11/16 11:22, Guenter Roeck wrote:
On 11/15/2014 06:33 PM, Jiang Liu wrote:
Hi Guenter,
Could you please help to provide the config file and
error messages?

Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

Hi Guenter,
Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
def_bool y
depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?

I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran make
savedefconfig.
old is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is old.

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with make savedefconfig, so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?
Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?
Thanks!
Gerry

Thanks,
Guenter

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14



On 2014/11/16 16:24, Jiang Liu wrote:
 On 2014/11/16 14:56, Guenter Roeck wrote:
 On 11/15/2014 08:20 PM, Jiang Liu wrote:

 I took the configuration file I had for the SMP case (located in the same
 directory in the git repository), disabled SMP, and ran make
 savedefconfig.
 old is relative in this context; I don't usually create new configuration
 files for each new kernel release, so, yes, you could say that the file
 I used is old.

 CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
 created with make savedefconfig, so default settings are not included.
 Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
 surprising
 since its dependencies are not met as far as I can see.

 Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
 depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
 set)
 or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
 depends on
 !PCI_MSI).

 Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
 support to work after your patch ?
 Hi Guenter,
   Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
 With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
 If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
 should work theoretically. I remember it works on my HP laptop.
 Could you please help to check whether it solve the issue by manually
 turning on X86_IO_APIC?
Or could you please help to apply this patch?
http://patchwork.ozlabs.org/patch/408402/

 Thanks!
 Gerry
 

 Thanks,
 Guenter

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 11/16/2014 12:37 AM, Jiang Liu wrote:



On 2014/11/16 16:24, Jiang Liu wrote:

On 2014/11/16 14:56, Guenter Roeck wrote:

On 11/15/2014 08:20 PM, Jiang Liu wrote:

I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran make
savedefconfig.
old is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is old.

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with make savedefconfig, so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?

Or could you please help to apply this patch?
http://patchwork.ozlabs.org/patch/408402/



That patch does not help, unfortunately. The problem is exactly the same
after applying it.

Guenter


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 11/16/2014 12:24 AM, Jiang Liu wrote:

On 2014/11/16 14:56, Guenter Roeck wrote:

On 11/15/2014 08:20 PM, Jiang Liu wrote:


On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
  Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig


Hi Guenter,
 Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
  def_bool y
  depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
  select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?


I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran make
savedefconfig.
old is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is old.

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with make savedefconfig, so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?


I can not turn on X86_IO_APIC manually. I have to enable one of the
following to do it.

def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC

Since I want to build for 32 bit, I can not enable X86_64.
Since I want to build a uniprocessor image, I can not enable SMP.
X86_32_NON_STANDARD depends on SMP, so I can not enable it either.
X86_UP_IOAPIC depends on X86_UP_APIC which I can only enable by
disabling PCI_MSI.

So I disabled PCI_MSI and enabled X86_UP_IOAPIC as well as X86_IO_APIC.
The resulting image hangs completely with no console output whatsoever.

Guenter

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 11/16/2014 08:01 AM, Guenter Roeck wrote:

On 11/16/2014 12:24 AM, Jiang Liu wrote:

On 2014/11/16 14:56, Guenter Roeck wrote:

On 11/15/2014 08:20 PM, Jiang Liu wrote:


On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
  Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig


Hi Guenter,
 Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
  def_bool y
  depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
  select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?


I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran make
savedefconfig.
old is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is old.

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with make savedefconfig, so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really
surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not
set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which
depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Hi Guenter,
Previously, X86_IO_APIC will be enabled if PCI_MSI is enabled.
With my patch, x86_IO_APIC may be disabled even if PCI_MSI is enabled.
If X86_LOCAL_APIC/PCI_MSI are enabled and X86_IO_APIC is disabled, it
should work theoretically. I remember it works on my HP laptop.
Could you please help to check whether it solve the issue by manually
turning on X86_IO_APIC?


I can not turn on X86_IO_APIC manually. I have to enable one of the
following to do it.

 def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC

Since I want to build for 32 bit, I can not enable X86_64.
Since I want to build a uniprocessor image, I can not enable SMP.
X86_32_NON_STANDARD depends on SMP, so I can not enable it either.
X86_UP_IOAPIC depends on X86_UP_APIC which I can only enable by
disabling PCI_MSI.

So I disabled PCI_MSI and enabled X86_UP_IOAPIC as well as X86_IO_APIC.
The resulting image hangs completely with no console output whatsoever.



Additional data points: After reverting your patch on top of linux-next,
everything works fine. The working configuration has CONFIG_IRQ_DOMAIN,
CONFIG_X86_IO_APIC, CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS, and
CONFIG_ACPI_HOTPLUG_IOAPIC enabled. The non-working configuration
(with your patch applied) has all those disabled.

Guenter

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On 2014/11/16 11:22, Guenter Roeck wrote:
 On 11/15/2014 06:33 PM, Jiang Liu wrote:
 Hi Guenter,
 Could you please help to provide the config file and
 error messages?
 
 Config file:
 
 https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig
 
 
 Error log:
 
 http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio
 
 
 You can find the root file system used for the test as well as the test
 script at
 https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
 
 There isn't really an error message, though - the boot stalls until the
 controlling daemon
 kills the qemu session.
Hi Guenter,
With the test suite at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
and configuration file qemu_x86_pc_nosmp_defconfig, I have
following findings:
1) disabling PCI_MSI, OK.
2) manually turning on X86_IO_APIC, OK.
3) with 3.16 kernel, disabling PCI_MSI, OK
4) with 3.16 kernel, disabling PCI_MSI, enabling X86_UP_APIC, fail

So the root cause is that KVM doesn't support the configuration with
LOCAL_APIC enabled but IO_APIC disabled, though this configuration
works with bare-metal machines.
There are two possible solutions here:
1) ALways enalbe IO_APIC if KVM is enabled.
2) Enhance KVM to support LOCAL_APIC when IOAPIC is disabled.

But I'm not familiar with KVM and don't know how to achieve solution 2.
Any suggestions?
Regards!
Gerry

 
 Guenter
 
 Thanks!
 Gerry

 On 2014/11/16 5:19, Guenter Roeck wrote:
 On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,

 Changes since 20141113:

 New tree: overlayfs

 The idle tree gained a conflict against Linus' tree.

 The scsi tree gained a conflict against the usb tree.

 Non-merge commits (relative to Linus' tree): 6264
   6509 files changed, 209171 insertions(+), 167101 deletions(-)


 I bisected the x86-nosmp qemu runtime failure I have seen for
 the last few days. Here is the result:

 bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
 commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
 Author: Jiang Liu jiang@linux.intel.com
 Date:   Mon Oct 27 16:12:06 2014 +0800

  x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

 Detailed log:

 git bisect start 'HEAD' 'v3.18-rc4'
 # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge
 remote-tracking branch 'sound-asoc/for-next'
 git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
 # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge
 remote-tracking branch 'usb-serial/usb-next'
 git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
 # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge
 remote-tracking branch 'kvm/linux-next'
 git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
 # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge
 remote-tracking branch 'audit/next'
 git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
 # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch
 'x86/vdso'
 git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
 # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch
 'sched/urgent'
 git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
 # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch
 'x86/boot'
 git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
 # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect
 __clear_irq_vector() with vector_lock
 git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
 # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use
 helpers to access irq_cfg data structure associated with IRQ
 git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
 # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT
 IRQ related code from io_apic.c into htirq.c
 git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
 # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI
 and HT_IRQ indepenent of X86_IO_APIC
 git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
 # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ
 initialization routines from io_apic.c into vector.c
 git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
 # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86,
 irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

 I'll be happy to provide the configuration if needed.

 Guenter
 -- 
 To unsubscribe from this list: send the line unsubscribe
 linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On 11/15/2014 08:20 PM, Jiang Liu wrote:

On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
Could you please help to provide the config file and
error messages?

Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?

I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran "make savedefconfig".
"old" is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is "old".

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with "make savedefconfig", so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 2014/11/16 11:22, Guenter Roeck wrote:
> On 11/15/2014 06:33 PM, Jiang Liu wrote:
>> Hi Guenter,
>> Could you please help to provide the config file and
>> error messages?
> 
> Config file:
> 
> https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig
Hi Guenter,
Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
def_bool y
depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?
Thanks!
Gerry

> 
> 
> Error log:
> 
> http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio
> 
> 
> You can find the root file system used for the test as well as the test
> script at
> https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
> 
> There isn't really an error message, though - the boot stalls until the
> controlling daemon
> kills the qemu session.
> 
> Guenter
> 
>> Thanks!
>> Gerry
>>
>> On 2014/11/16 5:19, Guenter Roeck wrote:
>>> On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,

 Changes since 20141113:

 New tree: overlayfs

 The idle tree gained a conflict against Linus' tree.

 The scsi tree gained a conflict against the usb tree.

 Non-merge commits (relative to Linus' tree): 6264
   6509 files changed, 209171 insertions(+), 167101 deletions(-)

>>>
>>> I bisected the x86-nosmp qemu runtime failure I have seen for
>>> the last few days. Here is the result:
>>>
>>> bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
>>> commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
>>> Author: Jiang Liu 
>>> Date:   Mon Oct 27 16:12:06 2014 +0800
>>>
>>>  x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
>>>
>>> Detailed log:
>>>
>>> git bisect start 'HEAD' 'v3.18-rc4'
>>> # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge
>>> remote-tracking branch 'sound-asoc/for-next'
>>> git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
>>> # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge
>>> remote-tracking branch 'usb-serial/usb-next'
>>> git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
>>> # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge
>>> remote-tracking branch 'kvm/linux-next'
>>> git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
>>> # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge
>>> remote-tracking branch 'audit/next'
>>> git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
>>> # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch
>>> 'x86/vdso'
>>> git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
>>> # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch
>>> 'sched/urgent'
>>> git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
>>> # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch
>>> 'x86/boot'
>>> git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
>>> # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect
>>> __clear_irq_vector() with vector_lock
>>> git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
>>> # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use
>>> helpers to access irq_cfg data structure associated with IRQ
>>> git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
>>> # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT
>>> IRQ related code from io_apic.c into htirq.c
>>> git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
>>> # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI
>>> and HT_IRQ indepenent of X86_IO_APIC
>>> git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
>>> # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ
>>> initialization routines from io_apic.c into vector.c
>>> git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
>>> # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86,
>>> irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
>>>
>>> I'll be happy to provide the configuration if needed.
>>>
>>> Guenter
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To

Re: linux-next: Tree for Nov 14


On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

Error log:

http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio

You can find the root file system used for the test as well as the test script 
at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86

There isn't really an error message, though - the boot stalls until the 
controlling daemon
kills the qemu session.

Guenter


Thanks!
Gerry

On 2014/11/16 5:19, Guenter Roeck wrote:

On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:

Hi all,

Changes since 20141113:

New tree: overlayfs

The idle tree gained a conflict against Linus' tree.

The scsi tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 6264
  6509 files changed, 209171 insertions(+), 167101 deletions(-)



I bisected the x86-nosmp qemu runtime failure I have seen for
the last few days. Here is the result:

bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
Author: Jiang Liu 
Date:   Mon Oct 27 16:12:06 2014 +0800

 x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

Detailed log:

git bisect start 'HEAD' 'v3.18-rc4'
# good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 
'sound-asoc/for-next'
git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
# bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 
'usb-serial/usb-next'
git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
# bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 
'kvm/linux-next'
git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
# good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 
'audit/next'
git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
# bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
# good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
# bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
# good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
__clear_irq_vector() with vector_lock
git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
# bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
access irq_cfg data structure associated with IRQ
git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
# good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
related code from io_apic.c into htirq.c
git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
# bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ 
indepenent of X86_IO_APIC
git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
# good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
initialization routines from io_apic.c into vector.c
git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
# first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
MSI and HT_IRQ indepenent of X86_IO_APIC

I'll be happy to provide the configuration if needed.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

Hi Guenter,
Could you please help to provide the config file and
error messages?
Thanks!
Gerry

On 2014/11/16 5:19, Guenter Roeck wrote:
> On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20141113:
>>
>> New tree: overlayfs
>>
>> The idle tree gained a conflict against Linus' tree.
>>
>> The scsi tree gained a conflict against the usb tree.
>>
>> Non-merge commits (relative to Linus' tree): 6264
>>  6509 files changed, 209171 insertions(+), 167101 deletions(-)
>>
> 
> I bisected the x86-nosmp qemu runtime failure I have seen for
> the last few days. Here is the result:
> 
> bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
> commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
> Author: Jiang Liu 
> Date:   Mon Oct 27 16:12:06 2014 +0800
> 
> x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
> 
> Detailed log:
> 
> git bisect start 'HEAD' 'v3.18-rc4'
> # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking 
> branch 'sound-asoc/for-next'
> git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
> # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking 
> branch 'usb-serial/usb-next'
> git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
> # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking 
> branch 'kvm/linux-next'
> git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
> # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking 
> branch 'audit/next'
> git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
> # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
> git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
> # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
> git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
> # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
> git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
> # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
> __clear_irq_vector() with vector_lock
> git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
> # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
> access irq_cfg data structure associated with IRQ
> git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
> # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
> related code from io_apic.c into htirq.c
> git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
> # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and 
> HT_IRQ indepenent of X86_IO_APIC
> git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
> # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
> initialization routines from io_apic.c into vector.c
> git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
> # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
> MSI and HT_IRQ indepenent of X86_IO_APIC
> 
> I'll be happy to provide the configuration if needed.
> 
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20141113:
> 
> New tree: overlayfs
> 
> The idle tree gained a conflict against Linus' tree.
> 
> The scsi tree gained a conflict against the usb tree.
> 
> Non-merge commits (relative to Linus' tree): 6264
>  6509 files changed, 209171 insertions(+), 167101 deletions(-)
> 

I bisected the x86-nosmp qemu runtime failure I have seen for
the last few days. Here is the result:

bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
Author: Jiang Liu 
Date:   Mon Oct 27 16:12:06 2014 +0800

x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

Detailed log:

git bisect start 'HEAD' 'v3.18-rc4'
# good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 
'sound-asoc/for-next'
git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
# bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 
'usb-serial/usb-next'
git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
# bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 
'kvm/linux-next'
git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
# good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 
'audit/next'
git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
# bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
# good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
# bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
# good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
__clear_irq_vector() with vector_lock
git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
# bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
access irq_cfg data structure associated with IRQ
git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
# good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
related code from io_apic.c into htirq.c
git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
# bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ 
indepenent of X86_IO_APIC
git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
# good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
initialization routines from io_apic.c into vector.c
git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
# first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
MSI and HT_IRQ indepenent of X86_IO_APIC

I'll be happy to provide the configuration if needed.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20141113:
 
 New tree: overlayfs
 
 The idle tree gained a conflict against Linus' tree.
 
 The scsi tree gained a conflict against the usb tree.
 
 Non-merge commits (relative to Linus' tree): 6264
  6509 files changed, 209171 insertions(+), 167101 deletions(-)
 

I bisected the x86-nosmp qemu runtime failure I have seen for
the last few days. Here is the result:

bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
Author: Jiang Liu jiang@linux.intel.com
Date:   Mon Oct 27 16:12:06 2014 +0800

x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

Detailed log:

git bisect start 'HEAD' 'v3.18-rc4'
# good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 
'sound-asoc/for-next'
git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
# bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 
'usb-serial/usb-next'
git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
# bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 
'kvm/linux-next'
git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
# good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 
'audit/next'
git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
# bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
# good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
# bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
# good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
__clear_irq_vector() with vector_lock
git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
# bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
access irq_cfg data structure associated with IRQ
git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
# good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
related code from io_apic.c into htirq.c
git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
# bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ 
indepenent of X86_IO_APIC
git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
# good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
initialization routines from io_apic.c into vector.c
git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
# first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
MSI and HT_IRQ indepenent of X86_IO_APIC

I'll be happy to provide the configuration if needed.

Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

Hi Guenter,
Could you please help to provide the config file and
error messages?
Thanks!
Gerry

On 2014/11/16 5:19, Guenter Roeck wrote:
 On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,

 Changes since 20141113:

 New tree: overlayfs

 The idle tree gained a conflict against Linus' tree.

 The scsi tree gained a conflict against the usb tree.

 Non-merge commits (relative to Linus' tree): 6264
  6509 files changed, 209171 insertions(+), 167101 deletions(-)

 
 I bisected the x86-nosmp qemu runtime failure I have seen for
 the last few days. Here is the result:
 
 bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
 commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
 Author: Jiang Liu jiang@linux.intel.com
 Date:   Mon Oct 27 16:12:06 2014 +0800
 
 x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
 
 Detailed log:
 
 git bisect start 'HEAD' 'v3.18-rc4'
 # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking 
 branch 'sound-asoc/for-next'
 git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
 # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking 
 branch 'usb-serial/usb-next'
 git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
 # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking 
 branch 'kvm/linux-next'
 git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
 # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking 
 branch 'audit/next'
 git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
 # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
 git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
 # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
 git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
 # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
 git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
 # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
 __clear_irq_vector() with vector_lock
 git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
 # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
 access irq_cfg data structure associated with IRQ
 git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
 # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
 related code from io_apic.c into htirq.c
 git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
 # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and 
 HT_IRQ indepenent of X86_IO_APIC
 git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
 # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
 initialization routines from io_apic.c into vector.c
 git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
 # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
 MSI and HT_IRQ indepenent of X86_IO_APIC
 
 I'll be happy to provide the configuration if needed.
 
 Guenter
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

Error log:

http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio

You can find the root file system used for the test as well as the test script 
at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86

There isn't really an error message, though - the boot stalls until the 
controlling daemon
kills the qemu session.

Guenter


Thanks!
Gerry

On 2014/11/16 5:19, Guenter Roeck wrote:

On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:

Hi all,

Changes since 20141113:

New tree: overlayfs

The idle tree gained a conflict against Linus' tree.

The scsi tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 6264
  6509 files changed, 209171 insertions(+), 167101 deletions(-)



I bisected the x86-nosmp qemu runtime failure I have seen for
the last few days. Here is the result:

bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
Author: Jiang Liu jiang@linux.intel.com
Date:   Mon Oct 27 16:12:06 2014 +0800

 x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

Detailed log:

git bisect start 'HEAD' 'v3.18-rc4'
# good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 
'sound-asoc/for-next'
git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
# bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 
'usb-serial/usb-next'
git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
# bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 
'kvm/linux-next'
git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
# good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 
'audit/next'
git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
# bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
# good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
# bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
# good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
__clear_irq_vector() with vector_lock
git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
# bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
access irq_cfg data structure associated with IRQ
git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
# good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
related code from io_apic.c into htirq.c
git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
# bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ 
indepenent of X86_IO_APIC
git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
# good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
initialization routines from io_apic.c into vector.c
git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
# first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
MSI and HT_IRQ indepenent of X86_IO_APIC

I'll be happy to provide the configuration if needed.

Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


On 2014/11/16 11:22, Guenter Roeck wrote:
 On 11/15/2014 06:33 PM, Jiang Liu wrote:
 Hi Guenter,
 Could you please help to provide the config file and
 error messages?
 
 Config file:
 
 https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig
Hi Guenter,
Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
def_bool y
depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?
Thanks!
Gerry

 
 
 Error log:
 
 http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio
 
 
 You can find the root file system used for the test as well as the test
 script at
 https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
 
 There isn't really an error message, though - the boot stalls until the
 controlling daemon
 kills the qemu session.
 
 Guenter
 
 Thanks!
 Gerry

 On 2014/11/16 5:19, Guenter Roeck wrote:
 On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,

 Changes since 20141113:

 New tree: overlayfs

 The idle tree gained a conflict against Linus' tree.

 The scsi tree gained a conflict against the usb tree.

 Non-merge commits (relative to Linus' tree): 6264
   6509 files changed, 209171 insertions(+), 167101 deletions(-)


 I bisected the x86-nosmp qemu runtime failure I have seen for
 the last few days. Here is the result:

 bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
 commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
 Author: Jiang Liu jiang@linux.intel.com
 Date:   Mon Oct 27 16:12:06 2014 +0800

  x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

 Detailed log:

 git bisect start 'HEAD' 'v3.18-rc4'
 # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge
 remote-tracking branch 'sound-asoc/for-next'
 git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
 # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge
 remote-tracking branch 'usb-serial/usb-next'
 git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
 # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge
 remote-tracking branch 'kvm/linux-next'
 git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
 # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge
 remote-tracking branch 'audit/next'
 git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
 # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch
 'x86/vdso'
 git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
 # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch
 'sched/urgent'
 git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
 # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch
 'x86/boot'
 git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
 # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect
 __clear_irq_vector() with vector_lock
 git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
 # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use
 helpers to access irq_cfg data structure associated with IRQ
 git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
 # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT
 IRQ related code from io_apic.c into htirq.c
 git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
 # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI
 and HT_IRQ indepenent of X86_IO_APIC
 git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
 # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ
 initialization routines from io_apic.c into vector.c
 git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
 # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86,
 irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

 I'll be happy to provide the configuration if needed.

 Guenter
 -- 
 To unsubscribe from this list: send the line unsubscribe
 linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


 
 -- 
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On 11/15/2014 08:20 PM, Jiang Liu wrote:

On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
Could you please help to provide the config file and
error messages?

Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?

I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran make savedefconfig.
old is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is old.

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with make savedefconfig, so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Thanks,
Guenter

linux-next: Tree for Nov 14

2014-11-14 Thread Stephen Rothwell

Hi all,

Changes since 20141113:

New tree: overlayfs

The idle tree gained a conflict against Linus' tree.

The scsi tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 6264
 6509 files changed, 209171 insertions(+), 167101 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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" and checkout or reset to the new
master.

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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 229 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (2c54396e40c7 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (9ff0bb5ba606 ARM: 8180/1: mm: implement no-highmem 
fast path in kmap_atomic_pfn())
Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/fixes (8a97577a5967 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux)
Merging sparc/master (ab5c780913bc sparc64: Do irq_{enter,exit}() around 
generic_smp_call_function*().)
Merging net/master (19ca9fc1445b vxlan: Do not reuse sockets for a different 
address family)
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (3542aed74809 ALSA: hda - Add mute LED control 
for Lenovo Ideapad Z560)
Merging pci-current/for-linus (7a1562d4f2d0 PCI: Apply _HPX Link Control 
settings to all devices with a link)
Merging wireless/master (4e6ce4dc7ce7 ath9k: Fix RTC_DERIVED_CLK usage)
Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging tty.current/tty-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging usb.current/usb-linus (2aea83a484fc Merge tag 'fixes-for-v3.18-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code)
Merging usb-serial-fixes/usb-linus (ffcfe30ebd8d USB: serial: cp210x: add IDs 
for CEL MeshConnect USB Stick)
Merging staging.current/staging-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3)
Merging input-current/for-linus (4ab8f7f320f9 Input: alps - ignore potential 
bare packets when device is out of sync)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read 
API and fix stack corruption)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (a87fa1d81a9f of: Fix overflow bug 
in string property parsing functions)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (7069a97a1415 selftests/net: move test out of 
Makefile into a shell script)
Merging drm-intel-fixes/for-linux-next-fixes (e9d784d535e4

linux-next: Tree for Nov 14

2014-11-14 Thread Stephen Rothwell

Hi all,

Changes since 20141113:

New tree: overlayfs

The idle tree gained a conflict against Linus' tree.

The scsi tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 6264
 6509 files changed, 209171 insertions(+), 167101 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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 and checkout or reset to the new
master.

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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 229 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (2c54396e40c7 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (9ff0bb5ba606 ARM: 8180/1: mm: implement no-highmem 
fast path in kmap_atomic_pfn())
Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/fixes (8a97577a5967 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux)
Merging sparc/master (ab5c780913bc sparc64: Do irq_{enter,exit}() around 
generic_smp_call_function*().)
Merging net/master (19ca9fc1445b vxlan: Do not reuse sockets for a different 
address family)
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (3542aed74809 ALSA: hda - Add mute LED control 
for Lenovo Ideapad Z560)
Merging pci-current/for-linus (7a1562d4f2d0 PCI: Apply _HPX Link Control 
settings to all devices with a link)
Merging wireless/master (4e6ce4dc7ce7 ath9k: Fix RTC_DERIVED_CLK usage)
Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging tty.current/tty-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging usb.current/usb-linus (2aea83a484fc Merge tag 'fixes-for-v3.18-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code)
Merging usb-serial-fixes/usb-linus (ffcfe30ebd8d USB: serial: cp210x: add IDs 
for CEL MeshConnect USB Stick)
Merging staging.current/staging-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3)
Merging input-current/for-linus (4ab8f7f320f9 Input: alps - ignore potential 
bare packets when device is out of sync)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard 
stripe)
Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read 
API and fix stack corruption)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (a87fa1d81a9f of: Fix overflow bug 
in string property parsing functions)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (7069a97a1415 selftests/net: move test out of 
Makefile into a shell script)
Merging drm-intel-fixes/for-linux-next-fixes (e9d784d535e4 drm/i915:

RE: linux-next: Tree for Nov 14 (lustre)

2013-11-14 Thread Peng, Tao



>-Original Message-
>From: Randy Dunlap [mailto:rdun...@infradead.org]
>Sent: Friday, November 15, 2013 3:04 AM
>To: Stephen Rothwell; linux-n...@vger.kernel.org
>Cc: LKML; peng tao; Peng, Tao; Greg Kroah-Hartman;
>andreas.dil...@intel.com; hpdd-discuss
>Subject: Re: linux-next: Tree for Nov 14 (lustre)
>
>On 11/13/13 20:22, Stephen Rothwell wrote:
>> Hi all,
>>
>> Please do *not* add any v3.14 material to linux-next until after
>> v3.13-rc1 is released.
>>
>> Changes since 20131113:
>>
>
>Please fix MANY build errors that show up when CONFIG_PROC_FS is not
>enabled.
>
I'll look into this.

Thanks,
Tao

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: linux-next: Tree for Nov 14 (lustre)

2013-11-14 Thread Randy Dunlap

On 11/13/13 20:22, Stephen Rothwell wrote:
> Hi all,
> 
> Please do *not* add any v3.14 material to linux-next until after
> v3.13-rc1 is released.
> 
> Changes since 20131113:
> 

Please fix MANY build errors that show up when CONFIG_PROC_FS is not enabled.

thanks.
-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14 (lustre)

2013-11-14 Thread Randy Dunlap

On 11/13/13 20:22, Stephen Rothwell wrote:
 Hi all,
 
 Please do *not* add any v3.14 material to linux-next until after
 v3.13-rc1 is released.
 
 Changes since 20131113:
 

Please fix MANY build errors that show up when CONFIG_PROC_FS is not enabled.

thanks.
-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: Tree for Nov 14 (lustre)

2013-11-14 Thread Peng, Tao



-Original Message-
From: Randy Dunlap [mailto:rdun...@infradead.org]
Sent: Friday, November 15, 2013 3:04 AM
To: Stephen Rothwell; linux-n...@vger.kernel.org
Cc: LKML; peng tao; Peng, Tao; Greg Kroah-Hartman;
andreas.dil...@intel.com; hpdd-discuss
Subject: Re: linux-next: Tree for Nov 14 (lustre)

On 11/13/13 20:22, Stephen Rothwell wrote:
 Hi all,

 Please do *not* add any v3.14 material to linux-next until after
 v3.13-rc1 is released.

 Changes since 20131113:


Please fix MANY build errors that show up when CONFIG_PROC_FS is not
enabled.

I'll look into this.

Thanks,
Tao

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

linux-next: Tree for Nov 14

2013-11-13 Thread Stephen Rothwell

Hi all,

Please do *not* add any v3.14 material to linux-next until after
v3.13-rc1 is released.

Changes since 20131113:

The akpm tree lost a patch that turned up elsewhere.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 29 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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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 Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (42a2d923cc34 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next)
Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (737d5b980be8 ARC: [plat-arcfpga] defconfig update)
Merging arm-current/fixes (6ecf830e5029 ARM: 7880/1: Clear the IT state 
independent of the Thumb-2 mode)
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/Kconfig
Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated 
IRQF_DISABLED)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq 
stack from softirq stack)
Merging sparc/master (6d15ee492809 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging net/master (42a2d923cc34 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next)
Merging ipsec/master (be408cd3e1fe Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (44832a71f377 ALSA: usb-audio: add front jack 
channel selector for EMU0204)
Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check 
earlier for MMCONFIG region at address zero")
Merging wireless/master (8e3ffa471091 prism54: set netdev type to "wlan")
Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6)
Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart 
selection for older products)
Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for 
Z3X Box device)
Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6)
Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6)
Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for 
model found on Dell XT2)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (f262f0f5cad0 crypto: s390 - Fix aes-cbc IV 
corruption)
CONFLICT (content): Merge conflict in drivers/crypto/caam/jr.c
Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros 
to inline functions)
Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: 
add initialization code for dma reserved memory")
Merging rr-fixes/fixes (f6537f2f0eba scripts/kallsyms: filter symbols not in 
kernel address space)
Merging mfd-fixes/master (d0e639c9e06d Linux 3.12-rc4)
Merging vfio-fixes/for-linus (d93b3ac0edb8 VFIO: vfio_iommu_type1: fix bug 
caused by break in nested loop)
Merging

linux-next: Tree for Nov 14

2013-11-13 Thread Stephen Rothwell

Hi all,

Please do *not* add any v3.14 material to linux-next until after
v3.13-rc1 is released.

Changes since 20131113:

The akpm tree lost a patch that turned up elsewhere.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 29 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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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 Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (42a2d923cc34 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next)
Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make make install 
not depend on vmlinux)
Merging arc-current/for-curr (737d5b980be8 ARC: [plat-arcfpga] defconfig update)
Merging arm-current/fixes (6ecf830e5029 ARM: 7880/1: Clear the IT state 
independent of the Thumb-2 mode)
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/Kconfig
Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated 
IRQF_DISABLED)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq 
stack from softirq stack)
Merging sparc/master (6d15ee492809 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging net/master (42a2d923cc34 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next)
Merging ipsec/master (be408cd3e1fe Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (44832a71f377 ALSA: usb-audio: add front jack 
channel selector for EMU0204)
Merging pci-current/for-linus (67d470e0e171 Revert x86/PCI: MMCONFIG: Check 
earlier for MMCONFIG region at address zero)
Merging wireless/master (8e3ffa471091 prism54: set netdev type to wlan)
Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6)
Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart 
selection for older products)
Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for 
Z3X Box device)
Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6)
Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6)
Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for 
model found on Dell XT2)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard 
stripe)
Merging crypto-current/master (f262f0f5cad0 crypto: s390 - Fix aes-cbc IV 
corruption)
CONFLICT (content): Merge conflict in drivers/crypto/caam/jr.c
Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros 
to inline functions)
Merging devicetree-current/devicetree/merge (1931ee143b0a Revert drivers: of: 
add initialization code for dma reserved memory)
Merging rr-fixes/fixes (f6537f2f0eba scripts/kallsyms: filter symbols not in 
kernel address space)
Merging mfd-fixes/master (d0e639c9e06d Linux 3.12-rc4)
Merging vfio-fixes/for-linus (d93b3ac0edb8 VFIO: vfio_iommu_type1: fix bug 
caused by break in nested loop)
Merging

Re: linux-next: Tree for Nov 14

2012-11-15 Thread Mel Gorman

On Wed, Nov 14, 2012 at 12:05:15PM -0500, Rik van Riel wrote:
> On 11/14/2012 03:13 AM, Hugh Dickins wrote:
> 
> >Please, Ingo, stop trying to force this in ahead of time, yet again.
> >
> >People are still reviewing and comparing competing solutions.
> >Maybe this latest will prove to be closest to the right answer,
> >maybe it will not.  It's, what, about two days old right now?
> >
> >If we had wanted to push in a good solution a little prematurely,
> >we would surely have chosen Andrea's AutoNUMA months ago, despite
> >efforts to block it; and maybe we shall still want to go that way.
> 
> As much as I would like to see NUMA stuff going upstream
> the day before yesterday, I have to agree with Hugh that
> we need to do things right.
> 

After my last test of tests against schednuma I have to agree. While the
differences we see in different tests could be explained by different JVM
configurations, it does not tell us *why* they performed differently. Because
of the monolithic nature of some of the patches it's non-trivial to
establish which part is causing the problems.  I still have not got
around to sending the latest schednuma through a spidey decoder ring to
see exactly how it works.  FWIW the idea that is described sounds great.

> Having unreviewed (some of it NAKed) code sitting in
> tip.git and you trying to force it upstream is not the
> right way to go.
> 
> >Please, forget about v3.8, cut this branch out of linux-next,
> >and seek consensus around getting it right for v3.9.
> 
> I suspect that no matter how long we delay merging the
> NUMA placement code, we will always run into some kind
> of regression. I am not sure if a delay will buy us much.
> 
> On the mm/ bits, there appears to be consensus already.
> Mel Gorman's patch series contains the nicest mm/ bits
> from autonuma and sched/numa, plus further improvements.
> Andrea has supported Mel's series, and Ingo is pulling
> code from it.
> 
> That leads me to believe Mel's NUMA bits may be worth
> considering for 3.8.
> 

I still think the series is not fully baked.  I'm still working on getting
some of the basics right and getting the System CPU usage down which right
now is through the roof. It's going to take me time and while I think I'll
have something working semi-properly by 3.8 rolls around I severely doubt
it'll have seen any wide-spread testing.  My preference is the final result
be sortof comparable with autonumas performance but satisfy the scheduler
folk in terms of how it integrates with kernel/sched/* and not use kernel
threads except as a last resort.

Big chunks are still missing. No knob for turning off from command line,
no THP native migration (getting the simple case right first), placement
policy is still extremely heavy (was run in kernel thread context before and
needs to change now), page struct elements are not folded into page->flags,
task_struct has fields that should move to task_struct->task_balancenuma,
no docs etc etc etc.

> On top of that, we could place the policy code by
> Peter and Ingo, but as a nice reviewable patch series,
> not hidden away through various tip.git branches.
> 
> Does a combination of Mel's NUMA mm/ bits and the
> policy code from Peter and Ingo sound reasonable?
> 
> Mel, is that reasonable to you?
> 

It'd be reasonable to me. Preferably patches would affect individual areas
rather than being a large patch affecting multiple areas. As well as being
easier to comprehend, we can also bisect the result. To me, the obvious
discrete areas that a single patch would affect are

1. The PTE update helper functions
2. The PTE scanning machinary driven from task_numa_tick
3. Task and process fault accounting and how that information is used
   to determine if a page is misplaced
4. Fault handling, migrating the page if misplaced, what information is
   provided to the placement policy

Obviously that is not always possible.

Thanks to the kernel.org folk I have a git tree at

git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux-balancenuma.git

The mm-balancenuma-v1r15[*] and mm-balancenuma-v2r45 branches correspond to
the V1 and V2 series I released. I've pushed a mm-balancenuma-v3r22-snapshot
branch which is unreleased but shows where the tree currently stands.
Almost nothing in there after the initial placement policy has been tested
at all but it shows the initial adjustment to how PMD faults are handled
and some preliminary migration rate-limiting code. The same patches when
complete should be usable by schednuma be it due to a rebase on top or
because they pull the patches in and adjust them accordingly.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-15 Thread Mel Gorman

On Wed, Nov 14, 2012 at 12:05:15PM -0500, Rik van Riel wrote:
 On 11/14/2012 03:13 AM, Hugh Dickins wrote:
 
 Please, Ingo, stop trying to force this in ahead of time, yet again.
 
 People are still reviewing and comparing competing solutions.
 Maybe this latest will prove to be closest to the right answer,
 maybe it will not.  It's, what, about two days old right now?
 
 If we had wanted to push in a good solution a little prematurely,
 we would surely have chosen Andrea's AutoNUMA months ago, despite
 efforts to block it; and maybe we shall still want to go that way.
 
 As much as I would like to see NUMA stuff going upstream
 the day before yesterday, I have to agree with Hugh that
 we need to do things right.
 

After my last test of tests against schednuma I have to agree. While the
differences we see in different tests could be explained by different JVM
configurations, it does not tell us *why* they performed differently. Because
of the monolithic nature of some of the patches it's non-trivial to
establish which part is causing the problems.  I still have not got
around to sending the latest schednuma through a spidey decoder ring to
see exactly how it works.  FWIW the idea that is described sounds great.

 Having unreviewed (some of it NAKed) code sitting in
 tip.git and you trying to force it upstream is not the
 right way to go.
 
 Please, forget about v3.8, cut this branch out of linux-next,
 and seek consensus around getting it right for v3.9.
 
 I suspect that no matter how long we delay merging the
 NUMA placement code, we will always run into some kind
 of regression. I am not sure if a delay will buy us much.
 
 On the mm/ bits, there appears to be consensus already.
 Mel Gorman's patch series contains the nicest mm/ bits
 from autonuma and sched/numa, plus further improvements.
 Andrea has supported Mel's series, and Ingo is pulling
 code from it.
 
 That leads me to believe Mel's NUMA bits may be worth
 considering for 3.8.
 

I still think the series is not fully baked.  I'm still working on getting
some of the basics right and getting the System CPU usage down which right
now is through the roof. It's going to take me time and while I think I'll
have something working semi-properly by 3.8 rolls around I severely doubt
it'll have seen any wide-spread testing.  My preference is the final result
be sortof comparable with autonumas performance but satisfy the scheduler
folk in terms of how it integrates with kernel/sched/* and not use kernel
threads except as a last resort.

Big chunks are still missing. No knob for turning off from command line,
no THP native migration (getting the simple case right first), placement
policy is still extremely heavy (was run in kernel thread context before and
needs to change now), page struct elements are not folded into page-flags,
task_struct has fields that should move to task_struct-task_balancenuma,
no docs etc etc etc.

 On top of that, we could place the policy code by
 Peter and Ingo, but as a nice reviewable patch series,
 not hidden away through various tip.git branches.
 
 Does a combination of Mel's NUMA mm/ bits and the
 policy code from Peter and Ingo sound reasonable?
 
 Mel, is that reasonable to you?
 

It'd be reasonable to me. Preferably patches would affect individual areas
rather than being a large patch affecting multiple areas. As well as being
easier to comprehend, we can also bisect the result. To me, the obvious
discrete areas that a single patch would affect are

1. The PTE update helper functions
2. The PTE scanning machinary driven from task_numa_tick
3. Task and process fault accounting and how that information is used
   to determine if a page is misplaced
4. Fault handling, migrating the page if misplaced, what information is
   provided to the placement policy

Obviously that is not always possible.

Thanks to the kernel.org folk I have a git tree at

git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux-balancenuma.git

The mm-balancenuma-v1r15[*] and mm-balancenuma-v2r45 branches correspond to
the V1 and V2 series I released. I've pushed a mm-balancenuma-v3r22-snapshot
branch which is unreleased but shows where the tree currently stands.
Almost nothing in there after the initial placement policy has been tested
at all but it shows the initial adjustment to how PMD faults are handled
and some preliminary migration rate-limiting code. The same patches when
complete should be usable by schednuma be it due to a rebase on top or
because they pull the patches in and adjust them accordingly.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14 (gpu/drm/i915)

2012-11-14 Thread Andrew Morton

On Wed, 14 Nov 2012 11:41:49 -0800
Randy Dunlap  wrote:

> On 11/13/2012 09:30 PM, Stephen Rothwell wrote:
> 
> > Hi all,
> > 
> > News: next-20121115 (i.e. tomorrow) will be the last release until
> > next-20121126 (which should be just be after -rc7, I guess - assuming
> > that Linus does not release v3.7 before then), so if you want something
> > in linux-next for a reasonable amount of testing, it should probably be
> > committed tomorrow.
> > 
> > Changes since 20121113:
> > 
> 
> 
> 
> on i386:
> 
> ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!
> 
> Reference to that symbol is found in
> i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
> i915_gem_execbuffer.c:
> 
> static struct eb_objects *
> eb_create(int size)
> {
>   struct eb_objects *eb;
>   int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
>   BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
> 

Where to start.

- eb_create() has no business assuming that the hlist_head has any
  particular size.  We could easily add some conditionally-compiled
  debug fields in there, and drm blows up.

- The assertion is obviously true at present, so I assume that gcc
  screwed up and failed to reduce all that to a compile-time constant.

- We have a BUILD_BUG_ON_NOT_POWER_OF_2().  Use it?

- This code is using PAGE_SIZE to scale a kernel data structure. 
  PAGE_SIZE can vary by a factor of 16, depending on Kconfig.  This
  can result in 64k PAGE_SIZE machines exhibiting different beahviour
  from that which the testers saw.

  Don't do it.  It's better to hard-wire 4096.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14 (gpu/drm/i915)

2012-11-14 Thread Randy Dunlap

On 11/13/2012 09:30 PM, Stephen Rothwell wrote:

> Hi all,
> 
> News: next-20121115 (i.e. tomorrow) will be the last release until
> next-20121126 (which should be just be after -rc7, I guess - assuming
> that Linus does not release v3.7 before then), so if you want something
> in linux-next for a reasonable amount of testing, it should probably be
> committed tomorrow.
> 
> Changes since 20121113:
> 



on i386:

ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!

Reference to that symbol is found in
i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
i915_gem_execbuffer.c:

static struct eb_objects *
eb_create(int size)
{
struct eb_objects *eb;
int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-14 Thread Linus Torvalds

On Tue, Nov 13, 2012 at 10:56 PM, Andrew Morton
 wrote:
>
> That solves one problem, but I still need to route around the numa
> stuff when preparing the 3.8-rc1 merge.  Again!

Btw - and this is tangential/unrelated - I really think that your
should strive to *not* base -mm on top of next, but instead put it on
top of the release kernel.

The "on top of next" approach not only causes you continual problems
like the above, it also causes the (related) problem that your email
patch-bombs always tend to be fairly late in the merge window, because
you need to wait for the big parts of linux-next to have hit my tree.

So it's more work for you, and it actually causes merge problems for me too.

I realize that you want to test a "everything" kernel, but at the same
time, that's actually counter-productive. It means that your tree ends
up depending on others, and you have to fight bugs that aren't even
necessarily yours at all.

And in this particular case, it would be easier for the NUMA people,
since your patches would presumably contain Mel's work, so they could
more easily rebase on top of your work, rather than the current
situation which is ass-backwards and has fundamental odering problems:
you want to base your stuff on linux-next, people want to put their
numa stuff into linux-next, and you have a bad circle.

Of course, people who want to base their work on top of Mel's code
often are git users already, so now they'd want a stable git tree
(non-rebased) to work on top, so they'd have problems with -mm anyway.
I don't know if Mel is a git user at all (there are no commits in the
kernel tree that are done by Mel, but maybe Mel has used git
elsewhere), but in this case maybe it would be a possibility that
Mel's NUMA patches could be done as one single stable -git branch, and
come into -mm (and linux-next) that way?

So I really think it would be much nicer if you just did your tree
directly on top of mine, instead of on top of linux-next. It would
make everything easier for everybody.

Of course, if you then want to test the combined thing, that's fine,
but that merging is also something that git is pretty good at. You
could just check the linux-next tree itself, since then Stephen would
have done the merging for you.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-14 Thread Rik van Riel


On 11/14/2012 03:13 AM, Hugh Dickins wrote:


Please, Ingo, stop trying to force this in ahead of time, yet again.

People are still reviewing and comparing competing solutions.
Maybe this latest will prove to be closest to the right answer,
maybe it will not.  It's, what, about two days old right now?

If we had wanted to push in a good solution a little prematurely,
we would surely have chosen Andrea's AutoNUMA months ago, despite
efforts to block it; and maybe we shall still want to go that way.


As much as I would like to see NUMA stuff going upstream
the day before yesterday, I have to agree with Hugh that
we need to do things right.

Having unreviewed (some of it NAKed) code sitting in
tip.git and you trying to force it upstream is not the
right way to go.


Please, forget about v3.8, cut this branch out of linux-next,
and seek consensus around getting it right for v3.9.


I suspect that no matter how long we delay merging the
NUMA placement code, we will always run into some kind
of regression. I am not sure if a delay will buy us much.

On the mm/ bits, there appears to be consensus already.
Mel Gorman's patch series contains the nicest mm/ bits
from autonuma and sched/numa, plus further improvements.
Andrea has supported Mel's series, and Ingo is pulling
code from it.

That leads me to believe Mel's NUMA bits may be worth
considering for 3.8.

On top of that, we could place the policy code by
Peter and Ingo, but as a nice reviewable patch series,
not hidden away through various tip.git branches.

Does a combination of Mel's NUMA mm/ bits and the
policy code from Peter and Ingo sound reasonable?

Mel, is that reasonable to you?

Peter & Ingo, are you willing to rebase your policy
code on top of Mel's mm/ patches?

--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-14 Thread Hugh Dickins

On Wed, 14 Nov 2012, Ingo Molnar wrote:
> * Andrew Morton  wrote:
> > On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar  wrote:
> > > * Andrew Morton  wrote:
> > > > On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell 
> > > >  wrote:
> > > > 
> > > > > News: next-20121115 (i.e. tomorrow) will be the last release until
> > > > > next-20121126 (which should be just be after -rc7, I guess - assuming
> > > > > that Linus does not release v3.7 before then), so if you want 
> > > > > something
> > > > > in linux-next for a reasonable amount of testing, it should probably 
> > > > > be
> > > > > committed tomorrow.
> > > > 
> > > > It would help if the old sched/numa code wasn't in -next while 
> > > > you're away.  That would give me a clean run at 3.7 and will 
> > > > make it easier for others to integrate and test the four(!) 
> > > > different autoschednumacore implementations on top of 
> > > > linux-next.
> > > > 
> > > > Pretty please?
> > > 
> > > The next integration should have this solved: I have removed the 
> > > old sched/numa bits, replaced by the latest rebased/reworked 
> > > numa/core bits.
> > > 
> > 
> > That solves one problem, but I still need to route around the 
> > numa stuff when preparing the 3.8-rc1 merge.  Again!
> 
> I'm eyeing a v3.8 merge... modulo unforeseen problems. This has 
> been going on for way too long.
> 
> numa/core performs very well, and the rest can be done 
> iteratively.
> 
> The mm/ bits changed very little due to the latest rounds of 
> review. Most of the discussion centered around specific 
> implementational details and naming - and where we were wrong I 
> changed the code - numa/core sums up the consensus so far.
> 
> If I missed anything let me know and I'll fix the code ASAP ...

Please, Ingo, stop trying to force this in ahead of time, yet again.

People are still reviewing and comparing competing solutions.
Maybe this latest will prove to be closest to the right answer,
maybe it will not.  It's, what, about two days old right now?

If we had wanted to push in a good solution a little prematurely,
we would surely have chosen Andrea's AutoNUMA months ago, despite
efforts to block it; and maybe we shall still want to go that way.

Please, forget about v3.8, cut this branch out of linux-next,
and seek consensus around getting it right for v3.9.

I dislike speaking out in this way, because I'm well aware of
how very much more effort you and Peter and Andrea and Mel and
Rik and many others are making than I can manage - thank you all.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-14 Thread Hugh Dickins

On Wed, 14 Nov 2012, Ingo Molnar wrote:
 * Andrew Morton a...@linux-foundation.org wrote:
  On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar mi...@kernel.org wrote:
   * Andrew Morton a...@linux-foundation.org wrote:
On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell 
s...@canb.auug.org.au wrote:

 News: next-20121115 (i.e. tomorrow) will be the last release until
 next-20121126 (which should be just be after -rc7, I guess - assuming
 that Linus does not release v3.7 before then), so if you want 
 something
 in linux-next for a reasonable amount of testing, it should probably 
 be
 committed tomorrow.

It would help if the old sched/numa code wasn't in -next while 
you're away.  That would give me a clean run at 3.7 and will 
make it easier for others to integrate and test the four(!) 
different autoschednumacore implementations on top of 
linux-next.

Pretty please?
   
   The next integration should have this solved: I have removed the 
   old sched/numa bits, replaced by the latest rebased/reworked 
   numa/core bits.
   
  
  That solves one problem, but I still need to route around the 
  numa stuff when preparing the 3.8-rc1 merge.  Again!
 
 I'm eyeing a v3.8 merge... modulo unforeseen problems. This has 
 been going on for way too long.
 
 numa/core performs very well, and the rest can be done 
 iteratively.
 
 The mm/ bits changed very little due to the latest rounds of 
 review. Most of the discussion centered around specific 
 implementational details and naming - and where we were wrong I 
 changed the code - numa/core sums up the consensus so far.
 
 If I missed anything let me know and I'll fix the code ASAP ...

Please, Ingo, stop trying to force this in ahead of time, yet again.

People are still reviewing and comparing competing solutions.
Maybe this latest will prove to be closest to the right answer,
maybe it will not.  It's, what, about two days old right now?

If we had wanted to push in a good solution a little prematurely,
we would surely have chosen Andrea's AutoNUMA months ago, despite
efforts to block it; and maybe we shall still want to go that way.

Please, forget about v3.8, cut this branch out of linux-next,
and seek consensus around getting it right for v3.9.

I dislike speaking out in this way, because I'm well aware of
how very much more effort you and Peter and Andrea and Mel and
Rik and many others are making than I can manage - thank you all.

Hugh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-14 Thread Rik van Riel


On 11/14/2012 03:13 AM, Hugh Dickins wrote:


Please, Ingo, stop trying to force this in ahead of time, yet again.

People are still reviewing and comparing competing solutions.
Maybe this latest will prove to be closest to the right answer,
maybe it will not.  It's, what, about two days old right now?

If we had wanted to push in a good solution a little prematurely,
we would surely have chosen Andrea's AutoNUMA months ago, despite
efforts to block it; and maybe we shall still want to go that way.


As much as I would like to see NUMA stuff going upstream
the day before yesterday, I have to agree with Hugh that
we need to do things right.

Having unreviewed (some of it NAKed) code sitting in
tip.git and you trying to force it upstream is not the
right way to go.


Please, forget about v3.8, cut this branch out of linux-next,
and seek consensus around getting it right for v3.9.


I suspect that no matter how long we delay merging the
NUMA placement code, we will always run into some kind
of regression. I am not sure if a delay will buy us much.

On the mm/ bits, there appears to be consensus already.
Mel Gorman's patch series contains the nicest mm/ bits
from autonuma and sched/numa, plus further improvements.
Andrea has supported Mel's series, and Ingo is pulling
code from it.

That leads me to believe Mel's NUMA bits may be worth
considering for 3.8.

On top of that, we could place the policy code by
Peter and Ingo, but as a nice reviewable patch series,
not hidden away through various tip.git branches.

Does a combination of Mel's NUMA mm/ bits and the
policy code from Peter and Ingo sound reasonable?

Mel, is that reasonable to you?

Peter  Ingo, are you willing to rebase your policy
code on top of Mel's mm/ patches?

--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

2012-11-14 Thread Linus Torvalds

On Tue, Nov 13, 2012 at 10:56 PM, Andrew Morton
a...@linux-foundation.org wrote:

 That solves one problem, but I still need to route around the numa
 stuff when preparing the 3.8-rc1 merge.  Again!

Btw - and this is tangential/unrelated - I really think that your
should strive to *not* base -mm on top of next, but instead put it on
top of the release kernel.

The on top of next approach not only causes you continual problems
like the above, it also causes the (related) problem that your email
patch-bombs always tend to be fairly late in the merge window, because
you need to wait for the big parts of linux-next to have hit my tree.

So it's more work for you, and it actually causes merge problems for me too.

I realize that you want to test a everything kernel, but at the same
time, that's actually counter-productive. It means that your tree ends
up depending on others, and you have to fight bugs that aren't even
necessarily yours at all.

And in this particular case, it would be easier for the NUMA people,
since your patches would presumably contain Mel's work, so they could
more easily rebase on top of your work, rather than the current
situation which is ass-backwards and has fundamental odering problems:
you want to base your stuff on linux-next, people want to put their
numa stuff into linux-next, and you have a bad circle.

Of course, people who want to base their work on top of Mel's code
often are git users already, so now they'd want a stable git tree
(non-rebased) to work on top, so they'd have problems with -mm anyway.
I don't know if Mel is a git user at all (there are no commits in the
kernel tree that are done by Mel, but maybe Mel has used git
elsewhere), but in this case maybe it would be a possibility that
Mel's NUMA patches could be done as one single stable -git branch, and
come into -mm (and linux-next) that way?

So I really think it would be much nicer if you just did your tree
directly on top of mine, instead of on top of linux-next. It would
make everything easier for everybody.

Of course, if you then want to test the combined thing, that's fine,
but that merging is also something that git is pretty good at. You
could just check the linux-next tree itself, since then Stephen would
have done the merging for you.

  Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14 (gpu/drm/i915)

2012-11-14 Thread Randy Dunlap

On 11/13/2012 09:30 PM, Stephen Rothwell wrote:

 Hi all,
 
 News: next-20121115 (i.e. tomorrow) will be the last release until
 next-20121126 (which should be just be after -rc7, I guess - assuming
 that Linus does not release v3.7 before then), so if you want something
 in linux-next for a reasonable amount of testing, it should probably be
 committed tomorrow.
 
 Changes since 20121113:
 



on i386:

ERROR: __build_bug_on_failed [drivers/gpu/drm/i915/i915.ko] undefined!

Reference to that symbol is found in
i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
i915_gem_execbuffer.c:

static struct eb_objects *
eb_create(int size)
{
struct eb_objects *eb;
int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));


-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14 (gpu/drm/i915)

2012-11-14 Thread Andrew Morton

On Wed, 14 Nov 2012 11:41:49 -0800
Randy Dunlap rdun...@infradead.org wrote:

 On 11/13/2012 09:30 PM, Stephen Rothwell wrote:
 
  Hi all,
  
  News: next-20121115 (i.e. tomorrow) will be the last release until
  next-20121126 (which should be just be after -rc7, I guess - assuming
  that Linus does not release v3.7 before then), so if you want something
  in linux-next for a reasonable amount of testing, it should probably be
  committed tomorrow.
  
  Changes since 20121113:
  
 
 
 
 on i386:
 
 ERROR: __build_bug_on_failed [drivers/gpu/drm/i915/i915.ko] undefined!
 
 Reference to that symbol is found in
 i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
 i915_gem_execbuffer.c:
 
 static struct eb_objects *
 eb_create(int size)
 {
   struct eb_objects *eb;
   int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
   BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
 

Where to start.

- eb_create() has no business assuming that the hlist_head has any
  particular size.  We could easily add some conditionally-compiled
  debug fields in there, and drm blows up.

- The assertion is obviously true at present, so I assume that gcc
  screwed up and failed to reduce all that to a compile-time constant.

- We have a BUILD_BUG_ON_NOT_POWER_OF_2().  Use it?

- This code is using PAGE_SIZE to scale a kernel data structure. 
  PAGE_SIZE can vary by a factor of 16, depending on Kconfig.  This
  can result in 64k PAGE_SIZE machines exhibiting different beahviour
  from that which the testers saw.

  Don't do it.  It's better to hard-wire 4096.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


* Andrew Morton  wrote:

> On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar  wrote:
> 
> > 
> > * Andrew Morton  wrote:
> > 
> > > On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell 
> > >  wrote:
> > > 
> > > > News: next-20121115 (i.e. tomorrow) will be the last release until
> > > > next-20121126 (which should be just be after -rc7, I guess - assuming
> > > > that Linus does not release v3.7 before then), so if you want something
> > > > in linux-next for a reasonable amount of testing, it should probably be
> > > > committed tomorrow.
> > > 
> > > It would help if the old sched/numa code wasn't in -next while 
> > > you're away.  That would give me a clean run at 3.7 and will 
> > > make it easier for others to integrate and test the four(!) 
> > > different autoschednumacore implementations on top of 
> > > linux-next.
> > > 
> > > Pretty please?
> > 
> > The next integration should have this solved: I have removed the 
> > old sched/numa bits, replaced by the latest rebased/reworked 
> > numa/core bits.
> > 
> 
> That solves one problem, but I still need to route around the 
> numa stuff when preparing the 3.8-rc1 merge.  Again!

I'm eyeing a v3.8 merge... modulo unforeseen problems. This has 
been going on for way too long.

numa/core performs very well, and the rest can be done 
iteratively.

The mm/ bits changed very little due to the latest rounds of 
review. Most of the discussion centered around specific 
implementational details and naming - and where we were wrong I 
changed the code - numa/core sums up the consensus so far.

If I missed anything let me know and I'll fix the code ASAP ...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 18:15:36 +1100 Stephen Rothwell  
wrote:

> Hi Andrew,
> 
> On Tue, 13 Nov 2012 22:56:35 -0800 Andrew Morton  
> wrote:
> >
> > On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar  wrote:
> > 
> > > * Andrew Morton  wrote:
> > > 
> > > > It would help if the old sched/numa code wasn't in -next while 
> > > > you're away.  That would give me a clean run at 3.7 and will 
> > > > make it easier for others to integrate and test the four(!) 
> > > > different autoschednumacore implementations on top of 
> > > > linux-next.
> > > > 
> > > > Pretty please?
> > > 
> > > The next integration should have this solved: I have removed the 
> > > old sched/numa bits, replaced by the latest rebased/reworked 
> > > numa/core bits.
> > 
> > That solves one problem, but I still need to route around the numa
> > stuff when preparing the 3.8-rc1 merge.  Again!
> 
> I am not sure what is actually involved here, but would it help if I
> made you a new akpm-base with the old tip tree replaced by the new one
> that Ingo just pushed out?  Or are there still problematic things in the
> tip tree?

If this new code is targeted at 3.9 as I'm suggesting then it should go
into -next after 3.8-rc1, so the sched/numa part of -tip should be
omitted from -next until then.

If instead the plan is to merge it all into 3.8 then -tip should go
into -next as-is.

How's your crystal ball?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

Hi Andrew,

On Tue, 13 Nov 2012 22:56:35 -0800 Andrew Morton  
wrote:
>
> On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar  wrote:
> 
> > * Andrew Morton  wrote:
> > 
> > > It would help if the old sched/numa code wasn't in -next while 
> > > you're away.  That would give me a clean run at 3.7 and will 
> > > make it easier for others to integrate and test the four(!) 
> > > different autoschednumacore implementations on top of 
> > > linux-next.
> > > 
> > > Pretty please?
> > 
> > The next integration should have this solved: I have removed the 
> > old sched/numa bits, replaced by the latest rebased/reworked 
> > numa/core bits.
> 
> That solves one problem, but I still need to route around the numa
> stuff when preparing the 3.8-rc1 merge.  Again!

I am not sure what is actually involved here, but would it help if I
made you a new akpm-base with the old tip tree replaced by the new one
that Ingo just pushed out?  Or are there still problematic things in the
tip tree?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpAijL7Gb2xX.pgp
Description: PGP signature

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 17:55:28 +1100 Stephen Rothwell  
wrote:
>
> On Tue, 13 Nov 2012 21:37:42 -0800 Andrew Morton  
> wrote:
> >
> > It would help if the old sched/numa code wasn't in -next while you're
> > away.  That would give me a clean run at 3.7 and will make it easier
> > for others to integrate and test the four(!) different
> > autoschednumacore implementations on top of linux-next.
> > 
> > Pretty please?
> 
> So, your understanding is that the "old sched/numa code" won't (and
> shouldn't) be merged into Linus' tree (for v3.7, or ever)?
> 
> In that case, what I can do is give you a tree that is the same as
> akpm-base but with one of the merges in the tip tree reverted (and, in
> fact, I could push that into akpm-base to make things easier for you).
> I guess that would be the merge of the numa/core branch which would
> result in the following commits being reverted:

Ok, ignore all this :-(

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpwlGRG7WBLT.pgp
Description: PGP signature

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar  wrote:

> 
> * Andrew Morton  wrote:
> 
> > On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell  
> > wrote:
> > 
> > > News: next-20121115 (i.e. tomorrow) will be the last release until
> > > next-20121126 (which should be just be after -rc7, I guess - assuming
> > > that Linus does not release v3.7 before then), so if you want something
> > > in linux-next for a reasonable amount of testing, it should probably be
> > > committed tomorrow.
> > 
> > It would help if the old sched/numa code wasn't in -next while 
> > you're away.  That would give me a clean run at 3.7 and will 
> > make it easier for others to integrate and test the four(!) 
> > different autoschednumacore implementations on top of 
> > linux-next.
> > 
> > Pretty please?
> 
> The next integration should have this solved: I have removed the 
> old sched/numa bits, replaced by the latest rebased/reworked 
> numa/core bits.
> 

That solves one problem, but I still need to route around the numa
stuff when preparing the 3.8-rc1 merge.  Again!

And yes, I'm assuming you're not targeting 3.8.  Given the history
behind this and the number of people who are looking at it, that's too
hasty.  Hugh can speak to his own reasons for feeling the same way.

And I must say that I deeply regret not digging my heels in when this
went into -next all those months ago.  It has caused a ton of trouble
for me and for a lot of other people.

Put it in -next after 3.8-rc1 with a view to a 3.9 merge, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

Hi Andrew,

On Tue, 13 Nov 2012 21:37:42 -0800 Andrew Morton  
wrote:
>
> It would help if the old sched/numa code wasn't in -next while you're
> away.  That would give me a clean run at 3.7 and will make it easier
> for others to integrate and test the four(!) different
> autoschednumacore implementations on top of linux-next.
> 
> Pretty please?

So, your understanding is that the "old sched/numa code" won't (and
shouldn't) be merged into Linus' tree (for v3.7, or ever)?

In that case, what I can do is give you a tree that is the same as
akpm-base but with one of the merges in the tip tree reverted (and, in
fact, I could push that into akpm-base to make things easier for you).
I guess that would be the merge of the numa/core branch which would
result in the following commits being reverted:

Andrea Arcangeli (1):
  numa, mm: Support NUMA hinting page faults from gup/gup_fast

Gerald Schaefer (1):
  sched, numa, mm, s390/thp: Implement pmd_pgprot() for s390

Ingo Molnar (2):
  mm/pgprot: Move the pgprot_modify() fallback definition to mm.h
  sched, numa, mm: Add NUMA_MIGRATION feature flag

Lee Schermerhorn (3):
  mm/mpol: Add MPOL_MF_NOOP
  mm/mpol: Check for misplaced page
  mm/mpol: Add MPOL_MF_LAZY

Peter Zijlstra (17):
  sched, numa, mm: Make find_busiest_queue() a method
  sched, numa, mm: Describe the NUMA scheduling problem formally
  mm/thp: Preserve pgprot across huge page split
  mm/mpol: Make MPOL_LOCAL a real policy
  mm/mpol: Create special PROT_NONE infrastructure
  mm/migrate: Introduce migrate_misplaced_page()
  mm/mpol: Use special PROT_NONE to migrate pages
  sched, numa, mm: Introduce tsk_home_node()
  sched, numa, mm/mpol: Make mempolicy home-node aware
  sched, numa, mm: Introduce sched_feat_numa()
  sched, numa, mm: Implement THP migration
  sched, numa, mm: Implement home-node awareness
  sched, numa, mm: Introduce last_nid in the pageframe
  sched, numa, mm/mpol: Add_MPOL_F_HOME
  sched, numa, mm: Add fault driven placement and migration policy
  sched, numa, mm: Implement constant, per task Working Set Sampling (WSS) 
rate
  sched, numa, mm: Implement slow start for working set sampling

Ralf Baechle (1):
  sched, numa, mm, MIPS/thp: Add pmd_pgprot() implementation

Rik van Riel (6):
  mm/generic: Only flush the local TLB in ptep_set_access_flags()
  x86/mm: Only do a local tlb flush in ptep_set_access_flags()
  x86/mm: Introduce pte_accessible()
  mm: Only flush the TLB when clearing an accessible pte
  sched, numa, mm: Add credits for NUMA placement
  x86/mm: Completely drop the TLB flush from ptep_set_access_flags()

 CREDITS  |1 -
 Documentation/scheduler/numa-problem.txt |  230 
 arch/mips/include/asm/pgtable.h  |2 -
 arch/s390/include/asm/pgtable.h  |   13 -
 arch/sh/mm/Kconfig   |1 -
 arch/x86/include/asm/pgtable.h   |7 -
 arch/x86/mm/pgtable.c|8 +-
 include/asm-generic/pgtable.h|4 -
 include/linux/huge_mm.h  |   19 -
 include/linux/init_task.h|8 -
 include/linux/mempolicy.h|8 -
 include/linux/migrate.h  |7 -
 include/linux/migrate_mode.h |3 -
 include/linux/mm.h   |  122 +++
 include/linux/mm_types.h |   10 -
 include/linux/mmzone.h   |   14 +-
 include/linux/page-flags-layout.h|   83 -
 include/linux/sched.h|   44 +--
 include/uapi/linux/mempolicy.h   |   17 +-
 init/Kconfig |   14 -
 kernel/sched/core.c  |   77 +---
 kernel/sched/debug.c |3 -
 kernel/sched/fair.c  |  579 ++
 kernel/sched/features.h  |   14 -
 kernel/sched/sched.h |   36 --
 kernel/sysctl.c  |   45 +--
 mm/huge_memory.c |  251 +++--
 mm/memory.c  |  127 +--
 mm/mempolicy.c   |  204 ++-
 mm/migrate.c |   87 +
 mm/mprotect.c|   31 +-
 mm/pgtable-generic.c |9 +-
 32 files changed, 209 insertions(+), 1869 deletions(-)

Does that sound like what you need?

If Ingo hasn't removed/reverted that branch tomorrow, I can do this
revert again just after merging the tip tree.

> Also, I need to get a fresh mmotm into -next tomorrow.  Don't do
> anything until I've pulled that rabbit out of the hat :)

No worries.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpefsv3Wtl87.pgp
Description: PGP signature

Re: linux-next: Tree for Nov 14


* Andrew Morton  wrote:

> On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell  
> wrote:
> 
> > News: next-20121115 (i.e. tomorrow) will be the last release until
> > next-20121126 (which should be just be after -rc7, I guess - assuming
> > that Linus does not release v3.7 before then), so if you want something
> > in linux-next for a reasonable amount of testing, it should probably be
> > committed tomorrow.
> 
> It would help if the old sched/numa code wasn't in -next while 
> you're away.  That would give me a clean run at 3.7 and will 
> make it easier for others to integrate and test the four(!) 
> different autoschednumacore implementations on top of 
> linux-next.
> 
> Pretty please?

The next integration should have this solved: I have removed the 
old sched/numa bits, replaced by the latest rebased/reworked 
numa/core bits.

(There's no fundamental changes to the mm/ bits, so the 
conflict/merge fall-out should be minimal and/or trivial.)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Tue, 13 Nov 2012 21:37:42 -0800 Andrew Morton  
wrote:

> It would help if the old sched/numa code wasn't in -next while you're
> away.

Now I think about it, that's going to be hard.  If I integrate against
tomorrow's -next, the mmotm patches will be against next+schednuma. 
Then you'll need to unintegrate them - effectively redo them against
mainline.

That won't be t hard, but there are some tricky bits.  Is there a way
I can extract a schednuma-free -next tomorrow?  That way I can do the wrangling.

This thing really has been a pain ;(  I've been uncharacteristically
patient!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell  
wrote:

> News: next-20121115 (i.e. tomorrow) will be the last release until
> next-20121126 (which should be just be after -rc7, I guess - assuming
> that Linus does not release v3.7 before then), so if you want something
> in linux-next for a reasonable amount of testing, it should probably be
> committed tomorrow.

It would help if the old sched/numa code wasn't in -next while you're
away.  That would give me a clean run at 3.7 and will make it easier
for others to integrate and test the four(!) different
autoschednumacore implementations on top of linux-next.

Pretty please?

Also, I need to get a fresh mmotm into -next tomorrow.  Don't do
anything until I've pulled that rabbit out of the hat :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Nov 14

Hi all,

News: next-20121115 (i.e. tomorrow) will be the last release until
next-20121126 (which should be just be after -rc7, I guess - assuming
that Linus does not release v3.7 before then), so if you want something
in linux-next for a reasonable amount of testing, it should probably be
committed tomorrow.

Changes since 20121113:

The v4l-dvb tree still had its build failure so I used the version from
next-20121026.

The usb tree gained a conflict against usb.current tree.

The staging tree lost its build failure.

The akpm tree lost its build failure.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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 (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 210 trees (counting Linus' and 28 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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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 Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (9924a19 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of 
git://git.pengutronix.de/git/wsa/linux)
Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by 
list_head-style lists.)
Merging arm-current/fixes (2b6e204 ARM: 7572/1: proc-v6.S: fix comment)
Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp)
Merging powerpc-merge/merge (8c23f40 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging sparc/master (b251f0f Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (eb5ce43 vxlan: fix a typo.)
Merging sound-current/for-linus (d2153a1 ALSA: es1968: precedence bug in 
snd_es1968_tea575x_get_pins())
Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots 
unless port supports hotplug)
Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while 
checking tx status)
Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3)
Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3)
Merging usb.current/usb-linus (e592c5d Revert "USB/host: Cleanup unneccessary 
irq disable code")
Merging staging.current/staging-linus (d38e0e3 Revert "Staging: Android alarm: 
IOCTL command encoding fix")
Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3)
Merging input-current/for-linus (40a8120 Input: MT - document new 'flags' 
argument of input_mt_init_slots())
Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 
arrays via dm-raid.c)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in 
cryptd_queue_worker to prevent data corruption)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using 
proper "spi:" modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, 
remove cast)
Merging rr-fixes/fixes (237242b virtio: Don't

linux-next: Tree for Nov 14

Hi all,

News: next-20121115 (i.e. tomorrow) will be the last release until
next-20121126 (which should be just be after -rc7, I guess - assuming
that Linus does not release v3.7 before then), so if you want something
in linux-next for a reasonable amount of testing, it should probably be
committed tomorrow.

Changes since 20121113:

The v4l-dvb tree still had its build failure so I used the version from
next-20121026.

The usb tree gained a conflict against usb.current tree.

The staging tree lost its build failure.

The akpm tree lost its build failure.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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 (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 210 trees (counting Linus' and 28 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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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 Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (9924a19 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of 
git://git.pengutronix.de/git/wsa/linux)
Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by 
list_head-style lists.)
Merging arm-current/fixes (2b6e204 ARM: 7572/1: proc-v6.S: fix comment)
Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp)
Merging powerpc-merge/merge (8c23f40 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging sparc/master (b251f0f Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (eb5ce43 vxlan: fix a typo.)
Merging sound-current/for-linus (d2153a1 ALSA: es1968: precedence bug in 
snd_es1968_tea575x_get_pins())
Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots 
unless port supports hotplug)
Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while 
checking tx status)
Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3)
Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3)
Merging usb.current/usb-linus (e592c5d Revert USB/host: Cleanup unneccessary 
irq disable code)
Merging staging.current/staging-linus (d38e0e3 Revert Staging: Android alarm: 
IOCTL command encoding fix)
Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3)
Merging input-current/for-linus (40a8120 Input: MT - document new 'flags' 
argument of input_mt_init_slots())
Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 
arrays via dm-raid.c)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in 
cryptd_queue_worker to prevent data corruption)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using 
proper spi: modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, 
remove cast)
Merging rr-fixes/fixes (237242b virtio: Don't access index

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 News: next-20121115 (i.e. tomorrow) will be the last release until
 next-20121126 (which should be just be after -rc7, I guess - assuming
 that Linus does not release v3.7 before then), so if you want something
 in linux-next for a reasonable amount of testing, it should probably be
 committed tomorrow.

It would help if the old sched/numa code wasn't in -next while you're
away.  That would give me a clean run at 3.7 and will make it easier
for others to integrate and test the four(!) different
autoschednumacore implementations on top of linux-next.

Pretty please?

Also, I need to get a fresh mmotm into -next tomorrow.  Don't do
anything until I've pulled that rabbit out of the hat :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Tue, 13 Nov 2012 21:37:42 -0800 Andrew Morton a...@linux-foundation.org 
wrote:

 It would help if the old sched/numa code wasn't in -next while you're
 away.

Now I think about it, that's going to be hard.  If I integrate against
tomorrow's -next, the mmotm patches will be against next+schednuma. 
Then you'll need to unintegrate them - effectively redo them against
mainline.

That won't be t hard, but there are some tricky bits.  Is there a way
I can extract a schednuma-free -next tomorrow?  That way I can do the wrangling.

This thing really has been a pain ;(  I've been uncharacteristically
patient!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14


* Andrew Morton a...@linux-foundation.org wrote:

 On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell s...@canb.auug.org.au 
 wrote:
 
  News: next-20121115 (i.e. tomorrow) will be the last release until
  next-20121126 (which should be just be after -rc7, I guess - assuming
  that Linus does not release v3.7 before then), so if you want something
  in linux-next for a reasonable amount of testing, it should probably be
  committed tomorrow.
 
 It would help if the old sched/numa code wasn't in -next while 
 you're away.  That would give me a clean run at 3.7 and will 
 make it easier for others to integrate and test the four(!) 
 different autoschednumacore implementations on top of 
 linux-next.
 
 Pretty please?

The next integration should have this solved: I have removed the 
old sched/numa bits, replaced by the latest rebased/reworked 
numa/core bits.

(There's no fundamental changes to the mm/ bits, so the 
conflict/merge fall-out should be minimal and/or trivial.)

Thanks,

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

Hi Andrew,

On Tue, 13 Nov 2012 21:37:42 -0800 Andrew Morton a...@linux-foundation.org 
wrote:

 It would help if the old sched/numa code wasn't in -next while you're
 away.  That would give me a clean run at 3.7 and will make it easier
 for others to integrate and test the four(!) different
 autoschednumacore implementations on top of linux-next.
 
 Pretty please?

So, your understanding is that the old sched/numa code won't (and
shouldn't) be merged into Linus' tree (for v3.7, or ever)?

In that case, what I can do is give you a tree that is the same as
akpm-base but with one of the merges in the tip tree reverted (and, in
fact, I could push that into akpm-base to make things easier for you).
I guess that would be the merge of the numa/core branch which would
result in the following commits being reverted:

Andrea Arcangeli (1):
  numa, mm: Support NUMA hinting page faults from gup/gup_fast

Gerald Schaefer (1):
  sched, numa, mm, s390/thp: Implement pmd_pgprot() for s390

Ingo Molnar (2):
  mm/pgprot: Move the pgprot_modify() fallback definition to mm.h
  sched, numa, mm: Add NUMA_MIGRATION feature flag

Lee Schermerhorn (3):
  mm/mpol: Add MPOL_MF_NOOP
  mm/mpol: Check for misplaced page
  mm/mpol: Add MPOL_MF_LAZY

Peter Zijlstra (17):
  sched, numa, mm: Make find_busiest_queue() a method
  sched, numa, mm: Describe the NUMA scheduling problem formally
  mm/thp: Preserve pgprot across huge page split
  mm/mpol: Make MPOL_LOCAL a real policy
  mm/mpol: Create special PROT_NONE infrastructure
  mm/migrate: Introduce migrate_misplaced_page()
  mm/mpol: Use special PROT_NONE to migrate pages
  sched, numa, mm: Introduce tsk_home_node()
  sched, numa, mm/mpol: Make mempolicy home-node aware
  sched, numa, mm: Introduce sched_feat_numa()
  sched, numa, mm: Implement THP migration
  sched, numa, mm: Implement home-node awareness
  sched, numa, mm: Introduce last_nid in the pageframe
  sched, numa, mm/mpol: Add_MPOL_F_HOME
  sched, numa, mm: Add fault driven placement and migration policy
  sched, numa, mm: Implement constant, per task Working Set Sampling (WSS) 
rate
  sched, numa, mm: Implement slow start for working set sampling

Ralf Baechle (1):
  sched, numa, mm, MIPS/thp: Add pmd_pgprot() implementation

Rik van Riel (6):
  mm/generic: Only flush the local TLB in ptep_set_access_flags()
  x86/mm: Only do a local tlb flush in ptep_set_access_flags()
  x86/mm: Introduce pte_accessible()
  mm: Only flush the TLB when clearing an accessible pte
  sched, numa, mm: Add credits for NUMA placement
  x86/mm: Completely drop the TLB flush from ptep_set_access_flags()

 CREDITS  |1 -
 Documentation/scheduler/numa-problem.txt |  230 
 arch/mips/include/asm/pgtable.h  |2 -
 arch/s390/include/asm/pgtable.h  |   13 -
 arch/sh/mm/Kconfig   |1 -
 arch/x86/include/asm/pgtable.h   |7 -
 arch/x86/mm/pgtable.c|8 +-
 include/asm-generic/pgtable.h|4 -
 include/linux/huge_mm.h  |   19 -
 include/linux/init_task.h|8 -
 include/linux/mempolicy.h|8 -
 include/linux/migrate.h  |7 -
 include/linux/migrate_mode.h |3 -
 include/linux/mm.h   |  122 +++
 include/linux/mm_types.h |   10 -
 include/linux/mmzone.h   |   14 +-
 include/linux/page-flags-layout.h|   83 -
 include/linux/sched.h|   44 +--
 include/uapi/linux/mempolicy.h   |   17 +-
 init/Kconfig |   14 -
 kernel/sched/core.c  |   77 +---
 kernel/sched/debug.c |3 -
 kernel/sched/fair.c  |  579 ++
 kernel/sched/features.h  |   14 -
 kernel/sched/sched.h |   36 --
 kernel/sysctl.c  |   45 +--
 mm/huge_memory.c |  251 +++--
 mm/memory.c  |  127 +--
 mm/mempolicy.c   |  204 ++-
 mm/migrate.c |   87 +
 mm/mprotect.c|   31 +-
 mm/pgtable-generic.c |9 +-
 32 files changed, 209 insertions(+), 1869 deletions(-)

Does that sound like what you need?

If Ingo hasn't removed/reverted that branch tomorrow, I can do this
revert again just after merging the tip tree.

 Also, I need to get a fresh mmotm into -next tomorrow.  Don't do
 anything until I've pulled that rabbit out of the hat :)

No worries.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpefsv3Wtl87.pgp
Description: PGP signature

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar mi...@kernel.org wrote:

 
 * Andrew Morton a...@linux-foundation.org wrote:
 
  On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell s...@canb.auug.org.au 
  wrote:
  
   News: next-20121115 (i.e. tomorrow) will be the last release until
   next-20121126 (which should be just be after -rc7, I guess - assuming
   that Linus does not release v3.7 before then), so if you want something
   in linux-next for a reasonable amount of testing, it should probably be
   committed tomorrow.
  
  It would help if the old sched/numa code wasn't in -next while 
  you're away.  That would give me a clean run at 3.7 and will 
  make it easier for others to integrate and test the four(!) 
  different autoschednumacore implementations on top of 
  linux-next.
  
  Pretty please?
 
 The next integration should have this solved: I have removed the 
 old sched/numa bits, replaced by the latest rebased/reworked 
 numa/core bits.
 

That solves one problem, but I still need to route around the numa
stuff when preparing the 3.8-rc1 merge.  Again!

And yes, I'm assuming you're not targeting 3.8.  Given the history
behind this and the number of people who are looking at it, that's too
hasty.  Hugh can speak to his own reasons for feeling the same way.

And I must say that I deeply regret not digging my heels in when this
went into -next all those months ago.  It has caused a ton of trouble
for me and for a lot of other people.

Put it in -next after 3.8-rc1 with a view to a 3.9 merge, please.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 17:55:28 +1100 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 On Tue, 13 Nov 2012 21:37:42 -0800 Andrew Morton a...@linux-foundation.org 
 wrote:
 
  It would help if the old sched/numa code wasn't in -next while you're
  away.  That would give me a clean run at 3.7 and will make it easier
  for others to integrate and test the four(!) different
  autoschednumacore implementations on top of linux-next.
  
  Pretty please?
 
 So, your understanding is that the old sched/numa code won't (and
 shouldn't) be merged into Linus' tree (for v3.7, or ever)?
 
 In that case, what I can do is give you a tree that is the same as
 akpm-base but with one of the merges in the tip tree reverted (and, in
 fact, I could push that into akpm-base to make things easier for you).
 I guess that would be the merge of the numa/core branch which would
 result in the following commits being reverted:

Ok, ignore all this :-(

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpwlGRG7WBLT.pgp
Description: PGP signature

Re: linux-next: Tree for Nov 14

Hi Andrew,

On Tue, 13 Nov 2012 22:56:35 -0800 Andrew Morton a...@linux-foundation.org 
wrote:

 On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar mi...@kernel.org wrote:
 
  * Andrew Morton a...@linux-foundation.org wrote:
  
   It would help if the old sched/numa code wasn't in -next while 
   you're away.  That would give me a clean run at 3.7 and will 
   make it easier for others to integrate and test the four(!) 
   different autoschednumacore implementations on top of 
   linux-next.
   
   Pretty please?
  
  The next integration should have this solved: I have removed the 
  old sched/numa bits, replaced by the latest rebased/reworked 
  numa/core bits.
 
 That solves one problem, but I still need to route around the numa
 stuff when preparing the 3.8-rc1 merge.  Again!

I am not sure what is actually involved here, but would it help if I
made you a new akpm-base with the old tip tree replaced by the new one
that Ingo just pushed out?  Or are there still problematic things in the
tip tree?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpAijL7Gb2xX.pgp
Description: PGP signature

Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012 18:15:36 +1100 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 Hi Andrew,
 
 On Tue, 13 Nov 2012 22:56:35 -0800 Andrew Morton a...@linux-foundation.org 
 wrote:
 
  On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar mi...@kernel.org wrote:
  
   * Andrew Morton a...@linux-foundation.org wrote:
   
It would help if the old sched/numa code wasn't in -next while 
you're away.  That would give me a clean run at 3.7 and will 
make it easier for others to integrate and test the four(!) 
different autoschednumacore implementations on top of 
linux-next.

Pretty please?
   
   The next integration should have this solved: I have removed the 
   old sched/numa bits, replaced by the latest rebased/reworked 
   numa/core bits.
  
  That solves one problem, but I still need to route around the numa
  stuff when preparing the 3.8-rc1 merge.  Again!
 
 I am not sure what is actually involved here, but would it help if I
 made you a new akpm-base with the old tip tree replaced by the new one
 that Ingo just pushed out?  Or are there still problematic things in the
 tip tree?

If this new code is targeted at 3.9 as I'm suggesting then it should go
into -next after 3.8-rc1, so the sched/numa part of -tip should be
omitted from -next until then.

If instead the plan is to merge it all into 3.8 then -tip should go
into -next as-is.

How's your crystal ball?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14