>>> Please confirm (or not) that 1.5.3 is "safe" with regard to sw
>>> flush cache problem on IPC, etc.
>> Yes, it is.

This does not match my experience (while admittedly I have not tried
1.5.3 specifically, see below).

>> Well, the bug could be there too, but we've never been able to make
>> it show up before UBC integration.

For what values of "we"?  I've been running 1.4T for years, and have
been experiencing random crashes of various long-running programs that
I've written off to bugs in them - notably the X server - but which I
believe were due to this problem.  Finally one day I tried to run a mud
on such hardware under 1.4T, and I never once got it to survive long
enough to start accepting connections.  I switched to a newer machine
and the problem vanished.

I have also had the bug strike other code.  I have a picture-display
program which uses the 3/3/2 TrueColor visual presented by the X server
on 8bpp PseudoColor hardware, dithering pictures for decent display.
Once, when running it on such hardware, I had a small number of pixels
totally garbaged as the dithering program was dithering while the OS
was paging - it looked like about one cache line of total garbage (or
for all I know possibly some other process's data).

I've also yet to have a "make build" complete without dying at least
once in the process on such hardware.

And this is all under 1.4T, a pre-UBC kernel.  The bug definitely is
there pre-UBC.  I even posted to port-sparc about it at the time; I'm
not sure how this turned into "we've never been able to make it show up
before UBC integration" - perhaps my reports didn't connect with the
bug in someone's mind at the time.

These days all my 1, 1+, and IPC machines are sitting on the shelf, so
it no longer bothers me.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B