VME Auto system controller ID issue

Good point Bill. Do you know how I can test/change VxWorks to confirm it is or isn't a RMW issue?

This is what I thought as well. I do recall at a previous employer we had similar issues with the same Tundra chip---and the workaround was extra crap that the BSP had to perform during initialization.... but I really don't want to go that route again if avoidable.

Thanks,

Bo

On Mon, 15 Jan 2007 10:54:28 -0600, Bo queried:

I wish I did; still don't have a good handle on how shared memory is _really_ implemented in spite of mucking with it on and off for a number of years. The point is that if the memory spaces weren't shared the transactions would succeed, otherwise Tundra wouldn't be able to sell chip one. I suspect your implementation is drawing out a latent defect in the implementation of shared memory; I'm aware of another who encountered a similar hang using a more standard configuration (but totally weird in other ways). That too is unresolved as far as I know.

Regards

... snip ...

I have no idea whether this is applicable to the OP's problem, but in general memory is shared as long as it is not written. If a process wants to write in it, the page table for that process is modified to remap that portion, a copy of the original made, and the write then proceeds. That portion of the memory is then no longer shared.

If the memory is truly shared, so that one processes writes show up in other processes memory space, then various synchronization protocols must be used. This can involves semaphores, monitors, critical sections, etc.

Threads are generally lightweight processeses, using memory shared with other threads in the same process, and will need the synchronization primitives to access it.

Yes the memory is truly shared. However, it is my understand that the RMW protection scheme across a VME backplane is implemented in hardware generally and that any HW that does not support RMW, the RMW protection scheme must be emulated by SW--resulting in a much slower transaction. In my particular case, it seems that the physical option jumper causes the HW to work/not work depending on its position-- which seems divorced from SW in my view. That is, if it was a SW issue, the problem would exist regardless of the HW jumper position.

I do find it odd that earlier board models (using the same TUndra chip) do not exhibit the problem.

Bo

ie it 'appears' to be an honest-to-God hardware lock-up--from which only a power cycle will recover. Scary, huh?

I don't think that TAS has been changed---at least not by me.

Thanks for the suggestions and help,

Bo

Indeed it's scary and smells of an errata, it appears that the system controller has left the scene. I would recommend getting Tundra to look at the issue. I'm sure they'll want a dump of the Universe and a trace if you've got the capability. You can initiate the dialog at

Regards