Re: What to do about RCS/OpenRCS
On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni p...@freebsd.org wrote: Hi; I guess I see the following options: 1) Just leave GNU RCS in the tree. 2) Improve OpenRCS so it can be swapped in. 3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate) and import just a /bin/ident binary (perhaps from OpenRCS). Both 2) and 3) require some work. I suspect 3) requires less. :) I honestly don't see a real problem with (1): we do want to replace as much GNU software as we can but not at the cost of making our life unnecessarily difficult. To be honest I'm not entirely sure what's the real reason of this crusade. FreeBSD can't import newer version of some components of the toolchain (e.g. compiler, linker, debugger) and some of them are slowly (or less slowly) bitrotting. I feel that in that case there's a real goal which justifies all the headache derived from the conversion. For GNU RCS, I'm not completely sure there is. I've never heard anybody complaining about lack of features for RCS or bugs. My $0.02, I suspect very few people really rely on it and just complain for the sake of doing it, but I'm not gonna argue on this further. That said, unfortunately there's a lot more than doing the conversion and fixing the code so that the testsuite will pass. You need to upstream the fixes and so deal with another layer and other maintainers otherwise the code in base and the one upstream will diverge. People rely from time to time on bugs of old software (e.g. single vs double dash options) and are gonna complain. The testsuite, even if comprehensive, unlikely will cover some corner cases and suddenly software will start breaking. In other words, a lot of (unneeded) work for you for a software that just worked fine(TM) until yesterday. I'm not gonna stop you from doing this, but I learned the hard way that it's something that can/should be avoided unless really necessary (and a better license doesn't seem to be a strong enough reason, IMHO). -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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 on current amd64
On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar n...@pozo.com wrote: I get the following panic on current svn ver r280793: Revert to r280784. This should fix. ___ 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: pf crash on -current
On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude allanj...@freebsd.org wrote: Upgraded my router today, because it was approaching the 24 uptime days of doom Now, it likes to die on me, a lot The bt you posted suggest this could be stack overflow, probably due to infinite recursion. Also, as a wild guess, just looking at the stacktrace, I think this might be related to the recent ipv6 fragment changes. Try to back them out, and see if things gets more stable ( r278831 and r278843). -- Davide ___ 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
default pager (csh)
Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: default pager (csh)
On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall mcdou...@egr.msu.edu wrote: The PAGER was less for about half a year and reverted. Please see: https://svnweb.freebsd.org/base?view=revisionrevision=242643 ___ 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 OK, I think this ends the discussion =) Thanks! -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] nmbclusters should be always positive
Currently, the following is allowed in FreeBSD:
root@rabbit1:/home/davide/udp-clt # sysctl kern.ipc.nmbclusters=2147483647
kern.ipc.nmbclusters: 2036598 - -2147483648
The following is an attempt of fixing.
I also think nmbcluster should actually be u_int and not it, but this
is a discussion for another day, maybe.
diff --git a/sys/kern/kern_mbuf.c b/sys/kern/kern_mbuf.c
index 7ab6509..15b38a9 100644
--- a/sys/kern/kern_mbuf.c
+++ b/sys/kern/kern_mbuf.c
@@ -162,7 +162,7 @@ sysctl_nmbclusters(SYSCTL_HANDLER_ARGS)
newnmbclusters = nmbclusters;
error = sysctl_handle_int(oidp, newnmbclusters, 0, req);
if (error == 0 req-newptr newnmbclusters != nmbclusters) {
- if (newnmbclusters nmbclusters
+ if (newnmbclusters 0 newnmbclusters nmbclusters
nmbufs = nmbclusters + nmbjumbop + nmbjumbo9 +
nmbjumbo16) {
nmbclusters = newnmbclusters;
nmbclusters = uma_zone_set_max(zone_clust, nmbclusters);
--
Davide
There are no solved problems; there are only problems that are more
or less solved -- Henri Poincare
___
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: RFC: Remove pty(4)
On Thu, Nov 27, 2014 at 10:37 AM, Alfred Perlstein bri...@mu.org wrote: On Nov 27, 2014, at 1:52 AM, Konstantin Belousov wrote: On Wed, Nov 26, 2014 at 04:41:27PM -0800, Davide Italiano wrote: On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. Why this is good thing to do ? It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and userspace loops over ptyXX and after it successfully opens it tries to open the other one with the same suffix. So, having a single device is not really enough. My option, instead, is that of removing pty(4), which is nothing more than a compatibility driver, and move pmtx(4) code somewhere else. The main drawback of the removal of this is that it makes impossible to run FreeBSD = 7 jails and SSH into them. I personally don't consider this a huge issue, in light of the fact that FreeBSD-7 has been EOL for a long time, but I would like to hear other people comments. You don't, but other people care about ABI. Besides older jails which you do not care about, there is significant set of programs which were coded to use Berkley' pty directly. Even high-profile applications like Emacs automatically selected pty(4) up to its previous version on FreeBSD. The code review for the proposed change can be found here: https://reviews.freebsd.org/D659 If I won't get any objection I'll commit this in one week time, i.e. August 27th. Why not just statically create the pairs in /dev? Use some loader tunable (kern.ptymax) to set a count on the number of pre-created device pairs to create and then just explicitly create them in the mod_event handler? It could default to 100 or so. Done, thank you for the suggestion, John. root@maxwell:/home/davide # kldload pty root@maxwell/home/davide # sysctl -a |grep pty kern.tty_pty_warningcnt: 1 kern.npty: 32 debug.softdep.emptyjblocks: 0 root@maxwell:/home/davide # ls /dev/pty* /dev/ptyl0 /dev/ptyl2 /dev/ptyl4 /dev/ptyl6 /dev/ptyl8 /dev/ptyla /dev/ptylc /dev/ptyle /dev/ptylg /dev/ptyli /dev/ptylk /dev/ptylm /dev/ptylo /dev/ptylq /dev/ptyls /dev/ptylu /dev/ptyl1 /dev/ptyl3 /dev/ptyl5 /dev/ptyl7 /dev/ptyl9 /dev/ptylb /dev/ptyld /dev/ptylf /dev/ptylh /dev/ptylj /dev/ptyll /dev/ptyln /dev/ptylp /dev/ptylr /dev/ptylt /dev/ptylv https://reviews.freebsd.org/D1238 for review. I hope anybody that raised concerns about the previous patch can try this new one. I do not see why dev_clone event makes your so unhappy. I object against removal of it (and this is what you are aiming at, it seems). It provides useful functionality, which is not substituted by anything cdevpriv(9) can provide. My only hope is that you are confusing dev_clone event and a library of clone_create(9)/clone_cleanup(9)/dev_stdclone(9) functions. The former is needed and cannot be replaced by cdevpriv(9). The later is clumsy and never was used properly. My opinion is that it is impossible to use properly. There are five uses of that in tree left, and it seems that removing them worth cleaning of buggy by design and undocumented KPI. Really big and complicated target is the hand-written timeout-based (?!) custom cloning code in snd(4). I believe it _can_ be converted to cdevpriv(9). All right, I dropped the review and reverted my branch. Thanks for the comment(s). -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: RFC: Remove pty(4)
On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and userspace loops over ptyXX and after it successfully opens it tries to open the other one with the same suffix. So, having a single device is not really enough. My option, instead, is that of removing pty(4), which is nothing more than a compatibility driver, and move pmtx(4) code somewhere else. The main drawback of the removal of this is that it makes impossible to run FreeBSD = 7 jails and SSH into them. I personally don't consider this a huge issue, in light of the fact that FreeBSD-7 has been EOL for a long time, but I would like to hear other people comments. The code review for the proposed change can be found here: https://reviews.freebsd.org/D659 If I won't get any objection I'll commit this in one week time, i.e. August 27th. Why not just statically create the pairs in /dev? Use some loader tunable (kern.ptymax) to set a count on the number of pre-created device pairs to create and then just explicitly create them in the mod_event handler? It could default to 100 or so. Done, thank you for the suggestion, John. root@maxwell:/home/davide # kldload pty root@maxwell/home/davide # sysctl -a |grep pty kern.tty_pty_warningcnt: 1 kern.npty: 32 debug.softdep.emptyjblocks: 0 root@maxwell:/home/davide # ls /dev/pty* /dev/ptyl0 /dev/ptyl2 /dev/ptyl4 /dev/ptyl6 /dev/ptyl8 /dev/ptyla /dev/ptylc /dev/ptyle /dev/ptylg /dev/ptyli /dev/ptylk /dev/ptylm /dev/ptylo /dev/ptylq /dev/ptyls /dev/ptylu /dev/ptyl1 /dev/ptyl3 /dev/ptyl5 /dev/ptyl7 /dev/ptyl9 /dev/ptylb /dev/ptyld /dev/ptylf /dev/ptylh /dev/ptylj /dev/ptyll /dev/ptyln /dev/ptylp /dev/ptylr /dev/ptylt /dev/ptylv https://reviews.freebsd.org/D1238 for review. I hope anybody that raised concerns about the previous patch can try this new one. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Unbreak makefs -M
r258695 introduces a sanity check for makefs in order to verify that minimum image size specified is always less than maximum image size. If makefs(1) is invoked specifying minimum image size, but not maximum one, the program exits with an error. Example: # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the minimum and maximum sizes to bsize. I guess it's meaningful to assert that minsize maxsize iff maxsize is actually specified. The following patch tries to fix the problem. Visual inspection of code also shows that maxsize == 0 is treated as maxsize not specified. I'm not by any means familiar with makefs(1) code, so I may miss something here. % git diff diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c index 92d5508..83e9eae 100644 --- a/usr.sbin/makefs/ffs.c +++ b/usr.sbin/makefs/ffs.c @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, fsinfo_t *fsopts) if (ffs_opts-avgfpdir == -1) ffs_opts-avgfpdir = AFPDIR; - if (roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) + if (fsopts-maxsize 0 +roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) errx(1, `%s' minsize of %lld rounded up to ffs bsize of %d exceeds maxsize %lld. Lower bsize, or round the minimum and maximum sizes to bsize., dir, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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
RFC: Remove pty(4)
One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and userspace loops over ptyXX and after it successfully opens it tries to open the other one with the same suffix. So, having a single device is not really enough. My option, instead, is that of removing pty(4), which is nothing more than a compatibility driver, and move pmtx(4) code somewhere else. The main drawback of the removal of this is that it makes impossible to run FreeBSD = 7 jails and SSH into them. I personally don't consider this a huge issue, in light of the fact that FreeBSD-7 has been EOL for a long time, but I would like to hear other people comments. The code review for the proposed change can be found here: https://reviews.freebsd.org/D659 If I won't get any objection I'll commit this in one week time, i.e. August 27th. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: wrong page state m 0xe00000027a9adb40 + savecore deadlock
On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht me...@bris.ac.uk wrote:
Anyway, savecore eventually deadlocks:
panic: deadlkres: possible deadlock detected for 0xe000127b7b00, blocked
for 901401 ticks
[trim]
Tracing command savecore pid 805 tid 100079 td 0xe000127b7b00
cpu_switch(0xe000127b7b00, 0xe00011178900, 0xe00012402fc0,
0x9ffc005e7e80) at cpu_switch+0xd0
sched_switch(0xe000127b7b00, 0xe00011178900, 0x9ffc00f15698,
0x9ffc00f15680) at sched_switch+0x890
mi_switch(0x103, 0x0, 0xe000127b7b00, 0x9ffc0062d1f0) at
mi_switch+0x3f0
turnstile_wait(0xe00012402fc0, 0xe00012400480, 0x0,
0x9ffc00dcb698) at turnstile_wait+0x960
__mtx_lock_sleep(0x9ffc010f9998, 0xe000127b7b00, 0xe00012402fc0,
0x9ffc00dc0558, 0x742) at __mtx_lock_sleep+0x2f0
__mtx_lock_flags(0x9ffc010f9980, 0x0, 0x9ffc00dd4a90, 0x742) at
__mtx_lock_flags+0x1e0
vfs_vmio_release(0xa0009ebe72f0, 0xe0027ed2ab70, 0x3,
0xa0009ebe736c, 0xa0009ebe7498, 0xa0009ebe72f8,
0x9ffc00dd4a90, 0x9ffc010f9680) at vfs_vmio_release+0x290
getnewbuf(0xe000127f4ec0, 0x0, 0x0, 0x8000, 0xa0009ebe99a8, 0x0,
0x9ffc010f0798, 0xa0009ebe72f0) at getnewbuf+0x7e0
getblk(0xe000127f4ec0, 0x4cbaa, 0x8000, 0x0, 0x0, 0x0, 0x0, 0x0) at
getblk+0xee0
ffs_balloc_ufs2(0xe000127f4ec0, 0x4cbaa, 0xa000c60ba000,
0xe00011165a00, 0x7f05, 0xa0009dd79160) at ffs_balloc_ufs2+0x2950
ffs_write(0xa0009dd79248, 0x3000, 0x265d5) at ffs_write+0x5c0
VOP_WRITE_APV(0x9ffc00e94ac0, 0xa0009dd79248, 0x0, 0x0) at
VOP_WRITE_APV+0x330
vn_write(0xe000129ae820, 0xa0009dd79360, 0xe00011165a00, 0x0,
0xe000129ae830, 0xe000127f4ec0) at vn_write+0x450
vn_io_fault(0xe000129ae820, 0xa0009dd79360, 0xe00011165a00, 0x0,
0xe000127b7b00) at vn_io_fault+0x330
dofilewrite(0xe000127b7b00, 0x7, 0xe000129ae820, 0xa0009dd79360,
0x, 0x0) at dofilewrite+0x180
kern_writev(0xe000127b7b00, 0x7, 0xa0009dd79360) at kern_writev+0xa0
sys_write(0xe000127b7b00, 0xa0009dd794e8, 0x9ffc00abac80, 0x48d)
at sys_write+0x100
syscall(0xe000129d04a0, 0x140857000, 0x8000, 0xe000127b7b00, 0x0,
0x0, 0x9ffc00ab7280, 0x8) at syscall+0x5e0
--More--
I'm not commenting on the first panic you got -- but on the deadlock
reported by DEADLKRES. I think that's the vm_page lock.
You can run kgdb /boot/${KERNEL}/kernel where ${KERNEL} is the incrimined one
then l *vfs_vmio_release+0x290
to get the exact point where it fails.
I'm unsure here because 'show alllocks' and 'show locks' outputs are
empty -- are you building your kernel with WITNESS etc..?
Thanks,
--
Davide
There are no solved problems; there are only problems that are more
or less solved -- Henri Poincare
___
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: WITNESS: unable to allocate a new witness object
On Tue, Oct 15, 2013 at 4:17 PM, Anton Shterenlikht me...@bris.ac.uk wrote: I'm trying to set up textdump(4). On boot I see: WITNESS: unable to allocate a new witness object also It means that you run out of WITNESS object on the free list. Expensive timeout(9) function: 0x9ffc00e222e0(0xa09ed320) 0.002434387 s kickstart. It's output from DIAGNOSTIC, it's triggered when the callout handler execution time exceeds a given threshold. You can safely ignore it. Also, please stop spamming on mailing lists with new posts. They more or less all refers to the same problem. Keeps posting doesn't encourage people to look at it, neither it helps to have it solved more quickly. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Mon, Oct 14, 2013 at 10:21 AM, Anton Shterenlikht me...@bris.ac.uk wrote: From davide.itali...@gmail.com Fri Oct 11 15:39:49 2013 If you're not able to get a full dump, a textdump would be enough. In your DDB scripts just remove the 'call doadump' step and you should be done, unless I'm missing something. Please adjust the script as well to include all the informations requested as mentioned in my previous link, e.g. 'show lockedvnods' is not mentioned on the example section of textdump(4) manpage but it could be useful to ease debugging. I still haven't got it right, but I now collected manually some (hopefully) useful info (see below). This is fair enough -- If you're still at the ddb prompt, please print the whole panic message (or at least the address of the lock reported as deadlocked by DEADLKRES), so that we can at least have a candidate. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Fri, Oct 11, 2013 at 11:26 AM, Anton Shterenlikht me...@bris.ac.uk wrote: From davide.itali...@gmail.com Thu Sep 26 13:12:30 2013 On Thu, Sep 26, 2013 at 12:23 PM, Anton Shterenlikht me...@bris.ac.uk wrote: Regarding textdump(4), I'm not clear where the following scripts should be located and used: [snip] Are these ddb(8) commands? Or do I set these in /etc/rc.conf? The scripts (quotes unneeded) should be located in /etc/ddb.conf. I think you want ddb_enable=YES in your /etc/rc.conf I've set textdump following the man page. I've got several more deadlocks, but it seems savecore causes deadlock too! # savecore savecore: reboot after panic: deadlkres: possible deadlock detected for 0xe000129d2000, blocked for 902608 ticks savecore: writing core to ./vmcore.5 When the size of vmcore.x file gets to about 9GB, I get a deadlock again. What can I do now? Thanks Anton If you're not able to get a full dump, a textdump would be enough. In your DDB scripts just remove the 'call doadump' step and you should be done, unless I'm missing something. Please adjust the script as well to include all the informations requested as mentioned in my previous link, e.g. 'show lockedvnods' is not mentioned on the example section of textdump(4) manpage but it could be useful to ease debugging. Thanks for your time, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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 stable-9 in current host
On Tue, Oct 1, 2013 at 9:05 AM, Alexander Yerenkow yeren...@gmail.com wrote: Hello all. Can someone help me? :) [trim] === usr.bin/clang/tblgen (obj,depend,all,install) ... c++ -O2 -pipe -I/zbuilder/vm4all/src-stable-9-clone/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/zbuilder/vm4all/src-stable-9-clone/usr.bin/ clang/tblgen/../../../contrib/llvm/tools/clang/include -I/zbuilder/vm4all/src-stable-9-clone/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGe n -I. -I/zbuilder/vm4all/src-stable-9-clone/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__S TDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd9.2\ -DLLVM_HOST_TRIPLE=\x86_64 -unknown-freebsd9.2\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/zbuilder/vm4all/src-stable-9-clone/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /zbuil der/vm4all/src-stable-9-clone/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/X86RecognizableInstr.cpp make: don't know how to make /usr/lib/libstdc++.a. Stop *** [bootstrap-tools] Error code 2 It's one of the gifts of the recent no gcc and libstdc++ built by default. I think the easiest way to fix that would be rebuilding world on your 10 machine with WITH_GCC=yes and WITH_GNUCXX=yes in src.conf(5) The long term solution, as proposed by dim@ is that of fixing bsd.prog.mk in 9 and 8. One of the major drawbacks of this, is that, even though it will be done immediately, won't hit 9.2. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Thu, Sep 26, 2013 at 12:23 PM, Anton Shterenlikht me...@bris.ac.uk wrote: Regarding textdump(4), I'm not clear where the following scripts should be located and used: [snip] Are these ddb(8) commands? Or do I set these in /etc/rc.conf? The scripts (quotes unneeded) should be located in /etc/ddb.conf. I think you want ddb_enable=YES in your /etc/rc.conf -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Wed, Sep 25, 2013 at 11:11 AM, Anton Shterenlikht me...@bris.ac.uk wrote: FreeBSD mech-as221.men.bris.ac.uk 10.0-ALPHA2 FreeBSD 10.0-ALPHA2 #8 r255811: Tue Sep 24 09:04:17 BST 2013 r...@mech-as221.men.bris.ac.uk:/usr/obj/usr/src/sys/UZI ia64 panic: deadlkres: possible deadlock detected for 0xe00012d07b00, blocked for 902743 ticks cpuid = 1 KDB: stack backtrace: db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc00bfb030, 0x9ffc0045b350, 0x40c, 0x9ffc00dd20a0) at kdb_backtrace+0xc0 vpanic(0x9ffc00aec840, 0xa05cb518) at vpanic+0x260 panic(0x9ffc00aec840, 0x9ffc00aecaa0, 0xe00012d07b00, 0xdc657) at panic+0x80 deadlkres(0xdc657, 0xe00012d07b00, 0x9ffc00aef478, 0x9ffc00aec7d0) at deadlkres+0x420 fork_exit(0x9ffc00b441e0, 0x0, 0xa05cb550) at fork_exit+0x120 enter_userland() at enter_userland KDB: enter: panic [ thread pid 0 tid 100047 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe28fb0,gp ;; db db show msgbuf *skip* 118Sep 24 09:36:02 mech-as221 su: mexas to root on /dev/pts/0 lock order reversal: 1st 0xa0005f0518b8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 2nd 0xe00012343000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc00bfb030, 0x9ffc00509870) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0x9ffc00b01d10, 0x9ffc0050d240, 0xb9d, 0x9ffc00b2e268) at _witness_debugger+0x60 witness_checkorder(0xe00012343000, 0x9ffc00b01660, 0x9ffc00b2e268, 0x11c, 0x0) at witness_checkorder+0x15b0 _sx_xlock(0xe00012343000, 0x0, 0x9ffc00b2e268, 0x11c) at _sx_xlock+0x120 ufsdirhash_acquire(0xe000123bd308, 0xe00012343000, 0x9ffc008d1920, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000123bd308, 0xa00060ecbd08, 0x1d08, 0xa0008fea51e8) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000123d8000, 0xe000129e29d8, 0x0, 0x0) at ufs_dirremove+0x380 ufs_remove(0xa0008fea5380, 0xe000129e29d8, 0xa1c) at ufs_remove+0xe0 VOP_REMOVE_APV(0x9ffc00bc3180, 0xa0008fea5380, 0xe000122f8678, 0x0, 0x9ffc005c2920, 0xa1c, 0x9ffc00dd20a0) at VOP_REMOVE_APV+0x220 kern_unlinkat(0xe000123e1200, 0xff9c, 0x7fffee36, 0x0, 0x0) at kern_unlinkat+0x3f0 kern_unlink(0xe000123e1200, 0x7fffee36, 0x0) at kern_unlink+0x40 sys_unlink(0xe000123e1200, 0xa0008fea54e8, 0x9ffc00988c80, 0x48d) at sys_unlink+0x30 syscall(0xe000123de940, 0x7fffee36, 0x7fffeb00, 0xe000123e1200, 0x0, 0x0, 0x9ffc00983f20, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return 6pid 52065 (conftest), uid 0: exited on signal 11 (core dumped) db show thread Thread 100047 at 0xe00011973b00: proc (pid 0): 0x9ffc00c15828 name: deadlkres stack: 0xa05c4000-0xa05cbfff flags: 0x4 pflags: 0x20 state: RUNNING (CPU 1) priority: 108 container lock: sched lock 1 (0x9ffc00c3de80) db Can you please paste the output of 'show locks', 'show alllocks', 'show lockedvnods' at least? Ideally you should provide all the informations listed here. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html Thanks, -- Davide A mathematical theory is not to be considered complete until you have made it so clear that you can explain it to the first man whom you meet on the street. (D. Hilbert) ___ 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Wed, Sep 25, 2013 at 5:30 PM, Anton Shterenlikht me...@bris.ac.uk wrote: From davide.itali...@gmail.com Wed Sep 25 16:12:47 2013 Can you please paste the output of 'show locks', 'show alllocks', 'show lockedvnods' at least? Ideally you should provide all the informations listed here. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html ok, I'll need to study this. I've in the kernel: # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use (turn off in stable branch): options DDB # Support DDB options GDB # Support remote GDB options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones so I'm missing DEBUG_LOCKS, DEBUG_VFS_LOCKS and DIAGNOSTIC from the handbook list. What about all debug options in GENERIC which are not mentioned in your link? Specifically, do I need to have DEADLKRES? Yes, you need that option because it's DEADLKRES that triggers the panic. I've never used trace. Also, I'm getting a panic, so cannot run ps, I think. You can run 'ps' from ddb prompt. As an advice I suggest you to setup textdump(4) on your machine and set up a script to gather the required informations, so that you can get those informations pretty easily for report. The manpage has detailed description about how to do this. Thanks Anton -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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 arptimer on r255764
On Sun, Sep 22, 2013 at 2:25 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, Sep 21, 2013 at 11:23:47PM -0700, Tim Kientzle wrote: I'm seeing this panic pretty consistently when I try to do a buildworld on r255764 (i386): http://people.freebsd.org/~kientzle/r255764%20panic%202013-09-21%20at%209.27.09%20PM.png I'm not seeing it on r255602, so I suspect it's a recent problem. Running on VMWare Fusion 6. This was about as vanilla a build as you can get: no local code changes, no custom config, no src.conf or make.conf, no ports installed, etc. +1 I also see this on yesterday's HEAD: http://bsd-geek.de/pics/IMG_20130922_100936.jpg The only difference is that I don''t need to run a buildworld, just going into multi user and wait a few seconds. I don't see this in single user mode, though. Try this: http://people.freebsd.org/~davide/review/lc_calloutfix.diff I'll commit as soon as I'll receive OK from re@. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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 arptimer on r255764
On Sun, Sep 22, 2013 at 2:28 PM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Sep 22, 2013 at 05:11:30AM -0700, Davide Italiano wrote: On Sun, Sep 22, 2013 at 2:25 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, Sep 21, 2013 at 11:23:47PM -0700, Tim Kientzle wrote: I'm seeing this panic pretty consistently when I try to do a buildworld on r255764 (i386): http://people.freebsd.org/~kientzle/r255764%20panic%202013-09-21%20at%209.27.09%20PM.png I'm not seeing it on r255602, so I suspect it's a recent problem. Running on VMWare Fusion 6. This was about as vanilla a build as you can get: no local code changes, no custom config, no src.conf or make.conf, no ports installed, etc. +1 I also see this on yesterday's HEAD: http://bsd-geek.de/pics/IMG_20130922_100936.jpg The only difference is that I don''t need to run a buildworld, just going into multi user and wait a few seconds. I don't see this in single user mode, though. Try this: http://people.freebsd.org/~davide/review/lc_calloutfix.diff I'll commit as soon as I'll receive OK from re@. Yes, that seems to help. I am running it for a few minutes now which is a few minutes more that without the patch. ;-) Thanks! P.S.: Fortunately I migrated the system to ZFS with Boot Environments, so I could boot the old world and kernel without any hassle! \o/ A fix is now committed (r255788). Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: FreeBSD 10.0 Alpha 2 panic kernel trap 12 with interrupts disable
On Sun, Sep 22, 2013 at 1:40 PM, Miguel Clara miguelmcl...@gmail.com wrote: Its definatly not related to GCC, I'm getting the same while trying to buildkernel, I'm trying to upgrade to a more recent current version! Same kernel panic is showing... No one else had this problem yet? Thanks On Sun, Sep 22, 2013 at 6:12 PM, Miguel Clara miguelmcl...@gmail.comwrote: I'm trying to build kdelibs on 10.0 Alpha 2, however after 3 triesI get a panic while building gcc, but I'm not sure if its related or just coincidence! --- Kernel 12 trap 12 with interrupts disable Fatal trap 12: page fault in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x30 fault code = supervisor read data, page not present ... Stopped at trunstile_broadcast+0x8c: movq 0x20(%rbx, %rax,1),%rdx You need to show at least a full backtrace to locate where the problem is. Please when you drop into ddb type 'bt' and paste the output. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: FreeBSD 10.0 Alpha 2 panic kernel trap 12 with interrupts disable
On Sun, Sep 22, 2013 at 1:47 PM, Miguel C. miguelmcl...@gmail.com wrote: Hum, its probably best to take a scrennshot since I can't copy this from the console! attaching the file That was a regression I introduced, but I'm confident r255788 fixed the issue. Please update your sources and rebuild your kernel. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: FreeBSD 10.0 Alpha 2 panic kernel trap 12 with interrupts disable
On Sun, Sep 22, 2013 at 2:06 PM, Miguel Clara miguelmcl...@gmail.comwrote: I sent the mail again to the list in a smaller size, the first one was huge ... Anyway that's the revision I'm trying to build -- r255788 ... but the problem is, I can't buildkernel, I get a panic while doing it... so unless there's some kernel.txz available already compile, I'm out of luck! Unfortunately the one available on the ftp at the moment is alpha2, which is the one with the problem! ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/ Thanks, -- Davide ___ 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: FreeBSD 10.0 Alpha 2 panic kernel trap 12 with interrupts disable
On Sun, Sep 22, 2013 at 2:47 PM, Miguel Clara miguelmcl...@gmail.com wrote: Thanks for the suggestion but I would have tried it If r255788 or newer was there but its not the case! I also checked ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/10.0-CURRENT/ but kernel.txz seems to be outdated too! I guess the best thing for me at the moment is to wait for a new snapshot. The link I gave to you contains a snapshot as per r255342 (which is way before the regression was introduced). You can use that, then checkout the sources via svnlite and rebuild. I don't see a reason why you cannot use that and you want to wait for ALPHA3, but alas. -- Davide ___ 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 on head (r255759) [_callout_stop_safe()- panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140]
On Sat, Sep 21, 2013 at 2:51 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 21 Sep 2013 07:08:25 -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 9/21/2013 7:06 AM, Bjoern A. Zeeb wrote: On Sat, 21 Sep 2013, Bryan Drewery wrote: Unread portion of the kernel message buffer: panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe118aeef820 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe118aeef8d0 vpanic() at vpanic+0x126/frame 0xfe118aeef910 panic() at panic+0x43/frame 0xfe118aeef970 __rw_assert() at __rw_assert+0xa3/frame 0xfe118aeef980 _callout_stop_safe() at _callout_stop_safe+0x54/frame 0xfe118aeef9f0 arptimer() at arptimer+0x14e/frame 0xfe118aeefa30 softclock_call_cc() at softclock_call_cc+0x188/frame 0xfe118aeefb10 softclock() at softclock+0x47/frame 0xfe118aeefb30 intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfe118aeefb70 ithread_loop() at ithread_loop+0xa6/frame 0xfe118aeefbb0 fork_exit() at fork_exit+0x84/frame 0xfe118aeefbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe118aeefbf0 --- trap 0, rip = 0, rsp = 0xfe118aeefcb0, rbp = 0 --- +1 from me; I guess introduced somwhere between 255569 and 255758, as these are my edges of kernel.old and kernel. r255726 was stable for me. r255759 is not. r255755 converted ipfilter to callout, but I am unsure if that is the problem. r255729 is also stable for me - I'm with r255729 again, since r255757 crashed. Let me know if this fixes the problem for you: http://people.freebsd.org/~davide/review/lc_calloutfix.diff Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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 on head (r255759) [_callout_stop_safe()- panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140]
On Sat, Sep 21, 2013 at 9:31 AM, Bryan Drewery bdrew...@freebsd.org wrote: On 9/21/2013 11:18 AM, Adam McDougall wrote: On 09/21/13 09:41, Davide Italiano wrote: On Sat, Sep 21, 2013 at 2:51 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 21 Sep 2013 07:08:25 -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 9/21/2013 7:06 AM, Bjoern A. Zeeb wrote: On Sat, 21 Sep 2013, Bryan Drewery wrote: Unread portion of the kernel message buffer: panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe118aeef820 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe118aeef8d0 vpanic() at vpanic+0x126/frame 0xfe118aeef910 panic() at panic+0x43/frame 0xfe118aeef970 __rw_assert() at __rw_assert+0xa3/frame 0xfe118aeef980 _callout_stop_safe() at _callout_stop_safe+0x54/frame 0xfe118aeef9f0 arptimer() at arptimer+0x14e/frame 0xfe118aeefa30 softclock_call_cc() at softclock_call_cc+0x188/frame 0xfe118aeefb10 softclock() at softclock+0x47/frame 0xfe118aeefb30 intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfe118aeefb70 ithread_loop() at ithread_loop+0xa6/frame 0xfe118aeefbb0 fork_exit() at fork_exit+0x84/frame 0xfe118aeefbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe118aeefbf0 --- trap 0, rip = 0, rsp = 0xfe118aeefcb0, rbp = 0 --- +1 from me; I guess introduced somwhere between 255569 and 255758, as these are my edges of kernel.old and kernel. r255726 was stable for me. r255759 is not. r255755 converted ipfilter to callout, but I am unsure if that is the problem. r255729 is also stable for me - I'm with r255729 again, since r255757 crashed. Let me know if this fixes the problem for you: http://people.freebsd.org/~davide/review/lc_calloutfix.diff Thanks, Worked for me so far. I generally couldn't stay up more than 30 minutes before the patch and now my uptime is 90 minutes. Thanks! Same here. -- Regards, Bryan Drewery I would wait another couple of hours before the commit, but still I'm confident this fixed the problem. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Intermittent hangs in vmem_periodic()
Thanks Gleb. I've removed DIAGNOSTIC and the problem is gone now. JFYI, I hit this problem today as well. I don't think you really need to disable DIAGNOSTIC completely in order to get rid of that. I've noticed Peter Holm has recently committed a new sysctl that allows you to selectively disable calls to vmem_check (debug.vmem_check), which should (probably) help. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Interesting panic from the Yahoo builder (10-current)
On Sun, Sep 8, 2013 at 4:27 PM, Sean Bruno sean_br...@yahoo.com wrote: On Sat, 2013-09-07 at 17:05 +0200, Davide Italiano wrote: On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno sean_br...@yahoo.com wrote: Our yBSD builder needs to mount a disk image temporarily that has a dos partition (for openstack-ish things) to put configs into it. It seems that under high stress, we can squeeze a panic out of it in namei(). Sean Unread portion of the kernel message buffer: panic: namei: nameiop contaminated with flags cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048d8e53b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe048d8e5460 vpanic() at vpanic+0x126/frame 0xfe048d8e54a0 kassert_panic() at kassert_panic+0x136/frame 0xfe048d8e5510 namei() at namei+0x2c8/frame 0xfe048d8e5600 msdosfs_mount() at msdosfs_mount+0x556/frame 0xfe048d8e57c0 vfs_donmount() at vfs_donmount+0xc35/frame 0xfe048d8e5aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe048d8e5ae0 amd64_syscall() at amd64_syscall+0x223/frame 0xfe048d8e5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe048d8e5bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8000a8b68a, rsp = 0x7fffd508, rbp = 0x7fffdb30 --- Uptime: 34m55s Dumping 1140 out of 16350 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% Reading symbols from /boot/modules/msdosfs.ko...done. Loaded symbols for /boot/modules/msdosfs.ko #0 doadump (textdump=1) at pcpu.h:227 227 pcpu.h: No such file or directory. in pcpu.h (kgdb) Hangup detected on fd 0 error detected on stdin Can you please print the value of cnp-cn_nameiop (or, even better, the whole struct) before the panic? Thanks, Hrm ... tried to reproduce after recompiling the kernel (turning off KDB_UNATTENDED) and its not happening now. I'll keep an eye out for it. Sean From a first look (even without the informations) it looks very strange that the assertion fails, NDINIT() is called just before namei() in order to initialize struct nameidata, and that's what almost every other filesystem do, so I'm surprised noone hit this problem before. A (relatively random) guess is that you might run on (some sort of) broken hardware. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Interesting panic from the Yahoo builder (10-current)
On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno sean_br...@yahoo.com wrote: Our yBSD builder needs to mount a disk image temporarily that has a dos partition (for openstack-ish things) to put configs into it. It seems that under high stress, we can squeeze a panic out of it in namei(). Sean Unread portion of the kernel message buffer: panic: namei: nameiop contaminated with flags cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048d8e53b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe048d8e5460 vpanic() at vpanic+0x126/frame 0xfe048d8e54a0 kassert_panic() at kassert_panic+0x136/frame 0xfe048d8e5510 namei() at namei+0x2c8/frame 0xfe048d8e5600 msdosfs_mount() at msdosfs_mount+0x556/frame 0xfe048d8e57c0 vfs_donmount() at vfs_donmount+0xc35/frame 0xfe048d8e5aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe048d8e5ae0 amd64_syscall() at amd64_syscall+0x223/frame 0xfe048d8e5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe048d8e5bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8000a8b68a, rsp = 0x7fffd508, rbp = 0x7fffdb30 --- Uptime: 34m55s Dumping 1140 out of 16350 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% Reading symbols from /boot/modules/msdosfs.ko...done. Loaded symbols for /boot/modules/msdosfs.ko #0 doadump (textdump=1) at pcpu.h:227 227 pcpu.h: No such file or directory. in pcpu.h (kgdb) Hangup detected on fd 0 error detected on stdin Can you please print the value of cnp-cn_nameiop (or, even better, the whole struct) before the panic? Thanks, -- Davide A mathematical theory is not to be considered complete until you have made it so clear that you can explain it to the first man whom you meet on the street. (D. Hilbert) ___ 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: Question about socket timeouts
On Thu, Aug 29, 2013 at 6:03 PM, John Baldwin j...@freebsd.org wrote: On Monday, August 26, 2013 3:05:06 pm John Baldwin wrote: On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote: Please consider the following patch: http://people.freebsd.org/~davide/review/socket_timeout.diff I've tested it and it works OK. I got a timeout which is ~= 25ms using the testcase provided by the user. The only doubt I have is about the range check, I've changed a bit because the 'integer' part of sbintime_t fits in 32-bits, but I'm not sure it's the best way of doing this. Nice! Bruce actually wants me to adjust the range check a bit (which will fit in well with your changes I think). Please let me get that fix in (so it can be part of the future MFC) and then you can commit this. Thanks! Actually, I think you still need to patch the sogetopt() case to work correctly (it is still doing a manual conversion from 'val' to a timeval assuming it is in 'hz' units). I'm done with my range check changes, please move forward with your change (though make sure you fix the sogetsockopt() case please). -- John Baldwin For the archives, this should be fixed in r255138. Thanks to both, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Question about socket timeouts
On Tue, Aug 27, 2013 at 7:10 AM, Vitja Makarov vitja.maka...@gmail.com wrote: On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov vitja.maka...@gmail.com wrote: 2013/8/23 Davide Italiano dav...@freebsd.org: I think that for socket's timeouts it's ok to have a HZ-precision. It would be much more important to implement high-precision timeouts for select() and friends, if it's not done yet (sorry I'm running 9.1). JFYI, select()/usleep()/etc... are all fine grained right now in HEAD. That's cool! Does that mean that FreeBSD 10 would be a tickless system? -- vitja. FreeBSD will have a tickless callout(9) subsystem. There are still some kernel subsystems that depends on hardclock() even if the long term goal is that of moving away from it (when/if possible). A notable example is SCHED_ULE code which depends on hardclock() (sched_tick()) but it could be optimized to skip some calls even though CPU is active. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Question about socket timeouts
On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin j...@freebsd.org wrote:
On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin j...@freebsd.org wrote:
On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
2013/8/22 John Baldwin j...@freebsd.org:
On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
2013/8/21 John Baldwin j...@freebsd.org:
On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
On Mon, 19 Aug 2013, Adrian Chadd wrote:
Yes! Please file a PR!
This sorta implies that both are acceptable (although,
the Linux behavior seems more desirable).
http://austingroupbugs.net/view.php?id=369
No, that says round up, so it does mean that the requested timeout
should be the minimum amount slept. tvtohz() does this. Really odd
that the socket code is using its own version of this rather than
tvtohz().
Oh, I bet this just predates tvtohz(). Interesting that it keeps
getting
bug fixes in its history that simply using tvtohz() would have
solved.
Try this:
Index: uipc_socket.c
===
--- uipc_socket.c (revision 254570)
+++ uipc_socket.c (working copy)
@@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
*sopt)
if (error)
goto bad;
- /* assert(hz 0); */
if (tv.tv_sec 0 || tv.tv_sec INT_MAX /
hz ||
tv.tv_usec 0 || tv.tv_usec = 100)
{
error = EDOM;
goto bad;
}
- /* assert(tick 0); */
- /* assert(ULONG_MAX - INT_MAX = 100);
*/
- val = (u_long)(tv.tv_sec * hz) + tv.tv_usec
/ tick;
- if (val INT_MAX) {
+ val = tvtohz(tv);
+ if (val == INT_MAX) {
error = EDOM;
goto bad;
}
- if (val == 0 tv.tv_usec != 0)
- val = 1;
switch (sopt-sopt_name) {
case SO_SNDTIMEO:
That must help. But I want to see the issue solved in the next
release. I can't apply patch to the production system. Btw in
production environment we have kern.hz set to 1000 so it's not a
problem there.
Can you test this in some way in a test environment?
Ok, sorry for posting out of the list.
Simple test program is attached. Without your patch timeout expires in
about 20ms. With it it's ~40ms.
40 instead of 30 is beacuse of odd tick added by tvtohz().
Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for
HEAD I think we can fix this to use a precise timeout. I've cc'd davide@
so he can take a look at that.
--
John Baldwin
Hi,
I think I can switch this code to new timeout KPI, but this will
require the timeout field of 'struct sockbuf' to be changed from 'int'
to 'sbintime_t' which breaks binary compatibility. Do you have any
strong objections about this? If any, I would like this to happen ABI
freeze, so it looks like this is the right moment.
This should be fine to change now, it just can't be MFC'd (which we can't
do anyway).
--
John Baldwin
Please consider the following patch:
http://people.freebsd.org/~davide/review/socket_timeout.diff
I've tested it and it works OK. I got a timeout which is ~= 25ms using
the testcase provided by the user.
The only doubt I have is about the range check, I've changed a bit
because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
sure it's the best way of doing this.
Thanks,
--
Davide
There are no solved problems; there are only problems that are more
or less solved -- Henri Poincare
___
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: Question about socket timeouts
On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov vitja.maka...@gmail.com wrote: 2013/8/23 Davide Italiano dav...@freebsd.org: I think that for socket's timeouts it's ok to have a HZ-precision. It would be much more important to implement high-precision timeouts for select() and friends, if it's not done yet (sorry I'm running 9.1). JFYI, select()/usleep()/etc... are all fine grained right now in HEAD. -- vitja. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: [rfc] migrate lagg to an rmlock
On Sat, Aug 24, 2013 at 7:16 AM, Robert Watson rwat...@freebsd.org wrote: On Sat, 24 Aug 2013, Alexander V. Chernikov wrote: On 24.08.2013 00:54, Adrian Chadd wrote: I'd like to commit this to -10. It migrates the if_lagg locking from a rw lock to a rm lock. We see a bit of contention between the transmit and We're running lagg with rmlock on several hundred heavily loaded machines, it really works better. However, there should not be any contention between receive and transmit side since there is actually no _real_ need to lock RX (and even use lagg receive code at all): http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html We should distinguish lock contention from line contention. When acquiring a rwlock on multiple CPUs concurrently, the cache lines used to implement the lock are contended, as they must bounce between caches via the cache coherence protocol, also referred to as contention. In the if_lagg code, I assume that the read-only acquire of the rwlock (and perhaps now rmlock) is for data stability rather than mutual exclusion -- e.g., to allow processing to completion against a stable version of the lagg configuration. As such, indeed, there should be no lock contention unless a configuration update takes place, and any line contention is a property of the locking primitive rather than data model. There are a number of other places in the kernel where migration to an rmlock makes sense -- however, some care must be taken for four reasons: (1) while read locks don't experience line contention, write locking becomes observably e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike rwlocks, more expensive so is not suitable for all rwlock line contention spots -- implement reader priority propagation, so you must reason about; and (3) historically, rmlocks have not fully implemented WITNESS so you may get less good debugging output. if_lagg is a nice place I'm not sure what you mean here with (3), because from my understanding of the code WITNESS is implemented both in the sleepable and non-sleepable case, but there could be something I'm missing. Something I think we lack in rmlock code is fully supported LOCK_PROFILING as we have in all the other primitives, but again, if I'm wrong feel free to correct me. to use rmlocks, as reconfigurations are very rare, and it's really all about long-term data stability. 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 Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Question about socket timeouts
On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin j...@freebsd.org wrote:
On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
2013/8/22 John Baldwin j...@freebsd.org:
On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
2013/8/21 John Baldwin j...@freebsd.org:
On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
On Mon, 19 Aug 2013, Adrian Chadd wrote:
Yes! Please file a PR!
This sorta implies that both are acceptable (although,
the Linux behavior seems more desirable).
http://austingroupbugs.net/view.php?id=369
No, that says round up, so it does mean that the requested timeout
should be the minimum amount slept. tvtohz() does this. Really odd
that the socket code is using its own version of this rather than
tvtohz().
Oh, I bet this just predates tvtohz(). Interesting that it keeps
getting
bug fixes in its history that simply using tvtohz() would have solved.
Try this:
Index: uipc_socket.c
===
--- uipc_socket.c (revision 254570)
+++ uipc_socket.c (working copy)
@@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
*sopt)
if (error)
goto bad;
- /* assert(hz 0); */
if (tv.tv_sec 0 || tv.tv_sec INT_MAX / hz ||
tv.tv_usec 0 || tv.tv_usec = 100) {
error = EDOM;
goto bad;
}
- /* assert(tick 0); */
- /* assert(ULONG_MAX - INT_MAX = 100); */
- val = (u_long)(tv.tv_sec * hz) + tv.tv_usec /
tick;
- if (val INT_MAX) {
+ val = tvtohz(tv);
+ if (val == INT_MAX) {
error = EDOM;
goto bad;
}
- if (val == 0 tv.tv_usec != 0)
- val = 1;
switch (sopt-sopt_name) {
case SO_SNDTIMEO:
That must help. But I want to see the issue solved in the next
release. I can't apply patch to the production system. Btw in
production environment we have kern.hz set to 1000 so it's not a
problem there.
Can you test this in some way in a test environment?
Ok, sorry for posting out of the list.
Simple test program is attached. Without your patch timeout expires in
about 20ms. With it it's ~40ms.
40 instead of 30 is beacuse of odd tick added by tvtohz().
Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for
HEAD I think we can fix this to use a precise timeout. I've cc'd davide@
so he can take a look at that.
--
John Baldwin
Hi,
I think I can switch this code to new timeout KPI, but this will
require the timeout field of 'struct sockbuf' to be changed from 'int'
to 'sbintime_t' which breaks binary compatibility. Do you have any
strong objections about this? If any, I would like this to happen ABI
freeze, so it looks like this is the right moment.
Thanks,
--
Davide
There are no solved problems; there are only problems that are more
or less solved -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch: enable MEM_LOAD_UOPS_LLC_HIT_RETIRED on sandy bridge xeon
On Wed, Aug 14, 2013 at 10:58 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, This (and maybe more?) events are applicable to both the sandy bridge and sandy bridge xeon CPUs. This is from the Intel SDM June 2013 Volume #3. David/Jim, does this look fine to you? Thanks, ndex: sys/dev/hwpmc/hwpmc_core.c === --- sys/dev/hwpmc/hwpmc_core.c (revision 254263) +++ sys/dev/hwpmc/hwpmc_core.c (working copy) @@ -1541,13 +1541,18 @@ IAP_F_SBX | IAP_F_IBX | IAP_F_HW), IAPDESCR(D2H_01H, 0xD2, 0x01, IAP_F_FM | IAP_F_CA | IAP_F_CC2 | - IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | IAP_F_IBX | IAP_F_HW), + IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_SBX | IAP_F_IB | + IAP_F_IBX | IAP_F_HW), IAPDESCR(D2H_02H, 0xD2, 0x02, IAP_F_FM | IAP_F_CA | IAP_F_CC2 | - IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | IAP_F_IBX | IAP_F_HW), + IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_SBX | IIAP_F_IB | + IAP_F_IBX | IAP_F_HW), IAPDESCR(D2H_04H, 0xD2, 0x04, IAP_F_FM | IAP_F_CA | IAP_F_CC2 | - IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | IAP_F_IBX | IAP_F_HW), + IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_SBX | IIAP_F_IB | + IAP_F_IBX | IAP_F_HW), IAPDESCR(D2H_08H, 0xD2, 0x08, IAP_F_FM | IAP_F_CA | IAP_F_CC2 | - IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | IAP_F_IBX | IAP_F_HW), + IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_SBX | IIAP_F_IB | + IAP_F_IBX | IAP_F_HW), + IAPDESCR(D2H_0FH, 0xD2, 0x0F, IAP_F_FM | IAP_F_CA | IAP_F_CC2 | IAP_F_I7 | IAP_F_WM), IAPDESCR(D2H_10H, 0xD2, 0x10, IAP_F_FM | IAP_F_CC2E), Yes, this looks good for me, but it's incomplete. You need at least to put the event alias for both Sandy Bridge and Sandy Bridge Xeon in sys/dev/hwpmc/pmc_events.h Also, you tested the aforementioned events one by one to see if the pmc is allocated etc...? Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Early drop to debugger with DEBUG_MEMGUARD
On Mon, Aug 12, 2013 at 8:13 AM, David Wolfskill da...@catwhisker.org wrote: I first noticed this on my laptop on 08 Aug, after having built booted FreeBSD 10.0-CURRENT #975 r253985M/253985:141: Tue Aug 6 05:28:39 PDT 2013 root@localhost:/common/S4/obj/usr/src/sys/CANARY i386 OK. I'm away from home, and Internet access is a bit flaky, so initially, I suspected that something may have gone wrong with my source update; I later determined that disabling options DEBUG_MEMGUARD would avoid the panic. That said, I had been running a kernel with DEBUG_MEMGUARD for quite a while without issues; I suspect that this drop to debugger either reflects a real problem that disabling DEBUG_MEMGUARD merely hides or htat the assert in src/sys/kern/subr_vmem.c:1050 isn't actually correct in all cases. So I finally(!) had a chance to try to reproduce the error on a machine with a serial console; here's a cut/paste from that: ... | 7. Boot [V]erbose: NO |`:` `:` | | .-- `--. | | .---.. +-+ Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r254245M/254246:142: Mon Aug 12 07:20:47 PDT 2013 r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at /usr/src/sys/kern/subr_vmem.c:1050 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at db_trace_self_wrapper+0x2d/frame 0xc1820ba0 kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at kdb_backtrace+0x30/frame 0xc1820c08 vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 0xc1820c44 kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at kassert_panic+0xea/frame 0xc1820c68 vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 0xc1820ca0 memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at memguard_init+0x29/frame 0xc1820cc4 kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0 mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30 mi_startup() at mi_startup+0xf7/frame 0xc1820d58 begin() at begin+0x2c KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db As you can see, this is well before any device probes or much of anything else. Thus, I suspect that it's fairly possible that the assertion may well be OK after a certain point in the boot sequence, but decidedly *not* OK in this specific instance. Or perhaps the assertion just doesn't play well with DEBUG_MEMGUARD. I'm not about to pretend that I have anywhere near enough familiarity with what's going on to even suggest a fix, but it seems to me that Something Is Wrong Here. The kernel config (in this case) is: include GENERIC ident MEMGUARD options DEBUG_MEMGUARD The system was running a copy of: FreeBSD 10.0-CURRENT #1243 r254245M/254246:142: Mon Aug 12 05:39:42 PDT 2013 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 but with a newly-built MEMGUARD kernel (as above), built from the same sources. I have some time to poke at it for the next few hours; subject to my Internet access available time, I'm happy to do that, try patches, or whatever, but I could use a bit of guidance. Since it's been completely reproducible for me, I suspect that anyone with sufficiently recenty sources running head can reproduce it merely by enabling options DEBUG_MEMGUARD, rebuilding the kernel, and booting it. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. vmem_alloc() KPI needs the consumer to specify exactly a strategy for allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast allocation vs low fragmentation), and that's the assertion that's not respected within the code. 1050MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT); It looks like memguard_init() doesn't specify none of these two strategies. 209 vmem_alloc(parent, memguard_mapsize, M_WAITOK, base); My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with M_WAITOK to have
Re: Early drop to debugger with DEBUG_MEMGUARD
On Mon, Aug 12, 2013 at 9:01 AM, David Wolfskill da...@catwhisker.org wrote:
On Mon, Aug 12, 2013 at 08:30:15AM -0700, Davide Italiano wrote:
...
Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0 r254245M/254246:142: Mon Aug 12 07:20:47 PDT
2013
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
WARNING: WITNESS option enabled, expect reduced performance.
panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at
/usr/src/sys/kern/subr_vmem.c:1050
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at
db_trace_self_wrapper+0x2d/frame 0xc1820ba0
kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at
kdb_backtrace+0x30/frame 0xc1820c08
vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame
0xc1820c44
kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at
kassert_panic+0xea/frame 0xc1820c68
vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame
0xc1820ca0
memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at
memguard_init+0x29/frame 0xc1820cc4
kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame
0xc1820cf0
mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
mi_startup() at mi_startup+0xf7/frame 0xc1820d58
begin() at begin+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x3d: movl$0,kdb_why
db
As you can see, this is well before any device probes or much of
anything else. Thus, I suspect that it's fairly possible that the
assertion may well be OK after a certain point in the boot sequence,
but decidedly *not* OK in this specific instance. Or perhaps the
assertion just doesn't play well with DEBUG_MEMGUARD.
...
vmem_alloc() KPI needs the consumer to specify exactly a strategy for
allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast
allocation vs low fragmentation), and that's the assertion that's not
respected within the code.
1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
It looks like memguard_init() doesn't specify none of these two strategies.
209 vmem_alloc(parent, memguard_mapsize, M_WAITOK, base);
My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with
M_WAITOK to have your kernel booting. What's better between the two
probably will need some measurements but this should at least make
your kernel booting.
Thank you for the insight suggestion.
My first attempt was to make the following change:
Index: sys/vm/memguard.c
===
--- sys/vm/memguard.c (revision 254246)
+++ sys/vm/memguard.c (working copy)
@@ -206,9 +206,9 @@
{
vm_offset_t base;
- vmem_alloc(parent, memguard_mapsize, M_WAITOK, base);
+ vmem_alloc(parent, memguard_mapsize, M_WAITOK | M_FIRSTFIT, base);
memguard_map = vmem_create(memguard arena, base, memguard_mapsize,
- PAGE_SIZE, 0, M_WAITOK);
+ PAGE_SIZE, 0, M_WAITOK | M_FIRSTFIT);
memguard_cursor = base;
memguard_base = base;
This built OK; but attempting to boot yielded:
Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #1 r254245M/254246:142: Mon Aug 12 08:49:12 PDT 2013
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
WARNING: WITNESS option enabled, expect reduced performance.
panic: mti_zone 195 out of range 8
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c116fcdc,0,,c1167d73,fffe,...) at
db_trace_self_wrapper+0x2d/frame 0xc1820b58
kdb_backtrace(c11c4b23,0,c1167d58,c1820c30,c1820c00,...) at
kdb_backtrace+0x30/frame 0xc1820bc0
vpanic(c12eea08,100,c1167d58,c1820c30,c1820c30,...) at vpanic+0x11f/frame
0xc1820c00
kassert_panic(c1167d58,c3,8,c130d7e4,c130d7a8,...) at
kassert_panic+0xea/frame 0xc1820c24
malloc(380,c1279778,2,0,,...) at malloc+0x308/frame 0xc1820c70
vmem_create(c11a7530,c680,6681000,1000,0,...) at vmem_create+0x29/frame
0xc1820ca0
memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0
Re: ZFS Crashes
On Sun, Aug 11, 2013 at 9:20 AM, Larry Rosenman l...@lerctr.org wrote: In the last 12 hours I've had 4 crashes related to ZFS. total 97 -rw-r--r-- 1 ler ler 136488 Aug 11 11:17 core.txt.1 -rw-r--r-- 1 ler ler 117213 Aug 11 11:17 core.txt.2 -rw-r--r-- 1 ler ler 120357 Aug 11 11:17 core.txt.3 -rw-r--r-- 1 ler ler 71718 Aug 11 11:17 core.txt.4 These are all available at: http://www.lerctr.org/~ler/FreeBSD Any help would be appreciated. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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 Hi, at least one of your panics seems related to the recent changes in kernel virtual address allocation. (namely, http://www.lerctr.org/~ler/FreeBSD/core.txt.3). You can try revert the revision that introduced them and see if this stabilizes things. Just a guess though. http://svnweb.freebsd.org/base?view=revisionrevision=254025 Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: LOR on head ...
On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. sfour...@gmail.com wrote: I am going to respond to this before I forget I had the SAME exact LOR's with ath 9300 and I reported them, however I have since switched out motherboards and the LOR's have strangely diapered here is a full dmesg for a perfectly working system FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1e98220bSSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1c9bfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,NodeId,Topology,b23,b24 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer LAPIC quality 400 ACPI APIC Table: ALASKA A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20130725/tbfadt-630) ioapic0 Version 2.1 irqs 0-23 on motherboard ioapic1 Version 2.1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: ALASKA A M I on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 450 Event timer HPET2 frequency 14318180 Hz quality 450 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0xa port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.2 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 52 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 24 at device 0.0 on pci1 pcib2: ACPI PCI-PCI bridge irq 52 at device 4.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x4800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: ACPI PCI-PCI bridge irq 52 at device 5.0 on pci0 pci3: ACPI PCI bus on pcib3 xhci0: ASMedia ASM1042 USB 3.0 controller mem 0xfe40-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: ACPI PCI-PCI bridge irq 53 at device 7.0 on pci0 pci4: ACPI PCI bus on pcib4 xhci1: ASMedia ASM1042 USB 3.0 controller mem 0xfe30-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: ACPI PCI-PCI bridge irq 53 at device 9.0 on pci0 pci5: ACPI PCI bus on pcib5 ath0: Atheros AR938x mem 0xfe20-0xfe21 irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit
Re: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov a...@freebsd.org wrote: cc1: warnings being treated as errors /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function 'iap_allocate_pmc': /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' may be used uninitialized in this function *** [hwpmc_core.o] Error code 1 -- bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N You can find a patch attached at the end of this mail that should fix the problem. More generally speaking, why are you building -CURRENT using GCC while the default compiler has been clang since November 2012? I understand we cannot completely get rid of GCC as long as Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I see clang default on amd64 so I guess at some point we should declare GCC not officially supported anymore. Putting the additional burden of testing on the committer because two compilers are supported at the same time doesn't scale really well, at least according to me. Index: sys/dev/hwpmc/hwpmc_core.c === --- sys/dev/hwpmc/hwpmc_core.c (revision 250174) +++ sys/dev/hwpmc/hwpmc_core.c (working copy) @@ -1945,7 +1945,7 @@ caps = a-pm_caps; if ((IAP_PMC_CAPS caps) != caps) return (EPERM); - + map = 0;/* XXX: silent GCC warning */ arch = iap_is_event_architectural(pm-pm_event, map); if (arch == EV_IS_ARCH_NOTSUPP) return (EOPNOTSUPP); -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 3:10 PM, Dimitry Andric d...@freebsd.org wrote: On 2013-05-02 12:06, Davide Italiano wrote: On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov a...@freebsd.org wrote: cc1: warnings being treated as errors /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function 'iap_allocate_pmc': /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' may be used uninitialized in this function ... You can find a patch attached at the end of this mail that should fix the problem. Hm, the warning seems to be bogus. Newer versions of gcc (I tried 4.7.3 and 4.8.1) do not warn about 'map' (though they both warn about another variable, which is set, but not used.) More generally speaking, why are you building -CURRENT using GCC while the default compiler has been clang since November 2012? I understand we cannot completely get rid of GCC as long as Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I see clang default on amd64 so I guess at some point we should declare GCC not officially supported anymore. Putting the additional burden of testing on the committer because two compilers are supported at the same time doesn't scale really well, at least according to me. Some people still prefer gcc, and while this warning is a bit annoying, I see no problem in putting in a workaround. Using gcc for arches which Yes, for sure it's not a problem. I try to run 'make universe' when I commit change, but it's already slow on relatively recent hardware, and I just found annoying the need of rebuilding the system using two different compilers (in particular if one of them generates warning that are bogus, as happened in this case). Other than being time-expensive, the switch at runtime from clang to GCC was not so easy for me. In fact, if I try to change from clang to gcc46 and run 'make buildkernel' I get some errors like: cc1: error: unrecognized command line option '-fformat-extensions' cc1: warning: unrecognized command line option -Wno-error-parentheses-equality [enabled by default] cc1: warning: unrecognized command line option -Wno-error-empty-body [enabled by default] cc1: warning: unrecognized command line option -Wno-error-tautological-compare [enabled by default] *** [genassym.o] Error code 1 which disappear actually if I re-run buildworld. Maybe I'm missing something or I'm doing something wrong. But, at the end of the day, I preferred to have my lazyness winning. Actually, I don't think it worth the effort. If there's an easier way to do this, feel free to point me to it. default to clang will most likely have to be supported for quite some time. Also, if the external toolchain support ever comes off the ground, it will probably become necessary to suppress certain warnings on an individual basis; for example, with recent gcc versions, there are quite a large number of variable x set but not used warnings, which are not very useful, most of the time. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov a...@freebsd.org wrote: On 02.05.2013 14:06, Davide Italiano wrote: /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' may be used uninitialized in this function *** [hwpmc_core.o] Error code 1 You can find a patch attached at the end of this mail that should fix the problem. Thanks, it fix this warning. More generally speaking, why are you building -CURRENT using GCC while the default compiler has been clang since November 2012? 1) clang is not ready for production, it is too buggy. See its fixes rate for very common things 'must work' in every compiler. It is included into -current not because of its quality, but to involve developers into clang bugfixes to make its progress faster, and personally me don't want to find clang bugs. 2) Its build time is too long. 3) It generates bigger code. Putting the additional burden of testing on the committer because two compilers are supported at the same time doesn't scale really well, at least according to me. You'll hit this error later in any case, attempting to MFC your changes to -stable with GNU cc. -- bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N I won't object about your 2) and 3), but if you fear to hit bugs you shouldn't probably run -CURRENT. About the backport, I faced the problem of adapting code in the past when merging to stable releases, so this is actually a different problem. If I'd blindly merged the incrimined change to 9-STABLE without building and notifying the GCC warning, then I would expect you ranting at me because of build failure. There's a notion of default compiler in 9 and in 10 and they're different. My opinion is that people should live with it, and unless someone will introduce some mechanism a-la redports.org to overcome the issue, I will take my risks committing changes and fixing failures if they occur. It's already really difficult to have tinderbox not ranting these days, adding another compiler just result in another dimension of complexity in the whole scenario. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: Ports including sys/time.h broken
On Wed, Mar 27, 2013 at 9:28 PM, Pawel Pekala pa...@freebsd.org wrote: For some time now (about month?) ports using sys/time.h include fail to build and I`m sure they were building ok before. At least those seems affected by this: math/atlas math/openblas x11-toolkits/c++-gtk-utils All fail with similar errors: /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:141:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'bttosbt': /usr/include/sys/time.h:144:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:144:12: note: each undeclared identifier is reported only once for each function it appears in /usr/include/sys/time.h:144:23: error: expected ')' before 'bt' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:148:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:206:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:216:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tstosbt': /usr/include/sys/time.h:219:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:219:23: error: expected ')' before 'ts' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:224:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:234:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tvtosbt': /usr/include/sys/time.h:237:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:237:23: error: expected ')' before 'tv' In file included from ../common.h:110:0, from swap.c:40: /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:141:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'bttosbt': /usr/include/sys/time.h:144:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:144:12: note: each undeclared identifier is reported only once for each function it appears in /usr/include/sys/time.h:144:23: error: expected ')' before 'bt' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:148:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:206:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:216:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tstosbt': /usr/include/sys/time.h:219:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:219:23: error: expected ')' before 'ts' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:224:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:234:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tvtosbt': /usr/include/sys/time.h:237:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:237:23: error: expected ')' before 'tv' -- pozdrawiam / with regards Paweł Pękala ___ 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 I'm able to build the ports you mentioned. Even if the informations you give are not enough to diagnose the problem (e.g. which version of which compiler was used to build) my guess is that you're using some version of gcc which is stale, i.e. it was build before changes to system headers. -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: [RFC/RFT] calloutng
The patch has been splitted in smaller logical chunks in order to
improve readability and facilitate review.
The whole code can be found here:
http://people.freebsd.org/~davide/calloutng_split/
In particular:
http://people.freebsd.org/~davide/calloutng_split/sbintime.diff brings
the new type 32.32 fixed point used in lieu of 'int ticks' for the new
callout mechanism and relative functions (conversion from to
{timeval,bintime,timespec}, sbinuptime(), getsbinuptime())
This change is preliminary to
http://people.freebsd.org/~davide/calloutng_split/callout_internals.diff
which contains all the callout changes internally (introduction of
direct dispatching, conversion to sbintime, new precision mechanism)
http://people.freebsd.org/~davide/calloutng_split/cpuidle.diff (see
r242905) introduce some optimization in the sleep time calculation
and choose of the optimal sleep state, when CPU is idle.
http://people.freebsd.org/~mav/calloutng-20130221/libprocstatfix.diff
is a workaround in libprocstat in order to allow world to build after
changes. About this one, I'm not quite sure is the best solution, so
if there are other opinions, I'd be more than happy to hear.
Other patches available in the directory converts some kernel
consumers of callout(9) to the new interface (nanosleep, poll, select,
kqueue, syscons, etc...).
My plan is to commit the whole patchset March 4th, unless there are
valid reasons to not do so.
Any cooment is (as always) appreciated.
Thanks,
Davide
___
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: r246916 probably broke amd64 build
On Wed, Feb 20, 2013 at 10:54 AM, Dag-Erling Smørgrav d...@des.no wrote: Davide Italiano dav...@freebsd.org writes: Unfortunately tinderbox didn't catch this bug because it's triggered only when gcc is used to build kernel. In this particular case, the broken code is only built on platforms which default to clang. Otherwise, it would have been caught when building one of the platforms that default to gcc. I see. In fact this was a very unlucky case (problem in MD code, for a platform that default to clang). The tinderbox servers simply donn't have enough CPU power to build all possible combinations. There isn't even enough for a standard build of all platforms at a reasonable frequency. I have a stack of new servers, but nowhere to host them - see the donations wantlist for details. DES -- Dag-Erling Smørgrav - d...@des.no Sorry I can't help you with that. Thanks, Davide ___ 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: r246916 probably broke amd64 build
On Tue, Feb 19, 2013 at 3:22 PM, Simon L. B. Nielsen si...@qxnitro.org wrote: Hey, I think r246916 broke the build. I get the following when building amd64 kernel: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/x86/isa/clock.c cc1: warnings being treated as errors /usr/src/sys/x86/isa/clock.c: In function 'set_i8254_freq': /usr/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used uninitialized in this function Could you have a look? Thanks. -- 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 It's fixed (r247000). Unfortunately tinderbox didn't catch this bug because it's triggered only when gcc is used to build kernel. Thanks, Davide ___ 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: Running out of bits p_flag (sys/sys/proc.h)
On Sun, Feb 17, 2013 at 2:58 AM, hiren panchasara
hiren.panchas...@gmail.com wrote:
With revision=246484, it seems we have hit the limit.
At $WORK we have one more flag and to accommodate that we need to bump this
up.
Can p_flag be bumped up to u_long?
Index: proc.h
===
--- proc.h (revision 245937)
+++ proc.h (working copy)
@@ -497,7 +497,7 @@
* The following don't make too much sense.
* See the td_ or ke_ versions of the same flags.
*/
- int p_flag; /* (c) P_* flags. */
+ u_long p_flag; /* (c) P_* flags. */
enum {
PRS_NEW = 0,/* In creation */
PRS_NORMAL, /* threads can be run. */
Thanks,
Hiren
___
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
I see at least two problems here:
- The change you propose may result in a KBI breakage.
- sizeof(unsigned long) == 4 on some archs, e.g. my i386 Atom, which
makes the change uneffective.
Thanks,
Davide
___
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: [RFC/RFT] calloutng
[trimmed old mails] Here's a new version of the patch: http://people.freebsd.org/~davide/patches/calloutng-11022012.diff Significant bits changed (after wider discussion and suggestion by phk@): - Introduction of the new sbintime_t type (32.32 fixed point) with the respective conversion (sbintime2bintime, sbintime2timeval etc...) - switch from 64.64 (struct bintime) format to measure time to sbintime_t - Use sbintime_t to represent expected sleep time instead of measuring it in microseconds (cpu_idle_acpi(), cpu_idle_spin() ...). Thanks, Davide ___ 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: hwpmc support for haswell
On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara hiren.panchas...@gmail.com wrote: Hi, I've prepared a patch to add core and uncore events support for haswell processor. I do not have the hardware to test this. It applies cleanly and compiles fine though. http://www.strugglingcoder.info/patches/hwpmc_hw.txt This is initial version of patch and manpage is still missing. I will add it in a few days. Any help in testing is appreciated. Thanks, Hiren It seems Intel won't release this before June (at least to my knowledge). I would claim it'll be difficult to real test this before that date unless someone has prerelease hardware. Thanks Davide ___ 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: hwpmc support for Ivy Bridge Xeon
On Tue, Jan 29, 2013 at 12:29 AM, hiren panchasara hiren.panchas...@gmail.com wrote: On Mon, Jan 28, 2013 at 7:27 PM, hiren panchasara hiren.panchas...@gmail.com wrote: On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara hiren.panchas...@gmail.com wrote: I've tried to update hwpmc by adding support for xeon class of Ivy bridge processors. Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) I do not have a reference machine to test with. Any help in that regard would be appreciated. Got a machine with ivy bridge xeon. Will test my changes and update here soon. Hiren It seems to be working fine: Here is o/p of pmccontrol -L listing all the event counters: http://www.strugglingcoder.info/patches/hwpmc_ibx_pmccontrol.txt I don't see anything wrong there. And below is the o/p of pmctest.py script: http://www.strugglingcoder.info/patches/hwpmc_ibx_pmctest.txt With 'pmctest.py' are you talking about the gnn@ script available in tools/ ? What are you profiling (ls, find, the kernel) ? I've recently discovered an excellent tool from Peter in stress2 suite to test pmc. Maybe you can try it. http://svnweb.freebsd.org/base/user/pho/stress2/misc/pmc.sh?revision=237222view=markup cheers, Hiren Here are the diffs against head (245927): http://www.strugglingcoder.info/patches/hwpmc_ibx.txt Thanks, Hiren ___ 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 Thanks -- Davide ___ 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: hwpmc support for Ivy Bridge Xeon
On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara hiren.panchas...@gmail.com wrote: I've tried to update hwpmc by adding support for xeon class of Ivy bridge processors. Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) I do not have a reference machine to test with. Any help in that regard would be appreciated. Here are the diffs against head (245927): http://www.strugglingcoder.info/patches/hwpmc_ibx.txt Thanks, Hiren ___ 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 From a first look appears good -- I've a couple of observations though. I see your patch covers only core events -- am I missing something? Not really important, and I don't want to be pedantic here, but maybe this can be renamed to something less ugly: static int -iap_event_sb_sbx_ib_ok_on_counter(enum pmc_event pe, int ri) +iap_event_sb_sbx_ib_ibx_ok_on_counter(enum pmc_event pe, int ri) -- Davide ___ 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: [RFC/RFT] calloutng
On Sun, Dec 30, 2012 at 10:17 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: ... I grabbed testsleep.c to test an arm event timer implementation, and had to fix a couple nits... kqueueto was missing from the names[] array, and I had to add a * 1000 to a couple places where usec was stuffed into a timespec's tv_nsec. I also tested the calloutng_12_17 patches and the kqueue stuff behaved very strangely. Then I noticed you had a 12_26 patchset so I tested that (after crudely fixing a couple uninitialized var warnings), and it all looks good on this arm (Raspberry Pi). I'll attach the results. It's so sweet to be able to do precision sleeps. interesting numbers, but there seems to be some problem in computing the exact interval; delays are much larger than expected. In this test, the original timer code used to round to the next multiple of 1 tick and then add another tick (except for the kqueue case), which is exactly what you see in the second set of measurements. The calloutng code however seems to do something odd: in addition to fixed overhead (some 50us, which you can see in the tests for 1us and 300us), all delay seem to be ~10% larger than what is requested, upper bounded to 10ms (note, the numbers are averages so i cannot tell whether all samples are the same or there is some distribution of values). I am not sure if this error is peculiar of the ARM version or also appears on x86/amd64 but I believe it should be fixed. If you look at the results below: 1us possily ok: for very short intervals i would expect some kind of 'reschedule' without actually firing a timer; maybe 50us are what it takes to do a round through the scheduler ? 300us probably ok i guess the extra 50-90us are what it takes to do a round through the scheduler 1000us borderline (this is the case for poll and kqueue, which are rounded to 1ms) here intervals seem to be increased by 10%, and i cannot see a good reason for this (more below). 3000us and above: wrong here again, the intervals seem to be 10% larger than what is requested, perhaps limiting the error to 10-20ms. Maybe the 10% extension results from creating a default 'precision' for legacy calls, but i do not think this is done correctly. First of all, if users do not specify a precision themselves, the automatically generated value should never exceed one tick. Second, the only point of a 'precision' parameter is to merge requests that may be close in time, so if there is already a timer scheduled within [Treq, Treq+precision] i will get it; but if there no pending timer, then one should schedule it for the requested interval. Davide/Alexander, any ideas ? The first question is what couple timecounter/eventtimer is used. Some hardware is slower than other, and this may affect numbers. Thanks for testing, BTW. Davide cheers luigi for t in 1 300 3000 3 30 ; do for m in select poll usleep nanosleep kqueue kqueueto syscall ; do ./testsleep $t $m done done With calloutng_12_26.patch... HZ=100 HZ=250 HZ=1000 -- select 1 55.79 1 50.96 1 61.32 poll1 1109.46 1 1107.86 1 1114.38 usleep 1 56.33 1 72.90 1 62.78 nanosleep 1 52.66 1 55.23 1 64.23 kqueue 1 1114.23 1 1113.81 1 1121.21 kqueueto1 65.44 1 71.00 1 75.01 syscall 1 4.70 1 4.45 1 4.55 select300355.79300357.76300362.35 poll 300 1107.85300 1122.55300 1115.62 usleep300355.28300357.28300360.79 nanosleep 300354.49300355.82300360.62 kqueue300 1112.57300 1118.13300 1117.16 kqueueto 300375.98300378.62300395.61 syscall 300 4.41300 4.45300 4.54 select 3000 3246.75 3000 3246.74 3000 3252.72 poll 3000 3238.10 3000 3229.12 3000 3250.10 usleep 3000 3242.47 3000 3237.06 3000 3249.61 nanosleep3000 3238.79 3000 3231.55 3000 3248.11 kqueue 3000 3240.01 3000 3236.07 3000 3247.60 kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 syscall 3000 4.69 3000 4.44 3000 4.50 select 3 31714.60 3 31941.17 3 32467.69 poll3 31522.76 3 31983.00 3 32497.81 usleep 3
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore writes : On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It is a bad idea, and it is physically pointless, given the stabilities of the timebases available for computers in general. Please just take my word as a time-nut, and use a 32.32 binary format in seconds (see previous email) and be done with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. Right now -- the precision is specified in 'bintime', which is a binary number. It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in the specific platform. I do not really think it worth to create another structure for handling time (e.g. struct bintime32), as it will lead to code duplication for all the basic conversion/math operation. On the other hand, 32.32 may not be enough in the long future. What do you think about that? Thanks, Davide ___ 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: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans b...@optusnet.com.au wrote: On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: In message CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com , Davide Italiano writes: Right now -- the precision is specified in 'bintime', which is a binary number. It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in the specific platform. And that is way overkill for specifying a callout, at best your clock has short term stabilities approaching 1e-8, but likely as bad as 1e-6. So you always agreed with me that bintimes are unsuitable for almost everything, and especially unsuitable for timeouts? :-) (The reason why bintime is important for timekeeping is that we accumulate timeintervals approx 1e3 times a second, so the rounding error has to be much smaller than the short term stability in order to not dominate) bintimes are not unsuitable for timekeeping, but they a painful to use for other APIs. You have to either put bintimes in layers in the other APIs, or convert them to a more suitable format, and there is a problem placing the conversion at points where it is efficient. This thread seems to be mostly about putting the conversion in wrong places. My original objection was about using bintimes for almost everything at the implementation level. I do not really think it worth to create another structure for handling time (e.g. struct bintime32), as it will lead to code No, that was exactly my point: It should be an integer so that comparisons and arithmetic is trivial. A 32.32 format fits nicely into a int64_t which is readily available in the language. I would have tried a 32 bit format with a variable named 'ticks'. Something like: - ticks = 0. Same meaning as now. No changes in ABIs or APIs to use this. The tick period would be constant but for virtual ticks and not too small. hz = 1000 now makes the period too small, and not a power of 2. So make the period 1/128 second. This gives a 1.24.7 binary format. 2**24 seconds is 194 days. - ticks 0. The 31 value bits are now a cookie (descriptor) referring to a bintime or whatever. This case should rarely be used. I don't like it that a tickless kernel, which is needed mainly for power saving, has expanded into complications to support short timeouts which should rarely be used. Bruce, I don't really agree with this. The data addressed by cookie should be still stored somewhere, and KBI will result broken. This, indeed, is not real problem as long as current calloutng code heavily breaks KBI, but if that was your point, I don't see how your proposed change could help. As I said in my previous email: typedef dur_t int64_t;/* signed for bug catching */ #define DURSEC ((dur_t)1 32) #define DURMIN (DURSEC * 60) #define DURMSEC (DURSEC / 1000) #define DURUSEC (DURSEC / 1000) #define DURNSEC (DURSEC / 100) (Bikeshed the names at your convenience) Then you can say callout_foo(34 * DURSEC) callout_foo(2400 * DURMSEC) or callout_foo(500 * DURNSEC) Constructing the cookie for my special case would not be so easy. With this format you can specify callouts 68 years into the future with quarter nanosecond resolution, and you can trivially and efficiently compare dur_t's with if (d1 d2) This would make a better general format than timevals, timespecs and of course bintimes :-). It is a bit wasteful for timeouts since its extremes are rarely used. Malicious and broken callers can still cause overflow at 68 years, so you have to check for it and handle it. The limit of 194 days is just as good for timeouts. Bruce I think the phk's proposal is better. About your overflow objection, I think is really unlikely to happen, but better safe than sorry. Thanks Davide ___ 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: API explosion (Re: [RFC/RFT] calloutng)
dropping phk _AT_ onelab2 _DOT_ something from CC as long as it doesn't seem a valid mail address and I'm annoyed mails bounce back. On Wed, Dec 19, 2012 at 6:20 AM, Bruce Evans b...@optusnet.com.au wrote: On Wed, 19 Dec 2012, Davide Italiano wrote: On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans b...@optusnet.com.au wrote: I would have tried a 32 bit format with a variable named 'ticks'. Something like: - ticks = 0. Same meaning as now. No changes in ABIs or APIs to use this. The tick period would be constant but for virtual ticks and not too small. hz = 1000 now makes the period too small, and not a power of 2. So make the period 1/128 second. This gives a 1.24.7 binary format. 2**24 seconds is 194 days. - ticks 0. The 31 value bits are now a cookie (descriptor) referring to a bintime or whatever. This case should rarely be used. I don't like it that a tickless kernel, which is needed mainly for power saving, has expanded into complications to support short timeouts which should rarely be used. Bruce, I don't really agree with this. The data addressed by cookie should be still stored somewhere, and KBI will result broken. This, indeed, is not real problem as long as current calloutng code heavily breaks KBI, but if that was your point, I don't see how your proposed change could help. In the old API, it is an error to pass ticks 0, so only broken old callers are affected. Of course, if there are any then it would be hard to detect their garbage cookies. Anywy, it's too later to change to this, and maybe also to a 32.32 format. [32.32 format] It's not too late. What I'd like to do, right now people got interested in the problem is agreeing on the interface used. Following this thread, as I've already discussed to mav@, we would like to decide what of the two is better: - specify precision as additional argument (as we're doing right now) - use 'flags' argument If we allow time argument to be relative and not absolute, as suggested by luigi@, we can easily use relative precision where we had to use ffl() before. This would make a better general format than timevals, timespecs and of course bintimes :-). It is a bit wasteful for timeouts since its extremes are rarely used. Malicious and broken callers can still cause overflow at 68 years, so you have to check for it and handle it. The limit of 194 days is just as good for timeouts. I think the phk's proposal is better. About your overflow objection, I think is really unlikely to happen, but better safe than sorry. It's very easy for applications to cause kernel overflow using valid syscall args like tv_sec = TIME_T_MAX for a relative time in nanosleep(). Adding TIME_T_MAX to the current time in seconds overflow for all current times except for the first second after the Epoch. There is no difference between the overflow for 32-bit and 64-bit time_t's for this. This is now mostly handled so that the behaviour is harmless although wrong. E.g., the timeout might become negative, and then since it is not a cookie it is silently replaced by a timeout of 1 tick. In nanosleep(), IIRC there are further overflows that result in returning early instead of retrying the 1-tick timeouts endlessly. Bruce Thanks, Davide ___ 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: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng
On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo ri...@iet.unipi.it wrote: [addressing the various items separately] On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote: On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote: ... - for several functions the only change is the name of an argument from busy to us. Can you elaborate the reason for the change, and whether us means microseconds or the pronoun ?) Please see r242905 by mav@. i see the goal of this patch is to pass along the amount of time till the next timer. I wonder why the choice is to use (actually, call) the value microseconds rather use a bintime or something scaled and with a well defined resolution. In fact looking at the relevant diff http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905r2=242904pathrev=242905 cpu_idleclock() actually returns a value that is not even microseconds but 1/(2^20) seconds. The value seems to be ignored right now so it would be a good time to discuss the resolution. I am concerned that at some point (5 years from now perhaps ?) microseconds might start to become too coarse and we would like something with a more fine-grained resolution. On the other hand, for the purposes of this change, we can probably live with an upper limit of some seconds (waking up the machine once per second is not going to kill performance). I would talk more about power consumption problem rather than performances. Yes, you're right because now, even with calloutng changes, the CPU is woken up at least twice per second. The wheel scan, in case it doesn't find a new callout to schedule in the next half-second, schedules an interrupt half a second from now (where now is the time obtained using getbinuptime()/binuptime()). This is a threshold we set up empirically, and it resulted is good for now. But in the future someone may raise the threshold to 1 second, 10 seconds, or something like. So, I don't agree with your statement. So i would suggest to make the argument to these functions uint_32 or uint_64 (preferably the same for 32- and 64-bit machines), rename it to something different from 'us' and have at least 28-30 fractional bits to represent a bintime. Right now you are using a bintime with 20 fractional and 11 or 43 bits for the integer part. cheers luigi Thanks Davide ___ 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: [RFC/RFT] calloutng
On Mon, Dec 17, 2012 at 2:39 PM, David O'Brien obr...@freebsd.org wrote: On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote: On 15.12.2012 23:03, Alexander Motin wrote: Sorry, it's my fault. I've tried to save some time on patch generation and forgot about that change in lib/. We haven't touched user-level in our work except that file. Here is patch with that chunk added: http://people.freebsd.org/~mav/calloutng_12_15_1.patch And one more part I've missed is manual pages update, that probably needs more improvements: http://people.freebsd.org/~mav/calloutng_12_15.man.patch Perhaps use the SCM at what its good at? Sync your branch with HEAD and then do an 'svn diff ^/head' and your branch. -- -- David (obr...@freebsd.org) Last time I tried doing that the way you describe, I got an output with tons svn:mergeinfo and I didn't find a way to suppress them if not manually. e.g. Property changes on: usr.bin/procstat ___ Modified: svn:mergeinfo Merged /head/usr.bin/procstat:r236314-239017 Index: usr.bin/calendar === --- usr.bin/calendar(.../head) (revision 239166) +++ usr.bin/calendar(.../projects/calloutng)(revision 239166) Can you help me in understanding what I did wrong? Thanks ___ 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: [RFC/RFT] calloutng
On Sat, Dec 15, 2012 at 10:05 AM, Adrian Chadd adr...@freebsd.org wrote: Hi, Can you please test with MIPS? David has a MIPS board now. Quoting from my first mail -- We tested the code on amd64, MIPS and arm. I used the board you gave to me. I run only some basic tests, but I can look forward running something more complicated in order to track regressions (if any). Can you also test that various performance tests haven't been affected? Eg, do iperf tests through that MIPS board, configured up as an AP. Can you be more specific? Do we need it configured as AP or this situation can be in some way simulated? Please test with a bunch of disk IO activity too. What benckmark/tool do you suggest? iozone? Do you think is better attaching some external drive and run test on that rather than on the flash present on the board? I know this is a lot to ask for, but I'd hate to see some driver / subsystem behaviour change because you didn't quite see the evil way the callout mechanism is used, or how the timer stuff is affecting driver pre-emption. I understand your concerns. I'll try to do my best in order to heavily test. Any kind of suggestion is obviously appreciated. Thanks, Adrian On 15 December 2012 08:55, Alexander Motin m...@freebsd.org wrote: Hi. I'm sorry to interrupt review, but as usual good ideas came during the final testing, causing another round. :) Here is updated patch for HEAD, that includes several new changes: http://people.freebsd.org/~mav/calloutng_12_15.patch The new changes are: -- Precision and event aggregation code was reworked. Instead of previous -prec/+prec representation, precision is now single-sided -- -0/+prec. It allowed to significantly improve precision on long time intervals for APIs which imply that event should not happen before the specified time. Depending on CPU activity, mistake for long time intervals now will never be more then 1-500ms, even if specified precision allows more. -- Some minor optimizations were made to reduce callout overhead and latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer and TSC timecounter usleep(1) call from user-level executes in just 5-6us, instead of 7-8us before. Now it can do 180K cycles per second on single CPU with only partial CPU load. -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, setrlimit) were modified to reduce number of interrupts, also with event aggregation by explicit specification of the acceptable events precision. Now my Core2Duo test system has only 30 interrupts per second in idle. If not remaining syscons events, it could easily be 15. My IvyBridge ultrabook first time in its history shown 5.5 hours of battery time with full screen brightness and 10 hours with lid closed. -- Some kernel functions were added to make KPIs more complete. I've successfully tested this patch on amd64 and arm. -- Alexander Motin ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to freebsd-arch-unsubscr...@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: [RFC/RFT] calloutng
On Sat, Dec 15, 2012 at 12:34 PM, Mark Johnston mark...@gmail.com wrote: On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: Hi. I'm sorry to interrupt review, but as usual good ideas came during the final testing, causing another round. :) Here is updated patch for HEAD, that includes several new changes: http://people.freebsd.org/~mav/calloutng_12_15.patch This patch breaks the libprocstat build. Specifically, the OpenSolaris sys/time.h defines the preprocessor symbols gethrestime and gethrestime_sec. These symbols are also defined in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. libprocstat:zfs.c is compiled using include paths that pick up the OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. zfs.c includes taskqueue.h (with _KERNEL defined), which includes _callout.h, so both time.h and zfs_context.h are included in zfs.c, and the symbols are thus defined twice. The patch below fixes the build for me. Another approach might be to include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. Thanks, -Mark diff --git a/lib/libprocstat/zfs.c b/lib/libprocstat/zfs.c index aa6d78e..f8844bf 100644 --- a/lib/libprocstat/zfs.c +++ b/lib/libprocstat/zfs.c @@ -35,6 +35,7 @@ #undef lbolt #undef lbolt64 +#undef gethrestime #undef gethrestime_sec #include sys/zfs_context.h #include sys/spa.h I fixed (or at least workarounded) that issue during the summer. http://svnweb.freebsd.org/base?view=revisionrevision=237068 Probably that was lost somewhere. We're going to regenerate a patch, but for now I suggest to patch that manually or to checkout the calloutng project repository. ___ 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: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano dav...@freebsd.org
wrote:
Hi.
This patch takes callout(9) and redesign the KPI and the
implementation. The main objective of this work is making the
subsystem tickless. In the last several years, this possibility has
been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
but until now noone really implemented that.
If you want a complete history of what has been done in the last
months you can check the calloutng project repository
http://svnweb.freebsd.org/base/projects/calloutng/
For lazy people, here's a summary:
thanks for the work and the detailed summary.
Perhaps it would be useful if you could provide a few high level
details on the use and performance of the new scheme, such as:
- is the old callout KPI still available ? (i am asking because it would
help maintaining third party kernel modules that are expected to
work on different FreeBSD releases)
Obviously the old KPI is still available. callout(9) is a very popular
interface and I don't think removing the old interface is a good idea,
because could make unhappy some vendor when its code doesn't build
anymore on FreeBSD.
- do you have numbers on what is the fastest rate at which callouts
can be fired (e.g. say you have a callout which increments a
counter and schedules the next callout in (struct bintime){0,1} ) ?
- is there a possibility that if callout requests are too close to each
other (e.g. the above test) the thread dispatching callouts will
run forever ? if so, is there a way to make such thread yield
after a while ?
- since you mentioned nanosleep() poll() and select() have been
ported to the new callout, is there a way to guarantee that user
using these functions with a very short timeout are actually
descheduled as opposed to interval too short, don't bother ?
- do you have numbers on how many calls per second we can
have for a process that does
for (;;) { nanosleep(min_value_that_causes_descheduling);
I also have some comments on the diff:
- can you provide a diff -p ?
- for several functions the only change is the name of an argument
from busy to us. Can you elaborate the reason for the change,
and whether us means microseconds or the pronoun ?)
Please see r242905 by mav@.
Finally, a more substantial comment:
- a lot of functions which formerly had only a timo argument
now have timo, bt, precision, flags. Take seltdwait() as an example.
seltdwait() is not part of the public KPI. It has been modified to
avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
two separate functions, even though we could share most of the code is
not a clever approach, IMHO.
As I told before, seltdwait() is not exposed so we can modify its
argument without breaking anything.
It seems that you have been undecided between two approaches:
for some of these functions you have preserved the original function
that deals with ticks and introduced a new one that deals with the
bintime,
whereas in other cases you have modified the original function to add
bt, precision, flags.
I'm not. All the functions which are part of the public KPI (e.g.
condvar(9), sleepq(9), *) are still available. *_flags variants have
been introduced so that consumers can take advantage of the new
'precision tolerance mechanism' implemented. Also, *_bt variants have
been introduced. I don't see any undecision between the two
approaches.
Please note that now the callout backend deals with bintime, so every
time callout_reset_on() is called, the 'tick' argument passed is
silently converted to bintime.
I would suggest a more uniform approach, namely:
- preserve all the existing functions (T) that take a timeout in ticks;
- add a new set of corresponding functions (BT) that take
bt, precision, flags _instead_ of the ticks
- the functions (T) make immediately the conversion from ticks to
bintime(s), using macros or inline
- optionally, convert kernel components to the new (BT) functions
where this makes sense (e.g. we can exploit the finer-granularity
of the new calls, etc.)
cheers
luigi
1) callout(9) is not anymore constrained to the resolution a periodic
hz clock can give. In order to do that, the eventtimers(4) subsystem
is used as backend.
2) Conversely from what discussed in past, we maintained the callwheel
as underlying data structure for keeping track of the outstading
timeouts. This choice has a couple of advantages, in particular we can
still take benefits from the O(1) average complexity of the wheel for
all the operations. Also, we thought the code duplication that would
arise from the use of a two-staged backend for callout (e.g. use wheel
for coarse resolution event and another data structure, such as an
heap for high resolution events), is unacceptable. In fact
Re: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano dav...@freebsd.org wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano dav...@freebsd.org
wrote:
Hi.
This patch takes callout(9) and redesign the KPI and the
implementation. The main objective of this work is making the
subsystem tickless. In the last several years, this possibility has
been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
but until now noone really implemented that.
If you want a complete history of what has been done in the last
months you can check the calloutng project repository
http://svnweb.freebsd.org/base/projects/calloutng/
For lazy people, here's a summary:
thanks for the work and the detailed summary.
Perhaps it would be useful if you could provide a few high level
details on the use and performance of the new scheme, such as:
- is the old callout KPI still available ? (i am asking because it would
help maintaining third party kernel modules that are expected to
work on different FreeBSD releases)
Obviously the old KPI is still available. callout(9) is a very popular
interface and I don't think removing the old interface is a good idea,
because could make unhappy some vendor when its code doesn't build
anymore on FreeBSD.
- do you have numbers on what is the fastest rate at which callouts
can be fired (e.g. say you have a callout which increments a
counter and schedules the next callout in (struct bintime){0,1} ) ?
Right now, all the services rely on the old interface. This means they
cannot be fired before 1 tick has elapsed, e.g. considering hz = 1000
on most of the machines, 1 millisecond.
Now that nanosleep() relies on the new interface, we measured 4-5
microseconds latency for the processing before the callout is actually
fired. I can't say if we can still lower this value, but I cannot
imagine, for now, a consumer that actually request a shorter timeout.
- is there a possibility that if callout requests are too close to each
other (e.g. the above test) the thread dispatching callouts will
run forever ? if so, is there a way to make such thread yield
after a while ?
Most of the processing is still done in a SWI thread, at a later
time, so I don't think this is a problem.
- since you mentioned nanosleep() poll() and select() have been
ported to the new callout, is there a way to guarantee that user
using these functions with a very short timeout are actually
descheduled as opposed to interval too short, don't bother ?
- do you have numbers on how many calls per second we can
have for a process that does
for (;;) { nanosleep(min_value_that_causes_descheduling);
I don't follow you here.
I also have some comments on the diff:
- can you provide a diff -p ?
- for several functions the only change is the name of an argument
from busy to us. Can you elaborate the reason for the change,
and whether us means microseconds or the pronoun ?)
Please see r242905 by mav@.
Finally, a more substantial comment:
- a lot of functions which formerly had only a timo argument
now have timo, bt, precision, flags. Take seltdwait() as an example.
seltdwait() is not part of the public KPI. It has been modified to
avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
two separate functions, even though we could share most of the code is
not a clever approach, IMHO.
As I told before, seltdwait() is not exposed so we can modify its
argument without breaking anything.
It seems that you have been undecided between two approaches:
for some of these functions you have preserved the original function
that deals with ticks and introduced a new one that deals with the
bintime,
whereas in other cases you have modified the original function to add
bt, precision, flags.
I'm not. All the functions which are part of the public KPI (e.g.
condvar(9), sleepq(9), *) are still available. *_flags variants have
been introduced so that consumers can take advantage of the new
'precision tolerance mechanism' implemented. Also, *_bt variants have
been introduced. I don't see any undecision between the two
approaches.
Please note that now the callout backend deals with bintime, so every
time callout_reset_on() is called, the 'tick' argument passed is
silently converted to bintime.
I would suggest a more uniform approach, namely:
- preserve all the existing functions (T) that take a timeout in ticks;
- add a new set of corresponding functions (BT) that take
bt, precision, flags _instead_ of the ticks
- the functions (T) make immediately the conversion from ticks to
bintime(s), using macros or inline
- optionally, convert kernel components to the new (BT) functions
where this makes sense (e.g. we can exploit the finer-granularity
of the new calls, etc.)
This is the strategy we followed.
cheers
Re: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 3:21 PM, Oliver Pinter oliver.p...@gmail.com wrote:
Hi!
635 - return tticks;
636 + getbinuptime(pbt);
637 + bt.sec = data / 1000;
638 + bt.frac = (data % 1000) * (uint64_t)1844674407309000LL;
639 + bintime_add(bt, pbt);
640 + return bt;
641 }
What is this 1844674407309000LL constant?
783 @@ -275,7 +288,7 @@
784 do {
785 th = timehands;
786 gen = th-th_generation;
787 - bintime2timeval(th-th_offset, tvp);
788 + Bintime2timeval(th-th_offset, tvp);
789 } while (gen == 0 || gen != th-th_generation);
790 }
791
Capital B is there possible a typo?
Hi Oliver,
thanks for reporting. Yes, both are typos.
The costant is /* 18446744073709 = int(2^64 / 100) */ used to
convert from timeval to bintime.
On 12/14/12, Davide Italiano dav...@freebsd.org wrote:
On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano dav...@freebsd.org
wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano dav...@freebsd.org
wrote:
Hi.
This patch takes callout(9) and redesign the KPI and the
implementation. The main objective of this work is making the
subsystem tickless. In the last several years, this possibility has
been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
but until now noone really implemented that.
If you want a complete history of what has been done in the last
months you can check the calloutng project repository
http://svnweb.freebsd.org/base/projects/calloutng/
For lazy people, here's a summary:
thanks for the work and the detailed summary.
Perhaps it would be useful if you could provide a few high level
details on the use and performance of the new scheme, such as:
- is the old callout KPI still available ? (i am asking because it would
help maintaining third party kernel modules that are expected to
work on different FreeBSD releases)
Obviously the old KPI is still available. callout(9) is a very popular
interface and I don't think removing the old interface is a good idea,
because could make unhappy some vendor when its code doesn't build
anymore on FreeBSD.
- do you have numbers on what is the fastest rate at which callouts
can be fired (e.g. say you have a callout which increments a
counter and schedules the next callout in (struct bintime){0,1} ) ?
Right now, all the services rely on the old interface. This means they
cannot be fired before 1 tick has elapsed, e.g. considering hz = 1000
on most of the machines, 1 millisecond.
Now that nanosleep() relies on the new interface, we measured 4-5
microseconds latency for the processing before the callout is actually
fired. I can't say if we can still lower this value, but I cannot
imagine, for now, a consumer that actually request a shorter timeout.
- is there a possibility that if callout requests are too close to each
other (e.g. the above test) the thread dispatching callouts will
run forever ? if so, is there a way to make such thread yield
after a while ?
Most of the processing is still done in a SWI thread, at a later
time, so I don't think this is a problem.
- since you mentioned nanosleep() poll() and select() have been
ported to the new callout, is there a way to guarantee that user
using these functions with a very short timeout are actually
descheduled as opposed to interval too short, don't bother ?
- do you have numbers on how many calls per second we can
have for a process that does
for (;;) { nanosleep(min_value_that_causes_descheduling);
I don't follow you here.
I also have some comments on the diff:
- can you provide a diff -p ?
- for several functions the only change is the name of an argument
from busy to us. Can you elaborate the reason for the change,
and whether us means microseconds or the pronoun ?)
Please see r242905 by mav@.
Finally, a more substantial comment:
- a lot of functions which formerly had only a timo argument
now have timo, bt, precision, flags. Take seltdwait() as an example.
seltdwait() is not part of the public KPI. It has been modified to
avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
two separate functions, even though we could share most of the code is
not a clever approach, IMHO.
As I told before, seltdwait() is not exposed so we can modify its
argument without breaking anything.
It seems that you have been undecided between two approaches:
for some of these functions you have preserved the original function
that deals with ticks and introduced a new one that deals with the
bintime,
whereas in other cases you have modified the original function to add
bt, precision, flags.
I'm not. All the functions which are part of the public KPI (e.g.
condvar(9), sleepq(9), *) are still available. *_flags
[RFC/RFT] calloutng
Hi. This patch takes callout(9) and redesign the KPI and the implementation. The main objective of this work is making the subsystem tickless. In the last several years, this possibility has been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), but until now noone really implemented that. If you want a complete history of what has been done in the last months you can check the calloutng project repository http://svnweb.freebsd.org/base/projects/calloutng/ For lazy people, here's a summary: 1) callout(9) is not anymore constrained to the resolution a periodic hz clock can give. In order to do that, the eventtimers(4) subsystem is used as backend. 2) Conversely from what discussed in past, we maintained the callwheel as underlying data structure for keeping track of the outstading timeouts. This choice has a couple of advantages, in particular we can still take benefits from the O(1) average complexity of the wheel for all the operations. Also, we thought the code duplication that would arise from the use of a two-staged backend for callout (e.g. use wheel for coarse resolution event and another data structure, such as an heap for high resolution events), is unacceptable. In fact, as long as callout gained the ability to migrate from a cpu to another having a double backend would mean doubling the code for the migration path. 3) A way to dispatch interrupts from hardware interrupt context has been implemented, using special callout flag. This has limited applicability, but avoid the dispatching of a SWI thread for handling specific callouts, avoiding the wake up of another CPU for processing and a (relatively useless) context switch 4) As long as new callout mechanism deals with bintime and not anymore with ticks, time is specified as absolute and not relative anymore. In order to get current time binuptime() or getbinuptime() is used, and a sysctl is introduced to selectively choose the function to use, based on a precision threshold. 5) A mechanism for specifying precision tolerance has been implemented. The callout processing mechanism has been adapted and the callout data structure augmented so that the codepath can take advantage and aggregate events which overlap in time. The new proposed KPI for callout is the following: callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., int flags) where ‘time’ argument represets the time at which the callout should fire, ‘pr’ represents the precision tolerance expressed as an absolute value, and ‘flags’, which could be used to specify new features, i.e. for now, the possibility to run the callout from fast interrupt context. The old KPI has been extended introducing the callout_reset_flags() function, which is the same of callout_reset*(), but takes an additional argument ‘int flags’ that can be used in the same fashion of the ‘flags’ argument for the new KPI. Using the ‘flags’ consumers can also specify relative precision tolerance in terms of power-of-two portion of the timeout passed as ticks. Using this strategy, the new precision mechanism can be used for the existing services without major modifications. Some consumers have been ported to the new KPI, in particular nanosleep(), poll(), select(), because they take immediate advantage from the arbitrary precision offered by the new infrastructure. For some statistics about the outcome of the conversion to the new service, please refer to the end of this e-mail: http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html We didn't measure any significant performance regressions with hwmpc(4), using some benckmarks programs: http://people.freebsd.org/~davide/poll_test/poll_test.c http://people.freebsd.org/~mav/testsleep.c http://people.freebsd.org/~mav/testidle.c We tested the code on amd64, MIPS and arm. Any kind of testing or comment would be really appreciated. The full diff of the work against HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff If noone have objections, we plan to merge the repository to HEAD in a week or so. Thanks, Davide ___ 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: Dynamic Ticks/HZ
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden li...@rewt.org.uk wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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 Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. -- Davide ___ 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: Dynamic Ticks/HZ
On Nov 4, 2012 10:40 PM, Joe Holden li...@rewt.org.uk wrote: Davide Italiano wrote: On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden li...@rewt.org.uk wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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 Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. I'm also using a one second refresh rate, the system is entirely idle and the interupt rate is almost entirely static at 1127, occasionally it will drop to 1119. From what I understand the timer is hz/ticks which became dynamic in 9.0, although that behaviour doesn't appear to be in HEAD anymore, at least on this hardware. Thanks, J It should be available, AFAIK. As I can see from your previous post you get about 20 interrupts on cpu1. This number is about 1/100 of the value you get on a !tickless kernel. If you provide the required ktr infos, probably someone will take a look. ___ 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: [CFT] hwpmc support for Intel Ivy Bridge
On Tue, Sep 4, 2012 at 9:35 AM, Fabien Thomas fabien.tho...@netasq.com wrote: Le 3 sept. 2012 à 23:23, Baptiste Daroussin a écrit : On Mon, Sep 03, 2012 at 02:04:21PM +0200, Fabien Thomas wrote: Hi, Find a patch that add Intel Ivy Bridge support to hwpmc(9). The patch also support offcore RSP token for Sandy Bridge. Note: No uncore support. Tested on: Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz (2494.35-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 http://people.freebsd.org/~fabient/patch-hwpmc_ivy_bridge_head cd /usr/src patch -p0 patch-hwpmc_ivy_bridge_head and rebuild world. Fabien World building, I'll keep you in touch Is there any particulat testing, I can do other than using the new world? Thanks for testing! Yes you can test it quickly using top mode for example: kldload hwpmc pmccontrol -L to list all events some test: - offcore pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -w1 -T - unhalted cycle (programmable counter) pmcstat -n200 -SCPU_CLK_UNHALTED.THREAD_P -w4 -T - INSTR_RETIRED_ANY (fixed counter) pmcstat -n200 -S INSTR_RETIRED_ANY -w4 -T - Soft counter: pmcstat -SPAGE_FAULT.ALL -w4 -T all at the same time (and change view by pressing 'p': pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -n200 -SCPU_CLK_UNHALTED.THREAD_P -n200 -S INSTR_RETIRED_ANY -SPAGE_FAULT.ALL -w1 -T all events are described in the man page pmc.ivybridge regards, Bapt I suggest you to run the script you can find in /head/tools/test/hwpmc/pmctest.py , courtesy of gnn@. Thanks Davide ___ 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: [CFT] hwpmc support for Intel Ivy Bridge
[trimming old mails] Hi, here are the results # pmccontrol -L SOFT CLOCK.STAT CLOCK.HARD LOCK.FAILED PAGE_FAULT.WRITE PAGE_FAULT.READ PAGE_FAULT.ALL # pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -w1 -T pmcstat: ERROR: Cannot allocate system-mode pmc with specification OFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY: Invalid argument # pmcstat -n200 -S INSTR_RETIRED_ANY -w4 -T pmcstat: ERROR: Cannot allocate system-mode pmc with specification INSTR_RETIRED_ANY: Invalid argument # pmcstat -n200 -S INSTR_RETIRED_ANY -w4 -T pmcstat: ERROR: Cannot allocate system-mode pmc with specification INSTR_RETIRED_ANY: Invalid argument # pmcstat -SPAGE_FAULT.ALL -w4 -T (This one seems to work correctly # pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -n200 -SCPU_CLK_UNHALTED.THREAD_P -n200 -S INSTR_RETIRED_ANY -SPAGE_FAULT pmcstat: ERROR: Cannot allocate system-mode pmc with specification OFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY: Invalid argument Are you running this test on real hardware or are you using an hypervisor? The pmctest.py fails: # ./test/hwpmc/pmctest.py Traceback (most recent call last): File ./test/hwpmc/pmctest.py, line 94, in module main() File ./test/hwpmc/pmctest.py, line 81, in main stdout=PIPE) File /usr/local/lib/python2.7/subprocess.py, line 679, in __init__ errread, errwrite) File /usr/local/lib/python2.7/subprocess.py, line 1249, in _execute_child raise child_exception TypeError: execv() arg 2 must contain only strings regards, Bapt Yes, this is expected. You should specify a program that should be executed (to make measurements on it). I used to use 'ls' on my tests, using -p. Davide ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 7:05 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao atti...@freebsd.org wrote: On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao atti...@freebsd.org wrote: You don't want to work cooperatively. Why is it that mbuf's refactoring consultation is being held in internal, private, committers-and-invite-only-restricted meeting at BSDCan ? Why is it that so much review and discussion on changes are held privately ? Arnaud, belive me, to date I don't recall a single major technical decision that has been settled exclusively in private (not subjected to peer review) and in particular in person (e-mail help you focus on a lot of different details that you may not have under control when talking to people, etc). Whose call is it to declare something worth public discussion ? No one. Every time I see a Suggested by:, Submitted by:, Reported by:, and especially Approved by:, there should to be a public reference of the mentioned communication. Sometimes it is useful that a limited number of developers is involved in initial brainstorming of some works, Never. but after this period constructive people usually ask for peer review publishing their plans on the mailing lists or other media. Again, never. By doing so, you merely put the community in a situation where, well, We, committers, have come with this, you can either accept or STFU, but no major changes will be made because we decided so. The callout-ng conference at BSDCan was just beautiful, it was basically: Speaker: we will do this Audience: how about this situation ? What you will do will not work. Speaker: thank you for listening, end of the conference It was beautiful to witness. Well, my talk was mainly there to collect some opinion on how to continue my work. IIRC, the only one objection was on supporting callout execution from hw interrupt context. Mainly, the objection moved was that there were no practical applications for that. It turned out I found some, and in any case it wasn't it will not work but probably it's not an effort you want to put because the consumers that can exploit some functionality are few. I wasn't really so familiar with that so I hesitated in answering. In any case, I liked a lot the objection moved by Attilio because it gave me the possibility to investigate and find out the right direction. As you may see, there's a branch in projects/ in which the feature that won't work is implemented, so, maybe you're missing something. If you had some concerns on it you can raise up your hand and tell: hey, that sucks. It would be better than getting this feedback after 3 months of work honestly. I have nothing in contrary about getting feedbacks (negative or positive). But probably you belong to that kind of people that are able to tell only behind a monitor, so this is my last word on the topic. Get a life. If you don't see any public further discussion this may be meaning: a) the BSDCan meetings have been fruitless and there is no precise plan/roadmap/etc. so not only you make it private, but it shamelessly failed... b) there is still not consensus on details Then the discussion should stop, public records are kept for reference in the future. There is no problem with this. and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. This is not the way openness should be about. - Arnaud Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Davide ___ 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: possible array out of bounds access in sys/netinet/sctp_output.c
On Sun, Nov 27, 2011 at 5:24 PM, Jilles Tjoelker jil...@stack.nl wrote: On Sun, Nov 27, 2011 at 03:45:36PM +, Alexander Best wrote: i've been playing with clang tot and noticed the following error: /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing -march=core2 -std=c99 -g -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wno-error=tautological-compare -Wno-error=shift-count-negative -Wno-error=shift-count-overflow -Wno-error=shift-overflow -Wno-error=conversion -Wno-error=empty-body -Wno-error=gnu-designator -Wno-error=format -Wno-error=format-invalid-specifier -Wno-error=format-extra-args -Werror /usr/git-freebsd-head/sys/netinet/sctp_output.c clang: warning: argument unused during compilation: '-fformat-extensions' /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array index 1 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] sup_addr-addr_type[1] = htons(SCTP_IPV6_ADDRESS); ^ ~ /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array 'addr_type' declared here uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported address ^ 1 error generated. *** Error code 1 Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. this is from a GENERIC kernel build (so INET + INET6) for amd64. is this a false positive, or is length(sup_addr-addr_type) really == 1, thus making sup_addr-addr_type[1] an illegal access? This is the fairly common construct of a variable-length array at the end of a struct. With C89, this was not allowed but defining one element and allocating more elements worked in most implementations. C99 recognized this need and created a way to do it, which looks like uint16_t addr_type[];. This adds any necessary padding and allows access to however many elements have been allocated. Also, if it is not at the end of a struct it is an error. Using this new construct requires code changes because some code such as fairly close to the error message relies on the size of the one element already in the struct. -- Jilles Tjoelker ___ 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 I looked at sctp_send_initiate() and it seems that independently from the number of types supported (IPV6/IPV4 or both) two elements are allocated in the array sup_addr-addr_type[0] . In case only a type is supported one of the elements is simply padding. (http://fxr.watson.org/fxr/source/netinet/sctp_output.c#L4670) . So, this should fix the issue, but maybe I'm wrong so feel free to correct me. http://davit.altervista.org/sctp_header_types.diff I defined a new macro mainly because SCTP_ARRAY_MIN_LEN is used in another place, i.e. in the field name of struct sctp_host_name_param, defined in sctp_header.h). Thanks to arundel@ for testing. Regards Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] iap_event_westmere_ok_on_counter(), some events missing
Hi hackers, I've taken a closer look to iap_event_westmere_ok_on_counter() and comparing the code with the intel documentation it seems that some events some events valid only on 0-1 counter are not listed. Maybe I'm missing somethin', so please point me out. Otherwise, there's a patch that should fix http://davit.altervista.org/westmere_ok_on_counter.diff For more info, in the Intel developers manual volume 3, appendix A (field comments). Kind Regards Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Intel Sandy Bridge support for hwpmc
On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose ambrose...@gmail.com wrote:
hi, I apply your patch on this
[root@capoor-daemon /usr/src]# git show
commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
Author: kensmith kensm...@freebsd.org
Date: Mon Nov 14 00:45:25 2011 +
The releng/9.0 release branch has been created so convert stable/9 over
to our standard Politically Correct name for the balance of the
9.0-RELEASE
release cycle.
Approved by: re (implicit)
when my machine shutdown in my absence yesterday evening, I find a
kernel oops this morning,(sorry, just printf, I can not get a kernel
dump)
the kernel says it is at uncore_pcpu_fini+0x5b
I check the source, and it is at
static int
uncore_pcpu_fini(struct pmc_mdep *md, int cpu)
{
.
for (n = 0; n npmc; n++)
wrmsr(UCP_EVSEL0 + n, 0); //here
.
here is my cpu type, and build hwpmc into kernel
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-PRERELEASE #0 r+4ec1d95-dirty: Mon Nov 14 15:31:45 CST 2011
root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64
CPU: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz (2793.02-MHz K8-class CPU)
I will try to apply this to current to see if this is reproduced.
2011/11/14 Attilio Rao atti...@freebsd.org:
2011/11/13 Davide Italiano davide.itali...@gmail.com:
On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano
davide.itali...@gmail.com wrote:
Good evening folks.
During last days I've written a patch to add sandy bridge support to
hwpmc. Until now, the most recent Intel processor microarchitecture
supported was Westmere.
Testing is appreciated, in order to see if there's something that have
to be fixed.
You can find the diff here:
http://davit.altervista.rg/hwpmc_sandy_bridge.diff
I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@
and fabient@ for the useful suggestions.
Best
Davide
Sorry, bad link. It should be:
http://davit.altervista.org/hwpmc_sandy_bridge.diff
I can perform some small cleanups and likely test it too.
If Fabien or George can review it I'm fine with committing as long as
all that is settled.
+
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
Have you tried on -current? If yes, what are the results?
Can you provide a kernel dump and/or the instruction to reproduce this bug?
Best
Davide
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Intel Sandy Bridge support for hwpmc
Good evening folks. During last days I've written a patch to add sandy bridge support to hwpmc. Until now, the most recent Intel processor microarchitecture supported was Westmere. Testing is appreciated, in order to see if there's something that have to be fixed. You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ and fabient@ for the useful suggestions. Best Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Intel Sandy Bridge support for hwpmc
On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano davide.itali...@gmail.com wrote: Good evening folks. During last days I've written a patch to add sandy bridge support to hwpmc. Until now, the most recent Intel processor microarchitecture supported was Westmere. Testing is appreciated, in order to see if there's something that have to be fixed. You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ and fabient@ for the useful suggestions. Best Davide Sorry, bad link. It should be: http://davit.altervista.org/hwpmc_sandy_bridge.diff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Intel Sandy Bridge support for hwpmc
On Sun, Nov 13, 2011 at 9:56 PM, Attilio Rao atti...@freebsd.org wrote: 2011/11/13 Davide Italiano davide.itali...@gmail.com: On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano davide.itali...@gmail.com wrote: Good evening folks. During last days I've written a patch to add sandy bridge support to hwpmc. Until now, the most recent Intel processor microarchitecture supported was Westmere. Testing is appreciated, in order to see if there's something that have to be fixed. You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ and fabient@ for the useful suggestions. Best Davide Sorry, bad link. It should be: http://davit.altervista.org/hwpmc_sandy_bridge.diff Ci sono un po di cose da pulire, ma quello posso farlo io. Mi dici come riprodurre il deadlock con THREAD_P? Attilio -- Peace can only be achieved by understanding - A. Einstein pmcstat -SCPU_CLK_UNHALTED.THREAD_P dovrebbe andare. (facendo partire pmcstat non in system-mode, ad esempio pmcstat -pCPU_CLK_UNHALTED.THREAD_P ls , non va in deadlock. ___ 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: KMS testing, intel only
On Fri, Nov 11, 2011 at 4:14 PM, Alexander Yerenkow yeren...@gmail.com wrote: Hello all. Before I begin, I appreciate any help/comments/criticism. Please, don't hesitate to support this topic. Some time ago I've announced new project - of creating rolling images of FreeBSD from SVN. Along with plain standard ones (plain world+kernel install of bare system) I'm working on creating specific images. Like with preset installed packages (kde-set, gnome-set, etc.), like with some patches (area51/kde-wip/kms) etc. So, I did not fully automated (yet) creating of this one image, but you already can grab it to test: http://gits.kiev.ua/FreeBSD/FreeBSD-9-kms-i386-r227337-2011-11-10.img.xz I'm sure you find filename fully descriptive :) What can be done with this image (after unpacking): dd if=this.img of=your-usb bs=64M and simply boot from your usb. After you boot, login with root. First, you can try just launch ./runx.sh It will use /root/xorg.conf, create few log files (probably useful ones) in /root and launch two xterms and openbox for WM. How you can test graphics: 1. glxgears/glxinfo - it's not a benchmar, as you may know :) 2. blender - extensive graphics usage 3. stellarium - also extensive graphics usage 4. seamonkey (which starts for about 2-3 minutes in absence of internet) - can be used to immediately send feedback and/or log files. Please, note that switching to tty not working; after you finish with playing KMS you simply shutdown system. If you had some troubles, you always can reboot and edit /root/xorg.conf before launch X. Before each X start copy of xorg are creating, so you can make some tests and find difference between files, not worrying for backuping/storing configs. Misc notes: there is a script exist: /root/addpackage.sh to make life easier if you want to test some other software (remotely installs packages, e.g. ./ addpackage.sh firefox will get you firefox. maybe.) Also, on image about 1G free space, so you can install something even big, to try it. Also, on image pretty fresh ports tree present, with applied xorg-dev patch, you can play with ports too. Full package list: OpenEXR-1.6.1_3 aalib-1.4.r5_6 atk-2.0.1 autoconf-2.68 autoconf-wrapper-20101119 automake-1.11.1 automake-wrapper-20101119 bigreqsproto-1.1.1 bison-2.4.3,1 bitstream-vera-1.10_5 blender-2.60 ca_root_nss-3.12.11_1 cairo-1.10.2_2,1 compositeproto-0.4.2 consolekit-0.4.3 cups-client-1.5.0 damageproto-1.2.1 dbus-1.4.14_1 dbus-glib-0.94 desktop-file-utils-0.18 dmidecode-2.11 dri-7.11,2 dri2proto-2.6 eggdbus-0.6_1 encodings-1.0.4,1 evieext-1.1.1 expat-2.0.1_2 ffmpeg-0.7.6,1 fftw3-3.3_1 fixesproto-5.0 flac-1.2.1_2 flex-2.5.35_4 font-bh-ttf-1.0.3 font-misc-ethiopic-1.0.3 font-misc-meltho-1.0.3 font-util-1.2.0 fontconfig-2.8.0_1,1 fontsproto-2.1.1 freealut-1.1.0_2 freetype2-2.4.7 gamin-0.1.10_4 gdk-pixbuf-2.23.5_1 gettext-0.18.1.1 gio-fam-backend-2.28.8 glew-1.7.0 glib-2.28.8_2 glproto-1.4.14 gmake-3.82 gnome_subr-1.0 gobject-introspection-0.10.8 gpac-libgpac-0.4.5_4,1 gtk-2.24.6 gtk-update-icon-cache-2.24.6 hal-0.5.14_17 hicolor-icon-theme-0.12 ilmbase-1.0.1_1 inputproto-2.0.2 intltool-0.41.1 jasper-1.900.1_9 jbigkit-1.6 jpeg-8_3 kbproto-1.0.5 libGL-7.11 libGLU-7.4.4 libICE-1.0.7,1 libIDL-0.8.14_1 libSM-1.2.0,1 libX11-1.4.4,1 libXau-1.0.6 libXaw-1.0.9,1 libXcomposite-0.4.3,1 libXcursor-1.1.12 libXdamage-1.1.3 libXdmcp-1.1.0 libXext-1.3.0_1,1 libXfixes-5.0 libXfont-1.4.4,1 libXft-2.1.14 libXi-1.4.3,1 libXinerama-1.1.1,1 libXmu-1.1.0,1 libXp-1.0.1,1 libXpm-3.5.9 libXrandr-1.3.2 libXrender-0.9.6 libXt-1.1.1 libXv-1.0.6,1 libXvMC-1.0.6 libXxf86misc-1.0.3 libXxf86vm-1.1.1 libdrm-2.4.27 libevent-1.4.14b_2 libexecinfo-1.1_3 libffi-3.0.9 libfontenc-1.1.0 libgcrypt-1.5.0 libglut-7.4.4 libgpg-error-1.10 libiconv-1.13.1_1 libnotify-0.7.3_1 libogg-1.2.2,4 libpciaccess-0.12.1 libpthread-stubs-0.3_3 libsamplerate-0.1.8_2 libsndfile-1.0.25 libtheora-1.1.1_2 libtool-2.4_1 libvolume_id-0.81.1 libvorbis-1.3.2,3 libvpx-0.9.7 libxcb-1.7 libxkbfile-1.0.7 libxkbui-1.0.2_1 libxml2-2.7.8_1 libxslt-1.1.26_3 luit-1.1.0 m4-1.4.16,1 makedepend-1.0.3,1 mesa-demos-7.4.4 mkfontdir-1.0.6 mkfontscale-1.0.9 nspr-4.8.9 openal-soft-1.13 openbox-3.5.0 opencv-core-2.3.1_1 openjpeg-1.3_2 orc-0.4.14_1 p5-XML-Parser-2.41 pango-1.28.4 pciids-20111002 pcre-8.20 perl-5.12.4_2 pixman-0.24.0 pkg-config-0.25_1 png-1.4.8 policykit-0.9_6 polkit-0.99 portmaster-3.10 printproto-1.0.5 py27-libxml2-2.7.8_1 python27-2.7.2_3 python32-3.2.2_1 qt4-corelib-4.7.4 qt4-gui-4.7.4 qt4-network-4.7.4 qt4-opengl-4.7.4 qt4-script-4.7.4 randrproto-1.3.2 recordproto-1.14.1 renderproto-0.11.1 resourceproto-1.2.0 schroedinger-1.0.10 scrnsaverproto-1.2.1 sdl-1.2.14_2,2 seamonkey-2.4.1 shared-mime-info-0.90 stellarium-0.11.0 tiff-4.0.0_2 trapproto-3.4.3 videoproto-2.3.1 x264-0.116.2076
Re: Move banner to games
On Sat, Oct 2, 2010 at 2:36 PM, Paul B Mahol one...@gmail.com wrote: Hi, I see no point to have it in usr/bin. ___ 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 Consider that it could be used for system tasks , like print jobs. ___ 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 wpa_supplicant
On 03/09/10 08:32, Bernhard Schmidt wrote:
On Friday, September 03, 2010 01:34:54 Davide Italiano wrote:
Hi. I've been recently upgraded to -CURRENT (9.0).
After
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
# make install kernel KERNCONF=MYKERNEL
I have rebooted to single-user mode, as suggested in the documentation.
No more wireless connection. I've a intel 2200 bg wireless card,
running using the kernel built-in iwi module.
In particular, when I run wpa_supplicant -i wlan0 -c
/etc/wpa_supplicant.conf I get this:
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
...
My wpa_supplicant.conf is:
ap_scan=1
fast_reauth=1
network={
ssid=MY_SSID
psk=MY_KEY
}
Also, my /boot/loader.conf contains
legal.intel_iwi.license_ack=1
if_iwi_load=YES
and my rc.conf
wlans_iwi0=wlan0
ifconfig_wlan0=WPA inet 192.168.1.110 netmask 0xff00
defaultrouter=192.168.1.1
Again, it worked w/ freebsd 8.1 (stable). Also, I've read in the
UPDATING file in /usr/src this:
Applications such as wpa_supplicant(8) may require a full world
build without using NO_CLEAN in order to get synchronized with the
new structure.
But, I've done a make buildworld before, isn't enough?
Thanks a lot
Did you also run make installworld?
--
Bernhard
Now it works. Thanks. I've been forgotten to merge configuration files using
mergemaster.
___
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 with wpa_supplicant
Hi. I've been recently upgraded to -CURRENT (9.0).
After
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
# make install kernel KERNCONF=MYKERNEL
I have rebooted to single-user mode, as suggested in the documentation.
No more wireless connection. I've a intel 2200 bg wireless card,
running using the kernel built-in iwi module.
In particular, when I run wpa_supplicant -i wlan0 -c
/etc/wpa_supplicant.conf I get this:
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
...
My wpa_supplicant.conf is:
ap_scan=1
fast_reauth=1
network={
ssid=MY_SSID
psk=MY_KEY
}
Also, my /boot/loader.conf contains
legal.intel_iwi.license_ack=1
if_iwi_load=YES
and my rc.conf
wlans_iwi0=wlan0
ifconfig_wlan0=WPA inet 192.168.1.110 netmask 0xff00
defaultrouter=192.168.1.1
Again, it worked w/ freebsd 8.1 (stable). Also, I've read in the
UPDATING file in /usr/src this:
Applications such as wpa_supplicant(8) may require a full world
build without using NO_CLEAN in order to get synchronized with the
new structure.
But, I've done a make buildworld before, isn't enough?
Thanks a lot
Davide
___
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
