Re: bhyve fopen failure

Hi Chuck, In capability mode (capsicum sandbox), files like this need to be opened before bhyve enters sandboxed mode. (That’s ‘cap_enter()’.) Best, Conrad On Tue, Mar 2, 2021 at 09:31 Chuck Tuffli wrote: > I'm porting some code to bhyve and am getting a failure I don't > understand. This is

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Typo: On Mon, Jan 4, 2021 at 5:25 PM Conrad Meyer wrote: > SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-). 2^160 for a specific hash. 2^80 if you're just trying to find any collision. ___ freebsd-current@freebsd.org mail

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

med "x-gitbrutec-nonce." $ git cat-file -p 009 tree 4e778673b8af45ecd4c62e8b1d1438d06db7f440 parent 0080b4fc4c2066fa05641e73d5f0985c15ea author Conrad Meyer 1590357489 -0700 committer Conrad Meyer 1590357489 -0700 x-gitbrutec-nonce YYZSKGIQCLLXGE Use 'git update-ref' in post-co

Re: rand() is racy in multi-threaded programs?

Hi Andriy, On Wed, Dec 2, 2020 at 11:34 PM Andriy Gapon wrote: > > On 03/12/2020 01:20, Conrad Meyer wrote: > > Rand(3) is explicitly unsafe to use from concurrent threads without some > > external serialization, even after initialization. I’d suggest using a > > diff

Re: rand() is racy in multi-threaded programs?

Hi Andriy, Rand(3) is explicitly unsafe to use from concurrent threads without some external serialization, even after initialization. I’d suggest using a different API. Best, Conrad On Wed, Dec 2, 2020 at 13:53 Andriy Gapon wrote: > > Specifically, concurrent "first" calls to rand(). > There

Re: iflib/bridge kernel panic

Hi Shawn, Is it possible to reproduce the issue on FreeBSD? The excerpt you've linked to is not on FreeBSD. Conrad On Sun, Sep 20, 2020 at 5:53 PM Shawn Webb wrote: > > From latest HEAD on a Dell Precision 7550 laptop: > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > >

Re: To people upgrading from before r363679

The problem identified in Warner's email was fixed in r364030, so an easy solution is updating from r363678 or earlier directly to r364030 or later. Best, Conrad On Mon, Aug 10, 2020 at 3:20 AM Dennis Clarke wrote: > > On 8/5/20 9:19 PM, Warner Losh wrote: > > If you are upgrading across

Re: routed && route6d removal proposal

Sounds good to me. We don't need a RIP daemon in base, and if needed, it is just a pkg install away via one of the myrriad maintained routing daemons. Thanks, Conrad On Sun, Jun 21, 2020 at 4:06 PM Alexander V. Chernikov wrote: > > Hey, > > I would like to propose removal of sbin/routed and

Re: HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

r-x 1 root wheel 12 Jun 6 09:24 /dev/gpt/testingeli.eli -> ../md0s1.eli https://reviews.freebsd.org/D25168 On Sat, Jun 6, 2020 at 8:52 AM Conrad Meyer wrote: > > Hi Xin Li, > > Thank you for the report and diagnosis. Sorry for the breakage. > > I have reverted the ch

Re: HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

time to revive my laptop. TL;DR: if you are > using /dev/diskid or /dev/gptid labels and GELI, please wait until > things settled. > > === > > On 6/5/20 9:12 AM, Conrad Meyer wrote: > > Author: cem > > Date: Fri Jun 5 16:12:21 2020 > > New Revision: 361838 >

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

Hi Grzegorz, If you have another machine connected by network that you can install and start netdumpd on, and; ipv4 configured on a supported network device before the machine paniced; and a recent CURRENT; you should be able to initiate a kernel dump over the network with 'netdump -s server-ip'

Re: Working on Zoom port

Hi Matthias, From personal experience, receiving Zoom video in conferences with native www/chromium and the web interface works perfectly fine and has for some time (at least the last year). I think, but don't recall if I personally tried it, that mic support is fine as well. Audio playback is

Re: System clock is slow

On Tue, Mar 10, 2020 at 9:24 AM Theron wrote: > I had previously used powerd to let the CPU underclock to 700MHz when > idle. Now, I've lost all control over CPU frequency (either by powerd > or by sysctl) since there is some in-kernel cpufreq driver which I can't > figure out how to disable.

