> On Jan 6, 2017, at 17:33, Michael Butler wrote:
>
> With the introduction of MSG_MORETOCOME, the build of libsysdecode is
> broken.
>
> Was the following patch the intended but missed fix?
Addressed in r311584 — thank you for the submission!
-Ngie
FreeBSD_HEAD_i386 - Build #4588 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4588/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4588/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4588/console
Change
FreeBSD_HEAD_i386 - Build #4587 - Still Failing:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4587/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4587/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4587/console
Change
FreeBSD_HEAD_i386 - Build #4586 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4586/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4586/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4586/console
Change summaries:
With the introduction of MSG_MORETOCOME, the build of libsysdecode is
broken.
Was the following patch the intended but missed fix?
Index: lib/libsysdecode/mktables
===
--- lib/libsysdecode/mktables (revision 311572)
+++
email freebsd-wireless with the wifi details. i know our iwm driver
gets antenna configs wrong sometimes and that can cause issues.
-a
On 6 January 2017 at 11:07, Jonathan Anderson wrote:
> On 6 Jan 2017, at 13:53, Pete Wright wrote:
>>
>>
>> i've been having the same
On 6 Jan 2017, at 14:26, Matthew Macy wrote:
Thanks. Pete already filed that as part of #108. With luck markj@ will
have that fixed this weekend.
-M
Fantastic, I'll subscribe to that issue.
Cheers,
Jon
--
jonathan.ander...@ieee.org
___
On 6 Jan 2017, at 14:06, Matthew Macy wrote:
kernel cores tend to be large (all of wired memory after all) and
unless I have exactly the same kernel as you with the same sources at
the same changeset, not useful. A backtrace is a good place to start.
kgdb /boot/kernel/kernel
On Fri, Jan 06, 2017 at 09:54:50AM -0500, Kurt Lidl wrote:
> Yesterday, I upgraded the kernel on my sparc64 to -head,
> so I was running a mis-matched kernel and userland.
> The userland was a recent (as of two days ago) stable/10.
>
> In the nightly report, I noticed the following:
>
> >
On Wednesday, January 04, 2017 09:59:09 PM Konstantin Belousov wrote:
> On Wed, Jan 04, 2017 at 06:53:23PM +, Eric Joyner wrote:
> > Adding freebsd-current, because that's a good idea.
> >
> > I see these lines in the beginning of dmesg:
> >
> > MADT: Ignoring local APIC ID 256 (too high)
>
On Thursday, January 05, 2017 08:17:56 PM Sean Bruno wrote:
> tl;dr --> igbX devices will become emX devices
>
> We're about to commit an update to sys/dev/e1000 that will implement and
> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks
> who can test and poke at the
On 6 Jan 2017, at 12:48, Pete Wright wrote:
On 1/6/17 9:14 AM, Matthew Macy wrote:
I just did the merge and it's using a relatively untested new KPI so
regressions aren't too surprising I'm afraid. #96 is more or less
content free in terms of providing useful information. Getting a core
+
Thanks. Pete already filed that as part of #108. With luck markj@ will have
that fixed this weekend.
-M
On Fri, 06 Jan 2017 11:24:00 -0800 Jonathan Anderson
wrote
> On 6 Jan 2017, at 14:06, Matthew Macy wrote:
>
> > kernel cores tend to
On 6 Jan 2017, at 13:53, Pete Wright wrote:
i've been having the same problems with iwm too (failing to load
firmware on boot). my trick has been to either boot into an old
kernel where iwm was mostly usable. also i've commented out the line
enabling wlan0 in my rc.conf then uncommented it
kernel cores tend to be large (all of wired memory after all) and unless I have
exactly the same kernel as you with the same sources at the same changeset, not
useful. A backtrace is a good place to start.
> kgdb /boot/kernel/kernel /var/crash/vmcore.last
% bt
-M
On Fri, 06 Jan 2017
On 1/6/17 10:44 AM, Jonathan Anderson wrote:
On 6 Jan 2017, at 12:48, Pete Wright wrote:
On 1/6/17 9:14 AM, Matthew Macy wrote:
I just did the merge and it's using a relatively untested new KPI so
regressions aren't too surprising I'm afraid. #96 is more or less
content free in terms of
On 1/6/17 9:14 AM, Matthew Macy wrote:
> > Please try the drm-next branch now. Up until very recently, the
> > shrinkers responsible for culling ttm/gem allocations were never run.
> > I've now implemented the shrinker, but it's driven from vm_lowmem, so
> > you'll probably still see what
> > Please try the drm-next branch now. Up until very recently, the
> > shrinkers responsible for culling ttm/gem allocations were never run.
> > I've now implemented the shrinker, but it's driven from vm_lowmem, so
> > you'll probably still see what looks like a leak until you hit low
On 5 Jan 2017, at 0:17, Matthew Macy wrote:
On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson
wrote
Hi all,
I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly
close
to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use
of
On 2 Jan 2017, at 13:33, Mark Johnston wrote:
On Mon, Jan 02, 2017 at 10:31:50AM -0330, Jonathan Anderson wrote:
Hi all,
I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly
close
to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use
of
not-quite-CURRENT, it's
03.01.2017 20:21, Jung-uk Kim пишет:
On 01/03/2017 11:22, Hans Petter Selasky wrote:
On 01/03/17 16:26, Moore, Robert wrote:
Not sure I understand. The fix has been committed, and is part of
version 20161222.
Hi Robert,
From what I can see that patches have been pushed to the following
On 01/06/17 03:48, Steven Hartland wrote:
> Hmm I'm not sure about everyone else but I we treat emX as legacy
> devices (not used one in years) but igbX is very common here.
>
> The impact of changing a nic device name is quite a bit more involved
> than just rc.conf it effects other areas too,
Yesterday, I upgraded the kernel on my sparc64 to -head,
so I was running a mis-matched kernel and userland.
The userland was a recent (as of two days ago) stable/10.
In the nightly report, I noticed the following:
Network interface status:
NameMtu Network Address Ipkts
I've just updated, and the problem is gone. Thanks!
On 1221T1520, Moore, Robert wrote:
> We have fixed this issue for the latest version of ACPICA that will happen
> this week, probably 22 december.
>
>
> > -Original Message-
> > From: owner-freebsd-a...@freebsd.org
Hmm I'm not sure about everyone else but I we treat emX as legacy
devices (not used one in years) but igbX is very common here.
The impact of changing a nic device name is quite a bit more involved
than just rc.conf it effects other areas too, jails etc so given we can
loose access to the
On 01/06/17 11:04, blubee blubeeme wrote:
I was looking at the linuxkpi source code in /sys/compat/linuxkpi and I had
a question.
A lot of those files just look like linux files brought over to FreeBSD, is
there any reason why those files couldn't be implemented in BSD w/o the
dependencies on
I was looking at the linuxkpi source code in /sys/compat/linuxkpi and I had
a question.
A lot of those files just look like linux files brought over to FreeBSD, is
there any reason why those files couldn't be implemented in BSD w/o the
dependencies on the other Linux headers?
For example this
27 matches
Mail list logo