RE: 4.5-5.0 New Bootloader needed
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, March 12, 2002 10:05 PM To: [EMAIL PROTECTED] Subject: 4.5-5.0 kldxref:No such file or directory As an asside, I've noticed in the past when upgrading from 4.0 to 5.0, I've had to forcebly reinstall the loader. I dont know why, but the loader shiped with (at least) 4.4 doesnt seem to like loading 5.0 kernel bits. If i understand the boot procedure right it isnt the the mbr but the boot sector of the partition. For 5.0 the kernel and modules stuff can be found unter /boot not in the root-tree. So after a buildkernel and installkernel none of the boot sectors are overwritten and the old kernel will be loaded. I think this has to be mentioned in the UPDATING text should it? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4.5-5.0 New Bootloader needed
At Wed, 13 Mar 2002 09:14:09 +0100,
Jan Stocker wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, March 12, 2002 10:05 PM
To: [EMAIL PROTECTED]
Subject: 4.5-5.0 kldxref:No such file or directory
As an asside, I've noticed in the past when upgrading from 4.0 to
5.0, I've had to forcebly reinstall the loader. I dont know why,
but the loader shiped with (at least) 4.4 doesnt seem to like
loading 5.0 kernel bits.
If i understand the boot procedure right it isnt the the mbr but the boot
sector of the partition. For 5.0 the kernel and modules stuff can be found
unter /boot not in the root-tree. So after a buildkernel and installkernel
none of the boot sectors are overwritten and the old kernel will be loaded.
I think this has to be mentioned in the UPDATING text should it?
Jan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
This changes after the installworld target. From UPDATING:
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot in single user [3]
make installworld
mergemaster [4]
[1]
reboot
I updated my machine from 4.5-stable to 5.0-current without a hang up,
but I did notice that after I installed the kernel it didn't boot it.
But after the installworld it did.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Updating 4.5-5.0 forces some ports to fail: old include files
Hi, after updating my fresh installed 4.5 to -current i was unable to compile GDM. After a nice hint the problem was found. In /usr/include are some old files which are no longer used by -current but be found by the configure program of gdm (i think) and so be used. So i think updating an old 4.x system should lead to a removal of no longer used files to avoid this problem. I've moved my old include and made a installworld again. This is the diff: Only in include.old: gmp.h Only in include.old/machine: asnames.h Only in include.old/machine: bus_pio_ind.h Only in include.old/machine: console.h Only in include.old/machine: globaldata.h Only in include.old/machine: globals.h Only in include.old/machine: i4b_isppp.h Only in include.old/machine: if_wavelan_ieee.h Only in include.old/machine: ioctl_fd.h Only in include.old/machine: ipl.h Only in include.old/machine: lock.h Only in include.old/machine: mouse.h Only in include.old/machine: ultrasound.h Only in include.old: msdosfs Only in include.old/net: hostcache.h Only in include.old/net: if_faith.h Only in include.old/netatm: kern_include.h Only in include.old/netinet: in_hostcache.h Only in include.old/nfs: krpc.h Only in include.old/nfs: nfs.h Only in include.old/nfs: nfsdiskless.h Only in include.old/nfs: nfsm_subs.h Only in include.old/nfs: nfsmount.h Only in include.old/nfs: nfsrtt.h Only in include.old/nfs: nfsrvcache.h Only in include.old/nfs: nfsv2.h Only in include.old/nfs: nqnfs.h Only in include.old: ntfs Only in include.old: nwfs Only in include.old/security: _pam_compat.h Only in include.old/security: _pam_macros.h Only in include.old/security: _pam_types.h Only in include.old/security: pam_malloc.h Only in include.old/security: pam_misc.h Only in include.old: skey.h Only in include.old: ss Only in include.old: struct.h Only in include.old/sys: inttypes.h Only in include.old/sys: syscall-hide.h Only in include.old/sys: tprintf.h Only in include.old/sys: wormio.h Only in include.old/ufs: mfs -Original Message- From: Michael J Estes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 12:13 AM To: [EMAIL PROTECTED] Cc: gnome@FreeBSD. ORG; ports@FreeBSD. ORG Subject: Re: GDM port broken I had the same problem recently and I managed to fix it my removing /usr/include then doing a 'make installworld'. I'm assuming you are on -CURRENT. I think this is related to recent pam changes. Seems there may have been some stale pam related .h files. -Mike Estes On Mon, 2002-03-11 at 14:46, Jan Stocker wrote: Compiling gdm failed on completly fresh installed system... cc -O -pipe -march=pentiumpro -I/usr/X11R6/include -g -Wall -Wpointer-arith -Wmi ssing-prototypes -Wmissing-declarations -o gdmaskpass dmaskpass.o -Wl,-E -L/us r/X11R6/lib -L/usr/local/lib -lintl -lpam -lwrap -lpam -lutil -lutil -lXiner ama gdmaskpass.o: In function `main': /usr/ports/x11/gdm/work/gdm-2.2.5.4/utils/gdmaskpass.c(.data+0x0): undefined ref erence to `misc_conv' gmake[2]: *** [gdmaskpass] Error 1 gmake[2]: Leaving directory `/usr/ports/x11/gdm/work/gdm-2.2.5.4/utils' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-gnome in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Hi, Here are my test news. The -O bug doesn't happen with gcc295 from ports ! I tried all these FLAGS, but noone of them was creating the problems we see with -O : Optimization Options -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks -fdelayed-branch -felide-constructors -fexpensive-optimizations -ffast-math -ffloat-store -fforce-addr -fforce-mem -finline-functions -fkeep-inline-functions -fmemoize-lookups -fno-default-inline -fno-defer-pop -fno-function-cse -fno-inline -fno-peephole -fomit-frame-pointer -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fstrength-reduce -fthread-jumps -funroll-all-loops So what does -O exactly ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
STABLE is broken too, but in a different manner. I just added -O and
then this happened.
[algo] :testing inplace_merge #1() (weak) ... eh_test in free(): warning: junk
pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: modified (chunk-) pointer
# gdb eh_test eh_test.core
#0 0x806630b in void _STL::inplace_mergeSortClass * (__first=0xbfbff0ac,
__middle=0xbfbff23c, __last=0xbfbff3cc) at test_algo.cpp:58
58{
(gdb) bt
#0 0x806630b in void _STL::inplace_mergeSortClass * (__first=0xbfbff0ac,
__middle=0xbfbff23c, __last=0xbfbff3cc) at test_algo.cpp:58
#1 0x8066e8a in void WeakCheckSortBuffer, test_inplace_merge_1
(v=@0xbfbff83c, op=@0xbfbff434, max_iters=200) at test_algo.cpp:216
#2 0x804b41e in test_algo () at test_algo.cpp:248
#3 0x8049e37 in main (argc=3, argv=0xbfbffbe0) at main.cpp:275
#4 0x8049759 in _start ()
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Tue, Mar 12, 2002 at 09:33:32PM -0800, Julian Elischer wrote: any change that has to be added to 4.x tomake it run on 5.x is the wrong answer. 4.x binaries should all run on 5.x (unless something was accidentally committed to 4.x that should be backed out.) any change for allowing 4.x binaries to run on 5.x should be done on the 5.x side of things, (unless I've misunderstood the problem here) Yes: see my followup. Kris msg36020/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x binary. I'm not immediately familiar with the issues surrounding eaccess(). Kris msg36021/pgp0.pgp Description: PGP signature
Re: 4.5-5.0 New Bootloader needed
On Wed, Mar 13, 2002 at 09:14:09AM +0100, Jan Stocker wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, March 12, 2002 10:05 PM To: [EMAIL PROTECTED] Subject: 4.5-5.0 kldxref:No such file or directory As an asside, I've noticed in the past when upgrading from 4.0 to 5.0, I've had to forcebly reinstall the loader. I dont know why, but the loader shiped with (at least) 4.4 doesnt seem to like loading 5.0 kernel bits. If i understand the boot procedure right it isnt the the mbr but the boot sector of the partition. For 5.0 the kernel and modules stuff can be found unter /boot not in the root-tree. So after a buildkernel and installkernel none of the boot sectors are overwritten and the old kernel will be loaded. I think this has to be mentioned in the UPDATING text should it? It should be taken care of by installworld when it installs new config files for the loader, right? i.e. the /boot/kernel location for the 5.0 kernel is specified in the default config file. Kris msg36022/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. binary. I'm not immediately familiar with the issues surrounding eaccess(). Kris -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4.5-5.0 kldxref:No such file or directory
On Wed, 13 Mar 2002 04:13:35 +0100, Emiel Kollof wrote: Why not test for it like this (or similar): [ -x /usr/sbin/kldxref ] /usr/bin/kldxref (etcetera...) I think the reason this isn't helpful is because it only catches one failure case. The other is where /usr/sbin/kldxref doesn't execute properly, because it relies on features of an as-yet not installed shell, libc, kernel or all three. In such cases, I don't think we should consider the installation of the kernel to have failed. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Wed, Mar 13, 2002 at 01:24:36PM +0300, Maxim Konovalov wrote: On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. Well, eaccess(2) is presumably a good idea, so it would be better to just MFC it :) Kris msg36025/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 03:38-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 01:24:36PM +0300, Maxim Konovalov wrote: On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. Well, eaccess(2) is presumably a good idea, so it would be better to just MFC it :) Agree. Kris -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded. All cpp* files are the same in the port and our system compilers. And ideas and pointers which subsystems I could test for this breakage ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4.5-5.0 New Bootloader needed
Kris Kennaway wrote: It should be taken care of by installworld when it installs new config files for the loader, right? i.e. the /boot/kernel location for the 5.0 kernel is specified in the default config file. I think the point here is that when upgrading, you should boot the new kernel *before* running the installworld (and thus before installing the new loader). If you're not paying attention (or don't know better) you'll boot the old kernel instead and possibly have a bad time. This is in fact mentioned in UPDATING already, but it's a bit buried in the more mundane items. It's also confusing that it's not mentioned in the section about the 4.x - 5.0 dance. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Tue, 12 Mar 2002, Julian Elischer wrote: any change that has to be added to 4.x tomake it run on 5.x is the wrong answer. 4.x binaries should all run on 5.x (unless something was accidentally committed to 4.x that should be backed out.) any change for allowing 4.x binaries to run on 5.x should be done on the 5.x side of things, (unless I've misunderstood the problem here) Yes, the problem here is that Kris is building and running a 5.x world on a 4.x kernel in a chroot to support the build cluster. Common binaries such as sh are just now beginning to rely on the new kernel functionality (a trend that will continue, as I pointed out), and my belief is the model being used is flawed as anything other than a short term thing. On the other hand, there's no harm in MFC'ing eaccess(), since it's a generally useful thing. However, as soon as the 64-bit UFS2 work starts coming in, and the new system calls are brought in to support that, even basic applications such as 'sh' are going to stop working again, due to stat(). But my feeling is that's actually OK given the direction: 4.x kernel 5.x kernel 4.x binariesREQUIREDREQUIRED 5.x binariesDEGRADING REQUIRED This case falls squarely into the 'DEGRADING' category, given the approach of new functionality. For example, ls will shortly learn about ACL system calls, which while present in the -STABLE aren't implemented. Likewise, configure scripts that test the behavior of system calls will also start failing in appropriately. To get us 5.0-DP1 packages, sure, MFC eaccess(). We'll just need to make sure that over the next month or two, -CURRENT is in a position where it can run safely on the package cluster to support 5.0 package builds. I can MFC eaccess() later today, assuming there are no objections. I've been meaning to for a while, so that I can merge it into Darwin. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4.5-5.0 kldxref:No such file or directory
* Crist J. Clark ([EMAIL PROTECTED]) wrote: *** Error code 1 (ignored) ^ Note. Since there is no kldxref in 4.5, this should probably included in the bootstrap process somehow. A known issue. The install process deliberately ignores this as a non-fatal error. Ok, but comming as it does at the _end_ of the kernel install process it's very deceptive. I think a note, or an if [ -x ... would be a good idea. brad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cardbux.c:186: too many arguments to function `pci_read_device'
Only my laptop didn't compile the kernel with this morning's cvsup. It stops with the following error. cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/ dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundar y=2 -Werror /usr/src/sys/dev/cardbus/cardbus.c /usr/src/sys/dev/cardbus/cardbus.c: In function `cardbus_attach_card': /usr/src/sys/dev/cardbus/cardbus.c:186: too many arguments to function `pci_read _device' *** Error code 1 Stop in /usr/obj/usr/src/sys/PIII850N. *** Error code 1 ed -- Griffin Plaza Partners, LLC - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Wed, 13 Mar 2002, Maxim Konovalov wrote: I believe you have :-) ummm but we =have never guaranteed that N+1 binaries will run on N systems. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cardbux.c:186: too many arguments to function `pci_read_device'
Date: Wed, 13 Mar 2002 10:33:41 -0800 From: Edwin Culp [EMAIL PROTECTED] Only my laptop didn't compile the kernel with this morning's cvsup. It stops with the following error. ... -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundar y=2 -Werror /usr/src/sys/dev/cardbus/cardbus.c /usr/src/sys/dev/cardbus/cardbus.c: In function `cardbus_attach_card': /usr/src/sys/dev/cardbus/cardbus.c:186: too many arguments to function `pci_read _device' *** Error code 1 Right; Warner fixed it in the commit at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1235808+0+current/cvs-all (08:32:11 PST today). Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Exception-handling is broken with -O in -stable, and has been for years.
FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds
to implement exceptions, so when the GCC folks broke that path, it was
never fixed. There are supposedly patches floating around that fix the
problem, but they either didn't work as advertised or the ball got dropped.
This problem should exist in -current since I think FreeBSD finally drops
setjmp/longjmp stack unwinds and goes to dwarf 2 unwinds, which do work
(and which are used by the GCC 2.95 port, which also works but which
isn't compatible with /usr/lib/libstdc++.{a,so}).
This issue is why Yahoo! has to use its own build of GCC, and I doubt
we're the only ones...
-Ed
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 12:15:34PM -0800, Ed Hall wrote: Exception-handling is broken with -O in -stable, and has been for years. FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds to implement exceptions, so when the GCC folks broke that path, it was never fixed. There are supposedly patches floating around that fix the problem, but they either didn't work as advertised or the ball got dropped. We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? cd /usr/ports/devel/stlport make install cd work/STL*/test/eh add -O to gcc-freebsd.mk gmake -f gcc-freebsd.mk clean gmake -f gcc-freebsd.mk and see what happens ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
segfault in getpwuid()?
Can anyone explain this to me?
#0 0x286613cc in _ftello () from /usr/lib/libc.so.5
#1 0x28661358 in ftello () from /usr/lib/libc.so.5
#2 0x286612f6 in ftell () from /usr/lib/libc.so.5
#3 0x28678ef7 in .cerror () from /usr/lib/libc.so.5
#4 0x28676c9e in isatty () from /usr/lib/libc.so.5
#5 0x2865f621 in _nsyy_init_buffer () from /usr/lib/libc.so.5
#6 0x2865f577 in _nsyy_create_buffer () from /usr/lib/libc.so.5
#7 0x2865e9c3 in _nsyylex () from /usr/lib/libc.so.5
#8 0x28657680 in _nsyyparse () from /usr/lib/libc.so.5
#9 0x2865905d in _nsdbtget () from /usr/lib/libc.so.5
#10 0x286591dc in nsdispatch () from /usr/lib/libc.so.5
#11 0x2863085a in getpwuid () from /usr/lib/libc.so.5
#12 0x2814db0e in g_get_any_init () at gutils.c:539
#13 0x2814ddb9 in g_get_home_dir () at gutils.c:623
#14 0x2859bd97 in gnomelib_init () from /usr/X11R6/lib/libgnome.so.5
#15 0x282123bf in gnome_init_with_popt_table ()
from /usr/X11R6/lib/libgnomeui.so.5
#16 0x282124ae in gnome_init () from /usr/X11R6/lib/libgnomeui.so.5
#17 0x281765b5 in gnome_CORBA_init () from /usr/X11R6/lib/libgnorba.so.5
#18 0x805dddb in main ()
#19 0x8058ee5 in _start ()
A listing at #12:
534 # endif /* !HAVE_GETPWUID_R */
535
536 if (!pw)
537 {
538 setpwent ();
539 pw = getpwuid (getuid ());
540 endpwent ();
541 }
542 if (pw)
543 {
(that's from glib12)
This makes panel,gnome-session, etc all crash on start.
-current as of this morning.
-Seth
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 02:08:55PM +0100, Martin Blapp wrote: I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded. All cpp* files are the same in the port and our system compilers. And ideas and pointers which subsystems I could test for this breakage ? Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Kris msg36040/pgp0.pgp Description: PGP signature
Re: gcc -O broken in CURRENT
Hi Kris, Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Easy to say, hard to do. STABLE is broken as current is, and it seems that 4.4 and 4.3 are also broken for the STLport test. This is a very difficult thing to do for someone that does not know gcc internals. Impossible for me. I don't have the resources (time) and knowledge (compiler coding) to do this. I can only state that: - plain gcc without patches works - gcc295 from ports works - gcc is STABLE and CURRENT is broken - It's not the dewarf unwinding. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 11:42:46PM +0100, Martin Blapp wrote: Hi Kris, Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Easy to say, hard to do. STABLE is broken as current is, and it seems that 4.4 and 4.3 are also broken for the STLport test. That gives you MORE information: look for patches to the gcc directory which have been MFCed. This is a very difficult thing to do for someone that does not know gcc internals. You don't have to understand the changes, just look at the cvs logs for the past few months, and try backing out revisions to see if it fixes things, or at least identify a list of possible changes which others can test. Kris msg36042/pgp0.pgp Description: PGP signature
Re: gcc -O broken in CURRENT
Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
cd /usr/src/gnu/usr.bin/cc make make install On Wed, 13 Mar 2002, Martin Blapp wrote: Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 11:49:52PM +0100, Martin Blapp wrote: Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? cd /usr/src/gnu/usr.bin/cc make all Kris msg36045/pgp0.pgp Description: PGP signature
malloc() and the stock Perl in -CURRENT (and -STABLE)
Dear all...
This morning I found a very interesting mail. All of you can see it from:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1669241+0+current/freebsd-questions
As stated in the mail, a simple Perl script like this:
-- Begin --
#!/usr/bin/perl
$temp = ;
$begin = time;
for ($i = 0; $i 100; $i++) {
$result .= $i\n;
}
print Exec time: , time - $begin, secs\n;
-- End --
can show that there PROBABLY is something wrong with malloc() in -CURRENT
and -STABLE.
I am just bringing this to a wider audience so maybe this could be a
valueable information for FreeBSD developer and Perl maintainer in FreeBSD.
I heard that Perl in -CURRENT would be updated to Perl 5.6.1, maybe the
maintainer can put the default build for this new version of Perl to use its
own malloc (provided from Perl 5.6.1) IF it turns out that there is nothing
wrong with malloc() in -CURRENT and -STABLE (I don't know cause I am not a C
programmer)...
Thanks...
/john
I go, I fight, and I win!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
bpf broken
../../../net/bpf.c: In function `bpf_wakeup': ../../../net/bpf.c:518: structure has no member named `si_pid' -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota Waiter, there's no fly in my soup! - Kermit the Frog To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bpf broken
* Michael D. Harnois [EMAIL PROTECTED] [020313 20:07] wrote: ../../../net/bpf.c: In function `bpf_wakeup': ../../../net/bpf.c:518: structure has no member named `si_pid' cvsup again, you caught a bad window. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
I wrote: : This problem should exist in -current since I think FreeBSD finally drops ^^ That should be shouldn't. I shouldn't post in a hurry (like I'm doing now). -Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
* John Indra [EMAIL PROTECTED] [020313 19:47] wrote: Dear all... This morning I found a very interesting mail. All of you can see it from: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1669241+0+current/freebsd-questions FreeBSD 5.0 has (being a developer release) has special diagnostics turned on in malloc that causes it to take more time to do allocations. see the malloc(3) manpage and make sure to disable these features if doing benchmarks. I'm sorry I can't find out all the other tweaks needed to get the best performance out of 5.x, perhaps the -doc people can point us the way. niether the tuning(7) manpage nor http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html describe this... -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
On Wed, Mar 13, 2002 at 09:28:10PM -0800, Alfred Perlstein wrote: FreeBSD 5.0 has (being a developer release) has special diagnostics turned on in malloc that causes it to take more time to do allocations. But... it DOESN'T only happen in -CURRENT. Even Raistlin Majere [EMAIL PROTECTED] is using a -STABLE or a -RELEASE maybe (he doesn't state his uname output in the message). And to confirm, I have just run the script with FreeBSD 4.4-STABLE of Nov 24th 2001: 44 secs! Awfully slow! (Perl 5.005_03 built from buildworld) And... let me tell you more. I run the script in -CURRENT who has: $ ll /etc/malloc.conf lrwxr-xr-x 1 root wheel 2 Feb 8 14:08 /etc/malloc.conf - aj This is a fresh -CURRENT (Mar 13th 2002) with Perl 5.6.0 built from buildworld. And to clarify things... I don't know what's wrong with malloc() in -CURRENT and -STABLE (and I don't even know whether it's even wrong). All I want is to let the Perl maintainer in -CURRENT and -STABLE to compile the stock Perl with its own malloc library, thus Perl in FreeBSD doesn't suffer from this kind of slowness. Thanks... -Alfred /john I go, I fight, and I win! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
In message [EMAIL PROTECTED], John Indra writes:
Dear all...
This morning I found a very interesting mail. All of you can see it from:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1669241+0+current/freebsd-questions
As stated in the mail, a simple Perl script like this:
-- Begin --
#!/usr/bin/perl
$temp = ;
$begin = time;
for ($i = 0; $i 100; $i++) {
$result .= $i\n;
}
print Exec time: , time - $begin, secs\n;
-- End --
can show that there PROBABLY is something wrong with malloc() in -CURRENT
and -STABLE.
No, there is nothing wrong as such, it is a deliberate design-choice
in phkmalloc() which conflicts with perls use of realloc().
Basically I profiled a lot of programs and found that very few programs
used realloc() and decided that consequently it was the least important
of the entries from a performance point of view.
The above perl program results in a loop more or less like:
n = 2
for (i = 0; i 100; i++)
realloc(n++);
Now, if you read _any_ malloc(3) man page, they will tell you that there
is no way it can be guaranteed that this does not result in a lot of
copying.
(insert bikeshed discussion about wisdom of the above code, assume
I maintain the opinion throughout that it is braindamaged to be
that stupid in a so central program as perl)
At the cost of considerable complexity (a mremap(2) implementation amongst
other things), realloc in phkmalloc(3) can be optimised but it is not
on my plate right now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
The above perl program results in a loop more or less like: n = 2 for (i = 0; i 100; i++) realloc(n++); Now, if you read _any_ malloc(3) man page, they will tell you that there is no way it can be guaranteed that this does not result in a lot of copying. Um, except that copying isn't what is causing the problem. The performance problem is apparantly caused by tens of thousands of page faults per second as the memory is freed and immediately reallocated again from the kernel. Doesn't phkmalloc keep a small pool of allocations around to avoid problems like this? -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
On Thu, Mar 14, 2002 at 07:04:06AM +0100, Poul-Henning Kamp wrote: At the cost of considerable complexity (a mremap(2) implementation amongst other things), realloc in phkmalloc(3) can be optimised but it is not on my plate right now. Glad to know that there is no problem with malloc() in -CURRENT. But I still think that this must be addressed in Perl. So maybe, the stock Perl should be built against its own malloc library? Thank you for the clarification. /john I go, I fight, and I win! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
On Thu, Mar 14, 2002 at 12:47:29PM +0700, John Indra wrote: And to clarify things... I don't know what's wrong with malloc() in -CURRENT and -STABLE (and I don't even know whether it's even wrong). All I want is to let the Perl maintainer in -CURRENT and -STABLE to compile the stock Perl with its own malloc library, thus Perl in FreeBSD doesn't suffer from this kind of slowness. phkmalloc is generally pretty efficient..how do you know that switching to the perl internal malloc to optimize this particular usage pattern won't severely pessimize others? Kris msg36055/pgp0.pgp Description: PGP signature
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
:The above perl program results in a loop more or less like:
:...
:
:Now, if you read _any_ malloc(3) man page, they will tell you that there
:is no way it can be guaranteed that this does not result in a lot of
:copying.
:
: Um, except that copying isn't what is causing the problem. The performance
:problem is apparantly caused by tens of thousands of page faults per second as
:the memory is freed and immediately reallocated again from the kernel. Doesn't
:phkmalloc keep a small pool of allocations around to avoid problems like
:this?
:
:-DG
:
:David Greenman
:Co-founder, The FreeBSD Project - http://www.freebsd.org
I can significantly reduce page faulting for the above test
(rewritten in C below) with the following:
rm /etc/malloc.conf
ln -s /etc/malloc.conf
That cuts it down by a factor of 15 to 25.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
#include stdio.h
#include stdlib.h
#include unistd.h
int
main(int ac, char **av)
{
char *ptr = NULL;
int i;
for (i = 2; i 100; ++i)
ptr = realloc(ptr, i);
return(0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
In message [EMAIL PROTECTED], David Greenman writes:
The above perl program results in a loop more or less like:
n = 2
for (i = 0; i 100; i++)
realloc(n++);
Now, if you read _any_ malloc(3) man page, they will tell you that there
is no way it can be guaranteed that this does not result in a lot of
copying.
Um, except that copying isn't what is causing the problem. The performance
problem is apparantly caused by tens of thousands of page faults per second as
the memory is freed and immediately reallocated again from the kernel. Doesn't
phkmalloc keep a small pool of allocations around to avoid problems like
this?
Yes it does, but it doesn't help here. Basically what happens is
that relloc() is called on to extend a string of one megabyte by
another page, so it allocates 1M+1p and copies the contents over.
Now, in this very particular cornercase, we might be able to optimize
for just being able to allocate the next page, but in all real-world
scenarioes I've seen, real usage is more like:
long loop {
realloc(n++);
do some other stuff involving malloc/free/realloc
}
which negates that optimization.
But if somebody wants to try to code this optimization, I'll be more
than happy to review the result. I just don't expect it to do much
in real-life as opposed to silly benchmark situations.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
On Thu, Mar 14, 2002 at 12:47:29PM +0700, John Indra wrote: And to clarify things... I don't know what's wrong with malloc() in -CURRENT and -STABLE (and I don't even know whether it's even wrong). All I want is to let the Perl maintainer in -CURRENT and -STABLE to compile the stock Perl with its own malloc library, thus Perl in FreeBSD doesn't suffer from this kind of slowness. phkmalloc is generally pretty efficient..how do you know that switching to the perl internal malloc to optimize this particular usage pattern won't severely pessimize others? If you read the bug report, you'll see that using perl's malloc results in the program running more than 10 times faster. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
In message: [EMAIL PROTECTED] Ed Hall [EMAIL PROTECTED] writes: : Exception-handling is broken with -O in -stable, and has been for years. : FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds : to implement exceptions, so when the GCC folks broke that path, it was : never fixed. There are supposedly patches floating around that fix the : problem, but they either didn't work as advertised or the ball got dropped. H, C++ exceptions work in -stable with -O and have for at least a year. At least they are working for us in our environment. What's busted? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
On Wed, Mar 13, 2002 at 10:42:08PM -0800, David Greenman wrote: On Thu, Mar 14, 2002 at 12:47:29PM +0700, John Indra wrote: And to clarify things... I don't know what's wrong with malloc() in -CURRENT and -STABLE (and I don't even know whether it's even wrong). All I want is to let the Perl maintainer in -CURRENT and -STABLE to compile the stock Perl with its own malloc library, thus Perl in FreeBSD doesn't suffer from this kind of slowness. phkmalloc is generally pretty efficient..how do you know that switching to the perl internal malloc to optimize this particular usage pattern won't severely pessimize others? If you read the bug report, you'll see that using perl's malloc results in the program running more than 10 times faster. Yah, that program..phk seems to be saying that he believes the malloc usage pattern is atypical for applications in general, so it's conceivable that there are also other common usage patterns within perl which would be optimized by phkmalloc and not by the internal malloc. It should be benchmarked more thoroughly before the switch is made; there's only one datapoint at the moment, which isn't enough to decide whether it's a net win. Kris msg36060/pgp0.pgp Description: PGP signature
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
David Greenman wrote: The above perl program results in a loop more or less like: n = 2 for (i = 0; i 100; i++) realloc(n++); Now, if you read _any_ malloc(3) man page, they will tell you that there is no way it can be guaranteed that this does not result in a lot of copying. Um, except that copying isn't what is causing the problem. The performance problem is apparantly caused by tens of thousands of page faults per second as the memory is freed and immediately reallocated again from the kernel. Doesn't phkmalloc keep a small pool of allocations around to avoid problems like this? It's the other order, since it has to copy the prior contents... the new memory is malloc'ed, and the old is freed. Poul is right that a remmap() would be useful, in order to move only the mappings, leaving the pages intact, to grow the mmap'ed region and relocate it at the same time. Another thing that's common in most malloc implementations that are less picky than phkmalloc is growth by power-of-2 on each allocation, causing the allocated region to double, after the first realloc, on each grow. The best performance that this will get, though, is the same performance that the per process open file table grow gets (i.e. pretty bad). The remmap is a better idea. It might be wedged into the exiting mmap for a malloc of the same object with a larger size (e.g. remapping MAP_ANON memory with a larger size and a non-zero address implies a zero address, same pages, larger allocation, since mapping over an existing mapping makes no sense). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Ed Hall [EMAIL PROTECTED] writes: : Exception-handling is broken with -O in -stable, and has been for years. : FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds : to implement exceptions, so when the GCC folks broke that path, it was : never fixed. There are supposedly patches floating around that fix the : problem, but they either didn't work as advertised or the ball got dropped. H, C++ exceptions work in -stable with -O and have for at least a year. At least they are working for us in our environment. What's busted? Per thread exception stacks? THat's where I'd look... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
On Thu, 2002-03-14 at 01:48, Kris Kennaway wrote: It should be benchmarked more thoroughly before the switch is made; there's only one datapoint at the moment, which isn't enough to decide whether it's a net win. Another thing to watch out for: we now force -Uusemymalloc in perl builds because mixing malloc() implementations can lead to core dumps when a chunk of memory is handed to the wrong version of free() (or realloc()). (A test of this is to use Data::Dumper-Dump() (*not* Dumpxs()! that is in fact the workaround...) to print lots of complex hashes; this fairly reliably makes perl dump core (or sometimes just die with a Bizarre copy of ...) on all our supported platforms when perl's malloc() is used. Of course, that might just be a bug in 5.00503, since I never tried 5.6.x with perl's own malloc()...) -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
Fyi: perl-5.7.3/pod/perldelta.pod says Incompatible Changes 64-bit platforms and malloc If your pointers are 64 bits wide, the Perl malloc is no longer being used because it does not work well with 8-byte pointers. Also, usually the system mallocs on such platforms are much better optimized for such large memory models than the Perl malloc. Some memory-hungry Perl applications like the PDL don't work well with Perl's malloc. Finally, other applications than Perl (like modperl) tend to prefer the system malloc. Such platforms include Alpha and 64-bit HPPA, MIPS, PPC, and Sparc. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
Terry Lambert wrote: The remmap is a better idea. It might be wedged into the exiting mmap for a malloc of the same object with a larger size (e.g. remapping MAP_ANON memory with a larger size and a non-zero address implies a zero address, same pages, larger allocation, since mapping over an existing mapping makes no sense). Actually, there are a lot of options for this. The first thing that mmap does is convert the len from a size_t into an ssize_t -- from unsigned to signed -- and then checks the sign bit, and disallows the request entirely. If it fit the profile, it could have the sign inverted, and the remmap semantics, instead. Similarly, there is a check for an fd != -1 in the MAP_ANON case, that disallows it if it's not -1. Any non -1 value could be interpreted as special. In addition, you could jam the remap semantics into the flags (e.g. adding a MAP_REMAP), or into the prot flag, if the flags bits were too precious (there're plenty available, actually). Validating that the existing mapping is present and anonymous would be a case of looking it up. Actually, vm_mmap uses NULL and 0 compares on a pointer value interchangalby... style violation, that. Probably, you would need to put the old size into the fd field, if you wanted to be sure that it didn't accidently do the wrong thing... it seems that differentiating one ANON mapping region form one contuguous and following it is rather difficult... depending on the implementaiton of phkmalloc, you might have to constrain the caller to even pages, if you want it to be able to work without perhaps taking a combined split region on a realloc of an alloc'ed area, and breaking it. You could get this information from the (noncontiguous) metadata area, but it would not be general, and would still need to be pushed into the kernel somehow. Given that the length is limited effectively to a signed int, even though the man page lists it as a size_t (unsigned int), passing the old size in the fd doesn't seem that abominable... In the worst case of many consecutive reallocations, you would probably want to check the region for the new mapping to see if it was clear, and do a map add, rather than a remap (technically), you would end uprotoring through three adjacent mapping sets, otherwise (looking for the hole in the map). For a very big allocation, this means that for an N-N+1 allocation delta, N could never exceed 1/3 of the user process address space after the process itself not including the realloc in question, was subtracted out.. plus one page. But that's really a micro-optimization that won't be hit (until the first time someone starts testing the speedup claims... 8-)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
