Re: panic: kmem_malloc boot error w/ 6.2
On Fri, 26 Jan 2007, Scott Long wrote: makeoptions DEBUG=-g .. when I added this, boot works fine. When removing it, you get the panic. Strange, huh? :-/ Below is a snippet of the boot log: Please compile KDB and DDB into your kernel so we can see exactly where the panic is happening. Not sure what exactly I should be looking for, but removing the makeoptions line and adding those debuggers, and running 'trace' when it panics gives this: amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 139900MB (286515200 sectors) RAID 1 (optimal) ipmi0: IPMI device rev. 0, firmware rev. 1.81, version 1.5 ipmi0: Number of channels 4 ipmi0: Attached watchdog ATA PseudoRAID loaded GEOM: new disk afd0 GEOM: new disk amrd0 panic: kmem_malloc(-1059844096): kmem_map too small: 3084288 total allocated KDB: enter: panic [thread pid 2 tid 12 ] Stopped at kdb_enter+0x2c: leave db> trace Tracing pid 2 tid 12 td 0xc5fadc00 kdb_enter(c06bc072,100,2,c0c361c0,c0d41000,...) at kdb_enter+0x2c panic(c06cb66a,c0d41000,2f1000,e4bb8bb0,c0622016,...) at panic+0x122 kmem_malloc(c0c4b0c0,c0d41000,2,2) at kmem_malloc+0x44f uma_large_malloc(c0d41000,2,c0d40100,0,c6264a50,...) at uma_large_malloc+0x30 malloc(c0d40100,c06eab00,2,c620dc00,c5ff6600,...) at malloc+0x81 g_read_data(c60fb480,0,0,c0d40100,0,0) at g_read_data+0x3c g_mbr_taste(c0709040,c620dc00,0) at g_mbr_taste+0x127 g_new_provider_event(c620dc00,0,6667,c5fadc00,0,...) at g_new_provider_event+0x6e g_run_events(0,c5fadc00,c5fac430,c04e5dd4,e4bb8d24,...) at g_run_events+0x13e g_event_procbody(0,e4bb8d38,0,c04e5dd4,0,...) at g_event_procbody+0x59 fork_exit(c04e5dd4,0,e4bb8d38) at fork_exit+0x4f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4bb8d6c, ebp = 0 --- HTH, -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does FBSD always assume it's on an 8080 CPU?
On Fri, Jan 26, 2007 at 08:45:15PM -0800, Chris H. wrote: > Hello and thank you for your response... > > Quoting Mike Jakubik <[EMAIL PROTECTED]>: > > >Chris H. wrote: > >> > >>CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) > >>Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 > >>Features=0x383fbff > >> AMD > >>Features=0xc0400800 > >> > >>That I simply build world/kernel with an clean (empty) make.conf > >>and add the following during port(s) building to attain optimum results > >>given my CPU for this current biuld? > >> > >>CPUTYPE?=pentium4 > >> > >>COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 > > > >Why are you using "pentium4" with an Athlon XP CPU? use "athlonxp" > >instead. Also, don't modify the COPTFLAGS. > > > > Ooops. I've changed it to: > > CPUTYPE?=athlon-4 > CFLAGS+= -march=athlon-4 -mmmx -m3dnow -m3dnow+ -msse -msse2 > > Look a little better? :) No, the CFLAGS is still entirely superfluous. Just setting CPUTYPE will DTRT. Kris pgptR1CHjkukJ.pgp Description: PGP signature
Re: Why does FBSD always assume it's on an 8080 CPU?
Hello and thank you for your response... Quoting Mike Jakubik <[EMAIL PROTECTED]>: Chris H. wrote: CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 That I simply build world/kernel with an clean (empty) make.conf and add the following during port(s) building to attain optimum results given my CPU for this current biuld? CPUTYPE?=pentium4 COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Why are you using "pentium4" with an Athlon XP CPU? use "athlonxp" instead. Also, don't modify the COPTFLAGS. Ooops. I've changed it to: CPUTYPE?=athlon-4 CFLAGS+= -march=athlon-4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Look a little better? :) --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Loosing spam fight
On Fri, 2007-Jan-26 09:24:58 -0200, JoaoBR wrote: >like I said, for my understandings firewall implemention for spam fighting is >wrong > >because you reject the message Except that the original mail was talking about greylisting. This won't reject any mail sent from a MTA that correctly implements SMTP. According to the SMTP specs, I am perfectly at liberty to tell you that I can't accept your mail right now, please try again later. -- Peter Jeremy pgpvKL9pCcmYU.pgp Description: PGP signature
Re: Why does FBSD always assume it's on an 8080 CPU?
Chris H. wrote: CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 That I simply build world/kernel with an clean (empty) make.conf and add the following during port(s) building to attain optimum results given my CPU for this current biuld? CPUTYPE?=pentium4 COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Why are you using "pentium4" with an Athlon XP CPU? use "athlonxp" instead. Also, don't modify the COPTFLAGS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does FBSD always assume it's on an 8080 CPU?
Quoting Dimitry Andric <[EMAIL PROTECTED]>: Chris H. wrote: I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... See /usr/share/examples/etc/make.conf. Sigh, the obvious is so /easily/ overlooked. Thanks for the "heads-up". :) That helps quite alot. --Chris As Pentium have been the "norm" for many years now, why aren't these /assumed/? Because i486 is still the lowest common denominator, at least for 6.x. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Yes. Is this so horrible? -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does FBSD always assume it's on an 8080 CPU?
Context switching. We already preserve the "core" CPU state and the FPU state between context switches. Adding MMX into the mix means preserving an MMX state (since it can clobber the FPU state) and so forth. jmc Quoting Dimitry Andric <[EMAIL PROTECTED]>: Chris H. wrote: I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... See /usr/share/examples/etc/make.conf. As Pentium have been the "norm" for many years now, why aren't these /assumed/? Because i486 is still the lowest common denominator, at least for 6.x. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Yes. Is this so horrible? Hello Kris, John, Dimitry, and thank you for your taking the time to respond and the "wake-up call" (in regards to searching the list first) ;) Based on your responses and my research in that area: -- Yes, it's supposed to be that way. Certain parts of the FreeBSD system cannot use MMX or SSE instructions (e.g. the boot loader) but it's okay since they are absolutely not performance critical. Kris ## The kernel will "support" MMX and SSE -- that is, any programs (root or userland) which use MMX/SSE will work just fine. That is: any programs built with gcc can indeed support MMX and SSE operations. The kernel itself _will not_ use any SSE or MMX operations when built. This is because these optimisations are known to break the FreeBSD kernel. This applies to all i386 architectures, and probably 64-bit architectures too (not sure). Chad -- Can I (pre || a)ssume that given my CPU echoes the following: CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 That I simply build world/kernel with an clean (empty) make.conf and add the following during port(s) building to attain optimum results given my CPU for this current biuld? CPUTYPE?=pentium4 COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Sorry, I'm new to Athlon. Does it show? Again, apologies for spamming this list, and thank you (and everyone else) very much for all your time. --Chris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does FBSD always assume it's on an 8080 CPU?
Chris H. wrote: ...or when will FreeBSD support Pentium features? I want to apologize in advance if this should be on the kern@ But it seemed apropriate for this list too and I'm already on it. I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... As Pentium have been the "norm" for many years now, why aren't these /assumed/? I'm building on several SMP PIII's and a build is in process now on a PIV Athalon running 6.2 the source and ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this current kernel build is echoing these same -mno- lines. I have machinei386 cpuI686_CPU deviceapic uncommented and I386_CPU, I486_CPU & I586_CPU commented. I have grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES Yet the only case I find relating to this is on line: 130 in: /src/sys/i386/conf/NOTES which reads: # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default # on I686_CPU and above. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Thank you very much for all your time and consideration. --Chris Context switching. We already preserve the "core" CPU state and the FPU state between context switches. Adding MMX into the mix means preserving an MMX state (since it can clobber the FPU state) and so forth. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does FBSD always assume it's on an 8080 CPU?
Chris H. wrote: > I've noticed building kernels, that since v. >= 5 that during > the phase 2/3 all the lines echoed to the screen contain: > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... See /usr/share/examples/etc/make.conf. > As Pentium have been the "norm" for many years now, why aren't > these /assumed/? Because i486 is still the lowest common denominator, at least for 6.x. > Default? hmmm... not as far as I can tell. Anyway, I would *greatly* > appreciate any insight on this issue. Do I need to pollute my make.conf > file to achive a Pentium kernel? Yes. Is this so horrible? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Why does FBSD always assume it's on an 8080 CPU?
...or when will FreeBSD support Pentium features? I want to apologize in advance if this should be on the kern@ But it seemed apropriate for this list too and I'm already on it. I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... As Pentium have been the "norm" for many years now, why aren't these /assumed/? I'm building on several SMP PIII's and a build is in process now on a PIV Athalon running 6.2 the source and ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this current kernel build is echoing these same -mno- lines. I have machinei386 cpuI686_CPU deviceapic uncommented and I386_CPU, I486_CPU & I586_CPU commented. I have grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES Yet the only case I find relating to this is on line: 130 in: /src/sys/i386/conf/NOTES which reads: # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default # on I686_CPU and above. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Thank you very much for all your time and consideration. --Chris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Why does FBSD always assume it's on an 8080 CPU?
...or when will FreeBSD support Pentium features? I want to apologize in advance if this should be on the kern@ But it seemed apropriate for this list too and I'm already on it. I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... As Pentium have been the "norm" for many years now, why aren't these /assumed/? I'm building on several SMP PIII's and a build is in process now on a PIV Athalon running 6.2 the source and ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this current kernel build is echoing these same -mno- lines. I have machine i386 cpu I686_CPU device apic uncommented and I386_CPU, I486_CPU & I586_CPU commented. I have grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES Yet the only case I find relating to this is on line: 130 in: /src/sys/i386/conf/NOTES which reads: # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default # on I686_CPU and above. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Thank you very much for all your time and consideration. --Chris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: kmem_malloc boot error w/ 6.2
Pekka Savola wrote: Hello, (Not subscribed, let's hope this gets through..) I saw the strangest case I've yet seen today when upgrading a dual-P3 system using sources (buildworld etc.) from FreeBSD 5.5 to RELENG_6 (6.2). The system paniced at boot with a message like: panic: kmem_malloc(-1059844096): kmem_map too small: 2990080 total allocated This seemed to be just before one would mount the root filesystem. GENERIC kernel on 6.2-RELEASE boot CD worked though. FreeSBIE 2.0 kernel (6.2-RELEASE) panicked in the same way, as well as another Rescue CD based on FreeBSD 6.1. I did a fair bit of bisecting (about 10 compiles) to find out which feature in GENERIC removes this panic, and came to a suprising conclusion: makeoptions DEBUG=-g .. when I added this, boot works fine. When removing it, you get the panic. Strange, huh? :-/ Below is a snippet of the boot log: Please compile KDB and DDB into your kernel so we can see exactly where the panic is happening. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
'make buildworld' fails
I've just updated the sources in FreeBSD 6.2-RELEASE and tried to rebuild world. With option 'NO_CXX=YES' in /etc/make.conf world compiled successful, if this option not added 'make buildworld' failed. 'make buildworld' fails: <..> ===> gnu/usr.bin/groff/src/libs/libgroff (depend) Making version.cpp rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/iftoa.c /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/itoa.c /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/matherr.c /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/progname.c mkdep -f .depend -a /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/assert.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/change_lf.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cmap.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/color.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cset.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/device.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/errarg.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/error.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/fatal.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/filename.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/font.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/fontfile.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/geometry.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/glyphuni.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/htmlhint.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/hypot.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/invalid.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/lf.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/lineno.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/macropath.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/maxfilename.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/mksdir.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/nametoindex.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/paper.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/prime.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/ptable.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/searchpath.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/string.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/strsave.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/symbol.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/tmpfile.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/tmpname.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/unicode.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/uniglyph.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/uniuni.cpp version.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cmap.cpp:27:18: cmap
panic: kmem_malloc boot error w/ 6.2
Hello, (Not subscribed, let's hope this gets through..) I saw the strangest case I've yet seen today when upgrading a dual-P3 system using sources (buildworld etc.) from FreeBSD 5.5 to RELENG_6 (6.2). The system paniced at boot with a message like: panic: kmem_malloc(-1059844096): kmem_map too small: 2990080 total allocated This seemed to be just before one would mount the root filesystem. GENERIC kernel on 6.2-RELEASE boot CD worked though. FreeSBIE 2.0 kernel (6.2-RELEASE) panicked in the same way, as well as another Rescue CD based on FreeBSD 6.1. I did a fair bit of bisecting (about 10 compiles) to find out which feature in GENERIC removes this panic, and came to a suprising conclusion: makeoptions DEBUG=-g .. when I added this, boot works fine. When removing it, you get the panic. Strange, huh? :-/ Below is a snippet of the boot log: ... acd0: DVDROM at ata0-master UDMA33 afd0: 6869804134400MB at ata2-master PIO3 acd1: CDROM at ata2-slave PIO3 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 139900MB (286515200 sectors) RAID 1 (optimal) panic: kmem_malloc(-1059844096): kmem_map too small: 2990080 total allocated Uptime: 2s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 buildworld fails with NO_SHARED
In the last episode (Jan 26), Bill Vermillion said:
> I had wanted to build static binaries in /bin and /sbin - so
> I set NO_SHARED. The man pages says "... this can be bad. If set
> every utility that uses bsd.prog.mk will be linked statically."
>
> Here is the tail end of the output of make buildworld as I mailed
> it to me from the machine I was bringing up as we start to replace
> all the 4.11 servers.
>
> > ===> usr.sbin/gstat (all)
> > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall
> > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -c
> > /usr/src/usr.sbin/gstat/gstat.c
> > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall
> > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static
> > -o gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit
> > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1c): In
> > function `StartElement':
> > : undefined reference to `sbuf_new'
> > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1538): In
> > function `readkmem':
> > : undefined reference to `kvm_read'
> > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3938): In
> > function `term_deletechars':
> > : undefined reference to `tgoto'
Looks like there are some missing/misordered library dependencies.
Moving -lcurses after -ledit, and adding -lkvm and -lsbuf fixes it.
The main thing you lose by statically linking is dlopen(), so nsswitch
and pam modules from ports won't work. Modules built into libc.a or
libpam.a (NIS and pam_unix for example) will work. Also, if you're on
-current you can tell cached to do NSS lookups on behalf of static
binaries.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/gstat/Makefile,v
retrieving revision 1.6.2.1
diff -u -r1.6.2.1 Makefile
--- Makefile10 Jun 2006 15:40:10 - 1.6.2.1
+++ Makefile26 Jan 2007 17:00:38 -
@@ -3,7 +3,7 @@
PROG= gstat
MAN= gstat.8
WARNS?=5
-DPADD= ${LIBGEOM} ${LIBDEVSTAT} ${LIBBSDXML} ${LIBCURSES} ${LIBEDIT}
-LDADD= -lgeom -ldevstat -lbsdxml -lcurses -ledit
+DPADD= ${LIBGEOM} ${LIBDEVSTAT} ${LIBBSDXML} ${LIBEDIT} ${LIBCURSES}
+LDADD= -lgeom -ldevstat -lbsdxml -ledit -lcurses -lkvm -lsbuf
.include
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 buildworld fails with NO_SHARED
On 1/26/07, Bill Vermillion <[EMAIL PROTECTED]> wrote: I had wanted to build static binaries in /bin and /sbin - so I set NO_SHARED. The man pages says "... this can be bad. If set every utility that uses bsd.prog.mk will be linked statically." I have problems in the past - on other platforms - where having statically linked tools in /bin saved the day. [Fixing things that some other SA's had no clue about as to what they were doing]. Since FreeBSD went to dynamically linked binaries, there is the /rescue directory which contains static binaries of the programs you would need to recover from a failure. There really is nothing to indicated what 'bad' may be - other than statically linking these. I took the NO_SHARED out and the buildworld went just fine. Is this a bug? I would think if the variable is set and useable things should work. Seems to be a bug, as their appears to be missing libraries in the NO_SHARED case. Here is the tail end of the output of make buildworld as I mailed it to me from the machine I was bringing up as we start to replace all the 4.11 servers. The verison is 6.2-STABLE with the tag in the cvsup set as RELENG_6_2. So this is exact with the release on Jan 19. Do I need to send this to anyone to look at. Any hints? Or should I just 'fugidaboudid' > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static -o gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit sbuf(9) - sbuf_new, sbuf_clear, sbuf_setpos, sbuf_bcat, sbuf_bcopyin, sbuf_bcpy, sbuf_cat, sbuf_copyin, sbuf_cpy, sbuf_printf, sbuf_vprintf, sbuf_putc, sbuf_trim, sbuf_overflowed, sbuf_finish, sbuf_data, sbuf_len, sbuf_delete - safe string formatting > : undefined reference to `sbuf_new' > : undefined reference to `sbuf_finish' > : undefined reference to `sbuf_data' > : undefined reference to `sbuf_delete' > : undefined reference to `sbuf_bcat' Not sure which library has the above function in them. The following functions seem to be defined in libkvm. > : undefined reference to `kvm_read' > : undefined reference to `kvm_geterr' > : undefined reference to `kvm_nlist' > : undefined reference to `kvm_geterr' curs_termcap (3X) - tgetent, tgetflag, tgetnum, tgetstr, tgoto, tputs - direct curses interface to the terminfo capability database > : undefined reference to `tgoto' > : undefined reference to `tgetstr' > : undefined reference to `tgetent' > : undefined reference to `tgetflag' > : undefined reference to `tgetnum' These seem to come from curses, but are not in your libcurses library. Is there another library these functions come from? Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.2 buildworld fails with NO_SHARED
I had wanted to build static binaries in /bin and /sbin - so I set NO_SHARED. The man pages says "... this can be bad. If set every utility that uses bsd.prog.mk will be linked statically." I have problems in the past - on other platforms - where having statically linked tools in /bin saved the day. [Fixing things that some other SA's had no clue about as to what they were doing]. There really is nothing to indicated what 'bad' may be - other than statically linking these. I took the NO_SHARED out and the buildworld went just fine. Is this a bug? I would think if the variable is set and useable things should work. Here is the tail end of the output of make buildworld as I mailed it to me from the machine I was bringing up as we start to replace all the 4.11 servers. The verison is 6.2-STABLE with the tag in the cvsup set as RELENG_6_2. So this is exact with the release on Jan 19. Do I need to send this to anyone to look at. Any hints? Or should I just 'fugidaboudid' Bill - Forwarded message from Charlie Root <[EMAIL PROTECTED]> - > From: Charlie Root <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Fri, 26 Jan 2007 10:52:42 -0500 > Subject: errors on buldworkd with NO_SHARED > X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com > X-Spam-Level: > X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 > autolearn=ham version=3.1.7 > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -static -o > getfmac getfmac.o > gzip -cn /usr/src/usr.sbin/getfmac/getfmac.8 > getfmac.8.gz > ===> usr.sbin/getpmac (all) > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c > /usr/src/usr.sbin/getpmac/getpmac.c > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -static -o > getpmac getpmac.o > gzip -cn /usr/src/usr.sbin/getpmac/getpmac.8 > getpmac.8.gz > ===> usr.sbin/gstat (all) > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -c > /usr/src/usr.sbin/gstat/gstat.c > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static -o > gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1c): In > function `StartElement': > : undefined reference to `sbuf_new' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x42e): In > function `EndElement': > : undefined reference to `sbuf_finish' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x43b): In > function `EndElement': > : undefined reference to `sbuf_data' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x453): In > function `EndElement': > : undefined reference to `sbuf_delete' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x808): In > function `CharData': > : undefined reference to `sbuf_bcat' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1538): In > function `readkmem': > : undefined reference to `kvm_read' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1550): In > function `readkmem': > : undefined reference to `kvm_geterr' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1591): In > function `readkmem_nl': > : undefined reference to `kvm_nlist' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x15b8): In > function `readkmem_nl': > : undefined reference to `kvm_geterr' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3938): In function > `term_deletechars': > : undefined reference to `tgoto' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3c56): In function > `term_echotc': > : undefined reference to `tgetstr' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3dbc): In function > `term_echotc': > : undefined refere
Re: Loosing spam fight
On Thursday 25 January 2007 11:18, Peter N. M. Hansteen wrote: > JoaoBR <[EMAIL PROTECTED]> writes: > > all this methods are certainly useless, stay calm ok > > I fully sympathize with your need to rant, but in this context most of > what you say is really quite beside the point. Please read what the > material at the links provided actually says. > the articles you linked show how to implement pf like I said, for my understandings firewall implemention for spam fighting is wrong because you reject the message unless you are the man of a corporate network you do have *NO* right to decide which message your users receive or not. May be some *WANT* viagra offers and others *WANT* a bigger penis so the only correct decision is to filter spam and put it into a spam folder where the user can review it and decide by his own if want it or not but may be, to change your opinion, you need to loose a case being responsible for some having a small penis and pay him his losses hihihihi, 100k/inch or something hihihi laugh with me and have a good day :) -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FreeBSD 6.2-STABLE and Flash 7 patch
Kai Lockwood <> wrote on Friday, January 26, 2007 5:10 AM: > Oliver Fromme wrote: >> [EMAIL PROTECTED] wrote: >> > Torfinn Ingolfsen wrote: >> > > BTW, what is the reason this "hack" isn't included in the base kernel >> > > / code? >> > >> > Because it is probably unnecessary? I run a recent 6-STABLE and use >> > the flash7 plugin *without* this patch. I am using Opera, though, not > >> Firefox... >> >> Same here. I use Opera with the Flash plugin on 6-STABLE >> without any problems. I haven't applied a patch to rtld. >> > This is a Firefox specific patch which requires the rtld be patched. > Many thanks to those who have provided patch updates because I was at > a lost without them. > Ummm... In that case the application should be fixed rather than patching the operating system. Which finally explains why this patch should definitely not be included in the base. Helge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
