Re: Mount_nfs question
On Mon, 30 May 2011, Mark Saad wrote: So I am stumped on this one. I want to know what the IP of each nfs server that is providing each nfs export. I am running 7.4-RELEASE When I run mount -t nfs I see something like this VIP-01:/export/source on /mnt/src VIP-02:/export/target on /mnt/target VIP-01:/export/logs on /mnt/logs VIP-02:/export/package on /mnt/pkg The issue is I use a load balanced nfs server , from isilon. So VIP-01 could be any one of a group of IPs . I am trying to track down a network congestion issue and I cant find a way to match the output of lsof , and netstat to the output of mount -t nfs . Does anyone have any ideas how I could track this down , is there a way to run mount and have it show the IP and not the name of the source server ? Unfortunately, there's not a good answer to this question. nfsstat(1) should have a mode that can iterate down active mount points displaying statistics and connection information for each, but doesn't. NFS sockets generally don't appear in sockstat(1) either. However, they should appear in netstat(1), so you can at least identify the sockets open to various NFS server IP addresses (especially if they are TCP mounts). Enhancing nfsstat(1) to display more detailed information would, I think, be a very useful task for someone to get up to (and perhaps should appear on our ideas list). Something that would be nice to have, in support of this, is a way for file systems to provide extended status via a system call that queries mountpoints, both portable information that spans file systems, and file system-specific data. Morally, similar to nmount(2) but for statistics rather than setting things. The easier route is to add new sysctls that dump per-mountpoint state directly from NFS, but given how much other information we'd like to export, it would be great to have a more general mechanism. (The more adventurous can, with a fairly high degree of safety, use kgdb on /dev/mem (read-only) to walk the NFS stack's mount tables, but that's not much fun.) Robert ___ 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: Active slice, only for a next boot
On 2011-May-30 17:42:39 +, Dieter BSD dieter...@engineer.com wrote: A better approach is to be able to boot whatever slice you want without having to change the active slice. NetBSD can do this. The MBR puts up a menu of the bootable slices on the disk being booted. You can allow the timer to time out and boot the default. Or you can enter the number of the slice you want to boot. Or you can type a function key F1 F2 ... to boot a different disk, and it will load the MBR from that disk and run it. There is an alternative for keyboards without function keys. So can FreeBSD - though only for MBR - this functionality doesn't seem to have made it into the GPT bootcode. And it works great. Except that one of the 27 stages of boot code that FreeBSD uses INSISTS on booting the active slice, so you can tell the MBR to boot slice 3 and slice 3's boot code sees that slice 4 is active and boots slice 4. Multibooting worked correctly when I last used it (a few years ago). Have you raised this as a PR? RS-232 console + hardware modem + POTS = remote console And even that doesn't fully work unless you have a serial-aware BIOS. -- Peter Jeremy pgpuWO4m4fFPp.pgp Description: PGP signature
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Sat May 28 11, Bruce Cran wrote: On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote: well i'm not an expert on this. but are we 100% sure that a kernel on amd64 compiled with -O2 frename-registers can be debugged the same way as one with -O? if that is the case: sure...-O2 is fine. ;) however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-pointers, since removing frame pointers makes debugging impossible (on i386). With -O2 code is moved around and removed, so debugging is more difficult, but can still provide useful information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? -- Bruce Cran -- a13x ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 2011-05-31 11:57, Alexander Best wrote: ... however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-pointers, since removing frame pointers makes debugging impossible (on i386). With -O2 code is moved around and removed, so debugging is more difficult, but can still provide useful information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Dimitry Andric wrote: On 2011-05-31 11:57, Alexander Best wrote: ... however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-pointers, since removing frame pointers makes debugging impossible (on i386). With -O2 code is moved around and removed, so debugging is more difficult, but can still provide useful information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. *lol* we're moving in circles. so back to the beginning: why not use -O for all archs, if debugging was enabled? for amd64 -O2 is always set, no matter, if debugging is enabled or disabled. cheers. alex -- a13x ___ 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: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)
On Mon May 30 11, Dieter BSD wrote: Chris writes: Ports need attention. The warnings I get there are frightening. I find it comforting that they're just that: warnings. How do they frighten you? High quality code does not have any warnings. The most frightening thing is the attitute that They're just warnings, so I'll ignore them. Most compiler warnings should be fatal errors. And a lot of the warnings that require a -Wwhatever should be on by default. please keep in mind that -Wfoo does reflect the ideas of the GNU people regarding *proper* code. the warnings themselves are sometimes wrong, because they complain about perfectly correct code. so -Wfoo should not be considered a code verifier, but in fact what it is: a warning flag. sometimes it's correct and indeed reports wrong code, sometimes it is completely wrong. cheers. alex Code that doesn't compile cleanly often has other problems, like assuming that all CPUs are ILP32 little endian, like not checking return codes, etc. But hey, the next time the weather service issues a tornado warning, feel free to go outside and fly a kite. After all it's just a warning. a13x writes: -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc trunk and it's not in the gcc(1) manual. [1] http://gcc.gnu.org/wiki/Wcoercion And yet someone marked the bug fixed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 -- a13x ___ 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: [RFC] Enabling invariant TSC timecounter on SMP
on 24/05/2011 20:56 Jung-uk Kim said the following: I think it's about time to enable invariant TSC timecounter on SMP by default. Please see the attached patch. It is also available from here: http://people.freebsd.org/~jkim/tsc_smp_test4.diff avg convinced me enough that it should be an opt-out feature going forward. :-) Not sure if I really did that. My position is this: - if we think that TSC is SMP-safe then it should have the best priority - we should do our best to auto-guess if TSC is SMP-safe unless a user explicitly overrides that property (either via explicit testing or by making guesses based on CPU model or etc) Comments? Perhaps I missed it, but I don't remember the lowres part of the patch being discussed. -- 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
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On May 31, 2011, at 3:46 AM, Alexander Best arun...@freebsd.org wrote: On Tue May 31 11, Dimitry Andric wrote: On 2011-05-31 11:57, Alexander Best wrote: ... however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-pointers, since removing frame pointers makes debugging impossible (on i386). With -O2 code is moved around and removed, so debugging is more difficult, but can still provide useful information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. *lol* we're moving in circles. so back to the beginning: why not use -O for all archs, if debugging was enabled? for amd64 -O2 is always set, no matter, if debugging is enabled or disabled. I don't know, but I've run into cases where gcc has inlined or shuffled around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to use -O0 when DEBUG_FLAGS was defined. Thanks, -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: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)
On Tue, 31 May 2011, Alexander Best wrote: On Mon May 30 11, Dieter BSD wrote: Chris writes: Ports need attention. The warnings I get there are frightening. I find it comforting that they're just that: warnings. How do they frighten you? High quality code does not have any warnings. The most frightening thing is the attitute that They're just warnings, so I'll ignore them. Most compiler warnings should be fatal errors. And a lot of the warnings that require a -Wwhatever should be on by default. please keep in mind that -Wfoo does reflect the ideas of the GNU people regarding *proper* code. the warnings themselves are sometimes wrong, because they complain about perfectly correct code. so -Wfoo should not be considered a code verifier, but in fact what it is: a warning flag. sometimes it's correct and indeed reports wrong code, sometimes it is completely wrong. And, it's also worth remembering that warnings change over time, as the compiler changes. One of the known issues building with clang is that large quantities of warning-free code under gcc are in fact rife with warnings under clang, including the gcc source code itself. In general, my hope is that we can get the FreeBSD base warning-free for a useful set of warnings, and on the whole, this is the case. Pretty much the entire kernel is compiled with quite a large number of warning classes enabled, and -Werror set, for example. (One of the other tensions, of course, is the locally maintained vs externally maintained tension: fixing warnings in other people's code is useful only if you can get them to accept the fixes back -- maintaining large numbers of patch sets over time is not sustainable for non-trivial quantifies of code, if you're tracking the upstream vendor. Ports is the worst possible case, where maintaining local patches is quite expensive. In the FreeBSD base we can do a lot better, since we can use revision control and automatic merging to help us, but it's still an overhead that has to be reasoned about carefully.) Robert___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Garrett Cooper wrote: On May 31, 2011, at 3:46 AM, Alexander Best arun...@freebsd.org wrote: On Tue May 31 11, Dimitry Andric wrote: On 2011-05-31 11:57, Alexander Best wrote: ... however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-pointers, since removing frame pointers makes debugging impossible (on i386). With -O2 code is moved around and removed, so debugging is more difficult, but can still provide useful information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. *lol* we're moving in circles. so back to the beginning: why not use -O for all archs, if debugging was enabled? for amd64 -O2 is always set, no matter, if debugging is enabled or disabled. I don't know, but I've run into cases where gcc has inlined or shuffled around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to use -O0 when DEBUG_FLAGS was defined. ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't -fno-omit-frame-pointer be set uncondtitionally on all archs? just like -fno-strict-aliasing? cheers. alex Thanks, -Garrett -- a13x ___ 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: ndis driver presents the valid WiFi network as having the name 0x000000
On Friday, May 27, 2011 5:14:09 pm Yuri wrote: Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with Windows driver. This same card and driver work fine with pretty much any other network I tried. But this one particular network shows as 0x00 and I can't connect to it. Another FreeBSD desktop with native ath driver and apple both connect to it fine. What might be causing such weird behavior? Is this a known problem? Any way to troubleshoot this? I have this same problem. I've had to resort to using wpa_cli to 'select' my network at work that has this issue and then using 'ap_scan 2' to force wpa_supplicant to associate with it. You also will want ndis_events running if you need to do WPA authentication. -- John Baldwin ___ 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: Active slice, only for a next boot
On Monday, May 30, 2011 1:42:39 pm Dieter BSD wrote: And it works great. Except that one of the 27 stages of boot code that FreeBSD uses INSISTS on booting the active slice, so you can tell the MBR to boot slice 3 and slice 3's boot code sees that slice 4 is active and boots slice 4. There are only 3 stages, and boot1.S is what looks at the active slice. Unfortunately it doesn't have a better way to do this as the only input it gets from boot0 or any other MBR boot loader is the BIOS drive number in %dl. I'm not sure how else you would detect that a non-active slice was booted from when that is your only input. One could define some extended structure to pass that information and send it in a register, but you'd still have to cope with MBR boot loaders that don't pass it (e.g. the Windows ones if you are dual-booting with Windows) and you'd need to have some sanity checks to make sure one doesn't treat garbage input as valid. -- John Baldwin ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Alexander Best wrote:
On Tue May 31 11, Garrett Cooper wrote:
On May 31, 2011, at 3:46 AM, Alexander Best arun...@freebsd.org wrote:
On Tue May 31 11, Dimitry Andric wrote:
On 2011-05-31 11:57, Alexander Best wrote:
...
however i've often read messages - mostly by bruce evans - claiming
that
anything greater than -O will in fact decrease a kernel's ability to
be
debugged just as well as a kernel with -O.
The critical option when -O2 is used is -fno-omit-frame-pointers,
since
removing
frame pointers makes debugging impossible (on i386). With -O2 code is
moved around and
removed, so debugging is more difficult, but can still provide useful
information.
any reason we cannot use -O2 -fno-omit-frame-pointers
-fno-strict-aliasing
as
standard COPTFLAGS with debugging enabled for *all* archs?
Most likely, the performance gain from -O2 is rather small, except for
special cases, but the pain during debugging is increased a great deal.
Even if you add frame pointers, with -O2 large pieces of code can be
transformed, variables or even entire functions can be completely
eliminated, and so on, making debugging much more difficult.
*lol* we're moving in circles. so back to the beginning: why not use -O
for all archs, if debugging was enabled? for amd64 -O2 is always set, no
matter, if debugging is enabled or disabled.
I don't know, but I've run into cases where gcc has inlined or shuffled
around code on amd64 with -O2 -fno-strict-aliasing, so I changed my
make.conf to use -O0 when DEBUG_FLAGS was defined.
...which leads me to the conclusion that -O should be set when DEBUG was
defined: an all ARCHS.
right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the
kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior?
shouldn't
-fno-omit-frame-pointer be set uncondtitionally on all archs? just like
-fno-strict-aliasing?
so how about the following patch?
cheers.
alex
cheers.
alex
Thanks,
-Garrett
--
a13x
--
a13x
diff --git a/sys/conf/Makefile.amd64 b/sys/conf/Makefile.amd64
index 5096829..f70f3de 100644
--- a/sys/conf/Makefile.amd64
+++ b/sys/conf/Makefile.amd64
@@ -31,13 +31,6 @@ S= ../../..
.endif
.include $S/conf/kern.pre.mk
-DDB_ENABLED!= grep DDB opt_ddb.h || true
-DTR_ENABLED!= grep KDTRACE_FRAME opt_kdtrace.h || true
-HWPMC_ENABLED!=grep HWPMC opt_hwpmc_hooks.h || true
-.if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED)
-CFLAGS+= -fno-omit-frame-pointer
-.endif
-
MKMODULESENV+= MACHINE=amd64
.if ${CC:T:Mclang} == clang
diff --git a/sys/conf/Makefile.powerpc b/sys/conf/Makefile.powerpc
index e4cd85f..04bc66b 100644
--- a/sys/conf/Makefile.powerpc
+++ b/sys/conf/Makefile.powerpc
@@ -37,11 +37,6 @@ INCLUDES+= -I$S/contrib/libfdt
CFLAGS+= -msoft-float
-DDB_ENABLED!= grep DDB opt_ddb.h || true
-.if !empty(DDB_ENABLED)
-CFLAGS+= -fno-omit-frame-pointer
-.endif
-
%BEFORE_DEPEND
%OBJS
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index e9aa6e2..0314ada 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -24,26 +24,28 @@ OBJCOPY?= objcopy
SIZE?= size
.if defined(DEBUG)
-_MINUS_O= -O
+COPTFLAGS?=-O -pipe
CTFFLAGS+= -g
+.elif ${MACHINE_CPUARCH} == amd64 ${CC:T:Mclang} != clang
+COPTFLAGS?=-O2 -frename-registers -pipe
.else
-_MINUS_O= -O2
+COPTFLAGS?=-O2 -pipe
.endif
-.if ${MACHINE_CPUARCH} == amd64
-COPTFLAGS?=-O2 -frename-registers -pipe
-.else
-COPTFLAGS?=${_MINUS_O} -pipe
+
+.if !empty(COPTFLAGS:M-O[234sz]) empty(COPTFLAGS:M-fno-strict-aliasing)
+COPTFLAGS+=-fno-strict-aliasing
.endif
-.if !empty(COPTFLAGS:M-O[23s]) empty(COPTFLAGS:M-fno-strict-aliasing)
-COPTFLAGS+= -fno-strict-aliasing
+
+.if empty(COPTFLAGS:M-O0) empty(COPTFLAGS:M-fno-omit-frame-pointer)
+COPTFLAGS+=-fno-omit-frame-pointer
.endif
+
.if !defined(NO_CPU_COPTFLAGS)
-COPTFLAGS+= ${_CPUCFLAGS}
+COPTFLAGS+=${_CPUCFLAGS}
.endif
-C_DIALECT= -std=c99
-NOSTDINC= -nostdinc
-INCLUDES= ${NOSTDINC} ${INCLMAGIC} -I. -I$S
+C_DIALECT= -std=c99
+INCLUDES= -nostdinc ${INCLMAGIC} -I. -I$S
# This hack lets us use the OpenBSD altq code without spamming a new
# include path into contrib'ed source files.
@@ -146,8 +148,7 @@ SYSTEM_LD_TAIL= @${OBJCOPY} --strip-symbol gcc2_compiled.
${.TARGET} ; \
${SIZE} ${.TARGET} ; chmod 755 ${.TARGET}
SYSTEM_DEP+= ${LDSCRIPT}
-# MKMODULESENV is set here so that port makefiles can augment
-# them.
+# MKMODULESENV is set here so that port makefiles can augment them.
MKMODULESENV+= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR}
MKMODULESENV+= MACHINE_CPUARCH=${MACHINE_CPUARCH}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
Re: Include file search path
On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. Warner ___ 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: Mount_nfs question
Maybe you can use showmount -a SERVER-IP, foreach server you have... That might work. NFS doesn't actually have a notion of a mount, but the mount protocol daemon (typically called mountd) does try and keep track of NFSv3 mounts from the requests it sees. How well this works for NFSv3 will depend on how well the server keeps track of these things and how easily they are lost during a server reboot or similar. Since NFSv4 doesn't use the mount protocol, it will be useless for NFSv4. Thiago 2011/5/30 Mark Saad nones...@longcount.org: On Mon, May 30, 2011 at 8:13 PM, Rick Macklem rmack...@uoguelph.ca wrote: Hello All So I am stumped on this one. I want to know what the IP of each nfs server that is providing each nfs export. I am running 7.4-RELEASE When I run mount -t nfs I see something like this VIP-01:/export/source on /mnt/src VIP-02:/export/target on /mnt/target VIP-01:/export/logs on /mnt/logs VIP-02:/export/package on /mnt/pkg The issue is I use a load balanced nfs server , from isilon. So VIP-01 could be any one of a group of IPs . I am trying to track down a network congestion issue and I cant find a way to match the output of lsof , and netstat to the output of mount -t nfs . Does anyone have any ideas how I could track this down , is there a way to run mount and have it show the IP and not the name of the source server ? Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump doesn't know much about NFS, but if al you want are the IP#s, it'll do. But, no, mount won't tell you more than what the argument looked like. rick Wireshark seams like using a tank to swap a fly. Maybe, but watching traffic isn't that scary and over the years I've discovered things I would have never expected from doing it. Like a case where one specific TCP segment was being dropped by a network switch (it was a hardware problem in the switch that didn't manifest itself any other way). Or, that one client was generating a massive number of Getattr and Lookup RPCs. (That one turned out to be a grad student who had made themselves an app. that had a bunch of threads continually scanning to fs changes. Not a bad idea, but the threads never took a break and continually did it.) I've always found watching traffic kinda fun, but then I'm weird, rick ___ 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
/usr/share/calendar/calendar.british
Hi hack...@freebsd.org Britain had a national holiday yesterday. FreeBSD didn't notice as no /usr/share/calendar/calendar.british Other countries have their dates listed, so I wrote src/ http://www.freebsd.org/cgi/query-pr.cgi?pr=157466 If you'r British, or in Britain etc, please look at http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/calendars/calendar.british mail me additions/ corrections. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; indent with ; cumulative like a play script. Mail plain text format; Not quoted-printable, Not HTML, Not base 64. ___ 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: ndis driver presents the valid WiFi network as having the name 0x000000
On Tuesday 31 May 2011 16:29:15 John Baldwin wrote: On Friday, May 27, 2011 5:14:09 pm Yuri wrote: Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with Windows driver. This same card and driver work fine with pretty much any other network I tried. But this one particular network shows as 0x00 and I can't connect to it. Another FreeBSD desktop with native ath driver and apple both connect to it fine. What might be causing such weird behavior? Is this a known problem? Any way to troubleshoot this? I have this same problem. I've had to resort to using wpa_cli to 'select' my network at work that has this issue and then using 'ap_scan 2' to force wpa_supplicant to associate with it. You also will want ndis_events running if you need to do WPA authentication. Are you using -D bsd or -D ndis as the driver for wpa_supplicant? -- Bernhard ___ 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: ndis driver presents the valid WiFi network as having the name 0x000000
On Tuesday, May 31, 2011 12:36:43 pm Bernhard Schmidt wrote: On Tuesday 31 May 2011 16:29:15 John Baldwin wrote: On Friday, May 27, 2011 5:14:09 pm Yuri wrote: Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with Windows driver. This same card and driver work fine with pretty much any other network I tried. But this one particular network shows as 0x00 and I can't connect to it. Another FreeBSD desktop with native ath driver and apple both connect to it fine. What might be causing such weird behavior? Is this a known problem? Any way to troubleshoot this? I have this same problem. I've had to resort to using wpa_cli to 'select' my network at work that has this issue and then using 'ap_scan 2' to force wpa_supplicant to associate with it. You also will want ndis_events running if you need to do WPA authentication. Are you using -D bsd or -D ndis as the driver for wpa_supplicant? -- Bernhard -- John Baldwin ___ 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: ndis driver presents the valid WiFi network as having the name 0x000000
On Tuesday, May 31, 2011 12:36:43 pm Bernhard Schmidt wrote: On Tuesday 31 May 2011 16:29:15 John Baldwin wrote: On Friday, May 27, 2011 5:14:09 pm Yuri wrote: Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with Windows driver. This same card and driver work fine with pretty much any other network I tried. But this one particular network shows as 0x00 and I can't connect to it. Another FreeBSD desktop with native ath driver and apple both connect to it fine. What might be causing such weird behavior? Is this a known problem? Any way to troubleshoot this? I have this same problem. I've had to resort to using wpa_cli to 'select' my network at work that has this issue and then using 'ap_scan 2' to force wpa_supplicant to associate with it. You also will want ndis_events running if you need to do WPA authentication. Are you using -D bsd or -D ndis as the driver for wpa_supplicant? Whatever the defaults are (which would be -B ndis). -- John Baldwin ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 2011-05-31 16:39, Alexander Best wrote: ... ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't -fno-omit-frame-pointer be set uncondtitionally on all archs? No, not unconditionally on all archs. Some arches have no problem debugging when gcc's frame pointer is turned off, namely arm, ia64, mips, powerpc and sparc, if I read the source correctly. On these arches, even -O already sets -fomit-frame-pointer. So, for all arches, if DEBUG is enabled, we could just use -O (as default only, if the user wants to override this for whatever reason, it should be honoured). just like -fno-strict-aliasing? That should only be needed in combination with -O2, if that is the default optimization (e.g. if DEBUG is not enabled). IMHO this option should not be forced, if users specify their own CFLAGS/COPTFLAGS. Summarizing, I would suggest: - If DEBUG is enabled, use plain -O by default, on all arches - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all arches. ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 2011-05-31 17:26, Alexander Best wrote: ... so how about the following patch? Could you please try to not mix spacing and style changes with functional changes in this patch? It makes it more difficult to review. ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On May 31, 2011, at 11:45 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-05-31 17:26, Alexander Best wrote: ... so how about the following patch? Could you please try to not mix spacing and style changes with functional changes in this patch? It makes it more difficult to review. +1 ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 05/31/2011 07:39, Alexander Best wrote: ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. +1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Dimitry Andric wrote:
On 2011-05-31 16:39, Alexander Best wrote:
...
...which leads me to the conclusion that -O should be set when DEBUG was
defined: an all ARCHS.
right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the
kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior?
shouldn't
-fno-omit-frame-pointer be set uncondtitionally on all archs?
No, not unconditionally on all archs. Some arches have no problem
debugging when gcc's frame pointer is turned off, namely arm, ia64,
mips, powerpc and sparc, if I read the source correctly.
On these arches, even -O already sets -fomit-frame-pointer.
So, for all arches, if DEBUG is enabled, we could just use -O (as
default only, if the user wants to override this for whatever reason, it
should be honoured).
just like
-fno-strict-aliasing?
That should only be needed in combination with -O2, if that is the
default optimization (e.g. if DEBUG is not enabled). IMHO this option
should not be forced, if users specify their own CFLAGS/COPTFLAGS.
Summarizing, I would suggest:
- If DEBUG is enabled, use plain -O by default, on all arches
- If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all
arches.
thanks for your suggestions. i've incorporated them into the patch.
one thing i'm unsure is: what should be done when the user *doesn't* define
DEBUG, but has DDB, KDTRACE_FRAME or HWPMC in his kernel config?
the current behavior is to set -fno-omit-frame-pointer on amd64 and powerpc.
i think this behavior shouldn't be change. even though the user didn't specify
DEBUG, the fact that he has those kernel options indicates that he wants to do
some kind of debugging imho.
cheers.
alex
ps: sorry for the extra whitespace changes!
--
a13x
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index e9aa6e2..e6beda8 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -24,18 +24,12 @@ OBJCOPY?= objcopy
SIZE?= size
.if defined(DEBUG)
-_MINUS_O= -O
+COPTFLAGS?=-O -pipe
CTFFLAGS+= -g
+.elif ${MACHINE_CPUARCH} == amd64 ${CC:T:Mclang} != clang
+COPTFLAGS?=-O2 -fno-strict-aliasing -frename-registers -pipe
.else
-_MINUS_O= -O2
-.endif
-.if ${MACHINE_CPUARCH} == amd64
-COPTFLAGS?=-O2 -frename-registers -pipe
-.else
-COPTFLAGS?=${_MINUS_O} -pipe
-.endif
-.if !empty(COPTFLAGS:M-O[23s]) empty(COPTFLAGS:M-fno-strict-aliasing)
-COPTFLAGS+= -fno-strict-aliasing
+COPTFLAGS?=-O2 -fno-strict-aliasing -pipe
.endif
.if !defined(NO_CPU_COPTFLAGS)
COPTFLAGS+= ${_CPUCFLAGS}
___
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: [RFC] Enabling invariant TSC timecounter on SMP
On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: on 24/05/2011 20:56 Jung-uk Kim said the following: I think it's about time to enable invariant TSC timecounter on SMP by default. Please see the attached patch. It is also available from here: http://people.freebsd.org/~jkim/tsc_smp_test4.diff avg convinced me enough that it should be an opt-out feature going forward. :-) Not sure if I really did that. My position is this: - if we think that TSC is SMP-safe then it should have the best priority - we should do our best to auto-guess if TSC is SMP-safe unless a user explicitly overrides that property (either via explicit testing or by making guesses based on CPU model or etc) I am sorry if I misunderstood your intention. However, I added explicit boot-time TSC sanity check (to do our best to auto-guess) and I think TSC is fairly SMP-safe. Hence, I thought that it is about time for the change. Comments? Perhaps I missed it, but I don't remember the lowres part of the patch being discussed. No, it wasn't discussed with you. Do you see any problem with that code? Thanks, Jung-uk Kim ___ 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
sizeof(function pointer)
I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. Thanks, matthew ___ 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: sizeof(function pointer)
On May 31, 2011, at 5:07 PM, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. Warner___ 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: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)
please keep in mind that -Wfoo does reflect the ideas of the GNU people regarding *proper* code. the warnings themselves are sometimes wrong, because they complain about perfectly correct code. I attempted to get the gcc people to improve this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 Most of the warnings I see are either due to someone thinking all the world is ILP32 and doing things like storing a 64 bit pointer or long in a 32 bit int, or due to the compiler needing more info to insure that they are not trying to stuff 64 bits into 32, such as missing prototypes. Either way it needs to be fixed. In many cases the developers that claim to write such great code, and claim that the compiler warnings don't matter are the ones whose code has the most bugs (seg faults, floating point exceptions, ...). Pretty much the entire kernel is compiled with quite a large number of warning classes enabled, and -Werror set, for example. Whoever did this, THANK YOU!!! fixing warnings in other people's code is useful only if you can get them to accept the fixes back Fixing bugs is always useful. Certainly it is a *lot* more efficient if you can get them fixed at the source rather than having to maintain patches. ___ 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: Active slice, only for a next boot
Peter writes: A better approach is to be able to boot whatever slice you want without having to change the active slice. NetBSD can do this. The MBR puts up a menu of the bootable slices on the disk being booted. You can allow the timer to time out and boot the default. Or you can enter the number of the slice you want to boot. Or you can type a function key F1 F2 ... to boot a different disk, and it will load the MBR from that disk and run it. There is an alternative for keyboards without function keys. So can FreeBSD - though only for MBR If so, the documentation could use improvement. Examples would be great. - this functionality doesn't seem to have made it into the GPT bootcode. Is anyone working on this? MBR is only good for 2 TB and the 3 TB disks are becoming cost competitive. I've switched over to GPT for everything except boot disks, as it is less brain damaged than MBR. And it works great. Except that one of the 27 stages of boot code that FreeBSD uses INSISTS on booting the active slice, so you can tell the MBR to boot slice 3 and slice 3's boot code sees that slice 4 is active and boots slice 4. Multibooting worked correctly when I last used it (a few years ago). Have you raised this as a PR? No, partly because I haven't had much luck with PRs. Mainly because I'd rather spend my time trying to migrate to GPT than improving MBR. So many bugs/misfeatures so little time, RS-232 console + hardware modem + POTS = remote console And even that doesn't fully work unless you have a serial-aware BIOS. Real computers have RS-232 consoles. If you neglected to specify RS-232 console in the requirements, there is this thing. I haven't tried it. http://www.realweasel.com/ Somebody probably sells a KVM-over-IP box. You could see if openbios supports your mainboard. John writes: And it works great. Except that one of the 27 stages of boot code that FreeBSD uses INSISTS on booting the active slice, so you can tell the MBR to boot slice 3 and slice 3's boot code sees that slice 4 is active and boots slice 4. There are only 3 stages, It feels like more. :-) and boot1.S is what looks at the active slice. Unfortunately it doesn't have a better way to do this as the only input it gets from boot0 or any other MBR boot loader is the BIOS drive number in %dl. I'm not sure how else you would detect that a non-active slice was booted from when that is your only input. The NetBSD boot code manages to do it. ___ 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: sizeof(function pointer)
On Tue, 31 May 2011 17:18:16 -0600 Warner Losh i...@bsdimp.com wrote: On May 31, 2011, at 5:07 PM, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. Not so on ia64, where they have special function descriptor type. -- Alexander Kabaev signature.asc Description: PGP signature
Re: sizeof(function pointer)
On 05/31/11 18:18, Warner Losh wrote: On May 31, 2011, at 5:07 PM, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. It is also true on ARM, PPC, PPC64, and ia64, which I just tested. I think you're safe. -Nathan ___ 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: sizeof(function pointer)
On 05/31/11 19:06, Alexander Kabaev wrote: On Tue, 31 May 2011 17:18:16 -0600 Warner Loshi...@bsdimp.com wrote: On May 31, 2011, at 5:07 PM, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. Not so on ia64, where they have special function descriptor type. As is also true on PPC64 and (I think) at least some MIPS. But on all of these, a function pointer is a regular data pointer to the function descriptor, which then points to the function, so they are still the same size as a void *. -Nathan ___ 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: Active slice, only for a next boot
Dieter BSD dieter...@engineer.com wrote: If you neglected to specify RS-232 console in the requirements, there is this thing. ??I haven't tried it. http://www.realweasel.com/ Heard of it, aka the PC Weasel. I've never actually seen one. They have been around for a while; the original -- which they apparently still make -- was ISA. Somebody probably sells a KVM-over-IP box. Raritan, at least. Probably others also. Unfortunately it doesn't have a better way to do this as the only input it gets from boot0 or any other MBR boot loader is the BIOS drive number in %dl. I'm not sure how else you would detect that a non-active slice was booted from when that is your only input. The NetBSD boot code manages to do it. Dunno how NetBSD does it, but one approach that comes to mind would be for whatever installs boot1 to set one of its bytes to the slice number in which it is installed. ___ 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: sizeof(function pointer)
On May 31, 2011, at 5:06 PM, Alexander Kabaev wrote: Usually it is different only on segmented architectures like 16-bit x86. Not so on ia64, where they have special function descriptor type. Actually, no. On ia64 a function pointer has the same size as a data pointer. It's just that a function pointer does not point to the actual function (i.e. the first instruction of a function), but to a function descriptor. The function descriptor contains the address of the actual function and the value of the GP register that needs to be set before entering the function. As such, only virtual functions in C++ are impacted by this. The function descriptor needs to be stored in the object instead of the function pointer in that case. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ 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: [RFC] Enabling invariant TSC timecounter on SMP
on 31/05/2011 23:16 Jung-uk Kim said the following: On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: on 24/05/2011 20:56 Jung-uk Kim said the following: I think it's about time to enable invariant TSC timecounter on SMP by default. Please see the attached patch. It is also available from here: http://people.freebsd.org/~jkim/tsc_smp_test4.diff avg convinced me enough that it should be an opt-out feature going forward. :-) Not sure if I really did that. My position is this: - if we think that TSC is SMP-safe then it should have the best priority - we should do our best to auto-guess if TSC is SMP-safe unless a user explicitly overrides that property (either via explicit testing or by making guesses based on CPU model or etc) I am sorry if I misunderstood your intention. However, I added explicit boot-time TSC sanity check (to do our best to auto-guess) and I think TSC is fairly SMP-safe. Hence, I thought that it is about time for the change. In this case - yes. But I remember that you were thinking about either improving or simplifying that check or both. Comments? Perhaps I missed it, but I don't remember the lowres part of the patch being discussed. No, it wasn't discussed with you. Do you see any problem with that code? I don't see any obvious problem, but I also don't understand rationale of using smaller max_freq for the ncpus 1 case. Maybe these two logical changes should be done as two separate commits. -- 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
