Re: weird Ctrl-T debug messages

2020-06-27 Thread John Baldwin
personally, e.g., while running commands like dd[0], cp, mv, > poudriere etc.), not for getting debug output. I agree with this. > Question: Speaking of discovering the feature, wouldn't it make sense > to document this tunable on the stack(9) and/or tty(4) man page(s)? This sounds l

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

2020-05-27 Thread John Baldwin
On 5/27/20 2:05 PM, Hans Petter Selasky wrote: > On 2020-05-27 15:41, Justin Hibbits wrote: >> On Wed, 27 May 2020 06:27:16 -0700 >> John Baldwin wrote: >> >>> On 5/27/20 2:39 AM, Andriy Gapon wrote: >>>> On 27/05/2020 11:13, Andriy Gapon wrote: &

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

2020-05-27 Thread John Baldwin
multi-pass and to resume all the bridges first before trying to resume leaf devices (including timers), but that's a fair bit of work. It might be that we just need to resume timer interrupts later after the new-bus resume (I think we currently do it before?), though the reason for that

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

2020-05-26 Thread John Baldwin
fffe00a7a19ad0 >> amd64_syscall() at amd64_syscall+0x140/frame 0xfe00a7a19bf0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00a7a19bf0 >> >> I am not sure if this is just a coincidence but it appears as if a write to >> some >> PCI configuratio

Re: RFC: merging nfs-over-tls changes into head/sys

2020-05-22 Thread John Baldwin
let me know if you see problems with me doing this? I don't see any problems, per se, but I still need to do some changes on my end for software KTLS RX before it's ready to merge (I'm hoping to kill the iovecs in the kthreads entirely). -- John Baldwin __

Re: ${COMPILER_VERSION} < 40300

2020-05-08 Thread John Baldwin
e first step towards any of that is probably to remove some of the cruft from cdefs.h and possibly some other places. (BTW, it would be good to know if it's at all useful to keep any of the icc bits around.) -- John Baldwin ___ freebsd-current@free

Re: toolchain status

2020-04-20 Thread John Baldwin
ernal toolchain for 13) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

2020-04-08 Thread John Baldwin
d to have ctfconvert installed. This does mean you need to use a custom kernel instead of GENERIC. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Emacs tramp mode doesn't work with CURRENT

2020-03-10 Thread John Baldwin
.x host) Have you been able to bisect it at all? I think libedit is probably a good candidate as well. What I see is that tramp-mode just hangs until I kill the ssh session it is using, and then I see the same output you had below in the debug window showing the extraneous newlines.

Re: how to use the ktls

2020-01-27 Thread John Baldwin
On 1/26/20 8:08 PM, Rick Macklem wrote: John Baldwin wrote: [stuff snipped] Hmmm, this might be a fair bit of work indeed. Right now KTLS only works for transmit (though I have some WIP for receive). KTLS does assumes that the initial handshake and key negotiation is handled by OpenSSL

Re: how to use the ktls

2020-01-13 Thread John Baldwin
On 1/12/20 8:23 PM, Benjamin Kaduk wrote: > On Thu, Jan 09, 2020 at 10:53:38PM +, Rick Macklem wrote: >> John Baldwin wrote: >>> On 1/7/20 3:02 PM, Rick Macklem wrote: >>>> Hi, >>>> >>>> Now that I've completed NFSv4.2 I'm on to the next

Re: how to use the ktls

