Re: ifconfig accepting hostname as ipv4 address
On Saturday 09 June 2012 23:29:02 Kevin Oberman wrote: On Sat, Jun 9, 2012 at 12:37 AM, Garrett Cooper yaneg...@gmail.com wrote: I agree that it's not the best configuration in the world, as it would only work 100% if a machine had proper DNS records or a definitive hosts file. There are already enough bugs with static IP configurations and hostnames as-is *I'm looking at you mountlate* -- no sense to introduce more potentially buggy interoperability that only works in a handful of niche cases. The idea was that you could enter all of the local interface names in /etc/hosts and than just put the names into the ifconfig commands. It was handy for keeping track of what port connected where on systems that had numerous interfaces, though this was more common in the day of async serial lines and modems. I'll admit that I have mixed feelings about its practicality today, though it does not hurt anything, as far as I can tell. It works fine as long as the machine has its own address in /etc/hosts - does anyone not do that? Also, note that I'm not suggesting adding any functionality at all; just replying to a suggestion that functionality be /removed/ - by pointing out that we find it useful and would rather not see it go. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 07/06/2012 01:26, Florian Smeets wrote: On 05.06.12 16:29, Mark Felder wrote: On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets f...@freebsd.org wrote: As far as i understand it does at least enable usage of pages up to 4MB, perhaps someone should teach mysql about the FreeBSD's limits? If you look at the output i sent, it certainly changes from using no superpage mappings at all to using them to some degree, if you script can be trusted Wow, this is a nice find. If someone were to add a patch for FreeBSD's superpages we might be able to get a nice little performance boost with little effort. Even the increase to 4MB for now is a welcome improvement. I'll make sure to put this in my toolbox I played with this some more. MySQL does not seem to use superpages. After a mysqld restart Ivan's script and procstat showed superpage mappings for mysqld, but it seems once MySQL touches the memory it's not in superpages anymore. I looked at the MySQL code a bit and one would need to add FreeBSD support in a couple of places. Perhaps I'll find some time to try this, but i cannot make any promises. If I understand how superpages are promoted correctly, you may get a nice effect simply by changing malloc()s of 2MB+ sizes to calloc()s. signature.asc Description: OpenPGP digital signature
Re: cleaning /usr/obj before copying it to USB key
On Sun, Jun 10, 2012 at 01:07:58PM +0300, Aldis Berjoza wrote:
On Sat, 9 Jun 2012 08:57:33 -0700
Tim Kientzle t...@kientzle.com wrote:
You can delete all of the '.o' files using a command like this:
find /usr/obj -name '*.o' | xargs rm
I think:
find /usr/obj -name '*.o' -delete
is much better
Or:
find /usr/obj -name '*.o' -exec rm {} \+
pgp8GkHn7TLql.pgp
Description: PGP signature
Re: cleaning /usr/obj before copying it to USB key
El día Monday, June 11, 2012 a las 09:24:02AM +0200, Lars Engels escribió:
On Sun, Jun 10, 2012 at 01:07:58PM +0300, Aldis Berjoza wrote:
On Sat, 9 Jun 2012 08:57:33 -0700
Tim Kientzle t...@kientzle.com wrote:
You can delete all of the '.o' files using a command like this:
find /usr/obj -name '*.o' | xargs rm
I think:
find /usr/obj -name '*.o' -delete
is much better
Or:
find /usr/obj -name '*.o' -exec rm {} \+
Thanks for the hints concerning find(1) usage. I was wondering if there
is nothing like
# make install-clean
or
# make remove-tempfiles
Thanks
matthias
--
Matthias Apitz
e g...@unixarea.de - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: usertime stale at about 371k seconds
On 05/31/2012 02:34, Andrey Zonov wrote:
On 5/30/12 11:27 PM, Andrey Zonov wrote:
Hi,
I have long running process for which `ps -o usertime -p $pid' shows
always the same time - 6190:07.65, `ps -o cputime -p $pid' for the same
process continue to grow and now it's 21538:53.61. It looks like
overflow in resource usage code or something.
I reproduced that problem with attached program. I ran it with 23
threads on machine with 24 CPUs and after night I see this:
$ ps -o usertime,time -p 24134 sleep 60 ps -o usertime,time -p 24134
USERTIME TIME
6351:24.74 14977:35.19
USERTIME TIME
6351:24.74 15000:34.53
Per thread user-time counts correct:
$ ps -H -o usertime,time -p 24134
USERTIME TIME
0:00.00 0:00.00
652:35.84 652:38.59
652:34.75 652:37.97
652:50.46 652:51.97
652:38.93 652:43.08
652:39.73 652:43.36
652:44.09 652:47.36
652:56.49 652:57.94
652:51.84 652:54.41
652:37.48 652:41.57
652:36.61 652:40.90
652:39.41 652:42.52
653:03.72 653:06.72
652:49.96 652:53.25
652:45.92 652:49.03
652:40.33 652:42.05
652:46.53 652:49.31
652:44.77 652:47.33
653:00.54 653:02.24
652:33.31 652:36.13
652:51.03 652:52.91
652:50.73 652:52.71
652:41.32 652:44.64
652:59.86 653:03.25
(kgdb) p $my-p_rux
$14 = {rux_runtime = 2171421985692826, rux_uticks = 114886093,
rux_sticks = 8353, rux_iticks = 0, rux_uu = 381084736784, rux_su =
65773652, rux_tu = 904571706136}
(kgdb) p $my-p_rux
$15 = {rux_runtime = 2191831516209186, rux_uticks = 115966087,
rux_sticks = 8444, rux_iticks = 0, rux_uu = 381084736784, rux_su =
66458587, rux_tu = 913099969825}
As you can see rux_uu stale, but rux_uticks still ticks. I think the
problem is in calcru1(). This expression
uu = (tu * ut) / tt
overflows.
I applied the following patch:
Index: /usr/src/sys/kern/kern_resource.c
===
--- /usr/src/sys/kern/kern_resource.c (revision 235394)
+++ /usr/src/sys/kern/kern_resource.c (working copy)
@@ -885,7 +885,7 @@ calcru1(struct proc *p, struct rusage_ext *ruxp, s
struct timeval *sp)
{
/* {user, system, interrupt, total} {ticks, usec}: */
- uint64_t ut, uu, st, su, it, tt, tu;
+ uint64_t ut, uu, st, su, it, tt, tu, tmp;
ut = ruxp-rux_uticks;
st = ruxp-rux_sticks;
@@ -909,10 +909,20 @@ calcru1(struct proc *p, struct rusage_ext *ruxp, s
* The normal case, time increased.
* Enforce monotonicity of bucketed numbers.
*/
- uu = (tu * ut) / tt;
+ if (ut == 0)
+ uu = 0;
+ else {
+ tmp = tt / ut;
+ uu = tmp ? tu / tmp : 0;
+ }
if (uu ruxp-rux_uu)
uu = ruxp-rux_uu;
and now ran test again.
This looks related to, and possibly identical to, PR kern/76972:
http://www.freebsd.org/cgi/query-pr.cgi?pr=76972
If you filed a PR, please submit a follow-up to both PRs so they
reference each other.
Thanks,
Eric
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Issue with KGDB setup. System freezes when it enters ddb
Hello, Can someone plese help me understand what is the problem? After fresh disk installation of freeBSD9.0 AMD64 from disk, I copied /usr/src/sys/am64/conf/GENERIC to KGDBKERNEL and added following lines to the file options GDB options DDB options KDB_UNATTENDED options BREAK_TO_DEBUGGER options ALT_BREAK_TO_DEBUGGER After this I rebuilt the Kernel and installed as below. make buildworld make buildkernel kernconf=KGDBKERNEL make installkernel kernconf=KGDBKERNEL Reboot into single user mode. mergemaster -p make installworld mergemaster Reboot. After this to setup KGDB I am using following document as my reference. http://chetanbl.blogspot.com/ To break into ddb I am trying issue sysctl debug.kdb.enter=1. Then the system becomes unresponsive. Also, I tried to enter ddb at booting stage by issuing boot -d command. Even then system becomes unresponsive. I need to solve this problem ASAP. Can someone helpme? Thanks, Nag ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Getting rid of RC2 cipher
# From: '/usr/src/crypto/openssl/CHANGES.SSLeay' NO_RC2=YES Doesn't work (after build and install): # /usr/bin/openssl ciphers -v | grep -i rc RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VirtualBox on FreeBSD is looking for you!
On Sunday 10 June 2012 08:55:52 Bernhard Froehlich wrote: - USB support (needs fixing) Hi, If questions arise I can answer them and give advice with regard to libusb in baseport and the USB FS interface. I've been somewhat involved fixing the USB support for VirtualBox under FreeBSD last time, and I think the VirtualBox team did a minor mistake from the beginning and that was to use the USB FS IOCTL interface directly, instead of using the USB library from baseport. Anyway, that works too as long as you understand a bit of USB :-) Currently there are some issues. One of them is that certain functionality is only available as root, like detaching kernel drivers and such. I'm not sure what the best way forward is. Currently PRIV_DRIVER is used for alot in USB, and VirtualBox needs that to function properly currently with regard to USB. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FreeBSD Boot Times
Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. -Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falk bfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
They have a lot of manpower and can spend a lot of time replacing the boot subsystems and all startup scripts every 2 releases. For FreeBSD it's not a big issue as most people don't reboot often. If it's an itch you want to scratch you're more than welcome to look into it; that seems to be the way a lot of little things get worked on around here. Unfortunately the new systemd rc system (which is pretty awful) has issues of its own including the inability to handle /usr on a separate filesystem under certain situations.[1] I honestly prefer the freebsd startup system and rc.conf. Speed isn't an issue for me right now. It's even less obvious if you just use an SSD for /. [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
On Jun 11, 2012, at 6:21 PM, Brandon Falk bfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. -Brandon _ In amd64 builds the system checks it's ram twice . Early in the boot phase using a slower method , and latter using a faster SMAP method. In 9.0-RELEASE you can disable the early men check via a loader tunable , here is a snip it from the release notes on 9.0 . It should also be mfc'd to 7, and 8 stable. [amd64, i386, pc98] A loader(8) tunable hw.memtest.tests has been added. This controls whether to perform memory testing at boot time or not. The default value is 1 (perform a memory test).[r224516] The next it is switch to a modular kernel this speeds up boot times be omitting kernel items you do not need, you can also do this via with a static kernel by removing / disabling unused options . Look at the Archives for ha hackers there is a ton of info on this. Most of the rest of the boot up time is via init / rc'ng starting an configuring things . Right now this is not parallel-ized out the box . Pc-bsd has something called fastboot ? I am am not sure how it works but it improves load time in their setups . See http://lists.pcbsd.org/pipermail/testing/2012-January/006358.html Other then that, there are some other things being developed check the FreeBSD wiki for a rc.ng management daemon frs or fsr ? --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Upcoming release schedule - 8.4 ?
Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Mon, Jun 11, 2012 at 03:38:56PM -0700, John Kozubik wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: decoding of multi-byte nops in dtrace
on 11/06/2012 06:49 per...@pluto.rain.com said the following:
Sounds as if DTrace could use an improvement to recognize and handle
the tail call optimization, maybe something along the lines of:
If a function has no otherwise-determined return probe
and it contains a jump to the entry point of another function
then it inherits that other function's return probe.
I'd expect that to handle cases like
int bar(...)
{
...
return baz;
}
int foo(...)
{
...
return bar(...);
}
(although probably not cases where the return in foo calls a
function pointer). And no, I am not volunteering to add it --
ENOTIME :(
(Open)Solaris fdt code for sparc already handles this case (last instruction in
a function being a call), but not any other implementation.
Not sure if that is for technical reasons or if nobody just bothered.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
