Message ID | 512685B7.5080404@mail.ru (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
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.
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
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 ?
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.
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.
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.
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
--- 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......|