2020-01-08 Thread John Baldwin
s = SSL_new(...); /* fd is the existing TCP socket */ SSL_set_fd(s, fd); OpenSSL_connect(s); if (BIO_get_ktls_send(SSL_get_wbio(s)) { /* Can use KTLS for transmit. */ } if (BIO_get_ktls_recv(SSL_get_rbio(s)) { /* Can use KTLS for receive. */ } -- John Baldwin ___

Re: New external GCC toolchain ports/packages

2019-12-20 Thread John Baldwin
On 12/19/19 12:06 PM, Ryan Libby wrote: > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: >> >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are built as fla

Re: New external GCC toolchain ports/packages

2019-12-19 Thread John Baldwin
On 12/18/19 4:16 PM, Mark Millard wrote: > > > On 2019-Dec-18, at 13:48, John Baldwin wrote: > >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are built as

New external GCC toolchain ports/packages

2019-12-18 Thread John Baldwin
on newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). I do plan to switch the default toolchains for make universe/tinderbox for targets using -xtoolchain-gcc based on GCC 6 over to the freebsd-gcc6 variants in the next week or so. -- John Baldwin

Re: make delete-old: missing some files?

2019-10-24 Thread John Baldwin
On 10/22/19 8:42 PM, Alexey Dokuchaev wrote: > On Tue, Oct 22, 2019 at 04:34:53PM -0700, John Baldwin wrote: >> On 10/18/19 10:05 AM, Alexey Dokuchaev wrote: >>> hi there, >>> >>> i've made my -CURRENT world and installed, but "make delete-old"

Re: make delete-old: missing some files?

2019-10-22 Thread John Baldwin
hing, or ObsoleteFiles.inc lacks a few entries? These are from the OpenSSL 1.1.1 commit. However, they are tagged as OLD_LIBS and check-old-libs and delete-old-libs should be automatically deleting these? Does 'make check-old' report these files as old libraries? -- John Baldwin

Re: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

2019-10-07 Thread John Baldwin
On 9/25/19 10:33 AM, Sergey Kandaurov wrote: > On Sat, Sep 21, 2019 at 08:43:58PM -0400, Ryan Stone wrote: >> I have written a short test program that runs unlinkat(2) in >> capability mode and fails due to not having the write capabilities: >> >> https://people.freebsd.org/~rstone/src/unlink.c >>

Re: problem with LOCAL_MODULES

2019-08-30 Thread John Baldwin
On 8/30/19 10:42 AM, Kyle Evans wrote: > On Fri, Aug 16, 2019 at 7:38 PM John Baldwin wrote: >> >> On 8/16/19 3:05 AM, Gary Jennejohn wrote: >>> I tried to build a kernel today and it failed in modules-all even >>> though I had LOCAL_MODULES=""

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-19 Thread John Baldwin
On 8/16/19 5:33 PM, Rozhuk Ivan wrote: > On Fri, 16 Aug 2019 17:23:08 -0700 > John Baldwin wrote: > >>> I use better way: >>> /etc/make.conf: >>> # Modules to build with kernel. >>> PORTS_MODULES+= graphics/drm-fbsd12.0-kmod >>> graphics/gpu

Re: problem with LOCAL_MODULES

2019-08-16 Thread John Baldwin
ule} (${target:S/^reinstall$/install/:S/^clobber$/cleandir/})" @cd ${LOCAL_MODULES_DIR}/${module}; ${MKMODULESENV} ${MAKE} \ @@ -83,6 +84,7 @@ modules-${target}: ${target:S/^reinstall$/install/:S/^clobber$/cleandir/} .endfor .endif +.endif .endfor # Handle ports (as def

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-16 Thread John Baldwin
ing (you have to just use LOCAL_MODULES=) this already exists. You can set it in /etc/src.conf, in a kernel config, or on the command line. > Rather than a default to on with an opt out mechanism perhaps > while we gain experience change this to a default to off with > an opt in mechanism? It'

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-16 Thread John Baldwin
On 8/16/19 3:52 PM, Rozhuk Ivan wrote: > On Fri, 16 Aug 2019 15:40:24 -0700 > I use better way: > /etc/make.conf: > # Modules to build with kernel. > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod This doesn't work for folks who use pre-built packages. -

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-16 Thread John Baldwin
On 8/14/19 1:19 PM, Ian Lepore wrote: > On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote: >> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote: >> >>> On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote: >>>> On 8/14/19 11:06 AM, Kyle Evans wrote: &

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-16 Thread John Baldwin
only one /usr/local/sys/modules? Do I need multiple port trees > just to pull in out of tree module sources? In some ways, installing sources for DRM is a compromise for the fact that we can't have DRM in the base source anymore (for various reasons). However, virtualbox is also probably in t

Re: Can't boot current under bhyve on current

