Skip site navigation (1)Skip section navigation (2)
Date:      31 Dec 2008 15:11:39 +0100
From:      "Arno J. Klaassen" <arno@heho.snv.jussieu.fr>
To:        Roman Divacky <rdivacky@freebsd.org>
Cc:        emulation@freebsd.org
Subject:   Re: 8-current: linux_dist-gentoo-stage3 wonn't bootstrap
Message-ID:  <wphc4kxwmc.fsf@heho.snv.jussieu.fr>
In-Reply-To: <wpk59j48jf.fsf_-_@heho.snv.jussieu.fr>
References:  <wp3ag9s5hy.fsf@heho.snv.jussieu.fr> <20081227220645.GA13295@freebsd.org> <wpmyeg2yjg.fsf@heho.snv.jussieu.fr> <20081228175745.GA56640@freebsd.org> <wpmyegdr0v.fsf@heho.snv.jussieu.fr> <20081228202526.GA74948@freebsd.org> <wpy6y0f32m.fsf@heho.snv.jussieu.fr> <20081228211505.GA80323@freebsd.org> <wpocyw9dt7.fsf@heho.snv.jussieu.fr> <20081228214438.GA83007@freebsd.org> <wpk59j48jf.fsf_-_@heho.snv.jussieu.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
"Arno J. Klaassen" <arno@heho.snv.jussieu.fr> writes:

> [NB, subject changed; this bug is produce now on -current ]
> 
> Roman Divacky <rdivacky@freebsd.org> writes:
> 
> > On Sun, Dec 28, 2008 at 10:42:44PM +0100, Arno J. Klaassen wrote:
> > > Roman Divacky <rdivacky@freebsd.org> writes:
> > > 
> > > > On Sun, Dec 28, 2008 at 09:38:09PM +0100, Arno J. Klaassen wrote:
> > > > > 
> > > > > Roman Divacky <rdivacky@freebsd.org> writes:
> > > > > 
> > > > > > > > 
> > > > > > > > does this patch fix the hang? 
> > > > > > > > 
> > > > > > > > www.vlakno.cz/~rdivacky/linprocfs.patch
> > > > > > > 
> > > > > > > nope, though it does fix the lock order reversal 
> > > > > > > (I attach the slightly modified patch for linprocfs.c to
> > > > > > > make it compile)
> > > > > >  
> > > > > > the LOR is probably harmless.... dont bother with that patch :)
> > > > > > 
> > > > > > > funny enough, it again hangs in compiling gconv_simple.c 
> > > > > > > with cc1 in pipewr state and no assembler showing up in
> > > > > > > ps(1) after having succesfully compiled a bunch of other
> > > > > > > files.
> > > > > > 
> > > > > > you mean native cc1? or linux one?
> > > > > 
> > > > > linux :
> > > > > 
> > > > > # ps axuww | fgrep 1129
> > > > > root       11290  0.0  0.1  2296  1432   0  D     8:29PM   0:00.01 [i486-pc-linux-gnu-g]
> > > > > root       11291  0.0  0.8 18152 16808   0  I     8:29PM   0:00.96 [cc1]
> > > > > 
> > > > > and no trace of gconv_simple.o
> > > > > 
> > > > > last line of log-file is :
> > > > > 
> > > > > i486-pc-linux-gnu-gcc gconv_simple.c -c -std=gnu99  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2     -I../include -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv -I/var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdep!
 s/!
>  unix!
> > >   -I.!
> > > > >  ./sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include -isystem /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h        -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o
> > > > > 
> > > > > 
> > > > > ++, Arno
> > > > >  
> > > > 
> > > > can you break into DDB and extract a backtrace of the stuck process?
> > > 
> > > OK, I'll hook up a serconsole tomorrow ..
> > > 
> > > for now some good old quick n dirty copy paste by pen and paper :
> > > 
> > >  11290 (i486-pc-linux-gnu-gcc]
> > > 
> > >   sched_switch
> > >   mi_switch
> > >   sleepq_switch
> > >   sleepq_wait
> > >   _sleep
> > >   linux_vfork
> > >   ia32_syscall
> > >   Xint0x80_syscall
> > >    syscall (190, Linux ELF32, linux_vfork)
> > > 
> > > 
> > >  11291 (cc1)
> > > 
> > >   sched_switch
> > >   mi_switch
> > >   sleepq_switch
> > >   sleepq_catch_signals
> > >   sleepq_wait_sig
> > >   _sleep
> > >   pipe_write
> > >   dofilewrite
> > >   kern_writev
> > >   write
> > >   ia32_syscall
> > >   Xint80_syscall
> > >     syscall (4, Linux ELF32, write)
> > 
> > I dont see anything obvious.. can you do "ps axl" and see what the MWCHAN is?
> > that might shed some light to this...
> 
> bon, in fact when I launce the command by hand adding a '-v ' to gcc, output
> says :
> 
> /usr/libexec/gcc/i486-pc-linux-gnu/4.1.2/cc1 ... | /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/../../../../i486-pc-linux-gnu/bin/as -V -Qy -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o -
> 
> 
> but, cc1 is stuck in 'pipewr' and no .../bin/as process is running (any longer)
> nor the file .../gconv_simple.o created 

I investigated this a bit more (still chrooted to /usr/local/gentoo-stage3) :

  i486-pc-linux-gnu-gcc gconv_open.c -c                 : OK
  i486-pc-linux-gnu-gcc gconv_open.c -c -pipe           : OK

  i486-pc-linux-gnu-gcc gconv_simple.c -c               : OK
  i486-pc-linux-gnu-gcc gconv_simple.c -c -pipe         : pipe to as(1) fails

I tried to play with kern.ipc.maxpipekva (I vaguely remember that
was necessary for linux testsuites) pumping it up to "536608768", but
no difference. If someone has another suggestion?

Thanx, Arno




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wphc4kxwmc.fsf>