5.0-RUSH: -current install testers wanted!
I built a make release overnight and I managed to install from it by copying the boot.flp image to a ZIP disk, selecting Minimum and FTP passive. So far so good. But we all know that sysintall has a few more bells and whistles than that, so NOW is the TIME of all good men to come to the aid of their favourite installer! I want as many people as possible to beat up on sysinstall as much as they can. And I want them to do it RSN: 5.0-R is only 9 days away. Please try to be creative in the choices you make in sysinstall, we don't need 20 people all testing ftp-passive, we need to get all the media options tested, IPv4 and IPv6, all the different distributions, scripted installs, on different hardware configs and so. If you find problems, please try to see if you reproduce them, if you can, try to see if you can isolate them to some particular menu choice or set of circumstances. Please report your findings with send-pr. If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. I can't promise to fix all the issues which come up, but I will do my very best... -- 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
make release run output
i386 release succeeded sparc64 release succeeded pc98 release failed : /usr/src/sys/pc98/i386/machdep.c:2371: structure has no member named `dr0' : ... alpha release failed : sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt :1440 /R/stage/image.kern 8 fd1440 : ... : cpio: write error: No space left on device Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45002/pgp0.pgp Description: PGP signature
Re: make release run output
Thankyou! This is most valuable at this time! Do we have some volunteers chasing the pc98 and alpha issues ? Poul-Henning In message [EMAIL PROTECTED], Ruslan Ermilov writes: --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable i386 release succeeded sparc64 release succeeded pc98 release failed : /usr/src/sys/pc98/i386/machdep.c:2371: structure has no member named `dr0' : ... alpha release failed : sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/sta= ge /mnt 1440 /R/stage/image.kern 8 fd1440 : ... : cpio: write error: No space left on device Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9tPIMUkv4P6juNwoRAu29AJ9bLguvYFj24I70+CyW2kibpsDB9QCcCNeK F/0O5Msawf3A6sOLUGonLBk= =mKIc -END PGP SIGNATURE- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- 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: 5.0-RUSH: -current install testers wanted!
Poul-Henning Kamp wrote: I want as many people as possible to beat up on sysinstall as much as they can. And I want them to do it RSN: 5.0-R is only 9 days away. Please try to be creative in the choices you make in sysinstall, we don't need 20 people all testing ftp-passive, we need to get all the media options tested, IPv4 and IPv6, all the different distributions, scripted installs, on different hardware configs and so. If you find problems, please try to see if you reproduce them, if you can, try to see if you can isolate them to some particular menu choice or set of circumstances. Please report your findings with send-pr. Ad-Hoc testing is unlikely to find problems; if you are expecting a certain class of problems, it's best to treat them, up front. There are a number of systems right now with broken INT 0x12 implementations which will not boot at all right now (they panic almost immediately). I think you are going to end up with a lot of bug reports not related to the problems you are trying to prevent/address. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release run output
On Tue, Oct 22, 2002 at 08:41:38AM +0200, Poul-Henning Kamp wrote: Thankyou! This is most valuable at this time! Do we have some volunteers chasing the pc98 and alpha issues ? I thought you'd fix pc98. These were your changes, weren't they? :-) In message [EMAIL PROTECTED], Ruslan Ermilov writes: --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable i386 release succeeded sparc64 release succeeded pc98 release failed : /usr/src/sys/pc98/i386/machdep.c:2371: structure has no member named `dr0' : ... alpha release failed : sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/sta= ge /mnt 1440 /R/stage/image.kern 8 fd1440 : ... : cpio: write error: No space left on device Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED]Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.comEnabling The Information Age --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9tPIMUkv4P6juNwoRAu29AJ9bLguvYFj24I70+CyW2kibpsDB9QCcCNeK F/0O5Msawf3A6sOLUGonLBk= =mKIc -END PGP SIGNATURE- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- 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. -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45005/pgp0.pgp Description: PGP signature
Re: make release run output
In message [EMAIL PROTECTED], Ruslan Ermilov writes: --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2002 at 08:41:38AM +0200, Poul-Henning Kamp wrote: =20 Thankyou! =20 This is most valuable at this time! =20 Do we have some volunteers chasing the pc98 and alpha issues ? =20 I thought you'd fix pc98. These were your changes, weren't they? :-) Right now getting sysinstall and libdisk to grok sparc64 has higher priority for me. The fixes needed to pc98 are trivial so any random committer can probably do that faster than I can get to it. -- 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: 5.0-RUSH: -current install testers wanted!
* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2002-10-21 ] [ Subjecte: 5.0-RUSH: -current install testers wanted! ] I want as many people as possible to beat up on sysinstall as much as they can. I've been fighting to find a way to install -CURRENT pure on my workstation using the 4.7 CD I just got in the mail, to no avail, because of the bin-base thing. But with the 4.7 installer, bouncing around in the FTP and networking screens, having done the restart sysinstall thing once, I managed to get a SIG11, though I couldn't reproduce it with debugging on. Anyone with a good idea on how to bootstrap a _clean_ 5.0 install to a box with only a CDROM drive, and 4.7 CD, with broken PXE firmware, and an IDE disk which can be thrashed, by all means tell me... I'd imagine that I could just use the mfsroot and kernel, but there's no way for me to disable atkbd/atkbdc that _I_ know of, in the post-userconfig world, and my keyboard is broken at the mountroot prompt, as the atkbdc detected based on my usb keyboard makes neither interface work, as both are exposed to the kernel. I've never had to install CURRENT on here without the ability to burn a bootable CD, and use userconfig... Yes, it was that long ago that I did my initial install. Thoughts? Yes, I could build my own kernel and fake it, but I can't do that in a real, user environment, and I'd love to have some idea of what might be possible... Damned Korean legacy-free box :/ Thanks, juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Juli Mallett wrote: Anyone with a good idea on how to bootstrap a _clean_ 5.0 install to a box with only a CDROM drive, and 4.7 CD, with broken PXE firmware, and an IDE disk which can be thrashed, by all means tell me... I'd imagine that I could just use the mfsroot and kernel, but there's no way for me to disable atkbd/atkbdc that _I_ know of, in the post-userconfig world, and my keyboard is broken at the mountroot prompt, as the atkbdc detected based on my usb keyboard makes neither interface work, as both are exposed to the kernel. I've never had to install CURRENT on here without the ability to burn a bootable CD, and use userconfig... Yes, it was that long ago that I did my initial install. Thoughts? Find another box where it has already been successfully installed, and an ISO image has been built from sources. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] Juli Mallett wrote: Anyone with a good idea on how to bootstrap a _clean_ 5.0 install to a box with only a CDROM drive, and 4.7 CD, with broken PXE firmware, and an IDE disk which can be thrashed, by all means tell me... I'd imagine that I could just use the mfsroot and kernel, but there's no way for me to disable atkbd/atkbdc that _I_ know of, in the post-userconfig world, and my keyboard is broken at the mountroot prompt, as the atkbdc detected based on my usb keyboard makes neither interface work, as both are exposed to the kernel. I've never had to install CURRENT on here without the ability to burn a bootable CD, and use userconfig... Yes, it was that long ago that I did my initial install. Thoughts? Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
It seems Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. Where do you live ? I'm sure we can find someone with a CD burner near you willing to make a copy and snailmail it to you... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Soeren Schmidt [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] It seems Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. Where do you live ? I'm sure we can find someone with a CD burner near you willing to make a copy and snailmail it to you... (Consider this a beg for anyone close enough for it to be cost effective to send me a 5.0-CURRENT snapshot CD, on which I can somehow disable the atkbdc/atkbd stuff at bootup, or which has them out of the kernel...) Juli Mallett 11145 W 76th Terrace Shawnee, KS 66214 United States Thanks for the idea :) juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. You don't burn a CD from the other box, you install from it. Though FreeBSD doesn't technically support it, because they do not make the sysinstall image easily available, you can upgrade via a CDROM FS image via NFS, without even needing a local CDROM installed on the machine being upgraded. To do this, copy over /stand/sysinstall to /tmp/sysinstall (it is crunched, therefore av[0] needs to be sysinstall), mount the image via NFS, run the sysinstall in /tmp, and select local file system for the media from which you will be upgrading. You must manullay run disklabel to change the boot code, after the upgrade, and prior to the reboot (the upgrade code in sysinstall makes assumptions about the boot media when it comes to the boot code installation, and those assumptions are often invalis, as in this case). If you are using SSH, you will potentially need to add the ssh line to the pam.conf file, or you will need physical console access to get back into the machine after you reboot with the new OS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. You don't burn a CD from the other box, you install from it. Though FreeBSD doesn't technically support it, because they do not make the sysinstall image easily available, you can upgrade via a CDROM FS image via NFS, without even needing a local CDROM installed on the machine being upgraded. To do this, copy over /stand/sysinstall to /tmp/sysinstall (it is crunched, therefore av[0] needs to be sysinstall), mount the image via NFS, run the sysinstall in /tmp, and select local file system for the media from which you will be upgrading. You must manullay run disklabel to change the boot code, after the upgrade, and prior to the reboot (the upgrade code in sysinstall makes assumptions about the boot media when it comes to the boot code installation, and those assumptions are often invalis, as in this case). If you are using SSH, you will potentially need to add the ssh line to the pam.conf file, or you will need physical console access to get back into the machine after you reboot with the new OS. If I wanted to do this, I could, but it would not give me a clean 5.0 install, and it is also not that simple at this time, as (afaict) kern.disks is required by sysinstall, which 4.x doesn't support... And even then, I'd have to blow away everything except /tmp first, which is a hell of a lot of fun, especially when it (often) doesn't work... -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
On Sat, Oct 19, 2002 at 07:54:01PM -0700, Kris Kennaway wrote: World is broken if you try and build with -fno-builtin: c++ -O -pipe -ggdb -fno-builtin -march=pentium3 -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o gen-perf.o hash-table.o iterator.o key-list.o list-node.o main.o new.o options.o read-line.o trace.o vectors.o version.o hash.o getopt.o getopt1.o gen-perf.o: In function `Gen_Perf::Gen_Perf()': /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45014/pgp0.pgp Description: PGP signature
Re: 5.0-RUSH: -current install testers wanted!
Juli Mallett wrote: If I wanted to do this, I could, but it would not give me a clean 5.0 install, and it is also not that simple at this time, as (afaict) kern.disks is required by sysinstall, which 4.x doesn't support... And even then, I'd have to blow away everything except /tmp first, which is a hell of a lot of fun, especially when it (often) doesn't work... If you want a *clean* 5.0 install, you will have to burn a CDROM, mount up a disk to be the target of a make installworld, or use PXE. Period. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
On Tue, Oct 22, 2002 at 12:10:25AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 5 umass0: Get Max Lun not supported (STALLED) da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 0H 0S/T 0C) but there's only /dev/da2 under /dev, and no entries for the slices. Shouldn't devfs or usbd or something create them automatically, since MAKEDEV is no more? You can probably trigger a re-examination of the device by opening it for write and closing again. Something as simple as sh -c true 4/dev/da2 may do the trick. It's just the Name that don't exist. Some time ago I was told to just open the device even if there is no node listable in /dev. E.g. mount_msdosfs /dev/da2s1 /mnt This is a pre GEOM scenario, so it might have been fixed. Also the panic is a pre GEOM panic - at least for me. I wouldn't give it much time to debug before rechecking with a recent kernel. I can't update my machine right now, but if Lars could update his system and recheck the situation... -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. snapshots.jp.freebsd.org hasn't completed a make release since September 17th by the looks of things. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ld: unrecognised emulation mode: elf_i386
On my recent -current system I'm getting strange problems when trying to compile some source, eg comms/birda: === Building for birda-1.00 === lib Warning: Object directory not changed from original /usr/ports/comms/birda/work/birda-1.00/lib cc -O -pipe -march=pentium3 -march=pentium3 -I/usr/ports/comms/birda/work/birda-1.00/lib/../src -c /usr/ports/comms/birda/work/birda-1.00/lib/../src/unix.c -o unix.o ld: unrecognised emulation mode: elf_i386 Supported emulations: elf_i386_fbsd *** Error code 1 Stop in /usr/ports/comms/birda/work/birda-1.00/lib. *** Error code 1 Stop in /usr/ports/comms/birda/work/birda-1.00. *** Error code 1 And I've had the same problem with some other ports/source too, here's the version of gcc: Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) Any help would be appreciated :) -- Simon Dick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Building -CURRENT with 4.5-RELEASE
On Tue, Oct 22, 2002 at 04:25:23AM +0200, Gerhard Haering wrote: Is it possible, or do I need to use a more recent installation to be able to build -CURRENT? Yes, it is. It should even be possible to build -CURRENT with as early as 4.0-RELEASE. If it doesn't, please drop me a line. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45019/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
On Mon, Oct 21, 2002 at 02:10:01PM -0400, Andrew Gallatin wrote: Ruslan, Can you help with this, please? I think you're the best candidate since you know so much about the build system and you are the groff maintainer. I've found that if I just cd to /usr/src/share/doc and do a 'make' groff works like a charm. But from inside make buildworld, groff a) emits 'out of memory warnings' on each file processed b) produces empty output files c) eventually dies, killing the build Assuming that I installed the version of groff made by buildworld, along with libc.so, libm.so, and libstdc++.so (all built by buildworld) prior to running make in /usr/src/share/doc, can you please explain what's different about groff in the buildworld case? I'm tearing my hair out trying to figure out what broke. Trying it now on beast. Will keep you updated. I seem to have already found what seems to be a culprit, but it barfs differently here. Thanks, Drew stage 4: building everything.. -- === share/doc/usd/13.viref out of memory *** Error code 255 -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45020/pgp0.pgp Description: PGP signature
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === share/doc/usd/13.viref out of memory *** Error code 255 Stop in /h/des/src/share/doc/usd/13.viref. *** Error code 1 Stop in /h/des/src/share/doc/usd. *** Error code 1 Stop in /h/des/src/share/doc. *** Error code 1 Stop in /h/des/src/share. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Dynamic growth of the buffer and buffer page reclaim
Introduction: The I/O buffer of the kernel are currently allocated in buffer_map sized statically upon boot, and never grows. This limits the scale of I/O performance on a host with large physical memory. We used to tune NBUF to cope with that problem. This workaround, however, results in a lot of wired pages not available for user processes, which is not acceptable for memory-bound applications. In order to run both I/O-bound and memory-bound processes on the same host, it is essential to achieve: A) allocation of buffer from kernel_map to break the limit of a map size, and B) page reclaim from idle buffers to regulate the number of wired pages. The patch at: http://people.FreeBSD.org/~tanimura/patches/dynamicbuf.diff.gz implements buffer allocation from kernel_map and reclaim of buffer pages. With this patch, make kernel-depend make kernel completes about 30-60 seconds faster on my PC. Implementation in Detail: A) is easy; first you need to do s/buffer_map/kernel_map/. Since an arbitrary number of buffer pages can be allocated dynamically, buffer headers (struct buf) should be allocated dynamically as well. Glue them together into a list so that they can be traversed by boot() et. al. In order to accomplish B), we must find buffers both the filesystem and I/O codes will not touch. The clean buffer queue holds such the buffers. (exception: if the vnode associated with a clean buffer is held by the namecache, it may access the buffer page.) Thus, we should unwire the pages of a buffer prior to enqueuing it to the clean queue, and rewire the pages down in bremfree() if the pages are not reclaimed. Although unwiring gives a page a chance of being reclaimed, we can go further. In Solaris, it is known that file cache pages should be reclaimed prior to the other kinds of pages (anonymous, executable, etc.) for a better performance. Mainly due to a lack of time to work on distinguishing the kind of a page to be unwired, I simply pass all unwired pages to vm_page_dontneed(). This approach places most of the unwired buffer pages at just one step to the cache queue. Experimental Evaluation and Results: The times taken to complete make kernel-depend make kernel just after booting into single-user mode have been measured on my ThinkPad 600E (CPU: Pentium II 366MHz, RAM: 160MB) by time(1). The number passed to the -j option of make(1) has been varied from 1 to 30 in order to control the pressure of the memory demand for user processes. The baseline is the kernel without my patch. The following table shows the results. All of the times are in seconds. -j baselinew/ my patch realusersys realusersys 1 1608.21 1387.94 125.96 1577.88 1391.02 100.90 10 1576.10 1360.17 132.76 1531.79 1347.30 103.60 20 1568.01 1280.89 133.22 1509.36 1276.75 104.69 30 1923.42 1215.00 155.50 1865.13 1219.07 113.43 Most of the improvements in the real times are accomplished by the speedup of system calls. The hit ratio of getblk() may be increased, but not examined yet. Another interesting results are the numbers of swaps, shown below. -j baselinew/ my patch 1 0 0 10 0 0 20 141 77 30 530 465 Since the baseline kernel does not free buffer pages at all(*), it may be putting a pressure on the pages too much. (*) bfreekva() is called only when the whole KVA is too fragmented. Userland Interfaces: The sysctl variable vfs.bufspace now reports the size of the pages allocated for buffer, both wired and unwired. A new sysctl variable, vfs.bufwiredspace tells the size of the buffer pages wired down. vfs.bufkvaspace returns the size of the KVA space for buffer. Future Works: The handling of unwired pages can be improved by scanning only buffer pages. In that case, we may have to run the vm page scanner more frequently, as does Solaris. vfs.bufspace does not track the buffer pages reclaimed by the page scanner. They are counted when the buffer associated with those pages are removed from the clean queue, which is too late. Benchmark tools concentrating on disk I/O performance (bonnie, iozone, postmark, etc) may be more suitable than make kernel for evaluation. Comments and flames are welcome. Thanks a lot. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
In message [EMAIL PROTECTED], Seigo Tanimur a writes: The patch at: http://people.FreeBSD.org/~tanimura/patches/dynamicbuf.diff.gz Comments and flames are welcome. Thanks a lot. This looks very very interesting! -- 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
smbfs broken?
When i tries to copy a file from smbfs share mounted by mount_smbfs i get an error: cp: ./filename: Bad address But when i copy a file to share i get kernel panic like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present current process= 531 (cp) trap number= 12 panic: page fault Share mounted from SAMBA server (FreeBSD 4.7-RELEASE) Last cvsup + buildworld was about 16-17 October 2002 uname -a FreeBSD neo.del.local 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 17 19:19:49 EEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 02:01:35PM +0300, Vitaly Markitantov [EMAIL PROTECTED] wrote: When i tries to copy a file from smbfs share mounted by mount_smbfs i get an error: cp: ./filename: Bad address But when i copy a file to share i get kernel panic like this: Fatal trap 12: page fault while in kernel mode fault virtual address= 0x0 fault code = supervisor write, page not present current process = 531 (cp) trap number = 12 panic: page fault Share mounted from SAMBA server (FreeBSD 4.7-RELEASE) Last cvsup + buildworld was about 16-17 October 2002 uname -a FreeBSD neo.del.local 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 17 19:19:49 EEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 My observations indicate same, I got instant panic while trying to copy any file from ro mounted smb share (NT4). First suspected Openoffice (xls file), but later found the real. For now sharity-light gives me chanche to get work done. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
Vitaly Markitantov wrote: When i tries to copy a file from smbfs share mounted by mount_smbfs i get an error: cp: ./filename: Bad address But when i copy a file to share i get kernel panic like this: Fatal trap 12: page fault while in kernel mode fault virtual address= 0x0 fault code = supervisor write, page not present current process = 531 (cp) trap number = 12 panic: page fault It would help a lot if you could provide a traceback. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current vs stable performance compare?
Where i can found performance comparison of -CURRENT over -STABLE systems? -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: smbfs broken?
On 22-Oct-2002 Vitaly Markitantov wrote: When i tries to copy a file from smbfs share mounted by mount_smbfs i get an error: cp: ./filename: Bad address But when i copy a file to share i get kernel panic like this: Fatal trap 12: page fault while in kernel mode fault virtual address= 0x0 Null pointer dereference. Can you compile DDB into the kernel and get a stack trace? fault code = supervisor write, page not present current process = 531 (cp) trap number = 12 panic: page fault Share mounted from SAMBA server (FreeBSD 4.7-RELEASE) Last cvsup + buildworld was about 16-17 October 2002 uname -a FreeBSD neo.del.local 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 17 19:19:49 EEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current vs stable performance compare?
In message [EMAIL PROTECTED], Vitaly Markitantov writes: Where i can found performance comparison of -CURRENT over -STABLE systems? Very little has been done yet, -CURRENT is not expected to perform particularly well until more of the kernel is out from under the Giant lock. -- 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: 5.0-RUSH: -current install testers wanted!
Hello. I downloaded the floppies for 5.0-20021021-SNAP from ftp2.freebsd.org. When I perform the install it complains a few times about not being able to create /tmp, due to a read-only filesystem, and, later in the install, cannot write /etc/resolv.conf, stopping the install dead in its tracks. This is before it creates the emergency shell, so I cannot remount / rw. Thanks. On Tuesday, October 22, 2002, at 02:33 AM, Poul-Henning Kamp wrote: I built a make release overnight and I managed to install from it by copying the boot.flp image to a ZIP disk, selecting Minimum and FTP passive. So far so good. But we all know that sysintall has a few more bells and whistles than that, so NOW is the TIME of all good men to come to the aid of their favourite installer! I want as many people as possible to beat up on sysinstall as much as they can. And I want them to do it RSN: 5.0-R is only 9 days away. Please try to be creative in the choices you make in sysinstall, we don't need 20 people all testing ftp-passive, we need to get all the media options tested, IPv4 and IPv6, all the different distributions, scripted installs, on different hardware configs and so. If you find problems, please try to see if you reproduce them, if you can, try to see if you can isolate them to some particular menu choice or set of circumstances. Please report your findings with send-pr. If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. I can't promise to fix all the issues which come up, but I will do my very best... -- 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 -- Kyle R. Green [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message [EMAIL PROTECTED], Kyle R.Green wr ites: Hello. I downloaded the floppies for 5.0-20021021-SNAP from ftp2.freebsd.org. When I perform the install it complains a few times about not being able to create /tmp, due to a read-only filesystem, and, later in the install, cannot write /etc/resolv.conf, stopping the install dead in its tracks. This bugs were fixed about 20 hours ago. -- 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
groff -ms breakage
It seems groff is failing to format most of the roff documentation in src/share/doc, for example psd/15.yacc. Here is the output that groff -Tascii -ms produces on -current: ss..:44: warning: number register `0:LL' not defined ss..:44: warning: number register `0:ri' not defined ss..:44: warning: number register `0:pri' not defined ss..:44: warning: number register `0:LT' not defined ss..:44: warning: number register `0:li' not defined ss..:44: warning: number register `0:pli' not defined ss..:44: warning: `FAM' not defined ss..:44: warning: number register `0:PS' not defined ss..:44: warning: number register `0:VS' not defined [etc.] ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.3i]: can't break line ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.5i]: can't break line ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.7i]: can't break line [etc.] Com- puter pro- gram input gen- er- ally has some struc- here is the output from the same command on 4.7-RELEASE: Computer program input generally has some structure; in fact, every computer program that does input can be thought of as defining an ``input language'' which it accepts. An input Reverting s.tmac to an earlier version does not seem to fix the problem. Also, postscript and html output formats seem much less broken than text. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Expensive timeout(9) function @an_stats_update() [/usr/src/sys/dev/an/if_an.c:724]
Noticed a bunch of: Expensive timeout(9) function: 0xc0170e40(0xc274c000) 0.001114387 from running (yesterday's) -CURRENT, so I thought I'd check against (yesterday's kernel.debug (before I replaced it with today's). Per nm -lan kernel.debug, I see: c0170420 T an_attach/usr/src/sys/dev/an/if_an.c:377 c0170a60 t an_rxeof /usr/src/sys/dev/an/if_an.c:529 c0170da0 t an_txeof /usr/src/sys/dev/an/if_an.c:687 c0170e40 t an_stats_update /usr/src/sys/dev/an/if_an.c:724 c0170f60 T an_intr /usr/src/sys/dev/an/if_an.c:761 c01711f0 t an_cmd /usr/src/sys/dev/an/if_an.c:829 c0171420 t an_reset /usr/src/sys/dev/an/if_an.c:875 (I thought a bit of additional contect might be of use.) I do have some patches to the an driver installed (from Doug Ambrisko) that don't seem to have been committed (yet?). If he (or anyone else) would like me to test things, I'm willing and able. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Mon, Oct 21, 2002 at 02:10:01PM -0400, Andrew Gallatin wrote: Ruslan, Can you help with this, please? I think you're the best candidate since you know so much about the build system and you are the groff maintainer. I've found that if I just cd to /usr/src/share/doc and do a 'make' groff works like a charm. But from inside make buildworld, groff a) emits 'out of memory warnings' on each file processed b) produces empty output files c) eventually dies, killing the build Assuming that I installed the version of groff made by buildworld, along with libc.so, libm.so, and libstdc++.so (all built by buildworld) prior to running make in /usr/src/share/doc, can you please explain what's different about groff in the buildworld case? I'm tearing my hair out trying to figure out what broke. Well, I tried this on beast. It is easily reproduceable. It turned out that if you build groff with -DNO_CPU_CFLAGS (the way it is built during the bootstrap-tools stage of buildworld), it fails with the `out of memory' error in contrib/groff/src/libs/libgroff/new.cc. To reproduce, it is only necessary to build the following dirs, in order, with -DNO_CPU_CFLAGS: gnu/usr.bin/groff/src/libs/libgroff gnu/usr.bin/groff/src/roff/groff And then run groff from the latter as follows: groff -V More fun. Groff is built with -fno-rtti and -fno-exceptions: : RCS file: /home/ncvs/src/gnu/usr.bin/groff/Attic/Makefile.cfg,v : Working file: Makefile.cfg : head: 2.13 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 36;selected revisions: 1 : description: : : revision 2.7 : date: 1999/04/04 16:44:33; author: obrien; state: Exp; lines: +2 -1 : This is old C++ code -- no need for rtti or exceptions. If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? I am Cc:ing our GCC gurus in a hope they can shed a light on this. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45034/pgp0.pgp Description: PGP signature
Re: smbfs broken?
On Tue, Oct 22, 2002 at 04:23:20AM -0700, Maxime Henrion [EMAIL PROTECTED] wrote: [snip] It would help a lot if you could provide a traceback. This is the one I'm seeing everytime while trying to copy file from ro smbfs mount. -current is about four days old, smbfs.ko _is_ compiled with -DSMP and in sync with kernel. Script started on Tue Oct 22 17:21:53 2002 bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vm core.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x2 fault code = supervisor read, page not present instruction pointer = 0x8:0x2 stack pointer = 0x10:0xdf9b6764 frame pointer = 0x10:0xdf9b6764 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 641 (cp) trap number = 12 panic: page fault cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks... panic: bdwrite: buffer is not busy cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 6m44s pfs_vncache_unload(): 1 entries remaining Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at ../../../kern/kern_shutdown.c:223 223 dumping++; (kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:223 #1 0xc022ccba in boot (howto=260) at ../../../kern/kern_shutdown.c:355 #2 0xc022cf77 in panic () at ../../../kern/kern_shutdown.c:508 #3 0xc0274c3d in bdwrite (bp=0xce3bfaf4) at ../../../kern/vfs_bio.c:950 #4 0xc031cb0b in ffs_update (vp=0xc458e4a0, waitfor=0) at ../../../ufs/ffs/ffs_inode.c:125 #5 0xc03309b2 in ffs_fsync (ap=0xdf9b6564) at ../../../ufs/ffs/ffs_vnops.c:315 #6 0xc032fad9 in ffs_sync (mp=0xc3fa8a00, waitfor=2, cred=0xc1324e80, td=0xc041cfc0) at vnode_if.h:612 #7 0xc02897f8 in sync (td=0xc041cfc0, uap=0x0) at ../../../kern/vfs_syscalls.c:130 #8 0xc022c89b in boot (howto=256) at ../../../kern/kern_shutdown.c:264 #9 0xc022cf77 in panic () at ../../../kern/kern_shutdown.c:508 #10 0xc039b5c2 in trap_fatal (frame=0xdf9b6724, eva=0) at ../../../i386/i386/trap.c:846 #11 0xc039b272 in trap_pfault (frame=0xdf9b6724, usermode=0, eva=2) at ../../../i386/i386/trap.c:760 #12 0xc039ace2 in trap (frame= {tf_fs = -1053753320, tf_es = 16, tf_ds = -543490032, tf_edi = -1001077964, tf_esi = -543463582, tf_ebp = -543463580, tf_isp = -543463600, tf_ebx = 0, tf_edx = -543461984, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs = 8, tf_eflags = 66178, tf_esp = -543463520, tf_ss = -1001019794}) at ../../../i386/i386/trap.c:446 #13 0xc0383f58 in calltrap () at {standard input}:99 #14 0xc455a66e in ?? () #15 0xc455a072 in ?? () #16 0xc4559e87 in ?? () #17 0xc45609f8 in ?? () #18 0xc035947d in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0) ---Type return to continue, or q return to quit--- at vnode_if.h:1265 #19 0xc0342ee3 in vm_fault (map=0xc3ff70cc, vaddr=671461376, fault_type=1 '\001', fault_flags=0) at vm_pager.h:124 #20 0xc039b165 in trap_pfault (frame=0xdf9b6a94, usermode=0, eva=671461376) at ../../../i386/i386/trap.c:736 #21 0xc039ace2 in trap (frame= {tf_fs = -543490024, tf_es = -1070333936, tf_ds = -1006698480, tf_edi = -796884992, tf_esi = 671461376, tf_ebp = -543462632, tf_isp = -543462720, tf_ebx = 16384, tf_edx = 671477760, tf_ecx = 4096, tf_eax = -543462144, tf_trapno = 12, tf_err = 0, tf_eip = -1069967698, tf_cs = 8, tf_eflags = 66054, tf_esp = -543462296, tf_ss = -543462308}) at ../../../i386/i386/trap.c:446 #22 0xc0383f58 in calltrap () at {standard input}:99 #23 0xc03313d1 in ffs_write (ap=0xdf9b6be8) at ../../../ufs/ffs/ffs_vnops.c:810 #24 0xc0291c1d in vn_write (fp=0xc4b4, uio=0xdf9b6c68, active_cred=0xc4337d80, flags=0, td=0xc3fbd9c0) at vnode_if.h:417 #25 0xc024ff45 in dofilewrite (td=0xc3fbd9c0, fp=0xc4b4, fd=4, buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215 #26 0xc024fdd9 in write (td=0xc3fbd9c0, uap=0xdf9b6d10) at ../../../kern/sys_generic.c:329 #27 0xc039b9ec in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4, tf_esi = 671461376, tf_ebp = -1077937512, tf_isp = -543462028, tf_ebx = 84480, tf_edx = 0, tf_ecx = 134672640, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134524975, tf_cs = 31, tf_eflags = 531, tf_esp =
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? Interesting. I wonder of the lack of exceptions is what's confusing ld? As to mpcu: On alphas, the compiler has more chance to make mistakes if its compiled for CPUs ev56 which do not support byte/word instructions. In those cases, it needs to generate shifty/masky code to pull 8 and 16 bit values out of 32-bit loads and stores. This has a history of being more error prone. Eg, some complex ports work on stable at high optimization levels with -mcpu=ev56 which don't work without -mpcu. If we have to, we can always compile groff as -mcpu=ev56 because we emulate these instructions in the kernel on older machines. That would make groff run about like molases in January on older machines, though, as each byte/word instruction would generate an illegal instruction trap and that trap would be handled by the alpha trap handler.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
On 22-Oct-2002 Vallo Kallaste wrote: On Tue, Oct 22, 2002 at 04:23:20AM -0700, Maxime Henrion [EMAIL PROTECTED] wrote: [snip] It would help a lot if you could provide a traceback. This is the one I'm seeing everytime while trying to copy file from ro smbfs mount. -current is about four days old, smbfs.ko _is_ compiled with -DSMP and in sync with kernel. Can you compile smbfs into your kernel 'options SMBFS' instead of as a module and then get a dump and provide a trace? Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x2 fault code= supervisor read, page not present instruction pointer = 0x8:0x2 #11 0xc039b272 in trap_pfault (frame=0xdf9b6724, usermode=0, eva=2) at ../../../i386/i386/trap.c:760 #12 0xc039ace2 in trap (frame= {tf_fs = -1053753320, tf_es = 16, tf_ds = -543490032, tf_edi = -1001077964, tf_esi = -543463582, tf_ebp = -543463580, tf_isp = -543463600, tf_ebx = 0, tf_edx = -543461984, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs = 8, tf_eflags = 66178, tf_esp = -543463520, tf_ss = -1001019794}) at ../../../i386/i386/trap.c:446 #13 0xc0383f58 in calltrap () at {standard input}:99 #14 0xc455a66e in ?? () #15 0xc455a072 in ?? () #16 0xc4559e87 in ?? () #17 0xc45609f8 in ?? () These frames are in smbfs and are where the bug is, but we obviously can't figure out much with just ??'s. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
On (2002/10/22 10:48), John Baldwin wrote: This is the one I'm seeing everytime while trying to copy file from ro smbfs mount. -current is about four days old, smbfs.ko _is_ compiled with -DSMP and in sync with kernel. Can you compile smbfs into your kernel 'options SMBFS' instead of as a module and then get a dump and provide a trace? Just to save some time in the feedback round-trip, I'd recommend adding all of these options, in case the bug is in an smbfs dependency: options SMBFS #SMB/CIFS filesystem options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB options LIBICONV#optional internationalization options LIBMCHAIN #mbuf management library Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Tue, Oct 22, 2002 at 10:45:52AM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? Interesting. I wonder of the lack of exceptions is what's confusing ld? Seems so. With -fno-exceptions and last delta to groff/Makefile backed out: $ roff/groff/groff -V /usr/libexec/ld-elf.so.1: roff/groff/groff: too few PT_LOAD segments The same, but without -fno-exceptions: $ roff/groff/groff -V troff -Tps | grops I wonder if the follwing commit might be relevant to the -DNOSHARED issue with groff: : kan 2002/10/19 16:03:35 PDT : : Modified files: : libexec/rtld-elf rtld.c : Log: : Change the symbol lookup order to search RTLD_GLOBAL objects : before referencing object's DAG. This makes it possible for : C++ exceptions to work across shared libraries and brings : us closer to the search order used by Solaris/Linux. : : Reviewed by:jdp : Approved by:obrien : MFC after: 1 month : : Revision ChangesPath : 1.68 +12 -12src/libexec/rtld-elf/rtld.c As to mpcu: On alphas, the compiler has more chance to make mistakes if its compiled for CPUs ev56 which do not support byte/word instructions. In those cases, it needs to generate shifty/masky code to pull 8 and 16 bit values out of 32-bit loads and stores. This has a history of being more error prone. Eg, some complex ports work on stable at high optimization levels with -mcpu=ev56 which don't work without -mpcu. If we have to, we can always compile groff as -mcpu=ev56 because we emulate these instructions in the kernel on older machines. That would make groff run about like molases in January on older machines, though, as each byte/word instruction would generate an illegal instruction trap and that trap would be handled by the alpha trap handler.. Can't we make it the default in GCC, or in share/mk/bsd.cpu.mk? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45039/pgp0.pgp Description: PGP signature
New-busified rc(4) - testers needed
At the request of another developer who has since been swamped and unable to actually test it, I converted the rc(4) driver over to new-bus. If anyone can test it I would appreciate it. Download the tarball http://www.FreeBSD.org/~jhb/patches/rc.tgz and unpack it into a -current kernel source tree. Build the 'rc' module and give it a go. It should work with the same hints that the old driver worked. Also, you should be able to kldunload the driver if none of the devices are open. If there are devices open, the kldunload should fail with EBUSY. Thanks. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: groff -ms breakage
On Tue, Oct 22, 2002 at 11:59:54PM +1000, Tim Robbins wrote: It seems groff is failing to format most of the roff documentation in src/share/doc, for example psd/15.yacc. Here is the output that groff -Tascii -ms produces on -current: ss..:44: warning: number register `0:LL' not defined ss..:44: warning: number register `0:ri' not defined ss..:44: warning: number register `0:pri' not defined ss..:44: warning: number register `0:LT' not defined ss..:44: warning: number register `0:li' not defined ss..:44: warning: number register `0:pli' not defined ss..:44: warning: `FAM' not defined ss..:44: warning: number register `0:PS' not defined ss..:44: warning: number register `0:VS' not defined [etc.] ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.3i]: can't break line ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.5i]: can't break line ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.7i]: can't break line [etc.] Com- puter pro- gram input gen- er- ally has some struc- here is the output from the same command on 4.7-RELEASE: Computer program input generally has some structure; in fact, every computer program that does input can be thought of as defining an ``input language'' which it accepts. An input Reverting s.tmac to an earlier version does not seem to fix the problem. Also, postscript and html output formats seem much less broken than text. Yes, I know. This is a result of my latest revision to contrib/groff/tmac/troffrc. Please feel free to back it out if you need to -- ENOTIME for this anymore today, all my spare time has been eaten by another groff problem on Alphas. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45041/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
On Tue, Oct 22, 2002 at 05:29:29PM +0300, Ruslan Ermilov wrote: On Mon, Oct 21, 2002 at 02:10:01PM -0400, Andrew Gallatin wrote: Ruslan, Can you help with this, please? I think you're the best candidate since you know so much about the build system and you are the groff maintainer. I've found that if I just cd to /usr/src/share/doc and do a 'make' groff works like a charm. But from inside make buildworld, groff a) emits 'out of memory warnings' on each file processed b) produces empty output files c) eventually dies, killing the build Assuming that I installed the version of groff made by buildworld, along with libc.so, libm.so, and libstdc++.so (all built by buildworld) prior to running make in /usr/src/share/doc, can you please explain what's different about groff in the buildworld case? I'm tearing my hair out trying to figure out what broke. Well, I tried this on beast. It is easily reproduceable. It turned out that if you build groff with -DNO_CPU_CFLAGS (the way it is built during the bootstrap-tools stage of buildworld), it fails with the `out of memory' error in contrib/groff/src/libs/libgroff/new.cc. To reproduce, it is only necessary to build the following dirs, in order, with -DNO_CPU_CFLAGS: gnu/usr.bin/groff/src/libs/libgroff gnu/usr.bin/groff/src/roff/groff And then run groff from the latter as follows: groff -V More fun. Groff is built with -fno-rtti and -fno-exceptions: : RCS file: /home/ncvs/src/gnu/usr.bin/groff/Attic/Makefile.cfg,v : Working file: Makefile.cfg : head: 2.13 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 36;selected revisions: 1 : description: : : revision 2.7 : date: 1999/04/04 16:44:33; author: obrien; state: Exp; lines: +2 -1 : This is old C++ code -- no need for rtti or exceptions. If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? I am Cc:ing our GCC gurus in a hope they can shed a light on this. Yeah, it only seems to work if you remove -fno-exceptions. It only makes ``groff -V'' work, but full groff invocations continue to fail with ``out of memory'' during the buildworld. So we apparently need to compile Groff with -mcpu=ev56, as Andrew suggested (I did not check will it help or not, and I do not have any more time today for this). But removing -fno-exceptions has a good impact on rtld(1) issue. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45042/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: Well, I tried this on beast. It is easily reproduceable. It turned out that if you build groff with -DNO_CPU_CFLAGS (the way it is built during the bootstrap-tools stage of buildworld), it fails with the `out of memory' error in contrib/groff/src/libs/libgroff/new.cc. To reproduce, it is only necessary to build the following dirs, in order, with -DNO_CPU_CFLAGS: gnu/usr.bin/groff/src/libs/libgroff gnu/usr.bin/groff/src/roff/groff And then run groff from the latter as follows: groff -V More fun. Groff is built with -fno-rtti and -fno-exceptions: FWIW, the out of memory is because it is attempting to malloc a huge amount of ram. Apparently mistakenly: (gdb) break /usr/src/contrib/groff/src/libs/libgroff/new.cc:45 Breakpoint 1 at 0x12000c9cc: file /usr/src/contrib/groff/src/libs/libgroff/new.cc, line 45. (gdb) r Starting program: /usr/src/gnu/usr.bin/groff/src/roff/groff/groff Breakpoint 1, operator new(unsigned long) (size=4832141312) at /usr/src/contrib/groff/src/libs/libgroff/new.cc:45 45if (p == 0) { (gdb) p/x size $1 = 0x12004a000 (gdb) Note that 0x12004a000 looks quite a bit like an address in the data segment. The stack looks like this (its happening before main is entered): (gdb) where #0 operator new(unsigned long) (size=4832141312) at /usr/src/contrib/groff/src/libs/libgroff/new.cc:45 #1 0x12000d528 in operator new[](unsigned long) () #2 0x12000c1ac in search_path (this=0x120035930, envvar=0x0, standard=0x12002b8b1 /usr/share/groff_font, add_home=1,add_current=0) at /usr/src/contrib/groff/src/libs/libgroff/searchpath.cc:39 #3 0x12000aec4 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)at /usr/src/contrib/groff/src/libs/libgroff/fontfile.cc:34 #4 0x12000af30 in _GLOBAL__I__ZN4font3resE ()at /usr/src/contrib/groff/src/libs/libgroff/fontfile.cc:34 #5 0x12002a0b8 in __do_global_ctors_aux () #6 0x12150 in _init () #7 0x12228 in _start () The code calling new is this bit of c++ code: (gdb) frame 2 #2 0x12000c1ac in search_path (this=0x120035930, envvar=0x0, standard=0x12002b8b1 /usr/share/groff_font, add_home=1, add_current=0) at /usr/src/contrib/groff/src/libs/libgroff/searchpath.cc:39 39dirs = new char[((e *e) ? strlen(e) + 1 : 0) (gdb) l 34if (add_home) 35 home = getenv(HOME); 36char *e = 0; 37if (envvar) 38 e = getenv(envvar); 39dirs = new char[((e *e) ? strlen(e) + 1 : 0) 40+ (add_current ? 1 + 1 : 0) 41+ ((home *home) ? strlen(home) + 1 : 0) 42+ ((standard *standard) ? strlen(standard) : 0) 43+ 1]; I have no idea what 'e' is, gdb doesn't like things declared in the middle of a scope, apparently. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Build breakage
From a tree that I updated last night, building on a 4.7-stable system: as -o boot2.o boot2.s as --defsym SIOPRT=0x3f8 --defsym SIOFMT=0x3 --defsym SIOSPD=9600 /home/imp/FreeBSD/src/sys/boot/i386/boot2/sio.s -o sio.o ld -nostdlib -static -N -Ttext 0x2000 -o boot2.out /usr/obj/home/imp/FreeBSD/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/home/imp/FreeBSD/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1498 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e18 text=200 data=1c18 org=0 entry=0 -24 bytes available *** Error code 1 I didn't see this a few days ago when I did a buildworld on my current box. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Anyone cares to post a ktrace? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Tue, 22 Oct 2002 11:39:43 -0400 Alexander Kabaev [EMAIL PROTECTED] wrote: Anyone cares to post a ktrace? -- Alexander Kabaev If this is a case of a brk(2) failing, then I have a patch in testing to fix that. Give me some time to finish. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Alexander Kabaev writes: On Tue, 22 Oct 2002 11:39:43 -0400 Alexander Kabaev [EMAIL PROTECTED] wrote: Anyone cares to post a ktrace? -- Alexander Kabaev If this is a case of a brk(2) failing, then I have a patch in testing to fix that. Give me some time to finish. I've appended a trace. Drew 1447 ktrace RET ktrace 0 1447 ktrace CALL execve(0x11fff963,0x11fff700,0x11fff718) 1447 ktrace NAMI ./groff 1447 groffRET execve 0 1447 groffCALL fstat(0x1,0x11ffefa0) 1447 groffRET fstat 0 1447 groffCALL readlink(0x12002da88,0x11ffef80,0x3f) 1447 groffNAMI /etc/malloc.conf 1447 groffRET readlink -1 errno 2 No such file or directory 1447 groffCALL mmap(0,0x2000,0x3,0x1002,0x,0,0) 1447 groffRET mmap 1073741824/0x4000 1447 groffCALL break(0x12004a000) 1447 groffRET break -1 errno 12 Cannot allocate memory 1447 groffCALL break(0x12004a000) 1447 groffRET break -1 errno 12 Cannot allocate memory 1447 groffCALL write(0x1,0x11ffec60,0xc) 1447 groffGIO fd 1 wrote 12 bytes size = 0x16 1447 groffRET write 12/0xc 1447 groffCALL break(0x12004a000) 1447 groffRET break -1 errno 12 Cannot allocate memory 1447 groffCALL write(0x2,0x12002b9df,0xe) 1447 groffGIO fd 2 wrote 14 bytes out of memory 1447 groffRET write 14/0xe 1447 groffCALL exit(0x) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
Bernd Walter wrote: It's just the Name that don't exist. Some time ago I was told to just open the device even if there is no node listable in /dev. E.g. mount_msdosfs /dev/da2s1 /mnt Yes, this works (Terry also pointed this out.) I wish this could be wired to the media change signal somehow. This is a pre GEOM scenario, so it might have been fixed. Also the panic is a pre GEOM panic - at least for me. I wouldn't give it much time to debug before rechecking with a recent kernel. I can't update my machine right now, but if Lars could update his system and recheck the situation... Just checkeded, and it does NOT crash anymore on bootup when no media is inserted (with yesterday's -current.) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: 5.0-RUSH: -current install testers wanted!
Last week I replace a broken mainboard with a dual-Athlon one (Tyan Tiger s2466n-4m) and decided to upgrade that box from 4-stable to -current by installing the 0917-jpsnap via the floppies and passive ftp. I hit several sysinstall-problems some of which my already be fixed: - The hd I install -current onto previously had 4-stable on it, I deleted slice one (was the only one) and created a new one and selected the standard MBR. I decided to give UFS2 a try and created the filesystems with '-O 2 -U' (there was some problem toggling Softupdates und just adding '-O 2' to the newfs-options). But after rebooting the 4-stable (!) bootloader came claiming it wasn't able to load /kernel, a `ls` at the bootloader-prompt showed the contents of the former root-fs, even the former contents of some of the sub- direcroties , e.g. /etc could be displayed. - After a `dd if=/dev/zero of=/dev/da0 count=16` (booted with another hd containing 4-stable) I repeated the above procedure and ended up with the -current bootloader yelling No UFS several times. For now I ended up having the root-fs UFS1 and var, usr and tmp UFS2. This problem seems to be on the todo-list. - During the 6-7 sysinstall-runs (it hung and crashed unreproduceable 4-5 times) I always had the problem that after configuring the nic with a ipv4-adress it took some random time between ~15 seconds up to several minutes to look up the hostname of the jpsnap-server. This definitely wasn't a network- or dns-problem, another box connected via the same line and using the same nameserver didn't have problems looking up the hostname. I ran tcpdump on the other box and the reason for this seems to be sysinstall doing ipv6 neigbhourhood-detection and ping6 the ipv6-address of the jpsnap- server also the interface wasn't configured for ipv6. I also saw some stuff that I don't know of what it is: fe80::2e0:81ff:fe22:d7cf ff02::2:f8c7:7880: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::2:f8c7:7880 [hlim 1] - The 3 or 4 times I got to the point to set the root password the prompt to enter it popped up in ttyv1 and not in tty0 like the rest of sysinstall. I wasn't actually able to set one but sysinstall returned to the post-install-configuration-menue when hitting ctrl-c in ttyv0. Some problems I have with the installed -current: - The bios of the board offers ACPI-support and as I thought FreeBSD's support of this is advanced enough I decided to turn it but it turned out to not be SMP-safe. I can't remeber a panic while running an UP-kernel for the short time to update to latest -current and build a SMP-kernel. When both ACPI- (via kld) and SMP-support are enabled the box is fscking unstable, I get about 3 lock-order-reversal- and locking-against-myself-panics per hour and occasionally spontaneous reboots. After turing of ACPI-support in the bios the ACPI-kld no longer gets loaded and the box runs stable for 3 days (no more panics or spontaneous reboots), still with the same kernel built of sources as of Oct 17. The mainboard has 2 pci-bridges, they and all devices behind them successfully get probed when running with ACPI enabled so this doesn't sound like the problem described in the todo-list. acpiconf doesn't work except for `acpiconf -s 1` (after an `acpiconf -e`), `acpiconf -s 1` turns off the output of the gfx- card for the fraction of second (once also the hd sounded as it would spin-down) and as soon it returns 2 resume-messages get displayed. Doing this causes a panic (pagefaults iirc) in about 1 of 5 times. - After the tons of panics I got the background fsck always cleaned up an alarming number of files and directories on the UFS2- filesystems, much more than I've ever seen after a panic of a 4-stable box. As I got most panics while extracting tarballs or building ports this could be ok but once also file I successfully downloaded some 30-60 seconds before a panic got deleted during the fsck-run, imho this shouldn't happen. Last but not least it would be fine if sysinstall would also support ATAPI-floppies (/dev/afd0) for mounting the fixit-floppy. I didn't check recently but I think support for mounting the live-cdrom in SCSI-cdroms is also broken, last time I tried it also wasn't possible to install from a SCSI-cdrom as sysinstall didn't detect /dev/cd0c. Hrm, the minor looks wrong in devices.c, could this be the reason ? static struct _devname { DeviceType type; char *name; char *description; int major, minor, delta, max; } device_names[] = { { DEVICE_TYPE_CDROM,cd%dc,SCSI CDROM drive, 15, 2, 8, 4 but: ls -la /dev/cd0c crw-r- 1 root operator 15, 0 Oct 22 19:02 /dev/cd0c At least the minor matches for acd0c. Marius To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 10:48:58AM -0400, John Baldwin [EMAIL PROTECTED] wrote: Can you compile smbfs into your kernel 'options SMBFS' instead of as a module and then get a dump and provide a trace? #13 0xc0383f58 in calltrap () at {standard input}:99 #14 0xc455a66e in ?? () #15 0xc455a072 in ?? () #16 0xc4559e87 in ?? () #17 0xc45609f8 in ?? () These frames are in smbfs and are where the bug is, but we obviously can't figure out much with just ??'s. I had all but SMBFS in kernel, mostly because it has been working only occasionally in the near past. Here's the improved backtrace, for more information you'll need to step me down your own path, I have no debugging skills. Script started on Tue Oct 22 20:57:11 2002 bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vmc ore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x2 fault code = supervisor read, page not present instruction pointer = 0x8:0x2 stack pointer = 0x10:0xd66eb758 frame pointer = 0x10:0xd66eb758 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 700 (cp) trap number = 12 panic: page fault cpuid = 0; lapic.id = boot() called on cpu#0 syncing disks... panic: bdwrite: buffer is not busy cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 18m27s pfs_vncache_unload(): 2 entries remaining Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at ../../../kern/kern_shutdown.c:223 223 dumping++; (kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:223 #1 0xc02367ea in boot (howto=260) at ../../../kern/kern_shutdown.c:355 #2 0xc0236aa7 in panic () at ../../../kern/kern_shutdown.c:508 #3 0xc027e76d in bdwrite (bp=0xce36b3b8) at ../../../kern/vfs_bio.c:950 #4 0xc032663b in ffs_update (vp=0xc42665c8, waitfor=0) at ../../../ufs/ffs/ffs_inode.c:125 #5 0xc033a4e2 in ffs_fsync (ap=0xd66eb558) at ../../../ufs/ffs/ffs_vnops.c:315 #6 0xc0339609 in ffs_sync (mp=0xc3fac600, waitfor=2, cred=0xc1341e80, td=0xc0435c00) at vnode_if.h:612 #7 0xc0293328 in sync (td=0xc0435c00, uap=0x0) at ../../../kern/vfs_syscalls.c:130 #8 0xc02363cb in boot (howto=256) at ../../../kern/kern_shutdown.c:264 #9 0xc0236aa7 in panic () at ../../../kern/kern_shutdown.c:508 #10 0xc03a7912 in trap_fatal (frame=0xd66eb718, eva=0) at ../../../i386/i386/trap.c:846 #11 0xc03a75c2 in trap_pfault (frame=0xd66eb718, usermode=0, eva=2) at ../../../i386/i386/trap.c:760 #12 0xc03a7032 in trap (frame= {tf_fs = -1004273640, tf_es = 16, tf_ds = -697434096, tf_edi = -1004220364, tf_esi = -697387178, tf_ebp = -697387176, tf_isp = -697387196, tf_ebx = 0, tf_edx = -697385568, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs = 8, tf_eflags = 66194, tf_esp = -697387116, tf_ss = -1069774098}) at ../../../i386/i386/trap.c:446 #13 0xc03902a8 in calltrap () at {standard input}:99 #14 0xc03c8aee in smb_smb_readx (ssp=0xc424d034, fid=2048, len=0xd66eb756, rresid=0xd66eb7f8, uio=0xd66eb868, scred=0x0) at ../../../netsmb/smb_smb.c:636 #15 0xc03c84f2 in smb_smb_read (ssp=0xc424eb00, fid=2048, len=0xd66eb7fc, rresid=0xd66eb7f8, uio=0xd66eb868, scred=0x0) at ../../../netsmb/smb_smb.c:739 #16 0xc03c8307 in smb_read (ssp=0xc424eb00, fid=2048, uio=0xd66eb7fc, scred=0xd66eb850) at ../../../netsmb/smb_smb.c:795 #17 0xc01f2deb in smbfs_getpages (ap=0x0) at ../../../fs/smbfs/smbfs_io.c:486 #18 0xc0362fad in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0) at vnode_if.h:1265 #19 0xc034ca13 in vm_fault (map=0xc4030198, vaddr=671461376, fault_type=1 '\001', fault_flags=0) at vm_pager.h:124 #20 0xc03a74b5 in trap_pfault (frame=0xd66eba94, usermode=0, eva=671461376) at ../../../i386/i386/trap.c:736 ---Type return to continue, or q return to quit--- #21 0xc03a7032 in trap (frame= {tf_fs = -697434088, tf_es = -1070268400, tf_ds = -1006436336, tf_edi = -823279616, tf_esi = 671461376, tf_ebp = -697386216, tf_isp = -697386304, tf_ebx = 16384, tf_edx = 671477760, tf_ecx = 4096, tf_eax = -697385728, tf_trapno = 12, tf_err = 0, tf_eip = -1069917698, tf_cs = 8, tf_eflags = 66054, tf_esp = -697385880, tf_ss = -697385892}) at
building -CURRENT on RELENG_4
hi, there! cross-building -CURRENT on RELENG_4 is broken in src/usr.bin/xlint/lint1: --- cut here --- ... sh /usr/fbsd/HEAD/src/usr.bin/xlint/lint1/makeman /usr/libexec/lint1 -m lint.7 lint1: illegal option -- m usage: lint1 [-abcdeghprstuvyzF] src dest gzip -cn lint.7 lint.7.gz --- cut here --- /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
emacs?
I'm confused about the -CURRENT emacs breakage. Is this an O.S. breakage which will eventually be fixed, or a permanent change which will require a patch to emacs? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
On Tue, Oct 22, 2002 at 11:22:41AM +0300, Ruslan Ermilov wrote: On Sat, Oct 19, 2002 at 07:54:01PM -0700, Kris Kennaway wrote: World is broken if you try and build with -fno-builtin: c++ -O -pipe -ggdb -fno-builtin -march=pentium3 -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o gen-perf.o hash-table.o iterator.o key-list.o list-node.o main.o new.o options.o read-line.o trace.o vectors.o version.o hash.o getopt.o getopt1.o gen-perf.o: In function `Gen_Perf::Gen_Perf()': /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. Kris msg45053/pgp0.pgp Description: PGP signature
Re: smbfs broken?
On 22-Oct-2002 Vallo Kallaste wrote: On Tue, Oct 22, 2002 at 10:48:58AM -0400, John Baldwin [EMAIL PROTECTED] wrote: Can you compile smbfs into your kernel 'options SMBFS' instead of as a module and then get a dump and provide a trace? #13 0xc0383f58 in calltrap () at {standard input}:99 #14 0xc455a66e in ?? () #15 0xc455a072 in ?? () #16 0xc4559e87 in ?? () #17 0xc45609f8 in ?? () These frames are in smbfs and are where the bug is, but we obviously can't figure out much with just ??'s. I had all but SMBFS in kernel, mostly because it has been working only occasionally in the near past. Here's the improved backtrace, for more information you'll need to step me down your own path, I have no debugging skills. Script started on Tue Oct 22 20:57:11 2002 bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vmc ore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x2 fault code= supervisor read, page not present instruction pointer = 0x8:0x2 As someone else has pointed out, it is executing at a garbage address which is why it panic'd. My guess is that smb_smb_readx() called some function which had a buffer overflow of a variable on the stack and trashed the return address. Actually, there are some bugs in the mbchains code. I've just committed a possible fix. Can you cvsup and try out revision 1.9 of subr_mchain.c and see if it works better? Thanks. #14 0xc03c8aee in smb_smb_readx (ssp=0xc424d034, fid=2048, len=0xd66eb756, rresid=0xd66eb7f8, uio=0xd66eb868, scred=0x0) at ../../../netsmb/smb_smb.c:636 md_get_uint16le(mdp, NULL); The md_get_* functions didn't all handle the case of the second argument being NULL properly. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
--On mardi 22 octobre 2002 10:08 +0100 Ceri Davies [EMAIL PROTECTED] wrote: On Tue, Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. snapshots.jp.freebsd.org hasn't completed a make release since September 17th by the looks of things. I was willing to install a fresh -current, I'm trying to make release from a -stable box, but I don't believe it will end well. Could someone make release from a recent -current so that many of us could install it ? -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
Vallo Kallaste wrote: On Tue, Oct 22, 2002 at 04:23:20AM -0700, Maxime Henrion [EMAIL PROTECTED] wrote: [snip] It would help a lot if you could provide a traceback. This is the one I'm seeing everytime while trying to copy file from ro smbfs mount. -current is about four days old, smbfs.ko _is_ compiled with -DSMP and in sync with kernel. [ ... ] Everyone is reporting a bug similar to this; it is probably a problem in the memory allocator. #11 0xc039b272 in trap_pfault (frame=0xdf9b6724, usermode=0, eva=2) at ../../../i386/i386/trap.c:760 #12 0xc039ace2 in trap (frame= {tf_fs = -1053753320, tf_es = 16, tf_ds = -543490032, tf_edi = -1001077964, tf_esi = -543463582, tf_ebp = -543463580, tf_isp = -543463600, tf_ebx = 0, tf_edx = -543461984, tf_ecx = 0, tf_eax = 14, tf_trapno = 12, tf_err = 0, tf_eip = 2, tf_cs = 8, tf_eflags = 66178, tf_esp = -543463520, tf_ss = -1001019794}) at ../../../i386/i386/trap.c:446 #13 0xc0383f58 in calltrap () at {standard input}:99 #14 0xc455a66e in ?? () #15 0xc455a072 in ?? () #16 0xc4559e87 in ?? () #17 0xc45609f8 in ?? () If you are running the smbfs.ko, either load the module symbols into gdb before asking for the traceback, or statically compile SMBFS into the kernel. We need the intermediate code. #18 0xc035947d in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0) ...though the fact that this happened agains the vn device on an SMBFS from a file write is pretty indicative that you are running a vnconfig'ed device on top of an SMBFS file. This is probably not a good thing to do. It would be nice if you could give us more information as to exactly what it is you are doing, logically, to cause this problem; as things sit, it seems you are doing some evil things. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
On Tue, 22 Oct 2002, Seigo Tanimura wrote: Introduction: [...] The patch at: http://people.FreeBSD.org/~tanimura/patches/dynamicbuf.diff.gz Cool.. -jbaselinew/ my patch realusersys realusersys 1 1608.21 1387.94 125.96 1577.88 1391.02 100.90 101576.10 1360.17 132.76 1531.79 1347.30 103.60 201568.01 1280.89 133.22 1509.36 1276.75 104.69 301923.42 1215.00 155.50 1865.13 1219.07 113.43 definitly statistically significant. Another interesting results are the numbers of swaps, shown below. -jbaselinew/ my patch 1 0 0 100 0 20141 77 30530 465 this too. Comments and flames are welcome. Thanks a lot. No flames.. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage. Is this an O.S. breakage which will eventually be fixed, or a permanent change which will require a patch to emacs? Thanks. This is a permanent change. The new binutils defaults have changed to generate binaries, which are more convenient for runtime linker to relocate. The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dmesg warnings, related to acpi?
I have two \\_SB_.PCI0 related warnings being output at boot. The one about AE_BAD_DATA is fairly recent, but I don't know what kernel it appeared with. I moved recently and haven't have a smooth upgrade path. The FDC0 - AE_AML_UNINITIALIZED_LOCAL warning has been around for some time. Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Tue Oct 22 09:07:41 CDT 2002 root@max:/usr/obj/usr/src/sys/MAXKERNEL Preloaded elf kernel /boot/kernel/kernel at 0xc053d000. Preloaded elf module /boot/kernel/acpi.ko at 0xc053d0a8. Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (933.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,FXSR,SSE real memory = 402587648 (393152K bytes) avail memory = 384352256 (375344K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 9 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 5 IOAPIC #0 intpin 19 - irq 11 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard Using $PIR table, 8 entries at 0xc00fdb50 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.FDC0 - AE_AML_UNINITIALIZED_LOCAL acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xc f8-0xcff on acpi0 pcib0: could not get PCI interrupt routing table for \\_SB_.PCI0 - AE_BAD_DATA initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: 3dfx Voodoo5 port 0xc000-0xc0ff mem 0xd000-0xd7ff,0xd800-0xd bff irq 9 at device 0.0 on pci1 info: [drm] Initialized tdfx 1.0.0 20010216 on minor 0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C596 ATA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 11 at device 7.2 on pc i0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 pci0: bridge, HOST-PCI at device 7.3 (no driver attached) ahc0: Adaptec 2940 Ultra2 SCSI adapter (OEM) port 0xd800-0xd8ff mem 0xe5101000 -0xe5101fff irq 11 at device 15.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xdc00-0xdc1f mem 0xe500-0xe50f ,0xe510-0xe5100fff irq 10 at device 17.0 on pci0 fxp0: Ethernet address 00:a0:c9:10:bc:94 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto wi0: Intersil Prism2.5 mem 0xe5102000-0xe5102fff irq 5 at device 18.0 on pci0 wi0: 802.11 address: 00:05:5d:ee:ec:90 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary 1.00.05, Station 1.03.04 pcm0: Creative EMU10K1 port 0xe000-0xe01f irq 9 at device 20.0 on pci0 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0 locked from /usr/src/sy s/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0 locked from /usr/src/sy s/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0 locked from /usr/src/sy s/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0:fake locked from /usr/s rc/sys/dev/sound/pcm/channel.c:677 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0 locked from /usr/src/sy s/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0:fake locked from /usr/s rc/sys/dev/sound/pcm/channel.c:677 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0 locked from /usr/src/sy s/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1307: could sleep with pcm0:fake locked from /usr/s rc/sys/dev/sound/pcm/channel.c:677
Re: libstdc++ does not contain fabsl symbol
Kris Kennaway wrote: /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. Is it? What standard defines this thing, which g++ has as a built-in? Alternately, the use could avoid adding the -fno-builtin, and the problem would go away. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Building KDE3
I recently (late last week) upgraded my machine from -stable to -current. I immediately had an issue with __sF errors from various libraries and saw that it was fixed as of this past weekend, so I cvsuped and made world yesterday morning, too. Knowing that c++ apps would start to break till they were recompiled using the new version of gcc, I set out upgrade all my ports over the weekend. Unfortunately, I've run into a snag when building kdebase3: c++ -DNDEBUG -DNO_DEBUG -O2 -O -pipe -mcpu=pentiumpro -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o kappfinder -pthread main.o scanner.o checker.o kappfinder_meta_unload.o -Wl,-export-dynamic -L/usr/X11R6/lib -L/usr/local/lib /usr/local/lib/libkdeui.so /usr/local/lib/libkdecore.so /usr/local/lib/libDCOP.so -L/usr/lib /usr/local/lib/libkdefx.so -lqt-mt -lpng -lz -lXext -lX11 -lSM -lICE -lXrender -lstdc++ -lm -ljpeg -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/X11R6/lib checker.o: In function `checkDesktopFile(QString const, QString)': checker.o(.text+0x53e): undefined reference to `cout' checker.o(.text+0x54b): undefined reference to `ostream::operator(char const*)' checker.o(.text+0x57d): undefined reference to `ostream::operator(char const*)' checker.o(.text+0x58d): undefined reference to `ostream::operator(char const*)' checker.o(.text+0x6f9): undefined reference to `cout' checker.o(.text+0x706): undefined reference to `ostream::operator(char const*)' checker.o(.text+0x70e): undefined reference to `endl(ostream)' checker.o(.text+0x7e9): undefined reference to `cout' checker.o(.text+0x7f2): undefined reference to `ostream::operator(char const*)' checker.o(.text+0x7fa): undefined reference to `endl(ostream)' gmake[3]: *** [kappfinder] Error 1 gmake[3]: Leaving directory `/usr/ports/x11/kdebase3/work/kdebase-3.0.4/kappfinder' Of course, I have reinstalled kdelibs3, XFree86, png, jpeg, and qt3. So, at this point, I'm really rather stumped as to what kdebase3 is complaining about. I did a google search looking for someone else with the problem, and I came across a post to this mailing list from back in July by Michael Hostbaek, and only saw one response from Ollivier Robert asking if Michael's version of libstdc++ is in sync. Well, mine definately should be: [ root@sorrow /usr/lib ]$ ls -l libstdc++* -r--r--r-- 1 root wheel 929880 Oct 21 13:17 libstdc++.a lrwxr-xr-x 1 root wheel 14 Oct 22 15:31 libstdc++.so - libstdc++.so.4 -r--r--r-- 1 root wheel 282096 Oct 10 13:58 libstdc++.so.3 -r--r--r-- 1 root wheel 450092 Oct 21 13:17 libstdc++.so.4 -r--r--r-- 1 root wheel 912730 Oct 21 13:17 libstdc++_p.a October 21, at 13:17 PM corresponds to when I did the make world yesterday. Any ideas? :-) Thanks. Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs broken?
On Tue, Oct 22, 2002 at 12:15:09PM -0700, Terry Lambert [EMAIL PROTECTED] wrote: #14 0xc455a66e in ?? () #15 0xc455a072 in ?? () #16 0xc4559e87 in ?? () #17 0xc45609f8 in ?? () If you are running the smbfs.ko, either load the module symbols into gdb before asking for the traceback, or statically compile SMBFS into the kernel. We need the intermediate code. Yes, sorry about that. I seem to remember similar procedures needed for debugging the vinum kld. #18 0xc035947d in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0) ...though the fact that this happened agains the vn device on an SMBFS from a file write is pretty indicative that you are running a vnconfig'ed device on top of an SMBFS file. This is probably not a good thing to do. No, I'm not doing such thing, never even tried it. It would be nice if you could give us more information as to exactly what it is you are doing, logically, to cause this problem; as things sit, it seems you are doing some evil things. No, I'm doing exactly what I describe. Usual boot to multiuser, then kill all of the processes not strictly necessary (seti, fetchmail, sendmail, you-name-it), mount the smb share -ro from NT4 server, cd /some/mountpoint and cp thisfile.xls /tmp. That's it. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: [...] And I want them to do it RSN: 5.0-R is only 9 days away. [...] 9 days??? There won't be another DP? A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
If memory serves me right, The Anarcat wrote: On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: [...] And I want them to do it RSN: 5.0-R is only 9 days away. [...] 9 days??? There won't be another DP? Um, not exactly. The current release date isn't until 20 November (subject to change, but that's the official word until RE says otherwise). That being said, the more testing we can get with sysinstall and fresh installations, the better. Urk. We really need to update some of the dates on the 5.0 release schedule. I'll push this during the RE telecon this week, if we don't get to it sooner. Bruce. PS. We're still trying to do DP2. Any other snapshots we release after DP2 are more likely to be release-candidate-style snapshots. msg45064/pgp0.pgp Description: PGP signature
Re: libstdc++ does not contain fabsl symbol
On Tue, Oct 22, 2002 at 12:40:38PM -0700, Terry Lambert wrote: Kris Kennaway wrote: /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. Is it? What standard defines this thing, which g++ has as a built-in? Alternately, the use could avoid adding the -fno-builtin, and the problem would go away. ISO C99 7.12.7.2 The fabs functions Synopsis #include math.h double fabs(double x); float fabsf(float x); long double fabsl(long double x); Description The fabs functions compute the absolute value of a floating-point number x. Returns The fabs functions return | x |. Regards, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 01:07:50PM -0700, Bruce A. Mah wrote: If memory serves me right, The Anarcat wrote: On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: And I want them to do it RSN: 5.0-R is only 9 days away. 9 days??? There won't be another DP? Um, not exactly. The current release date isn't until 20 November (subject to change, but that's the official word until RE says otherwise). That being said, the more testing we can get with sysinstall and fresh installations, the better. Urk. We really need to update some of the dates on the 5.0 release schedule. I'll push this during the RE telecon this week, if we don't get to it sooner. I've noticed many commits on cvs-all include an Approved by: re line, but I haven't seen an official code slush/freeze announcement. Is RE going to request a code freeze around 10 Nov.? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
On Tue, Oct 22, 2002 at 12:40:38PM -0700, Terry Lambert wrote: Is it? Yes, because as it stands this function is supplied by gcc as a built-in function, and the source tree will not compile without it (e.g. with a non-gcc compiler). Alternately, the use could avoid adding the -fno-builtin, and the problem would go away. -fno-builtin tells gcc to stop using its own builtin functions and use the FreeBSD version instead. We don't built with it by default, but we probably should. Kris msg45067/pgp0.pgp Description: PGP signature
Re: smbfs broken?
Vallo Kallaste wrote: It would be nice if you could give us more information as to exactly what it is you are doing, logically, to cause this problem; as things sit, it seems you are doing some evil things. No, I'm doing exactly what I describe. Usual boot to multiuser, then kill all of the processes not strictly necessary (seti, fetchmail, sendmail, you-name-it), mount the smb share -ro from NT4 server, cd /some/mountpoint and cp thisfile.xls /tmp. That's it. I don't understand, then. There should be no other way that an ffs_write call can trap to needing an SMBFS page: --- #16 0xc03c8307 in smb_read (ssp=0xc424eb00, fid=2048, uio=0xd66eb7fc, scred=0xd66eb850) at ../../../netsmb/smb_smb.c:795 #17 0xc01f2deb in smbfs_getpages (ap=0x0) at ../../../fs/smbfs/smbfs_io.c:486 #18 0xc0362fad in vnode_pager_getpages (object=0x0, m=0x0, count=0, reqpage=0) at vnode_if.h:1265 #19 0xc034ca13 in vm_fault (map=0xc4030198, vaddr=671461376, fault_type=1 '\001', fault_flags=0) at vm_pager.h:124 #20 0xc03a74b5 in trap_pfault (frame=0xd66eba94, usermode=0, eva=671461376) at ../../../i386/i386/trap.c:736 ---Type return to continue, or q return to quit--- #21 0xc03a7032 in trap (frame= {tf_fs = -697434088, tf_es = -1070268400, tf_ds = -1006436336, tf_edi = -823279616, tf_esi = 671461376, tf_ebp = -697386216, tf_isp = -697386304, tf_ebx = 16384, tf_edx = 671477760, tf_ecx = 4096, tf_eax = -697385728, tf_trapno = 12, tf_err = 0, tf_eip = -1069917698, tf_cs = 8, tf_eflags = 66054, tf_esp = -697385880, tf_ss = -697385892}) at ../../../i386/i386/trap.c:446 #22 0xc03902a8 in calltrap () at {standard input}:99 #23 0xc033af01 in ffs_write (ap=0xd66ebbe8) at ../../../ufs/ffs/ffs_vnops.c:810 #24 0xc029b74d in vn_write (fp=0xc40341a4, uio=0xd66ebc68, active_cred=0xc4251d00, flags=0, td=0xc13534e0) at vnode_if.h:417 #25 0xc0259a75 in dofilewrite (td=0xc13534e0, fp=0xc40341a4, fd=4, buf=0x2805b000, nbyte=0, offset=0, flags=0) at file.h:215 #26 0xc0259909 in write (td=0xc13534e0, uap=0xd66ebd10) at ../../../kern/sys_generic.c:329 --- You *must* be doing something that causes an SMBFS object to act as backing store for an FFS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Am I doing the wrong thing? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
If memory serves me right, Steve Kargl wrote: I've noticed many commits on cvs-all include an Approved by: re line, but I haven't seen an official code slush/freeze announcement. Feature freeze started 16 October. New feature commits (as opposed to bugfix or doc commits) should have RE approval. Is RE going to request a code freeze around 10 Nov.? Clearly we're not adhering to the last published code-freeze date; according to that, we would have been in code-freeze for two days already. The more src-oriented members of RE are probably in a better position than I am to say when code-freeze is going to start. Bruce. msg45070/pgp0.pgp Description: PGP signature
Re: libstdc++ does not contain fabsl symbol
Stefan Farfeleder wrote: [ ... fabsl() ... ] What standard defines this thing, which g++ has as a built-in? Alternately, the use could avoid adding the -fno-builtin, and the problem would go away. ISO C99 7.12.7.2 The fabs functions Synopsis #include math.h double fabs(double x); float fabsf(float x); long double fabsl(long double x); Thanks; that's exactly what I wanted to know. The answer, then, is that FreeBSD is not fully compliant with ISO C99, although there is work in progress to add compliance. I personally don't understand why the avoidance of the built-in. It's worthwhile adding the function, but rather than doing this one at a time, and finding out 10 years later that FreeBSD is finally compliant (in 2011, after the 2009 version of the standard is out ;^)), it's probably a better idea to write an external reference compliance program, so that you can compile it up, and find out all the undefined references at once, so that we can make a concerted effort. I expect this will have to be done by someone with access to the ISO C99 standard, unles it's postied online for free somewhere? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Is sysinstall still supposed to copy the contents of the mfsroot- image to /stand ? This at least results in two copies of sysinstall, one in /stand and the other one in /usr/sbin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .de writes: Is sysinstall still supposed to copy the contents of the mfsroot- image to /stand ? This at least results in two copies of sysinstall, one in /stand and the other one in /usr/sbin. That is intentional -- 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: libstdc++ does not contain fabsl symbol
On Tue, Oct 22, 2002 at 01:28:56PM -0700, Terry Lambert wrote: Stefan Farfeleder wrote: [ ... fabsl() ... ] What standard defines this thing, which g++ has as a built-in? Alternately, the use could avoid adding the -fno-builtin, and the problem would go away. ISO C99 7.12.7.2 The fabs functions #include math.h long double fabsl(long double x); The answer, then, is that FreeBSD is not fully compliant with ISO C99, although there is work in progress to add compliance. AFAIK, FreeBSD contains none of the long double math.h functions. I also suspect that many of the complex.h functions aren't implemented, yet. I personally don't understand why the avoidance of the built-in. Can you selectively turn off the memcpy, etc. built-in functions? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
On 22-Oct-2002 walt wrote: Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Am I doing the wrong thing? Try LDFLAGS=-Wl,-znocombreloc, that's what I used to get xemacs working. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: That is intentional Is it ok then that the sysinstall in /stand of the 0917-JPSNAP immediately dumps core with signal 10 when run on a 1017 -current ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .de writes: On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: That is intentional Is it ok then that the sysinstall in /stand of the 0917-JPSNAP immediately dumps core with signal 10 when run on a 1017 -current ? Current developments considered: that's probably to be expected. -- 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: 5.0-RUSH: -current install testers wanted!
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], [EMAIL PROTECTED] .de writes: Is sysinstall still supposed to copy the contents of the mfsroot- image to /stand ? This at least results in two copies of sysinstall, one in /stand and the other one in /usr/sbin. That is intentional Yes. It would be a good idea to make the sysinstall available as a binary image on the CDROM, as well, to permit it to be used for network mounted upgrades of things like lots of CDROM-less boxes in racks, too, which would make it 3 places. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
libstdc++ is supposed to provide crude replacements for missing -l functions in its libmath/stubs.c file. Apparently, missing fabsl is an omission and should be fixed in FSF sources. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- === lib/libdisk /h/des/src/lib/libdisk/chunk.c:49: warning: static declaration for `Find_Mother_Chunk' follows non-static /h/des/src/lib/libdisk/disk.c: In function `Int_Open_Disk': /h/des/src/lib/libdisk/disk.c:524: warning: passing arg 4 of `xmlparse' from incompatible pointer type /h/des/src/lib/libdisk/disk.c:813: too few arguments to function `Add_Chunk' /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include/ctype.h: At top level: /h/des/src/lib/libdisk/disk.c:430: warning: `assignToPartition' defined but not used *** Error code 1 Stop in /h/des/src/lib/libdisk. *** Error code 1 Stop in /h/des/src/lib. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 04:40:12PM -0400, Brian F. Feldman wrote: For what it's worth; I'm also using a dual-Athlon that gets spontaneous reboots once in a while and seems like it could possibly have to do with ACPI activating while the system is trying to cool itself down. Do you have any more hints here on where the problem may lie so I can attempt to track it down? Nope, sorry, just happens... Thinking a bit about it I think so far they only happened when the box was fairly idle so maybe it occures when ACPI is trying to throttle down the system. Like I wrote I disabled ACPI for now as it seems to cause the frequent locking-related panics I saw. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
* De: [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: That is intentional Is it ok then that the sysinstall in /stand of the 0917-JPSNAP immediately dumps core with signal 10 when run on a 1017 -current ? You're really supposed to run /usr/sbin/sysinstall. This breaks my finger memory, but is the new world order. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcic state
pcic doesn't work with NEWCARD. I'm working on it.. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
Kris Kennaway [EMAIL PROTECTED] writes: On Tue, Oct 22, 2002 at 11:22:41AM +0300, Ruslan Ermilov wrote: On Sat, Oct 19, 2002 at 07:54:01PM -0700, Kris Kennaway wrote: World is broken if you try and build with -fno-builtin: c++ -O -pipe -ggdb -fno-builtin -march=pentium3 -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o gen-perf.o hash-table.o iterator.o key-list.o list-node.o main.o new.o options.o read-line.o trace.o vectors.o version.o hash.o getopt.o getopt1.o gen-perf.o: In function `Gen_Perf::Gen_Perf()': /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. No one has started work on any of the C99 math functions yet. I think with the exception of the math functions we conform to C99. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sbin/gbde compilation problem
Hi, I just did a cvsup and am trying to do a buildworld and am having a problem: === === sbin/gbde cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/sbin/gbde/gbde.c cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c template.c cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/sys/geom/geom_enc.c cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/sys/crypto/rijndael/rijndael-api-fst.c /usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_makeKey': /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:67: `TRUE' undeclared (first use in this function) /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:67: (Each undeclared identifier is reported only once /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:67: for each function it appears in.) /usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_cipherInit': /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:81: `TRUE' undeclared (first use in this function) cc1: warnings being treated as errors^M /usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_padEncrypt': /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:223: warning: implicit declaration of function `panic' *** Error code 1^M === The rijndael-api-fst.c file is being compiled without -D_KERNEL. Consequently, some things like TRUE and FALSE are not being defined, and sys/systm.h, which has the prototype for panic(), is not being included. What should I do? -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UPDATING entry needed (Re: Building KDE3)
On Tue, Oct 22, 2002 at 03:46:04PM -0400, Adam K Kirchhoff wrote: I recently (late last week) upgraded my machine from -stable to -current. When you upgraded, you presumably didn't clear out stale headers from /usr/include. This needs to be added as a step in UPDATING because it will bite everyone updating from 4.x. Kris msg45088/pgp0.pgp Description: PGP signature
Re: Building -CURRENT with 4.5-RELEASE
* Ruslan Ermilov [EMAIL PROTECTED] [2002-10-22 12:23 +0300]: On Tue, Oct 22, 2002 at 04:25:23AM +0200, Gerhard Haering wrote: Is it possible, or do I need to use a more recent installation to be able to build -CURRENT? Yes, it is. It should even be possible to build -CURRENT with as early as 4.0-RELEASE. If it doesn't, please drop me a line. make installworld dumps core at installing passwd (4.5-RELEASE). I've now dl-ed and burnt the DP1 CD instead and am trying to get this to run. -- Gerhard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
On Tue, Oct 22, 2002 at 10:23:06AM -0700, Lars Eggert wrote: Bernd Walter wrote: It's just the Name that don't exist. Some time ago I was told to just open the device even if there is no node listable in /dev. E.g. mount_msdosfs /dev/da2s1 /mnt Yes, this works (Terry also pointed this out.) I wish this could be wired to the media change signal somehow. I'm seeing the phaenomen with a CF media in a pcmcia slot. There is no media change in that situation because the CF itself implements the ata commands. But then again - it should be verified with a recent -current. This is a pre GEOM scenario, so it might have been fixed. Also the panic is a pre GEOM panic - at least for me. I wouldn't give it much time to debug before rechecking with a recent kernel. I can't update my machine right now, but if Lars could update his system and recheck the situation... Just checkeded, and it does NOT crash anymore on bootup when no media is inserted (with yesterday's -current.) Nice to hear. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Building -CURRENT with 4.5-RELEASE
On Tue, Oct 22, 2002 at 11:52:11PM +0200, Gerhard Häring wrote: * Ruslan Ermilov [EMAIL PROTECTED] [2002-10-22 12:23 +0300]: On Tue, Oct 22, 2002 at 04:25:23AM +0200, Gerhard Haering wrote: Is it possible, or do I need to use a more recent installation to be able to build -CURRENT? Yes, it is. It should even be possible to build -CURRENT with as early as 4.0-RELEASE. If it doesn't, please drop me a line. make installworld dumps core at installing passwd (4.5-RELEASE). Are you running a current kernel at this point? If you aren't it's safe to say it won't work. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45091/pgp0.pgp Description: PGP signature
Re: UPDATING entry needed (Re: Building KDE3)
On Tue, 22 Oct 2002, Kris Kennaway wrote: On Tue, Oct 22, 2002 at 03:46:04PM -0400, Adam K Kirchhoff wrote: I recently (late last week) upgraded my machine from -stable to -current. When you upgraded, you presumably didn't clear out stale headers from /usr/include. This needs to be added as a step in UPDATING because it will bite everyone updating from 4.x. Kris It's already in UPDATING with the rm -rf /usr/include/g++ line in the steps for going from 4 to -current. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
file system deadlock in -CURRENT
Hi, I found an interesting problem during tracing my perl-5.8 problem I mailed some days ago. Sometimes - I cannot forcibly reproduce this event - while I'm trying to truss a process, I first get the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: cannot open /proc/44502/mem: No such file or directory or the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: PIOCWAIT: Input/output error And then I cannot enter this directory any more. Every process trying to access /usr/ports/lang/perl5.8/work/5.8.0 hangs in an uninterruptible sleep: /# cd /usr/ports/lang/perl5.8 /usr/ports/lang/perl5.8# ls CVS/ distinfo pkg-comment pkg-install* pkg-plistwork/ Makefile files/ pkg-descrpkg-message test.log /usr/ports/lang/perl5.8# cd work /usr/ports/lang/perl5.8/work# ls BSDPAN-5.8.0/ perl-5.8.0/ use.perl /usr/ports/lang/perl5.8/work# cd perl-5.8.0 /usr/ports/lang/perl5.8/work/perl-5.8.0# ls [at this point the shell (or any other process) hangs. I can otherwise use the machine as usual but cannot access this directory] Only solution to revive the directory again is a reboot. I have recompiled the kernel with options WITNESS options MUTEX_DEBUG One lock order reversal was logged by the kernel 3 hours earlier: lock order reversal 1st 0xc05a1fe0 spechash (spechash) @ ../../../kern/vfs_subr.c:2748 2nd 0xc17866f0 vnode interlock (vnode interlock) @ ../../../kern/vfs_subr.c:2751 (possibly unrelated) The last time I had this problem I also had a kernel panic (but no crash dump or console output during the crash - possibly also unrelated. I still have reliability problems during heave file system activity). I'm trying to reproduce this error again, then hopefully with a crash dump. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: file system deadlock in -CURRENT
Daniel Rock schrieb: Hi, I found an interesting problem during tracing my perl-5.8 problem I mailed some days ago. Sometimes - I cannot forcibly reproduce this event - while I'm trying to truss a process, I first get the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: cannot open /proc/44502/mem: No such file or directory or the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: PIOCWAIT: Input/output error A side note: The problem seems to be related with programs compiled with profiling enabled. trussing a normal program never showed this behaviour. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
Mike Barcroft wrote: This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. No one has started work on any of the C99 math functions yet. I think with the exception of the math functions we conform to C99. I have written compile time compliance validation tests for: 7.12 Mathematics (macros and constants) 7.12.3 Classification macros 7.12.4 Trigonometric functions 7.12.5 Hyperbolic functions 7.12.6 Exponential and logarithmic functions They test that things that are supposed to be defined are defined, and they enforce type checking for defintions that are in scope at the time the code is compiled (assuming you make the compiler gripe). In case someone wants to work on this, I can send you a tar-ball. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
John Baldwin wrote: On 22-Oct-2002 walt wrote: Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Try LDFLAGS=-Wl,-znocombreloc, that's what I used to get xemacs working. Yes, that worked, thanks. I found I had to edit the generated Makefile in /usr/ports/editors/emacs20/work/emacs-20.7 because 'configure' complained about the LDFLAGS, otherwise. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DRM
I'm running a 5.0-CURRENT from earlier this morning and receive this notice: /usr/src/sys/kern/kern_sysctl.c:1000: could sleep with drm memory locked from @/dev/drm/drm_memory.h:217 I have 'device agp' in my kernel and I've got mga.ko loaded. The notice is raised when doing 'sysctl -a'. If I can provide any more information, let me know. -- Sean M. Kelly [EMAIL PROTECTED] Asst. Unix Systems and Network Admin. Creighton University Computer Center To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Building -CURRENT with 4.5-RELEASE
On Wed, Oct 23, 2002 at 01:48:14AM +0200, Gerhard Häring wrote: * Brooks Davis [EMAIL PROTECTED] [2002-10-22 15:01 -0700]: Are you running a current kernel at this point? If you aren't it's safe to say it won't work. No, this is 4.5-RELEASE, as I said. By current kernel, do you mean an up-to-date FreeBSD 4, like 4.7-STABLE, or a -CURRENT kernel? I mean a -CURRENT kernel like /usr/src/UPDATING tells you to use. UPDATING is the authoritative document on this subject. When I came to FreeBSD, ppl told me that you don't update the kernel separately, so I'm not sure what you mean. You don't want to randomly update the kernel without updating userland because some program like ipfw will stop working sometimes. On the flip side, if you don't update the kernel before install world, the old kernel may not support syscalls required by the new binaries. In the past this has included things like /bin/sh so it is necessicary to install a new kernel before installing a new world unless you want to get your self into a real mess. Additionaly, it's very easy to switch back to an old kernel. Switching back to an older world requires backups. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45098/pgp0.pgp Description: PGP signature
formatting bootable media
Hi, the following produces a bootable CF card under 4.7: dd if=/dev/zero of=/dev/da2 bs=512 count=32 fdisk -BI da2 disklabel -w -B da2s1 auto disklabel -r da2s1 /tmp/da2s1 disklabel -r da2s1 | grep ' c:' | sed 's/c:/a:/' /tmp/da2s1 disklabel -R -B da2s1 /tmp/da2s1 newfs /dev/da2s1a When executed under -current, I end up in the loader when booting from the media, and I can't seem to get it to see the file system: Console: internal video/keyboard BIOS drive C: is disk0 BIOS 639kB/64512kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Thu Sep 19 12:19:30 PDT 2002) \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... can't load 'kernel' can't load 'kernel.old' Type '?' for a list of commands, 'help' for more detailed help. ok ls open '/' failed: no such file or directory ok lsdev cd @ 0x11ee0 disk @ 0x10ca0 disk0: BIOS drive C: disk0s1a: FFS pxe @ 0xeef0 If I access the -current-created media under 4.7, I see these messages: da2: rejecting BSD label: raw partition offset != slice offset da2: start 1, end 2104704, size 2104704 da2c: start 0, end 2104703, size 2104704 da2s1: rejecting BSD label: raw partition offset != slice offset da2s1: start 1, end 2104704, size 2104704 da2s1c: start 0, end 2104703, size 2104704 Any ideas? Might this be geom-related? Or a pilot error on my part? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Building -CURRENT with 4.5-RELEASE
* Brooks Davis [EMAIL PROTECTED] [2002-10-22 15:01 -0700]: On Tue, Oct 22, 2002 at 11:52:11PM +0200, Gerhard Häring wrote: * Ruslan Ermilov [EMAIL PROTECTED] [2002-10-22 12:23 +0300]: On Tue, Oct 22, 2002 at 04:25:23AM +0200, Gerhard Haering wrote: Is it possible, or do I need to use a more recent installation to be able to build -CURRENT? Yes, it is. It should even be possible to build -CURRENT with as early as 4.0-RELEASE. If it doesn't, please drop me a line. make installworld dumps core at installing passwd (4.5-RELEASE). Are you running a current kernel at this point? If you aren't it's safe to say it won't work. No, this is 4.5-RELEASE, as I said. By current kernel, do you mean an up-to-date FreeBSD 4, like 4.7-STABLE, or a -CURRENT kernel? When I came to FreeBSD, ppl told me that you don't update the kernel separately, so I'm not sure what you mean. Confused, Gerhard PS: Using DP1 to compile -CURRENT CVS also doesn't work :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sbin/gbde compilation problem
On Tue, Oct 22, 2002 at 05:45:24PM -0400, Craig Rodrigues wrote: Hi, I just did a cvsup and am trying to do a buildworld and am having a problem: === === sbin/gbde /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:67: `TRUE' undeclared (first use in this function) /usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_cipherInit': /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:81: `TRUE' undeclared (first use in this function) cc1: warnings being treated as errors^M /usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_padEncrypt': /usr/src/sys/crypto/rijndael/rijndael-api-fst.c:223: warning: implicit declaration of function `panic' *** Error code 1^M === This patch worked for me. Is it acceptable for commit? -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] --- sys/crypto/rijndael/rijndael-api-fst.c.orig Tue Oct 22 20:16:28 2002 +++ sys/crypto/rijndael/rijndael-api-fst.c Tue Oct 22 20:29:20 2002 @@ -22,6 +22,7 @@ #include sys/systm.h #else #include string.h +#include err.h #endif #include crypto/rijndael/rijndael-alg-fst.h #include crypto/rijndael/rijndael-api-fst.h @@ -64,7 +65,11 @@ rijndaelKeyEncToDec(key-keySched, key-ROUNDS); } +#ifdef _KERNEL return TRUE; +#else + return 1; +#endif } int rijndael_cipherInit(cipherInstance *cipher, BYTE mode, char *IV) { @@ -78,7 +83,11 @@ } else { bzero(cipher-IV, MAX_IV_SIZE); } +#ifdef _KERNEL return TRUE; +#else + return 1; +#endif } int rijndael_blockEncrypt(cipherInstance *cipher, keyInstance *key, @@ -219,8 +228,14 @@ outBuffer += 16; } padLen = 16 - (inputOctets - 16*numBlocks); - if (padLen 0 padLen = 16) + if (padLen 0 padLen = 16) { +#ifdef _KERNEL panic(rijndael_padEncrypt(ECB)); +#else + errx(1, rijndael_padEncrypt(ECB)); + +#endif + } bcopy(input, block, 16 - padLen); for (cp = block + 16 - padLen; cp block + 16; cp++) *cp = padLen; @@ -240,8 +255,15 @@ outBuffer += 16; } padLen = 16 - (inputOctets - 16*numBlocks); - if (padLen 0 padLen = 16) + if (padLen 0 padLen = 16) { +#ifdef _KERNEL panic(rijndael_padEncrypt(CBC)); +#else + errx(1, rijndael_padEncrypt(CBC)); + +#endif + } + for (i = 0; i 16 - padLen; i++) { block[i] = input[i] ^ iv[i]; }
Re: formatting bootable media
Lars Eggert wrote: Hi, the following produces a bootable CF card under 4.7: dd if=/dev/zero of=/dev/da2 bs=512 count=32 fdisk -BI da2 disklabel -w -B da2s1 auto disklabel -r da2s1 /tmp/da2s1 Turns out that the disklabel -r output after this step differs between -current and 4.7: #size offsetfstype [fsize bsize bps/cpg] -stable: c: 21032640unused0 0 -current: c: 21047040unused0 0 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature