y
know what she does. I did not see it causing issues practically, while
multiple clangs in the path cause real problems.
>
> --- Original message ---
> From: "Konstantin Belousov"
> Date: 15 August 2019, 19:48:37
>
> Please look at https://reviews.freebsd.org/D21
Please look at https://reviews.freebsd.org/D21060
I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
It probably does not matter when all your software comes from ports or
packages, but is actually very annoying when developing on FreeBSD.
In particular, you never know which `clang'
On Mon, Aug 12, 2019 at 12:14:25PM +0300, Andriy Gapon wrote:
>
> I am trying to debug a leak of a shared vnode lock and I noticed that
> there is no check for td_lk_slocks in userret. There are checks for
> td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario
> where a thread
On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote:
> On 01/08/2019 22:51, Ian Lepore wrote:
> > On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote:
> >> On 01/08/2019 19:12, Warner Losh wrote:
> >>>
> >>>
> >>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes
> >>>
On Thu, Aug 08, 2019 at 09:35:23AM +0300, Vladimir Zakharov wrote:
> On Mon, Aug 05, 2019, Konstantin Belousov wrote:
> > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> > > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> > >
> > >
Apparently, NIS is still in use even in large enterprise environments,
not everything was consumed by LDAP. And there, Linux added a quirk
very long time ago, in 2013 at least, see
https://marc.info/?l=fedora-extras-commits=13667504323=2
What they did is the increase of the longest allowed
On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
>
> > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > > Hi,
> > >
> > > Has anyone else noticed the kernel being unable to spawn init lately?
> > >
> > >
On Thu, Jul 25, 2019 at 02:10:46PM -0500, Larry Rosenman wrote:
> On 07/25/2019 1:40 pm, Justin Hibbits wrote:
> > On Thu, 25 Jul 2019 12:35:32 -0600
> > Alan Somers wrote:
> >
> >> On Thu, Jul 25, 2019 at 12:13 PM Larry Rosenman
> >> wrote:
> >> >
> >> > On 07/25/2019 1:10 pm, Alan Somers
On Mon, Jul 22, 2019 at 02:03:26PM +0200, Ronald Klop wrote:
>
> Van: Laurie Jennings
> Datum: zondag, 21 juli 2019 16:58
> Aan: Konstantin Belousov
> CC: FreeBSD Current
> Onderwerp: Re: mmap port from 9 not working
> >
> > On Sunday, July 21, 2019, 10:44:
On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote:
> I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a
> pointer from the kernel via an ioctl and I map it into a shared buffer.
> char *kptr; // mem ptr from kernel
>
On Sun, Jul 14, 2019 at 03:34:20PM -0400, Mark Johnston wrote:
> On Sun, Jul 14, 2019 at 01:14:57AM +0300, Konstantin Belousov wrote:
> > On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote:
> > > I have cores. Ideas?
> > > svn rev: r349976
> >
On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote:
> I have cores. Ideas?
> svn rev: r349976
>
> [I] ➜ more core.txt.12
> borg.lerctr.org dumped core - see /var/crash/vmcore.12
>
> Sat Jul 13 16:47:03 CDT 2019
>
> FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976
On Fri, Jul 05, 2019 at 08:59:23PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote:
> >> On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote:
> >> > I have been working on a Linu
On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote:
> On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote:
> > I have been working on a Linux compatible copy_file_range(2) syscall
> > (the current code can be found at https://reviews.freebsd.org/D20584).
>
> > One
On Sun, Jun 09, 2019 at 06:12:59AM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote:
> >> Hi,
> >>
> First off, thanks Kostik for the fine explanation. I agree with Oliver that
> it should
>
On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote:
> Hi,
>
> I've started working of a copy_file_range() syscall for FreeBSD. I think I
> have the
> kernel patched and ready for some testing.
> However, I'm confused about what I need to do in src/lib/libc/sys?
> - Some syscalls have
On Sun, Jun 02, 2019 at 07:45:34PM +0200, Kurt Jaeger wrote:
> Hi!
>
> > > > > [panic] non-zero write count during poudriere run
> > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031
> > > > >
> > > > > Ideas on how to proceed ?
> > > >
> > > > Try this.
> > >
> > > Unfortunatly,
On Sun, Jun 02, 2019 at 06:48:51PM +0200, Kurt Jaeger wrote:
> Hi!
>
> > > [panic] non-zero write count during poudriere run
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031
> > >
> > > Ideas on how to proceed ?
> >
> > Try this.
>
> Unfortunatly, I can no longer reproduce the
On Fri, May 31, 2019 at 12:49:11PM +0200, Kurt Jaeger wrote:
> Hi!
>
> [panic] non-zero write count during poudriere run
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031
>
> Ideas on how to proceed ?
Try this.
diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c
index
On Mon, May 27, 2019 at 03:55:21PM +0200, voida...@420blaze.it wrote:
> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
What problem are you trying to solve ?
>
> The patch attached for the bug is for
On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
> Hi
>
> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
> to a file,
>
> this works: # echo 1 >> /path/to/file
>
> but this does not: # echo 1 > /path/to/file
>
> "Operation not supported." is returned
On Sun, May 19, 2019 at 02:47:10AM +, Rick Macklem wrote:
> Alan Somers wrote:
> >On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote:
> >>
> >> Hi,
> >>
> >> I've been working with Peter Errikson on a patch for mountd that adds a
> >> new option
> >> for incremental updating of exports. This
On Sat, May 18, 2019 at 12:57:29PM -0600, Warner Losh wrote:
> On Sat, May 18, 2019, 9:48 AM Mark Johnston wrote:
>
> > On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote:
> > > On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> &g
On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
>
On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> >
On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > I just updated from r346856 to r347950 and ran into a new panic, caused
> > by having if_tap_load="YES" in /boot/loader.conf - because it's already
> > built-in to the
On Wed, May 15, 2019 at 10:02:51AM +1200, Thomas Munro wrote:
> 1. As mentioned, you can't list 'em (unlike Linux, where you can just
> ls /dev/shm). There's a TODO note, but it's not clear whether it's
> best to extend ipcs or create a new userspace tool, and it wasn't
> immediately clear to me
Cc: list trimmed to relevant. Very long essey below, be warned.
On Sun, Apr 28, 2019 at 03:52:21PM -0400, k...@ixsystems.com wrote:
> FreeBSD Community,
>
>
>
> I'm pleased to announce a CFT for builds of FreeBSD 12-stable and 13-current
> using "TrueOS-inspired" packaged base. These are
On Mon, Apr 08, 2019 at 12:10:23AM +0200, Antoine Brodin wrote:
> Hi,
>
> There seems to be a kernel regression in head, that happened
> somewhere between r343921 and r345991.
Can you bisect ?
I looked over the stated range and I do not see a revision that would be
an obvious candidate for the
On Sat, Mar 23, 2019 at 01:23:58AM +0300, Rozhuk Ivan wrote:
> On Fri, 22 Mar 2019 12:12:44 -0700
> Maxim Sobolev wrote:
>
> > src/UPDATING entry perhaps in order?
> >
> > > Read the updated man page for geom_uzip. Add
> > > device xz
> > > to your kernel config.
>
>
>
On Fri, Mar 22, 2019 at 07:08:18PM +0300, Rozhuk Ivan wrote:
>
>
> ld: error: undefined symbol: xz_dec_init
> >>> referenced by g_uzip_lzma.c:106 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:106)
> >>> g_uzip_lzma.o:(g_uzip_lzma_ctor)
>
> ld: error: undefined symbol: xz_dec_run
> >>>
On Mon, Mar 18, 2019 at 05:20:35PM +0200, Andriy Gapon wrote:
>
> First, a note that this was observed on a system that runs a fairly old
> current
> (~ 1 year old) with a fairly long uptime (> 6 months).
> I noticed that the system was nearly out of memory, 98% of swap was in use,
> there was
On Thu, Mar 14, 2019 at 12:59:14PM -0700, John Baldwin wrote:
> On 3/14/19 12:20 PM, Konstantin Belousov wrote:
> > On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote:
> >> On 2019-Mar-13 23:30:07 -0700, Steve Kargl
> >> wrote:
> >>> AFAICT, all
On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote:
> On 2019-Mar-13 23:30:07 -0700, Steve Kargl
> wrote:
> >AFAICT, all libm float routines need to be modified to conditional
> >include ieeefp.h and call fpsetprec(FP_PD). This will work around
> >issues is FP and libm. FreeBSD needs
On Tue, Mar 12, 2019 at 04:10:19PM -0500, Larry Rosenman wrote:
> I'm working with Aki Tuomi of Dovecot and he asks:
>
> I tried to ask if you could ask from some Kernel hacker why I cannot
> send kqueue() fd over unix socket, I get "Operation not supported".
Right, because sending kqfd to other
On Sat, Feb 23, 2019 at 10:04:07AM -0800, Rodney W. Grimes wrote:
> > On Sat, Feb 23, 2019 at 11:19:31AM +0200, Konstantin Belousov wrote:
> > > On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote:
> > > > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl w
On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote:
> On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote:
> > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote:
> > > r343567 merges the PAE vs non-PAE pmap headers for i386
> > > freebsd. After bisection and dealing
On Thu, Feb 14, 2019 at 04:24:28PM -0500, Robert Huff wrote:
>
> On a system running:
>
> FreeBSD 13.0-CURRENT r343080 amd64
>
> with source tree updated at midnight last night, attempts to
> build a kernel with "device em" die with:
Did you added 'device iflib' to your kernel
Hello,
at https://reviews.freebsd.org/D18894 I put a review which main goal is
to allow i386 kernels to use NX bits on capable hardware. In essence,
single kernel now can operate using either PAE or non-PAE pagetables,
the selection is done at the cold (very early boot, before paging is
turned
On Sat, Jan 19, 2019 at 11:54:25PM +0300, Lev Serebryakov wrote:
> Hello Rebecca,
>
> Saturday, January 19, 2019, 6:06:52 PM, you wrote:
>
> > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could
> > not find or understand anything in this home-rown UI with crazy-fast mouse.
On Fri, Dec 28, 2018 at 10:18:12AM +0100, Gary Jennejohn wrote:
> I don't know why this hasn't already been reported, but I've been
> seeing this error since the commit was made.
>
> ===> lib/libc (obj,all,install)
> /usr/src/lib/libc/string/strerror.c:96:11: error: passing 'const char []' to
>
On Tue, Dec 11, 2018 at 04:04:15PM -0500, Kris Moore wrote:
> On 12/11/18 4:01 PM, Alexandre C. Guimarães wrote:
> > Hi.
> >
> > This is just informative.
> >
> > Apparently Linux is considering deprecate x32 support:
> >
> > https://lkml.org/lkml/2018/12/10/1151
> >
> > Cheers!
> >
>
> Hey
On Fri, Dec 07, 2018 at 05:02:03PM -0800, Steve Kargl wrote:
> On Sat, Dec 08, 2018 at 02:43:17AM +0200, Konstantin Belousov wrote:
> > On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote:
> > > On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote:
>
On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote:
> On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote:
> > On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote:
> > > On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote:
> > > &
On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote:
> On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote:
> > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote:
> > >
> > > make core dumps.
> > > devd core dumps.
> > > init core dumps.
> > > cc core dumps.
> > >
On Wed, Nov 28, 2018 at 10:50:59AM +0100, Peter Holm wrote:
> On Wed, Nov 28, 2018 at 01:46:17AM +0200, Konstantin Belousov wrote:
> > On Wed, Nov 28, 2018 at 12:54:21AM +0300, Vladimir Kondratyev wrote:
> > > Following test case triggers assertion after r340343:
> >
On Wed, Nov 28, 2018 at 12:54:21AM +0300, Vladimir Kondratyev wrote:
> Following test case triggers assertion after r340343:
>
>
> #include
>
> int
> main(int argc, char **argv)
> {
> openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
> }
>
> It results in:
>
> panic:
On Sat, Nov 24, 2018 at 12:09:34PM -0800, John-Mark Gurney wrote:
> Konstantin Belousov wrote this message on Sat, Nov 24, 2018 at 12:40 +0200:
> > On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote:
> > > I have an BeagleBoard Black. I'm running a recent snaps
On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote:
> I have an BeagleBoard Black. I'm running a recent snapshot:
> FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC arm
>
> aka:
> FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz
>
> It has 512MB
On Mon, Nov 12, 2018 at 06:08:11PM +0100, Guido Falsi wrote:
> On 12/11/18 15:33, Konstantin Belousov wrote:
> > On Mon, Nov 12, 2018 at 11:52:25AM +0100, Guido Falsi wrote:
> >> cpu_stdext_feature: 281
> > ...
> >> cpu_set_user_tls+0x2d: callset_pcb_flag
On Mon, Nov 12, 2018 at 11:52:25AM +0100, Guido Falsi wrote:
> cpu_stdext_feature: 281
...
> cpu_set_user_tls+0x2d: callset_pcb_flags_raw
...
>
> The patch does produce a working kernel. In fact I'm running that kernel
> now.
Do you have a bios option called like 'limit max cpuid value'
On Sun, Nov 11, 2018 at 08:44:24PM +0100, Guido Falsi wrote:
> On 11/11/18 11:10, Guido Falsi wrote:
> > On 11/11/18 00:07, Konstantin Belousov wrote:
> >> On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote:
> >>> On 10/11/18 13:08, Guido Falsi wrote
On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote:
> On 10/11/18 13:08, Guido Falsi wrote:
> > Hi,
> >
> > Today I was updating my home machines to recent head, r340303.
> > Previously I was running r339449.
> >
> > I have a build machine where I build base packages (and also runs
> >
On Thu, Nov 08, 2018 at 07:08:50PM -0700, Alan Somers wrote:
> On a fresh install of 12.0-BETA3, I'm seeing processes get stuck in the
> STOP state. Neither SIGCONT nor SIGKILL has any effect. And it's
> reproducible. All I have to do is:
> 1) Login to my login manager, which starts xfce
> 2)
On Mon, Nov 05, 2018 at 09:10:13PM -0500, Charlie Li wrote:
> On 03/11/2018 19:45, Konstantin Belousov wrote:
> > Or rather, it is a middle of the valid instruction.
> > Next frame looks like it is process_irelocs(), if trusting the line
> > numbers. So most likely it
On Mon, Nov 05, 2018 at 06:56:57PM +, Johannes Lundberg wrote:
> The short version is that drm2 in base (/sys/dev/drm2/) have support for hw
> up to 2013 (maybe 2014), that's why drm-legacy-kmod is said to support hw
> up to that year.
drm2 in base supports everything from gen3 to gen6 and did
On Sun, Nov 04, 2018 at 12:43:34AM -0700, Julian Elischer wrote:
> what's an ifunc?
>
A special kind of relocation, controlled by the user code.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To
On Sat, Nov 03, 2018 at 06:59:02PM -0400, Charlie Li wrote:
> On 03/11/2018 11:29, Konstantin Belousov wrote:
> > Some minimal amount of facts instead of guesses would be much more useful.
> >
> Yeah, being sleep deprived and hurried (on my end) certainly doesn't help.
> >
On Sat, Nov 03, 2018 at 08:52:16AM -0400, Charlie Li wrote:
> On 01/11/2018 15:43, Charlie Li wrote:
> > On 01/11/2018 12:04, Brooks Davis wrote:
> >> Is this failure with devel/llvm70? It's currently missing the patch
> >> required to make this work. https://reviews.freebsd.org/D17709 contains
On Tue, Oct 23, 2018 at 08:54:24AM -0600, Warner Losh wrote:
> On Tue, Oct 23, 2018 at 5:54 AM Toomas Soome wrote:
>
> >
> > > On 23 Oct 2018, at 13:53, Lev Serebryakov wrote:
> > >
> > > On 22.10.2018 12:27, Toomas Soome wrote:
> > >
> > >> It would help to get output from loader lsdev -v
On Sun, Oct 21, 2018 at 06:09:50PM +0200, Hannes Hauswedell wrote:
> Hi everyone,
>
> I wanted to ask what the current status of Ryzen support is and/or
> whether any new changes are planned.
>
> My situation:
> * second generation Ryzen: 2600X
> * running -CURRENT
> * I have done the things
On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote:
>
> On r339386 I am seeing a 100% hang at boot up time. Boot ends at
>
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University
On Sun, Oct 14, 2018 at 05:45:30PM +0200, Dirk Meyer wrote:
> Don Lewis schrieb:,
>
> > It looks to me like the base libssl.so version needs to get moved to a
> > value that doesn't collide with ports, perhaps 12. These are the
> > library version numbers currently used by the various ssl ports:
On Thu, Oct 11, 2018 at 07:07:45PM +, Glen Barber wrote:
> On Thu, Oct 11, 2018 at 09:05:52AM +0200, Raúl wrote:
> > Maybe related to recent Glen's Heads-UP?
> >
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html
> >
>
> No, this is different, and more recent
On Sat, Oct 06, 2018 at 11:40:36PM -0600, Warner Losh wrote:
> On Sat, Oct 6, 2018 at 12:48 PM Warner Losh wrote:
>
> > Greetings,
> >
> > As you can tell, the project is looking to clear some of the deadwood from
> > its driver lists. One problem is that we have to guess what's in used based
>
On Mon, Oct 01, 2018 at 09:15:46AM +0300, Yuri Pankov wrote:
> Hi,
>
> I've noticed the following rebooting after a panic:
>
> pid 41246 (vmstat), uid 0: exited on signal 11 (core dumped)
> pid 47091 (netstat), uid 0: exited on signal 11
>
> And indeed, trying to manually run those on the
On Mon, Sep 17, 2018 at 12:17:25PM -0600, Warner Losh wrote:
> On Sun, Sep 16, 2018 at 11:29 PM Rebecca Cran wrote:
> I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old
> > Apple systems that use 32-bit EFI: it sounds like it should be possible,
> > and is something I'd like
On Sun, Sep 16, 2018 at 01:43:51PM -0700, Manfred Antar wrote:
> With r338700 support.S i get panic after rebooting:
>
> avail memory = 16529514496 (15763 MB)
> MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
> SMP: Added CPU 2
On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote:
> On 8/31/18 1:28 AM, Konstantin Belousov wrote:
> > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote:
>
> [ .. snip .. ]
>
> >> I see another problem after using Ian's workaround of
On Thu, Aug 30, 2018 at 10:12:33PM +0300, Konstantin Belousov wrote:
> On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote:
> > Sorry, I accidentally took the discussion off-list, where Konstantin
> > provided some more patches. I'm attaching the one that finally wor
On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote:
> On 8/29/18 7:40 PM, John Baldwin wrote:
> > On 8/29/18 4:20 PM, Ian FREISLICH wrote:
> >> Hi
> >>
> >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP
> >> at line 84. My system is UP so I'm not compiling an
On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote:
> Sorry, I accidentally took the discussion off-list, where Konstantin
> provided some more patches. I'm attaching the one that finally worked
> for me. It also adds some diagnostic prints which require bootverbose
> to be enabled.
On Wed, Aug 29, 2018 at 07:17:07PM +0300, Yuri Pankov wrote:
> Konstantin Belousov wrote:
> > On Wed, Aug 29, 2018 at 09:12:37AM -0500, Kyle Evans wrote:
> >> I guess this patch might do it:
> >> https://people.freebsd.org/~kevans/efi-bootmap.diff
> >>
>
BSD
+ *
+ * Copyright (c) 2018 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Konstantin Belousov
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted pro
On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
> Hi,
>
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> 20180802) fail to boot on MBP 2017:
>
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic
On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:
> Now, with the patch applied correctly, the machine actually boots.
>
> Before calling init_ops.mp_bootaddress in
> getmemsize (machdep.c), physmap looks like this:
>
> physmap_idx: 8
> i mem atop
> 0 0x0 0x0
> 1 0x3 0x30
> 2
On Sat, Aug 25, 2018 at 11:51:21PM -0400, Theron wrote:
>
> A recent change in CURRENT has sysutils/acpi_call reliably cause a
> kernel panic when run on a Dell XPS laptop system. I bisected this to
> r336876: Use SMAP on amd64. I would have thought that this is a simple
> compatibility
On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote:
>
>
> > On 24. Aug 2018, at 21:59, Konstantin Belousov wrote:
> > Please apply the following debugging patch on top of the previous 'fix'.
> > You need debug.late_console=0.
>
> Unfortunately debug
On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
>
>
> > On 22. Aug 2018, at 23:15, Konstantin Belousov wrote:
> >
> >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> >>
> >>
> >>>> O
On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
>
>
> > On 22. Aug 2018, at 17:46, Konstantin Belousov wrote:
> >
> >> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
> >>
> >>
> >>>> O
On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>
>
> > On 20. Aug 2018, at 17:09, Konstantin Belousov wrote:
> >
> >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >>
> >> See here for a scree
On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>
> See here for a screenshot (also including the output of "show pte
> 0xf8000100"):
>
> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
It is too early for ddb routines to register.
Ok can you
wrote:
> > >>
> > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> > >>>
> > >>>
> > >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov
> > >>>> mailto:kostik...@gmail.com>> wrote:
>
On Fri, Aug 17, 2018 at 10:02:08AM +0100, John Baldwin wrote:
> On 8/17/18 9:54 AM, Michael Gmelin wrote:
> >
> >
> >> On 17. Aug 2018, at 08:17, John Baldwin wrote:
> >>
> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> >>>
&g
On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>
>
> > On 15. Aug 2018, at 15:04, Konstantin Belousov wrote:
> >
> >> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> >> Reviving this old thread, since I just updated t
On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> Reviving this old thread, since I just updated to r337818 and a similar
> problem is happening again. Since the fix in r334799 (review
> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
> so maybe this is
If you use UEFI boot, have EFIRT compiled in kernel (the case of
GENERIC) or pre-loaded as module, and efirt is not disabled by a tunable,
and the machine resets during kernel initialization, try this.
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index d5d795ab502..c9334eab916
On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote:
> On 8/14/18 4:12 AM, Johannes Lundberg wrote:
> > Hi
> >
> > Something that we have seen for a long time on FreeBSD is the boot message
> >
> > Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
> > suffer
> >
On Sat, Aug 11, 2018 at 12:05:25PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote:
> >> >BTW, does NFS server use extended attributes ? What for ? Can you,
> >> >please,
&g
On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote:
> >BTW, does NFS server use extended attributes ? What for ? Can you, please,
> >point out the code which does this ?
> For the pNFS service, there are two system namespace extended attributes for
> each file stored on the service.
>
On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote:
> I did notice that my code locks the vnode first and then calls
> vn_start_write()
> for the vn_extattr_set() calls, whereas the syscall code locks the vnode
> after the vn_start_write() call.
>
> Does that matter?
Yes, it matter.
On Thu, Aug 09, 2018 at 02:54:59PM -0400, Ryan Stone wrote:
> On Sat, Aug 4, 2018 at 9:17 PM Erich Dollansky
> wrote:
> >
> > Hi,
> >
> > I compiled me yesterday this system:
> >
> > 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
> >
> > When restarting fortune core dumps. When trying to load the
On Thu, Aug 09, 2018 at 01:39:20AM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> [stuff snipped]
> >> >Can you print the only buffer on the clean queue when the panic occur ?
> >> ffst3 vtyp=1 bodirty=0 boclean=1
> >> buf at 0x428a110
> >>
On Thu, Aug 09, 2018 at 10:26:06AM +0100, Johannes Lundberg wrote:
> On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov
> wrote:
>
> > On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote:
> > > Hi
> > >
> > > So I believe the reason
On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote:
> Hi
>
> So I believe the reason I'm not seeing and printf output in dmesg is that
> it is too early in some functions.
> For example
> machdep.s
> getmemsize()
> add_efi_map_entries()
> etc
>
> However, these functions do
On Wed, Aug 08, 2018 at 12:30:54PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Tue, Aug 07, 2018 at 12:28:33PM +, Rick Macklem wrote:
> >> Hi,
> >>
> >> During testing of the pNFS server I get an ffs_truncate3 panic every once
> >
On Tue, Aug 07, 2018 at 02:49:10PM -0700, Doug Ambrisko wrote:
> On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote:
> | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
> | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
> | > > On Mon, 6 Au
On Tue, Aug 07, 2018 at 08:54:39PM +0100, Johannes Lundberg wrote:
> Hi
>
> I seem to have some unkillable Linux processes...
> This is on my AMD Ryzen, the exact same installation on my Broadwell laptop
> does not show this behavior.
> At the second top output, the three remaining processes' cpu
On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
> On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
> > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
> >>
> >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
> >> wrote:
> >> >
On Tue, Aug 07, 2018 at 12:28:33PM +, Rick Macklem wrote:
> Hi,
>
> During testing of the pNFS server I get an ffs_truncate3 panic every once in
> a while.
> A few things that might be relevant:
> - Seems to happen more often when soft update journaling is enabled, but will
> happen when
201 - 300 of 1223 matches
Mail list logo
