On Mon, 2008-08-04 at 17:48 +0200, Geert Uytterhoeven wrote: > On PS3, recent kernels lock up in the very early stage (i.e. before mere > mortals get to see a working console). The kernel crashes with > > | kernel BUG at linux/arch/powerpc/platforms/ps3/htab.c:141! > > Bisecting shows this happens since: > > | commit a1f242ff460e4b50a045fa237c3c56cce9eabf83 > | Author: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > | Date: Wed Jul 23 21:27:08 2008 -0700 > | > | powerpc ioremap_prot > | > | This adds ioremap_prot and pte_pgprot() so that one can extract > protection > | bits from a PTE and use them to ioremap_prot() (in order to support > ptrace > | of VM_IO | VM_PFNMAP as per Rik's patch). > | > | This moves a couple of flag checks around in the ioremap implementations > | of arch/powerpc. There's a side effect of allowing non-cacheable and > | non-guarded mappings on ppc32 which before would always have > _PAGE_GUARDED > | set whenever _PAGE_NO_CACHE is. > | > | (standard ioremap will still set _PAGE_GUARDED, but ioremap_prot will be > | capable of setting such a non guarded mapping). > > Inside ps3_hpte_insert(), lv1_write_htab_entry() fails with error code 5 > (LV1_ACCESS_VIOLATION) when adding the PS3 hotplug memory. > > debug_dump_hpte() prints for the offending hpte: > > | pa = 500001000000h > | lpar = 500001000000h > | va = adc7d4c2d0000000h > | group = 6168h > | bitmap = 0h > | hpte.v = adc7d4c2d011h > | hpte.r = 500001000115h > ^ > | psize = 0h > | slot = 6168h > > After manually reverting the offending commit, the system boots again. The > only > change is: > > | pa = 500001000000h > | lpar = 500001000000h > | va = adc7d4c2d0000000h > | group = 6168h > | bitmap = 0h > | hpte.v = adc7d4c2d011h > | hpte.r = 500001000117h > ^ > | psize = 0h > | slot = 6168h > > Note that when adding the initial (non-hotplug) memory, hpte.r always ends in > `194', both before and after reverting the offending commit. > > ps3_hpte_insert() seems to be called during system initialization with the > following values of rflags: > - first call: 0x190 > - initial memory: 0x194 (455 times) > - hotplug memory: > o crash: 0x115 > o OK: 0x117 > > Do you have an idea of what's really going on?
Weird... Both look incorrect. In fact, it's a bit scary... The one with the 7 at the end means that user space as RO access to the segment (oops !) and supervisor too. The one with the 5 means RO for user and RW for supervisor. That is unless your HV is munging them in strange ways... I don't know why LV1 is refusing a combination though. As for the flags, it depends what htab_bolt_mapping() is called with. Do you have a backtrace ? I'm a bit lots in the mem hotswap code trying to figure out where the mapping comes from.. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
