Re: [RFC PATCH 2/5] powerpc: Exception hooks for context tracking subsystem
On Sun, 2013-02-10 at 15:10 +0100, Frederic Weisbecker wrote: 2013/2/1 Li Zhong zh...@linux.vnet.ibm.com: This is the exception hooks for context tracking subsystem, including data access, program check, single step, instruction breakpoint, machine check, alignment, fp unavailable, altivec assist, unknown exception, whose handlers might use RCU. This patch corresponds to [PATCH] x86: Exception hooks for userspace RCU extended QS commit 6ba3c97a38803883c2eee489505796cb0a727122 Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com Looks good! I guess we should move exception_enter/exit definition to the generic code. They should be the same for all archs after all. Indeed. Also we are relying on user_mode(regs) but this may be buggy with some corner cases. For example if an exception happen after a call to user_exit() I guess you mean user_enter() here, or am I confused? (on syscall exit) but before we actually resume in userspace, the exception will exit in kernel mode from the context tracking POV. So instead on relying on the regs, which are not sync with the context tracking state, we should use something like: prev_state = exception_enter(); ... exception_exit(prev_state); Also preempt_schedule_irq() is concerned as well by this problem. So I should convert it to that scheme as well. I'm going to prepare some patches. Feel free to merge this patch in the powerpc tree, I'll do the conversion along the way. Or if your patches gets merged earlier than these, I can update my code according to yours. Thanks, Zhong Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3: Strange issue with kexec and FreeBSD loader
I was able to capture the debug output from the purgatory code and it's very odd. This the SHA256 digest calculated by kexec-tools: root@ps3-linux:~# kexec -l loader.ps3 Warning: append= option is not passed. Using the first kernel root partition Modified cmdline: Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled segment[0].mem:0x131d000 memsz:262144 segment[1].mem:0x135d000 memsz:36864 segment[2].mem:0x7fff000 memsz:4096 sha256_digest: 77 d5 30 a7 67 5f 67 93 f1 e0 ce 84 bd 4e 1b ec 3c 4a 9e 86 5c a1 33 87 9e b1 5f c8 91 ce e8 61 And this is the debug output i'm always getting from the purgatory code: I'm in purgatory sha256 digests do not match :( digest: fd 4f df a8 af 5b e1 6b bc 51 5d b8 ab be 75 fb 76 fd 64 64 26 3e a8 9f 46 ec 91 de 05 4e 72 78 sha256_digest: 00 39 e3 b2 45 0d 20 68 74 c2 4e ee e4 4a cf ec c3 78 4f 1c 65 ff a8 76 73 68 5d 01 70 0b b6 50 regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3: Strange issue with kexec and FreeBSD loader
Phileas Fogg wrote: Hi, i'm using OpenWRT petitboot bootloader on my PS3 to boot FreeBSD loader which is a simple PPC32 ELF file. I haven't had any issues with it and OpenWRT based on Linux 3.3.8. Recently i built an OpenWRT image with Linux 3.7, i have no issues at all with kexec and any Linux kernels starting with 2.6 but FreeBSD loader won't boot and just hangs. The same issue with OpenWRT based on Linux 3.6 kernel. So, i started to analyze this problem and found out where it hangs. It seems that the purgatory code from kexec-tools loops endlessly if SHA256 verification of the loaded segments fails. See http://git.kernel.org/?p=utils/kernel/kexec/kexec-tools.git;a=blob_plain;f=purgatory/purgatory.c;hb=566ca8a12145196b00ad37939cfd58a97f96ba89 Because the function _verify_sha256_digest fails, the function _purgatory_ loops endlessly. This problem occurs only with Linux 3.6 or Linux 3.7 and FreeBSD loader. I killed the endless loop and could boot the FreeBSD loader on Linux 3.7 too. Any idea what could cause this problem ? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Found another strange problem. I'm not able to boot FreeBSD LiveCD with OpenWRT + Linux 3.8 (or Linux 3.7), the same CD which boots on OpenWRT + Linux 3.3.8. The LiveCD just panics and the PS3 console shuts down. Very odd. The problem is probably connected with the kexec issue i'm having and happens only with the recent Linux kernels. regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: Remove unneeded xxx_set_drvdata(..., NULL) calls
On Fri, 15 Feb 2013 15:18:35 -0800, Doug Anderson wrote:
There is simply no reason to be manually setting the private driver
data to NULL in the remove/fail to probe cases. This is just extra
cruft code that can be removed.
A few notes:
* Nothing relies on drvdata being set to NULL.
* The __device_release_driver() function eventually calls
dev_set_drvdata(dev, NULL) anyway, so there's no need to do it
twice.
I had not noticed this change. Very good news!
* I verified that there were no cases where xxx_get_drvdata() was
being called in these drivers and checking for / relying on the NULL
return value.
This could be cleaned up kernel-wide but for now just take the baby
step and remove from the i2c subsystem.
Reported-by: Wolfram Sang w...@the-dreams.de
Reported-by: Stephen Warren swar...@wwwdotorg.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
(...)
For i2c-taos-evm:
Reviewed-by: Jean Delvare kh...@linux-fr.org
Also a note:
--- a/drivers/i2c/busses/i2c-octeon.c
+++ b/drivers/i2c/busses/i2c-octeon.c
@@ -595,7 +595,7 @@ static int octeon_i2c_probe(struct platform_device *pdev)
result = i2c_add_adapter(i2c-adap);
if (result 0) {
dev_err(i2c-dev, failed to add adapter\n);
- goto fail_add;
+ goto out;
}
dev_info(i2c-dev, version %s\n, DRV_VERSION);
@@ -603,8 +603,6 @@ static int octeon_i2c_probe(struct platform_device *pdev)
return 0;
-fail_add:
- platform_set_drvdata(pdev, NULL);
out:
return result;
};
There no longer is any point in this error path, all gotos in this
function could be changed to returns (in a separate patch, obviously.)
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3: Strange issue with kexec and FreeBSD loader
Phileas Fogg wrote: I was able to capture the debug output from the purgatory code and it's very odd. This the SHA256 digest calculated by kexec-tools: root@ps3-linux:~# kexec -l loader.ps3 Warning: append= option is not passed. Using the first kernel root partition Modified cmdline: Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled segment[0].mem:0x131d000 memsz:262144 segment[1].mem:0x135d000 memsz:36864 segment[2].mem:0x7fff000 memsz:4096 sha256_digest: 77 d5 30 a7 67 5f 67 93 f1 e0 ce 84 bd 4e 1b ec 3c 4a 9e 86 5c a1 33 87 9e b1 5f c8 91 ce e8 61 And this is the debug output i'm always getting from the purgatory code: I'm in purgatory sha256 digests do not match :( digest: fd 4f df a8 af 5b e1 6b bc 51 5d b8 ab be 75 fb 76 fd 64 64 26 3e a8 9f 46 ec 91 de 05 4e 72 78 sha256_digest: 00 39 e3 b2 45 0d 20 68 74 c2 4e ee e4 4a cf ec c3 78 4f 1c 65 ff a8 76 73 68 5d 01 70 0b b6 50 regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev I was able to analyze the problem more and found out that the device tree memory region gets corrupted. I slightly modified kexec-tools and made it first compute a checksum of the first segment only where the new kernel is located. And the checksum was always verified as correct in the purgatoroy code. Then i made kexec-tools compute the checksum of the 3rd segment only where a device tree is stored. And this time the verify function in the purgatory failed always. Output form the purgatory code: I'm in purgatory sha256 digests do not match :( digest: e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f b9 24 27 ae 41 e4 64 9b 93 4c a4 95 99 1b 78 52 b8 55 sha256_digest: 57 08 81 e7 62 c3 22 2f d9 1d 94 a5 d0 f7 53 8f fe 69 64 84 4d 71 2d aa e2 07 45 b3 78 79 6e 26 sha256_regions: start=0x07fff000 len=0x1000 The sha256_digest is actually the correct SHA256 checksum precomputed by kexec-tools when the new kernel was given to the old kernel. I will try to analyze the problem more later. regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3: Strange issue with kexec and FreeBSD loader
I found new clues about the problem. Normally the device tree memory segment is allocated at the top of the boot memory region. The boot memory size on the PS3 console is 128MB. root@ps3-linux:~# kexec -l loader.ps3 segment[0].mem:0x131d000 memsz:262144 segment[1].mem:0x135d000 memsz:36864 segment[2].mem:0x7fff000 memsz:4096 And the device tree is located at address 0x7fff000, it's the last page of the boot memory. I changed the kexec-tools and made it store the device tree just after the purgatory code which is located at address 0x135d000. Like here: root@ps3-linux:~# kexec -l loader.ps3 segment[0].mem:0x131d000 memsz:262144 segment[1].mem:0x135d000 memsz:36864 segment[2].mem:0x1366000 memsz:4096 new address of device tree segment And now the sha256 verification is always successful for the FreeBSD loader too. But still no idea what actually corrupts the device tree segment when it's located at the top of the boot memory region. And why it happens on Linux 3.7 and Linux 3.8 but not on Linux 3.3.8. regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] of: use platform_device_add
On Fri, Jan 18, 2013 at 01:40:00AM +, Grant Likely wrote:
This allows platform_device_add a chance to call insert_resource on all
of the resources from OF. At a minimum this fills in proc/iomem and
presumably makes resource tracking and conflict detection work better.
However, it has the side effect of moving all OF generated platform
devices from /sys/devices to /sys/devices/platform/. It /shouldn't/
break userspace because userspace is not supposed to depend on the full
path (because userspace always does what it is supposed to, right?).
This may cause breakage if either:
1) any two nodes in a given device tree have overlapping staggered
regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained
within the other). In this case one of the devices will fail to
register and an exception will be needed in platform_device_add() to
complain but not fail.
Grant,
The patch introduce a regression on imx6q boot. The IOMUXC block on
imx6q is special. It acts not only a pin controller but also a system
controller with a bunch of system level registers in there. That's why
we currently have the following two nodes in imx6q device tree with the
same start reg address, which work with drivers/mfd/syscon.c and
drivers/pinctrl/pinctrl-imx6q.c respectively.
gpr: iomuxc-gpr@020e {
compatible = fsl,imx6q-iomuxc-gpr, syscon;
reg = 0x020e 0x38;
};
iomuxc: iomuxc@020e {
compatible = fsl,imx6q-iomuxc;
reg = 0x020e 0x4000;
};
With the patch in place, pinctrl-imx6q fails to register like below.
syscon 20e.iomuxc: syscon regmap start 0x20e end 0x20e3fff registered
imx6q-pinctrl 20e.iomuxc: can't request region for resource [mem
0x020e-0x020e3fff]
imx6q-pinctrl: probe of 20e.iomuxc failed with error -16
Shawn
2) any device calls request_mem_region() on a region larger than
specified in the device tree. In this case the device node may be
wrong, or the driver is overreaching. In either case I'd like to know
about any problems and fix them.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: dts - add ranges property for SEC
Hi Kim, Thank you for the fixing. Best regards, Liu Po - 8038 -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, February 13, 2013 1:27 AM To: Phillips Kim-R1AAHA Cc: Liu Po-B43644; linuxppc-...@ozlabs.org Subject: Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC On Jan 18, 2013, at 2:40 PM, Kim Phillips wrote: On Fri, 18 Jan 2013 17:16:13 +0800 Po Liu po@freescale.com wrote: This facilitates getting the physical address of the SEC node. Signed-off-by: Liu po po@freescale.com --- Reviewed-by: Kim Phillips kim.phill...@freescale.com Kim This was missing a trailing ';', so wondering if it was ever tested? I fixed when I applied. applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/kernel: using %12.12s instead of %12s for avoiding memory overflow.
Hello relative members:
please give a glance to this patch, when you have time.
thanks.
:-)
gchen.
于 2013年01月24日 12:14, Chen Gang 写道:
for tmp_part-header.name:
it is Terminating null required only for names 12 chars.
so need to limit the %.12s for it in printk
additional info:
%12s limit the width, not for the original string output length
if name length is more than 12, it still can be fully displayed.
if name length is less than 12, the ' ' will be filled before name.
%.12s truly limit the original string output length (precision)
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/nvram_64.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index bec1e93..57bf6d2 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -202,7 +202,7 @@ static void __init nvram_print_partitions(char * label)
printk(KERN_WARNING %s-\n, label);
printk(KERN_WARNING indx\t\tsig\tchks\tlen\tname\n);
list_for_each_entry(tmp_part, nvram_partitions, partition) {
- printk(KERN_WARNING %4d\t%02x\t%02x\t%d\t%12s\n,
+ printk(KERN_WARNING %4d\t%02x\t%02x\t%d\t%12.12s\n,
tmp_part-index, tmp_part-header.signature,
tmp_part-header.checksum, tmp_part-header.length,
tmp_part-header.name);
--
Chen Gang
Asianux Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] of: use platform_device_add
On Sun, Feb 17, 2013 at 11:03:35AM +0800, Shawn Guo wrote: On Fri, Jan 18, 2013 at 01:40:00AM +, Grant Likely wrote: This allows platform_device_add a chance to call insert_resource on all of the resources from OF. At a minimum this fills in proc/iomem and presumably makes resource tracking and conflict detection work better. However, it has the side effect of moving all OF generated platform devices from /sys/devices to /sys/devices/platform/. It /shouldn't/ break userspace because userspace is not supposed to depend on the full path (because userspace always does what it is supposed to, right?). This may cause breakage if either: 1) any two nodes in a given device tree have overlapping staggered regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained within the other). In this case one of the devices will fail to register and an exception will be needed in platform_device_add() to complain but not fail. Grant, The patch introduce a regression on imx6q boot. It also breaks all of_amba_device users. of_amba_device_create() -- amba_device_add() -- request_resource() and fails. Shawn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