Re: Which AMD CPUs are supported -- temperature

The step size of 1/8 degree C/K is documented in the public BKDG (prior to 17h) and PPR (17h+) documents available on AMD’s website, at least for relatively recent models. I don’t know about very old models (really anything older than 17h, although I’ve looked at the 15h docs some). Best, Conrad

Re: hwpstate_intel hangs kernel

cannot set or unset that hint from loader prompt; >> >> ok> set hint.hwpstate_intel.0.disabled="0" >> ok> show >> >> hint.hwpstate= >> ... >> >> Best regards >> Andreas >> >> On Sat, Feb 1, 2020 at 11:26 PM Andreas

Re: Is amd automount still supported in 13.0 or not?

Yep, amd is deprecated for 13.0: https://svnweb.freebsd.org/base?view=revision=354902 , https://svnweb.freebsd.org/base?view=revision=354997 . Conrad On Mon, Feb 3, 2020 at 3:23 PM Bob Willcox wrote: > > Hi All, > > I've recently installed a 13.0 snapshot on one of my system to get some >

Re: hwpstate_intel hangs kernel

Hi Andrey, Please try 'hint.hwpstate_intel.0.disabled="1"' as a workaround for now. I think I have identified at least one problematic piece of code, although I don't know if it's the root cause. I will go ahead and fix that, which may not fix the hang, and also add some debug printfs that can

Re: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld

Isn’t rtld’s behavior here correct? It’s really Clang which is doing something quite odd. On Fri, Dec 20, 2019 at 13:27 Ryan Stone wrote: > I've noticed that on head, if I directly execute rtld to run an > executable, AT_EXECPATH contains the path to rtld on head (on > 12.0-RELEASE it will

Re: /etc/os-release isn't created

Hi, Did you run etcupdate or mergemaster as part of updating your host? Best, Conrad On Sat, Nov 23, 2019 at 1:15 PM Yasuhiro KIMURA wrote: > > Hello, > > Yesterday I updated my 13-CURRENT host from r354592 to r355028 and > /etc/os-release symbolic link wasn't created. > >

Re: panic: Unregistered use of FPU in kernel

This kinda just looks like ddb doesn't know how to disassemble crc32q? Which might not be too surprising. Note that it also truncates the qword constant in "add" at +167/+0xa7. That one isn't corruption; just a DDB bug. Can you print the faulting %rip and dump a few bytes at that address in

Re: Deadlock involving truss -f, pdfork() and wait4()

On Fri, Sep 13, 2019 at 11:37 AM Mark Johnston wrote: > > On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > > This gets me a little further but now the wait4 call by the parent > > never reaps the child and instead blocks forever: > > Does it perform a wildcarded wait(), or does it

Re: Building world with gcc9 not working

On Mon, Sep 9, 2019 at 8:25 PM Rebecca Cran wrote: > > Is building world with gcc still supported? I'm getting an error running > the following: > > make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld Hi Rebecca, Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc

Re: HEADSUP: drm-current-kmod now installs sources

This is super cool, thank you! Is it feasible to integrate other out-of-tree kmods in a similar way, e.g., nvidia-driver? On Tue, Aug 13, 2019 at 2:58 PM John Baldwin wrote: > > With help from zeising@ in particular, I've just committed a change > to the drm-current-kmod port that makes it

Re: SVN r350713 breaks non-debug kernel builds

Thanks for the report Michael, and sorry about the breakage. I believe this patch should fix the build, and I am testing it now: --- sys/kern/kern_sysctl.c (revision 350714) +++ sys/kern/kern_sysctl.c (working copy) @@ -55,6 +55,7 @@ #include #include #include +#include

Re: Reducing UFS corruption from unclean shutdowns?

On Fri, Jun 21, 2019 at 2:55 PM Alan Somers wrote: > I would've thought that immediately following a sync(8), the > filesystem would be consistent. Why do I still see errors after a > panic in files that were written before I sync()ed? > -Alan Hi Alan, Contra the name, sync(2) (sync(8)) isn't

Re: CURRENT >r349150: boot failure in rc.conf.local

