Re: current hangs...
In message [EMAIL PROTECTED], John Baldwin writes: On 20-Jan-01 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Baldwin writes: On 20-Jan-01 The Hermit Hacker wrote: On Sat, 20 Jan 2001, Mark Murray wrote: on a 2xPII/350, 256M, two scsi disks on ahc, and ccd I have three times now hung the machine so that only reset got any attention simply by make -j 128 world Do you have an easy way to narrow it down to CCD by doing the same thing but without ccd involvement? I don't have CCD, and got home last night from the office and mine was hung also, on a kernel from the day before ... being in X, pretty much nothing I could do to try and debug it ... new laptop gets in this week, so will be setting up the whole serial console debugging env ... Is it SMP, and does it have multiple SCSI disks hanging off of the same device? SMP, one scsi disk on each controller, /usr and /home ccd'ed. Is there any code dealing with disk I/O in the kernel that does the equivalent of this: while (!io_done) /* spin */ ; That assumes an interrupt will set io_done? Using DELAY() in places might explain this. Not that I know of. -- 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
VN bug or pilot error ?
Hello, I've got a recent current (cvsuped and rebuilt yesterday) on a laptop and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel and I've also tried to kldload vn.ko, but I get consistently "vn0c : device not configured" when I try to use it to mount a locally stored iso image. I've switched to Stable and I can mount the exact same image. TfH PS : it seems it's possible to vn-mount a file located on an NFS server, when the man page says it is not possible (which is right ?) -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 4.0.2
On Sun, Jan 21, 2001 at 01:51:05AM -0600, David Syphers wrote: the binaries from a directory labeled "FreeBSD 5.x". So I tried the ports, and it built fine for a long time, and then after about 35300 lines of output to the screen, ran into make: don't know how to make ../../../fonts/encodings/encodings.dir. Stop *** Error code 2 Stop in /usr/ports/x11/XFree86-4/work/xc/fonts/bdf. The port should be working, but since it's not for you, just add the package. pkg_add -r XFree86 Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] PGP signature
Re: HEADS UP: Strange booting lockups
On Sun, Jan 21, 2001 at 02:32:38AM -0800, Jason Evans wrote: Several of us have started experiencing problems with kernels that won't boot. The symptom is hard to miss: the machine locks up at the spinner just before printing the copyright message at the beginning of the boot sequence. Hmm. I've recently tried to boot a kernel off of a CDRW, and it got through the loader, printed the copyright and blinked the keyboard leds, and froze. The lsdev command causes the loader to panic when booted from the CD. Could this possibly be related? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/24444: syslogd(8) does not update hostname
the hostname, one being a syscall and the other being a sysctl. One could of course have the kernel print a message to the console about it, syslogd(8) would pick that up. Yes, I was about to propose this, but then I thought: why? If we go this way, then we should definitely also log an IP address change, maybe even our default router change MAC address... why not even hardware changes since last reboot? Working in a security job, I can understand worries about important events going unnoticed. But doing this in kernel is IMHO overkill, maybe it could be interesting for TrustetBSD, but not in the normal kernel; at least, it should be configurable at both compile time and runtime (high securelevel and/or a sysctl). The Right Way (tm) to do this is to use (or write) an host intrusion detection system. Having said this, the proposed patch looks fine to me and I think it should be committed. Bye, Andrea -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixed (was Re: HEADS UP: Strange booting lockups)
On Sun, Jan 21, 2001 at 02:32:38AM -0800, Jason Evans wrote: We don't know why this is happening, and at this point the primary suspicion is that this problem has been lurking for quite some time, and we've recently committed a combination of changes that causes the problem to exhibit itself more consistently. Jake Burkholder, Peter Wemm, and I all checked in changes that were independently tested and confirmed to work, yet the combination of the changes seems to be bad, even though none of them appear to touch code that is executed so early during boot. It was my fault. I tested my changes, and during review, one of the review comments was a request to change the order of fields in struct mtx. I didn't change the order in a static initializer though. Yay for last minute changes without repeated testing. Thanks go to Jake for finding the problem. In my tired and frantic state, I was about to resort to backing the whole thing out. =) There is a report (that just came to my attention) of this problem existing for one person at least two weeks ago, so it isn't clear yet what conditions cause the problem to manifest itself. I'm not sure what caused the problem as mentioned in the above paragraph, but Donald Maddox may have the explanation for it in another email in this thread. Wearing the pointy hat, Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make buildworld failed...
Hello! After cvsuped, i try to build world under FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 === usr.bin/kdump cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/u sr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/u sr/include -c ioctl.c In file included from ioctl.c:99: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous definition In file included from ioctl.c:51: /usr/obj/usr/src/i386/usr/include/machine/i4b_rbch_ioctl.h:45: `TELNO_MAX' undeclared here (not in a function) ioctl.c: In function `ioctlname': ioctl.c:693: invalid use of `restrict' ioctl.c:693: sizeof applied to an incomplete type *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Rgdz,/"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WITNESS may cause failed boot, patch available
Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha. The bug also exists on x86, but does not necessarily cause any problems. If you run into problems (probably during boot), there is a patch available that should fix the WITNESS problem: http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cc1 gets segmentation faults
Huh, I removed '-O' switch from ${CFLAGS} and managed to rebuild
and reinstall gcc. This new (in fact the same) gcc now works fine both
with '-O' and without it. Looks like a pilot error. Strange, anyway.
Sorry to bother you all.
On Sun, Jan 21, 2001 at 02:50:48PM +0300, Alex Kapranoff wrote:
I have -CURRENT on a UP P166 box.
I've just managed to build a new kernel and world (cvsuped yesterday)
and installed them both. Now I get:
cc: Internal compiler error: program cc1 got fatal signal 11
*** Error code 1
Stop in /usr/home/alex/work/own.
whenever I want to compile something not so trivial as `hello world'.
So, am I stuck in this situation? I cannot build neither kernel nor
gcc now. Are there any ways out? Unfortunately, I don't backup system
binaries, libs or headers.
How can I debug this? BTW, other big programs such as INN, apache +
mod_php4 work like a charm.
--
Alex Kapranoff, Voice: +7(0832)791845
We've lived 2 weeks in the brand new millenium...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sys/time.h w/ timespec stuff
On Sun, 21 Jan 2001, Will Andrews wrote: The timespec* stuff is hidden behind the _KERNEL aura on FreeBSD, but not on OpenBSD. This is manifested in OpenBSD's make source, which uses timespec for a few things. So now, maybe someone can answer my question: why is timespec _KERNEL? The timespec macros are unportable and are specialized for the kernel, so they shouldn't be turned into application interfaces. Similarly for the timeval macros, except they shouldn't have been turned into application interfaces (we have them for compatibility with NetBSD/ OpenBSD). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld in -current failed...
Hello. After resup few hours ago, i try to buildworld on FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 gzip -cn /usr/src/lib/libc/../libc/regex/re_format.7 re_format.7.gz make in free(): error: junk pointer, too high to make sense. Abort trap - core dumped *** Error code 134 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any idea? -- Rgdz,/"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WITNESS may cause failed boot, patch available
Jason Evans wrote: Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha. The bug also exists on x86, but does not necessarily cause any problems. If you run into problems (probably during boot), there is a patch available that should fix the WITNESS problem: http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff This looks like a variation of Peter's mutex.diff which moves a bunch of macros to kern/kern_mutex.c from sys/mutex.h - so is it final now that we will move them there? Jason -Bosko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
loopback nfs hangs now propagated to -stable...
The loopback nfs hangs that have been with us for a month have now propagated to -stable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
strong recommendation re: NFS
Guys, I've noticed that some of you have been making noises about cleaning up the NFS macros in current. I strongly recommend that you not do this, at least not unless you want to take on a man month (or two!) worth of work debugging! In fact, I would recommend that the NFS subsystem be left alone as much as possible until -current is far more stable then it is. NFS issues tend to be subtle, and unless you've been staring at the code for a year you are likely to introduce more bugs then you fix. There's a reason why I (Mr 'rewrite everything' Dillon) haven't touched them. Concentrate on making the general network stack (aka TCP) and filesystems SMP aware. Leave NFS alone for now. Please. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 4.0.2
Kris Kennaway wrote: On Sun, Jan 21, 2001 at 01:51:05AM -0600, David Syphers wrote: the binaries from a directory labeled "FreeBSD 5.x". So I tried the ports, and it built fine for a long time, and then after about 35300 lines of output to the screen, ran into make: don't know how to make ../../../fonts/encodings/encodings.dir. Stop *** Error code 2 Stop in /usr/ports/x11/XFree86-4/work/xc/fonts/bdf. The port should be working, but since it's not for you, just add the package. pkg_add -r XFree86 If you are currently running 4.0.1, I would seriously recommend skipping this minor revision. I have run into a multitude of problems with it, and am now back right where I started. One, is the lack of DRM support for the matrox cards anymore. The kernel module has a version number in it, which is less than that required by the DRM system. It won't insert the module until you update this--so it appears that no one is actually using it. Another, is that there seem to be delays in the event stream, making interactive performance terrible. One example: When I go to move a window, I start dragging it, moving the outline as I go. Then I unclick, yet the frame is still visible. I actually have to move the mouse more to get the window move to take effect. There are other cases, where it appears to lose events all together--like clicking on windows to raise them, or with menus. There were also a handful of other things, that I don't recall offhand now. These problems were observed on a 4.2-STABLE box, not too long ago. I have compiled the source from scratch (with and without matrox DRM stuff), as well as using the stock 4.0.2_5 package, both of which behave the same. Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loopback nfs hangs now propagated to -stable...
: :The loopback nfs hangs that have been with us for a month have now propagated :to -stable. Can you break into DDB and get a 'ps' and a kernel core? There are a bunch of things it could be, including possibly my low-memory deadlock code (which concentrated more on UFS and not so much on NFS), though my low-memory deadlock code was committed all the way back in december (12/29). The only recent commit was to fix an O_EXCL bug, and I doubt that could cause a loopback deadlock. The cause could also be related to MFC's (not by me) related to the network stack, which are more recent. There isn't much in the cvs logs that I can see as having caused the problem to occur only recently. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Strange booting lockups
In message [EMAIL PROTECTED] Jason Evans writes: : Several of us have started experiencing problems with kernels that won't : boot. The symptom is hard to miss: the machine locks up at the spinner : just before printing the copyright message at the beginning of the boot : sequence. I've seen this on laptops that don't clear their RAM for a long time. I suspect that it is something different, however. My bug is that the kernel goes looking for dmesg buffer, finds a bogus pointer and walks off the edge of the world. Bang, you are dead. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WITNESS may cause failed boot, patch available
On Sun, Jan 21, 2001 at 01:06:15PM -0500, Bosko Milekic wrote: http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff This looks like a variation of Peter's mutex.diff which moves a bunch of macros to kern/kern_mutex.c from sys/mutex.h - so is it final now that we will move them there? It was one of the things I expected to happen as part of the mutex API and inlining cleanup, but it was necessary to either move a bunch of mutex implementation details out of mutex.h, or to expose even more implementation details in order to fix the WITNESS breakage, so I did the former. By the way, Peter helped me clean this patch up, so there isn't a conflict of interest between the two patches. I just wish this could have waited until your mutex cleanups were ready. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvsup'ing repo cvs-checkout'ing sources makes cvs complain...
/* apologies if this is not the most appropriate list; [additional] * apologies for the long post; suggestions and pointers gladly * accepted. */ Dear FreeBSD'ers, Over the past few days, I have been cvsup'ing FreeBSD's repository and cvs-checkout'ing out my -CURRENT sources; for the record, I had been cvsup'ing my sources and making the buildkernel etc. dance flawlessly on this very test system. It seems a logical approach to switch from cvsup'ing each system separately to cvsup'ing the repo cvs-checkout'ing the desired modules (src, ports, doc, www) for each of my systems. However, I have had a few (probably minor) problems on my -CURRENT test system, where I am playing the new "cvsup repo"/"cvs-checkout modules" dance. My (stripped) cvs-supfile: blockquote # $FreeBSD: src/share/examples/cvsup/cvs-supfile,v 1.26.2.3 2000/09/22 06:31:21 asami Exp $ # *default host=cvsup.nl.FreeBSD.org *default base=/myjunk *default prefix=/myjunk/home/ncvs *default release=cvs *default delete use-rel-suffix *default compress src-all ports-all doc-all www /blockquote The background (also posted to -questions) -- Following Warner's directions in internat.txt, I removed the crypto-related stuff, and issued the following explicit command: 201 1:54am /usr # cvs -d /myjunk/home/ncvs checkout -r HEAD src # Script started on Wed Jan 17 01:54:54 2001 You have mail. 201 1:54am /usr # cvs -d /myjunk/home/ncvs checkout -r HEAD src cvs checkout: Updating src RCS file: /myjunk/home/ncvs/src/Makefile,v retrieving revision 1.234 retrieving revision 1.242 Merging differences between 1.234 and 1.242 into Makefile src/Makefile already contains the differences between 1.234 and 1.242 RCS file: /myjunk/home/ncvs/src/Makefile.inc1,v retrieving revision 1.141.2.2 retrieving revision 1.180 Merging differences between 1.141.2.2 and 1.180 into Makefile.inc1 src/Makefile.inc1 already contains the differences between 1.141.2.2 and 1.180 RCS file: /myjunk/home/ncvs/src/README,v retrieving revision 1.15 retrieving revision 1.19 Merging differences between 1.15 and 1.19 into README src/README already contains the differences between 1.15 and 1.19 RCS file: /myjunk/home/ncvs/src/UPDATING,v retrieving revision 1.73.2.3 retrieving revision 1.134 Merging differences between 1.73.2.3 and 1.134 into UPDATING src/UPDATING already contains the differences between 1.73.2.3 and 1.134 /* How come...? */ ? src/contrib ? src/gnu ? src/etc ? src/games ? src/include ? src/lib ? src/libexec ? src/release ? src/bin ? src/sbin ? src/share ? src/sys ? src/usr.bin ? src/usr.sbin ? src/tools ? src/kerberosIV ? src/kerberos5 ? src/makeworld_logfiles /* ? cvs doesn't like all directories, except the removed (crypto) ones, which are correctly updated. */ cvs checkout: Updating src/crypto U src/crypto/README cvs checkout: Updating src/crypto/heimdal U src/crypto/heimdal/ChangeLog snip /* cvs correctly updates the files in the src/crypto directories: heimdal, kerberos, openssh, etc. */ cvs checkout: Updating src/secure U src/secure/Makefile snip /* cvs correctly updates the files in the src/crypto directories: heimdal, kerberos, openssh, etc.; nothing else is updated */ 202 1:59am /usr # exit exit Script done on Wed Jan 17 02:00:13 2001 Needless to say, I rm -rf'ed the directories marked by "?", and repeated the whole checkout operation. Apart from a few ? in front of some files of mine in the source tree, everything was fine. I am now happily running a -CURRENT built from those very sources. What am I missing in the above cvs steps ? Why were my source directories marked as "?" and not updated ? Is it really necessary to rm -rf those subtrees? Mutatis mutandis, the same occurred in my ports tree (in the same -CURRENT system): Script started on Thu Jan 18 00:28:26 2001 You have mail. 201 12:28am /usr # cvs -d /myjunk/home/ncvs checkout ports cvs checkout: Updating ports U ports/.cvsignore cvs checkout: move away ports/INDEX; it is in the way C ports/INDEX cvs checkout: move away ports/LEGAL; it is in the way C ports/LEGAL U ports/Makefile U ports/README ? ports/README.html ? ports/Mk ? ports/Templates ? ports/Tools ? ports/archivers ? ports/astro ? ports/audio ? ports/benchmarks ? ports/biology ? ports/cad ? ports/chinese ? ports/comms ? ports/converters ? ports/databases ? ports/deskutils ? ports/devel ? ports/editors ? ports/emulators ? ports/ftp ? ports/games other directories snipped Again, removing the "?" directories (except distfiles) and cvs checkout'ing once more gave me a working ports tree. I haven't tried other modules (yet). I would first like to understand what happened. -- brand-new problems - As I said above, I removed the "?" directories, cvs-checkout'ed my sources, and successfully updated my -CURRENT (test) system. But on the next src checkout, the following warnings were given: Script started on Fri Jan 19
Re: VN bug or pilot error ?
On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot [EMAIL PROTECTED] wrote: I've got a recent current (cvsuped and rebuilt yesterday) on a laptop and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel and I've also tried to kldload vn.ko, but I get consistently "vn0c : device not configured" when I try to use it to mount a locally stored iso image. Change "vn0c" to "vn0". I believe this is the result of PHK's change in mid-December which added cloning to vn. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup'ing repo cvs-checkout'ing sources makes cvs complain...
Dear Salvo, Maybe I do not know your problem exactly but I am trying to find out... I think that what you saw at first try was related to the fact that the source tree you tried to upgrade did not have CVS directories in each directory. These directories are needed for proper CVS operation. If you cd to any dir that you have rm -f-ed and checked out again, you will find a CVS subdir in each. If you like you can look at what is in those dirs, in short CVS keeps book about what files have been co-d from the repo, at what time etc so that it knows what files to update and leaves the rest alone. Also, it uses this info to decide which files have changed when you want to commit. So if you want to place a directory under CVS control, you must first rm -rf it and then check it out again. As for your second question: CVS does not normally delete files that you no longer need but only displays warnings about them. You can remove those files now. Cvsup in contrast also removes the files if you tell it so. A useful option to use when doing CVS updates is -P it will delete empty directories in the tree. But even that will not delete files. Also you can try to use -d which will create directories upon checkout if needed. Also, if you want the HEAD branch, you can just say: -A and it will do instead of -r HEAD. Good luck and I hope this was of some help. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup'ing repo cvs-checkout'ing sources makes cvs complain...
Original Message On 1/21/01, 11:28:46 PM, Szilveszter Adam [EMAIL PROTECTED] wrote regarding Re: cvsup'ing repo cvs-checkout'ing sources makes cvs complain...: Dear Salvo, So if you want to place a directory under CVS control, you must first rm -rf it and then check it out again. Thanks a lot again. And still more apologies for the newbieish questions. Evidently, I was not correct in implicitly assuming that cvs would recognize/adopt a previously cvsup'ed tree. As for your second question: CVS does not normally delete files that you no longer need but only displays warnings about them. You can remove those files now. Cvsup in contrast also removes the files if you tell it so. Ok, since I logged those warnings, I'll just write a two-liner awk/perl script for that :-) Best regards, Salvo (I'll get out and grep someone... :-)) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Strange booting lockups
On Sun, Jan 21, 2001 at 06:05:20AM -0500, Donald J . Maddox wrote: It may have absolutely nothing to do with either of these cases, but I found out the hard way recently that booting with no device.hints in /boot will exhibit symptoms that appear identical to this. Is it possible that something is trashing the device list, or not initializing it properly at kernel load time? This is a different problem. If you don't have device hints available at boot (statically compiled into the kernel or loaded from /boot) then the console driver doesn't get its hints, and doesn't work in the manner you describe. Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] PGP signature
lastest kernel from cvs ( sh exists with signal 8 )
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single user
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Strange booting lockups
On Sun, Jan 21, 2001 at 03:29:22PM -0800, Kris Kennaway wrote: On Sun, Jan 21, 2001 at 06:05:20AM -0500, Donald J . Maddox wrote: It may have absolutely nothing to do with either of these cases, but I found out the hard way recently that booting with no device.hints in /boot will exhibit symptoms that appear identical to this. Is it possible that something is trashing the device list, or not initializing it properly at kernel load time? This is a different problem. If you don't have device hints available at boot (statically compiled into the kernel or loaded from /boot) then the console driver doesn't get its hints, and doesn't work in the manner you describe. Yeah, I know what my problem was... I was just suggesting that if something trashed the area of memory where these hints live at boot time, it could possibly cause the problem being described. That wasn't the problem, but hey, I was trying to help :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
The Hermit Hacker wrote: just tried to reboot with a latest build (from this afternoon), and upon reboot, it gives: pid 6 (sh), uid 0: exited with signal 8 when /etc/rc tries to run, and, of course, won't let me get to single user mode for same reason ... checked /usr/src/UPDATING, and nothing in there seems to apply ... We were discussing this and a couple of other related strange things that turned up. I might have broken the npx code with my last config(8) change and the corresponding #ifdefs. I have not gone back over it all again but will shortly. Given that two people have this sort of problem now, things are pointing to the npx commits somehow. You did rebuild config, right? Can you please check the opt_npx.h file in your build directory and make sure it has "#define DEV_NPX 1" in it? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
d'oh, did it backwards again ... buildkernel then buildworld ... let me go
back and rebuild kernel and see if that is all it was in my case ...
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single user
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
We were discussing this and a couple of other related strange things
that turned up. I might have broken the npx code with my last config(8)
change and the corresponding #ifdefs. I have not gone back over it all
again but will shortly. Given that two people have this sort of problem
now, things are pointing to the npx commits somehow. You did rebuild config,
right?
Can you please check the opt_npx.h file in your build directory and make sure
it has "#define DEV_NPX 1" in it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Cannot build emulators/vmware2
After installworld'ing today, I cannot compile emulators/vmware2. Does someone see this result? - cc -O -mpentiumpro -pipe -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/include -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/common -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/export/include -I/sys -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/ -DCDEV_MAJOR_=200 -DSMP -DAPIC_IO -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/include -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/common -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/expor! t/include -I/sys -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/ -I. -I@ -I@/dev -I@/../include -mpreferred-stack-boundary=2 -c /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c In file included from /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:66: /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.h:25: field `rsel' has incomplete type /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c: In function `FreeBSD_Driver_Poll': /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:495: warning: implicit declaration of function `selrecord' /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c: In function `FreeBSD_DriverSelectTimeout': /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:519: warning: implicit declaration of function `selwakeup' *** Error code 1 Stop in /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib. *** Error code 1 Stop in /home/ports/emulators/vmware2. *** Error code 1 Stop in /home/ports/emulators/vmware2. *** Error code 1 Stop in /home/ports/emulators/vmware2. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VN bug or pilot error ?
thanks a lot : that was it ! Peter Jeremy wrote: On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot [EMAIL PROTECTED] wrote: I've got a recent current (cvsuped and rebuilt yesterday) on a laptop and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel and I've also tried to kldload vn.ko, but I get consistently "vn0c : device not configured" when I try to use it to mount a locally stored iso image. Change "vn0c" to "vn0". I believe this is the result of PHK's change in mid-December which added cloning to vn. Peter -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VN bug or pilot error ?
But while you're at it, migrate to md(4) instead of vn(4), it does vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices Poul-Henning In message [EMAIL PROTECTED], Thierry Herbelot writes: thanks a lot : that was it ! Peter Jeremy wrote: On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot [EMAIL PROTECTED] wrote: I've got a recent current (cvsuped and rebuilt yesterday) on a laptop and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel and I've also tried to kldload vn.ko, but I get consistently "vn0c : device not configured" when I try to use it to mount a locally stored iso image. Change "vn0c" to "vn0". I believe this is the result of PHK's change in mid-December which added cloning to vn. Peter -- Thierry Herbelot 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: Cannot build emulators/vmware2
On 22-Jan-01 Jun Kuriyama wrote: After installworld'ing today, I cannot compile emulators/vmware2. Does someone see this result? Fix it to #include sys/selinfo.h instead of sys/select.h sys/select.h was just recently gutted and/or axed (can't remember which). If selinfo doesn't work on stable, just do a #ifdef __FreeBSD_version 4 use selinfo, else use select.h. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: lastest kernel from cvs ( sh exists with signal 8 )
The Hermit Hacker wrote:
d'oh, did it backwards again ... buildkernel then buildworld ... let me go
back and rebuild kernel and see if that is all it was in my case ...
Argh! I wish people would stop using buildkernel! :-( It calls config(8)
in such a way that buries the warning messages where people dont see.
config(8) is meant to be used interactively :-(
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single use
r
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
We were discussing this and a couple of other related strange things
that turned up. I might have broken the npx code with my last config(8)
change and the corresponding #ifdefs. I have not gone back over it all
again but will shortly. Given that two people have this sort of problem
now, things are pointing to the npx commits somehow. You did rebuild confi
g,
right?
Can you please check the opt_npx.h file in your build directory and make su
re
it has "#define DEV_NPX 1" in it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrapp
y
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.or
g
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
-On [20010122 07:55], Peter Wemm ([EMAIL PROTECTED]) wrote: The Hermit Hacker wrote: d'oh, did it backwards again ... buildkernel then buildworld ... let me go back and rebuild kernel and see if that is all it was in my case ... Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Yeah well, buildkernel was advocated as the next best thing to sliced bread. Myself, I'll stick to the ``old way''. Never failed me thus far. At least, nothing a good rm -rf compile/KERNEL cannot solve. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup'ing repo cvs-checkout'ing sources makes cvs complain...
-On [20010121 23:10], Salvo Bartolotta ([EMAIL PROTECTED]) wrote: Following Warner's directions in internat.txt, I removed the crypto-related stuff, and issued the following explicit command: One question: why? crypto is now folded into src-all -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lots of page faults
-On [20010120 08:40], Alex Kapranoff ([EMAIL PROTECTED]) wrote: Additional symptoms include very high system CPU state percentage and a lot of page faults. A page fault is not a bad thing, it is merely an indicator from the CPU to the kernel that the page you want to refer to, the next page of executable data of the application you are running, is not in memory [yet]. The CPU causes a page fault and the kernel pages in the part(s) of the application to memory and then resumes operation, now being able to refer to the appropriate page. [snip] Is my RAM rotting or what? Given you get coredumps on cc, as and such, it could be. But not always, I have had current give me coredumps in cc and as before but that was due to problems in the binaries themselves after some changes in the world. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 Donald J . Maddox wrote: On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I just do it the old fashioned way, and with the exception of the 2.9 - 2.10 binutils upgrade, it always works. buildkernel overloads the KERNEL variable and thus violates POLA, so it needs fixing regardless, but I don't see a reason to encourage its use unless it is actually needed. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
d'oh, did it backwards again ... buildkernel then buildworld ... let me go
back and rebuild kernel and see if that is all it was in my case ...
Argh! I wish people would stop using buildkernel! :-( It calls config(8)
in such a way that buries the warning messages where people dont see.
config(8) is meant to be used interactively :-(
well, according to /usr/src/UPDATING, that is the documented way to do
things, or at least two out of 4 of them:
To build a kernel
-
If you are updating from a prior version of FreeBSD (even one just
a few days old), you should follow this procedure. With a
/usr/obj tree with a fresh buildworld,
make buildkernel KERNEL=YOUR_KERNEL_HERE
make installkernel KERNEL=YOUR_KERNEL_HERE
To just build a kernel when you know that it won't mess you up
--
cd src/sys/{i386,alpha}/conf
config KERNEL_NAME_HERE [1]
cd ../../compile/KERNEL_NAME_HERE
make depend
make
make install
[1] If in doubt, -r might help here.
If this fails, go to the "To build a kernel" section.
To rebuild everything and install it on the current system.
---
make world
Build a new kernel, see above.
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNEL=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/GENERIC.hints /boot/device.hints [2]
make installkernel KERNEL=YOUR_KERNEL_HERE
make installworld
[1]
reboot
If this is wrong, can we get that updated?
Even /usr/src/README references and steers ppl to buildkernel:
"The ``buildkernel'' and ``installkernel'' targets build and install the
kernel and the modules (see below)"
I have no probs with switching back to the more 'manual way' of cd'ng into
conf and using config, etc ... I just got the impression awhile back that
using buildkernel/installkernel was the recommended way of doing this, so
switched to it ...
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single use
r
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
We were discussing this and a couple of other related strange things
that turned up. I might have broken the npx code with my last config(8)
change and the corresponding #ifdefs. I have not gone back over it all
again but will shortly. Given that two people have this sort of problem
now, things are pointing to the npx commits somehow. You did rebuild confi
g,
right?
Can you please check the opt_npx.h file in your build directory and make su
re
it has "#define DEV_NPX 1" in it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrapp
y
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.or
g
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 John Baldwin wrote: On 22-Jan-01 Donald J . Maddox wrote: On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. That last 'buildkernel' should be 'toolchain'. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: VN bug or pilot error ?
Poul-Henning Kamp wrote: But while you're at it, migrate to md(4) instead of vn(4), it does vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices If I may, two more questions : - the 4.2 man page for vn says the file must be stored locally (I have tried vn-mounting a NFS file and it worked : certainly the man page could be corrected - or I was lucky ?) - under 4.2-Release, I have trouble using a larger than 20 Megs MD partition (I have increased MDNsect to 8, but I still can't store more the 20 Megs : a "cp" with a 35 Megs file stays blocked, and always at the same place - I will give more details) TfH Poul-Henning In message [EMAIL PROTECTED], Thierry Herbelot writes: thanks a lot : that was 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. -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VN bug or pilot error ?
In message [EMAIL PROTECTED], Thierry Herbelot writes: Poul-Henning Kamp wrote: But while you're at it, migrate to md(4) instead of vn(4), it does vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices If I may, two more questions : Sorry, my misundertstanding, seing that you emailed to current@ I pressumed we were talking about -current here. The new md(4)/mdconfig(8) is only in -current and will not make it into -stable any time soon if at all. Poul-Henning - the 4.2 man page for vn says the file must be stored locally (I have tried vn-mounting a NFS file and it worked : certainly the man page could be corrected - or I was lucky ?) - under 4.2-Release, I have trouble using a larger than 20 Megs MD partition (I have increased MDNsect to 8, but I still can't store more the 20 Megs : a "cp" with a 35 Megs file stays blocked, and always at the same place - I will give more details) TfH Poul-Henning In message [EMAIL PROTECTED], Thierry Herbelot writes: thanks a lot : that was 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. -- Thierry Herbelot -- 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: lastest kernel from cvs ( sh exists with signal 8 )
Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes This may be controversial, but it has always worked for me, and although it's not supposed to (in my understanding), the build (I think both world and kernel) does use installed headers. If you don't think so, mv /usr/include and then try to build either. 2) cd usr.sbin/config; make obj make depend make make install 3) config and build kernel 4) make buildworld 5) install kernel 6) make installworld 7) update /etc if necessary 8) reboot Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld 5) reboot cycle instead, since I have been assured that this is the canonical way of doing things now. It appears that these pronouncements were premature at best. On Sun, Jan 21, 2001 at 11:12:44PM -0800, John Baldwin wrote: Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I just do it the old fashioned way, and with the exception of the 2.9 - 2.10 binutils upgrade, it always works. buildkernel overloads the KERNEL variable and thus violates POLA, so it needs fixing regardless, but I don't see a reason to encourage its use unless it is actually needed. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 The Hermit Hacker wrote: On Sun, 21 Jan 2001, Peter Wemm wrote: The Hermit Hacker wrote: d'oh, did it backwards again ... buildkernel then buildworld ... let me go back and rebuild kernel and see if that is all it was in my case ... Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( well, according to /usr/src/UPDATING, that is the documented way to do things, or at least two out of 4 of them: What happened is that binutils was upgraded from 2.9 to 2.10 in both -current and -stable, and the old and new binutils weren't compatible. So, you had to installworld before building your kernel (which is what I did, and always do in fact). However, this made some people uncomfortable, so a 'buildkernel' target was made to work around this one problem. Then, in order to really beat it into -stable users heads to use it for the one needed upgrade, it was declared the end-all be-all method of upgrading a kernel when updating world. Except that it really isn't. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 Donald J . Maddox wrote: Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I normally do this, FWIW: 1) make buildworld 2) make installworld 3) config FOO 4) compile kernel FOO 5) install kernel FOO 6) update /etc 7) reboot 1-5 are all in 2 scripts, and part of 6) is in a script. Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld 5) reboot This should work, except that buildkernel has a few problems: 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting meanings. Simply using KERNCONF for the buildkernel case instead can fix this, however. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: VN bug or pilot error ?
But while you're at it, migrate to md(4) instead of vn(4), it does vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices So why not change the release process to use md instead of vn, so that we can make sure it works before vn is axed? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] "Donald J . Maddox" writes: : way of doing things now. It appears that these pronouncements were : premature at best. Actually no. It isn't premature. It is the canonical way. It is how we've been telling people to build it for at least the past year or so. Some people don't like it and this is really the first I've heard of it. The reliance on buildworld is, I'll agree, a bit much. But that's going away soon. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Exit value of rtprio(1)
Manual page of rtprio(1) says it returns exit value 0 on success when PID is specified via argument. But current rtprio(1) returns 1 whether rtprio(2) is processed successfully or not. This patch seems to fix to return 0 on success as documented in manpage. Please let me know if it is wrong... I'll commit this in this week. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project rtprio.diff
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote: On 22-Jan-01 Donald J . Maddox wrote: 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I used to do 'make -DCLOBBER includes' to make sure no old stuff survived, but somebody decided that was just too convenient, I guess. No CLOBBER in the Makefiles anymore... SNIP This should work, except that buildkernel has a few problems: 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting meanings. Simply using KERNCONF for the buildkernel case instead can fix this, however. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ I think this is a good policy :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] John Baldwin writes: : 2) It hides the output from config(8). config(8) prints out all sorts of : useful warnings when options are deprecated, etc., but buildkernel hides these : from the user. The problem is that config(8) is by design an interactive tool, : which buildkernel fails to take into account. The hack now is to have : config(8) treat warnings as errors instead. :-/ config is not an interactive tool, any more than the compiler is an interactive tool. buildkernel hiding it from the user is a bug in buildkernel. It should be fixed. You shouldn't throw the baby out with the bath water. buildkernel is a much simplified way of telling people how to build kernels. As someone in the front lines of that game, I can tell you that the support load from that has dropped off quite a bit since we started telling people to use it. If you want to advocate all the steps that make it safe by hand, feel free, but the average user had no need to know them, nor do them by hand. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VN bug or pilot error ?
In message [EMAIL PROTECTED], John Hay write s: But while you're at it, migrate to md(4) instead of vn(4), it does vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices So why not change the release process to use md instead of vn, so that we can make sure it works before vn is axed? I will do, as soon as I have time... -- 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
