Re: Identifying broken applications following careless use of make -DBATCH_DELETE_OLD_FILES delete-old-libs

I find that "pkg_libchk" (from ports-mgmt/bsdadminscripts2) is helpful for such cases. Peace, david -- David H. Wolfskill da...@catwhisker.org As if Trump's lies weren't obvious already, Palin has joined in to prove it. See

Re: Laptop exhibits erratic responsiveness

On Mon, Nov 30, 2020 at 11:03:29PM +0200, Konstantin Belousov wrote: > ... > > I suppose I will be commenting out that DIAGNOSTIC option now :-} > > Try to just set debug.vmem_check to 0 and see if it helps. > ... OK; I rebooted the new(er) laptop with the previous kernel (that was built

Re: Laptop exhibits erratic responsiveness

On Mon, Nov 30, 2020 at 05:21:28AM -0800, David Wolfskill wrote: > ... > FWIW, the copy of the laptop's "head" kernel config in > http://www.catwhisker.org/~david/FreeBSD/head/CANARY is current. > > And the only difference between the stable/12 config and the head confi

Re: Laptop exhibits erratic responsiveness

On Mon, Nov 30, 2020 at 02:10:51PM +0100, Mateusz Guzik wrote: > ... > > I definitely do NOT see anything like this running stable/12 (presently > > at r368181). > > > > I will try some experiments with another laptop (a newer one, for which > > the built-in mouse is detected weirdly, making it

Re: Laptop exhibits erratic responsiveness

On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote: > On 11/29/20, David Wolfskill wrote: > > On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote: > >> FWIW, I would try running lockstat on the box. (My supposition is that > >> the > >>

Re: Laptop exhibits erratic responsiveness

On Sun, Nov 29, 2020 at 08:16:22AM -0800, David Wolfskill wrote: > On Sun, Nov 29, 2020 at 11:04:46AM -0500, Ryan Stone wrote: > ... > > I believe that if you run lockstat with the additional "-x > > destructive" option, it will disable the responsiveness test (the

Re: Laptop exhibits erratic responsiveness

On Sun, Nov 29, 2020 at 11:04:46AM -0500, Ryan Stone wrote: > On Sun, Nov 29, 2020 at 9:12 AM David Wolfskill wrote: > > OK, and demonstrated some long RTTs about every 11 packets or so, but we > > see thing come to a screeching halt with: > > > > ... > > 64 byt

Re: Laptop exhibits erratic responsiveness

On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote: > ... > According to the data you got the entire kernel "freezes" every 11-12 > seconds. So something way off is going on there. I'm (quite) prepared to believe that. :-} > Given that the bug seems to be reproducible I think it would

Re: Laptop exhibits erratic responsiveness

On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote: > FWIW, I would try running lockstat on the box. (My supposition is that the > delay is due to a lock. That could be incorrect. Lockstat may provide some > clue as to whether this is a line of inquiry worth pursuing.) > Thanks

Laptop exhibits erratic responsiveness

I've delayed trying to send this, as I wasn't clear on how to express it -- and I had hoped that the problem would "go away" before I figured that part out: I first observed it around 09 Nov, which is when I updated the laptop (via in-place source upgrade, as usual) from r367484 to r367517. One

Re: what's going on with SVN ?

On Fri, Nov 20, 2020 at 11:51:32AM +0100, Claude Buisson wrote: > Hello, > > $ svnsync sync file:///home/svnmirror/base > svnsync: E170013: Unable to connect to a repository at URL > 'https://svn.freebsd.org/base' > svnsync: E65: Error running context: No route to host > > $ host

Re: in -current is svn still canonical?

On Mon, Nov 16, 2020 at 10:32:38PM -0700, Warner Losh wrote: > ... > However, when you make the switch to git (either due to the flag day and > tracking -current, or jumping from svn on a stable branch), there's no tool > to convert the subversion checked out tree to a git tree. The needed >

Re: immediate panic after nvidia load

On Tue, Nov 10, 2020 at 02:37:53PM +0100, h v wrote: > Hi, > ... > >> recent current (faf24c828d5-c254344(main)): macmini3,1 panics after > >> loading nvidia (nvidia-driver-340-340.108_2) > >> > >> > >> How to proceed ? > >> > >> Kind Regards > >> > >> Henry > >> > > When you built the

Re: immediate panic after nvidia load

On Tue, Nov 10, 2020 at 01:09:14PM +0100, h v wrote: > Hi, > > recent current (faf24c828d5-c254344(main)): macmini3,1 panics after > loading nvidia (nvidia-driver-340-340.108_2) > > > How to proceed ? > > Kind Regards > > Henry > When you built the kernel, did you also rebuild the

Re: "make[2]: don't know how to make /usr/src/sys/net/route/route_ifaddrs.c. Stop"

On Sun, Nov 08, 2020 at 03:16:02PM +0100, Herbert J. Skuhra wrote: > On Sun, Nov 08, 2020 at 06:02:33AM -0800, David Wolfskill wrote: > > Resolved by r367486. > > e.g. svnmir.bme.FreeBSD.org is still at r367484. Why the delay? > > And the certificate of cgit-beta.fr

Re: "make[2]: don't know how to make /usr/src/sys/net/route/route_ifaddrs.c. Stop"

Resolved by r367486. Peace, david -- David H. Wolfskill da...@catwhisker.org So now Donald J. Trump is demonstrating that he's a sore loser (in addition to his other well-known sociopathies). See http://www.catwhisker.org/~david/publickey.gpg for my public key.

"make[2]: don't know how to make /usr/src/sys/net/route/route_ifaddrs.c. Stop"

This is during an in-place source update from: FreeBSD g1-48.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #53 r367444M/367444: Sat Nov 7 05:21:56 PST 2020 r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300127 1300127 to r367484, during "make

Re: r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined

On Fri, Nov 06, 2020 at 09:59:06AM +0100, O. Hartmann wrote: > Just updated CURRENT to r367415 and loading linux kernel module(s) fail with > > # kldload linux > > link_elf_obj: symbol sdt_provider_linuxulator undefined > linker_load_file: /boot/kernel/linux_common.ko - unsupported file type >

"panic: page fault" in iwn signal handler(?) at r367127

I've copied the dump and core.txt files to http://www.catwhisker.org/~david/FreeBSD/head/r367127/ Here's a copy/paste of the stack trace (from the core.txt.3 file): p 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xf8084000 fault code = supervisor

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

On Tue, Aug 18, 2020 at 03:37:50PM +0200, Mateusz Guzik wrote: > So the previous patch should just print a warning. > > Does this take care of the problem in general? I don't have means to > test the patch. > Sorry for the delay, but finished patching & rebuilding, and (essentially), yes.

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: > Try this: > [replacing new KASSERT() with WITNESS_WARN()...] > Thanks; on it. Should take care of it, I think. Peace, david -- David H. Wolfskill da...@catwhisker.org Donald Trump is either

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

On Tue, Aug 18, 2020 at 02:48:47PM +0200, Mateusz Guzik wrote: > see https://reviews.freebsd.org/D26027 > Right; I was just reviewing the list of updated files and noted src/sys/kern/kern_malloc.c, and its svn log showed:

"panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

Just did a src update from r364296 -> r364341 on amd64 on my bild machine (laptop is still working -- it built firefox earlier, which takes some time). On initial reboot, the build machine panicked: umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:6:0: Attached to scbus6

Re: "make installworld" fail r363660 -> r363689 (amd64)

On Thu, Jul 30, 2020 at 07:14:26PM -0500, Kyle Evans wrote: > ... > > I finally just re-retried the "make installworld," and it succeeded. > > > > To be clear, this was just a second installworld without rebuilding, > correct? Yes. The most recent typescript from the build process on that

Re: "make installworld" fail r363660 -> r363689 (amd64)

On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote: > On Thu, Jul 30, 2020 at 6:24 AM David Wolfskill wrote: > ... > > ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make: > > Undefined symbol "regcomp@FBSD_1.6" > > &

Re: "make installworld" fail r363660 -> r363689 (amd64)

On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote: > ... > Hi, > > Can you describe the environment in which you're running installworld, > please? i.e. is it just a raw installworld directly in your shell, or > something more complicated? "make installworld" is being invoked via [t]csh

"make installworld" fail r363660 -> r363689 (amd64)

build{worl,kernel} and installkernel were uneventful, but: ... install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/Mail install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/mailx ===> usr.bin/msgs (install) install -s -o root -g wheel -m 555 msgs /usr/bin/msgs install -o root

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 01:19:33PM -0400, Mark Johnston wrote: > On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote: > > On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: > > > ... > > > This should fix noexec for modules. > >

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: > ... > This should fix noexec for modules. > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > index 81db4d7ca85..cb84fc95691 100644 > --- a/sys/x86/x86/mp_x86.c > +++ b/sys/x86/x86/mp_x86.c > Thanks! Patch

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote: > ... > > Unfortunately, I ran out of time to do further experiments for now; I'll > > need to do some work-related things for a while, but thought that this > > might at least provide some useful information. > > > > Here is what I

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote: > ... > Can you boot into single-user, without loading linux/cuse/nvidia modules. > Even, do not load any module at all, and keeping root ro. > > If boot succeed, then try to load modules one by one and see which causes > panic.

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 10:42:59AM -0400, Mark Johnston wrote: > ... > Since you are preloading some iwm firmware file, it might be worth > trying to revert r362035. I don't really see how the change could > result in this panic, though. It's iwn (vs. iwm), but sure, I'll try that as time

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 04:46:58PM +0300, Konstantin Belousov wrote: > ... > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > > can certainly clean out /usr/obj/* & start a new build (just before I > > head out for a bike ride). > > That, and also rebuild all third-party

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote: > ... > The link times out. Sigh. Sorry about that; I have copied the images to freefall:~dhw/head/r362045/ . > There is not much to access in futex_xchgl_resolver() except for the > data segment. Without full panic message

Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

Build machine (mini-tower) performed the update (r362008 -> r362045) without issue, but my laptop panicked quite early on -- before the dump device was configured. I have taken and placed a couple of screen shots in http://www.catwhisker.org/~david/FreeBSD/head/r362045/ Looking at the displayed

Re: rc.d services started twice

On Sun, Jun 07, 2020 at 04:44:12PM +0200, Andreas Nilsson wrote: > Hello, > > for quite a while I've been noticing that rc-services seems to be start > twice on -CURRENT. Why is this? Is anyone else seeing this? > > I see 'Starting cron' twice, as well as ntpd, loading of modules mounting > of

Re: panic: page fault head/amd64 @r361830

On Fri, Jun 05, 2020 at 06:41:27AM -0700, David Wolfskill wrote: > My build machine had no issues with the upgrade from r361784 to r361830, > but my laptop panicked during the transition from single- to multi-user > mode, just after bpf was attached. > . Thanks to Hans Petter

panic: page fault head/amd64 @r361830

My build machine had no issues with the upgrade from r361784 to r361830, but my laptop panicked during the transition from single- to multi-user mode, just after bpf was attached. Rebooting from the old kernel worked; trying to boot from r361830 failed again with similar symptoms, and the laptop

Re: Error loading tcp_bbr kernel module

On Sat, May 09, 2020 at 02:18:51PM +0200, Gordon Bergling wrote: > Greetings, > > I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error > when I try to load for example tcp_bbr.ko. > > kldload: an error occurred while loading module tcp_rack.ko. Please check > dmesg(8)

Re: Weird mouse behavior after r360108 -> r360140 update

On Tue, Apr 21, 2020 at 01:32:33PM +0200, Mikaël Urankar wrote: > On 21/04/2020 12:57, David Wolfskill wrote: > > The mouse (on my laptop) is... sluggish -- I have an acceleration factor > > of 2.7 specified; behavior is as if that's being ignored. > > > > More annoyi

Re: Weird mouse behavior after r360108 -> r360140 update

On Tue, Apr 21, 2020 at 03:57:40AM -0700, David Wolfskill wrote: > The mouse (on my laptop) is... sluggish -- I have an acceleration factor > of 2.7 specified; behavior is as if that's being ignored. > > More annoying: the "paste" (from "copy/paste") is not work

Weird mouse behavior after r360108 -> r360140 update

The mouse (on my laptop) is... sluggish -- I have an acceleration factor of 2.7 specified; behavior is as if that's being ignored. More annoying: the "paste" (from "copy/paste") is not working. (It's possible that what I'm seeing is that the "copy" part isn't working, so the "paste" part has

Re: sort.core error doing installworld on Current.

On Fri, Apr 17, 2020 at 12:24:41PM +0200, Johan Hendriks wrote: > > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes: > > I have no idea how to bypass this issue. > Sorry; I was busy with work stuff when your original post came by. IIRC, you had several system components excluded from

PORTS_MODULES if you built head between r359681 - r359690

TL;DR: You may want to take evasive action, such as manually copying the r359690 (or later) from src/share/mk/bsd.sys.mk to /usr/share/mk/bsd.sys.mk before attempting to make use of the PORTS_MODULES specificsation if the current version of /usr/share/mk/bsd.sys.mk is from r359681. Details &

Re: kernel build failed

On Sun, Mar 29, 2020 at 02:02:02PM +0300, Alexandr Krivulya wrote: > 28.03.20 18:32, Dimitry Andric пишет: > ... > > This typically happens if you don't run "make buildworld", or at least > > "make kernel-toolchain" before running "make buildkernel", and your > > userland is missing those headers,

Re: kernel build failed

On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote: > Hello, > on latest CURRENT kernel fails to build: > > ===> aesni (all) > [Creating objdir > /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...] > ... >

Re: llvm 10 libomp build error

On Thu, Mar 12, 2020 at 09:13:38AM +, Filippo Moretti wrote: > Same problem yesterdayFilippo > > On Thursday, March 12, 2020, 08:59:17 AM GMT+1, Ronald Klop > wrote: > > Hi, > > Clean build after svn update gives: > > cc: error: no such file or directory:  >

Re: r358062(ncurses) breaks installed ports, howto check?

On Mon, Feb 24, 2020 at 08:19:59PM +0100, O. Hartmann wrote: > Hello, > > After r358062, many installed ports do not work anymore on several running > systems (CURRENT). > /usr/src/UPDATING states one should reinstall all ncurses depending ports, > but no hint is > given! Can someone mitigate

Re: r358220: compiler error: fatal error: '__errc' file not found #include <__errc>

On Fri, Feb 21, 2020 at 03:24:16PM +0100, O. Hartmann wrote: > Hallo, > > > recent CURRENT r358220 (host operating on FreeBSD 13.0-CURRENT #48 r358183: > Thu Feb 20 22:33:34 > CET 2020 amd64), fails to build for me on a couple of boxes: > > [...] > I had no issues building r358220 from

Re: -CURRENT kernel fails to build

On Wed, Feb 19, 2020 at 12:26:02PM +0200, Rares Aioanei wrote: > Hello, > > I'm compiling the latest -CURRENT kernel (rev. 358098) , and I get > null byte errors : > "/stor/src/sys/dev/hyperv/utilities/vmbus_shutdown.c:168:19: error: > null character ignored [-Werror,-Wnull-character]" . If I

Re: CURRENT panciks right after kernel load (r357966)

On Sat, Feb 15, 2020 at 08:54:15PM +0300, Lev Serebryakov wrote: > Hello Current, > > CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics > with page fault right after kernel load (before any kernel output). > > Stacktrace (typed from photo of screen, all trap-related

r357907 seems to have broken sys/kern/vfs_default.c

... Building /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/vdev_file.o --- vfs_default.o --- /usr/src/sys/kern/vfs_default.c:576:10: error: implicit declaration of function 'lockmgr_lock_fast_path' is invalid in C99 [-Werror,-Wimplicit-function-declaration]

GPF just after mounting root at r357726

Looks as if the same thing affected both my laptop and my build machine -- each updated from r357688 (built yesterday & smoke-tested without incident). While I got some screenshots for the laptop, I have a serial console for the build machine, so: ... ---<>--- Table 'FACP' at 0xde3c1b98 Table

Re: Is amd automount still supported in 13.0 or not?

On Tue, Feb 04, 2020 at 09:46:50AM -0600, Bob Willcox wrote: > ... > > Amd is not build by default now and will be removed from base. But you > > can continue using it by installing sysutils/am-utils from port. > > Thanks for the tip. I will likely go ahead and install the am-utils port as >

Re: 13.0-CURRENT r356767 wanted ZFS

On Fri, Jan 17, 2020 at 12:18:41AM +, Clay Daniels wrote: > 13.0-CURRENT r356767 would not take NO for an answer, and kept up a loop > until I gave up trying to use UFS. No big deal, seems to work fine... > > Clay > Err...? Is there some additional context that I'm missing? I've been

Re: Reverting -current by date.

On Wed, Nov 20, 2019 at 09:38:53AM -0800, bob prohaska wrote: > >From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case

Re: ThinkPad: reboots after successful shutdown -p

On Sun, Nov 17, 2019 at 11:14:02PM -0800, Xin Li wrote: > Hi, > > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the > system would shut down and seemingly powered off, then it would restart > after about 5-10 seconds. > > Is this a known issue? Arguably this is not necessarily

Re: Segmentation fault in netstat after r354373 -> r354373 update

On Thu, Nov 07, 2019 at 04:08:28PM +0100, Arnaud Ysmal wrote: > Hi, > > I just got the same issue, it happens when argv[0] does not contain a / > (calling uptime segfault but calling /usr/bin/uptime works). > > In xo_parse_args there is no check whether cp is NULL before calling > xo_streq. >

Segmentation fault in netstat after r354373 -> r354373 update

(I haven't started to look for a culprit yet; thought I'd let folks know about it first. -- dhw) g1-49(13.0-C)[1] uname -a FreeBSD g1-49.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #514 r354436M/354436: Thu Nov 7 04:15:23 PST 2019

Re: 2 things; a cool crash log of my grandmother-laptop, that's plasma's now bricked; vmn0 not X -configuring

On Thu, Oct 10, 2019 at 01:46:10AM +0200, Miranda van den Breukelingen wrote: > 1. First this happened today on my old Dell laptop: > > https://pastebin.com/esMKFz63 > > any suggestions, when booting with 3530XX nothing happens; is it > fuse_ko? the kernel? at the very end of the boot process,

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

On Tue, Oct 08, 2019 at 05:15:19AM -0700, David Wolfskill wrote: > This was on my laptop (build machine, which was updated in parallel, > but uses a different NIC, had no issues) after a src update from > r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in > this c

panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

This was on my laptop (build machine, which was updated in parallel, but uses a different NIC, had no issues) after a src update from r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in this case). The ddb "dump" command recorded a dump, which I managed to capture; the information

Re: panic: sched_pickcpu: Failed to find a cpu.

On Wed, Sep 25, 2019 at 11:44:51PM +0900, Yasuhiro KIMURA wrote: > yasu@rolling-vm-freebsd1[2001]% uname -a > ~ > FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD > 13.0-CURRENT r352351 GENERIC

Re: "panic: sched_pickcpu: Failed to find a cpu" after r352636 -> r352671

On Wed, Sep 25, 2019 at 08:02:12AM -0400, Alexander Motin wrote: > Thanks for the notice, it was a wrong assertion. Fixed. I'm sorry. > After applying r352677 (via "svn patch --strip 1"), the machine boots successfully: FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT

"panic: sched_pickcpu: Failed to find a cpu" after r352636 -> r352671

... SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x0003 VER: 0x01060015 LDR: 0x0008 DFR: 0x x2APIC: 1 lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x11ff timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #6

Re: r351247: buildkernel failure: error: use of undeclared identifier 'miibus_statchg_XXXX

On Tue, Aug 20, 2019 at 08:47:04AM +0200, O. Hartmann wrote: > Recent CURRENT (r351247) fails to buildkernel due to a compilation error, > pointing to an mii issue. > > For almost every mii-related if_ the compiler drops an error like: > ... > Seems the subfolder for USB NICs is missing

"df /" output missing "Filesystem" after r351187 -> r351211

"df" (without the mountpoint specification) is normal, but specifying the mountpoint appears to cause a large number of "space" characters to be emitted after "Filesystem" in the heading, and the actual "filesystem" data to be elided. E.g.: freebeast(13.0-C)[1] uname -aUK FreeBSD

Re: r350583 - init died (signal 6, exit 0)

On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote: > Hi, > > Has anyone else noticed the kernel being unable to spawn init lately? > > All I get is: > > init died (signal 6, exit 0) > panic: Going nowhere without my init! > > /sbin/init hasn't had any changes in 4 months, and is

Re: No keyboard or mouse for X11 after r349596 -> r349645 update

On Wed, Jul 03, 2019 at 05:07:39AM -0700, David Wolfskill wrote: > OK; that was ... weird. I sent the above message (from a tmux session on a different machine), and the laptop dropped to the db> prompt; the backtrace appears to have involved deadlkres(), but when I tried typing &quo

No keyboard or mouse for X11 after r349596 -> r349645 update

I saw no issues on my (headless) build machine with the update, but on my laptop (where I run xdm), the mouse was unresponsive, and I see these messages (in /var/log/messages): <28>1 2019-07-03T11:34:32.927353+00:00 g1-49.catwhisker.org console-kit-daemon 1142 - - WARNING: Error waiting for

Re: Post-installworld mergemaster breakage r348504 -> r348529?

On Mon, Jun 03, 2019 at 08:15:18AM -0600, Warner Losh wrote: > I just committed this as a stop-gap fix. > > Warner > Cool. I encountered the issue on my build box -- laptop was still busy with other stuff. Later, when the laptop was ready for the same update to head, I applied the change

Re: Post-installworld mergemaster breakage r348504 -> r348529?

On Mon, Jun 03, 2019 at 01:17:44PM +0200, Andreas Nilsson wrote: > ... > > Any hints? > > Might this be the same I noticed with "make packages", ie: > diff --git a/Makefile.inc1 b/Makefile.inc1 > index 6c77c8abdb8..60ac6493c95 100644 > --- a/Makefile.inc1 > +++ b/Makefile.inc1 > @@ -888,7

Post-installworld mergemaster breakage r348504 -> r348529?

I see: ... -- >>> Installing everything completed on Mon Jun 3 03:48:55 PDT 2019 -- Mon Jun 3 03:48:55 PDT 2019 *** Creating the temporary root environment in

Re: Just a heads up : /usr/bin/time missing after install

On Sat, May 25, 2019 at 10:13:45AM -0400, Dennis Clarke wrote: > > Installed with FreeBSD-13.0-CURRENT-amd64-20190517-r347896-memstick.img > and /usr/bin/time was seen to be missing. > ... I see it on my systems after source-based updates to r348231 and r348268 (on amd64). E.g.:

Panic after update from r347896 to r347950: panic: insanity vmem 0xffffffff81d7c840

This was fairly late in the transition from single- to multi-user mode: the NICs had been probed; em0 was determined (correctly) to have no link, but the wireless NIC (wlan0) hadn't associated to the AP yet. I have placed copies of the dump and a couple of screenshots in

Re: mergemaster still having issues

On Fri, May 17, 2019 at 10:55:18AM -0700, Pete Wright wrote: > ... > > E.g.: > > pushd usr.bin/mergemaster && make install; popd > > > > Then re-start the userland installation (e.g., "mergemaster -p ...") and > > proceed with the rest of the install as usual. > > Ah OK, i think missed that

Re: mergemaster still having issues

On Fri, May 17, 2019 at 10:46:57AM -0700, Pete Wright wrote: > hello - i am still having issues with mergemaster when > building/installing current on my end as per this thread: > https://lists.freebsd.org/pipermail/freebsd-current/2019-May/073403.html > > my source contains the fix that I think

r347638 breaks mergemaster

Today's daily update of head is from r347606 to r347682. src/UPDATING (still) cites: ... To rebuild everything and install it on the current system. --- # Note: sometimes if you are running current you gotta do more

Re: r344798: c++: error: linker command failed with exit code

On Tue, Mar 05, 2019 at 05:45:11PM +0100, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > recent buildworld on a CURRENT box (FreeBSD 13.0-CURRENT #246 r344742: Sun > Mar 3 21:26:44 CET > 2019 amd64) fails to build due to: > > [...] > > Building

Re: kernel build dies with "unknown option"

On Wed, Feb 13, 2019 at 06:29:33PM -0500, Robert Huff wrote: > > On a system running: > > FreeBSD 13.0-CURRENT r343080 16 Jan 2019 amd64 > > I updated the source tree as of midnight US Eastern time, then > ran buildworld. That completed successfully. > Then: > >

Re: "Oddness" in head since around r343678 or so

On Thu, Feb 07, 2019 at 05:09:40AM -0800, David Wolfskill wrote: > ... > The laptop is configured to run xdm; while running stable/11 or > stable/12, there's a period of about 5 seconds after xdm's login banner > shows up before either the mouse or keyboard responds. > > Up

"Oddness" in head since around r343678 or so

I run and track stable/11, stable/12, and head (from separate slices -- no VMs involved) on my laptop; among other things, this permits some degree of comparison among them. The laptop is configured to run xdm; while running stable/11 or stable/12, there's a period of about 5 seconds after xdm's

Re: UEFI, loader.efi and /boot.config

On Thu, Jan 17, 2019 at 07:31:38PM -0700, Rebecca Cran wrote: > > With a recent change I made for UEFI, we now install loader.efi onto the ESP > and don’t run boot1. That means that /boot.config is no longer read, and so > console settings need to be put in /boot/loader.conf.  > I was wondering

Re: r343111 breaks build

On Thu, Jan 17, 2019 at 03:53:03PM +0100, Trond Endrestøl wrote: > On Thu, 17 Jan 2019 04:49-0800, David Wolfskill wrote: > > > On Thu, Jan 17, 2019 at 03:37:16PM +0300, Lev Serebryakov wrote: > ... > > > I can not build CURRENT r343111 on r343022 world. Looks like r3

Re: r343111 breaks build

On Thu, Jan 17, 2019 at 03:37:16PM +0300, Lev Serebryakov wrote: > > I can not build CURRENT r343111 on r343022 world. Looks like r343111 > itself cause problems (r343110 builds): > > In file included from /data/src/contrib/libc++/src/algorithm.cpp:11: > In file included from

Whine: "Could not open /dev/crypto: No such file or directory"

After update from r341844 to r342042, I see the above-cited "whine" when I attempt to use an SSH client on the upgraded machine. SSH client function seems OK, so the message is (apparently) merely annoying: freebeast(13.0-C)[2] uname -a FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD

Re: Suppose a user on a pilgrimage to /usr/src, modified UPDATING

On Mon, Dec 10, 2018 at 09:49:13AM +, miltonott wrote: > O great and powerful FreeBSD biome. May I redirect from here to a paste > site > service, a rearrangement of development directory head file /usr/src/UPDATING. > > UPDATING.ORIG -> http://dpaste.com/1WRWG26.txt > - > UPDATING

Panic during network initialization after r339583 -> r339639

Gory details in . I snapped some screenshots, but can't associate using laptop's iwn(4) (in stable/11, stable/12, or head/13) at the place I'm currently staying. (I may be able to at least get the screenshots uploaded to the Web server

Re: A new stable/12 poudriere jail is inferior to its stable/12 host

On Sun, Oct 21, 2018 at 02:14:16PM +0100, Graham Perrin wrote: > On 21/10/2018 13:31, David Wolfskill wrote: > > On Sun, Oct 21, 2018 at 09:41:46AM +0100, Graham Perrin wrote: > >> With the host already at r339438, > >> creation of a jail (method: svn (othe

Re: A new stable/12 poudriere jail is inferior to its stable/12 host

On Sun, Oct 21, 2018 at 09:41:46AM +0100, Graham Perrin wrote: > With the host already at r339438, > creation of a jail (method: svn (other methods failed)) resulted in > inferior version r339435. > > Is this normal? > > Re: >

Re: careless commits disrupt

On Thu, Oct 11, 2018 at 05:54:08PM +0200, Julian H. Stacey wrote: > > 3_sxnet.pico v3_tlsf.pico v3_utl.pico v3err.pico | tsort -q` -lpthread > /usr/bin/ld: error: unable to find library -lpthread > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code

Re: Sound issues with Dell Latitude 7490 (kabylake)

On Wed, Oct 03, 2018 at 03:28:45PM +0200, Jakob Alvermark wrote: > ... > This is probably not a proper fix, but it helps to understand the problem. > > Could you post the output of 'sysctl dev.hdaa' with and without the > patch so we can see what's different? > . I have run: uname

Re: Sound issues with Dell Latitude 7490 (kabylake)

On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote: > > Do the headphones work with this patch? > > Index: sys/dev/sound/pci/hda/hdaa.c > === > --- sys/dev/sound/pci/hda/hdaa.c    (revision 339076) > +++

Re: x11/nvidia-driver no longer works under -current (r338323)

On Sun, Aug 26, 2018 at 09:12:05PM +1000, Kubilay Kocak wrote: > ... > > It fails here: > > Hi John, > > It fails earlier, can you find and paste the 'error: ' line(s) ? > I expect the observed failure is related to the message Alan Cox sent yesterday: | Subject: Re: nvidia-driver build

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

<    1   2   3   4   5   6   7   8   9   >