> 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?
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/