Hi everyone, Please find a proposed fix in https://reviews.freebsd.org/D20686 . I didn't notice this thread because I'm already subscribed to current and CC's don't display any differently in my mail reader. (I don't read every thread on current.) Take care, Conrad On Tue, Jun 18, 2019 at

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Hi Rainier, On Mon, May 27, 2019 at 7:47 AM wrote: > I have a 32bit FreeBSD 6 binary that I'll need for a bit until the > department who is technically responsible for the service gets around > redoing that service. Even if this proposal is approved, it would only affect 13+. You could still

Re: Weirdness when writing to pseudofs file

On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg wrote: > > It seems, a single '>' will cause it to try to create the file (even > > though it already exists) and that fails (kern_openat). > > > I would guess because of > >

Re: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.

Sorry about that. Please update to r347329. Thanks, Conrad On Wed, May 8, 2019 at 9:16 AM Andrey V. Elsukov wrote: > Hi, > > today I updated one of my test machines and discovered that message from > the subject periodically printed in the console. > > FreeBSD 13.0-CURRENT

Re: Optimization bug with floating-point?

Hi John, On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote: > One issue I'm aware of is that clang does not have any support for the > special arrangement FreeBSD/i386 uses where it uses different precision > for registers vs in-memory for some of the floating point types (GCC has > a special

Re: PMC Sierra SPC SAS-SATA Card + ESXi

Hi Evgheni, Is it possible to replace the card with a different one? The PMC Sierra driver is not very good. Best, Conrad On Sun, Mar 10, 2019 at 12:24 AM Evgheni Melman wrote: > > So I got this weird setup, where I … a PMC-Sierra PM8003 > card (same as PM8001, but with external QSFP afaik) …

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl wrote: > This is interesting as well. Does this mean that amd64 is now > the only tier 1 platform and all other architectures are after > thoughts? This has been the de facto truth for years. i386 is mostly only supported by virtue of sharing code

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl wrote: > Ideas? > ... > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class > CPU) >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13

Re: r344398 Import ACPICA 20190215: breaks bhyve

Oops, to the list this time. Hi Oleg, Those look like the ACPI lines bhyve attempts to generate and compile in basl_fwrite_madt(): 272 /* Legacy IRQ0 is connected to pin 2 of the IOAPIC */ 273 EFPRINTF(fp, "[0001]\t\tSubtable Type : 02\n"); 274 EFPRINTF(fp,

Re: sha256 speed

There is support for the SHA intrinsic in aesni(4) that would be relatively easy to adapt to userspace for libmd, if someone was interested. Especially now that we demand linker ifunc support (on x86 platforms, at least). I posted a patch and some performance comparison in

Re: buildworld falure: truncated or malformed archive

There's always 'WITHOUT_CLANG=1' in src.conf. Best, Conrad On Mon, Dec 31, 2018 at 12:09 PM Warner Losh wrote: > > On Mon, Dec 31, 2018, 1:36 PM Ryan Stone > > Does this mean that it's currently impossible to build a world with > > debug symbols? > > > > Yes. Clang is simply too big until 64

Re: possible POLA violation for NFS server to make it Linux compatible

On Tue, Dec 18, 2018 at 5:07 PM Rick Macklem wrote: > The change to make the FreeBSD NFSv4 server use vfs.nfsd.nfs_privport is > trivial > and I think being compatible with Linux is important (I see it as the defacto > standard NFS implementation these days). > > What do others think I should

Re: toolchain(s) for universe kernels

I use: make -sj${NCPU} tinderbox JFLAG=-j${NCPU} UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN Best, Conrad On Mon, Nov 19, 2018 at 10:00 AM Eric van Gyzen wrote: > > I want to > > make MAKE_JUST_KERNELS=1 universe > > but it seems that I need a toolchain first. There are multiple >

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

Perfect! Sounds like we are on the right track, at least. Best, Conrad On Tue, Nov 13, 2018 at 8:55 PM Rebecca Cran wrote: > > On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote: > > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > > I.e.,

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

Please try r340426 :-). On Tue, Nov 13, 2018 at 8:41 PM Conrad Meyer wrote: > > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > I.e., sometimes the CPU chooses to report on a range from 0-225C and > sometimes -49C-206C. I think someone else's 2990WX did the

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

