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"
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"
Re: Move banner to games
On Sat, Oct 2, 2010 at 2:36 PM, Paul B Mahol 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: RFC: Remove pty(4)
On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin 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"
Re: RFC: Remove pty(4)
On Thu, Nov 27, 2014 at 10:37 AM, Alfred Perlstein 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 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"
[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"
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 wrote: > The PAGER was less for about half a year and reverted. Please see: > > https://svnweb.freebsd.org/base?view=revision&revision=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"
Re: pf crash on -current
On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude 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"
Re: Panic on current amd64
On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar 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: What to do about RCS/OpenRCS
On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni 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: KMS testing, intel only
On Fri, Nov 11, 2011 at 4:14 PM, Alexander Yerenkow 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 > sc
[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 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 wrote: > 2011/11/13 Davide Italiano : >> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano >> 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: [PATCH] Intel Sandy Bridge support for hwpmc
On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose wrote:
> hi, I apply your patch on this
> [root@capoor-daemon /usr/src]# git show
> commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
> Author: kensmith
> 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 :
>> 2011/11/13 Davide Italiano :
>>> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano
>>> 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] 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: possible array out of bounds access in sys/netinet/sctp_output.c
On Sun, Nov 27, 2011 at 5:24 PM, Jilles Tjoelker 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"
Re: [CFT] hwpmc support for Intel Ivy Bridge
On Tue, Sep 4, 2012 at 9:35 AM, Fabien Thomas 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 > 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: Dynamic Ticks/HZ
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden 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" wrote: > > Davide Italiano wrote: >> >> On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden 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"
[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: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote:
>
> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano
> 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 mainta
Re: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano wrote:
> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote:
>>
>> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano
>> 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
Re: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 3:21 PM, Oliver Pinter 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 wrote:
>> On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano
>> wrote:
>>> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote:
>>>>
>>>> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano
>>>> 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 n
Re: [RFC/RFT] calloutng
On Sat, Dec 15, 2012 at 10:05 AM, Adrian Chadd 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 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 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 > #include I fixed (or at least workarounded) that issue during the summer. http://svnweb.freebsd.org/base?view=revision&revision=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: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng
On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo 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 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=242905&r2=242904&pathrev=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 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: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp 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 wrote: > On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > >> >> In message >> >> , 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 wrote: > On Wed, 19 Dec 2012, Davide Italiano wrote: > >> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans 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: [RFC/RFT] calloutng
On Sun, Dec 30, 2012 at 10:17 PM, Luigi Rizzo 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
Re: hwpmc support for Ivy Bridge Xeon
On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara 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: hwpmc support for Ivy Bridge Xeon
On Tue, Jan 29, 2013 at 12:29 AM, hiren panchasara wrote: > On Mon, Jan 28, 2013 at 7:27 PM, hiren panchasara > wrote: >> On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara >> 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=237222&view=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 haswell
On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara 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: [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: Running out of bits p_flag (sys/sys/proc.h)
On Sun, Feb 17, 2013 at 2:58 AM, hiren panchasara
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: r246916 probably broke amd64 build
On Tue, Feb 19, 2013 at 3:22 PM, Simon L. B. Nielsen 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: r246916 probably broke amd64 build
On Wed, Feb 20, 2013 at 10:54 AM, Dag-Erling Smørgrav wrote: > Davide Italiano 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: [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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 7:05 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao 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: Interesting panic from the Yahoo builder (10-current)
On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno 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: Interesting panic from the Yahoo builder (10-current)
On Sun, Sep 8, 2013 at 4:27 PM, Sean Bruno wrote: > On Sat, 2013-09-07 at 17:05 +0200, Davide Italiano wrote: >> On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno 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: 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: 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 wrote: > On Sat, 21 Sep 2013 07:08:25 -0500 > Bryan Drewery 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 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 >>> wrote: >>>> On Sat, 21 Sep 2013 07:08:25 -0500 >>>> Bryan Drewery 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: Panic in arptimer on r255764
On Sun, Sep 22, 2013 at 2:25 AM, Lars Engels 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 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 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 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 wrote: > >> >> 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. 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 wrote: > 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 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Wed, Sep 25, 2013 at 11:11 AM, Anton Shterenlikht 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* > > <118>Sep 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 > <6>pid 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 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: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Thu, Sep 26, 2013 at 12:23 PM, Anton Shterenlikht 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: Problem building stable-9 in current host
On Tue, Oct 1, 2013 at 9:05 AM, Alexander Yerenkow 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 Fri, Oct 11, 2013 at 11:26 AM, Anton Shterenlikht wrote: > >From davide.itali...@gmail.com Thu Sep 26 13:12:30 2013 >>On Thu, Sep 26, 2013 at 12:23 PM, Anton Shterenlikht 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: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Mon, Oct 14, 2013 at 10:21 AM, Anton Shterenlikht 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: wrong page state m 0xe00000027a9adb40 + savecore deadlock
On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht 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 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"
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"
[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"
Re: Ports including sys/time.h broken
On Wed, Mar 27, 2013 at 9:28 PM, Pawel Pekala 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: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov 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 wrote: > On 2013-05-02 12:06, Davide Italiano wrote: >> >> On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov 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 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: LOR on head ...
On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. 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=0x178bfbff > > Features2=0x1e98220b > AMD Features=0x2e500800 > AMD > Features2=0x1c9bfff,> > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 7868518400 (7504 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > 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 irqs 0-23 on motherboard > ioapic1 irqs 24-55 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: 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: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.2 (no driver attached) > pcib1: irq 52 at device 2.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 24 at > device 0.0 on pci1 > pcib2: irq 52 at device 4.0 on pci0 > pci2: on pcib2 > re0: 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: on re0 > rgephy0: 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: irq 52 at device 5.0 on pci0 > pci3: on pcib3 > xhci0: mem 0xfe40-0xfe407fff irq > 46 at device 0.0 on pci3 > xhci0: 32 byte context size. > usbus0 on xhci0 > pcib4: irq 53 at device 7.0 on pci0 > pci4: on pcib4 > xhci1: mem 0xfe30-0xfe307fff irq > 50 at device 0.0 on pci4 > xhci1: 32 byte context size. > usbus1 on xhci1 > pcib5: irq 53 at device 9.0 on pci0 > pci5: on pcib5 > ath0: 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 enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: AR9380 mac 448.3 RF5110 phy 0.0 > ath0: 2GHz radio: 0x; 5GHz radio: 0x > ahci0: port > 0xf040-0xf047,0xf030-0xf033,0xf020-0xf027,0xf010-0xf013,0xf000-0xf00f mem > 0xfe50b000-0xfe50b3ff irq 19 at device 17.0 on pci0 > ahci0: AHCI v1.20 with 3 6Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich5: at channel 5 on ahci0 > ohci0: mem 0xfe50a000-0xfe50afff irq > 18 at device 18.0 on pci0 > usbus2 on ohci0 > ehci0: mem 0xfe509000-0xfe5090ff > irq 17 at device 18.2 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > ohci1: mem 0xfe508000-0xfe508fff irq > 20 at device 19.0 on pci0 > usbus4 on ohci1 > ehci1: mem 0xfe507000-0xfe5070ff > ir
Re: ZFS Crashes
On Sun, Aug 11, 2013 at 9:20 AM, Larry Rosenman 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=revision&revision=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: Early drop to debugger with DEBUG_MEMGUARD
On Mon, Aug 12, 2013 at 8:13 AM, David Wolfskill 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, &ba
Re: Early drop to debugger with DEBUG_MEMGUARD
On Mon, Aug 12, 2013 at 9:01 AM, David Wolfskill 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/s
Re: patch: enable MEM_LOAD_UOPS_LLC_HIT_RETIRED on sandy bridge xeon
On Wed, Aug 14, 2013 at 10:58 PM, Adrian Chadd 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: Question about socket timeouts
On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote:
> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>> 2013/8/22 John Baldwin :
>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> >> 2013/8/21 John Baldwin :
>> >> > 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: Question about socket timeouts
On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin wrote:
> On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
>> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote:
>> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>> >> 2013/8/22 John Baldwin :
>> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> >> >> 2013/8/21 John Baldwin :
>> >> >> > 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 wrote: > 2013/8/23 Davide Italiano : > > 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 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 Thu, Aug 29, 2013 at 6:03 PM, John Baldwin 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 wrote: >> On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov >> wrote: >>> 2013/8/23 Davide Italiano : >>> >>> 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"
