* MPC5200b jffs2 memcpy alignment problem
From: Stephan Gatzka @ 2012-06-30 19:16 UTC (permalink / raw)
To: linux-mtd, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]
Hello!
First of all, please apologize my cross posting.
I have a problem running jffs2 on an MPC5200b board. I run kernel 3.4,
but older kernels like 3.1.5 are also affected. Every time I mount
jffs2, previously written content gets garbled.
The problem was nailed down to memcpy(&fd->name, rd->name, checkedlen);
in jffs2_scan_dirent_node in fs/jffs2/scan.c.
This is a copy directly from the mapped flash.
memcpy from copy_32.S only ensures that the 32 bit stores to the
destination ptr are aligned. And that's the problem with the MPC5200b
because the user manual (Chapter 9.2, LocalPlus bus features) clearly
states that unaligned access is not supported. But the code above
results in unaligned loads from the LocalPlus bus.
I think there are two possible solutions:
1. Rewrite memcpy this way: Only if both src and dst are 32 bit aligned,
use 32 bit load/store to copy, otherwise use byte load/store
instructions. (btw. is there a reason for not to use the load multiple
and store multiple instructions in memcpy?) This might be the best way
to do because in my opinion the semantics of memcpy put no restrictions
on the alignment of src and dst.
2. use memcpy_fromio in the jffs2 code. memcpy_fromio behaves exactly in
the way I described above. This could be also a good solution because
flash access via LocalPlus bus is clearly IO.
What is your opinion where to fix this problem?
Regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4931 bytes --]
^ permalink raw reply
* Re: MPC5200b jffs2 memcpy alignment problem
From: Albrecht Dreß @ 2012-06-30 20:09 UTC (permalink / raw)
To: stephan; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <4FEF5098.8070602@gatzka.org>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
Hi Stephan:
Am 30.06.12 21:16 schrieb(en) Stephan Gatzka:
> I have a problem running jffs2 on an MPC5200b board. I run kernel 3.4, but older kernels like 3.1.5 are also affected. Every time I mount jffs2, previously written content gets garbled.
>
> The problem was nailed down to memcpy(&fd->name, rd->name, checkedlen); in jffs2_scan_dirent_node in fs/jffs2/scan.c.
[snip]
> 2. use memcpy_fromio in the jffs2 code. memcpy_fromio behaves exactly in the way I described above. This could be also a good solution because flash access via LocalPlus bus is clearly IO.
I don't recall who proposed this patch, but exactly this solution is around for a longer time (mayby you search archives...). On my board, I have a flash chip attached to the LocalBus in 16-bit mode. Based on 3.2.16, the patch is:
---8<----------------------------------------------------------------------------
--- linux-3.2.16-orig/fs/jffs2/scan.c 2012-04-23 00:31:32.000000000 +0200
+++ linux-3.2.16/fs/jffs2/scan.c 2012-04-27 13:23:06.000000000 +0200
@@ -509,7 +509,11 @@
sumptr = kmalloc(sumlen, GFP_KERNEL);
if (!sumptr)
return -ENOMEM;
+#ifdef CONFIG_PPC_MPC52xx
+ memcpy_fromio(sumptr + sumlen - buf_len, buf + buf_size - buf_len, buf_len);
+#else
memcpy(sumptr + sumlen - buf_len, buf + buf_size - buf_len, buf_len);
+#endif
}
if (buf_len < sumlen) {
/* Need to read more so that the entire summary node is present */
@@ -1039,7 +1043,11 @@
if (!fd) {
return -ENOMEM;
}
+#ifdef CONFIG_PPC_MPC52xx
+ memcpy_fromio(&fd->name, rd->name, checkedlen);
+#else
memcpy(&fd->name, rd->name, checkedlen);
+#endif
fd->name[checkedlen] = 0;
crc = crc32(0, fd->name, rd->nsize);
---8<----------------------------------------------------------------------------
Works perfectly with it...
Hope this helps,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: MPC5200b jffs2 memcpy alignment problem
From: Stephan Gatzka @ 2012-07-01 6:47 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <1341086991.2252.0@antares>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
Hi Albrecht,
> I don't recall who proposed this patch, but exactly this solution is
> around for a longer time (mayby you search archives...). On my board, I
> have a flash chip attached to the LocalBus in 16-bit mode. Based on
> 3.2.16, the patch is:
Thanks for your answer and yes, this patch will definitely work. But I
want to have a solution in the mainline kernel, that's why I'm asking
how to deal best with this problem.
Regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4931 bytes --]
^ permalink raw reply
* 3.5.0-rc5: BUG: soft lockup - CPU#0 stuck for 22s
From: Christian Kujau @ 2012-07-01 7:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: LKML
Hi,
while trying to upgrade from 3.4.0 to 3.5.0-rc5 on this Powerbook G4
(powerpc 32 bit), this happens during booting:
--------------
usb 2-1: new full-speed USB device number 4 using ohci_hcd
SCSI subsystem initialized
scsi0 : SBP-2 IEEE-1394
scsi1 : SBP-2 IEEE-1394
firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
scsi 0:0:0:0: Direct-Access Ext Hard Disk PQ: 0 ANSI: 4
[25 seconds later]
BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:695]
Modules linked in: sd_mod arc4 firewire_sbp2 scsi_mod b43 mac80211 cfg80211
irq event stamp: 56975532
hardirqs last enabled at (56975531): <c053aea8>] _raw_spin_unlock_irqrestore+0x40/0x9c
hardirqs last disabled at (56975532): <c0011688>] reenable_mmu+0x40/0x98
softirqs last enabled at (56966080): <c000f3f0>] call_do_softirq+0x14/0x24
softirqs last disabled at (56966073): <c000f3f0>] call_do_softirq+0x14/0x24
NIP: c053aeac LR: c053aea8 CTR: c009d510
REGS: eed1fd40 TRAP: 0901 Not tainted (3.5.0-rc5)
MSR: 00009032 ME IR DR RI > CR: 24042484 XER: 00000000
TASK = eece5c00[695] 'modprobe' THREAD: eed1e000 #012GPR00: 012GPR08:
NIP [c053aeac] _raw_spin_unlock_irqrestore+0x44/0x9c
LR [c053aea8] _raw_spin_unlock_irqrestore+0x40/0x9c
Call Trace:
[eed1fdf0] [c053aea8] _raw_spin_unlock_irqrestore+0x40/0x9c (unreliable)
[eed1fe00] [c005fbd8] lowest_in_progress+0xa8/0xcc
[eed1fe20] [c005fc5c] async_synchronize_cookie_domain+0x60/0x1f4
[eed1fe70] [c005fe3c] async_synchronize_full+0x3c/0x74
[eed1fe90] [c0083908] sys_init_module+0x174/0x1168
[eed1ff40] [c00117e8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff5d694#012[ 36.339234] LR = 0x100041c0
Instruction dump:
38630010
73e08000
--------------
This is what netconsole was able to receive. I've made a screenshot from
another boot with the same vanilla 3.5.0-rc5 (today's mainline) and put it
(along with some more details) up here:
http://nerdbynature.de/bits/3.5.0-rc5/soft_lockup/
Any ideas?
Thanks,
Christian.
--
BOFH excuse #436:
Daemon escaped from pentagram
^ permalink raw reply
* Re: [PATCH -V1 4/9] arch/powerpc: Use vsid and segment offset to represent virtual address
From: Aneesh Kumar K.V @ 2012-07-01 7:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, anton
In-Reply-To: <1341006336.2563.35.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Fri, 2012-06-29 at 19:47 +0530, Aneesh Kumar K.V wrote:
>>
>> +/* 78 bit power virtual address */
>> struct virt_addr {
>> - unsigned long addr;
>> + unsigned long vsid;
>> + unsigned long seg_off;
>> };
>
> Do we really need to do that ? It's really nasty...
>
> We are trying to add only a few bits, we get 12 for free by just using a
> page number (4k based always, not PAGE_SHIFT based btw) no ? That should
> get us going for a while....
>
Ok, will update to vpn in the next iteration.
Thanks
-aneesh
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Neuling @ 2012-07-01 10:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1341002709.2563.28.camel@pasglop>
> Here are a few powerpc fixes. Arguably some of this should have come to
> you earlier but I'm only just catching up after my medical leave.
>
> Mostly these fixes regressions, a couple are long standing bugs.
Benh,
This should probably go up now too:
http://patchwork.ozlabs.org/patch/167270/
Do you want me to send it separate from that series?
Mikey
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-07-01 11:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev list
In-Reply-To: <21923.1341139814@neuling.org>
On Sun, 2012-07-01 at 20:50 +1000, Michael Neuling wrote:
> > Here are a few powerpc fixes. Arguably some of this should have come to
> > you earlier but I'm only just catching up after my medical leave.
> >
> > Mostly these fixes regressions, a couple are long standing bugs.
>
> Benh,
>
> This should probably go up now too:
>
> http://patchwork.ozlabs.org/patch/167270/
>
> Do you want me to send it separate from that series?
Looks like it needs to go to -stable all the way down to 3.2... I'll
send it tomorrow with the appropriate tags.
Cheers,
Ben.
^ permalink raw reply
* Re: MPC5200b jffs2 memcpy alignment problem
From: William F. @ 2012-07-01 13:50 UTC (permalink / raw)
To: stephan; +Cc: Albrecht Dreß, linuxppc-dev, linux-mtd
In-Reply-To: <4FEFF265.3010102@gatzka.org>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
(SPAM)
Em 01-07-2012 03:47, Stephan Gatzka escreveu:
> Hi Albrecht,
>
> > I don't recall who proposed this patch, but exactly this solution is
> > around for a longer time (mayby you search archives...). On my
> board, I
> > have a flash chip attached to the LocalBus in 16-bit mode. Based on
> > 3.2.16, the patch is:
>
> Thanks for your answer and yes, this patch will definitely work. But I
> want to have a solution in the mainline kernel, that's why I'm asking
> how to deal best with this problem.
>
> Regards,
>
> Stephan
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
[-- Attachment #2: Type: text/html, Size: 1385 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: Yasuaki Ishimatsu @ 2012-07-02 2:53 UTC (permalink / raw)
To: Jiang Liu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEF1F6A.6090705@gmail.com>
Hi Jiang,
Thank you for your feedback.
2012/07/01 0:46, Jiang Liu wrote:
> On 06/27/2012 01:44 PM, Yasuaki Ishimatsu wrote:
>> When offline_pages() is called to offlined memory, the function fails since
>> all memory has been offlined. In this case, the function should succeed.
>> The patch adds the check function into offline_pages().
>>
>> 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>
>>
>> ---
>> drivers/base/memory.c | 20 ++++++++++++++++++++
>> include/linux/memory.h | 1 +
>> mm/memory_hotplug.c | 5 +++++
>> 3 files changed, 26 insertions(+)
>>
>> Index: linux-3.5-rc4/drivers/base/memory.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/drivers/base/memory.c 2012-06-26 13:28:16.726211752 +0900
>> +++ linux-3.5-rc4/drivers/base/memory.c 2012-06-26 13:34:22.423639904 +0900
>> @@ -70,6 +70,26 @@ void unregister_memory_isolate_notifier(
>> }
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> +bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn)
>> +{
>> + struct memory_block *mem;
>> + struct mem_section *section;
>> + unsigned long pfn, section_nr;
>> +
>> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> + section_nr = pfn_to_section_nr(pfn);
>> + section = __nr_to_section(section_nr);
> Is it possible for __nr_to_section return NULL here?
Yes. I'll add NULL check.
>
>> + mem = find_memory_block(section);
>> + if (!mem)
>> + continue;
>> + if (mem->state == MEM_OFFLINE)
>> + continue;
>> + return false;
>> + }
>> +
>> + return true;
>> +}
> Need a put_dev(&mem->dev) for the last memory block device handled before return.
Thanks.
I think kobject_put(&mem->dev.kobj) should be handled for all memory block
devices found by find_memory_block(). I'll update it.
Thanks,
Yasuaki Ishimatsu
>
>> +
>> /*
>> * register_memory - Setup a sysfs device for a memory block
>> */
>> Index: linux-3.5-rc4/include/linux/memory.h
>> ===================================================================
>> --- linux-3.5-rc4.orig/include/linux/memory.h 2012-06-25 04:53:04.000000000 +0900
>> +++ linux-3.5-rc4/include/linux/memory.h 2012-06-26 13:34:22.424639891 +0900
>> @@ -120,6 +120,7 @@ extern int memory_isolate_notify(unsigne
>> extern struct memory_block *find_memory_block_hinted(struct mem_section *,
>> struct memory_block *);
>> extern struct memory_block *find_memory_block(struct mem_section *);
>> +extern bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn);
>> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
>> enum mem_add_context { BOOT, HOTPLUG };
>> #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:28:16.743211538 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:48:38.264940468 +0900
>> @@ -887,6 +887,11 @@ static int __ref offline_pages(unsigned
>>
>> lock_memory_hotplug();
>>
>> + if (memory_is_offline(start_pfn, end_pfn)) {
>> + ret = 0;
>> + goto out;
>> + }
>> +
>> zone = page_zone(pfn_to_page(start_pfn));
>> node = zone_to_nid(zone);
>> nr_pages = end_pfn - start_pfn;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> 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
* Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages
From: Yasuaki Ishimatsu @ 2012-07-02 2:56 UTC (permalink / raw)
To: Jiang Liu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEF2075.2050603@gmail.com>
Hi Jiang,
2012/07/01 0:51, Jiang Liu wrote:
> On 06/27/2012 01:44 PM, Yasuaki Ishimatsu wrote:
>> When offline_pages() is called to offlined memory, the function fails since
>> all memory has been offlined. In this case, the function should succeed.
>> The patch adds the check function into offline_pages().
>>
>> 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>
>>
>> ---
>> drivers/base/memory.c | 20 ++++++++++++++++++++
>> include/linux/memory.h | 1 +
>> mm/memory_hotplug.c | 5 +++++
>> 3 files changed, 26 insertions(+)
>>
>> Index: linux-3.5-rc4/drivers/base/memory.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/drivers/base/memory.c 2012-06-26 13:28:16.726211752 +0900
>> +++ linux-3.5-rc4/drivers/base/memory.c 2012-06-26 13:34:22.423639904 +0900
>> @@ -70,6 +70,26 @@ void unregister_memory_isolate_notifier(
>> }
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> +bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn)
>> +{
>> + struct memory_block *mem;
>> + struct mem_section *section;
>> + unsigned long pfn, section_nr;
>> +
>> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> + section_nr = pfn_to_section_nr(pfn);
>> + section = __nr_to_section(section_nr);
>> + mem = find_memory_block(section);
> Seems find_memory_block_hinted() is more efficient than find_memory_block() here.
Thanks. I'll update it.
Thanks,
Yasuaki Ishimatsu
>
>> + if (!mem)
>> + continue;
>> + if (mem->state == MEM_OFFLINE)
>> + continue;
>> + return false;
>> + }
>> +
>> + return true;
>> +}
>> +
>> /*
>> * register_memory - Setup a sysfs device for a memory block
>> */
>> Index: linux-3.5-rc4/include/linux/memory.h
>> ===================================================================
>> --- linux-3.5-rc4.orig/include/linux/memory.h 2012-06-25 04:53:04.000000000 +0900
>> +++ linux-3.5-rc4/include/linux/memory.h 2012-06-26 13:34:22.424639891 +0900
>> @@ -120,6 +120,7 @@ extern int memory_isolate_notify(unsigne
>> extern struct memory_block *find_memory_block_hinted(struct mem_section *,
>> struct memory_block *);
>> extern struct memory_block *find_memory_block(struct mem_section *);
>> +extern bool memory_is_offline(unsigned long start_pfn, unsigned long end_pfn);
>> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
>> enum mem_add_context { BOOT, HOTPLUG };
>> #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-26 13:28:16.743211538 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26 13:48:38.264940468 +0900
>> @@ -887,6 +887,11 @@ static int __ref offline_pages(unsigned
>>
>> lock_memory_hotplug();
>>
>> + if (memory_is_offline(start_pfn, end_pfn)) {
>> + ret = 0;
>> + goto out;
>> + }
>> +
>> zone = page_zone(pfn_to_page(start_pfn));
>> node = zone_to_nid(zone);
>> nr_pages = end_pfn - start_pfn;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> 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
* Re: [RFC PATCH 10/12] memory-hotplug : free memmap of sparse-vmemmap
From: Yasuaki Ishimatsu @ 2012-07-02 3:01 UTC (permalink / raw)
To: Jiang Liu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, cl, linuxppc-dev, akpm
In-Reply-To: <4FEF2214.4000205@gmail.com>
Hi Jiang,
2012/07/01 0:58, Jiang Liu wrote:
> On 06/27/2012 01:56 PM, Yasuaki Ishimatsu wrote:
>> I don't think that all pages of virtual mapping in removed memory can be
>> freed, since page which type is MIX_SECTION_INFO is difficult to free.
>> So, the patch only frees page which type is SECTION_INFO at first.
>>
>> 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/x86/mm/init_64.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/mm.h | 2 +
>> mm/memory_hotplug.c | 5 ++
>> mm/sparse.c | 5 +-
>> 4 files changed, 99 insertions(+), 2 deletions(-)
>>
>> Index: linux-3.5-rc4/include/linux/mm.h
>> ===================================================================
>> --- linux-3.5-rc4.orig/include/linux/mm.h 2012-06-27 09:11:13.790150442 +0900
>> +++ linux-3.5-rc4/include/linux/mm.h 2012-06-27 09:11:16.433117400 +0900
>> @@ -1588,6 +1588,8 @@ int vmemmap_populate(struct page *start_
>> 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,
>> Index: linux-3.5-rc4/mm/sparse.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/sparse.c 2012-06-27 09:06:35.317631878 +0900
>> +++ linux-3.5-rc4/mm/sparse.c 2012-06-27 09:11:16.434117388 +0900
>> @@ -614,12 +614,13 @@ static inline struct page *kmalloc_secti
>> /* 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)
>> Index: linux-3.5-rc4/arch/x86/mm/init_64.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/arch/x86/mm/init_64.c 2012-06-27 09:11:13.791150430 +0900
>> +++ linux-3.5-rc4/arch/x86/mm/init_64.c 2012-06-27 09:11:59.254581998 +0900
>> @@ -978,6 +978,95 @@ vmemmap_populate(struct page *start_page
>> return 0;
>> }
>>
>> +unsigned long find_and_clear_pte_page(unsigned long addr, unsigned long end,
>> + struct page *page)
> I think the third parameter should be "struct page **pp" instead of "struct page *page".
> And "page = pte_page(*pte)" should be "*pp = pte_page(*pte)".
> Otherwise the found page pointer can't be returned to the caller and vmemmap_kfree()
> just sees random value in variable "page".
Oh, you are right. I'll update it.
Thanks,
Yasuaki Ishimatsu
>> +{
>> + pgd_t *pgd;
>> + pud_t *pud;
>> + pmd_t *pmd;
>> + pte_t *pte;
>> + unsigned long next;
>> +
>> + page = NULL;
>> +
>> + pgd = pgd_offset_k(addr);
>> + if (pgd_none(*pgd))
>> + return PAGE_SIZE;
>> +
>> + pud = pud_offset(pgd, addr);
>> + if (pud_none(*pud))
>> + return PAGE_SIZE;
>> +
>> + 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 = pte_page(*pte);
>> + pte_clear(&init_mm, addr, pte);
>> + } else {
>> + next = pmd_addr_end(addr, end);
>> +
>> + pmd = pmd_offset(pud, addr);
>> + if (pmd_none(*pmd))
>> + return next;
>> +
>> + page = pmd_page(*pmd);
>> + pmd_clear(pmd);
>> + }
>> +
>> + return next;
>> +}
>> +
>> +void __meminit
>> +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;
>> + unsigned int order;
>> + struct page *page;
>> +
>> + for (; addr < end; addr = next) {
>> + next = find_and_clear_pte_page(addr, end, page);
>> + if (!page)
>> + continue;
>> +
>> + if (is_vmalloc_addr(page))
>> + vfree(page);
>> + else {
>> + order = next - addr;
>> + free_pages((unsigned long)page,
>> + get_order(sizeof(struct page) * order));
>> + }
>> + }
>> +}
>> +
>> +void __meminit
>> +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;
>> + unsigned long magic;
>> +
>> + for (; addr < end; addr = next) {
>> + next = find_and_clear_pte_page(addr, end, page);
>> + if (!page)
>> + continue;
>> +
>> + magic = (unsigned long) page->lru.next;
>> + if (magic == SECTION_INFO)
>> + put_page_bootmem(page);
>> + }
>> +}
>> +
>> void __meminit
>> register_page_bootmem_memmap(unsigned long section_nr, struct page *start_page,
>> unsigned long size)
>> Index: linux-3.5-rc4/mm/memory_hotplug.c
>> ===================================================================
>> --- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-06-27 09:11:13.789150454 +0900
>> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-27 09:11:16.436117363 +0900
>> @@ -303,6 +303,8 @@ static int __meminit __add_section(int n
>> #ifdef CONFIG_SPARSEMEM_VMEMMAP
>> static int __remove_section(struct zone *zone, struct mem_section *ms)
>> {
>> + unsigned long flags;
>> + struct pglist_data *pgdat = zone->zone_pgdat;
>> int ret;
>>
>> if (!valid_section(ms))
>> @@ -310,6 +312,9 @@ static int __remove_section(struct zone
>>
>> ret = unregister_memory_section(ms);
>>
>> + pgdat_resize_lock(pgdat, &flags);
>> + sparse_remove_one_section(zone, ms);
>> + pgdat_resize_unlock(pgdat, &flags);
>> return ret;
>> }
>> #else
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> 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
* [PATCH] powerpc: Fixup oddity in entry_32.S
From: Benjamin Herrenschmidt @ 2012-07-02 4:47 UTC (permalink / raw)
To: linuxppc-dev
When I "fixed" the CONFIG_TRACE_IRQFLAGS case on interrupt entry,
I screwed up a little bit with the test for user space vs. kernel.
The code is fine, there's just some dead code around it. I basically
removed the test and always create the added stack frame whether
coming from user or kernel since in any case we do need to save
a bunch of volatile registers or bad things would happen (we can
take page faults in the kernel for example).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ba3aeb4..477ec2c 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -226,13 +226,7 @@ reenable_mmu: /* re-enable mmu so we can */
stw r3,16(r1)
stw r4,20(r1)
stw r5,24(r1)
- andi. r12,r12,MSR_PR
- b 11f
bl trace_hardirqs_off
- b 12f
-11:
- bl trace_hardirqs_off
-12:
lwz r5,24(r1)
lwz r4,20(r1)
lwz r3,16(r1)
^ permalink raw reply related
* Re: 3.5.0-rc5: BUG: soft lockup - CPU#0 stuck for 22s
From: Benjamin Herrenschmidt @ 2012-07-02 4:50 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.2.01.1207010009270.5568@trent.utfs.org>
On Sun, 2012-07-01 at 00:18 -0700, Christian Kujau wrote:
> Hi,
>
> while trying to upgrade from 3.4.0 to 3.5.0-rc5 on this Powerbook G4
> (powerpc 32 bit), this happens during booting:
>
> --------------
> usb 2-1: new full-speed USB device number 4 using ohci_hcd
> SCSI subsystem initialized
> scsi0 : SBP-2 IEEE-1394
> scsi1 : SBP-2 IEEE-1394
> firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
> scsi 0:0:0:0: Direct-Access Ext Hard Disk PQ: 0 ANSI: 4
Interesting... I observed something roughly similar on a dual G4
the other day associated with a 30s to 1mn pause during boot. RCU
was complaining loudly.
In my case, it did continue booting normally, is that the case for you ?
Also if I compile the kernel without CONFIG_SMP, it did go away as well,
do you observe that too ?
I don't have a spare cycle to investigate this problem this week I'm
afraid, it might help if you could try a bisection though.
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-07-02 4:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus
Here are two more fixes that I "missed" when scrubbing patchwork last
week which are worth still having in 3.5.
Cheers,
Ben.
The following changes since commit bc6dc752f35488160ffac07ae91bed1bddaea32a:
powerpc/pseries: Fix software invalidate TCE (2012-06-29 14:35:37 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to 2f584a146a2965b82fce89b8d2f95dc5cfe468d0:
powerpc/kvm: sldi should be sld (2012-07-02 14:30:12 +1000)
----------------------------------------------------------------
Anton Blanchard (1):
powerpc/xmon: Use cpumask iterator to avoid warning
Michael Neuling (1):
powerpc/kvm: sldi should be sld
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
arch/powerpc/xmon/xmon.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* linux-next: manual merge of the signal tree with Linus' tree
From: Stephen Rothwell @ 2012-07-02 6:12 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel, Tiejun Chen, linux-next, Paul Mackerras,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/powerpc/kernel/entry_64.S between commit c58ce2b1e3c7 ("ppc64: fix
missing to check all bits of _TIF_USER_WORK_MASK in preempt") from Linus'
tree and commit d07644a97726 ("powerpc: missing NOTIFY_RESUME check on
64bit if CONFIG_PREEMPT is set") from the signal tree.
I *think* that the former is a superset of the latter, so I just used the
former.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: 3.5.0-rc5: BUG: soft lockup - CPU#0 stuck for 22s
From: Christian Kujau @ 2012-07-02 6:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML
In-Reply-To: <1341204649.2588.29.camel@pasglop>
On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
> Interesting... I observed something roughly similar on a dual G4
> the other day associated with a 30s to 1mn pause during boot. RCU
> was complaining loudly.
>
> In my case, it did continue booting normally, is that the case for you ?
No, in my case it stopped booting, though there was no "panic" message.
> Also if I compile the kernel without CONFIG_SMP, it did go away as well,
> do you observe that too ?
This PoweBook G4 is UP anyway and I'm always building w/o CONFIG_SMP.
> I don't have a spare cycle to investigate this problem this week I'm
> afraid, it might help if you could try a bisection though.
Yes, I've started a bisection already and will report back.
FYI, I've put a netconsole-log below from another boot (in the
middle of a bisection), the instruction dump is slightly more complete.
Thanks!
Christian.
[ 40.345973] BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:691]
[ 40.347737] Modules linked in: sd_mod arc4 firewire_sbp2 scsi_mod b43 mac80211 cfg80211
[ 40.349443] irq event stamp: 65779272
[ 40.351156] hardirqs last enabled at (65779271): [<c052fae8>] _raw_spin_unlock_irqrestore+0x40/0x9c
[ 40.352911] hardirqs last disabled at (65779272): [<c0011648>] reenable_mmu+0x40/0x98
[ 40.354649] softirqs last enabled at (65769864): [<c000f3c0>] call_do_softirq+0x14/0x24
[ 40.356386] softirqs last disabled at (65769857): [<c000f3c0>] call_do_softirq+0x14/0x24
[ 40.358098] NIP: c005ee64 LR: c005ee54 CTR: c009c578
[ 40.359788] REGS: eece3d70 TRAP: 0901 Not tainted (3.4.0-05609-gc80ddb5)
[ 40.361517] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 24042482 XER: 00000000
[ 40.363261] TASK = eec30b80[691] 'modprobe' THREAD: eece2000#012
[ 40.363261] GPR00: c005ee54 eece3e20 eec30b80 00000000 00000002 c005edd0 00000000 00000000 #012
[ 40.363261] GPR08: 00000000 eece2000 00000000 00000001 24042488
[ 40.368310] NIP [c005ee64] async_synchronize_cookie_domain+0x70/0x1f4
[ 40.369978] LR [c005ee54] async_synchronize_cookie_domain+0x60/0x1f4
[ 40.371614] Call Trace:
[ 40.373226] [eece3e20] [c005ee54] async_synchronize_cookie_domain+0x60/0x1f4 (unreliable)
[ 40.374884] [eece3e70] [c005f034] async_synchronize_full+0x3c/0x74
[ 40.376524] [eece3e90] [c0082790] sys_init_module+0x178/0x1164
[ 40.378151] [eece3f40] [c00117a8] ret_from_syscall+0x0/0x38
[ 40.379783] --- Exception: c01 at 0xff5d694#012[ 40.379783] LR = 0x100041c0
[ 40.382928] Instruction dump:
[ 40.384489] 93a10044 419e0014 3d20c06f 8009d020 2f800000 419e017c 7fc3f378 4bfffed9
[ 40.386081] 7f9f1840 419d0060 7f9f1800 419e0050 <881bf008> 2f800000 419e0014 3d20c06f
--
BOFH excuse #241:
_Rosin_ core solder? But...
^ permalink raw reply
* Re: [PATCH 5/5] usb: gadget: composite: parse dt overrides
From: Felipe Balbi @ 2012-07-02 7:35 UTC (permalink / raw)
To: Alexandre Pereira da Silva
Cc: Roland Stigge, linux-doc, Greg Kroah-Hartman, devicetree-discuss,
linux-usb, linux-kernel, Felipe Balbi, Rob Herring, Rob Landley,
linuxppc-dev
In-Reply-To: <1340720833-781-6-git-send-email-aletes.xgr@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]
Hi,
On Tue, Jun 26, 2012 at 11:27:13AM -0300, Alexandre Pereira da Silva wrote:
> Grab the devicetree node properties to override VendorId, ProductId,
> bcdDevice, Manucacturer, Product and SerialNumber
>
> Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
I need Grant's acked-by to queue this one.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui @ 2012-07-02 10:10 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Li Yang-R58472, Zhao Chenhui-B35336,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXWiGOCtP1iJYR2S48XwR2Wpry8+VswctctdVfY9Z+QTiQ@mail.gmail.com>
On Fri, Jun 29, 2012 at 10:39:24AM -0500, Tabi Timur-B04825 wrote:
> On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
> <chenhui.zhao@freescale.com> wrote:
> > Do hardware timebase sync. Firstly, stop all timebases, and transfer
> > the timebase value of the boot core to the other core. Finally,
> > start all timebases.
> >
> > Only apply to dual-core chips, such as MPC8572, P2020, etc.
> >
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > Changes for v6:
> > =A0* added 85xx_TB_SYNC
> > =A0* added isync() after set_tb()
> > =A0* removed extra entries from mpc85xx_smp_guts_ids
> >
> > =A0arch/powerpc/include/asm/fsl_guts.h | =A0 =A02 +
> > =A0arch/powerpc/platforms/85xx/Kconfig | =A0 =A05 ++
> > =A0arch/powerpc/platforms/85xx/smp.c =A0 | =A0 84 +++++++++++++++++++=
++++++++++++++++
> > =A03 files changed, 91 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platfor=
ms/85xx/smp.c
> > index ff42490..edb0cad 100644
> > --- a/arch/powerpc/platforms/85xx/smp.c
> > +++ b/arch/powerpc/platforms/85xx/smp.c
> > @@ -24,6 +24,7 @@
> > =A0#include <asm/mpic.h>
> > =A0#include <asm/cacheflush.h>
> > =A0#include <asm/dbell.h>
> > +#include <asm/fsl_guts.h>
> >
> > =A0#include <sysdev/fsl_soc.h>
> > =A0#include <sysdev/mpic.h>
> > @@ -42,6 +43,69 @@ extern void __early_start(void);
> > =A0#define NUM_BOOT_ENTRY =A0 =A0 =A0 =A0 8
> > =A0#define SIZE_BOOT_ENTRY =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(NUM_BOOT_E=
NTRY * sizeof(u32))
> >
> > +#ifdef CONFIG_85xx_TB_SYNC
> > +static struct ccsr_guts __iomem *guts;
> > +static u64 timebase;
> > +static int tb_req;
> > +static int tb_valid;
> > +
> > +static void mpc85xx_timebase_freeze(int freeze)
> > +{
> > + =A0 =A0 =A0 unsigned int mask;
>=20
> 'mask' should be uint32_t
OK.
>=20
> > +
> > + =A0 =A0 =A0 if (!guts)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
>=20
> This function should never be called if guts is NULL, so this check
> should be unnecessary.
OK.
>=20
> > +
> > + =A0 =A0 =A0 mask =3D CCSR_GUTS_DEVDISR_TB0 | CCSR_GUTS_DEVDISR_TB1;
> > + =A0 =A0 =A0 if (freeze)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 setbits32(&guts->devdisr, mask);
> > + =A0 =A0 =A0 else
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrbits32(&guts->devdisr, mask);
> > +
> > + =A0 =A0 =A0 in_be32(&guts->devdisr);
> > +}
> > +
> > @@ -249,6 +323,16 @@ void __init mpc85xx_smp_init(void)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0smp_85xx_ops.cause_ipi =3D doorbell_ca=
use_ipi;
> > =A0 =A0 =A0 =A0}
> >
> > + =A0 =A0 =A0 np =3D of_find_matching_node(NULL, mpc85xx_smp_guts_ids=
);
> > + =A0 =A0 =A0 if (np) {
> > +#ifdef CONFIG_85xx_TB_SYNC
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 guts =3D of_iomap(np, 0);
>=20
> You need to test the return value of of_iomap(). smp_85xx_ops should
> be set only if guts is not NULL.
Yes. Thanks.
>=20
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 smp_85xx_ops.give_timebase =3D mpc85xx_=
give_timebase;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 smp_85xx_ops.take_timebase =3D mpc85xx_=
take_timebase;
> > +#endif
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(np);
> > + =A0 =A0 =A0 }
> > +
> > =A0 =A0 =A0 =A0smp_ops =3D &smp_85xx_ops;
> >
> > =A0#ifdef CONFIG_KEXEC
> > --
> > 1.6.4.1
^ permalink raw reply
* Re: MPC5200b jffs2 memcpy alignment problem
From: Anatolij Gustschin @ 2012-07-02 10:21 UTC (permalink / raw)
To: stephan; +Cc: Albrecht Dreß, linuxppc-dev, linux-mtd
In-Reply-To: <4FEFF265.3010102@gatzka.org>
Hi Stephan,
On Sun, 01 Jul 2012 08:47:01 +0200
Stephan Gatzka <stephan@gatzka.org> wrote:
> Hi Albrecht,
>
> > I don't recall who proposed this patch, but exactly this solution is
> > around for a longer time (mayby you search archives...). On my board, I
> > have a flash chip attached to the LocalBus in 16-bit mode. Based on
> > 3.2.16, the patch is:
>
> Thanks for your answer and yes, this patch will definitely work. But I
> want to have a solution in the mainline kernel, that's why I'm asking
> how to deal best with this problem.
This problem has been discussed several times [1], [2], but wasn't
resolved yet. The clean solution suggested was to implement a custom
mapping driver [3].
Thanks,
Anatolij
[1] http://thread.gmane.org/gmane.linux.drivers.mtd/21521
[2] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/36324
[3] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/36324/focus=36608
^ permalink raw reply
* Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui @ 2012-07-02 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1340880651.20977.83.camel@pasglop>
On Thu, Jun 28, 2012 at 08:50:51PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
> >
> >
> > The bootloader have done a timebase sync. If we do not need KEXEC or
> > HOTPLUG_CPU feature, it is unnecessary to do it again at boot time of
> > kernel. I only compile the timebase sync routines
> > when users enable KEXEC or HOTPLUG_CPU.
>
> Still, how much are you really saving ? Is it worth the added mess and
> loss of test coverage ?
>
> We have too many conditional stuff like that already.
>
> Cheers,
> Ben.
OK. I will remove this config option.
-Chenhui
^ permalink raw reply
* [PATCH] [powerpc] Export memory limit via device tree
From: Suzuki K. Poulose @ 2012-07-02 11:49 UTC (permalink / raw)
To: benh; +Cc: mahesh, linuxppc-dev, linux-kernel
The powerpc kernel doesn't export the memory limit enforced by 'mem='
kernel parameter. This is required for building the ELF header in
kexec-tools to limit the vmcore to capture only the used memory. On
powerpc the kexec-tools depends on the device-tree for memory related
information, unlike /proc/iomem on the x86.
Without this information, the kexec-tools assumes the entire System
RAM and vmcore creates an unnecessarily larger dump.
This patch exports the memory limit, if present, via chosen/linux,memory-limit
property, so that the vmcore can be limited to the memory limit.
The prom_init seems to export this value in the same node. But doesn't really
appear there. Also the memory_limit gets adjusted with the processing of
crashkernel= parameter. This patch makes sure we get the actual limit.
The kexec-tools will use the value to limit the 'end' of the memory
regions.
Tested this patch on ppc64 and ppc32(ppc440) with a kexec-tools
patch by Mahesh.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Tested-by: Mahesh J. Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/machine_kexec.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index c957b12..0c9695d 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -207,6 +207,12 @@ static struct property crashk_size_prop = {
.value = &crashk_size,
};
+static struct property memory_limit_prop = {
+ .name = "linux,memory-limit",
+ .length = sizeof(phys_addr_t),
+ .value = &memory_limit,
+};
+
static void __init export_crashk_values(struct device_node *node)
{
struct property *prop;
@@ -226,6 +232,15 @@ static void __init export_crashk_values(struct device_node *node)
crashk_size = resource_size(&crashk_res);
prom_add_property(node, &crashk_size_prop);
}
+
+ /* memory-limit is needed for constructing the crash regions */
+ prop = of_find_property(node, memory_limit_prop.name, NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ if (memory_limit)
+ prom_add_property(node, &memory_limit_prop);
+
}
static int __init kexec_setup(void)
^ permalink raw reply related
* Re: 3.5.0-rc5: BUG: soft lockup - CPU#0 stuck for 22s
From: Christian Kujau @ 2012-07-02 11:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: stern, dan.j.williams, linuxppc-dev, LKML, JBottomley
In-Reply-To: <1341204649.2588.29.camel@pasglop>
On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
> > while trying to upgrade from 3.4.0 to 3.5.0-rc5 on this Powerbook G4
> > (powerpc 32 bit), this happens during booting:
> >
> > --------------
> > usb 2-1: new full-speed USB device number 4 using ohci_hcd
> > SCSI subsystem initialized
> > scsi0 : SBP-2 IEEE-1394
> > scsi1 : SBP-2 IEEE-1394
> > firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
> > scsi 0:0:0:0: Direct-Access Ext Hard Disk PQ: 0 ANSI: 4
>
> Interesting... I observed something roughly similar on a dual G4
> the other day associated with a 30s to 1mn pause during boot. RCU
> was complaining loudly.
>
> In my case, it did continue booting normally, is that the case for you ?
>
> Also if I compile the kernel without CONFIG_SMP, it did go away as well,
> do you observe that too ?
>
> I don't have a spare cycle to investigate this problem this week I'm
> afraid, it might help if you could try a bisection though.
OK, after a git-bisect, the following commit has been identified as bad:
---------------------------
a7a20d103994fd760766e6c9d494daa569cbfe06 is the first bad commit
commit a7a20d103994fd760766e6c9d494daa569cbfe06
Author: Dan Williams <dan.j.williams@intel.com>
Date: Thu Mar 22 17:05:11 2012 -0700
[SCSI] sd: limit the scope of the async probe domain
---------------------------
Unfortunately it's not possible to "git revert" just this single commit:
------------
$ git revert a7a20d103994fd760766e6c9d494daa569cbfe06
error: could not revert a7a20d1... [SCSI] sd: limit the scope of the async probe domain
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
------------
I _guess_ this is probably due to:
------------
commit ea80dadec7a06889562b478cf0b87afbe62b7ac8
Author: James Bottomley <JBottomley@Parallels.com>
Date: Wed Jun 6 14:54:13 2012 +0900
[SCSI] Fix sd_probe_domain config problem
------------
The whole git-bisect log, dmesg, .config and so on is here:
http://nerdbynature.de/bits/3.5.0-rc5/soft_lockup/
Anyone got an idea how to go from here?
Thanks,
Christian.
--
BOFH excuse #380:
Operators killed when huge stack of backup tapes fell over.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/p1022ds/DTS: Add RTC support
From: Kumar Gala @ 2012-07-02 13:32 UTC (permalink / raw)
To: <Chang-Ming.Huang@freescale.com>; +Cc: linuxppc-dev
In-Reply-To: <1334626955-8069-2-git-send-email-Chang-Ming.Huang@freescale.com>
On Apr 16, 2012, at 8:42 PM, <Chang-Ming.Huang@freescale.com> =
<Chang-Ming.Huang@freescale.com> wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>=20
> Add the RTC support for p1022ds
>=20
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
> arch/powerpc/boot/dts/p1022ds.dtsi | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
applied
- k=
^ permalink raw reply
* Re: MPC5200b jffs2 memcpy alignment problem
From: Stephan Gatzka @ 2012-07-02 16:41 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linux-mtd, linuxppc-dev
In-Reply-To: <20120702122134.50340f5f@wker>
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
Hi!
> This problem has been discussed several times [1], [2], but wasn't
> resolved yet. The clean solution suggested was to implement a custom
> mapping driver [3].
Then I'll do that. It doesn't look terribly complicated.
It would be helpful if someone can test the first version if it's available.
Regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4931 bytes --]
^ permalink raw reply
* Re: 3.5.0-rc5: BUG: soft lockup - CPU#0 stuck for 22s
From: Paul E. McKenney @ 2012-07-02 16:45 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.2.01.1207012326110.5568@trent.utfs.org>
On Sun, Jul 01, 2012 at 11:30:40PM -0700, Christian Kujau wrote:
> On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
> > Interesting... I observed something roughly similar on a dual G4
> > the other day associated with a 30s to 1mn pause during boot. RCU
> > was complaining loudly.
> >
> > In my case, it did continue booting normally, is that the case for you ?
>
> No, in my case it stopped booting, though there was no "panic" message.
>
> > Also if I compile the kernel without CONFIG_SMP, it did go away as well,
> > do you observe that too ?
>
> This PoweBook G4 is UP anyway and I'm always building w/o CONFIG_SMP.
>
> > I don't have a spare cycle to investigate this problem this week I'm
> > afraid, it might help if you could try a bisection though.
>
> Yes, I've started a bisection already and will report back.
>
> FYI, I've put a netconsole-log below from another boot (in the
> middle of a bisection), the instruction dump is slightly more complete.
Li Zhong posted a patch to fix this (async_synchronize_full() below):
https://lkml.org/lkml/2012/7/2/32
This gets rid of this problem on my UP testing. If it works for you,
please give Li Zhong a Tested-by.
Thanx, Paul
> Thanks!
> Christian.
>
> [ 40.345973] BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:691]
> [ 40.347737] Modules linked in: sd_mod arc4 firewire_sbp2 scsi_mod b43 mac80211 cfg80211
> [ 40.349443] irq event stamp: 65779272
> [ 40.351156] hardirqs last enabled at (65779271): [<c052fae8>] _raw_spin_unlock_irqrestore+0x40/0x9c
> [ 40.352911] hardirqs last disabled at (65779272): [<c0011648>] reenable_mmu+0x40/0x98
> [ 40.354649] softirqs last enabled at (65769864): [<c000f3c0>] call_do_softirq+0x14/0x24
> [ 40.356386] softirqs last disabled at (65769857): [<c000f3c0>] call_do_softirq+0x14/0x24
> [ 40.358098] NIP: c005ee64 LR: c005ee54 CTR: c009c578
> [ 40.359788] REGS: eece3d70 TRAP: 0901 Not tainted (3.4.0-05609-gc80ddb5)
> [ 40.361517] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 24042482 XER: 00000000
> [ 40.363261] TASK = eec30b80[691] 'modprobe' THREAD: eece2000#012
> [ 40.363261] GPR00: c005ee54 eece3e20 eec30b80 00000000 00000002 c005edd0 00000000 00000000 #012
> [ 40.363261] GPR08: 00000000 eece2000 00000000 00000001 24042488
> [ 40.368310] NIP [c005ee64] async_synchronize_cookie_domain+0x70/0x1f4
> [ 40.369978] LR [c005ee54] async_synchronize_cookie_domain+0x60/0x1f4
> [ 40.371614] Call Trace:
> [ 40.373226] [eece3e20] [c005ee54] async_synchronize_cookie_domain+0x60/0x1f4 (unreliable)
> [ 40.374884] [eece3e70] [c005f034] async_synchronize_full+0x3c/0x74
> [ 40.376524] [eece3e90] [c0082790] sys_init_module+0x178/0x1164
> [ 40.378151] [eece3f40] [c00117a8] ret_from_syscall+0x0/0x38
> [ 40.379783] --- Exception: c01 at 0xff5d694#012[ 40.379783] LR = 0x100041c0
> [ 40.382928] Instruction dump:
> [ 40.384489] 93a10044 419e0014 3d20c06f 8009d020 2f800000 419e017c 7fc3f378 4bfffed9
> [ 40.386081] 7f9f1840 419d0060 7f9f1800 419e0050 <881bf008> 2f800000 419e0014 3d20c06f
>
>
> --
> BOFH excuse #241:
>
> _Rosin_ core solder? But...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ 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