PS3: Strange issue with kexec and FreeBSD loader

linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed

* 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-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-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-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-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-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  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: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 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 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 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 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-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 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 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

* 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 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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).