Re: Q: Extending the sysctl MIB for Linuxulator variables
Mike Smith wrote: Yes, this is very true. But I think we are fooling ourselves if we believe linux emulation will not become 'standard' in the near future. Then we'll kick ourselves for giving the sysctl's convoluted names :-) Yeah... Then, the next in line after "linux" are: ibcs2 and svr4 and whatever comes next. Can you live with them as main sysctl categories? Adding anything at the top level would be a terrible mistake. Given that "ABI" is a bit obscure, kern.compat is the only sensible choice. kern.modules seems to be slightly more general in that you can have kern.modules.xxx where xxx is anything under /modules that needs/wants to some tuning via sysctl. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
Systems Administrator wrote: Thats not where it dies :).. It's the same problem. libtermcap has changed or causes conflicts with symbols (if I understand some of Peter's commits). The tput function you noted would have come from -ltermcap (as does the tgetent, tgetnum, etc.i below) What I don't know is whether -ltermcap is replaced by -lncurses or -ltermcap -lncurses. utils.o(.text+0xbd0): undefined reference to `tgetent' utils.o(.text+0xbf6): undefined reference to `tgetnum' utils.o(.text+0xc1c): undefined reference to `tgetnum' /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function `_rl_get_screen_size': terminal.o(.text+0x79): undefined reference to `tgetnum' terminal.o(.text+0xc9): undefined reference to `tgetnum' /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function `rl_resize_terminal': terminal.o(.text+0x1ae): undefined reference to `tgetstr' -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newpcm
Cameron Grant wrote: a design overview of newpcm is available at http://www.vilnya.demon.co.uk/design.txt i intend to put a hardware driver skeleton up on the same site in the next few days. What about a man page? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cds disappeared
Kenneth D. Merry wrote: This sounds like it could be a different problem than Randy Busy is having. He has two CDROM drives, and it looks like they have been swapped somehow. It sounds like you've only got one CDROM drive in each machine. Please send the output of the following, with mountable media in the drive: camcontrol devlist -v camcontrol tur cd0 -v camcontrol inquiry cd0 mount /dev/cd0a /mnt Ken, What ever change is causing the problem with SCSI CD drives, it went into the tree sometime last week. I'm seeing the same error reported about xmcd. My last "cvsup ; make world" was on Sep 1. I haven't updated xmcd to see if the problem goes away. troutmask:root[201] camcontrol devlist -v scbus-1 on xpt0 bus 0: at scbus-1 target -1 lun -1 (xpt0) scbus0 on ahc0 bus 0: SEAGATE ST34371N 0280at scbus0 target 0 lun 0 (pass0,da0) DEC DLT2000 8B37 at scbus0 target 1 lun 0 (pass1,sa0) QUANTUM LIGHTNING 730S 241E at scbus0 target 2 lun 0 (pass2,da1) PLEXTOR CD-ROM PX-12CS 1.00 at scbus0 target 6 lun 0 (pass3,cd0) at scbus0 target -1 lun -1 () troutmask:root[202] camcontrol tur cd0 -v Unit is ready troutmask:root[203] camcontrol inquiry cd0 pass3: PLEXTOR CD-ROM PX-12CS 1.00 Removable CD-ROM SCSI-2 device pass3: 10.000MB/s transfers (10.000MHz, offset 15) troutmask:root[204] mount /dev/cd0a /mnt mount: /dev/cd0a on /mnt: incorrect super block Note: it is an audio cd so I expect the mount to fail. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with Linux emulation
Thomas Schuerger wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
This happens when the install script wants to call {PREFIX}/sbin/ldconfig
(the Linux-ldconfig).
I rebuilt and reinstalled the linux emulation module, but that
didn_t help either.
Installing the above port will still cause a kernel panic.
I haven_t read this list for a while, so I might have missed
something important.
Any hints or ideas what might be going wrong? What can I do to make
it work again?
rant
You should be reading this list if you run -current!
/rant
Cvsup up to date sources.
Build a new kernel.
Install kernel.
Edit /etc/rc.conf to *not* load the linux module at boot time.
Reboot.
make world
Edit /etc/rc.conf to load the linux module at boot time.
Either reboot or kldload the linux module.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kernel breakage on SMP
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf vers.c linking kernel exception.o: In function `vm86_biosret': exception.o(.text+0x582): undefined reference to `MPrellock' exception.o: In function `Xintr0': exception.o(.text+0x11b4): undefined reference to `MPrellock' exception.o: In function `Xintr1': exception.o(.text+0x143c): undefined reference to `MPrellock' exception.o: In function `Xintr2': exception.o(.text+0x16bc): undefined reference to `MPrellock' exception.o: In function `Xintr3': exception.o(.text+0x193c): undefined reference to `MPrellock' exception.o(.text+0x1bbc): more undefined references to `MPrellock' follow *** Error code 1 Stop in /usr/src/sys/compile/TROUTMASK. troutmask:kargl[352] find /sys/i386 -name \*.\[sch\] | xargs grep MPrellock /sys/i386/include/asnames.h:#define _MPrellockMPrellock /sys/i386/include/asnames.h:#define _MPrellock_edxMPrellock_edx /sys/i386/include/lock.h: call_MPrellock ; \ /sys/i386/isa/apic_vector.s:call_MPrellock_edx /sys/i386/isa/ipl.s:call_MPrellock_edx /sys/i386/i386/mplock.s: * void MPrellock_edx(unsigned int *lock : %edx) /sys/i386/i386/mplock.s:NON_GPROF_ENTRY(MPrellock_edx) /sys/i386/i386/mplock.s:call_MPrellock_edx /sys/i386/i386/mplock.s:jmp _MPrellock_edx /sys/i386/i386/mplock.s:jmp _MPrellock_edx /sys/i386/i386/mplock.s:jmp _MPrellock_edx /sys/i386/i386/mplock.s:jmp _MPrellock_edx /sys/i386/i386/mplock.s:jmp _MPrellock_edx /sys/i386/i386/mplock.s:call_MPrellock_edx Are asnames.h and lock.h correct? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
removing enigma(1)
[Donning asbestos underwear] With the FreeBSD 4.0 code freeze fast approaching, are there any compelling reasons to keep enigma (src/usr.bin/enigma) in the source tree? Yes, I know it is a *small* utility, but 1. it provides rather weak encryption, 2. the crypto-distribution is available with stronger encryption, and 3. src/ports/security contains stronger encryption schemes. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
On Sat, Oct 26, 2002 at 11:42:02AM -0700, Tim Kientzle wrote: Peter Wemm wrote: 'make installworld' without ... a new kernel would be rather messy. ... a reminder of the sequence is probably in order: buildworld buildkernel installkernel reboot installworld reboot This _does_not_work_ because 'installkernel' does not update the bootblocks. It should. Otherwise, 'installkernel' is not filling it's contract: it is not ensuring that the next boot uses the new kernel. It works fine if you are already running 5.x with the newer bootblocks. You should only have to do the bootblock update once. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
On Mon, Oct 28, 2002 at 11:56:34AM -0800, Tim Kientzle wrote: M. Warner Losh wrote: Tim Kientzle [EMAIL PROTECTED] writes: : ... 'installkernel' is not filling it's contract: it is : not ensuring that the next boot uses the new kernel. Are you sure you need new bootblocks? I've not had issues and am pretty careless about when I do installworld vs installkernel. You need them for the 4.x - 5.0 upgrade, but I didn't think you've needed new ones for a long time now. In case you've forgotten, in another month or two, thousands of people are going to be upgrading from 4.x - 5.0. Those are going to be people who don't regularly read -current or even -stable. The upgrade process right now is getting pretty ugly and needs to be cleaned up some before release. Peter's comments that started this thread included info for people *already* running -current. He simply reviewed the *standard* procedure for updating a -current system. He was not addressing the 4.x to 5.0 upgrade path. Installing new boot blocks is a one time issue and it is not part of the standard updating procedure. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc in CURRENT fails as of 1200 GMT today
On Wed, Oct 30, 2002 at 08:55:05PM +, Daniel Flickinger wrote:
Sent: Wed, 30 Oct 2002 09:02:17 -0800 by Marcel Moolenaar
On Wed, Oct 30, 2002 at 04:48:23PM +, Daniel Flickinger wrote:
/usr/src/lib/libc/uuid/uuid_compare.c:31:18: uuid.h: No such file \
or directory
+ [snip]
+
+ and a couple pages of resulting syntax errors
+
+ I assume you didn't do a makeworld, but just a make in libc?
No, I go for broke...
make -j 4 -k -s ${TFLG} buildworld
What is ${TFLG}?
I just did
cvsup /root/supfile
cd /usr/obj
rm -rf *
cd /usr/src
make -j 4 buildworld
Everything built without a problem on my athlon system.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Thu, Oct 31, 2002 at 03:18:47PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : Nope. The only difference between 53 bits and 64 bits of precision is : just that: precision. The number of bits for expoentent is : independent of this. : : .125 ^ 2 = 0.015625 : .25 ^ 3 = 0.015625 : : So if I go from 3 digits of precision to 2 digits of precision for : my mantissa, in order to represent the same number, I need a larger : exponent. That's not how it works. The exponent is more like .125 * 2^3 vs .124 * 2^3 Both have exponent 3, but the differ by a bit or two in the mantissa. Loren already posted a pointer to What Every Scientist Should Know About Floating-Point Arithmetic by David Goldberg. But, for Terry edification http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf This is only 1 of 66100 hits from a google search with keywords floating point scientist. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: another include failure to find in buildworld
On Fri, Nov 01, 2002 at 12:50:38PM -0800, Marcel Moolenaar wrote: On Fri, Nov 01, 2002 at 07:23:04AM +, Daniel Flickinger wrote: This is another instance where the build is not reading from the /usr/obj tree, reading from /usr/include first. I don't think so. You cannot do cross-builds if you're messing up the include searches. I would suggest you check out a clean source tree, revert /usr/include to a state where you know it failed before (ie remove /usr/include/uuid.h for example) and start a *non-parallel* build without any options like -k or -s for target buildworld *AFTER* validating and preferrably nuking /etc/make/.conf. There's really no point complaining on the list about breakages that you only see. If the failure is real, we at least need to be able to reproduce it before we can fix it and so far you're the only one with problems. I'll do the same to make sure my claim that you're the only one who sees this has been verified for me for the latest sources... Don't waste your time, Marcel. Unless Daniel has changed his build procedure, he uses a custom script to do the builds. See http://www.freebsd.org/cgi/getmsg.cgi?fetch=491021+500131+/usr/local/www/db/text/2002/freebsd-current/20021020.freebsd-current -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 09:47:26AM -0800, Kris Kennaway wrote: On Sat, Nov 02, 2002 at 10:35:03AM -0500, Adam K Kirchhoff wrote: So is the current position on the matter that __sF is going to remain out of libc? Yes. This will break some commercially available software that can't easily replaced. kargl[248] f95 -V a.f90 NAGWare Fortran 95 compiler Release 4.2(468) Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K. f95comp version is 4.2(468) /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF' collect2: ld returned 1 exit status I seriously doubt that NAG will support both a 4.x and 5.x version of their compiler. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 10:58:41AM -0800, Will Andrews wrote: On Sat, Nov 02, 2002 at 10:10:31AM -0800, Steve Kargl wrote: This will break some commercially available software that can't easily replaced. kargl[248] f95 -V a.f90 NAGWare Fortran 95 compiler Release 4.2(468) Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K. f95comp version is 4.2(468) /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF' collect2: ld returned 1 exit status I seriously doubt that NAG will support both a 4.x and 5.x version of their compiler. That's why we have compat libs. compat4x should handle this unless I'm mistaken. It doesn't work the way you think. To understand the issues http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/\ www/db/text/2002/freebsd-current/20021013.freebsd-current -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote: I seriously doubt that NAG will support both a 4.x and 5.x version of their compiler. This shouldn't be a problem. The commercial software Should Not Be(tm) supporting something as variable as CURRENT, and with the STABLE libraries around in COMPAT mode, the compiler Will Just Work(tm) (or should with not much effort). By the time __sF is mainstream, I guess the vendor will have adapted their product to match. Win, win. No, it does not just work. The NAG f95 compiler generates a C file. The C file is compiled by gcc. f95 -o a a.f90 is equivalent to f95 -c -o a.c a.f90 gcc -o a a.c -lf96 -lm -lc libf96.so is linked against libc.so, which is a symlink to libc.so.4 on a 4.x system. libm.so and libc.so are symlinks that point to libm.so.2 and libc.so.5 on 5.x. You pick up the wrong libc.so in the above line. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 12:00:42PM -0800, Marcel Moolenaar wrote: On Sat, Nov 02, 2002 at 11:24:32AM -0800, Steve Kargl wrote: No, it does not just work. The NAG f95 compiler generates a C file. The C file is compiled by gcc. f95 -o a a.f90 is equivalent to f95 -c -o a.c a.f90 gcc -o a a.c -lf96 -lm -lc libf96.so is linked against libc.so, which is a symlink to libc.so.4 on a 4.x system. libm.so and libc.so are symlinks that point to libm.so.2 and libc.so.5 on 5.x. You pick up the wrong libc.so in the above line. I see where this is breaking. The compat libs work because binaries are already linked against them. What you're describing is a need to link against libc.so.4 whilst on a -current box. Much the same as developing under the Linuxulator: you're not using the native bits. The problem is not unsolvable, but you also need the 4.x headers to make it work. The first hurdle is getting NAG f90 to pick up a random C compiler. The random C compiler then has to pick up the 4.x headers and libraries by having an alternate system includes and libraries path. With GCC this should be simple enough. That's exactly the problem. I haven't been able to state it in the same manner as you. Alfred just committed a make.conf knob, WANT_COMPAT4_STDIO, that permits libc to be built with __sF visible outside of libc. I suspect most people will not need the knob, but it will allow commercial apps to run if need be. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 12:06:38PM -0800, Peter Wemm wrote: This is also solveable by setting a strategic symlink from libc.so - /usr/lib/compat/libc.so.4 in the f95 backend's search path. Does it do a gcc -o a a.c -L /usr/local/lib/f95 -lf96 -lm -lc or something like that? If so, you can put the libc.so symlink in there. I assume that the generated code doesn't contain #includes... If it does you'll also need to do something about that so that you get the right #includes. libf96.so is a 4.x binary. Even if it wasn't for __sF, you should be compiling with 4.x libraries and (if needed) 4.x headers, because you have parts of the 4.x stdio.h embedded in libf96.so. The only include that I any aware of is f95.h which mainly defines stuff in libf95 (e.g., a typedef for struct nagf95_complex). The verbose compiler output is below. Note, that the crt* files are also 5.x instead of 4.x. Maybe it's just good fortune, but NAG's f95 compiler works great on 5.x (except for the __sF snafu). -- Steve kargl[226] f95 -v -Wc,-v -Wl,-v a.f90 a.f90: Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) /usr/libexec/cc1 -lang-c -v -I/usr/local/lib/NAGWare -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -Dunix -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -D__unix__ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__ELF__ -D_LONGLONG -DBSD -DANSI_C -DINT64=long long -DPOW_IS_INACCURATE /var/tmp/a.051193.c -quiet -dumpbase a.051193.c -version -fsigned-char -o /var/tmp/cczLSErX.s GNU CPP version 3.2.1 [FreeBSD] 20021009 (prerelease) (cpplib) (i386 FreeBSD/ELF) GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease) (i386-undermydesk-freebsd) compiled by GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease). ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/local/lib/NAGWare /usr/include End of search list. /usr/bin/as -v -o a.o /var/tmp/cczLSErX.s GNU assembler version 2.13 [FreeBSD] 2002-10-10 (i386-obrien-freebsd5.0) using BFD version 2.13 [FreeBSD] 2002-10-10 Loading... Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) /usr/libexec/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /usr/local/lib/NAGWare/quickfit.o a.o -rpath /usr/local/lib/NAGWare /usr/local/lib/NAGWare/libf96.so /usr/local/lib/NAGWare/libf96.a -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o GNU ld version 2.13 [FreeBSD] 2002-10-10 Supported emulations: elf_i386_fbsd To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 08:42:35PM +, Mark Murray wrote: By the time __sF is mainstream, I guess the vendor will have adapted their product to match. Win, win. No, it does not just work. The NAG f95 compiler generates a C file. The C file is compiled by gcc. How about much effort? there _has_ to be some kind of way to specify which C library to use. The only work-around I know is documented in (watch the line wrap) http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/www\ /db/text/2002/freebsd-current/20021013.freebsd-current To recap, I can do f95 -c hello.f90 gcc -v -o hello -nostdlib \ /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o \ /usr/local/lib/NAGWare/quickfit.o hello.o /usr/local/lib/NAGWare/libf96.so\ -lm \ /usr/home/karg/tmp/minpack/lib/libc.so \ /usr/lib/crtend.o /usr/lib/crtn.o But, the 2nd and 6th lines in the gcc command use the crt* files from freebsd-current. The math library, -lm, is also from freebsd-current. /usr/lib/compat does contains neither a 4.x math library nor the crt* files. The libc.so in the above is a symlink kargl[274] ldd hello hello: libf96.so.1 = /usr/local/lib/NAGWare/libf96.so.1 (0x2806b000) libm.so.2 = /usr/lib/libm.so.2 (0x2810b000) libc.so.4 = /usr/lib/compat/libc.so.4 (0x28129000) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote: On Sat, 2 Nov 2002, Mark Murray wrote: This shouldn't be a problem. The commercial software Should Not Be(tm) supporting something as variable as CURRENT, and with the STABLE libraries around in COMPAT mode, the compiler Will Just Work(tm) (or should with not much effort). By the time __sF is mainstream, I guess the vendor will have adapted their product to match. Win, win. This isn't the case for one piece of vendor software that I'm not allowed to talk about. See the new WANT_COMPAT4_STDIO make.conf knob. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 06:36:31PM -0500, Matthew N. Dodd wrote: On Sat, 2 Nov 2002, Steve Kargl wrote: On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote: This isn't the case for one piece of vendor software that I'm not allowed to talk about. See the new WANT_COMPAT4_STDIO make.conf knob. This won't be acceptable as the vender will likely not be producing a separate 5.0 build (ie the same build needs to run on both.) until 4.x is EOLed. Forcing people to rebuild libc seems a high barrier to entry. Maybe I misunderstand you. But, a person running FreeBSD 5.x, who wants to runs this vendor's 4.x software, will need to build their libc with WANT_COMPAT4_STDIO defined if this product needs to see __sF. This is my exact problem. I have NAG's Fortran 95 compiler, which was built for FreeBSD 4.2. I ran it on 5.0 without a problem until __sF was made static. NAG may never release a 5.x version of their compiler because it may not be cost effective. This is a compromise to move forward with the elimination of the visibility of __sF. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 04:19:10PM -0800, Juli Mallett wrote: Keep in mind this only affects linking a closed library, and that this situation is a bit absurd, given that a reasonable solution exists, and if necessary, can be packaged up nicely... A bit absurd? Can you explain why it is absurb and can you give me the reasonable solution that you have? Developers using this sort of environment are asking for trouble. It seems to me a serious developer will develop where the tools are working and supported (keep in mind this is a issue with a vendor LIBRARY being LINKED in, not a TOOL being USED), The TOOL was working fine until __sF was made static. or set up a proper cross-env to target the platform where the library is targettted This is what I guess we'll have to do. or will force their vendor to support the new platform they (for whatever reason) see fit to develop on. Force the vendor to support the new platform? No, this will most likely cause the vendor to abandon the FreeBSD platform. So much for encouraging commercial support for FreeBSD. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sat, Nov 02, 2002 at 08:42:57PM -0800, Marcel Moolenaar wrote: On Sat, Nov 02, 2002 at 03:58:14PM -0800, Steve Kargl wrote: See the new WANT_COMPAT4_STDIO make.conf knob. This won't be acceptable as the vender will likely not be producing a separate 5.0 build (ie the same build needs to run on both.) until 4.x is EOLed. Forcing people to rebuild libc seems a high barrier to entry. Maybe I misunderstand you. But, a person running FreeBSD 5.x, who wants to runs this vendor's 4.x software, will need to build their libc with WANT_COMPAT4_STDIO defined if this product needs to see __sF. No; you're mixing things up. The compat4x stuff we have now allows you to run 4.x binaries on 5.x. The problem that WANT_COMPAT4_STDIO addresses is *compiling* 4.x compatible programs on 5.x! A world of difference. I just looked through /usr/lib on the 4.7 live ISO. We are missing a bunch of libraries. See another post with the list. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Ghost of __sF and COMPAT4X libraries.
Since I appear to one the few people caught by the __sF and commercial software broken by staticizing __sF, I decided to look at the 4.7 live filesystem ISO image to see what I would need to build a proper set of libraries. Here is a summary of what I found. List of shared libraries in 4.7 not included in COMPAT4X. libacl.so.3 libalias.so.4 libasn1.so.5libatm.so.2 libbz2.so.1 libcalendar.so.2 libcam.so.2 libcipher.so.2 libcom_err.so.2 libcrypt.so.2 libcrypto.so.2 libdes.so.3 libdevstat.so.2 libdialog.so.4libfetch.so.3 libform.so.2 libftpio.so.5libg2c.so.1 libgmp.so.3 libgnuregex.so.2 libgssapi.so.5 libhdb.so.5 libhistory.so.4 libipsec.so.1 libipx.so.2 libisc.so.1 libkadm.so.3libkadm5clnt.so.5 libkadm5srv.so.5 libkafs.so.3 libkdb.so.3 libkrb.so.3 libkrb5.so.5 libkvm.so.2 libm.so.2 libmd.so.2 libmenu.so.2 libmilter.so.2libmp.so.3 libncp.so.1 libncurses.so.5 libnetgraph.so.1 libopie.so.2libpanel.so.2 libpcap.so.2 libposix1e.so.2 libradius.so.1 libreadline.so.4 libroken.so.5librpcsvc.so.2libskey.so.2libsmb.so.1 libssh.so.2 libssl.so.2 libtacplus.so.1 libusbhid.so.0 libutil.so.3 libvgl.so.2 libwrap.so.3libxpg4.so.3 libz.so.2 libgcc.a on 4.7 contains references to __sF. There is no libgcc.so. The following libraries are installed by COMPAT4X, but are not present in 4.7. I assume these are carried forward from 4.x x 7. libssl.so.1 libusb.so.0 libcrypto.so.1 libfetch.so.2 The following 4.7 libs make reference to __sF. Several of the corresponding 5.0 libraries still have the same version number. We may need to bump the version numbers. libalias.so.4libbz2.so.1 libc.so.4libc_r.so.4 libcam.so.2 libcom_err.so.2 libcrypto.so.2 libdes.so.3 libdevstat.so.2 libdialog.so.4libedit.so.3 libfetch.so.3 libftpio.so.5libg2c.so.1 libgmp.so.3 libhistory.so.4 libipsec.so.1libisc.so.1 libkdb.so.3 libkrb.so.3 libkrb5.so.5 libkvm.so.2 libm.so.2libmp.so.3 libncp.so.1 libncurses.so.5 libopie.so.2 libpam.so.1 libpcap.so.2 libperl.so.3 libreadline.so.4 libroken.so.5 libskey.so.2 libsmb.so.1 libssh.so.2 libstdc++.so.3 libutil.so.3 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: another include failure to find in buildworld
On Sun, Nov 03, 2002 at 10:04:06AM +, Daniel Flickinger wrote: Sent: Fri, 1 Nov 2002 12:59:33 -0800 by Steve Kargl + Don't waste your time, Marcel. Unless Daniel has changed his + build procedure, he uses a custom script to do the builds. I stated the conditions at the top of my report: from cvsup *default date=2002.11.01.06.00.00: rm -rf /usr/obj/usr make -j 4 -k -s buildworld ... IN OTHER WORDS, I WAS NOT USING A SCRIPT. Secondly, -k and -s do NOT mask errors; if anything, they make them more visible. I am methodical and thorough, but I don't piss against the wind, Steve; consider the issue closed. I am considering it closed. I just updated 2 pre-uuid systems and did not hit the problem you had. You're the only person reporting the problem. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sun, Nov 03, 2002 at 03:29:04AM -0800, Juli Mallett wrote: * De: Steve Kargl [EMAIL PROTECTED] [ Data: 2002-11-02 ] [ Subjecte: Re: __sF ] On Sat, Nov 02, 2002 at 05:40:08PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] You should be linking against the -stable versions of these items as well as the libc.so.4. If you don't, then you are asking for problems. Maybe you can kludge it to make libc.so.5 work, but the whole reason that it is .5 and not .4 is that it is not binary compatible with .4, and for more reasons than just __sF. Fine, I'll try to set up a cross build enviroment. But, we need to then install a complete set of 4.x libraries in /usr/lib/compat. No, that's for runtime compatability. You want a true cross environment. Read any of the thousands of pages about setting up GCC for cross-platform development, as that's what you're doing. You just happen to have a chance of running the cross-created things locally. Let's say I have an 4.7 app linked against libcam.so. Now, I update to 5.0. What library will this app use? There isn't a COMPAT4X library available and the 5.0 has the same version number and libcam.so has a reference to __sF. There probably aren't many apps that use libcam, so this is perhaps stretch. Well, consider libm.so and the 8000 ports. As to my particular problem, a cross-platform environment won't be of much use because NAG hard-coded several paths into their app, e.g., /usr/bin/cc. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
On Sun, Nov 03, 2002 at 09:28:24AM -0800, Juli Mallett wrote: * De: Steve Kargl [EMAIL PROTECTED] [ Data: 2002-11-03 ] [ Subjecte: Re: __sF ] As to my particular problem, a cross-platform environment won't be of much use because NAG hard-coded several paths into their app, e.g., /usr/bin/cc. Then you should seriously consider the quality of such application, or whether you'd be better using it on an actual and supported platform. Anything less would be uncivilised. (Seriously) This is the *only* native Fortran 95 compiler for FreeBSD. So much for acceptance of FreeBSD by commerical vendors. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hello World stuck in infinite loop
On Tue, Nov 05, 2002 at 11:07:02AM -0800, Chad Parry wrote:
I'm seeing an infinite loop that can be traced to a signal handler in the
uthread module. I'm using a snapshot of CURRENT from 2002-01-09.
Repro:
Write the classic hello world program. When you build it, link in
libc_r. Use a shell script to execute it over and over in a tight
loop. This works on my box (using zsh):
# echo 'main() { printf(Hello World!\\n); }' hello.c
# gcc -o hello hello.c -lc_r
With the -v flag, you find
/usr/bin/ld -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o h /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /var/tmp/ccGisSmu.o -lc_r
-lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
What happens if you use
gcc -v -o hello -pthread hello.c
/usr/bin/ld -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o h1 /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /var/tmp/ccjfgwUn.o -lgcc
-lc_r -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
Note the order of the libraries.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Why is my -current system Hard Locking?
This sounds good, but isn't it. X doesn't have control of the graphics and kbd on my system. Only xdm and clients are running, the server is on another system. When panics happen ( and they have ) I get the message on the screen. Also this problem has been happening both with X running and not. Any other suggestions? If it happens without X running, then you should drop into the debugger and get a backtrace and crash dump. Do you have known method of inducing the panic? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Wed, Nov 06, 2002 at 04:38:55PM -0800, Terry Lambert wrote: Steven G. Kargl wrote: Could someone add the following patch to UPDATING? Change the words to whatever suits your fancy. +20021031 + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static. + This changes the visibility of __sF to a symbol internal to + libc. All applications linked against libc or a library that + depends on libc that were compiled prior to 31 Oct 2002 will + need to be updated after a make world. An error message that + includes undefined reference to `__sF' is an indication that + that application needs to be recompiled. + Any chance we could get rid of all externally visable symbols that are not defined as being there by some standard, and not just __sF, since we are breaking the FORTRAN compiler and other third party code already? This isn't restricted to my Fortran 95 problem, which I've found an acceptable work-around. I just spent the better part of a day re-installing 122 ports because these ports were linked against an earlier libc. All of this is 3rd party software. But, if you have a pre-20021031 world and you build only a post-20021021 libc, then a whole bunch of libraries in /usr/lib will becomed unusable. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree
On Wed, Nov 06, 2002 at 09:34:39PM -0500, Horen wrote: Posted a week ago the question, didn't get any reaction. Everything with current from last night works fine but killing X or logging out ends in a black screen. No way to activate the display without reboot. Remote login is fine. Typing blind works too. Is there a fix in sight, would be great help. I just rebuilt world and XFree86 4.2.1. I killed and restarted X several times while getting my fvwm2 desktop back to normal. I didn't have this black screen problem. How old is your X and desktop? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Thu, Nov 07, 2002 at 08:40:32AM -0800, John Polstra wrote: In article [EMAIL PROTECTED], M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Steven G. Kargl [EMAIL PROTECTED] writes: : Could someone add the following patch to UPDATING? : Change the words to whatever suits your fancy. I'm trying to devise a good way to deal with this breakage and hope it is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on -current is to make __sF global again and arrange for: stdin == __sF[0] stdout == __sF[1] stderr == __sF[2] John, As the author of cvsup, I'm sure you know what is required. But, I rebuilt cvsup from net/cvsup yesterday on a new world, and it appears to be working fine. What problems should I expect? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Thu, Nov 07, 2002 at 09:21:53AM -0800, John Polstra wrote: In article [EMAIL PROTECTED], Steve Kargl [EMAIL PROTECTED] wrote: I rebuilt cvsup from net/cvsup yesterday on a new world, and it appears to be working fine. What problems should I expect? It's possible that if you already have a working installation of pm3 or ezm3, you'll be able to build CVSup on -current. But if you try to build pm3 or ezm3 from scratch, you'll find that the build fails. I removed all ports because of the __sF symbol problem. I simply did cd /usr/ports/net/cvsup ; make install and this automatically installed ezm3. pkg_info doesn't show pm3 installed on system. Perhaps, only pm3 is the port that will have the problem. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Thu, Nov 07, 2002 at 09:35:19AM -0800, John Polstra wrote: In article [EMAIL PROTECTED], Steve Kargl [EMAIL PROTECTED] wrote: On Thu, Nov 07, 2002 at 09:21:53AM -0800, John Polstra wrote: It's possible that if you already have a working installation of pm3 or ezm3, you'll be able to build CVSup on -current. But if you try to build pm3 or ezm3 from scratch, you'll find that the build fails. I removed all ports because of the __sF symbol problem. I simply did cd /usr/ports/net/cvsup ; make install and this automatically installed ezm3. pkg_info doesn't show pm3 installed on system. Perhaps, only pm3 is the port that will have the problem. That would surprise me, but I haven't tried it myself. Inspection of the ezm3 bootstrap shows that it has references to __sF. Well, I just pkg_deinstall's both ezm3 and cvsup. I re-installed both without problems. I then used cvsup to pull down some source updates. However, here's the strange or maybe fortunate part troutmask:kargl[246] cd /usr/local/lib/m3 troutmask:kargl[247] find . -name \*.a | xargs nm -A | grep __sF ./pkg/m3core/FreeBSD4/libm3core.a:Cstdio.mo: U __sF troutmask:kargl[248] strings /usr/local/sbin/cvsupd | grep __sF troutmask:kargl[249] strings /usr/local/bin/cvsup | grep __sF -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, Nov 08, 2002 at 12:17:00PM -0500, Daniel Eischen wrote:
On Fri, 8 Nov 2002, M. Warner Losh wrote:
Yes, but this is too painful. If we were going to do this, the time
for the pain was 6-9 months ago, not just before the release.
All the ports are going to be rebuilt for the release anyways,
so this doesn't affect fresh installs, correct? It is only a
problem when mixing older 4.x and 5.0 libraries/binaries with
__sF-free libc (if I understand things correctly).
This is 5.0; it is a major release and there will be some flies
in the ointment. I say bite the bullet now -- don't wait.
I agree with Dan. Let's do it now. My understanding is
that 5.0 will be an early adopter release and production
systems should run 4.7{8,9,..} until 5.1 is released.
To accomplish the change, I think we need to do:
1. Install a complete set of 4.7 shared libs in COMPAT4X.
This should porivde the necessary runtime compatibility
with 4.x.
2. Bump all shared library on 5.0. This will get rid of
any interdependencies among the libraries and it deals
with the version number problems I detailed in the thread
Ghost of __sF ... a couple a days ago.
3. Put a big fat WARNING in src/UPDATING about the problem
4. Put the same WARNING in /etc/motd, so people currently
run -current will know to update their ports.
5. Broadcast the WARNING to appropriate mailing lists and
newsgroups.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Sat, Nov 09, 2002 at 04:16:11AM +1000, Andrew Kenneth Milton wrote: 6. Assume Crash Position. Thanks for your important contribution to a discussion which is addressing a rather serious problem. Here's the important part of the Ghost... thread. The following 4.7 libs make reference to __sF. libalias.so.4libbz2.so.1 libc.so.4libc_r.so.4 libcam.so.2 libcom_err.so.2 libcrypto.so.2 libdes.so.3 libdevstat.so.2 libdialog.so.4libedit.so.3 libfetch.so.3 libftpio.so.5libg2c.so.1 libgmp.so.3 libhistory.so.4 libipsec.so.1libisc.so.1 libkdb.so.3 libkrb.so.3 libkrb5.so.5 libkvm.so.2 libm.so.2libmp.so.3 libncp.so.1 libncurses.so.5 libopie.so.2 libpam.so.1 libpcap.so.2 libperl.so.3 libreadline.so.4 libroken.so.5 libskey.so.2 libsmb.so.1 libssh.so.2 libstdc++.so.3 libutil.so.3 Here's the fun part. The following 5.0 libraries have the same version number as their 4.x counterparts. Try running a 4.x app linked against one of these libaries on a 5.0 machine. You should also note that this list may not be complete list of libraries suffering this problem. libalias.so.4libbz2.so.1 libcam.so.2 libcom_err.so.2 libcrypto.so.2 libdes.so.3 libdialog.so.4 libfetch.so.3 libftpio.so.5libg2c.so.1 libhistory.so.4 libipsec.so.1 libisc.so.1 libkvm.so.2 libm.so.2libncp.so.1 libncurses.so.5 libopie.so.2 libpcap.so.2 libreadline.so.4 libsmb.so.1 libssh.so.2 libutil.so.3 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Fri, Nov 08, 2002 at 05:05:23PM -0800, Brooks Davis wrote:
On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
I'd love for there to be a way to know which binaries use __sF.
The following script run on your bin, sbin, lib, and libexec directories
does a pretty decent job of finding files that contain refrences to __sF
and listing the ports that use them (depend on portupgrade).
#!/bin/sh
sym=__sF
for file in $*; do
if [ -n `nm ${file} 21 | egrep ${sym}$` ]; then
echo ${file} `pkg_which $file`
fi
done
nm doesn't work on shared libraries. You can
use strings to find __sF in shared libs.
troutmask:kargl[201] cd /mnt/usr/lib/
troutmask:kargl[202] nm libm.a | grep sF
U __sF
troutmask:kargl[203] nm libm.so.2 | grep sF
nm: libm.so.2: no symbols
troutmask:kargl[204] strings libm.so.2 | grep sF
__sF
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: after cvsup make chinpui3 get undefined reference error
On Thu, Nov 14, 2002 at 03:00:51PM -0800, Kris Kennaway wrote: On Thu, Nov 14, 2002 at 08:31:43AM +0800, suken woo wrote: g++ -o chinput chinput.o init.o server.o config.o color.o util.o convert.o IC.o XIM.o focus.o root.o overspot.o onspot.o offspot.o voice.o keyboard.o handw.o hwengine.o loop.o -L/usr/X11R6/lib -lXext -lX11 ./IMdkit/lib/libXimd.a -L../../unicon-im/client -L../../unicon-im/server -limmclient -Wl,-rpath=/usr/local/lib/Chinput/im -limm_server -lc_r -lc -lImlib ../../unicon-im/server/libimm_server.so: undefined reference to `ostream::operator(char const*)' ../../unicon-im/server/libimm_server.so: undefined reference to `cout' *** Error code 1 Again, it's unfortunate but expected that many ports fail to build on -current. There's not much point in reporting them (they're all listed at http://bento.freebsd.org) unless you can supply a patch to fix it. I just had 3 PR (44290,44291,45201) closed because no one would commit the patches to fix the builds on -current. Two of these PRs were submitted almost a month ago. So, supplying patch hardly guarantees the port will be fixed. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NetBSD ftpd security advisory
NetBSD.org has a security advisory about potential problems with their ftpd. If this is part of lukemftp, then the issue of removing/updating lukemftp needs to be addressed for FreeBSD 5.0 RELEASE. ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2002-027.txt.asc -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
On Wed, Nov 20, 2002 at 08:14:49PM -0800, David O'Brien wrote: On Wed, Nov 20, 2002 at 05:57:41PM +0100, Marc Recht wrote: Hi! Will gcc 3.2.1/release be imported before 5.0R ? Just curious.. There will be no more GCC imports before 5.0-R. It is just too much code churn with too little road testing before 5.0-R. David, Can you close PR gnu/44426? It details a bug in FreeBSD's pre-release version of 3.2.1, which is fixed in more recent 3.2.1 sources. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more info - Re: panic: sleeping thread owns a mutex - with debug traceback
On Wed, Nov 20, 2002 at 09:59:32PM -0800, Joel M. Baldwin wrote: --On Wednesday, November 20, 2002 9:47 PM -0800 Nate Lawson [EMAIL PROTECTED] wrote: Wow, I haven't seen so many panics from one person before. Tried memtest86.com yet? yes, LONG before I posted the first time. I've even swaped the memory from another system. The problem ISN'T the memory. Please don't top post. Have you tested the power supply? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
On Thu, Nov 21, 2002 at 10:22:42PM -0800, Terry Lambert wrote:
Marc Recht wrote:
So it's been extensively tested by the full user base for the
last two days, and you should have known about it before you
posted. 8-) 8-).
My original question was only if it will be imported before 5.0R. David
O'Brien already answered it with no. That's fine with me.
Don't worry about it; it's being totally blown out of proportion;
there's no way anyone will commit to importing a 2 day old 3.2.1,
which is why I put the smiley's there.
Well, the 2-day old 3.2.1 fixes numerous problems
with our 3.2.1 [FreeBSD] 20021009 (prerelease).
Compiling this
void ice(int m, int n, double *f) {
int i, j;
for (j = 0; j n; j++) {
for (i = 1; i m; i++) {
f[i] = (double) (i * j);
f[i + j] = (double) ((i + 1) * j);
}
}
}
with gcc -O2 -c yields an ICE in FreeBSD-current.
The 2-day old gcc 3.2.1 does not blow chucks on the
above code.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
On Fri, Nov 22, 2002 at 03:37:53AM -0800, Terry Lambert wrote: Steve Kargl wrote: Don't worry about it; it's being totally blown out of proportion; there's no way anyone will commit to importing a 2 day old 3.2.1, which is why I put the smiley's there. Well, the 2-day old 3.2.1 fixes numerous problems with our 3.2.1 [FreeBSD] 20021009 (prerelease). Compiling this [[code elided] with gcc -O2 -c yields an ICE in FreeBSD-current. The 2-day old gcc 3.2.1 does not blow chucks on the above code. What does it do for all the other code in -ports, and in the comp.source.* archives, and that anyone else has ever written, such that you know it doesn't cause more problems than it solves? FreeBSD 5.0 is scheduled for a 15 Dec 02 release. We have 24 days to find the problems. With the recent spat of problems reported after DP2 was released, I suspect 15 Dec 02 is optimistic. Supposedly, bringing in 3.2 was going to solve more problems than it caused. It turns out the 4.x compiler, GCC 2.95.3, also does not have an ICE as a result of compiling that code. You know the reason why 3.2 pre-release was brought into the tree, right? GCC has changed the C++ ABI between 3.1.1 and 3.2. If FreeBSD 5.0 shipped with 2.95.3, then 5.x would use 2.95.3 until 6.0 was released. Try getting support from the GCC folks for 2.95.3. I respect David's judgement about bringing 3.2.1 into the tree, but your statement above (totally blown out...) suggests you don't follow GCC development. Several significant bugs were fixed between our pre-release version and 3.2.1. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installworld and stale {include,lib} fun
On Sat, Nov 23, 2002 at 10:36:16AM +, Mark Murray wrote: Apparently editors/vim-lite had picked up an old, obsolete libposix*.so from one of the past installations and linked against that. Deleting the port and reinstalling it worked like a charm, which made me think a bit... Should we recommend in UPDATING that source upgrades include something similar? Well, maybe not all the time (since ports can break like vim did for me), but at least under a making your /usr as clean as possible paragraph? I would support this, as long as it was not compulsory. As demonstrated, you probably don't want to remove the old libraries. It is much better to do something like find /usr/lib -type f | xargs touch sleep 60 cd /usr/src make installworld You can now look for older stale (shared) libraries and then search /usr/local/bin for binaries that use those libraries. Note, the above doesn't work if you use install -C -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: '-ax' option in gcc
On Sat, Nov 23, 2002 at 07:26:00PM +0100, Miguel Mendez wrote: On Sat, 23 Nov 2002 18:21:09 +0100 Jens Rehsack [EMAIL PROTECTED] wrote: You may also read http://gcc.gnu.org/ for details 'bout the new compiler and http://gcc.gnu.org/news/profiledriven.html for information about the new Infrastructure for Profile Driven Optimizations. Yes, thanks for the info, FWIW I think it's quite against POLA to remove an option yet keep it documented in the man page :) The official documentation for gcc is gcc.info. The man page(s) easily get out of sync. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syslog:soffice.bin (ooo-1.0.1) sched_get_priority_min/max
On Thu, Nov 28, 2002 at 01:19:22AM +, Daniel Flickinger wrote: This does seem to cure the sched_get_priority_min/max signals from ooo, but ooo crashes everytime you close a file unless you have another active file in a second window ... nice/PIA. make sure you save your work early and often, just like voting in Boston. It works fine for me, but then again I try to avoid Office suites as much as possible. I only use it when someone sends me an MS Word, Powerpoint, or Excel attachment. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: missing: usr.bin/rdist - used: ports/net/rdist6
On Fri, Nov 29, 2002 at 12:48:49AM +0100, Julian H. Stacey wrote: Kris Kennaway wrote: On Thu, Nov 28, 2002 at 07:22:16PM +0100, Julian Stacey wrote: 5.0-DP2 (unlike 4.7) has no src/usr.bin/rdist - just ports/net/rdist6 =20 rdist6 is supposed to be better, but no rdist after basic install is a pa= in. =20 Has this been well debated already ? or should I file a Send-PR ? It was moved to the 44bsd-rdist port, because it's not particularly useful thesedays in the fact of better tools like rsync. Thanks Kris, - But Rsync (1.5M) is also not in src/ ! Is there some reason you can't install it from /usr/ports/net/rsync? - Rdist(1) is in the 4.3 UCB blue ring bound URM manual. Principle of least suprise could have left it. Rdist is more generic on older Unixes, which often have no rdist6 or rsync. When was 4.3 UCB released? - Does src/ have anything protocol compatible with most other older /or commercial Unix bases ? Is there some reason you can't install /usr/ports/net/44bsd-rdist? - 4.3 UCB URM does not even list man fortune(1) yet 5.0-DP2 src/games/fortune bloats 3735K. ports/net/44bsd-rdist takes 297K, 4.7 src/usr.bin/rdist is just 114K. The size of fortune is irrelevant. - Please consider restoring rdist to FreeBSD. Thanks. No thanks. It was removed almost 2 years ago because better alternatives are available. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Harry Potter and the Disappearing Disklabel
On Fri, Nov 29, 2002 at 09:41:56AM -0500, Wesley Morgan wrote: I've seen one post similar to this, but not much else. I think maybe the UFS2 problem had to do with Kirk's recent changes, but the disklabel issue... I'm wary to reboot my machine! What in the hell could be causing this? I'm tempted to point the finger at GEOM, but hate to say anything like that. Are your world and kernel in sync (post-kirk commit)? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvsup weird problem [gcc-3.2.1 commit problem?]
On Fri, Dec 06, 2002 at 01:18:57AM +0800, leafy wrote: On Thu, Dec 05, 2002 at 07:13:23PM +0200, Giorgos Keramidas wrote: Been there, done that - several times :) Hmmm, try a different cvsup server then. I just updated from cvsup.gr.freebsd.org and all seems fine. The files are still there, but nothing breaks... Connected to cvsup.gr.freebsd.org Updating collection src-all/cvs Delete src/contrib/gcc/INSTALL Cannot delete /usr/src/contrib/gcc/INSTALL: Directory not empty You will get it eventually :) cvsup3.freebsd.org and cvsup7.freebsd.org also give the the error message. However, Giorgos is right in that nothing breaks because of this problem. cvsup complete and I suspect make buildworld will succeed because the contents of src/contrib/gcc/INSTALL are not used. I also suspect that David accidentally committed the html files. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Jailing a 4.7 environment on 5.0?
Is is possible to set up a jail that contains 4.7 on a 5.0 system? In particular, how does one deal with the difference between devfs and MAKEDEV? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Jailing a 4.7 environment on 5.0?
On Thu, Dec 12, 2002 at 01:56:40PM +1300, Andrew Thompson wrote: On Thu, 2002-12-12 at 13:52, Kris Kennaway wrote: On Wed, Dec 11, 2002 at 04:19:31PM -0800, Steve Kargl wrote: Is is possible to set up a jail that contains 4.7 on a 5.0 system? Yes. But doesnt a jail share the same kernel? (I have never set one up so I dont know what I am talking about :) Yes, it does use the same kernel. If you read the jail(8) man page, it discusses setting up a jail on a 4.x system. The first section contains This example shows how to setup a jail directory tree containing an entire FreeBSD distribution: D=/here/is/the/jail cd /usr/src mkdir -p $D make world DESTDIR=$D cd etc make distribution DESTDIR=$D cd $D/dev sh MAKEDEV jail cd $D ln -sf dev/null kernel Clearly, this doesn't work on a 5.0 system if you want to set up a 4.7 jail. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Jailing a 4.7 environment on 5.0?
On Wed, Dec 11, 2002 at 05:17:12PM -0800, Kris Kennaway wrote: On Wed, Dec 11, 2002 at 05:08:46PM -0800, Steve Kargl wrote: This example shows how to setup a jail directory tree containing an entire FreeBSD distribution: D=/here/is/the/jail cd /usr/src mkdir -p $D make world DESTDIR=$D cd etc make distribution DESTDIR=$D cd $D/dev sh MAKEDEV jail cd $D ln -sf dev/null kernel Clearly, this doesn't work on a 5.0 system if you want to set up a 4.7 jail. Replace the 'cd %D/dev; sh MAKEDEV jail' with 'mount -t devfs / $D/dev' Thanks for the pointer. The entire example doesn't apply because my /usr/src is FreeBSD 5.0. I have 4.7-disc2.iso and used a md device to copy the files into a jail. It appears to work, but I have a few more things to set up. I'll report with a full description of what I'm doing later. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Jailing a 4.7 environment on 5.0?
On Wed, Dec 11, 2002 at 08:07:14PM -0800, Kris Kennaway wrote:
On Wed, Dec 11, 2002 at 07:34:05PM -0800, Steve Kargl wrote:
Replace the 'cd %D/dev; sh MAKEDEV jail' with 'mount -t devfs / $D/dev'
Thanks for the pointer. The entire example doesn't
apply because my /usr/src is FreeBSD 5.0. I have
4.7-disc2.iso and used a md device to copy the files
into a jail. It appears to work, but I have a few more
things to set up. I'll report with a full description
of what I'm doing later.
Um, that's not what I said at all. Just use devfs and be done with
it. Your way isn't likely to work now (different device numbers
between 5.0 and 4.x) or in the future (future changes to how devices
work).
You misunderstood. Here's the example again from jail(8).
D=/here/is/the/jail
cd /usr/src
mkdir -p $D
make world DESTDIR=$D
cd etc
make distribution DESTDIR=$D
cd $D/dev
sh MAKEDEV jail
cd $D
ln -sf dev/null kernel
My /usr/src is FreeBSD 5.0. I need a 4.7 environment.
I cannot do steps 2 and 4-8. I did
mkdir /usr/jail
mdconfig -a -t vnode -f 4.7-disc2.iso -u 0
mount /dev/md0 /mnt
cp -pR /mnt/bin /usr/jail
cp -pR /mnt/sbin /usr/jail
cp -pR /mnt/usr /usr/jail
cp -pR /mnt/etc /usr/jail
cp -pR /mnt/var /usr/jail
mkdir /usr/jail/dev
mount -t devfs / /usr/jail/dev
cd /usr/jail
ln -sf dev/null kernel
I'm now ready to configure the jail for my proposes.
What I could not determine from jail(8) was how to
set up /usr/jail/dev. You gave me the pointer to
setting up devfs.
For my application, I need jail/dev/{null,stdin,stdout,
stderr}, gcc 2.9.4, whatever version of binutils is
used on 4.7, and /usr/lib/lib{c,m}.so.X and libgcc.a
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: TTL
On Fri, Dec 13, 2002 at 09:14:06PM -0800, Jimi Thompson wrote: This is an issue that we recently ran into at work and I wanted to mention this since 5.0 isn't released yet. I don't know if FreeBSD has addressed this or not but thought it should be mentioned just in case. We've discovered that in many *nix OS's the TCP stack sets the default TTL for packets to 30. Apparently, IBM (AIX) had not and our research showed that most of the other *nix OS's hadn't either. With the increasing complexity of the internet, this is often a problem for those who have large internal networks and/or live in Australia. 30 hops often isn't enough to make to the core DNS. It probably ought to be extended to something more realistic. The other numbers that I've seen used 64, 128, and 256. troutmask:sgk[202] sysctl -a | grep -i ttl net.inet.ip.ttl: 64 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: compat4x
On Mon, Dec 16, 2002 at 03:37:58AM +0100, Harald Hanche-Olsen wrote: Shouldn't libposix1e.so.2 have been part of the compat4x package? I came across at least one program that uses it. There are numerous libraries missing from compat4x. A worse problem is that several 4.x shared libs have the same version number as 5.x libs (e.g., libm.so.2). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: script bug: rc.sendmail
On Sun, Dec 22, 2002 at 12:06:02AM -0600, Geoffrey T. Falk wrote: To disable sendmail, one expects to set sendmail_enable=NO in /etc/rc.conf. /etc/rc.sendmail looks for sendmail_enable=[Nn][Oo][Nn][Ee] (should be [Nn][Oo] to conform with standard usage.) The consequence is that an administrator may intend to disable sendmail, but it will still be enabled. man rc.sendmail -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
acpi panic
A kernel (and world) built from -current sources from Sunday morning about 9 am PST yields: panic: pmap_mapdev: Couldn't alloc kernel virtual memory Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx, in_Debugger.0 db tr panic AcpiOsMapMemory AcpiTbGetThisTable AcpiTbGetTableBody AcpiTbGetTable AcpiTbGetTableRsdt AcpiLoadTables acpi_identify bus_generic_probe nexus_attach device_probe_and_attach probe_and_attach root_bus_configure configure mi_strartup begin I get an instant reboot if I try to get a coredump, and the machine does not have a serial console. The panic is 100% reproducible, so I can get additional info if requested. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT: buildworld failure: sbin/swapon
On Sat, Dec 28, 2002 at 06:35:15PM +, Daniel Flickinger wrote: Sent: Fri, 27 Dec 2002 03:03:46 -0800 by Kris Kennaway: | | Well, -current builds fine for me using the 'proper' mechanism, so | if you want to be different you're basically on your own :-) It builds for me too. OK; but it still non-builds swapon with the includes from the running 1200 GMT 08 Dec. Pre-building the includes is irrelevant but to avoid your dismissal, I'll do it your way --and, I believe, we are both using the same system: Tyan 2462 SMP: rm -rf /usr/src/* rm -rf /usr/obj/* cvsup supfile-date [*default date=2002.12.27.12.00.00] What is contents of supfile-date? make buildworld What is contents of /etc/make.conf? Bottom line: where is 'swapoff(char *str)'? libc -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
On Tue, Jan 14, 2003 at 03:22:02AM +1000, Andy Farkas wrote: Once again it's my pleasure to announce Release Cadidate 3 of FreeBSD 5.0. Sysinstall complains about not being able to find the 'crypto' stuff, but thats ok - its always done that. Obviously, this isn't okay. No go for 5.0-RC3: # pkg_add cvsup-without-gui-16.1f.tgz /usr/libexec/ld-elf.so.1: Shared object libssl.so.2 not found # Why does pkg_install now need libssl? troutmask:kargl[251] ldd /usr/sbin/pkg_add /usr/sbin/pkg_add: libfetch.so.3 = /usr/lib/libfetch.so.3 (0x28074000) libmd.so.2 = /usr/lib/libmd.so.2 (0x2808) libssl.so.2 = /usr/lib/libssl.so.2 (0x2808a000) libcrypto.so.2 = /usr/lib/libcrypto.so.2 (0x280b9000) libc.so.5 = /usr/lib/libc.so.5 (0x2817f000) I suspect your previous success in upgrading was accomplished because the version number of libssl didn't change. Many of the shared libraries in 5.0 have version number bumps, including libssl.so.2. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Alternative way to do -stable to -current upgrade
Nik Clayton wrote: 5. Mount all the fixed disk partitions, and then (assuming they're all mounted under /mnt/root) cd /mnt/root/usr/src make DESTDIR=/mnt/root 7. Build and install a new kernel Come on then, which is it? Okay, here's some feedback ;-) In 5. above, is "make DESTDIR=/mnt/root" missing "world" or "installworld"? AFAIK, a plain "make DESTDIR=/mnt/root" will not do the install portion. If this is the case, then you better make sure the /modules agrees with your 7., or people loading modules during the reboot will be screwed. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sshd in current....no config files in /etc/ssh
William Woods wrote: OK, well, I useally merge files by hand because I am not familiar with mergemaster..how would I do this by hand? man mergemaster If you insist on doing it by hand, start with "diff -urN /etc /usr/src/etc" -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sshd in current....no config files in /etc/ssh
troutmask:root[204] locate sshd_config /usr/local/etc/sshd_config /usr/src/crypto/openssh/sshd_config man locate man 8 sshd William Woods wrote: Good god, I am saying that the files to merger dont existthere is nothing to merge... I don't see you making that statement below. You said "OK, well, I useally merge files by hand because I am not familiar with mergemaster..how would I do this by hand?" "man mergemaster" will familiarize you with the command. "diff ..." is how you might start to do it by hand. If a file does not appear to exist (oh, ah, such as /etc/sshd_config), try RTFM. This is the eror I get when trying to run ssdd /etc/ssh/sshd_config: No such file or directory the file sshd_config does not exist on my system to merge... On 07-Mar-00 Steve Kargl wrote: William Woods wrote: OK, well, I useally merge files by hand because I am not familiar with mergemaster..how would I do this by hand? man mergemaster If you insist on doing it by hand, start with "diff -urN /etc /usr/src/etc" -- Steve -- E-Mail: [EMAIL PROTECTED] Date: 07-Mar-00 Time: 11:29:42l -- NOTICE TO BULK E-MAILERS: Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, and all unsolicited commercial e-mail sent to this address is subject to a download and archival fee in the amount of $500 US -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Error code 2
KAMIL MUHD wrote: Hi everyone... I got this error evrytime I try to make world no matter how often I cvsup'ed. I don't know what it is, what is Error code 2 anyway? Is my cc version is out-of-date? I'm using the GNU gcc-2.95.1. My box is running on 4.0-CURRENT. Any idea? Is it because I've cvsuped the wrong file? I cvsuped the 4.x-secure-stable-supfile and 4.x-stable-supfile. cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational In /etc/make.conf, you should comment out WANT_CSRG_LIBM. The default math library is in src/lib/msun. Why the csrg math library is still in the src tree is somewhat of a mystery to me. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
remove src/lib/libm from source tree
Is there any compelling reason for retaining src/lib/libm in the source tree? Yes, I realize that libm is the original libm from CSRG 4.4 BSD-lite. However, the errors noted below have been in the source since 1994 when rgrimes imported the initial sources. The only person that I can of that may have a working copy of libm is bde. Additionally, with Martin Craucer's recent FP work, I think PR i386/105 have become fixed: a [1995/01/11] i386/105 bde Distributed libm (msun) has \ non-standard error handling. -- Steve cd /usr/src/lib/libm make depend make cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational -c /usr/src/lib/libm/common_source/lgamma. c -o lgamma.o /usr/src/lib/libm/common_source/lgamma.c:141: syntax error before `double' *** Error code 1 (continuing) /usr/src/lib/libm/ieee/support.c: In function `scalb': /usr/src/lib/libm/ieee/support.c:91: argument `N' doesn't match prototype /usr/include/math.h:153: prototype declaration *** Error code 1 (continuing) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** ELF Branding changes require action on your part.
David O'Brien wrote: - Forwarded message from "David E. O'Brien" [EMAIL PROTECTED] - Log: Change our ELF binary branding to something more acceptable to the Binutils maintainers. ... Note that a new kernel can still properly load old binaries except for Linux static binaries branded in our old method. - End forwarded message - One statically linked Linux binary that will cause you trouble after you build world is the Linux ``ldconfig''. After your ``make world'' and before you reboot that new kernel, issue: brandelf -t Linux /compat/linux/sbin/ldconfig Does this mean that we can re-brand any statically linux binary if it fails? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Internal compiler error: program ld got fatal signal 10
First, the error message: cc -fpic -DPIC -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libmd/i386/rmd160.S -o rmd160.So building shared library libmd.so.2 cc: Internal compiler error: program ld got fatal signal 10 *** Error code 1 Stop in /usr/src/lib/libmd. *** Error code 1 Now, the details. I started on Monday trying to update a 15 March 00 -current to current -current. I get the above error message with a source tree after *default date=2000.05.23.00.00.00 as specified in my cvsup supfile. The system builds fine for all earlier dates that I've tried. I have used the following three CFLAGS as set in /etc/make.conf CFLAGS= CFLAGS=-O -pipe CFLAGS=-O2 -pipe and the above error occurs. Any and all suggestions are welcomed, but it appears to be a problem with the new binutils. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
Bob Martin wrote: with "unsubscribe freebsd-current" in the body of the message If you are using an older K6 with more than 32mb of ram, this will happen from time to time of it's own accord. I have never taken the time to find out why, but if you search the archives, you will find that it happens quite a bit. SMP Pentium Pro with 256 MB of memory, and only scsi hardware. Note, ld is getting a signal 10 (SIGBUS) not signal 11 (SIGSEGV), which is the typical crappy hardware signal. Also, I can build the world as long as I use sources older that 23 May 00. This leads me to believe that the new binutils are having some problems. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
Warner Losh wrote: In message [EMAIL PROTECTED] Bob Martin writes: : If you are using an older K6 with more than 32mb of ram, this will : happen from time to time of it's own accord. I have never taken the time : to find out why, but if you search the archives, you will find that it : happens quite a bit. I'm using a PIII-500 and it is happening to me. This system would always build world great, but now fails all the time (20 builds) at exactly the same spot. I don't think this is hardware. It definitely isn't hardware. This, I believe, is a result of the new binutils. I've narrowed the window to *default date=2000.05.22.00.00.00 -- build completes. *default date=2000.05.22.12.00.00 -- ld gets a signal 10. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
Warner Losh wrote: In message [EMAIL PROTECTED] Marcel Moolenaar writes: : The ability to do cross builds rules out the need to update binutils : first. I haven't done any cross-builds since, well, februari, so I'm not : at all up to date on that front; things may have been broken by then... I did a complete buildworld in early May w/o a hitch that worked when I installed it on my bouncer box. Maybe I just need more swap than I have on my machine, or higher limits for the process building things. Then again, I do have 1/2G of swap that isn't being used at all during the builds... Warner, I've got 500MB of swap. It is never touched during the build. The machine is very lightly loaded (i.e., only "make buildworld" running). I was surprise that no one else had reported this problem when I sent my original e-mail. It must be restricted to a specific hardware combination. -- Steve Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Fri May 26 09:39:34 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/TROUTMASK Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 268435456 (262144K bytes) avail memory = 257748992 (251708K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0346000. VESA: v1.2, 4096k memory, flags:0x0, mode table:0xc00c1bdf (c0001bdf) VESA: S3 Incorporated. 86C325 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: Intel PIIX3 ATA controller at 7.1 pci0: S3 ViRGE graphics accelerator at 15.0 irq 19 ahc0: Adaptec 2940 Ultra SCSI adapter port 0xf400-0xf4ff mem 0xf0dff000-0xf0df irq 18 at device 16.0 on pci0 ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs xl0: 3Com 3c905-TX Fast Etherlink XL port 0xf0c0-0xf0ff irq 17 at device 17.0 on pci0 xl0: Ethernet address: 00:60:97:98:38:65 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 8 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: This ppc chipset does not support the extended I/O port range...no problem ppc0: Parallel port at port 0x378-0x37b irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode pps0: Pulse per second Timing Interface on ppbus0 ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port unknown0: PNP0a03 at port 0xcf8-0xcff on isa0 unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0700 can't assign resources unknown1: PNP0c02 at port 0x80,0x10-0x1f,0x22-0x2f,0x30-0x3f,0x50-0x5f,0x90-0x9f,0xa2-0xaf,0xb0-0xbf,0xe0-0xef iomem 0xfff8-0x on isa0 unknown2: PNP0c01 at iomem 0-0x9,0xe-0xf,0x10-0xfff on isa0 unknown3: PNP0200 at port 0-0xf,0x81-0x8f,0xc0-0xdf drq 4 on isa0 unknown4: PNP at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 unknown5: PNP0100 at port 0x40-0x43 irq 0 on isa0 unknown6: PNP0b00 at port 0x70-0x71 irq 8 on isa0 unknown: PNP0303 can't assign resources npxisa0: Legacy ISA coprocessor support at port 0xf0-0xff irq 13 on isa0 unknown7: PNP0800 at port 0x61 on isa0 unknown: PNP0f13 can't assign resources unknown8: PNP0c02 at port 0x4d0-0x4d1 on isa0 unknown9: PNP0c02 at iomem 0xfec0-0xfec0,0xfee0-0xfee00fff on isa0 unknown10: WaveTable at port 0x620-0x623 on isa0 sbc0: Creative SB16/SB32 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: SB DSP 4.13 on sbc0 unknown11: Game at port 0x200-0x207 on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Waiting 10 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! sa0 at ahc0 bus 0 target 1 lun
Re: Internal compiler error: program ld got fatal signal 10
Warner Losh wrote: David, I'm fairly certain that there are malloc related bugs in the new binutils. If I have malloc.conf pointing at AJ, then we die in ld all the time. If I remove that file, then we don't and things appear to work. That's why some people succeeded in their upgrade, and why some fail. Bingo. I have AJ set. P.S. One more beer to phk for putting this functionality into malloc :-) We're going to have one happy phk. Mark me down for one beer. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: roots shell == /bin/sh please
gnu not unix wrote: I could also live with /bin/bash as root's shell. Not sure why bash is not part of freebsd "core" anyways. GPL. Bloat. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Maxim Sobolev wrote: [Charset koi8-r unsupported, filtering to ASCII...] Mark Murray wrote: Agreed. I have already committed a "persistent" entropy cache that reseeds the random device on reboot. You may also want to extend /etc/crontab to periodically save entropy. This would help if something unexpected like halt(8) or panic(9) happened. I thought about a reseed daemon periodically saving entropy to, say, /var/log/entropy. But, a crontab entry would work just as well. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld seg faulting.
On Sun, Aug 31, 2003 at 07:52:15PM +1000, Alastair G. Hogge wrote: Hello list, For the past couple of weeks I've been tyring to keep my system up to date with cvsup. However, when ever I run a buildworld I get problems with gcc (I think it's gcc). I've tried nuking /usr/obj and running make clean many tims before each build but this doesn't help. What I've noticed is that the seg fault doesn't occur in the same place. There isn't enough context in the error messages you reported. Are you using the -j option during your buildworld? However, your last sentence in the above quoted paragraph, suggests that you have bad memory or a heating problem or a suspect power supply. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scheduling
On Thu, Sep 04, 2003 at 03:24:13AM +1000, Andy Farkas wrote: Not to flog a dead horse, but scheduling seems to be very broken this month. I am subjectively watching my smp box do a: 'cd /usr/ports/www/apache2 ; make all' in one window, and 'cd cd /usr/ports/databases/mysql40-server/ ; make all' in another window, and most disturbingly a 'top -S' in a 3rd window reporting 42.63% idle on cpu0, 39.50% idle on cpu1. It just doesn't seem right to me. You failed to mention which scheduler you are using. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re-fdisk'ing a partition - permission denied?
On Mon, Sep 08, 2003 at 06:13:43PM -0400, Matthew N. Dodd wrote: On Mon, 8 Sep 2003, Kevin Oberman wrote: In any case, since GEOM was added you can no longer slice or label an active device. As a result, the only way I know of to change slices or labels on V5 is to boot off of CD or floppy Fixit disks or install disks. (I just had to do this on my laptop this morning.) I still use my foot-shooting patch. Any chance that this patch will be committed? Or, has this patch been sent to the bikeshed? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
What happen to bimonthly status reports?
I've been tasked with putting together a large memory system (~16 GB) for numerical simulations. I decided to check the status of the AMD64 and IA64 port on the status page (http://www.freebsd.org/news/status/status.html), but the last available status report is the Jan-Feb 2003 report. I also searched the mailing list archives for the two platforms, but could not find the info that I was looking for. So, what is the status of the AMD64 and IA64 ports; particularly in regards to large memory configurations (i.e, max memory per platform and max memory per process on the platform)? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, Sep 10, 2003 at 05:23:55PM +0200, Michael Nottebrock wrote: Steve Kargl wrote: I have no problems in building the traditional C hello world program with cc -pedantic. You're right about that, you'll need a C++ hello world (iostream, cout). This is in the archives anyway and (should be) well known. Yes, it is a well known issue. The user is getting exactly what they wanted when she gave -pedantic to g++. (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) 4.9 and 5.0-R are independent branch. By your logic we should wait to 4.10 or 4.11 or 4.12 or ... before any substantial change can be made to -CURRENT. The point is that is isn't wise to commit a change like the -pthread deprecation that breaks many ports just before a ports-freeze. Which threads library should -pthread link to your app (libc_r, libkse, or libthr) on a 5.x system? The reason gcc-3.3.1 was committed before 5.0-R should be fairly obvious. I was concerned with the -pthread deprecation. Why? The portmgr can tag the ports collection at any point in time before or after the -pthread deprecation date. Additionally, your initial email started with your whining about -pedantic a and Hello world programs, which is completely orthogonal to -pthread. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, Sep 10, 2003 at 04:34:31PM -0700, Scott Reese wrote: On Wed, 2003-09-10 at 14:14, Scott Reese wrote: [I'm not presently subscribed to this list so please CC me in any replies. Thank you] Hello, I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B 400 motherboard with 512 MB RAM. The system starts and runs great, but I can't build anything with it anymore. Did you have these errors with your PIII 800 MHz processor and 256 MB of RAM? If the answer is no, the old harware wsa rock solid, then I suspect you have a hardware problem. For example, power supply can't supply enough power or the memory isn't seated correctly or insufficient heat sinking on the CPU or ... -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, Sep 10, 2003 at 04:45:47PM -0700, Scott Reese wrote: On Wed, 2003-09-10 at 16:40, Steve Kargl wrote: On Wed, Sep 10, 2003 at 04:34:31PM -0700, Scott Reese wrote: On Wed, 2003-09-10 at 14:14, Scott Reese wrote: I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B 400 motherboard with 512 MB RAM. The system starts and runs great, but I can't build anything with it anymore. Did you have these errors with your PIII 800 MHz processor and 256 MB of RAM? If the answer is no, the old harware wsa rock solid, then I suspect you have a hardware problem. For example, power supply can't supply enough power or the memory isn't seated correctly or insufficient heat sinking on the CPU or ... No, I didn't have these errors with the old hardware. It seemed very solid to me. I would be extremely disappointed if this were a hardware failure of some kind as I just got it upgraded this morning. :/ One question, though...Doesn't flakey hardware usually cause *random* errors? I ask because the error I'm receiving upon issuing 'make buildworld' is recurring in exactly the same place every time. I'm wondering if something somewhere got hosed... I deleted your original email, but I thought you said that you got ICE's while building a couple of ports. Do you set CFLAGS and/or CPUTYPE to some strange combination of options? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Thu, Sep 11, 2003 at 01:41:05AM +0200, Michael Nottebrock wrote:
Steve Kargl wrote:
Why? The portmgr can tag the ports collection at any point in
time before or after the -pthread deprecation date.
Steve, ports-freeze dates are set and published ahead of time just as dates
for releases are.
And the cvs tag can and has in the past been slid forward or
backwards when unforseen problems occur.
Don't bother telling me I'm whining, pointing at the handbook again and
saying don't expect anything to work on -CURRENT at any given time,
you're shooting the messenger.
If you want to use g++ -pedantic, do the following
cd $HOME
mkdir gcc
cd gcc
cvs -qz9 -d :pserver:[EMAIL PROTECTED]:/cvsroot/gcc update\
-r tree-ssa-20020619-branch -PAd gcc
cd ..
mkdir obj
cd obj
../gcc/configure --enable-languages=c,c++ --prefix=$HOME
gmake bootstrap
gmake install
troutmask:sgk[205] $HOME/bin/g++ -static -pedantic -o a a.cc
troutmask:sgk[206] a
hello world
troutmask:sgk[207] cat a.cc
#include iostream
int main(void) {
std::cout hello world\n;
return 0;
}
--
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
uart module breaks buildkernel
=== uart @ - /usr/src/sys machine - /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/dev/uart/uart_if.m -c awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/isa/isa_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/makeobjops.awk @/dev/uart/uart_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/uart/../../dev/uart/uart_bus_acpi.c /usr/src/sys/modules/uart/../../dev/uart/uart_bus_ebus.c /usr/src/sys/modules/uart/../../dev/uart/uart_bus_isa.c /usr/src/sys/modules/uart/../../dev/uart/uart_bus_pci.c /usr/src/sys/modules/uart/../../dev/uart/uart_bus_puc.c /usr/src/sys/modules/uart/../../dev/uart/uart_core.c /usr/src/sys/modules/uart/../../dev/uart/uart_cpu_i386.c /usr/src/sys/modules/uart/../../dev/uart/uart_dev_i8251.c /usr/src/sys/modules/uart/../../dev/uart/uart_dev_ns8250.c /usr/src/sys/modules/uart/../../dev/uart/uart_dev_sab82532.c /usr/src/sys/modules/uart/../../dev/uart/uart_dev_z8530.c uart_if.c /usr/src/sys/modules/uart/../../dev/uart/uart_tty.c /usr/src/sys/dev/uart/uart_bus_ebus.c:39:34: sparc64/ebus/ebusvar.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/uart. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/local/obj/usr/src/sys/HOTRATS. *** Error code 1 Stop in /usr/src. *** Error code 1 Caveat sys/sparc64 doesn't exist on this system because it isn't a sparc64 platform and it has limited disk space. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck failed after hard crash
On Sun, Sep 14, 2003 at 11:42:21AM +0200, Sebastian Ssmoller wrote: i did cvsup for /usr/src yesterday and did a build world. i also build a new kernel without all these debugging things. If you're running FreeBSD-current, I would suggest that you put the debugging options back into your kernel. i rebooted the system and everything went fine first but then i tried to recompile pf_freebsd and the system crashed. Without debugging or even a panic message, it is fairly difficult to make any useful suggestions. i rebooted and did fsck and tried the rebuild again - same thing :( Panic message? reboot again, fsck with many errors (some sectors could not be written, inconsistancy soft updates). i managed to start gnome2 agian. i started vmware and ... crash agin :'( Are you sure you don't want to run FreeBSD 4.8? so i thought of using the old kernel again but when i restart and run fsck it is NOT able to mark /usr as clean !! :( what can i do now ? any ideas ? When fsck fails to clean /usr are there any error messages? What fsck command did you issue to clean up /usr? Did you try using an alternate super block? What compiler flags did you use to build the kernel? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
On Wed, Sep 17, 2003 at 08:31:52PM +0200, sebastian ssmoller wrote: Motherboard Temp Voltages 255C / 491F / 528KVcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1:0 rpm+12.0V: +15.938V 2:0 rpm-12.0V: -15.938V 3:0 rpm- 5.0V: -6.654V i'm not sure whether this output is correct : 255 C ?? so this should be a reason for acpi to throttling the cpu, doesnt it ? 0 rpm? Are you sure your fans are working? As for cpu throttling try the following troutmask:kargl[225] sysctl -a | grep acpi.cpu hw.acpi.cpu.max_speed: 2 hw.acpi.cpu.current_speed: 2 hw.acpi.cpu.performance_speed: 2 hw.acpi.cpu.economy_speed: 1 -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compiler Woes (was: Re: RAM Recommendations for a VIA Mainboard?)
On Wed, Sep 17, 2003 at 01:21:39PM -0700, Scott Reese wrote: On Tue, 2003-09-16 at 18:48, Matthias Andree wrote: Scott Reese [EMAIL PROTECTED] writes: Though I'm not sure if RAM is my problem because I'm not getting Sig 11 errors. I keep getting extremely consistent internal compiler errors pretty much whenever I try to build *anything*. I've tried to buildkernel about 16 times today and each time I get stuck here (or very near here): An internal compiler error (ICE for short) can also be a compiler bug if it happens in the same place consistently. I recall other ICE Subject lines, but ignored the corresponding posts; the list archives may help you. Heh. Most of those messages were probably from me desperately seeking assistance of any kind (quick check confirms this). :) Most of those older posts were concerned with people who added -march=p4 or -march=athlon to CFLAGS. Those problems have been fixed with the latest GCC update in the source tree. I was also wondering if there was a way to build the system with an older compiler (like, say, 3.1)? I had these same problems with 3.2.1 so I wondered if going back to an earlier version would eliminate the issue. Going backwards with the compiler probably won't help. Have you tried installing 4.8 on this system. I still suspect you have a hardware problem. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix. It's not like we're making someone change their code to accomodate library or kernel interface changes. This is exactly the case the is going to cause the problems, though. For you, compiling a 3rd party app and dealing with failures in the linker is easy to deal with. For someone else, it might not be. If they go to compile an app and it compiles and runs fine on linux but fails on FreeBSD with linker errors, it will likely leave a negative impression in their mind. I'm comparing my arguments to linux because a lot more apps are written with linux in mind than with solaris in mind these days. People who are writing for linux or switching from linux might not know that '-lpthread' is a requirement, but they are more likely to know that '-pthread' will take care of all of that magic for them. This argument really comes down to ease of use and user experience. Steering away from de-facto standards steers us away from a positive user and developer experience. If the behavior of -pthread is documented in the man pages, then your argument holds no water. If the link stage fails, one would hope that the user can read the documention. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is 5.1 now more stable than 4.9rc
On Tue, Sep 30, 2003 at 11:52:05AM -0400, Eriq Lamar wrote: It just seems that there are alot of issues w/ 4.9, doesn't seem stable at all. The answer is probably no. Of course, your vague statement about 4.9 not being stable makes it hard to judge whether 5.1 is a better choice than 4.9. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Wed, Oct 01, 2003 at 01:04:51AM +0200, Lukas Ertl wrote: are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Wed, Oct 01, 2003 at 01:19:26PM +0200, Alexander Leidinger wrote: On Tue, 30 Sep 2003 16:25:06 -0700 Steve Kargl [EMAIL PROTECTED] wrote: As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. Snapshots are available in 4.9? I thought it's not only about the FS structure, it's about the code in -current (which is much different from the 4.x code). I wrote snapshots require softupdates. How you jumped to the conclusion that 4.x has snapshots is beyond me. My truck has a 4-speed manual transmission, therefore all trucks have 4-speed manual transmissions. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 10:10:41PM -0400, Barney Wolff wrote: Does this mean that the situation can ever arise where a security bug is corrected in the advisory's announced releases but not in -current? No. Well, at least not to date. Or, can we assume that as of the time of the security announcement the vulnerability has *always* been corrected in -current? Yes. You will need to run cvsup to update your sources and at a minimum rebuild the vulnerable application. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 10:48:53PM -0400, Barney Wolff wrote: On Fri, Oct 03, 2003 at 07:17:50PM -0700, Will Andrews wrote: ... The rule is that changes are always committed to -CURRENT first, unless they do not apply. This rule is rarely broken in FreeBSD, and certainly never broken for security issues. That's of course expected and appreciated. But consider the different actions required of a reasonably paranoid FreeBSD SA on receipt of a security advisory: If following anything but -current, cvsup and check the versions of the listed files. If following -current, either trust that the updates made it to the mirror of choice, or look up on www.freebsd.org what the latest versions of the listed files are and check that you have them. Since the SO is presumably taking the changes from -current, I hope it would not be too much of an imposition to list those versions in the advisory as well. If you're running -current, then you are reading the cvs-all or at least the cvs-src mailing list. It should be apparent that the fixes hit -current before the SA is announced. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no partition entries for /dev/ad3
On Wed, Oct 08, 2003 at 11:20:16AM -0700, Andrew P. Lentvorski, Jr. wrote: On Wed, 8 Oct 2003, ecsd wrote: The chronology is that I booted the system, did the disklabel -w -r ad3 auto, turned around to disklabel -e /dev/ad3s1c (as I would normally do), and was told that /dev/ad3s1c did not exist. Then I wrote in here asking for help. ad3s1c does not exist. Since it looks like you already have a working FreeBSD system, can you try running /stand/sysinstall ? At that point, you can choose Configure and the Fdisk and Label choices are generally a much freindlier interface to getting a disk online. On 5.1, you want to use /usr/sbin/sysinstall. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: pmap_zero_page: CMAP3 busy
Upgrade tonight (7pm PST) and received the following on rebooting panic: pmap_zero_page: CMAP3 busy Unfortunately, this system does not have a serial console and the panic locked it up tight. Only a hard reset brought the system back. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
cd0 errors during probe?
Can I assume that the following error messages are erronous because cd0 appears to function without any problems? There is a CD in the drive. cd0 at ahc0 bus 0 target 4 lun 0 cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [129875 x 2048 byte records] (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retries Exhausted (cd0:ahc0:0:4:0): cddone: got error 0x5 back (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retries Exhausted (cd0:ahc0:0:4:0): cddone: got error 0x5 back (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retries Exhausted (cd0:ahc0:0:4:0): cddone: got error 0x5 back (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB:
Re: cd0 errors during probe?
On Sun, Oct 12, 2003 at 02:51:50PM -0600, Kenneth D. Merry wrote: On Sun, Oct 12, 2003 at 10:26:54 -0700, Steve Kargl wrote: Can I assume that the following error messages are erronous because cd0 appears to function without any problems? There is a CD in the drive. cd0 at ahc0 bus 0 target 4 lun 0 cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [129875 x 2048 byte records] (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) Looks like GEOM is trying to read the first sector of the CD, but since it's likely an audio CD, it doesn't quite work. Yes, it is an audio CD. I suspected that it was a transient GEOM/CAM issue, but wanted to make sure before I needlessly replaced the cdrom drive. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Sun, Oct 19, 2003 at 03:05:29PM -0600, Scott Long wrote: Kris Kennaway wrote: This symbol is defined in libc.so.5. One way you can see this problem is if you are running a 4.x binary that links to libm.so.2 on a 5.x system, because libm has the same version number in 5.x but is not binary compatible. So the 4.x binary links to libc.so.4 and libm.so.2, and the latter is actually a 5.x library that expects to have __fpclassifyd resolved by linking with libc.so.5. Is it the case on your system that you have old 4.x binaries installed? Kris We need to resolve this before 5.2 in some fashion. It looks like the easiest thing to do is bump libm. Is this advisable? I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Sun, Oct 19, 2003 at 03:48:58PM -0700, Kris Kennaway wrote: On Sun, Oct 19, 2003 at 03:13:41PM -0700, Steve Kargl wrote: I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. You don't want to do it before you have to, because this creates more pain for people when you make a change that breaks backwards compat (given the policy/preference of only bumping once per major release). I'm working on a script that will detect the kind of backwards compatibility breakage we're seeing here by comparing the symbols in 4.x and 5.x versions of libraries with the same major revision. We can then run this once a day/week/whatever somewhere to catch these problems as soon as they occur in future. You and I participated in the first go around in the library versioning problem. For one of my attempts to discuss this problem, see http://www.freebsd.org/cgi/getmsg.cgi?fetch=1981830+1986079+/usr/local/www/db/text/2002/freebsd-current/20021103.freebsd-current -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: I had a fair amount of time over the last week running in disconnected operation, and realized I had too many cables under my desk, so I spent a bit of time exploring the FreeBSD console code. After reading a FREENIX paper this summer on a Linux ethernet console driver, I took a pass at implementing ethernet console support for FreeBSD. Robert, This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386_set_ldt warnings
On Wed, Oct 22, 2003 at 12:09:43PM -0400, Daniel Eischen wrote: On Wed, 22 Oct 2003, C. Kukulies wrote: Some (kde) applications now have a warning appear in xconsole: Warning: pid 595 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 596 used static ldt allocation. See the i386_set_ldt man page for more info Should I worry about that? Rebuild KDE? Let me guess. You are using Nividia-supplied drivers/libraries? It won't bother you unless you want to use libkse or libthr for your threading library instead of libc_r. Seeing that libc_r won't be the default sometime after 5.2-RELEASE, you might want to complain to NVidia. Do they supply source or is it binary only? I see similar messages on the console and I do not have a nvidia card. By the time I find the message the process has terminated, so I have no way of translating the PID into an actual executable name. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld broken at lib/msun
On Fri, Jun 06, 2003 at 09:20:16PM -0700, walt wrote:
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99
-c i387_e_acos.S -o i387_e_acos.o
{standard input}: Assembler messages:
{standard input}:19: Error: junk `(__ieee754_acos)' after expression
{standard input}:19: Error: junk `(__ieee754_acos)' after expression
*** Error code 1
Now, i387_e_acos.S hasn't changed, so something else is wrong.
When I 'cd /usr/src/lib/msun' and do a make from there it compiles
and assembles just fine. This maybe smells like one of the usual
suspects like awk, sed, sh, and their surly gang ;-)
sed was just repaired yesterday, for example. Maybe it still needs
another tweak?
It is the inclusion of -std=gnu99.
--
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, May 28, 2003 at 06:40:46PM +0930, Daniel O'Connor wrote: On Wed, 28 May 2003 18:39, M. Warner Losh wrote: : : Maybe the kernel build stuff can look in /usr/local/src/sys/modules : : for things to build or something.. : : YUCK! : : *WHY?* : : I have asked this before BTW, and I haven't been told why it sucks. Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Thu, May 29, 2003 at 09:20:23AM +0930, Daniel O'Connor wrote: On Wed, 28 May 2003 23:58, Steve Kargl wrote: Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. You are describing how it happens now, not WHY it happens like that. The WHY is obvious. The modules (1) get rebuilt with the kernel. (2) get installed with the kernel. (3) get moved to /boot/kernel.old when a new kernel is installed. (4) *Ideally*, if an API changes, the modules will be updated by the developer/committer who breaks the modules; otherwise, a person experiencing the breakage can ask for the commit to be backed out. (Note, the *ideally* acknowledges that 64-bit platforms seem to suffer API breakage more than ia32). I think the existing solution has problems, and would prefer some external hooks for 3rd party modules. If you mean third party modules without available sources, then (1) The module should work for whatever -RELEASE i for which it was built. (2) If you upgrade the OS, the module may or may not work. (a) If it works, well aren't you lucky. (b) If it doesn't work, then (i) Ask the vendor for an update. (ii) Hack around the breakage. (iii) Downgrade to the *PROPER* -RELEASE. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
