Re: Sharing compiled builds between multiple 12-CURRENT boxes.

On Sun, Aug 19, 2018 at 12:34:20AM +0200, Dhananjay Balan wrote: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

On Thu, Aug 16, 2018 at 12:49:06PM -0700, Bryan Drewery wrote: > ... > r337928 should fix it. > > > -- > Regards, > Bryan Drewery > Just tested after applying r337928 on top of sources at r337903; the rebuild after restoring crypto/openssh/moduli was successful: FreeBSD

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

On Thu, Aug 16, 2018 at 12:43:42PM -0400, Charlie Li wrote: > > I've found this one intermittent at best. I'll run a buildworld on > anything newer than r337852, get the linker error, update to even the > next newer revision that changes completely unrelated files, build > succeeds. Case in

/usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

Running: FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80 r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 after updating working copy to r337903, I'm seeing: ... >>> stage 4.3: building

Re: r337738 -> r337834: Forth loader OK; Lua loader says "BTX halted"

On Wed, Aug 15, 2018 at 10:45:03AM -0600, Warner Losh wrote: > ... > You may need to build a smaller loader_lua. If so please see > https://reviews.freebsd.org/D16724 and apply and rebuild. The good news is > that you only need to rebuild src/stand, which is fast. > > Warner Aye; testing that

r337738 -> r337834: Forth loader OK; Lua loader says "BTX halted"

I'm tracking head/amd64 daily twice on each of two machines: my "build machine" ("freebeast") and my laptop, each first using the traditional Forth loader, then (on a different slice), the Lua loader. Each is using BIOS and MBR (not UEFI; not GPT). Yesterday's update was to r337738, and was

Re: Unexpected results with 'mergemaster -Ui'

Of course, I then saw that you *had* an "ntpd" entry in your side anyway. Sorry for the noise. Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300 See

Re: Unexpected results with 'mergemaster -Ui'

On Sat, Aug 11, 2018 at 10:48:33AM +0200, Kurt Jaeger wrote: > Hi! > > > line 133 onwards, for example. > > > > I never before found any potential change to > > /etc/group > > > > Please, is it unusual? > > No, it is normal, that happens if you have local

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

On Sat, Aug 04, 2018 at 02:31:56PM +0300, Toomas Soome wrote: > ... > It probably r337271, could you check https://reviews.freebsd.org/D16588? > > > rgds, > toomas > Success: FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #69

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

On Sat, Aug 04, 2018 at 02:31:56PM +0300, Toomas Soome wrote: > ... > > It probably r337271, could you check https://reviews.freebsd.org/D16588? > > > rgds, > toomas > Thanks; I'll give that a try & report back. Peace, david -- David H. Wolfskill

"Can't load kernel" after r337232 -> r337285 update (amd64)

Yesterday, the daily build/smoike-test of head yielded: FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #68 r337232M/337232:1200076: Fri Aug 3 03:52:52 PDT 2018 r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 (This is on my laptop; my build

Re: ntpd as ntpd user question

