El día Tuesday, July 28, 2015 a las 09:20:38AM +0100, David Chisnall escribió:
It sounds as if the swap was working (as the build took a long time, it
didn’t run out of memory). My guess would be that, before the reboot,
something had wired (or, if not, then touched frequently enough to
On 27 Jul 2015, at 20:49, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
No idea.
May be someone know about current status swap in file on UFS.
This is work for me some time ago.
It sounds as if the swap was working (as the build took a long time, it didn’t
run out of memory). My guess would be
FreeBSD_HEAD_i386 - Build #693 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/console
Change summaries:
On Tue, Jul 28, 2015 at 04:05:33PM -0700, Adrian Chadd wrote:
Is this still happening for you?
g1-245(10.2-P)[4] ls -lT /S4/ntpd.core
-rw-r--r-- 1 root wheel 13783040 Jul 28 04:56:28 2015 /S4/ntpd.core
Apparently so, yes.
(/S4 is where I have the head root file system mounted when
Is this still happening for you?
-a
On 24 July 2015 at 06:03, David Wolfskill da...@catwhisker.org wrote:
On Sun, Jul 19, 2015 at 11:36:00AM -0700, David Wolfskill wrote:
On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote:
...
Was there anything (at all) in /var/log/messages
On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote:
[trim]
So, a couple of fscks found some problems, but none causing this.
I found the actual problem. The mount point for /usr was mode 700
even though the root of the mounted filesystem on /usr was mode 755.
Did I explain that
On Tue, Jul 28, 2015 at 04:25:45PM -0700, Adrian Chadd wrote:
...
Hm, is there any way you can get symbols for it?
Well, I could CFLAGS+= -g in /etc/make.conf to a clean build, then
try to re-create it ( point gdb at the objects in /usr/obj/obj/*) --
would that do?
I don't think I can easily
WITH_DEBUG_FILES=1 (IIRC)
On 7/28/15 6:35 PM, Adrian Chadd wrote:
There's some way in stable/10 and -head to get it to install debug
symbols for things. Maybe it's only libraries, but you'll at least
want that in there so you can get stack traces through libc.
-adrian
-check_test:xflag - passed
[0.101s]
[192.168.10.2] out:
[192.168.10.2] out: Results file id is usr_tests.20150728-214137-422996
[192.168.10.2] out: Results saved to
/root/.kyua/store/results.usr_tests.20150728-214137-422996.db
[192.168.10.2] out:
[192.168.10.2] out: 4336/4338 passed (2 failed
There's some way in stable/10 and -head to get it to install debug
symbols for things. Maybe it's only libraries, but you'll at least
want that in there so you can get stack traces through libc.
-adrian
___
freebsd-current@freebsd.org mailing list
On Mon, Jul 27, 2015 at 08:47:04PM +0200, Matthias Apitz wrote:
This pointed in the right direction. I have had 6x 1 GByte additional
swap partitions to plain files mounted
Swap devices are used in an interleaved fashion. By having multiple
file-backed swap devices on (presumably) the same
FreeBSD_HEAD_i386 - Build #694 - Fixed:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/694/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/694/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/694/console
Change summaries:
285938
Checking the source tree on CURRENT r285995 via svn status reveals that there
is a remnant etc/rc.d/tests obviously not caught by make delete-old:
? .snap
? .sujournal
? etc/rc.d/tests
? sys/amd64/conf/KOENIGSBERG
Can someone fix this?
Regards,
oh
Hi,
for some work we are doing on bhyve, we need some lightweight mechanism that
a kernel thread can use to wake up another user thread possibly
waiting for some event.
If the recipient of the event were a kernel thread it would simply
do a tsleep(chan...) and the sender would do a wakeup() or
Sources as of r285995 fail to build kernel with
[...]
--- kernel ---
linking kernel
kern_shutdown.o: In function `kern_reboot':
/usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to
`bufshutdown' *** [kernel] Error code 1
Regards,
oh
On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Sources as of r285995 fail to build kernel with
[...]
--- kernel ---
linking kernel
kern_shutdown.o: In function `kern_reboot':
/usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to
On Tue, 28 Jul 2015 21:58:26 -0700
Conrad Meyer cse@gmail.com wrote:
On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Sources as of r285995 fail to build kernel with
[...]
--- kernel ---
linking kernel
kern_shutdown.o: In function `kern_reboot':
Running a workstation with CURRENT (FreeBSD 11.0-CURRENT #5 r285947: Tue Jul 28
13:39:03 CEST 2015 amd64) equipted with an Intel XEON E5-1650 v3, see the
extraction from recent dmesg below.
I double checked the UEFI settings (the box is a Fujitsu Celsius M740 with most
recent firmware 1.8.0) and
Gary Palmer gpal...@freebsd.org wrote:
As best that I can recall, the permissions of the directory underneath
the mount point has been causing problems like this for as long as I've been
using FreeBSD, which is over 20 years at this point. It's certainly
bit me in the distant past.
I
Having in kernel
device ig4
makes buildkernel failing in CURRENT r285995:
config: Error: device ig4 is unknown
Loading the kernel module via kldload ig4 works fine.
Regards
oh
___
freebsd-current@freebsd.org mailing list
On Tue, Jul 28, 2015 at 10:21 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
On Tue, 28 Jul 2015 21:58:26 -0700
Conrad Meyer cse@gmail.com wrote:
On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Sources as of r285995 fail to build kernel with
[...]
On 28 Jul 2015, at 18:23, Adrian Chadd adrian.ch...@gmail.com wrote:
(What would be nice is having kqueue know about conditionals, so we
can sleep on a cond as well as a kqueue fd+queue, but I can't have
everything I want..)
I recently came across a need to do something like this. Being
]
[192.168.10.2] out:
[192.168.10.2] out: Results file id is usr_tests.20150728-153648-237338
[192.168.10.2] out: Results saved to
/root/.kyua/store/results.usr_tests.20150728-153648-237338.db
[192.168.10.2] out:
[192.168.10.2] out: 4334/4337 passed (3 failed)
[192.168.10.2] out:
Warning: run
On 28 July 2015 at 10:31, David Chisnall thera...@freebsd.org wrote:
On 28 Jul 2015, at 18:23, Adrian Chadd adrian.ch...@gmail.com wrote:
(What would be nice is having kqueue know about conditionals, so we
can sleep on a cond as well as a kqueue fd+queue, but I can't have
everything I want..)
There's a kqueue notification mechanism just for this very thing.
(What would be nice is having kqueue know about conditionals, so we
can sleep on a cond as well as a kqueue fd+queue, but I can't have
everything I want..)
-adrian
On 28 July 2015 at 05:19, Luigi Rizzo ri...@iet.unipi.it
On 28 July 2015 at 00:23, jenkins-ad...@freebsd.org wrote:
FreeBSD_HEAD-tests - Build #1226 - Unstable:
[..]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send - failed: 2
checks failed; see output for more details [0.371s]
[192.168.10.2] out:
Hi
I cannot for the life of me figure out why this is so:
As non-root:
[zen] /usr/lib $ file libgcc_s.so
libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1
As root:
[zen] /usr/lib # file libgcc_s.so
libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1
Only on one of my machines,
On 28 Jul 2015, at 18:33, Adrian Chadd adrian.ch...@gmail.com wrote:
Windows has had this for years. It makes async network programming
with thread worker queues significantly less abusive.
Can you do the same with Solaris completion ports? It might be a good source
of inspiration for a
On 28 July 2015 at 10:42, David Chisnall thera...@freebsd.org wrote:
On 28 Jul 2015, at 18:33, Adrian Chadd adrian.ch...@gmail.com wrote:
Windows has had this for years. It makes async network programming
with thread worker queues significantly less abusive.
Can you do the same with Solaris
On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote:
On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote:
Hi
I cannot for the life of me figure out why this is so:
As non-root:
[zen] /usr/lib $ file libgcc_s.so
libgcc_s.so: broken symbolic link to
On Tue, Jul 28, 2015 at 21:21:07 +0300, Sergey Kandaurov wrote:
On 28 July 2015 at 00:23, jenkins-ad...@freebsd.org wrote:
FreeBSD_HEAD-tests - Build #1226 - Unstable:
[..]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send - failed:
2 checks failed; see output for more
On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote:
Hi
I cannot for the life of me figure out why this is so:
As non-root:
[zen] /usr/lib $ file libgcc_s.so
libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1
As root:
[zen] /usr/lib # file libgcc_s.so
When I upgraded an approximately 3 month old -CURRENT system to yesterday, I
got page not present panics, after a message about pmspcv not supporting
my ahd(4) deviceid.
I did NOT capture the panic, but adding
nodevicepmspcv
Allowed me to boot.
Dmesg.boot from the WORKING system
On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
Garrett Cooper yaneurab...@gmail.com wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
...
CC=clang
CXX=clang++
CPP=clang-cpp
You need to
On 7/28/15 2:58 PM, Bryan Drewery wrote:
On 7/28/15 2:26 PM, Bryan Drewery wrote:
On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
Garrett Cooper yaneurab...@gmail.com wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty recent base/head (r284639)? This is on amd64 with
On 28 July 2015 at 16:09, David Wolfskill da...@catwhisker.org wrote:
On Tue, Jul 28, 2015 at 04:05:33PM -0700, Adrian Chadd wrote:
Is this still happening for you?
g1-245(10.2-P)[4] ls -lT /S4/ntpd.core
-rw-r--r-- 1 root wheel 13783040 Jul 28 04:56:28 2015 /S4/ntpd.core
Apparently
Glen Barber wrote:
On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote:
On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote:
Hi
=20
I cannot for the life of me figure out why this is so:
=20
As non-root:
[zen] /usr/lib $ file libgcc_s.so
libgcc_s.so: broken
On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote:
I found the actual problem. The mount point for /usr was mode 700
even though the root of the mounted filesystem on /usr was mode 755.
Did I explain that clearly (quite difficult because two things are
the same thing, although
David Wolfskill wrote:
My experience with SU+J is limited (and negative -- in large part,
because I tend heavily on dump | restore pipelines to copy file
systems, some of which are live at the time (danger mitigated by -L
flag for dump).
As an aside, mine has been pretty positive, except for
On 7/28/15 2:26 PM, Bryan Drewery wrote:
On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
Garrett Cooper yaneurab...@gmail.com wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
...
CC=clang
40 matches
Mail list logo
