Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
On Wed, 1 Sep 2010, Ivan Voras wrote: On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. Once I pay attention to any particular window, the scheduler rapidly (like, in 15 agonising seconds or so) decides that the processes associated with that particular window are interactive and performance there picks up again. But it only takes 10 seconds (not timed; ballpark figures) or so of inattention for a window's processes to lapse back into a low-priority state, with the attendant performance problems. windows in X11 have nothing to do with the scheduler (contrary to MS Windows where the OS actually re-nices processes whose windows have focus) - here you are just interacting with a process. Yup, and it does seem that by interacting with the process, things'll start to pick up again - for the processes associated with that window. On the other hand, I have noticed that a 2xQuad-core machine I have access too has more X11 interactivity problems than this single quad-core machine, though again not as serious as yours. I don't know why this is. From the hardware side it might be the shared FSB or from the software side it might be the scheduler. If you want to try something I think it's easier for you to disable one CPU in BIOS or pin X.org and its descendant processes to CPUs of a single socket than to diagnose scheduler problems. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. It would be best if you could quantify this in some way. I have no idea how. Yeah, I realised that my report was this doesn't work [very well]! which is fairly terrible when it comes to tracking things down; mostly, I was hoping to prompt none, some or lots of same heres to see if the problem was commonly seen. Also (as you're aware) a desktop environment is a complex beast, and putting numbers against look and feel is tricky - however in this situation, I can get numbers from a wall-clock, the behaviour is that pronounced. I'll certainly try getting the whole X tree onto a single socket, to see if that makes any difference. I'll certainly have a stab with your suggestion - thanks Ivan. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
On Thu, 2 Sep 2010, Andriy Gapon wrote: on 02/09/2010 12:08 jan.gr...@bristol.ac.uk said the following: On Wed, 1 Sep 2010, Ivan Voras wrote: On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. From my experience: 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - enabling OpenGL desktop effects in KDE4 leads to the consequences like what you describe. With all GUI bells and whistles disabled the system behaves quite like the AMD system. All desktop effects are disabled. The graphics are from an nVidia GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour that's affected, though: the box runs a number of small headless [interactive] server processes which also appear to get rapidly starved of CPU time.) The behaviour isn't visible with the 4bsd scheduler; stuff generally remains snappy and responsive. I'll keep poking around and see if I can get to the bottom of it. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Rereleasing dolphins into the wild since 1998. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Once I pay attention to any particular window, the scheduler rapidly (like, in 15 agonising seconds or so) decides that the processes associated with that particular window are interactive and performance there picks up again. But it only takes 10 seconds (not timed; ballpark figures) or so of inattention for a window's processes to lapse back into a low-priority state, with the attendant performance problems. I don't think my desktop usage is particularly abnormal; I doubt my level of frustration is, either :-) I think the issue here is that a modern desktop has quite a lot of associated processes, and you can't keep them all sufficiently interactive in the eyes of sched_ule to ensure they stay responsive. Are there particular tunables associated with sched_ule (the manpage says not) that I might look at to try to address this? Or process flags I can set on my desktop tasks to keep them nearer the interactive end of the spectrum? Claimed is: o Interactivity heuristics that detect interactive applications and schedules them preferentially under high load. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. At the moment I'm fiddling around with cpusets to try to pin my port builds to a subset of the available processors. Suggestions are welcome! Cheers, jan PS. I've stuck it out with sched_ule since it's been available, but I should point out this isn't a sudden change in its behaviour; it's done this for a while. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ No generalised law is without exception. A self-demonstrating axiom. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, Oliver Fromme wrote: Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. Check the man page for rm: -f Attempt to remove the files without prompting for confirma- tion, regardless of the file's permissions. If the file does not exist, do not display a diagnostic message or modify the exit status to reflect an error. That's what's happening the second time through. The first time, your current directory is getting removed (so ../ won't refer to a real directory the second time around). The bug is really in rm(1)'s initial diagnostic message. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ We thought time travel was impossible. But that was now and this is then. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.x EoL
On Tue, 17 Oct 2006, Michael W. Oliver wrote: 1. Be prepared to spend a lot of time in single-user mode, especially for the 4-5 step, because there is a LOT for mergemaster to do. The step from 5-6 is not nearly as painful. I didn't try to do the installworld and mergemaster in multiuser, and if you do then have a bigger set than I do. If you're setting up machines that you're going to be upgrading like this in the future, I think it's _really_ worthwhile hacking out a couple of root slices - that is, space for a second / and /usr - to facilitate this. You can run mergemaster on a secondary copy of your /etc (this, of course, requries that the contents of /etc are relatively quiescent for this step) and tidy up by hand. You can perform a dump restore followed by a source upgrade, a fresh source install or a binary upgrade ad lib; just reboot (with nextboot) when done. This also means you can keep the previous OS around for a while in case there are problems with the new one. For setups that aren't amenable to automated deployments this works pretty well and gives you a safety-net for upgrades. Cheers, jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ We thought time travel was impossible. But that was now and this is then. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
(some?) startup scripts being run twice..?
I'm running a stock freebsd-stable as a workstation. I'm seeing something unusual: it looks like some startup scripts are being run twice when the machine boots. Originally I caught this because an old-fashioned /usr/local/etc/rc.d script was being called twice. However, on looking closer it seems that I'm getting ntpd launched twice as well. There may be others that bomb out - but has anyone got any suggestions as to what might be causing this? rc.conf is boring (just turns on a bunch of the usual suspects you'd see on a workstation); I can't see in /etc/rc why this might be occurring. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...and then three milkmaids turned up (to the delight and delactation of the crowd). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Solved (pilot error) Re: (some?) startup scripts being run twice..?
On Tue, 2 May 2006, Jan Grant wrote: I'm running a stock freebsd-stable as a workstation. I'm seeing something unusual: it looks like some startup scripts are being run twice when the machine boots. Originally I caught this because an old-fashioned /usr/local/etc/rc.d script was being called twice. However, on looking closer it seems that I'm getting ntpd launched twice as well. There may be others that bomb out - but has anyone got any suggestions as to what might be causing this? rc.conf is boring (just turns on a bunch of the usual suspects you'd see on a workstation); I can't see in /etc/rc why this might be occurring. Tracked this down: fwiw, from /etc/rc.conf - local_startup=/etc/rc.d /usr/local/etc/rc.d /usr/X11R6/etc/rc.d The /usr/local/etc/rc.d old-fashioned startup script was being called twice due to the double invocation of /etc/rc.d/localpkg. Cheers, jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Roger Penrose can never be convinced that this sentence is true. (If he doesn't get the joke, you can at least prove that he owes you money.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (some?) startup scripts being run twice..?
On Tue, 2 May 2006, Alexey Karagodov wrote: where ntpd script located? in /etc/rc.d or /usr/local/etc/rc.d or both? I've already checked this: it's solely in /etc/rc.d. There's other evidence of dual initialisation, too: [[[ Apr 27 08:51:01 xxx sshd[1296]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. Apr 27 08:51:01 xxx sshd[1296]: fatal: Cannot bind any address. ]]] The instance of sshd that is running was successfully started a few seconds before this. Again, this is coming out of /etc/rc. 2006/5/2, Jan Grant [EMAIL PROTECTED]: I'm running a stock freebsd-stable as a workstation. I'm seeing something unusual: it looks like some startup scripts are being run twice when the machine boots. Originally I caught this because an old-fashioned /usr/local/etc/rc.d script was being called twice. However, on looking closer it seems that I'm getting ntpd launched twice as well. There may be others that bomb out - but has anyone got any suggestions as to what might be causing this? rc.conf is boring (just turns on a bunch of the usual suspects you'd see on a workstation); I can't see in /etc/rc why this might be occurring. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...and then three milkmaids turned up (to the delight and delactation of the crowd). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Solution: (n) a watered-down version of something neat. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnome-upgrade.sh
On Fri, 11 Nov 2005, Michael C. Shultz wrote: On Friday 11 November 2005 01:43, Jan Grant wrote: My pkgtools.conf has hundreds(! - busy workstation) of entries along these lines - some entries apply to several ports, and the portupgrade toolset just basically uses the union of all matching rules: [[[ '*/*' = 'BATCH=yes', '*/kde*' = 'WITH_KDE_DEBUG=yes', 'databases/p5-DBI' = 'WITH_PROXY=yes', 'deskutils/kdepim3' = 'WITH_KPILOT=yes', 'devel/gnomevfs2' = 'WITH_X11=yes', 'devel/sdl12' = 'WITH_X11=yes', 'devel/subversion' = 'WITH_PYTHON=yes WITH_MOD_DAV_SVN=yes WITHOUT_BDB=yes', ]]] ... and so on; so deskutils/kdepim3 gets built with BATCH=yes WITH_KPILOT=yes WITH_KDE_DEBUG=yes but more importantly, any future kde packages also get WITH_KDE_DEBUG=yes automatically. It'd be convenient if portmanager supported the same wildcard ability (it'd make the script to migrate settings from pkgtools.conf to portmanager much more straightforward). Port build options are covered in man portmanager(1). You didn't provide an example where wild cards are used so I'm not sure what you mean there. The asterisks in the snippet above are wildcards. When portupgrade looks for the options to a port, it pattern-matches against all the entries. The deskutils/kdepim3 is a simple example above. Stopping/starting is a new feature just introduced in 0.3.3_3. Cheers, that's very handy. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Goedel would be proud - I'm both inconsistent _and_ incomplete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnome-upgrade.sh
On Fri, 11 Nov 2005, Michael C. Shultz wrote: [on wildcards in portmanager rules] Silly me, I get it now. Not supported yet but I like the idea so am adding it to the things to do list. This one will be near the top. That's great! - especially since that pretty much makes it a mechanical process to take pkgtools.conf and spit out a corresponding portmanager config. Thanks Mike. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Personal responsibility for corporate decisions: if they've nothing to hide, they've nothing to lobby against. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnome-upgrade.sh
On Fri, 11 Nov 2005, Michael C. Shultz wrote: On Friday 11 November 2005 05:58, Michael C. Shultz wrote: On Friday 11 November 2005 05:58, Jan Grant wrote: On Fri, 11 Nov 2005, Michael C. Shultz wrote: [on wildcards in portmanager rules] Silly me, I get it now. Not supported yet but I like the idea so am adding it to the things to do list. This one will be near the top. That's great! - especially since that pretty much makes it a mechanical process to take pkgtools.conf and spit out a corresponding portmanager config. Thanks Mike. I'll try to remember cc'ing you when I submit a change this. My guess is two days to a week, depends on if any new bugs are reported. -Mike One last thing, if you make a script that does the conversion, might I have a copy? Here is how I'll set up pm-020.conf to work: Surely. pkgtools.conf is actually a ruby script: I've no idea how dynamically the rules are evaluated but something that works ona prettystock bunch of settings should be close to trivial. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...and then three milkmaids turned up (to the delight and delactation of the crowd). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnome-upgrade.sh
On Fri, 11 Nov 2005, Michael C. Shultz wrote: One last thing, if you make a script that does the conversion, might I have a copy? Here is how I'll set up pm-020.conf to work: Surely. pkgtools.conf is actually a ruby script: I've no idea how dynamically the rules are evaluated but something that works ona prettystock bunch of settings should be close to trivial. Thank you. If it works well I might use it to have portmanager pick up settings from portupgrade on the fly, or at least provide some sort of conversion command. Thanks :) Attached uses ruby to parse the pkgtools.conf (it relies on the portupgrade ruby package) - it'll spit out the appropriate sections (HOLD_PKGS, BEFOREBUILD, AFTERINSTALL and MAKE_ARGS) in what I think the portmanager format is (although the script is trivial, as you can see). Note that the MAKE_ARGS etc go through a hash/dictionary and consequently are unordered. A small snippet of the output I get from this: [[[ CATEGORY/PORT|OPTION=| # do not delete this line! # Ignored packages from HOLD_PKGS IGNORE|bsdpan-*| IGNORE|x11/nvidia-driver| IGNORE|editors/openoffice*| # STOP entries come from BEFOREBUILD # START entries come from AFTERINSTALL START|/databases/postgresql7 chmod a+x /usr/local/share/postgresql/502.pgsql| START|/www/jakarta-tomcat5 chmod a-x /usr/local/etc/rc.d/020.jakarta-tomcat*.sh| # Package options from MAKE_ARGS # Note: pkgtools.conf will use the UNION of all matching lines security/gnupg|WITH_SUID_GPG=yes| devel/subversion|WITH_PYTHON=yes WITH_MOD_DAV_SVN=yes WITHOUT_BDB=yes| x11/kde3|| deskutils/kdepim3|WITH_KPILOT=yes| www/gallery|| www/rt*|WITH_FASTCGI=yes WITH_APACHE2=yes DB_TYPE=Pg DB_HOST=localhost DB_DATABASE=rt3 DB_USER=rt3| www/apache2|WITH_PROXY_MODULES=yes| multimedia/kdemultimedia*|WITH_LAME=yes WITH_XINE=yes WITH_MPEGLIB=yes| */*|BATCH=yes| java/jdk14|NATIVE_BOOTSTRAP=yes JAVA_HOME=| */kde*|WITH_KDE_DEBUG=yes| mail/exim|WITH_EXIMON=yes WITH_EXISCAN_ACL=yes WITH_TCP_WRAPPERS=yes WITH_PGSQL=yes WITHOUT_PERL=yes | ]]] -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ I'm the dandy information superhighwayman.#!/usr/local/bin/ruby require pkgtools puts CATEGORY/PORT|OPTION=| # do not delete this line! load_config # held packages puts puts # Ignored packages from HOLD_PKGS puts config_value(:HOLD_PKGS).each do |pkg| puts IGNORE| + pkg + | end # beforebuild becomes stop puts puts # STOP entries come from BEFOREBUILD puts config_value(:BEFOREBUILD).each do |pkg| puts STOP|/ + pkg[0] + + pkg[1] + | end # afterinstall becomes start puts puts # START entries come from AFTERINSTALL puts config_value(:AFTERINSTALL).each do |pkg| puts START|/ + pkg[0] + + pkg[1] + | end # package options. puts puts # Package options from MAKE_ARGS puts # Note: pkgtools.conf will use the UNION of all matching lines puts config_value(:MAKE_ARGS).each do |pkg| puts pkg[0] + | + pkg[1] + | end ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrading 5.4 - 6.0 without reinstalling. safe ?
On Thu, 10 Nov 2005, Filip Lenaerts wrote: hi all On Thu, Nov 10, 2005 at 11:17:13AM +, Jan Grant wrote: FWIW I've just done a successful remote source-based upgrade from 5.4 to 6.0 (I'm brave) with no problems. I use a second root and /usr to be also did that last night with the latest sources, but failed when booting in single user mode: i get a kernel panic when the kernel is loading the nvidia0 device. Providing you remember to rebuild or disable any 5.x-era kernel modules from ports (nvidia, rtc, etc) prior to the reboot it should work fine and offers a now this is interesting :) i have a nvidia gforce 6600xl, but i can't remember installing/using the nvidia port. perhaps its installed as dependency of xorg? moreover in the sources, there is also a agp_nvidia.c. anyone perhaps knows how this relates to the ports? is it an equivalent? are they redundant to eachother? You have an option to use the FreeBSD agp device support or nVidia's. I have no idea what criteria one might use to select between them. i'll try recompiling this evening the port and try a boot -s :) If the device is loaded from /boot/loader.conf you might need to disable that in order for the boot to single-user to work. YMMV. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Goth isn't dead, it's just lying very still and sucking its cheeks in. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Resolver doesn't like 1.2.3.04 in /etc/hosts
On Thu, 27 Oct 2005, Mark Andrews wrote: On 2005-10-26, Mark Andrews wrote: Leading zeros are ambigious. Some platforms treat them as octal others treat them as decimal. There is nothing ambiguous about the example provided. (Perhaps it wasn't a good example, but it's always a bug if '04' is not correctly decoded, regardless of the numeric base in use.) You want a ambigious example? 192.168.222.012 It amazed me that no RFC ever appears to have standardised this format (although it is alluded to in passing as being decimal in various other places). Eg, 1035 has: [[[ The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., 10.2.0.52 or 192.0.5.6). ]]] (although that's DNS zone file format, not /etc/hosts.) It's much easier to just reject octal and hexadecimal than to work out when and when not it is ambigious. It is also better to demand all 4 octets. It also generates less support complaints. I'm happy to reject octal and hex too! Anyway, count this as one (minor) support gripe :-) Thanks for your time, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ stty intr ^m ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Resolver doesn't like 1.2.3.04 in /etc/hosts
On Thu, 27 Oct 2005, Paul T. Root wrote: man inet_addr and you'll find: All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; otherwise, the number is interpreted as decimal). So a leading zero means hex. Stop trying to make it look pretty. Standards are a good thing and need to be followed. I also found: [[[ STANDARDS The inet_ntop() and inet_pton() functions conform to X/Open Networking Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not accept 1-, 2-, or 3-part dotted addresses; all four parts must be specified and are interpreted only as decimal values. This is a narrower input set than that accepted by inet_aton(). ]]] on that same man page :-) Cheers, jan PS. I only raised the issue in case anyone else was bitten by it (which is why a PR might be handy). Having fixed /etc/hosts, I don't think this is worth wasting more energy on. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Resolver doesn't like 1.2.3.04 in /etc/hosts
On Thu, 27 Oct 2005, Paul T. Root wrote: Jan Grant wrote: On Thu, 27 Oct 2005, Paul T. Root wrote: man inet_addr and you'll find: All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; otherwise, the number is interpreted as decimal). So a leading zero means hex. Stop trying to make it look pretty. Standards are a good thing and need to be followed. [ STANDARDS section from the man page snipped ] Sure but the hosts(5) man page says that it follows inet_addr(3) spec. Sorry, I neglected to put that little leap in. You're right. So, we appear to agree that either the man page for hosts(5) is in need of an update, or the resolver is currently not conforming to the described behaviour? Since 1.2.3.04foo is currently an illegal /etc/hosts entry. Cheers, -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ They modified their trousers secretly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Resolver doesn't like 1.2.3.04 in /etc/hosts
I don't know whether this is worth filing a PR for, but it seems the resolver no longer likes leading zeroes in an IP4 address in /etc/hosts. The change (in 5- ) appeared sometime in the last month or two. Personally I'm inclined to view this as a regression although it's simple enough to work around. Cheers, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Unfortunately, I have a very good idea how fast my keys are moving. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: who has experience about updating freebsd from 4.11 to 5.x
On Mon, 5 Sep 2005 [EMAIL PROTECTED] wrote: Quoting liguoqiang\(126\) [EMAIL PROTECTED]: Hi, all: I update my freebsd ver 4.11 by cvsup src-all tree. It's successfully as below: make buildworld make buildkernel make installkernel But some errors appear when i make installworld: It has been my experience that updating from one full version to another (3.x to 4.x, 4.x to 5.x) is better done by doing a clean binary install of the next version, then import/install software and users on the new system. I understand that this is not always an option, but I have had less problems this way than cvsup across full versions. FWIW I've had no problems following the source upgrade instructions - they were very successful. The only issue I came across was one of my own making: I used a second drive to install copies of /, /usr to manage upgrades (much like solaris' liveupdate) and wound up with a ufs2 /, which my original bootloader (from the 3.x days) didn't grok. Cheers, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ and Nostradamus never dreamed of the Church of the Accellerated Worm ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Expert input required: P4 odd signals, no apparent memory fault, DISABLE_PSE?
I'm tracking -STABLE on a 1.8GHz P4 with 512MB of memory. Roughly since the PAE changes were MFCed, I've been seeing memory-corruption-related errors under specific circumstances: for example, a run of portsdb -fUu can be guaranteed to generate SIGBUS, SIGILL and SIGSEGVs in a handful of sh, sed, etc. processes. However, reverting to a 4.8 kernel from prior to September either hides/masks these errors, or no longer triggers them. The memory/mobo _appears_ to check out OK under (ferinstance) extended runs of memtest86. Now, on -current I've seen reference to the DISABLE_PSE kernel option, and some discussion that this behaviour may be due to a processor/timing bug. So I have the following questions which I'd appreciate an expert giving a definitive opinion on (I'm no x86/hardware hacker, me): - are these problems potentially caused by this bug? - what exactly does DISABLE_PSE do? (it's undocumented and a one-para explanation of the expected behaviour of this option would be appreciated) - were any commits around the time of the MFC of the PAE code liable to have introduced problems into the kernel which this workaround might address? I know it's a lot to ask, but both hardware and OS have been rock-solid up until this point. Although I've not conclusively ruled out hardware faults, the continued stability under high load of a pre-september 4.8 kernel makes me suspicious that this is more likely to be a bug getting tickled than I'd normally suspect from these symptoms. I'm about to experiment with this option but it currently feels a little like cargo-cult admin. If there are any definitive tests that would indicate if this hardware problem is present and addressed by this, that's be nice to know too. Cheers, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ No generalised law is without exception. A self-demonstrating axiom. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Expert input required: P4 odd signals, no apparent memoryfault, DISABLE_PSE?
On Mon, 20 Oct 2003, Mike Tancsa wrote: How recent is your copy of RELENG_4 ? The PSE disable code was committed to the tree already as well as a fix so it would work with APM on the 17th. By default it is disabled. If you look at your dmesg.boot you should see Warning: Pentium 4 CPU: PSE disabled Latest was pre-weekend; I'm just completing a fresh build now, so I hope this'll lick the problem, thanks. (Incidentally this might well be worth documenting in UPDATING since it's an issue that's been plaguing me [and a few correspondents, according to emails I've had] for a while.) -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ Prolog in JavaScript: http://ioctl.org/logic/prolog-latest ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Solved. Re: Expert input required: P4 odd signals, no apparent memoryfault, DISABLE_PSE?
On Mon, 20 Oct 2003, Jan Grant wrote: On Mon, 20 Oct 2003, Mike Tancsa wrote: How recent is your copy of RELENG_4 ? The PSE disable code was committed to the tree already as well as a fix so it would work with APM on the 17th. By default it is disabled. If you look at your dmesg.boot you should see Warning: Pentium 4 CPU: PSE disabled Latest was pre-weekend; I'm just completing a fresh build now, so I hope this'll lick the problem, thanks. (Incidentally this might well be worth documenting in UPDATING since it's an issue that's been plaguing me [and a few correspondents, according to emails I've had] for a while.) Well, I'm pleased to report what looks like success: as Mike indicated, PSE is now disabled automatically by default. I've tried repeating the activities which have recently been triggering memory corruption - so far with no ill effects. I'll keep the stress tests running overnight. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ I think therefore I am. -- Ronnie Descartes ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var error
On Wed, 9 Jul 2003, Kirk Strauser wrote: At 2003-07-09T08:36:50Z, Brandon S. Allbery KF8NH [EMAIL PROTECTED] writes: Install sysutils/lsof and use it to find what program has a deleted file open on /var; kill that program, and the space will be reclaimed. I see that advice a lot. Is lsof inherently superior to `fstat' in the base system? You don't _need_ lsof, it just ties things neatly together for you. If you don't have lsof (for whatever reason), you can scan down /var looking for missing open inodes - eg, the script at http://ioctl.org/unix/scripts/openfiles does that. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ ...and then three milkmaids turned up (to the delight and delactation of the crowd). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: OpenSSL 0.9.7 in -STABLE
On Tue, 25 Feb 2003, Jacques A. Vidrine wrote: On Tue, Feb 25, 2003 at 10:30:54AM -0500, Mike Tancsa wrote: At 07:32 AM 25/02/2003 -0600, Jacques A. Vidrine wrote: I believe you also need `device cryptodev', else when your application tries to open /dev/crypto it will get ENXIO (use truss or ktrace to see if this is what is happening). That was it, Thanks! Great! There is now a VERY noticeable difference in the amount of CPU that sshd takes. The backup server is a PIII800. When doing a dump from a fast client, with 3des I was looking at close to 40%-50% of CPU going to sshd on the server. Now I see about 3%-5%. So how is the total throughput? Is it a win or a lose with the 7951? Excuse my curiosity: would measuring the throughput of a loopback ssh link give a good estimate of this? -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ Theory and practice _are_ the same thing. In theory. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Remote upgrading (was: /etc/make.conf question)
On Tue, 12 Mar 2002, Erik Trulsson wrote: There are two reasons for booting into single-user. One is to make sure that the machine is quiet since any programs running might get confused as the system is changed underneath them. The other is to allow you to check that the newly-built kernel is working properly before you install all the user-land programs. It is easy to go back to using an older kernel but reversing an installworld is not so easy. Now, if you can ensure that the machine is quiet in some other way, for example by not running any applications yourself and making sure nobody else is logged in, and are confident that the new kernel will work then there is no reason you can't do a remote upgrade. I have done remote upgrades on my computer several times without any major problems but YMMV. There also seems to be a bit of a push to get /usr (and /) read-only. If you can manage that, then an alternative (fast) upgrade mechanism looks like this: - mirror (copy) / and /usr to spare partition - mount copy of / and /usr somewhere out of the way - run the upgrade on the off-line copy - reboot into the mirrored system - if that worked ok, switch your notion of live and copy. It'd be really nice if the bootloader could fall back to the known good state, should the reboot fail. Otherwise, you're stuck with a serial console to try to figure things out. Sun have something like this for Solaris; it's a neat trick. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] Impact of vulnerability: Run code of an attacker's choice Maximum Severity Rating: Moderate -- M$ security bulletin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
