Re: files disappearing from ls on NFS
On Mon, 6 May 2013, Rick Macklem wrote:
RMHartmut Brandt wrote:
RM Hi Rick,
RM
RM the patch doesn't help. So how can I help to fix that? Of course, I
RM can use the work-around with oldnfs, but ...
RM
RMWell, I plan on going through the readdir code and seeing if I can spot
RMa case that would break for small RPC replies. If I can find something,
RMI'll email you a patch for testing. (I can't seem to reproduce the problem
RMhere.)
RM
RMThe mysterious part for me is why it has shown up recently, because there
RMhasn't been any recent change committed that seems like it could cause this.
RM(Maybe it is just a co-incidence that it showed up recently and the bug has
RM been there all along?)
RM
RMI'll admit my worst fear is that is somehow caused by the switch to clang for
RMcertain arches. If that is the case, it could take a long time to isolate.
I'm quite sure that I've build the system in February with clang already.
But in march or so a new clang version was committed.
harti
RM -Original Message-
RM From: Rick Macklem [mailto:rmack...@uoguelph.ca]
RM Sent: Saturday, May 04, 2013 11:33 PM
RM To: Brandt, Hartmut
RM Cc: curr...@freebsd.org; Andrzej Tobola
RM Subject: Re: files disappearing from ls on NFS
RM
RM Hartmut Brandt wrote:
RM On Fri, 3 May 2013, Rick Macklem wrote:
RM
RM RMOk, if you succeed in isolating the commit, that would be great.
RM
RM Hmm. I'm somewhat stuck. clang from yesterday can't compile clang
RM from
RM a month ago...
RM
RM harti
RM
RM Oh well. You could try this patch (which is the one to fix readdir for
RM union mounts), since I can see that VOP_VPTOCNP() will also be broken
RM without it. (I can't see how that would break ls, but it breaks
RM __getcwd() and friends, so maybe it can affect ls somehow?)
RM
RM It's a cut/paste under windows, so I'm afraid the whitespace will be
RM messed up, but it's pretty simple to apply by hand.
RM
RM Index: nfs_clvnops.c
RM ===
RM --- nfs_clvnops.c (revision 249568)
RM +++ nfs_clvnops.c (working copy)
RM @@ -2221,6 +2221,7 @@
RM !NFS_TIMESPEC_COMPARE(np-n_mtime, vattr.va_mtime)) {
RM mtx_unlock(np-n_mtx);
RM NFSINCRGLOBAL(newnfsstats.direofcache_hits);
RM + *ap-a_eofflag = 1;
RM return (0);
RM } else
RM mtx_unlock(np-n_mtx); @@ -2233,8 +2234,10 @@
RM tresid = uio-uio_resid;
RM error = ncl_bioread(vp, uio, 0, ap-a_cred);
RM
RM - if (!error uio-uio_resid == tresid)
RM + if (!error uio-uio_resid == tresid) {
RM NFSINCRGLOBAL(newnfsstats.direofcache_misses);
RM + *ap-a_eofflag = 1;
RM + }
RM return (error);
RM }
RM
RM I haven't yet succeeded in reproducing the problem, but will be poking
RM at it some more, rick
RM
RM RM
RM RMrick
RM RM
RM RM harti
RM RM
RM RM On Fri, 3 May 2013, Rick Macklem wrote:
RM RM
RM RM RMHartmut Brandt wrote:
RM RM RM Hi,
RM RM RM
RM RM RM I've updated one of my -current machines this week
RM (previous
RM RM update
RM RM RM was in
RM RM RM february). Now I see a strange effect (it seems only on
RM NFS
RM RM mounts):
RM RM RM ls or
RM RM RM even echo * will list only some files (strange enough the
RM first
RM RM files
RM RM RM from
RM RM RM the normal, alphabetically ordered list). If I change
RM something
RM RM in the
RM RM RM directory (delete a file or create a new one) for some
RM time
RM the
RM RM RM complete
RM RM RM listing will appear but after sime time (seconds to a
RM minute
RM or
RM RM so)
RM RM RM again
RM RM RM only part of the files is listed.
RM RM RM
RM RM RM A ktrace on ls /usr/src/lib/libc/gen shows that
RM getdirentries is
RM RM RM called
RM RM RM only once (returning 4096). For a full listing
RM getdirentries
RM is
RM RM called
RM RM RM 5
RM RM RM times with the last returning 0.
RM RM RM
RM RM RM I can still open files that are not listed if I know their
RM name,
RM RM RM though.
RM RM RM
RM RM RM The NFS server is a Windows 2008 server with an OpenText
RM NFS
RM RM Server
RM RM RM which
RM RM RM works without problems to all the other FreeBSD machines.
RM RM RM
RM RM RM So what could that be?
RM RM RM
RM RM RMSomeone else reported missing files returned via ls
RM recently,
RM RM when
RM RM RMthey used a small readdirsize (below 8K). I haven't yet had
RM a
RM RM change to try
RM RM RMand reproduce it or do any snooping around.
RM RM RM
RM RM RMThere haven't been any recent changes to readdir in the NFS
RM client,
RM RM RMexcept a trivial one that adds a check for vnode type being
RM VDIR,
RM RM RMso I don't see that it can be a recent NFS change.
RM RM RM
RM RM RMIf you can increase the readdirsize, try that to see if it
RM avoids
RM RM RMthe problem. nfsstat -m shows you what the mount options
RM end
RM up
RM RM RMbeing after doing the mount. The server might be limiting
RM the
RM RM readdirsize
RM RM RMto 4K, so you should check, even if you specify a large
RM value
RM for
RM RM RMthe mount.
RM RM RM
RM RM RMrick
RM RM RM
[head tinderbox] failure on arm/arm
TB --- 2013-05-07 05:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-05-07 05:10:19 - 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 --- 2013-05-07 05:10:19 - starting HEAD tinderbox run for arm/arm
TB --- 2013-05-07 05:10:19 - cleaning the object tree
TB --- 2013-05-07 05:11:34 - /usr/local/bin/svn stat /src
TB --- 2013-05-07 05:11:37 - At svn revision 250322
TB --- 2013-05-07 05:11:38 - building world
TB --- 2013-05-07 05:11:38 - CROSS_BUILD_TESTING=YES
TB --- 2013-05-07 05:11:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-05-07 05:11:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-05-07 05:11:38 - SRCCONF=/dev/null
TB --- 2013-05-07 05:11:38 - TARGET=arm
TB --- 2013-05-07 05:11:38 - TARGET_ARCH=arm
TB --- 2013-05-07 05:11:38 - TZ=UTC
TB --- 2013-05-07 05:11:38 - __MAKE_CONF=/dev/null
TB --- 2013-05-07 05:11:38 - cd /src
TB --- 2013-05-07 05:11:38 - /usr/bin/make -B buildworld
Building an up-to-date make(1)
World build started on Tue May 7 05:11:43 UTC 2013
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 May 7 08:13:24 UTC 2013
TB --- 2013-05-07 08:13:24 - generating LINT kernel config
TB --- 2013-05-07 08:13:24 - cd /src/sys/arm/conf
TB --- 2013-05-07 08:13:24 - /usr/bin/make -B LINT
TB --- 2013-05-07 08:13:24 - cd /src/sys/arm/conf
TB --- 2013-05-07 08:13:24 - /usr/sbin/config -m LINT
TB --- 2013-05-07 08:13:24 - building LINT kernel
TB --- 2013-05-07 08:13:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-05-07 08:13:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-05-07 08:13:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-05-07 08:13:24 - SRCCONF=/dev/null
TB --- 2013-05-07 08:13:24 - TARGET=arm
TB --- 2013-05-07 08:13:24 - TARGET_ARCH=arm
TB --- 2013-05-07 08:13:24 - TZ=UTC
TB --- 2013-05-07 08:13:24 - __MAKE_CONF=/dev/null
TB --- 2013-05-07 08:13:24 - cd /src
TB --- 2013-05-07 08:13:24 - /usr/bin/make -B buildkernel KERNCONF=LINT
Kernel build for LINT started on Tue May 7 08:13:24 UTC 2013
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
[...]
~ ^ ~
/src/sys/arm/mv/common.c:1765:21: warning: comparison of unsigned expression =
0 is always true [-Wtautological-compare]
if (wintab-remap = 0 win_cpu_can_remap(i) != 1) {
~ ^ ~
/src/sys/arm/mv/common.c:884:1: error: unused function 'decode_win_sdram_fixup'
[-Werror,-Wunused-function]
decode_win_sdram_fixup(void)
^
4 warnings and 1 error generated.
*** [common.o] Error code 1
Stop in /obj/arm.arm/src/sys/LINT.
*** [buildkernel] Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2013-05-07 08:28:51 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-05-07 08:28:51 - ERROR: failed to build LINT kernel
TB --- 2013-05-07 08:28:51 - 9289.93 user 1641.05 system 11911.67 real
http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.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
problem building -current
Hi, I'm running an older -current: bewilderbeast/usr/src;uname -a FreeBSD bewilderbeast.blackhelicopters.org 10.0-CURRENT FreeBSD 10.0-CURRENT #15: Thu Nov 8 14:02:45 EST 2012 mwlu...@bewilderbeast.blackhelicopters.org:/usr/obj/usr/src/sys/G Trying to build new, and get: ... c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd10.0\ -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PluginLoader.cpp -o PluginLoader.o c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd10.0\ -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PrettyStackTrace.cpp -o PrettyStackTrace.o c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd10.0\ -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp -o Process.o In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp:85: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc: In member function 'virtual llvm::sys::TimeValue llvm::sys::self_process::get_user_time() const': /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc:75: error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in this scope *** [Process.o] Error code 1 Stop in /usr/src/lib/clang/libllvmsupport. *** [bootstrap-tools] Error code 1 Stop in /usr/src. *** [_bootstrap-tools] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. /etc/src.conf: SENDMAIL_MC=/etc/mail/bwb.mc WITHOUT_BIND=YES SENDMAIL_MC=/etc/mail/bwb.mc PERL_VERSION=5.10.1 WITHOUT_PKGNG=yes # added by use.perl 2012-11-15 11:47:34 PERL_VERSION=5.14.2 I don't see any references to this error anywhere in the FreeBSD lists. Any ideas how to get past it? Or should I just upgrade from snapshot and try again? Thanks, ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code ILUVMICHAEL gets you 30% off helps me. ___ 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: Light humour
Paul Webster wrote on 28.04.2013 02:31: Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ antibsd.wordpress.com is no longer available. The authors have deleted this site. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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 building -current
On 7 May 2013 17:21, Michael W. Lucas mwlu...@michaelwlucas.com wrote: Hi, I'm running an older -current: bewilderbeast/usr/src;uname -a FreeBSD bewilderbeast.blackhelicopters.org 10.0-CURRENT FreeBSD 10.0-CURRENT #15: Thu Nov 8 14:02:45 EST 2012 mwlu...@bewilderbeast.blackhelicopters.org:/usr/obj/usr/src/sys/G Trying to build new, and get: ... c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd10.0\ -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp -o Process.o In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp:85: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc: In member function 'virtual llvm::sys::TimeValue llvm::sys::self_process::get_user_time() const': /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc:75: error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in this scope *** [Process.o] Error code 1 You can try to install this change into your /usr/include/time.h and try again. http://svnweb.freebsd.org/base?view=revisionrevision=245428 --- head/include/time.h 2013/01/14 17:41:04 245427 +++ head/include/time.h 2013/01/14 18:01:19 245428 @@ -112,6 +112,7 @@ #define CLOCK_MONOTONIC_FAST 12 /* FreeBSD-specific. */ #define CLOCK_SECOND 13 /* FreeBSD-specific. */ #define CLOCK_THREAD_CPUTIME_ID14 +#defineCLOCK_PROCESS_CPUTIME_ID15 #endif /* !defined(CLOCK_REALTIME) __POSIX_VISIBLE = 200112 */ #if !defined(TIMER_ABSTIME) __POSIX_VISIBLE = 200112 -- wbr, pluknet ___ 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 building -current
On 2013-05-07 16:01, Sergey Kandaurov wrote: On 7 May 2013 17:21, Michael W. Lucas mwlu...@michaelwlucas.com wrote: ... c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd10.0\ -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp -o Process.o In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp:85: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc: In member function 'virtual llvm::sys::TimeValue llvm::sys::self_process::get_user_time() const': /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc:75: error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in this scope *** [Process.o] Error code 1 You can try to install this change into your /usr/include/time.h and try again. http://svnweb.freebsd.org/base?view=revisionrevision=245428 --- head/include/time.h 2013/01/14 17:41:04 245427 +++ head/include/time.h 2013/01/14 18:01:19 245428 @@ -112,6 +112,7 @@ #define CLOCK_MONOTONIC_FAST 12 /* FreeBSD-specific. */ #define CLOCK_SECOND 13 /* FreeBSD-specific. */ #define CLOCK_THREAD_CPUTIME_ID 14 +#defineCLOCK_PROCESS_CPUTIME_ID15 #endif /* !defined(CLOCK_REALTIME) __POSIX_VISIBLE = 200112 */ #if !defined(TIMER_ABSTIME) __POSIX_VISIBLE = 200112 Yes, this is an annoying problem. When the CLOCK_PROCESS_CPUTIME_ID support was originally added, it was only put in sys/time.h, not in time.h. So any application that includes the latter will not be able to use the define. There are multiple possibilities to solve this, but I'm thinking of putting a -DCLOCK_PROCESS_CPUTIME_ID=15 on the command line for older versions of -current... -Dimitry ___ 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: Light humour
On 5/7/13 6:38 AM, Ruslan Makhmatkhanov wrote: Paul Webster wrote on 28.04.2013 02:31: Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ antibsd.wordpress.com is no longer available. The authors have deleted this site. that must have been a LOT of work to write... why would one delete it? ___ 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: Light humour
On Tue, May 7, 2013 at 6:24 PM, Julian Elischer jul...@freebsd.org wrote: On 5/7/13 6:38 AM, Ruslan Makhmatkhanov wrote: Paul Webster wrote on 28.04.2013 02:31: Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ antibsd.wordpress.com is no longer available. The authors have deleted this site. that must have been a LOT of work to write... why would one delete it? Maybe they found out that their blog was hosted on a BSD platform? :) -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: x11/nvidia-driver-173 build failed on CURRENT
On Mon, 06 May 2013 14:14:04 +0200, Dimitry Andric d...@freebsd.org wrote:
/wrkdirs/usr/ports/x11/nvidia-driver-173/work/NVIDIA-FreeBSD-x86-173.14.35/src/nv-freebsd.h:145:11:
note: previous declaration is here
RM_STATUS os_alloc_contig_pages(void **, U032);
^
Please try the attached patch. I am not sure if there are more driver
versions that include these inconsisent prototypes, but if anybody is
aware of them, we can adjust the ${NVVERSION} check a little.
Thanks so much for the patch, it worked for me.
___
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
[UPDATE] sysutils/bsdconfig snapshot
Hello, I've taken a new snapshot of HEAD usr.sbin/bsdconfig and made it available through the ports tree (as sysutils/bsdconfig). The last snapshot was quite some time months ago, so a lot has changed since then. Most notably, we now have the beginnings of the package management module, edging ever-closer to a 1.0 release status. I'd like to see if there are any interested folks out there that could give my updated version a go and provide some feedback. Any/all feedback would be greatly appreciated. Just an FYI however… this code is only expected to work on 9.0-R or higher. -- Cheers, 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: [UPDATE] sysutils/bsdconfig snapshot
(replying to my own request with some additional details on what to try in this update) On May 7, 2013, at 1:36 PM, Teske, Devin wrote: Hello, I've taken a new snapshot of HEAD usr.sbin/bsdconfig and made it available through the ports tree (as sysutils/bsdconfig). The last snapshot was quite some time months ago, so a lot has changed since then. Files have moved, there's now a /usr/share/bsdconfig directory for shared include files, and the fake language files have been removed. That's what you'll notice from what the new port installs. Most notably, we now have the beginnings of the package management module, edging ever-closer to a 1.0 release status. Of which it's important to note that this initial work is based on the old pkg_tools and not pkgng. We'll convert it to pkgng later, but first we need to make sure the framework for interacting with huge package data is usable. One of the challenges in testing this feature is that on 9.1, there aren't any packages available (yet; that should change eventually -- being restored retroactively). However, if you don't use the FTP media types, you'll get a lot further. What I've been using as a test is to download the 9.0-RELEASE packages/INDEX file and throw that into a local packages directory and then point the Directory media type at the parent directory where the packages directory was created. For example, … cd /tmp mkdir packages fetch ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/9.0-RELEASE/packages/INDEX Then use the Directory media type and enter a value of /tmp. The packages/INDEX file will be found in the media (/tmp directory) and the the packages interface will then be presented. If you're already running 9.0-RELEASE, then you can choose the FTP Passive media type, then choose the second menu item title URL and enter the URL ftp://ftp-archive.freebsd.org;. ASIDE: /me notes that he really ought to change the FTP routine to use a default $FTPMODE of auto instead of active (currently, FTP means explicitly active, and FTP Passive means explicitly passive). Once you're in the package interface, you will see: 1. List of package categories. NOTE: For a package category to be listed, it has to have at least one package. This list also includes a dummy category named All. 2. For each category (including the All dummy category), the number of: 2.a. packages available in that category 2.b. packages that are installed from that category 2.c. selected packages (a selected package is one that has been been marked for install, re-install, un-install, or marked as a dependency of a package to install/re-install) are displayed. 3. Above the category list is a Review menu item. Use this to review the selections you've made. Choosing a category intuitively displays the packages available from that category. In the list of packages, packages that are already installed are marked with an X; those marked for install have an I; re-install have an R; un-install, U; and dependencies are marked with a D. Selecting a package that is not marked will turn the mark into an I. Selecting a package that is marked with an X will bring up a menu asking if you would like to mark it for Uninstall, Re-install, or return it back to just being installed. Selecting a package that is marked as a dependency turns it into a package requested for installation (D mark becomes I mark). If without leaving the package selection screen you then re-select the same package (which was a dependency turned into an I), the mark goes away, but if you exit and return to the package selection menu, the mark is restored as a D. This is because package dependencies are not calculated until you return to the category list (when counts must be updated). When you're navigating the menus, you may notice an asterisk (*) on some menu items. This indicates that a page has been cached. Unlike sysinstall which would spend ~10 minutes (on my hardware) processing the INDEX file, building the in-memory structures for all category submenus, bsdconfig only generates the menus you request, and does them on-the-fly. The first time you are presented with the list of package categories, no category has an asterisk next to it. The first time you enter a package category, this is a small 1-5 second delay (depending on hardware) to generate the menu(s) for that category. When you return to the category list, that category will now have an asterisk displayed next to it to let you know: a. this category has been visited and b. the menus have been cached in-memory so re-entering this category will be fast (less than one second). Another notable feature once you get to the package menus is that not all packages are displayed on one page. There is a global PACKAGES_MENU_SIZE which defaults to 2000 and sets the maximum number of packages that can appear on one page (in contrast, sysinstall would display all 21,000+
Re: Problem with firewire disks with recent -CURRENT.
rmt...@servalan.servalan.com writes:
Tried upgrading one of my machines to -CURRENT yesterday and got the
following panic when the sbp code did its probing of all the firewire
devices:
panic: mutex sbp not owned at /usr/src/sys/cam/cam_xpt.c:4549
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff81fe6837f0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff81fe6838a0
vpanic() at vpanic+0x126/frame 0xff81fe6838e0
panic() at panic+0x43/frame 0xff81fe683940
__mtx_assert() at __mtx_assert+0xc2/frame 0xff81fe683950
xpt_compile_path() at xpt_compile_path+0xa1/frame 0xff81fe6839a0
xpt_create_path() at xpt_create_path+0x5b/frame 0xff81fe6839f0
sbp_do_attach() at sbp_do_attach+0xe8/frame 0xff81fe683a30
I did some further poking around in the source code trying to figure out what
went on here. Looks to me like in the current version of xpt_find_target()
(called by xpt_compile_path() and hence, indirectly, by xpt_create_path() )
the code expects the SIM's mutex to be owned, but apparently the call from
the sbp_do_attach happens without the SIM mutex being locked. I tried hacking
together the following patch and the resulting kernel comes up and lets the
system properly detect the drives and do I/O to them. I don't know enough
about the CAM system and its locking to know if this patch is the Right
Thing to do here, though.
diff -r 96ce948dd944 sys/dev/firewire/sbp.c
--- a/sys/dev/firewire/sbp.cSat May 04 17:23:33 2013 -0500
+++ b/sys/dev/firewire/sbp.cTue May 07 19:17:28 2013 -0500
@@ -1085,10 +1085,13 @@
END_DEBUG
sbp_xfer_free(xfer);
- if (sdev-path == NULL)
+if (sdev-path == NULL) {
+ CAM_SIM_LOCK(target-sbp-sim);
xpt_create_path(sdev-path, NULL,
cam_sim_path(target-sbp-sim),
target-target_id, sdev-lun_id);
+CAM_SIM_UNLOCK(target-sbp-sim);
+ }
/*
* Let CAM scan the bus if we are in the boot process.
___
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
build kernel fail on 250341 in vxge...
FYI: fresh buildworld and buildkernel tonight with 250341 and I see a bunch of errors while building vxge like this (my kernel config file has device vx commented out btw). Any pointers/help ? I'm building this on my build machine which is FreeBSD 10.0-CURRENT #26 r250314: Mon May 6 20:32:29 CDT 2013 === vxge (all) snip ERROR: vxgehal-channel.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-mm.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxge-queue.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-blockpool.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-fifo.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-ring.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-config.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-doorbells.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-ifmsg.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-device.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-srpcim.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-mgmt.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxge.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-virtualpath.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-mrpcim.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 ERROR: vxgehal-mgmtaux.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 1023 /snip Then, after zlib, it bombs: === zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -i nclude /usr/obj/usr/src/sys/MACKGEN/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-omit-frame-poi nter -I/usr/obj/usr/src/sys/MACKGEN -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msof t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-argumen ts -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpo inter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdi agnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit y -c /usr/src/sys/modules/zlib/../../net/zlib.c ctfconvert -L VERSION -g zlib.o ld -d -warn-common -r -d -o zlib.ko.debug zlib.o ctfmerge -L VERSION -g -o zlib.ko.debug zlib.o : export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | xargs -J% objcopy % zlib.ko.debug objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error ___ 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: panic in sctp_del_addr_from_vrf() ?
I tried by analogy your patch add _padalign in all places where was before r250300, and in stcp. Uptime now 15hours, before - 5min - 3hour max. I waiting for more statistic. my changes: Index: sys/netinet/tcp_subr.c === --- sys/netinet/tcp_subr.c (revision 250330) +++ sys/netinet/tcp_subr.c (working copy) @@ -255,7 +255,7 @@ #define V_tcpcb_zone VNET(tcpcb_zone) MALLOC_DEFINE(M_TCPLOG, tcplog, TCP address and flags print buffers); -static struct mtx isn_mtx; +static struct mtx_padalign isn_mtx; #define ISN_LOCK_INIT() mtx_init(isn_mtx, isn_mtx, NULL, MTX_DEF) #define ISN_LOCK() mtx_lock(isn_mtx) Index: sys/netinet/in_pcb.h === --- sys/netinet/in_pcb.h (revision 250330) +++ sys/netinet/in_pcb.h (working copy) @@ -330,7 +330,7 @@ /* * Global lock protecting non-pcbgroup hash lookup tables. */ - struct rwlock ipi_hash_lock; + struct rwlock_padalign ipi_hash_lock; /* * Global hash of inpcbs, hashed by local and foreign addresses and Index: sys/netinet/in_var.h === --- sys/netinet/in_var.h (revision 250330) +++ sys/netinet/in_var.h (working copy) @@ -116,7 +116,7 @@ #define INADDR_HASH(x) \ (V_in_ifaddrhashtbl[INADDR_HASHVAL(x) V_in_ifaddrhmask]) -extern struct rwlock in_ifaddr_lock; +extern struct rwlock_padalign in_ifaddr_lock; #define IN_IFADDR_LOCK_ASSERT() rw_assert(in_ifaddr_lock, RA_LOCKED) #define IN_IFADDR_RLOCK() rw_rlock(in_ifaddr_lock) Index: sys/netinet/sctp_pcb.h === --- sys/netinet/sctp_pcb.h (revision 250330) +++ sys/netinet/sctp_pcb.h (working copy) @@ -193,11 +193,11 @@ sctp_zone_t ipi_zone_asconf; sctp_zone_t ipi_zone_asconf_ack; - struct rwlock ipi_ep_mtx; - struct mtx ipi_iterator_wq_mtx; - struct rwlock ipi_addr_mtx; - struct mtx ipi_pktlog_mtx; - struct mtx wq_addr_mtx; + struct rwlock_padalign ipi_ep_mtx; + struct mtx_padalign ipi_iterator_wq_mtx; + struct rwlock_padalign ipi_addr_mtx; + struct mtx_padalign ipi_pktlog_mtx; + struct mtx_padalign wq_addr_mtx; uint32_t ipi_count_ep; /* assoc/tcb zone info */ Index: sys/netinet/ip_id.c === --- sys/netinet/ip_id.c (revision 250330) +++ sys/netinet/ip_id.c (working copy) @@ -97,7 +97,7 @@ static int array_size = 8192; static int random_id_collisions = 0; static int random_id_total = 0; -static struct mtx ip_id_mtx; +static struct mtx_padalign ip_id_mtx; static void ip_initid(void); static int sysctl_ip_id_change(SYSCTL_HANDLER_ARGS); Index: sys/netinet/ip_input.c === --- sys/netinet/ip_input.c (revision 250330) +++ sys/netinet/ip_input.c (working copy) @@ -85,7 +85,7 @@ CTASSERT(sizeof(struct ip) == 20); #endif -struct rwlock in_ifaddr_lock; +struct rwlock_padalign in_ifaddr_lock; RW_SYSINIT(in_ifaddr_lock, in_ifaddr_lock, in_ifaddr_lock); VNET_DEFINE(int, rsvp_on); @@ -155,7 +155,7 @@ static VNET_DEFINE(uma_zone_t, ipq_zone); static VNET_DEFINE(TAILQ_HEAD(ipqhead, ipq), ipq[IPREASS_NHASH]); -static struct mtx ipqlock; +static struct mtx_padalign ipqlock; #define V_ipq_zone VNET(ipq_zone) #define V_ipq VNET(ipq) Index: sys/sys/socketvar.h === --- sys/sys/socketvar.h (revision 250330) +++ sys/sys/socketvar.h (working copy) @@ -133,7 +133,7 @@ * avoid defining a lock order between listen and accept sockets * until such time as it proves to be a good idea. */ -extern struct mtx accept_mtx; +extern struct mtx_padalign accept_mtx; #define ACCEPT_LOCK_ASSERT() mtx_assert(accept_mtx, MA_OWNED) #define ACCEPT_UNLOCK_ASSERT() mtx_assert(accept_mtx, MA_NOTOWNED) #define ACCEPT_LOCK() mtx_lock(accept_mtx) Index: sys/kern/uipc_socket.c === --- sys/kern/uipc_socket.c (revision 250330) +++ sys/kern/uipc_socket.c (working copy) @@ -240,14 +240,14 @@ * accept_mtx locks down per-socket fields relating to accept queues. See * socketvar.h for an annotation of the protected fields of struct socket. */ -struct mtx accept_mtx; +struct mtx_padalign accept_mtx; MTX_SYSINIT(accept_mtx, accept_mtx, accept, MTX_DEF); /* * so_global_mtx protects so_gencnt, numopensockets, and the per-socket * so_gencnt field. */ -static struct mtx so_global_mtx;
