FreeBSD_HEAD-tests - Build #1229 - Still Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1229/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1229/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1229/console
Change su
On 29/07/2015 05:48, Jamie Landeg-Jones wrote:
> Gary Palmer 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
>
On Tue, Jul 28, 2015 at 10:21 PM, O. Hartmann
wrote:
> On Tue, 28 Jul 2015 21:58:26 -0700
> Conrad Meyer wrote:
>
>> On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann
>> wrote:
>> > Sources as of r285995 fail to build kernel with
>> >
>> > [...]
>> > --- kernel ---
>> > linking kernel
>> > kern_shutd
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
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
___
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
http://lists.freebsd.org
On Tue, 28 Jul 2015 21:58:26 -0700
Conrad Meyer wrote:
> On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann
> 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_shutdo
Gary Palmer 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 concur. I always make
On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann
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
> `bufshutdown' *** [kernel] Err
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
___
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
___
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
http
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 ca
On 28 July 2015 at 16:09, David Wolfskill 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 so, yes.
>
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 th
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 I
]
[192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_save -> passed
[0.154s]
[192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_eq_ne ->
passed [0.290s]
[192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_exit -> passed
[0.228s]
[192.168.10.2] ou
Is this still happening for you?
-a
On 24 July 2015 at 06:03, David Wolfskill 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 about ntpd? Eve
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 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 a
On 7/28/15 2:26 PM, Bryan Drewery wrote:
> On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
>> Garrett Cooper 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=
On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
> Garrett Cooper 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 re
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 atta
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, exce
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
> >
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 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
> l
On Tue, Jul 28, 2015 at 21:21:07 +0300, Sergey Kandaurov wrote:
> On 28 July 2015 at 00:23, 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
On 28 July 2015 at 10:42, David Chisnall wrote:
> On 28 Jul 2015, at 18:33, Adrian Chadd 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 g
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, all
On 28 July 2015 at 00:23, 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: sys/kern/unix_seqpacket_test:shutdown_send_sigpipe
On 28 Jul 2015, at 18:33, Adrian Chadd 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 good API if so.
David
On 28 July 2015 at 10:31, David Chisnall wrote:
> On 28 Jul 2015, at 18:23, Adrian Chadd 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
On 28 Jul 2015, at 18:23, Adrian Chadd 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 able to add
condvar /
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 wrote:
> Hi,
> for some
t: libexec/rtld-elf/ld_library_pathfds:last_library_directory
-> passed [0.163s]
[192.168.10.2] out:
libexec/rtld-elf/ld_library_pathfds:middle_library_directory -> passed
[0.195s]
[192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:missing_library ->
passed [0.213s]
[1
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 wak
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
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 dis
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 k
On 27 Jul 2015, at 20:49, Slawa Olhovchenkov 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 that, befor
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:
28593
42 matches
Mail list logo
