* PS3: Strange issue with kexec and FreeBSD loader
@ 2013-02-08 23:10 Phileas Fogg
2013-02-16 10:53 ` Phileas Fogg
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-08 23:10 UTC (permalink / raw)
To: linuxppc-dev
CkhpLAoKaSdtIHVzaW5nIE9wZW5XUlQgcGV0aXRib290IGJvb3Rsb2FkZXIgb24gbXkgUFMzIHRv
IGJvb3QgRnJlZUJTRCBsb2FkZXIgd2hpY2ggaXMgYSBzaW1wbGUgUFBDMzIgRUxGIGZpbGUuCkkg
aGF2ZW4ndCBoYWQgYW55IGlzc3VlcyB3aXRoIGl0IGFuZCBPcGVuV1JUIGJhc2VkIG9uIExpbnV4
IDMuMy44LgpSZWNlbnRseSBpIGJ1aWx0IGFuIE9wZW5XUlQgaW1hZ2Ugd2l0aCBMaW51eCAzLjcs
IGkgaGF2ZSBubyBpc3N1ZXMgYXQgYWxsIHdpdGgga2V4ZWMgYW5kIGFueSBMaW51eCBrZXJuZWxz
IHN0YXJ0aW5nIHdpdGggMi42IGJ1dApGcmVlQlNEIGxvYWRlciB3b24ndCBib290IGFuZCBqdXN0
IGhhbmdzLiBUaGUgc2FtZSBpc3N1ZSB3aXRoIE9wZW5XUlQgYmFzZWQgb24gTGludXggMy42IGtl
cm5lbC4KU28sIGkgc3RhcnRlZCB0byBhbmFseXplIHRoaXMgcHJvYmxlbSBhbmQgZm91bmQgb3V0
IHdoZXJlIGl0IGhhbmdzLgoKSXQgc2VlbXMgdGhhdCB0aGUgcHVyZ2F0b3J5IGNvZGUgZnJvbSBr
ZXhlYy10b29scyBsb29wcyBlbmRsZXNzbHkgaWYgU0hBMjU2IHZlcmlmaWNhdGlvbiBvZiB0aGUg
bG9hZGVkIHNlZ21lbnRzCmZhaWxzLgoKU2VlCsKgIGh0dHA6Ly9naXQua2VybmVsLm9yZy8/cD11
dGlscy9rZXJuZWwva2V4ZWMva2V4ZWMtdG9vbHMuZ2l0O2E9YmxvYl9wbGFpbjtmPXB1cmdhdG9y
eS9wdXJnYXRvcnkuYztoYj01NjZjYThhMTIxNDUxOTZiMDBhZDM3OTM5Y2ZkNThhOTdmOTZiYTg5
CgpCZWNhdXNlIHRoZSBmdW5jdGlvbiBfdmVyaWZ5X3NoYTI1Nl9kaWdlc3QgZmFpbHMsIHRoZSBm
dW5jdGlvbiBfcHVyZ2F0b3J5XyBsb29wcyBlbmRsZXNzbHkuClRoaXMgcHJvYmxlbSBvY2N1cnMg
b25seSB3aXRoIExpbnV4IDMuNiBvciBMaW51eCAzLjcgYW5kIEZyZWVCU0QgbG9hZGVyLgpJIGtp
bGxlZCB0aGUgZW5kbGVzcyBsb29wIGFuZCBjb3VsZCBib290IHRoZSBGcmVlQlNEIGxvYWRlciBv
biBMaW51eCAzLjcgdG9vLgoKQW55IGlkZWEgd2hhdCBjb3VsZCBjYXVzZSB0aGlzIHByb2JsZW0g
PwoKVGhhbmtzLgo=
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-08 23:10 PS3: Strange issue with kexec and FreeBSD loader Phileas Fogg
@ 2013-02-16 10:53 ` Phileas Fogg
2013-02-16 22:14 ` Phileas Fogg
2013-02-16 23:12 ` Phileas Fogg
2013-02-16 18:51 ` Phileas Fogg
2013-02-19 18:40 ` Phileas Fogg
2 siblings, 2 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-16 10:53 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-08 23:10 PS3: Strange issue with kexec and FreeBSD loader Phileas Fogg
2013-02-16 10:53 ` Phileas Fogg
@ 2013-02-16 18:51 ` Phileas Fogg
2013-02-19 18:40 ` Phileas Fogg
2 siblings, 0 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-16 18:51 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-16 10:53 ` Phileas Fogg
@ 2013-02-16 22:14 ` Phileas Fogg
2013-02-16 23:12 ` Phileas Fogg
1 sibling, 0 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-16 22:14 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
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=0x0000000007fff000 len=0x0000000000001000
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-16 10:53 ` Phileas Fogg
2013-02-16 22:14 ` Phileas Fogg
@ 2013-02-16 23:12 ` Phileas Fogg
2013-02-17 8:53 ` Geert Uytterhoeven
2013-02-21 0:14 ` Geoff Levand
1 sibling, 2 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-16 23:12 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-16 23:12 ` Phileas Fogg
@ 2013-02-17 8:53 ` Geert Uytterhoeven
2013-02-17 12:40 ` Phileas Fogg
2013-02-21 0:14 ` Geoff Levand
1 sibling, 1 reply; 23+ messages in thread
From: Geert Uytterhoeven @ 2013-02-17 8:53 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
Hi Phileas,
On Sun, Feb 17, 2013 at 12:12 AM, Phileas Fogg <phileas-fogg@mail.ru> wrote:
> 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.
Have you looked at the actual data that ends up being written there?
It may give a clue...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-17 8:53 ` Geert Uytterhoeven
@ 2013-02-17 12:40 ` Phileas Fogg
0 siblings, 0 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-17 12:40 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
Geert Uytterhoeven wrote:
> Hi Phileas,
>
> On Sun, Feb 17, 2013 at 12:12 AM, Phileas Fogg <phileas-fogg@mail.ru> wrote:
>> 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.
>
> Have you looked at the actual data that ends up being written there?
> It may give a clue...
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
i was able to dump the device tree data from the purgatory code and compared the
original DT which i dumped from kexec-tools and the one from purgatory.
About 20 bytes at the end of the string table of the device tree were corrupted.
Large part of the new data are 0s.
regards
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-08 23:10 PS3: Strange issue with kexec and FreeBSD loader Phileas Fogg
2013-02-16 10:53 ` Phileas Fogg
2013-02-16 18:51 ` Phileas Fogg
@ 2013-02-19 18:40 ` Phileas Fogg
2013-02-19 19:54 ` Phileas Fogg
2 siblings, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-19 18:40 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
I could finally find the commit which broke FreeBSD booting in linux-stable.git
repository.
The Linux 3.4-rc1 seems to have this problem already.
--------------
commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
Merge: b57cb72 dfbc2d7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Mar 21 18:55:10 2012 -0700
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc merge from Benjamin Herrenschmidt:
"Here's the powerpc batch for this merge window. It is going to be a
bit more nasty than usual as in touching things outside of
arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
rid of the bugger (legacy iSeries support) which was a PITA to
maintain and that nobody really used anymore.
Here are some of the highlights:
- Legacy iSeries is gone. Thanks Stephen ! There's still some bits
and pieces remaining if you do a grep -ir series arch/powerpc but
they are harmless and will be removed in the next few weeks
hopefully.
- The 'fadump' functionality (Firmware Assisted Dump) replaces the
previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
mechanism to get the hypervisor to do crash dumps on pSeries, the
new implementation hopefully being much more reliable. Thanks
Mahesh Salgaonkar.
- The "EEH" code (pSeries PCI error handling & recovery) got a big
spring cleaning, motivated by the need to be able to implement a
new backend for it on top of some new different type of firwmare.
The work isn't complete yet, but a good chunk of the cleanups is
there. Note that this adds a field to struct device_node which is
not very nice and which Grant objects to. I will have a patch soon
that moves that to a powerpc private data structure (hopefully
before rc1) and we'll improve things further later on (hopefully
getting rid of the need for that pointer completely). Thanks Gavin
Shan.
- I dug into our exception & interrupt handling code to improve the
way we do lazy interrupt handling (and make it work properly with
"edge" triggered interrupt sources), and while at it found & fixed
a wagon of issues in those areas, including adding support for page
fault retry & fatal signals on page faults.
- Your usual random batch of small fixes & updates, including a bunch
of new embedded boards, both Freescale and APM based ones, etc..."
I fixed up some conflicts with the generalized irq-domain changes from
Grant Likely, hopefully correctly.
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
(141 commits)
powerpc/ps3: Do not adjust the wrapper load address
powerpc: Remove the rest of the legacy iSeries include files
powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
init: Remove CONFIG_PPC_ISERIES
powerpc: Remove FW_FEATURE ISERIES from arch code
tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
powerpc/spufs: Fix double unlocks
powerpc/5200: convert mpc5200 to use of_platform_populate()
powerpc/mpc5200: add options to mpc5200_defconfig
powerpc/mpc52xx: add a4m072 board support
powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
board
powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
MAINTAINERS: Update PowerPC 4xx tree
powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
powerpc: document the FSL MPIC message register binding
powerpc: add support for MPIC message register API
powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
powerpc/85xx: mpc8548cds - add 36-bit dts
...
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-19 18:40 ` Phileas Fogg
@ 2013-02-19 19:54 ` Phileas Fogg
2013-02-20 20:43 ` Phileas Fogg
0 siblings, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-19 19:54 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
Phileas Fogg wrote:
> I could finally find the commit which broke FreeBSD booting in linux-stable.git
> repository.
> The Linux 3.4-rc1 seems to have this problem already.
>
> --------------
> commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
> Merge: b57cb72 dfbc2d7
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Mar 21 18:55:10 2012 -0700
>
> Merge branch 'next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
>
> Pull powerpc merge from Benjamin Herrenschmidt:
> "Here's the powerpc batch for this merge window. It is going to be a
> bit more nasty than usual as in touching things outside of
> arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
> rid of the bugger (legacy iSeries support) which was a PITA to
> maintain and that nobody really used anymore.
>
> Here are some of the highlights:
>
> - Legacy iSeries is gone. Thanks Stephen ! There's still some bits
> and pieces remaining if you do a grep -ir series arch/powerpc but
> they are harmless and will be removed in the next few weeks
> hopefully.
>
> - The 'fadump' functionality (Firmware Assisted Dump) replaces the
> previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
> mechanism to get the hypervisor to do crash dumps on pSeries, the
> new implementation hopefully being much more reliable. Thanks
> Mahesh Salgaonkar.
>
> - The "EEH" code (pSeries PCI error handling & recovery) got a big
> spring cleaning, motivated by the need to be able to implement a
> new backend for it on top of some new different type of firwmare.
>
> The work isn't complete yet, but a good chunk of the cleanups is
> there. Note that this adds a field to struct device_node which is
> not very nice and which Grant objects to. I will have a patch soon
> that moves that to a powerpc private data structure (hopefully
> before rc1) and we'll improve things further later on (hopefully
> getting rid of the need for that pointer completely). Thanks Gavin
> Shan.
>
> - I dug into our exception & interrupt handling code to improve the
> way we do lazy interrupt handling (and make it work properly with
> "edge" triggered interrupt sources), and while at it found & fixed
> a wagon of issues in those areas, including adding support for page
> fault retry & fatal signals on page faults.
>
> - Your usual random batch of small fixes & updates, including a bunch
> of new embedded boards, both Freescale and APM based ones, etc..."
>
> I fixed up some conflicts with the generalized irq-domain changes from
> Grant Likely, hopefully correctly.
>
> * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
> (141 commits)
> powerpc/ps3: Do not adjust the wrapper load address
> powerpc: Remove the rest of the legacy iSeries include files
> powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
> init: Remove CONFIG_PPC_ISERIES
> powerpc: Remove FW_FEATURE ISERIES from arch code
> tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
> powerpc/spufs: Fix double unlocks
> powerpc/5200: convert mpc5200 to use of_platform_populate()
> powerpc/mpc5200: add options to mpc5200_defconfig
> powerpc/mpc52xx: add a4m072 board support
> powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
> Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
> powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
> board
> powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
> MAINTAINERS: Update PowerPC 4xx tree
> powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
> powerpc: document the FSL MPIC message register binding
> powerpc: add support for MPIC message register API
> powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
> powerpc/85xx: mpc8548cds - add 36-bit dts
> ...
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Reverting this commit fixes the problem with SHA256 checkusm in the purgatory
code too. I'm trying to find out which commit exactly caused the problem.
regards
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-19 19:54 ` Phileas Fogg
@ 2013-02-20 20:43 ` Phileas Fogg
2013-02-21 0:32 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-20 20:43 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
Phileas Fogg wrote:
> Phileas Fogg wrote:
>> I could finally find the commit which broke FreeBSD booting in linux-stable.git
>> repository.
>> The Linux 3.4-rc1 seems to have this problem already.
>>
>> --------------
>> commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
>> Merge: b57cb72 dfbc2d7
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date: Wed Mar 21 18:55:10 2012 -0700
>>
>> Merge branch 'next' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
>>
>> Pull powerpc merge from Benjamin Herrenschmidt:
>> "Here's the powerpc batch for this merge window. It is going to be a
>> bit more nasty than usual as in touching things outside of
>> arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
>> rid of the bugger (legacy iSeries support) which was a PITA to
>> maintain and that nobody really used anymore.
>>
>> Here are some of the highlights:
>>
>> - Legacy iSeries is gone. Thanks Stephen ! There's still some bits
>> and pieces remaining if you do a grep -ir series arch/powerpc but
>> they are harmless and will be removed in the next few weeks
>> hopefully.
>>
>> - The 'fadump' functionality (Firmware Assisted Dump) replaces the
>> previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
>> mechanism to get the hypervisor to do crash dumps on pSeries, the
>> new implementation hopefully being much more reliable. Thanks
>> Mahesh Salgaonkar.
>>
>> - The "EEH" code (pSeries PCI error handling & recovery) got a big
>> spring cleaning, motivated by the need to be able to implement a
>> new backend for it on top of some new different type of firwmare.
>>
>> The work isn't complete yet, but a good chunk of the cleanups is
>> there. Note that this adds a field to struct device_node which is
>> not very nice and which Grant objects to. I will have a patch soon
>> that moves that to a powerpc private data structure (hopefully
>> before rc1) and we'll improve things further later on (hopefully
>> getting rid of the need for that pointer completely). Thanks Gavin
>> Shan.
>>
>> - I dug into our exception & interrupt handling code to improve the
>> way we do lazy interrupt handling (and make it work properly with
>> "edge" triggered interrupt sources), and while at it found & fixed
>> a wagon of issues in those areas, including adding support for page
>> fault retry & fatal signals on page faults.
>>
>> - Your usual random batch of small fixes & updates, including a bunch
>> of new embedded boards, both Freescale and APM based ones, etc..."
>>
>> I fixed up some conflicts with the generalized irq-domain changes from
>> Grant Likely, hopefully correctly.
>>
>> * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
>> (141 commits)
>> powerpc/ps3: Do not adjust the wrapper load address
>> powerpc: Remove the rest of the legacy iSeries include files
>> powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
>> init: Remove CONFIG_PPC_ISERIES
>> powerpc: Remove FW_FEATURE ISERIES from arch code
>> tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
>> powerpc/spufs: Fix double unlocks
>> powerpc/5200: convert mpc5200 to use of_platform_populate()
>> powerpc/mpc5200: add options to mpc5200_defconfig
>> powerpc/mpc52xx: add a4m072 board support
>> powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
>> Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
>> powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
>> board
>> powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
>> MAINTAINERS: Update PowerPC 4xx tree
>> powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
>> powerpc: document the FSL MPIC message register binding
>> powerpc: add support for MPIC message register API
>> powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
>> powerpc/85xx: mpc8548cds - add 36-bit dts
>> ...
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Reverting this commit fixes the problem with SHA256 checkusm in the purgatory
> code too. I'm trying to find out which commit exactly caused the problem.
>
> regards
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
I found the single commit which brakes kexec stuff for FreeBSD loader or other
custom ELF kernels on the PS3 console.
From 7230c5644188cd9e3fb380cc97dde00c464a3ba7 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 6 Mar 2012 18:27:59 +1100
Subject: [PATCH] powerpc: Rework lazy-interrupt handling
regards
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-16 23:12 ` Phileas Fogg
2013-02-17 8:53 ` Geert Uytterhoeven
@ 2013-02-21 0:14 ` Geoff Levand
1 sibling, 0 replies; 23+ messages in thread
From: Geoff Levand @ 2013-02-21 0:14 UTC (permalink / raw)
To: Phileas Fogg; +Cc: cbe-oss-dev, linuxppc-dev
Hi Phileas,
On Sun, 2013-02-17 at 00:12 +0100, Phileas Fogg wrote:
> 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.
Excellent work so far.
You may be able to use the Cell Processor's DABR (Data Address Breakpoint)
register to find out what code is writing to that memory area. I have a
helper patch to setup the DABR register from kernel code here:
http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux.git;a=commitdiff;h=c46799f5c6ba7594cdaa248ec60a50c7ad1cdeaa
-Geoff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-20 20:43 ` Phileas Fogg
@ 2013-02-21 0:32 ` Benjamin Herrenschmidt
2013-02-21 20:38 ` Phileas Fogg
0 siblings, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2013-02-21 0:32 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
On Wed, 2013-02-20 at 21:43 +0100, Phileas Fogg wrote:
> I found the single commit which brakes kexec stuff for FreeBSD loader or other
> custom ELF kernels on the PS3 console.
>
>
> From 7230c5644188cd9e3fb380cc97dde00c464a3ba7 Mon Sep 17 00:00:00 2001
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Tue, 6 Mar 2012 18:27:59 +1100
> Subject: [PATCH] powerpc: Rework lazy-interrupt handling
Odd... That rework had its own issues and so several patches went in
subsequently to address them. It's possible that the PS3 does more
horrid stuff we missed here but I don't quite see how to relate that to
your specific memory corruption problem...
Do you see any "pattern" to the corruption ? Does it looks like
something known ? IE., exception frame, ASCII data, MSR values, ...
Ben.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 20:38 ` Phileas Fogg
@ 2013-02-21 20:35 ` Benjamin Herrenschmidt
2013-02-21 21:44 ` Phileas Fogg
2013-02-21 22:06 ` Phileas Fogg
0 siblings, 2 replies; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2013-02-21 20:35 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
On Thu, 2013-02-21 at 21:38 +0100, Phileas Fogg wrote:
> The new 8 bytes at offset 0x90 in dt.dump.hex look suspicously like
> the kernel virtual address: 0xc00000000001a4a0.
It does indeed. What does that address correspond to in the kernel
text ? Can you disassemble around it with "objdump -D vmlinux" ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 0:32 ` Benjamin Herrenschmidt
@ 2013-02-21 20:38 ` Phileas Fogg
2013-02-21 20:35 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-21 20:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Wed, 2013-02-20 at 21:43 +0100, Phileas Fogg wrote:
>
>> I found the single commit which brakes kexec stuff for FreeBSD loader or other
>> custom ELF kernels on the PS3 console.
>>
>>
>> From 7230c5644188cd9e3fb380cc97dde00c464a3ba7 Mon Sep 17 00:00:00 2001
>> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Date: Tue, 6 Mar 2012 18:27:59 +1100
>> Subject: [PATCH] powerpc: Rework lazy-interrupt handling
>
> Odd... That rework had its own issues and so several patches went in
> subsequently to address them. It's possible that the PS3 does more
> horrid stuff we missed here but I don't quite see how to relate that to
> your specific memory corruption problem...
>
> Do you see any "pattern" to the corruption ? Does it looks like
> something known ? IE., exception frame, ASCII data, MSR values, ...
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Hi,
here is some data for analyzing.
First, i modified kexec-tools and dumped the kernel and DT segments before they
are passed to the kexec_load syscall. I also modified the purgatory code and
made it dump the computed SHA256 checksum, the original SHA256 checksum and
the DT.
Here is the output from kexec-tools:
--------------------------------------
root@ps3-linux:~# kexec -l loader.ps3
segment[0].mem:0x1371000 memsz:262144
segment[1].mem:0x13b1000 memsz:36864
segment[2].mem:0x7fff000 memsz:4096
sha256_digest: 66 a6 c0 be d5 3c ba c2 85 6 97 4 d2 e1 aa 28 63 fa 7f 79 ce de
e7 7f 26 14 a1 fa 2a ea bc 83
Here is the output from the purgatory code:
---------------------------------------------
I'm in purgatory
sha256 digests do not match :(
digest: d4 dc 50 0a ef 78 8e 28 e0 9a fe 52 e1 72 1c b3 23 a6 f4 ea 40
7a 2d fd 6b 2a 66 95 63 f6 99 2a
sha256_digest: 66 a6 c0 be d5 3c ba c2 85 06 97 04 d2 e1 aa 28 63 fa 7f 79 ce
de e7 7f 26 14 a1 fa 2a ea bc 83
sha256_regions:
start=0x0000000001371000 len=0x0000000000040000
start=0x0000000007fff000 len=0x0000000000001000
Here is the DT dump from kexec-tools:
---------------------------------------
00000000 d0 0d fe ed 00 00 03 70 00 00 00 40 00 00 02 74 |.......p...@...t|
00000010 00 00 00 20 00 00 00 02 00 00 00 02 00 00 00 00 |... ............|
00000020 00 00 00 00 07 ff f0 00 00 00 00 00 00 00 03 70 |...............p|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 01 2f 00 00 00 00 00 00 03 00 00 00 04 |..../...........|
00000050 00 00 00 00 00 00 00 02 00 00 00 03 00 00 00 04 |................|
00000060 00 00 00 0f 00 00 00 02 00 00 00 03 00 00 00 09 |................|
00000070 00 00 00 1b 00 00 00 00 73 6f 6e 79 2c 70 73 33 |........sony,ps3|
00000080 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 26 |...............&|
00000090 00 00 00 00 00 00 00 03 00 00 00 08 00 00 00 39 |...............9|
000000a0 00 00 00 00 38 6d 43 80 00 00 00 03 00 00 00 08 |....8mC.........|
000000b0 00 00 00 48 00 00 00 00 53 6f 6e 79 50 53 33 00 |...H....SonyPS3.|
000000c0 00 00 00 03 00 00 00 01 00 00 00 4e 00 00 00 00 |...........N....|
000000d0 00 00 00 01 2f 63 68 6f 73 65 6e 00 00 00 00 03 |..../chosen.....|
000000e0 00 00 00 08 00 00 00 53 00 00 00 00 00 00 00 00 |.......S........|
000000f0 00 00 00 03 00 00 00 07 00 00 00 4e 63 68 6f 73 |...........Nchos|
00000100 65 6e 00 00 00 00 00 03 00 00 00 02 00 00 00 66 |en.............f|
00000110 20 00 00 00 00 00 00 02 00 00 00 01 2f 63 70 75 | .........../cpu|
00000120 73 00 00 00 00 00 00 03 00 00 00 04 00 00 00 00 |s...............|
00000130 00 00 00 01 00 00 00 03 00 00 00 04 00 00 00 0f |................|
00000140 00 00 00 00 00 00 00 03 00 00 00 05 00 00 00 4e |...............N|
00000150 63 70 75 73 00 00 00 00 00 00 00 01 2f 63 70 75 |cpus......../cpu|
00000160 73 2f 63 70 75 40 30 00 00 00 00 03 00 00 00 04 |s/cpu@0.........|
00000170 00 00 00 6f 00 00 00 00 00 00 00 03 00 00 00 04 |...o............|
00000180 00 00 00 7f 00 00 00 80 00 00 00 03 00 00 00 04 |................|
00000190 00 00 00 91 00 00 80 00 00 00 00 03 00 00 00 04 |................|
000001a0 00 00 00 9e 63 70 75 00 00 00 00 03 00 00 00 04 |....cpu.........|
000001b0 00 00 00 aa 00 00 00 80 00 00 00 03 00 00 00 04 |................|
000001c0 00 00 00 bc 00 00 80 00 00 00 00 03 00 00 00 08 |................|
000001d0 00 00 00 c9 00 00 00 00 00 00 00 00 00 00 00 01 |................|
000001e0 00 00 00 03 00 00 00 04 00 00 00 4e 63 70 75 00 |...........Ncpu.|
000001f0 00 00 00 03 00 00 00 04 00 00 00 e4 00 00 00 00 |................|
00000200 00 00 00 03 00 00 00 04 00 00 00 e8 00 00 00 00 |................|
00000210 00 00 00 02 00 00 00 02 00 00 00 01 2f 6d 65 6d |............/mem|
00000220 6f 72 79 00 00 00 00 03 00 00 00 07 00 00 00 9e |ory.............|
00000230 6d 65 6d 6f 72 79 00 00 00 00 00 03 00 00 00 07 |memory..........|
00000240 00 00 00 4e 6d 65 6d 6f 72 79 00 00 00 00 00 03 |...Nmemory......|
00000250 00 00 00 10 00 00 00 e4 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 08 00 00 00 00 00 00 02 00 00 00 02 |................|
00000270 00 00 00 09 23 61 64 64 72 65 73 73 2d 63 65 6c |....#address-cel|
00000280 6c 73 00 23 73 69 7a 65 2d 63 65 6c 6c 73 00 63 |ls.#size-cells.c|
00000290 6f 6d 70 61 74 69 62 6c 65 00 6c 69 6e 75 78 2c |ompatible.linux,|
000002a0 61 76 5f 6d 75 6c 74 69 5f 6f 75 74 00 6c 69 6e |av_multi_out.lin|
000002b0 75 78 2c 72 74 63 5f 64 69 66 66 00 6d 6f 64 65 |ux,rtc_diff.mode|
000002c0 6c 00 6e 61 6d 65 00 6c 69 6e 75 78 2c 6d 65 6d |l.name.linux,mem|
000002d0 6f 72 79 2d 6c 69 6d 69 74 00 62 6f 6f 74 61 72 |ory-limit.bootar|
000002e0 67 73 00 63 6c 6f 63 6b 2d 66 72 65 71 75 65 6e |gs.clock-frequen|
000002f0 63 79 00 64 2d 63 61 63 68 65 2d 6c 69 6e 65 2d |cy.d-cache-line-|
00000300 73 69 7a 65 00 64 2d 63 61 63 68 65 2d 73 69 7a |size.d-cache-siz|
00000310 65 00 64 65 76 69 63 65 5f 74 79 70 65 00 69 2d |e.device_type.i-|
00000320 63 61 63 68 65 2d 6c 69 6e 65 2d 73 69 7a 65 00 |cache-line-size.|
00000330 69 2d 63 61 63 68 65 2d 73 69 7a 65 00 69 62 6d |i-cache-size.ibm|
00000340 2c 70 70 63 2d 69 6e 74 65 72 72 75 70 74 2d 73 |,ppc-interrupt-s|
00000350 65 72 76 65 72 23 73 00 72 65 67 00 74 69 6d 65 |erver#s.reg.time|
00000360 62 61 73 65 2d 66 72 65 71 75 65 6e 63 79 00 00 |base-frequency..|
00000370
Here is the DT dump from the purgatory code after the verify function failed:
------------------------------------------------------------------------------
00000000 d0 0d fe ed 00 00 03 70 00 00 00 40 00 00 02 74 |.......p...@...t|
00000010 00 00 00 20 00 00 00 02 00 00 00 02 00 00 00 00 |... ............|
00000020 00 00 00 00 07 ff f0 00 00 00 00 00 00 00 03 70 |...............p|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 01 2f 00 00 00 00 00 00 03 00 00 00 04 |..../...........|
00000050 00 00 00 00 00 00 00 02 00 00 00 03 00 00 00 04 |................|
00000060 00 00 00 0f 00 00 00 02 00 00 00 03 00 00 00 09 |................|
00000070 00 00 00 1b 00 00 00 00 73 6f 6e 79 2c 70 73 33 |........sony,ps3|
00000080 80 00 00 00 00 00 80 30 80 00 00 00 00 00 80 02 |.......0........|
00000090 c0 00 00 00 00 01 a4 a0 00 00 00 08 00 00 00 39 |...............9|
000000a0 00 00 00 00 38 6d 43 80 00 00 00 03 00 00 00 08 |....8mC.........|
000000b0 00 00 00 48 00 00 00 00 53 6f 6e 79 50 53 33 00 |...H....SonyPS3.|
000000c0 00 00 00 03 00 00 00 01 00 00 00 4e 00 00 00 00 |...........N....|
000000d0 00 00 00 01 2f 63 68 6f 73 65 6e 00 00 00 00 03 |..../chosen.....|
000000e0 00 00 00 08 00 00 00 53 00 00 00 00 00 00 00 00 |.......S........|
000000f0 00 00 00 03 00 00 00 07 00 00 00 4e 63 68 6f 73 |...........Nchos|
00000100 65 6e 00 00 00 00 00 03 00 00 00 02 00 00 00 66 |en.............f|
00000110 20 00 00 00 00 00 00 02 00 00 00 01 2f 63 70 75 | .........../cpu|
00000120 73 00 00 00 00 00 00 03 00 00 00 04 00 00 00 00 |s...............|
00000130 00 00 00 01 00 00 00 03 00 00 00 04 00 00 00 0f |................|
00000140 00 00 00 00 00 00 00 03 00 00 00 05 00 00 00 4e |...............N|
00000150 63 70 75 73 00 00 00 00 00 00 00 01 2f 63 70 75 |cpus......../cpu|
00000160 73 2f 63 70 75 40 30 00 00 00 00 03 00 00 00 04 |s/cpu@0.........|
00000170 00 00 00 6f 00 00 00 00 00 00 00 03 00 00 00 04 |...o............|
00000180 00 00 00 7f 00 00 00 80 00 00 00 03 00 00 00 04 |................|
00000190 00 00 00 91 00 00 80 00 00 00 00 03 00 00 00 04 |................|
000001a0 00 00 00 9e 63 70 75 00 00 00 00 03 00 00 00 04 |....cpu.........|
000001b0 00 00 00 aa 00 00 00 80 00 00 00 03 00 00 00 04 |................|
000001c0 00 00 00 bc 00 00 80 00 00 00 00 03 00 00 00 08 |................|
000001d0 00 00 00 c9 00 00 00 00 00 00 00 00 00 00 00 01 |................|
000001e0 00 00 00 03 00 00 00 04 00 00 00 4e 63 70 75 00 |...........Ncpu.|
000001f0 00 00 00 03 00 00 00 04 00 00 00 e4 00 00 00 00 |................|
00000200 00 00 00 03 00 00 00 04 00 00 00 e8 00 00 00 00 |................|
00000210 00 00 00 02 00 00 00 02 00 00 00 09 2f 6d 65 6d |............/mem|
00000220 6f 72 79 00 00 00 00 03 00 00 00 07 00 00 00 9e |ory.............|
00000230 6d 65 6d 6f 72 79 00 00 00 00 00 03 00 00 00 07 |memory..........|
00000240 00 00 00 4e 6d 65 6d 6f 72 79 00 00 00 00 00 03 |...Nmemory......|
00000250 00 00 00 10 00 00 00 e4 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 08 00 00 00 00 00 00 02 00 00 00 02 |................|
00000270 00 00 00 09 23 61 64 64 72 65 73 73 2d 63 65 6c |....#address-cel|
00000280 6c 73 00 23 73 69 7a 65 2d 63 65 6c 6c 73 00 63 |ls.#size-cells.c|
00000290 6f 6d 70 61 74 69 62 6c 65 00 6c 69 6e 75 78 2c |ompatible.linux,|
000002a0 61 76 5f 6d 75 6c 74 69 5f 6f 75 74 00 6c 69 6e |av_multi_out.lin|
000002b0 75 78 2c 72 74 63 5f 64 69 66 66 00 6d 6f 64 65 |ux,rtc_diff.mode|
000002c0 6c 00 6e 61 6d 65 00 6c 69 6e 75 78 2c 6d 65 6d |l.name.linux,mem|
000002d0 6f 72 79 2d 6c 69 6d 69 74 00 62 6f 6f 74 61 72 |ory-limit.bootar|
000002e0 67 73 00 63 6c 6f 63 6b 2d 66 72 65 71 75 65 6e |gs.clock-frequen|
000002f0 63 79 00 64 2d 63 61 63 68 65 2d 6c 69 6e 65 2d |cy.d-cache-line-|
00000300 73 69 7a 65 00 64 2d 63 61 63 68 65 2d 73 69 7a |size.d-cache-siz|
00000310 65 00 64 65 76 69 63 65 5f 74 79 70 65 00 69 2d |e.device_type.i-|
00000320 63 61 63 68 65 2d 6c 69 6e 65 2d 73 69 7a 65 00 |cache-line-size.|
00000330 69 2d 63 61 63 68 65 2d 73 69 7a 65 00 69 62 6d |i-cache-size.ibm|
00000340 2c 70 70 63 2d 69 6e 74 65 72 72 75 70 74 2d 73 |,ppc-interrupt-s|
00000350 65 72 76 65 72 23 73 00 72 65 67 00 74 69 6d 65 |erver#s.reg.time|
00000360 62 61 73 65 2d 66 72 65 71 75 65 6e 63 79 00 00 |base-frequency..|
00000370
And here is the diff between 2 hexdumps:
-----------------------------------------
--- dt.kexec.hex
+++ dt.dump.hex
@@ -6,8 +6,8 @@
00000050 00 00 00 00 00 00 00 02 00 00 00 03 00 00 00 04 |................|
00000060 00 00 00 0f 00 00 00 02 00 00 00 03 00 00 00 09 |................|
00000070 00 00 00 1b 00 00 00 00 73 6f 6e 79 2c 70 73 33 |........sony,ps3|
-00000080 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 26 |...............&|
-00000090 00 00 00 00 00 00 00 03 00 00 00 08 00 00 00 39 |...............9|
+00000080 80 00 00 00 00 00 80 30 80 00 00 00 00 00 80 02 |.......0........|
+00000090 c0 00 00 00 00 01 a4 a0 00 00 00 08 00 00 00 39 |...............9|
000000a0 00 00 00 00 38 6d 43 80 00 00 00 03 00 00 00 08 |....8mC.........|
000000b0 00 00 00 48 00 00 00 00 53 6f 6e 79 50 53 33 00 |...H....SonyPS3.|
000000c0 00 00 00 03 00 00 00 01 00 00 00 4e 00 00 00 00 |...........N....|
@@ -31,7 +31,7 @@
000001e0 00 00 00 03 00 00 00 04 00 00 00 4e 63 70 75 00 |...........Ncpu.|
000001f0 00 00 00 03 00 00 00 04 00 00 00 e4 00 00 00 00 |................|
00000200 00 00 00 03 00 00 00 04 00 00 00 e8 00 00 00 00 |................|
-00000210 00 00 00 02 00 00 00 02 00 00 00 01 2f 6d 65 6d |............/mem|
+00000210 00 00 00 02 00 00 00 02 00 00 00 09 2f 6d 65 6d |............/mem|
00000220 6f 72 79 00 00 00 00 03 00 00 00 07 00 00 00 9e |ory.............|
00000230 6d 65 6d 6f 72 79 00 00 00 00 00 03 00 00 00 07 |memory..........|
00000240 00 00 00 4e 6d 65 6d 6f 72 79 00 00 00 00 00 03 |...Nmemory......|
As you see, the data is different at offsets 0x80, 0x90 and 0x210.
The new 8 bytes at offset 0x90 in dt.dump.hex look suspicously like the kernel
virtual address: 0xc00000000001a4a0.
I'll try out the advice with DABR register from Geoff later and see if i can get
the code address which corrupts the data in DT.
regards
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 20:35 ` Benjamin Herrenschmidt
@ 2013-02-21 21:44 ` Phileas Fogg
2013-02-21 23:46 ` Benjamin Herrenschmidt
2013-02-21 22:06 ` Phileas Fogg
1 sibling, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-21 21:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Thu, 2013-02-21 at 21:38 +0100, Phileas Fogg wrote:
>> The new 8 bytes at offset 0x90 in dt.dump.hex look suspicously like
>> the kernel virtual address: 0xc00000000001a4a0.
>
> It does indeed. What does that address correspond to in the kernel
> text ? Can you disassemble around it with "objdump -D vmlinux" ?
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Here.
I used OpenWRT ELF for testing and it's stripped.
Then i compiled Linux 3.8 myself and didn't strip it.
Addresses are different in both cases but the code is the same and
it is kexec code :)
Stripped OpenWRT image:
------------------------
c00000000001a474: 48 00 00 05 bl 0xc00000000001a478
c00000000001a478: 7c a8 02 a6 mflr r5
c00000000001a47c: 38 a5 00 1c addi r5,r5,28
c00000000001a480: 7c 21 0b 78 mr r1,r1
c00000000001a484: 80 85 00 00 lwz r4,0(r5)
c00000000001a488: 2c 04 00 00 cmpwi r4,0
c00000000001a48c: 40 82 00 62 bnea- 0x60
c00000000001a490: 4b ff ff f0 b 0xc00000000001a480
c00000000001a494: 00 00 00 00 .long 0x0
c00000000001a498: a0 6d 00 48 lhz r3,72(r13)
c00000000001a49c: 48 00 00 11 bl 0xc00000000001a4ac
c00000000001a4a0: 38 80 00 02 li r4,2 <-------- !!!
c00000000001a4a4: 98 8d 00 4b stb r4,75(r13)
c00000000001a4a8: 4b ff ff cc b 0xc00000000001a474
c00000000001a4ac: 39 20 00 02 li r9,2
c00000000001a4b0: 39 40 00 30 li r10,48
c00000000001a4b4: 7d 68 02 a6 mflr r11
c00000000001a4b8: 7d 80 00 a6 mfmsr r12
c00000000001a4bc: 7d 89 48 78 andc r9,r12,r9
c00000000001a4c0: 7d 8a 50 78 andc r10,r12,r10
c00000000001a4c4: 7d 21 01 64 mtmsrd r9,1
Unstripped Linux 3.8 kernel:
-----------------------------
c00000000001c02c <.kexec_wait>:
c00000000001c02c: 48 00 00 05 bl c00000000001c030 <.kexec_wait+0x4>
c00000000001c030: 7c a8 02 a6 mflr r5
c00000000001c034: 38 a5 00 1c addi r5,r5,28
c00000000001c038: 7c 21 0b 78 mr r1,r1
c00000000001c03c: 80 85 00 00 lwz r4,0(r5)
c00000000001c040: 2c 04 00 00 cmpwi r4,0
c00000000001c044: 40 82 00 62 bnea- 60 <reloc_start+0x60>
c00000000001c048: 4b ff ff f0 b c00000000001c038 <.kexec_wait+0xc>
c00000000001c04c <kexec_flag>:
c00000000001c04c: 00 00 00 00 .long 0x0
c00000000001c050 <.kexec_smp_wait>:
c00000000001c050: a0 6d 00 48 lhz r3,72(r13)
c00000000001c054: 48 00 00 11 bl c00000000001c064 <real_mode>
c00000000001c058: 38 80 00 02 li r4,2 <---------- !!!
c00000000001c05c: 98 8d 00 4b stb r4,75(r13)
c00000000001c060: 4b ff ff cc b c00000000001c02c <.kexec_wait>
c00000000001c064 <real_mode>:
c00000000001c064: 39 20 00 02 li r9,2
c00000000001c068: 39 40 00 30 li r10,48
regards
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 20:35 ` Benjamin Herrenschmidt
2013-02-21 21:44 ` Phileas Fogg
@ 2013-02-21 22:06 ` Phileas Fogg
2013-02-21 23:47 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-21 22:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Thu, 2013-02-21 at 21:38 +0100, Phileas Fogg wrote:
>> The new 8 bytes at offset 0x90 in dt.dump.hex look suspicously like
>> the kernel virtual address: 0xc00000000001a4a0.
>
> It does indeed. What does that address correspond to in the kernel
> text ? Can you disassemble around it with "objdump -D vmlinux" ?
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Does it look like the new data at offset 0x80 and 0x88 in DT are MSR flags
MSR_DR, MSR_IR and MSR_EE ?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 21:44 ` Phileas Fogg
@ 2013-02-21 23:46 ` Benjamin Herrenschmidt
2013-02-22 20:49 ` Phileas Fogg
0 siblings, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2013-02-21 23:46 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
On Thu, 2013-02-21 at 22:44 +0100, Phileas Fogg wrote:
> Stripped OpenWRT image:
> ------------------------
>
> c00000000001a474: 48 00 00 05 bl 0xc00000000001a478
> c00000000001a478: 7c a8 02 a6 mflr r5
> c00000000001a47c: 38 a5 00 1c addi r5,r5,28
> c00000000001a480: 7c 21 0b 78 mr r1,r1
> c00000000001a484: 80 85 00 00 lwz r4,0(r5)
> c00000000001a488: 2c 04 00 00 cmpwi r4,0
> c00000000001a48c: 40 82 00 62 bnea- 0x60
> c00000000001a490: 4b ff ff f0 b 0xc00000000001a480
> c00000000001a494: 00 00 00 00 .long 0x0
> c00000000001a498: a0 6d 00 48 lhz r3,72(r13)
> c00000000001a49c: 48 00 00 11 bl 0xc00000000001a4ac
Smell like a bad stack pointer to me...
One thing I noticed is that kexec doesn't seem to hard disable
interrupts, which is ... fishy at best. It should do that
before it switches stacks around. Dunno if that's the cause
of the problem but it might be worth adding a hard_irq_disable()
after all the local_irq_disable(), making sure we are hard
disabled before going into asm.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 22:06 ` Phileas Fogg
@ 2013-02-21 23:47 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2013-02-21 23:47 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
On Thu, 2013-02-21 at 23:06 +0100, Phileas Fogg wrote:
> Does it look like the new data at offset 0x80 and 0x88 in DT are MSR
> flags
> MSR_DR, MSR_IR and MSR_EE ?
Yes, that looks plausible though I would have expected ME to be set as
well ... Or it could be a CCR value. But it does look like something
splattered the DT as if it was a stack... ie, bad r1 value.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-22 20:49 ` Phileas Fogg
@ 2013-02-22 19:52 ` Benjamin Herrenschmidt
2013-02-22 23:41 ` Phileas Fogg
0 siblings, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2013-02-22 19:52 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
On Fri, 2013-02-22 at 21:49 +0100, Phileas Fogg wrote:
> i wanted to let you know that i tested your advice. And let me say, it's was a
> damn good advice :) I can boot FreeBSD loader on Linux 3.8 now, no SHA256
> checksum failures. And no panics with FreeBSD LiveCD anymore too.
>
> I just inserted hard_irq_disable() after each local_irq_disable() in
> arch/powerpc/kernel/machine_kexec_64.c
Awesome ! :-)
Care to send a patch with a Signed-off-by: ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-21 23:46 ` Benjamin Herrenschmidt
@ 2013-02-22 20:49 ` Phileas Fogg
2013-02-22 19:52 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-22 20:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Thu, 2013-02-21 at 22:44 +0100, Phileas Fogg wrote:
>> Stripped OpenWRT image:
>> ------------------------
>>
>> c00000000001a474: 48 00 00 05 bl 0xc00000000001a478
>> c00000000001a478: 7c a8 02 a6 mflr r5
>> c00000000001a47c: 38 a5 00 1c addi r5,r5,28
>> c00000000001a480: 7c 21 0b 78 mr r1,r1
>> c00000000001a484: 80 85 00 00 lwz r4,0(r5)
>> c00000000001a488: 2c 04 00 00 cmpwi r4,0
>> c00000000001a48c: 40 82 00 62 bnea- 0x60
>> c00000000001a490: 4b ff ff f0 b 0xc00000000001a480
>> c00000000001a494: 00 00 00 00 .long 0x0
>> c00000000001a498: a0 6d 00 48 lhz r3,72(r13)
>> c00000000001a49c: 48 00 00 11 bl 0xc00000000001a4ac
>
>
> Smell like a bad stack pointer to me...
>
> One thing I noticed is that kexec doesn't seem to hard disable
> interrupts, which is ... fishy at best. It should do that
> before it switches stacks around. Dunno if that's the cause
> of the problem but it might be worth adding a hard_irq_disable()
> after all the local_irq_disable(), making sure we are hard
> disabled before going into asm.
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Hi,
i wanted to let you know that i tested your advice. And let me say, it's was a
damn good advice :) I can boot FreeBSD loader on Linux 3.8 now, no SHA256
checksum failures. And no panics with FreeBSD LiveCD anymore too.
I just inserted hard_irq_disable() after each local_irq_disable() in
arch/powerpc/kernel/machine_kexec_64.c
Thanks
regards
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-22 23:41 ` Phileas Fogg
@ 2013-02-22 22:45 ` Benjamin Herrenschmidt
2013-02-22 23:53 ` Phileas Fogg
0 siblings, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2013-02-22 22:45 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
On Sat, 2013-02-23 at 00:41 +0100, Phileas Fogg wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2013-02-22 at 21:49 +0100, Phileas Fogg wrote:
> >> i wanted to let you know that i tested your advice. And let me say, it's was a
> >> damn good advice :) I can boot FreeBSD loader on Linux 3.8 now, no SHA256
> >> checksum failures. And no panics with FreeBSD LiveCD anymore too.
> >>
> >> I just inserted hard_irq_disable() after each local_irq_disable() in
> >> arch/powerpc/kernel/machine_kexec_64.c
> >
> > Awesome ! :-)
> >
> > Care to send a patch with a Signed-off-by: ?
>
> No problem, but as i said it was your idea how to fix the issue with kexec.
> Anyways here is the patch which i tested on my PS3 console with Linux 3.8.
> After applying this patch i can boot any Linux kernel starting with 2.6,
> FreeBSD loader, FreeBSD LiveCD and my own tiny ELF kernels too.
> Even OpenBSD bootloader starts now too :)
> And i don't see any failed SHA256 checksums in the purgatory code.
Thanks, but I still need the Signed-off-by: line before i can apply
it :-) (legal...)
Cheers,
Ben.
> regards
>
> From c17cdf38dfe180b4a571827bb547aaf9b678cf29 Mon Sep 17 00:00:00 2001
> From: Phileas Fogg <phileas-fogg@mail.ru>
> Date: Sat, 23 Feb 2013 00:32:19 +0100
> Subject: [PATCH] kexec: disable hard IRQ before kexec
>
> Disable hard IRQ before kexec a new kernel image.
> Not doing it can result in corrupted data in the memory segments
> reserved for the new kernel.
> ---
> arch/powerpc/kernel/machine_kexec_64.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> b/arch/powerpc/kernel/machine_kexec_64.c
> index 7206701..e08b9d0 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -162,6 +162,7 @@ static int kexec_all_irq_disabled = 0;
> static void kexec_smp_down(void *arg)
> {
> local_irq_disable();
> + hard_irq_disable();
> mb(); /* make sure our irqs are disabled before we say they are */
> get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
> while(kexec_all_irq_disabled == 0)
> @@ -244,6 +245,7 @@ static void kexec_prepare_cpus(void)
> wake_offline_cpus();
> smp_call_function(kexec_smp_down, NULL, /* wait */0);
> local_irq_disable();
> + hard_irq_disable();
> mb(); /* make sure IRQs are disabled before we say they are */
> get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
>
> @@ -281,6 +283,7 @@ static void kexec_prepare_cpus(void)
> if (ppc_md.kexec_cpu_down)
> ppc_md.kexec_cpu_down(0, 0);
> local_irq_disable();
> + hard_irq_disable();
> }
>
> #endif /* SMP */
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-22 19:52 ` Benjamin Herrenschmidt
@ 2013-02-22 23:41 ` Phileas Fogg
2013-02-22 22:45 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 23+ messages in thread
From: Phileas Fogg @ 2013-02-22 23:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Fri, 2013-02-22 at 21:49 +0100, Phileas Fogg wrote:
>> i wanted to let you know that i tested your advice. And let me say, it's was a
>> damn good advice :) I can boot FreeBSD loader on Linux 3.8 now, no SHA256
>> checksum failures. And no panics with FreeBSD LiveCD anymore too.
>>
>> I just inserted hard_irq_disable() after each local_irq_disable() in
>> arch/powerpc/kernel/machine_kexec_64.c
>
> Awesome ! :-)
>
> Care to send a patch with a Signed-off-by: ?
>
> Cheers,
> Ben.
>
>
No problem, but as i said it was your idea how to fix the issue with kexec.
Anyways here is the patch which i tested on my PS3 console with Linux 3.8.
After applying this patch i can boot any Linux kernel starting with 2.6,
FreeBSD loader, FreeBSD LiveCD and my own tiny ELF kernels too.
Even OpenBSD bootloader starts now too :)
And i don't see any failed SHA256 checksums in the purgatory code.
regards
From c17cdf38dfe180b4a571827bb547aaf9b678cf29 Mon Sep 17 00:00:00 2001
From: Phileas Fogg <phileas-fogg@mail.ru>
Date: Sat, 23 Feb 2013 00:32:19 +0100
Subject: [PATCH] kexec: disable hard IRQ before kexec
Disable hard IRQ before kexec a new kernel image.
Not doing it can result in corrupted data in the memory segments
reserved for the new kernel.
---
arch/powerpc/kernel/machine_kexec_64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 7206701..e08b9d0 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -162,6 +162,7 @@ static int kexec_all_irq_disabled = 0;
static void kexec_smp_down(void *arg)
{
local_irq_disable();
+ hard_irq_disable();
mb(); /* make sure our irqs are disabled before we say they are */
get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
while(kexec_all_irq_disabled == 0)
@@ -244,6 +245,7 @@ static void kexec_prepare_cpus(void)
wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
local_irq_disable();
+ hard_irq_disable();
mb(); /* make sure IRQs are disabled before we say they are */
get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
@@ -281,6 +283,7 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
local_irq_disable();
+ hard_irq_disable();
}
#endif /* SMP */
--
1.8.1.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: PS3: Strange issue with kexec and FreeBSD loader
2013-02-22 22:45 ` Benjamin Herrenschmidt
@ 2013-02-22 23:53 ` Phileas Fogg
0 siblings, 0 replies; 23+ messages in thread
From: Phileas Fogg @ 2013-02-22 23:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Sat, 2013-02-23 at 00:41 +0100, Phileas Fogg wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Fri, 2013-02-22 at 21:49 +0100, Phileas Fogg wrote:
>>>> i wanted to let you know that i tested your advice. And let me say, it's was a
>>>> damn good advice :) I can boot FreeBSD loader on Linux 3.8 now, no SHA256
>>>> checksum failures. And no panics with FreeBSD LiveCD anymore too.
>>>>
>>>> I just inserted hard_irq_disable() after each local_irq_disable() in
>>>> arch/powerpc/kernel/machine_kexec_64.c
>>>
>>> Awesome ! :-)
>>>
>>> Care to send a patch with a Signed-off-by: ?
>>
>> No problem, but as i said it was your idea how to fix the issue with kexec.
>> Anyways here is the patch which i tested on my PS3 console with Linux 3.8.
>> After applying this patch i can boot any Linux kernel starting with 2.6,
>> FreeBSD loader, FreeBSD LiveCD and my own tiny ELF kernels too.
>> Even OpenBSD bootloader starts now too :)
>> And i don't see any failed SHA256 checksums in the purgatory code.
>
> Thanks, but I still need the Signed-off-by: line before i can apply
> it :-) (legal...)
>
> Cheers,
> Ben.
>
>> regards
>>
>> From c17cdf38dfe180b4a571827bb547aaf9b678cf29 Mon Sep 17 00:00:00 2001
>> From: Phileas Fogg <phileas-fogg@mail.ru>
>> Date: Sat, 23 Feb 2013 00:32:19 +0100
>> Subject: [PATCH] kexec: disable hard IRQ before kexec
>>
>> Disable hard IRQ before kexec a new kernel image.
>> Not doing it can result in corrupted data in the memory segments
>> reserved for the new kernel.
>> ---
>> arch/powerpc/kernel/machine_kexec_64.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
>> b/arch/powerpc/kernel/machine_kexec_64.c
>> index 7206701..e08b9d0 100644
>> --- a/arch/powerpc/kernel/machine_kexec_64.c
>> +++ b/arch/powerpc/kernel/machine_kexec_64.c
>> @@ -162,6 +162,7 @@ static int kexec_all_irq_disabled = 0;
>> static void kexec_smp_down(void *arg)
>> {
>> local_irq_disable();
>> + hard_irq_disable();
>> mb(); /* make sure our irqs are disabled before we say they are */
>> get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
>> while(kexec_all_irq_disabled == 0)
>> @@ -244,6 +245,7 @@ static void kexec_prepare_cpus(void)
>> wake_offline_cpus();
>> smp_call_function(kexec_smp_down, NULL, /* wait */0);
>> local_irq_disable();
>> + hard_irq_disable();
>> mb(); /* make sure IRQs are disabled before we say they are */
>> get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
>>
>> @@ -281,6 +283,7 @@ static void kexec_prepare_cpus(void)
>> if (ppc_md.kexec_cpu_down)
>> ppc_md.kexec_cpu_down(0, 0);
>> local_irq_disable();
>> + hard_irq_disable();
>> }
>>
>> #endif /* SMP */
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Next attempt.
Signed-off-by: Phileas Fogg <phileas-fogg@mail.ru>
---
From c17cdf38dfe180b4a571827bb547aaf9b678cf29 Mon Sep 17 00:00:00 2001
From: Phileas Fogg <phileas-fogg@mail.ru>
Date: Sat, 23 Feb 2013 00:32:19 +0100
Subject: [PATCH] kexec: disable hard IRQ before kexec
Disable hard IRQ before kexec a new kernel image.
Not doing it can result in corrupted data in the memory segments
reserved for the new kernel.
---
arch/powerpc/kernel/machine_kexec_64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 7206701..e08b9d0 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -162,6 +162,7 @@ static int kexec_all_irq_disabled = 0;
static void kexec_smp_down(void *arg)
{
local_irq_disable();
+ hard_irq_disable();
mb(); /* make sure our irqs are disabled before we say they are */
get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
while(kexec_all_irq_disabled == 0)
@@ -244,6 +245,7 @@ static void kexec_prepare_cpus(void)
wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
local_irq_disable();
+ hard_irq_disable();
mb(); /* make sure IRQs are disabled before we say they are */
get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
@@ -281,6 +283,7 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
local_irq_disable();
+ hard_irq_disable();
}
#endif /* SMP */
--
1.8.1.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-02-22 22:53 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-08 23:10 PS3: Strange issue with kexec and FreeBSD loader Phileas Fogg
2013-02-16 10:53 ` Phileas Fogg
2013-02-16 22:14 ` Phileas Fogg
2013-02-16 23:12 ` Phileas Fogg
2013-02-17 8:53 ` Geert Uytterhoeven
2013-02-17 12:40 ` Phileas Fogg
2013-02-21 0:14 ` Geoff Levand
2013-02-16 18:51 ` Phileas Fogg
2013-02-19 18:40 ` Phileas Fogg
2013-02-19 19:54 ` Phileas Fogg
2013-02-20 20:43 ` Phileas Fogg
2013-02-21 0:32 ` Benjamin Herrenschmidt
2013-02-21 20:38 ` Phileas Fogg
2013-02-21 20:35 ` Benjamin Herrenschmidt
2013-02-21 21:44 ` Phileas Fogg
2013-02-21 23:46 ` Benjamin Herrenschmidt
2013-02-22 20:49 ` Phileas Fogg
2013-02-22 19:52 ` Benjamin Herrenschmidt
2013-02-22 23:41 ` Phileas Fogg
2013-02-22 22:45 ` Benjamin Herrenschmidt
2013-02-22 23:53 ` Phileas Fogg
2013-02-21 22:06 ` Phileas Fogg
2013-02-21 23:47 ` Benjamin Herrenschmidt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.