, sigh, it never landed: https://reviews.freebsd.org/D16855 Ok I'll go ahead and commit that too. Thanks, Conrad On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer wrote: > > On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran wrote: > > > > On Tuesday, 13 November 2018 21:17:59 MST

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran wrote: > > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote: > > > Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat > > plausible 75?C (still pretty warm even for load). How good is your > >

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

On Tue, Nov 13, 2018 at 8:05 PM Rebecca Cran wrote: > > On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote: > > > The 2700 has an offset of 0 though (2700X has 10). > > And I'm seeing a difference of more than 30 degrees. I guess something > > else must be happening here. > > I had

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

On Tue, Nov 13, 2018 at 7:16 PM Daniel Eischen wrote: > > On Tue, 13 Nov 2018, Conrad Meyer wrote: > > > On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen wrote: > >> I've attached it. If it gets filtered by the mail list, I'll > >> make it http accessible. > &

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

Of course, Johannes has already thought of this! See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228480 and https://reviews.freebsd.org/D15567 . On Tue, Nov 13, 2018 at 6:41 PM Conrad Meyer wrote: > > On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen wrote: > > I've attached it.

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen wrote: > I've attached it. If it gets filtered by the mail list, I'll > make it http accessible. Thanks Daniel. It looks like your hostbridge zero device has a different device id than in my first generation Ryzen system. Would you please try the

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

On Tue, Nov 13, 2018 at 5:15 PM Rozhuk Ivan wrote: > > On Tue, 13 Nov 2018 19:41:47 -0500 > Daniel Eischen wrote: > > > >> I'm trying to track down a couple of things. amdtemp doesn't > > >> report any temperature sensors, and acpi seems to have some > > >> errors. Not sure if they are

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

Hi Daniel, On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen wrote: > > Greetings, > > I'm trying to track down a couple of things. amdtemp doesn't > report any temperature sensors, and acpi seems to have some > errors. Not sure if they are related. Maybe not. If they do not attach, it

Re: Hole-punching, TRIM, etc

On Tue, Nov 13, 2018 at 2:59 PM Alan Somers wrote: > > On Tue, Nov 13, 2018 at 3:51 PM Conrad Meyer wrote: >> >> On Tue, Nov 13, 2018 at 2:10 PM Alan Somers wrote: >> > ... >> > 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP). >&g

Re: Hole-punching, TRIM, etc

Hi Alan, On Tue, Nov 13, 2018 at 2:10 PM Alan Somers wrote: > > Hole-punching has been discussed on these lists before[1]. It basically > means to turn a dense file into a sparse file by deallocating storage for > some of the blocks in the middle. There's no standard API for it. Linux > uses

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann wrote: > After kldload amdtemp I see the following sysctls: > dev.cpu.0.temperature: 77.1C > dev.amdtemp.0.core0.sensor0: 77.1C > > The temperature I see in BIOS is much lower (maybe around 40.0C). Don't > know if just the offset is wrong or the

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

One thing that may allow progress is explicitly passing the path to a new enough linker to make. In the past when some I encountered a similar problem (I use amd64-xtoolchain-gcc, amd64-gcc, and binutils for toolchain, and due to some miscommunication the wrong linker was selected automatically),

Re: newfs silently fails if random is not ready (?)

Differential up here: https://reviews.freebsd.org/D17049 for any lurkers I didn't manage to tag in the review. Best, Conrad On Wed, Sep 5, 2018 at 12:57 AM, Mark R V Murray wrote: > Nice catch! Thanks :-) > > M > > >> On 5 Sep 2018, at 04:13, Conrad Meyer wrote: >&

Re: newfs silently fails if random is not ready (?)

= EWOULDBLOCK) + error = 0; + KASSERT(error == 0, ("unexpected %d", error)); } if (error == 0) { read_rate_increment((uio->uio_resid + sizeof(uint32_t))/sizeof(uint32_t)); Best, Conrad On Tue, Sep 4, 2018 at 8:13 PM, Conrad Mey

Re: newfs silently fails if random is not ready (?)

Hi Lev, I took a first attempt at reproducing this problem on a fast desktop-class system. First steps, give us a way to revert back to unseeded status: --- a/sys/dev/random/fortuna.c +++ b/sys/dev/random/fortuna.c @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); #ifdef _KERNEL #include +#include

Re: newfs silently fails if random is not ready (?)

On Tue, Sep 4, 2018 at 2:10 PM, Lev Serebryakov wrote: > Wednesday, September 5, 2018, 12:05:43 AM, you wrote: >> 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? Yes, it should. > One

Re: newfs silently fails if random is not ready (?)

Hi Lev, 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

Re: newfs silently fails if random is not ready (?)

Hi Lev, 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

Re: github freebsd and svn freebsd

On Tue, Sep 4, 2018 at 3:32 AM, tech-lists wrote: > Hello list, > > What's the difference between github freebsd and svn freebsd, other than one > is on github and the other is on svn? The github repository is read-only mirror -- new additions all come through SVN. > How does one transcode or

Re: ffs_truncate3 panics

On Wed, Aug 8, 2018 at 5:30 AM, Rick Macklem wrote: > - Oh, and this is an old i386 with 256Mbytes (not one of them new fangled > computers, >where memory is in Gbytes;-) Have you run memtest86+ recently? Best, Conrad ___

Re: acpiconf -s 3 does not call acpi sleep event handlers

For those not on the bug, this is being followed up in PR 230290. On Wed, Aug 1, 2018 at 10:27 PM, Johannes Lundberg wrote: > > > On Thu, Aug 2, 2018 at 06:20 Andriy Gapon wrote: >> >> On 02/08/2018 01:17, Conrad Meyer wrote: >> > I don't understand the concer

Re: acpiconf -s 3 does not call acpi sleep event handlers

t; On Wed, Aug 1, 2018 at 22:55 Conrad Meyer wrote: >> >> ReqSleepState is the routine that takes care of suspend, not the >> eventhandler. I'm not sure what difference the proposed change is >> supposed to make. > > > Listeners to acpi_sleep_event don’t get

Re: acpiconf -s 3 does not call acpi sleep event handlers

ReqSleepState is the routine that takes care of suspend, not the eventhandler. I'm not sure what difference the proposed change is supposed to make. Best, Conrad On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg wrote: > > > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer wrote: >&

Re: acpiconf -s 3 does not call acpi sleep event handlers

It seems deliberate, although the commit message does not call it out and the event is perhaps poorly named. The event currently indicates that the lid was closed. And the final registered eventhandler for the event calls ReqSleepState. The ReqSleepState routine, as well as the userspace ioctl

Re: Changes to sysctl values

On Thu, Jul 26, 2018 at 8:52 PM, Shane Ambler wrote: > I use devel/py-sysctl in some scripts to get values, using a recent > 12-current (r336728) I see at least two values that get a different > value type than on 11-stable. Same version of python and port. > ... Hi Shane, At some point, new

Re: how do I use the make universe machines?

On Tue, Jun 5, 2018 at 6:12 PM, Benjamin Kaduk wrote: > On Wed, Jun 06, 2018 at 12:47:17AM +, Rick Macklem wrote: >> I've heard mention of "make universe" machines multiple times, >> but have no idea how to use them? >> Is there doc on this? >> >> Thanks, rick >> ps: I'll admit I haven't

Re: svn commit: r333240 - in head/sys: powerpc/powerpc sys [appears to have broken the builds of head for riscv64]

The same change as for powerpc needs to be made for riscv — the (bcopy) trick — to avoid expansion. Best, Conrad P.S., Mark, your email server is misconfigured and most/all of your emails get flagged as spam. I only saw this because I occasionally check the spam folder. On Sat, May 5, 2018 at

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

Hi Vitalij, On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij wrote: > DUMP can be found here http://hell.ukr.net/panic/panic.jpg > or even video record from screen http://hell.ukr.net/panic/recorder.webm Looks like the panic message is printed directly after: "igb0: using 2

Re: clang manual page?

stent manual page is of little > help. In fact, your 7 word response is an affirmation that > the tools supplied in base should be properly documented. > > -- > steve > > > > On Thu, Apr 05, 2018 at 05:42:58PM -0700, Conrad Meyer wrote: >> I never said it was in base

Re: clang manual page?

To a first order approximation, the manual page for clang is gcc(1). Conrad On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl wrote: > Is anyone working on fixing the clang manual to actually > document the available options? > > % man clang > (search for -std=) >

Re: clang manual page?

C++ standard library to use > > Does == ? > > -- > steve > > On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote: >> To a first order approximation, the manual page for clang is gcc(1). >> >> Conrad >> >> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl

Re: FreeBSD has a politics problem

John, A good portion of your original email happens to be inaccurate or misleading. In the spirit of good faith discussion, I'm going to assume you're just accidentally misinformed, and not willfully misrepresenting things. So, some corrections and clarifications follow. If you have further

Re: Kernel selection in Lua loader

On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans wrote: > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill wrote: >> >> ... >> kernels="kernel kernel.old kernel.save" >> >> and the Forth loader presented (precisely) those kernels as the >> available options

Re: pkg does not recognize correct kernel version

On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop wrote: > On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov > wrote: > >> Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD > > > Which man page? I can't find it in pkg help update or

Re: Since last week (today) current on my Ryzen box is unstable

On Sat, Feb 17, 2018 at 12:52 PM, Andrew Reilly wrote: > I've applied the patch, and the boot process is quiet now, but it's still > loading cc_vegas.ko, seemingly in response to seeing this device: (from > pciconf -l -v) > > none4@pci0:17:0:2: class=0x108000

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

On Tue, Feb 13, 2018 at 6:02 AM, David Wolfskill wrote: > On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote: >> >> > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error. >> > > At least, removing it fixes build for me. > > FWIW, I have

Re: multimedia/libvpx cause clang fatal error on CURRENT

Is this the same issue as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225488 ? That was fixed in r328513. Please try that revision if you're not at it yet. On Mon, Jan 29, 2018 at 7:57 PM, Iblis Lin wrote: > Hi, > > I got this while building multimedia/libvpx > >

Re: To which list should I submit a patch?

IMO, either is fine. I think documentation may refer to docs outside of the src tree, whereas this is in the src tree. Thanks for the submission. Best, Conrad On Thu, Jan 4, 2018 at 12:42 PM, Leonardo Fogel wrote: > > > Hi, > I have written a short patch that

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

Possibly because Xeon 5400 dates to 2007 — it may have less advanced speculative / out-of-order execution and may not have the same branch prediction algorithm as Haswell. On Thu, Jan 4, 2018 at 1:07 PM, Michael Butler wrote: > On 01/04/18 14:59, Klaus P.

Re: Poll: should man(1)'s default pager change to "less -s"?

nt using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > <cy.schub...@cschubert.com> or <c...@freebsd.org> > The need of the many outweighs the greed of the few. > --- >

Re: Poll: should man(1)'s default pager change to "less -s"?

On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl wrote: > There isn't a question. I'm pointing out your poll apparently > is limited to a select few individuals that use FreeBSD. The select few individuals being "literally anyone that wants to participate?"

Re: kernel panic: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)

Hi Wolfram, I believe r305900 broke it. I don't have any patch or workaround, sorry. It wouldn't be too hard for someone interested in virtualization to fix the issue. Please follow up in the bug :-). Best, Conrad On Wed, Nov 15, 2017 at 7:16 AM, Wolfram Schneider wrote:

Re: kernel panic: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)

Hi Wolfram, Looks like the same issue as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223531 . Best, Conrad On Wed, Nov 15, 2017 at 1:31 AM, Wolfram Schneider wrote: > Hi, > > I have a virtual machine running with FreeBSD 11-stable at a cloud > provider. It runs fine. I

Re: Encrypted Swap Problem with 12.0-CURRENT r324427

Thomas, Please try r32. Based on your panic message, "panic: freeing invalid range," it may be the same general swap issue which r32 aimed to address. Best, Conrad On Tue, Oct 10, 2017 at 2:20 PM, Thomas Laus wrote: > Allan Jude [allanj...@freebsd.org] wrote: >> >>

Re: C++ in jemalloc

On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and

Re: C++ in jemalloc

On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard wrote: > Luckily most kernel and world code that I actively use > does not throw C++ exceptions in my use. > > But devel/kyua is majorly broken by the C++ exception > issue: It makes extensive use of C++ exceptions. In my > view

Re: panic in AcpiOsGetTimer during boot.

