Maybe I misunderstood after all.
I took this:
"You can work around it temporarily by setting a lower arc_min first."
To mean that I could do something like:
vfs.zfs.arc_min="1073741824"
vfs.zfs.arc_max="8589934592"
in loader.conf, which would circumvent the problem.
But with the above, in that or
FreeBSD_HEAD_amd64_gcc - Build #1344 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1344/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1344/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1344/c
OK, I follow you now.
Thanks for the explanation.
I will try that later tonight or tomorrow.
On Tue, Jul 5, 2016 at 9:45 PM, Allan Jude wrote:
> On 2016-07-05 21:32, Nathan Bosley wrote:
> > I think in about 4 - 5 hours I can show what values I'm using in
> > loader.conf under, say, r302264 and
On 2016-07-05 21:32, Nathan Bosley wrote:
> I think in about 4 - 5 hours I can show what values I'm using in
> loader.conf under, say, r302264 and r302265 for comparison. I'm not 100%
> sure that the problem arose for me in r302265; I merely suspect it.
>
> On Tue, Jul 5, 2016 at 9:25 PM, Allan Ju
FreeBSD_HEAD_amd64_gcc - Build #1343 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1343/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1343/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1343/c
I think in about 4 - 5 hours I can show what values I'm using in
loader.conf under, say, r302264 and r302265 for comparison. I'm not 100%
sure that the problem arose for me in r302265; I merely suspect it.
On Tue, Jul 5, 2016 at 9:25 PM, Allan Jude wrote:
> On 2016-07-05 20:27, Steven Hartland w
On 2016-07-05 20:27, Steven Hartland wrote:
> Ahh right, let me check that.
>
> On 06/07/2016 00:51, Nathan Bosley wrote:
>> I actually have this same problem.
>> I'll send more details when I get home later.
>>
>> I think the problem started for me after r302265.
>> Before that, I can set vfs.zfs
Ahh right, let me check that.
On 06/07/2016 00:51, Nathan Bosley wrote:
I actually have this same problem.
I'll send more details when I get home later.
I think the problem started for me after r302265.
Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in loader.conf.
After r302265, se
I actually have this same problem.
I'll send more details when I get home later.
I think the problem started for me after r302265.
Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in loader.conf.
After r302265, setting either vfs.zfs.arc_max or vfs.zfs.arc_min in
loader.conf results in t
What is it currently?
Just had a quick play here:
sysctl vfs.zfs.arc_max
vfs.zfs.arc_max: 32283127808
sysctl vfs.zfs.arc_max=32283127807
vfs.zfs.arc_max: 32283127808 -> 32283127807
sysctl vfs.zfs.arc_max=32283127808
vfs.zfs.arc_max: 32283127807 -> 32283127808
Error 22 = EINVAL so I suspect you'r
FreeBSD_HEAD_amd64_gcc - Build #1342 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1342/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1342/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1342/c
Steven and -current:
I just updated to r302350 with a GENERIC kernel config. I see this in
dmesg:
VT(efifb): resolution 1024x768
Setting sysctl vfs.zfs.arc_max failed: 22
CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3491.98-MHz K8-class
CPU)
The relevant parts of /boot/loader
Answering to myself
On 07/05/16 15:24, Pedro Giffuni wrote:
Hmm ...
On 07/05/16 15:14, Conrad Meyer wrote:
Whoops, missed reply-all the first time.
It seems pretty clear that alloc_size (return value is a memory
allocation of size from parameter N) does not apply to posix_memalign,
becau
Hmm ...
On 07/05/16 15:14, Conrad Meyer wrote:
Whoops, missed reply-all the first time.
It seems pretty clear that alloc_size (return value is a memory
allocation of size from parameter N) does not apply to posix_memalign,
because posix_memalign's allocation is stored via a pointer argument
rat
Whoops, missed reply-all the first time.
It seems pretty clear that alloc_size (return value is a memory
allocation of size from parameter N) does not apply to posix_memalign,
because posix_memalign's allocation is stored via a pointer argument
rather than return value.
https://gcc.gnu.org/online
Hi,
It looks like clang 3.3/3.4 from ports both don’t like __alloc_size
being attached to posix_memalign. This only concerns me because it might make
the src upgrade path from 9.3/10.3 to 11.0 painful.
Thoughts on how this should be fixed or whether or not we care?
Thanks,
-Ngie
> On Jul 5, 2016, at 12:29, Ngie Cooper (yaneurabeya)
> wrote:
…
> Actually, there’s a better #define:
>
> /usr/include/x86/specialreg.h:#define CPUID2_SSE410x0008
Submitted a potential fix via: https://reviews.freebsd.org/D7119 .
Thanks,
-Ngie
signature.asc
Description: Message
>> Are you sure the portsnap process finished successfully? It appears to
>> be trying to use the FreeBSD 9.x/10.x syntax for adding the dependencies
>> of dialog4ports, rather than the 11.x method.
>>
>
> Nope the opposite :)
>
> dialog4ports uses bsd.prog.mk, somehow his make ends up using the
> On Jul 5, 2016, at 11:54, Ngie Cooper (yaneurabeya)
> wrote:
>
>>
>> On Jul 5, 2016, at 11:52, Dimitry Andric wrote:
>>
>> On 05 Jul 2016, at 18:03, jenkins-ad...@freebsd.org wrote:
>>>
>>> FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing:
>>>
>>> Build information:
>>> https://jenk
FreeBSD_HEAD_amd64_gcc - Build #1341 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1341/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1341/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1341/c
> On Jul 5, 2016, at 11:52, Dimitry Andric wrote:
>
> On 05 Jul 2016, at 18:03, jenkins-ad...@freebsd.org wrote:
>>
>> FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing:
>>
>> Build information:
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/
>> Full change log:
>> https:/
On 05 Jul 2016, at 18:03, jenkins-ad...@freebsd.org wrote:
>
> FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing:
>
> Build information:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/
> Full change log:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/changes
> F
Main disk would not boot cleanly.
could not fsck_ffs, cannot find inode
files went missing from /etc (make.conf, pf.conf, firewall*,
file went missing from rc.d
files went missing from /etc/X11
shell history file remained locked.
find suddenly could not find /usr/local/lib/*/libc.so.5
freecolor co
FreeBSD_HEAD_amd64_gcc - Build #1340 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1340/c
On 2016-07-05 10:10, Jonathan Anderson wrote:
> On 5 Jul 2016, at 6:35, Marin BERNARD wrote:
>
>> Hi all,
>>
>> Ive been trying to install FreeBSD Current (11.0 ALPHA5 & ALPHA6) with
>> encrypted root on ZFS, and was unable to complete the setup process. The
>> installation stops just after the
On 5 Jul 2016, at 6:35, Marin BERNARD wrote:
Hi all,
Ive been trying to install FreeBSD Current (11.0 ALPHA5 & ALPHA6)
with
encrypted root on ZFS, and was unable to complete the setup process.
The
installation stops just after the GELI volume is initialized, and
bsdinstall(8) reports : mkd
FreeBSD_HEAD_amd64_gcc - Build #1339 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1339/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1339/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1339/c
Hi all,
Ive been trying to install FreeBSD Current (11.0 ALPHA5 & ALPHA6) with
encrypted root on ZFS, and was unable to complete the setup process. The
installation stops just after the GELI volume is initialized, and
bsdinstall(8) reports : mkdir : /mnt/boot : No such file or directory. The
deb
FreeBSD_HEAD_amd64_gcc - Build #1338 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1338/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1338/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1338/c
On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote:
> These 2 files can make ls suck:
>
> touch 火灾1
> touch 火灾2
>
> 2 files start with 2 same Chinese chars.
>
I cannot reproduce on my head laptop, neither on a clean 11.0-ALPHA6 jail.
I'll try on a clean 11.0-ALPHA6 VM
Best regards,
FreeBSD_HEAD_amd64_gcc - Build #1337 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1337/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1337/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1337/c
31 matches
Mail list logo