Re: Switchover to CAM ATA?
Hello, Alexander.
You wrote 22 апреля 2010 г., 19:31:37:
> and RAID5 (due to lack of module in a base system).
I'm cleaning up gradi5 now according to style(9) and want to make
port out of it in month or two ("unfortunalety", I have alot of paid
work, which is not FreeBSD-related in any way).
It works very well for me on, and I have one HDD crash already,
recovered with graid5 :)
--
// Black Lion AKA Lev Serebryakov
___
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: Switchover to CAM ATA?
Hello, Nenhum_de_Nos.
You wrote 23 апреля 2010 г., 09:08:05:
>> > and RAID5 (due to lack of module in a base system).
>> I'm cleaning up gradi5 now according to style(9) and want to make
>> port out of it in month or two ("unfortunalety", I have alot of paid
>> work, which is not FreeBSD-related in any way).
>> It works very well for me on, and I have one HDD crash already,
>> recovered with graid5 :)
> this means graid5 in the tree ?
Unfortunalety, it means graid5 in ports only for now. But in
future... who knows?
--
// Black Lion AKA Lev Serebryakov
___
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: Switchover to CAM ATA?
Hello, Pawel. You wrote 26 апреля 2010 г., 23:10:12: > You most likely got it right, I'm just saying creating separate GEOM > class for each metadata format is wrong direction. :) Does ataraid translations and checksuming (in case of RAID5) now or it configures chipsets only? All these ``raids'' are known as ``soft raids'' or ``fake raids'', but what does do real work -- BIOS or driver (Ataraid in case of FreeBSD)? -- // Black Lion AKA Lev Serebryakov ___ 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: Switchover to CAM ATA?
Hello, Dag-Erling. You wrote 27 апреля 2010 г., 17:34:14: > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. Why are they called ``PSEUDO-raids'' then? -- // Black Lion AKA Lev Serebryakov ___ 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"
5.0-RELEASE & VMWare 3.2
Hello, current! How are you? When I needed to experiment with 4.6-RELEASE and I didn't have ``free'' computer, I installed 4.6-RELEASE on VMWare. It works pretty well and I was totally satisfied. My host is: 2xP!!!-770Mhz, 512Mb of memory, Hardware RAID with 2x40Gb IBM IDE HDDs (and one simple system disk). Host OS is W'2000 WS. Now I'm trying to look at 5.0-RELEASE (I've downloaded ISO of first i386 CD). It doesn't work under VMWare 3.2! Ok, it works, really. But speed is VERY low. I even could not do installation! Unpacking of distributive have been started at normal speed, but after 2 or 3 minutes speed decreased to 6Kb/s and after that to 1Kb/s! `top' on emergency console shows, that cpio+gunzip take only 5% of CPU, system takes 25% of CPU and interrupts takes 70% of CPU! 4.6-RELEASE installs on same VMWare virtual computer without any problems and works very fast! Is it problem of VMWare or 5.0-RELEASE? Is it known problem? I could provide any additional information, if needed. Lev Serebryakov /---\ | FIDONet: 2:5030/661.0 | | E-Mail: [EMAIL PROTECTED] | | Page:http://lev.serebryakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re[2]: 5.0-RELEASE & VMWare 3.2
Hello, Brooks! Thursday, January 23, 2003, 10:56:28 PM, you wrote: BD> From sys/i386/conf/NOTES: BD> # CPU_DISABLE_CMPXCHG disables the CMPXCHG instruction on > i386 IA32 BD> # machines. VmWare seems to emulate this instruction poorly, causing BD> # the guest OS to run very slowly. Enabling this with a SMP kernel BD> # will cause the kernel to be unusable. BD> You need a kernel with this option or compiled with "cpu I386_CPU". Thnx... Hmm... I need installer with special kernel... Is it possible without building full release? All my FreeBSD-equipped computers are production ones, so I could not try 5.0 on real hardware yet. And I don't have enough HDD space on my 4.x servers to hold CVS & build full 5.0-RELEASE only for custom kernel. Lev Serebryakov /---\ | FIDONet: 2:5030/661.0 | | E-Mail: [EMAIL PROTECTED] | | Page:http://lev.serebryakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Official request: Please make GNU grep the default
Hello, Gabor. You wrote 14 августа 2010 г., 20:10:56: > 2, GNU grep uses internal optimizations to get that performance. I think > it's a wrong approach because the regex library itself should be > optimized instead to keep BSD grep clean and simple and to provide the > same efficiency for all utilities that are linked to the regex library. > Our libc-regex is definitely need to be replaced at some point in the > future but that's a more complex item. See the following references: > http://wiki.freebsd.org/BSDgrep > http://wiki.freebsd.org/Regex You don't have these links on Wiki page, so I post them here. I hope, you've read these articles, but it is better to duplicate links, than miss them. http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/ And it iw very strange to see TRE s slow, because it seems, it is based on "fast" linear approcach, when gnu-regexp is old, slow, one... -- // Black Lion AKA Lev Serebryakov ___ 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: Interpreted language(s) in the base
Hello, Doug. You wrote 16 августа 2010 г., 10:15:55: > lua too "flavor of the day," not enough track record of stability, > not enough installed base/proven utility To be honest, lua is used in TONS of (commercial and, often, console) games as scripting engine, without any issues with stability or speed. Console games are very special world, where stability is holy cow, BTW. >> some JavaScript engines probably fit the description. > Yikes! Sorry I asked. :) Best scripting language ever :) Mixup of Lisp and Self, disguised to looks like "traditional" language. And, yes, I'm serious here. But JavaScript have one problem: both good open-source engines (SpiderMonkey and V8) don't have good "system" library for file/io/process operations. They are too-browser specific. They can be easily stipped down to bare engines (very small, very efficient), but in such case here is huge amount of work by writing all native objects and operations needed for system scripting. -- // Black Lion AKA Lev Serebryakov ___ 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: Parallelized scripting
Hello, Buganini. You wrote 27 сентября 2010 г., 05:51:11: > Hi, I just wrote a rough C program that may help to do parallelized > scripting, for example, parallelized rc.d scripts. > http://github.com/buganini/brackets > in this way it is easy to use, no need to escape argv for multiple times. > any comments are welcomed. Idea is interesting, but code... My, oh my, why do you use fixed-length arrays of arrays of pointers, on stack in 2010?! 4096 looks like very big number, but it is still finite, and could be exploitable. -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Hello, Lawrence. You wrote 19 июня 2010 г., 07:27:30: > Amount of feedback received thus far: nichts, nil, nada I wanted to help you, but here is one problem: I dont have any traffic-loaded 9-CURRENT machines. I have some not-so-critical 7.x and 8.x machines with noticeable traffic (for example, my torrent box still run 7-STABLE), but no 9-CURRENT except VMWare on my desktop :( I think, it is common case: 9-CURRENT machines are developers one, without noticeable amount of network traffic and all traffic-loaded machines run more stable versions. -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] ZFS v15 patch (version 3)
Hello, . You wrote 7 июля 2010 г., 22:25:20: > If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 > really doesn't give any major enhancements over 14 and FreeBSD 9 isn't > coming out any time. > 19 would give much need log device removal and triple parity RAID-Z. > Both of which are well tested at this point via OpenSolaris. Is here any ZFS history, in "date - pool version - new features" format? I understand, that it is more solaris-specific question, but I can not formulate request for Google to find out answer by myself :( -- // Black Lion AKA Lev Serebryakov ___ 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"
`make buildworld' failed
src/secure/lib/libssh/../../../crypto/openssh/version.c In file included from /usr/src/crypto/openssh/monitor_wrap.c:37: /usr/src/crypto/openssh/auth.h:116:17: krb.h: No such file or directory mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error freebsd# Lev Serebryakov /---\ | FIDONet: 2:5030/661.0 | | E-Mail: [EMAIL PROTECTED] | | Page:http://lev.serebryakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Regression: ALPHA3 can not properly init diskless / nanobsd system
Hello FreeBSD, I have NanoBSD system built from and it works. It creates THREE memory filesystems, as needed: % mount | grep /dev/md /dev/md0 on /etc (ufs, local) /dev/md1 on /var (ufs, local) /dev/md2 on /var/tmp (ufs, local) % But same system built from ALPHA3 sources (r338399 to be exact) doesn't create /etc in-memory overlay, and can not copy SSHD keys and create host.conf. After that sshd could not start. New version doesn't properly create overlay for /etc: % mount | grep /dev/md /dev/md1 on /var (ufs, local) /dev/md2 on /var/tmp (ufs, local) % All configuration files are the same. -- Best regards, Lev mailto:l...@freebsd.org ___ 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"
New loader (installed with ALPHA3) complains about missing modules but doesn't say what it needed
Hello FreeBSD, When I rebuilt NanoBSD image from CYRRENT r336582 to ALPHA3 r338399 loader starts to complain that it could not find required module(s). But I don't have any in my /boot/loader.conf and I didn't change anything in my configs. Unfortunately, loader doesn't provide any details: which modules are required. -- Best regards, Lev mailto:l...@freebsd.org ___ 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: Regression: ALPHA3 can not properly init diskless / nanobsd system (mdmfs or mknewfs or md is broken?)
Hello Lev, Saturday, September 1, 2018, 2:39:12 AM, you wrote: > I have NanoBSD system built from and it works. It creates THREE memory > filesystems, as needed: > % mount | grep /dev/md > /dev/md0 on /etc (ufs, local) > /dev/md1 on /var (ufs, local) > /dev/md2 on /var/tmp (ufs, local) > % > But same system built from ALPHA3 sources (r338399 to be exact) doesn't > create /etc in-memory overlay, and can not copy SSHD keys and create > host.conf. After that sshd could not start. > New version doesn't properly create overlay for /etc: > % mount | grep /dev/md > /dev/md1 on /var (ufs, local) > /dev/md2 on /var/tmp (ufs, local) > % I've get log from boot, but it is not very informative: arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache random: read_random_uio unblock wait random: read_random_uio unblock wait random: unblocking device. mdmfs: mount exited with error code 1 cp: /etc/periodic/monthly/999.local and /conf/base/etc/periodic/monthly/999.local are identical (not copied). It fails for first time, but works after that (for /tmp and /var). My kernel doesn't have TMPFS compiled in. -- Best regards, Levmailto:l...@freebsd.org ___ 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"
mdmfs fails for first time with md (Was: Regression: ALPHA3 can not properly init diskless / nanobsd system (mdmfs or mknewfs or md is broken?))
Hello Lev, Tuesday, September 4, 2018, 2:25:21 AM, you wrote: > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > random: read_random_uio unblock wait > random: read_random_uio unblock wait > random: unblocking device. > mdmfs: mount exited with error code 1 > cp: /etc/periodic/monthly/999.local and > /conf/base/etc/periodic/monthly/999.local are identical (not copied). > It fails for first time, but works after that (for /tmp and /var). > My kernel doesn't have TMPFS compiled in. Looks like it is hardware-depended. It works on Atom D2500-based system and 100% fails on Celeron J3160 based one. How could I debug this? -- Best regards, Levmailto:l...@freebsd.org ___ 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"
newfs silently fails if random is not ready (?)
Hello FreeBSD, I have problems with diskless install when kernel doesn't have tmpfs and random device takes long time to unlock. Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail to create FS. I've added '-XL' options to mdmfs and it looks like this: da0: quirks=0x2 arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache *** Figure out our NFS root path *** *** handle_remount /conf *** *** templates are base default *** *** handle_remount /conf/base/etc *** *** handle_remount /conf/base/var *** *** handle_remount /conf/default/etc *** *** handle_remount /conf/default/var *** *** create_md etc with size 20480 *** DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B DEBUG: running: /sbin/newfs -U /dev/md0 random: read_random_uio unblock wait random: read_random_uio unblock wait random: unblocking device. DEBUG: running: /sbin/mount /dev/md0 /etc mount: /dev/md0: No such file or directory mdmfs: mount exited with error code 1 "/dev/md0" is here, but it is empty, without any FS. I could run "/sbin/newfs -U /dev/md0" later by hands and it works. -- Best regards, Lev mailto:l...@freebsd.org ___ 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"
Celeron J3160 with enabled Turbo mode stays at 480MHz (lowest setting) forever and can not lower frequency without Tuebo mode
Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz even if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. -- Best regards, Lev mailto:l...@freebsd.org ___ 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: newfs silently fails if random is not ready (?)
Hello Conrad, Tuesday, September 4, 2018, 11:37:59 PM, you wrote: > Newfs just uses arc4random(3) to generate its FSID and generation > numbers. arc4random(3) is seeded from getentropy(3) -> getrandom(2) ->> read_random_uio(9), which is what produces the "random: > read_random_uio unblock wait" messages. > Is newfs tripping on a raise()/abort() in arc4random(3) / > getentropy(3)? Nope, it is silently does nothing > Is your program that runs newfs checking for non-zero > exit status? It is not "my" program, it is system mdmfs(8), and it checks exit statuses, as far as I can see from source code. > Do you see any newfs cores when this happens? It is very first step in diskless boot, so no cores are possible, but I don't see "core dumped" messages too. > Thanks, > Conrad > On Tue, Sep 4, 2018 at 1:08 PM, Lev Serebryakov wrote: >> Hello FreeBSD, >> >> I have problems with diskless install when kernel doesn't have tmpfs and >> random device takes long time to unlock. >> >> Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail >> to create FS. >> >> I've added '-XL' options to mdmfs and it looks like this: >> >> da0: quirks=0x2 >> arc4random: no preloaded entropy cache >> arc4random: no preloaded entropy cache >> *** Figure out our NFS root path *** >> *** handle_remount /conf *** >> *** templates are base default *** >> *** handle_remount /conf/base/etc *** >> *** handle_remount /conf/base/var *** >> *** handle_remount /conf/default/etc *** >> *** handle_remount /conf/default/var *** >> *** create_md etc with size 20480 *** >> DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B >> DEBUG: running: /sbin/newfs -U /dev/md0 >> random: read_random_uio unblock wait >> random: read_random_uio unblock wait >> random: unblocking device. >> DEBUG: running: /sbin/mount /dev/md0 /etc >> mount: /dev/md0: No such file or directory >> mdmfs: mount exited with error code 1 >> >> "/dev/md0" is here, but it is empty, without any FS. >> >> I could run "/sbin/newfs -U /dev/md0" later by hands and it works. >> >> -- >> Best regards, >> Lev mailto:l...@freebsd.org >> >> ___ >> freebsd...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" -- Best regards, Levmailto:l...@freebsd.org ___ 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"
sh(1) and more(1) hangs on serial terminal at [ttydcd] state.
Hello FreeBSD, When I use serial console (configured as console + "getty std.115200 xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever. If I hit ^T system shows that locked process is in "[ttydcd]" state. ^C kills locked process. What do I have misconfigured? -- Best regards, Lev mailto:l...@freebsd.org ___ 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: newfs silently fails if random is not ready (?)
Hello Conrad, Wednesday, September 5, 2018, 12:05:43 AM, you wrote: > On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov wrote: >> Tuesday, September 4, 2018, 11:37:59 PM, you wrote: >>> Is newfs tripping on a raise()/abort() in arc4random(3) / >>> getentropy(3)? >> Nope, it is silently does nothing > I think it is tripping on raise/abort() in one of these routines, but > nothing is printing that information. See below. Maybe, it should be fixed? One second after that random is ready to use and newfs works as intended. It is, really, some race between early init script (rc.initdiskless) and kernel. I don't think, that newfs must be killed/aborted in such situation, it could wait! >>> Is your program that runs newfs checking for non-zero >>> exit status? >> It is not "my" program, it is system mdmfs(8), and it checks exit >> statuses, as far as I can see from source code. > Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. > It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) > the same as programs that exit with success. This is a (major) > problem and the reason raise/abort is not visible. And it is another problem. But if it will be fixed, it doesn't help to init system properly in my case, only diagnostic will be better. -- Best regards, Levmailto:l...@freebsd.org ___ 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: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
Hello Cy, Wednesday, September 5, 2018, 3:12:34 AM, you wrote: > Are you running powers? powerd? yes. With "adaptive" strategy" > Do you use c-states? Oops. My fault. I've forgot to set cx_lowest to C3 on all cores. BTW, these four settings in rc.conf(5) performance_cx_lowest performance_cpu_freq economy_cx_lowest economy_cpu_freq do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! > What happens if you boot in (instead of switch to) turbo mode? Sorry? I could only turn Turbo mode on/off in BIOS before boot. BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but gives only 1601 Mhz, not 2240MHz max: TURBO ON: dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 TURBO OFF: dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 But I could live with that :-) -- Best regards, Levmailto:l...@freebsd.org ___ 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: newfs silently fails if random is not ready (?)
Hello Conrad,
Wednesday, September 5, 2018, 7:39:07 AM, you wrote:
> I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
> condition. This may be sufficient to fix the problem:
> --- a/sys/dev/random/randomdev.c
> +++ b/sys/dev/random/randomdev.c
> @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
> error = tsleep(&random_alg_context, PCATCH, "randseed",
> hz/10);
> if (error == ERESTART || error == EINTR)
> break;
> + /* Squash hz/10 timeout condition */
> + if (error == EWOULDBLOCK)
> + error = 0;
> + KASSERT(error == 0, ("unexpected %d", error));
> }
> if (error == 0) {
> read_rate_increment((uio->uio_resid +
> sizeof(uint32_t))/sizeof(uint32_t));
Fantastic! Thanks!
--
Best regards,
Levmailto:l...@freebsd.org
___
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: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
On 05.09.2018 15:53, Cy Schubert wrote: >> 1601 is not the actual frequency. That is just how it is reported. It >> is almost certainly running much higher than 1601. > > We don't know this until we can independently verify it. Do you mind > running some benchmarks with and without turbo mode? What could be adequate benchmarks for this? Something likje "openssl speed aes128-cbc" or I need more specific one? -- // Lev Serebryakov ___ 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: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 05.09.2018 17:51, Cy Schubert wrote: > I don't think you need something accurate. 1.6GHz and 2.48Ghz.. Maybe... I i'm trying now. > We don't know whether it is implemented through ACPI or similar to the > old turbo jumper on the MB, which increased the clock rate and sometimes > the voltage ( required to maintain stability when increasing the clock > rate). We don't know how your MB manufacturer implemented this. I thought, it could be implemented only in one? official, way, as it is Intel's official technology, and not MoBo's one. -- // Lev Serebryakov ___ 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: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 05.09.2018 17:51, Cy Schubert wrote: > I don't think you need something accurate. Ok, here is results. I'm working in single-user mode. TL;DR "Turbo" mode make "openssl" much slower (x3.5)! I can not properly interpret this result. But "turbostat" properly detect Turbo/No-Turbo mode, so it is not mistake in BIOS. (1) Trubo ENABLED, powerd IS NOT started dev.cpu.0.freq=480 no matter what. turbostat shows DIFFERENT speeds, like this (I've removed IRQ-related fields to fit in one line): Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - -- 2 0.30 135916006.18 0.00 93.52 31 0 00 2 0.36 863 16000.08 0.00 99.56 31 0 11 4 0.47 1462160024.56 0.00 74.96 31 1 02 2 0.22 167016000.05 0.00 99.72 29 1 13 2 0.14 179216000.02 0.00 99.84 29 "openssl speed aes-256-cbc": type16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 5653.98k 6159.49k 6356.31k17271.70k17517.23k (2) Trubo ENABLED, powerd IS started dev.cpu.0.freq shows different values, from 60 in idle to 1601 under load. turbostat shows same values, but at idle Bzy_MHz drops low. openssl is the same type16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 5580.78k 6155.97k 6349.23k17273.51k17511.77k (3) Trubo DISABLED, powerd IS NOT started dev.cpu.0.freq=1600 no matter what. turbostat shows higher numbers: Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - -- 2 0.21 180716001.44 0.00 98.35 38 0 00 3 0.28 176416000.06 0.00 99.66 38 0 11 3 0.24 205216001.72 0.00 98.03 38 1 02 1 0.09 162916000.02 0.00 99.89 36 1 13 2 0.22 166416003.94 0.00 95.84 36 "openssl speed aes-256-cbc": type16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 18939.95k20638.71k21281.24k57836.36k58736.39k (3.5 times faster that with Turbo ENABLED!) (4) Trubo DISABLED, powerd IS started dev.cpu.0.freq shows different values, from 60 in idle to 1600 under load. turbostat shows very low Bzy_MHz on idle, but high (suspiciously high) under load: Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - -- 147592.22 26661600 1.66 0.00 6.1241 0 00 147592.22 26661600 1.62 0.00 6.1641 0 11 147592.21 26661600 1.41 0.00 6.3841 1 02 147592.21 26661600 1.78 0.00 6.0138 1 13 147692.24 26661600 1.84 0.00 5.9238 openssl is almost the same type16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 16277.18k20620.71k21272.10k57998.35k58687.83k -- // Lev Serebryakov ___ 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: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
Hello Benjamin, Thursday, September 6, 2018, 1:32:46 AM, you wrote: >> > I don't think you need something accurate. >> Ok, here is results. I'm working in single-user mode. >> >> TL;DR "Turbo" mode make "openssl" much slower (x3.5)! >> >> I can not properly interpret this result. > You need to say more about what openssl is doing (i.e., how it was > configured, what architecture it's on, etc.). In particular, there > was for a time an AVX2 implementation for some primitives, that ended up > being a net loss, since heavy use of those instructions would cause > overheating and throttling. OpenSSL has a lot of custom assembly for these > common primitves, with some logic to select among them both at > configuration time and at runtime, so results such as this may or may not > be widely transferrable. It is system (very fresh ALPHA4) openssl, built with default settings. Simple single run with one thread, without AES-NI: openssl speed aes-256-cbc It is as simple as that. -- Best regards, Levmailto:l...@freebsd.org ___ 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: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 06.09.2018 4:15, Benjamin Kaduk wrote: > Okay, "system openssl" and the FreeBSD version is enough to nail down the > code and configuration, and I see the processor type is in the subject > line. I guess posting the CPU features bits from dmesg might save whoever > tries to track down the codepaths being used some time (unless that was > posted already and I missed it?). I'll post it tonight, but I don't think it is very openssl-specific or thermal throttling. I've monitored temperatures, of course, and monitored frequencies with turbostat. With Turbo enabled freuqnces jumps wildly and were lower than with Turbo disabled. And anyway, even frequencies jumps were not large enough to explain x3.5 difference. Another thing which puzzles me, that with Turbo disabled (!) I see frequencies 2666MHz accroding to turbostat, which seems impossible, as it is higher than official Turbo frequency (!). I don't know how to explain this. Maybe, turbostat fails? -- // Lev Serebryakov ___ 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: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 06.09.2018 4:15, Benjamin Kaduk wrote: > Okay, "system openssl" and the FreeBSD version is enough to nail down the > code and configuration, and I see the processor type is in the subject > line. I guess posting the CPU features bits from dmesg might save whoever > tries to track down the codepaths being used some time (unless that was > posted already and I missed it?). CPU: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (1600.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406c4 Family=0x6 Model=0x4c Stepping=4 Features=0xbfebfbff Features2=0x43d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics And here are two outputs of turbostat with additional settings: turbostat, Turbo DISABLED: CPUID(0): GenuineIntel 11 CPUID levels; family:model:stepping 0x6:4c:4 (6:76:4) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM CPUID(6): APERF, No-TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, EPB cpu3: MSR_IA32_MISC_ENABLE: 0x4000850089 (TCC EIST No-MWAIT PREFETCH No-TURBO) CPUID(7): No-SGX cpu3: MSR_PLATFORM_INFO: 0x60002001400 6 * 133.3 = 800.0 MHz max efficiency frequency 20 * 133.3 = 2666.6 MHz base frequency cpu3: MSR_IA32_POWER_CTL: 0x (C1E auto-promotion: DISabled) cpu3: MSR_TURBO_RATIO_LIMIT: 0x cpu3: MSR_PKG_CST_CONFIG_CONTROL: 0x0014000f (UNlocked: pkg-cstate-limit=15: unknown) NSFOD /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu2: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) turbostat, Turbo ENABLED: CPUID(0): GenuineIntel 11 CPUID levels; family:model:stepping 0x6:4c:4 (6:76:4) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM CPUID(6): APERF, TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, EPB cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT PREFETCH TURBO) CPUID(7): No-SGX cpu1: MSR_PLATFORM_INFO: 0x60002001400 6 * 133.3 = 800.0 MHz max efficiency frequency 20 * 133.3 = 2666.6 MHz base frequency cpu1: MSR_IA32_POWER_CTL: 0x (C1E auto-promotion: DISabled) cpu1: MSR_TURBO_RATIO_LIMIT: 0x cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x0014000f (UNlocked: pkg-cstate-limit=15: unknown) NSFOD /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu2: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) -- // Lev Serebryakov ___ 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"
Speed problems with both system openssl and security/openssl-devel
Hello Brnrd, I'm benchmarking new hardware (rather limited one, but still) which supports AES-NI (Celeron J3160). I'm comparing simple "openssl speed aes-256-cbc" and "openssl speed -evp aes-256-cbc" on FreeBSD 12-ALPHA4 (built by myself with all debug options turned off) and Debian Linux 9.5.0 booted from install DVD (without installation). Simple "openssl speed aes-256-cbc" shows same numbers both in single-threaded and multi-threaded mode (for all 4 cores). Linux is marginally faster, but it is in the margin of measurement error. But "openssl speed -evp aes-256-cbc" gives me very disappointing results. FreeBSD's openssl is WAY slower than Linux one. It is even slower than non-evp mode for small blocks. Here are results (As reported by openssl, with fractions dropped): Lin 1894220637 21300 57967 58769 58769 Free 1893120591 21282 58342 58731 58779 Lin-evp 97049 151466 183905 194385 197514 197727 Free-evp 283810845 35362 81892 131264 137579 Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl (1.0.2p) and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), results are virtually the same. I have "ASM" and "SSE2" options enabled in port. What happens here? Why does FreeBSD's build of openssl use AES-NI so inefficient? -- Best regards, Lev mailto:l...@freebsd.org ___ 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
Hello Kevin, Thursday, September 13, 2018, 6:32:30 AM, you wrote: > This is probably not the issue, but aesni is not in the GENERIC kernel. Are > you sure aesni.ko is loaded? > % kldstat | grep aesni I'm not using modules, as it is NanoBSD image build for minimal size ant maximal efficiency. But I have aesni in my kernel config for sure: % grep aesni ~/nanobsd/gatevay.v3/J3160 device aesni % -- Best regards, Levmailto:l...@freebsd.org ___ 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
Hello Dimitry, Thursday, September 13, 2018, 11:52:08 AM, you wrote: > I can't reproduce your findings, at least not on a Core i7-4790K: I can not reproduce it on E3-1220v3 + 11-STABLE either. But security/openssl111 works as expected on J3160 and it bothers me. Something is wrong not with hardware, but with software here. -- Best regards, Levmailto:l...@freebsd.org ___ 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
Hello Dimitry, Thursday, September 13, 2018, 11:52:08 AM, you wrote: > I can't reproduce your findings, at least not on a Core i7-4790K: > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > FreeBSD 93454 89077 117328 281016 285456 > Ubuntu 93405 88892 114192 122346 120266 > FreeBSD-evp633283688010 700775 701168 700669 > Ubuntu-evp 623889681075 697211 700505 698460 > That was with base openssl 1.0.2p on FreeBSD 12-ALPHA5, and 1.1.0g on > Ubuntu 18.04. Here are additional numbers on J3160, with security/openssl111 port added: Lin 1.1.0f 18942 20637 21300 57967 58769 58769 Free 1.0.2p 18938 20627 21243 57940 58785 Free 1.1.0i 18929 20593 21285 58287 58766 58751 Free 1.1.1 18936 20588 21266 57923 58690 58731 Lin-evp 1.1.0f 97049 151466 183905 194385 197514 197727 Free-evp 1.0.2p 2828 10665 35364 81836 130502 Free-evp 1.1.0i 2869 10813 34932 81292 131308 137376 Free-evp 1.1.1 96959 151359 183390 194431 197076 197686 I've checked poudriere logs, all ports are built with -DAES_ASM. -- Best regards, Levmailto:l...@freebsd.org ___ 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
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 ___ 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 17.09.2018 10:40, Daniel Nebdal wrote: > Could it be relevant that the Debian binary was probably compiled with > gcc, and the FreeBSD binary with clang? Maybe. Now I'm trying to trace codepath of "openssl speed -evp aes-256-cbc" on FreeBSD to understand where and why it refuses to use AES. No much luck, though, openssl sources are very convoluted :-( > 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.) -- // Lev Serebryakov ___ 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"
vtnet + gif (IPv4 in IPv4) + iperf3 leads to crash on ALPHA6
I'm preparing some benchmarking setup, which includes gif tunnel from FreeBSD to FreeBSD, where one end is 12.0-ALPHA6/r338707 installed as guest in VirtualBox with virtual NIC (vtnet). This tunnel works for simple pings, but when I run iperf3 on this "link" ALPHA4 system crashes. It is 100% reproducible for me. panic: Assertion !in_epoch(net_epoch_preempt) && !mtx_owned(&(&(tcbinfo))->ipi_lock) failed at /data/src/sys/netinet/tcp_input.c:803 cpuid = 0 time = 1537187018 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe44a310 vpanic() at vpanic+0x1a3/frame 0xfe44a370 panic() at panic+0x43/frame 0xfe44a3d0 tcp_input() at tcp_input+0x16a9/frame 0xfe44a520 ip_input() at ip_input+0x126/frame 0xfe44a5a0 netisr_dispatch_src() at netisr_dispatch_src+0x83/frame 0xfe44a600 gif_input() at gif_input+0x2db/frame 0xfe44a640 in_gif_input() at in_gif_input+0x73/frame 0xfe44a680 encap_input() at encap_input+0x1cf/frame 0xfe44a6f0 encap4_input() at encap4_input+0x28/frame 0xfe44a720 ip_input() at ip_input+0x126/frame 0xfe44a7a0 netisr_dispatch_src() at netisr_dispatch_src+0x83/frame 0xfe44a800 ether_demux() at ether_demux+0x15e/frame 0xfe44a830 ether_nh_input() at ether_nh_input+0x373/frame 0xfe44a880 netisr_dispatch_src() at netisr_dispatch_src+0x83/frame 0xfe44a8e0 ether_input() at ether_input+0x42/frame 0xfe44a900 vtnet_rxq_eof() at vtnet_rxq_eof+0x736/frame 0xfe44a9a0 vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x58/frame 0xfe44a9d0 vtpci_legacy_intr() at vtpci_legacy_intr+0xb0/frame 0xfe44aa10 ithread_loop() at ithread_loop+0x140/frame 0xfe44aa70 fork_exit() at fork_exit+0x84/frame 0xfe44aab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe44aab0 -- // Lev Serebryakov ___ 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
Hello Lev, Thursday, September 13, 2018, 2:46:46 AM, you wrote: > Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl > (1.0.2p) > and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), results > are > virtually the same. I have "ASM" and "SSE2" options enabled in port. > What happens here? Why does FreeBSD's build of openssl use AES-NI so > inefficient? More datapoints. (1) aes-256-cbc behaves really wired. Time output is completely bogus without "-elapsed" and speed is unbelievably low with "-elapsed". aes-256-gcm doesn't have this anomaly without "-elapsed" (please note "in 0.xxs" here): Doing aes-256-cbc for 3s on 16 size blocks: 503555 aes-256-cbc's in 0.60s Doing aes-256-cbc for 3s on 64 size blocks: 520386 aes-256-cbc's in 0.54s Doing aes-256-cbc for 3s on 256 size blocks: 435106 aes-256-cbc's in 0.44s Doing aes-256-cbc for 3s on 1024 size blocks: 242832 aes-256-cbc's in 0.38s Doing aes-256-cbc for 3s on 8192 size blocks: 49087 aes-256-cbc's in 0.09s ... aes-256-cbc 13393.26k61782.64k 254599.17k 663093.25k 4289287.51k Doing aes-256-gcm for 3s on 16 size blocks: 12051311 aes-256-gcm's in 3.03s Doing aes-256-gcm for 3s on 64 size blocks: 6428598 aes-256-gcm's in 3.04s Doing aes-256-gcm for 3s on 256 size blocks: 2122316 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 1024 size blocks: 610443 aes-256-gcm's in 3.13s Doing aes-256-gcm for 3s on 8192 size blocks: 75836 aes-256-gcm's in 3.03s ... aes-256-gcm 63611.04k 135380.66k 181104.30k 199531.13k 204947.96k with "-elapsed": Doing aes-256-cbc for 3s on 16 size blocks: 493829 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 64 size blocks: 530550 aes-256-cbc's in 3.06s Doing aes-256-cbc for 3s on 256 size blocks: 426699 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 1024 size blocks: 243305 aes-256-cbc's in 3.03s Doing aes-256-cbc for 3s on 8192 size blocks: 48069 aes-256-cbc's in 3.01s ... aes-256-cbc 2626.91k11087.41k36317.07k82191.94k 130919.48k Doing aes-256-gcm for 3s on 16 size blocks: 12041385 aes-256-gcm's in 3.08s Doing aes-256-gcm for 3s on 64 size blocks: 6445757 aes-256-gcm's in 3.05s Doing aes-256-gcm for 3s on 256 size blocks: 2129499 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 1024 size blocks: 587396 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 75806 aes-256-gcm's in 3.03s ... aes-256-gcm 62590.75k 135047.68k 181245.26k 199977.06k 204866.89k (2) I've added debug output to 'crypto/evp/e_aes.c' and it shows, that AES-NIU should be used. (3) openssl111 from ports doesn't show these problems. -- Best regards, Levmailto:l...@freebsd.org ___ 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"
IPsec on ALPHA7 — reproducible crash
I have reproducible crash of ALPHA7 when I try to benchmark IPsec. Could somebody look at it? I could provide additional info, if needed. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659 -- // Lev Serebryakov ___ 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"
loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)
On 22.10.2018 12:27, Toomas Soome wrote: > It would help to get output from loader lsdev -v command. current loader crashes on "lsdev" for me: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not threadripper-related, my hardware is Intel Atom). -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
current kernel built without TCO (-fno-optimize-sibling-calls) is almost unusable
I've built 13/current kernel with "-fno-optimize-sibling-calls" option to have full and true stacks. And my test stand (which is lousy Atom D2500, I need to admit) becomes unusable with such kernel. Here are NO any errors or message on console, but system drops ssh connection after several seconds (soemtimes before logon, sometimes right after showing shell), timeouts connections to it, etc. When I able to run "top -SH" (for several seconds!) it shows 98% idle! -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
current kernel built without TCO (-fno-optimize-sibling-calls) is almost unusable
On 23.10.2018 17:21, Lev Serebryakov wrote: > Here are NO any errors or message on console, but system drops ssh > connection after several seconds (soemtimes before logon, sometimes > right after showing shell), timeouts connections to it, etc. > > When I able to run "top -SH" (for several seconds!) it shows 98% idle! It is as simple as this: it crashes and reboots each 1-2 minutes... -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Solved (Was: current kernel built without TCO (-fno-optimize-sibling-calls) is almost unusable)
On 23.10.2018 17:25, Lev Serebryakov wrote: >> Here are NO any errors or message on console, but system drops ssh >> connection after several seconds (soemtimes before logon, sometimes >> right after showing shell), timeouts connections to it, etc. >> >> When I able to run "top -SH" (for several seconds!) it shows 98% idle! > It is as simple as this: it crashes and reboots each 1-2 minutes... Stack overflow. I've increased kernel stack size and now it works (slowly). -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
netmap on cxgb (Chelsio T3) — panic on transmit
I've obtained Chelsio T3 for my "network lab". It works with cxgb driver well, but when I try to use Netmap's pkt-gen on it it crashes system immediately with such message: panic: trying to coalesce 9 packets in to one WR I've turned all checksums, lro and tso off, but it doesn't help. Do I have any chances to get netmap supported (maybe, not very efficient) on this NIC? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: gpart: param 'skip_dsn': Invalid argument (13-CURRENT/amd64)
Hello Ronald, Saturday, December 1, 2018, 6:47:45 PM, you wrote: > I got this response after gpart bootcode. > Should I be worried? > [AFTER make installkernel && make installworld] > -- Installing everything completed on Sat Dec 1 15:43:19 CET 2018 > -- > [root@sjakie /data/src/freebsd-current]# gpart bootcode -b /boot/pmbr -p > /boot/gptzfsboot -i 1 ada0 > partcode written to ada0p1 > gpart: param 'skip_dsn': Invalid argument You need new geom_part.ko or old userland part. There was change which make new gpart userland utility incompatible with old kernel module. It is why source upgrade procedure "officialy" requires reboot after install kernel and before installworld. You could repeat re-installation of "gpart bootkode -b /boot/pmbr" after reboot. Now your bootcode (pmbr) has not been upgraded. I don't think it will cause a problem, as last changes to it was made long time ago :-) -- Best regards, Levmailto:l...@freebsd.org ___ 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"
iflib.tx_abdicate: very strange behavior on incoming IPsec traffic (regression?)
(I'm not sure, that it is exactly "bug" or "defect" and want to I've found very strange behavior of 13-CURRENT system I210 (igb) interfaces and enabled "dev.igb.X.iflib.tx_abdicate". I'm measuring "router" performance with BSDRP's "equilibrium" script (thank you, Oliver, for this great tool!). It generates traffic to route with pkt-gen and try to find packet rate / bandwidth with binary search. I'm testing simple UDP traffic via physical connection, without any GIF/GRE and other pseudo-interfaces. Router pass UDP traffic from igb1 to igb0, and this traffic is for ONLY ONE IP:PORT pair, as I'm imitating edge router for small network where only one host will receive huge amounts of traffic (i.e. torrent-box). When I enable "dev.igb.X.iflib.tx_abdicate" on both igb1 (inbound) and igb0 (outbound) interface, packet per second become a little better. So far so good. Now I'm throwing IPsec into mix. All incoming traffic is tunneled with IPsec policy, with aes-128-gcm encryption. And with IPsec tx_abdicate makes thing much worse and much more unstable. There is results without tx_abdicate: 480Mbit/s, 182Kpps And it is results with tx_abdicate: 352MBit/s, 85Kpps. And what is worse, "equilibrium" script starts to see unstable packet rate. Without tx_abdicate or without IPsec process of searching for "maximum" packet rate is very stable: each next measurement in binary search looks like previous, there is no big jumps and found "equilibrium" rate is very close to "maximum seen", and overloaded router shows rate smaller than equilibrium one). But with both "tx_abdicate" and IPsec it looks like (please, note, that overloaded router shows much better rate than not-overloaded): Benchmark tool using equilibrium throughput method - Benchmark mode: Throughput (pps) for Router - UDP load = 18B, IPv4 packet size=46B, Ethernet frame size=60B - Link rate = 1488 Kpps - Tolerance = 0.01 Iteration 1 - Offering load = 744 Kpps - Step = 372 Kpps - Measured forwarding rate = 120 Kpps - Forwared rate too low, forcing OLOAD=FWRATE and STEP=FWRATE/2 Iteration 2 - Offering load = 120 Kpps - Step = 60 Kpps - Trend = decreasing - Measured forwarding rate = 81 Kpps Iteration 3 - Offering load = 60 Kpps - Step = 60 Kpps - Trend = decreasing - Measured forwarding rate = 60 Kpps Iteration 4 - Offering load = 90 Kpps - Step = 30 Kpps - Trend = increasing - Measured forwarding rate = 84 Kpps Iteration 5 - Offering load = 75 Kpps - Step = 15 Kpps - Trend = decreasing - Measured forwarding rate = 75 Kpps Iteration 6 - Offering load = 82 Kpps - Step = 7 Kpps - Trend = increasing - Measured forwarding rate = 81 Kpps Iteration 7 - Offering load = 85 Kpps - Step = 3 Kpps - Trend = increasing - Measured forwarding rate = 85 Kpps Iteration 8 - Offering load = 86 Kpps - Step = 1 Kpps - Trend = increasing - Measured forwarding rate = 86 Kpps Estimated Equilibrium Ethernet throughput= 86 Kpps (maximum value seen: 120 Kpps) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: iflib.tx_abdicate: very strange behavior on incoming IPsec traffic (regression?)
On 07.12.2018 16:40, Lev Serebryakov wrote: > (I'm not sure, that it is exactly "bug" or "defect" and want to ... discuss it here before filing PR. > Now I'm throwing IPsec into mix. All incoming traffic is tunneled with > IPsec policy, with aes-128-gcm encryption. And with IPsec tx_abdicate > makes thing much worse and much more unstable. I could say, that it doesn't matter, if I using IPsec with "tunnel" policy to encrypt and tunnel transit traffic or if I add "gif" into mix and encrypt GIF traffic in "transport" mode. In both cases tx_abdicate makes PPS much lower. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: iflib.tx_abdicate: very strange behavior on incoming IPsec traffic (regression?)
On 07.12.2018 18:02, Lev Serebryakov wrote: >> (I'm not sure, that it is exactly "bug" or "defect" and want to > ... discuss it here before filing PR. > >> Now I'm throwing IPsec into mix. All incoming traffic is tunneled with >> IPsec policy, with aes-128-gcm encryption. And with IPsec tx_abdicate >> makes thing much worse and much more unstable. > I could say, that it doesn't matter, if I using IPsec with "tunnel" > policy to encrypt and tunnel transit traffic or if I add "gif" into mix > and encrypt GIF traffic in "transport" mode. In both cases tx_abdicate > makes PPS much lower. And one more datapoint: if I'm using "null" cipher (so, IPsec is in play, but no real encryption is performed) losses in packet rate are about 50% from turning on tx_abdicate. It is worst-case scenario. And if I have outbound traffic (traffic is received without IPsec processing and sent with IPsec processing on other interface) I have noticeable gains, up to 15% in packets per second and bandwidth. So, lookslike tx_abdicate works well when it is applied to non-IPsec-processed traffic. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
Hello Freebsd-hackers,
I'm experiencing very strange situation on my lab system which is
E3-1220v2, 8GiB of RAM and 850 EVO SATA SSD (with single ZFS pool).
It runs CURRENT r341157. Kernel is built *without* INVARIANTS and other
heavy debug aids.
Everything works great — but compilation. "make -j *1* buildkernel" takes
forever and each compiler invocation takes up to 10 seconds. For example,
I've clocked compilation of sys/dev/aic7xxx/aic7xxx_93cx6.c by stopwatch and
it takes 9 seconds. Please note, it is SINGLE JOB build. If I run "make
-j4" it will be much longer for each compiler out of 4. And all this time
"cc" / "c++" consume 100% of CPU.
Even when build is single-job, system becomes unresponsive. With
4-job build running it could takes up to minute to switch screen's windows!
Another strange thing I noticed: when system is in such state, "top -SH"
shows that sometimes very low-profile processes, like clock software
interrupt (!) could consume large amount of CPU for short periods time. When
system is idle there never will be "intr{swi4: clock (0)}" consuming 55% CPU
for one "frame" or sshd, or screen itself.
I'm completely lost. Is it problem of software? Hardware? If it is
hardware problem what should I blame?
I've checked all "standard" places — CPU is not throttling, SSD looks
perfectly Ok according to SMART and there is no complains from AHCI driver
about timeouts and such, system doesn't start to use swap.
--
Best regards,
Lev mailto:l...@freebsd.org
___
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: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
Hello Lev, Saturday, December 8, 2018, 2:13:03 PM, you wrote: > I've checked all "standard" places — CPU is not throttling, SSD looks > perfectly Ok according to SMART and there is no complains from AHCI driver > about timeouts and such, system doesn't start to use swap. ZFS ARC was checked too. Here is statistics from top when single-job kernel build is in action. A lot of free memory, small ARC, too much CPU is consumed by interrupts, but there is free CPU clocks: last pid: 19488; load averages: 7.03, 5.35, 5.10 up 0+14:43:04 15:09:55 417 threads: 7 running, 395 sleeping, 15 waiting CPU 0: 50.0% user, 0.0% nice, 0.0% system, 16.4% interrupt, 33.6% idle CPU 1: 16.4% user, 0.0% nice, 16.8% system, 0.0% interrupt, 66.8% idle CPU 2: 0.0% user, 0.0% nice, 33.2% system, 0.0% interrupt, 66.8% idle CPU 3: 33.2% user, 0.0% nice, 33.2% system, 0.0% interrupt, 33.6% idle Mem: 28M Active, 315M Inact, 2076K Laundry, 2541M Wired, 1129K Buf, 5031M Free ARC: 1025M Total, 197M MFU, 415M MRU, 514K Anon, 20M Header, 392M Other 189M Compressed, 563M Uncompressed, 2.98:1 Ratio Swap: 16G Total, 16G Free -- Best regards, Levmailto:l...@freebsd.org ___ 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: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> Another strange thing I noticed: when system is in such state, "top -SH"
> shows that sometimes very low-profile processes, like clock software
> interrupt (!) could consume large amount of CPU for short periods time. When
> system is idle there never will be "intr{swi4: clock (0)}" consuming 55% CPU
> for one "frame" or sshd, or screen itself.
Like this. This system doesn't have any significant network traffic now —
only one ssh connection, which is used as console. And 62.3% for network
card. WTF?!
PID USERNAMEPRI NICE SIZERES STATEC TIMEWCPU COMMAND
20128 root1010 104M74M CPU1 1 0:31 100.00% cc
0 root-76- 0 4608K -2 53:25 62.23%
kernel{if_config_tqg_0}
11 root-60- 0 240K WAIT 0 25:45 24.89% intr{swi4:
clock (0)}
9 root -8- 0 160K tx->tx 0 7:38 24.88%
zfskern{txg_thread_enter}
995 root 24017M 7676K select 1 2:20 12.44% sendmail
13791 root 24024M15M select 0 0:04 12.44% make
--
Best regards,
Levmailto:l...@freebsd.org
___
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: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
Hello Lev, Saturday, December 8, 2018, 2:13:03 PM, you wrote: > Even when build is single-job, system becomes unresponsive. With > 4-job build running it could takes up to minute to switch screen's windows! And even with 1-job kernel build upsmon's connection to remote upsd flickers! Unbelievable. Looks like each next compiler invocation is slower and more stressful than previous one. -- Best regards, Levmailto:l...@freebsd.org ___ 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: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
Hello Eugene, Saturday, December 8, 2018, 4:27:13 PM, you wrote: >> I'm completely lost. Is it problem of software? Hardware? If it is >> hardware problem what should I blame? > Try using different kern.timecounter.hardware and/or kern.eventtimer.timer > but first try kern.eventtimer.periodic=1 instead of default 0. Nothing helps. I've tried periodic=1 and replace hardware and time with HPT (from TSC-Low and LAPIC), but system still "sticky" with single-job build and unresposnive with multiple-job build, and still there is strange bursts of CPU consumption from threads and processes which should be low-profile. > If something of this helps, try going back to defaults and then disable > power-saving settings, if any. I'll try to disable C2/C3 and turn off Turbo as next step... -- Best regards, Levmailto:l...@freebsd.org ___ 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: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
Hello Mateusz, Saturday, December 8, 2018, 5:27:42 PM, you wrote: >> Looks like each next compiler invocation is slower and more stressful than >> previous one. > Is this a fresh install? Almost fresh. It was installed from some rather fresh 13 snapshot and then upgraded to r341157 and custom kernel via source update. Now I'm trying to update it second time without luck. First upgrade was not so painful, as far as I can remember :-) > Can you please narrow the problem down to a specific kernel revision? I'm still not sure it is software or hardware problem. > Most importantly, does this show up with a 12.0 kernel? I didn't tried 12 kernel on this hardware. > I'm running one amd box and a number of intel boxes with various cpus, > no issues. Me too, but this is only one box which have 13 and try to compile something, all other boxes are either 11/12 or are small NanoBSD installations without toolchain... -- Best regards, Levmailto:l...@freebsd.org ___ 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"
ZFS sends TIRMs to agressively? (Was: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system)
Hello Lev, Saturday, December 8, 2018, 7:58:37 PM, you wrote: >> Can you please narrow the problem down to a specific kernel revision? > I'm still not sure it is software or hardware problem. Looks like Samsung 850 EVO doesn't like TRIMs sent by ZFS (and I've thought it is good SSD, consumer-grade, but really good one!). I've tuned down TRIMs with vfs.zfs.per_txg_dirty_frees_percent=10 vfs.zfs.free_max_blocks=1000 vfs.zfs.vdev.trim_max_active=4 And it MOSTLY solved problem: there are some freezing from time to time (and strange consumption of CPU by low-profile threads) with these settings. When I've disabled TRIM completely all freezes are gone, and low-profile threads consume tenths of percent of CPU, as it is intended. -- Best regards, Levmailto:l...@freebsd.org ___ 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"
r111 build error
Hello Freebsd-current, I'm building very last r341836 (with new llvm/clang 7) on r341726 and get this build error (with MALLOC_PRODUCTION=yes): ===> usr.bin/clang/clang (all) c++ -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitia lizeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -static -o clang.full cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a -lz -lncursesw -lpthread ld: error: undefined symbol: clang::LocationContext::getCurrentStackFrame() const >>> referenced by ExplodedGraph.h:138 >>> (/usr/src/contrib/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h:138) >>> ReturnUndefChecker.o:(void >>> clang::ento::check::PreStmt::_checkStmt<(anonymous >>> namespace)::ReturnUndefChecker>(void*, clang::Stmt const*, >>> clang::ento::CheckerContext&)) in archive >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::CallExpr::getLocStart() const >>> referenced by MacOSXAPIChecker.cpp:86 >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86) >>> MacOSXAPIChecker.o:((anonymous >>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&, >>> clang::CallExpr const*, llvm::StringRef) const) in archive >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::Stmt::getLocStart() const >>> referenced by DeadStoresChecker.cpp:265 >>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp:265) >>> DeadStoresChecker.o:((anonymous >>> namespace)::DeadStoreObs::observeStmt(clang::Stmt const*, clang::CFGBlock >>> const*, clang::LiveVariables::LivenessValues const&)) in archive >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::CodeSegAttr::clone(clang::ASTContext&) const >>> referenced by SemaDecl.cpp:0 >>> (/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp:0) >>> >>> SemaDecl.o:(clang::Sema::getImplicitCodeSegOrSectionAttrForFunction(clang::FunctionDecl >>> const*, bool)) in archive >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::ArtificialAttr::clone(clang::ASTContext&) const >>> referenced by AttrTemplateInstantiate.inc:150 >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:150) >>> >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr >>> const*, clang::ASTContext&, clang::Sema&, >>> clang::MultiLevelTemplateArgumentList const&)) in archive >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::CPUDispatchAttr::clone(clang::ASTContext&) const >>> referenced by AttrTemplateInstantiate.inc:243 >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:243) >>> >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr >>> const*, clang::ASTContext&, clang::Sema&, >>> clang::MultiLevelTemplateArgumentList const&)) in archive >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::CodeSegAttr::clone(clang::ASTContext&) const >>> referenced by AttrTemplateInstantiate.inc:303 >>> (/usr/obj/us
Re: r341836 build error
Hello Lev, Wednesday, December 12, 2018, 2:11:10 AM, you wrote: Sorry for messed up subject, I mean r341836 of course. -- Best regards, Levmailto:l...@freebsd.org ___ 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: r111 build error
On 12.12.2018 14:59, Dimitry Andric wrote: >>>> ld: error: undefined symbol: clang::CallExpr::getLocStart() const >>>>>>> referenced by MacOSXAPIChecker.cpp:86 >>>>>>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86) >>>>>>> MacOSXAPIChecker.o:((anonymous >>>>>>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&, >>>>>>> clang::CallExpr const*, llvm::StringRef) const) in >>>>>>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a > > Any ideas on how to reproduce this build failure? I have run multiple > universe builds before committing this update, and I never saw any error > which resembles the above. rm -rf /usr/obj/src helps to get rid of this error. I've had /usr/obj from previous version (but I didn't use -DNO_CLEAN!). > It almost looks as if your libclang.a is not rebuilt properly, or not > built at all. Can you show the time stamps of: I can not, as I cleaned up /usr/obj/src and now I have clean build. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
r343111 breaks build
I can not build CURRENT r343111 on r343022 world. Looks like r343111 itself cause problems (r343110 builds): In file included from /data/src/contrib/libc++/src/algorithm.cpp:11: In file included from /data/src/contrib/libc++/include/random:1646: In file included from /data/src/contrib/libc++/include/istream:163: In file included from /data/src/contrib/libc++/include/ostream:138: In file included from /data/src/contrib/libc++/include/ios:216: In file included from /data/src/contrib/libc++/include/__locale:18: In file included from /data/src/contrib/libc++/include/mutex:191: In file included from /data/src/contrib/libc++/include/__mutex_base:16: In file included from /data/src/contrib/libc++/include/system_error:146: In file included from /data/src/contrib/libc++/include/__errc:106: In file included from /data/src/contrib/libc++/include/cerrno:27: /data/src/contrib/libc++/include/errno.h:70:2: error: unterminated conditional directive #ifdef ELAST ^ /data/src/contrib/libc++/include/errno.h:63:2: error: unterminated conditional directive #ifdef ELAST ^ /data/src/contrib/libc++/include/errno.h:56:2: error: unterminated conditional directive #ifdef ELAST ^ /data/src/contrib/libc++/include/errno.h:52:2: error: unterminated conditional directive #if !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) ^ /data/src/contrib/libc++/include/errno.h:36:2: error: unterminated conditional directive #if !defined(EOWNERDEAD) || !defined(ENOTRECOVERABLE) || !defined(EINTEGRITY) ^ /data/src/contrib/libc++/include/errno.h:34:2: error: unterminated conditional directive #ifdef __cplusplus ^ /data/src/contrib/libc++/include/errno.h:11:2: error: unterminated conditional directive #ifndef _LIBCPP_ERRNO_H ^ In file included from /data/src/contrib/libc++/src/algorithm.cpp:11: In file included from /data/src/contrib/libc++/include/random:1646: In file included from /data/src/contrib/libc++/include/istream:163: In file included from /data/src/contrib/libc++/include/ostream:138: In file included from /data/src/contrib/libc++/include/ios:216: In file included from /data/src/contrib/libc++/include/__locale:18: In file included from /data/src/contrib/libc++/include/mutex:191: In file included from /data/src/contrib/libc++/include/__mutex_base:17: In file included from /data/src/contrib/libc++/include/__threading_support:16: /data/src/contrib/libc++/include/errno.h:70:2: error: unterminated conditional directive #ifdef ELAST ^ /data/src/contrib/libc++/include/errno.h:63:2: error: unterminated conditional directive #ifdef ELAST ^ /data/src/contrib/libc++/include/errno.h:56:2: error: unterminated conditional directive #ifdef ELAST ^ /data/src/contrib/libc++/include/errno.h:52:2: error: unterminated conditional directive #if !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) ^ /data/src/contrib/libc++/include/errno.h:36:2: error: unterminated conditional directive #if !defined(EOWNERDEAD) || !defined(ENOTRECOVERABLE) || !defined(EINTEGRITY) ^ /data/src/contrib/libc++/include/errno.h:34:2: error: unterminated conditional directive #ifdef __cplusplus ^ /data/src/contrib/libc++/include/errno.h:11:2: error: unterminated conditional directive #ifndef _LIBCPP_ERRNO_H ^ -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 5:31, Rebecca Cran wrote: > I was wondering if people will expect /boot.config to still be read and so > code should be added to loader to continue to parse it, or if loader.conf can > be considered the correct place and boot.config forgotten about? Please, not, please support /boot.config. loader.conf could be too late in case of serial consoles. I wonder, why EFI/UEFI and GPt booting (which should be more advanced) is more limited than classic MBR/boot0 + boot1 + loader scheme :-( Serial console support is worse. Selection of boot partition is not supported (as opposide to very-simple-516-bytes boot0!), and so on :-( -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 17:03, Olivier Cochard-Labbé wrote: > > I was wondering if people will expect /boot.config to still be > read and so code should be added to loader to continue to parse it, > or if loader.conf can be considered the correct place and > boot.config forgotten about? > Please, not, please support /boot.config. loader.conf could be too late > in case of serial consoles. > > I wonder, why EFI/UEFI and GPt booting (which should be more advanced) > is more limited than classic MBR/boot0 + boot1 + loader scheme :-( > > Serial console support is worse. Selection of boot partition is not > supported (as opposide to very-simple-516-bytes boot0!), and so on :-( > > > > Hi, > As an heavy nanobsd user on headless (serial/IPMI SoL) appliances, being > able to early select the boot partition by MBR/boot0 and configuring > early message redirection (with boot.config) is very useful. > Not being able to do the same with GPT/EFI is the feature preventing me > to upgrade my nanobsd image scheme. My case exactly. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 17:10, Kyle Evans wrote: > There's some UEFI var that's supposed to serve the same kind of > purpose as /boot.config -- early boot parameters. I think we had > discussed implementing this at some point, but this hasn't been done > yet as far as I've seen. Would this be usable on your appliances? How could I set UEFI variable? Via BIOS/UEFI Setup? I don't see this at my systems. Also, there are same problems with GPT/BIOS setup (which uses GPT but legacy boot) :-( -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 20:13, Warner Losh wrote:
>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
>> legacy boot) :-(
>>
>
> What same problems? I don't think we've touched how gptboot has handed off
> to /boot/loader in a long, long time. It there's an issue here, it's a
> different issue.
Ok, strictly speaking it is different issue with same "high-level"
description: pmbr/gptboot has less features than simplest oldest boot0.
pmbr/gptbood doesn't have any way to select partition to boot from, as
"boot0" has. No, setting "nextboot" from live system is not a solution.
I speak about NanoBSD situation when there is tow partitions, both
bootable, one marked as "active" ("bootme" on GPT parlance) but it is
completely broken and user need to boot from other one form very
beginning. This task is trivially solved by "boot0" in pure-MBR case.
What about GPT/Legacy and GPT/UEFI?
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 20:13, Warner Losh wrote: > If your BIOS allows it, you can set the standard ConOut variables the UEFI > standard defines with the efivar program. In addition, you can add args to > the 'binary blob' part of the BOOT OPTIONS variables (Boot), though > efibootmgr doesn't currently support it (it likely should). All my UEFI-enabled systems have only one UEFI knob: "Boot: [LEGACY|UEFI]", it's all :-( It is not-so-new SuperMicro MoBos (X9, X10 generations), some Chinese MiniPC, Intel D2500CC MoBo and such. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 21:14, Toomas Soome wrote: > errm.. you press a key and enter device and or loader path. if it is not > working - the code is there to be fixed. And loader looks to "bootme" attribute and try to boot from partition which has one, even if it is loaded from other partition itself. > GPT does not have the concept of active partition. It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have any tools to set these attributes, AFAIK. Same for UEFI boot code. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 22:27, Warner Losh wrote: > > errm.. you press a key and enter device and or loader path. if it > is not working - the code is there to be fixed. > And loader looks to "bootme" attribute and try to boot from partition > which has one, even if it is loaded from other partition itself. > Correct. And system crashes, because "bootme" partition has broken installation. With MBR + boot0/boot0sio it is solved with one keypress. > > GPT does not have the concept of active partition. > It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > any tools to set these attributes, AFAIK. Same for UEFI boot code. > > gpart can set these. You need live, booted system (at least single-user) to use gpart. > UEFI completely ignores them, though, because getting to that data is > hard in the UEFI environment. But in UEFI, you're supposed to use > Boot and BootOrder/BootNext as managed by efibootmgr. Again, you need booted system to use efibootmgr. boot0/boot0sio works before system and could switch boot partition in case of MBR. It is why I write, that GPT/Legacy and GPT/UEFI miss important feature which is present for MBR boot for ages. Which is sad & funny at same time, as GPT/UEFI has much more code than 512 bytes of boot0. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 22:35, Rodney W. Grimes wrote: >>> errm.. you press a key and enter device and or loader path. if it is not >>> working - the code is there to be fixed. >> And loader looks to "bootme" attribute and try to boot from partition >> which has one, even if it is loaded from other partition itself. >> >>> GPT does not have the concept of active partition. >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > The gpart(8) command is used to set/unset these. gpart need booted system. NanoBSD typically have two "system" partitions, "old" (previous) and "new" (current). After upgrade they switched (new code is written to "previos" partition and bootable atteibute is set to it, "active" in case of MBR and "bootme" in case of GPT). If this new partition has problems and could not be booted, it is hard to boot from "old" (previous) one. MBR + boot0 could (interactively) change active partition before system is booted, and this problem could be solved with one keypress: you select old partition on boot. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Warner, Saturday, January 19, 2019, 12:17:29 AM, you wrote: > Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose > which Boot variable to use to boot. Some will even create new Boot > variables that they use when you choose a raw device to boot from. I have never seen such item in BIOS Setup. I've checked two MoBos now (one is Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC like Intel NUK): both have one knob in setup about boot type (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese one) could be booted to "UEFI Console" which is not documented anywhere. Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could not find or understand anything in this home-rown UI with crazy-fast mouse. I have never seen documentation in MoBo manuals about such features, BTW. And, again, GPT/Legacy still left behind, and it could be very useful for small systems, as sometimes 4 partitions of MBR is not enough (2 code partitions + 1 config partition + 1 persistent data partition, and SOMETIMES, there is place for swap, for example, but MBR is full already). > But this whole thread tells me we need to rewrite the boot section of our > handbook. Oh, yes, please! -- Best regards, Levmailto:l...@freebsd.org ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Emmanuel, Saturday, January 19, 2019, 12:10:13 AM, you wrote: > With UEFI Boot* variable you could do : > - Update previous partition and set BootNext to it > - If it fail next boot will be on current partition due to BootOrder > - If it succeed, change the BootOrder to have the new partition first. It will not work with GPT/Legacy, but looks like it is solution for UEFI. Thank you. -- Best regards, Levmailto:l...@freebsd.org ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Tomoaki, Saturday, January 19, 2019, 4:42:21 AM, you wrote: > I should note that 512-bytes boot0 doesn't have that feature. > What had it WAS larger boot0ext, which has already gone on stable/11 > and later. IIRC, sysinstall let me select which to install on MBR. It has, look at src/stand/i386/boot0/boot0.S It works :-) -- Best regards, Levmailto:l...@freebsd.org ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Rebecca, Saturday, January 19, 2019, 6:06:52 PM, you wrote: > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > On ASUS systems you normally press F8 during POST to bring up the boot menu, > and F11 on Supermicro systems. Yes, I know. But what should I do next? There is no "Set UEFI Boot Var" item in it. You could select different physical drives (but not partitions of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI Shell" which is not documented anywhere, and it doesn't work always. When I google "ASUS EFI Shell", for example, all results says about preparing USB stick with EFI shell and such, not about commands and variables of EFI shell. I don't say, that it is impossible, I only could not find good (or any) documentation. -- Best regards, Levmailto:l...@freebsd.org ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Rebecca,
Sunday, January 20, 2019, 7:27:56 AM, you wrote:
> Ultimately, UEFI doesn't care about disks and partitions: it only really knows
> about ESPs -- FAT12/16/32 formatted partitions that contain the EFI directory
> structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi, the
> Microsoft boot loader in /EFI/Microsoft and GRUB/shim in /EFI/fedora, /EFI/
> opensuse etc.
Problem is (for me), our code we put in ESP partition doesn't care about
several FreeBSD partitions and ability to continue boot from any of them in
simple way. I have been said, that code in ESP partition looks and some EFI
variables (BootNext & Co), and I could "Set them in BIOS", but all this
thread doesn't have any clues HOW could I set them in BIOS. Need I EFI shell
(which, according to this message must be installed separately!), or something?
And I repeat for 4th or 5th time: subject is about GPT. GPT/Legacy has same
problem :-)
--
Best regards,
Levmailto:l...@freebsd.org
___
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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 20.01.2019 20:05, Warner Losh wrote: > Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. loader.efi lives on ESP partition, do I understand it right? So, it could not be damaged with "bad" upgrade? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 21.01.2019 15:39, Toomas Soome wrote: >>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. >> loader.efi lives on ESP partition, do I understand it right? So, it >> could not be damaged with "bad" upgrade? > > It could, unless the backup is created. Does it live on code (root) FS or ESP? I understand, that when you upgrade ESP partition, you could ruin it, but typically root FS is upgraded much more often than ESP/boot0/boot1 parts. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 21.01.2019 15:59, Toomas Soome wrote: >>>>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. >>>> loader.efi lives on ESP partition, do I understand it right? So, it >>>> could not be damaged with "bad" upgrade? >>> >>> It could, unless the backup is created. >> Does it live on code (root) FS or ESP? I understand, that when you >> upgrade ESP partition, you could ruin it, but typically root FS is >> upgraded much more often than ESP/boot0/boot1 parts. > > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi annd > boot1.efi is stored to ESP and will execute loader.efi as bios boot2 programs > do. So, Warner's advice to use set currdev=diskXpY: boot with loader.efi is not direct replacement to choosing boot partition via boot0 now (as "boot1.eif doesn't allow that" and /boot/loader.efi could be broken with unsuccessful upgrade), am I right? > we will drop boot1.efi (it is already dropped in illumos btw), and will only > use loader.efi - and in this case, the loader.efi is installed to ESP and > will only start the kernel. Ok, I need to wait for it. > But then again, if you are using stock (generic) OS on embedded system, you > are already doing it wrong and will get into the trouble sooner or later:) I can not say, is NanoBSD "stock" or not :-) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: problem building dev/e1000
On 15.02.2019 21:59, Ian Lepore wrote: > My question would be: why? If some drivers have a new dependency on > iflib, why isn't that expressed in sys/conf/files and handled > automatically? My question exactly. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: CFT: FreeBSD Package Base
On 28.04.2019 22:52, k...@ixsystems.com wrote: > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and 13-current > using "TrueOS-inspired" packaged base. These are stock FreeBSD images which > will allow users to perform all updating via the 'pkg' command directly. > Rather than trying to answer all questions in this announcement, we've > created a FAQ page with more details. Please refer to this page, and let us > know if you have additional questions that we can include on that page going > forward. Is it too coarse, isn't it? I'm not very interested in packetized base for "big servers" which contains full FreeBSd installation, but I have several NanoBSD installations, which have more than 100 "WITHOUT_XXX" options in src.conf. I want to have packetized base to create such images via `pkg' Not all these options could be converted to packages, options like WITHOUT_KERBEROS is more build option, but about 2/3 of these options turn off some file-based features, like sendmail, PPP, toolchain or bzip2. IMHO, to be really useful packets in base should be based on these src.conf options to have ability to skip unneeded "optional" base components (including, for example, man pages!). And one more, not covered with src.conf WITHOUT_XXX: static libraries and header files, of course! -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: CFT: FreeBSD Package Base
On 29.04.2019 16:39, k...@ixsystems.com wrote: > > This should be very doable with this package base. We use it for FreeNAS in a > similar manner, where we disable a couple dozen things from base, resulting > in a much more stripped down userland-base package. By default we also break > out the doc/tests/debug bits into their own userland-* packages, for same > reasons, to keep image nice and small. > Ok, after # tar tf FreeBSD-HEAD-pkgbase-x64-20190426.iso | grep All dist/FreeBSD:13:amd64/latest/All dist/FreeBSD:13:amd64/latest/All/ca_root_nss-3.43_1.txz dist/FreeBSD:13:amd64/latest/All/jq-1.6.txz dist/FreeBSD:13:amd64/latest/All/kernel-20190420203550_1.txz dist/FreeBSD:13:amd64/latest/All/oniguruma-6.9.1.txz dist/FreeBSD:13:amd64/latest/All/pkg-1.10.5_5.txz dist/FreeBSD:13:amd64/latest/All/userland-20190420203550.txz dist/FreeBSD:13:amd64/latest/All/userland-base-20190420203550_7.txz dist/FreeBSD:13:amd64/latest/All/userland-docs-20190420203550.txz dist/FreeBSD:13:amd64/latest/All/userland-lib32-20190420203550.txz # I was under impression, that there is only 3 userland packages, not 100+ :-) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 01.05.2019 0:15, Warner Losh wrote: > I think all the features are there. You can install loader.efi as you > used to install boot1.efi and have it work as well or better than boot1.efi. Thank you! > > > But then again, if you are using stock (generic) OS on embedded > system, you are already doing it wrong and will get into the trouble > sooner or later:) > I can not say, is NanoBSD "stock" or not :-) > > > One of the big reasons I did the latest changes was to make it possible > for NanoBSD to work better. Could you please look at, which helps NanoBSD to work better with strange/broken hardware? https://reviews.freebsd.org/D17102 https://reviews.freebsd.org/D17103 (I don't know do we need this for UEFI loader, though). -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: panic: Unregistered use of FPU in kernel
On 26.09.2019 20:02, Konstantin Belousov wrote: >> panic: Unregistered use of FPU in kernel >> >> stack trace: >> ... >> sse42_crc32c >> readsuper >> ffs_sbget >> g_label_ufs_taste_common >> g_label_taste >> g_new_provider_event >> g_run_events >> fork_exit >> ... >> >> Has anybody touched this area recently? I'll try to narrow down the commit >> range. > > Start with disassembling the faulting instruction. I suspect that somehow > vital compiler switches like -mno-sse got omitted in the build. *sse42*_crc32c on top of the stack says, that it USES SSE :) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Why are `powerd` and `power_profile` starting scripts (which go to `/etc/rc.d`) is protected with `WITHOUT_ACPI` and `WITHOUT_APM`?
I'm building very small system image and have `WITHOUT_ACPI` and
`WITHOUT_APM` set in `/etc/src.conf`. It has very surprising
consequences: powerd(8) is built and installed (which is very good), but
its starting script (`/etc/rc.d/powerd`) is not installed because:
libexec/rc/Makefile/rc.d:139
.if ${MK_ACPI} != "no" || ${MK_APM} != "no"
CONFS+= powerd
.endif
Why is it so? powerd(8) IS installed and WORKS well with these
WITHOUT_XXX options well, but could not be started at boot with these
options!
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Re: pkg 1.4 freeze please test test test!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29/10/2014 02:19, Baptiste Daroussin wrote: > We are starting the release process of pkg 1.4, we want to have a > better release process than with every single previous version of > pkg. For that we will need you help! > > pkg-devel has been updated to the latest version of pkg as of > alpha2. I have 1.4.0.p.a16 installed and have two problems now: (1) Latest 11:amd64 package repository doesn't have newest package (2) this package thinks, that 1.4.0.p.a16 is newer than 1.4.0.a4: lev@labrat:~% pkg version -vIL= ... pkg-devel-1.4.0.p.a16 > succeeds index (index has 1.4.0.a4) ... lev@labrat:~% sudo pkg -4 upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (216 candidates): 37% pkg-devel~ports-mgmt/pkg-devel has no direct installation candidates, change it to pkg-devel~ports-mgmt/pkg-devel? [Y/n]: y Checking for upgrades (216 candidates): 100% Processing candidates (216 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. lev@labrat:~% - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJUVOQAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1EUQALM9Hs2X1F3Zoa94RwpHK4XI 0H8/VWB/NA9J//UGqW1btikXpbSDRSA2DsjL3wzfk0Z0SNQrExrUlwthkv3n/llh OPTthShVOijOGTuvE+voBuc0aGNDOfAodNaJKHncF/qai/6P3WqqGnxsuEGegZm4 JD0bM0OQfnoQz/xECWFOwJA6EFPgneAzCthpNkCFUbe0d7/hk9uDD3I6rmJPzT4T pMRizelSZxNyMc0kVJZjfa/Zlj6h818R6puzbb3ErX0SyijyzyOKI1pAZ5mmSgl4 vPbMWELHQWVRRQS1KcvGfNJMgpYB0UG93flZ+E9M3h/ScBqdZc+2OqYUEd+ZiE/T kPJ0oQw9t283banasA0k8Ej59478ZN1CxnmO766x96lqCTlbqbl3KFwgpNORCvas /WBjV0T8ZgSf1gCh5WnFQDF0rmpfql4Ol0ynY4A8ToKtJsAUpQ+vwR8WieHRKWf9 28fqmq/+ZewX5mS/7/eZ/DZdlqgKSmWv7JbETVYR3IAkF1a3s38DrU1ZZ5TnUrPM xWqvFC8hfW7aiMtzQ8OWW8WIFMC02/0oyxEqnFsVh/+IIsvXtTQOmPFd+tNlU3Xq FjkqFJRmVBqLS2eXtNvF5WzOJrEJmAOkkYVzGAlpYQVAVie+UZHKu3D1A8B8+EPO 3PfdV96CUGhS56H9Z8R3 =v9Qt -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"
Changing timezone without reboot/restarting each service?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in "old" timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUYLEoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePW08P/1hlYiwRN7AnEjGcnMMIDmW/ jkydPH8NPHr4PrEBexIJE9+bj1UzRSqK9v1t6r8ktdX7Myph1Kb8CaM4nS8+tesS 7Wqblk/o+zHkeBOtF8J9Ar7+7ZdZWd+oG/cTAmZdlxXV1i70s1Qe2TwozO0RKCgm DHtD65jTKGUxWIliRz3GX46NnhRdOeBj+m/2dxe5s0nkP7eUknpJKBBd3IZPAUAQ 5WQvX3YbVwlE9r+pVTWFGvotKMwbmHGtJSyDrsYxyL6T2FY8+8/jl31FSLQNvlXX 9ymWjKnVIECPdRpVfQsEgp6WvRJ+xEKhyDbXCLCiOtTWX8ieJd0qZPFS4J7V87uu SwSs1OVGwfy6zSVI33QFFsp4fJzpFACxUV7YfAO/SDM+CMrGsfSCFfSyutHx1Qip 3EiVAbHKFsCdiTHRiEZfE3cg91Gp25MDWwhmePo521UTS5bI9/vg9KVFF/5QyLgl jHDMz0T8LPUernxqZilJ02vBUu1eHaznbIRgD7zQjuG2YvO5S4vh/Rdt9dbj/cRp DpIfogfEpsvTHVv7N5xWfq0zu/DTCtNtv0eIFZy8WheFb5GvHlI8IwwgVE5CuF9D 4FcIJnOU20LqQjk7LujborqwMj8ifbz48wa4xYc8/G4woKJ/Snsu3Fxdbrtmc5b4 flIOddz8QQmSn28/wOF5 =HDMD -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"
Changing timezone without reboot/restarting each service?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in "old" timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUYLE/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePaAwP/AxFm4IT8GiScZ3TQkpO/89z +LKfHU5qF45M3fRQLU3wPPtp/RYFIb5SGPRLRg9L6SmY1tppx8GlBRU/kORUPizt e9865/4p1RwOlEOJ5vxulJGxMYEjWFGB9kLnkNLgpzMK/88GmT5ntZqVIoC9wuSo fYXME7O2ZOm7Fczaiu5oH8CSlOMBNXXuaXJsuvH7WVWKOLO5XbHZd4UJbkltJQGW LEfHzLcTIU0LEzuZSVIPIzde4cGey0phO7a01XXx2+SIydU077LdV6cB2pKvTYLR t7cifOjoCWkUX/5qknoIQMrY398b6NMpQQURQoG4Uh2WvLDm5OAwYZoHfjroU2+5 7XVSrkKJd67EEw0ve84DVHWAOdtPvciNNMTVZu5z9jkFZwkVKQP7i+ct9E5g5qRq N/hiz6mUrwOfHeXKdnXBg2zc2YLlHxvhJyUc45Gi0W0MmLVMRRFPKkcVblOB5rnJ JKz5fVAXiO8VMUmTCx2TJ/YUzvsxXXkSJ0+abMviV+zACPBdaxKWb4UhEIaNdSMg hrhkd1jOWVdP83ucvXRmIoBxW9Pvfs0r249lFDTRW1PuY+P4JZLvUplvIKo5wR/X mDfeOjSy7qWq2KMVlfHh+3r2wCqRsNWy3JzaRe1npSpD+34vI+7jhPPWS7yUILQi +JB5MQZr0BRwU59Hhi6o =mE5w -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: External toolchain support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29.11.2014 18:04, Baptiste Daroussin wrote: > mips cannot be tested because upstream gcc never heard of FreeBSD > running on mips, and I did not receive any patches for mips. I'm afraid, arm has same problem. I was need to patch arm-for-uC toolchain to be able built it on ARM host, and this fix is very cross-specific. As far as I know, gcc for freebsd-arm target needs patches too, but different ones. At least to configure scripts & gcc host-drivers. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUfKyGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP8ZsP/jIWqU+9ACCR4/Rdf5A7SaGc msCsofot9YrClKNJWPdjL0V2jMtKAURJVFf3OpRi6jXY9HJKzjIjHAoXDfwr97qP 9VyLgfvtNn+ffNuFuwUalwkiFcyzqvsADTHxFqFmCnhAAnjnHzn0CzushzKSRKYN 9yEhQphipCZ1DuP1cTE8z9/BOPAfXNjgjavfAYpnJARm+XZzPn2XG83rFnlLcZFo UcByyuZznxfImH6hxoNsRVkdj5yvuGmzxQJQf+ilipiI3pDZk5/Q+ZWzWGap/gC/ 0k2zWqyKO2O5pSNb8i8vsW2J+zg++BmMnO0VAt3pjxd4dqbrV5qk/g4oXiuxB2uX 8YnvbDJuLKzvI31GCrjOOa462yZlmoCBHRoqjUBZxeHh5QQSJyZjDc0ClRGbdfi/ FNLTx/jPhouxh1vEC1nV44FGS2v5Go9urKa1OhWYRrf+NyNlt7Ao5VutujgfQlvF sLo663/Ja9W2MzLHmPanHMJcPl/Y7v9S7Mwh/EPCIe8Fd8VeYUPhOlT349Z7FnhT e7Nu4zcnY82PJ4fU/yREHxZWsEwtRxx5vr1YrLClt8R7nx8ZXzq8A9JBLjqt/RfK 4BOe0D1t8zMARroiw9RaYFm8Md8nybWp+Q++ouME51jWWPgDxV9BbKaIx6Y4r+6V RO63nTfg3A8uT/D60bIA =aiOJ -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"
Proper way to build nanobsd with "external" toolchain on new CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm using these settings to build minimal NanoBSD as fast as possible for long time: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings XSTRIPBIN=/usr/bin/strip COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_CLANG=yes WITHOUT_BINUTILS=yes WITHOUT_GCC=yes Where XSTRIPBIN is my addition (or installworld will fail due to absent "strip" for "install -s"). This setup is used to build amd64 NanoBSD on amd64 "host" system when version of "host" is not very old. It allows to avoid building of compilers completely, which speeds up built significantly (x3! on my system, really). But latest CURRENT has many improvements for external toolchain support. Maybe, here are more "official" way to achieve same result? - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUpHF7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePsocQAIdg2iIpEE1QkCtfzndl0HF9 fuO5fEdNo/Er6RRqeeS4rdsw19s82TvO4pqV8J4hM06ZE9mKchyiZBE5HywwktJl 957t1Ov9rgFupcBSHKf3KnT54556QaAhhlWRPfu3ktHY3O/X/LgEwXB63EZ4MzwE fqIXPmukXbek21/FkTiYDNRXND2h2TN9oq4FQpDUZ1aF0kH4L1YZE3Hgc5Nnsjpr etf+otiV/IPP/8Oi0vBJapsnrlQAP9hDWKorqd7ABuVzBMBv+wA+UAPROEUB4fqy /bTL1W6LITNBESTAyjnr+EoKmUB/TQlizFsLpR8OIpLqt1XaovKUyKxAjMaq04ho cZjLhTOxCirhGe0CwfPEkAls9CLL8OHWijiEVvP9rr91R/8zyfYeD0qFTUZzJ674 BYSF9CxcESLDR/qTpy/qZWSAyDEv9FT8hNwvZvyqGu5jXTZJW8PYKPyfiVHTOTB1 sNUda/LXEHVpDL+S6bECSXvtsrQGsjjwBwaJuA0s/e/TCk2ZYuQ6A42HvaOR2QIU V9keME7bCi7xuntedCDTw4Ros843Cl7ikRk74mpOV1OxzwV1MX3r0I6SDxV11tsz rngBCemEjQ4LCvonZBdborMJrvyygJzsFg7AHNw22tCC0w/n6dHz4poAC5tAsMWy Y1bDv8ZLmcIssxE2oQjB =8XAn -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: Proper way to build nanobsd with "external" toolchain on new CURRENT?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01.01.2015 01:14, Garrett Cooper wrote:
>> Where XSTRIPBIN is my addition (or installworld will fail due to
>> absent "strip" for "install -s”)
>
> Should XSTRIPBIN be STRIP_CMD? From build(7)…
>
> STRIP_CMDCommand to use at install time when stripping
> binaries. Be sure to add any additional tools required to run
> STRIP_CMD to the LOCAL_ITOOLS make(1) variable before running the
> distributeworld or installworld targets. See install(1) for more
> details.
>
> This should be unnecessary though as I’ve already resolved the
> strip command not being present issue in r275867.
After some digging ~1.5 years ago (or more?) I found, that this work
for me (conditional on filled XSTRIPBIN):
IMAKEENV+= STRIPBIN=${XSTRIPBIN}
Without this when I specify WITHOUT_TOOLCHAIN=yes on build stage each
installation is failed due to absent "strip".
But maybe, it is not very clean way, I don't know.
- --
// Lev Serebryakov AKA Black Lion
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJUpHkXXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePBqYQAKAz0z6DJEso5Qlr7uTKA9D+
PDk3YcmGzboahnWq2bPmgpVsUL4zDWG8sIX77WcCPtQoMgZdnVfvh7oJPh470rLs
2+lnFv8qGGd1bqZHj1k25DuOgNdphocy+Ed9azyBt6kIRkl7Elypzew8Ai5Kp+W9
vdRwbSdZ0qXKDx8hUjTXMcKNeloS7Hb6avLylqTIys4WD4YeoWEmUQ2w+k9f1iPc
6XpXVRfAz3A3dGuLRE2dsKzMeUrJZojOJbBCfVDTT7fBgpKQ1x4mhKxAlZqyDckm
DbOafX/hssmseuffu8xj2TIw+/7XptIpf8+fhw0D4qn/thR/V9lctZOo9NWa7jQ/
g7Q+HSfg1MD78UQOQ4CiJzTSGJWpdezI/Z7pgGXCwmspjFsLGGeNWidY/crhtjPL
kBJJUydZo9hG0w21JfASh36vHDH5maWv2Vq9rNgumpSYgQXYX7SJn2uXCRp19/71
VlyQCly2Q6bTj61OL+Zj3kc79hGVtZERKEFtOoJi4Xfme+8VinAQGVe//czxlpjc
+GW0joH2MgthFZC3+kf2Wy8OYMfq/NSnlr//+5uT+vM6yXWtQIqVCCMHCtu6anjI
lHAfQ1GW9UuZ3E8R9RVD59k3be+hooxHufZHvYSrQUMNQwItmmC+bmozh6g1Hd/1
k/veiHpg1Ox55DpJkCPO
=wSqb
-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: Proper way to build nanobsd with "external" toolchain on new CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01.01.2015 01:14, Garrett Cooper wrote: > STRIP_CMDCommand to use at install time when stripping > binaries. Be sure to add any additional tools required to run > STRIP_CMD to the LOCAL_ITOOLS make(1) variable before running the > distributeworld or installworld targets. See install(1) for more > details. > > This should be unnecessary though as I’ve already resolved the > strip command not being present issue in r275867. BTW, install(1) says about STRIPBIN and not STRIP_CMD The install utility checks for the presence of the STRIPBIN environment variable and if present, uses the assigned value as the program to run if and when the -s option has been specified. and "grep STRIP_CMD /usr/src/Makefile* /usr/share/mk/*" brings nothing. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUpHy9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePm0EQAMJtYyBDJnxTLrzq8yAP7O2O lLzFRqmqcx67RzBVWwww3bLwbEJcmRFlBLBgzpcCH7xW4B1vDoLXCv8vRtga8T1X gNJNK/piYNh+GRKAk7eOi/lzGgPkq4esmOaRhr2k9C1TdqGqJ586c6VyokHzgiS/ nwF24WdRUHFYe0RaLz16R0RkLtUnDSJQCtSgduG6MYCo4zQjvcBTrLg6tLSczMyS RxKSHEgE4GSadOtw1y6pa9bhpbvjbSefkTdjXRYAv+MWL33W/AYh5Ujl06Eu+Y1h Kk3Q0jwdvnjCEtGsJA+cGUWPIlSSocSi2kM9lXD/Dc3X+aaBGrR7ch2zI1ETvSoF XhszBuQkObgRdSKfyEeFLu1RsuuK7G8o94Mf3BxLELppNAlVCJY5jHn6DZE9OLFm AZTYHZIc/M/otB7dTM2vnzUZYSlkNcqke5rzKNijaWqbyUOMxBBuKIe4zfQMX12o KsW/YDroebFdJCQ7bsH9+bm83MedOxvipIR6CDcZUCuClg4s/BDY0sYi11AC3+F7 SEgwUZpBXsDkpr1ejE2WSARFMYkdZaSOpm1GI3a2d0/FtgFLqUgZP3bCq+ZWGQT1 Q7TMewN2u7BB0SJBnWg9AzVseeQX3+wLStKEHgg1IQsFYdNRzSFFzEArlzsLx1w0 b6AZmoBhRLFJi/lm0LE9 =ll9M -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: Proper way to build nanobsd with "external" toolchain on new CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01.01.2015 01:14, Garrett Cooper wrote: > This should be unnecessary though as I’ve already resolved the > strip command not being present issue in r275867. It looks like this fix will not work if we do "real" cross-build. Because, as far as I understand, ITOOLS are copied from host system and in such case "strip" is not guaranteed to be able to strip target binaries... - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUpH9SXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePs90QANUYMAEDQwfeWaHG/bKVe21X Cqb/qEEnIl0PiHPUR4PpuiC7w8oZx9Z/bSKvuevTvtfVIiIJzYaVQyOmgJ6/3iZY OWVLrF3nqpHp/8JPJ8BUGbdILzLZvu4tCEJ1NkKNiLBri16B7kO6tMjbkXuvtsnb t81swMMUVZ4mBfmTzJmkyvxregrjjGQK00BIAcO5Gsd4+bBXC/TJ4or13cjDpaae cu8Ux8eZ28Rgsv/igle23BVWaMWhnzZ2OX+olodknsE06TpgyHMqjBO7G/9YeqI1 9jDobSBkB8t2qIkf4gZmXE0+Ply2/ywppig2F7XdBQEJpprQG1wH4nAO8MZi15o9 wGW4YK/Ft/SjeF6tQbyb8jZjgEo6Q+HPwTsvmyh2p4luW+kKPePxvlSDoEWoVq4u 4vycodqL3LUya42Btx0gMqhGLc7ekh1Ify3FFBJtVqfZJXXUxm35DkM9W99o/E98 NhpZRpYuuLYpD84mGpEpHysNTSBZy3i8yI9Cs51MOueT4nxGY7fceKzPJIgxt9gM I6YjnyE47tgbBBcdfpFew36f039IltSmmDW129XVYGn6OAXf7ar16lltI/0mB1Sf K4y8MjIHpCVf0c23c21DDRSdAVYQV2rTrz/h3urHzplQG5iuV4ptZGj/Uh7NNtDp fVKTfoJw6BbrN0VziTMS =KVLn -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"
vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Is here any possibility to add "virtualbox" driver to vt? Now console of -CURRENT guest in VirtualBox (using "vga" driver) is almost unusable slow! I'm not sure, that VirtualBox has API for paravirtualized screen output, though (guest addons?). - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUqooJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePKr0P/R1zqoNqgda2PjWrOwZYeCed gwWVzSEahFsxd+qNpEeKVXvcD4MP8oFMMjUsoNOqf9jonk3vVkzDfpHwHziRxBxL KhojqPvONZH75WF0PREOpx8/Ff3wtuZNggeyShZPb4ZiyZkXTScDxxn5ZhzGjDG4 OWViWEGK1Sw8U7gbyXPZs2D5B5kcExK5NFQyyIEnaRkGhwqHUCRsa5UP1we0QMsw YB8XswSf0z9GqpGv0KYSJqFqieSsxmzt3fE34vGTVE+vm1LToEdq6hWkHAgACuqa KmpAxaam1L4adH+SaPI9jMfpaPChE3RhwUpKMhexy64basyCC49yvXLXiF/28K35 ztsknr8tBmSv3lvMAFyxJqjZiq34WR7PcAbiPCLPy7FPwmvwbx6CSf1lUs96nuOw MfHB1eRzOlA2ABz/WwXMBKEmzNUdAsV1X1ILaCpRPQdDy2liIQpqsiNQS83obfw3 8pY+y7BH0hmI5auUbC5sk/kE/YbmAwoqS7FygV7rujb7pAOJQ6e4MlyTC3+pA+3J Qjspxe0YfOXO+tIH5/ydFMvZPGvrDwh+gx50d5INKAk57DFWzV4qCxnjYjJIbXys pifLOV2oh2sURd4atMEG2SfN8gYeDHMzOeav7sFo7XIM1S+9/i33LG9iSXwpukec eOjKYLgaSeGEy24lgCLs =tA47 -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: vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.01.2015 20:11, Jung-uk Kim wrote: > Someone with copious free time and enough knowledge should be able > to port Linux KMS/DRM2 driver for us. > > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux > > It shouldn't be too hard. ;-) This driver looks empty to me :) On the other hand here is https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/freebsd/drm/ - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUqsmJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePfL0P+gJAtX5zpJAOL5xczPwPU5JL d6CFQMDOBAnbHk7RaBSuY4JIuvyLE/9xORSYgM4ll8t1Uhn8f33nFLNiD2kIbJsF ntMlYIS1axJubvSNBs+u1U08tEANlyxFMKEaVvzNQ8L0e3wx1MTjwNCJcN3kU9AY nUu1Twwn6YB5K1E6JJ0cICzmdgw3LAJOUjql8sZh6amyFwWk2xInV7Bxf8+DYG4S 2U1xRmmxxiEhtksPesnVsHe1u4I4gS36U15yjwycsyMLyaNEwUe412pyTGKAeeWZ iwCRpSQbmXb3uMsZbQcC8Xb5F1dsMMWgIqQl/4IWhDnyY4eaYNqMeNnDEYmXv5IR Qo/m3mzFoUEs8A0U7JyH3GOrSnGtHeEBdqs1t+aGbZfU4dfiDql8TLcV1Z7uKksq Sl0seAV29jPSB5YBazPsxVJkFsR25qv2TFOvYzGlwsfF39mJHsjZRIgz7cLWaLbM PU0E96EUn6cnL72bHJkaYKzs5ZOBa2ThvgXLo31Uqj4jbgR6kembT9iGId295pIb Lo9Tf2bJWzAvPoEwNulc4mMagUiUez6jSYez09+iN3km0c1/EkIMqDdfK5DXWiQN 2cYyUEDF+WInZwqW7Fa9Rq99xILrUNgv1ENs587Ixs5mOnDlInpvs7cLVlf5YsYj 2iecQhYsC6aYTneYV52s =6MF5 -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: vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.01.2015 20:33, Jung-uk Kim wrote: >> This driver looks empty to me :) > I meant: > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm > Yes, I understand. I've wrote about this one that it seems empty. No big method tables, no custom vbox-related code, nothing, looks like driver skeleton. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUq8OcXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1noQAMT0QQTbT8oBDn1C/AsNH15b fs0vz/BbEkM3KrHSrOYHR1CRmupBCHunzbaIUn0emooSjI4HSHSHLzd6JQ4P6mAw iSs7hmDvu7wJqoQyQpKfh99ZMnSl46PeR7uhlP9yJ8M+nCs5pIJNLVWMc+bclHi2 5Bb0X3K0eChuMP44GqIBBTABejXX+jsE8/0XUAilutLmFbHzdB9Il6YINFb2fb08 yyL4BDqpbiVQT4M4M9tFO88QvBej6lAAnNExAkdJdIj/KBHGsZOz0Ky+IWwQHfIi ErlKr8EcVgxYVBMat1eUQA66uwclr8aJm2mGHXAlDiFSAbi/r17irdjVdgSM9EZ9 Ga7EJ4vLZIpyDvzXmaVqvBXtmaNbqaiOPg6HsXgfkSGt49x8V5Vocw4hqk/R6jDa dhFEUZzvmxkuq70XywoYT1mt1kqzl0h83A5/c8fcPjeoxQMG5cfPl5q5iGiW9DjV 0NBC8nc+Qm1evu9DZO0jz0QCEWmmyUJxLsQjtsJkEpUWGc62TJXE6sz4KyQY9qvW jYVAI9OhQQVwLd7p7LKbRuePb43kNmAvCw6PGIb6r/EhqVurYf/l0zx3uzRkx06D dbg+3OvXa7eq5vkNnJiFslai6DGXbulOpH6ksOuNBKq2Pfw0xu+lilEHtkyEcbJy imtO+NSzbzgAlgS41kN1 =mOlA -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"
DigitalOcean offers VMs with FreeBSD!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ I didn't see this news on mailing lists :) - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUt6STXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePp6oP/3yvWOpt83MiEVuoTxZpGuVI 4vpWyv+U9SaDzFNo7HGOO5qI0L1vqe77mzzlqA2bVUcITKx+YckO5gtRdSDh3GtB FzpHpVHXDD96YacyxYaPFIqnGYAUoeNgX/mcTQz2IYouWWDuRsy17joetXVmtunP 2SFntiAnf8xYYfc/T3Bwjhff+TUgcQhmVH567EUpa2QTtWEesxeISqUj54/JwPzX 1sI0Yy2t293g/udCQxROU1rFqjmjTW6r31iS27IUbwdQtyGXR1EHMMopKXxxOq5x w1THJyLOQOETTRAYJpEpHgNRmgFZazfvxe6mPDQyuEQ/tuCZgO1WLwPajhy8Ckws Fa9vQsVyQOFjj5hP1BbGJFtIpc0BMuyXESfABRTBQZsD/SHJzly59wGqgl1lwFQ5 fUb5oDyc07M6jquQo/Pc05cwHxgsRumAYZ1CIxNTR930ShL4mpcYTS6xWlkzm4bA cqfSZ2FW57RKjWrArI7xOrG83aneHjkwJtNQ/5nLbpmemmRMW9qRzd9YaWkGfmNn jsnwwS5gmIuLK5GTkprWQ1wBltdV7BiFFNAIRi6OBpM/pmwshOVXHOPJp+9YXCLJ UfmLedFGSp/J/BESsRmJ1rlt52coy/NY3AxA+z/JW3kgD/EIRdiNSswktTTn9nCR 8bOmQUvmMdQ/bRjlGomh =shHj -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: DigitalOcean offers VMs with FreeBSD!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15.01.2015 14:29, Lev Serebryakov wrote: > https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ > > I didn't see this news on mailing lists :) But here are some thread about FreeBSD is way slower than Linux in these virtual installations https://news.ycombinator.com/item?id=487 - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUt9yXXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePU9YP/22oUffmkkbbd0KUbJgDQqDi PaohQ/LiFs3elpIQboQXuMIQtYqcAEE/3IXskc/ShHfnKNm0V9V1gPkn9wpaAWza cbOPwwE8RStpN52z6wKpAy6FM1aXkuL4idDc6ErHfIP4VDW4sgaJhBb0hnIsSWO1 745MTWJg8bldr5Kqzr/8mFDgCuNWHZi/QTNHSggDni566T0xn7hEbPbQoiALpZT8 3b5I8KGu/4VnvT7vmZmj65HyX9N9MtllfbpmCv9iQAJd+Tf6kTiURiFv/6vJDN0m 1cD5j5EZU+mJOjfU9n3dbP3M2xIhbVOZBrUtD23S2CeZtHPtZgcgt19aBQ2ZjTlx TcpykUDoIfAwmD8bjNe8mc06rn6MM7QYnKTxUN9WdkVpTzu+GcA2g00ET4fY8EnF 4R36/vnula2S8f5ON+MrBmtQ/vdiHc7w1QNxq41McegZzmkF4lcjHVS39MNAiXaf eG6fQHaEibVGBUBsPX5FjUWIWugAG6CFDX435AN2bx0WM7ocgQd+ITEWIVytG68c jqpnGF15crFzZCEYpeHUhrieYrzIHqxarrkWMBefLVxflricB/alPeYc+jNT6wcm K5MUcBVXfWTcUVP0SgXNAnWY8Tmvwfbmb9MkNPudIOFjDBc3pEPICW23uviNizLt OoYcVXcOj+ALB27alZi1 =uggy -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: DigitalOcean offers VMs with FreeBSD!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15.01.2015 18:44, Slawa Olhovchenkov wrote: >>> https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ >>> >>> >>> I didn't see this news on mailing lists :) >> But here are some thread about FreeBSD is way slower than Linux >> in these virtual installations >> >> https://news.ycombinator.com/item?id=487 > > May be IOPS quotation? Can you test with dd and custom kernel with > MAXPHYS=1048576 ? I haven't Digital Ocean instance(s) right now :) - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUt+Q7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePvnMQAJviVsAGTxG0yFOqmBFDVAda N/HQ2Px5PBPwYBPmyY0GFPIRUW6dpRbiAKuchDTOxmOrRwjBj+2NNN03ktR7qzIk vD0xz3q72Jw/5CfnpUqb8/HXwRGX/6wPX+YVK4L54RFco3QlslyzFJ8T+lGUQ5wA Fk+Gus1ibz5NNsSoIhsbb/QJzbEhMVj2DaSoMm0D4MAI+0/cl/GmtWUSgY0y6N7t /w3NR1Bon3d4FblQOGqdF/VovN5tX2YInMttD5s+Av/OQTxX+VPfp3qx41BcC3pa 0CFp0le4TQp980vJuUbZ1RmJycp7AfkYU4v89foDcqNlyX9KIqBTBQoadVl37jud fBcAOmc7/wu4y1CVSY6btOFuOaAUFY5vglIixXqabJsJyFc3ymx6yP1MNOjUfTzK k/azAZis7DnV8YsyUQbJv5rl9VH2G3qwDpwB7ae9dG2kA2zicrN0cTfEIYJkrrFe VF+oyzR7PyRGQ98/lE4ewLiHW2zWUyzo+YJp1MJTkWIvWAp7Q/FyyaayXQ9Kju4a FtQMwD46lvPhQKsg5245Sn3Fg18HJmrWwGM5Qr3axs2aOKNvj5fPuStelaKQVYIi oIG30WSZcK/RnUuS5rvPgLzOM+O27ez3oj861cd3itYR8yz9qun5PDBAiwZgf2T+ 7ROGjnFANJvQtr5pUBXV =Tpza -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"
Could not build r279842 on r278265 -- mount_smbfs vs /lib/libkiconv problems when WITHOUT_ICONV is set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I could not build NanoBSD system from r279842 sources on r278265 host
with host tools ("cross-build" with external toolchain).
buildworld fails with
- --- usr.sbin.all__D ---
/lib/libkiconv.so.4: undefined reference to `__bsd_iconv_close@FBSD_1.3'
/lib/libkiconv.so.4: undefined reference to `__bsd_iconv@FBSD_1.3'
/lib/libkiconv.so.4: undefined reference to `__bsd_iconv_open@FBSD_1.3'
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [mount_smbfs] Error code 1
I have WITHOUT_ICONV=yes, but it worked month ago and I could not
find anything appropriate in UPDATING or with google.
- --
// Lev Serebryakov AKA Black Lion
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJU/tWFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePgEMP/iEO0Q0evzcTFEce7In8+yC+
IV0J+/2cVsw00vjVq2jYsGEPvDBnMCOEKxWv//m06CTgX3/hisap3gEw8Ynqxn9c
oj75r9bBXJgpft9hbuMXZvfomXbwqcyvJvTufMhIdhCm0vs8I95Fl/MTLtXc29XL
EZBgCI5mxp+tCIjPHHj0znhKJ8Z1DoVtMOrOAfmvnVPlhfjqY3mjdrU7/KlYrbql
dqsxoROcbHXqDRcmNeI/68ap6vwm46a+SEaJBhaE0qIBjw2vJ3zVwr+NdNk9vS9+
YLpAcerskDEvXuKmz5LJ6ekuvCHTA0qvs8KwweSqJET6eK5hS2/WRUdlo1GO6IG/
a8EqgL/cDwfwTDO1n6B6oTwPxYG5p9+ybWmWxVaWa5+FdJHTNnfJUTexDdf82Ltt
O3u9fkIZxl2xH2JMfzd5B3EeB3tsy0vBa09WqLR9VdFg6A58F4cPKFYCEpklJUhi
hly2wpPVNv5X+Tm2xJW2bJbpOeuncVwrNJs+o4ga1IolsLGMwyUnWHezW3SDjMLV
eLQPvsX+15qZLnbVcU8bm8EmIENMppdzQwfA1E+tMmuhYUKHpTuItyO0/foE9Ecn
FH5ye93gB77WhZvHuA73ASmMWpraBPlvyE0pp4/wFiDyjRmGjh6gAK0ll7HRXmV1
xk3R0BEV20wrL0+R3XbD
=y/6b
-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: Could not build r279842 on r278265 -- mount_smbfs vs /lib/libkiconv problems when WITHOUT_ICONV is set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10.03.2015 14:29, Lev Serebryakov wrote: > I have WITHOUT_ICONV=yes, but it worked month ago and I could not > find anything appropriate in UPDATING or with google. When I delete "WITOUT_ICONV" as workaround here is another very strange problem — abort() in clang!: - --- .depend --- rm -f .depend CC='/usr/bin/cc -target x86_64-unknown-freebsd11.0 - --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - -B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE - -I/data/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/include - -I/data/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt - -DHAVE_KERNEL_OPTION_HEADERS -I. -I/data/src/sys - -I/data/src/sys/contrib/altq - -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -std=iso9899:1999 /data/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt/ng_ubt.c Assertion failed: (BufEnd[0] == 0 && "We assume that the input buffer has a null character at the end" " to simplify lexing!"), function InitLexer, file /data/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp, line 63. Stack dump: 0. Program arguments: /usr/bin/cc -cc1 -triple x86_64-unknown-freebsd11.0 -Eonly -disable-free -main-file-name ng_ubt.c -mrelocation-model static -mdisable-fp-elim -masm-verbose - -mconstructor-aliases -munwind-tables -target-cpu x86-64 - -dwarf-column-info -nostdsysteminc -nobuiltininc -resource-dir /usr/bin/../lib/clang/3.5.1 -dependency-file - -MT ng_ubt.o - -sys-header-deps -D _KERNEL -D KLD_MODULE -D HAVE_KERNEL_OPTION_HEADERS -I /data/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/include - -I /data/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt - -I . -I /data/src/sys -I /data/src/sys/contrib/altq -I /data/obj.nano/gateway.v2/data/src/sys/D2500CC -isysroot /data/obj.nano/gateway.v2/data/src/tmp -std=iso9899:1999 - -fdebug-compilation-dir /data/obj.nano/gateway.v2/data/src/sys/D2500CC/modules/data/src/sys/modules/netgraph/bluetooth/ubt - -ferror-limit 19 -fmessage-length 0 -mstackrealign - -fobjc-runtime=gnustep -fdiagnostics-show-option -x c /data/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt/ng_ubt.c cc: error: unable to execute command: Abort trap (core dumped) - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU/uiKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePq/MQAK9uWLxToG1ypF24F+ymkmA6 5lOisHgejIpKeb5XtBYQBPe9O2E48G/m1ECNaoTd4cGBa8EOZih75sKEAkwm4nlT Yp52p4qFwVgVGn/l90UAE6gmpqdKlqkj4w+O6f3m7PAXBYNvPRHCNXKHlRwMxZBL TBY6QQbYti4nxAwPs8Fj35VUlvXhbKPgwVPRwefG70fFZDieQEG3LV4ugoopVDAL QLDnmUF3FcXtG4DZjHtuQUqMQNGKkxBfqPgQZmvp/fdxfXuX+vlV7oSZICBx47rU lkSNlo4dWXLVh3jWGX/7jNQJOCcbGE7OgYLEJeSVbDGrsVi5FOgh86Tdcr8EFDLZ G9lpgkY1V2fOMkaxpe6JFt1jgFfYwnmVf6v3pNWOIW7Nfwjg6PbMgZ2Si3852Xy7 bZPTsPjOVsvAm6Sj5UPEQ13EayiIVTT5qhrHo0CXJ0mphFiHxCgfNcFRsgmdcCn4 lPw6hD0U0y3idUe1P784HZsXcBVpSWxD61S3ReFxyUA33WxmCXdde3yaYSYFdg4m AqnWhEpjvmp0uSsXMNlocux6Bdb8RC4hXTybpsnJkKJ1jLpFWHuM5DU166GaSPFp U/Cgx6tAlUR9wCuB8ZBmvo3Z7T/zOFUlHdYIGlsOIXiXk74JuetEp6Wgy18a9W4E afpD6j83/kv7ZAs1fFq7 =LVcG -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: Could not build r279842 on r278265 -- mount_smbfs vs /lib/libkiconv problems when WITHOUT_ICONV is set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10.03.2015 16:32, Dimitry Andric wrote: > I have never seen this assertion before. Is there something wrong > with your copy of ng_ubt.c, or some of the files it includes? "svn status" says, that it is equivalent to repository ones. > Can you provide a reproducible test case? I'll try, but I'm not sure :( > Also, in your original post you were talking about an "external > toolchain", but I see /usr/bin/cc in the command line, so that does > not look very external to me... It is external to "build world" process. It was not built at bootstrap stage of "make buildworld" but provided by host system (which has same ARCH/TARGET as target system). It looks like this (in /etc/src.conf): XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings XSTRIPBIN=/usr/bin/strip COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_CLANG=yes WITHOUT_GCC=yes WITHOUT_BINUTILS=yes WITHOUT_ELFTOOLCHAIN_TOOLS=yes - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU/vReXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePt08QAJuAPu/Wnn0hZyyLzPe+fP02 wTD/Aw975yTAtGZs8F7nHMLi/mhm7WKJoz2m9RuUXvFCxFTHKmOUKu+468+Puxsh BtxYuCgprBiFupXY+m4rBjAfHzmTzPYSbKh94jKkUtWFiO0B3CLHM4wioVolZh++ X71CmQwhD+NEBtUHKjd9TObeJ2Sd1NeDJknA+63cg4kUPepr27sB1VkhgoI9PHHV i9Q9nL3jkBels5LVBnkkqZSy4RwL5RGeQp7+YNfDpJsr6Uc5vNvjn6fp5EwqQ3Da naK4bQxrGJfVWb3sVT0xwVcSBApJQI1+OX4rQs5YHNy7o00Ymax5riBkMfooGXEv myxjObkiZIDXDc0mMVMLL0jv5+c2EYkUsnFpxZzyWPxLnwAwPidtU4Za+5+q9Wyx sqXlViHfv6GSfxTGtefrmQ9ZuDazekgCQZ+pSUzhMoLEDxXK/yNP+JhwUEEOY5p6 N7c/95z9DvfaIQMmRdVQ2W2yeh5hnNzBk/q4bJUN3kTljW61QWwEz7eGM5lTa8H0 jRQ6HIdOXgAF1Kd+b524Am0J2WNlnnpf/VLo1pVU5tV9EcBSoOkaAduvz0lUwJJn eYEaIF3Kn3CpQ80hTgejPkrqAZE3tyjKwcZKdsp5KST4Y2tvzUf7AzF0+o7EMP61 deRYN+pfs/Y9yPcRSbQo =QjJX -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: Could not build r279842 on r278265 -- mount_smbfs vs /lib/libkiconv problems when WITHOUT_ICONV is set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10.03.2015 14:29, Lev Serebryakov wrote:
> I could not build NanoBSD system from r279842 sources on r278265
> host with host tools ("cross-build" with external toolchain).
>
> buildworld fails with
>
> --- usr.sbin.all__D --- /lib/libkiconv.so.4: undefined reference to
> `__bsd_iconv_close@FBSD_1.3' /lib/libkiconv.so.4: undefined
> reference to `__bsd_iconv@FBSD_1.3' /lib/libkiconv.so.4: undefined
> reference to `__bsd_iconv_open@FBSD_1.3' cc: error: linker command
> failed with exit code 1 (use -v to see invocation) ***
> [mount_smbfs] Error code 1
>
> I have WITHOUT_ICONV=yes, but it worked month ago and I could not
> find anything appropriate in UPDATING or with google.
I think, it is result of "overlinking elimination" work. But I'm
wonder, why SYSTEM libraries are in this output at all!?
- --
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJU/vWQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePHwMP/2xq7OnTeyxJ7JRBEmRNkwgc
OAqsEtMJwCFLnT8vAmyWQcXYeVDraKv7xqn6nq+euSbGNcv2FoRlLKCH9+ON7A1u
JXGpizIvmW3PszT0nvAaq4bgi7Tqouq1xNng6PIK+7t6EZ4k8j7dl7LOc8fnGjDx
T0L0Siv2mU4yksBcsMLnC670wFQb/INFCJT4nsQvr8HDr4mGCHwkIUe/2av+s6jX
IeixAipoh7trRA8J7FEi7yG35SZ4I6n2qWU4VVLSbpX0VutEuE4qP9bBmisDCxfT
Z5mlXXO7GF8/lck6Pm0vwQq4AxfN+5LiJ5H0jIl+OfmaVzglhLKSHFxVBlPdc9pQ
nMHyI8+xy6ZAcDR/NkbnoCXa5068m6XuMYigYOwMlduumksNuGYUf8D4yD3ZoxPP
KE01e2f5gyDNcaaZj1vJA6Kq5lPrTUOHl4Pq4tB8L/xhJp/gcZClAxLwXyxCv1EB
S3eVMWnhoX0Gzg4K0G8v6bJLWV0UDPejtdgEj6N7E3LK7kt5H5Zzm3HmdfRmn+JB
f5G41AXORt1LNtWGgOQPp62HNVb2voPWg51cJNBBbI1un8PjpUVVRhl/Z1hKGUj2
0yu519flB0ALR1UTRj8qZNRM5q+VkVeNBppzbzIAJyyjezLIqjvH9gQq632zoyTW
uj2/TEuFxkGmSDHbvYhA
=OXyG
-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"
r279842 could not do "installworld" if compiler was not build at "buildoworld" phase (amd64/efi trys to compile on install)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NaonBSD build with r279842 host and r279842 sources without compiler built in "buildworld" stage fails to make "installworld" because it try to compile "sys/boot/amd64/efi" at install phase: I have this in "src.conf" WITHOUT_CROSS_COMPILER=yes WITHOUT_CLANG=yes WITHOUT_BINUTILS=yes WITHOUT_ELFTOOLCHAIN_TOOLS=yes WITHOUT_GCC=yes WITHOUT_TOOLCHAIN=yes And got this at "make installworld": ===> sys/boot/userboot/userboot (install) install -o root -g wheel -m 444 userboot.so /data/obj.nano/gateway.v2/_.w/boot ===> sys/boot/ficl32 (install) ===> sys/boot/ficl (install) ===> sys/boot/amd64 (install) ===> sys/boot/amd64/efi (install) cc -O2 -pipe -fPIC -I. - -I/data/src/sys/boot/amd64/efi/../../efi/include - -I/data/src/sys/boot/amd64/efi/../../efi/include/amd64 - -I/data/src/sys/boot/amd64/efi/../../../contrib/dev/acpica/include - -I/data/src/sys/boot/amd64/efi/../../.. -DBOOT_FORTH - -I/data/src/sys/boot/amd64/efi/../../ficl - -I/data/src/sys/boot/amd64/efi/../../ficl/amd64 -DLOADER_DISK_SUPPORT - -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT - -I/data/src/sys/boot/amd64/efi/../../common -ffreestanding -mno-mmx - -mno-sse -mno-aes -mno-avx -msoft-float -std=gnu99 - -Qunused-arguments -c /data/src/sys/boot/amd64/efi/autoload.c /tmp/install.4m4ZY660/sh: cc: not found *** Error code 127 Stop. make[7]: stopped in /data/src/sys/boot/amd64/efi *** Error code 1 r278206 worked with this config. BTW, it will be nice to have WITHOUT_UEFI knob. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU/0hSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePxtQP/A1tFNf2TEVwGn8K6xILuPf4 nKMf5sfCMLyObskWJ1QUFpg8x2CV+R3LInCOliAgLamA3McFy62md7+h2V+FtBrc T/7W6kzNS7WBQCXALsb1psOFSpTqhmvEF3q3WT0gvyeO8xrI4rF5qrohgLpsIcY7 otamP8WcFRdDA9+EHiiXJo7OB+r/1bhTtoZQ/n4wfTzrUyfUk6faZlVAdFewRfjZ gOwZ7vUMkOrhabcnxt+sf1qhA9Ned0Cd31DJp+Bq3VJ1P6HFkcOydM4sKfNQO2sL BWCnTmskm/ZoD8MRkAeC7MJ0xHCCETxToWzDckA5naYiqSUm/PKp5srqtM1vLLDr 2YPh8CXqSqM8gbNIP66LAhsQGpfofUgPb8El16Ha9Ah5e5XGUMc5p1MWYIDR4LkF YVse2v/J4tQZuSdGzgWXMQicMpw2CSBwZQ9Wd/cN2PFF/yp75C4J1dk9wOa97VMW Y+U9dNoFo7QXVj5l3g/Dp5vU9AudAD1P10lzlZmoPVzex/eKJs3JUW7vvUFRLRgc oPgstt2nie5/r16cvuRcA8pdAU1bW0Kem2XxY1bg7yhLodxDLlgfxrpaGXj/NW2w F0qjKtlLFXdkd4AUA9zX4VkMwRCX4nRCQ043cY9ICC25ufvliSgnERGzpvQXkxu6 CtlMK+h3Mplsn0LoR6uq =1UGD -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"
save-entropy race in -CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have newly installed 10-STABLE server which sometimes (every second dat on average) sends me messages like this (TWO AT SAME TIME!): From: Cron Daemon Subject: Cron /usr/libexec/save-entropy unlink: saved-entropy.8: No such file or directory mv: saved-entropy.7: No such file or directory and From: Cron Daemon Subject: Cron /usr/libexec/save-entropy mv: rename saved-entropy.6 to saved-entropy.7: No such file or directory mv: saved-entropy.5: No such file or directory mv: rename saved-entropy.4 to saved-entropy.5: No such file or directory mv: saved-entropy.3: No such file or directory mv: saved-entropy.2: No such file or directory mv: saved-entropy.1: No such file or directory All these files present: % sudo ls -l /var/db/entropy - -r 1 operator operator 2048 1 May 00:11 saved-entropy.1 - -r 1 operator operator 2048 1 May 00:00 saved-entropy.2 - -r 1 operator operator 2048 30 Apr 23:55 saved-entropy.3 - -r 1 operator operator 2048 30 Apr 23:44 saved-entropy.4 - -r 1 operator operator 2048 30 Apr 23:33 saved-entropy.5 - -r 1 operator operator 2048 30 Apr 23:22 saved-entropy.6 - -r 1 operator operator 2048 30 Apr 23:11 saved-entropy.7 - -r 1 operator operator 2048 30 Apr 23:00 saved-entropy.8 % What's wrong? - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJVQpyLXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePcSAP/RLLJYc67zrVGEXVGL3csVlM PZhkWW/c69ppdWjEXT8IE2FlhGGuaMnRr7B5m9Q7m7l+8wfJQ1/hSiVeLEaCfnUb eq2kq7PTjbeeoSMAjegdxNklz4XWJiLhMifpFCBRNh0IdlkeA/wTUYQrm8NuZ5QY fC6oZEMGnuCFhO5TgM6KgXblHcsjeiHRweMt7rJ1o9leJWB3Hxd2HvPdiPSRAqnZ 3Fs0zwHF5YnKHMyF1D0/+NB5kZer9cr9+LRQqh8hhtWDGDF0Dhblx+lY9vatttRU bA5HwTP1y/+jrPfZyGnxSqtWW14NrVczt4Z/9yCJ/6YtSywa9EnA6xui6JECMeg0 AJInge8nLlHoszRWxr0c2uJOQ+z1dgF7F6EK+A45n2/+gTBNSMVOJoDw6c4rqxMh tUYoIIIyKEm5V8B+GRq+Bcq4o5tFBxaZQw3ORiL378cJp5EK0KNEErkFak8QXn82 Utj5LT/A/WXcqJ0VX2/MNGn3wy2AA/2FfOTUx8emzRR9WvseMa+lpwXM9pTbjZXE l8lDw7BaCXnC4kC4mFquwLTdyDDg1U4nMGXT7Lo1XR0lI6IY/067FluHpt8N/Qd3 H2bJTBzN0G2l9Lcgq8WMdVCy9p5iJa+l+l/BUP9j7uVTy+5ghjtzTl/Y7jqvc1ua B+KqTOy1wtm0lmbIWj7a =cUdc -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"
