* Re: memory-hotplug : suppres "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning
From: Andrew Morton @ 2012-10-05 21:09 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, wency, linux-acpi, x86, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, liuj97
In-Reply-To: <506D1F1D.9000301@jp.fujitsu.com>
On Thu, 4 Oct 2012 14:31:09 +0900
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> wrote:
> When our x86 box calls __remove_pages(), release_mem_region() shows
> many warnings. And x86 box cannot unregister iomem_resource.
>
> "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>"
>
> release_mem_region() has been changed as called in each PAGES_PER_SECTION
> chunk since applying a patch(de7f0cba96786c). Because powerpc registers
> iomem_resource in each PAGES_PER_SECTION chunk. But when I hot add memory
> on x86 box, iomem_resource is register in each _CRS not PAGES_PER_SECTION
> chunk. So x86 box unregisters iomem_resource.
>
> The patch fixes the problem.
>
> --- linux-3.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-04 14:22:59.833520792 +0900
> +++ linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-04 14:23:05.150521411 +0900
> @@ -77,7 +77,8 @@ static int pseries_remove_memblock(unsig
> {
> unsigned long start, start_pfn;
> struct zone *zone;
> - int ret;
> + int i, ret;
> + int sections_to_remove;
>
> start_pfn = base >> PAGE_SHIFT;
>
> @@ -97,9 +98,13 @@ static int pseries_remove_memblock(unsig
> * to sysfs "state" file and we can't remove sysfs entries
> * while writing to it. So we have to defer it to here.
> */
> - ret = __remove_pages(zone, start_pfn, memblock_size >> PAGE_SHIFT);
> - if (ret)
> - return ret;
> + sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
> + for (i = 0; i < sections_to_remove; i++) {
> + unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
> + ret = __remove_pages(zone, start_pfn, PAGES_PER_SECTION);
> + if (ret)
> + return ret;
> + }
It is inappropriate that `i' have a signed 32-bit type. I doubt if
there's any possibility of an overflow bug here, but using a consistent
and well-chosen type would eliminate all doubt.
Note that __remove_pages() does use an unsigned long for this, although
it stupidly calls that variable "i", despite the C programmers'
expectation that a variable called "i" has type "int".
The same applies to `sections_to_remove', but __remove_pages() went and
decided to use an `int' for that variable. Sigh.
Anyway, please have a think, and see if we can come up with the best
and most accurate choice of types and identifiers in this code.
^ permalink raw reply
* Re: [RFC v9 PATCH 16/21] memory-hotplug: free memmap of sparse-vmemmap
From: Ni zhan Chen @ 2012-10-06 14:18 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, linux-ia64, Wen Congyang, len.brown, linux-acpi,
linux-sh, x86, linux-kernel, cmetcalf, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <506D2C1C.5060706@jp.fujitsu.com>
On 10/04/2012 02:26 PM, Yasuaki Ishimatsu wrote:
> Hi Chen,
>
> Sorry for late reply.
>
> 2012/10/02 13:21, Ni zhan Chen wrote:
>> On 09/05/2012 05:25 PM, wency@cn.fujitsu.com wrote:
>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> All pages of virtual mapping in removed memory cannot be freed,
>>> since some pages
>>> used as PGD/PUD includes not only removed memory but also other
>>> memory. So the
>>> patch checks whether page can be freed or not.
>>>
>>> How to check whether page can be freed or not?
>>> 1. When removing memory, the page structs of the revmoved memory
>>> are filled
>>> with 0FD.
>>> 2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be
>>> cleared.
>>> In this case, the page used as PT/PMD can be freed.
>>>
>>> Applying patch, __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is
>>> integrated
>>> into one. So __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is deleted.
>>>
>>> Note: vmemmap_kfree() and vmemmap_free_bootmem() are not
>>> implemented for ia64,
>>> ppc, s390, and sparc.
>>>
>>> CC: David Rientjes <rientjes@google.com>
>>> CC: Jiang Liu <liuj97@gmail.com>
>>> CC: Len Brown <len.brown@intel.com>
>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> CC: Paul Mackerras <paulus@samba.org>
>>> CC: Christoph Lameter <cl@linux.com>
>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>> CC: Wen Congyang <wency@cn.fujitsu.com>
>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>> ---
>>> arch/ia64/mm/discontig.c | 8 +++
>>> arch/powerpc/mm/init_64.c | 8 +++
>>> arch/s390/mm/vmem.c | 8 +++
>>> arch/sparc/mm/init_64.c | 8 +++
>>> arch/x86/mm/init_64.c | 119
>>> +++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/mm.h | 2 +
>>> mm/memory_hotplug.c | 17 +------
>>> mm/sparse.c | 5 +-
>>> 8 files changed, 158 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
>>> index 33943db..0d23b69 100644
>>> --- a/arch/ia64/mm/discontig.c
>>> +++ b/arch/ia64/mm/discontig.c
>>> @@ -823,6 +823,14 @@ int __meminit vmemmap_populate(struct page
>>> *start_page,
>>> return vmemmap_populate_basepages(start_page, size, node);
>>> }
>>> +void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> +void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> void register_page_bootmem_memmap(unsigned long section_nr,
>>> struct page *start_page, unsigned long size)
>>> {
>>> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
>>> index 3690c44..835a2b3 100644
>>> --- a/arch/powerpc/mm/init_64.c
>>> +++ b/arch/powerpc/mm/init_64.c
>>> @@ -299,6 +299,14 @@ int __meminit vmemmap_populate(struct page
>>> *start_page,
>>> return 0;
>>> }
>>> +void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> +void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> void register_page_bootmem_memmap(unsigned long section_nr,
>>> struct page *start_page, unsigned long size)
>>> {
>>> diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
>>> index eda55cd..4b42b0b 100644
>>> --- a/arch/s390/mm/vmem.c
>>> +++ b/arch/s390/mm/vmem.c
>>> @@ -227,6 +227,14 @@ out:
>>> return ret;
>>> }
>>> +void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> +void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> void register_page_bootmem_memmap(unsigned long section_nr,
>>> struct page *start_page, unsigned long size)
>>> {
>>> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
>>> index add1cc7..1384826 100644
>>> --- a/arch/sparc/mm/init_64.c
>>> +++ b/arch/sparc/mm/init_64.c
>>> @@ -2078,6 +2078,14 @@ void __meminit vmemmap_populate_print_last(void)
>>> }
>>> }
>>> +void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> +void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> +}
>>> +
>>> void register_page_bootmem_memmap(unsigned long section_nr,
>>> struct page *start_page, unsigned long size)
>>> {
>>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>>> index 0075592..4e8f8a4 100644
>>> --- a/arch/x86/mm/init_64.c
>>> +++ b/arch/x86/mm/init_64.c
>>> @@ -1138,6 +1138,125 @@ vmemmap_populate(struct page *start_page,
>>> unsigned long size, int node)
>>> return 0;
>>> }
>>> +#define PAGE_INUSE 0xFD
>>> +
>>> +unsigned long find_and_clear_pte_page(unsigned long addr, unsigned
>>> long end,
>>> + struct page **pp, int *page_size)
>>> +{
>>> + pgd_t *pgd;
>>> + pud_t *pud;
>>> + pmd_t *pmd;
>>> + pte_t *pte;
>>> + void *page_addr;
>>> + unsigned long next;
>>> +
>>> + *pp = NULL;
>>> +
>>> + pgd = pgd_offset_k(addr);
>>> + if (pgd_none(*pgd))
>>> + return pgd_addr_end(addr, end);
>>> +
>>> + pud = pud_offset(pgd, addr);
>>> + if (pud_none(*pud))
>>> + return pud_addr_end(addr, end);
>>> +
>>> + if (!cpu_has_pse) {
>>> + next = (addr + PAGE_SIZE) & PAGE_MASK;
>>> + pmd = pmd_offset(pud, addr);
>>> + if (pmd_none(*pmd))
>>> + return next;
>>> +
>>> + pte = pte_offset_kernel(pmd, addr);
>>> + if (pte_none(*pte))
>>> + return next;
>>> +
>>> + *page_size = PAGE_SIZE;
>>> + *pp = pte_page(*pte);
>>> + } else {
>>> + next = pmd_addr_end(addr, end);
>>> +
>>> + pmd = pmd_offset(pud, addr);
>>> + if (pmd_none(*pmd))
>>> + return next;
>>> +
>>> + *page_size = PMD_SIZE;
>>> + *pp = pmd_page(*pmd);
>>> + }
>>> +
>>> + /*
>>> + * Removed page structs are filled with 0xFD.
>>> + */
>>> + memset((void *)addr, PAGE_INUSE, next - addr);
>>> +
>>> + page_addr = page_address(*pp);
>>> +
>>> + /*
>>> + * Check the page is filled with 0xFD or not.
>>> + * memchr_inv() returns the address. In this case, we cannot
>>> + * clear PTE/PUD entry, since the page is used by other.
>>> + * So we cannot also free the page.
>>> + *
>>> + * memchr_inv() returns NULL. In this case, we can clear
>>> + * PTE/PUD entry, since the page is not used by other.
>>> + * So we can also free the page.
>>> + */
>>> + if (memchr_inv(page_addr, PAGE_INUSE, *page_size)) {
>>> + *pp = NULL;
>>> + return next;
>>> + }
>>> +
>>
>> Hi Yasuaki,
>>
>> why call memchr_inv check after memset, this time the page can always
>> be filled with 0xFD.
>
> The page is not always filled with 0xFD. find_and_clear_pte_page()
> is calld in each section. So the function fills the page
> section size/sizeof(page) byte with 0xFD one time. Thus if section
> size is
> small, the page is filled with 0xFD.
Hi Yasuaki,
But when section size will be small?
Regards,
Chen
>
> Thanks,
> Yasuaki Ishimatsu
>
>
>>> + if (!cpu_has_pse)
>>> + pte_clear(&init_mm, addr, pte);
>>> + else
>>> + pmd_clear(pmd);
>>> +
>>> + return next;
>>> +}
>>> +
>>> +void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> + unsigned long addr = (unsigned long)memmap;
>>> + unsigned long end = (unsigned long)(memmap + nr_pages);
>>> + unsigned long next;
>>> + struct page *page;
>>> + int page_size;
>>> +
>>> + for (; addr < end; addr = next) {
>>> + page = NULL;
>>> + page_size = 0;
>>> + next = find_and_clear_pte_page(addr, end, &page, &page_size);
>>> + if (!page)
>>> + continue;
>>> +
>>> + free_pages((unsigned long)page_address(page),
>>> + get_order(page_size));
>>> + __flush_tlb_one(addr);
>>> + }
>>> +}
>>> +
>>> +void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
>>> +{
>>> + unsigned long addr = (unsigned long)memmap;
>>> + unsigned long end = (unsigned long)(memmap + nr_pages);
>>> + unsigned long next;
>>> + struct page *page;
>>> + int page_size;
>>> + unsigned long magic;
>>> +
>>> + for (; addr < end; addr = next) {
>>> + page = NULL;
>>> + page_size = 0;
>>> + next = find_and_clear_pte_page(addr, end, &page, &page_size);
>>> + if (!page)
>>> + continue;
>>> +
>>> + magic = (unsigned long) page->lru.next;
>>> + if (magic == SECTION_INFO)
>>> + put_page_bootmem(page);
>>> + flush_tlb_kernel_range(addr, end);
>>> + }
>>> +}
>>> +
>>> void register_page_bootmem_memmap(unsigned long section_nr,
>>> struct page *start_page, unsigned long size)
>>> {
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index c607913..fb0d1fc 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -1620,6 +1620,8 @@ int vmemmap_populate(struct page *start_page,
>>> unsigned long pages, int node);
>>> void vmemmap_populate_print_last(void);
>>> void register_page_bootmem_memmap(unsigned long section_nr, struct
>>> page *map,
>>> unsigned long size);
>>> +void vmemmap_kfree(struct page *memmpa, unsigned long nr_pages);
>>> +void vmemmap_free_bootmem(struct page *memmpa, unsigned long
>>> nr_pages);
>>> enum mf_flags {
>>> MF_COUNT_INCREASED = 1 << 0,
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 647a7f2..c54922c 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -308,19 +308,6 @@ static int __meminit __add_section(int nid,
>>> struct zone *zone,
>>> return register_new_memory(nid,
>>> __pfn_to_section(phys_start_pfn));
>>> }
>>> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>>> -static int __remove_section(struct zone *zone, struct mem_section *ms)
>>> -{
>>> - int ret = -EINVAL;
>>> -
>>> - if (!valid_section(ms))
>>> - return ret;
>>> -
>>> - ret = unregister_memory_section(ms);
>>> -
>>> - return ret;
>>> -}
>>> -#else
>>> static int __remove_section(struct zone *zone, struct mem_section
>>> *ms)
>>> {
>>> unsigned long flags;
>>> @@ -337,9 +324,9 @@ static int __remove_section(struct zone *zone,
>>> struct mem_section *ms)
>>> pgdat_resize_lock(pgdat, &flags);
>>> sparse_remove_one_section(zone, ms);
>>> pgdat_resize_unlock(pgdat, &flags);
>>> - return 0;
>>> +
>>> + return ret;
>>> }
>>> -#endif
>>> /*
>>> * Reasonably generic function for adding memory. It is
>>> diff --git a/mm/sparse.c b/mm/sparse.c
>>> index fac95f2..ab9d755 100644
>>> --- a/mm/sparse.c
>>> +++ b/mm/sparse.c
>>> @@ -613,12 +613,13 @@ static inline struct page
>>> *kmalloc_section_memmap(unsigned long pnum, int nid,
>>> /* This will make the necessary allocations eventually. */
>>> return sparse_mem_map_populate(pnum, nid);
>>> }
>>> -static void __kfree_section_memmap(struct page *memmap, unsigned
>>> long nr_pages)
>>> +static void __kfree_section_memmap(struct page *page, unsigned long
>>> nr_pages)
>>> {
>>> - return; /* XXX: Not implemented yet */
>>> + vmemmap_kfree(page, nr_pages);
>>> }
>>> static void free_map_bootmem(struct page *page, unsigned long
>>> nr_pages)
>>> {
>>> + vmemmap_free_bootmem(page, nr_pages);
>>> }
>>> #else
>>> static struct page *__kmalloc_section_memmap(unsigned long nr_pages)
>>
>
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: fix VMX fix for memcpy case
From: Vaidyanathan Srinivasan @ 2012-10-06 15:19 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, paulus, Anton Blanchard
In-Reply-To: <20121002005912.GA27768@linux.vnet.ibm.com>
* Nishanth Aravamudan <nacc@linux.vnet.ibm.com> [2012-10-01 17:59:13]:
> [urgh, sorry Anton, Ben & Paul, inadvertently hit send before adding
> linuxppc-dev to the cc!]
>
> Hi Anton,
>
> In 2fae7cdb60240e2e2d9b378afbf6d9fcce8a3890 ("powerpc: Fix VMX in
> interrupt check in POWER7 copy loops"), I think you inadvertently
> introduced a regression for memcpy on POWER7 machines. copyuer and
> memcpy diverge slightly in their use of cr1 (copyuser doesn't use it,
> but memcpy does) and you end up clobbering that register with your fix.
> That results in (taken from an FC18 kernel):
>
> [ 18.824604] Unrecoverable VMX/Altivec Unavailable Exception f20 at c000000000052f40
> [ 18.824618] Oops: Unrecoverable VMX/Altivec Unavailable Exception, sig: 6 [#1]
> [ 18.824623] SMP NR_CPUS=1024 NUMA pSeries
> [ 18.824633] Modules linked in: tg3(+) be2net(+) cxgb4(+) ipr(+) sunrpc xts lrw gf128mul dm_crypt dm_round_robin dm_multipath linear raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua squashfs cramfs
> [ 18.824705] NIP: c000000000052f40 LR: c00000000020b874 CTR: 0000000000000512
> [ 18.824709] REGS: c000001f1fef7790 TRAP: 0f20 Not tainted (3.6.0-0.rc6.git0.2.fc18.ppc64)
> [ 18.824713] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 4802802e XER: 20000010
> [ 18.824726] SOFTE: 0
> [ 18.824728] CFAR: 0000000000000f20
> [ 18.824731] TASK = c000000fa7128400[0] 'swapper/24' THREAD: c000000fa7480000 CPU: 24
> GPR00: 00000000ffffffc0 c000001f1fef7a10 c00000000164edc0 c000000f9b9a8120
> GPR04: c000000f9b9a8124 0000000000001438 0000000000000060 03ffffff064657ee
> GPR08: 0000000080000000 0000000000000010 0000000000000020 0000000000000030
> GPR12: 0000000028028022 c00000000ff25400 0000000000000001 0000000000000000
> GPR16: 0000000000000000 7fffffffffffffff c0000000016b2180 c00000000156a500
> GPR20: c000000f968c7a90 c0000000131c31d8 c000001f1fef4000 c000000001561d00
> GPR24: 000000000000000a 0000000000000000 0000000000000001 0000000000000012
> GPR28: c000000fa5c04f80 00000000000008bc c0000000015c0a28 000000000000022e
> [ 18.824792] NIP [c000000000052f40] .memcpy_power7+0x5a0/0x7c4
> [ 18.824797] LR [c00000000020b874] .pcpu_free_area+0x174/0x2d0
> [ 18.824800] Call Trace:
> [ 18.824803] [c000001f1fef7a10] [c000000000052c14] .memcpy_power7+0x274/0x7c4 (unreliable)
> [ 18.824809] [c000001f1fef7b10] [c00000000020b874] .pcpu_free_area+0x174/0x2d0
> [ 18.824813] [c000001f1fef7bb0] [c00000000020ba88] .free_percpu+0xb8/0x1b0
> [ 18.824819] [c000001f1fef7c50] [c00000000043d144] .throtl_pd_exit+0x94/0xd0
> [ 18.824824] [c000001f1fef7cf0] [c00000000043acf8] .blkg_free+0x88/0xe0
> [ 18.824829] [c000001f1fef7d90] [c00000000018c048] .rcu_process_callbacks+0x2e8/0x8a0
> [ 18.824835] [c000001f1fef7e90] [c0000000000a8ce8] .__do_softirq+0x158/0x4d0
> [ 18.824840] [c000001f1fef7f90] [c000000000025ecc] .call_do_softirq+0x14/0x24
> [ 18.824845] [c000000fa7483650] [c000000000010e80] .do_softirq+0x160/0x1a0
> [ 18.824850] [c000000fa74836f0] [c0000000000a94a4] .irq_exit+0xf4/0x120
> [ 18.824854] [c000000fa7483780] [c000000000020c44] .timer_interrupt+0x154/0x4d0
> [ 18.824859] [c000000fa7483830] [c000000000003be0] decrementer_common+0x160/0x180
> [ 18.824866] --- Exception: 901 at .plpar_hcall_norets+0x84/0xd4
> [ 18.824866] LR = .check_and_cede_processor+0x48/0x80
> [ 18.824871] [c000000fa7483b20] [c00000000007f018] .check_and_cede_processor+0x18/0x80 (unreliable)
> [ 18.824877] [c000000fa7483b90] [c00000000007f104] .dedicated_cede_loop+0x84/0x150
> [ 18.824883] [c000000fa7483c50] [c0000000006bc030] .cpuidle_enter+0x30/0x50
> [ 18.824887] [c000000fa7483cc0] [c0000000006bc9f4] .cpuidle_idle_call+0x104/0x720
> [ 18.824892] [c000000fa7483d80] [c000000000070af8] .pSeries_idle+0x18/0x40
> [ 18.824897] [c000000fa7483df0] [c000000000019084] .cpu_idle+0x1a4/0x380
> [ 18.824902] [c000000fa7483ec0] [c0000000008a4c18] .start_secondary+0x520/0x528
> [ 18.824907] [c000000fa7483f90] [c0000000000093f0] .start_secondary_prolog+0x10/0x14
> [ 18.824911] Instruction dump:
> [ 18.824914] 38840008 90030000 90e30004 38630008 7ca62850 7cc300d0 78c7e102 7cf01120
> [ 18.824923] 78c60660 39200010 39400020 39600030 <7e00200c> 7c0020ce 38840010 409f001c
> [ 18.824935] ---[ end trace 0bb95124affaaa45 ]---
> [ 18.825046] Unrecoverable VMX/Altivec Unavailable Exception f20 at c000000000052d08
>
> I believe the right fix is to make memcpy match usercopy and not use
> cr1.
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> ---
> I've not tested this fix yet, but I think it's logically correct.
> Probably needs to go to 3.6-stable as well.
>
> diff --git a/arch/powerpc/lib/memcpy_power7.S b/arch/powerpc/lib/memcpy_power7.S
> index 7ba6c96..0663630 100644
> --- a/arch/powerpc/lib/memcpy_power7.S
> +++ b/arch/powerpc/lib/memcpy_power7.S
> @@ -239,8 +239,8 @@ _GLOBAL(memcpy_power7)
> ori r9,r9,1 /* stream=1 */
>
> srdi r7,r5,7 /* length in cachelines, capped at 0x3FF */
> - cmpldi cr1,r7,0x3FF
> - ble cr1,1f
> + cmpldi r7,0x3FF
> + ble 1f
> li r7,0x3FF
> 1: lis r0,0x0E00 /* depth=7 */
> sldi r7,r7,7
This change on v3.6 mainline tree allows kernel to boot without exception.
--Vaidy
^ permalink raw reply
* Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: Andi Kleen @ 2012-10-08 4:37 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, linux-ia64, wency, len.brown, linux-acpi, linux-sh,
x86, linux-kernel, cmetcalf, linux-mm, minchan.kim,
kosaki.motohiro, rientjes, sparclinux, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <506E4799.30407@jp.fujitsu.com>
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> writes:
> + }
> +
> + /*
> + * We use 2M page, but we need to remove part of them,
> + * so split 2M page to 4K page.
> + */
> + pte = alloc_low_page(&pte_phys);
What happens when the allocation fails?
alloc_low_page seems to be buggy there too, it would __pa a NULL
pointer.
> + if (pud_large(*pud)) {
> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
> + set_pud(pud, __pud(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 1G page, but we need to remove part of them,
> + * so split 1G page to 2M page.
> + */
> + pmd = alloc_low_page(&pmd_phys);
Same here
> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
> +
> + spin_lock(&init_mm.page_table_lock);
> + pud_populate(&init_mm, pud, __va(pmd_phys));
> + spin_unlock(&init_mm.page_table_lock);
> + }
> +
> + pmd = map_low_page(pmd_offset(pud, 0));
> + phys_pmd_remove(pmd, addr, end);
> + unmap_low_page(pmd);
> + __flush_tlb_all();
> + }
> + __flush_tlb_all();
This doesn't flush the other CPUs doesn't it?
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: Wen Congyang @ 2012-10-08 5:23 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, Yasuaki Ishimatsu, minchan.kim,
kosaki.motohiro, rientjes, sparclinux, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <m2d30tvatv.fsf@firstfloor.org>
At 10/08/2012 12:37 PM, Andi Kleen Wrote:
> Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> writes:
>> + }
>> +
>> + /*
>> + * We use 2M page, but we need to remove part of them,
>> + * so split 2M page to 4K page.
>> + */
>> + pte = alloc_low_page(&pte_phys);
>
> What happens when the allocation fails?
>
> alloc_low_page seems to be buggy there too, it would __pa a NULL
> pointer.
Yes, it will cause kernek panicked in __pa() if CONFI_DEBUG_VIRTUAL is set.
Otherwise, it will return a NULL pointer. I will update this patch to deal
with NULL pointer.
>
>> + if (pud_large(*pud)) {
>> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
>> + set_pud(pud, __pud(0));
>> + pages++;
>> + continue;
>> + }
>> +
>> + /*
>> + * We use 1G page, but we need to remove part of them,
>> + * so split 1G page to 2M page.
>> + */
>> + pmd = alloc_low_page(&pmd_phys);
>
> Same here
>
>> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
>> +
>> + spin_lock(&init_mm.page_table_lock);
>> + pud_populate(&init_mm, pud, __va(pmd_phys));
>> + spin_unlock(&init_mm.page_table_lock);
>> + }
>> +
>> + pmd = map_low_page(pmd_offset(pud, 0));
>> + phys_pmd_remove(pmd, addr, end);
>> + unmap_low_page(pmd);
>> + __flush_tlb_all();
>> + }
>> + __flush_tlb_all();
>
> This doesn't flush the other CPUs doesn't it?
How to flush the other CPU's tlb? use on_each_cpu() to run __flush_tlb_all()
on each online cpu?
Thanks
Wen Congyang
>
> -Andi
>
^ permalink raw reply
* Re: [PATCH 0/10] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-08 5:26 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, Yasuaki Ishimatsu, minchan.kim,
rientjes, sparclinux, cl, linuxppc-dev, akpm, liuj97
In-Reply-To: <CAHGf_=qCZvL7xcOkea80Y995sZWkOMQLLVnuvLUto4W+qpUbWA@mail.gmail.com>
At 10/06/2012 03:06 AM, KOSAKI Motohiro Wrote:
>> Known problems:
>> 1. memory can't be offlined when CONFIG_MEMCG is selected.
>> For example: there is a memory device on node 1. The address range
>> is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>> and memory11 under the directory /sys/devices/system/memory/.
>> If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
>> when we online pages. When we online memory8, the memory stored page cgroup
>> is not provided by this memory device. But when we online memory9, the memory
>> stored page cgroup may be provided by memory8. So we can't offline memory8
>> now. We should offline the memory in the reversed order.
>> When the memory device is hotremoved, we will auto offline memory provided
>> by this memory device. But we don't know which memory is onlined first, so
>> offlining memory may fail. In such case, you should offline the memory by
>> hand before hotremoving the memory device.
>
> Just iterate twice. 1st iterate: offline every non primary memory
> block. 2nd iterate:
> offline primary (i.e. first added) memory block. It may work.
>
OK, I will try it.
Thanks
Wen Congyang
^ permalink raw reply
* RE: [RFC PATCH] powerpc/fsl: add timer wakeup source
From: Wang Dongsheng-B40534 @ 2012-10-08 7:13 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala
Cc: Wang Dongsheng, linuxppc-dev@lists.ozlabs.org list,
Li Yang-R58472, linux-pm@vger.kernel.org
In-Reply-To: <1349302807.31013.20@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, October 04, 2012 6:20 AM
> To: Kumar Gala
> Cc: Wang Dongsheng; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org list=
;
> Wang Dongsheng-B40534; Li Yang-R58472; linux-pm@vger.kernel.org
> Subject: Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
>=20
> On 10/03/2012 08:35:58 AM, Kumar Gala wrote:
> >
> > On Oct 3, 2012, at 5:42 AM, Wang Dongsheng wrote:
> >
> > > This is only for freescale powerpc platform. The driver provides a
> > way
> > > to wake up system. Proc
> > interface(/proc/powerpc/wakeup_timer_seconds).
> > >
> > > eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds", 5 seconds after
> > > the system will be woken up. echo another time into proc
> > interface
> > > to update the time.
> > >
> > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > ---
> > > arch/powerpc/platforms/Kconfig | 23 +++
> > > arch/powerpc/platforms/Makefile | 1 +
> > > arch/powerpc/platforms/fsl_timer_wakeup.c | 217
> > +++++++++++++++++++++++++++++
> > > 3 files changed, 241 insertions(+)
> > > create mode 100644 arch/powerpc/platforms/fsl_timer_wakeup.c
> >
> > Adding the Linux PM list to see if there is some existing support for
> > this on other arch's in kernel.
> >
> > I'm pretty sure /proc/ is NOT where we want this exposed.
>=20
> Should probably go under the sysfs directory of the mpic device. Or
> better, make a generic interface for timer-based suspend wakeup (if there
> isn't one already). This current approach sits in an unpleasant middle
> ground between generic and device-specific.
> =09
/sys/power/wakeup_timer_seconds how about this?
I think it is a freescale generic interface, this interface control by
FSL_SOC && SUSPEND.
> > > diff --git a/arch/powerpc/platforms/Kconfig
> > b/arch/powerpc/platforms/Kconfig
> > > index b190a6e..7b9232a 100644
> > > --- a/arch/powerpc/platforms/Kconfig
> > > +++ b/arch/powerpc/platforms/Kconfig
> > > @@ -99,6 +99,29 @@ config MPIC_TIMER
> > > only tested on fsl chip, but it can potentially support
> > > other global timers complying to Open-PIC standard.
> > >
> > > +menuconfig FSL_WAKEUP_SOURCE
> > > + bool "Freescale wakeup source"
> > > + depends on FSL_SOC && SUSPEND
> > > + default n
> > > + help
> > > + This option enables wakeup source for wake up system
> > > + features. This is only for freescale powerpc platform.
> > > +
> > > +if FSL_WAKEUP_SOURCE
> > > +
> > > +config FSL_TIMER_WAKEUP
> > > + tristate "Freescale mpic global timer wakeup event"
> > > + default n
> > > + help
> > > + This is only for freescale powerpc platform. The driver
> > > + provides a way to wake up system.
> > > + Proc interface(/proc/powerpc/wakeup_timer_seconds).
> > > + eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds",
> > > + 5 seconds after the system will be woken up. echo another
> > > + time into proc interface to update the time.
> > > +
> > > +endif
>=20
> Use depends rather than if/else. Why do you need FSL_WAKEUP_SOURCE?
>
It lists all wake up source. If later have wakeup source can be improved by
it to control. Buttons event wakeup source will be added after the timer.
> These names are overly broad -- this is only for FSL MPIC, not for other
> FSL chips (e.g. mpc83xx has a different global timer implementation, and
> there's FSL ARM chips, etc).
>=20
Yes, thanks. Change to FSL_MPIC_TIMER_WAKEUP.
> > > +static ssize_t timer_wakeup_write(struct file *file, const char
> > __user *buf,
> > > + size_t count, loff_t *off)
> > > +{
> > > + struct fsl_timer_wakeup *priv;
> > > + struct inode *inode =3D file->f_path.dentry->d_inode;
> > > + struct proc_dir_entry *dp;
> > > + struct timeval time;
> > > + char *kbuf;
> > > +
> > > + dp =3D PDE(inode);
> > > + priv =3D dp->data;
> > > +
> > > + kbuf =3D kzalloc(count + 1, GFP_KERNEL);
> > > + if (!kbuf)
> > > + return -ENOMEM;
> > > +
> > > + if (copy_from_user(kbuf, buf, count)) {
> > > + kfree(kbuf);
> > > + return -EFAULT;
> > > + }
> > > +
> > > + kbuf[count] =3D '\0';
> > > +
> > > + if (kstrtol(kbuf, 0, &time.tv_sec)) {
> > > + kfree(kbuf);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + kfree(kbuf);
> > > +
> > > + time.tv_usec =3D 0;
> > > +
> > > + mutex_lock(&priv->mutex);
> > > +
> > > + if (!time.tv_sec) {
> > > + if (priv->timer) {
> > > + mpic_free_timer(priv->timer);
> > > + priv->timer =3D NULL;
> > > + }
> > > + mutex_unlock(&priv->mutex);
> > > +
> > > + return count;
> > > + }
> > > +
> > > + if (priv->timer) {
> > > + mpic_free_timer(priv->timer);
> > > + priv->timer =3D NULL;
> > > + }
> > > +
> > > + priv->timer =3D mpic_request_timer(timer_event_interrupt, priv,
> > &time);
>=20
> If the new time is zero, consider that a cancellation of the timer and
> don't request a new one or return -EINVAL.
>=20
Thanks, I think i should add comments. Let this patch easy to read.
Here is get a new timer.
If the new time is zero, consider that has been checked.
if (!time.tv_sec) {...} this is check zero.
The "mpic_request_timer" before this code.
- Dongsheng
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Alexander Graf @ 2012-10-08 10:10 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF15B15F@039-SN2MPN1-013.039d.mgd.msft.net>
On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Wednesday, July 04, 2012 4:50 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =
MAS2
>> EPN mask for 64-bit
>>=20
>>=20
>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>=20
>>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant =
bits.
>>> Change get tlb eaddr to use this mask.
>>=20
>> Please see section 6.11.4.8 in the PowerISA 2.06b:
>>=20
>> MMU behavior is largely unaffected by whether the thread is in 32-bit
>> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =
The
>> only differ- ences occur in the EPN field of the TLB entry and the =
EPN
>> field of MAS2. The differences are summarized here.
>>=20
>> * Executing a tlbwe instruction in 32-bit mode will set bits =
0:31
>> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case =
those
>> bits are not written to zero.
>> * In 32-bit implementations, MAS2U can be used to read or write
>> EPN0:31 of MAS2.
>>=20
>> So if MSR.CM is not set tlbwe should mask the upper 32 bits out - =
which
>> can happen regardless of CONFIG_64BIT.
>=20
> MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0) =
according
> to section 6.10.3.10 in the PowerISA 2.06b.
>=20
> MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL =
define
> for this case.
So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=3D0?
>=20
>> Also, we need to implement MAS2U, to potentially make the upper =
32bits of
>> MAS2 available, right? But that one isn't as important as the first =
bit.
>=20
> MAS2U is guest privileged why does it need special care?
Maybe it's mapped to the upper bits of GMAS2 automatically?
> Freescale core Manuals and EREF does not mention MAS2U so I think I =
our case
> it is not implemented.
Please check with a simple mfspr() test on real hw to see if it really =
isn't implemented.
Alex
^ permalink raw reply
* [PATCH] powerpc/83xx: use module_i2c_driver to simplify the code
From: Wei Yongjun @ 2012-10-08 12:39 UTC (permalink / raw)
To: galak, benh, paulus, grant.likely, rob.herring
Cc: yongjun_wei, linuxppc-dev, devicetree-discuss, linux-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index ef6537b..d91799e 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -232,17 +232,7 @@ static struct i2c_driver mcu_driver = {
.id_table = mcu_ids,
};
-static int __init mcu_init(void)
-{
- return i2c_add_driver(&mcu_driver);
-}
-module_init(mcu_init);
-
-static void __exit mcu_exit(void)
-{
- i2c_del_driver(&mcu_driver);
-}
-module_exit(mcu_exit);
+module_i2c_driver(mcu_driver);
MODULE_DESCRIPTION("Power Management and GPIO expander driver for "
"MPC8349E-mITX-compatible MCU");
^ permalink raw reply related
* [PATCH] powerpc/windfarm: use module_i2c_driver to simplify the code
From: Wei Yongjun @ 2012-10-08 13:00 UTC (permalink / raw)
To: benh; +Cc: yongjun_wei, linuxppc-dev, linux-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/macintosh/windfarm_smu_sat.c | 13 +------------
drivers/macintosh/windfarm_max6690_sensor.c | 13 +------------
drivers/macintosh/windfarm_lm75_sensor.c | 14 +-------------
drivers/macintosh/windfarm_fcu_controls.c | 14 +-------------
4 files changed, 4 insertions(+), 50 deletions(-)
diff --git a/drivers/macintosh/windfarm_smu_sat.c b/drivers/macintosh/windfarm_smu_sat.c
index 426e810..d87f5ee 100644
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -364,18 +364,7 @@ static struct i2c_driver wf_sat_driver = {
.id_table = wf_sat_id,
};
-static int __init sat_sensors_init(void)
-{
- return i2c_add_driver(&wf_sat_driver);
-}
-
-static void __exit sat_sensors_exit(void)
-{
- i2c_del_driver(&wf_sat_driver);
-}
-
-module_init(sat_sensors_init);
-module_exit(sat_sensors_exit);
+module_i2c_driver(wf_sat_driver);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
MODULE_DESCRIPTION("SMU satellite sensors for PowerMac thermal control");
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 371b058..945a25b 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -130,18 +130,7 @@ static struct i2c_driver wf_max6690_driver = {
.id_table = wf_max6690_id,
};
-static int __init wf_max6690_sensor_init(void)
-{
- return i2c_add_driver(&wf_max6690_driver);
-}
-
-static void __exit wf_max6690_sensor_exit(void)
-{
- i2c_del_driver(&wf_max6690_driver);
-}
-
-module_init(wf_max6690_sensor_init);
-module_exit(wf_max6690_sensor_exit);
+module_i2c_driver(wf_max6690_driver);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
MODULE_DESCRIPTION("MAX6690 sensor objects for PowerMac thermal control");
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index b0c2d36..9ef32b3 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -174,19 +174,7 @@ static struct i2c_driver wf_lm75_driver = {
.id_table = wf_lm75_id,
};
-static int __init wf_lm75_sensor_init(void)
-{
- return i2c_add_driver(&wf_lm75_driver);
-}
-
-static void __exit wf_lm75_sensor_exit(void)
-{
- i2c_del_driver(&wf_lm75_driver);
-}
-
-
-module_init(wf_lm75_sensor_init);
-module_exit(wf_lm75_sensor_exit);
+module_i2c_driver(wf_lm75_driver);
MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
MODULE_DESCRIPTION("LM75 sensor objects for PowerMacs thermal control");
diff --git a/drivers/macintosh/windfarm_fcu_controls.c b/drivers/macintosh/windfarm_fcu_controls.c
index b3411ed..fd6ed15 100644
--- a/drivers/macintosh/windfarm_fcu_controls.c
+++ b/drivers/macintosh/windfarm_fcu_controls.c
@@ -593,19 +593,7 @@ static struct i2c_driver wf_fcu_driver = {
.id_table = wf_fcu_id,
};
-static int __init wf_fcu_init(void)
-{
- return i2c_add_driver(&wf_fcu_driver);
-}
-
-static void __exit wf_fcu_exit(void)
-{
- i2c_del_driver(&wf_fcu_driver);
-}
-
-
-module_init(wf_fcu_init);
-module_exit(wf_fcu_exit);
+module_i2c_driver(wf_fcu_driver);
MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
MODULE_DESCRIPTION("FCU control objects for PowerMacs thermal control");
^ permalink raw reply related
* RE: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Caraman Mihai Claudiu-B02008 @ 2012-10-08 13:06 UTC (permalink / raw)
To: Alexander Graf
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <0A87124F-B5D0-475C-A33C-A1F36C1B56D9@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Monday, October 08, 2012 1:11 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
> EPN mask for 64-bit
>=20
>=20
> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Wednesday, July 04, 2012 4:50 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
> >> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
> >> EPN mask for 64-bit
> >>
> >>
> >> On 25.06.2012, at 14:26, Mihai Caraman wrote:
> >>
> >>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant
> bits.
> >>> Change get tlb eaddr to use this mask.
> >>
> >> Please see section 6.11.4.8 in the PowerISA 2.06b:
> >>
> >> MMU behavior is largely unaffected by whether the thread is in 32-bit
> >> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =
The
> >> only differ- ences occur in the EPN field of the TLB entry and the EPN
> >> field of MAS2. The differences are summarized here.
> >>
> >> * Executing a tlbwe instruction in 32-bit mode will set bits 0:31
> >> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case
> those
> >> bits are not written to zero.
> >> * In 32-bit implementations, MAS2U can be used to read or write
> >> EPN0:31 of MAS2.
> >>
> >> So if MSR.CM is not set tlbwe should mask the upper 32 bits out -
> which
> >> can happen regardless of CONFIG_64BIT.
> >
> > MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)
> according
> > to section 6.10.3.10 in the PowerISA 2.06b.
> >
> > MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL
> define
> > for this case.
>=20
> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=3D0?
We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 will
respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does=
not
require this treatment since EPN upper bits are not taken into consideratio=
n anyway.
>=20
> >
> >> Also, we need to implement MAS2U, to potentially make the upper 32bits
> of
> >> MAS2 available, right? But that one isn't as important as the first
> bit.
> >
> > MAS2U is guest privileged why does it need special care?
>=20
> Maybe it's mapped to the upper bits of GMAS2 automatically?
GMAS2?
>=20
> > Freescale core Manuals and EREF does not mention MAS2U so I think I our
> case
> > it is not implemented.
>=20
> Please check with a simple mfspr() test on real hw to see if it really
> isn't implemented.
I will try this with SPR number 0x277.
-Mike
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Alexander Graf @ 2012-10-08 13:10 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF20D198@039-SN2MPN1-012.039d.mgd.msft.net>
On 08.10.2012, at 15:06, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Monday, October 08, 2012 1:11 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =
MAS2
>> EPN mask for 64-bit
>>=20
>>=20
>> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Wednesday, July 04, 2012 4:50 PM
>>>> To: Caraman Mihai Claudiu-B02008
>>>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>>>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>>>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =
MAS2
>>>> EPN mask for 64-bit
>>>>=20
>>>>=20
>>>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>>>=20
>>>>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant
>> bits.
>>>>> Change get tlb eaddr to use this mask.
>>>>=20
>>>> Please see section 6.11.4.8 in the PowerISA 2.06b:
>>>>=20
>>>> MMU behavior is largely unaffected by whether the thread is in =
32-bit
>>>> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1).=
The
>>>> only differ- ences occur in the EPN field of the TLB entry and the =
EPN
>>>> field of MAS2. The differences are summarized here.
>>>>=20
>>>> * Executing a tlbwe instruction in 32-bit mode will set bits =
0:31
>>>> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case
>> those
>>>> bits are not written to zero.
>>>> * In 32-bit implementations, MAS2U can be used to read or write
>>>> EPN0:31 of MAS2.
>>>>=20
>>>> So if MSR.CM is not set tlbwe should mask the upper 32 bits out -
>> which
>>>> can happen regardless of CONFIG_64BIT.
>>>=20
>>> MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)
>> according
>>> to section 6.10.3.10 in the PowerISA 2.06b.
>>>=20
>>> MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL
>> define
>>> for this case.
>>=20
>> So tlbe->mas2 is guaranteed to have the upper bits be 0 when =
MSR.CM=3D0?
>=20
> We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 =
will
> respect this but vcpu->arch.shared->mas2 will not. tlb entry selection =
does not
> require this treatment since EPN upper bits are not taken into =
consideration anyway.
That's fine. We don't control the contents of shared->mas2 anyway.
>=20
>>=20
>>>=20
>>>> Also, we need to implement MAS2U, to potentially make the upper =
32bits
>> of
>>>> MAS2 available, right? But that one isn't as important as the first
>> bit.
>>>=20
>>> MAS2U is guest privileged why does it need special care?
>>=20
>> Maybe it's mapped to the upper bits of GMAS2 automatically?
>=20
> GMAS2?
Ah. The guest has direct control over the real MAS2. Oh well.
>=20
>>=20
>>> Freescale core Manuals and EREF does not mention MAS2U so I think I =
our
>> case
>>> it is not implemented.
>>=20
>> Please check with a simple mfspr() test on real hw to see if it =
really
>> isn't implemented.
>=20
> I will try this with SPR number 0x277.
Thanks :)
Alex
^ permalink raw reply
* Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
From: Scott Wood @ 2012-10-08 20:55 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, Li Yang-R58472, linux-pm@vger.kernel.org,
Wang Dongsheng, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259DF1A14@039-SN2MPN1-021.039d.mgd.msft.net>
On 10/08/2012 02:13:26 AM, Wang Dongsheng-B40534 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, October 04, 2012 6:20 AM
> > To: Kumar Gala
> > Cc: Wang Dongsheng; Wood Scott-B07421; =20
> linuxppc-dev@lists.ozlabs.org list;
> > Wang Dongsheng-B40534; Li Yang-R58472; linux-pm@vger.kernel.org
> > Subject: Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
> >
> > On 10/03/2012 08:35:58 AM, Kumar Gala wrote:
> > >
> > > On Oct 3, 2012, at 5:42 AM, Wang Dongsheng wrote:
> > >
> > > > This is only for freescale powerpc platform. The driver =20
> provides a
> > > way
> > > > to wake up system. Proc
> > > interface(/proc/powerpc/wakeup_timer_seconds).
> > > >
> > > > eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds", 5 seconds =20
> after
> > > > the system will be woken up. echo another time into proc
> > > interface
> > > > to update the time.
> > > >
> > > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > > ---
> > > > arch/powerpc/platforms/Kconfig | 23 +++
> > > > arch/powerpc/platforms/Makefile | 1 +
> > > > arch/powerpc/platforms/fsl_timer_wakeup.c | 217
> > > +++++++++++++++++++++++++++++
> > > > 3 files changed, 241 insertions(+)
> > > > create mode 100644 arch/powerpc/platforms/fsl_timer_wakeup.c
> > >
> > > Adding the Linux PM list to see if there is some existing support =20
> for
> > > this on other arch's in kernel.
> > >
> > > I'm pretty sure /proc/ is NOT where we want this exposed.
> >
> > Should probably go under the sysfs directory of the mpic device. Or
> > better, make a generic interface for timer-based suspend wakeup (if =20
> there
> > isn't one already). This current approach sits in an unpleasant =20
> middle
> > ground between generic and device-specific.
> > =09
> /sys/power/wakeup_timer_seconds how about this?
> I think it is a freescale generic interface, this interface control by
> FSL_SOC && SUSPEND.
There's no such thing as a "Freescale generic interface". Linux APIs =20
are not organized by hardware vendor. Either make a truly generic =20
interface, reuse an existing one, or do something that is attached to =20
the specific driver.
> > > > diff --git a/arch/powerpc/platforms/Kconfig
> > > b/arch/powerpc/platforms/Kconfig
> > > > index b190a6e..7b9232a 100644
> > > > --- a/arch/powerpc/platforms/Kconfig
> > > > +++ b/arch/powerpc/platforms/Kconfig
> > > > @@ -99,6 +99,29 @@ config MPIC_TIMER
> > > > only tested on fsl chip, but it can potentially =20
> support
> > > > other global timers complying to Open-PIC standard.
> > > >
> > > > +menuconfig FSL_WAKEUP_SOURCE
> > > > + bool "Freescale wakeup source"
> > > > + depends on FSL_SOC && SUSPEND
> > > > + default n
> > > > + help
> > > > + This option enables wakeup source for wake up system
> > > > + features. This is only for freescale powerpc platform.
> > > > +
> > > > +if FSL_WAKEUP_SOURCE
> > > > +
> > > > +config FSL_TIMER_WAKEUP
> > > > + tristate "Freescale mpic global timer wakeup event"
> > > > + default n
> > > > + help
> > > > + This is only for freescale powerpc platform. The =20
> driver
> > > > + provides a way to wake up system.
> > > > + Proc interface(/proc/powerpc/wakeup_timer_seconds).
> > > > + eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds",
> > > > + 5 seconds after the system will be woken up. echo =20
> another
> > > > + time into proc interface to update the time.
> > > > +
> > > > +endif
> >
> > Use depends rather than if/else. Why do you need FSL_WAKEUP_SOURCE?
> >
> It lists all wake up source. If later have wakeup source can be =20
> improved by
> it to control. Buttons event wakeup source will be added after the =20
> timer.
It does not list all wake up sources -- there's also ethernet, USB, etc.
> > These names are overly broad -- this is only for FSL MPIC, not for =20
> other
> > FSL chips (e.g. mpc83xx has a different global timer =20
> implementation, and
> > there's FSL ARM chips, etc).
> >
> Yes, thanks. Change to FSL_MPIC_TIMER_WAKEUP.
>=20
> > > > +static ssize_t timer_wakeup_write(struct file *file, const char
> > > __user *buf,
> > > > + size_t count, loff_t *off)
> > > > +{
> > > > + struct fsl_timer_wakeup *priv;
> > > > + struct inode *inode =3D file->f_path.dentry->d_inode;
> > > > + struct proc_dir_entry *dp;
> > > > + struct timeval time;
> > > > + char *kbuf;
> > > > +
> > > > + dp =3D PDE(inode);
> > > > + priv =3D dp->data;
> > > > +
> > > > + kbuf =3D kzalloc(count + 1, GFP_KERNEL);
> > > > + if (!kbuf)
> > > > + return -ENOMEM;
> > > > +
> > > > + if (copy_from_user(kbuf, buf, count)) {
> > > > + kfree(kbuf);
> > > > + return -EFAULT;
> > > > + }
> > > > +
> > > > + kbuf[count] =3D '\0';
> > > > +
> > > > + if (kstrtol(kbuf, 0, &time.tv_sec)) {
> > > > + kfree(kbuf);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + kfree(kbuf);
> > > > +
> > > > + time.tv_usec =3D 0;
> > > > +
> > > > + mutex_lock(&priv->mutex);
> > > > +
> > > > + if (!time.tv_sec) {
> > > > + if (priv->timer) {
> > > > + mpic_free_timer(priv->timer);
> > > > + priv->timer =3D NULL;
> > > > + }
> > > > + mutex_unlock(&priv->mutex);
> > > > +
> > > > + return count;
> > > > + }
> > > > +
> > > > + if (priv->timer) {
> > > > + mpic_free_timer(priv->timer);
> > > > + priv->timer =3D NULL;
> > > > + }
> > > > +
> > > > + priv->timer =3D mpic_request_timer(timer_event_interrupt, =20
> priv,
> > > &time);
> >
> > If the new time is zero, consider that a cancellation of the timer =20
> and
> > don't request a new one or return -EINVAL.
> >
> Thanks, I think i should add comments. Let this patch easy to read.
> Here is get a new timer.
> If the new time is zero, consider that has been checked.
>=20
> if (!time.tv_sec) {...} this is check zero.
> The "mpic_request_timer" before this code.
Ah, I see. Wouldn't it be simpler to remove that block and just test =20
time.tv_sec when requesting the new timer?
-Scott=
^ permalink raw reply
* [PATCH] powerpc/usb: fix build warning
From: Kim Phillips @ 2012-10-08 21:47 UTC (permalink / raw)
To: linuxppc-dev, linux-usb; +Cc: Shengzhou Liu
commit 3735ba8db8e6ea22ad3ff524328926d8d780a884 "powerpc/usb: fix bug of
CPU hang when missing USB PHY clock" introduced a new build warning:
In file included from linux/drivers/usb/host/ehci-hcd.c:1208:0:
linux/drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_setup_phy':
linux/drivers/usb/host/ehci-fsl.c:225:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
this fixes it.
Cc: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 9bfde82..968f751 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -222,7 +222,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
if (pdata->controller_ver < 0) {
dev_warn(hcd->self.controller, "Could not get controller version\n");
- return;
+ return -EINVAL;
}
portsc = ehci_readl(ehci, &ehci->regs->port_status[port_offset]);
--
1.7.12.2
^ permalink raw reply related
* net: fix typo in freescale/ucc_geth.c
From: Michael Neuling @ 2012-10-08 23:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Rothwell, LKML, linuxppc-dev, linux-next, Maxime Bizon,
David S. Miller
In-Reply-To: <20121008173653.1d17895964980c98af59c8ea@canb.auug.org.au>
The following patch:
acb600d net: remove skb recycling
added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
This is a typo and should be dev_kfree_skb(). This fixes this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
This hit as a compile error in next-20121008 with mpc85xx_defconfig.
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index dfa0aaa..0a70bb5 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3268,7 +3268,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
if (netif_msg_rx_err(ugeth))
ugeth_err("%s, %d: ERROR!!! skb - 0x%08x",
__func__, __LINE__, (u32) skb);
- dev_free_skb(skb);
+ dev_kfree_skb(skb);
ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = NULL;
dev->stats.rx_dropped++;
^ permalink raw reply related
* Re: [PATCH 0/5] Move some OF functionality from pseries to generic OF code
From: Michael Ellerman @ 2012-10-08 23:54 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: cbe-oss-dev, devicetree-discuss, linuxppc-dev, LKML
In-Reply-To: <506B2E63.5090900@linux.vnet.ibm.com>
On Tue, 2012-10-02 at 13:11 -0500, Nathan Fontenot wrote:
> This set of patches moves some OF code that has been living
> in the pseries tree over to the generic OF code base. The
> functionality being migrated over is something that, I believe,
> should live in the generic code base. The specific functionality
> being migrated to generic OF code is;
Your changes collide with commit 475d0094293:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=475d0094293b51353e342d1198377967dbc48169
At a quick glance they don't look like they conflict in concept, just
textually.
cheers
^ permalink raw reply
* Re: memory-hotplug : suppres "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning
From: Yasuaki Ishimatsu @ 2012-10-09 2:51 UTC (permalink / raw)
To: Andrew Morton
Cc: len.brown, wency, linux-acpi, x86, linux-kernel, dave, linux-mm,
paulus, minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev,
liuj97
In-Reply-To: <20121005140938.e3e1e196.akpm@linux-foundation.org>
Hi Andrew,
2012/10/06 6:09, Andrew Morton wrote:
> On Thu, 4 Oct 2012 14:31:09 +0900
> Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> wrote:
>
>> When our x86 box calls __remove_pages(), release_mem_region() shows
>> many warnings. And x86 box cannot unregister iomem_resource.
>>
>> "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>"
>>
>> release_mem_region() has been changed as called in each PAGES_PER_SECTION
>> chunk since applying a patch(de7f0cba96786c). Because powerpc registers
>> iomem_resource in each PAGES_PER_SECTION chunk. But when I hot add memory
>> on x86 box, iomem_resource is register in each _CRS not PAGES_PER_SECTION
>> chunk. So x86 box unregisters iomem_resource.
>>
>> The patch fixes the problem.
>>
>> --- linux-3.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-04 14:22:59.833520792 +0900
>> +++ linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-04 14:23:05.150521411 +0900
>> @@ -77,7 +77,8 @@ static int pseries_remove_memblock(unsig
>> {
>> unsigned long start, start_pfn;
>> struct zone *zone;
>> - int ret;
>> + int i, ret;
>> + int sections_to_remove;
>>
>> start_pfn = base >> PAGE_SHIFT;
>>
>> @@ -97,9 +98,13 @@ static int pseries_remove_memblock(unsig
>> * to sysfs "state" file and we can't remove sysfs entries
>> * while writing to it. So we have to defer it to here.
>> */
>> - ret = __remove_pages(zone, start_pfn, memblock_size >> PAGE_SHIFT);
>> - if (ret)
>> - return ret;
>> + sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
>> + for (i = 0; i < sections_to_remove; i++) {
>> + unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
>> + ret = __remove_pages(zone, start_pfn, PAGES_PER_SECTION);
>> + if (ret)
>> + return ret;
>> + }
>
> It is inappropriate that `i' have a signed 32-bit type. I doubt if
> there's any possibility of an overflow bug here, but using a consistent
> and well-chosen type would eliminate all doubt.
>
> Note that __remove_pages() does use an unsigned long for this, although
> it stupidly calls that variable "i", despite the C programmers'
> expectation that a variable called "i" has type "int".
>
> The same applies to `sections_to_remove', but __remove_pages() went and
> decided to use an `int' for that variable. Sigh.
>
> Anyway, please have a think, and see if we can come up with the best
> and most accurate choice of types and identifiers in this code.
Your concern is right. Overflow bug may occur in the future.
So I changed type of "i" and "sections_to_remove" to "unsigned long".
Please merge it into your tree instead of previous patch.
__remove_pages() also has same concern. So I'll fix it.
-----------------------------------------------------------------------
When our x86 box calls __remove_pages(), release_mem_region() shows
many warnings. And x86 box cannot unregister iomem_resource.
"Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>"
release_mem_region() has been changed as called in each PAGES_PER_SECTION
chunk since applying a patch(de7f0cba96786c). Because powerpc registers
iomem_resource in each PAGES_PER_SECTION chunk. But when I hot add memory
on x86 box, iomem_resource is register in each _CRS not PAGES_PER_SECTION
chunk. So x86 box unregisters iomem_resource.
The patch fixes the problem.
CC: David Rientjes <rientjes@google.com>
CC: Jiang Liu <liuj97@gmail.com>
CC: Len Brown <len.brown@intel.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 11 ++++++++---
mm/memory_hotplug.c | 4 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- linux-3.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-05 14:33:09.516197839 +0900
+++ linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-09 11:27:50.555709827 +0900
@@ -78,6 +78,7 @@ static int pseries_remove_memblock(unsig
unsigned long start, start_pfn;
struct zone *zone;
int ret;
+ unsigned long i, sections_to_remove;
start_pfn = base >> PAGE_SHIFT;
@@ -97,9 +98,13 @@ static int pseries_remove_memblock(unsig
* to sysfs "state" file and we can't remove sysfs entries
* while writing to it. So we have to defer it to here.
*/
- ret = __remove_pages(zone, start_pfn, memblock_size >> PAGE_SHIFT);
- if (ret)
- return ret;
+ sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
+ for (i = 0; i < sections_to_remove; i++) {
+ unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
+ ret = __remove_pages(zone, start_pfn, PAGES_PER_SECTION);
+ if (ret)
+ return ret;
+ }
/*
* Update memory regions for memory remove
Index: linux-3.6/mm/memory_hotplug.c
===================================================================
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-05 15:21:42.856325965 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-05 15:21:43.047326148 +0900
@@ -596,11 +596,11 @@ int __remove_pages(struct zone *zone, un
BUG_ON(phys_start_pfn & ~PAGE_SECTION_MASK);
BUG_ON(nr_pages % PAGES_PER_SECTION);
+ release_mem_region(phys_start_pfn << PAGE_SHIFT, nr_pages * PAGE_SIZE);
+
sections_to_remove = nr_pages / PAGES_PER_SECTION;
for (i = 0; i < sections_to_remove; i++) {
unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
- release_mem_region(pfn << PAGE_SHIFT,
- PAGES_PER_SECTION << PAGE_SHIFT);
ret = __remove_section(zone, __pfn_to_section(pfn));
if (ret)
break;
^ permalink raw reply
* Re: net: fix typo in freescale/ucc_geth.c
From: David Miller @ 2012-10-09 4:21 UTC (permalink / raw)
To: mikey; +Cc: sfr, linux-kernel, linuxppc-dev, edumazet, linux-next, mbizon
In-Reply-To: <23452.1349740345@neuling.org>
From: Michael Neuling <mikey@neuling.org>
Date: Tue, 09 Oct 2012 10:52:25 +1100
> The following patch:
> acb600d net: remove skb recycling
> added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
>
> This is a typo and should be dev_kfree_skb(). This fixes this.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Applied, thanks a lot.
^ permalink raw reply
* Re: net: fix typo in freescale/ucc_geth.c
From: Eric Dumazet @ 2012-10-09 6:04 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, LKML, linuxppc-dev, Eric Dumazet, linux-next,
Maxime Bizon, David S. Miller
In-Reply-To: <23452.1349740345@neuling.org>
On Tue, 2012-10-09 at 10:52 +1100, Michael Neuling wrote:
> The following patch:
> acb600d net: remove skb recycling
> added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
>
> This is a typo and should be dev_kfree_skb(). This fixes this.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> This hit as a compile error in next-20121008 with mpc85xx_defconfig.
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index dfa0aaa..0a70bb5 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -3268,7 +3268,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
> if (netif_msg_rx_err(ugeth))
> ugeth_err("%s, %d: ERROR!!! skb - 0x%08x",
> __func__, __LINE__, (u32) skb);
> - dev_free_skb(skb);
> + dev_kfree_skb(skb);
>
> ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = NULL;
>
Oops, thanks Michael !
^ permalink raw reply
* Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-09 6:16 UTC (permalink / raw)
To: Vasilis Liaskovitis
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <20120926164649.GA7559@dhcp-192-168-178-175.profitbricks.localdomain>
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote:
> Hi,
>
> I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3]
> Running in a guest (qemu+seabios from [4]).
> CONFIG_SLAB=y
> CONFIG_DEBUG_SLAB=y
>
> After succesfull hot-add and online, I am doing a hot-remove with "echo 1 > /sys/bus/acpi/devices/PNP/eject"
> When I do the OSPM-eject, I often get slab corruption in "acpi-state" cache, or in other caches
I found the reason: when you do OSPM-eject, the kernel will auto offline and remove the memory.
But, offlining memory fails, and the memory is still used by the kernel. But device_release_driver()
doesn't tell this error to the caller acpi_bus_remove(). The kernel will poweroff and eject
the device by emulate _PS3 and _EJ0. The kernel uses some memory which doesn't exist. It's
very dangerous.
Thanks
Wen Conyang
>
> [ 170.566995] Slab corruption (Not tainted): Acpi-State start=ffff88009fc1e548, len=80
> [ 170.567265] Redzone: 0x0/0x0.
> [ 170.567399] Last user: [< (null)>](0x0)
> [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569712] Prev obj: start=000000009fc1e4d0, len=80
> [ 170.569869] BUG: unable to handle kernel paging request at 000000009fc1e520
> [ 170.570171] IP: [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.570397] PGD 7cf37067 PUD 0
> [ 170.570619] Oops: 0000 [#1] SMP
> [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata scsi_mod virtio_pci virtio_ring virtio
> [ 170.573474] CPU 0
> [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 170.573830] RIP: 0010:[<ffffffff8112803c>] [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.574106] RSP: 0018:ffff88003eaf3a70 EFLAGS: 00010202
> [ 170.574268] RAX: 000000009fc1e4c8 RBX: 0000000000000002 RCX: 00000000000024b8
> [ 170.574468] RDX: 000000009fc1e4c8 RSI: 000000009fc1e4c8 RDI: ffff88003e9bb980
> [ 170.574668] RBP: ffff88003e9bb980 R08: ffff880037964078 R09: 0000000000000000
> [ 170.574870] R10: 000000000000021e R11: 0000000000000002 R12: 000000009fc1e4c8
> [ 170.575070] R13: 000000009fc1e520 R14: 000000000000004f R15: 00000000ffffffa5
> [ 170.575274] FS: 00007fc6b7530700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 170.575494] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 170.575665] CR2: 000000009fc1e520 CR3: 000000007c9c1000 CR4: 00000000000006f0
> [ 170.575870] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 170.576075] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 170.576507] Stack:
> [ 170.576599] 0000000000000010 0000000001893fbe ffff88009fc1e000 0000000000000050
> [ 170.576938] 000000009fc1e4c8 000000000000004f 00000000ffffffa5 ffffffff8112899f
> [ 170.576938] ffff88003eb309d8 ffffffff81712d6d ffff88003e9bb980 ffff88009fc1e540
> [ 170.576938] Call Trace:
> [ 170.576938] [<ffffffff8112899f>] ? check_poison_obj+0x1df/0x1f0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff81128a9d>] ? cache_alloc_debugcheck_after.isra.52+0xed/0x220
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff8112beb5>] ? kmem_cache_alloc+0xb5/0x1e0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff812edf2d>] ? acpi_ds_result_push+0x5d/0x12e
> [ 170.576938] [<ffffffff812ed127>] ? acpi_ds_exec_end_op+0x28e/0x3d3
> [ 170.576938] [<ffffffff812fd86a>] ? acpi_ps_parse_loop+0x79f/0x931
> [ 170.576938] [<ffffffff812fdd6c>] ? acpi_ps_parse_aml+0x89/0x261
> [ 170.576938] [<ffffffff812fe50c>] ? acpi_ps_execute_method+0x1be/0x266
> [ 170.576938] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 170.576938] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 170.576938] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 170.576938] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 170.576938] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 170.576938] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 170.576938] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 170.576938] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 170.576938] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 170.576938] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 170.576938] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 170.576938] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 170.576938] Code: cb 75 dc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 8b 7f 0c 4c 89 e2 e8 02 fd ff ff 4c 89 e6 49 89 c5 48 89 ef e8 d4 fc ff ff <49> 8b 55 00 48 8b 30 48 c7 c7 8c 39 6f 81 31 c0 e8 3e 34 3b 00
>
> Other times, the problem happens on a slab object free:
>
> [ 52.313366] Offlined Pages 32768
> [ 52.800232] slab error in verify_redzone_free(): cache `Acpi-ParseExt': memory outside object was overwritten
> [ 52.801298] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12
> [ 52.802039] Call Trace:
> [ 52.802443] [<ffffffff811280cb>] ? __slab_error.isra.46+0x1b/0x30
> [ 52.803199] [<ffffffff811287b6>] ? cache_free_debugcheck+0x256/0x260
> [ 52.803940] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.804645] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.805321] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.806023] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.806762] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.807499] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.808183] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.808897] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.809659] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] ffff88008f809670: redzone 1:0x0, redzone 2:0x0.
> [ 52.810032] ------------[ cut here ]------------
> [ 52.810032] kernel BUG at mm/slab.c:3125!
> [ 52.810032] invalid opcode: 0000 [#1] SMP
> [ 52.810032] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis tpm tpm_bios microcode parport_pc parport evdev processor thermal_sys psmouse i2c_piix4 serio_raw i2c_core button ext3 jbd mbcache sg sr_mod cdrom virtio_net ata_generic virtio_blk virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 52.810032] CPU 0
> [ 52.810032] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 52.810032] RIP: 0010:[<ffffffff81128733>] [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP: 0018:ffff88003eaf3bc0 EFLAGS: 00010093
> [ 52.810032] RAX: 00000000017eac3c RBX: ffff88003e9bb700 RCX: 0000000002aaaaab
> [ 52.810032] RDX: 0000000000000000 RSI: 0000000000010000 RDI: 0000000000000060
> [ 52.810032] RBP: ffff88008f809670 R08: 09f911029d74e35b R09: 0000000000000000
> [ 52.810032] R10: 00000000000001d3 R11: 0000000000000002 R12: ffff88008f809000
> [ 52.810032] R13: ffffffff812e1b0e R14: 0000000000000000 R15: 0000000000010c00
> [ 52.810032] FS: 00007f63fc263700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 52.810032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 52.810032] CR2: 00007fff8d895b78 CR3: 000000007c866000 CR4: 00000000000006f0
> [ 52.810032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 52.810032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 52.810032] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 52.810032] Stack:
> [ 52.810032] ffff88003e9bb980 ffff88008f809670 ffff880037ba8e18 ffff88008f809678
> [ 52.810032] ffff88003e9bb700 0000000000000282 ffff88003e9bf270 ffffffff812e1b0e
> [ 52.810032] 0000000000000001 ffffffff81128fe3 ffff88003e80f5e8 ffff88003eb31748
> [ 52.810032] Call Trace:
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.810032] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.810032] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.810032] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.810032] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.810032] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] Code: 89 ea 49 89 38 8b 73 14 8b 7b 0c e8 18 f6 ff ff 49 b8 5b e3 74 9d 02 11 f9 09 4c 89 00 44 8b 7b 14 44 89 f8 e9 fa fe ff ff 0f 0b <0f> 0b 48 8b 40 30 e9 d9 fe ff ff e8 c6 43 3b 00 0f 0b 48 8b 40
> [ 52.810032] RIP [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP <ffff88003eaf3bc0>
> [ 52.810032] ---[ end trace c699c8cecd5870a3 ]---
>
>
> And other times, I see a filesystem related slab corruption when doing the eject.
> Here I have also seen a bad rss-counter state message.
>
> [ 232.114232] BUG: Bad rss-counter state mm:ffff88007d9c1f80 idx:0 val:1
> [ 232.115214] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 232.115807] IP: [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.116186] PGD 7cdec067 PUD 7c946067 PMD 0
> [ 232.116627] Oops: 0000 [#3] SMP
> [ 232.116990] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm microcode tpm_tis tpm tpm_bios evdev psmouse serio_raw i2c_piix4 i2c_core parport_pc parport processor thermal_sys button ext3 jbd mbcache virtio_net sg sr_mod cdrom virtio_blk ata_generic virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 232.120013] CPU 2
> [ 232.120013] Pid: 880, comm: dhclient Tainted: G D 3.6.0-rc7-guest #1 Bochs Bochs
> [ 232.120013] RIP: 0010:[<ffffffffa00cfce3>] [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.120013] RSP: 0018:ffff88007cd6fab8 EFLAGS: 00010246
> [ 232.120013] RAX: ffff88003e513f50 RBX: ffff88003e513f50 RCX: 0000000000000000
> [ 232.120013] RDX: 0000000000000000 RSI: ffff88003e513f50 RDI: ffff880097800000
> [ 232.120013] RBP: ffff88003e513f50 R08: 000000003e513f01 R09: 0000000180240024
> [ 232.120013] R10: ffff88003e513f50 R11: 00000000000198e0 R12: 0000000000000000
> [ 232.120013] R13: ffffffffa00eb437 R14: ffff880097800000 R15: 000000000000027a
> [ 232.120013] FS: 00007f082638d700(0000) GS:ffff88003ec80000(0000) knlGS:0000000000000000
> [ 232.120013] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 232.120013] CR2: 0000000000000000 CR3: 000000007c94c000 CR4: 00000000000006e0
> [ 232.120013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 232.120013] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 232.120013] Process dhclient (pid: 880, threadinfo ffff88007cd6e000, task ffff88007ca46800)
> [ 232.120013] Stack:
> [ 232.120013] ffff88007dc205b0 ffffffff8116645f ffff88007dc205b0 ffff88007dc205b0
> [ 232.120013] ffff88007cf58800 0000000000000000 000000000000000e 0000000000000000
> [ 232.120013] 000000000000027a ffffffff8112b934 0000005000000003 0000000000000fff
> [ 232.120013] Call Trace:
> [ 232.120013] [<ffffffff8116645f>] ? __find_get_block+0x7f/0x200
> [ 232.120013] [<ffffffff8112b934>] ? kmem_cache_alloc+0xe4/0x140
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffffa00d0279>] ? journal_get_write_access+0x29/0x50 [jbd]
> [ 232.120013] [<ffffffffa00eaeef>] ? __ext3_get_inode_loc+0xcf/0x360 [ext3]
> [ 232.120013] [<ffffffffa0101317>] ? __ext3_journal_get_write_access+0x27/0x60 [ext3]
> [ 232.120013] [<ffffffffa00eb213>] ? ext3_reserve_inode_write+0x73/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb27b>] ? ext3_mark_inode_dirty+0x3b/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffff8115ded6>] ? __mark_inode_dirty+0x36/0x230
> [ 232.120013] [<ffffffff811504a1>] ? update_time+0x71/0xb0
> [ 232.120013] [<ffffffff811536c9>] ? mnt_clone_write+0x9/0x20
> [ 232.120013] [<ffffffff81150581>] ? file_update_time+0xa1/0xf0
> [ 232.120013] [<ffffffff8103385c>] ? ptep_set_access_flags+0x6c/0x70
> [ 232.120013] [<ffffffff810e3f30>] ? __generic_file_aio_write+0x1a0/0x3c0
> [ 232.120013] [<ffffffff811396fb>] ? __sb_start_write+0x6b/0x130
> [ 232.120013] [<ffffffff810e41ce>] ? generic_file_aio_write+0x7e/0x100
> [ 232.120013] [<ffffffff81137484>] ? do_sync_write+0x94/0xd0
> [ 232.120013] [<ffffffff81137caa>] ? vfs_write+0xaa/0x160
> [ 232.120013] [<ffffffff81137f87>] ? sys_write+0x47/0x90
> [ 232.120013] [<ffffffff814e5765>] ? async_page_fault+0x25/0x30
> [ 232.120013] [<ffffffff814eca79>] ? system_call_fastpath+0x16/0x1b
> [ 232.120013] Code: 54 24 2c f6 47 14 04 74 1f 41 bc e2 ff ff ff 48 81 c4 98 00 00 00 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 4c 8b 27 <4d> 8b 3c 24 41 f6 07 02 75 d4 65 48 8b 04 25 80 b9 00 00 48 89
>
> Is this a known issue? If yes, can you point me to any relevant patches?
>
> When I do an SCI(hardware) eject, I have not seen corruptions. The acpi driver is
> evaluating fewer objects in this path I think, but I don't see why corruption can't
> happen here as well.
>
> I have seen similar problems with CONFIG_SLUB (I did not have debug_options
> there but I can also provide those if helpful)
>
> [1] https://lkml.org/lkml/2012/9/6/635
> [2] https://lkml.org/lkml/2012/9/11/542
> [3] https://lkml.org/lkml/2012/9/20/37
> [4] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/98691
>
> thanks,
>
> - Vasilis
>
^ permalink raw reply
* [RFC Patch] 405gp IBM EMAC Phy probe fails with no link
From: Andrew May @ 2012-10-09 6:23 UTC (permalink / raw)
To: linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
I have an older PPC 405GP board with a 2.6.33 kernel that fails to
install a eth0 instance because the phy probe fails when there is no
good ethernet link.
I have looked at the latest kernel code and it seems just about the same
in this area, but I have not tried it.
Does anyone else still have a 405GP board to try and see if eth0 comes
up with not enet cable?
I tried to probe the phy earlier and skip the emac_configure() call in
emac_init_phy() to avoid doing the MR0_SRST bit set.
But the phy read still times out.
I then went with this approach to re-call emac_init_phy() after the
emac_reset() finally completes when a cable is plugged in.
Does anyone else have any ideas why the phy probe fails on the first pass?
[-- Attachment #2: ibm_phyprobe.patch --]
[-- Type: text/x-patch, Size: 2450 bytes --]
diff -ur linux.orig/drivers/net/ibm_newemac/core.c linux/drivers/net/ibm_newemac/core.c
--- linux.orig/drivers/net/ibm_newemac/core.c 2012-10-08 12:38:33.000000000 -0700
+++ linux/drivers/net/ibm_newemac/core.c 2012-10-08 14:31:35.797089192 -0700
@@ -106,6 +106,7 @@
*/
static DECLARE_WAIT_QUEUE_HEAD(emac_probe_wait);
+static int emac_init_phy(struct emac_instance *dev);
/* Having stable interface names is a doomed idea. However, it would be nice
* if we didn't have completely random interface names at boot too :-) It's
* just a matter of making everybody's life easier. Since we are doing
@@ -135,7 +136,7 @@
EMAC_FTR_440EP_PHY_CLK_FIX))
DBG(dev, "%s" NL, error);
else if (net_ratelimit())
- printk(KERN_ERR "%s: %s\n", dev->ofdev->node->full_name, error);
+ printk(KERN_INFO "%s: %s\n", dev->ofdev->node->full_name, error);
}
/* EMAC PHY clock workaround:
@@ -161,6 +162,7 @@
}
/* PHY polling intervals */
+#define PHY_POLL_NO_PHY (5 * HZ)
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
@@ -1156,8 +1158,12 @@
/* Start PHY polling now.
*/
- if (dev->phy.address >= 0) {
+ if (dev->phy.address >= 0 || dev->phy.address == -2) {
int link_poll_interval;
+ if (dev->phy.address == -2) {
+ netif_carrier_off(dev->ndev);
+ link_poll_interval = PHY_POLL_NO_PHY;
+ }else
if (dev->phy.def->ops->poll_link(&dev->phy)) {
dev->phy.def->ops->read_link(&dev->phy);
emac_rx_clk_default(dev);
@@ -1243,7 +1249,17 @@
if (!dev->opened)
goto bail;
- if (dev->phy.def->ops->poll_link(&dev->phy)) {
+
+ if (!dev->phy.def) {
+ /* If the reset finally clears, because the phy now
+ * has a link, then reprobe for the phy.
+ */
+ if (emac_reset(dev) == 0)
+ {
+ emac_init_phy(dev);
+ }
+ link_poll_interval = PHY_POLL_NO_PHY;
+ }else if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
emac_rx_clk_default(dev);
/* Get new link parameters */
@@ -2376,7 +2392,7 @@
return 0;
}
-static int __devinit emac_init_phy(struct emac_instance *dev)
+static int emac_init_phy(struct emac_instance *dev)
{
struct device_node *np = dev->ofdev->node;
struct net_device *ndev = dev->ndev;
@@ -2470,7 +2486,9 @@
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
- return -ENXIO;
+ busy_phy_map = 0;
+ dev->phy.address = -2;
+ return 0;
}
/* Init PHY */
^ permalink raw reply
* support for Xilinx PCIe BUS IP core
From: Bashar Romanous @ 2012-10-09 7:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Dear All,
This is the first thread in the list, I'm working on research project that
requires me to have "PCI Express Bus Support" for Xilinx FPGA board
ML605 running PetaLinux (kernel 2.6.37.6) on MicroBlaze. I'm using Xilinx
soft IP core "PLB2PCIe bridge" configured as Root Complex. the problem is
that on the Linux Kernel side, in the "Bus Options", there is no support
for Xilinx PCIe Bus.
Has anybody written Linux Driver for this IP core? what about Xilinx' (*AXI
RC*/*EP* Bridge for *PCI Express)? any drivers for this?*
Best Regards,
Bashar
[-- Attachment #2: Type: text/html, Size: 1994 bytes --]
^ permalink raw reply
* Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-09 8:11 UTC (permalink / raw)
To: Vasilis Liaskovitis
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <20120926164649.GA7559@dhcp-192-168-178-175.profitbricks.localdomain>
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote:
> Hi,
>
> I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3]
> Running in a guest (qemu+seabios from [4]).
> CONFIG_SLAB=y
> CONFIG_DEBUG_SLAB=y
>
> After succesfull hot-add and online, I am doing a hot-remove with "echo 1 > /sys/bus/acpi/devices/PNP/eject"
> When I do the OSPM-eject, I often get slab corruption in "acpi-state" cache, or in other caches
The following patch can fix this problem:
https://lkml.org/lkml/2012/7/12/186
Thanks
Wen Congyang
>
> [ 170.566995] Slab corruption (Not tainted): Acpi-State start=ffff88009fc1e548, len=80
> [ 170.567265] Redzone: 0x0/0x0.
> [ 170.567399] Last user: [< (null)>](0x0)
> [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569712] Prev obj: start=000000009fc1e4d0, len=80
> [ 170.569869] BUG: unable to handle kernel paging request at 000000009fc1e520
> [ 170.570171] IP: [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.570397] PGD 7cf37067 PUD 0
> [ 170.570619] Oops: 0000 [#1] SMP
> [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata scsi_mod virtio_pci virtio_ring virtio
> [ 170.573474] CPU 0
> [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 170.573830] RIP: 0010:[<ffffffff8112803c>] [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.574106] RSP: 0018:ffff88003eaf3a70 EFLAGS: 00010202
> [ 170.574268] RAX: 000000009fc1e4c8 RBX: 0000000000000002 RCX: 00000000000024b8
> [ 170.574468] RDX: 000000009fc1e4c8 RSI: 000000009fc1e4c8 RDI: ffff88003e9bb980
> [ 170.574668] RBP: ffff88003e9bb980 R08: ffff880037964078 R09: 0000000000000000
> [ 170.574870] R10: 000000000000021e R11: 0000000000000002 R12: 000000009fc1e4c8
> [ 170.575070] R13: 000000009fc1e520 R14: 000000000000004f R15: 00000000ffffffa5
> [ 170.575274] FS: 00007fc6b7530700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 170.575494] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 170.575665] CR2: 000000009fc1e520 CR3: 000000007c9c1000 CR4: 00000000000006f0
> [ 170.575870] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 170.576075] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 170.576507] Stack:
> [ 170.576599] 0000000000000010 0000000001893fbe ffff88009fc1e000 0000000000000050
> [ 170.576938] 000000009fc1e4c8 000000000000004f 00000000ffffffa5 ffffffff8112899f
> [ 170.576938] ffff88003eb309d8 ffffffff81712d6d ffff88003e9bb980 ffff88009fc1e540
> [ 170.576938] Call Trace:
> [ 170.576938] [<ffffffff8112899f>] ? check_poison_obj+0x1df/0x1f0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff81128a9d>] ? cache_alloc_debugcheck_after.isra.52+0xed/0x220
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff8112beb5>] ? kmem_cache_alloc+0xb5/0x1e0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff812edf2d>] ? acpi_ds_result_push+0x5d/0x12e
> [ 170.576938] [<ffffffff812ed127>] ? acpi_ds_exec_end_op+0x28e/0x3d3
> [ 170.576938] [<ffffffff812fd86a>] ? acpi_ps_parse_loop+0x79f/0x931
> [ 170.576938] [<ffffffff812fdd6c>] ? acpi_ps_parse_aml+0x89/0x261
> [ 170.576938] [<ffffffff812fe50c>] ? acpi_ps_execute_method+0x1be/0x266
> [ 170.576938] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 170.576938] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 170.576938] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 170.576938] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 170.576938] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 170.576938] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 170.576938] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 170.576938] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 170.576938] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 170.576938] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 170.576938] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 170.576938] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 170.576938] Code: cb 75 dc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 8b 7f 0c 4c 89 e2 e8 02 fd ff ff 4c 89 e6 49 89 c5 48 89 ef e8 d4 fc ff ff <49> 8b 55 00 48 8b 30 48 c7 c7 8c 39 6f 81 31 c0 e8 3e 34 3b 00
>
> Other times, the problem happens on a slab object free:
>
> [ 52.313366] Offlined Pages 32768
> [ 52.800232] slab error in verify_redzone_free(): cache `Acpi-ParseExt': memory outside object was overwritten
> [ 52.801298] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12
> [ 52.802039] Call Trace:
> [ 52.802443] [<ffffffff811280cb>] ? __slab_error.isra.46+0x1b/0x30
> [ 52.803199] [<ffffffff811287b6>] ? cache_free_debugcheck+0x256/0x260
> [ 52.803940] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.804645] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.805321] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.806023] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.806762] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.807499] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.808183] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.808897] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.809659] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] ffff88008f809670: redzone 1:0x0, redzone 2:0x0.
> [ 52.810032] ------------[ cut here ]------------
> [ 52.810032] kernel BUG at mm/slab.c:3125!
> [ 52.810032] invalid opcode: 0000 [#1] SMP
> [ 52.810032] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis tpm tpm_bios microcode parport_pc parport evdev processor thermal_sys psmouse i2c_piix4 serio_raw i2c_core button ext3 jbd mbcache sg sr_mod cdrom virtio_net ata_generic virtio_blk virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 52.810032] CPU 0
> [ 52.810032] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 52.810032] RIP: 0010:[<ffffffff81128733>] [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP: 0018:ffff88003eaf3bc0 EFLAGS: 00010093
> [ 52.810032] RAX: 00000000017eac3c RBX: ffff88003e9bb700 RCX: 0000000002aaaaab
> [ 52.810032] RDX: 0000000000000000 RSI: 0000000000010000 RDI: 0000000000000060
> [ 52.810032] RBP: ffff88008f809670 R08: 09f911029d74e35b R09: 0000000000000000
> [ 52.810032] R10: 00000000000001d3 R11: 0000000000000002 R12: ffff88008f809000
> [ 52.810032] R13: ffffffff812e1b0e R14: 0000000000000000 R15: 0000000000010c00
> [ 52.810032] FS: 00007f63fc263700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 52.810032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 52.810032] CR2: 00007fff8d895b78 CR3: 000000007c866000 CR4: 00000000000006f0
> [ 52.810032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 52.810032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 52.810032] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 52.810032] Stack:
> [ 52.810032] ffff88003e9bb980 ffff88008f809670 ffff880037ba8e18 ffff88008f809678
> [ 52.810032] ffff88003e9bb700 0000000000000282 ffff88003e9bf270 ffffffff812e1b0e
> [ 52.810032] 0000000000000001 ffffffff81128fe3 ffff88003e80f5e8 ffff88003eb31748
> [ 52.810032] Call Trace:
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.810032] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.810032] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.810032] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.810032] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.810032] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] Code: 89 ea 49 89 38 8b 73 14 8b 7b 0c e8 18 f6 ff ff 49 b8 5b e3 74 9d 02 11 f9 09 4c 89 00 44 8b 7b 14 44 89 f8 e9 fa fe ff ff 0f 0b <0f> 0b 48 8b 40 30 e9 d9 fe ff ff e8 c6 43 3b 00 0f 0b 48 8b 40
> [ 52.810032] RIP [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP <ffff88003eaf3bc0>
> [ 52.810032] ---[ end trace c699c8cecd5870a3 ]---
>
>
> And other times, I see a filesystem related slab corruption when doing the eject.
> Here I have also seen a bad rss-counter state message.
>
> [ 232.114232] BUG: Bad rss-counter state mm:ffff88007d9c1f80 idx:0 val:1
> [ 232.115214] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 232.115807] IP: [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.116186] PGD 7cdec067 PUD 7c946067 PMD 0
> [ 232.116627] Oops: 0000 [#3] SMP
> [ 232.116990] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm microcode tpm_tis tpm tpm_bios evdev psmouse serio_raw i2c_piix4 i2c_core parport_pc parport processor thermal_sys button ext3 jbd mbcache virtio_net sg sr_mod cdrom virtio_blk ata_generic virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 232.120013] CPU 2
> [ 232.120013] Pid: 880, comm: dhclient Tainted: G D 3.6.0-rc7-guest #1 Bochs Bochs
> [ 232.120013] RIP: 0010:[<ffffffffa00cfce3>] [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.120013] RSP: 0018:ffff88007cd6fab8 EFLAGS: 00010246
> [ 232.120013] RAX: ffff88003e513f50 RBX: ffff88003e513f50 RCX: 0000000000000000
> [ 232.120013] RDX: 0000000000000000 RSI: ffff88003e513f50 RDI: ffff880097800000
> [ 232.120013] RBP: ffff88003e513f50 R08: 000000003e513f01 R09: 0000000180240024
> [ 232.120013] R10: ffff88003e513f50 R11: 00000000000198e0 R12: 0000000000000000
> [ 232.120013] R13: ffffffffa00eb437 R14: ffff880097800000 R15: 000000000000027a
> [ 232.120013] FS: 00007f082638d700(0000) GS:ffff88003ec80000(0000) knlGS:0000000000000000
> [ 232.120013] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 232.120013] CR2: 0000000000000000 CR3: 000000007c94c000 CR4: 00000000000006e0
> [ 232.120013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 232.120013] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 232.120013] Process dhclient (pid: 880, threadinfo ffff88007cd6e000, task ffff88007ca46800)
> [ 232.120013] Stack:
> [ 232.120013] ffff88007dc205b0 ffffffff8116645f ffff88007dc205b0 ffff88007dc205b0
> [ 232.120013] ffff88007cf58800 0000000000000000 000000000000000e 0000000000000000
> [ 232.120013] 000000000000027a ffffffff8112b934 0000005000000003 0000000000000fff
> [ 232.120013] Call Trace:
> [ 232.120013] [<ffffffff8116645f>] ? __find_get_block+0x7f/0x200
> [ 232.120013] [<ffffffff8112b934>] ? kmem_cache_alloc+0xe4/0x140
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffffa00d0279>] ? journal_get_write_access+0x29/0x50 [jbd]
> [ 232.120013] [<ffffffffa00eaeef>] ? __ext3_get_inode_loc+0xcf/0x360 [ext3]
> [ 232.120013] [<ffffffffa0101317>] ? __ext3_journal_get_write_access+0x27/0x60 [ext3]
> [ 232.120013] [<ffffffffa00eb213>] ? ext3_reserve_inode_write+0x73/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb27b>] ? ext3_mark_inode_dirty+0x3b/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffff8115ded6>] ? __mark_inode_dirty+0x36/0x230
> [ 232.120013] [<ffffffff811504a1>] ? update_time+0x71/0xb0
> [ 232.120013] [<ffffffff811536c9>] ? mnt_clone_write+0x9/0x20
> [ 232.120013] [<ffffffff81150581>] ? file_update_time+0xa1/0xf0
> [ 232.120013] [<ffffffff8103385c>] ? ptep_set_access_flags+0x6c/0x70
> [ 232.120013] [<ffffffff810e3f30>] ? __generic_file_aio_write+0x1a0/0x3c0
> [ 232.120013] [<ffffffff811396fb>] ? __sb_start_write+0x6b/0x130
> [ 232.120013] [<ffffffff810e41ce>] ? generic_file_aio_write+0x7e/0x100
> [ 232.120013] [<ffffffff81137484>] ? do_sync_write+0x94/0xd0
> [ 232.120013] [<ffffffff81137caa>] ? vfs_write+0xaa/0x160
> [ 232.120013] [<ffffffff81137f87>] ? sys_write+0x47/0x90
> [ 232.120013] [<ffffffff814e5765>] ? async_page_fault+0x25/0x30
> [ 232.120013] [<ffffffff814eca79>] ? system_call_fastpath+0x16/0x1b
> [ 232.120013] Code: 54 24 2c f6 47 14 04 74 1f 41 bc e2 ff ff ff 48 81 c4 98 00 00 00 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 4c 8b 27 <4d> 8b 3c 24 41 f6 07 02 75 d4 65 48 8b 04 25 80 b9 00 00 48 89
>
> Is this a known issue? If yes, can you point me to any relevant patches?
>
> When I do an SCI(hardware) eject, I have not seen corruptions. The acpi driver is
> evaluating fewer objects in this path I think, but I don't see why corruption can't
> happen here as well.
>
> I have seen similar problems with CONFIG_SLUB (I did not have debug_options
> there but I can also provide those if helpful)
>
> [1] https://lkml.org/lkml/2012/9/6/635
> [2] https://lkml.org/lkml/2012/9/11/542
> [3] https://lkml.org/lkml/2012/9/20/37
> [4] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/98691
>
> thanks,
>
> - Vasilis
>
^ permalink raw reply
* Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: wujianguo @ 2012-10-09 8:26 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, jiang.liu, linux-ia64, wency, len.brown, linux-acpi,
linux-sh, wujianguo, x86, linux-kernel, cmetcalf, linux-mm,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, qiuxishi, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <506E4799.30407@jp.fujitsu.com>
Hi Congyang,
I think we should also free pages which are used by page tables after removing
page tables of the memory.
From: Jianguo Wu <wujianguo@huawei.com>
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
---
arch/x86/mm/init_64.c | 110 +++++++++++++++++++++++++++++++++++++++---------
1 files changed, 89 insertions(+), 21 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 5596dfa..81f9c3b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -675,6 +675,74 @@ int arch_add_memory(int nid, u64 start, u64 size)
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+static inline void free_pagetable(struct page *page)
+{
+ struct zone *zone;
+
+ __ClearPageReserved(page);
+ __free_page(page);
+
+ zone = page_zone(page);
+ zone_span_writelock(zone);
+ zone->present_pages++;
+ zone_span_writeunlock(zone);
+ totalram_pages++;
+}
+
+static void free_pte_table(pte_t *pte_start, pmd_t *pmd)
+{
+ pte_t *pte;
+ int i;
+
+ for (i = 0; i < PTRS_PER_PTE; i++) {
+ pte = pte_start + i;
+ if (pte_val(*pte))
+ break;
+ }
+
+ /* free a pte talbe */
+ if (i == PTRS_PER_PTE) {
+ free_pagetable(pmd_page(*pmd));
+ pmd_clear(pmd);
+ }
+}
+
+static void free_pmd_table(pmd_t *pmd_start, pud_t *pud)
+{
+ pmd_t *pmd;
+ int i;
+
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ pmd = pmd_start + i;
+ if (pmd_val(*pmd))
+ break;
+ }
+
+ /* free a pmd talbe */
+ if (i == PTRS_PER_PMD) {
+ free_pagetable(pud_page(*pud));
+ pud_clear(pud);
+ }
+}
+
+static void free_pud_table(pud_t *pud_start, pgd_t *pgd)
+{
+ pud_t *pud;
+ int i;
+
+ for (i = 0; i < PTRS_PER_PUD; i++) {
+ pud = pud_start + i;
+ if (pud_val(*pud))
+ break;
+ }
+
+ /* free a pud table */
+ if (i == PTRS_PER_PUD) {
+ free_pagetable(pgd_page(*pgd));
+ pgd_clear(pgd);
+ }
+}
+
static void __meminit
phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end)
{
@@ -704,21 +772,19 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
unsigned long pages = 0, next;
int i = pmd_index(addr);
- for (; i < PTRS_PER_PMD; i++, addr = next) {
+ for (; i < PTRS_PER_PMD && addr < end; i++, addr = next) {
unsigned long pte_phys;
pmd_t *pmd = pmd_page + pmd_index(addr);
pte_t *pte;
- if (addr >= end)
- break;
-
- next = (addr & PMD_MASK) + PMD_SIZE;
+ next = pmd_addr_end(addr, end);
if (!pmd_present(*pmd))
continue;
if (pmd_large(*pmd)) {
- if ((addr & ~PMD_MASK) == 0 && next <= end) {
+ if (IS_ALIGNED(addr, PMD_SIZE) &&
+ IS_ALIGNED(next, PMD_SIZE)) {
set_pmd(pmd, __pmd(0));
pages++;
continue;
@@ -729,7 +795,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
* so split 2M page to 4K page.
*/
pte = alloc_low_page(&pte_phys);
- __split_large_page((pte_t *)pmd, addr, pte);
+ __split_large_page((pte_t *)pmd,
+ (unsigned long)__va(addr), pte);
spin_lock(&init_mm.page_table_lock);
pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
@@ -738,7 +805,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
spin_lock(&init_mm.page_table_lock);
pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- phys_pte_remove(pte, addr, end);
+ phys_pte_remove(pte, addr, next);
+ free_pte_table(pte, pmd);
unmap_low_page(pte);
spin_unlock(&init_mm.page_table_lock);
}
@@ -751,21 +819,19 @@ phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
unsigned long pages = 0, next;
int i = pud_index(addr);
- for (; i < PTRS_PER_PUD; i++, addr = next) {
+ for (; i < PTRS_PER_PUD && addr < end; i++, addr = next) {
unsigned long pmd_phys;
pud_t *pud = pud_page + pud_index(addr);
pmd_t *pmd;
- if (addr >= end)
- break;
-
- next = (addr & PUD_MASK) + PUD_SIZE;
+ next = pud_addr_end(addr, end);
if (!pud_present(*pud))
continue;
if (pud_large(*pud)) {
- if ((addr & ~PUD_MASK) == 0 && next <= end) {
+ if (IS_ALIGNED(addr, PUD_SIZE) &&
+ IS_ALIGNED(next, PUD_SIZE)) {
set_pud(pud, __pud(0));
pages++;
continue;
@@ -776,15 +842,18 @@ phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
* so split 1G page to 2M page.
*/
pmd = alloc_low_page(&pmd_phys);
- __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
+ __split_large_page((pte_t *)pud,
+ (unsigned long)__va(addr),
+ (pte_t *)pmd);
spin_lock(&init_mm.page_table_lock);
pud_populate(&init_mm, pud, __va(pmd_phys));
spin_unlock(&init_mm.page_table_lock);
}
- pmd = map_low_page(pmd_offset(pud, 0));
- phys_pmd_remove(pmd, addr, end);
+ pmd = map_low_page((pmd_t *)pud_page_vaddr(*pud));
+ phys_pmd_remove(pmd, addr, next);
+ free_pmd_table(pmd, pud);
unmap_low_page(pmd);
__flush_tlb_all();
}
@@ -805,15 +874,14 @@ kernel_physical_mapping_remove(unsigned long start, unsigned long end)
pgd_t *pgd = pgd_offset_k(start);
pud_t *pud;
- next = (start + PGDIR_SIZE) & PGDIR_MASK;
- if (next > end)
- next = end;
+ next = pgd_addr_end(start, end);
if (!pgd_present(*pgd))
continue;
pud = map_low_page((pud_t *)pgd_page_vaddr(*pgd));
- phys_pud_remove(pud, __pa(start), __pa(end));
+ phys_pud_remove(pud, __pa(start), __pa(next));
+ free_pud_table(pud, pgd);
unmap_low_page(pud);
}
-- 1.7.6.1 .
On 2012-10-5 10:36, Yasuaki Ishimatsu wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
>
> For hot removing memory, we sholud remove page table about the memory.
> So the patch searches a page table about the removed memory, and clear
> page table.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
> arch/x86/include/asm/pgtable_types.h | 1
> arch/x86/mm/init_64.c | 147 +++++++++++++++++++++++++++++++++++
> arch/x86/mm/pageattr.c | 47 +++++------
> 3 files changed, 173 insertions(+), 22 deletions(-)
>
> Index: linux-3.6/arch/x86/mm/init_64.c
> ===================================================================
> --- linux-3.6.orig/arch/x86/mm/init_64.c 2012-10-04 18:30:21.171698416 +0900
> +++ linux-3.6/arch/x86/mm/init_64.c 2012-10-04 18:30:27.317704652 +0900
> @@ -675,6 +675,151 @@ int arch_add_memory(int nid, u64 start,
> }
> EXPORT_SYMBOL_GPL(arch_add_memory);
>
> +static void __meminit
> +phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end)
> +{
> + unsigned pages = 0;
> + int i = pte_index(addr);
> +
> + pte_t *pte = pte_page + pte_index(addr);
> +
> + for (; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE, pte++) {
> +
> + if (addr >= end)
> + break;
> +
> + if (!pte_present(*pte))
> + continue;
> +
> + pages++;
> + set_pte(pte, __pte(0));
> + }
> +
> + update_page_count(PG_LEVEL_4K, -pages);
> +}
> +
> +static void __meminit
> +phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
> +{
> + unsigned long pages = 0, next;
> + int i = pmd_index(addr);
> +
> + for (; i < PTRS_PER_PMD; i++, addr = next) {
> + unsigned long pte_phys;
> + pmd_t *pmd = pmd_page + pmd_index(addr);
> + pte_t *pte;
> +
> + if (addr >= end)
> + break;
> +
> + next = (addr & PMD_MASK) + PMD_SIZE;
> +
> + if (!pmd_present(*pmd))
> + continue;
> +
> + if (pmd_large(*pmd)) {
> + if ((addr & ~PMD_MASK) == 0 && next <= end) {
> + set_pmd(pmd, __pmd(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 2M page, but we need to remove part of them,
> + * so split 2M page to 4K page.
> + */
> + pte = alloc_low_page(&pte_phys);
> + __split_large_page((pte_t *)pmd, addr, pte);
> +
> + spin_lock(&init_mm.page_table_lock);
> + pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
> + spin_unlock(&init_mm.page_table_lock);
> + }
> +
> + spin_lock(&init_mm.page_table_lock);
> + pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd));
> + phys_pte_remove(pte, addr, end);
> + unmap_low_page(pte);
> + spin_unlock(&init_mm.page_table_lock);
> + }
> + update_page_count(PG_LEVEL_2M, -pages);
> +}
> +
> +static void __meminit
> +phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
> +{
> + unsigned long pages = 0, next;
> + int i = pud_index(addr);
> +
> + for (; i < PTRS_PER_PUD; i++, addr = next) {
> + unsigned long pmd_phys;
> + pud_t *pud = pud_page + pud_index(addr);
> + pmd_t *pmd;
> +
> + if (addr >= end)
> + break;
> +
> + next = (addr & PUD_MASK) + PUD_SIZE;
> +
> + if (!pud_present(*pud))
> + continue;
> +
> + if (pud_large(*pud)) {
> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
> + set_pud(pud, __pud(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 1G page, but we need to remove part of them,
> + * so split 1G page to 2M page.
> + */
> + pmd = alloc_low_page(&pmd_phys);
> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
> +
> + spin_lock(&init_mm.page_table_lock);
> + pud_populate(&init_mm, pud, __va(pmd_phys));
> + spin_unlock(&init_mm.page_table_lock);
> + }
> +
> + pmd = map_low_page(pmd_offset(pud, 0));
> + phys_pmd_remove(pmd, addr, end);
> + unmap_low_page(pmd);
> + __flush_tlb_all();
> + }
> + __flush_tlb_all();
> +
> + update_page_count(PG_LEVEL_1G, -pages);
> +}
> +
> +void __meminit
> +kernel_physical_mapping_remove(unsigned long start, unsigned long end)
> +{
> + unsigned long next;
> +
> + start = (unsigned long)__va(start);
> + end = (unsigned long)__va(end);
> +
> + for (; start < end; start = next) {
> + pgd_t *pgd = pgd_offset_k(start);
> + pud_t *pud;
> +
> + next = (start + PGDIR_SIZE) & PGDIR_MASK;
> + if (next > end)
> + next = end;
> +
> + if (!pgd_present(*pgd))
> + continue;
> +
> + pud = map_low_page((pud_t *)pgd_page_vaddr(*pgd));
> + phys_pud_remove(pud, __pa(start), __pa(end));
> + unmap_low_page(pud);
> + }
> +
> + __flush_tlb_all();
> +}
> +
> #ifdef CONFIG_MEMORY_HOTREMOVE
> int __ref arch_remove_memory(u64 start, u64 size)
> {
> @@ -687,6 +832,8 @@ int __ref arch_remove_memory(u64 start,
> ret = __remove_pages(zone, start_pfn, nr_pages);
> WARN_ON_ONCE(ret);
>
> + kernel_physical_mapping_remove(start, start + size);
> +
> return ret;
> }
> #endif
> Index: linux-3.6/arch/x86/include/asm/pgtable_types.h
> ===================================================================
> --- linux-3.6.orig/arch/x86/include/asm/pgtable_types.h 2012-10-04 18:26:51.925486954 +0900
> +++ linux-3.6/arch/x86/include/asm/pgtable_types.h 2012-10-04 18:30:27.322704656 +0900
> @@ -334,6 +334,7 @@ static inline void update_page_count(int
> * as a pte too.
> */
> extern pte_t *lookup_address(unsigned long address, unsigned int *level);
> +extern int __split_large_page(pte_t *kpte, unsigned long address, pte_t *pbase);
>
> #endif /* !__ASSEMBLY__ */
>
> Index: linux-3.6/arch/x86/mm/pageattr.c
> ===================================================================
> --- linux-3.6.orig/arch/x86/mm/pageattr.c 2012-10-04 18:26:51.923486952 +0900
> +++ linux-3.6/arch/x86/mm/pageattr.c 2012-10-04 18:30:27.328704662 +0900
> @@ -501,21 +501,13 @@ out_unlock:
> return do_split;
> }
>
> -static int split_large_page(pte_t *kpte, unsigned long address)
> +int __split_large_page(pte_t *kpte, unsigned long address, pte_t *pbase)
> {
> unsigned long pfn, pfninc = 1;
> unsigned int i, level;
> - pte_t *pbase, *tmp;
> + pte_t *tmp;
> pgprot_t ref_prot;
> - struct page *base;
> -
> - if (!debug_pagealloc)
> - spin_unlock(&cpa_lock);
> - base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
> - if (!debug_pagealloc)
> - spin_lock(&cpa_lock);
> - if (!base)
> - return -ENOMEM;
> + struct page *base = virt_to_page(pbase);
>
> spin_lock(&pgd_lock);
> /*
> @@ -523,10 +515,11 @@ static int split_large_page(pte_t *kpte,
> * up for us already:
> */
> tmp = lookup_address(address, &level);
> - if (tmp != kpte)
> - goto out_unlock;
> + if (tmp != kpte) {
> + spin_unlock(&pgd_lock);
> + return 1;
> + }
>
> - pbase = (pte_t *)page_address(base);
> paravirt_alloc_pte(&init_mm, page_to_pfn(base));
> ref_prot = pte_pgprot(pte_clrhuge(*kpte));
> /*
> @@ -579,17 +572,27 @@ static int split_large_page(pte_t *kpte,
> * going on.
> */
> __flush_tlb_all();
> + spin_unlock(&pgd_lock);
>
> - base = NULL;
> + return 0;
> +}
>
> -out_unlock:
> - /*
> - * If we dropped out via the lookup_address check under
> - * pgd_lock then stick the page back into the pool:
> - */
> - if (base)
> +static int split_large_page(pte_t *kpte, unsigned long address)
> +{
> + pte_t *pbase;
> + struct page *base;
> +
> + if (!debug_pagealloc)
> + spin_unlock(&cpa_lock);
> + base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
> + if (!debug_pagealloc)
> + spin_lock(&cpa_lock);
> + if (!base)
> + return -ENOMEM;
> +
> + pbase = (pte_t *)page_address(base);
> + if (__split_large_page(kpte, address, pbase))
> __free_page(base);
> - spin_unlock(&pgd_lock);
>
> return 0;
> }
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply related
* [GIT PULL] Disintegrate UAPI for powerpc [ver #2]
From: David Howells @ 2012-10-09 9:15 UTC (permalink / raw)
To: benh; +Cc: dhowells, linuxppc-dev, linux-kernel
Can you merge the following branch into the powerpc tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-powerpc-20121009
for you to fetch changes up to c3617f72036c909e1f6086b5b9e364e0ef90a6da:
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm (2012-10-09 09:47:26 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm
arch/powerpc/include/asm/Kbuild | 35 --
arch/powerpc/include/asm/bootx.h | 123 +------
arch/powerpc/include/asm/cputable.h | 35 +-
arch/powerpc/include/asm/elf.h | 311 +-----------------
arch/powerpc/include/asm/kvm_para.h | 70 +---
arch/powerpc/include/asm/mman.h | 27 +-
arch/powerpc/include/asm/nvram.h | 55 +---
arch/powerpc/include/asm/ptrace.h | 242 +-------------
arch/powerpc/include/asm/signal.h | 143 +-------
arch/powerpc/include/asm/spu_info.h | 29 +-
arch/powerpc/include/asm/swab.h | 15 +-
arch/powerpc/include/asm/termios.h | 69 +---
arch/powerpc/include/asm/types.h | 30 +-
arch/powerpc/include/asm/unistd.h | 374 +--------------------
arch/powerpc/include/uapi/asm/Kbuild | 41 +++
arch/powerpc/include/{ => uapi}/asm/auxvec.h | 0
arch/powerpc/include/{ => uapi}/asm/bitsperlong.h | 0
arch/powerpc/include/uapi/asm/bootx.h | 132 ++++++++
arch/powerpc/include/{ => uapi}/asm/byteorder.h | 0
arch/powerpc/include/uapi/asm/cputable.h | 36 ++
arch/powerpc/include/uapi/asm/elf.h | 307 +++++++++++++++++
arch/powerpc/include/{ => uapi}/asm/errno.h | 0
arch/powerpc/include/{ => uapi}/asm/fcntl.h | 0
arch/powerpc/include/{ => uapi}/asm/ioctl.h | 0
arch/powerpc/include/{ => uapi}/asm/ioctls.h | 0
arch/powerpc/include/{ => uapi}/asm/ipcbuf.h | 0
arch/powerpc/include/{ => uapi}/asm/kvm.h | 0
arch/powerpc/include/uapi/asm/kvm_para.h | 90 +++++
arch/powerpc/include/{ => uapi}/asm/linkage.h | 0
arch/powerpc/include/uapi/asm/mman.h | 31 ++
arch/powerpc/include/{ => uapi}/asm/msgbuf.h | 0
arch/powerpc/include/uapi/asm/nvram.h | 62 ++++
arch/powerpc/include/{ => uapi}/asm/param.h | 0
arch/powerpc/include/{ => uapi}/asm/poll.h | 0
arch/powerpc/include/{ => uapi}/asm/posix_types.h | 0
arch/powerpc/include/{ => uapi}/asm/ps3fb.h | 0
arch/powerpc/include/uapi/asm/ptrace.h | 259 +++++++++++++++
arch/powerpc/include/{ => uapi}/asm/resource.h | 0
arch/powerpc/include/{ => uapi}/asm/seccomp.h | 0
arch/powerpc/include/{ => uapi}/asm/sembuf.h | 0
arch/powerpc/include/{ => uapi}/asm/setup.h | 0
arch/powerpc/include/{ => uapi}/asm/shmbuf.h | 0
arch/powerpc/include/{ => uapi}/asm/sigcontext.h | 0
arch/powerpc/include/{ => uapi}/asm/siginfo.h | 0
arch/powerpc/include/uapi/asm/signal.h | 145 +++++++++
arch/powerpc/include/{ => uapi}/asm/socket.h | 0
arch/powerpc/include/{ => uapi}/asm/sockios.h | 0
arch/powerpc/include/uapi/asm/spu_info.h | 53 +++
arch/powerpc/include/{ => uapi}/asm/stat.h | 0
arch/powerpc/include/{ => uapi}/asm/statfs.h | 0
arch/powerpc/include/uapi/asm/swab.h | 23 ++
arch/powerpc/include/{ => uapi}/asm/termbits.h | 0
arch/powerpc/include/uapi/asm/termios.h | 76 +++++
arch/powerpc/include/uapi/asm/types.h | 40 +++
arch/powerpc/include/{ => uapi}/asm/ucontext.h | 0
arch/powerpc/include/uapi/asm/unistd.h | 380 ++++++++++++++++++++++
56 files changed, 1705 insertions(+), 1528 deletions(-)
rename arch/powerpc/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/bitsperlong.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/bootx.h
rename arch/powerpc/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/cputable.h
create mode 100644 arch/powerpc/include/uapi/asm/elf.h
rename arch/powerpc/include/{ => uapi}/asm/errno.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/kvm.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/kvm_para.h
rename arch/powerpc/include/{ => uapi}/asm/linkage.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/mman.h
rename arch/powerpc/include/{ => uapi}/asm/msgbuf.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/nvram.h
rename arch/powerpc/include/{ => uapi}/asm/param.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/poll.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/posix_types.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ps3fb.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/ptrace.h
rename arch/powerpc/include/{ => uapi}/asm/resource.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/seccomp.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/sembuf.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/setup.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/siginfo.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/signal.h
rename arch/powerpc/include/{ => uapi}/asm/socket.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/sockios.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/spu_info.h
rename arch/powerpc/include/{ => uapi}/asm/stat.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/statfs.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/swab.h
rename arch/powerpc/include/{ => uapi}/asm/termbits.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/termios.h
create mode 100644 arch/powerpc/include/uapi/asm/types.h
rename arch/powerpc/include/{ => uapi}/asm/ucontext.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/unistd.h
.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox