Messages in this thread | | | Date | Tue, 17 Aug 2010 14:44:20 -0700 (PDT) | Subject | Re: tasks getting stuck on mmap_sem? | From | David Miller <> |
| |
From: Tony Luck <tony.luck@intel.com> Date: Tue, 17 Aug 2010 11:24:19 -0700
> On Tue, Aug 17, 2010 at 9:14 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> No. Looks like the rwsem changes broke sparc too. ia64 had some problems too. > > I did have some similar mmap_sem issues - but the combination of > fixing the types > of the RWSEM_* defines to be unsigned, and the return value of > ia64_atomic64_add() > to be "long" rather than "int" looks to have cleared up the problems I > was seeing. I > could generally see the hung processes in less than 10 consecutive > kernel builds, but > ran a few thousand builds over the weekend with no issues.
You might be triggering it via threading as well, since make uses vfork() for running sub-jobs.
> If git is multi-threaded, it may be hitting some different code path > ... but it isn't trivial > for me to try this out (my systems are on an isolated lab network segment).
Like you I tried fixing atomic64, but as I mentioned it turns out sparc64 (like powerpc) always uses a 32-bit 'int' semaphore count.
I thought perhaps that for some reason the rwsem generic code had a dependency on 'long' so I switched sparc64's rwsems over to 'long' counters last night too, but I still get the problem.
Even reverting the rwsem commit that added the "<" test didn't fix things, so now I'm simply going to bisect.
| |