Hey Rick, Are you running into the same issue reported on this svn-src thread? https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151775.html I believe jkim has reverted the change in a subsequent revision (r324136). Best, Conrad On Sun, Oct 1, 2017 at 3:12 PM, Rick Macklem

Re: r323694 amd64 - crash in linsysfs: Was: svn commit: r323692 - in head/sys/compat: linsysfs linux

Please try r323710. I believe you're running into the issue Hans noticed here: https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151324.html . It should be addressed in r323710. Sorry, Conrad ___ freebsd-current@freebsd.org mailing list

Re: Panic: @r323525: iflib

Well, we know it's due to r323516, but unfortunately can't have you bisect from there because it was committed as a giant lump. If it can't be fixed quickly, maybe it should be reverted? Best, Conrad On Wed, Sep 13, 2017 at 6:10 AM, David Wolfskill wrote: > My build

Re: extending the maximum filename length (pointer to patch)[request for input]

On Tue, Sep 12, 2017 at 2:23 PM, Rainer Duffner wrote: > And there’s also this bug: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067 > > "g_dev_taste: make_dev_p() failed on importing pool with snapshots with long > names“ > > > > But maybe that has nothing

Re: extending the maximum filename length (pointer to patch)[request for input]

On Tue, Sep 12, 2017 at 2:11 PM, Ben RUBSON wrote: > Hi Conrad, > > This patch makes me think about another related bug #184340 : > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 > It is about PATH_MAX which in some cases can be too small. > > Not sure if it's the

Re: extending the maximum filename length

On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer wrote: > maybe we could get it into -current. > It'd be silly to have to have people re-inventing hte wheel all the time. > How about you put those changes into the reviews.freebsd.org and we can get > some general consensus on

Re: extending the maximum filename length

On Fri, Sep 8, 2017 at 10:21 AM, David Wolfskill wrote: > On Sat, Sep 09, 2017 at 01:15:31AM +0800, Julian Elischer wrote: >> Has anyone using freeBSD ever increased NAME_MAX (filename maximum >> length) and have any experience with it? >> >> We ($JOB) would recompile the

Re: extending the maximum filename length

On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer wrote: > Has anyone using freeBSD ever increased NAME_MAX (filename maximum length) > and have any experience with it? > > We ($JOB) would recompile the entire system so intra-system compatibility > would probably be ok, and we

Re: 64-bit inodes (ino64) Status Update and Call for Testing

Hi Jilles, Thanks for bringing this up. And of course, thanks to kib@ for including the d_namlen size bump and for his work in driving the rest of this change through to completion. On Sun, May 21, 2017 at 5:14 AM, Jilles Tjoelker wrote: > We have another type in this area

Re: svn commit: r316977 - head/sys/dev/syscons

On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann wrote: > Am Sat, 15 Apr 2017 20:03:50 + (UTC) > Bruce Evans schrieb: > >> Author: bde >> Date: Sat Apr 15 20:03:50 2017 >> New Revision: 316977 >> URL: https://svnweb.freebsd.org/changeset/base/316977 > >

Re: panic: invalid bcd xxx

On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen wrote: > Your system's real-time clock is returning garbage. r312702 added some > input validation a few weeks ago. Previously, the kernel was reading beyond > the end of an array and either complaining about the clock or

Re: 'Protocol not supported' on linux socket call ( r313313 amd64 )

Hi Oleg, It seems likely it is related to r313284. Best, Conrad On Wed, Feb 8, 2017 at 7:44 AM, Oleg V. Nauman wrote: > After upgrading of current on amd64 box to r313313 I noticed that skype has > stopped working. > Below is the end of 'truss' output for skype: > >

Re: ASLR

On Wed, Jan 18, 2017 at 9:53 AM, Johannes Lundberg wrote: > Hi > > What is the status of ASLR? > > https://reviews.freebsd.org/D5603 > > The thread has been silent for a couple of months. I'm happy to test if > needed. Hi Johannes, I think we were waiting on some review, but

Re: r311674: buildworld failure: iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'

Please try r311675. Thanks, Conrad On Sun, Jan 8, 2017 at 1:05 AM, O. Hartmann wrote: > It seems, the most recent CURRENT sources are broken (r311674), buildworld > failure occur > at: > > [...] > --- cd9660.o --- > In file included from

  1   2   >