> On 8 Apr 2023, at 20:21, Gary Jennejohn wrote:
>
> This isn't a fatal error, but it would be easy to fix:
>
> /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function
> 'inet6_get_plen' [-Wunused-function]
> inet6_get_plen(const struct in6_a
This isn't a fatal error, but it would be easy to fix:
/usr/src/sys/netlink/route/iface.c:738:1: warning: unused function
'inet6_get_plen' [-Wunused-function]
inet6_get_plen(const struct in6_addr *addr)
^
1 warning generated.
This function is called in get_sa_plen(const struct so
x27;m running CURRENT 8d95f500521 and I'm receiving loads of dmesg
warnings:
---
ACPI Warning: Firmware issue: Excessive sleep time
(0x0010
ms >
10 ms) in ACPI Control Method (20220331/exsystem-347)
---
Is there a way to silence it?
I think this spam message is from linux.
>> What do you think opening a review about this fix/tweak to stop this
>> spamming that blinds dmesg?
[snip]
FYI, both FreeBSD and Linux use ACPICA to implement ACPI.
https://acpica.org
This message was added by this commit:
https://github
receiving loads of dmesg
warnings:
---
ACPI Warning: Firmware issue: Excessive sleep time
(0x0010
ms >
10 ms) in ACPI Control Method (20220331/exsystem-347)
---
Is there a way to silence it?
I think this spam message is from linux.
So, I think we should discuss on linu
---
ACPI Warning: Firmware issue: Excessive sleep time
(0x0010
ms >
10 ms) in ACPI Control Method (20220331/exsystem-347)
---
Is there a way to silence it?
I think this spam message is from linux.
So, I think we should discuss on linux forum but I don't familier
to
On 22. 6. 13., Jung-uk Kim wrote:
On 22. 6. 13., Masachika ISHIZUKA wrote:
What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?
I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
warnings:
---
ACPI Warning: Firmware issue:
On 22. 6. 13., Masachika ISHIZUKA wrote:
What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?
I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
warnings:
---
ACPI Warning: Firmware issue: Excessive sleep time (0x00
> What do you think opening a review about this fix/tweak to stop this
> spamming that blinds dmesg?
>
>> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
>> warnings:
>> > ---
>> > ACPI Warning: Firmware issue: Excessive s
What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?
Masachika ISHIZUKA escreveu no dia domingo,
12/06/2022 à(s) 09:03:
> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
> warnings:
> > ---
> &g
> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings:
> ---
> ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms >
> 10 ms) in ACPI Control Method (20220331/exsystem-347)
> ---
> Is there a way to silence it?
Hi.
Hello,
I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings:
---
ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms >
10 ms) in ACPI Control Method (20220331/exsystem-347)
---
Is there a way to silence it?
Thanks in advance,
Nuno Teixeira
cue
> > > them and store the data on ZFS volumes. Mounting of the HDD doesn't work,
> > > FreeBSD
> > > 12.3 obviously lack in some etx2 features, namely "needs_recovery". The
> > > kernel
> > > reports:
> > >
> > >
x27;t work, FreeBSD
> > 12.3 obviously
> > lack in some etx2 features, namely "needs_recovery". The kernel reports:
> >
> > WARNING: mount of da4p3 denied due to unsupported optional features:
> > needs_recovery
> >
> > How can this problem be solved?
>
ot;. The kernel reports:
WARNING: mount of da4p3 denied due to unsupported optional features:
needs_recovery
How can this problem be solved?
Thanks in advance,
oh
Probably as the name of the mailing list suggest you should upgrade to
14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix
Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue
them and
store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3
obviously
lack in some etx2 features, namely "needs_recovery". The kernel reports:
WARNING: mount of da4p
I'm using 14.0-current on old DELL xps12 notebook.
Xconsole on it is fillfulled the 'ACPI Warning: Firmware issue:
Excessive sleep time (0x0014 ms > 10 ms) in ACPI
Control Method (20220331/exsystem-347)' messages and I'm failling
to see other important messages.
# ls -l, *
/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero
offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/main-src/lib/libc/stdio/fread.c:133:10 in
==47404==AddressSanitizer: WARNING: unexpected format specifier in printf
aarch64 1400043 1400043
my boot sequences are getting a report of:
# dmesg -a | grep zfsk
/etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5).
for the likes of a system (aarch64 example) based on:
# gpart show
=>40 2000409184 ada0 GPT (954G)
40 409
Am Wed, 11 Aug 2021 15:03:54 -0400
Ed Maste schrieb:
> On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote:
> >
> > Hallo,
> >
> > latest upgrade of CURRENT sources renders buildworld into failure, box is
> > running
> > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST
>
On Wed, Aug 11, 2021, 3:52 PM FreeBSD User wrote:
> Am Wed, 11 Aug 2021 15:03:54 -0400
> Ed Maste schrieb:
>
> > On Wed, 11 Aug 2021 at 05:41, FreeBSD User
> wrote:
> > >
> > > Hallo,
> > >
> > > latest upgrade of CURRENT sources renders buildworld into failure, box
> is running
> > > FreeBSD 1
Am Wed, 11 Aug 2021 15:03:54 -0400
Ed Maste schrieb:
> On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote:
> >
> > Hallo,
> >
> > latest upgrade of CURRENT sources renders buildworld into failure, box is
> > running
> > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST
>
On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote:
>
> Hallo,
>
> latest upgrade of CURRENT sources renders buildworld into failure, box is
> running
> FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST
> 2021 amd64:
Assuming this was with BEARSSL enabled, it should be fi
bin --- --- all_subdir_sbin/dmesg ---
===> sbin/dmesg
(all) --- all_subdir_stand --- ar: warning: can't open file: ccopy.pieo: No
such file or
directory 1.72 real 3.57 user 1.07 sys
Kind regards
oh
--
O. Hartmann
Hello Jonh!
I did it and it worked fine:
etcupdate extract
etcupdate diff > /tmp/etc.diff
cd /
patch -R < /tmp/etc.diff
Patch can't find diff paths so I run it inside /etc /etc/defalts ... until
all diff is applied.
Now when I run 'etcupdate' I don't get any w
On 22 Jun 2021, at 20:24, John Baldwin wrote:
>
> On 6/22/21 11:13 AM, O. Hartmann wrote:
>> Hello,
>> on a recent CURRENT (FreeBSD 14.0-CURRENT #6 main-n247512-e3be51b2bc7c: Tue
>> Jun 22 15:31:03
>> CEST 2021 amd64) we build a 13-STABLE based NanoBSD from a dedicated source
>> tree for a smal
On 6/22/21 11:13 AM, O. Hartmann wrote:
Hello,
on a recent CURRENT (FreeBSD 14.0-CURRENT #6 main-n247512-e3be51b2bc7c: Tue Jun
22 15:31:03
CEST 2021 amd64) we build a 13-STABLE based NanoBSD from a dedicated source
tree for a small
routing appliance. It should be " ...we built ..." because sin
On 6/22/21 12:34 AM, Nuno Teixeira wrote:
Hello,
Should I be worry about etcupdate warning "No previous tree to compare
against, a sane comparison is not possible." when I recompile and update
current?
I receive same warning when I do a 'etcupdate -p' after installworld to
apu2c4/src/sys/amd64/acpica/acpi_wakecode.S
error:
unknown -Werror warning specifier: '-Wno-error-tautological-compare'
[-Werror,-Wunknown-warning-option] error: unknown -Werror warning specifier:
'-Wno-error-empty-body' [-Werror,-Wunknown-warning-option] error: unknown
Hello,
Should I be worry about etcupdate warning "No previous tree to compare
against, a sane comparison is not possible." when I recompile and update
current?
I receive same warning when I do a 'etcupdate -p' after installworld too.
Thanks,
Nuno Teixeira
oot or log console messages:
> >
> > [...]
> > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD
> > 13.0.
> >
> > Where does this message come from and what is causing the warning? I tried
> > to identify
> > and eliminate this message,
From: Mark Millard
Subject: Re: WARNING: Device "kbd" is Giant locked and may be deleted before
FreeBSD 13.0.
Date: Fri, 15 Jan 2021 16:54:26 -0800
> Other examples for the general type of question . . .
>
>
> For example, various aarch64, armv7, and powerpc*:
>
&g
On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O.
wrote:
> Running FreeBSD CURRENT on a USB only platform with a customised kernel, I
> see this
> message all the time I reboot or log console messages:
>
> [...]
> WARNING: Device "kbd" is Giant locked and may be d
Running FreeBSD CURRENT on a USB only platform with a customised kernel, I see
this
message all the time I reboot or log console messages:
[...]
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
Where does this message come from and what is causing the
On Fri, 2 Nov 2018, Hans Petter Selasky wrote:
> On 11/2/18 5:24 PM, Enji Cooper (yaneurabeya) wrote:
> > signed ioctl value warnings
> > in uhsoctl().
>
> Here you go:
>
> https://svnweb.freebsd.org/changeset/base/340089
Thanks!
Marcin
smime.p7s
Description: S/MIME Cryptographic Signature
On 11/2/18 5:24 PM, Enji Cooper (yaneurabeya) wrote:
signed ioctl value warnings
in uhsoctl().
Here you go:
https://svnweb.freebsd.org/changeset/base/340089
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinf
FYI!
> On Oct 25, 2018, at 4:38 AM, Marcin Cieslak wrote:
>
> The following patch seems to fix the signed ioctl value warnings
> in uhsoctl().
>
> The code is the same in the current and stable branches.
>
> Marcin
>
> Index: usr.sbin/uhsoctl/uhsoctl.c
> ==
On 10/26/18 10:48 AM, Dag-Erling Smørgrav wrote:
Rebecca Cran writes:
After installing 12.0-BETA1, on the first boot I noticed a warning
about $local_unbound_tls not being set properly.
Ah, I should probably have added it to /etc/defaults/rc.conf. Can you
do that (just set it to “no”) and
Rebecca Cran writes:
> After installing 12.0-BETA1, on the first boot I noticed a warning
> about $local_unbound_tls not being set properly.
Ah, I should probably have added it to /etc/defaults/rc.conf. Can you
do that (just set it to “no”) and let me know if it helps?
DES
--
Dag-
After installing 12.0-BETA1, on the first boot I noticed a warning about
$local_unbound_tls not being set properly.
It looks like that flag was only added recently by Dag-Erling, in "Add
support for DNS-over-TLS to the local_unbound service."
On Thu, Oct 25, 2018 at 10:46 AM Warner Losh wrote:
>
>
> On Thu, Oct 25, 2018 at 10:26 AM Rebecca Cran
> wrote:
>
>> On 10/25/18 10:20 AM, Rebecca Cran wrote:
>>
>> >
>> > uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0
>> > uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR
On 10/25/18 10:46 AM, Warner Losh wrote:
Oh! that looks mostly right, though IIRC the higher UIDs might be
something else. Harmless enough for now, though.
Thanks.
I also think you might be able to test if we can remove a special case
kludge we have for the AMDI0020 device since it look
On Thu, Oct 25, 2018 at 10:26 AM Rebecca Cran wrote:
> On 10/25/18 10:20 AM, Rebecca Cran wrote:
>
> >
> > uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0
> > uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1
> > uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2
>
On 10/25/18 10:20 AM, Rebecca Cran wrote:
uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0
uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1
uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2
uart3 pnpinfo _HID=AMDI0020 _UID=3 at handle=\_SB_.FUR3
Also, in c
On 10/25/18 10:18 AM, Warner Losh wrote:
That seems incorrect. It looks like we're attaching too much. what does
devinfo -v | grep uart tell you?
uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0
uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1
uart2 pnpinfo _HID=AMD
On Thu, Oct 25, 2018 at 10:16 AM Rebecca Cran wrote:
> On 10/25/18 10:00 AM, Warner Losh wrote:
>
> >
> > I suspect you can just lose those hints in the hints file and be fine.
> The
> > uart should attach via acpi. The keyboard won't, however, since it isn't
> > enabled. Can you try removing the
On 10/25/18 10:00 AM, Warner Losh wrote:
I suspect you can just lose those hints in the hints file and be fine. The
uart should attach via acpi. The keyboard won't, however, since it isn't
enabled. Can you try removing these lines from your hints file and see if
the problem persists? Note this
On Thu, Oct 25, 2018 at 9:35 AM Rebecca Cran wrote:
> On 10/25/18 5:02 AM, Rodney W. Grimes wrote:
>
> > Can you please reply with the specific device.
> > If you have seen one it may be an issue to removing it,
> > especially if this is on a "new AMD" system.
>
>
> This is a new Ryzen system. Fo
On 10/25/18 5:02 AM, Rodney W. Grimes wrote:
Can you please reply with the specific device.
If you have seen one it may be an issue to removing it,
especially if this is on a "new AMD" system.
This is a new Ryzen system. For me, I get warnings about atkbdc0 and uart0:
atkbdc0: at port 0x60
> On Thu, Oct 25, 2018 at 8:10 AM Eric van Gyzen wrote:
>
> > On 10/25/18 6:57 AM, Rodney W. Grimes wrote:
> > >>> I noticed a warning on a new AMD system running 12-BETA1:
> > >>>
> > >>> non-PNP ISA device will be removed from GE
On Thu, Oct 25, 2018 at 8:10 AM Eric van Gyzen wrote:
> On 10/25/18 6:57 AM, Rodney W. Grimes wrote:
> >>> I noticed a warning on a new AMD system running 12-BETA1:
> >>>
> >>> non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
> >&g
On 10/25/18 6:57 AM, Rodney W. Grimes wrote:
I noticed a warning on a new AMD system running 12-BETA1:
non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
Can you please reply with the specific device.
If you have seen one it may be an issue to removing it,
especially if this is on
> > I noticed a warning on a new AMD system running 12-BETA1:
> >
> > non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
> Can you please reply with the specific device.
> If you have seen one it may be an issue to removing it,
> especially if th
The following patch seems to fix the signed ioctl value warnings
in uhsoctl().
The code is the same in the current and stable branches.
Marcin
Index: usr.sbin/uhsoctl/uhsoctl.c
===
--- usr.sbin/uhsoctl/uhsoctl.c (revision 339406)
+
> I noticed a warning on a new AMD system running 12-BETA1:
>
> non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
Can you please reply with the specific device.
If you have seen one it may be an issue to removing it,
especially if this is on a "new AMD" sys
I noticed a warning on a new AMD system running 12-BETA1:
non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
It looks like it was introduced by Warner in r327120. Should those devices have
been removed already?
—
Rebecca
___
freebsd
tuexen@head:~/head/sys/i386/conf % config -g TCP
> WARNING: duplicate option `GEOM_PART_GPT' encountered.
> Kernel build directory is ../compile/TCP
> Don't forget to do ``make cleandepend && make depend''
> tuexen@head:~/head/sys/i386/conf % cd ../
> +.endif
Using this patch I was able to build/install world and kernel on an i386 system.
However, after removing it, I can't build world then. When trying to compile a
kernel "the old way" I end up with:
tuexen@head:~/head/sys/i386/conf % config -g TCP
WARNING: duplicate option `G
On 9/21/18 10:10 PM, Rebecca Cran wrote:
> On 9/21/18 10:00 PM, Warner Losh wrote:
>
>> That may be the issue... Does the patch I included help? I'm building now
>> on my stable system, but it's slow...
>
> It does seem to have got further this time, so a cautious yes.
I can change that to a def
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),
On 9/21/18 10:00 PM, Warner Losh wrote:
> That may be the issue... Does the patch I included help? I'm building now
> on my stable system, but it's slow...
It does seem to have got further this time, so a cautious yes.
--
Rebecca
___
freebsd-curren
On 9/21/18 9:57 PM, Warner Losh wrote:
> Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
>
> They look good for me, but the only way you get this error is if they
> are wrong.
bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE
bfd
bcran@cube:~/workspace/freebsd % make -V
On Fri, Sep 21, 2018 at 9:59 PM Rebecca Cran wrote:
> On 9/21/18 9:57 PM, Warner Losh wrote:
>
> > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
> >
> > They look good for me, but the only way you get this error is if they
> > are wrong.
>
>
> bcran@cube:~/workspace/freebsd
Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
They look good for me, but the only way you get this error is if they are
wrong.
Although from your typescript, I see:
===> lib/libc (cleandir)
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc
On Fri, Sep 21, 2018 at 9:34 PM Warner Losh wrote:
>
>
> On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote:
>
>> On 9/21/18 9:09 PM, Warner Losh wrote:
>>
>> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
>> > freebsd-toolch...@freebsd.org> wrote:
>> >
>> >> On 9/21/18 4
On 9/21/18 9:34 PM, Warner Losh wrote:
> What does ld.lld say?
>
> However, it shouldn't matter: we don't build libc until *AFTER* we
> build ld.lld, so this error is bogusly triggering. I suspect that it
> needs to be limited to only building targets, since tree traversal
> ones, as well as inst
On 9/21/18 9:35 PM, Warner Losh wrote:
>
> I meant to add, can you give a few lines before the error is spewed
> here in email? My IRC computer died before I could see any answers
> there...
>
> My 11.2-stable system has 6.0.1, so I can't test from there.
I've uploaded the full 'buildworld' outpu
On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote:
> On 9/21/18 9:09 PM, Warner Losh wrote:
>
> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
> > freebsd-toolch...@freebsd.org> wrote:
> >
> >> On 9/21/18 4:06 PM, Mark Johnston wrote:
> >>> https://reviews.freebsd.org/D17
On 9/21/18 9:09 PM, Warner Losh wrote:
> On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
> freebsd-toolch...@freebsd.org> wrote:
>
>> On 9/21/18 4:06 PM, Mark Johnston wrote:
>>> https://reviews.freebsd.org/D17279 for anyone else that would like to
>>> review.
>>
>> Is that po
On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
freebsd-toolch...@freebsd.org> wrote:
> On 9/21/18 4:06 PM, Mark Johnston wrote:
> >
> > https://reviews.freebsd.org/D17279 for anyone else that would like to
> > review.
>
>
> Is that possibly related to the error I'm getting tr
On 9/21/18 4:06 PM, Mark Johnston wrote:
>
> https://reviews.freebsd.org/D17279 for anyone else that would like to
> review.
Is that possibly related to the error I'm getting trying to build
-CURRENT on 11.2?
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc req
On Fri, Sep 21, 2018 at 04:37:08PM -0400, Ed Maste wrote:
> On 21 September 2018 at 15:31, Mark Johnston wrote:
> >
> > Perhaps the following? It's not quite right since it'll still use
> > -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> > figure out how to define a linker fe
On 21 September 2018 at 15:31, Mark Johnston wrote:
>
> Perhaps the following? It's not quite right since it'll still use
> -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> figure out how to define a linker feature for only non-cross toolchains.
> In any case, we're going to u
On Fri, Sep 21, 2018 at 02:54:04PM -0400, Ed Maste wrote:
> On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
> wrote:
> > In looking into another report about using devel/amd64-gcc to buld
> > head I tried a build of -r338675 ( with WERROR= ). It got:
> >
> ...
> >
> > Question:
>
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
wrote:
> In looking into another report about using devel/amd64-gcc to buld
> head I tried a build of -r338675 ( with WERROR= ). It got:
>
...
>
> Question:
>
> Is ignoring "-z ifunc-noplt" a problem for using what
> is built?
This
In looking into another report about using devel/amd64-gcc to buld
head I tried a build of -r338675 ( with WERROR= ). It got:
--- kernel.full ---
linking kernel.full
/usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored.
ctfmerge -L VERSION -g -o kernel.full ...
text
On Tue, Jun 27, 2017 at 1:56 PM, Trond Endrestøl <
trond.endres...@fagskolen.gjovik.no> wrote:
> On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote:
>
> > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
> >
> > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > >
On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
>
> > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> > >
> > > This patch made ruby23 happy on my end.
On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
> On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> >
> > This patch made ruby23 happy on my end. Can't say the same for
> > emacs-nox11 or temacs while building the
On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote:
>
> > On Jun 26, 2017, at 13:25, Konstantin Belousov wrote:
> >
> > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
> >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov
> >> wrote:
> >>
> >>> No need, I understoo
> On Jun 26, 2017, at 13:25, Konstantin Belousov wrote:
>
> On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
>> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov
>> wrote:
>>
>>> No need, I understood why MAP_STACK failed in this case, thanks to the
>>> ktrace log. This is i
On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov
> wrote:
>
> > No need, I understood why MAP_STACK failed in this case, thanks to the
> > ktrace log. This is indeed something ruby-specific, or rather, triggered
> > by ruby sp
On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov
wrote:
> No need, I understood why MAP_STACK failed in this case, thanks to the
> ktrace log. This is indeed something ruby-specific, or rather, triggered
> by ruby special use of libthr. It is not related to the main stack
> split.
>
> It see
On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > https://people.freebsd.org/~kib/misc/vm2.2.patch
>
> This patch made ruby23 happy on my end. Can't say the same for
> emacs-nox11 or temacs while building the former.
What exactly do you mean ? Explain the behaviour and show t
On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote:
> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> >
> > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov
> > > wrote:
> > >
> > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
> > >> maybe message go
> On Jun 25, 2017, at 10:21 AM, Konstantin Belousov wrote:
>
> On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote:
>>
>>> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov
>>> wrote:
>>>
>>> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> On Jun 25, 2017,
On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote:
>
> > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov
> > wrote:
> >
> > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> >>
> >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov
> >>> wrote:
> >>>
> >>> On Sun
> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov wrote:
>
> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
>>
>>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov
>>> wrote:
>>>
>>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
maybe message got reform
On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
>
> > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov
> > wrote:
> >
> > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
> >> maybe message got reformatted in mail program (mac mail).
> >> could you send me a tar fil
> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > > > >>>> New world and kernel r320323
> > > > > >>>> I get a new error or message when using ruby:
> > > > > >>>>
> > > > > >>>>
&g
017, at 6:23 PM, Konstantin Belousov
> > > > >>> wrote:
> > > > >>>
> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > > >>>> New world and kernel r320323
> > > > &g
t; > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > >>>> New world and kernel r320323
> > > >>>> I get a new error or message when using ruby:
> > > >>>>
> > > >>>>
> >
and kernel r320323
> > >>>> I get a new error or message when using ruby:
> > >>>>
> > >>>>
> > >>>> /usr/local/sbin/portupgrade -av
> > >>>> : warning: pthread_create failed for timer: Resource temporar
nstantin Belousov
> >>> wrote:
> >>>
> >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> >>>> New world and kernel r320323
> >>>> I get a new error or message when using ruby:
> >>>>
> >
700, Manfred Antar wrote:
>>>> New world and kernel r320323
>>>> I get a new error or message when using ruby:
>>>>
>>>>
>>>> /usr/local/sbin/portupgrade -av
>>>> : warning: pthread_create failed for timer: Resource tempor
> On Jun 24, 2017, at 6:55 PM, David Wolfskill wrote:
>
> On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
>> ...
>>> ktrace your failing ruby invocation, then post output of kdump -H somewhere.
>>>
>>
>> Ok not sure if this is right , but this is what i did:
>>
>> (tmp)4637}k
I get a new error or message when using ruby:
> >>
> >>
> >> /usr/local/sbin/portupgrade -av
> >> : warning: pthread_create failed for timer: Resource temporarily
> >> unavailable, scheduling broken
> >>
> >> everything works just
> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote:
>
> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
>> New world and kernel r320323
>> I get a new error or message when using ruby:
>>
>>
>> /usr/local/sbin/portupgrade -av
>&g
On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> New world and kernel r320323
> I get a new error or message when using ruby:
>
>
> /usr/local/sbin/portupgrade -av
> : warning: pthread_create failed for timer: Resource temporarily
> unavailab
New world and kernel r320323
I get a new error or message when using ruby:
/usr/local/sbin/portupgrade -av
: warning: pthread_create failed for timer: Resource temporarily
unavailable, scheduling broken
everything works just this message when using ruby. I recompiled ruby , still
same
1 - 100 of 531 matches
Mail list logo
