Subject: Re: Kernel assertion failures while bootstrapping gcc
To: Steve Woodford <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 02/13/2004 16:28:51
> 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.