who building sucessed zhcon under current
I wanna to buid it ,but always get failed. thanks any information. best regards === Building for zh-zhcon-0.2_4 gmake all-recursive gmake[1]: Entering directory `/usr/ports/chinese/zhcon/work/zhcon-0.2' Making all in src gmake[2]: Entering directory `/usr/ports/chinese/zhcon/work/zhcon-0.2/src' Making all in display gmake[3]: Entering directory `/usr/ports/chinese/zhcon/work/zhcon-0.2/src/displa y' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/ports/chinese/zhcon/work/zhcon-0.2/src/display ' gmake[3]: Entering directory `/usr/ports/chinese/zhcon/work/zhcon-0.2/src' c++ -O2 -DNDEBUG -funsigned-char -Wall -Wl,-rpath=/usr/lib/unicon -o zhcon -L /usr/lib/unicon basefont.o big52gbdecoder.o big5decoder.o configfile.o console. o gb2big5decoder.o gbdecoder.o gbkdecoder.o graphdev.o hzdecoder.o jisdecoder.o kscmdecoder.o main.o window.o winime.o zhcon.o overspotclient.o nativeinputserve r.o inputclient.o inputmanager.o inputserver.o candilist.o uniconinputserver.o c onfigserver.o nativebarclient.o display/libdisplay.a -lutil -lc -lintl -L/usr/l ib/unicon -L/usr/local/lib overspotclient.o: In function `OverSpotClient::Update()': overspotclient.o(.text+0x536): undefined reference to `InputServer::IsFullChar() ' overspotclient.o(.text+0x57e): undefined reference to `InputServer::IsFullComma( )' overspotclient.o: In function `OverSpotClient::AdjustWinPos(int, int, int, int)' : overspotclient.o(.text+0xa74): undefined reference to `Window::ColsOvered()' overspotclient.o(.text+0xa7e): undefined reference to `Window::RowsOvered()' inputmanager.o: In function `InputManager::ProcessInputKey(char)': inputmanager.o(.text+0xbf9): undefined reference to `InputServer::IsFullChar()' inputmanager.o(.text+0xc30): undefined reference to `InputServer::IsFullComma()' nativebarclient.o: In function `NativeBarClient::Update()': nativebarclient.o(.text+0x6fb): undefined reference to `InputServer::IsFullChar( )' nativebarclient.o(.text+0x73e): undefined reference to `InputServer::IsFullComma ()' gmake[3]: *** [zhcon] Error 1 gmake[3]: Leaving directory `/usr/ports/chinese/zhcon/work/zhcon-0.2/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/chinese/zhcon/work/zhcon-0.2/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/chinese/zhcon/work/zhcon-0.2' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/chinese/zhcon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: imake-4 build broken
On Thu, Oct 10, 2002 at 08:03:00PM -0400, Mike Barcroft [EMAIL PROTECTED] wrote: imake-4 port building is broken. I guess that's because xc/config/makedepend/main.c defines _POSIX_SOURCE before including signal.h. Signal.h includes sys/signal.h which has conditional #if !defined(_POSIX_SOURCE) and NSIG will be left undefined. Don't know who is in fault here, imake sources or our headers, my knowledge happens to end there. I don't really understand how this is happening. The uses of NSIG are also conditionalized. If _POSIX_SOURCE is defined, line 46 should not be visible. What rev is your /usr/include/sys/cdefs.h and /usr/include/signal.h? /usr/include/sys/cdefs.h: $FreeBSD: src/sys/sys/cdefs.h,v 1.67 2002/10/07 02:50:44 mike Exp $ $FreeBSD: src/sys/sys/cdefs.h,v 1.67 2002/10/07 02:50:44 mike Exp $ /usr/include/signal.h: $FreeBSD: src/include/signal.h,v 1.19 2002/10/06 21:54:08 mike Exp $ The same error happens several times down the road of XFree86-4 port compilation and all the problematic source files contain #include signal.h surrounded by _POSIX_SOURCE. Removing this _POSIX_SOURCE thing got the XFree86-4 port compile to me. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Again: panic kmem_malloc()
At 00:23 11/10/2002, Terry Lambert wrote: Robert Watson wrote: I've run into this on a couple of boxes, but those boxes were diskless root boxes, and used md backed ffs for /tmp and /var. Apparently if you do that, you're likely to exceed the kernel's auto-tuned kmem map size. That said, they didn't do it as frequently, so perhaps there's been a chance. A glance at the malloc buckets on the machine suggested that this wasn't a memory leak (the normal candidate in this sort of scenario). Use of swapping on additional space not known to the kernel at boot time, will also cause this; That's not happening on my box. It has 64 MB real memory, 128 MB swap area mounted like this: /dev/da0s1b noneswapsw 0 0 pstat -s says: Device 1K-blocks UsedAvail Capacity Type /dev/da0s1b13107210244 120828 8%Interleaved Is there a way to check the free list of the kernel? Maybe I can find out what action triggers eating al its memory. Ben To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
** HEADS UP ** DON'T MAKE WORLD !!!
I've ended up hosing world with the Binutils upgrade. It is best you don't try to install a world right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- === gnu/lib/csu Assembler messages: FATAL: can't create crtbegin.o: Invalid bfd target *** Error code 2 Stop in /h/des/src/gnu/lib/csu. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: who building sucessed zhcon under current
The port is broken, talk to the authors of this software about fixing it to work with gcc 3.2. Kris msg44536/pgp0.pgp Description: PGP signature
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
Thanks for the warning! M I've ended up hosing world with the Binutils upgrade. It is best you don't try to install a world right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
On Fri, Oct 11, 2002 at 02:42:34AM -0700, David O'Brien wrote: On Fri, Oct 11, 2002 at 01:04:23AM -0700, David O'Brien wrote: I've ended up hosing world with the Binutils upgrade. I think world is OK now. Looks as if something is (still?) broken: stage 4: building everything.. ... === gnu/usr.bin/binutils/gdb ... cc -O -pipe -mcpu=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include -Dprint_insn_i386=print_insn_i386_att -DDEFAULT_BFD_VEC=bfd_elf32_i386_vec -DGDB_XM_FILE -Dprint_insn_i386=print_insn_i386_att -DDEFAULT_BFD_VEC=bfd_elf32_i386_vec -DGDB_XM_FILE -DDEFAULT_BFD_ARCH=bfd_i386_arch -I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/obj/usr/src/i386/usr/include/readline -static -o gdb init.o annotate.o ax-general.o ax-gdb.o bcache.o blockframe.o breakpoint.o buildsym.o c-exp.o c-lang.o c-typeprint.o c-valprint.o ch-exp.o ch-lang.o ch-typeprint.o ch-valprint.o coffread.o complaints.o copying.o corefile.o corelow.o cp-valprint.o dcache.o dbxread.o demangle.o dwarfread.o dwarf2read.o elfread.o environ.o eval.o exec.o expprint.o f-exp.o f-lang.of-typeprint.o f-valprint.o findvar.o fork-child.o gdbarch.o gdbtypes.o infcmd.o inflow.o infptrace.o infrun.o inftarg.o language.o jv-exp.o jv-lang.o jv-valprint.o jv-typeprint.o nlmread.o m2-lang.o m2-exp.o m2-typeprint.o m2-valprint.o main.o maint.o mdebugread.o mem-break.o minsyms.o objfiles.o parse.o printcmd.o remote.o remote-utils.o scm-exp.o scm-lang.o scm-valprint.o solib.o source.o stabsread.o stack.o symfile.o symmisc.o symtab.o target.o thread.o top.o tracepoint.o typeprint.o utils.o valarith.o valops.o valprint.o values.o serial.o ser-unix.o ser-tcp.o arch-utils.o cp-abi.o completer.o doublest.o event-loop.o event-top.o frame.o gdb-events.o inf-loop.o linespec.o memattr.o regcache.o signals.o solib-svr4.o solib-legacy.o ui-file.o ui-out.o wrapper.o cli-out.o cli-cmds.o cli-decode.o cli-script.o cli-setshow.o cli-utils.o freebsd-uthread.o kvm-fbsd.o i386fbsd-nat.o i386bsd-tdep.o i386bsd-nat.o i386-nat.o i386-tdep.o i387-nat.o i387-tdep.o core-regset.o core-aout.o gdbversion.o -lkvm -lm ../libbfd/libbfd.a ../libopcodes/libopcodes.a -lgnuregex ../libiberty/libiberty.a -lreadline -ltermcap arch-utils.o(.data+0x40): undefined reference to `bfd_elf32_i386_vec' *** Error code 1 1 error What next? Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
hmm. I just up'd three -CURRENT machines from 22 Sept to 10 Oct. buildworld; cd sys/i386/conf config blah, etc; reboot; installworld. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- === gnu/usr.bin/binutils/libbfd In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h: In function `elf_slurp_reloc_table_from_section': /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1398: warning: implicit declaration of function `bfd_get_dynamic_symcount' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_add_default_symbol': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: too few arguments to function /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: At top level: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:2497: conflicting types for `elf_link_record_local_dynamic_symbol' /tinderbox/sparc64/src/contrib/binutils/bfd/elf-bfd.h:1564: previous declaration of `elf_link_record_local_dynamic_symbol' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_fix_symbol_flags': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_link_input_bfd': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:6911: warning: assignment from incompatible pointer type In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_gc_sections': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:7865: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_reloc_symbol_deleted_p': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8182: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `bfd_elf32_discard_info': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8312: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8322: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8327: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8328: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8331: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8333: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8388: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8389: structure has no member named `locsym_shndx' *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- === gnu/usr.bin/binutils/libbfd In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h: In function `elf_slurp_reloc_table_from_section': /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1398: warning: implicit declaration of function `bfd_get_dynamic_symcount' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_add_default_symbol': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1069: too few arguments to function /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:1136: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: At top level: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:2497: conflicting types for `elf_link_record_local_dynamic_symbol' /tinderbox/sparc64/src/contrib/binutils/bfd/elf-bfd.h:1564: previous declaration of `elf_link_record_local_dynamic_symbol' In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_fix_symbol_flags': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: warning: passing arg 1 of pointer to function from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:3952: too few arguments to function In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `elf_link_input_bfd': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:6911: warning: assignment from incompatible pointer type In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elfcode.h:1659, from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_gc_sections': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:7865: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `_bfd_elf32_reloc_symbol_deleted_p': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8182: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h: In function `bfd_elf32_discard_info': /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8312: warning: assignment from incompatible pointer type /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8322: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8327: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8328: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8331: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8333: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8388: structure has no member named `locsym_shndx' /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8389: structure has no member named `locsym_shndx' *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP: GCC 3.2.1 update is coming
David O'Brien [EMAIL PROTECTED] writes: On Thu, Oct 10, 2002 at 08:38:58PM -0400, Alexander Kabaev wrote: Could you please try to compile libmsun with with GCC 3.3 snapshot David just committed and see if that changes anything? It doesn't compile on -current. Mike and the standards guys are suspose to undo the breakage that crept into out headers. For the daring, try to build the port and then change the two u_long that is complained about to unsigned long. I've committed this for now. The `#ifndef _POSIX_SOURCE' conditional needs to check for other standards, but I'll leave this until I have a chance to go through the entire header to make it conformant. This is a new problem because of rev 1.74 of sys/types.h where a conditional was updated to check for other standards, but had some dependencies that I wasn't aware of and world didn't find them for me. If there are any others I should find them as I go through each standard header. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xmms compilation failure
Hi xmms fails to compile because of either: missing sys/types.h include in xmms-1.2.7/libxmms/util.c some error in our headers Simply adding sys/types.h before sys/sysctl.h works for me. rm -f .libs/util.lo cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include/gtk12 -I/usr/local/include/glib12 -D_THREAD_SAFE -I/usr/local/include -I/usr/X11R6/include -I../intl -I/usr/local/include -O -pipe -march=pentiumpro -Wall -Wpointer-arith -finline-functions -ffast-math -fomit-frame-pointer -Wall -Wpointer-arith -c util.c -fPIC -DPIC -o .libs/util.lo In file included from util.c:14: /usr/include/sys/sysctl.h:604: syntax error before u_int /usr/include/sys/sysctl.h:605: syntax error before size_t /usr/include/sys/sysctl.h:606: syntax error before size_t gmake[2]: *** [util.lo] Error 1 gmake[2]: Leaving directory `/usr/local/src/portbuild/usr/ports/audio/xmms/work/xmms-1.2.7/libxmms' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/portbuild/usr/ports/audio/xmms/work/xmms-1.2.7' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/audio/xmms. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
On Fri, Oct 11, 2002 at 07:37:53AM -0700, David Wolfskill wrote: On Fri, Oct 11, 2002 at 02:42:34AM -0700, David O'Brien wrote: On Fri, Oct 11, 2002 at 01:04:23AM -0700, David O'Brien wrote: I've ended up hosing world with the Binutils upgrade. I think world is OK now. Looks as if something is (still?) broken: Worked around. Very sorry for the breakage.. it was almost 4am and I thought I had gotten the world building fine. Several things conspired against the import this time... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Fri, Oct 11, 2002 at 01:25:29PM +, Mike Barcroft wrote: -- === gnu/usr.bin/binutils/libbfd In file included from /tinderbox/sparc64/src/contrib/binutils/bfd/elf32.c:22: ... /tinderbox/sparc64/src/contrib/binutils/bfd/elflink.h:8389: structure has no member named `locsym_shndx' *** Error code 1 ?? -- elf make world completed on Fri Oct 11 03:56:01 PDT 2002 (started Fri Oct 11 00:47:38 PDT 2002) -- blade100# To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP: GCC 3.2.1 update is coming
On Thu, 10 Oct 2002, Kris Kennaway wrote: On Thu, Oct 10, 2002 at 10:32:15PM -0700, David O'Brien wrote: On Thu, Oct 10, 2002 at 08:47:15PM -0700, Kris Kennaway wrote: Are these suitable for importing as a regression suite? We could just import the GCC testsuite... it would add 25 MB (checked out, more w/in /home/ncvs/src :-( ) Hmm, perhaps this should go in a new cvsup collection or somewhere else optional-but-accessible. Kris Errm, ports(7) umm portmgr. Ok, nothing to add here. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT running really slow under vmware2
define the 386' cpu type. it will make it not use some instructins that are not in the original 386. these instructions are also emulated VERY SLOWLY by vmware so not using them speeds up things.. On Fri, 11 Oct 2002, Jim Pirzyk wrote: Does anyone have experience running a recient -CURRENT as a vmware2 guest OS? I have tried -DP1 and a version from this week and both just die a slow death. I first tried to install a 4.6.2-RELEASE, and that worked. Then I tried to upgrade the system to -CURRENT via a make world (mergemaster, etc). and the 'make installworld' has not finished after 24 hours. The load goes up to ~ 5 during the install. I have tried this in multi user mode as well as in single user mode, no difference. When I install -DP1 and reboot, the system does the same thing processing the /etc/rc* scripts and never makes multi user mode. If I boot single user, the fsck has the same problem. - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o [EMAIL PROTECTED] --- _'\,_ (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-emulation in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Ugly PATCH] Re: Again: panic kmem_malloc()
Ben Stuyts wrote: Is there a way to check the free list of the kernel? Maybe I can find out what action triggers eating al its memory. ] panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated. That's easy: you're calling kmem_malloc() without M_NOWAIT. That function only operates on the maps kmem_map or mb_map. It calls vm_map_findspace(), which fails to find space in the map. vm_map_findspace() fails to add space to the map, because it only adds space tot he map if the map is kernel_map; all other maps fail catastrophically. The map you are calling it with is kmem_map (if it were mb_map, you would get an Out of mbuf clusters message on your console, and the allocation would fail, regardless of the value of the M_NOWAIT flags bit (mbuf allocations do not properly honor the lack of an M_NOWAIT flags bit). The panic message occurs becuause you asked it to wait for memory to be available. But the code is stupid, and refuses to wait for memory to be available, in the case that space can not be found in the map, because it does not properly realize that the freeing of memory elsewhere can result in freed space in the map. So it calls panic instead of waiting. Therefore, it's technically illegal to call kmem_malloc() with a third argument that does not include the M_NOWAIT bit, even though the function is documented, and obviously intended, to permit the use of this flags bit. In -current, there is exactly one place where kmem_malloc() is called with the kmem_map as its first argument: in the function page_alloc() in vm/uma_core.c. So, you have two bogus things happening: 1) page_alloc() in uma is using kmem_malloc() without the M_NOWAIT flag 2) kmem_malloc() without the M_NOWAIT flag panics, INSTEAD OF FRICKING WAITING, LIKE YOU ARE TELLING IT TO DO. :-0_ - Dr. Evil Probably, page_alloc should be rewritten to not use kmem_malloc(), and to use the kmem_alloc_wait() instead. Please find a (relatively bogus) patch attached, which could cause things to block for a long time, but will avoid the panic. Jeffrey Roberson is going to need to fix UMA allocations, per the comment in this patch, for a more permanent fix. I've specifically Cc:'ed him on this message. -- Terry Index: uma_core.c === RCS file: /cvs/src/sys/vm/uma_core.c,v retrieving revision 1.38 diff -c -r1.38 uma_core.c *** uma_core.c 28 Sep 2002 17:15:33 - 1.38 --- uma_core.c 11 Oct 2002 15:19:15 - *** *** 781,787 void *p;/* Returned page */ *pflag = UMA_SLAB_KMEM; ! p = (void *) kmem_malloc(kmem_map, bytes, wait); return (p); } --- 781,798 void *p;/* Returned page */ *pflag = UMA_SLAB_KMEM; ! /* !* XXX Bogus !* kmem_malloc() can panic if called without M_NOWAIT on kmem_map; !* work around this by calling kmem_alloc_wait() instead. This is !* really bogus, because it can hang indefinitely. Jeffrey Roberson !* needs to fix this to do all UMA allocations out of kernel_map, !* instead, so pmap_growkernel() can be used, instead of hanging. !*/ ! if (wait M_NOWAIT) ! p = (void *) kmem_malloc(kmem_map, bytes, wait); ! else ! p = (void *) kmem_alloc_wait(kmem_map, bytes); return (p); }
Re: [Ugly PATCH] Re: Again: panic kmem_malloc()
On Fri, 11 Oct 2002, Terry Lambert wrote: Ben Stuyts wrote: Is there a way to check the free list of the kernel? Maybe I can find out what action triggers eating al its memory. Maybe you should just increase the size of your kmem_map? I'll look into a better fix but that should do it short term. ] panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated. That's easy: you're calling kmem_malloc() without M_NOWAIT. That function only operates on the maps kmem_map or mb_map. It calls vm_map_findspace(), which fails to find space in the map. vm_map_findspace() fails to add space to the map, because it only adds space tot he map if the map is kernel_map; all other maps fail catastrophically. Well, for the old allocator this was a panicing situation. It never returned memory and kva back to kmem_map. So you were pretty much done. The map you are calling it with is kmem_map (if it were mb_map, you would get an Out of mbuf clusters message on your console, and the allocation would fail, regardless of the value of the M_NOWAIT flags bit (mbuf allocations do not properly honor the lack of an M_NOWAIT flags bit). It is documented that they do not. Notice we only have M_TRYWAIT now for mbufs. The panic message occurs becuause you asked it to wait for memory to be available. But the code is stupid, and refuses to wait for memory to be available, in the case that space can not be found in the map, because it does not properly realize that the freeing of memory elsewhere can result in freed space in the map. So it calls panic instead of waiting. It will wait for pages to be available. It just wont wait for KVA to be available. This was a somewhat less bogus with the old allocator. Therefore, it's technically illegal to call kmem_malloc() with a third argument that does not include the M_NOWAIT bit, even though the function is documented, and obviously intended, to permit the use of this flags bit. No, that's not true. It will wait if you're low on pages. It will not wait if you've run out of kva. There's a big difference. Also, WAITOK more appropriately means Never return NULL even if you have to panic. You just assumed it would mean Never return NULL even if you have to wait. ;-) I agree that it should mean the latter though. In -current, there is exactly one place where kmem_malloc() is called with the kmem_map as its first argument: in the function page_alloc() in vm/uma_core.c. So, you have two bogus things happening: 1)page_alloc() in uma is using kmem_malloc() without the M_NOWAIT flag Why is this bogus? 2)kmem_malloc() without the M_NOWAIT flag panics, INSTEAD OF FRICKING WAITING, LIKE YOU ARE TELLING IT TO DO. :-0_ - Dr. Evil Yes, I agree, it should wait. It might be interesting to see what the effects of allocating straight out of the kernel_map would be. Or perhaps positioning the kmem_map in such a way that it might be able to expand. I don't like the hard limit here anymore than anyone else does. On reasonable architectures your only worry is wasting pages and not kva. Now with UMA the VM can tell it that it's using too many pages and so the system is self tuning. We'll have to do something to help kva crippled architectures (x86) in the near term. Probably, page_alloc should be rewritten to not use kmem_malloc(), and to use the kmem_alloc_wait() instead. Please find a (relatively bogus) patch attached, which could cause things to block for a long time, but will avoid the panic. Jeffrey Roberson is going to need to fix UMA allocations, per the comment in this patch, for a more permanent fix. I've specifically Cc:'ed him on this message. Thanks for looking into this terry. Please, call me Jeff though. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current status of some cards
Hi, under -current I get the following results with my IBM A30p: 64MB CF-Card (ata) : Works (ad2) 64MB Sandisk Smartmedia : Works (ad2) Netgear FA411 (PCMCIA) : Works (ed0) Netgear FA510 (CB) : Attaches (dc0) reads the correct MAC (didn't before) but doesn't work (no carrier) like before. A few messages are attached. Thanks for the work BTW! One note: When booting with CF/SM Card inserted it gets attached as ad0 which prevents from mounting root. Is this because GEOM attaches its disks later on and PCCARD/PCMCIA attaches it's devices before? Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS cbb0: card inserted: event=0x, state=3810 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb0: cbb_power: CARD_VCC_3V and CARD_VPP_VCC [11] pccard0: read_cis start (8800) sc-membase (c020) end () sc-memlimit (cfff) cis mem map e58fe000 pccard0: CIS tuple chain: CISTPL_DEVICE type=funcspec speed=ext 01 04 df 72 01 ff unhandled CISTPL 1c 1c 04 03 d9 01 ff unhandled CISTPL 18 18 02 df 01 CISTPL_MANFID 20 04 45 00 01 04 CISTPL_VERS_1 15 17 04 01 53 75 6e 44 69 73 6b 00 53 44 50 00 35 2f 33 20 30 2e 36 00 ff unhandled CISTPL 80 80 03 14 08 00 CISTPL_FUNCID 21 02 04 01 CISTPL_FUNCE 22 02 01 01 CISTPL_FUNCE 22 03 02 0c 0f CISTPL_CONFIG 1a 05 01 07 00 02 0f CISTPL_CFTABLE_ENTRY 1b 0b c0 c0 a1 27 55 4d 5d 75 08 00 21 CISTPL_CFTABLE_ENTRY 1b 06 00 01 21 b5 1e 4d CISTPL_CFTABLE_ENTRY 1b 0d c1 41 99 27 55 4d 5d 75 64 f0 ff ff 21 CISTPL_CFTABLE_ENTRY 1b 06 01 01 21 b5 1e 4d CISTPL_CFTABLE_ENTRY 1b 12 c2 41 99 27 55 4d 5d 75 ea 61 f0 01 07 f6 03 01 ee 21 CISTPL_CFTABLE_ENTRY 1b 06 02 01 21 b5 1e 4d CISTPL_CFTABLE_ENTRY 1b 12 c3 41 99 27 55 4d 5d 75 ea 61 70 01 07 76 03 01 ee 21 CISTPL_CFTABLE_ENTRY 1b 06 03 01 21 b5 1e 4d CISTPL_CFTABLE_ENTRY 1b 04 07 00 28 d3 CISTPL_NO_LINK 14 00 CISTPL_END ff pccard0: check_cis_quirks pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: SunDisk, SDP, 5/3 0.6 pccard0: Manufacturer code 0x45, product 0x401 pccard0: function 0: fixed disk, ccr addr 200 mask f pccard0: function 0, config table entry 0: memory card; irq mask 0; memspace 0-7 ff; maxtwins 1; mwait_required rdybsy_active powerdown pccard0: function 0, config table entry 1: I/O card; irq mask ; iomask 4, io space 0-f; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pccard0: function 0, config table entry 2: I/O card; irq mask 4000; iomask a, io space 1f0-1f7 3f6-3f7; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqsha re irqpulse irqlevel powerdown pccard0: function 0, config table entry 3: I/O card; irq mask 4000; iomask a, io space 170-177 376-377; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqsha re irqpulse irqlevel powerdown pccard0: function 0, config table entry 7: I/O card; irq mask 4000; iomask a, io space 170-177 376-377; memspace 0-7ff; maxtwins 1; rdybsy_active io8 io16 irqsha re irqpulse irqlevel powerdown pccard0: functions scanning pccard0: Card has 1 functions. pccard_mfc is 0 pccard0: Memory space not yet implemented. pccard0: Neither memory nor I/O mampped pccard0: Allocation failed for cfe 0 pccard0: I/O rid 0 start 0 end pccard0: Memory space not yet implemented. cbb_pcic_socket_enable: cbb0: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb0: cbb_power: CARD_VCC_3V and CARD_VPP_VCC [11] start (8800) sc-membase (c020) end () sc-memlimit (cfff) pccard0: ccr_res == 8800-880003ff, base=200 pccard0: function 0 CCR at 0 offset 200: 41 80 2e 0, 0 0 0 0, 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 ad2: read interrupt arrived earlyad2: 61MB SanDisk SDCFB-64 [490/8/32] at ata2 -master BIOSPIO pccard0: function 0 CCR at 0 offset 200: 41 82 2e 0, 0 0 0 0, 0 Oct 11 12:25:59 nihil login: ROOT LOGIN (root) ON ttyv1 ad2: read interrupt arrived earlyad2: removed from configuration ad2: no status, reselecting device ad2: timeout sending command=e7 s=ff e=04 ad2: flushing cache on detach failed ata2: detached cbb_pcic_socket_disable cbb0: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb1: card inserted: event=0x, state=3820 cbb1: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb1: cbb_power: CARD_VCC_3V and CARD_VPP_VCC [11] start (8800) sc-membase (c020) end () sc-memlimit (cfff) cardbus1: Expecting link target, got 0x0 cardbus1: Resource not specified in CIS: id=10, size=80 cardbus1: Resource not specified in CIS: id=14, size=400 start (8800) sc-membase (c020) end () sc-memlimit (cfff) cardbus1: Non-prefetchable memory at 8800-880003ff cardbus1: Non-prefetchable memory rid=14 at 8800-880003ff (400) cardbus1: IO port at
Buildworld broken at gdb?
Following the gcc/binutils update: arch-utils.o(.data+0x40): undefined reference to `bfd_elf32_i386_vec' *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. Anyone else seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pw_scan() allows empty login names
Hello, Is it intentional? Here is a patch: Index: lib/libc/gen/pw_scan.c === RCS file: /home/ncvs/src/lib/libc/gen/pw_scan.c,v retrieving revision 1.23 diff -u -r1.23 pw_scan.c --- lib/libc/gen/pw_scan.c 2 Oct 2002 07:02:46 - 1.23 +++ lib/libc/gen/pw_scan.c 11 Oct 2002 11:36:19 - @@ -78,6 +78,8 @@ pw-pw_fields = 0; if (!(pw-pw_name = strsep(bp, :))) /* login */ goto fmt; + if (pw-pw_name[0] == '\0') + goto fmt; root = !strcmp(pw-pw_name, root); if (pw-pw_name[0] (pw-pw_name[0] != '+' || pw-pw_name[1] == '\0')) pw-pw_fields |= _PWF_NAME; %%% -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim;macomnet.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === libexec/rtld-elf ld: target elf64-alpha not found *** Error code 1 Stop in /h/des/src/libexec/rtld-elf. *** Error code 1 Stop in /h/des/src/libexec. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Yet another new preventer of cross-builds
Cross builds will be necessary for a goodly while; as on hardware like mine (new VAIO laptop) where current won't boot at all without lots of fiddling, for example... I'm going to put an empty stdint.h in stable for now, just to see what happens -- it delays the failure to the compile of tmpname.cc, but still dies. Let's try to keep current-dependencies out of the tool-build (or MFC them quickly, or at least #ifdef them) -- CVSUP about 2PM PDT 10/11, building under 4.7-REL (-stable destabilized today; got a panic booting that too...): -- Pete - === gnu/usr.bin/groff/src/libs/libgroff Making version.cc rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include -D__FBSDID=__RCSID /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/getopt.c /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/getopt1.c /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/iftoa.c /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/itoa.c /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/matherr.c mkdep -f .depend -a-DHAVE_CONFIG_H -I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include -D__FBSDID=__RCSID /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/assert.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/change_lf.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cmap.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/color.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cset.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/device.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/errarg.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/error.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/fatal.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/filename.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/font.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/fontfile.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/geometry.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/htmlhint.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/invalid.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/lf.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/lineno.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/macropath.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/maxfilename.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/mksdir.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/nametoindex.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/paper.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/prime.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/progname.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/ptable.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/searchpath.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/string.cc
Re: Yet another new preventer of cross-builds
That looks like the same error message I've been getting going from 4.6 to 4.7. I have one machine that went to through the build fine. But the machine that I'm working on now dies at the make buildworld with the same type message. Any suggestions on how to get around this? Cross builds will be necessary for a goodly while; as on hardware like mine (new VAIO laptop) where current won't boot at all without lots of fiddling, for example... I'm going to put an empty stdint.h in stable for now, just to see what happens -- it delays the failure to the compile of tmpname.cc, but still dies. Let's try to keep current-dependencies out of the tool-build (or MFC them quickly, or at least #ifdef them) -- CVSUP about 2PM PDT 10/11, building under 4.7-REL (-stable destabilized today; got a panic booting that too...): -- Pete - === gnu/usr.bin/groff/src/libs/libgroff Making version.cc rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H - I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../.. /contrib/groff/src/include - I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/incl ude - D__FBSDID=__RCSID /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff /../../../../../../contrib/groff/src/libs/libgroff/getopt.c /current/us r/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/gro ff/src/libs/libgroff/getopt1.c /current/usr/src/gnu/usr.bin/groff/src/l ibs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/iftoa.c /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../ contrib/groff/src/libs/libgroff/itoa.c /current/usr/src/gnu/usr.bin/gro ff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/ matherr.c mkdep -f .depend -a-DHAVE_CONFIG_H - I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../.. /contrib/groff/src/include - I/current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/incl ude - D__FBSDID=__RCSID /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff /../../../../../../contrib/groff/src/libs/libgroff/assert.cc /current/u sr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/gr off/src/libs/libgroff/change_lf.cc /current/usr/src/gnu/usr.bin/groff/s rc/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cmap .cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../.. /../contrib/groff/src/libs/libgroff/color.cc /current/usr/src/gnu/usr.b in/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/lib groff/cset.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../. ./../../../../contrib/groff/src/libs/libgroff/device.cc /current/usr/sr c/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/s rc/libs/libgroff/errarg.cc /current/usr/src/gnu/usr.bin/groff/src/libs/ libgroff/../../../../../../contrib/groff/src/libs/libgroff/error.cc /cu rrent/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../con trib/groff/src/libs/libgroff/fatal.cc /current/usr/src/gnu/usr.bin/grof f/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/f ilename.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../. ./../../../contrib/groff/src/libs/libgroff/font.cc /current/usr/src/gnu /usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/li bs/libgroff/fontfile.cc /current/usr/src/gnu/usr.bin/groff/src/libs/lib groff/../../../../../../contrib/groff/src/libs/libgroff/geometry.cc /cu rrent/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../con trib/groff/src/libs/libgroff/htmlhint.cc /current/usr/src/gnu/usr.bin/g roff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgrof f/invalid.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../.. /../../../../contrib/groff/src/libs/libgroff/lf.cc /current/usr/src/gnu /usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/li bs/libgroff/lineno.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgr off/../../../../../../contrib/groff/src/libs/libgroff/macropath.cc /cur rent/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../cont rib/groff/src/libs/libgroff/maxfilename.cc /current/usr/src/gnu/usr.bin /groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgr off/mksdir.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../. ./../../../../contrib/groff/src/libs/libgroff/nametoindex.cc /current/u sr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/gr off/src/libs/libgroff/new.cc /current/usr/src/gnu/usr.bin/groff/src/lib s/libgroff/../../../../../../contrib/groff/src/libs/libgroff/paper.cc / current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../c ontrib/groff/src/libs/libgroff/prime.cc /current/usr/src/gnu/usr.bin/gr off/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff /progname.cc /current/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../..
Re: [Ugly PATCH] Re: Again: panic kmem_malloc()
Jeff Roberson wrote: On Fri, 11 Oct 2002, Terry Lambert wrote: Ben Stuyts wrote: Is there a way to check the free list of the kernel? Maybe I can find out what action triggers eating al its memory. Maybe you should just increase the size of your kmem_map? I'll look into a better fix but that should do it short term. I think he's in an overload condition. Basically, it will always use all available resources, and then some. So incresing all available still leaves you with your foot shot off when the system asks for and then some. 8-(. 1)page_alloc() in uma is using kmem_malloc() without the M_NOWAIT flag Why is this bogus? Because it's possible to panic under heavy load. The only thing heavy load should cause is slowdown... ideally, proportional to the load... ;^). Yes, I agree, it should wait. It might be interesting to see what the effects of allocating straight out of the kernel_map would be. Or perhaps positioning the kmem_map in such a way that it might be able to expand. I don't like the hard limit here anymore than anyone else does. I looked at this. I don't think you can reasonable expand maps other than the kernel_map. The allocations are wrong... kernel_map is, unfortunately, special. This is about the 1,000,000th time I've wanted to establish mappings for all physical RAM, and maybe the entire address space, up front, instead of leaving it to demand-time. The problem with this is that you are talking 4M (or 8M, if you use PSE-36 or PAE). Then *everything* becomes allocable at interrupt time, and there's no such thing as tiered access semantics, only whether or not a mapping is assigned to the pool you want to allocate out of, or not. On reasonable architectures your only worry is wasting pages and not kva. Heh... It's not an unreasonable architecture, you're just using an unreasonable amount of memory on a reasonable architecture. Jeffrey Roberson is going to need to fix UMA allocations, per the comment in this patch, for a more permanent fix. I've specifically Cc:'ed him on this message. Thanks for looking into this terry. Please, call me Jeff though. No problem; I copied the name out of the source file; I tend to use Terrence in source files (you can see this in init_main.c and other places where I did enough work I felt it merited a copyright to be able to give it away). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CNet Pro200WL (Davicom DM9102A): fine under 4.6.2-p2, no worky under -CURRENT
Herro -CURRENT! I have a Dell Dimension 4500 that included a CNet Pro200WL adapter. I have 4.6.2-p2 installed on one partition and -CURRENT from earlier today on another. 4.6.2-p2 has no problem with this card, and while it's detected under -CURRENT, I can't seem to, well, make it work. I've attempted to force media types and suboptions to no avail (as opposed to autoselect). tcpdump in promiscuous mode shows only ARP requests when this machine tries to reach another on the subnet. Other machines never see any segments generated by this one, and 'netstat -i' shows no input / output errors. For what it's worth, the following message is broadcast to my console when trying to configure the interface: dc0: failed to force tx and rx to idle state I'm attaching dmesg and pciconf output to this message. Please let me know what (if any) further information is required. TIA! -- ryan beasley[EMAIL PROTECTED] GPG ID: 0x16EFBD48 http://www.goddamnbastard.org # /var/run/dmesg.boot Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #3: Fri Oct 11 19:54:38 CDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FREDRIK_DP Preloaded elf kernel /boot/kernel/kernel at 0xc03cd000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2392297388 Hz CPU: Pentium 4 (2392.30-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536084480 (523520K bytes) avail memory = 516149248 (504052K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 8 entries at 0xc00f44e0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: Intel 82845 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib2: PCIBIOS PCI-PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib2 pci2: multimedia, audio at device 1.0 (no driver attached) pci2: input device at device 1.1 (no driver attached) dc0: Davicom DM9102A 10/100BaseTX port 0xd400-0xd4ff mem 0xfeaffc00-0xfeaffcff irq 9 at device 2.0 on pci2 dc0: Ethernet address: 15:01:15:01:15:01 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 ATA100 controller port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) orm0: Option ROM at iomem 0xc-0xcefff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) Timecounters tick every 10.000 msec Initializing GEOMetry subsystem ad0: 38172MB MAXTOR 6L040J2 [77557/16/63] at ata0-master UDMA100 ad1: 38166MB WDC WD400BB-00AUA1 [77545/16/63] at ata0-slave UDMA33 acd0: CD-RW _NEC CD-RW NR-9100A at ata1-master PIO4 Mounting root from ufs:/dev/ad1s2a # pciconf -l agp0@pci0:0:0: class=0x06 card=0x1a308086 chip=0x1a308086 rev=0x11 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x chip=0x1a318086 rev=0x11 hdr=0x01 none0@pci0:29:0:class=0x0c0300 card=0x01321028 chip=0x24c28086 rev=0x01 hdr=0x00 none1@pci0:29:1:class=0x0c0300 card=0x01321028 chip=0x24c48086 rev=0x01 hdr=0x00 none2@pci0:29:2:
