On Thu, Sep 27, 2018 at 12:34:39PM -0700, Steve Kargl wrote:
> cd /usr/obj
> rm -f usr
> cd /usr/src
> svn update
> make buildworld
> (wait a long time)
>
> ===> lib/clang/libllvm (all)
> llvm-tblgen -gen-asm-matcher -I /usr/src/contrib/llvm/include -I
> /usr
cd /usr/obj
rm -f usr
cd /usr/src
svn update
make buildworld
(wait a long time)
===> lib/clang/libllvm (all)
llvm-tblgen -gen-asm-matcher -I /usr/src/contrib/llvm/include -I
/usr/src/contrib/llvm/lib/Target/Mips -d MipsGenAsmMatcher.inc.d -o
MipsGenAsmMatcher.inc /usr/src/contrib/llvm/lib/Tar
On Wed, Sep 19, 2018 at 05:02:11PM -0400, Mark Johnston wrote:
> On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> > I have the kernel and core file if more information is needed.
> >
> > % cat info.2
> > Dump header from device: /dev/ada0
I have the kernel and core file if more information is needed.
% cat info.2
Dump header from device: /dev/ada0p3
Architecture: amd64
Architecture Version: 2
Dump Length: 2348281856
Blocksize: 512
Compression: none
Dumptime: Wed Sep 19 12:29:59 2018
Hostname: troutmask.apl.washington.
On Fri, Aug 17, 2018 at 05:50:06PM -0400, Ed Maste wrote:
> On 8 August 2018 at 13:27, Warner Losh wrote:
> >
> >> % /usr/obj/usr/src/i386.i386/usr.sbin/kldxref/kldxref /boot/kernel
> >> kldxref: unhandled relocation type 2
> >> (40+ messages...)
> >
> >
> > Oh, wait: relocation type, not module i
On Wed, Aug 08, 2018 at 06:27:21PM +0100, Warner Losh wrote:
> On Wed, Aug 8, 2018 at 6:19 PM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> >
> > Thanks for info.
> >
> > I'll note that freshly built kldxref gives the same messages.
>
On Wed, Aug 08, 2018 at 06:14:19PM +0100, Warner Losh wrote:
> On Wed, Aug 8, 2018 at 5:58 PM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > Just build a new world and kernel. Upon doing "make installkernel",
> > I see at the end of the
Just build a new world and kernel. Upon doing "make installkernel",
I see at the end of the process
kldxref /boot/kernel
kldxref: unhandled relocation type 2
kldxref: unhandled relocation type 2
kldxref: unhandled relocation type 2
(40 more messages)
kldxref: unhandled relocation type 2
The curr
On Sat, Aug 04, 2018 at 10:23:56PM -0600, Brad Davis wrote:
> On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote:
> > On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > > > Author: brd
> > > > Date: Sat Aug 4 22:41:17 2018
> > > > New Revision: 337340
> > > > URL:
> > > > https://svnweb.free
This is now PR 229876.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229876
--
steve
On Mon, Jul 16, 2018 at 08:20:11PM -0700, Steve Kargl wrote:
> Version 2. After applying the patch, one can
>
> % svn delete libm/msun/src/polevll.c
> % svn commit libm/msun/src/polevll.
Version 2. After applying the patch, one can
% svn delete libm/msun/src/polevll.c
% svn commit libm/msun/src/polevll.c
* lib/msun/Makefile:
. Remove polevll.c
* lib/msun/ld80/e_powl.c:
. Copy contents of polevll.c to here. This is the only consumer of
these functions. Make functions
On Sun, Jul 15, 2018 at 02:00:37PM -0700, Matthew Macy wrote:
> On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen
> wrote:
> > On 07/15/2018 02:09 PM, Warner Losh wrote:
> >> I'm not saying that he has a lock. I'm saying he's are domain expert and
> >> many mistakes can be avoided by tal
On Sun, Jul 15, 2018 at 02:00:37PM -0700, Matthew Macy wrote:
> On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen
> wrote:
> > On 07/15/2018 02:09 PM, Warner Losh wrote:
> >> I'm not saying that he has a lock. I'm saying he's are domain expert and
> >> many mistakes can be avoided by tal
On Sun, Jul 15, 2018 at 12:23:06PM -0700, Cy Schubert wrote:
> I wasn't saying Steve has a lock however in case non-committers
> might feel they do, addressing all points in my reply. Not saying
> anyone feels this way today but we should consider this in whatever
> we decide here (considering all
On Sun, Jul 15, 2018 at 10:44:28AM -0700, Matthew Macy wrote:
>
> In the bug report you cite, Chris Lattner states: "This is actually an
> unspecified feature of C99 (whether it supports the _Imaginary type).
> It is desirable to support this, but not a regression.
>
Chris Lattner is wrong when
On Sun, Jul 15, 2018 at 12:06:47PM -0600, Ian Lepore wrote:
>
> On the other hand, what information is there for someone to know that
> Steve should be involved in a review? There is nothing in MAINTAINERS.
> The review was on phab for almost a month, and phab is supposedly the
> preferred way to
On Sun, Jul 15, 2018 at 10:21:25AM -0700, K. Macy wrote:
> >
> > Well, actually, the functions in polevll.c should have been copied
> > into ld80/e_powl.c, and polevall.c should never have been committed.
> > Unfortunately, the code was not reviewed for correctness.
>
> That is not correct. Please
On Sun, Jul 15, 2018 at 11:00:41AM -0600, Ian Lepore wrote:
> On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote:
> > Index: ld80/e_powl.c
> > ===
> > --- ld80/e_powl.c (revision 336304)
> > +++ ld
Apparently, the recents additions to libm were not
subject to any code review. The following patch
does two things. First, it works around
https://bugs.llvm.org/show_bug.cgi?id=8532
Second, it removes the pollution of libm with the
polevll.c functions. Those functions are used
only in ld80/e
On Tue, Jun 26, 2018 at 02:39:27PM -0700, Adrian Chadd wrote:
> On Mon, 25 Jun 2018 at 11:23, Steve Kargl
> wrote:
> >
> > On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote:
> > >
> > > I don't have hard evidence, but there is eno
On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote:
>
> I don't have hard evidence, but there is enough "smell" to open up a
> discussion...
>
> Short:
> Can it be that enabling numa in the kernel is the reason why some
> people see instability with zfs and usage of swap whil
On Sat, Jun 09, 2018 at 06:07:15PM -0700, Don Lewis wrote:
> On 9 Jun, Stefan Esser wrote:
>
> > 3) Programs that evenly split the load on all available cores have been
> >suffering from sub-optimal assignment of threads to cores. E.g. on a
> >CPU with 8 (virtual) cores, this resulted in
On Sun, Jun 03, 2018 at 09:28:47PM +, Rick Macklem wrote:
> mmacy has sent me a bunch of warnings of the "variable set but not used" kind
> generated by gcc8.
>
> When I've looked at the code, these are for RPC arguments I parse but do not
> use at this time.
> I'd like to leave the code in p
On Thu, May 31, 2018 at 03:23:56PM -0500, Mark Linimon wrote:
> On Thu, May 31, 2018 at 12:58:23PM -0700, Steve Kargl wrote:
> > On Thu, May 31, 2018 at 11:08:18AM -0700, Matthew Macy wrote:
> > >
> > > Based on the i386 discussion I recognize that there's a
On Thu, May 31, 2018 at 11:08:18AM -0700, Matthew Macy wrote:
>
> Based on the i386 discussion I recognize that there's a great deal of
> sentimental attachment to older hardware. However, there's very few
s/sentimental/practical
--
Steve
___
freebsd-
On Tue, May 22, 2018 at 04:32:39PM -0700, K. Macy wrote:
> Why are you running i386 on that?
>
I'm not. Just pointing out that drm2 runs on amd64 as
well as i386. Also need to correct the dis-information
that drm2 only applies to mid-Haswell and older.
In the end, src committers will do what t
On Tue, May 22, 2018 at 07:50:39AM +0100, Johannes Lundberg wrote:
> On Mon, May 21, 2018 at 23:50 Steve Kargl
> wrote:
>
> > On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > > >
> > > > I just ask.
> > > > Or why not include drm-n
On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for
On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> >
> > I just ask.
> > Or why not include drm-next to base svn repo and add some
> > option to make.conf to swith drm2/dem-next ?
>
> Even if it's not being built on amd64 we're still responsible for
> keeping it building on !amd64 so long
On Mon, May 21, 2018 at 01:16:12PM -0700, K. Macy wrote:
> On Mon, May 21, 2018 at 10:07 AM, Steve Kargl
> wrote:
> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
> >> On Sun, 20 May 2018 21:10:28 +0200
> >> Oliver Pinter wrote:
>>>
>&
On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>
> On 05/21/2018 10:07, Steve Kargl wrote:
> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
> >> On Sun, 20 May 2018 21:10:28 +0200
> >> Oliver Pinter wrote:
> >>
> >&
On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
> On Sun, 20 May 2018 21:10:28 +0200
> Oliver Pinter wrote:
>
> > > One of the reasons for the deprecation and removal of the drm2 bits
> > > is that they prevent us from automatically loading the
> > > drm-next/stable-kmod kernel modul
On Sun, May 20, 2018 at 06:47:07PM +0200, Niclas Zeising wrote:
> On 05/20/18 18:40, Steve Kargl wrote:
> > On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:
> >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> >>>
> >>> % mo
On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:
> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> > > On Fri, May 18, 2018, 20:00 Niclas Z
On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:
> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > Check the Makefiles
> >
> > % more /usr/ports/graphics/drm-next-kmod/Makefile
> >
> > ON
On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> On Fri, May 18, 2018, 20:00 Niclas Zeising wrote:
>
> > I propose that we remove the old drm2 driver (sys/dev/drm2) from
> > FreeBSD. I suggest the driver is marked as deprecated in 11.x and
> > removed from 12.0, as was done for
On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote:
> In review PR 228007, it came to my attention some individuals are
> mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> issue". See
It seems we've had the same discussion 2 yea
On Thu, May 10, 2018 at 06:21:51PM +0200, Tijl Coosemans wrote:
> On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl
> wrote:
> >
> > So, the runtime loader finds 6 instead of 716, tries to link,
> > fails, and issues an error message. There are a number ways to
> >
On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:
> > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > In review PR 228007, it came
In review PR 228007, it came to my attention some individuals are
mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
issue". See
https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
The problem can be summarized by the following
% gfortran7 -o z h.f90
% ./z
/
On Fri, Apr 06, 2018 at 01:25:54PM +0200, Dimitry Andric wrote:
> Yes, but that manual is also pretty much incomplete, so with the last
> import I decided to stay with the older perl doc based one. Upstream
> is pretty bad at writing detailed documentation, certainly in the form
> of man pages.
>
On Fri, Apr 06, 2018 at 06:20:41AM +0100, David Chisnall wrote:
> On 6 Apr 2018, at 01:30, Pete Wright wrote:
> >
> >
> > On 04/05/2018 17:15, Steve Kargl wrote:
> >> This assumes that a gcc(1) is available on the system.
> >>
> >> % man gc
On Thu, Apr 05, 2018 at 08:11:50PM -0500, Benjamin Kaduk wrote:
> On Thu, Apr 05, 2018 at 05:56:24PM -0700, Steve Kargl wrote:
> > I never said that you said it was in base. I'm noting that
> > referring a user to a non-existent manual page is of little
> > help. In fac
-0700, Conrad Meyer wrote:
> I never said it was in base.
>
> On Thu, Apr 5, 2018 at 5:15 PM, Steve Kargl
> wrote:
> > This assumes that a gcc(1) is available on the system.
> >
> > % man gcc
> > No manual entry for gcc
> >
> > If the system compiler
On Thu, Apr 05, 2018 at 05:30:04PM -0700, Pete Wright wrote:
>
>
> On 04/05/2018 17:15, Steve Kargl wrote:
> > This assumes that a gcc(1) is available on the system.
> >
> > % man gcc
> > No manual entry for gcc
> >
> > If the system compiler is clan
for clang is gcc(1).
>
> Conrad
>
> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl
> wrote:
> > Is anyone working on fixing the clang manual to actually
> > document the available options?
> >
> > % man clang
> > (search for -std=)
> >-std=
> >
Is anyone working on fixing the clang manual to actually
document the available options?
% man clang
(search for -std=)
-std=
Specify the language standard to compile for.
OK, what does mean?
--
Steve
___
freebsd-current@freebsd.
On Wed, Apr 04, 2018 at 02:13:15PM -0700, Steve Kargl wrote:
>
> OK, so where is elf64_linux_vdso_fixup suppose to come from?
>
The answer is compat/linux/linux_vdso.c where we find
#if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32))
#define __ELF_W
On Wed, Apr 04, 2018 at 01:19:55PM -0700, Steve Kargl wrote:
> On Wed, Apr 04, 2018 at 12:09:02PM -0700, Steve Kargl wrote:
> >
> > kernel config file contains
> >
> > options COMPAT_LINUX32
> > options COMPAT_LINUXKPI
> > options
On Wed, Apr 04, 2018 at 12:09:02PM -0700, Steve Kargl wrote:
>
> kernel config file contains
>
> options COMPAT_LINUX32
> options COMPAT_LINUXKPI
> options LINPROCFS
>
> When booting, the kernel tries to load the module. A manual
> loadi
On Wed, Apr 04, 2018 at 02:41:35PM -0400, Ed Maste wrote:
> On 3 April 2018 at 12:26, Steve Kargl
> wrote:
> > Booting a kernel from
> > % uname -a
> > FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \
> > Thu Mar 22 13:41:30 AKDT 2018 \
> >
Booting a kernel from
% uname -a
FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \
Thu Mar 22 13:41:30 AKDT 2018 \
kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64
gives the following from dmesg
% dmesg | grep linux
link_elf_obj: symbol elf64_linux_vdso_fixup
On Fri, Jan 26, 2018 at 07:25:51AM -0800, Steve Kargl wrote:
> On Fri, Jan 26, 2018 at 10:28:13PM +0900, Tomoaki AOKI wrote:
> > Hi.
> > Try `make install` in /usr/src/usr.sbin/kldxref BEFORE
> > `make installkernel`. (Backup kldxref for safety.)
> >
>
> Tha
On Fri, Jan 26, 2018 at 10:28:13PM +0900, Tomoaki AOKI wrote:
> Hi.
> Try `make install` in /usr/src/usr.sbin/kldxref BEFORE
> `make installkernel`. (Backup kldxref for safety.)
>
Thanks! This at least allowed 'make installkernel' to
finish cleanly. Now, outward to rebooting ...
--
Steve
___
This can't be good.
make buildworld
make buildkernel
make installkernel
...
===> zlib (install)
install -T release -o root -g wheel -m 555 zlib.ko /boot/kernel/
install -T debug -o root -g wheel -m 555 zlib.ko.debug
/usr/lib/debug/boot/kernel/
kldxref /boot/kernel
kldxref: error while reading
So, my system just wedge itself. No panic. No keyboard.
No mouse. No remote login. Nothing. Just wedged.
The system is FreeBSD 12.0-CURRENT r326432 Fri Dec 1 2017 amd64.
Imagine my surprise when I rebooted system and the file
I had been editing (and saving after every change) is
gone. /usr/
On Mon, Jan 15, 2018 at 08:38:15PM +0300, Mehmet Erol Sanliturk wrote:
>
> When you perform floating point computations , it may be useful
> to ...
read David Goldberg's paper, "What Every Computer Scientist Should
Know about Floating-Point Arithmetic."
http://www.validlab.com/
--
Steve
__
On Mon, Dec 25, 2017 at 09:16:24PM +0100, O. Hartmann wrote:
>
> Can someone help?
>
There isn't a lld.1 manpage.
grep MAN /usr/src/usr.bin/clang/lld/Makefile
MAN=
google 'man lld' eventually get one to
https://lld.llvm.org/#using-lld
which leads one to assume that there is no documentation
On Tue, Dec 12, 2017 at 10:41:49AM -0800, Conrad Meyer wrote:
> On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl
> wrote:
> > There isn't a question. I'm pointing out your poll apparently
> > is limited to a select few individuals that use FreeBSD.
>
> The selec
On Tue, Dec 12, 2017 at 11:19:21AM -0700, Alan Somers wrote:
> On Tue, Dec 12, 2017 at 11:15 AM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote:
> > > Should man(1)'s default pager chan
On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote:
> Should man(1)'s default pager change to "less -s"? Vote and flame at the
> Phabricator link below.
>
> https://reviews.freebsd.org/V7
>
Does not work.
Unhandled Exception ("AphrontMalformedRequestException")
Your browser did not su
On Sun, Dec 10, 2017 at 05:44:33PM +0100, Dimitry Andric wrote:
> On 9 Dec 2017, at 02:02, Steve Kargl
> wrote:
> >
> > The following patch documents the remaining kludges that
> > theraven@ committed in r255294 on 2013-09-06. I have
> > cleaned up all of th
The following patch documents the remaining kludges that
theraven@ committed in r255294 on 2013-09-06. I have
cleaned up all of the others, but powl and tgammal remain.
ngie@ seems to have documented the existence of powl with
r290605, but did not document the rather poor numerical
accuracy of th
The following patch removes an unused include.
Index: msun/bsdsrc/b_log.c
===
--- msun/bsdsrc/b_log.c (revision 2046)
+++ msun/bsdsrc/b_log.c (working copy)
@@ -36,7 +36,6 @@
__FBSDID("$FreeBSD: head/lib/msun/bsdsrc/b_log.c 176449 20
The following patch updates math.3 to reflect the current
state of reality.
Index: msun/man/math.3
===
--- msun/man/math.3 (revision 2046)
+++ msun/man/math.3 (working copy)
@@ -28,7 +28,7 @@
.\"from: @(#)math.36.
On Sat, Dec 02, 2017 at 11:42:26AM -0800, Eitan Adler wrote:
> On 2 December 2017 at 11:32, Steve Kargl
> wrote:
> > The following patch adds a guard macro to fpmath.h.
> > It is used to prevent multiple inclusions of its
> > content. Please apply to top-of-tree.
>
The following patch adds a guard macro to fpmath.h.
It is used to prevent multiple inclusions of its
content. Please apply to top-of-tree.
Index: libc/include/fpmath.h
===
--- libc/include/fpmath.h (revision 2044)
+++ libc/inc
On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
>
> Are you accusing me of lying?
>
Nope. I'm stating the obvious. If you are using
META_MODE and you do "make buildwould" that is
equivalent to "make -DNO_CLEAN buildworld", which
means you did not rebuild the *world*.
When I s
On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
>
>
> > On Nov 2, 2017, at 18:49, Steve Kargl
> > wrote:
> >
> >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> >>
> >> On Nov 2, 2017, at 15:44, Mark Millar
On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
>
> On Nov 2, 2017, at 15:44, Mark Millard wrote:
>
> >> Author: bdrewery
> >> Date: Thu Nov 2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> >>
> >>
> >> Log:
> >> Somet
On Thu, Oct 26, 2017 at 10:05:00AM +0800, blubee blubeeme wrote:
> I wrote a simple test program to test and see if math.h has the function:
> exp10f
> #include
>
> int main(int argc, char** argv)
> {
> (void)argv;
> return ((int*)(&exp10))[argc];
> }
>
> tried compiling it with clang:
> clang++
On Wed, Sep 27, 2017 at 03:13:21PM -0700, Steve Kargl wrote:
>
> Hmmm,
>
> % kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.0
> Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done.
> ABI doesn't support a vmcore target
>
> OK, so debugging i
Just got this panic on
FreeBSD troutmask.apl.washington.edu 12.0-CURRENT FreeBSD 12.0-CURRENT
#0 r321800: Mon Jul 31 13:48:43 PDT 2017
kargl@:/data/obj/usr/src/sys/SPEW amd64
core.txt.0 contains
panic: softdep_deallocate_dependencies: dangling deps
cpuid = 7
time = 1506549566
KDB: stack backtr
I grabbed a spare USB 2 TB hard drive yesterday. Put a GPT
scheme on the drive and then used newfs to create 1 large
UFS2 partition with softupdates and with journalling enabled.
I then some 150 GB of data to drive. The drive in question is
ugen0.3: at usbus0
umass0 on uhub8
umass0: on usbus0
On Fri, May 26, 2017 at 09:57:16PM +, Rick Macklem wrote:
> I have now found I can get rid of almost all of the degradation by building
> the
> recent kernel with
> options SCHED_4BSD
> instead of
> options SCHED_ULE
>
> The 1yr old kernel was built with SCHED_ULE, so the degradation is some
On Sat, May 20, 2017 at 11:39:14AM -0600, Ian Lepore wrote:
> On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote:
> > % which cpp
> > /usr/bin/cpp
> > troutmask:kargl[408] cpp --version
> > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
> &g
% which cpp
/usr/bin/cpp
troutmask:kargl[408] cpp --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM
4.0.0)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
troutmask:kargl[409] cpp --help |grep trad
-traditional-cppEnable so
In looking at NetBSD/OpenBSD's math_private.h, it seems the
content of mathimpl.h have been tacked onto it.
--
steve
On Tue, May 16, 2017 at 05:55:24PM -0700, Steve Kargl wrote:
> I don't have a commit bit. I just checked OpenBSD/NetBSD.
> They use a 3-clause license.
>
&g
. Doesn't look like it does. If you'd
> like, I can look at it an DTRT if you're unsure.
>
> Warner
>
> On Tue, May 16, 2017 at 6:48 PM, Steve Kargl
> wrote:
> > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote:
> >> On Tue, May 16, 2017 at 6:
On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote:
> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl
> wrote:
> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley
> > Copyright. Supposedly UCB no longer enforces clause 3. Can
> > clause 3 be remov
The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley
Copyright. Supposedly UCB no longer enforces clause 3. Can
clause 3 be removed?
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
__
On Sat, Mar 11, 2017 at 07:34:40AM +0100, Baptiste Daroussin wrote:
> On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote:
> > MANPATH is not handled correctly. According to the documentation
> > in apropos(1) and whatis(1):
> >
(snip)
>
> Sorry it took tim
On Thu, Mar 02, 2017 at 01:10:21PM +0100, Mateusz Guzik wrote:
> On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote:
> >
> > Summary of the transition interval:
> >
> > So for powerpc64 (and powerpc?) It is a good
> > idea to avoid anything that is after -r313254
> > and before -r314474
r313194 defined vm_ooffset_t and vm_pindex_t in sys/types.h.
I believe that forces a recompile of lang/gcc ports, and
probably anything built with the lang/gcc port to avoid
dependency issue. Neither "pkg audit -q" nor "pkg version -vl '<'"
pick up this issue.
% make
gcc6 -o hex -O2 -pipe -stat
On Tue, Feb 21, 2017 at 10:29:43PM -0800, Steve Kargl wrote:
> On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote:
> > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> > > Well, I found the guilty commit. r313934 breaks loading
> > > eith
On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote:
> On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> > Well, I found the guilty commit. r313934 breaks loading
> > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
> > details belo
On Tue, Feb 21, 2017 at 09:37:41PM -0800, Steve Kargl wrote:
> On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote:
> > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote:
> > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
> > >
On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote:
> On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote:
> > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
> > >
> > > Well, the good news seems to be that r313254 and older ar
LL prior to the merge into x86_mem.c. You now
use 0xfffUL. I have no idea whether this is related to
cause.
--
steve
On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> With a kernel and world from r313943 sources (circa
> Feb 19, 2017), kldload of either drm2.ko or i915kms.
On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
>
> Well, the good news seems to be that r313254 and older are 'ok'.
> So, something between r313943 and r313254 is triggering a the
> problem. I'm still bisecting, but it might take a day or two.
>
I&#x
On Tue, Feb 21, 2017 at 01:50:30AM +0100, Mateusz Guzik wrote:
> On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote:
> > On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> > > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > > >
On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > With a kernel and world from r313943 sources (circa
> > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> > will lock up the system.
On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > With a kernel and world from r313943 sources (circa
> > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> > will lock up the system.
With a kernel and world from r313943 sources (circa
Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
will lock up the system. There is no keyboard response,
screen output, or panic. Just a locked up system.
A kernel from r313027 and its modules boots fine.
'kldload drm2.ko' yields the foll
On Mon, Feb 20, 2017 at 09:04:35AM +0100, Dimitry Andric wrote:
> On 19 Feb 2017, at 21:30, Steve Kargl
> wrote:
> > ===> Building for help2man-1.47.4
> > elf_load_section: truncated ELF file
> > Abort trap
>
> but this looks like a half-written or empty fil
Looks like I picked the wrong time to update a month old.
Problem #1: 'kldload -v i915kms.ko' locks up the system. No
panic. No messages logged. No keyboard response. Black
screen of death.
Problem #2: 'kldload -v drm2.ko' locks up the system. No panic.
No messages logged. No keyboard respon
On Mon, Jan 09, 2017 at 10:26:16PM -0800, Simon J. Gerraty wrote:
> Steve Kargl wrote:
>
> > On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote:
> > > Steve Kargl wrote:
> > >
> > > > MANPATH is not handled correctly. According to t
On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote:
> Steve Kargl wrote:
>
> > MANPATH is not handled correctly. According to the documentation
> > in apropos(1) and whatis(1):
>
> Can you clarify where you are seeing this documentation?
> I don'
MANPATH is not handled correctly. According to the documentation
in apropos(1) and whatis(1):
MANPATH The standard search path used by man(1) may be changed by
specifying a path in the MANPATH environment variable. Invalid
paths, or paths without manual databases, are
On Thu, Dec 29, 2016 at 01:59:12AM +0200, Konstantin Belousov wrote:
> On Wed, Dec 28, 2016 at 03:24:39PM -0800, Steve Kargl wrote:
> > Patch results in a panic when I start X server.
> >
>
> You do not have INVARIANTS in the kernel config ?
>
Correct.
> Below is
301 - 400 of 1223 matches
Mail list logo
