On Fri, May 28, 2010 at 9:53 PM, Artyom Tarasenko <atar4q...@googlemail.com> wrote: >> 32m: 0x12fff394 >> 64m: 0x14fff394 >> 192m:0x1cfff394 >> 256m:0x20fff394 >> >> Memory probing? It would be strange that OS would do it itself. The OS >> could just >> ask OBP how much does it have. Here is the listing where it happens: >> >> _swift_vac_rgnflush: rd %psr, %g2 >> _swift_vac_rgnflush+4: andn %g2, 0x20, %g5 >> _swift_vac_rgnflush+8: mov %g5, %psr >> _swift_vac_rgnflush+0xc: nop >> _swift_vac_rgnflush+0x10: nop >> _swift_vac_rgnflush+0x14: mov 0x100, %g5 >> _swift_vac_rgnflush+0x18: lda [%g5] 0x4, %g5 >> _swift_vac_rgnflush+0x1c: sll %o2, 0x2, %g1 >> _swift_vac_rgnflush+0x20: sll %g5, 0x4, %g5 >> _swift_vac_rgnflush+0x24: add %g5, %g1, %g5 >> _swift_vac_rgnflush+0x28: lda [%g5] 0x20, %g5 >> >> _swift_vac_rgnflush+0x28: is the fatal one. >> >> kadb> $c >> _swift_vac_rgnflush(?) >> _vac_rgnflush() + 4 >> _hat_setup_kas(0xc00,0xf0447000,0x43a000,0x400,0xf043a000,0x3c0) + 70 >> _startup(0xfe000000,0x10000000,0xfa000000,0xf00e2bfc,0x10,0xdbc00) + 1414 >> _main(0xf00e0fb4,0xf0007810,0x293ff49f,0xa805209c,0x200,0xf00d1d18) + 14 >> >> Unfortunately (but not surprisingly) kadb doesn't allow debugging >> cache-flush code, so I can't check what is in >> [%g5] (aka sfar) on the real machine when this happens. > > I was telling fairy tales here and no one stopped me. [%g5] is not > sfar, it's the context pointer, > so the code makes much more sense! > > And I guess, SunOS 4.1.4 is buggy. I've managed to reproduce the > complete case on the real machine. The trick is to set the breakpoint > before the interrupts are switched off: > > kadb> _swift_vac_rgnflush:b > kadb> :c > breakpoint _swift_vac_rgnflush: rd %psr, %g2 > kadb> <o2=X > 44000e5 > kadb> $q > Type 'go' to resume > Type help for more information > ok 100 4 spacel@ . > 3fff00 > > So at _swift_vac_rgnflush+0x28 it would access (44000e5<<2) + (3fff00 > << 4) = 14fff394. Which is outside of IOMMU. > > ok 14fff394 20 spacel@ . > 3fe000 > > This seems to be an alias to > > ok 14000004 20 spacel@ . > 3fe000 > > So, it seems to be safe to pad iommu with an empty slot. I guess we > are not missing anything more serious. Alternatively we can use your > aliasing patch. > > What do you say?
Thanks, applied. > P.S. What is also interesting about SunOS 4.1.4 is that only the > single-cpu kernel (which is used during the installation) calls > _swift_vac_rgnflush on initialization. The smp kernel just doesn't > have this call in _hat_setup_kas. Maybe they have noticed the bug and > corrected it? > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/ >
