Re: samba+zfs
Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay=5 accf_data_load=YES aio_load=YES zfs_load=YES kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size=1844M vfs.zfs.arc_min=1024M vfs.zfs.arc_max=1536M vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable=1 ahci_load=YES asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = Primary backups interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = Primary backups path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916 kern.maxfilesperproc=204916 #raise sockets we can accept kern.ipc.somaxconn=32768 #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations net.inet.icmp.icmplim=500 kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=229376 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 #also add following to /boot/loader.conf #vm.kmem_size=1844M #kern.maxbcache=64M #kern.ipc.maxpipekva=4M #default setting of net.inet.ip.portrange.first is to low, causing us problems with bind net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #DOS protection net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=50 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 #some stuff for samba kern.ipc.nmbclusters=32768 kern.maxvnodes=80 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=524288 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65535 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.tcp.mssdflt=1460 #IPSEC net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules #NFS--not concerned with data
Re: samba+zfs
Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: asterisk:~# uname -a FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 19:46:53 CDT 2011 dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 asterisk:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Dan The Man wrote: Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay=5 accf_data_load=YES aio_load=YES zfs_load=YES kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size=1844M vfs.zfs.arc_min=1024M vfs.zfs.arc_max=1536M vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable=1 ahci_load=YES asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = Primary backups interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = Primary backups path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916 kern.maxfilesperproc=204916 #raise sockets we can accept kern.ipc.somaxconn=32768 #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations net.inet.icmp.icmplim=500 kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=229376 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 #also add following to /boot/loader.conf #vm.kmem_size=1844M #kern.maxbcache=64M #kern.ipc.maxpipekva=4M #default setting of net.inet.ip.portrange.first is to low, causing us problems with bind net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #DOS protection net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=50 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 #some stuff for samba kern.ipc.nmbclusters=32768 kern.maxvnodes=80 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0
Proftpd + Freebsd 9 + mod_mysql
Not sure if anyone else is having problem with proftpd on freebsd 9, but here is a patch to stop it terminating, should be included in next release, courtesy of TJ saunders working with me on it. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com freebsd-mysql-signal.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD Status Report July-September, 2011
FreeBSD Quarterly Status Report - Q3/2011 Introduction This report covers FreeBSD-related projects between July and September 2011. It is the third of the four reports planned for 2011. This quarter was mainly devoted to polishing the bits for the next major version of FreeBSD, 9.0, which is to be released by then end of this year. Thanks to all the reporters for the excellent work! This report contains 28 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between October and December 2011 is January 15th, 2012. __ Projects * GELI status update * HAST (Highly Available Storage) status update * pfSense * Tool for providing FreeBSD VM Images * ZFSguru * ZRouter.org project -- a FreeBSD-based firmware for embedded devices FreeBSD Team Reports * Ports Collection * The FreeBSD Foundation * The FreeBSD Release Engineering Team Network Infrastructure * 802.11n / atheros * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * Ethernet Switch Framework Kernel * The new CARP * VM layer for allocations larger than a page Documentation * Doc sprint on IRC, September 5, 2011 * The FreeBSD German Documentation Project Status Report * The FreeBSD Greek Documentation Project * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on Marvell Armada XP * FreeBSD/powerpc on AppliedMicro APM86290 Ports * FreeBSD Haskell Ports * KDE-FreeBSD * OpenAFS port * Portmaster Miscellaneous * bsd_day(2011) * EuroBSDcon 2011 * FreeBSD Developer Summit, Maarssen Google Summer of Code * Multibyte Encoding Support in Nvi __ 802.11n / atheros URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosTxAgg Contact: Adrian Chadd adr...@freebsd.org AR5416, AR9160, and AR9280 functions in both station and hostap mode. Performance is good. Software retry of frames is implemented. Aggregation is implemented. BAR TX is not yet handled. HT protection is not implemented; neither is MIMO powersave. Open tasks: 1. BAR TX 2. MIMO powersave 3. Correct handling of flushing TX queues during interface reset/reconfigure 4. Correct handling of 20-20/40mhz transitions (without dropping frames) 5. More intelligent rate control __ bsd_day(2011) URL: http://bsdday.eu/2011 Contact: Martin Matuska m...@freebsd.org Contact: Gabor Pali p...@freebsd.org The purpose of this one-day event was to gather Central European developers of today's open-source BSD systems to popularize their work and their organizations, and to meet each other in the real life. We wanted to motivate potential future developers and users, especially undergraduate university students, to work with BSD systems. This year's BSD-Day was be held in Bratislava, Slovakia at Slovak University of Technology, Faculty of Electrical Engineering and Information Technology on November 5, 2011. __ DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) URL: http://caia.swin.edu.au/freebsd/diffused/ URL: http://www.FreeBSDFoundation.org/project%20announcements.shtml#diffuse URL: http://caia.swin.edu.au/urp/diffuse/ URL: http://caia.swin.edu.au/urp/diffuse/downloads.html Contact: Sebastian Zander szan...@swin.edu.au Contact: Lawrence Stewart szan...@swin.edu.au Contact: Grenville Armitage garmit...@swin.edu.au DIFFUSE enables FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) to classify flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc.) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. The FreeBSD Foundation has funded the Centre for Advanced Internet
/sys/amd64/conf/DEFAULTS
Sorry for the boring question, but is the default configuration file /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration file for the kernel while building the kernel? I looked for include statements in GENERIC, but didn't find one. I use custom kernel config files and adapt most changes from the NOTES files in the sources tree. With the today's update of README in /sys/amd64/conf I realised some important changes, so this triggered my question. I simply made an additional include in the custom config file, but if this isn't necessary, I'll delete it again. And I'm interested in how the kernel is built from. It is a very convenient way to type simply make kerne in /usr/src/, but it vanishes to much of the complexity and understanding how the system builds and could cause problems. Thanks for your patience and tahnks in advance, Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf
2011/11/8 Attilio Rao atti...@freebsd.org: Author: attilio Date: Tue Nov 8 10:18:07 2011 New Revision: 227333 URL: http://svn.freebsd.org/changeset/base/227333 Log: Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default on all the architectures. The option allows to mount non-MPSAFE filesystem. Without it, the kernel will refuse to mount a non-MPSAFE filesytem. This patch is part of the effort of killing non-MPSAFE filesystems from the tree. This is just a gentle reminder in order to point you further to the official page: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS and encourage once again people in adopting a dying FS if it really matters to them. So far, unfortunately, I didn't see a lot of activity in this area but I hope that this would change soon. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
On 11/08/11 12:36, O. Hartmann wrote: Sorry for the boring question, but is the default configuration file /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration file for the kernel while building the kernel? I looked for include statements in GENERIC, but didn't find one. I use custom kernel config files and adapt most changes from the NOTES files in the sources tree. With the today's update of README in /sys/amd64/conf I realised some important changes, so this triggered my question. I simply made an additional include in the custom config file, but if this isn't necessary, I'll delete it again. And I'm interested in how the kernel is built from. It is a very convenient way to type simply make kerne in /usr/src/, but it vanishes to much of the complexity and understanding how the system builds and could cause problems. Thanks for your patience and tahnks in advance, Regards, Oliver From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! -- Niclas Zeising ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
Am 11/08/11 14:12, schrieb Niclas Zeising: On 11/08/11 12:36, O. Hartmann wrote: Sorry for the boring question, but is the default configuration file /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration file for the kernel while building the kernel? I looked for include statements in GENERIC, but didn't find one. I use custom kernel config files and adapt most changes from the NOTES files in the sources tree. With the today's update of README in /sys/amd64/conf I realised some important changes, so this triggered my question. I simply made an additional include in the custom config file, but if this isn't necessary, I'll delete it again. And I'm interested in how the kernel is built from. It is a very convenient way to type simply make kerne in /usr/src/, but it vanishes to much of the complexity and understanding how the system builds and could cause problems. Thanks for your patience and tahnks in advance, Regards, Oliver From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! Thank you very much. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose ambrose...@gmail.com wrote:
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
I have committed this as r227342. Thanks for the fix.
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
Yes, I can take a look.
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
Offhand, no. I'll try to find some time to look at your PRs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features)
I have improved the jail etc script significantly (in addition to ZFS
support and other improvements).
- you can now set a jail_name= parameter to set the name for your jail
- the jails are still searched by name, so you cannot manage the jail
with the script if name in /etc/rc.conf changes while running.
- the status subcommand now also shows the number of running
processes, this way you can identify an empty jail
- there are also two new subcommands - create and remove, intended
for persistent jail operation
- if a jail is set to persistent, you can do the following sequence:
create start stop remove.
- non-persistent jails may also be created (won't be started) but will
be removed on a stop
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch
On 31. 7. 2011 0:32, Jamie Gritton wrote:
Yes, that looks good. It keeps what I'd call expected behavior for
persist (at least on the startup side).
- Jamie
On 07/29/11 14:53, Martin Matuska wrote:
So what do you think about this updated patch (attached)?
Here we leave everything possible for jail_example_params.
Btw. you can also set jid=xxx in params to have a static jail id for
this jail.
Also stopping a persistent jail doesn't delete it (but you cannot start
it again).
Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napísal(a):
Yes, it was intentional to move away from the global sysctls and to
the per-jail parameters instead. It makes more sense once config
files come into play, which can do a better job of providing global
defaults as well as per-jail parameters.
The connection between ZFS and persist makes sense. So for ZFS-based
jail you'd want to set (and then reset) persist. For others, this
could be left to the user. The changes to jail(8) for config files
also sets persist when creating jails, and then clears it at a later
stage unless the user specifies to keep it set. It looks like I might
want to add some ZFS support to the new jail(8).
I would prefer to keep things simpler regarding create/start and
remove/stop, and keep them tied together.
- Jamie
On 07/28/11 12:00, Martin Matuska wrote:
If you start jail(8) witth -c (the new param way,) the values
of the
actual security.jail. variables are not initialized inside the jail,
default values are used instead. I don't know if this is intentional,
but probably yes. Default enforce_statfs=2, allow.mount=0.
As of me we can leave everything for ${_params}, but then ${_zfs}
makes
sense only if enforce_statfs2 and allow.mount=1.
Regarding zfs, if you want to operate zfs from the very start of a
jail
(and e.g. make use of /etc/rc.d/zfs which has jail support), you
have to
pair datasets with an existing jail. In simple words, you have to
create
a process-less jail (persist=1), attach zfs datasets and then run the
command. The persist option can be made optional - but we always start
with persist=1, then we can set (or not) persist=0 depending on user
setting.
The question that opens, should we remove a persisting jail on stop?
Or should we support new commands create and remove in addition to
start and stop? Create would just make a processless jail, remove
would wipe out a jail and start/stop would just deal with the
processes
(if persist=0 the old way, of course)?
Cheers,
mm
Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napísal(a):
Since I missed the 9.0 boat with jail config file capability,
something
like this seems necessary; rc.d/jail has long been unable to
handle the
full scale of what jail(8) can do.
I gather that setting persist is necessary for the ZFS operation. As
long as we're making the parameter setting more generic from rc, we
should handle the case where persist is specified in ${_params}, and
not
always set/reset it around the jail creation unless ZFS is used.
Also, why the specific inclusion of the security-related parameters?
They could just be folded into ${_params}, and if left unspecified
then
jail(8) should by default do the right thing.
- Jamie
On 07/28/11 08:11, Martin Matuska wrote:
The attached patch allows better fine-tuning of jails started via
/etc/rc.d, uses the new jail(8) flags (-c -m), the persist
parameter and
adds ZFS support.
Patch is fully backward compatible.
Please review, comment and/or test my attached patch.
Cheers,
mm
--
Martin Matuska
FreeBSD committer
http://blog.vx.sk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features)
I've been waiting for 9.0 to get fully released before I started in with
the new conf-based jail(8). While this patch has a bunch of good stuff,
some of it goes at cross purposes with the new jail program. I haven't
worked at all on the rc script part of things, so I think I'd want to
use a lot of this, but I want to make it all fit together. So how about
sitting on it for a while longer until it can be part of a unified effort?
- Jamie
On 11/08/11 08:49, Martin Matuska wrote:
I have improved the jail etc script significantly (in addition to ZFS
support and other improvements).
- you can now set a jail_name= parameter to set the name for your jail
- the jails are still searched by name, so you cannot manage the jail
with the script if name in /etc/rc.conf changes while running.
- the status subcommand now also shows the number of running
processes, this way you can identify an empty jail
- there are also two new subcommands - create and remove, intended
for persistent jail operation
- if a jail is set to persistent, you can do the following sequence:
create start stop remove.
- non-persistent jails may also be created (won't be started) but will
be removed on a stop
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch
On 31. 7. 2011 0:32, Jamie Gritton wrote:
Yes, that looks good. It keeps what I'd call expected behavior for
persist (at least on the startup side).
- Jamie
On 07/29/11 14:53, Martin Matuska wrote:
So what do you think about this updated patch (attached)?
Here we leave everything possible for jail_example_params.
Btw. you can also set jid=xxx in params to have a static jail id for
this jail.
Also stopping a persistent jail doesn't delete it (but you cannot start
it again).
Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napísal(a):
Yes, it was intentional to move away from the global sysctls and to
the per-jail parameters instead. It makes more sense once config
files come into play, which can do a better job of providing global
defaults as well as per-jail parameters.
The connection between ZFS and persist makes sense. So for ZFS-based
jail you'd want to set (and then reset) persist. For others, this
could be left to the user. The changes to jail(8) for config files
also sets persist when creating jails, and then clears it at a later
stage unless the user specifies to keep it set. It looks like I might
want to add some ZFS support to the new jail(8).
I would prefer to keep things simpler regarding create/start and
remove/stop, and keep them tied together.
- Jamie
On 07/28/11 12:00, Martin Matuska wrote:
If you start jail(8) witth -c (the new param way,) the values
of the
actual security.jail. variables are not initialized inside the jail,
default values are used instead. I don't know if this is intentional,
but probably yes. Default enforce_statfs=2, allow.mount=0.
As of me we can leave everything for ${_params}, but then ${_zfs}
makes
sense only if enforce_statfs2 and allow.mount=1.
Regarding zfs, if you want to operate zfs from the very start of a
jail
(and e.g. make use of /etc/rc.d/zfs which has jail support), you
have to
pair datasets with an existing jail. In simple words, you have to
create
a process-less jail (persist=1), attach zfs datasets and then run the
command. The persist option can be made optional - but we always start
with persist=1, then we can set (or not) persist=0 depending on user
setting.
The question that opens, should we remove a persisting jail on stop?
Or should we support new commands create and remove in addition to
start and stop? Create would just make a processless jail, remove
would wipe out a jail and start/stop would just deal with the
processes
(if persist=0 the old way, of course)?
Cheers,
mm
Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napísal(a):
Since I missed the 9.0 boat with jail config file capability,
something
like this seems necessary; rc.d/jail has long been unable to
handle the
full scale of what jail(8) can do.
I gather that setting persist is necessary for the ZFS operation. As
long as we're making the parameter setting more generic from rc, we
should handle the case where persist is specified in ${_params}, and
not
always set/reset it around the jail creation unless ZFS is used.
Also, why the specific inclusion of the security-related parameters?
They could just be folded into ${_params}, and if left unspecified
then
jail(8) should by default do the right thing.
- Jamie
On 07/28/11 08:11, Martin Matuska wrote:
The attached patch allows better fine-tuning of jails started via
/etc/rc.d, uses the new jail(8) flags (-c -m), the persist
parameter and
adds ZFS support.
Patch is fully backward compatible.
Please review, comment and/or test my attached patch.
Cheers,
mm
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
Re: /sys/amd64/conf/DEFAULTS
Am 11/08/11 14:31, schrieb Chuck Burns: On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck Hello. well, I'm aware of that, but it doesn't matter. As long as I do not use a broken or commented out module, it is all right. I was a little bit surprised having options already set I never set in the usual config file named after the host's name or GENERIC. And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
On Tue, Nov 8, 2011 at 3:52 PM, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Am 11/08/11 14:31, schrieb Chuck Burns: And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. That will be removed. see http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS -- Gianni ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
On Nov 8, 2011, at 7:52 AM, O. Hartmann wrote: Am 11/08/11 14:31, schrieb Chuck Burns: On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck Hello. well, I'm aware of that, but it doesn't matter. As long as I do not use a broken or commented out module, it is all right. I was a little bit surprised having options already set I never set in the usual config file named after the host's name or GENERIC. And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. I've never liked that DEFAULTS is magically invisible. I know that the intention was to keep users from shooting their feet off by accidentally excluding it from their configs, but I think it creates more confusion that it solves. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi,
On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe lacom...@gmail.com wrote:
On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao atti...@freebsd.org wrote:
2011/11/7 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov kostik...@gmail.com
wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
Well, unfortunately, I wasn't around to comment 10 years ago when this got in.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
Yes, and that's not an excuse to use the _internal_ implementation
details of mutex(9), and not the exposed API. This is especially true
when applied to someone so eager to follow standards.
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
You comment just as if __FILE__ and __LINE__ were mandatory in a debug
interface. This is _not_ true. __FILE__ and __LINE__ are just hideous
for debugging of anything but early alpha code. LOCK_FILE and
LOCK_LINE are a bad answer to a bad interface. Even if you just pass
NULL and 0 as argument, you've got the bloat of passing unused
argument. You might as well just pass a single argument that would do
the exact same job and be _always_ available, eg. the IP of the
caller, or the first return address. KDB magic still let you translate
to something humanly understandable. If the toolchain does not support
the feature on all supported platform, well, fix the toolchain.
To avoid future complaints about the fact that I would be only talk
without action, I did implement what I suggested above. As it is
quite a large patch-set, I will not post it directly here, however, it
is available on github:
Re: Fresh installed Freebsd 9 don't boot from hd
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able to
figure it out with some basic instructions. I'm currently running a fresh RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode, rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS: invalid zap_type=134218628
I've got following error after upgrading my 9.0-RC1 to RC2 using source and got this error at loader prompt: ZFS: invalid zap_type=134218628 when I tried zfsboottest from 9.0-STABLE it failed ./zfsboottest /boot/kernel/kernel /dev/ada0p4 returns pool status correctly but ends with the same message zfsboottest from 10.0-CURRENT returns pool status, zfsboottest.sh zroot printed OK message at the end (very useful zfsboottest.sh wasn't yet merged from current to stable). I've installed gptzfsboot, zfsloader, loader from -CURRENT and it boots fine. I'm running ZFS on GPT partitions, zfs version 28 with dedup on. File system can be successfully mount using FreeBSD memstick. I think that patches for boot should be merged to 9.0-RELEASE otherwise users may have the same problems I had. best regards, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote:
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
Sorry, haven't been able to merge them to 9 yet.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able
to
figure it out with some basic instructions. I'm currently running a fresh
RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode,
rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
On 11/08/2011 09:33, Scott Long wrote: On Nov 8, 2011, at 7:52 AM, O. Hartmann wrote: Am 11/08/11 14:31, schrieb Chuck Burns: On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck Hello. well, I'm aware of that, but it doesn't matter. As long as I do not use a broken or commented out module, it is all right. I was a little bit surprised having options already set I never set in the usual config file named after the host's name or GENERIC. And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. I've never liked that DEFAULTS is magically invisible. I know that the intention was to keep users from shooting their feet off by accidentally excluding it from their configs, but I think it creates more confusion that it solves. +1 on both counts -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
2011/11/8 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe lacom...@gmail.com wrote:
On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao atti...@freebsd.org wrote:
2011/11/7 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov kostik...@gmail.com
wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
Well, unfortunately, I wasn't around to comment 10 years ago when this got
in.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
Yes, and that's not an excuse to use the _internal_ implementation
details of mutex(9), and not the exposed API. This is especially true
when applied to someone so eager to follow standards.
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
You comment just as if __FILE__ and __LINE__ were mandatory in a debug
interface. This is _not_ true. __FILE__ and __LINE__ are just hideous
for debugging of anything but early alpha code. LOCK_FILE and
LOCK_LINE are a bad answer to a bad interface. Even if you just pass
NULL and 0 as argument, you've got the bloat of passing unused
argument. You might as well just pass a single argument that would do
the exact same job and be _always_ available, eg. the IP of the
caller, or the first return address. KDB magic still let you translate
to something humanly understandable. If the toolchain does not support
the feature on all supported platform, well, fix the toolchain.
To avoid future complaints about the fact that I would be only talk
without action, I did implement what I suggested above. As it is
quite a large patch-set, I will not post it
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-11-08 19:39:19 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-08 19:39:19 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-08 19:39:19 - cleaning the object tree TB --- 2011-11-08 19:39:34 - cvsupping the source tree TB --- 2011-11-08 19:39:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-08 19:40:20 - building world TB --- 2011-11-08 19:40:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 19:40:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 19:40:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 19:40:20 - SRCCONF=/dev/null TB --- 2011-11-08 19:40:20 - TARGET=sparc64 TB --- 2011-11-08 19:40:20 - TARGET_ARCH=sparc64 TB --- 2011-11-08 19:40:20 - TZ=UTC TB --- 2011-11-08 19:40:20 - __MAKE_CONF=/dev/null TB --- 2011-11-08 19:40:20 - cd /src TB --- 2011-11-08 19:40:20 - /usr/bin/make -B buildworld World build started on Tue Nov 8 19:40:20 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Nov 8 20:37:28 UTC 2011 TB --- 2011-11-08 20:37:28 - generating LINT kernel config TB --- 2011-11-08 20:37:28 - cd /src/sys/sparc64/conf TB --- 2011-11-08 20:37:28 - /usr/bin/make -B LINT TB --- 2011-11-08 20:37:29 - cd /src/sys/sparc64/conf TB --- 2011-11-08 20:37:29 - /usr/sbin/config -m GENERIC TB --- 2011-11-08 20:37:29 - building GENERIC kernel TB --- 2011-11-08 20:37:29 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 20:37:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 20:37:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 20:37:29 - SRCCONF=/dev/null TB --- 2011-11-08 20:37:29 - TARGET=sparc64 TB --- 2011-11-08 20:37:29 - TARGET_ARCH=sparc64 TB --- 2011-11-08 20:37:29 - TZ=UTC TB --- 2011-11-08 20:37:29 - __MAKE_CONF=/dev/null TB --- 2011-11-08 20:37:29 - cd /src TB --- 2011-11-08 20:37:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Nov 8 20:37:29 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_pci.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1653: error: 'ATH_AGGR_MIN_QDEPTH' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1653: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1653: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1654: error: 'ATH_AGGR_SCHED_LOW' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1655: error: 'ATH_AGGR_SCHED_HIGH' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-08 20:40:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-08 20:40:01 - ERROR: failed to build GENERIC kernel TB --- 2011-11-08 20:40:01 - 2883.29 user 681.07 system 3642.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couple of sched_ule issues
on 03/11/2011 22:17 Jeff Roberson said the following: On Thu, 15 Sep 2011, Andriy Gapon wrote: This is more of a just for the record email. I think I've already stated the following observations, but I suspect that they drowned in the noise of a thread in which I mentioned them. 1. Incorrect topology is built for single-package SMP systems. That topology has two levels (shared nothing and shared package) with exactly the same CPU sets. That doesn't work well with the rebalancing algorithm which assumes that each level is a proper/strict subset of its parent. 2. CPU load comparison algorithms are biased towards lower logical CPU IDs. With all other things being equal the algorithms will always pick a CPU with a lower ID. This creates certain load asymmetry and predictable patterns in load distribution. If all other things truly are equal why does selecting a lower cpu number matter? Honestly, I am not sure. This bias could definitely produce an inequality from the point of view of how many threads each CPU gets. But I can not say if there could be any inequality in how much CPU time each thread gets. But I don't rule out that that might be possible... Please also see this post of mine: http://thread.gmane.org/gmane.os.freebsd.current/133763/focus=134192 Another observation. It seems that ULE makes a decision about thread-to-CPU affinity at the time when a thread gets switched out. This looks logical from the implementation point of view. But it doesn't seem logical from a general point of view - when the thread will be becoming running again its affinity profile may become completely different. I think that it would depend on how much a thread actually spends not running. The decision is made at sched_add() time. sched_pickcpu() does the work and selects the run-queue we will be added to. We consider the CPU that the thread was last running on but the decision is made at the time that a run queue must be selected. Ah, yes. But, OTOH, it doesn't look like sched_add would be called for a CPU-bound thread (no voluntary sleeps) ? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
[cc list trimmed] on 08/11/2011 22:34 Attilio Rao said the following: 2011/11/8 Arnaud Lacombe lacom...@gmail.com: To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: I really think that this is way too dependent by the good health of your tool, thus that is highly fragile. However, you may have more luck by just the core of your kernel changes here, for comment and leave alone all the (ptr - LOCK_FILE/LOCK_LINE conversion). Said that, I think this logic is too fragile and likely won't be as effective as __FILE__/__LINE__ in many cases. I agree. If we were able to somehow automatically, magically, easily and correctly determine an instruction pointer of a caller, then it would make sense to ditch explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction pointer decoding. But if we are just replacing explicit passing of (well-known) macros __FILE__/__LINE__ with explicit passing of THIS_IP, then I don't see a point. Apologies if I missed the rationale for this change. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features)
Martin Matuska wrote: I have improved the jail etc script significantly (in addition to ZFS support and other improvements). - you can now set a jail_name= parameter to set the name for your jail - the jails are still searched by name, so you cannot manage the jail with the script if name in /etc/rc.conf changes while running. - the status subcommand now also shows the number of running processes, this way you can identify an empty jail - there are also two new subcommands - create and remove, intended for persistent jail operation - if a jail is set to persistent, you can do the following sequence: create start stop remove. - non-persistent jails may also be created (won't be started) but will be removed on a stop http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch Just a note - there were many attempts to add jail_myjail_name=myjail variable to rc.conf but it was always denied with same answer: There is no reason for it, it can be done by jail_myjail_flags= -n myjail See this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/150599 and freebsd-jail@ archive. Maybe it will change in jail v2 land or jail config by Jamie... Miroslav Lachman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: samba+zfs
On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man d...@sunsaturn.com wrote: Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: asterisk:~# uname -a FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 19:46:53 CDT 2011 dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 asterisk:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Dan The Man wrote: Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay=5 accf_data_load=YES aio_load=YES zfs_load=YES kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size=1844M vfs.zfs.arc_min=1024M vfs.zfs.arc_max=1536M vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable=1 ahci_load=YES asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = Primary backups interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = Primary backups path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916 kern.maxfilesperproc=204916 #raise sockets we can accept kern.ipc.somaxconn=32768 #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations net.inet.icmp.icmplim=500 kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=229376 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 #also add following to /boot/loader.conf #vm.kmem_size=1844M #kern.maxbcache=64M #kern.ipc.maxpipekva=4M #default setting of net.inet.ip.portrange.first is to low, causing us problems with bind net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #DOS protection net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=50 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 #some stuff for samba
/etc/group chkgrp invalid character @
With libnss-mysql we are able to login using email addresses etc. In the daily cron Daily run output email always get the following: Verifying group file syntax: chkgrp: /etc/group: line 3: '@' invalid character Could we modify system to support email addresses as usernames. From my testing it works fine, even with Daily run output complaining I can still su to user i added in wheel group. We'd need to fix ckkgrp source, adduser source, and making move to: #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h I beleive OS's like macOSX etc when I read over their source is already setting this to 256. I beleive param.h is only place need to define this, in 8.2 and previous UT_NAMESIZE needed to be set in /usr/src/include/utmp.h as 255 and /usr/src/sys/sys/param.h needed MAXLOGNAME set to UT_NAMESIZE+1, but seems we did away with utmp.h in freebsd 9.0 only needing to set param.h now. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Kurt Touet wrote: On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man d...@sunsaturn.com wrote: Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: asterisk:~# uname -a FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 19:46:53 CDT 2011 dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 asterisk:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Dan The Man wrote: Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay=5 accf_data_load=YES aio_load=YES zfs_load=YES kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size=1844M vfs.zfs.arc_min=1024M vfs.zfs.arc_max=1536M vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable=1 ahci_load=YES asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = Primary backups interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = Primary backups path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916
[head tinderbox] failure on i386/i386
TB --- 2011-11-08 20:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-08 20:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-08 20:50:00 - cleaning the object tree TB --- 2011-11-08 20:50:51 - cvsupping the source tree TB --- 2011-11-08 20:50:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-08 20:56:15 - building world TB --- 2011-11-08 20:56:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 20:56:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 20:56:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 20:56:15 - SRCCONF=/dev/null TB --- 2011-11-08 20:56:15 - TARGET=i386 TB --- 2011-11-08 20:56:15 - TARGET_ARCH=i386 TB --- 2011-11-08 20:56:15 - TZ=UTC TB --- 2011-11-08 20:56:15 - __MAKE_CONF=/dev/null TB --- 2011-11-08 20:56:15 - cd /src TB --- 2011-11-08 20:56:15 - /usr/bin/make -B buildworld World build started on Tue Nov 8 20:56:16 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Nov 8 23:04:37 UTC 2011 TB --- 2011-11-08 23:04:37 - generating LINT kernel config TB --- 2011-11-08 23:04:37 - cd /src/sys/i386/conf TB --- 2011-11-08 23:04:37 - /usr/bin/make -B LINT TB --- 2011-11-08 23:04:37 - cd /src/sys/i386/conf TB --- 2011-11-08 23:04:37 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-08 23:04:37 - building LINT-NOINET kernel TB --- 2011-11-08 23:04:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 23:04:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 23:04:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 23:04:37 - SRCCONF=/dev/null TB --- 2011-11-08 23:04:37 - TARGET=i386 TB --- 2011-11-08 23:04:37 - TARGET_ARCH=i386 TB --- 2011-11-08 23:04:37 - TZ=UTC TB --- 2011-11-08 23:04:37 - __MAKE_CONF=/dev/null TB --- 2011-11-08 23:04:37 - cd /src TB --- 2011-11-08 23:04:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Nov 8 23:04:37 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpi_support/acpi_wmi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-fl! oat -ffreestanding -fstack-protector /src/sys/dev/ti/if_ti.c:134:2: error: #error options TI_JUMBO_HDRSPLIT requires TI_SF_BUF_JUMBO mkdep: compile failed *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-08 23:06:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-08 23:06:38 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-08 23:06:38 - 6274.74 user 1082.46 system 8198.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2011-11-08 20:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-08 20:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-08 20:50:00 - cleaning the object tree TB --- 2011-11-08 20:50:50 - cvsupping the source tree TB --- 2011-11-08 20:50:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-08 20:51:02 - building world TB --- 2011-11-08 20:51:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 20:51:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 20:51:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 20:51:02 - SRCCONF=/dev/null TB --- 2011-11-08 20:51:02 - TARGET=amd64 TB --- 2011-11-08 20:51:02 - TARGET_ARCH=amd64 TB --- 2011-11-08 20:51:02 - TZ=UTC TB --- 2011-11-08 20:51:02 - __MAKE_CONF=/dev/null TB --- 2011-11-08 20:51:02 - cd /src TB --- 2011-11-08 20:51:02 - /usr/bin/make -B buildworld World build started on Tue Nov 8 20:51:03 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Tue Nov 8 23:29:48 UTC 2011 TB --- 2011-11-08 23:29:48 - generating LINT kernel config TB --- 2011-11-08 23:29:48 - cd /src/sys/amd64/conf TB --- 2011-11-08 23:29:48 - /usr/bin/make -B LINT TB --- 2011-11-08 23:29:48 - cd /src/sys/amd64/conf TB --- 2011-11-08 23:29:48 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-08 23:29:48 - building LINT-NOINET kernel TB --- 2011-11-08 23:29:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-08 23:29:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-08 23:29:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-08 23:29:48 - SRCCONF=/dev/null TB --- 2011-11-08 23:29:48 - TARGET=amd64 TB --- 2011-11-08 23:29:48 - TARGET_ARCH=amd64 TB --- 2011-11-08 23:29:48 - TZ=UTC TB --- 2011-11-08 23:29:48 - __MAKE_CONF=/dev/null TB --- 2011-11-08 23:29:48 - cd /src TB --- 2011-11-08 23:29:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Nov 8 23:29:49 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpi_support/acpi_wmi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zon! e -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /src/sys/dev/ti/if_ti.c:134:2: error: #error options TI_JUMBO_HDRSPLIT requires TI_SF_BUF_JUMBO mkdep: compile failed *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-08 23:31:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-08 23:31:31 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-08 23:31:31 - 7632.41 user 1465.23 system 9691.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ath 11n tx work is now in head
Hi, I've merged in the bulk of my 11n TX work in a series of commits, culminating in a (still) overly large patch which added software TX aggregation and TX queue support. It's absolutely possible this has completely broken the ath driver. I'm going to spend the next few days throwing it against the hardware I have with me just to see if I broke anything during the merge. If you feel brave, throw on ATH_ENABLE_11N in your kernel config file and give it a go. If you're using legacy (non-11n) NICs, or you're not using 11N at home, please enable it too. It affects the non-11n TX path as well and I'd like to make absolutely sure this is still (mostly) working. Finally, if you -are- going to be testing this, I won't accept any error reports unless you've been running it with the -current debugging flags. That is, lock/witness debugging, asserts, and the memory allocator debugging. There's just too much that could be going wrong and I'd like to make sure that I have all of the relevant information from testers. Thanks again! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /etc/group chkgrp invalid character @
If you want to start a new thread please don't reply to an old one and change the subject line, please create a whole new message instead. That way those of us who read our mail threaded won't miss your new topic because it is hidden under an old one. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /etc/group chkgrp invalid character @
Understood, will resubmit, I didn't think of the email headers. Thank-you, Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Doug Barton wrote: If you want to start a new thread please don't reply to an old one and change the subject line, please create a whole new message instead. That way those of us who read our mail threaded won't miss your new topic because it is hidden under an old one. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
MAXLOGNAME + /etc/group + chkgrp invalid character @
With libnss-mysql we are able to login using email addresses etc. In the daily cron Daily run output email always get the following: Verifying group file syntax: chkgrp: /etc/group: line 3: '@' invalid character Could we modify system to support email addresses as usernames. From my testing it works fine, even with Daily run output complaining I can still su to user i added in wheel group. We'd need to fix ckkgrp source, adduser source, and making move to: #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h I beleive OS's like macOSX etc when I read over their source is already setting this to 256. I beleive param.h is only place need to define this, in 8.2 and previous UT_NAMESIZE needed to be set in /usr/src/include/utmp.h as 255 and /usr/src/sys/sys/param.h needed MAXLOGNAME set to UT_NAMESIZE+1, but seems we did away with utmp.h in freebsd 9.0 only needing to set param.h now. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
On 11/8/11 10:49 AM, Arnaud Lacombe wrote: Hi, To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug It convert a bunch of debug interface to use the caller instruction pointer, as well as a proof-of-concept teaching printf(9) to convert IP to symbol_name+offset. It translates in a direct saving of about +250kB on i386's GENERIC, just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, translates to a save of +80kB. Please note that this is still WIP code. A couple of comments. Firstly, the idea of a printf method to print the IP as symbol+offset is an interesting idea that should be followed up in its own right. However, (comment 2) I would much rather file+line in this case. I don't want to have the tools to decode the offset into a location in sources. We have both systems in operation art work and I far prefer the latter. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MAXLOGNAME + /etc/group + chkgrp invalid character @
On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: In the daily cron Daily run output email always get the following: Verifying group file syntax: chkgrp: /etc/group: line 3: '@' invalid character chkgrp expects group names to consist of characters in isalnum(). Could we modify system to support email addresses as usernames. Sure, that's why FreeBSD comes with source code. You can modify anything you like. :-) However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing @ into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. From my testing it works fine, even with Daily run output complaining I can still su to user i added in wheel group. We'd need to fix ckkgrp source, adduser source, and making move to: #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h You can do that also, but I think you'll break compatibility with NIS/YP. You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MAXLOGNAME + /etc/group + chkgrp invalid character @
On Tue, 8 Nov 2011, Chuck Swiger wrote: On Nov 8, 2011, at 3:47 PM, Dan The Man wrote: In the daily cron Daily run output email always get the following: Verifying group file syntax: chkgrp: /etc/group: line 3: '@' invalid character chkgrp expects group names to consist of characters in isalnum(). K so thats a simple fix where it does that check. Could we modify system to support email addresses as usernames. Sure, that's why FreeBSD comes with source code. You can modify anything you like. :-) However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports. You're not going to break anything allowing @ into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are. A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users. Wish you would elaborate abit more here, what I have found is email addresses tend to make the best usernames, people can remember them :) They are unique, and you solve 2 problems right away: a) they can actually remember their username b) they aren't having to pick through a million different taken usernames they have to pick on their own, which is frusterating way people often do signups. From my testing it works fine, even with Daily run output complaining I can still su to user i added in wheel group. We'd need to fix ckkgrp source, adduser source, and making move to: #define MAXLOGNAME 256 in /usr/src/sys/sys/param.h You can do that also, but I think you'll break compatibility with NIS/YP. Well with nss-mysql its as simple as modifying the /etc/nsswitch.conf on any machine to just point to same db server, works just fine. You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so. I've talked to many sys admins as well, that are all modifying the code to the kernel for a decade now on every new make buildworld, would be nice to see it mainstream. Only issue doing this I have seen so far, is having to nuke the wtmp/utx* files from /var/log on new installs to get them into new format, but that would be solved mainstream as well. I just find the benefits far outweight the cons, sure when we were all back in our computer science classes in 80s/90s it made sense. We all had accounts on the system for those 3-4 years, and generic usernames made sense, but now moving to webhosting environments and providing sftp/ssh type access to people on a larger scale, I think the email address as usernames make alot more sense now. I still teach unix at the university time to time and we still use the old putty/securecrt to sshd daemon way of learning from the command line, in that environment I find its about people forgetting passwords, take it up a notch to webhosting environment, and i find people forget their usernames to, and why I think it would be a good move... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MAXLOGNAME + /etc/group + chkgrp invalid character @
Hi--
On Nov 8, 2011, at 4:32 PM, Dan The Man wrote:
On Tue, 8 Nov 2011, Chuck Swiger wrote:
On Nov 8, 2011, at 3:47 PM, Dan The Man wrote:
In the daily cron Daily run output email always get the following:
Verifying group file syntax:
chkgrp: /etc/group: line 3: '@' invalid character
chkgrp expects group names to consist of characters in isalnum().
K so thats a simple fix where it does that check.
usr.sbin/chkgrp/chkgrp.c, line ~117:
for (cp = f[0] ; *cp ; cp++) {
if (!isalnum(*cp) *cp != '.' *cp != '_' *cp != '-'
(cp f[0] || *cp != '+')) {
warnx(%s: line %d: '%c' invalid character, gfn, n, *cp);
e++;
}
}
Add a *cp != '@' clause to the if statement.
Could we modify system to support email addresses as usernames.
Sure, that's why FreeBSD comes with source code.
You can modify anything you like. :-)
However, if you want to use a domain-aware login mechanism, Kerberos is in
the base system, and SASL and LDAP are available in ports. You're not going
to break anything allowing @ into the list of characters which pw(8)
likes, but the flatfile passwd and group files are not hierarchical the way
domain-aware network identity systems are.
A secondary issue is that there is rarely a one-to-one relationship between
email addresses and users; many email addresses are aliases which expand
either to a different username, or even to multiple users.
Wish you would elaborate abit more here, what I have found is email addresses
tend to make the best usernames, people can remember them :)
They are unique, and you solve 2 problems right away:
a) they can actually remember their username
b) they aren't having to pick through a million different taken usernames
they have to pick on their own, which is frusterating way people often do
signups.
If you've got a database of millions of users, you're definitely functioning in
a different realm than what /etc/passwd and /etc/group were designed for. :-)
Anyway, the idea is that you should be able to define multiple hierarchy levels
for your identity database, which NIS+, NetInfo, Kerberos, and LDAP
(kinda-sorta) can support. This lets you define an identity either at the root
level, which is visible everywhere, or in subdomains from root, which means the
identity is valid only within that subdomain but not in other subdomains-- and
johndoe in one subdomain can be entirely different than johndoe in some
other domain. (If you want johndoe the same everywhere, you'd define it at
root instead.)
That's just a bare-bones explanation, but a more complete one would likely
approach book-length. :-)
You might not care, but don't be surprised if you find that folks aren't
willing to adopt this change back into FreeBSD-- I've seen a few people
wanting to increase MAXLOGNAME since 2003 or so.
I've talked to many sys admins as well, that are all modifying the code to
the kernel for a decade now on every new make buildworld, would be nice to
see it mainstream.
Sure, you can find examples or counterexamples if you look for 'em...
Regards,
--
-Chuck
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi, On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer jul...@freebsd.org wrote: On 11/8/11 10:49 AM, Arnaud Lacombe wrote: Hi, To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug It convert a bunch of debug interface to use the caller instruction pointer, as well as a proof-of-concept teaching printf(9) to convert IP to symbol_name+offset. It translates in a direct saving of about +250kB on i386's GENERIC, just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, translates to a save of +80kB. Please note that this is still WIP code. A couple of comments. Firstly, the idea of a printf method to print the IP as symbol+offset is an interesting idea that should be followed up in its own right. However, (comment 2) I would much rather file+line in this case. I don't want to have the tools to decode the offset into a location in sources. this already exists and is called debug symbols - Arnaud We have both systems in operation art work and I far prefer the latter. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi, On Tue, Nov 8, 2011 at 3:55 PM, Andriy Gapon a...@freebsd.org wrote: [cc list trimmed] on 08/11/2011 22:34 Attilio Rao said the following: 2011/11/8 Arnaud Lacombe lacom...@gmail.com: To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: I really think that this is way too dependent by the good health of your tool, thus that is highly fragile. However, you may have more luck by just the core of your kernel changes here, for comment and leave alone all the (ptr - LOCK_FILE/LOCK_LINE conversion). Said that, I think this logic is too fragile and likely won't be as effective as __FILE__/__LINE__ in many cases. I agree. If we were able to somehow automatically, magically, easily and correctly determine an instruction pointer of a caller, then it would make sense to ditch explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction pointer decoding. again, no need for magic, this already exists, as the form of gcc[0]'s __builtin_return_address(0). But if we are just replacing explicit passing of (well-known) macros __FILE__/__LINE__ with explicit passing of THIS_IP, then I don't see a point. make sense too, but you need to be sure stuff between the caller and callee is fully inlined. Apologies if I missed the rationale for this change. mostly getting rid of all the __FILE__ and __LINE__ bloat. - Arnaud [0]: check about LLVM support is left to the reader. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi,
On Tue, Nov 8, 2011 at 3:34 PM, Attilio Rao atti...@freebsd.org wrote:
2011/11/8 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe lacom...@gmail.com wrote:
On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao atti...@freebsd.org wrote:
2011/11/7 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov kostik...@gmail.com
wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
Well, unfortunately, I wasn't around to comment 10 years ago when this got
in.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
Yes, and that's not an excuse to use the _internal_ implementation
details of mutex(9), and not the exposed API. This is especially true
when applied to someone so eager to follow standards.
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
You comment just as if __FILE__ and __LINE__ were mandatory in a debug
interface. This is _not_ true. __FILE__ and __LINE__ are just hideous
for debugging of anything but early alpha code. LOCK_FILE and
LOCK_LINE are a bad answer to a bad interface. Even if you just pass
NULL and 0 as argument, you've got the bloat of passing unused
argument. You might as well just pass a single argument that would do
the exact same job and be _always_ available, eg. the IP of the
caller, or the first return address. KDB magic still let you translate
to something humanly understandable. If the toolchain does not support
the feature on all supported platform, well, fix the toolchain.
To avoid future complaints about the fact that I would be only talk
without action, I did implement
Re: MAXLOGNAME + /etc/group + chkgrp invalid character @
On Tue, 8 Nov 2011, Chuck Swiger wrote:
Hi--
On Nov 8, 2011, at 4:32 PM, Dan The Man wrote:
On Tue, 8 Nov 2011, Chuck Swiger wrote:
On Nov 8, 2011, at 3:47 PM, Dan The Man wrote:
In the daily cron Daily run output email always get the following:
Verifying group file syntax:
chkgrp: /etc/group: line 3: '@' invalid character
chkgrp expects group names to consist of characters in isalnum().
K so thats a simple fix where it does that check.
usr.sbin/chkgrp/chkgrp.c, line ~117:
for (cp = f[0] ; *cp ; cp++) {
if (!isalnum(*cp) *cp != '.' *cp != '_' *cp != '-'
(cp f[0] || *cp != '+')) {
warnx(%s: line %d: '%c' invalid character, gfn, n, *cp);
e++;
}
}
Add a *cp != '@' clause to the if statement.
It doesn't bother me enough to have to modify the if statement on every
new buildworld(which I seem to be doing alot of lately), honestly that one
email login in the group file is only
email login that will ever touch an /etc file, rest is in database. I
wouldn't personally add any email type logins to a base system directly.
Could we modify system to support email addresses as usernames.
Sure, that's why FreeBSD comes with source code.
You can modify anything you like. :-)
However, if you want to use a domain-aware login mechanism, Kerberos is in the base
system, and SASL and LDAP are available in ports. You're not going to break anything
allowing @ into the list of characters which pw(8) likes, but the flatfile
passwd and group files are not hierarchical the way domain-aware network identity systems
are.
A secondary issue is that there is rarely a one-to-one relationship between
email addresses and users; many email addresses are aliases which expand either
to a different username, or even to multiple users.
Wish you would elaborate abit more here, what I have found is email addresses
tend to make the best usernames, people can remember them :)
They are unique, and you solve 2 problems right away:
a) they can actually remember their username
b) they aren't having to pick through a million different taken usernames
they have to pick on their own, which is frusterating way people often do
signups.
If you've got a database of millions of users, you're definitely functioning in
a different realm than what /etc/passwd and /etc/group were designed for. :-)
Well thats the idea right, unlimited growth but a central place to store
everything for scalability purposes. Of course if you actually tried to
login 1 million people to same machine, I am sure you would kill the I/O
instantly :)
Basically approach I've been taking is central database that stores all
users, any machine can be configured to not allow logins from anyone in
database by just removing them from /etc/nsswitch.conf. You can control
which of those million users can login to a certain machine by simply
modifying the select statement to the database in the nss-database config
file...all in all these changes take 2 seconds to change and makes things
quite easy.
Anyway, the idea is that you should be able to define multiple hierarchy levels for your identity database,
which NIS+, NetInfo, Kerberos, and LDAP (kinda-sorta) can support. This lets you define an identity either
at the root level, which is visible everywhere, or in subdomains from root, which means the identity is valid
only within that subdomain but not in other subdomains-- and johndoe in one subdomain can be
entirely different than johndoe in some other domain. (If you want johndoe the same
everywhere, you'd define it at root instead.)
That's just a bare-bones explanation, but a more complete one would likely
approach book-length. :-)
I'm sure it would make an interesting read, I try not to concern myself to
much with mechanisms that would likely to take to long to respond if there
were millions of users, working directly with mysql/postgres/oracle from
getgo i think is safe.
Think its almost like an analogy to where you started off building your
network code using something simple like select() then you kicked yourself
in the ass after for not having used epoll() on linux or kqueue() on
freebsd in an eventloop as your application got to many connections.
I do like your idea in a small office type setting though, definately
wouldn't mind trying something like that here at home so I had a central
way for all these development machines I got lieing around to have some
central login place.
Found this an interesting read last night:
http://www.mrp3.com/windows-to-unix-samba.html
might be abit dated...
Dan.
--
Dan The Man
CTO/ Senior System Administrator
Websites, Domains and Everything else
http://www.SunSaturn.com
Email: d...@sunsaturn.com
You might not care, but don't be surprised if you find that folks aren't
willing to adopt this change back into FreeBSD-- I've seen a few people wanting
to increase MAXLOGNAME since
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi, On Tue, Nov 8, 2011 at 8:09 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Nov 8, 2011 at 3:55 PM, Andriy Gapon a...@freebsd.org wrote: [cc list trimmed] on 08/11/2011 22:34 Attilio Rao said the following: 2011/11/8 Arnaud Lacombe lacom...@gmail.com: To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: I really think that this is way too dependent by the good health of your tool, thus that is highly fragile. However, you may have more luck by just the core of your kernel changes here, for comment and leave alone all the (ptr - LOCK_FILE/LOCK_LINE conversion). Said that, I think this logic is too fragile and likely won't be as effective as __FILE__/__LINE__ in many cases. I agree. If we were able to somehow automatically, magically, easily and correctly determine an instruction pointer of a caller, then it would make sense to ditch explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction pointer decoding. again, no need for magic, this already exists, as the form of gcc[0]'s __builtin_return_address(0). actually, this should be __builtin_return_address(1). - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) does not add post-processing for source file with compile-with command in sys/conf/files
On Tue, Oct 18, 2011 at 10:21 PM, Paul Ambrose ambrose...@gmail.com wrote:
when I digged the a PR(bin/160275), I found in_proto.c and
if_ethersubr.c ( see sys/conf/files ) does not get
${NORMAL_CTFCONVERT} post-processing in Makefile
(/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so
the objs does not contain ctf section
Here's a second attempt at this one. I think that this version is
much cleaner than the other options in this thread. If it survives a
make universe I intend to commit this:
Index: usr.sbin/config/mkmakefile.c
===
--- usr.sbin/config/mkmakefile.c(revision 227341)
+++ usr.sbin/config/mkmakefile.c(working copy)
@@ -762,16 +762,21 @@
break;
}
snprintf(cmd, sizeof(cmd),
- ${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}, ftype,
+ ${%s_%c%s}\n, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
if (strlen(ftp-f_objprefix))
- fprintf(f, \t%s $S/%s\n\n, compilewith, np);
+ fprintf(f, \t%s $S/%s\n, compilewith, np);
else
- fprintf(f, \t%s\n\n, compilewith);
+ fprintf(f, \t%s\n, compilewith);
+
+ if (!(ftp-f_flags NO_OBJ))
+ fprintf(f, \t@${NORMAL_CTFCONVERT}\n\n);
+ else
+ fprintf(f, \n);
}
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi, On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischer jul...@freebsd.org wrote: On 11/8/11 10:49 AM, Arnaud Lacombe wrote: Hi, To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug It convert a bunch of debug interface to use the caller instruction pointer, as well as a proof-of-concept teaching printf(9) to convert IP to symbol_name+offset. It translates in a direct saving of about +250kB on i386's GENERIC, just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, translates to a save of +80kB. Please note that this is still WIP code. A couple of comments. Firstly, the idea of a printf method to print the IP as symbol+offset is an interesting idea that should be followed up in its own right. FWIW, I have no credit in this idea. It has been in Linux for ages and ages. That said, IP address are barely used in FreeBSD, there is no legacy. As such, the API should not use `unsigned long' but `void *'[0]; this is the natural type returned by `__builtin_return_address()' and the `' operator. This would allow to introduce a modifier to `%p' to do the translation. - Arnaud ps: netgraph is on my target list, as well as the list code, to some extend :) [0]: as I really hate `caddr_t' ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: samba+zfs
On Tue, 8 Nov 2011, Kurt Touet wrote: On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man d...@sunsaturn.com wrote: Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: asterisk:~# uname -a FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 19:46:53 CDT 2011 dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 asterisk:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Dan The Man wrote: Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay=5 accf_data_load=YES aio_load=YES zfs_load=YES kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size=1844M vfs.zfs.arc_min=1024M vfs.zfs.arc_max=1536M vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable=1 ahci_load=YES asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = Primary backups interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = Primary backups path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916 kern.maxfilesperproc=204916 #raise sockets we can accept kern.ipc.somaxconn=32768 #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations net.inet.icmp.icmplim=500 kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=229376 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 #also add following to /boot/loader.conf #vm.kmem_size=1844M #kern.maxbcache=64M #kern.ipc.maxpipekva=4M #default setting of net.inet.ip.portrange.first is to low, causing us problems with bind net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #DOS protection net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=50 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 #some stuff for samba kern.ipc.nmbclusters=32768 kern.maxvnodes=80 net.inet.tcp.delayed_ack=0
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
On 11/8/11 5:22 PM, Arnaud Lacombe wrote:
Hi,
On Tue, Nov 8, 2011 at 3:34 PM, Attilio Raoatti...@freebsd.org wrote:
2011/11/8 Arnaud Lacombelacom...@gmail.com:
Hi,
On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombelacom...@gmail.com wrote:
On Mon, Nov 7, 2011 at 4:36 AM, Attilio Raoatti...@freebsd.org wrote:
2011/11/7 Arnaud Lacombelacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousovkostik...@gmail.com wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
Well, unfortunately, I wasn't around to comment 10 years ago when this got in.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
Yes, and that's not an excuse to use the _internal_ implementation
details of mutex(9), and not the exposed API. This is especially true
when applied to someone so eager to follow standards.
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
You comment just as if __FILE__ and __LINE__ were mandatory in a debug
interface. This is _not_ true. __FILE__ and __LINE__ are just hideous
for debugging of anything but early alpha code. LOCK_FILE and
LOCK_LINE are a bad answer to a bad interface. Even if you just pass
NULL and 0 as argument, you've got the bloat of passing unused
argument. You might as well just pass a single argument that would do
the exact same job and be _always_ available, eg. the IP of the
caller, or the first return address. KDB magic still let you translate
to something humanly understandable. If the toolchain does not support
the feature on all supported platform, well, fix the toolchain.
To avoid future complaints about the fact that I would be only talk
without action, I did implement what I suggested above. As it
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
On 11/8/11 5:52 PM, Arnaud Lacombe wrote: Hi, On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischerjul...@freebsd.org wrote: On 11/8/11 10:49 AM, Arnaud Lacombe wrote: Hi, To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug It convert a bunch of debug interface to use the caller instruction pointer, as well as a proof-of-concept teaching printf(9) to convert IP to symbol_name+offset. It translates in a direct saving of about +250kB on i386's GENERIC, just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, translates to a save of +80kB. Please note that this is still WIP code. A couple of comments. Firstly, the idea of a printf method to print the IP as symbol+offset is an interesting idea that should be followed up in its own right. FWIW, I have no credit in this idea. It has been in Linux for ages and ages. yeah as I said at work I use linux and BSD... the linux stuff that just prints out IP really annoys me. the list stuff and netgraph debug (which should be off in any production system) just require you to be able to see the console. and have sources nearby. if you need the IP use gdb. it's just what you are used to. You are obviously from the dark side ^H^H^H^H^H^H linux. so you are used to doing it that way.. but don't expect us to change just because that's what Linux does. When we have a problem at work on teh Linux driver, my first step is always to try duplicate it on FreeBSD because: 1/ half the time freebsd will just immediatly assert on something and present you with the bug.. done. 2/ I can run gdb through firewire on it on ANY standard unmodified kernel and find it, where on Linux I need to get a whole universe of stupid patches all aligned and MAYBE I might be able to see what is going on. if it's on redhat I need to do this, on ubuntu that, on suse something else ,and on different revisions of the kernel it all changes anyhow.. That said, IP address are barely used in FreeBSD, there is no legacy. As such, the API should not use `unsigned long' but `void *'[0]; this is the natural type returned by `__builtin_return_address()' and the `' operator. This would allow to introduce a modifier to `%p' to do the translation. possibly intptr_t is what should be used. but I'd expect Bruce to drop in here and let us us know. - Arnaud ps: netgraph is on my target list, as well as the list code, to some extend :) well let me know what you want to do because while it can do with love it is also used by a lot of people. if you nean to remove file/line.. don't. [0]: as I really hate `caddr_t' it's probably older than you are.. times change. void* wasn't used much back then. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-11-09 01:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 01:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-09 01:40:01 - cleaning the object tree TB --- 2011-11-09 01:40:28 - cvsupping the source tree TB --- 2011-11-09 01:40:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-09 01:45:51 - building world TB --- 2011-11-09 01:45:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 01:45:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 01:45:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 01:45:51 - SRCCONF=/dev/null TB --- 2011-11-09 01:45:51 - TARGET=arm TB --- 2011-11-09 01:45:51 - TARGET_ARCH=arm TB --- 2011-11-09 01:45:51 - TZ=UTC TB --- 2011-11-09 01:45:51 - __MAKE_CONF=/dev/null TB --- 2011-11-09 01:45:51 - cd /src TB --- 2011-11-09 01:45:51 - /usr/bin/make -B buildworld World build started on Wed Nov 9 01:45:52 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 9 02:42:09 UTC 2011 TB --- 2011-11-09 02:42:09 - cd /src/sys/arm/conf TB --- 2011-11-09 02:42:09 - /usr/sbin/config -m AVILA TB --- 2011-11-09 02:42:09 - building AVILA kernel TB --- 2011-11-09 02:42:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:42:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:42:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:42:09 - SRCCONF=/dev/null TB --- 2011-11-09 02:42:09 - TARGET=arm TB --- 2011-11-09 02:42:09 - TARGET_ARCH=arm TB --- 2011-11-09 02:42:09 - TZ=UTC TB --- 2011-11-09 02:42:09 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:42:09 - cd /src TB --- 2011-11-09 02:42:09 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Wed Nov 9 02:42:09 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Wed Nov 9 02:45:25 UTC 2011 TB --- 2011-11-09 02:45:25 - cd /src/sys/arm/conf TB --- 2011-11-09 02:45:25 - /usr/sbin/config -m BWCT TB --- 2011-11-09 02:45:25 - building BWCT kernel TB --- 2011-11-09 02:45:25 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:45:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:45:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:45:25 - SRCCONF=/dev/null TB --- 2011-11-09 02:45:25 - TARGET=arm TB --- 2011-11-09 02:45:25 - TARGET_ARCH=arm TB --- 2011-11-09 02:45:25 - TZ=UTC TB --- 2011-11-09 02:45:25 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:45:25 - cd /src TB --- 2011-11-09 02:45:25 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Wed Nov 9 02:45:25 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Wed Nov 9 02:47:37 UTC 2011 TB --- 2011-11-09 02:47:37 - cd /src/sys/arm/conf TB --- 2011-11-09 02:47:37 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-09 02:47:37 - building CAMBRIA kernel TB --- 2011-11-09 02:47:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:47:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:47:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:47:37 - SRCCONF=/dev/null TB --- 2011-11-09 02:47:37 - TARGET=arm TB --- 2011-11-09 02:47:37 - TARGET_ARCH=arm TB --- 2011-11-09 02:47:37 - TZ=UTC TB --- 2011-11-09 02:47:37 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:47:37 - cd /src TB --- 2011-11-09 02:47:37 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Wed Nov 9 02:47:37 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for CAMBRIA completed on Wed Nov 9 02:50:49 UTC 2011 TB --- 2011-11-09 02:50:49 - cd /src/sys/arm/conf TB --- 2011-11-09 02:50:49 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-09 02:50:49 - building CNS11XXNAS kernel TB --- 2011-11-09 02:50:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 02:50:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 02:50:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 02:50:49 - SRCCONF=/dev/null TB --- 2011-11-09 02:50:49 - TARGET=arm TB --- 2011-11-09 02:50:49 - TARGET_ARCH=arm TB --- 2011-11-09 02:50:49 - TZ=UTC TB --- 2011-11-09 02:50:49 - __MAKE_CONF=/dev/null TB --- 2011-11-09 02:50:49 - cd /src TB --- 2011-11-09 02:50:49 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS Kernel build
[head tinderbox] failure on i386/pc98
TB --- 2011-11-09 01:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 01:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-09 01:40:01 - cleaning the object tree TB --- 2011-11-09 01:40:24 - cvsupping the source tree TB --- 2011-11-09 01:40:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-09 01:40:38 - building world TB --- 2011-11-09 01:40:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 01:40:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 01:40:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 01:40:38 - SRCCONF=/dev/null TB --- 2011-11-09 01:40:38 - TARGET=pc98 TB --- 2011-11-09 01:40:38 - TARGET_ARCH=i386 TB --- 2011-11-09 01:40:38 - TZ=UTC TB --- 2011-11-09 01:40:38 - __MAKE_CONF=/dev/null TB --- 2011-11-09 01:40:38 - cd /src TB --- 2011-11-09 01:40:38 - /usr/bin/make -B buildworld World build started on Wed Nov 9 01:40:38 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 9 03:49:54 UTC 2011 TB --- 2011-11-09 03:49:54 - generating LINT kernel config TB --- 2011-11-09 03:49:54 - cd /src/sys/pc98/conf TB --- 2011-11-09 03:49:54 - /usr/bin/make -B LINT TB --- 2011-11-09 03:49:54 - cd /src/sys/pc98/conf TB --- 2011-11-09 03:49:54 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 03:49:54 - building GENERIC kernel TB --- 2011-11-09 03:49:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:49:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:49:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:49:54 - SRCCONF=/dev/null TB --- 2011-11-09 03:49:54 - TARGET=pc98 TB --- 2011-11-09 03:49:54 - TARGET_ARCH=i386 TB --- 2011-11-09 03:49:54 - TZ=UTC TB --- 2011-11-09 03:49:54 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:49:54 - cd /src TB --- 2011-11-09 03:49:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Nov 9 03:49:55 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c
[head tinderbox] failure on ia64/ia64
TB --- 2011-11-09 03:27:05 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 03:27:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-09 03:27:05 - cleaning the object tree TB --- 2011-11-09 03:27:19 - cvsupping the source tree TB --- 2011-11-09 03:27:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-09 03:27:32 - building world TB --- 2011-11-09 03:27:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:27:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:27:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:27:32 - SRCCONF=/dev/null TB --- 2011-11-09 03:27:32 - TARGET=ia64 TB --- 2011-11-09 03:27:32 - TARGET_ARCH=ia64 TB --- 2011-11-09 03:27:32 - TZ=UTC TB --- 2011-11-09 03:27:32 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:27:32 - cd /src TB --- 2011-11-09 03:27:32 - /usr/bin/make -B buildworld World build started on Wed Nov 9 03:27:33 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 9 04:55:23 UTC 2011 TB --- 2011-11-09 04:55:23 - generating LINT kernel config TB --- 2011-11-09 04:55:23 - cd /src/sys/ia64/conf TB --- 2011-11-09 04:55:23 - /usr/bin/make -B LINT TB --- 2011-11-09 04:55:23 - cd /src/sys/ia64/conf TB --- 2011-11-09 04:55:23 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 04:55:23 - building GENERIC kernel TB --- 2011-11-09 04:55:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:55:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:55:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:55:23 - SRCCONF=/dev/null TB --- 2011-11-09 04:55:23 - TARGET=ia64 TB --- 2011-11-09 04:55:23 - TARGET_ARCH=ia64 TB --- 2011-11-09 04:55:23 - TZ=UTC TB --- 2011-11-09 04:55:23 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:55:23 - cd /src TB --- 2011-11-09 04:55:23 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Nov 9 04:55:23 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_cal.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi, On Tue, Nov 8, 2011 at 9:35 PM, Julian Elischer jul...@freebsd.org wrote: On 11/8/11 5:52 PM, Arnaud Lacombe wrote: Hi, On Tue, Nov 8, 2011 at 7:08 PM, Julian Elischerjul...@freebsd.org wrote: On 11/8/11 10:49 AM, Arnaud Lacombe wrote: Hi, To avoid future complaints about the fact that I would be only talk without action, I did implement what I suggested above. As it is quite a large patch-set, I will not post it directly here, however, it is available on github: https://github.com/lacombar/freebsd/tree/master/topic/kern-lock-debug It convert a bunch of debug interface to use the caller instruction pointer, as well as a proof-of-concept teaching printf(9) to convert IP to symbol_name+offset. It translates in a direct saving of about +250kB on i386's GENERIC, just in kernel text size. Even the worst case, ie LOCK_DEBUG == 0, translates to a save of +80kB. Please note that this is still WIP code. A couple of comments. Firstly, the idea of a printf method to print the IP as symbol+offset is an interesting idea that should be followed up in its own right. FWIW, I have no credit in this idea. It has been in Linux for ages and ages. yeah as I said at work I use linux and BSD... the linux stuff that just prints out IP really annoys me. the list stuff and netgraph debug (which should be off in any production system) this is, I guess, where we do not agree. You find it acceptable to run totally different code in production and during debug. I do not. This is completely insane, even more nowadays where heavy parallelism increases the likelihood of races, and subtle change in the code, even optimization, can cause total behavioral change (ie. Heisenbug). For the record, we have been tracking for more than 2 months (first occurrences happened a year ago) an mbuf corruption in the network stack, present in all released code since at least FreeBSD 7[0]. Each time we think it is fixed, we are proven wrong by customers within a few days when the system crashes again. Even the last attempt which was believed to be bullet-proof failed and crashes daily. All that to say that production code should embed enough facilities to allow the system to be fully debugged with a runtime cost as low as possible, and a code-size cost as low as possible[1]. I should be able to connect on a production machine, turn a knob, an see what is going wrong, without the customer noticing. In the worst case, when you have to enable debug-only code, it must not be done by making the non-debug case more expensive, but wrap around. The whole original point of the patches was that LOCK_FILE and LOCK_LINE are a bad answer to a wrong problem. `__FILE__, __LINE__' and the bloat introduced is not the problem, `const char *file, int line' in way too much prototypes is. Now, you make me realize that `const char *file, int line' should just be removed, not replaced by `unsigned long' or anything else. It's likely to be done in another iteration. just require you to be able to see the console. and have sources nearby. if you need the IP use gdb. console debugging is yet another abomination which should be hunted down. Just try to do any useful work at high-pps on a serial console... it's just what you are used to. You are obviously from the dark side ^H^H^H^H^H^H linux. My obedience is totally irrelevant to the problem. However, if you want to know, my heart tends to be with BSDs. Unfortunately, it's a sad love-story where your Beloved keeps deceiving you day after day. You want to change small bits at a time, make several iteration of progress to make things brighter, but your Beloved refuses any change because of too much inertia. Sad. so you are used to doing it that way.. but don't expect us to change just because that's what Linux does. again, mentioning Linux is totally irrelevant. Use of Instruction Pointer are implementation details for a not so intrusive solution to the problem I pointed out, and which you are totally missing. Now, please answer this: do you find any of the bloat to the non-debug case (ie. passing a NULL pointer and a 0 integer, when `LOCK_DEBUG == 0') worth the extra debugability comfort to be acceptable ? If you do, then your focus is on making things comfortable for developers, at the expense 100's of users, rather than making things comfortable for 100's of users, at the expense of developers. When we have a problem at work on teh Linux driver, my first step is always to try duplicate it on FreeBSD because: well, you're lucky FreeBSD supports your device! Lately, we got lately a shiny multi-queue network cards with bypass mechanism... that is not supported in FreeBSD. So currently, we got an expensive paper-weight. 1/ half the time freebsd will just immediatly assert on something and present you with the bug.. done. well, certainly not from a release build; assertion are disabled. 2/ I can run gdb through firewire on it on ANY standard unmodified kernel
Re: samba+zfs
On Tue, Nov 8, 2011 at 8:16 PM, Dan The Man d...@sunsaturn.com wrote: On Tue, 8 Nov 2011, Kurt Touet wrote: On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man d...@sunsaturn.com wrote: Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1: asterisk:~# uname -a FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31 19:46:53 CDT 2011 dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 asterisk:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Tue, 8 Nov 2011, Dan The Man wrote: Ok here is some specs: this been running fine on 8.2 stable and i was sure it was running fine on RC1 as well. I did some testing against samba 34 35 and 36 in the ports collection all with the same slow write problems. I did further testing mounting drive in question with NFS and it did not suffer the same problem, so it seems just samba related here, where samba would actually outperform my NFS mount before, now its taking 10x as long to write anything. This is really most simplistic setup I have, all I want to do is map a network drive at the house read/write so my laptop, desktop etc all have access to it. I have played with all the smb.conf options, and can't seem to find where the issue is, further research suggests others are experiencing same problems with beta3 from following forum post: http://forums.freebsd.org/showthread.php?t=27300 Hardware this is running on: I beleive a 4 year old amd chip and board, with 2 gigs of ram, this is a home PC that serves as a NAS, it has 1 SSD as UFS boot OS filesystem, and uses ZFS in raid0 with 3 3terrabyte cheap hitachi drives for my storage space,which is mirrored nightly with rsync with another duplicate machine(cause I know someone is going to say why not use raid5-raidz) Network specs: machine currently has dedicated IPV4 and gif0 tunneled IPV6 addresses to he.net. I've played with nearly every option in smb.conf disabling, enabling etc and can't seem to find the issue: here are my current config file settings on machine that could apply to samba: asterisk:~# cat /boot/loader.conf autoboot_delay=5 accf_data_load=YES aio_load=YES zfs_load=YES kern.maxbcache=64M kern.ipc.maxpipekva=4M vfs.zfs.prefetch_disable=1 vm.kmem_size=1844M vfs.zfs.arc_min=1024M vfs.zfs.arc_max=1536M vfs.zfs.vdev.min_pending=2 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.zil_disable=1 ahci_load=YES asterisk:~# asterisk:~# cat /usr/local/etc/smb.conf # Global parameters [global] workgroup = HOME netbios name = ASTERISK server string = Primary backups interfaces = sk0 #smb ports = 139 #security = USER security = SHARE encrypt passwords = Yes #socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 domain master = no wins support = yes guest account = root socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY use sendfile = no level2 oplocks = True read raw = no write cache size = 262144 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes dns proxy = no max log size = 50 #log file = /dev/null log file = /var/log/samba.log debug level = 1 syslog = 0 [data] comment = Primary backups path = /data/public read only = No guest ok = Yes valid users = root asterisk:~# asterisk:~# cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1 2009/08/03 08:13:06 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 #raise file descriptors on the system kern.maxfiles=204916 kern.maxfilesperproc=204916 #raise sockets we can accept kern.ipc.somaxconn=32768 #http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 #NGINX webserver http://wiki.nginx.org/FreeBSDOptimizations net.inet.icmp.icmplim=500 kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=229376 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 #also add following to /boot/loader.conf #vm.kmem_size=1844M #kern.maxbcache=64M #kern.ipc.maxpipekva=4M #default setting of net.inet.ip.portrange.first is to low, causing us problems with bind net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #DOS protection net.inet.tcp.msl=7500 net.inet.tcp.blackhole=2
Re: samba+zfs
On 09/11/2011, at 16:29, Kurt Touet wrote: Is anyone else seeing problems like this with samba/zfs ?Perhaps it's not exclusive to samba, either? Yep, I see this too. I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) very slow - it reads writes and much more slowly (10-30MB/sec). When the array was fresh it was nice and fast - it is now 68% full and hasn't been much more full than that (I don't know but am pretty sure it never reach past 75%). The frustrating thing is trying to find some way of measuring what's actually going on.. I haven't had much luck :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: samba+zfs
On 09/11/2011, at 16:56, Daniel O'Connor wrote: On 09/11/2011, at 16:29, Kurt Touet wrote: Is anyone else seeing problems like this with samba/zfs ?Perhaps it's not exclusive to samba, either? Yep, I see this too. I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) very slow - it reads writes and much more slowly (10-30MB/sec). When the array was fresh it was nice and fast - it is now 68% full and hasn't been much more full than that (I don't know but am pretty sure it never reach past 75%). The frustrating thing is trying to find some way of measuring what's actually going on.. I haven't had much luck : Note that this is not restricted to Samba and while the server is not completely idle it's not doing very much. dd's of large files (spooled backups going to tape) to /dev/null are as slow as Samba. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2011-11-09 01:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 01:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-09 01:40:01 - cleaning the object tree TB --- 2011-11-09 01:40:19 - cvsupping the source tree TB --- 2011-11-09 01:40:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-09 01:40:34 - building world TB --- 2011-11-09 01:40:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 01:40:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 01:40:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 01:40:34 - SRCCONF=/dev/null TB --- 2011-11-09 01:40:34 - TARGET=i386 TB --- 2011-11-09 01:40:34 - TARGET_ARCH=i386 TB --- 2011-11-09 01:40:34 - TZ=UTC TB --- 2011-11-09 01:40:34 - __MAKE_CONF=/dev/null TB --- 2011-11-09 01:40:34 - cd /src TB --- 2011-11-09 01:40:34 - /usr/bin/make -B buildworld World build started on Wed Nov 9 01:40:35 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 9 03:49:56 UTC 2011 TB --- 2011-11-09 03:49:56 - generating LINT kernel config TB --- 2011-11-09 03:49:56 - cd /src/sys/i386/conf TB --- 2011-11-09 03:49:56 - /usr/bin/make -B LINT TB --- 2011-11-09 03:49:57 - cd /src/sys/i386/conf TB --- 2011-11-09 03:49:57 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-09 03:49:57 - building LINT-NOINET kernel TB --- 2011-11-09 03:49:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 03:49:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 03:49:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 03:49:57 - SRCCONF=/dev/null TB --- 2011-11-09 03:49:57 - TARGET=i386 TB --- 2011-11-09 03:49:57 - TARGET_ARCH=i386 TB --- 2011-11-09 03:49:57 - TZ=UTC TB --- 2011-11-09 03:49:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 03:49:57 - cd /src TB --- 2011-11-09 03:49:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Wed Nov 9 03:49:57 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Wed Nov 9 04:19:57 UTC 2011 TB --- 2011-11-09 04:19:57 - cd /src/sys/i386/conf TB --- 2011-11-09 04:19:57 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-09 04:19:57 - building LINT-NOINET6 kernel TB --- 2011-11-09 04:19:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:19:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:19:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:19:57 - SRCCONF=/dev/null TB --- 2011-11-09 04:19:57 - TARGET=i386 TB --- 2011-11-09 04:19:57 - TARGET_ARCH=i386 TB --- 2011-11-09 04:19:57 - TZ=UTC TB --- 2011-11-09 04:19:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:19:57 - cd /src TB --- 2011-11-09 04:19:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Wed Nov 9 04:19:57 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Wed Nov 9 04:50:20 UTC 2011 TB --- 2011-11-09 04:50:20 - cd /src/sys/i386/conf TB --- 2011-11-09 04:50:20 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-09 04:50:20 - building LINT-NOIP kernel TB --- 2011-11-09 04:50:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:50:20 - SRCCONF=/dev/null TB --- 2011-11-09 04:50:20 - TARGET=i386 TB --- 2011-11-09 04:50:20 - TARGET_ARCH=i386 TB --- 2011-11-09 04:50:20 - TZ=UTC TB --- 2011-11-09 04:50:20 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:50:20 - cd /src TB --- 2011-11-09 04:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP Kernel build for LINT-NOIP started on Wed Nov 9 04:50:20 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOIP completed on Wed Nov 9 05:17:35 UTC 2011 TB --- 2011-11-09 05:17:35 - cd /src/sys/i386/conf TB --- 2011-11-09 05:17:35 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-09 05:17:35 - building LINT-VIMAGE kernel TB --- 2011-11-09 05:17:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 05:17:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 05:17:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 05:17:35 - SRCCONF=/dev/null TB --- 2011-11-09 05:17:35 - TARGET=i386
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-11-09 05:05:54 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 05:05:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-09 05:05:54 - cleaning the object tree TB --- 2011-11-09 05:06:10 - cvsupping the source tree TB --- 2011-11-09 05:06:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-09 05:06:22 - building world TB --- 2011-11-09 05:06:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 05:06:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 05:06:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 05:06:22 - SRCCONF=/dev/null TB --- 2011-11-09 05:06:22 - TARGET=powerpc TB --- 2011-11-09 05:06:22 - TARGET_ARCH=powerpc64 TB --- 2011-11-09 05:06:22 - TZ=UTC TB --- 2011-11-09 05:06:22 - __MAKE_CONF=/dev/null TB --- 2011-11-09 05:06:22 - cd /src TB --- 2011-11-09 05:06:22 - /usr/bin/make -B buildworld World build started on Wed Nov 9 05:06:23 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Wed Nov 9 06:47:56 UTC 2011 TB --- 2011-11-09 06:47:57 - generating LINT kernel config TB --- 2011-11-09 06:47:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:47:57 - /usr/bin/make -B LINT TB --- 2011-11-09 06:47:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:47:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 06:47:57 - skipping GENERIC kernel TB --- 2011-11-09 06:47:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:47:57 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-09 06:47:57 - building GENERIC64 kernel TB --- 2011-11-09 06:47:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:47:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:47:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:47:57 - SRCCONF=/dev/null TB --- 2011-11-09 06:47:57 - TARGET=powerpc TB --- 2011-11-09 06:47:57 - TARGET_ARCH=powerpc64 TB --- 2011-11-09 06:47:57 - TZ=UTC TB --- 2011-11-09 06:47:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:47:57 - cd /src TB --- 2011-11-09 06:47:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 Kernel build for GENERIC64 started on Wed Nov 9 06:47:57 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector
Re: samba+zfs
On Tue, Nov 8, 2011 at 10:28 PM, Daniel O'Connor docon...@gsoft.com.au wrote: On 09/11/2011, at 16:56, Daniel O'Connor wrote: On 09/11/2011, at 16:29, Kurt Touet wrote: Is anyone else seeing problems like this with samba/zfs ? Perhaps it's not exclusive to samba, either? Yep, I see this too. I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) very slow - it reads writes and much more slowly (10-30MB/sec). When the array was fresh it was nice and fast - it is now 68% full and hasn't been much more full than that (I don't know but am pretty sure it never reach past 75%). The frustrating thing is trying to find some way of measuring what's actually going on.. I haven't had much luck : Note that this is not restricted to Samba and while the server is not completely idle it's not doing very much. dd's of large files (spooled backups going to tape) to /dev/null are as slow as Samba. - Dedupe? - Compression? - How much RAM? - What debug options do you have enabled in the kernel? I've been noticing a slowdown in some respects with NFS/SMB, but I suspected it was because I have an re(4) based NIC. ZFS has also wired down a lot of my system memory for the L2ARC... Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-11-09 04:57:29 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-09 04:57:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-09 04:57:29 - cleaning the object tree TB --- 2011-11-09 04:57:45 - cvsupping the source tree TB --- 2011-11-09 04:57:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-09 04:58:15 - building world TB --- 2011-11-09 04:58:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 04:58:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 04:58:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 04:58:15 - SRCCONF=/dev/null TB --- 2011-11-09 04:58:15 - TARGET=powerpc TB --- 2011-11-09 04:58:15 - TARGET_ARCH=powerpc TB --- 2011-11-09 04:58:15 - TZ=UTC TB --- 2011-11-09 04:58:15 - __MAKE_CONF=/dev/null TB --- 2011-11-09 04:58:15 - cd /src TB --- 2011-11-09 04:58:15 - /usr/bin/make -B buildworld World build started on Wed Nov 9 04:58:15 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 9 06:58:56 UTC 2011 TB --- 2011-11-09 06:58:57 - generating LINT kernel config TB --- 2011-11-09 06:58:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:58:57 - /usr/bin/make -B LINT TB --- 2011-11-09 06:58:57 - cd /src/sys/powerpc/conf TB --- 2011-11-09 06:58:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-09 06:58:57 - building GENERIC kernel TB --- 2011-11-09 06:58:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-09 06:58:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-09 06:58:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-09 06:58:57 - SRCCONF=/dev/null TB --- 2011-11-09 06:58:57 - TARGET=powerpc TB --- 2011-11-09 06:58:57 - TARGET_ARCH=powerpc TB --- 2011-11-09 06:58:57 - TZ=UTC TB --- 2011-11-09 06:58:57 - __MAKE_CONF=/dev/null TB --- 2011-11-09 06:58:57 - cd /src TB --- 2011-11-09 06:58:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Nov 9 06:58:57 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_reset.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9287_attach.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c
Re: samba+zfs
On 09/11/2011, at 17:32, Garrett Cooper wrote dd's of large files (spooled backups going to tape) to /dev/null are as slow as Samba. - Dedupe? Nope. - Compression? On the mail spool ports, but not on the tape spool. - How much RAM? 8GB. - What debug options do you have enabled in the kernel? It is 8.2-GENERIC so.. no WITNESS (for example) I've been noticing a slowdown in some respects with NFS/SMB, but I suspected it was because I have an re(4) based NIC. ZFS has also wired down a lot of my system memory for the L2ARC… re isn't great but I wouldn't expect it to slow down over time.. Unless bounce buffers got used more and more or something. I have an em0 card in this system - but in any case it is slow locally (i.e. dd a large file with 64k block size). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
