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
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
header named "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-
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
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
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
>
> Th
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 r363679
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 us
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 change
quite some 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:
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' i
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 f
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.
It
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
conf.
>>
>> On a side note I cannot set or unset that hint from loader prompt;
>>
>> ok> set hint.hwpstate_intel.0.disabled="0"
>> ok> show
>>
>> hint.hwpstate=
>> ...
>>
>> Best regards
>> Andreas
>>
>>
Yep, amd is deprecated for 13.0:
https://svnweb.freebsd.org/base?view=revision&revision=354902 ,
https://svnweb.freebsd.org/base?view=revision&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
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 b
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 conta
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.
>
> yasu@rolling-vm-freeb
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 both
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 exp
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
bui
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 insta
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
#include
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 s
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 11:0
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 ru
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
>
> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_v
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 r347327=4f47587(svn_h
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 h
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) …
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 wi
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
https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-
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, "[0001]\t\tLen
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 https://svnweb.freebsd.
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 bi
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 do?
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
> toolc
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?
> >
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 2990W
3°C.
Yeah, 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 201
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
> > coo
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 thou
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 accessib
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 attache
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
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 related.
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 suggests
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).
>>
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 f
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 number
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),
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:
&g
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));
Best,
Conrad
On Tue, Sep 4, 2
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
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 secon
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 routin
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 arc4random(3)
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 t
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
___
freebsd-current@freebsd.o
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 conc
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’
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:
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 t
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 sys
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 looke
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 4
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
rx queues 2 tx qu
ttle
> 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.
>>
>> On Thu
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=)
>-std=
> Specify
gt; 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
>> wrote:
>
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 que
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 for selecting a kernel to load and boot.
>>
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 pkg help upgrade or
> man pkg.
I had to di
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 card=0x14561022 chip=0x14561022
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 never specified WITH_A
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
>
> ```
> cc -O2 -pipe -ma
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 replaces the legacy interface make
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. Ohrhallinger wrote:
>> On 04.01.2018 19:5
keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
>
> Cy Schubert
> or
> The need of the many outweighs the greed of the few.
> ---
>
> From: Conrad Meyer
> Sent: 12/12/2017
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?" https://reviews.freebsd.org/auth/registe
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:
> Hi Conrad,
>
> tha
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 tried to upgrade to
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:
>>
>> Before the ddb> prom
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 uses them only for e
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 that disqualifies clang
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 wrote:
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
h
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 machine didn't have the prob
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 to do with it.
Hi Rainer,
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 case / and how to do it
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 them.
> We'll have to
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 entire system so intra-sy
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 have our own filesyst
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 which is too small in
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
>
> There is a lot of development going on thes
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 setting it to
> the wrong
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:
>
> 36723: linux_socketcall(1,
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 if that has stalled
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 /usr/src/usr.sbin/makefs/cd9660.c:108:
> In file include
1 - 100 of 139 matches
Mail list logo
