Hmm, with the previously mentioned solution, colored output was lost half
way through the build...
Going to do a single thread clean build later when I have the time to wait
and see what the results are.
On Tue, May 16, 2017 at 8:42 AM, Johannes Lundberg
wrote:
> Gonna answer myself here. Thin
Gonna answer myself here. Think I found a way.
Add CFLAGS=-fcolor-diagnostics to env or /etc/src.conf
Do clean build, that is no -DNO_CLEAN,KERNFAST, etc.
Makes it a lot easier to find the errors in a 16 threads build output...
The mystery still remains though, why is color disabled for parallel
Hi
I'm sure this has been discussed but my Google-fu couldn't find me any
information..
I get colored output when building kernel with a single thread, however,
for -j > 1 colored output is disabled.
Anyone know what's the reason for this?
/Johannes
_
Since the introduction of IFLIB, I have big trouble with especially a certain
type of NIC, namely formerly known igb and em.
The worst device is an Intel NIC known as i217-LM
em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086 rev=0x05
hdr=0x00 vendor = 'Intel Corporation'
FreeBSD Project Quarterly Status Report - 1st Quarter 2017
While a few of these projects indicate they are a "plan B" or an
"attempt III", many are still hewing to their original plans, and all
have produced impressive results. Please enjoy this vibrant collection
of reports, covering
On Mon, 15 May 2017 10:51:51 -0700 (PDT)
"Jeffrey Bouquet" wrote:
>
>
> On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI
> wrote:
>
> > Hi.
> > If including its version to nvidia.ko and nvidia-modeset.ko,
> > [hard / symbolic] link to it with current name should be needed
> > not to bother a
On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote:
> On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote:
> > Inodes are data structures corresponding to objects in a file system,
> > such as files and directories. FreeBSD has historically used 32-bit
> > values to identify
On 0515T2140, Konstantin Belousov wrote:
> On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote:
> > Thanks! The patch fixes resume for me, for both vt(4) and X11.
>
> Thanks everybody for testing, patch below should be committable, modulo
> bugs. I did not tested it and ask
On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote:
> Inodes are data structures corresponding to objects in a file system,
> such as files and directories. FreeBSD has historically used 32-bit
> values to identify inodes, which limits file systems to somewhat under
> 2^32 objects.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849
Jonathan Anderson changed:
What|Removed |Added
CC||jonat...@freebsd.org
--- Comme
On Mon, 15 May 2017 12:56:47 +0300, Konstantin Belousov wrote
On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:
In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82
a?= writes:
I've tried to verify that, and sadly it wasn't it for me. The c
On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote:
> Thanks! The patch fixes resume for me, for both vt(4) and X11.
Thanks everybody for testing, patch below should be committable, modulo
bugs. I did not tested it and ask for the same test as the previous
debugging patch.
> Would you please execute the following and attach your output?
> $ make -VMAKE_VERSION
make ver: 20170510
uname -U: 1200030
In my original post I also stated:
also getting "cc not found" errors whether ccache is enabled or not.
For example installworld (no ccache) broke with that message so I
d
> On May 15, 2017, at 11:01, Beeblebrox wrote:
>
>> I was looking at the "make: Unknown modifier ‘c’” warnings — which
>> were a symptom of the bug that was fixed late last week. I don’t
>> genuinely know if ccache works or doesn’t work. Thanks, -Ngie
>
> Thanks,
> I still do see those exact "m
> I was looking at the "make: Unknown modifier ‘c’” warnings — which
> were a symptom of the bug that was fixed late last week. I don’t
> genuinely know if ccache works or doesn’t work. Thanks, -Ngie
Thanks,
I still do see those exact "make: Unknown modifier ‘c’” warnings
along with the original f
On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI
wrote:
> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
>
> BTW, I personally using below in rc.conf for safety.
> On May 15, 2017, at 10:46, Beeblebrox wrote:
>
>> Upgrade make — it was a bug with it, fixed in the past few days.
>> HTH,
>
> I just rebuilt and installed a clean world without using ccache
> After reboot I tried buildworld with ccache enabled, but got same error.
>
> So, did not work unles
> Upgrade make — it was a bug with it, fixed in the past few days.
> HTH,
I just rebuilt and installed a clean world without using ccache
After reboot I tried buildworld with ccache enabled, but got same error.
So, did not work unless you meant a particular port?
--
FreeBSD_amd64_12-Current_Rad
On 15 May 2017, at 14:57, Konstantin Belousov wrote:
On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote:
Running drm-next (which has -CURRENT last merged somewhere around
r317651), this patch fixes one of the two problems I've been
experiencing with suspend/resume. Definite prog
On 0515T1256, Konstantin Belousov wrote:
> On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:
> >
> > In message <20170514193006.GA1298@brick>, Edward Tomasz
> > =?utf-8?Q?Napiera=C5=82
> > a?= writes:
> >
> > >I've tried to verify that, and sadly it wasn't it for me. Th
On 05/15/2017 10:27, Konstantin Belousov wrote:
On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote:
On 15 May 2017, at 7:26, Konstantin Belousov wrote:
Try this. If it works, I will write a proper patch.
diff --git a/sys/amd64/amd64/cpu_switch.S
b/sys/amd64/amd64/cpu_switch.S
On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote:
> On 15 May 2017, at 7:26, Konstantin Belousov wrote:
> >
> > Try this. If it works, I will write a proper patch.
> >
> > diff --git a/sys/amd64/amd64/cpu_switch.S
> > b/sys/amd64/amd64/cpu_switch.S
> > index 33437ad16e6..9c0cd05e
On 15 May 2017, at 7:26, Konstantin Belousov wrote:
Try this. If it works, I will write a proper patch.
diff --git a/sys/amd64/amd64/cpu_switch.S
b/sys/amd64/amd64/cpu_switch.S
index 33437ad16e6..9c0cd05ebea 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -369
> On May 15, 2017, at 01:20, Beeblebrox wrote:
>
> I have been getting ccache errors during buildworld. Ports for example does
> not have this problem. I compleely reset the cache data some 2 months ago and
> ccache seemed to play with that much more nicely.
>
> Apart from the error below, I'
Hi.
If including its version to nvidia.ko and nvidia-modeset.ko,
[hard / symbolic] link to it with current name should be needed
not to bother admins every time upgrading.
BTW, I personally using below in rc.conf for safety.
This only helps situations that...
*Insufficient loader memory, but OK
Revised like Boris did for misc/mc [1].
Now attached raw Makefile and patch (renamed), as patch does not
handle new files on nonexistent files directory. :-(
PORTREVISION bumped, as this port is small enough and NO_BUILD,
and need updating for recent -head.
But at least 2 ports is affected for n
Just had a unique to me, unbootable backup [beside the point,
just a sidebar comment... ] quandry dealing with the nvidia-driver update
that mesa-libs needed. [ or was appurtenant to it, unsure... ]
12.0 - CURRENT
[ my previous 'saves' -- files to consult... were in .jpg, so no avail for
Looks like video driver reports double buffer as single frame buffer, so vt
draw it as big screen, but video card draw it as two layers.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849
--- Comment #26 from Miroslav Lachman <000.f...@quip.cz> ---
(In reply to Thomas Steen Rasmussen / Tykling from comment #25)
Are you serious? Then why Joe provided the idea how to make ezjail survive this
code removal?
Did you read the comme
On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:
>
> In message <20170514193006.GA1298@brick>, Edward Tomasz
> =?utf-8?Q?Napiera=C5=82
> a?= writes:
>
> >I've tried to verify that, and sadly it wasn't it for me. The commit
> >that does break resume for me is r316767.
I have been getting ccache errors during buildworld. Ports for example does not
have this problem. I compleely reset the cache data some 2 months ago and
ccache seemed to play with that much more nicely.
Apart from the error below, I'm also getting some "cc not found" errors when
doing src stuf
I remember having problems with Realtek 8111E Ethernet on this Intel Ivy Bridge
computer a couple years ago, and now the problem has resurfaced.
I am fresh from updating FreeBSD to 11-STABLE and HEAD on two partitions, and
in both cases can not connect with onboard Ethernet.
>From NetBSD 7.99.1
32 matches
Mail list logo
