OK, here is what I did so far.
First I booted with 10.2 kernel (it's always good to have a backup).
Now I have 10.2 kernel and world. After that I installed clang38 using
ports (and discovered a bug #208375 in a process).
> Don't try to build world with ports clang, it's not yet supported (at
> l
Hello.
OK about 3 hours with last patch
No panic.
Sysctl -
sysctl kern.ipc.sf_long_headers
kern.ipc.sf_long_headers: 1
Gleb Smirnoff wrote:
GS> Vitalij,
GS>
GS> here is latest version of the patch. If you already run the
GS> previous one, no need to switch to this one, keep running as
Just forget, system was upgraded to 296385 (just sync with another servers )
Vitalij Satanivskij wrote:
VS>
VS> Hello.
VS>
VS> OK about 3 hours with last patch
VS>
VS> No panic.
VS>
VS> Sysctl -
VS> sysctl kern.ipc.sf_long_headers
VS> kern.ipc.sf_long_headers: 1
VS>
VS>
VS> Gleb Smirnof
OK, here is what I did so far.
First I booted with 10.2 kernel (it's always good to have a backup).
Now I have 10.2 kernel and world. After that I installed clang38 using
ports (and discovered a bug #208375 in a process).
> Don't try to build world with ports clang, it's not yet supported (at
> l
FreeBSD_HEAD_amd64_gcc4.9 - Build #1139 - Still Failing:
Build information:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1139/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1139/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_
If a custom kernel configuration file removes the SMP option, the kernel
build fails on the implicit declaration of lapic_read_icr_lo on (or
about) line 525 in local_apic.c. It refers to a static function whose
definition is removed when SMP is undefined,
imb
__
On 29 Mar 2016, at 11:38, Aleksander Alekseev wrote:
>
> OK, here is what I did so far.
>
> First I booted with 10.2 kernel (it's always good to have a backup).
> Now I have 10.2 kernel and world. After that I installed clang38 using
> ports (and discovered a bug #208375 in a process).
>
>> Don
> For some reason, your build does not pick up the __alloc_size defines
> from sys/cdefs.h. You will have to figure out which cdefs.h your
> build is including, and check whether that is in sync with the rest
> of your source tree.
I removed CC, CXX and CPP lines from /etc/make.conf and it solved
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275
Fabian Keil changed:
What|Removed |Added
CC||freebsd-current@FreeBSD.org
--- Comm
On Tue, 29 Mar 2016 16:53:18 +0300
Aleksander Alekseev wrote:
> > For some reason, your build does not pick up the __alloc_size
> > defines from sys/cdefs.h. You will have to figure out which
> > cdefs.h your build is including, and check whether that is in sync
> > with the rest of your source
> Do you still have your old make.conf for comparison?
Sure. Current make.conf:
```
CPUTYPE?=native
CFLAGS+=-O2 -pipe
CXXFLAGS+=-O2 -pipe
```
Old make.conf:
```
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
CPUTYPE?=native
CFLAGS+=-O2 -pipe
CXXFLAGS+=-O2 -pipe
```
Just re-check
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275
--- Comment #9 from Fabian Keil ---
I agree that moving the n calculation behind the error block
is technically sufficient to prevent the panic.
I added the NULL check in front of the brelse() because the function
contains a comment that i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275
--- Comment #10 from Konstantin Belousov ---
(In reply to Fabian Keil from comment #9)
See the comment near the end of cluster_read(), right after the opening '{' of
if (reqbp) block. It all comes from r294954.
--
You are receiving this
On Mon, Mar 28, 2016 at 11:38 PM, Ian Lepore wrote:
> Wow, there's just nothing to work with in that output. I think the
> increased debuging didn't output anything because nothing is happening,
> and that's consistant with the value in the Present State register when
> the driver attaches, whic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275
--- Comment #11 from Fabian Keil ---
Thanks for the pointer. Somehow I missed that comment.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebs
In the strain of the most recent update of www/firefox, on CURRENT the audio
capability
is gone! Firefox does not paly any kind of audio. Config is ports standard:
===> The following configuration options are available for firefox-45.0.1_3,1:
BUNDLED_CAIRO=on: Use bundled fork of cairo-1.9.
On 29 Mar 2016, at 15:53, Aleksander Alekseev wrote:
>
>> For some reason, your build does not pick up the __alloc_size defines
>> from sys/cdefs.h. You will have to figure out which cdefs.h your
>> build is including, and check whether that is in sync with the rest
>> of your source tree.
>
>
On 27/03/2016 09:07, Jia-Shiun Li wrote:
> I have one machine which is faster to build world and export /usr/obj for
> others to install.
>
> As of r297266 installworld would fail. It seems to be caused by r296921
> which would delete libc.ld. In this case libc.ld resides on a read-only
> /usr/obj
On Mon, 28 Mar 2016, Aleksander Alekseev wrote:
I think I realized what's going on. I probably rebuilded the world on
two different machines but forgot to do it on this one. I will
re-check this and report results a bit later.
OK, here is a problem. I can't upgrade the world because of compile
On Tue, 29 Mar 2016, Aleksander Alekseev wrote:
Do you still have your old make.conf for comparison?
Sure. Current make.conf:
```
CPUTYPE?=native
CFLAGS+=-O2 -pipe
CXXFLAGS+=-O2 -pipe
These will bite with no provocation, and prevent ports that want to set
their own flags from using them.
For me halped: PULSEAUDIO=off
30.03.16 00:31, O. Hartmann пишет:
>
> In the strain of the most recent update of www/firefox, on CURRENT the audio
> capability
> is gone! Firefox does not paly any kind of audio. Config is ports standard:
>
> ===> The following configuration options are available
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208275
--- Comment #12 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Tue Mar 29 19:59:45 UTC 2016
New revision: 297401
URL: https://svnweb.freebsd.org/changeset/base/297401
Log:
Do not access buffer if bread(9
Hi,
Being that it’s a 64-bit system and RPI2 images don’t work, is there any
procedure already established to build an image to boot on a Raspberry Pi 3?
Should Crochet work? How?
Thanks,
David.
___
freebsd-current@freebsd.org mailing list
https://lis
> Did you erase /usr/src before checking out -CURRENT? Obsolete files
> left in there can easily break things. 'svn stat /usr/src' will show
> those files with a '?'.
I did. `svn stat /usr/src` outputs nothing and has return code 0.
> The first stages of buildworld build a copy of clang under
On 28 Mar, Don Lewis wrote:
> On 28 Mar, O. Hartmann wrote:
> If I get a chance, I try booting my FreeBSD 11 machine with less RAM to
> see if that is a trigger.
I just tried cranking hw.physmen down to 8 GB on 11.0-CURRENT r297204,
GENERIC kernel. /boot/loader.conf contains:
geom_mirror_load
Hi,
It's under active development right now. Stay tuned.
-a
On 29 March 2016 at 13:58, Gala IT wrote:
> Hi,
>
> Being that it’s a 64-bit system and RPI2 images don’t work, is there any
> procedure already established to build an image to boot on a Raspberry Pi 3?
>
> Should Crochet work? How
Going from 11.0-CURRENT -r297048 to -r297369: buildworld after svnlite update:
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/. . . ends up with no
filecomplete.*
but the build tries to use what would be some of its contents
(_el_fn_sh_complete)
The details. . .
> --- all_subdir_bin ---
> --- sh
FreeBSD_HEAD_i386 - Build #2724 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2724/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2724/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2724/console
Change summaries:
2
FreeBSD_HEAD_i386 - Build #2725 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2725/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2725/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2725/console
Change summari
On Wed, Mar 30, 2016 at 2:19 AM, Jean-Sébastien Pédron wrote:
> On 27/03/2016 09:07, Jia-Shiun Li wrote:
> > I have one machine which is faster to build world and export /usr/obj for
> > others to install.
> >
> > As of r297266 installworld would fail. It seems to be caused by r296921
> > which w
If I try to build most recent HEAD (r297407), I get the following error:
[..snip..]
===> bwn (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys
32 matches
Mail list logo