2019-08-16 Thread John Baldwin
derr output. Can you try doing that to see if bhyve is reporting an error? Alternatively, can you see if the bhyve process is still running? -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/fr

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-14 Thread John Baldwin
options, and we need to figure out how to handle other options. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-14 Thread John Baldwin
Also, the 'make tinderbox' use case is a legit use case that some folks want (for CI, etc.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "fre

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-14 Thread John Baldwin
On 8/14/19 10:23 AM, Emmanuel Vadot wrote: > On Wed, 14 Aug 2019 10:13:48 -0700 > John Baldwin wrote: > >> On 8/14/19 9:22 AM, Ian Lepore wrote: >>> This all sounds vaguely wrong, backwards, to me. A developer who is >>> using a given module on their bu

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-14 Thread John Baldwin
r of people doing > crossbuilding is small enough that nobody else is going to object to > this "the whole world is amd64" automation. You assume DRM is amd64-only when it is definitely not. It also has suitable guards in its Makefile to only build the relevant ke

Re: HEADSUP: drm-current-kmod now installs sources

2019-08-14 Thread John Baldwin
On 8/13/19 3:17 PM, Ian Lepore wrote: > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote: >> For developers this means even if you are doing testing on a box >> that doesn't use DRM, you can install the package so that kernel >> builds will try to compile it and hopefully

HEADSUP: drm-current-kmod now installs sources

2019-08-13 Thread John Baldwin
es and try to build them if the package is installed. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kgdb assert while loading a kernel core

2019-08-08 Thread John Baldwin
quot; while loading my core > file. Usually this means that your vmcore file is not from the same kernel you are passing to kgdb. In the case of ports gdb the reason it crashes is that gdb is finding that the value of 'dumptid' from the vmcore is 0 and normally dumptid is t

Re: How to hotplug a PCI device (such as VF) on FreeBSD

2019-03-25 Thread John Baldwin
n' to force a rescan of a PCI bus as Ian noted. For native PCI-express hotplug you should not need to do manual rescans (though FreeBSD does not support PCI-e hotplug via Thunderbolt). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https

Re: Optimization bug with floating-point?

2019-03-14 Thread John Baldwin
have max ULP of 2.9 (the > desired result); with the latter you have a max ULP of 23.xxx. > I have observed a 6 billion ULP issue when running my testsuite. > As pointed out by John Baldwin, GCC is aware of the FPU setting. > The problem with clang is that it seems to unconditiona

Re: Optimization bug with floating-point?

2019-03-14 Thread John Baldwin
t is gcc doing different than clang in this case. I assume neither GCC _nor_ clang are adjusting the FPU in compiler-generated code, and in fact as Steve's earlier tests shows, the precision is set to PD by default when a clang-built binary is run. -- John Baldwin

Re: Optimization bug with floating-point?

2019-03-13 Thread John Baldwin
On 3/13/19 9:40 AM, Steve Kargl wrote: > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: >> On 3/13/19 8:16 AM, Steve Kargl wrote: >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: >>>> >>>> gcc8 --version >>>> gcc

Re: Optimization bug with floating-point?

2019-03-13 Thread John Baldwin
nt >> main(void) >> { >>double re, im, u, ur, ui; >>float complex f; >>float x, y; > > this line to "volatile float x, y". So it seems to be a regression in clang 7 vs clang 6? -- John Baldwin __

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

2019-03-01 Thread John Baldwin
, not > just core deciding what is or is not a tier 1 and/or how to fix our > tier 1 situation with i386 (which I do agree needs to change, but > to what I have not a solid idea.) As you are well aware, core@ has talked to some stakeholders already (including you) which has already resulted in

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

2019-02-28 Thread John Baldwin
removing per my other mail. While there is some cruft in a few files for older CPUs (mostly just initcpu.c and identcpu.c) it is quite small and in code that doesn't change. To effect any type of substantial "win" in reducing code complexity for i38

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

2019-02-28 Thread John Baldwin
; thinking of removing the workarounds like F00F. Are there any processors that > are still vulnerable to this? We have only removed support for 386 since it didn't support cmpxchg. We still nominally support 486s. I don't know how well FreeBS

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

2019-02-28 Thread John Baldwin
On 2/28/19 10:32 AM, Steve Kargl wrote: > On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote: >> You can do all your tests directly on amd64 by just adding >> "-m32" to compile i386 binaries against the libraries in /usr/lib32 >> and you will generate t

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

2019-02-28 Thread John Baldwin
for testing i386 things. I also run i386 VMs under bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 VMs though, and you don't need a VM to test userland-only changes (I'm usually trying to test kernel changes). However, an amd64 kernel is going to

Re: Panic in sys_fstatat()

2019-02-14 Thread John Baldwin
On 2/14/19 12:38 PM, Steve Kargl wrote: > On Thu, Feb 14, 2019 at 12:26:01PM -0800, John Baldwin wrote: >> On 2/13/19 6:47 PM, Steve Kargl wrote: >>> #16 0x00ff58bb in trap (frame=0x2e7b6880) at >>> /usr/src/sys/i386/i386/trap.c:519 >>> #17 0xffc0315d in ?? ()

Re: Panic in sys_fstatat()

2019-02-14 Thread John Baldwin
24 syscall (frame=0x2e7b6ce8) at /usr/src/sys/i386/i386/trap.c:1144 > #25 0xffc033a7 in ?? () > #26 0x2e7b6ce8 in ?? () > Backtrace stopped: Cannot access memory at address 0xfbafbbbc > (kgdb) Frame 18 is probably the root problem, though it doesn't look like kgdb is able t

Re: kernel config question

2019-01-04 Thread John Baldwin
On 1/3/19 10:40 PM, Kevin Oberman wrote: > On Wed, Jan 2, 2019 at 5:02 PM Robert Huff wrote: > >> >> John Baldwin writes: >> >>> -[8] In order to have a kernel that can run the 4.x binaries needed >> to >>> -do an installwo

Re: kernel config question

2019-01-02 Thread John Baldwin
On 1/2/19 1:31 PM, Robert Huff wrote: > > John Baldwin writes: > >> >> [8] In order to have a kernel that can run the 4.x binaries >> >> needed to do an installworld, you must include the >> >> COMPAT_FREEBSD4 option in your kernel. [...] >

Re: kernel config question

2019-01-02 Thread John Baldwin
; No, COMPAT_FREEBSD4 is not needed. Maybe COMPAT_FREEBSD11 is needed. Yes, that text needs to be made more generic to say that you will need COMPAT_FREEBSD. Though we've also had so

Re: buildworld falure: truncated or malformed archive

2019-01-02 Thread John Baldwin
ng (and llvm) with stripped down debug symbols by default. If you don't put any DEBUG_* foo in src.conf you will get debug symbols for all of the world including the limited ones for clang. (We use -gline-tables-only or some such fo

Re: 12.0 - (zpool upgrade ) /bootpool/boot/* new location for /boot/* ?

2018-12-17 Thread John Baldwin
n all of the devices.) I have a fresh install of 12.0-RC3 here that still has the files in /boot and doesn't have a /bootpool directory at all. -- John Baldwin ___ freebsd-current

Re: Composite PCI devices in FreeBSD (mfd in Linux)

2018-12-10 Thread John Baldwin
On 12/10/18 12:19 PM, Ian Lepore wrote: > On Mon, 2018-12-10 at 14:42 -0500, Anthony Jenkins wrote: >> On 12/10/18 1:26 PM, John Baldwin wrote: >>> >>> On 12/10/18 9:00 AM, Anthony Jenkins wrote: >>>> >>>> Hi all, >>>> >>>>

Re: Composite PCI devices in FreeBSD (mfd in Linux)

2018-12-10 Thread John Baldwin
e BAR. If you want to enforce exclusivity (once a device allocates part of a BAR then other children shouldn't be permitted to do so), then you will need a more complicated solution. Hopefully that gives you a starting point? -- John Baldwin

Re: axp288 on Intel HW

2018-11-16 Thread John Baldwin
ry devices work? Maybe your battery devices don't have a _STA method and you need the change in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191? -- John Baldwin ___ freeb

Re: Has anything changed from 11.2 to 12.0 in PCI MSI/MSIX path?

2018-11-01 Thread John Baldwin
complete or tag me > in necessary place? So that I can give a try in my board once it's ready. I just committed r340016 which merges r338360 along with followup fixes to stable/11. > On Mon, Oct 29, 2018 at 11:08 PM John Baldwin <mailto:j...@freebsd.org>> wrote: > > On 10/25/18 1

Re: Has anything changed from 11.2 to 12.0 in PCI MSI/MSIX path?

2018-10-29 Thread John Baldwin
tr_machdep.h as a precursor to MFC'ing this change. > On Thu, Oct 25, 2018 at 1:17 AM John Baldwin <mailto:j...@freebsd.org>> wrote: > > On 10/24/18 3:40 AM, Rajesh Kumar wrote: > > Hi, > > > > I have a amd64 based board. When I tried to

Re: savecore: BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

2018-10-25 Thread John Baldwin
On 10/25/18 2:14 AM, Marcin Cieslak wrote: > On Wed, 24 Oct 2018, John Baldwin wrote: > >> On 10/23/18 10:58 AM, Marcin Cieslak wrote: >>> This GDB was configured as "amd64-marcel-freebsd"...BFD: >>> /boot/kernel/kernel: invalid relocation type 37 &

Re: Has anything changed from 11.2 to 12.0 in PCI MSI/MSIX path?

2018-10-24 Thread John Baldwin
h my observations about the issue on > 11.1/11.2 in the following thread > https://forums.freebsd.org/threads/freebsd-11-1-installation-fails-and-rebooting.65814/ > > Let me know if you need any details. I believe this was fixed by r338360. -- John Baldwin __

Re: savecore: BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

2018-10-24 Thread John Baldwin
Is this something that matters at all? It is not something that is likely to be fixed. If you pkg install gdb from ports, is the kgdb it includes able to examine the crash dump? -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://l

Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

2018-09-17 Thread John Baldwin
On 9/17/18 11:32 AM, Michael Butler wrote: > On 9/10/18 1:20 PM, John Baldwin wrote: >> On 9/8/18 1:44 PM, Michael Butler wrote: >>> On 9/8/18 3:43 PM, Konstantin Belousov wrote: >>>> On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: >>>>

Re: devd on head -r338675 on aarch64 (Pine64+ 2GB example) gets during booting: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found"

2018-09-14 Thread John Baldwin
error booting FreeBSD/riscv in qemu. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send

Re: Speed problems with both system openssl and security/openssl-devel

2018-09-13 Thread John Baldwin
it doesn't I'd check for a BIOS option disabling it). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubsc

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread John Baldwin
2 users would have hassles getting kgdb to work? No, this means that if you turn this option on in HEAD and leave it always on (as I read your mail to say), then it would be a hassle for developers on head. On stable branches it would be nice to keep the info if people are building kernel

Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

2018-09-10 Thread John Baldwin
er/firewall with few actual applications running. >>> >>> As another data point, I manually reversed both SVN r338360 and r338415 >>> (a related change) and it is now stable running at SVN r338520, >> >&g

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread John Baldwin
tree the extra info is useful to have. For better or worse, kgdb also parses the path to try to find kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it won't be able to find the matching kernel using its current logic. crashinfo uses

Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

2018-08-29 Thread John Baldwin
interrupt_sorted), Probably just needs #ifdef SMP around the mallocarray(). I'll test locallyon a UP kernel config. -- John Baldwin ___ freebsd-current@freebsd.org mailing list h

Re: svn commit: r338204 - in head: etc etc/defaults sbin/devfs

2018-08-23 Thread John Baldwin
longer mimic the layout on the host, such as syslog.d being "flattened".) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Newly upgraded -CURRENT box does not boot

2018-08-21 Thread John Baldwin
o that maybe Brett has a chance to upgrade > to 12.0, unless this sounds familiar to someone and the cause is > obvious. =) I would start with bisecting the changes to libi386/biosdisk.c. Also, comparing 'lsdev -v' output between old and new loaders might be a useful step before starting on the bisecting. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools

2018-08-21 Thread John Baldwin
e/rescue >> [...] >> >> >> This problem occured during today's source updates since I was able to build >> the NanoBSD >> image I intend to build yesterday ~ r338060. >> >> What is going wrong? > > It seems the problem has been intr

Re: LUA loader: bhyve now doesn't?

2018-08-19 Thread John Baldwin
loader, >> or is this a change with the recent default switch? >> >> And to be clear, you expect the host's file to be used for this, not the VM >> filesystem? >> > > (CC'ing jhb@ and tychon@, who might have better insight) > > If

Re: kernel build failure

2018-08-19 Thread John Baldwin
think of no sound reason that you should be >>> forced to use modules. >> I thought that ZFS was required to be a module because of the licensing >> terms (they didn't want any CDDL code in the core kernel)? >> > > It can't be in _GENERIC_ for that reason. Ther

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

2018-08-17 Thread John Baldwin
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: >>> >>> >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov >>> <mailto:kosti

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

2018-08-17 Thread John Baldwin
t - so the previous fix just worked due to a bug it seems. > > Is there an easy way to output the content of physmap at that point > (debug.late_console=0 doesn’t work) - like an existing buffer I could use, or > would this be more elaborate (I did something complicated last time b

Re: programs like gdb core dump

2018-08-09 Thread John Baldwin
> Revision: Revision: 337343 The core dumps don't really do me any good unfortunately without a binary, but if you can open fortune.core under gdb for example, just getting the stack trace along with 'info reg' is probably sufficient. > Erich > > > On Wed, 8 Aug 2018 08:57:06 -

Re: Early kernel boot log?

2018-08-09 Thread John Baldwin
ically due to an exception occuring before > IDT is set up and trap machinery operational. Double-check that > there is no any early framebuffer access, as a drastic measure remove > all framebuffer drivers from your kernel config. > > I

Re: programs like gdb core dump

2018-08-08 Thread John Baldwin
On 8/7/18 7:00 PM, Erich Dollansky wrote: > Hi, > > On Tue, 7 Aug 2018 11:59:11 -0700 > John Baldwin wrote: > >> On 8/6/18 8:11 PM, Erich Dollansky wrote: >>> On Mon, 6 Aug 2018 15:57:53 -0700 >>> John Baldwin wrote: >>> >>>> On

Re: programs like gdb core dump

2018-08-07 Thread John Baldwin
On 8/6/18 8:11 PM, Erich Dollansky wrote: > Hi, > > On Mon, 6 Aug 2018 15:57:53 -0700 > John Baldwin wrote: > >> On 8/4/18 4:38 PM, Erich Dollansky wrote: >>> Hi, >>> >>> I compiled me yesterday this system: >>> >>> 12.0-CURREN

Re: programs like gdb core dump

2018-08-06 Thread John Baldwin
; > Bad system call (core dumped) > > Trying to install ports results in the same effect. > > Erich Did you upgrade from stable/11 with a world that is still stable/11? If so, did you make sure your kernel config includes COMPAT_FREEBSD11?

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-08-03 Thread John Baldwin
I decided that it was better to fix our stdatomic.h, so I have a review to do that at https://reviews.freebsd.org/D16585 -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-07-27 Thread John Baldwin
ight be to fix sys/cdefs.h and sys/stdatomic.h to actually work with modern GCC by having them not use the struct for the _GCC_ATOMICS case, only for the _SYNC case. I think that would fix all of the cases. -- John Baldwin ___ freebsd-current@free

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-07-26 Thread John Baldwin
der for the > directories for now. I finally got the approval 2 days ago to remove float.h from amd64-gcc so you shouldn't need this reverted anymore once the OFED thing is straightened out. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-07-26 Thread John Baldwin
On 7/26/18 10:55 AM, Mark Millard wrote: > > > On 2018-Jul-26, at 10:21 AM, John Baldwin wrote: > >> On 7/25/18 6:52 PM, Mark Millard wrote: >>> >>> >>> On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: >>> >>> >>> >>

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-07-26 Thread John Baldwin
On 7/25/18 6:52 PM, Mark Millard wrote: > > > On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: > > > >> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: >> >>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>> >>>> On 7/24/18 11:

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-07-25 Thread John Baldwin
On 7/25/18 10:09 AM, Mark Millard wrote: > > > On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: > >> On 7/24/18 11:39 PM, Mark Millard wrote: >>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>> >>>> https://ci.freebsd.org/job/FreeBSD-hea

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-07-25 Thread John Baldwin
mpiler-provided headers since they are a part of the language (and the system stdatomic.h simply attempts to mimic the compiler-provided header in case it is missing). Simple standalone tests of _Atomic(int) with GCC don't trigger those failures when using its stdatomic.h, so there is probably somethin

Re: atomic changes break drm-next-kmod?

2018-07-05 Thread John Baldwin
On 7/5/18 12:36 PM, Konstantin Belousov wrote: > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote: >> On 07/05/18 20:59, Hans Petter Selasky wrote: >>> On 07/05/18 19:48, Pete Wright wrote: >>>> >>>> >>>> On 07/05/2018 10

Re: atomic changes break drm-next-kmod?

2018-07-05 Thread John Baldwin
On 7/3/18 5:10 PM, Pete Wright wrote: > > > On 07/03/2018 15:56, John Baldwin wrote: >> On 7/3/18 3:34 PM, Pete Wright wrote: >>> >>> On 07/03/2018 15:29, John Baldwin wrote: >>>> That seems like kgdb is looking at the wrong CPU. Can you use >>

Re: atomic changes break drm-next-kmod?

2018-07-03 Thread John Baldwin
. You could also try using just 'r' to always force the use of a register. It would be less optimal than "er" but should function correctly. > On Tue, Jul 3, 2018 at 15:38 Pete Wright <mailto:p...@nomadlogic.org>> wrote: > > > > On 07/03/2018 15:29, Joh

Re: atomic changes break drm-next-kmod?

2018-07-03 Thread John Baldwin
On 7/3/18 3:34 PM, Pete Wright wrote: > > > On 07/03/2018 15:29, John Baldwin wrote: >> That seems like kgdb is looking at the wrong CPU. Can you use >> 'info threads' and look for threads not stopped in 'sched_switch' >> and get their backtraces? You could also just

Re: atomic changes break drm-next-kmod?

2018-07-03 Thread John Baldwin
On 7/3/18 3:20 PM, Pete Wright wrote: > > > On 07/03/2018 15:12, Pete Wright wrote: >> >> >> On 07/03/2018 14:17, Pete Wright wrote: >>> >>> >>> On 07/03/2018 12:02, John Baldwin wrote: >>>> On 7/3/18 11:28 AM, Niclas Zeising wr

Re: atomic changes break drm-next-kmod?

2018-07-03 Thread John Baldwin
quot;, "ir", v); -ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); -ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v); -ATOMIC_ASM(add, long, "addq %1,%0", "ir", v); -ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v); +ATOMIC_ASM(set, long, "orq %1,%0", "er", v); +ATOMIC_ASM(clear,long, "andq %1,%0", "er", ~v); +ATOMIC_ASM(add, long, "addq %1,%0", "er", v); +ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v); #defineATOMIC_LOADSTORE(TYPE) \ ATOMIC_LOAD(TYPE); \ -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-30 Thread John Baldwin
On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-30 Thread John Baldwin
On 6/30/18 9:17 AM, Mark Millard wrote: > On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > >> On 6/29/18 2:37 PM, Mark Millard wrote: >>> [I expect this is more than just amd64-gcc related but that is all >>> that ci.freebsd.org normally builds via a devel/*-g

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-30 Thread John Baldwin
eement on LDBL_MANT_DIG. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread John Baldwin
when at all possible. It's not clear to me if amd64 should be using the compiler provided values of things like LDBL_MIN/MAX either btw. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread John Baldwin
amd64-binutils: 2.30_3,1 > > and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 > (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). > > This indicates that -r465416 and -r466701 did not cause: > > --sysroot=/workspace/obj/workspace/src/amd64.amd64

Re: TSC calibration in virtual machines

2018-06-27 Thread John Baldwin
different > timecounter: > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/80.html I suspect you are probably right that we should just "trust" TSC frequencies provided by a hypervisor. We could perhaps choose to whitelist hypervisors known to provide accurate valu

Re: Resume without drm driver results in black screen

2018-06-15 Thread John Baldwin
of driver for the GPU that knows how to turn the display back on. That isn't a portable thing, it's GPU-specific. You could perhaps write smaller drivers that only support resume and not graphics acceleration, but that doesn't seem trivial. -- John Baldwin __

Re: kgdb crashing on a vmcore with dumptid = 0

2018-06-15 Thread John Baldwin
> old_chain = 0x804431820 > ti = 0x7fffd550 > kt = 0x0 > nkvm = 0x804363800 > temp = 0x8047f33b0 "/home/eax/crashes/aes_gpault_crash/vmcore.2" > kernel = 0x8043dec80 "/home/eax/crashes/aes_gpault_crash/kernel/kernel" > filename = 0x8047f33b0 "/home

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-18 Thread John Baldwin
ns on I/O APICs, so IRQ 256 is already reserved for use by one of those interrupt pins. The real fix is that I need to make FIRST_MSI_INT dynamic instead of a constant and just define it as the first free IRQ after the I/O APICs have probed. -- John Baldwin ___

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

2018-04-17 Thread John Baldwin
} > root@test:/usr/src > > If you need any aditional information please tell me about. Can you perhaps turn off the stack trace on boot to not lose the panic messages (remove KDB_TRACE from kernel config) and maybe modify the panic message to include the IRQ number pas

  1   2   3   4   5   6   7   8   9   10   >