> So, something overwrites the 'lmb' datastructures in the kernel as we > pull in the device tree. > > The symbol 'lmb' sits shortly after p1275buf, which is where we store > arguments and return values for all prom calls. > > What you could do is annotate arch/sparc/kernel/prom_common.c, function > build_one_prop() with printouts of the value of lmb.memory.cnt > > A good spot would be around the prom_firstprop() and prom_nextprop() > invocations. Usually (no problematic card or adaptec scsi in place of problematic card) cnt=2. With problematic card in place, cnt=3 from beginning and for a lot of prom nodes and then, yes, the corruption occurs: build_one_prop before getproperty: cnt=3, node=f009908c, name='driver,aapl,macosx,powerpc', value=fffff8001fed6340, length=31931 build_one_prop after getproperty: len=31931, cnt=32a4ee00e101ada6 Will look at it again tomorrow, enough for now. Seems that the length on the resource itself might be the culprit? -- Meelis Roos (mroos@xxxxxxxx) -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
