Re: sysctl filesystem ?
On 26 Jun 2012, at 15:42, m...@freebsd.org wrote: > While I understand the problems you allude to, the sysctl(8) binary > can protect itself from them. IMO the biggest problem with sysctls > not being files is that it makes no sense from the core UNIX > philosophy that everything is a file. Sockets and pipes and character > devices and even unseekable things like stdout are files; why aren't > these other objects that allow read, write, and have their own > namespace? I think I agree with what you're saying, subject to one modification: rather than saying "files", say "file descriptors", which are not quite the same but are, I think, what you mean. This doesn't mean you end up with a special file system mounted on /foo -- we don't do that for sockets or pipes --- but rather, we end up with using a similar object-oriented interface. And hence, BTW, our recent experimental addition of process descriptors to the API in support of Capsicum. However, I wonder how well that applies to sysctls, which unlike pipes/sockets, don't have an event model, etc... Robert___ 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: [CFC/CFT] large changes in the loader(8) code
"Andrey V. Elsukov" writes: > On 29.06.2012 15:01, Jan Beich wrote: > So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff >>> >>> FWIW, I verified it compiles OK with clang, and especially boot2's size >>> isn't increased at all. >> Does it boot for you? Same if I build zfs.c with gcc -O0: >> >> FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 >> (foo@bar, Tue Jun 26 18:52:52 UTC 2012) >> ZFS: can't find pool by guid >> ZFS: can't find pool by guid >> >> can't load 'kernel' >> > > Does zfsloader without patches compiled with CLANG work for you? It does. I did test before using $ cd /usr/src/sys/boot $ env -i __MAKE_CONF= PATH=/bin:/sbin:/usr/bin:/usr/sbin make CC=clang $ make install $ sudo qemu-system-x86_64 -curses -drive file=/dev/ada0 -drive file=/dev/ada1 In gcc -O0 case $ touch zfs/zfs.c $ rm i386/zfsloader/zfsloader* $ echo CFLAGS+=-O0 >>zfs/Makefile $ env -i ... make CC=gcc And for gcc47 $ touch zfs/zfs.c $ rm i386/zfsloader/zfsloader* $ env -i ... make CC=/usr/local/bin/gcc47 -C zfs I haven't tried to further track down which flag(s) within -O1 make zfsloader from your branch work when compiled with base gcc. ___ 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: MPSAFE VFS -- List of upcoming actions
On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > anything by SoC involved people about NTFS and certainly I don't see a > plan to get XFS locked. Stupid question, but what amount of locking does XFS in FreeBSD still need? I'm one of the maintainer of XFS on Linux, and while I know FreeBSD imported a really old version compared to the current one the codebases on IRIX and later Linux never relied on any global Giant-style locking. So if there is anything to fix it would be the in the small bits of FreeBSD-specific code. ___ 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 --- 2012-07-02 05:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 05:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 05:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-02 05:20:00 - cleaning the object tree TB --- 2012-07-02 05:32:25 - cvsupping the source tree TB --- 2012-07-02 05:32:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-02 05:34:16 - building world TB --- 2012-07-02 05:34:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 05:34:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 05:34:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 05:34:16 - SRCCONF=/dev/null TB --- 2012-07-02 05:34:16 - TARGET=i386 TB --- 2012-07-02 05:34:16 - TARGET_ARCH=i386 TB --- 2012-07-02 05:34:16 - TZ=UTC TB --- 2012-07-02 05:34:16 - __MAKE_CONF=/dev/null TB --- 2012-07-02 05:34:16 - cd /src TB --- 2012-07-02 05:34:16 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 05:34:17 UTC 2012 >>> 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 Mon Jul 2 08:08:07 UTC 2012 TB --- 2012-07-02 08:08:07 - generating LINT kernel config TB --- 2012-07-02 08:08:07 - cd /src/sys/i386/conf TB --- 2012-07-02 08:08:07 - /usr/bin/make -B LINT TB --- 2012-07-02 08:08:07 - cd /src/sys/i386/conf TB --- 2012-07-02 08:08:07 - /usr/sbin/config -m LINT TB --- 2012-07-02 08:08:07 - building LINT kernel TB --- 2012-07-02 08:08:07 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 08:08:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 08:08:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 08:08:07 - SRCCONF=/dev/null TB --- 2012-07-02 08:08:07 - TARGET=i386 TB --- 2012-07-02 08:08:07 - TARGET_ARCH=i386 TB --- 2012-07-02 08:08:07 - TZ=UTC TB --- 2012-07-02 08:08:07 - __MAKE_CONF=/dev/null TB --- 2012-07-02 08:08:07 - cd /src TB --- 2012-07-02 08:08:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 2 08:08:07 UTC 2012 >>> 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 completed on Mon Jul 2 08:42:00 UTC 2012 TB --- 2012-07-02 08:42:00 - cd /src/sys/i386/conf TB --- 2012-07-02 08:42:00 - /usr/sbin/config -m LINT-NOINET TB --- 2012-07-02 08:42:00 - building LINT-NOINET kernel TB --- 2012-07-02 08:42:00 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 08:42:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 08:42:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 08:42:00 - SRCCONF=/dev/null TB --- 2012-07-02 08:42:00 - TARGET=i386 TB --- 2012-07-02 08:42:00 - TARGET_ARCH=i386 TB --- 2012-07-02 08:42:00 - TZ=UTC TB --- 2012-07-02 08:42:00 - __MAKE_CONF=/dev/null TB --- 2012-07-02 08:42:00 - cd /src TB --- 2012-07-02 08:42:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Jul 2 08:42:00 UTC 2012 >>> 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 Mon Jul 2 09:14:58 UTC 2012 TB --- 2012-07-02 09:14:58 - cd /src/sys/i386/conf TB --- 2012-07-02 09:14:58 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-07-02 09:14:58 - building LINT-NOINET6 kernel TB --- 2012-07-02 09:14:58 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 09:14:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 09:14:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 09:14:58 - SRCCONF=/dev/null TB --- 2012-07-02 09:14:58 - TARGET=i386 TB --- 2012-07-02 09:14:58 - TARGET_ARCH=i386 TB --- 2012-07-02 09:14:58 - TZ=UTC TB --- 2012-07-02 09:14:58 - __MAKE_CONF=/dev/null TB --- 2012-07-02 09:14:58 - cd /src TB --- 2012-07-02 09:14:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Jul 2 09:14:59 UTC 2012 >>> 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 Mon Jul 2 09:46:27 UTC 2012 TB --- 2012-07-02 09:46:27 - cd /src/sys/i386/conf TB --- 2012-07-02 09:46:27 - /usr/sbin/config -m LINT-NOIP TB --- 2012-07-02 09:46:
Re: Occassional "permission denied" in the middle of a large transfer over NFS
On Sun, Jul 01, 2012 at 12:13:30PM +0100, Vincent Hoffman wrote: > On 01/07/2012 01:53, Rick Macklem wrote: > >>> > > I haven't looked at Andrey's patch, but conceptually it sounds like > > the best approach. As I understand it, the problem with replacing > > mountd with nfse (at least in the FreeBSD source tree) is that nfse > > is not 100% backwards compatible with /etc/exports and, as such, is > > a POLA violation. > Understood. Its far from a simple drop in replacement. List of difference between "nfse -C ..." (compatible mode with mountd) and mountd is given here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014554.html If we ignore absence of some obsolete options support and some command line options, the rest of differences visible to a user will occur only if one does not follow rules of exports(5) file format. The native mode of nfse (nfs.exports(5) file format) is different than the logic of mountd, just because using existent exports(5) file format it is impossible to specify export of not mounted file system, it is impossible to specify all export settings for one file system in one line, etc. Can you verify whether nfse compatible mode with mountd is really compatible with exports(5) files on your systems using instructions from this message (no installation or patching is required): http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html ___ 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: init: fatal signal: Segmentation fault
On Sun, Jul 01, 2012 at 11:03:49AM -0700, Marcel Moolenaar wrote: > > On Jun 21, 2012, at 8:40 AM, Anton Shterenlikht wrote: > > *snip* > > Trying to mount root from ufs:/dev/da2p2 [rw]... > > WARNING: / was not properly dismounted > > Jun 21 17:35:34 init: fatal signal: Segmentation fault > > Setting hostuuid: 0aa09909-35f1-11df-b7f8-00110a31e60a. > > Setting hostid: 0xc70eae4e. > > Entropy harvesting: interrupts ethernet point_to_point kickstart. > > Fast boot: skipping disk checks. > > Why are you forcing a fast boot? Subsequent problems are the result > of not making your file system clean. Well.. I had a complete freeze. The only way to recove was a cold reset, hence the "not properly dismounted" warning. I've no idea why the disk checks were skipped. As far as I remember, I just did a reboot, no extra or special options. > > > mount: /dev/da2p2: R/W mount of / denied. Filesystem is not clean - run > > fsck.: Operation not permitted > > Mounting root filesystem rw failed, startup aborted > > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > > Jun 21 17:36:06 init: /bin/sh on /etc/rc terminated abnormally, going to > > single user mode > > Jun 21 17:36:06 init: fatal signal: Segmentation fault > > I don't know if there's a separate problem with init(8) dumping > core or the immediate consequence of the above. > > > How can I recover from this? > > boot -s and see what happens. If init(8) dies again, use a > different init(8) by setting init_path at the loader prompt. > SOmething like the following could do the trick: > > set init_path="/sbin/init.bak" boot -s led to the same error "aborting boot". I didn't know about init.bak, will try next time. Anyway, I couldn't figure out how to recover, and decided to re-install. Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79
On Sun, Jul 01, 2012 at 11:28:04AM -0700, Marcel Moolenaar wrote: > > On Jun 29, 2012, at 3:40 AM, Anton Shterenlikht wrote: > > > # newfs /dev/da2p2 > > /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment size > > 4096 > >using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. > > super-block backups (for fsck -b #) at: > > 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, > > 10258112, 11540352, 12822592, > > 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, > > 23080512, 24362752, > > 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 8432 > > # mount /dev/da2p2 /mnt > > # cd /mnt > > # dump 0aLuf - / | restore -rf - > > > > results in this panic: > > > > KDB: stack backtrace: > > getenv with the following non-sleepable locks held: > > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > > (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 > > KDB: stack backtrace: > > getenv with the following non-sleepable locks held: > > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > > (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 > > KDB: stack backtrace: > > getenv with the following > > non-sleepablefatal kernel trap (cpu 0): > > locks held: > > I think you're kernel is seriously screwed-up. Do you have any > non-standard (for ia64) kernel configuration options? I didn't think so. The latest was this: (From http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI): cpu ITANIUM2# UZI - rx2600 portscluster node ident UZI makeoptions DEBUG=-g makeoptions MODULES_OVERRIDE="geom/geom_part geom/geom_label opensolaris zfs" #makeoptionsMODULES_OVERRIDE="geom/geom_part geom/geom_label opensolaris zfs acl_nfs4 acl_posix1e" options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER options CD9660 options DDB options DEADLKRES #optionsEXCEPTION_TRACING options FFS options GDB options INET options INET6 options INVARIANTS options INVARIANT_SUPPORT #optionsIPI_PREEMPTION options IPFILTER options IPFILTER_DEFAULT_BLOCK options IPFILTER_LOG options KDB options KTRACE options MD_ROOT options MSDOSFS options NFSCL options NFSD options P1003_1B_SEMAPHORES #optionsPREEMPTION options PRINTF_BUFR_SIZE=128 options PROCFS options PSEUDOFS #optionsSCHED_4BSD options SCHED_ULE options SCSI_DELAY=3000 options SCTP# Stream Control Transmission Protocol options SMP options SOFTUPDATES options STACK options SYSVMSG options SYSVSEM options SYSVSHM options UFS_DIRHASH options UWX_TRACE_ENABLE options WITNESS #optionsWITNESS_KDB options WITNESS_SKIPSPIN options _KPOSIX_PRIORITY_SCHEDULING device bge device bpf device cd device da device ehci device ether device firmware device fxp device loop device md device miibus device mpt device ohci device pass device pci device pty device puc device random device sa device scbus device scc device smbus device tun device uart device umass device usb ## # portbuilding options, from # http://www.freebsd.org/doc/en_US.ISO8859-1/articles/portbuild/article.html#NEW-NODE options NULLFS options TMPFS options GEOM_CONCAT options GEOM_STRIPE options SHMMAXPGS=65536 options SEMMNI=40 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 ## Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Occassional "permission denied" in the middle of a large transfer over NFS
On 02/07/2012 13:05, Andrey Simonenko wrote: > On Sun, Jul 01, 2012 at 12:13:30PM +0100, Vincent Hoffman wrote: >> On 01/07/2012 01:53, Rick Macklem wrote: >>> I haven't looked at Andrey's patch, but conceptually it sounds like >>> the best approach. As I understand it, the problem with replacing >>> mountd with nfse (at least in the FreeBSD source tree) is that nfse >>> is not 100% backwards compatible with /etc/exports and, as such, is >>> a POLA violation. >> Understood. Its far from a simple drop in replacement. > List of difference between "nfse -C ..." (compatible mode with mountd) > and mountd is given here: > > http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014554.html > > If we ignore absence of some obsolete options support and some command > line options, the rest of differences visible to a user will occur only > if one does not follow rules of exports(5) file format. > > The native mode of nfse (nfs.exports(5) file format) is different > than the logic of mountd, just because using existent exports(5) file > format it is impossible to specify export of not mounted file system, > it is impossible to specify all export settings for one file system in > one line, etc. > > Can you verify whether nfse compatible mode with mountd is really > compatible with exports(5) files on your systems using instructions > from this message (no installation or patching is required): > > http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html Its certainly compatible for me. I only have simple requirements though. (Basic NFS exports for servers to dump their backups onto.) nfse does look very good to me and I'll certainly be trying it in a VM. Any Ideas as to what would be needed to get this imported? Vince ___ 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: MPSAFE VFS -- List of upcoming actions
2012/7/2, Christoph Hellwig : > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >> anything by SoC involved people about NTFS and certainly I don't see a >> plan to get XFS locked. > > Stupid question, but what amount of locking does XFS in FreeBSD still > need? I'm one of the maintainer of XFS on Linux, and while I know > FreeBSD imported a really old version compared to the current one the > codebases on IRIX and later Linux never relied on any global Giant-style > locking. So if there is anything to fix it would be the in the small > bits of FreeBSD-specific code. Basically when it cames to make a MPSAFE filesystem under FreeBSD there are 2 things to pay attention at: filesystem specific locking and dealing with FreeBSD's VFS locking. The former is usually the tricky part because it varies among the filesystems and it is where the developers might have more knowledge. The latter can be helped by testing with a debugging kernel for low hanging fruits, but special attention must be put in things like avoid to put half-constructed vnodes in the mount lists, lookup races (in particular with DOTDOT case) and others. For a reference, one can always look to simple filesystems that are already made MPSAFE (like MSDOS-FS likely). In the XFS case, I think it would be desirable to have a real maintainership. This means, basically, not only work on the locking but really be keen to have a working XFS. At the moment, we might still have write support as well, but it is badly broken. What I suggest for XFS is: - Remove the current write support entirely - Try to bring the sole read support to new(ish) XFS version (at least to a version that is known to not be totally broken) - Fix up the support to work with FreeBSD VFS Thanks, 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: MPSAFE VFS -- List of upcoming actions
On 7/2/12 1:12 AM, Christoph Hellwig wrote: > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >> anything by SoC involved people about NTFS and certainly I don't see a >> plan to get XFS locked. > > Stupid question, but what amount of locking does XFS in FreeBSD still > need? I'm one of the maintainer of XFS on Linux, and while I know > FreeBSD imported a really old version compared to the current one the > codebases on IRIX and later Linux never relied on any global Giant-style > locking. So if there is anything to fix it would be the in the small > bits of FreeBSD-specific code. > I would be curious as well. Since I'm one of the people that has done the port of XFS to FreeBSD I'm wondering what this whole MP initiative with regards to filesystems is about. XFS certainly maintained any fine grain locking inherent to XFS it self. The XFS locks were mapped to FreeBSD sx locks in the code that is in the tree currently. The last time I made a pass at updating XFS some of locks were remapped to mtx locks. Is there somethings in the vfs layer in terms of locking that needs to be pushed down to the fs? -Russell signature.asc Description: OpenPGP digital signature
Re: MPSAFE VFS -- List of upcoming actions
2012/7/2, Russell Cattelan : > On 7/2/12 1:12 AM, Christoph Hellwig wrote: >> On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >>> anything by SoC involved people about NTFS and certainly I don't see a >>> plan to get XFS locked. >> >> Stupid question, but what amount of locking does XFS in FreeBSD still >> need? I'm one of the maintainer of XFS on Linux, and while I know >> FreeBSD imported a really old version compared to the current one the >> codebases on IRIX and later Linux never relied on any global Giant-style >> locking. So if there is anything to fix it would be the in the small >> bits of FreeBSD-specific code. >> > I would be curious as well. Since I'm one of the people that has done > the port of XFS to FreeBSD I'm wondering what this whole MP initiative > with regards to filesystems is about. So if you think that XFS doesn't need to acquire Giant why it is not yet marked MPSAFE? Also, did you really ever actually tested write support? (Not sure if it was added to you). 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: MPSAFE VFS -- List of upcoming actions
On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > anything by SoC involved people about NTFS and certainly I don't see a > > plan to get XFS locked. > > Stupid question, but what amount of locking does XFS in FreeBSD still > need? I'm one of the maintainer of XFS on Linux, and while I know > FreeBSD imported a really old version compared to the current one the > codebases on IRIX and later Linux never relied on any global Giant-style > locking. So if there is anything to fix it would be the in the small > bits of FreeBSD-specific code. > When I stopped being interested in XFS, I left is marked as non-MPSAFE entirely because of the lack of proper testing and because VFS locking was still evolving, there was no officially proper way of locking the FS and no other FS in the tree was MPSAFE. At that time the only problematic area was around inode instantiation, but sereval other lockingi changes have made it into the tree since then, namely ones that deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one needs to simply audit the code and make sure it still makse sense for today's VFS, which is not a huge amount of work. One step further woule be to take most of the XFS from under the exclusive vnode locking to improve the performance. And there is a third option - just let current XFS port die and start with newer version. -- Alexander Kabaev pgpzjQ50DAwMK.pgp Description: PGP signature
Re: swp_pager_meta_build DoS printf
On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote:
> Hey,
>
> hitting this printf in swp_pager_meta_build()
>
> if (uma_zone_exhausted(swap_zone)) {
> printf("swap zone exhausted, increase
> kern.maxswzone\n");
> vm_pageout_oom(VM_OOM_SWAPZ);
> pause("swzonex", 10);
> } else
>
> seems to be an effective way to put the machine into a state of no recovery
> unless the memory situation would be able to clear itself. Not that it
> wouldn't
> otherwise be any better but in addition having a couple of tenthousands of
> these
> going to console as well is really not helpful to try to do anything either.
> Can
> we make it a log() call or something?
>
> /bz
>
> PS: I am not sure as I have seen it on someone else's machines and it's
> probably been ZFS that caused it. I unfortunately neither had a way to
> get back in or break to a kernel debugger, so information is sparse.
This used to be a silent deadlock before I added the printf() and the call to
OOM. :-P Do you just want to ratelimit the printf? We have an API to ratelimit
printf's already.
--
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: problem with top
On Saturday, June 30, 2012 7:54:58 pm Erich Dollansky wrote:
> Hi,
>
> On Sunday, July 01, 2012 06:51:41 AM AN wrote:
> > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #23 r237852: Sat Jun 30
> > 18:45:27 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64
> >
> > After a recent upgrade, I am seeing a formatting issue with top.
> >
> > top -SPH -s 1:
> >
> > last pid: 26011; load averages: 3.61, 2.80, 1.56 up
> > 0+00:23:30 19:48:46
> > 268 processes: 6 running, 245 sleeping, 17 waiting
> > CPU 0: 22.0% user, 0.0% nice, 0.8% system, 0.8% interrupt, 76.4% idle
> > CPU 16877.6ctive, 2313M Inact, 6.3M Wired, 3 0.8 Cache, 1440M65.4, 7674M
> > Free
> > CPU 2: 28.3% user, 0.0% nice, 2.4% system, 0.0% interrupt, 69.3% idle
> > CPU 3: 36.2% user, 0.0% nice, 1.6% system, 0.0% interrupt, 62.2% idle
> > Mem: 455M Active, 2302M Inact, 3151M Wired, 3900K Cache, 1440M Buf, 7943M
> > Free
> > Swap: 20G Total, 20G Free
> >
> >
> > Seems like the entry for CPU 1 is wrong.
>
> I also noticed this but thought it is of temporary nature. The data of CPU 1
is getting overwritten by the data of the memory usage.
Ah, I think I have found the bug for this, can you try this change:
Index: usr.bin/top/machine.c
===
--- machine.c (revision 225593)
+++ machine.c (working copy)
@@ -263,6 +263,7 @@ update_layout(void)
{
y_mem = 3;
+ y_arc = 4;
y_swap = 4 + arc_enabled;
y_idlecursor = 5 + arc_enabled;
y_message = 5 + arc_enabled;
@@ -271,7 +272,8 @@ update_layout(void)
Header_lines = 7 + arc_enabled;
if (pcpu_stats) {
- y_mem = ncpus - 1;
+ y_mem += ncpus - 1;
+ y_arc += ncpus - 1;
y_swap += ncpus - 1;
y_idlecursor += ncpus - 1;
y_message += ncpus - 1;
--
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: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79
On Jul 2, 2012, at 5:43 AM, Anton Shterenlikht wrote: >> >> I think you're kernel is seriously screwed-up. Do you have any >> non-standard (for ia64) kernel configuration options? > > I didn't think so. > The latest was this: *snip* Looks fine indeed. I have pretty much the same, except for the IPFILTER options. I'm not concerned about. -- Marcel Moolenaar mar...@xcllnt.net ___ 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: swp_pager_meta_build DoS printf
On 2. Jul 2012, at 14:36 , John Baldwin wrote:
> On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote:
>> Hey,
>>
>> hitting this printf in swp_pager_meta_build()
>>
>>if (uma_zone_exhausted(swap_zone)) {
>>printf("swap zone exhausted, increase
>> kern.maxswzone\n");
>>vm_pageout_oom(VM_OOM_SWAPZ);
>>pause("swzonex", 10);
>>} else
>>
>> seems to be an effective way to put the machine into a state of no recovery
>> unless the memory situation would be able to clear itself. Not that it
>> wouldn't
>> otherwise be any better but in addition having a couple of tenthousands of
>> these
>> going to console as well is really not helpful to try to do anything either.
>> Can
>> we make it a log() call or something?
>>
>> /bz
>>
>> PS: I am not sure as I have seen it on someone else's machines and it's
>> probably been ZFS that caused it. I unfortunately neither had a way to
>> get back in or break to a kernel debugger, so information is sparse.
>
> This used to be a silent deadlock before I added the printf() and the call to
> OOM. :-P Do you just want to ratelimit the printf? We have an API to
> ratelimit
> printf's already.
Ratelimit would be fine; I was writing that on the wrong time of the wrong day
to
just get it out; could you do that?
/bz
--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!
___
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 ia64/ia64
TB --- 2012-07-02 16:39:32 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-07-02 16:39:32 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2012-07-02 16:39:32 - starting HEAD tinderbox run for ia64/ia64
TB --- 2012-07-02 16:39:32 - cleaning the object tree
TB --- 2012-07-02 16:39:32 - cvsupping the source tree
TB --- 2012-07-02 16:39:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/ia64/ia64/supfile
TB --- 2012-07-02 16:40:32 - building world
TB --- 2012-07-02 16:40:32 - CROSS_BUILD_TESTING=YES
TB --- 2012-07-02 16:40:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-07-02 16:40:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-07-02 16:40:32 - SRCCONF=/dev/null
TB --- 2012-07-02 16:40:32 - TARGET=ia64
TB --- 2012-07-02 16:40:32 - TARGET_ARCH=ia64
TB --- 2012-07-02 16:40:32 - TZ=UTC
TB --- 2012-07-02 16:40:32 - __MAKE_CONF=/dev/null
TB --- 2012-07-02 16:40:32 - cd /src
TB --- 2012-07-02 16:40:32 - /usr/bin/make -B buildworld
>>> World build started on Mon Jul 2 16:40:33 UTC 2012
>>> 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
[...]
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/ypwhich (cleandir)
rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin (cleandir)
"Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no")
"Makefile", line 264: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2012-07-02 16:42:58 - WARNING: /usr/bin/make returned exit code 1
TB --- 2012-07-02 16:42:58 - ERROR: failed to build world
TB --- 2012-07-02 16:42:58 - 85.10 user 18.66 system 205.89 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.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 mips/mips
TB --- 2012-07-02 16:42:58 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-07-02 16:42:58 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2012-07-02 16:42:58 - starting HEAD tinderbox run for mips/mips
TB --- 2012-07-02 16:42:58 - cleaning the object tree
TB --- 2012-07-02 16:42:58 - cvsupping the source tree
TB --- 2012-07-02 16:42:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/mips/mips/supfile
TB --- 2012-07-02 16:44:04 - building world
TB --- 2012-07-02 16:44:04 - CROSS_BUILD_TESTING=YES
TB --- 2012-07-02 16:44:04 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-07-02 16:44:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-07-02 16:44:04 - SRCCONF=/dev/null
TB --- 2012-07-02 16:44:04 - TARGET=mips
TB --- 2012-07-02 16:44:04 - TARGET_ARCH=mips
TB --- 2012-07-02 16:44:04 - TZ=UTC
TB --- 2012-07-02 16:44:04 - __MAKE_CONF=/dev/null
TB --- 2012-07-02 16:44:04 - cd /src
TB --- 2012-07-02 16:44:04 - /usr/bin/make -B buildworld
>>> World build started on Mon Jul 2 16:44:05 UTC 2012
>>> 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
[...]
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/ypwhich (cleandir)
rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin (cleandir)
"Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no")
"Makefile", line 264: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2012-07-02 16:46:29 - WARNING: /usr/bin/make returned exit code 1
TB --- 2012-07-02 16:46:29 - ERROR: failed to build world
TB --- 2012-07-02 16:46:29 - 88.08 user 18.24 system 211.06 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.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 powerpc/powerpc
TB --- 2012-07-02 16:46:30 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-07-02 16:46:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2012-07-02 16:46:30 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2012-07-02 16:46:30 - cleaning the object tree
TB --- 2012-07-02 16:46:30 - cvsupping the source tree
TB --- 2012-07-02 16:46:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2012-07-02 16:47:24 - building world
TB --- 2012-07-02 16:47:24 - CROSS_BUILD_TESTING=YES
TB --- 2012-07-02 16:47:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-07-02 16:47:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-07-02 16:47:24 - SRCCONF=/dev/null
TB --- 2012-07-02 16:47:24 - TARGET=powerpc
TB --- 2012-07-02 16:47:24 - TARGET_ARCH=powerpc
TB --- 2012-07-02 16:47:24 - TZ=UTC
TB --- 2012-07-02 16:47:24 - __MAKE_CONF=/dev/null
TB --- 2012-07-02 16:47:24 - cd /src
TB --- 2012-07-02 16:47:24 - /usr/bin/make -B buildworld
>>> World build started on Mon Jul 2 16:47:25 UTC 2012
>>> 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
[...]
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/ypwhich (cleandir)
rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin (cleandir)
"Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no")
"Makefile", line 264: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2012-07-02 16:52:53 - WARNING: /usr/bin/make returned exit code 1
TB --- 2012-07-02 16:52:53 - ERROR: failed to build world
TB --- 2012-07-02 16:52:53 - 238.14 user 32.23 system 383.77 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.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 powerpc64/powerpc
TB --- 2012-07-02 16:52:54 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-07-02 16:52:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2012-07-02 16:52:54 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2012-07-02 16:52:54 - cleaning the object tree
TB --- 2012-07-02 16:52:54 - cvsupping the source tree
TB --- 2012-07-02 16:52:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2012-07-02 16:53:51 - building world
TB --- 2012-07-02 16:53:51 - CROSS_BUILD_TESTING=YES
TB --- 2012-07-02 16:53:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-07-02 16:53:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-07-02 16:53:51 - SRCCONF=/dev/null
TB --- 2012-07-02 16:53:51 - TARGET=powerpc
TB --- 2012-07-02 16:53:51 - TARGET_ARCH=powerpc64
TB --- 2012-07-02 16:53:51 - TZ=UTC
TB --- 2012-07-02 16:53:51 - __MAKE_CONF=/dev/null
TB --- 2012-07-02 16:53:51 - cd /src
TB --- 2012-07-02 16:53:51 - /usr/bin/make -B buildworld
>>> World build started on Mon Jul 2 16:53:52 UTC 2012
>>> 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
[...]
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/ypwhich (cleandir)
rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin (cleandir)
"Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no")
"Makefile", line 264: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2012-07-02 16:59:40 - WARNING: /usr/bin/make returned exit code 1
TB --- 2012-07-02 16:59:40 - ERROR: failed to build world
TB --- 2012-07-02 16:59:40 - 238.30 user 33.30 system 406.26 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.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 sparc64/sparc64
TB --- 2012-07-02 16:59:40 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-07-02 16:59:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2012-07-02 16:59:40 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2012-07-02 16:59:40 - cleaning the object tree
TB --- 2012-07-02 16:59:40 - cvsupping the source tree
TB --- 2012-07-02 16:59:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2012-07-02 17:00:51 - building world
TB --- 2012-07-02 17:00:51 - CROSS_BUILD_TESTING=YES
TB --- 2012-07-02 17:00:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-07-02 17:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-07-02 17:00:51 - SRCCONF=/dev/null
TB --- 2012-07-02 17:00:51 - TARGET=sparc64
TB --- 2012-07-02 17:00:51 - TARGET_ARCH=sparc64
TB --- 2012-07-02 17:00:51 - TZ=UTC
TB --- 2012-07-02 17:00:51 - __MAKE_CONF=/dev/null
TB --- 2012-07-02 17:00:51 - cd /src
TB --- 2012-07-02 17:00:51 - /usr/bin/make -B buildworld
>>> World build started on Mon Jul 2 17:00:51 UTC 2012
>>> 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
[...]
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/ypwhich (cleandir)
rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin (cleandir)
"Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no")
"Makefile", line 264: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2012-07-02 17:04:12 - WARNING: /usr/bin/make returned exit code 1
TB --- 2012-07-02 17:04:12 - ERROR: failed to build world
TB --- 2012-07-02 17:04:12 - 85.69 user 17.27 system 271.68 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"
[head tinderbox] failure on i386/i386
TB --- 2012-07-02 14:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 14:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 14:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-02 14:30:00 - cleaning the object tree TB --- 2012-07-02 14:35:26 - cvsupping the source tree TB --- 2012-07-02 14:35:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-02 14:36:39 - building world TB --- 2012-07-02 14:36:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 14:36:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 14:36:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 14:36:39 - SRCCONF=/dev/null TB --- 2012-07-02 14:36:39 - TARGET=i386 TB --- 2012-07-02 14:36:39 - TARGET_ARCH=i386 TB --- 2012-07-02 14:36:39 - TZ=UTC TB --- 2012-07-02 14:36:39 - __MAKE_CONF=/dev/null TB --- 2012-07-02 14:36:39 - cd /src TB --- 2012-07-02 14:36:39 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 14:36:40 UTC 2012 >>> 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 Mon Jul 2 17:04:18 UTC 2012 TB --- 2012-07-02 17:04:18 - generating LINT kernel config TB --- 2012-07-02 17:04:18 - cd /src/sys/i386/conf TB --- 2012-07-02 17:04:18 - /usr/bin/make -B LINT TB --- 2012-07-02 17:04:18 - cd /src/sys/i386/conf TB --- 2012-07-02 17:04:18 - /usr/sbin/config -m LINT TB --- 2012-07-02 17:04:18 - building LINT kernel TB --- 2012-07-02 17:04:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 17:04:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 17:04:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 17:04:18 - SRCCONF=/dev/null TB --- 2012-07-02 17:04:18 - TARGET=i386 TB --- 2012-07-02 17:04:18 - TARGET_ARCH=i386 TB --- 2012-07-02 17:04:18 - TZ=UTC TB --- 2012-07-02 17:04:18 - __MAKE_CONF=/dev/null TB --- 2012-07-02 17:04:18 - cd /src TB --- 2012-07-02 17:04:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 2 17:04:19 UTC 2012 >>> 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 completed on Mon Jul 2 17:35:42 UTC 2012 TB --- 2012-07-02 17:35:42 - cd /src/sys/i386/conf TB --- 2012-07-02 17:35:42 - /usr/sbin/config -m LINT-NOINET TB --- 2012-07-02 17:35:42 - building LINT-NOINET kernel TB --- 2012-07-02 17:35:42 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 17:35:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 17:35:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 17:35:42 - SRCCONF=/dev/null TB --- 2012-07-02 17:35:42 - TARGET=i386 TB --- 2012-07-02 17:35:42 - TARGET_ARCH=i386 TB --- 2012-07-02 17:35:42 - TZ=UTC TB --- 2012-07-02 17:35:42 - __MAKE_CONF=/dev/null TB --- 2012-07-02 17:35:42 - cd /src TB --- 2012-07-02 17:35:42 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Jul 2 17:35:42 UTC 2012 >>> 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 Mon Jul 2 18:03:15 UTC 2012 TB --- 2012-07-02 18:03:15 - cd /src/sys/i386/conf TB --- 2012-07-02 18:03:15 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-07-02 18:03:15 - building LINT-NOINET6 kernel TB --- 2012-07-02 18:03:15 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 18:03:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 18:03:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 18:03:15 - SRCCONF=/dev/null TB --- 2012-07-02 18:03:15 - TARGET=i386 TB --- 2012-07-02 18:03:15 - TARGET_ARCH=i386 TB --- 2012-07-02 18:03:15 - TZ=UTC TB --- 2012-07-02 18:03:15 - __MAKE_CONF=/dev/null TB --- 2012-07-02 18:03:15 - cd /src TB --- 2012-07-02 18:03:15 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Jul 2 18:03:15 UTC 2012 >>> 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 Mon Jul 2 18:30:48 UTC 2012 TB --- 2012-07-02 18:30:48 - cd /src/sys/i386/conf TB --- 2012-07-02 18:30:48 - /usr/sbin/config -m LINT-NOIP TB --- 2012-07-02 18:30:
Re: MPSAFE VFS -- List of upcoming actions
On Mon, Jul 02, 2012 at 11:03:40AM -0400, Alexander Kabaev wrote: > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > > anything by SoC involved people about NTFS and certainly I don't see a > > > plan to get XFS locked. > > > > Stupid question, but what amount of locking does XFS in FreeBSD still > > need? I'm one of the maintainer of XFS on Linux, and while I know > > FreeBSD imported a really old version compared to the current one the > > codebases on IRIX and later Linux never relied on any global Giant-style > > locking. So if there is anything to fix it would be the in the small > > bits of FreeBSD-specific code. > > > > When I stopped being interested in XFS, I left is marked as non-MPSAFE > entirely because of the lack of proper testing and because VFS locking > was still evolving, there was no officially proper way of locking the > FS and no other FS in the tree was MPSAFE. At that time the only > problematic area was around inode instantiation, but sereval other > lockingi changes have made it into the tree since then, namely ones that > deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one > needs to simply audit the code and make sure it still makse sense for today's > VFS, which is not a huge amount of work. One step further woule be to take > most of the XFS from under the exclusive vnode locking to improve the > performance. If filesystem uses some global internal locks, that locks usually are placed after the vnode locks in global lock order, because VOP methods call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of events, when method is called with lookup directory locked, causes LOR. It appears because you lock global lock upon entry into VOP_LOOKUP(), and then need to lock the returned vnode. Dropping global lock inside VOP_LOOKUP() usually exposes races which were the reason to introduce the global lock. Having filesystem non-MPSAFE makes the LOR go away without the need to drop global lock. Example of FreeBSD native filesystem which suffered from this issue and required quite non-trivial handling is devfs. Devfs uses per-mount global lock. See devfs_allocv() and devfs_allocv_drop_refs() for the gory details. pgpvG8Zjgt51F.pgp Description: PGP signature
Re: SVN2CVS exporter down
On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote: > On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: > > Just FYI, > > > > the svn2cvs exporter is currently down due to > > http://svn.freebsd.org/changeset/base/237860 . > > I'll fix it as soon as I get back from lunch, so should be back in a > > few hours. > > Fixed. Please try not to replace files or even worse directories. Thanks. Simon, Are you saying we are now restricted in the svn operations we can perform due to the lack of the svn2cvs exporter to consume them? If so, this doesn't seem desirable... we moved to Subversion to obtain such operations as file and directory moves. I suspect such operations will only happen with increased frequency after the Ports Collection moves to Subversion. -- -- David (obr...@freebsd.org) ___ 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: SVN2CVS exporter down
On 2 Jul 2012, at 22:39, David O'Brien wrote: > On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote: >> On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: >>> Just FYI, >>> >>> the svn2cvs exporter is currently down due to >>> http://svn.freebsd.org/changeset/base/237860 . >>> I'll fix it as soon as I get back from lunch, so should be back in a >>> few hours. >> >> Fixed. Please try not to replace files or even worse directories. Thanks. > > Simon, > Are you saying we are now restricted in the svn operations we can perform > due to the lack of the svn2cvs exporter to consume them? Basically yes, though it's not a new thing - we have been from day 1 of using svn. Or rather, each time somebody "replaces" a file we (peter, bz, or me) have to manually hack svn2cvs to handle the case with the increasing risk that we will do it wrong and svn/cvs will be out of sync. > If so, this doesn't seem desirable... we moved to Subversion to obtain > such operations as file and directory moves. You can move files and dirs, just as long as you don't move them on top of existing files. The problem is that that creates an 'remove' and 'add' operation in the same changeset which CVS cannot handle. Tested patches are accepted (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even better - work on killing off CVS sooner rather than later. > I suspect such operations will only happen with increased frequency after > the Ports Collection moves to Subversion. Ports will explicitly deny "Replaced" files in a presubmit check. I will look at adding the same for src once I get a chance. -- Simon L. B. Nielsen ___ 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: MPSAFE VFS -- List of upcoming actions
On 7/2/12 10:03 AM, Alexander Kabaev wrote: > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: >> On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >>> anything by SoC involved people about NTFS and certainly I don't see a >>> plan to get XFS locked. >> >> Stupid question, but what amount of locking does XFS in FreeBSD still >> need? I'm one of the maintainer of XFS on Linux, and while I know >> FreeBSD imported a really old version compared to the current one the >> codebases on IRIX and later Linux never relied on any global Giant-style >> locking. So if there is anything to fix it would be the in the small >> bits of FreeBSD-specific code. >> > > When I stopped being interested in XFS, I left is marked as non-MPSAFE > entirely because of the lack of proper testing and because VFS locking > was still evolving, there was no officially proper way of locking the > FS and no other FS in the tree was MPSAFE. At that time the only > problematic area was around inode instantiation, but sereval other > lockingi changes have made it into the tree since then, namely ones that > deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one > needs to simply audit the code and make sure it still makse sense for today's > VFS, which is not a huge amount of work. One step further woule be to take > most of the XFS from under the exclusive vnode locking to improve the > performance. > > And there is a third option - just let current XFS port die and start with > newer version. > I like option 3. The current code is way way out of date and doesn't even reflect the last round of sync up I did. Unless somebody says "hey I'm using XFS" we could just let the current code go and reintroduce a current port if it ever receives the needed attention. Unfortunately I think there were would have be be some sponsorship of the effort since getting xfs fully supported would require some significant developer hours. If anybody is interesting in the current state of things here is my git tree that I cleaned up and put online during BSDCan. http://git.digitalelves.com/?p=FreeBSD_xfs.git;a=summary xfs-FreeBSD_7 has the last somewhat functional code. This was based on a code drop from linux XFS at the time. Log recovery was just starting to come to life (very simple recovery would work) Write was working to the point there you could do a single thread to the fs and have the data cmp back with the original file. Read also still works but is unstable. xfs-FreeBSD_9 is quick code drop I did a month or so ago. I does not compile as many of the linux files moved around so not all the compat stuff lines up and some new compat code needs to written. -Russell signature.asc Description: OpenPGP digital signature
Re: MPSAFE VFS -- List of upcoming actions
On Mon, 2 Jul 2012 23:12:06 +0300 Konstantin Belousov wrote: > On Mon, Jul 02, 2012 at 11:03:40AM -0400, Alexander Kabaev wrote: > > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > > > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > > > anything by SoC involved people about NTFS and certainly I > > > > don't see a plan to get XFS locked. > > > > > > Stupid question, but what amount of locking does XFS in FreeBSD > > > still need? I'm one of the maintainer of XFS on Linux, and while > > > I know FreeBSD imported a really old version compared to the > > > current one the codebases on IRIX and later Linux never relied on > > > any global Giant-style locking. So if there is anything to fix > > > it would be the in the small bits of FreeBSD-specific code. > > > > > > > When I stopped being interested in XFS, I left is marked as > > non-MPSAFE entirely because of the lack of proper testing and > > because VFS locking was still evolving, there was no officially > > proper way of locking the FS and no other FS in the tree was > > MPSAFE. At that time the only problematic area was around inode > > instantiation, but sereval other lockingi changes have made it into > > the tree since then, namely ones that deal with insmntque and also > > VOP_LOOKUP changes. To mark XFS MPSAFE, one needs to simply audit > > the code and make sure it still makse sense for today's VFS, which > > is not a huge amount of work. One step further woule be to take > > most of the XFS from under the exclusive vnode locking to improve > > the performance. > > If filesystem uses some global internal locks, that locks usually are > placed after the vnode locks in global lock order, because VOP methods > call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of > events, when method is called with lookup directory locked, causes > LOR. It appears because you lock global lock upon entry into > VOP_LOOKUP(), and then need to lock the returned vnode. > Dropping global lock inside VOP_LOOKUP() usually exposes races which > were the reason to introduce the global lock. Having filesystem > non-MPSAFE makes the LOR go away without the need to drop global lock. > > Example of FreeBSD native filesystem which suffered from this issue > and required quite non-trivial handling is devfs. Devfs uses per-mount > global lock. See devfs_allocv() and devfs_allocv_drop_refs() for > the gory details. All very informative, though misplaced in case of XFS. XFS does not use global lock internally, it is quite well locked inside and exclusive _VNODE_ lock we take by default in all methods is usually unnecessary as all it does it prevents other locks in XFS proper from having any useful function. -- Alexander Kabaev signature.asc Description: PGP signature
A suspicious warning in sys/boot/zfs/zfsimpl.c
When I built the world as of r237813, clang reported a warning which caught my attention. ===> sys/boot/zfs (all) clang -O2 -pipe -march=pentium4 -DBOOTPROG=\"zfsloader\" -I/usr/src/sys/boot/zfs/../common -I/usr/src/sys/boot/zfs/../.. -I. -I/usr/src/sys/boot/zfs/../../../lib/libstand -I/usr/src/sys/boot/zfs/../../cddl/boot/zfs -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Wformat -Wall -DNDEBUG -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/zfs/zfs.c -o zfs.o In file included from /usr/src/sys/boot/zfs/zfs.c:48: /usr/src/sys/boot/zfs/zfsimpl.c:2033:19: warning: array index 264 is past the end of the array (which contains 192 elements) [-Warray-bounds] memcpy(path, &dn.dn_bonus[sizeof(znode_phys_t)], ^ /usr/src/sys/boot/zfs/../../cddl/boot/zfs/zfsimpl.h:788:2: note: array 'dn_bonus' declared here uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)]; ^ I don't have a zfs-powered machine, so I'm not sure whether this warning is false-positive or not. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - ___ 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: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)
On Jun 30, 2012, at 3:47 PM, Bruce Cran wrote: > On 28/06/2012 00:11, Devin Teske wrote: >> I'd like to announce that I intend to import bsdconfig(8) today. > > I haven't seen this get committed yet - was there a problem? > No problems. A long weekend put the damper on the process but it has picked up again. By week's end there should be more info. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello Matthias Apitz and -current member, "sys/dev/atkbdc/atkbdc_isa.c" may not have your keyboard controller's ID. Run `acpidump -dt` and search your keyboard description. Is your keyboard controller "PNP0303" ? -- k...@ed.niigata-u.ac.jp > El d$(D+c*$(B Sunday, July 01, 2012 a las 06:29:28AM +0700, Erich Dollansky > escribi$(D+Q"k(B > > Hi, > > > and no older versions. I will install the USB booted system to harddisk > > and hope when booted from disk and not from USB the keyboard is working. > > > > I installed the system r235646 to disk and it shows the same problem: no > keyboard; > > if 7.4 still runs but not anything after 8.0, it is most likely what I have > written. Some USB hardware is not supported anymore in 8 and later. > > I would install the old one just to see You will also know wat hwardware is > used there and how it is supported. > > This might be the faster route before starting debugging something which is > not there. > > I said already that it works with a r21 version, CURRENT from > October 2010; so I booted this again and concerning keyboard, here is > the diff: > > r21: > > $ fgrep -i kb /tmp/dmesg-r21.txt > kbd1 at kbdmux0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > > $ ls -l /dev/kb* > lrwxr-xr-x 1 root wheel 6 Jul 1 08:39 /dev/kbd0 -> atkbd0 > lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 -> kbdmux0 > crw--- 1 root wheel0, 17 Jul 1 08:39 /dev/kbdmux0 > > r235646: > > $ fgrep -i kb /tmp/dmesg-r235646.txt > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > atkbdc0 failed to probe at port 0x60 on isa0 > > $ ls -l /dev/kb* > lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 -> kbdmux0 > crw--- 1 root wheel0, 17 Jul 1 08:39 /dev/kbdmux0 > > the complete /tmp/dmesg-r21.txt is attached, the > /tmp/dmesg-r235646.txt was in some message of this thread; > > So the question is: why the is not > detected anymore in r235646, while it is in r21? > > Thanks > > matthias ___ 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: SVN2CVS exporter down
On Mon, Jul 02, 2012 at 10:55:57PM +0100, Simon L. B. Nielsen wrote: > Tested patches are accepted > (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even better - > work on killing off CVS sooner rather than later. I like the latter. :-) As we discussed at BSDcan -- I don't use CVS at all for src or docs. I use a svnsync'ed mirror at home and $WORK. :-) It works great. -- -- David (obr...@freebsd.org) ___ 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"
10.0-CURRENT: kernel: Fatal trap 12: page fault while in kernel mode
The most recent build of FreeBSD 10.0-CURRENT crashes on one of our boxes with recent Intel hardware, see dmesg extract below. FreeBSD does obviously only crash on hardware with modern "Sandy-Bridge" hardware, the very same kernel config and a very similar setup does work very well on an older Intel Core2Dua architecture. Machine in question runs an older kernel (set via nextboot -k kernel.old) very well: FreeBSD 10.0-CURRENT #0 r237697: Thu Jun 28 11:45:08 CEST 2012 Most recent buildworls/kernels crash after going into multiuser mode (/etc/rc-scripts getting executed). Below the kernel trap message. I do this report on the fly, so if there is need for deeper investigations let me know, I will provide necessary detail requested. Regards, Oliver Jul 2 13:34:26 sb211 kernel: Fatal trap 12: page fault while in kernel mode Jul 2 13:34:26 sb211 kernel: cpuid = 3; apic id = 03 Jul 2 13:34:26 sb211 kernel: fault virtual address = 0x6c Jul 2 13:34:26 sb211 kernel: fault code = supervisor read data, page not present Jul 2 13:34:26 sb211 kernel: instruction pointer = 0x20:0x807ed8e0 Jul 2 13:34:26 sb211 kernel: stack pointer = 0x28:0xff88c5d5e570 Jul 2 13:34:26 sb211 kernel: frame pointer = 0x28:0xff88c5d5e620 Jul 2 13:34:26 sb211 kernel: code segment= base 0x0, limit 0xf, type 0x1b Jul 2 13:34:26 sb211 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jul 2 13:34:26 sb211 kernel: processor eflags= interrupt enabled, resume, IOPL = 0 Jul 2 13:41:47 sb211 syslogd: kernel boot file is /boot/kernel/kernel Jul 2 13:41:47 sb211 kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jul 2 13:41:47 sb211 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 2 13:41:47 sb211 kernel: The Regents of the University of California. All rights reserved. Jul 2 13:41:47 sb211 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 2 13:41:47 sb211 kernel: FreeBSD 10.0-CURRENT #0 r237995: Mon Jul 2 14:49:08 CEST 2012 Jul 2 13:41:47 sb211 kernel: r...@sb211.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/sb211 amd64 Jul 2 13:41:47 sb211 kernel: module_register: module enc already exists! Jul 2 13:41:47 sb211 kernel: Module enc failed to register: 17 Jul 2 13:41:47 sb211 kernel: CPU: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz (3209.59-MHz K8-class CPU) Jul 2 13:41:47 sb211 kernel: Origin = "GenuineIntel" Id = 0x206d7 Family = 6 Model = 2d Stepping = 7 Jul 2 13:41:47 sb211 kernel: Features=0xbfebfbff Jul 2 13:41:47 sb211 kernel: Features2=0x1fbee3bf Jul 2 13:41:47 sb211 kernel: AMD Features=0x2c100800 Jul 2 13:41:47 sb211 kernel: AMD Features2=0x1 Jul 2 13:41:47 sb211 kernel: TSC: P-state invariant, performance statistics Jul 2 13:41:47 sb211 kernel: real memory = 34359738368 (32768 MB) Jul 2 13:41:47 sb211 kernel: avail memory = 33072930816 (31540 MB) Jul 2 13:41:47 sb211 kernel: Event timer "LAPIC" quality 600 Jul 2 13:41:47 sb211 kernel: ACPI APIC Table: Jul 2 13:41:47 sb211 kernel: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs Jul 2 13:41:47 sb211 kernel: FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads signature.asc Description: OpenPGP digital signature
