> On Friday 13 February 2004 3:15 pm, Richard Earnshaw wrote:
> > Can anybody come up with some theories as to why ARM kernels might be
> > tripping the assertion in "umap->refcount != 0" in ubc_map.c when
> > bootstrapping gcc?  Although it's not predictable as to when it will
> > fail, it does seem to happen pretty much every time, and it's been
> > doing this on all kernels since late October last year.
> 
> This is also mentioned in your PR; port-arm/23581, for which I'm still 
> saving up enough round-tuits to investigate. ;)
> 
> Seriously, if this started happening around October '03, then that 
> corresponds to the optimised arm/xscale mem* and copyin/out functions 
> going in.
> 
> Since I haven't seen this problem on my Xscale machines, it's a fair bet 
> the non-xscale code in those functions is suspect. My only two 
> non-xscale machines are running kernels which predate those changes 
> (though one of them was used to test the changes at the time).
> 
> Cheers, Steve
> 

That's a possibility, but I have a feeling it was later than that (the 
bcopy changes went in during the first half of the month, but I think it 
was nearer the end of the month that the problems started occurring) --  I 
really need to try a binary chop to get a better window, but so many times 
the kernel just fails to build, or just fails to even boot that it's very 
tedious trying to distinguish one failure from another.

I think the problems also started occurring at around the same time there 
were a number of changes made "to fix the benchmark tests" that were being 
discussed at around that time -- it wouldn't surprise me if one of those 
tests was interacting badly on the ARM.

Finally, it's not precisely predictable when it would happen.  AFAICT if 
it were a bcopy problem it could only be responsible if it were scribbling 
somewhere it shouldn't instead of where it should.

R.