Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, 10 Oct 2021 at 22:17, Baptiste Daroussin wrote: > > > > > I don't know if this is the right place to jump in, but I suspect this > > is a related issue? > > I'm trying to do the opposite - building 14 on a 13-STABLE machine. It > > fails when trying to build ncurses: > > > > root@p14s-bsd:/usr/src # uname -v > > FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10 > > 03:25:38 CEST 2021 > > root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > > root@p14s-bsd:/usr/src # git pull > > Already up to date. > > root@p14s-bsd:/usr/src # git status > > On branch main > > Your branch is up to date with 'origin/main'. > > > > nothing to commit, working tree clean > > root@p14s-bsd:/usr/src # make buildworld > build.log > > (...) > > > > The full log is at http://eurostar.nebdal.no/build.log > > It's all variations over this: > > > > ===> lib/ncurses/ncurses (obj,all,install) > > Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o > > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > > implicit declaration of function '_nc_tiparm' is invalid in C99 > > [-Werror,-Wimplicit-function-declaration] > > TIPARM_1(set_a_background, bg), > > ^ > > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > > macro 'TIPARM_1' > > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > > ^ > > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > > incompatible integer to pointer conversion passing 'int' to parameter > > of type 'const char *' [-Werror,-Wint-conversion] > > TIPARM_1(set_a_background, bg), > > ^~ > > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > > macro 'TIPARM_1' > > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > > ^ > > > > -DanielN > > It is an entirely different storry that deserves its own investigation! > > I will try to find time in the next couple of days. > > In the meantile could you provide your make.conf, src.conf and src-env.conf? > > Best regards > Bapt Sure - they're plain enough: # cat /etc/make.conf cat: /etc/make.conf: No such file or directory # cat /etc/src.conf cat: /etc/src.conf: No such file or directory # cat /etc/src-env.conf WITH_META_MODE=YES I did try with meta mode disabled as well, with the same result. -DanielN
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin wrote:
>
> On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
> > On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote:
> >
> > > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
> > > >
> > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
> > > >
> > > > >
> > > > >
> > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > > > > wrote:
> > > > >
> > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> > > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov
> > > > >> > wrote:
> > > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> > > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov <
> > > > >> kostik...@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric <
> > > d...@freebsd.org>
> > > > >> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh
> > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > > > >> d...@freebsd.org> wrote:
> > > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
> > > > >> > > > > > > > > > >
> > > > >> wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > > > >> free...@walstatt-de.de>
> > > > >> > > > > wrote:
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2
> > > > >> > > > > main-n249971-0525ece3554e:
> > > > >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an
> > > > >> 13-STABLE
> > > > >> > > > > based
> > > > >> > > > > > > > >> appliance failed very early in the build process of
> > > the
> > > > >> 13-STABLE
> > > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent,
> > > since
> > > > >> the
> > > > >> > > > > sources
> > > > >> > > > > > > are
> > > > >> > > > > > > > >> fetched every time the build process is triggered.
> > > > >> > > > > > > > > ...
> > > > >> > > > > > > > >>
> > > > >> > > > > > >
> > > > >>
> > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > > >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et
> > > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > > >> > > > > > > > >>
> > > > >> > > > > > >
> > > > >> > > > >
> > > > >>
> > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen ---
> > > ld:
> > > > >> error:
> > > > >> > > > > > > undefined
> > > > >> > > > > > > > >> symbol: setupterm
> > > > >> > > > > > > > > referenced by Process.cpp
> > > > >> > > > > > > > >
> > > > >> > > > > > >
> > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > It is complaining about ncurses functions; it seems
> > > that
> > > > >> even
> > > > >> > > > > though
> > > > >> > > > > > > the link step gets -lncursesw added, it still is not able
> > > to
> > > > >> find the
> > > > >> > > > > > > symbol:
> > > > >> > > > > > > >
> > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow
> > > got
> > > > >> split off
> > > > >> > > > > from
> > > > >> > > > > > > > libncursesw:
> > > > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd
> > > > >> > > > > > > >
> > > > >> > > > > > > > This affects such cross-builds obviously, and manually
> > > > >> adding
> > > > >> > > > > -ltinfow
> > > > >> > > > > > > > to the link command line makes it link correctly.
> > > > >> > > > > > > >
> > > > >> > > > > > > > However, the 396851c20aebd commit is probably not
> > > suitable
> > > > >> for
> > > > >> > > > > MFC'ing
> > > > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge
> > > in
> > > > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level
> > > > >> > > > > Makefile.inc1?
> > > > >> > > > > > > >
> > > > >> > > > > > > > Baptiste, any ideas? :)
> > > > >> > > > > > > >
> > > > >> > > > > > > > Add setupterm() to libegacy as a nop.
> > > > >> > > > > > >
> > > > >> > > > > > > That's not enough I think, it requires more ncurses
> > > functions
> > > > >> than just
> > > > >> > > > > > > setupterm. And it actually calls them and checks the
> > > return
> > > > >> values too,
> > > > >> > > > > > > IIRC. :)
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return
> > > OK; }
> > > > >> > > > > > int tigetnum(const char *t) { return 0; }
> > > > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; }
> > > > >> > > > > > int del_curterm(TERMINAL *t) { return OK; }
> > > > >> > > > > >
> > > > >> > > > > >
Re: WSLg update on 1-5-2021 - BSD / WSL
On Thu, 6 May 2021 at 19:05, David Chisnall wrote: > [ Disclaimer: I work for Microsoft, but not on WSL and this is my own > opinion ] > (...) > David > Just as a counterpoint to Rozhuk's take, that all sounds sensible enough to me - FreeBSD would probably gain more from this than MS. So the WSL2 TODO would be something like this: * Ballooning driver. Seems like a proof of concept would be doable enough - could you model it as an unkillable task (userland or kernel) that wants to allocate a lot of memory, and anything it gets it hands back to the host? * Some sort of boot support. Maybe as a shim that chainloads an unmodified kernel? Probably finicky, but also self-contained. * File systems. Is / also 9p-over-HyperV-channels? If so that's kind of crucial and perhaps the hardest part. Oh, and how does the terminal work? You support multiple ttys, so I guess it's not straight emulated serial? -- Daniel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NPAPI (was: java web start / error)
On Fri, 2 Apr 2021 at 04:07, Graham Perrin wrote: > > On 05/03/2021 14:01, Antonio Olivares wrote: > > … worked well with firefox-esr which I use because the plugins > > are deprecated using the newer firefox. Despite that it also used to > > work with the regular firefox. … > > For reference – I dug up some of what's below in response to a question > in IRC about <https://wiki.freebsd.org/NPAPI>: > > Removal of NPAPI plugin support in Firefox 85 > <https://groups.google.com/g/mozilla.dev.platform/c/NsdReYslBU4/m/b9FwjVAbBAAJ> > > Java Plugin is Removed from JDK 8u for Linux, Solaris, and MacOS Platforms > <https://www.oracle.com/java/technologies/javase/8u271-relnotes.html#JDK-8240210> > > <https://github.com/davidben/nspluginwrapper> no recent activity, and > related <https://nspluginwrapper.org/> does not respond. > > <https://askubuntu.com/a/905937/25036> about Pale Moon. At this point, it may be easier to get hold of an old OS, an old copy of Firefox, and an old Java plugin, install them in a virtual machine, and firewall it so the VM only has access to that one site. Much like VHS, you apparently need to view it on preserved tech of a similar vintage. On the positive side, a setup like that should at least keep working indefinitely, unless they also manage to use HTTPS certificates an old browser can't understand. -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loader/boot fonts are painfully small (again)
On Fri, 12 Feb 2021 at 15:33, Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > On 11. Feb 2021, at 23:21, Yuri Pankov wrote: > > > > > > Lenovo P51 laptop, 15'' 4k (3840x2160) display. > > > > > > Booting from the latest available current snapshot (20210107), fonts > > > were at least readable; updating to the latest bits (manually > installing > > > new loader as well) made them really small -- terminal size reported by > > > stty is 480x135. > > > > > > > It is a issue about not so good automatic font size setup. The original > code was using 80x24 terminal as base, it was complained it did end up with > too large fonts, so I did pick uefi terminal size as base (see output from > mode command), but thats also not perfect. Till better solution, right now > the option is to set font manually (screen.font variable). > > Can we just stick with the "known to work almost everywhere and always" > default value of 80x24? These small fonts are great for those of you > who have 20/20 un corrected vision, but it is a royal PITA for almost > anyone who has even a slight visual imparement, even corrected I find > it near imposible to read the default efi screens we put up. > > I would suggest we also override this in the -RELEASE/SNAPSHOT > media as one just does not need to fight this font size issue > while trying to install a new system. > > Thanks, > Rod > > > > > I have also noticed large delays between different loader screens, > > > probably caused by very slow screen blanking given the terminal size? > > > > yes, it definitely needs boost.There are few things we can do about it. > > > > rgds, > > toomas > > If we assume that 16:9 screens are the most common aspect ratio, and that the font we use is 1:2 (which is just guesswork, based on the 8x16 console font), that gives us a 32:9 aspect ratio counted in characters. It seems sensible to stick to an integer multiple of that, to avoid any uncomfortable stretching or scaling. The 480x135 console you got follows that idea - it's the 15x scale. That's obviously a bit optimistic, but how about the 3x or 4x scale, at 96x27 or 128x36? -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT for vendor openzfs - week 5 reminder + memdisk images
On Sat, 15 Aug 2020 at 21:30, Matthew Macy wrote: > > > > > Hi. I have some problems downloading the amd64 image: > > > > baymax /home/djn > fetch -a > > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > > freebsd-openzfs-amd64-2020081100-memstick.img. 19% of 655 MB 2179 kBps > > 04m07s > > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > > truncated: 134152192/687158140 bytes > > baymax /home/djn > fetch -ar > > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 882 kBps > > 09m10s > > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > > truncated: 139132928/687158140 bytes > > baymax /home/djn > fetch -ar > > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 647 kBps > > 12m23s > > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be > > truncated: 142065664/687158140 bytes > > baymax /home/djn > > > > > It also fails using Firefox on windows on a different machine. (It's > > also much slower from that machine, about 200 kB/sec. I have no idea > > if that's relevant.) > > Yes, this appears to have been going on for at least the last week. > The FreeBSD infrastructure directly available to developers appears to > be unreliable for serving large files. Individuals with accounts on > freefall have been able to scp the files. It's possible that we may > just end up sharing images more widely by way of releng generated > images after commit. I'll see if there's an alternative for the last > week of the CFT. > > Cheers. > -M The instructions for building it myself seem easy enough, so it's not a problem for *me* - but I'm sure it can't hurt. :) Thanks, -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT for vendor openzfs - week 5 reminder + memdisk images
On Tue, 4 Aug 2020 at 02:25, Matthew Macy wrote: > > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. The tentative merge date is August > 17th. > > Again, I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. > > amd64, i386, and aarch64 memdisk images can be found at: > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/ > > If you're using a platform not listed above and would be inclined to > test if you had an image to work with, let us know. Alternatively, you > can still build following the instructions below. > > The review for merging in to base can be found at: > https://reviews.freebsd.org/D25872 > > == > NB: Do NOT zpool upgrade unless you are willing to live without the > ability to ever rollback to the legacy zfs kmod. > > Checkout updated HEAD: > % git clone https://github.com/mattmacy/networking.git -b > projects/openzfs_vendor freebsd > > Checkout updated openzfs in to sys/contrib: > % git clone https://github.com/zfsonfreebsd/ZoF.git -b > projects/openzfs_vendor freebsd/sys/contrib/openzfs > > Build world and kernel with whatever your usual configuration is. > Where possible the openzfs kmod is backward compatible with the cmd > utils in HEAD so common operations work with existing tools and the > new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries > are backward compatible with the zfs kmod in HEAD. Although ideally > one would test this in a separate boot environment, the > interoperability should allow one to rollback without too much > difficulty. > > NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools > other than the root pool will not be imported at boot. > > Thanks in advance for your time. > > -M > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hi. I have some problems downloading the amd64 image: baymax /home/djn > fetch -a https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz freebsd-openzfs-amd64-2020081100-memstick.img. 19% of 655 MB 2179 kBps 04m07s fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be truncated: 134152192/687158140 bytes baymax /home/djn > fetch -ar https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 882 kBps 09m10s fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be truncated: 139132928/687158140 bytes baymax /home/djn > fetch -ar https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz freebsd-openzfs-amd64-2020081100-memstick.img. 20% of 655 MB 647 kBps 12m23s fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be truncated: 142065664/687158140 bytes baymax /home/djn > It also fails using Firefox on windows on a different machine. (It's also much slower from that machine, about 200 kB/sec. I have no idea if that's relevant.) -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT October images do not create a bootable install
> On Thu, 7 Nov 2019 09:49:52 +0100 gljennj...@gmail.com said > I chose GPT. Maybe whoever wrote the EFI/BIOS code in your machine went all-in on "Legacy", and it only handles MBR disks (or disks < 2.2TB)? After all, it seems like "not booting" would be a standards-compliant way for a classic BIOS to handle a GPT disk. -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
vm_fault on boot with NVMe/nda
Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9),
with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card.
By default, it shows up as /dev/nvd0, and this is how I installed the
system. It has a single large UFS2 (with SJ and TRIM support) partition
mounted as /. (There's also a few other partitions on it that should be
irrelevant for this.) This works, but it does sometimes slow down for
minutes at the time with disturbing queue lengths in gstat; on the order of
tens of thousands. As I understand it, this is due to how TRIM operations
take precedence over everything else when using nvd ?
Looking around, I noticed the nda driver for NVMe-through-CAM. To test it,
I added hw.nvme.use_nvd=0 to loader.conf. On one level, this works: The
drive shows up as /dev/nda0 . On the other hand, trying to mount nda0p2 as
/ floods the console with "vm_fault: pager read error, pid 1 (init)", and
never finishes booting.
What is more interesting is that if I boot from the drive, but mount an
alpha9 usb stick as /, I can then mount the nda device just fine, and the
very minimal testing I did (using bin/cat and COPYRIGHT on the NVMe drive)
seems to work.
So - is nda meant to be bootable, or am I a bit over-eager in trying to do
so?
If not, is there anything smart I can do to get better performance out of
nvd?
(Or have I just overlooked something obvious?)
Dmesg from a normal nvd boot here:
https://openbenchmarking.org/system/1810159-RA-SSD30089593/SSD/dmesg
--
Daniel Nebdal
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Speed problems with both system openssl and security/openssl-devel
On Fri, 14 Sep 2018 at 02:12, Lev Serebryakov wrote: > > Hello John, > > Friday, September 14, 2018, 1:44:13 AM, you wrote: > > >> % grep aesni ~/nanobsd/gatevay.v3/J3160 > >> device aesni > > > From my understanding of the OpenSSL code, it doesn't use the kernel driver > > at all (the kernel driver is only needed for in-kernel crypto such as IPSec > > or GELI). > It is my understanding too. > > > AESNI are just instructions that can be used in userland, and > > OpenSSL's AESNI acceleration is purely different routines in userland. > > I would verify if AESNI shows up in the CPU features in dmesg first (if it > > doesn't I'd check for a BIOS option disabling it). > It is enabled. It is used for sure by openssl 1.1.0 on Linux and bu openssl > 1.1.1 > on FreeBSD, but not by openssl 1.0.2 and 1.1.0 on FreeBSD. Problem is, > openssl 1.1.1 is not used by anything on FreeBSD (yet) and almost > everything uses system (1.0.2) and only some other ports could use 1.1.0 > from ports. > > -- > Best regards, > Levmailto:l...@freebsd.org > Could it be relevant that the Debian binary was probably compiled with gcc, and the FreeBSD binary with clang? This seems like the sort of code that plausibly could bring out some compiler corner cases. (It's weird that 1.1.1 is fine, though.) -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: arc_reclaim_thread running hot
On Thu, 13 Sep 2018 at 15:19, Eric van Gyzen wrote:
>
> This morning, I found the arc_reclaim_thread running hot on my laptop
> running 12.0-ALPHA5 r338572.
>
> vfs.zfs.arc_max="4294967296" <-- 4 GiB
>
> last pid: 13288; load averages: 1.32, 1.26, 1.16
>
> Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
> ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
> 89M Compressed, 361M Uncompressed, 4.03:1 Ratio
>
> 22 root -8- 0 256K CPU2 2 309:20 99.75%
> zfskern{arc_reclaim_thread}
>
> zfs_arc_meta_strategy is still the default of 1.
>
> I sampled the thread's stacks with
>
> for N in `jot 1000`; do procstat -kk 100101; done | grep 100101
>
> and put the results here:
>
> https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt
>
> I'm happy to help debug this. Just let me know what you need.
>
> Eric
Just to summarize, these are the top 15 active
(guessing that the leftmost function is "current"):
22 arc_space_return
22 uma_dbg_free
26 uma_dbg_alloc
30 mi_switch
31 uma_zalloc_arg
33 multilist_sublist_lock
34 __mtx_unlock_flags
39
46 _sx_xlock
48 hdr_full_cons
50 uma_zfree_arg
58 aggsum_add
91 arc_adjust
156 _sx_xunlock
185 arc_evict_state
And the top 15 in total
(that is, no matter where in the call stack):
44 multilist_sublist_lock
44 uma_dbg_free
46 _sx_xlock
47 uma_dbg_alloc
61 arc_space_return
127 aggsum_add
139 hdr_full_cons
156 _sx_xunlock
211 uma_zfree_arg
219 uma_zalloc_arg
833 arc_evict_state
926 arc_adjust
961 arc_reclaim_thread
961 fork_exit
961 fork_trampoline
(I have nothing sensible to add about the actual problem.)
--
Daniel Nebdal
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ...
On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann <ohartm...@walstatt.org> wrote: > Hello out there, > > I had to replace a HDD on a RAIDZ1 pool comprised from 4 HDDs, each 3 TB > (netto size of > the pool is about 8-9 TB, the used amount is reported to be ~ 6TB). > > I just started the rebuild/resilvering process and watch the pool crwaling at > ~ 18 MB/s. > At the moment, there is no load on the array, the host is a IvyBridge XEON > with 4 core/8 > threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to a on-board > SATA II (300 > MB/s max) Intel chip - this just for the record. > > Recently, I switch on the "sync" attribute on most of the defined pools's zfs > filesystems > - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused recently > in FreeBSD > CURRENT's ZFS - this from a observers perspective only. > > When scrubbing, I see recently also reduced performance on the pool, so I'm > wondering > about the low throughput at the very moment when resilvering is in progress. > > If the "perspective" of "zpool status" is correct, then I have to wait after > two hours > for another 100 hours - ~ 4 days? Ups ... I think there is something badly > misconfigured > or missing. > > The pool is not "tuned" in any very sophisticated way, since I trust the > kernels ability > to scale automatically - if I'm not wrong for amd64 ... > > Are there any aspects to look at? > > Thanks in advance, > > Oliver > > -- > O. Hartmann > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). This is kind of to be expected - for whatever reason, resilvers seem to go super slow at first and then speed up significantly. Just don't ask me how long "at first" is - I'd give it several (more) hours. I don't _think_ sync affects resilver speed (since that's a filesystem level setting and the resilver happens at the block level), but that's pure speculation. The Tuning guide at https://wiki.freebsd.org/ZFSTuningGuide also suggests a list of sysctls you can tweak, which could be worth a try: ### wiki If you're getting horrible performance during a scrub or resilver, the following sysctls can be set: vfs.zfs.scrub_delay=0 vfs.zfs.top_maxinflight=128 vfs.zfs.resilver_min_time_ms=5000 vfs.zfs.resilver_delay=0 Setting those sysctls to those values increased my (Shawn Webb's) resilver performance from 7MB/s to 230MB/s. ### -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.x deadlocking during pfault (was Re: FreeBSD 11.x grinds to a halt after about 48h of uptime)
pu3:timer > > 1435985 pdpgs66 > > cpu2:timer > > Disks md0 ada0 ada1 pass0 pass1 pass2 intrn77 > > cpu7:timer > > KB/t 0.00 22.59 0.00 0.00 0.00 0.00 5819100 wire 75 > > cpu4:timer > > tps 17 168 0 0 0 0 9723008 act 51 > > cpu6:timer > > MB/s 0.00 3.70 0.00 0.00 0.00 0.00 636300 inact53 > > cpu5:timer > > %busy 0 3 0 0 0 0 cache > > vgapci0 > > 61912 free > >770732 buf > > > > > > I'm unable to scroll back the vmstat -m output in my tmux pane (running on a > > different system, this is super strange), so all I can show is this: > > > > > > inodedep16 12293K - 2770872 512 > > bmsafemap 949K - 2136243 256,8192 > >newblk28 24582K - 4111401 256 > > indirdep 4 1K - 865983 128,16384 > > freefrag 6 1K - 682027 128 > > freeblks 3 1K - 1318985 256 > > freefile 3 1K - 1272832 64 > >diradd 2 1K - 1306741 128 > > mkdir 0 0K - 5120 128 > >dirrem 0 0K - 1305358 128 > > newdirblk 0 0K - 2610 64 > > freework 9 1K - 1566489 64,128 > > sbdep 0 0K -45661 64 > > savedino 0 0K - 186280 256 > > softdep 6 3K -6 512 > > ufs_dirhash 1533 767K - 109513 > > 16,32,64,128,256,512,1024,2048,4096 > > ufs_quota 1 2048K -1 > > ufs_mount1855K - 18 512,2048,4096,8192 > > vm_pgdata 1 2048K -2 128 > > UMAHash23 5385K - 108 > > 512,1024,2048,4096,8192,16384,32768,65536 > > memdesc 1 4K -1 4096 > > atkbddev 2 1K -2 64 > > entropy 1 1K - 894489 32,4096 > >apmdev 1 1K -1 128 > >madt_table 0 0K -1 4096 > > SCSI ENC25 100K - 120744 16,64,256,2048,32768 > > io_apic 1 2K -1 2048 > > MCA18 3K - 18 64,128 > > msi16 2K - 16 128 > > nexusdev 5 1K -5 16 > > hdaa 554K -5 2048,16384,32768 > > hdac 1 1K -1 1024 > > hdacc 1 1K -1 32 > > linux29 2K - 29 64 > > solaris 295750 228696K - 140520323 > > 16,32,64,128,256,512,1024,2048,4096,8192,32768 > >kstat_data 6 1K -6 64 > > eli data22 4K - 6218901 > > 64,256,512,1024,2048,4096,8192,16384,32768,65536 > > ksem 1 8K -1 8192 > > nullfs_hash 1 2048K -1 > > nullfs_node 9 1K - 41 64 > > nullfs_mount 9 1K -9 32 > > fdesc_mount 1 1K -1 16 > > gem_name4614K - 122 32,4096 > >drm_global 2 1K -2 128,256 > > drm_dma 1 1K -1 32 > > drm_sarea 1 1K -1 16 > >drm_driver91 2278K - 125 > > 16,32,64,128,256,512,1024,2048,4096,8192,32768 > > drm_minor 2 1K -2 128 > > drm_files 1 1K -3 512 > > drm_ctxbitmap 1 4K -1 4096 > > drm_sman41 6K - 42 128 > > drm_hashtab 3 4129K -4 128,32768 > > drm_kms6919K - 163 > > 16,32,64,128,256,512,2048,4096,8192 > >drm_vblank 7 1K -7 32,256 > >ttm_pd1617K - 18 16,128,2048,65536 > > ttm_rman 2 1K -2 256 > > ttm_zone 2 1K -2 64 > > ttm_poolmgr 1 1K -1 512 > > > > > > Now what? > > > > The xterm I have running locally with a stuck top is showing the top 3 > > chrome > > processes in pfault state and it has "Swap: 11M In" in the header, so > > clearly > > 11.x is prone to deadlock during page faults and or swapping. It has last > > updated on 17:14:13 (compare to the other top at 17:14:10 not showing pfault > > state yet). > > Addendum: I still see the HDD indication light flickering every couple > of seconds, so something is still doing I/O. My SSH sessions into the > machine haven't time out, and the screensaver (just DPMS blank) is also > still kicking in correctly. > Just out of general interest, how is your swap set up? Is it on a zvol or something exotic like that, or is it just a normal partition? -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r294195: Kernel panic during installworld
On Thu, Feb 11, 2016 at 3:04 PM, Hans Petter Selasky <h...@selasky.org> wrote: > On 02/11/16 15:00, Daniel Nebdal wrote: >> >> plugging in a >> USB keyboard post-panic didn't do much > > > Hi, > > USB enumeration is disabled in the debugger. You need to plug it in > pre-crash :-) Same with any USB crash dump device(s). > > --HPS Myeah, I didn't really expect it to work - at least I left it plugged in now. :) -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r294195: Kernel panic during installworld
On Sat, Jan 30, 2016 at 6:16 AM, Ultima <ultima1...@gmail.com> wrote: > Just upgraded from 10-STABLE to head r295051 and I still have kernel > panics. I then tested with bsdinstall and found that the panics no longer > occur. I believe the issue is that some of my datasets are set to > recordsize=1M, this is most likely the root cause of these panics. > > On Sun, Jan 17, 2016 at 2:59 PM, Ultima <ultima1...@gmail.com> wrote: > >> https://puu.sh/mzmpL/b209da9263.jpgn I hope this is better, sorry I >> didn't know it would get stripped. >> >> Ultima >> >> On Sun, Jan 17, 2016 at 2:58 PM, Ultima <ultima1...@gmail.com> wrote: >> >>> https://puu.sh/mzmpL/b209da9263.jpgn I hope this is better, sorry I >>> didn't know it would get stripped. >>> >>> Ultima >>> >>> On Sun, Jan 17, 2016 at 12:59 PM, Allan Jude <allanj...@freebsd.org> >>> wrote: >>> >>>> On 2016-01-17 09:14, Ultima wrote: >>>> > make installkernel KERNCONF=MYKERNEL >>>> > reboot >>>> > mergemaster -p >>>> > make installworld -> attached >>>> > >>>> > MYKERNEL=GENERIC+ >>>> > options VIMAGE >>>> > options ROUTETABLES=2 >>>> > >>>> > Anything else that maybe helpful? >>>> > >>>> > Ultima >>>> > ___ >>>> > freebsd-current@freebsd.org mailing list >>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> > To unsubscribe, send any mail to " >>>> freebsd-current-unsubscr...@freebsd.org" >>>> > >>>> >>>> Your attachment was stripped. Can you post it somewhere and include the >>>> url? >>>> >>>> -- >>>> Allan Jude >>>> That looks kind of similar to one I just got (on r295122 , during a lot of ZFS traffic) : https://goo.gl/photos/UkPV2BVi27Yucdgn7 Buildworld and installworld doesn't seem to be enough to trigger it for me - I'm upgrading it to whatever CURRENT was at an hour ago now. I couldn't get any further contact with the debugger (plugging in a USB keyboard post-panic didn't do much), but I left it connected now, and I should be able to set up a dump device and/or serial debugging. (The GSS kernel config I'm using is just amd64 GENERIC + options KGSSAPI .) -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Best way to update FreeBSD 11 ?
On Wed, Dec 2, 2015 at 10:43 PM, David Wolfskill <da...@catwhisker.org> wrote: > On Wed, Dec 02, 2015 at 02:39:24PM -0700, Sergey Manucharian wrote: >> Hello, >> >> What is the best way to update FreeBSD 11-CURRENT? >> Initially I've installed it from an image from [0] a couple of months ago. >> ... > > That depends on why you are considering the update. > > For me, I do in-place source updates "fairly" often (ref. src/UPDATING). > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Those who would murder in the name of God or prophet are blasphemous cowards. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. If you have root on ZFS, you can shuffle your directories around to get something compatible with beadm [1] . With that in place, you could clone your existing install, chroot into it, do the upgrade there, and then if it looks like it should work you can activate it and reboot to test. If it fails, you should be able to re-activate the previously working environment (by setting vfs.root.mountfrom to the appropriate path in the loader, I think) and be back where you were without too much fuss. With the caveat that I've barely touched this myself. [1] https://forums.freebsd.org/threads/updating-existing-zfs-layout-to-beadm.44813/ -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSL vs. LibreSSL (OpenBSD)
On Fri, Apr 25, 2014 at 10:16 AM, Matthias Gamsjager mgamsja...@gmail.com wrote: Isn't the latest news that Googleco and the linux foundation setup a construction that these vital opensource projects get the proper funding. Meaning more man power and hopefully less bugs. It remains to be seen which of LibreSSL vs a freshly funded OpenSSL ends up being the better alternative. If it comes to that, porting LibreSSL to FreeBSD ought to be quick work; it should be reasonably stand-alone code, and they're working to remove as many as possible of the weird/old/incompatible bits. It's not like our and their libc are massively different either, so ... cautiously optimistic that it'll be a one-day job to get it compiling on FreeBSD by the time they feel done. :) -- Daniel Nebdal ___ 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] how to get the size of a malloc(9) block ?
On Sun, Dec 1, 2013 at 4:04 AM, d...@gmx.com wrote: John-Mark Gurney wrote, On 12/01/2013 03:20: Either it happens rarely, and always doing a realloc won't hurt performance, or it happens often, and then you should be using a larger buffer in the first place.. What if a size-elastic implementation of a dynamic data structure would be able to adjust to the malloc implementation, such as agreeing to allocate regions of size (2^k - 8)? Much like the use of getpagesize() (yes, I know it's not part of a technical standard). That could alternatively be solved by having an if I ask for N bytes right now, how large would the block be - API that doesn't promise too much. Call it something like malloc_suggest_size(size_t minsize) , and make the description something like ... return the largest number of bytes that would not allocate a larger block of memory than the provided minsize, in the current memory situation, plus some veiled threats about not using this value to do anything fancy with pointers to already-allocated memory. -- Daniel Nebdal ___ 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] how to get the size of a malloc(9) block ?
On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff gleb...@freebsd.org wrote: On Thu, Nov 28, 2013 at 03:13:53PM +, jb wrote: j But I don't understand why you find ksize()/malloc_usable_size() dangerous. j ... j j The original crime is commited when *usable size* (an implementation detail) j is exported (leaked) to the caller. j To be blunt, when a caller requests memory of certain size, and its request is j satisfied, then it is not its business to learn details beyond that (and they j should not be offered as well). j The API should be sanitized, in kernel and user space. j Otherwise, all kind of charlatans will try to play hair-raising games with it. j If the caller wants to track the *requested size* programmatically, it is its j business to do it and it can be done very easily. +1 This is kind of APIs that just shouldn't exist. -- Totus tuus, Glebius. Then again: Using the overflow memory is only going to bite them if the API lies : If the return value is exactly the size of the block you got allocated and can safely use until you free it, using it will per definition be safe. If the allocator later changes to, say, always allocate exact byte ranges, or to allocating blocks but having the option to fragment them later - then the return value would have to shrink to match, and any program using it would still DTRT. I'm completely ambivalent about adding it, though - it's not something I need, it's more stuff that needs to be handled if you change/rewrite the allocator, and it's not my decision. -- Daniel Nebdal ___ 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] SO_REUSEADDR and SO_REUSEPORT behaviour
On Fri, Nov 29, 2013 at 1:04 PM, Ermal Luçi e...@freebsd.org wrote: Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on both! This is not the case today. Only multicast sockets seem to have the behaviour of broadcasting the data to all sockets sharing the same properties through these options! The patch at [1] implements/corrects the behaviour for UDP sockets. Is there anything to be corrected in that patch? Why it has not been provided there before? Can it be committed to the tree? Any extra security checks for jails needed there? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff -- Ermal I understood it as working sort of like for TCP, where packages from a given remote host+port all end up at exactly one of the local sockets? If the idea is to split the workload over multiple threads holding their own sockets listening to the same interface+port, wouldn't sending all packets to all sockets all the time be kind of counterproductive? Of course, I haven't actually used it much; I might be wrong. -- Daniel Nebdal ___ 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: rcs
On Tue, Oct 8, 2013 at 11:34 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Daniel. You wrote 8 октября 2013 г., 19:40:23: DN If they get the package repositories back up - which I assume will DN happen before any official releases from 10 - it should just be pkg DN install rcs. As challenges go, that doesn't seem too bad? Topic starter mentioned, that assumption that everybody has online connection is completely wrong! As far as I understand, it was his main objection -- they have a lot of offline computers at work (something related to Security Theatre by DHS, but who am I to judge them?). And you again says about pkg install rcs which needs internet connection! -- // Black Lion AKA Lev Serebryakov l...@freebsd.org I was answering Alfred Perlsteins claim that FreeBSD is a chore to install packages into. I agree that it won't work without an internet connection (or a local package repository), but that's hardly a problem limited to FreeBSD. Anyway, it seems likely that we'll get OpenRCS in base, hopefully making everyone happy. -- Daniel Nebdal ___ 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: rcs
On Tue, Oct 8, 2013 at 4:09 PM, Alfred Perlstein bri...@mu.org wrote: On 10/7/13 9:49 PM, Julian Elischer wrote: On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Maybe there was no development for 15 years. However, the 7364 lines in ChangeLog after 2010-02-04 suggests that there may be few bugs to worry about. I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. So again, is there a way to make it so adding RCS after install is not a big deal at all? -- Alfred Perlstein If they get the package repositories back up - which I assume will happen before any official releases from 10 - it should just be pkg install rcs. As challenges go, that doesn't seem too bad? That said, an online meta package builder *is* a nice idea, and seems perfectly doable. -- Daniel Nebdal ___ 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: iSCSI boot ... root?
On Mon, Sep 16, 2013 at 5:45 PM, Kristjan Eentsalu eents...@gmail.com wrote: On 16.09.2013 13:35, Edward Tomasz Napierała wrote: Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 16 wrz 2013, o godz. 07:35: Is it now possible to boot from iSCSI? I'm not talking about an iSCSI controller, but with pxe - dhcp - tftp (loads loader) - (something) - boot (mounts root from iSCSI) Not yet. The iSCSI initiator requires iscsid(8) in order to work, and you can't run it before mounting root. I think the proper way to do this would be by doing something similar to Linux' initrd; i.e. booting from mdroot loaded by loader(8), run iscsid(8) from there, setup iSCSI session, then mount the real root and pivot to it. I'm not sure if it's possible right now. ___ 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 Don't know if it works with CURRENT but You can use iPXE(formerly gPXE) chainloading and isboot module. http://ipxe.org/howto/chainloading http://ipxe.org/howto/dhcpd http://lists.freebsd.org/pipermail/freebsd-scsi/2012-August/005570.html Kristjan Oh wow, that is rather neat. I don't actually have any use for it, but now I'm kind of tempted to try and find one. ___ 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: portmaster
On Tue, Sep 17, 2013 at 1:30 AM, ajtiM lum...@gmail.com wrote: Thank ou. On Sep 16, 2013, at 7:15 PM, Matthias Andree matthias.and...@gmx.de wrote: Am 17.09.2013 01:04, schrieb ajtiM: Again me… I was (am) long postmaster user. Is it possible to use on FreeBSD 10 too, please? Or is better to use something different? Portmaster works for me on FreeBSD 10-CURRENT. Be sure to use an up-to-date ports tree and install an up-to-date portmaster. Mitja http://www.redbubble.com/people/lumiwa Is it still required to add WITH_PKGNG=YES to /etc/make.conf to get pkgng support in portmaster, or is that default in 10 / now? ___ 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: VAIO intel i7 Ivy Bridge ultrabook installation fail: Disks not found
On Tue, May 14, 2013 at 7:41 PM, Nicolas Alexander Scheibling n.scheibl...@gmx.ch wrote: Hello, as I am newly writing to these mailing lists, forgive my formal and content-relative mistakes. As it stands now, I would absolutely love installing some 10-CURRENT on my newly acquired SONY VAIO ultrabook. AFAIK powered by Ivy Bridge ULV, 1.9 - 2.3 GHz. It has an additional SATA 32 GB Samsung SSD and a regular 500 GB HDD. It comes with Win 8, cannot stand the Metro. (although Elan Touchscreen is nice). I installed world from my old-beater AMD box on a USB pen drive (i386). Now it loads the kernel, but won't let me mount any root file systems. Looks like the platter isn't detected at all. Is that a common problem with Ivy Bridge systems? Is it a deliberate chipset flaw by Intel as in *this low-end lappy is not allowed to run anything else than WIN* or can I do something about it? Forgive me for being at least a power user, but certainly no device driver developer. :(, all has its limits. Thank you so much. I'd jump for joy seeing this thing run BSD, preferably even from USB, as the turbo boost and the lowish power consumption are really cool. Don't rip my head off for untainted e-mail origin and somesuch. I'm a lazy bugger, my life circumstances aren't that great and most Importantly I Dont Have A 5 Million $$ Server Farm. Cheers. Just out of curiosity - have you tried playing with the BIOS settings for USB legacy mode - and for the SATA chipset mode? (If any, ofc.) ___ 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: multi-homing in freebsd
On Sat, Mar 16, 2013 at 5:00 PM, Gary Palmer gpal...@freebsd.org wrote: On Sat, Mar 09, 2013 at 01:29:27PM +0100, Daniel Nebdal wrote: Going by Zaphod's recommendation of using a /32 for each IP, how about this? ifconfig arge0 inet 192.168.1.100/32 ifconfig arge0 alias 192.169.1.100/32 I wouldn't recommend 192.169, though - only 192.168.x.x is reserved for private networks, and 192.169 is a valid IP-routable prefix, assigned to some US company. To be exact: The ranges from RFC1918 are 10.0.0.0/8, 172.16.0.0 /20 and 192.168.0.0/24. I think you mean the RFC1918 ranges are 10.0.0.0/8 (aka 10.0.0.0 through 10.255.255.255) 172.16.0.0/12 (aka 172.16.0.0 through 172.31.255.255) 192.168.0.0/16 (aka 192.168.0.0 through 192.168.255.255) Regards, Gary Uhm, yes. I can't have been entirely awake when I wrote that. ___ 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: Error question
How does your make.conf and src.conf look? On Thu, Mar 14, 2013 at 3:49 PM, Charlie Jones cjo...@innerlightcorp.com wrote: I am trying to upgrade to 9.1-RELEASE uname -a FreeBSD havoc.innerlightcorp.com 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #0: Mon May 30 12:58:18 MDT 2011 r...@havoc.innerlightcorp.com:/usr/obj/usr/src/sys/CUSTOM amd64 I received these messages at the end of the make buildworld process. Is it something that I should be concerned with? Any ideas? I don't want to compound the problem by moving on when I see Error code 1. rm -f freebsd.cf freebsd.submit.cf cd /usr/src; MACHINE=i386 MACHINE_ARCH=i386 MACHINE_CPU=i686 mmx sse sse2 MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 _LDSCRIPTROOT=/usr/obj/usr/src/lib32 VERSION=FreeBSD 8.2-RELEASE-p2 amd64 802000 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bi n:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr /obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/ usr/games:/sbin:/bin:/usr/sbin:/usr/bin LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 COMPILER_TYPE=clang /usr/obj/usr/src/make.amd64/make AS=as --32 LD=ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 CC=cc -m32 -march=nocona -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 CXX=c++ -m32 -march=nocona -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 DESTDIR=/usr/obj/usr/src/lib32 -DCOMPAT_32BIT -DLIBRARIES_ONLY -DNO_CPU_CFLAGS -DNO_CTF -DNO_LINT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -f Makefile.inc1 par-cleandir /usr/src/Makefile.inc1, line 175: CPUTYPE global should be set with ?=. *** [_cleanobj] Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks in advance Charlie Jones ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-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: multi-homing in freebsd
Going by Zaphod's recommendation of using a /32 for each IP, how about this? ifconfig arge0 inet 192.168.1.100/32 ifconfig arge0 alias 192.169.1.100/32 I wouldn't recommend 192.169, though - only 192.168.x.x is reserved for private networks, and 192.169 is a valid IP-routable prefix, assigned to some US company. To be exact: The ranges from RFC1918 are 10.0.0.0/8, 172.16.0.0 /20 and 192.168.0.0/24. On Sat, Mar 9, 2013 at 9:57 AM, Yasir hussan kolya...@gmail.com wrote: Kindly will u give me example with cammand line, which can test on my freebsd machine, i want two ips 192.168.1.100 and 192.169.1.100 to be work on single network interface, my default interface for network is arge0 On Sat, Mar 9, 2013 at 3:08 AM, Zaphod Beeblebrox zbee...@gmail.com wrote: On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan kolya...@gmail.com wrote: i just want to run multiple IPs for single network card in freebsd OK. A better question. About the only caution I can give here (assuming you don't mean something more interesting like vlans and whatnot) is that if both IP addresses are on the SAME network, use a /32 as the netmask (it works better). If they are on different networks, specify the netmask as normal. You may, at this point, need a method to choose which IP address to use for any particular connection. There's a pile of documentation waiting for you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: multi-homing in freebsd
Oh, you specifically need them to have different interfaces? That's a bit more complicated. I guess you could rig something with netgraph (ngctl and such), but I'm not familiar with it... -- Daniel Nebdal On Sat, Mar 9, 2013 at 2:57 PM, Yasir hussan kolya...@gmail.com wrote: i want to have differnet ips`s and each should have different interface, it could be a virtual interface. like u can made it like ifconfig arge0.1 create but each ip should able to access from differnet machine On Sat, Mar 9, 2013 at 7:29 AM, Daniel Nebdal dneb...@gmail.com wrote: Going by Zaphod's recommendation of using a /32 for each IP, how about this? ifconfig arge0 inet 192.168.1.100/32 ifconfig arge0 alias 192.169.1.100/32 I wouldn't recommend 192.169, though - only 192.168.x.x is reserved for private networks, and 192.169 is a valid IP-routable prefix, assigned to some US company. To be exact: The ranges from RFC1918 are 10.0.0.0/8, 172.16.0.0 /20 and 192.168.0.0/24. On Sat, Mar 9, 2013 at 9:57 AM, Yasir hussan kolya...@gmail.com wrote: Kindly will u give me example with cammand line, which can test on my freebsd machine, i want two ips 192.168.1.100 and 192.169.1.100 to be work on single network interface, my default interface for network is arge0 On Sat, Mar 9, 2013 at 3:08 AM, Zaphod Beeblebrox zbee...@gmail.com wrote: On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan kolya...@gmail.com wrote: i just want to run multiple IPs for single network card in freebsd OK. A better question. About the only caution I can give here (assuming you don't mean something more interesting like vlans and whatnot) is that if both IP addresses are on the SAME network, use a /32 as the netmask (it works better). If they are on different networks, specify the netmask as normal. You may, at this point, need a method to choose which IP address to use for any particular connection. There's a pile of documentation waiting for you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: Response of *.freebsd.org websites are very slow
I think you're supposed to be automatically sent to the mirror that is closest to you - for some value of closest. If the mirror you're getting has issues, that might show up like this. Could you post the output of traceroute ftp.freebsd.org ? It should show which mirror you're getting, and perhaps if there are any obvious problems on the way. Also, you can try setting PACKAGEROOT to e.g. ftp://ftp.beastie.tdk.net , to see if that makes pkg_add work better. That's the mirror closest to me - if that one works ok for you, it's another sign that the problem is with your local mirror. :) -- Daniel Nebdal On Wed, Feb 27, 2013 at 2:39 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Dear All , I have installed https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HEAD-r247266-JPSNAP with a very nice steps flow and it has booted very well . During pkg_add -rv xorg it become necessary to try many times , and for other packages the action is the similar . The response of pkg_add is Address could not be found . . Actually , this situation is started after security incident occurrence . Access to *.freebsd.org sites are so slow that many times , web browsers Firefox , Chromium are displaying a message to tell : Site is not found ... Try once more ... To access to other sites in US may be considered instantaneous here in Turkey . I think a solution may be supplied for this problem . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-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: Response of *.freebsd.org websites are very slow
On Wed, Feb 27, 2013 at 11:37 AM, Daniel Kalchev dan...@digsys.bg wrote: On 27.02.13 12:23, Daniel Nebdal wrote: I think you're supposed to be automatically sent to the mirror that is closest to you - for some value of closest. If the mirror you're getting has issues, that might show up like this. Could you post the output of traceroute ftp.freebsd.org ? It should show which mirror you're getting, and perhaps if there are any obvious problems on the way. I believe, in his case that would be traceroute ftp.tr.freebsd.org. The list of mirrors is here http://www.freebsd.org/doc/handbook/mirrors-ftp.html in any case, anything *.freebsd.org actually refers to plenty of hosts all over the world -- some might be slow, some very fast. On the other hand, Address could not be found type of errors indicates something else than fast or slow. Daniel That sounds likely, yes - and interestingly, it seems to be down: djnebdal@login2 ~ traceroute -w 1 ftp.tr.freebsd.org traceroute to ftp.tr.freebsd.org (193.140.143.151), 30 hops max, 40 byte packets 1 mrom-gw1.uio.no (129.240.12.3) 0.881 ms 0.922 ms 0.981 ms 2 uio-gw7.uio.no (129.240.25.5) 0.387 ms 0.437 ms 0.492 ms 3 uio-gw8.uio.no (129.240.25.190) 0.336 ms 0.400 ms 0.419 ms 4 oslo-gw.uninett.no (128.39.65.17) 0.316 ms 0.355 ms 0.378 ms 5 se-tug.nordu.net (109.105.102.21) 7.947 ms 23.017 ms 23.080 ms 6 dk-uni.nordu.net (109.105.97.10) 16.457 ms 16.471 ms 16.456 ms 7 nordunet-bckp2.rt1.ams.nl.geant.net (62.40.125.205) 29.590 ms 29.631 ms 29.662 ms 8 so-2-0-0.rt1.fra.de.geant2.net (62.40.112.9) 36.480 ms 36.476 ms 36.473 ms 9 so-2-1-0.rt1.pra.cz.geant2.net (62.40.112.37) 42.983 ms 42.986 ms 42.944 ms 10 as0.rt1.bud.hu.geant2.net (62.40.112.42) 49.833 ms 49.594 ms 51.680 ms 11 so-2-0-0.rt1.sof.bg.geant2.net (62.40.112.201) 62.857 ms 62.901 ms 62.742 ms 12 ulakbim-gw.rt1.sof.bg.geant.net (62.40.125.130) 73.853 ms 73.985 ms 73.390 ms 13 * * * (...) 30 * * * djnebdal@login2 ~ ping ftp.tr.freebsd.org PING ftpfreebsd.marmara.edu.tr (193.140.143.151) 56(84) bytes of data. --- ftpfreebsd.marmara.edu.tr ping statistics --- 28 packets transmitted, 0 received, 100% packet loss, time 27001ms ___ 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: Response of *.freebsd.org websites are very slow
Ok, that's weird. What does a simple nslookup ftp.freebsd.org give you? On Wed, Feb 27, 2013 at 3:11 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev dan...@digsys.bg wrote: On 27.02.13 12:23, Daniel Nebdal wrote: I think you're supposed to be automatically sent to the mirror that is closest to you - for some value of closest. If the mirror you're getting has issues, that might show up like this. Could you post the output of traceroute ftp.freebsd.org ? It should show which mirror you're getting, and perhaps if there are any obvious problems on the way. I believe, in his case that would be traceroute ftp.tr.freebsd.org. The list of mirrors is here http://www.freebsd.org/doc/** handbook/mirrors-ftp.htmlhttp://www.freebsd.org/doc/handbook/mirrors-ftp.html in any case, anything *.freebsd.org actually refers to plenty of hosts all over the world -- some might be slow, some very fast. On the other hand, Address could not be found type of errors indicates something else than fast or slow. Daniel traceroute ftp.tr.freebsd.org is working . traceroute ftp.freebsd.org http://ftp.tr.freebsd.org is NOT working . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-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: Response of *.freebsd.org websites are very slow
On Wed, Feb 27, 2013 at 3:28 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Wed, Feb 27, 2013 at 6:22 AM, Daniel Nebdal dneb...@gmail.com wrote: Ok, that's weird. What does a simple nslookup ftp.freebsd.org give you? On Wed, Feb 27, 2013 at 3:11 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev dan...@digsys.bg wrote: On 27.02.13 12:23, Daniel Nebdal wrote: I think you're supposed to be automatically sent to the mirror that is closest to you - for some value of closest. If the mirror you're getting has issues, that might show up like this. Could you post the output of traceroute ftp.freebsd.org ? It should show which mirror you're getting, and perhaps if there are any obvious problems on the way. I believe, in his case that would be traceroute ftp.tr.freebsd.org. The list of mirrors is here http://www.freebsd.org/doc/** handbook/mirrors-ftp.htmlhttp://www.freebsd.org/doc/handbook/mirrors-ftp.html in any case, anything *.freebsd.org actually refers to plenty of hosts all over the world -- some might be slow, some very fast. On the other hand, Address could not be found type of errors indicates something else than fast or slow. Daniel traceroute ftp.tr.freebsd.org is working . traceroute ftp.freebsd.org http://ftp.tr.freebsd.org is NOT working . nslookup ftp.freebsd.org ;; connection timed out ; trying next origin ;; connection timed out ; no servers could be reached netbsd , openbsd , dragonflybsd is working . ftp.tr.freebsd.org is working . Thank you very much . Mehmet Erol Sanliturk So nslookup (of ftp.freeebsd.org) fails on FreeBSD, but not the other BSDs? That's very strange. Is /etc/resolv.conf the same in FreeBSD and one of the working ones? Have you set up a firewall on the FreeBSD install? Does it have IPv6? -- Daniel Nebdal ___ 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: r245741 (clang as cc) can not build binaries for GEODE processor
On Fri, Feb 22, 2013 at 7:46 AM, Lev Serebryakov l...@freebsd.org wrote: Hello, freebsd-current. I have -CURRENT i386 installation which runs r245741 now. Default compiler is clang: cc --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: i386-unknown-freebsd10.0 Thread model: posix This system is used to build NanoBSD images (and ports for these images) for my home router, which has AMD Geode CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) Build system has only one setting in /etc/src.conf and /etc/make.conf: MALLOC_PRODUCTION=yes NanoBSD image build includes many options, and CPUTYPE=geode is among them. Today I've rebuilt all ports (including samba36) and image (from r247117). And new samba port (samba36-3.6.12) failed to start on target system (with Geode CPU). It gets SIGILL (!!!). I was able to get core file by running testparam in NFS-mounted R/W file system, but after that GDB (on build system, as NanoBSD image doesn't contain one) says, that it could not access memory at failure address to show disassembly: gdb /usr/local/bin/testparm ~/testparm.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Core was generated by `testparm'. Program terminated with signal 4, Illegal instruction. #0 0x010351d6 in ?? () (gdb) x/i $pc 0x10351d6: Cannot access memory at address 0x10351d6 (gdb) bt #0 0x010351d6 in ?? () #1 0x in ?? () (gdb) -- // Black Lion AKA Lev Serebryakov l...@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 I'm not familiar with NanoBSD, but does it do the package builds for you - or do you do those by hand? If it's the latter, I don't quite understand how the compiler is supposed to know the target CPUTYPE? -- Daniel Nebdal ___ 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: r24684: /usr/src/lib/libldns/../../contrib/ldns/buffer.c:10:10: fatal error: 'ldns/config.h' file not found
That looks like a slightly different issue, though? r246855 built for me last night, for what it's worth - though I'm not sure if that was with -Werror. On Sat, Feb 16, 2013 at 12:14 AM, Michael Butler i...@protected-networks.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/15/13 17:49, Daniel Nebdal wrote: Should be fixed as of r246853 (marked as Add generated files, and it seems to add the missing config.h and a few others). Nope cc1: warnings being treated as errors /usr/src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: 'ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlEewWEACgkQQv9rrgRC1JKfhwCgl7Atdb2bOK0dT0tVzmLt1RjO AkYAoLfnOVaoQDnMmLFqx+zWVaBJ0uK1 =UMsp -END PGP SIGNATURE- ___ 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: r24684: /usr/src/lib/libldns/../../contrib/ldns/buffer.c:10:10: fatal error: 'ldns/config.h' file not found
Should be fixed as of r246853 (marked as Add generated files, and it seems to add the missing config.h and a few others). -- Daniel Nebdal On Fri, Feb 15, 2013 at 8:34 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am 02/15/13 19:08, schrieb David Wolfskill: On Fri, Feb 15, 2013 at 07:01:16PM +0100, O. Hartmann wrote: ... My boxes are one revision ahead of yours and all of them do not build the recent sources as reported: FreeBSD 10.0-CURRENT #0 r246825: Fri Feb 15 14:23:40 CET 2013 And by the way, we have amd64 only, no i386. Maybe this makes a diffrence? No, but contrib/ldns wasn't imported until r246827 What's the revision of your sources? Note, in particular, http://docs.FreeBSD.org/cgi/mid.cgi?86txpdptgf.fsf. Peace, david As the subject headline says: r24684 I try now sources r246848 and it fails the same way on FreeBSD 10.0-CURRENT/amd64 ___ 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: Stucking processes
Couldn't that just be because you're running a world that expects one kernel but finds another? As far as I know, running a newer world in a jail on an older system is not really recommended (while the opposite ought to be ok)? On Jun 16, 2012 11:33 AM, Alexander Yerenkow yeren...@gmail.com wrote: Hello all. Since I'm using stable as host, and current in chroot, I'll write to both mail list, sorry for any inconvenience. My host is binary freebsd-updated 9; FreeBSD 9.0-RELEASE-p3 (GENERIC) #0: Tue Jun 12 02:52:29 UTC 2012 I have chroot with latest current there installed r237089 (make buildworld buildkernel, no specific flags) When I built from ports some programs in chroot all went fine, until I got stucked process automoc (when building kdelibs4); After few restarts I got build, and forget about it. I'm toying now with portupgrade, and see similar stucks in ruby18 and ruby19 (Even got few times in miniruby while building 1.8); Here's example of stucked processes (they aren't in top, and seems totally inactive. I haven't kill them yet, so can try to dig, but to where?): 2677 5 Is0:00,00 | `-- /bin/sh 2678 5 I 0:00,00 | `-- sudo su 2679 5 I 0:00,00 | `-- su 2680 5 I 0:00,01 | `-- _su (csh) 2687 5 I 0:00,03 | `-- /bin/csh -i 2690 5 I+0:04,34 | `-- ruby19: portupgrade: [1/237] audio/libsamplerate (ruby19) # procstat -k 2690 PIDTID COMM TDNAME KSTACK 2690 100477 ruby19 -mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep do_wait __umtx_op_wait_uint_private_compat32 ia32_syscall Xint0x80_syscall 2690 101110 ruby19 -mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select freebsd32_select ia32_syscall Xint0x80_syscall #top (with inactive filtered out;) last pid: 11049; load averages: 0.09, 0.16, 0.19 up 0+00:14:48 12:27:20 63 processes: 1 running, 62 sleeping CPU: 1.0% user, 0.0% nice, 0.8% system, 1.2% interrupt, 97.0% idle Mem: 184M Active, 96M Inact, 1104M Wired, 2412K Cache, 171M Buf, 454M Free Swap: 4096M Total, 4096M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 2610 root 2 200 261M 82548K kqread 1 0:12 1.27% rtorrent Is this my side's problem, or there's something wrong with current? :) Any help appreciated. -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-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: Binary packages for LibreOffice 3.5 or 3.4
In the case of gcc46, when I execute the previous six lines, return to /data/port-work/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2, and run make, I get: it says: Error expanding embedded variable. (Per a previous message, I have re-compiled libcmis with gcc42.) Any ideas? Robert Huff Try with gmake instead? -- Daniel Nebdal ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On Wed, May 9, 2012 at 2:43 PM, Baptiste Daroussin b...@freebsd.org wrote: On Wed, May 09, 2012 at 07:59:15AM -0400, Robert Huff wrote: Daniel Nebdal writes: In the case of gcc46, when I execute the previous six lines, return to /data/port-work/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2, and run make, I get: it says: Error expanding embedded variable. (Per a previous message, I have re-compiled libcmis with gcc42.) Any ideas? Robert Huff Try with gmake instead? After fishing in different directoroes, I did so and got: Entering /data/port-work/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/sal/textenc Entering /data/port-work/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/sal/util Making: libuno_sal.so.3 : ERROR: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by ../unxfbsd.pro/lib/check_libuno_sal.so.3 not found dmake: Error code 1, while making '../unxfbsd.pro/lib/libuno_sal.so.3' Robert Huff That was the problem I was speaking about mixing different libstdc++ the one from base and the one from gcc46. I don't know how to fix this. regards, Bapt Does this also happen when building libreoffice with clang? I just built it on 8.2 using clang, and that worked fine (apart from a failure in vcl, but that was caused by some leftover qt3 headers in /usr/local/include ). Daniel Nebdal ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Wed, Dec 21, 2011 at 10:49 PM, Johan Hendriks joh.hendr...@gmail.com wrote: Alexander Leidinger schreef: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. (...) It does, though? It's in ports. The system compiler is for the system, but if you're compiling ports or standalone software you certainly can - and sometimes must - use something else. The point of that section seems to be if you're compiling userland software to compare, at least compile it with the same compiler, unless that's what you want to benchmark. Sensible enough. As for what the kernel is compiled with, I doubt that will have the same kind of effect as what the user software is compiled with. The kernel is compiled with very conservative settings anyway, and I don't think it really does much of the kind of heavy computation that benefits the most from better compilers. The most interesting part is probably the effect on the userland libraries. Has anyone done any tests on how much of an effect on user software performance it has if you change the compiler for the libraries in the base system? (I would guess not massive, but this is one of those things where some numbers wouldn't hurt). Oh, and remember that clang also works as a system compiler, and we're definitely not stuck on an old version of that. It produces code with performance comparable to gcc today, and I doubt it'll fall horribly behind in the foreseeable future. -- Daniel Nebdal ___ 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: SCHED_ULE should not be the default
On Thu, Dec 15, 2011 at 9:58 PM, Mike Tancsa m...@sentex.net wrote: On 12/15/2011 11:56 AM, Attilio Rao wrote: So, as very first thing, can you try the following: - Same codebase, etc. etc. - Make the test 4 times, discard the first and ministat for the other 3 - Reboot - Change the steal_thresh value - Make the test 4 times, discard the first and ministat for the other 3 Then report discarded values and the ministated one and we will have more informations I guess (also, I don't think devfs contention should play a role here, thus nevermind about it for now). Results and data at http://www.tancsa.com/ule-bsd.html ---Mike I took the liberty of re-plotting this as one boxplot per test-type, in the hope of getting a better overview. R script included. Beware the y-ranges. (To re-plot with a specific y range, add e.g. ylim=c(0,35) to the boxplot() calls.) http://nebdal.net/sched/plot.html -- Daniel Nebdal Dep. of genetics, Oslo University Hospital ___ 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: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab.
Thanks, John. I was afraid that was the answer. Now, II'm really confused. I'm guessing that the partitions will notl need to be shown in fstab (ada0s1a). What little mind I have left is a blank, /dev/ad4s1g will be automatically be detected. Is that correct? What will I do with my second disk /dev/ad0s1a that is already zero? I apologize but I have really confused myself. I've filled my glass with too much water and I'm drowning. Thanks for everyone's patience. ed P.S. If I am not the only idiot, maybe a couple of lines as an example could go into UPDATING. If I have understood ada correct, the first disk (lowest current number) is ada0, the next ada1, and so on. If you have ad0 and ad4, they will be ad0=ada0, and ad4=ada1 . It doesn't affect anything _except_ the disk names, so ad4s1f = ada1s1f and so on. You'll have to change most of your fstab, basically s/ad0/ada0/g and s/ad4/ada1/g . That said, my one ad to ada transition was on a ZFS-only system, which took the fstab editing out of it. I might be horribly wrong in some or all of the above. -- Daniel Nebdal ___ 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: run_interrupt_driven_config_hooks: waited too long' on HP DV8
On Mon, Mar 14, 2011 at 2:34 AM, Matthew Jacob m...@feral.com wrote: On 3/13/2011 5:03 PM, Yuri Pankov wrote: On Sun, Mar 13, 2011 at 04:41:58PM -0700, Matthew Jacob wrote: Yes they are. The full messages from the failed boot would be helpful. Looks like we have ATA in CAM now, so it's possible that the disk reset failed, etc... What are my options for saving the output from failed boot other than handtyping it (no serial ports, no serial USB adapters)? None that I can think of :-( Well, there's always the digital camera / posting pictures solution... -- Daniel Nebdal ___ 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: why panic(9) ?
On Wed, Jan 12, 2011 at 1:43 PM, Nils Holland n...@tisys.org wrote: C. P. Ghost wrote: As far as I know, Windows NT is a microkernel arch, and faulty drivers, often provided by external vendors would not bring that system (as much as we hate or despise its Windows OS personality that runs on top of it) to a complete halt. I don't know ... when Windows crashes (I'm no fan of it either, but anyway) and you ask Microsoft about it, then it's most of the time an external driver that is responsible. Graphics card driver seem to be the cause most often, but other stuff as well. (...) Greetings, Nils a) NT isn't really a microkernel; most drivers run in kernelspace and can happily mess things up if they fail. b) Graphics drivers are actually one of the things they've fixed (well, re-fixed; this was also the case in 3.51) - from Vista and onwards they mostly live in userspace. (I've had the graphics driver crash on me a few times - it's restarted automatically, and all that happens is that the screen goes black for some seconds. It's kind of impressive.) More on topic, I can only agree with the majority - failing fast is a feature, both to mess things up as little as possible, and to make diagnostics and later fixing easier. -- Daniel Nebdal ___ 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: sound config problem
On Tue, Nov 23, 2010 at 10:24 PM, AN a...@neu.net wrote: What is the status of sound on 9-current? I am having a problem getting sound to work. I have snd_hda_load=YES in /boot/loader.conf. When I try to configure sounds in Gnome, by going to System menu - preferences - sound, a small window opens saying waiting for sound system to respond then nothing happens. This system worked perfectly with sound under 8-stable. Any help fixing this would be appreciated. Below is relevant parts of verbose dmesg. If I can provide more info to troubleshoot this please let me know. tia (info cut for brevity) Just as a starter, does it work at all? That is, do you have a /dev/dsp? Do simple OSS programs work? (mpg123 is a nice minimal test; mplayer is fine.) There's always a chance of the problem being on the gnome side of things, so it just seems sensible to start with the really simple things. Apologies if you've done this already. :) -- Daniel Nebdal ___ 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: aperf/mperf
On Fri, Nov 19, 2010 at 4:39 PM, Andriy Gapon a...@freebsd.org wrote: I am thinking about providing two APIs for this. 1. KPI void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); 2. Userland sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. But I am not sure where to put the code for both APIs. Adding another device under cpu seems like an overkill. Ideas? Thanks! No comment on where to put it, but one other detail: Since these are measures since last reset, you probably want a similar cpu_zero_a_m_perf call. As for how that interacts with the sysctl, uhm ... maybe also offering a time-since-last-reset could be useful? -- Daniel Nebdal ___ 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: aperf/mperf
On Thu, Nov 18, 2010 at 2:32 PM, Andriy Gapon a...@freebsd.org wrote: on 18/11/2010 05:53 George Neville-Neil said the following: On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: Many modern processors provide APERF and MPERF MSRs which allow to easily and reliable calculate average CPU performance level over some interval of time. This also allows to notice things like performance boost, which is generally hidden from software. What would be a proper place to add code that would measure APERF/MPERF ratio? When should trigger such a measurement and over what interval? Ideas? Can you point me at documentation for this? This sounds a lot like hwpmc(4) and I wonder if we can make these available in the same way. Actually it feels more cpufreq-ish to me. This feature is documented in, e.g., Intel Software Developer's Manual volume 3A, section 14.2 P-STATE HARDWARE COORDINATION. Just for the sake of gathering information here: What they offer are two (64-bit, wrapping) counters; one that increases at a constant rate, and one that increases in proportion to the current performance of the CPU, so that APERF/MPERF = fraction of max possible performance the CPU has offered since the last time the counters were zeroed. Intel specifically suggests multiplying that with the observed CPU load over the same time period to get an absolute CPU load number, and using that to pick a suitable P-state. On a tangent, I wonder if you can get APERFMPERF if you're using an i5/i7 and their dynamic/automatic overclocking kicks in? As for what to do with it, it sounds like it would make sense as an alternate data source for powerd? -- Daniel Nebdal ___ 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: TTY task group scheduling
On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev kab...@gmail.com wrote: On Thu, 18 Nov 2010 18:56:35 + Alexander Best arun...@freebsd.org wrote: On Thu Nov 18 10, Matthew D. Fuller wrote: On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of Alexander Best, and lo! it spake thus: judging from the videos the changes are having a huge impact imo. Well, my (admittedly limited, and certainly anecdotal) experience is that Linux's interactive response when under heavy load was always much worse than FreeBSD's. So maybe that's just them catching up to where we already are ;) well...i tried playing back a 1080p vide files while doing `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. One thing that just begs to be asked: since when decoding 1080p became an interactive task? Strictly speaking it isn't - but displaying it is a timing-sensitive task that isn't CPU- or I/O-bound, and scheduling-wise that probably makes it more like the fast response when woken up interactive tasks than a CPU-bound non-interactive process. Decoding it into another file on the disk is in the latter category, of course - but I don't think that's what he meant. :) More on topic - while this was a tiny patch for Linux, it seems like it would take more work for us, since I don't believe either of the schedulers handles task groups in the required way. The linux patch was just create task groups automatically, since they already had some suitable logic for scheduling based on task groups in their CFS scheduler. We would have to (re-)add that first, which is non-trivial. -- Daniel Nebdal ___ 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: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED]
On Fri, Nov 12, 2010 at 5:24 AM, Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au wrote: 0n Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: I just committed libcompiler_rt.a to HEAD. Even though I don't expect serious issues -- especially not on the tier 1 architectures -- be sure to contact me in case something goes wrong. I hooked it up to the build in a separate commit, so if your system starts to act weird, just revert r2151 Can you please explain to us what this actually brings to the table for freebsd ? I know it replaces libgcc ... but why is that such a good thing ? -Alex The main thing is that it's BSD-licensed instead of GPL, I believe. -- Daniel Nebdal ___ 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: Is nvidia-driver 256.53 expected to work on -current?
On Mon, Oct 18, 2010 at 8:54 AM, Doug Barton do...@freebsd.org wrote: On Sun, 17 Oct 2010, Garrett Cooper wrote: On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton do...@freebsd.org wrote: On 10/17/2010 4:49 PM, Rob Farmer wrote: I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have device agp. Hmm. I had all the options off except linux. I'll try with your combination and see if that improves things. I've given up on linux emulation support since 256.3x as it was the factor that was causing lockups on my two machines. Thanks. I tried again without linux support, no change, it still froze up. I suppose I can try again tomorrow without any of the options selected. Doug For what it's worth, the newest nvidia driver in ports (256.53) reliably freezes both my 8-STABLE and 9-CURRENT machine dead within minutes (amd64 , KDE4 both with and without compositing, Geforce GT240 cards. The mouse stops moving, no keyboard input does anything, it doesn't answer on the network.) I haven't had time to look at it, so I'm using the nv driver for now. -- Daniel Nebdal ___ 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: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 8:58 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric d...@freebsd.org wrote: On 2010-09-29 02:28, Derek Tattersall wrote: A test shell script using mktemp (1) works fine on current built with clang today. The clang case produces a filename with all A's rather than the random letters expected. I cannot reproduce this on a system compiled entirely with clang: $ mktemp foo.XX foo.MyUM5k $ mktemp foo.XX foo.YidMeT $ mktemp foo.XX foo.L27Cfz $ mktemp foo.XX foo.k3haLx ... and so on. Can you post that test script, please? Please note your CPUTYPE and CFLAGS (for both those that had a problem and those that didn't) there might be some evidence in there that would help to resolve this issue with clang. Thanks, -Garrett Works for me with random names; tested with the File::Temp script posted earlier. Amd64 on a Core2-family Xeon. In a make buildenv - environment I have CPUTYPE='', and no CFLAGS set. As for version, err. I csup-ed the code on Sep 24, and VERSION is 'FreeBSD 9.0-CURRENT amd64 900021' . How do you find the r-number anyway? I can grab today's version and see if it still works for me. If it matters, the process was buildworld with gcc, installworld, buildworld with clang, installworld. -- Daniel Nebdal ___ 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: Building world with clang
On Tue, Aug 17, 2010 at 1:49 PM, Bob Bishop r...@gid.co.uk wrote: On 17 Aug 2010, at 12:32, Dimitry Andric wrote: However, a disadvantage is that the built-in search paths of the bootstrap compiler are not entirely disabled by using the -isysroot, -B and -L flags, This could be viewed as a bug ... For clarification, did you (Dimitry, that is) mean a) The paths are still there so they could resurface if some Makefile doesn't specify those flags , or b) they sometimes come into play even when using the appropriate flags? -- Daniel Nebdal ___ 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: Building world with clang
On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric dimi...@andric.com wrote:
On 2010-08-17 15:03, Daniel Nebdal wrote:
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags,
...
For clarification, did you (Dimitry, that is) mean
a) The paths are still there so they could resurface if some Makefile
doesn't specify those flags , or
b) they sometimes come into play even when using the appropriate flags?
Any sub-makefiles would not have to specify those flags explicitly,
since they were added to ${CC} and ${CXX}.
But what I meant is that even if you specify those flags, the compiler
still searches for headers and libraries in the base system. So if some
header is removed from /usr/src, for example, but is still available in
/usr/include, it can be erroneously picked up during buildworld.
Mmh, I just read through the in-detail description you gave in another
mail. It's a bit surprising that there isn't a simple and reliable way
to disable/replace all hardcoded paths, but I guess it doesn't come up
that often.
As a third possibility, hacking a real -drop-all-builtin-paths flag
into the local copies of both compilers could work (essentially being
a cleanup of your alternative 1), though there's still the issues with
-B. All in all, I agree that your alternative 2 sounds better.
--
Daniel Nebdal
___
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: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 2:04 PM, Kostik Belousov kostik...@gmail.com wrote: (...) From what it was claimed, even without the import, users can install whatever compiler from ports, set CC and start the build. Essentially, the import blesses the clang and its current state as ready for wide use. Not necessarily. If it is - disabled by default - not recommended anywhere - recommended against for production usage (I suspect it will carry the usual might set your dog on fire - disclaimer for a while) that's hardly a glowing recommendation. I'm not sure if it's the best comparison, but it reminds me of how SCHED_ULE was available but mostly ignored until it was made default. -- Daniel Nebdal ___ 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
