* Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
From: Benjamin Herrenschmidt @ 2010-08-05 2:04 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, kexec, linux-kernel, paulus, vgoyal
In-Reply-To: <20100804144929.GA13970@hmsreliant.think-freely.org>
On Wed, 2010-08-04 at 10:49 -0400, Neil Horman wrote:
> Ping yet again. Ben, This needs review/acceptance from you or Paul
> Neil
Isn't it already in powerpc-next about to be pulled by Linus ?
In general, I recommend you check the status of your patches on
patchwork. I'm nagging Jeremy to add a feature so it emails the
submitter when the patch status changes :-)
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-05 2:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <AANLkTinJKO3-iXOXuL7CMWCj5qMMHyMrtnadwPpqTeBu@mail.gmail.com>
=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Thursday, August 05, 2010 9:03 AM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
> akpm@linux-foundation.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang=20
> <tie-fei.zang@freescale.com> wrote:
> > From: Jerry Huang <Chang-Ming.Huang@freescale.com>
> >
> > Add auto CMD12 command support for eSDHC driver.
> > This is needed by P4080 and P1022 for block read/write.
> > Manual asynchronous CMD12 abort operation causes protocol=20
> violations on
> > these silicons.
> >
> > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > ---
> > =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A04 ++++
> > =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 14 ++++++++++++--
> > =A0drivers/mmc/host/sdhci.h =A0 =A0 =A0 =A0 | =A0 =A02 ++
> > =A03 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index c6d1bd8..a92566e 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -817,8 +817,12 @@ static void=20
> sdhci_set_transfer_mode(struct sdhci_host *host,
> > =A0 =A0 =A0 =A0WARN_ON(!host->data);
> >
> > =A0 =A0 =A0 =A0mode =3D SDHCI_TRNS_BLK_CNT_EN;
> > - =A0 =A0 =A0 if (data->blocks > 1)
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MULTI;
> > + =A0 =A0 =A0 if (data->blocks > 1) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks &=20
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI |=20
> SDHCI_TRNS_ACMD12;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI;
>=20
> nit:
> + mode |=3D SDHCI_TRNS_MULTI;
> + if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> + mode |=3D SDHCI_TRNS_ACMD12;
>=20
> Clearer, no?
why?
Roy
^ permalink raw reply
* Re: [Patch v2] kexec: increase max of kexec segments and use dynamic allocation
From: Cong Wang @ 2010-08-05 2:32 UTC (permalink / raw)
To: Milton Miller
Cc: Neil Horman, Neil Horman, huang ying, linux-kernel, kexec,
Eric W. Biederman, linuxppc-dev
In-Reply-To: <4C5122D1.8080203@redhat.com>
(Ping Milton...)
On 07/29/10 14:42, Cong Wang wrote:
> On 07/27/10 18:00, Milton Miller wrote:
>> [ Added kexec at lists.infradead.org and linuxppc-dev@lists.ozlabs.org ]
>>
>>>
>>> Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine
>>> with
>>> many memory ranges. When hibernate on a machine with disjoint memory
>>> we do
>>> need one segment for each memory region. Increase this hard limit to 16K
>>> which is reasonably large.
>>>
>>> And change ->segment from a static array to a dynamically allocated
>>> memory.
>>>
>>> Cc: Neil Horman<nhorman@redhat.com>
>>> Cc: huang ying<huang.ying.caritas@gmail.com>
>>> Cc: Eric W. Biederman<ebiederm@xmission.com>
>>> Signed-off-by: WANG Cong<amwang@redhat.com>
>>>
>>> ---
>>> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
>>> b/arch/powerpc/kernel/machine_kexec_64.c
>>> index ed31a29..f115585 100644
>>> --- a/arch/powerpc/kernel/machine_kexec_64.c
>>> +++ b/arch/powerpc/kernel/machine_kexec_64.c
>>> @@ -131,10 +131,7 @@ static void copy_segments(unsigned long ind)
>>> void kexec_copy_flush(struct kimage *image)
>>> {
>>> long i, nr_segments = image->nr_segments;
>>> - struct kexec_segment ranges[KEXEC_SEGMENT_MAX];
>>> -
>>> - /* save the ranges on the stack to efficiently flush the icache */
>>> - memcpy(ranges, image->segment, sizeof(ranges));
>>> + struct kexec_segment range;
>>
>> I'm glad you found our copy on the stack and removed the stack overflow
>> that comes with this bump, but ...
>>
>>>
>>> /*
>>> * After this call we may not use anything allocated in dynamic
>>> @@ -148,9 +145,11 @@ void kexec_copy_flush(struct kimage *image)
>>> * we need to clear the icache for all dest pages sometime,
>>> * including ones that were in place on the original copy
>>> */
>>> - for (i = 0; i< nr_segments; i++)
>>> - flush_icache_range((unsigned long)__va(ranges[i].mem),
>>> - (unsigned long)__va(ranges[i].mem + ranges[i].memsz));
>>> + for (i = 0; i< nr_segments; i++) {
>>> + memcpy(&range,&image->segment[i], sizeof(range));
>>> + flush_icache_range((unsigned long)__va(range.mem),
>>> + (unsigned long)__va(range.mem + range.memsz));
>>> + }
>>> }
>>
>> This is executed after the copy, so as it says,
>> "we may not use anything allocated in dynamic memory".
>>
>> We could allocate control pages to copy the segment list into.
>> Actually ppc64 doesn't use the existing control page, but that
>> is only 4kB today.
>>
>> We need the list to icache flush all the pages in all the segments.
>> The as the indirect list doesn't have pages that were allocated at
>> their destination.
>>
>> Or maybe the icache flush should be done in the generic code
>> like it does for crash load segments?
>>
>
> I don't get the point here, according to the comments,
> it is copied into stack because of efficiency.
>
--
The opposite of love is not hate, it's indifference.
- Elie Wiesel
^ permalink raw reply
* kernel panic on MPC8323 custom board
From: Youngjin Na @ 2010-08-05 2:57 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, akpm
[-- Attachment #1: Type: text/plain, Size: 5519 bytes --]
Hi.. all
I'm porting the linux 2.6.27 kernel to the custom board with Freescale8270.
The base is the pq2fads board. The board is noproblem with linux-2.6.17.1
and linux-2.6.25.
When booting this machine, a crash takes place such as :
---------------------------------------------------------------------
Using FCC1 ETHERNET device
TFTP from server 192.168.0.12; our IP address is 192.168.0.161
Filename 'cuImage.pq2fads'.
Load address: 0x100000
Loading: #########################################################
done
Bytes transferred = 822097 (c8b51 hex)
[codec]$ bootm 100000
## Booting kernel from Legacy Image at 00100000 ...
Image Name: Linux-2.6.27
Created: 2010-08-05 1:35:22 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 822033 Bytes = 802.8 kB
Load Address: 00400000
Entry Point: 00400ba0
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using board info...
Memory <- <0x0 0x10000000> (256MB)
CPU clock-frequency <- 0x1ad27480 (450MHz)
CPU timebase-frequency <- 0x17d7840 (25MHz)
CPU bus-frequency <- 0x5f5e100 (100MHz)
zImage starting: loaded at 0x00400000 (sp: 0x0ff65ac8)
Allocating 0x1e4924 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x005da9f0)...done 0x1b3224 bytes
Linux/PowerPC load: root=/dev/nfs rw
nfsroot=192.168.0.12:/project/target/target_nadatel
ip=192.168.0.161:192.168.0.12:192.168.0.1::h264codec:eth0:off
Finalizing device tree... flat tree at 0x40c038
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
[ 0.000000] Using Freescale PQ2FADS machine description
[ 0.000000] Linux version 2.6.27 (vyna@aLinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #55 Thu Aug 5 10:35:18 KST
2010
[ 0.000000] console [udbg0] enabled
setup_arch: bootmem
pq2fads_setup_arch()
pq2fads_setup_arch(), finish
arch: exit
[ 0.000000] Top of RAM: 0x10000000, Total RAM: 0x10000000
[ 0.000000] Memory hole size: 0MB
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000000 -> 0x00010000
[ 0.000000] Normal 0x00010000 -> 0x00010000
[ 0.000000] HighMem 0x00010000 -> 0x00010000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0x00000000 -> 0x00010000
[ 0.000000] On node 0 totalpages: 65536
[ 0.000000] free_area_init_node: node 0, pgdat c01adb3c, node_mem_map
c01e7000
[ 0.000000] DMA zone: 65024 pages, LIFO batch:15
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 65024
[ 0.000000] Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.12:/project/target/target_nadatel
ip=192.168.0.161:192.168.0.12:192.168.0.1::h264codec:eth0:off
[ 0.000000] PID hash table entries: 1024 (order: 10, 4096 bytes)
[ 0.000000] time_init: decrementer frequency = 25.000000 MHz
[ 0.000000] time_init: processor frequency = 450.000000 MHz
[ 0.000000] clocksource: timebase mult[a000000] shift[22] registered
[ 0.038127] Dentry cache hash table entries: 32768 (order: 5, 131072
bytes)
[ 0.060153] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.134314] High memory: 0k
[ 0.141880] Memory: 257792k/262144k available (1648k kernel code, 4204k
reserved, 76k data, 194k bss, 124k init)
[ 0.172857] Calibrating delay loop... 49.79 BogoMIPS (lpj=24896)
[ 0.207709] Mount-cache hash table entries: 512
[ 0.234059] Unable to handle kernel paging request for data at address
0x00000032
[ 0.255641] Faulting instruction address: 0xc0183c50
[ 0.270489] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.286545] Freescale PQ2FADS
[ 0.295392] Modules linked in:
[ 0.304504] NIP: c0183c50 LR: c0183ef4 CTR: 00000000
[ 0.319345] REGS: cf821db0 TRAP: 0300 Not tainted (2.6.27)
[ 0.336514] MSR: 00009032 <EE,ME,IR,DR> CR: 82004024 XER: 00000000
[ 0.355515] DAR: 00000032, DSISR: 20000000
[ 0.367750] TASK = cf81f8a0[1] 'swapper' THREAD: cf820000
[ 0.383362] GPR00: c0183ef4 cf821e60 cf81f8a0 00000000 c015e5e0 cf821ec0
00000024 0000013f
[ 0.408348] GPR08: 3860ffda c01a0000 00000002 8124000c 24004024 ffffffff
0fffe000 11fc6000
[ 0.433334] GPR16: fffffffb fcfdffff fffffeff ffffffff 00000000 0fff8c94
00000002 0ff65e80
[ 0.458319] GPR24: 00000000 00000000 00000000 c01b0000 cf821ec0 c01b0000
c01b0000 cf821eb8
[ 0.483863] NIP [c0183c50] find_section32+0x14/0xb8
[ 0.498409] LR [c0183ef4] vdso_do_find_sections+0x28/0xc8
[ 0.514537] Call Trace:
[ 0.521839] [cf821e60] [c00f5ce8] kobject_uevent_env+0x2f4/0x318
(unreliable)
[ 0.543176] [cf821e90] [c0183ef4] vdso_do_find_sections+0x28/0xc8
[ 0.561394] [cf821eb0] [c01841b4] vdso_setup+0x2c/0xb8
[ 0.576749] [cf821f10] [c0184308] vdso_init+0x64/0x1dc
[ 0.592113] [cf821f30] [c0003904] do_one_initcall+0x54/0x184
[ 0.609022] [cf821fb0] [c017d848] do_initcalls+0x34/0x58
[ 0.624897] [cf821fd0] [c017d92c] kernel_init+0x40/0x94
[ 0.640528] [cf821ff0] [c000f9f8] kernel_thread+0x44/0x60
[ 0.656643] Instruction dump:
[ 0.665493] 41a2000c 7c0803a6 4e800021 80010014 38210010 7c0803a6
4e800020 9421ffd0
[ 0.688656] 7c0802a6 bf010010 90010034 7cbc2b78 <a1230032> 3b400001
7c7f1b78 81630020
[ 0.712438] ---[ end trace 31fd0ba7d8756001 ]---
[ 0.726196] Kernel panic - not syncing: Attempted to kill init!
[ 0.743876] Rebooting in 180 seconds..
-------------------------------
I don't know what is could someone help me?
Thanks
Best Regards
Victor
[-- Attachment #2: Type: text/html, Size: 6920 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Michael Neuling @ 2010-08-05 3:34 UTC (permalink / raw)
To: Bounine, Alexandre
Cc: linux-kernel, Alexandre Bounine, thomas.moll, linuxppc-dev,
Timur Tabi
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552011430BC@CORPEXCH1.na.ads.idt.com>
In message <0CE8B6BE3C4AD74AB97D9D29BD24E552011430BC@CORPEXCH1.na.ads.idt.com> you wrote:
> Yang Li pointed to these patches in his post from July 23, 2010.
> It would be nice to have these patches in mainline code.=20
This is still broken in Kumar's latest tree. Do you guys wanna repost
them so Kumar can pick them up easily?
Mikey
>
> > -----Original Message-----
> > From: timur.tabi@gmail.com [mailto:timur.tabi@gmail.com] On Behalf Of
> Timur Tabi
> > Sent: Tuesday, August 03, 2010 9:02 AM
> > To: Bounine, Alexandre
> > Cc: Michael Neuling; Alexandre Bounine; linuxppc-dev@lists.ozlabs.org;
> linux-kernel@vger.kernel.org;
> > thomas.moll@sysgo.com; Kumar Gala
> > Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO
> port
> >=20
> > On Tue, Aug 3, 2010 at 7:17 AM, Bounine, Alexandre
> > <Alexandre.Bounine@idt.com> wrote:
> > > This happened after change to book-e definitions.
> > > There are patches that address this issue.
> >=20
> > And those patches should have been applied before 2.6.35 was released.
> > Someone dropped the ball. 2.6.35 is broken for a number of PowerPC
> > boards:
> >=20
> > $ make mpc85xx_defconfig
> > ....
> > $ make
> > ....
> > CC arch/powerpc/sysdev/fsl_rio.o
> > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
> > arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
> > (first use in this function)
> > arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared identifier
> > is reported only once
> > arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it appears
> in.)
> > make[1]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1
> >=20
> > --
> > Timur Tabi
> > Linux kernel developer at Freescale
>
^ permalink raw reply
* Relocating bootwrapper causes kernel panic
From: Shawn Jin @ 2010-08-05 4:11 UTC (permalink / raw)
To: ppcdev
Hi,
I'm trying to relocate the bootwrapper from the default address
(0x400000) to a higher address (e.g. 0x800000) in order to support a
larger than 4MB initramfs. However the kernel panic when trying to
access the device tree blob which was relocated accordingly to a
higher address. The kernel message from __log_buf is shown below.
The flat tree located at 0xbe4300 as the kerne message showed. Why
cannot the kernel access this area? No TLB set for this area?
<1>Unable to handle kernel paging request for data at address 0xc0be4308
<1>Faulting instruction address: 0xc01fdabc
<4>Oops: Kernel access of bad area, sig: 11 [#1]
<4>
<4>NIP: c01fdabc LR: c01fdc38 CTR: 00000000
<4>REGS: c0383ee0 TRAP: 0300 Not tainted (2.6.33.5)
<4>MSR: 00001032 <ME,IR,DR> CR: 28558922 XER: 00000504
<4>DAR: c0be4308, DSISR: c0000000
<4>TASK = c0375328[0] 'swapper' THREAD: c0382000
<4>GPR00: c01fdc38 c0383f90 c0375328 c01fd4c8 00000000 00000000
00be4300 00000010
<4>GPR08: c01dbd94 c0be4300 04000000 00000000 00000000 00000000
07fff000 00000001
<4>GPR16: 007fff0d 00800554 00000001 007fff00 07ff9d78 ffffffff
00000000 07d5d2a0
<4>GPR24: 00000891 00000000 c0390000 c01fd4c8 00000000 00be4300
00000000 00be4300
<4>NIP [c01fdabc] of_scan_flat_dt+0x20/0x174
<4>LR [c01fdc38] early_init_devtree+0x28/0x288
<4>Call Trace:
<4>[c0383fb0] [c01fdc38] early_init_devtree+0x28/0x288
<4>[c0383fd0] [c01fe9c0] machine_init+0x20/0x5c
<4>[c0383ff0] [c0002244] start_here+0x48/0xc4
<4>Instruction dump:
<4>7fe5fb78 4bfff899 90610008 4bfffeb4 9421ffe0 7c0802a6 bf410008 90010024
<4>7c7b1b78 7c9c2378 3f40c039 813a9070 <80090008> 7fe90214 38600000 3ba0ffff
<4>---[ end trace 31fd0ba7d8756001 ]---
<0>Kernel panic - not syncing: Attempted to kill the idle task!
<4>Call Trace:
<4>[c0383dd0] [c0006c90] show_stack+0x40/0x168 (unreliable)
<4>[c0383e10] [c001cbfc] panic+0x8c/0x178
<4>[c0383e60] [c00209b0] do_exit+0x5c4/0x5d0
<4>[c0383ea0] [c000bb08] kernel_bad_stack+0x0/0x4c
<4>[c0383ec0] [c000ede8] bad_page_fault+0x90/0xd8
<4>[c0383ea0] [c000bb08] kernel_bad_stack+0x0/0x4c
<4>[c0383ec0] [c000ede8] bad_page_fault+0x90/0xd8
<4>[c0383ed0] [c000e2b8] handle_page_fault+0x7c/0x80
<4>[c0383f90] [00000000] (null)
<4>[c0383fb0] [c01fdc38] early_init_devtree+0x28/0x288
<4>[c0383fd0] [c01fe9c0] machine_init+0x20/0x5c
<4>[c0383ff0] [c0002244] start_here+0x48/0xc4
The kernel message from uboot and the bootwrapper is shown below.
=> bootm 5000000
## Booting image at 05000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1757351 Bytes = 1.7 MB
Load Address: 00800000
Entry Point: 00800554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00800000 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080c000:0x00bd702c)...done 0x3886ec bytes
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
Thanks,
-Shawn.
^ permalink raw reply
* [PATCH 0/4] powerpc: cpu offline/online fixes for CONFIG_PREEMPT
From: Darren Hart @ 2010-08-05 4:28 UTC (permalink / raw)
To: linux-kernel; +Cc: dvhltc, brking, linuxppc-dev, will_schmidt, tglx
The following patch series addresses several issues detected during intense CPU
offline/online testing on the mainline kernel with CONFIG_PREEMPT=y. These
patches require the following patch from Brian King:
http://patchwork.ozlabs.org/patch/59645/
Tested against linux-2.6.git master with and without CONFIG_DEBUG_PREEMPT.
^ permalink raw reply
* [PATCH 1/3] powerpc-enable-preemption-before-cpu_die
From: Darren Hart @ 2010-08-05 4:28 UTC (permalink / raw)
To: linux-kernel; +Cc: dvhltc, brking, linuxppc-dev, will_schmidt, tglx
In-Reply-To: <1280982515-18231-1-git-send-email-dvhltc@us.ibm.com>
From: Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
start_secondary() is called shortly after _start and also via
cpu_idle()->cpu_die()->pseries_mach_cpu_die()
start_secondary() expects a preempt_count() of 0. pseries_mach_cpu_die() is
called via the cpu_idle() routine with preemption disabled, resulting in the
following repeating message during rapid cpu offline/online tests
with CONFIG_PREEMPT=y:
BUG: scheduling while atomic: swapper/0/0x00000002
Modules linked in: autofs4 binfmt_misc dm_mirror dm_region_hash dm_log [last unloaded: scsi_wait_scan]
Call Trace:
[c00000010e7079c0] [c0000000000133ec] .show_stack+0xd8/0x218 (unreliable)
[c00000010e707aa0] [c0000000006a47f0] .dump_stack+0x28/0x3c
[c00000010e707b20] [c00000000006e7a4] .__schedule_bug+0x7c/0x9c
[c00000010e707bb0] [c000000000699d9c] .schedule+0x104/0x800
[c00000010e707cd0] [c000000000015b24] .cpu_idle+0x1c4/0x1d8
[c00000010e707d70] [c0000000006aa1b4] .start_secondary+0x398/0x3d4
[c00000010e707e30] [c000000000008278] .start_secondary_resume+0x10/0x14
Move the cpu_die() call inside the existing preemption enabled block of
cpu_idle(). This is safe as the idle task is affined to a single CPU so the
debug_smp_processor_id() tests (from cpu_should_die()) won't trigger as we are
in a "migration disabled" region.
Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
Acked-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Nathan Fontenot <nfont@austin.ibm.com>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Cc: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/kernel/idle.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 049dda6..39a2baa 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -94,9 +94,9 @@ void cpu_idle(void)
HMT_medium();
ppc64_runlatch_on();
tick_nohz_restart_sched_tick();
+ preempt_enable_no_resched();
if (cpu_should_die())
cpu_die();
- preempt_enable_no_resched();
schedule();
preempt_disable();
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] powerpc-silence-__cpu_up-under-normal-operation
From: Darren Hart @ 2010-08-05 4:28 UTC (permalink / raw)
To: linux-kernel; +Cc: dvhltc, brking, linuxppc-dev, will_schmidt, tglx
In-Reply-To: <1280982515-18231-1-git-send-email-dvhltc@us.ibm.com>
From: Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
During CPU offline/online tests __cpu_up would flood the logs with
the following message:
Processor 0 found.
This provides no useful information to the user as there is no context
provided, and since the operation was a success (to this point) it is expected
that the CPU will come back online, providing all the feedback necessary.
Change the "Processor found" message to DBG() similar to other such messages in
the same function. Also, add an appropriate log level for the "Processor is
stuck" message.
Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
Acked-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Nathan Fontenot <nfont@austin.ibm.com>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Cc: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 5c196d1..cc05792 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -429,11 +429,11 @@ int __cpuinit __cpu_up(unsigned int cpu)
#endif
if (!cpu_callin_map[cpu]) {
- printk("Processor %u is stuck.\n", cpu);
+ printk(KERN_ERR "Processor %u is stuck.\n", cpu);
return -ENOENT;
}
- printk("Processor %u found.\n", cpu);
+ DBG("Processor %u found.\n", cpu);
if (smp_ops->give_timebase)
smp_ops->give_timebase();
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] powerpc-silence-xics_migrate_irqs_away-during-cpu-offline
From: Darren Hart @ 2010-08-05 4:28 UTC (permalink / raw)
To: linux-kernel; +Cc: dvhltc, brking, linuxppc-dev, will_schmidt, tglx
In-Reply-To: <1280982515-18231-1-git-send-email-dvhltc@us.ibm.com>
From: Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
All IRQs are migrated away from a CPU that is being offlined so the
following messages suggest a problem when the system is behaving as
designed:
IRQ 262 affinity broken off cpu 1
IRQ 17 affinity broken off cpu 0
IRQ 18 affinity broken off cpu 0
IRQ 19 affinity broken off cpu 0
IRQ 256 affinity broken off cpu 0
IRQ 261 affinity broken off cpu 0
IRQ 262 affinity broken off cpu 0
Don't print these messages when the CPU is not online.
Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
Acked-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Nathan Fontenot <nfont@austin.ibm.com>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Cc: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/xics.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index f19d194..8d0b0b1 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -930,8 +930,10 @@ void xics_migrate_irqs_away(void)
if (xics_status[0] != hw_cpu)
goto unlock;
- printk(KERN_WARNING "IRQ %u affinity broken off cpu %u\n",
- virq, cpu);
+ /* This is expected during cpu offline. */
+ if (cpu_online(cpu))
+ printk(KERN_WARNING "IRQ %u affinity broken off cpu %u\n",
+ virq, cpu);
/* Reset affinity to all cpus */
cpumask_setall(irq_to_desc(virq)->affinity);
--
1.7.0.4
^ permalink raw reply related
* Re: Request review of device tree documentation
From: David Gibson @ 2010-08-05 4:43 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
On Fri, Jun 11, 2010 at 04:59:46PM -0600, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can find it here:
>
> http://devicetree.org/Device_Tree_Usage
Sorry I haven't replied sooner, I've been away, then sick and
generally preoccupied. Still here are some comments now.
How Addressing Works:
* Small inconsistency you use "address1", "address2" then "unit-address3".
* Perhaps re-emphasise that a parent's #*-cells properties govern the
children's reg properties, not its own, since this is a common
misunderstanding..
Non Memory Mapped Devices:
* Your phrasing here suggests that non-memory-maped == zero
size-cells, which is not always true.
Ranges (Address Translation):
* Third paragraph, first sentence is a grammatical dogs' breakfast,
How Interrupts Work:
* Bogus paragraph break partway through first sentence.
* At the end you say the second cell indicates the interrupt's
polarity, but you don't specify how this is encoded. It might be
worth emphasising that while most interrupt specifiers do include
trigger and polarity type information, the encoding of it can and
does vary between interrupt controllers.
Advanced Sample Machine:
* The unit address in the name shouldn't have a "0x" prefix
Advanced Interrupt Mapping:
* Perhaps worth noting that while a PCI *card* will use INTA..INTD,
on-board PCI devices can, and frequently do, have interrupts wired
side-band to the PCI bus, directly to the main interrupt
controller.
* In your example, you're muddying the waters of your previous usage
of interrupt-parent. The PCI child nodes have the PCI top-level
node as their implicit interrupt parent, because its their first
ancestor with an interrupt-map, and we hit that before the
interrupt-parent property specified at the very top level. This
means amongst other things that if there are PCI devices with
seperately wired interrupts, they must explicitly set
interrupt-parent to bypass the normal PCI interrupt mapping.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-08-05 4:45 UTC (permalink / raw)
To: svaidy
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <20100723070701.GC26162@dirshya.in.ibm.com>
On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote:
> * Benjamin Herrenschmidt<benh@kernel.crashing.org> [2010-07-23 15:11:00]:
>
>> On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:
>>> Yes. extended_cede_processor() will return with interrupts enabled in
>>> the cpu. (This is done by the hypervisor). Under normal cases we
>>> cannot be interrupted because no IO interrupts are routed to us after
>>> xics_teardown_cpu() and since the CPU is out of the map, nobody will
>>> send us IPIs.
>>
>> What about decrementer ?
>
> Decrementer expiry event handling is bit complex. The event as such
> may not bring back the extended_cede_processor() cpu, but may be
> marked pending when we get out of this state eventually. I will find
> more information on this event and update.
Hi Vaidy, have you been able to dig anything up about the decrementer
expiry?
Thanks,
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
>
>>> Though H_CEDE will return with interrupts enabled, it is unlikely that
>>> an interrupt can be delivered in this context.
>>
>> Well, if interrupts are soft-disabled, even if one occurs, we will just
>> mask and return, so that at least should be ok.
>
> Yes. We will immediately return to the extended_cede_processor() in
> the while loop until the preferred_offline_state is changed.
>
> --Vaidy
^ permalink raw reply
* Re: [PATCH 1/9] v4 Move the find_memory_block() routine up
From: KAMEZAWA Hiroyuki @ 2010-08-05 4:45 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581B67.1010202@austin.ibm.com>
On Tue, 03 Aug 2010 08:36:39 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Move the find_memory_block() routine up to avoid needing a forward
> declaration in subsequent patches.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 2/9] v4 Add new phys_index properties
From: KAMEZAWA Hiroyuki @ 2010-08-05 4:49 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581B9B.8050106@austin.ibm.com>
On Tue, 03 Aug 2010 08:37:31 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the 'phys_index' properties of a memory block to include a
> 'start_phys_index' which is the same as the current 'phys_index' property.
> The property still appears as 'phys_index' in sysfs but the memory_block
> struct name is updated to indicate the start and end values.
> This also adds an 'end_phys_index' property to indicate the id of the
> last section in th memory block.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
nitpick. After this patch, end_phys_index is added but contains 0.
It's better to contain the same value with phys_index..
But, ok. Following patch will fix it.
Thanks,
-Kame
> ---
> drivers/base/memory.c | 28 ++++++++++++++++++++--------
> include/linux/memory.h | 3 ++-
> 2 files changed, 22 insertions(+), 9 deletions(-)
>
> Index: linux-2.6/drivers/base/memory.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/memory.c 2010-08-02 13:32:21.000000000 -0500
> +++ linux-2.6/drivers/base/memory.c 2010-08-02 13:33:27.000000000 -0500
> @@ -109,12 +109,20 @@ unregister_memory(struct memory_block *m
> * uses.
> */
>
> -static ssize_t show_mem_phys_index(struct sys_device *dev,
> +static ssize_t show_mem_start_phys_index(struct sys_device *dev,
> struct sysdev_attribute *attr, char *buf)
> {
> struct memory_block *mem =
> container_of(dev, struct memory_block, sysdev);
> - return sprintf(buf, "%08lx\n", mem->phys_index);
> + return sprintf(buf, "%08lx\n", mem->start_phys_index);
> +}
> +
> +static ssize_t show_mem_end_phys_index(struct sys_device *dev,
> + struct sysdev_attribute *attr, char *buf)
> +{
> + struct memory_block *mem =
> + container_of(dev, struct memory_block, sysdev);
> + return sprintf(buf, "%08lx\n", mem->end_phys_index);
> }
>
> /*
> @@ -128,7 +136,7 @@ static ssize_t show_mem_removable(struct
> struct memory_block *mem =
> container_of(dev, struct memory_block, sysdev);
>
> - start_pfn = section_nr_to_pfn(mem->phys_index);
> + start_pfn = section_nr_to_pfn(mem->start_phys_index);
> ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
> return sprintf(buf, "%d\n", ret);
> }
> @@ -191,7 +199,7 @@ memory_block_action(struct memory_block
> int ret;
> int old_state = mem->state;
>
> - psection = mem->phys_index;
> + psection = mem->start_phys_index;
> first_page = pfn_to_page(psection << PFN_SECTION_SHIFT);
>
> /*
> @@ -264,7 +272,7 @@ store_mem_state(struct sys_device *dev,
> int ret = -EINVAL;
>
> mem = container_of(dev, struct memory_block, sysdev);
> - phys_section_nr = mem->phys_index;
> + phys_section_nr = mem->start_phys_index;
>
> if (!present_section_nr(phys_section_nr))
> goto out;
> @@ -296,7 +304,8 @@ static ssize_t show_phys_device(struct s
> return sprintf(buf, "%d\n", mem->phys_device);
> }
>
> -static SYSDEV_ATTR(phys_index, 0444, show_mem_phys_index, NULL);
> +static SYSDEV_ATTR(phys_index, 0444, show_mem_start_phys_index, NULL);
> +static SYSDEV_ATTR(end_phys_index, 0444, show_mem_end_phys_index, NULL);
> static SYSDEV_ATTR(state, 0644, show_mem_state, store_mem_state);
> static SYSDEV_ATTR(phys_device, 0444, show_phys_device, NULL);
> static SYSDEV_ATTR(removable, 0444, show_mem_removable, NULL);
> @@ -476,16 +485,18 @@ static int add_memory_block(int nid, str
> if (!mem)
> return -ENOMEM;
>
> - mem->phys_index = __section_nr(section);
> + mem->start_phys_index = __section_nr(section);
> mem->state = state;
> mutex_init(&mem->state_mutex);
> - start_pfn = section_nr_to_pfn(mem->phys_index);
> + start_pfn = section_nr_to_pfn(mem->start_phys_index);
> mem->phys_device = arch_get_memory_phys_device(start_pfn);
>
> ret = register_memory(mem, section);
> if (!ret)
> ret = mem_create_simple_file(mem, phys_index);
> if (!ret)
> + ret = mem_create_simple_file(mem, end_phys_index);
> + if (!ret)
> ret = mem_create_simple_file(mem, state);
> if (!ret)
> ret = mem_create_simple_file(mem, phys_device);
> @@ -507,6 +518,7 @@ int remove_memory_block(unsigned long no
> mem = find_memory_block(section);
> unregister_mem_sect_under_nodes(mem);
> mem_remove_simple_file(mem, phys_index);
> + mem_remove_simple_file(mem, end_phys_index);
> mem_remove_simple_file(mem, state);
> mem_remove_simple_file(mem, phys_device);
> mem_remove_simple_file(mem, removable);
> Index: linux-2.6/include/linux/memory.h
> ===================================================================
> --- linux-2.6.orig/include/linux/memory.h 2010-08-02 13:23:49.000000000 -0500
> +++ linux-2.6/include/linux/memory.h 2010-08-02 13:33:27.000000000 -0500
> @@ -21,7 +21,8 @@
> #include <linux/mutex.h>
>
> struct memory_block {
> - unsigned long phys_index;
> + unsigned long start_phys_index;
> + unsigned long end_phys_index;
> unsigned long state;
> /*
> * This serializes all state change requests. It isn't
>
> --
> 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: [PATCH 3/9] v4 Add section count to memory_block
From: KAMEZAWA Hiroyuki @ 2010-08-05 4:50 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581BDD.1040601@austin.ibm.com>
On Tue, 03 Aug 2010 08:38:37 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Add a section count property to the memory_block struct to track the number
> of memory sections that have been added/removed from a memory block. This
> allows us to know when the last memory section of a memory block has been
> removed so we can remove the memory block.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 4/9] v4 Add mutex for add/remove of memory blocks
From: KAMEZAWA Hiroyuki @ 2010-08-05 4:53 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581C26.5080007@austin.ibm.com>
On Tue, 03 Aug 2010 08:39:50 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Add a new mutex for use in adding and removing of memory blocks. This
> is needed to avoid any race conditions in which the same memory block could
> be added and removed at the same time.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
But a nitpick (see below)
> ---
> drivers/base/memory.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> Index: linux-2.6/drivers/base/memory.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/memory.c 2010-08-02 13:35:00.000000000 -0500
> +++ linux-2.6/drivers/base/memory.c 2010-08-02 13:45:34.000000000 -0500
> @@ -27,6 +27,8 @@
> #include <asm/atomic.h>
> #include <asm/uaccess.h>
>
> +static struct mutex mem_sysfs_mutex;
> +
For static symbol of mutex, we usually do
static DEFINE_MUTEX(mem_sysfs_mutex);
Then, extra calls of mutex_init() is not required.
^ permalink raw reply
* Help with an odd problem sharing memory on the ppc460ex
From: Ayman El-Khashab @ 2010-08-05 4:50 UTC (permalink / raw)
To: linuxppc-dev
I've got custom boards that have been running for a while on rev A
460ex parts but when the rev B parts became available some problems
surfaced. We are trying to work around the issues in software. To make
this simple, I've got 2 460exs connected together via PCI and PCIe so i
can switch the transport. For now, I am using PCI. I've setup the PIMs
and POMs to map one CPUs DRAM across the bus to the other CPU. So they
have a sort of shared memory scheme. This works fine in many cases.
I think I have a caching problem though even though I think the cache is
disabled via u-boot. What happens is that CPU0 will write into CPU1's
memory. CPU1 will still see a stale value though ... I can't figure out
how this happens. If CPU0 comes back and reads from CPU1's memory
though, it gets the correct value. Now if I reduce the frequency of
the reads/writes to something low (maybe 1 or 2 per second), then very
often CPU1 will see the change. I continue to think it is a cache
issue, but I am not sure. Also not sure how to work around that. Is
that something I need to do via the TLBs? Is the cache really disabled
or does Linux mess with the TLB/cache settings? When I boot Linux I
reserve the upper 16Mb of memory (from 112-128Mb space) and then mmap
that entire region into CPU1's space. Not sure if when it is reserved
if it is treated differently by Linux or not.
Any help is greatly appreciated.
Thanks
Ayman
^ permalink raw reply
* Re: [PATCH 5/9] v4 Allow memory_block to span multiple memory sections
From: KAMEZAWA Hiroyuki @ 2010-08-05 4:55 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581C61.1050408@austin.ibm.com>
On Tue, 03 Aug 2010 08:40:49 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the memory sysfs code that each sysfs memory directory is now
> considered a memory block that can contain multiple memory sections per
> memory block. The default size of each memory block is SECTION_SIZE_BITS
> to maintain the current behavior of having a single memory section per
> memory block (i.e. one sysfs directory per memory section).
>
> For architectures that want to have memory blocks span multiple
> memory sections they need only define their own memory_block_size_bytes()
> routine.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
(But maybe it's better to get ppc guy's Ack.)
^ permalink raw reply
* Re: [PATCH 6/9] v4 Update the find_memory_block declaration
From: KAMEZAWA Hiroyuki @ 2010-08-05 4:59 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581C99.8090201@austin.ibm.com>
On Tue, 03 Aug 2010 08:41:45 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the find_memory_block declaration to to take a struct mem_section *
> so that it matches the definition.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Hmm...my mmotm-0727 has this definition in memory.h...
extern struct memory_block *find_memory_block(struct mem_section *);
What patch makes it unsigned long ?
^ permalink raw reply
* Re: [PATCH 7/9] v4 Update the node sysfs code
From: KAMEZAWA Hiroyuki @ 2010-08-05 5:01 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581CCB.7070806@austin.ibm.com>
On Tue, 03 Aug 2010 08:42:35 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the node sysfs code to be aware of the new capability for a memory
> block to contain multiple memory sections. This requires an additional
> parameter to unregister_mem_sect_under_nodes so that we know which memory
> section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 9/9] v4 Update memory-hotplug documentation
From: KAMEZAWA Hiroyuki @ 2010-08-05 5:04 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <4C581D30.60300@austin.ibm.com>
On Tue, 03 Aug 2010 08:44:16 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the memory hotplug documentation to reflect the new behaviors of
> memory blocks reflected in sysfs.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
A request from me:
Could you clarify what happens if there are memory hole in [start end)_phys_index.
in Documentation ? (Or add TODO list.)
Thanks,
-Kame
> ---
> Documentation/memory-hotplug.txt | 40 +++++++++++++++++++++++----------------
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> Index: linux-2.6/Documentation/memory-hotplug.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/memory-hotplug.txt 2010-08-02 14:09:28.000000000 -0500
> +++ linux-2.6/Documentation/memory-hotplug.txt 2010-08-02 14:10:36.000000000 -0500
> @@ -126,36 +126,44 @@ config options.
> --------------------------------
> 4 sysfs files for memory hotplug
> --------------------------------
> -All sections have their device information under /sys/devices/system/memory as
> +All sections have their device information in sysfs. Each section is part of
> +a memory block under /sys/devices/system/memory as
>
> /sys/devices/system/memory/memoryXXX
> -(XXX is section id.)
> +(XXX is the section id.)
>
> -Now, XXX is defined as start_address_of_section / section_size.
> +Now, XXX is defined as (start_address_of_section / section_size) of the first
> +section contained in the memory block.
>
> For example, assume 1GiB section size. A device for a memory starting at
> 0x100000000 is /sys/device/system/memory/memory4
> (0x100000000 / 1Gib = 4)
> This device covers address range [0x100000000 ... 0x140000000)
>
> -Under each section, you can see 4 files.
> +Under each section, you can see 5 files.
>
> -/sys/devices/system/memory/memoryXXX/phys_index
> +/sys/devices/system/memory/memoryXXX/start_phys_index
> +/sys/devices/system/memory/memoryXXX/end_phys_index
> /sys/devices/system/memory/memoryXXX/phys_device
> /sys/devices/system/memory/memoryXXX/state
> /sys/devices/system/memory/memoryXXX/removable
>
> -'phys_index' : read-only and contains section id, same as XXX.
> -'state' : read-write
> - at read: contains online/offline state of memory.
> - at write: user can specify "online", "offline" command
> -'phys_device': read-only: designed to show the name of physical memory device.
> - This is not well implemented now.
> -'removable' : read-only: contains an integer value indicating
> - whether the memory section is removable or not
> - removable. A value of 1 indicates that the memory
> - section is removable and a value of 0 indicates that
> - it is not removable.
> +'phys_index' : read-only and contains section id of the first section
> + in the memory block, same as XXX.
> +'end_phys_index' : read-only and contains section id of the last section
> + in the memory block.
> +'state' : read-write
> + at read: contains online/offline state of memory.
> + at write: user can specify "online", "offline" command
> + which will be performed on al sections in the block.
> +'phys_device' : read-only: designed to show the name of physical memory
> + device. This is not well implemented now.
> +'removable' : read-only: contains an integer value indicating
> + whether the memory block is removable or not
> + removable. A value of 1 indicates that the memory
> + block is removable and a value of 0 indicates that
> + it is not removable. A memory block is removable only if
> + every section in the block is removable.
>
> NOTE:
> These directories/files appear after physical memory hotplug phase.
>
>
> --
> 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
* Re: Relocating bootwrapper causes kernel panic
From: Shawn Jin @ 2010-08-05 5:13 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <AANLkTi=x-EA59xfn_r5xMuJL6mufObSvSSEOeY9KTjQS@mail.gmail.com>
> I'm trying to relocate the bootwrapper from the default address
> (0x400000) to a higher address (e.g. 0x800000) in order to support a
> larger than 4MB initramfs. However the kernel panic when trying to
> access the device tree blob which was relocated accordingly to a
> higher address. The kernel message from __log_buf is shown below.
>
> The flat tree located at 0xbe4300 as the kerne message showed. Why
> cannot the kernel access this area? No TLB set for this area?
>
> <1>Unable to handle kernel paging request for data at address 0xc0be4308
> <1>Faulting instruction address: 0xc01fdabc
> <4>Oops: Kernel access of bad area, sig: 11 [#1]
Before the flat tree was accessed, I checked the DTLB and didn't find
any entry related to 0xc0be4300. After the exception, I found the
following DTLBs.
30 : 02 c0be4000 4KB ------ -> 00000000
31 : 00 fa000000 8MB VI-S-M -> fa000000
The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
should be something like 00be4000?
Thanks,
-Shawn.
^ permalink raw reply
* [linux-next] build failure
From: divya @ 2010-08-05 5:32 UTC (permalink / raw)
To: LKML, linux-next, linuxppc-dev, netdev, jeffrey.t.kirsher
Yestersday's linux-next(2.6.35_next_20100802) build fails with the following error on both system p and x.
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_select_queue':
drivers/net/ixgbe/ixgbe_main.c:6159: error: 'struct ixgbe_fcoe' has no member named 'up'
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_xmit_frame':
drivers/net/ixgbe/ixgbe_main.c:6221: error: 'struct ixgbe_fcoe' has no member named 'up'
make[3]: *** [drivers/net/ixgbe/ixgbe_main.o] Error 1
make[2]: *** [drivers/net/ixgbe] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Thanks
Divya
^ permalink raw reply
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Kumar Gala @ 2010-08-05 7:01 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <4C48B3FD.7080006@emcraft.com>
On Jul 22, 2010, at 4:11 PM, Ilya Yanok wrote:
> 23.07.2010 1:09, Ilya Yanok wrote:
>> I hope to disturb you but I haven't got any reply for my first posting...
>
> I shouldn't be working at night... It's 'hate' not 'hope'...
>
> Regards, Ilya.
I have a fix, can you test?
- k
^ permalink raw reply
* Re: Relocating bootwrapper causes kernel panic
From: Shawn Jin @ 2010-08-05 7:23 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <AANLkTin3u=U-L2grncS_UtWqkGnb9bNUy4a4nqkRhQQ9@mail.gmail.com>
>> The flat tree located at 0xbe4300 as the kerne message showed. Why
>> cannot the kernel access this area? No TLB set for this area?
>>
>> <1>Unable to handle kernel paging request for data at address 0xc0be4308
>> <1>Faulting instruction address: 0xc01fdabc
>> <4>Oops: Kernel access of bad area, sig: 11 [#1]
>
> Before the flat tree was accessed, I checked the DTLB and didn't find
> any entry related to 0xc0be4300. After the exception, I found the
> following DTLBs.
>
> 30 : 02 =A0c0be4000 =A0 4KB ------ -> 00000000
> 31 : 00 =A0fa000000 =A0 8MB VI-S-M -> fa000000
>
> The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
> should be something like 00be4000?
When the early_debug is enabled, the kernel can boot successfully. I
checked the TLB settings and found the following.
28 : 00 c0000000 8MB V--S-M -> 00000000
29 : 00 fa000000 8MB VI-S-M -> fa000000
30 : 00 c0800000 8MB V--S-M -> 00800000
31 : 14 04919000 ?KB V---WM -> 00e45000
So the kernel can access the dtb at 0xbe4300 because of the pinned down DTL=
B#30.
I think the cause is clear now. But how to fix it? Two questions:
1. Should this DTLB miss exception properly set a new TLB entry for
the new dtb address 0xbe4300?
2. If the DTLB miss exception handler is not the right guy to load a
proper TLB entry, how can I set one entry based on the link_address
and the address of the flat dt blob?
Thanks a lot,
-Shawn.
^ 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