I feel like I ought to help out with this since it's my change which
broke things, but I don't have access to a Sparc32 box. Does anyone
have a remotely rebootable machine I can use?
Ollie
sun4c Sparc32 are probably a bit thin on the ground. Im my experience,
they also have a habit of locking up (power up reset required) when
debugging kernel issues.
However, I think I am getting somewhere.
The problem would apear to be that sun4c_update_mmu_cache is beeing called
(either directly from the fault handling code or via update_mmu_cache)
before the mm->context has been set up. The only place I found that sets
this is sun4c_switch_mm (called from the scheduler as switch_mm).
In other words, the vma system is not operational untill after the task
gets scheduled.
There may be a way around this - by calling sun4c_alloc_context when the
mm gets set up. I will give it a go and see what happens.
David, are there any issues that you are aware of in calling
sun4c_alloc_context without switching to it?
Regards
Mark Fortescue.
-
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
