And another note. I took a look at the MMU chapter in the Cell Architecture handbook and indeed the first 15 bits in VA are treated as 0 by the hardware.
Quote: 1. High-order bits above 65 bits in the 80-bit virtual address (VA[0:14]) are not implemented. The hardware always treats these bits as `0'. Software must not set these bits to any other value than `0' or the results are undefined in the PPE. regards Воскресенье, 10 февраля 2013, 12:59 +04:00 от Phileas Fogg <phileas-f...@mail.ru>: >Hi, > >i found where the problem lies. >I also printed some values in ps3_hpte_insert with and without 64TB support, i >used OpenWRT with Linux 3.7.6 for testing. > >Some values without 64TB support: >------------------------------------------------- > >[ 0.060487] RPC: Registered named UNIX socket transport module. >[ 0.060511] RPC: Registered udp transport module. >[ 0.060672] RPC: Registered tcp transport module. >[ 0.060873] RPC: Registered tcp NFSv4.1 backchannel transport module. >[ 0.061080] initcall .init_sunrpc+0x0/0xbc returned 0 after 784 usecs >[ 0.061280] calling .populate_rootfs+0x0/0x120 @ 1 >[ 0.061683] ps3_hpte_insert:result=0 vpn=f09b89af50101 pa=d4e0000 ix=dfa0 >v=f09b89af5001 r=6c005d4e0194 psize=0 ssize=0 lpar=6c005d4e0000 >[ 0.061733] ps3_hpte_insert:result=0 vpn=f09b89af50102 pa=d4e1000 ix=dfb8 >v=f09b89af5001 r=6c005d4e1194 psize=0 ssize=0 lpar=6c005d4e1000 >[ 0.061895] ps3_hpte_insert:result=0 vpn=f09b89af50103 pa=d4e2000 ix=dfb0 >v=f09b89af5001 r=6c005d4e2194 psize=0 ssize=0 lpar=6c005d4e2000 > > >Some values with 64TB support: >------------------------------------------------- > >[ 0.076477] calling .init_sunrpc+0x0/0xbc @ 1 >[ 0.076992] RPC: Registered named UNIX socket transport module. >[ 0.077017] RPC: Registered udp transport module. >[ 0.077076] RPC: Registered tcp transport module. >[ 0.077277] RPC: Registered tcp NFSv4.1 backchannel transport module. >[ 0.077484] initcall .init_sunrpc+0x0/0xbc returned 0 after 784 usecs >[ 0.077684] calling .populate_rootfs+0x0/0x120 @ 1 >[ 0.078126] ps3_hpte_insert:result=-17 vpn=25008684d80101 pa=d567000 >ix=2ec8 v=25008684d8001 r=6c005d567194 psize=0 ssize=0 lpar=6c005d567000 >[ 0.078164] ps3_hpte_insert:result=-17 vpn=25008684d80101 pa=d567000 >ix=2ec8 v=25008684d8001 r=6c005d567194 psize=0 ssize=0 lpar=6c005d567000 >[ 0.078287] ------------[ cut here ]------------ >[ 0.078482] Kernel BUG at c00000000002cb3c [verbose debug info unavailable] >[ 0.078686] Oops: Exception in kernel mode, sig: 5 [#1] >[ 0.078883] SMP NR_CPUS=2 PS3 >[ 0.079084] Modules linked in: >[ 0.079287] NIP: c00000000002cb3c LR: c00000000002cb38 CTR: 00000000002ffc38 >[ 0.079489] REGS: c00000000d04f0e0 TRAP: 0700 Not tainted (3.7.6) >[ 0.079687] MSR: 8000000000020032 <SF,IR,DR,RI> CR: 22000022 XER: 00000000 >[ 0.079888] SOFTE: 0 >[ 0.080090] TASK = c00000000d049060[1] 'swapper/1' THREAD: c00000000d04c000 >CPU: 1 >GPR00: c00000000002cb38 c00000000d04f360 c0000000012ec8d0 0000000000000081 >GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >GPR08: 0000000000000000 c00000000124ce10 0000000000000000 c00000000002bcf0 >GPR12: 0000000022000022 c000000007ffe280 c000000000008c94 c0000000005cba00 > > > >And now take a look at 'v' values in both cases. > >Without 64TB support: v=f09b89af5001 >With 64TB support: v=25008684d8001 > >Number of leading zeros in f09b89af5001 is 16. >Number of leading zeros in 25008684d8001 is 14. > >And that's why lv1_insert_htab_entry fails with -17 which means >LV1_ILLEGAL_PARAMETER_VALUE because >the Hypervisor of PS3 checks 'AVPN' values for number of leading zeros and >allows at least 15 bits which in case >of 'v' value 25008684d8001 is too small of course. > >Not sure how to fix it in current Linux kernel. You guys know it better than >me. > >Regards > > > > >Понедельник, 14 января 2013, 15:37 -08:00 от Geoff Levand < >ge...@infradead.org >: >>Hi, >> >>On Fri, 2013-01-11 at 18:12 -0800, Geoff Levand wrote: >>> I checked these, and Michael's 407821a34fce89b4f0b031dbab5cec7d059f46bc >>> does indeed cause the LV1 hypervisor to panic early, and if that is >>> reverted, Aneesh's 048ee0993ec8360abb0b51bdf8f8721e9ed62ec4 hits a BUG. >> >>Just to give an update, I did a little more work on it and found that >>the call to lv1_insert_htab_entry() inside ps3_hpte_insert() is >>failing. >> >> >>http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux.git;a=blob;f=arch/powerpc/platforms/ps3/htab.c;hb=HEAD#l70 >> >>The values of the variables printed all look strange compared with >>commit 048ee0993 reverted. I'll try do some more work on it this >>week. >> >>-Geoff >> >> >> >> >> >>_______________________________________________ >>Linuxppc-dev mailing list >>Linuxppc-dev@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/linuxppc-dev > >_______________________________________________ >Linuxppc-dev mailing list >Linuxppc-dev@lists.ozlabs.org >https://lists.ozlabs.org/listinfo/linuxppc-dev
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
