From: Josip Rodin <joy@xxxxxxxxxxxxxx> Date: Thu, 25 Oct 2007 01:28:12 +0200 > On Wed, Oct 24, 2007 at 03:58:29PM -0700, David Miller wrote: > > Let's see if there is some aspect of the environment that > > contributed to the problem occurring. Please reproduce > > with 2.6.23-final and then list (I know this is redundant, > > just humor me :-): > > Confirming that the machine could reproduce the problem with 2.6.23.1. > (I can send over the .config if it matters.) Ok, good. > > 1) system type > > A Sun Fire 280R, with two CPU boards, each carrying a TI UltraSparc III > (Cheetah), and 2 GB of RAM. If you need more info, just say. > > (Bernd Zeimetz has previously suggested that the problem is linked to > the processor type, the USIII.) I think it might be too. > > 2) compiler used to build kernel and is it SMP? > > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > > I've no idea if that compiler is SMP, if you want I'll ask someone else. I was asking if the running kernel were SMP or not, I'll assume it is :-) > > 3) glibc in use > > 4) compiler used to build running glibc > > In that particular chroot, it's: Thanks for the info. > > If you have a reproducable test case, that's even better. > > There doesn't appear to be a pattern, on this machine at least - I just let > the buildd run, building whatever comes up, and after a few hours it > inevitably runs into a wall. If you try, within that troublesome build-root, a few times to try to fork off a couple hundred: dpkg-query --something python-2.5 or whatever, can you get some of processes to wedge under that build root? If it only happens with UltraSPARC-III and IIIi chips, that is a huge clue. It turns out I have a 280R here as well, so if necessary I can fire it up and work on reproducing your environment. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