On Mon, Jul 23, 2018 at 04:00:04PM +, Filippo Moretti wrote: > I have ntpd both in etc(passwd and /etc/group but installworld fail saying > that user ntpd is missing can you please let me know how > to manually edit the entries for ntpd in both files.Etcupdate fails > .It is rather odd

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

On Fri, Jun 08, 2018 at 11:40:37AM -0400, Jonathan T. Looney wrote: > ... > If anyone is hitting this bug and needs to get a working system in the > meantime, you'll need to revert the following commits which implemented (or > updated) this change: > > r334830 > r334829 > r334824 > > Jonathan I

Panic from ipfw_alloc_rule() after r334769 -> r334832

Sorry for lack of much analysis; am at BSDCan. jtl@ suggested that a sequence of changes involving memory allocation and ipfw counters is likely to be at issue. I tried grabbing some screen shots, the last of which has a backtrace (that isn't cut off, as the middle one is); they are available at

Re: Error build nvidia-driver with r334555

On Sun, Jun 03, 2018 at 06:48:01PM +0700, Alex V. Petrov wrote: > > --- nvidia_subr.o --- > > > nvidia_subr.c:367:26: error: 'memset' call operates on objects of type > 'struct nv_ioctl_card_info' while the size is based on a different type > 'struct nv_ioctl_card_info *' [-Werror,-Wsizeof

You might want to be careful around r334147...

I had no issues on my build machine (head/amd64; GENERIC kernel) performing src-based upgrades from r333974 -> r334147 -> r334205 (first step yesterday; second today). On my laptop (also head/amd64; lightly-customize kernel that includes GENERIC), I was able to go from r333974 -> r334147, booted

Re: Something between r333623 - r333670 locks up at start of boot

On Thu, May 17, 2018 at 09:34:03AM +0200, Jean-Sébastien Pédron wrote: > ... > I broke syscons(4) yesterday and bde@ provided a patch which cem@ > committed in r333683 [1]. > > It should work again for you now. Sorry for the breakage. > Aye, all better now: FreeBSD g1-215.catwhisker.org

Something between r333623 - r333670 locks up at start of boot

...on my laptop. Build machine was "fine." Links -- including to copies of most recent verbose dmesg.boot files -- may be found at . Last successful build & smoke-test of head on my laptop was: FreeBSD g1-215.catwhisker.org 12.0-CURRENT

panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

This was running: FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 during boot, after updating from: FreeBSD g1-215.catwhisker.org

Re: "panic: Unholding 5 with cnt = 0" head/amd64 @r331290

On Wed, Mar 21, 2018 at 04:26:57PM +0400, Roman Bogorodskiy wrote: > ... > > Anything I can/should do to poke at it before trying to capture a dump? > > Looks like it's related to: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510#c18 > . Hmm... OK; thanks. I went ahead and

"panic: Unholding 5 with cnt = 0" head/amd64 @r331290

This is on my build machine, running a GENERIC kernel. (Laptop is still building lib32 shim libraries as I type). Here's a copy/paste from the serial console: da3: Attempt to query device size failed: NOT READY, Medium not present da3: quirks=0x2 da3: Delete methods: GEOM: new

Possible race in buildworld, @r330236 -> @r330274

On the two machines where I track head daily, I had failures during "make buildworld" ... in different places on the two machines; re-trying the build succeeded (in each case). Lately, I have (also) been tracking head on these machines with /etc/src.conf augmented with: # For Lua loader

Kernel selection in Lua loader

The Lua loader appears to be using a mechanism other than the "kernels=..." specification in /boot/loader.conf to slect potential kernels to load. I'm not claiming this is "bad" -- just "different." I noticed because I sometimes build a kernel that ... panics, or some such thing, so I hve had

Re: ACPI panic on boot with new Lua loader and other minor issues

gt; > For reasons unknown, ACPI is off, as shown by David Wolfskill in a > previous message: > https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html That has been fixed (for me, at least). My last two build/smoke-tests were at r329517 and r329561; I believe that r

Re: LUA boot loader coming very soon

Also, after reverting r329225, I was able to build & boot the build machine with the Lua loader... but I didn't even see any way of interacting with it on the serial console. (I do get that opportunity with the Forth loader.) Peace, david -- David H. Wolfskill

Re: Crash during boot [g_part_wither()?] @r329259

On Wed, Feb 14, 2018 at 06:09:51AM -0800, Cy Schubert wrote: > Try reverting this https://svnweb.freebsd.org/changeset/base/329225 for now. > Aye; thanks: after 'svn merge -c -329225 ^/head /usr/src' & a rebuild/install, the boot completes: FreeBSD freebeast.catwhisker.org 12.0-CURRENT

Re: LUA boot loader coming very soon

On Mon, Feb 12, 2018 at 08:27:27AM -0700, Warner Losh wrote: > ... > So please give it a spin and give me any feedback, documentation updates > and/or bug fixes. I'm especially interested in reviews from people that > have embedded Lua in other projects or experts in Lua that can improve the >

Crash during boot [g_part_wither()?] @r329259

I got one of these on each of my laptop and build machine; details beelow are from the build machine (which has a serial console and runs a vanilla GENERC kernel). Previous (successful) builld was r329197 (for both machines), yesterday. Copy/paste from serial console: ... da1: Serial Number

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote: > > > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error. > > > At least, removing it fixes build for me. FWIW, I have never specified WITH_AUTO_OBJ -- and I do encounter the "Variable OBJTOP is recursive"

Re: HEAD amd64 seems unhappy

On Sat, Feb 03, 2018 at 08:38:22PM -0600, Josh Paetzel wrote: > --- all_subdir_lib/libngatm --- > /usr/src/sys/contrib/ngatm/netnatm/api/cc_port.c:71:28: error: result of > comparison 'u_int' (aka 'unsigned int') > 4294967295 is always fal > se [-Werror,-Wtautological-type-limit-compare] >

Change in head breaks install of port x11/nvdia-drive-340?

I'm tracking stable/11 & head (on separate slices) on my laptop, which uses the x11/nvidia-driver-340 port -- which has a kernel module. Thus, I have: PORTS_MODULES=x11/nvidia-driver-340 in /etc/src.conf (for each of stable/11 and head), so every time the kernel is rebuilt, the kernel module

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote: > On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill <da...@catwhisker.org> > wrote: > > > This is on my "build machine" (laptop is still building updated ports > > for today, so I don't

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

On Fri, Jan 26, 2018 at 04:29:47AM -0800, David Wolfskill wrote: > This is on my "build machine" (laptop is still building updated ports > for today, so I don't know yet whether or not it encounters this.) > The laptop did the same source-based update, and did no

Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

This is on my "build machine" (laptop is still building updated ports for today, so I don't know yet whether or not it encounters this.) I had performed a source-based update from r328393 to r328436, rebooted, performed "make delete-old-libs", and all seemed well. I then issued "sudo shutdown

r328075 appears to break sbin/fsdb

As O. Hartmann noted (in svn-src-head@), the change to rename cgget to cglookup also affects fsdb: --- all_subdir_sbin/fsdb --- --- fsdb.o --- /usr/src/sbin/fsdb/fsdb.c:479:9: error: implicit declaration of function 'cgget' is invalid in C99 [-Werror,-Wimplicit-function-declaration] cgbp

Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140

On Sun, Dec 24, 2017 at 03:16:59PM +0100, Dimitry Andric wrote: > ... > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 2; apic id = 02 > > instruction pointer = 0x20:0x81066968 > > stack pointer = 0x28:0x82286a90 > > frame pointer

Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140

On Sun, Dec 24, 2017 at 03:03:33PM +0100, O. Hartmann wrote: > ... > So, it is dangerous to update beyond r327121? I'm running on most of our > machines now > r327121 and it does not show nay anomalies so far ... > > Regards, > Oliver > . Hmm... Well, reviewing the output from "svn log", I

Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140

Had this on the laptop; fotunately, also got it on the build machine (as it's a lot easier to work with the serial console of the latter for this -- and it runs a GENERIC kernel): ... FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #51 r327140M/327142:1200054:

Re: /usr/obj is 11GB huge on FreeBSD 12-current

On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: > Hi, > > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > is now 11GB huge: > > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj > > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj >

Re: kernel names

On Thu, Dec 14, 2017 at 09:17:36AM -0800, bob prohaska wrote: > On Thu, Dec 14, 2017 at 01:47:13PM +0800, blubee blubeeme wrote: > > When you boot into FreeBSD and you can select kernels, there's only 2 > > options: > > default and kernel.old > > > > Is there a way to have better output and

Re: logger(1) exited on signal 11 after r326525 -> r326622

On Wed, Dec 06, 2017 at 08:54:52PM +0300, Maxim Konovalov wrote: > Hi David, > > On Wed, 6 Dec 2017, 05:12-0800, David Wolfskill wrote: > > > I noticed among the messages on the console during the final stages of > > the transition from single- to multi-user mode

logger(1) exited on signal 11 after r326525 -> r326622

I noticed among the messages on the console during the final stages of the transition from single- to multi-user mode: ... Dec 6 12:53:13 g1-252 kernel: ugen2.3: at usbus2 Dec 6 12:53:13 g1-252 kernel: ugen1.3: at usbus1 Dec 6 12:53:13 g1-252 kernel: pid 334 (logger), uid 0: exited on signal

Re: what happened to src/sys/boot?

On Sat, Dec 02, 2017 at 03:42:07PM +0200, Daniel Braniss wrote: > Hi, > it seems to have disappeared. > ... Ref. r325834: r325834 | imp | 2017-11-14 15:02:19 -0800 (Tue, 14 Nov 2017) | 4 lines Move sys/boot to stand. Fix

Re: Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional

On Sun, Nov 05, 2017 at 08:13:27AM -0800, Simon J. Gerraty wrote: > Simon J. Gerraty wrote: > ... > > I think I might have a fix for that. > > Or rather I know what the issue is - RELDIR isn't defined because > .CURDIR isn't under SRCTOP, > if OBJTOP were defined at that point,

Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional

This is a self-hosted amd64; the failure was during the (re)build of the kernel module for x11/nvidia-driver-340 as the final bit of "make buildkernel": ... >>> stage 3.1: building everything ... ===> nvidia-driver-340-340.102 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===>

Re: panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

On Tue, Oct 31, 2017 at 02:35:19PM +0200, Andriy Gapon wrote: > On 31/10/2017 14:32, David Wolfskill wrote: > > Andriy, I "cloned" the slice before doing the above, so I can poke > > at this a bit more (e.g., try to get a crash dump), if that would > > still be usef

Re: panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

On Tue, Oct 31, 2017 at 01:53:27PM +0200, Konstantin Belousov wrote: > ... > > db> > > Try to revert r325227. OK; did that, via "svn merge -c -r325227 ^/head"; rebuilt/installed kernel, and a reboot was ... boringly normal. :-) FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT

panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

Performed the usual src update in head/amd64; today was from r325137 to r325228. Laptop had no complaints; everything Just Worked (as usual). This time, it was the build machine that whined -- rather less inconvenient for me. :-} Here's what it says currently: ... APIC: Using the MADT

Re: /sys/boot compile broken

On Sat, Oct 21, 2017 at 08:41:04AM +0200, Gary Jennejohn wrote: > SVN for HEAD source at 324810. > > Compiling /sys/boot is totally screwed up. The failure is that > geliboot.c cannot be found. > > This prevents a successful ``make buildworld''. I did not encounter this issue in my upgrade

Re: cve-2017-13077 - WPA2 security vulni

On Tue, Oct 17, 2017 at 12:51:23PM -0400, Allan Jude wrote: > > > Question: Should one expect a wpa_supplicant-2.6_2 executable built > > under FreeBSD stable/11 (amd64) to work on the same hardware, but > > running head? > > Did you run the version from ports, or did you run the base

Re: cve-2017-13077 - WPA2 security vulni

On Mon, Oct 16, 2017 at 11:27:00PM -0700, Cy Schubert wrote: > In message , Franco > Fichtne > r writes: > ... > > wpa_supplicant 2.6_2 > > > > No apparent issues with the ports, preliminary connectivity > > checks work as expected.

Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)

On Fri, Oct 13, 2017 at 08:48:11AM -0700, Matt Joras wrote: > On 10/13/2017 05:33, David Wolfskill wrote: > > On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: > >> ... > >>> panic: UNR inconsistency: items 0 found 7 (line 361) > >

Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)

On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: > ... > > panic: UNR inconsistency: items 0 found 7 (line 361) > > > Revert r324542 and try again. > > This revision was not tested with DIAGNOSTIC enabled. OK; I believe we have a winner! Thanks! :-) I copied the head slice

Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)

On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: > ... > > panic: UNR inconsistency: items 0 found 7 (line 361) > > > Revert r324542 and try again. Will do; but I have a few things to get done first, so it may be an hour or so before I can report results. > This revision was

@r324591: panic: UNR inconsistency: items 0 found 7 (line 361)

This occurred after I had booted & smoke-tested my laptop, then issued "sudo shutdown -r now"; it's *possible* that there was also a (similar?) problem shutting down yesterday (@r324542), but the screen had gone dark and declined to shed any light, so I'm not sure on that point. uname strings

Re: r324053: kldxref: Parse error of description string U32:vendor;U32:device;P;D:human

On Wed, Sep 27, 2017 at 05:08:23AM -0700, David Wolfskill wrote: > On Wed, Sep 27, 2017 at 11:23:22AM +0200, O. Hartmann wrote: > > The installation of a newly, prsitine build kernel fails on CURRENT with the > > error shown below: > > > > [...] > > kldxref /boo

Re: r324053: kldxref: Parse error of description string U32:vendor;U32:device;P;D:human

On Wed, Sep 27, 2017 at 11:23:22AM +0200, O. Hartmann wrote: > The installation of a newly, prsitine build kernel fails on CURRENT with the > error shown below: > > [...] > kldxref /boot/kernel > kldxref: Parse error of description string U32:vendor;U32:device;P;D:human > *** [afterinstall] Error

Re: Panic: @r323525: iflib

On Wed, Sep 13, 2017 at 09:21:57AM -0600, Sean Bruno wrote: > ... > When you get a chance, let me know what em(4) device is in your machine > (pciconf -lvbc). I'll see if I have one around here to test. stable/11 says: em0@pci0:0:25:0:class=0x02 card=0x05cc1028 chip=0x153a8086

Panic: @r323525: iflib

My build machine didn't have the problem -- unfortunately (as I have a serial console on it). The laptop did The panic occurs immediately after probing the NICs (so the good news is that it didn't have a chance yet to mount any filesystems; the bad news is that there's no dump available).

Re: extending the maximum filename length

On Sat, Sep 09, 2017 at 01:15:31AM +0800, Julian Elischer wrote: > Has anyone using freeBSD ever increased NAME_MAX (filename maximum > length) and have any experience with it? > > We ($JOB) would recompile the entire system so intra-system > compatibility would probably be ok, and we have our

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 08:08:57PM +0200, Hartmann, O. wrote: > On Tue, 22 Aug 2017 06:38:36 -0700 > David Wolfskill <da...@catwhisker.org> wrote: > > I also ran into this problem after "upgrading" to r322769 and now I > have on ALL systems, I did this "up

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 08:43:27PM +0300, Konstantin Belousov wrote: > ... > Try this. The patch helped ae@, it seems. > I will commit it anyway in a hour, but more confirmations or nacks > would be good. This patch has some debugging bits which add noise on > console when a process traps. If

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 06:34:42PM +0300, Konstantin Belousov wrote: > ... > > Bisection time? Or if there's another approach (or even a suggestion > > for a revision to try first), I'm up for it. 9And yes, I'll just > > be rebuilding the kernel for the rest of this exercise, I think. > > That

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > ... > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > object directories. > > > > I think I'll need a working /bin/sh to do that. As noted, I could > > try the stable/11 /bin/sh; on the other

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > ... > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > object directories. > > > > I think I'll need a working /bin/sh to do that. As noted, I could > > try the stable/11 /bin/sh; on the other

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 03:34:49PM +0300, Konstantin Belousov wrote: > ... > $ gdb /bin/sh sh.core > (gdb) bt > (gdb) info registers > (gdb) disassemble [New LWP 100182] Core was generated by `sh -c cc --version || echo 0.0.0'. Program terminated with signal SIGSEGV, Segmentation fault. #0

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 08:15:56AM -0400, Ed Maste wrote: > On 22 August 2017 at 07:46, David Wolfskill <da...@catwhisker.org> wrote: > > > > lldb's notion of the backtrace was fairly non-useful: > > g1-252(11.1-S)[7] lldb -c sh.core > > Try: > % lldb /bin

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 02:59:23PM +0300, Konstantin Belousov wrote: > ... > > lldb's notion of the backtrace was fairly non-useful: > > g1-252(11.1-S)[7] lldb -c sh.core > > (lldb) target create --core "sh.core" > > Core file '/home/david/sh.core' (x86_64) was loaded. > > (lldb) bt > > * thread

SIGSEGV in /bin/sh after r322740 -> r322776 update

Started with: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #445 r322740M/322745:1200040: Mon Aug 21 04:35:19 PDT 2017 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 After source-based update (which was uneventful): FreeBSD

Re: Apparent race in buildworld (head/amd64, r322214 -> r322304)

On Wed, Aug 09, 2017 at 12:22:20PM -0700, Bryan Drewery wrote: > > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s > ... > > This should fix it: > https://people.freebsd.org/~bdrewery/patches/gcc_s-install-race.diff > > The problem has consistently been, from your reports, that gcc_s

Re: Panic on boot after upgrade from r320827 -> r320869

On Tue, Jul 11, 2017 at 08:32:26AM -0600, Warner Losh wrote: > ... > > While O. Hartmann had written to indicate the he had identified r320844 > > as the culprit, and I had other reason to suspect it, I was a bit busy > > at work yesterday, and unable to determine this for myself empirically. > >

Re: Panic on boot after upgrade from r320827 -> r320869

On Mon, Jul 10, 2017 at 04:51:09AM -0700, David Wolfskill wrote: > Pnic occurred prior to mounting file systems While O. Hartmann had written to indicate the he had identified r320844 as the culprit, and I had other reason to suspect it, I was a bit busy at work yesterday, and una

Panic on boot after upgrade from r320827 -> r320869

Pnic occurred prior to mounting file systems; I was able to boot from the r320827 (as "kernel.old") OK. I was not able to get a dump. Both the laptop and the build machine panicked, but the build machine's keyboard was unresponsive and its serial console isn't funtioning at the moment (because

Re: r320528? "undefined reference to `_bus_dma*" linking kernel

On Sat, Jul 01, 2017 at 08:59:58AM -0700, Jason Harmening wrote: > ... > These are all functions that were removed entirely or inlined for x86 in > r320528. > Looks like you have stale object files hanging around, seems like make > clean should fix it. OK; I'll pass that along to bdrewery@, as

r320528? "undefined reference to `_bus_dma*" linking kernel

This is for a transition from r320495 --> r32053ng: FreeBSD g1-227.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #396 r320495M/320496:1200036: Fri Jun 30 05:20:04 PDT 2017 r...@g1-227.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 ... >>> World build completed on Sat Jul 1

Re: r320358 panics immediately on boot / AMD64-GENERIC kernel

On Tue, Jun 27, 2017 at 12:09:56PM -0400, Michael Jung wrote: > Screen image with backtrace > > https://pasteboard.co/dZRVG5Uo.jpg > > > After upgrading from 318959 to 320358 I immediately get the attached > panic. > > This is AMD64 / GENERIC kernel. > > /boot/loader.conf is empty. > > The

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > ... > > Hmmm. > > As if computer tries to say you, do not use meta mode. For building the kernel, on head as of some commit after r320307 (but by r320324). Peace, david -- David H. Wolfskill

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote: > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > > KLD geom_eli.ko: depends on kernel - not available or version mismatch > > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type &

Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

This is amd64: FreeBSD 12.0-CURRENT #386 r320324M/320326:1200035: Sun Jun 25 06:36:19 PDT 2017 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 After a src update to r320353, the last several lines on the serial console from the initial (verbose) reboot are: ...

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > ... > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

On Sun, Jun 25, 2017 at 04:21:16PM +0300, Konstantin Belousov wrote: > ... > > #cat /etc/src-env.conf > > WITH_META_MODE=yes > > So can you _remove_ all kernel object files and rebuild anew with the > clean build dir, please ? OK; that seems to have resulted in a kernel that boots to multi-user

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote: > ... > > > The layout of the struct vm_map_entry was changed, the faulted address > > > is somewhat consistent with ABI mismatch. > > > > Kinky. :-} > Do you use any third-party modules ? On the laptop, I use

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

On Sun, Jun 25, 2017 at 03:32:26PM +0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x120 > This is clear

Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

Both on laptop and build machine; fortunately for me, the latter has a serial console, so: __ _ _ | | | _ \ / | __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_)

Re: post ino64: lockd no runs?

On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > of my systems after a full rebuild of src and ports. No log entries > offer any insight as to why :-( > > imb I don't tend to use NFS on my systems

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

On Fri, Jun 09, 2017 at 08:23:55AM -0700, David Wolfskill wrote: > ... > > The main suspect is r319722. > > Try reverting it or downgrading before it (the later might be simple due > > to the patch size). > > > > It was easy enough for me to use "svn dif

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

On Fri, Jun 09, 2017 at 04:55:17PM +0300, Konstantin Belousov wrote: > On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote: > > Build machine updated from r319689 to r319733 OK; smoke test was > > uneventful. > > > > Laptop updated similarly, but s

Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

Build machine updated from r319689 to r319733 OK; smoke test was uneventful. Laptop updated similarly, but smoke test was a little more "interesting". Turns out that laptop gets to multi-user mode OK... if I disable starting xdm, devd, and hald. But then, issuing "service hald onestart"

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > This is on my "build machine"; running GENERIC/amd64 built yesterday: > Nevermind. Replacing /usr/src with a fresh checkout resolved the issue. Peace, davdi -- David H. Wolfskill

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > This is on my "build machine"; running GENERIC/amd64 built yesterday: > > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353 > r318739M/318739:1200031: Wed May 24 10:0

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > ... > I have attached a copy of the meta file in question. > Bah. Really attaching this time. Peace, david -- David H. Wolfskill da...@catwhisker.org "[T]he president’s im

Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

This is on my "build machine"; running GENERIC/amd64 built yesterday: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353 r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 after updating

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 01:42:39PM -0700, Simon J. Gerraty wrote: > David Wolfskill <da...@catwhisker.org> wrote: > > As far as I can tell, the "ld" command was: > > Since you have the .meta file, it should tell you exactly what the > command was and what

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote: > ... > > > I have updated /usr/src back to 318781, then started a new build. > > So are you building stock 318781, or did you reverted r318750 ? > > Stock 318781 [*]. I revert as a (nearly) last resort. :

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 05:16:38PM +0300, Konstantin Belousov wrote: > On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote: > > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > > > If build of r318739 succed, can you try, please, to r

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > ... > > (lldb) bt > > * thread #1, name = 'ld', stop reason = signal SIGSEGV > > * frame #0: 0x > > (lldb) > > > > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV. > Useful gdb is in

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote: > ... > > building special pic c library > > --- libc.so.7 --- > > cc: error: unable to execute command: Segmentation fault (core dumped) > > cc: error: linker command failed due to signal (use -v to see invocation) > > ***

ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

Yesterday's in-place src update (r318606 -> r318739) was a bit more "interesting" than usual; as has been noted elsewhere, it really is necessary to boot the new kernel before the "make installworld" completes successfully. That said, it ("make installworld") did complete successfully, and a

Re: filemon: weird full-time build although filemon enabled

On Mon, May 08, 2017 at 07:32:58PM +0200, O. Hartmann wrote: > Am Mon, 8 May 2017 10:17:05 -0700 > "Simon J. Gerraty" schrieb: > ... > > bmake has a set of knobs for telling it to ignore things. > > OP try > > > > .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d > > > >

Re: make buildworld broken at r317821 (libsysdecode)

On Fri, May 05, 2017 at 07:05:14PM +0800, Alastair Hogge wrote: > On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote: > > Hello! > > > > Cannot build world due to error in compiling lib/libsysdecode. Cleaning > > (make clean, make cleandepend and wiping out ccache data) does not help. > > >

<    1   2   3   4   5   6   7   8   9   >