Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

2021-12-21 Thread Michael Butler via freebsd-current 

Confirmed. The kernel at ..

FreeBSD 14.0-CURRENT #0 f06f1d1fdb9: Mon Dec 20 12:24:51 EST 2021

 .. boots successfully.

The kernel at ..

FreeBSD 14.0-CURRENT #1 553af8f1ec7: Tue Dec 21 15:16:10 EST 2021

 .. fails immediately after printing something like ..

Timecounters tick every 1.000 msec
Timecounter "TSC" frequency 701570048 Hz quality 800

 .. but before initializing ipfw as it used to,

Michael

On 12/21/21 12:01, Michael Butler via freebsd-current wrote:

I have an old pentium-3 that also won't boot kernels built after Dec 6th.

I suspect the commits listed below but, with the device being remote and 
having no DRAC, I'm struggling to test this theory.


The relevant commits ..

commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:19 2021 -0500

     x86: Perform late TSC calibration before LAPIC timer calibration

commit 62d09b46ad7508ae74d462e49234f0a80f91ff69
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:10 2021 -0500

     x86: Defer LAPIC calibration until after timecounters are available

It's currently running git rev e43d081f352 and I have a kernel at git 
rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening,


 Michael


On 12/17/21 15:07, Larry Rosenman wrote:

On 12/17/2021 1:36 pm, Mark Johnston wrote:

On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help


I can't tell what this is saying.  A kernel built on the 7th does not
crash, or...?  Which revision did you update from before you started
seeing crashes?

From a kgdb session it'd be useful to see output from

(kgdb) frame 8
(kgdb) p/x *tmp

to start.



Correct, the 7th didn't panic, but the 9th did, and yesterday's too.

Grrr
ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
 <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
Failed to open vmcore: /var/crash/vmcore.0: Permission denied
(kgdb) bt
No stack.
quitb)

ler in borg in /mnt🔒 on ☁️  (us-east-1) took 6s
❯ sudo chmod +r /var/crash/*

ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
 <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr 
!= NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr 
!= NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(kgdb) bt
No thread selected.
(kgdb) fr 8
No thread selected.
(kgdb)


On 12/10/2021 10:36 am, Alexander Motin wrote:
&

Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

2021-12-21 Thread Michael Butler via freebsd-current 

I have an old pentium-3 that also won't boot kernels built after Dec 6th.

I suspect the commits listed below but, with the device being remote and 
having no DRAC, I'm struggling to test this theory.


The relevant commits ..

commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:19 2021 -0500

x86: Perform late TSC calibration before LAPIC timer calibration

commit 62d09b46ad7508ae74d462e49234f0a80f91ff69
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:10 2021 -0500

x86: Defer LAPIC calibration until after timecounters are available

It's currently running git rev e43d081f352 and I have a kernel at git 
rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening,


Michael


On 12/17/21 15:07, Larry Rosenman wrote:

On 12/17/2021 1:36 pm, Mark Johnston wrote:

On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help


I can't tell what this is saying.  A kernel built on the 7th does not
crash, or...?  Which revision did you update from before you started
seeing crashes?

From a kgdb session it'd be useful to see output from

(kgdb) frame 8
(kgdb) p/x *tmp

to start.



Correct, the 7th didn't panic, but the 9th did, and yesterday's too.

Grrr
ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
Failed to open vmcore: /var/crash/vmcore.0: Permission denied
(kgdb) bt
No stack.
quitb)

ler in borg in /mnt🔒 on ☁️  (us-east-1) took 6s
❯ sudo chmod +r /var/crash/*

ler in borg in /mnt🔒 on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr != 
NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
.

/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr != 
NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(kgdb) bt
No thread selected.
(kgdb) fr 8
No thread selected.
(kgdb)


On 12/10/2021 10:36 am, Alexander Motin wrote:
> Hi Larry,
>
> This looks like some use-after-free or otherwise corrupted callout
> structure.  Unfortunately the backtrace does not tell what was the
> callout.  When was the previous update to look what could change?
>
> On 10.12.2021 11:24, Larry Rosenman wrote:
>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
>> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021
>> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>> amd64
>>
>> VMCORE *IS* available.
>>
>>
>>
>>
>> Unread portion of the kernel message buffer:
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 20
>> fault virtual address   = 0x0
>> fault code 

Re: cross-compiling for i386 on amd64 fails

2021-11-16 Thread Michael Butler via freebsd-current 

I should have been more specific ..

I'm observing that "/usr/src/release/release.sh -c release-i386.conf" 
fails when targeting a i386 build on an amd64 host :-(



On 11/16/21 02:33, Warner Losh wrote:

A meta-build worked for me just now...

Warner

On Mon, Nov 15, 2021 at 9:35 PM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:


Haven't had time to identify which change caused this yet but I now get ..

===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is
incompatible with elf_i386_fbsd
===> cddl/lib/libspl (obj,all,install)
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
--- libavl.so.2 ---
*** [libavl.so.2] Error code 1

make[4]: stopped in /usr/src/cddl/lib/libavl

 imb

cross-compiling for i386 on amd64 fails

2021-11-15 Thread Michael Butler via freebsd-current 

Haven't had time to identify which change caused this yet but I now get ..

===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is 
incompatible with elf_i386_fbsd

===> cddl/lib/libspl (obj,all,install)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- libavl.so.2 ---
*** [libavl.so.2] Error code 1

make[4]: stopped in /usr/src/cddl/lib/libavl

imb

current now panics when starting VBox VM

2021-11-02 Thread Michael Butler via freebsd-current 

On current as of this morning (I haven't tried to bisect yet) ..

FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
14.0-CURRENT #42 main-a670e1c13a: Tue Nov  2 09:29:28 EDT 2021 
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI 
 amd64


 .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, 
trying to start a VirtualBox VM triggers this panic ..


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ca5564
stack pointer   = 0x28:0xfe011c036b80
frame pointer   = 0x28:0xfe011c036b80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1378 (plasmashell)
trap number = 12
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e403b2 at drm_atomic_helper_check_modeset+0xb2
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at panic+0x43
#14 0x80ca928c at trap_fatal+0x2dc
#15 0x80ca962f at trap_pfault+0x32f
#16 0x80ca8a3c at trap+0x23c
#17 0x80c81fc8 at calltrap+0x8
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e403b2 at drm_atomic_helper_check_modeset+0xb2
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at panic+0x43
#14 0x80ca928c at trap_fatal+0x2dc
#15 0x80ca962f at trap_pfault+0x32f
#16 0x80ca8a3c at trap+0x23c
#17 0x80c81fc8 at calltrap+0x8
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e403b2 at drm_atomic_helper_check_modeset+0xb2
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at panic+0x43
#14 0x80ca928c at trap_fatal+0x2dc
#15 0x80ca962f at trap_pfault+0x32f
#16 0x80ca8a3c at trap+0x23c
#17 0x80c81fc8 at calltrap+0x8
WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) 
failed at 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666

#0 0x81ec2c63 at linux_dump_stack+0x23
#1 0x81e40542 at drm_atomic_helper_check_modeset+0x242
#2 0x81d3870c at intel_atomic_check+0x8c
#3 0x81e3f383 at drm_atomic_check_only+0x423
#4 0x81e3f783 at drm_atomic_commit+0x13
#5 0x81e4c2e8 at drm_client_modeset_commit_atomic+0x148
#6 0x81e4c046 at drm_client_modeset_commit_force+0x66
#7 0x81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a
#8 0x81e85ef6 at vt_kms_postswitch+0x166
#9 0x807a59f0 at vt_window_switch+0x120
#10 0x807a2b4f at vtterm_cngrab+0x4f
#11 0x80865716 at cngrab+0x16
#12 0x808cbe1c at vpanic+0xec
#13 0x808cbd23 at pani

Re: what does "failed to read progbits" mean?

2021-10-25 Thread Michael Butler via freebsd-current 
This seems to have gone away after 
https://freshbsd.org/freebsd/src/commit/70f51f0e474ffe1fb74cb427423a2fba3637544d


Not sure if the bug that commit fixes was the underlying cause,

Michael


On 10/25/21 11:40, Nuno Teixeira wrote:

Same here:
kldxref /boot/kernel
failed to read progbits

But kernel failed to install. I will include log tomorrow, I'm doing a 
clean build with /usr/obj/.. deleted.


Michael Butler via freebsd-current <mailto:freebsd-current@freebsd.org>> escreveu no dia quinta, 21/10/2021 
à(s) 20:14:


Well this is different .. I did a full rebuild (after "rm -rf
/usr/obj/*") this morning and now see ..

===> linux_common (install)
install -T release -o root -g wheel -m 555   linux_common.ko
/boot/kernel/
install -T dbg -o root -g wheel -m 555   linux_common.ko.debug
/usr/lib/debug/boot/kernel/
===> linuxkpi (install)
install -T release -o root -g wheel -m 555   linuxkpi.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   linuxkpi.ko.debug
/usr/lib/debug/boot/kernel/
kldxref /boot/kernel
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
kldxref: /boot/kernel/kernel: cannot load DT_RELA section
--
  >>> Installing kernel TOSHI completed on Thu Oct 21 15:05:00 EDT 2021
--

Is something broken or just cosmetic noise?

         imb

what does "failed to read progbits" mean?

2021-10-21 Thread Michael Butler via freebsd-current 
Well this is different .. I did a full rebuild (after "rm -rf 
/usr/obj/*") this morning and now see ..


===> linux_common (install)
install -T release -o root -g wheel -m 555   linux_common.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   linux_common.ko.debug 
/usr/lib/debug/boot/kernel/

===> linuxkpi (install)
install -T release -o root -g wheel -m 555   linuxkpi.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   linuxkpi.ko.debug 
/usr/lib/debug/boot/kernel/

kldxref /boot/kernel
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
kldxref: /boot/kernel/kernel: cannot load DT_RELA section
--
>>> Installing kernel TOSHI completed on Thu Oct 21 15:05:00 EDT 2021
--

Is something broken or just cosmetic noise?

imb

Re: drm-devel-kmod build failures

2021-10-11 Thread Michael Butler via freebsd-current 

Thanks - that works :-)

On 10/11/21 13:31, Mateusz Guzik wrote:

This should do it (untested):

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 37b268afa..f05de73fa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -117,9 +117,15 @@ dma_buf_close(struct file *fp, struct thread *td)
 return (0);
  }

+#if __FreeBSD_version >= 1400037
+static int
+dma_buf_stat(struct file *fp, struct stat *sb,
+struct ucred *active_cred __unused)
+#else
  static int
  dma_buf_stat(struct file *fp, struct stat *sb,
  struct ucred *active_cred __unused, struct thread *td __unused)
+#endif
  {

 /* XXX need to define flags for st_mode */


On 10/11/21, Michael Butler via freebsd-current
 wrote:

After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..

--- dma-buf.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1:

error: conflicting types for 'dma_buf_stat'
dma_buf_stat(struct file *fp, struct stat *sb,
^
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18:

note: previous declaration is here
static fo_stat_t dma_buf_stat;
   ^
1 error generated.
*** [dma-buf.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi
1 error

make[3]: stopped in
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi

I get a similar error with drm-current-kmod. What changed?

imb

drm-devel-kmod build failures

2021-10-11 Thread Michael Butler via freebsd-current 
After the latest freebsd version bump in param.h, I tried to rebuild the 
DRM modules. It failed with ..


--- dma-buf.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1: 
error: conflicting types for 'dma_buf_stat'

dma_buf_stat(struct file *fp, struct stat *sb,
^
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18: 
note: previous declaration is here

static fo_stat_t dma_buf_stat;
 ^
1 error generated.
*** [dma-buf.o] Error code 1

make[3]: stopped in 
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi

1 error

make[3]: stopped in 
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi


I get a similar error with drm-current-kmod. What changed?

imb

Re: intermittent bsdtar/jemalloc failures

2021-10-08 Thread Michael Butler via freebsd-current 

On 10/7/21 20:19, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:

On 10/7/21 16:52, Mark Johnston wrote:

On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current 
wrote:

On 10/7/21 15:39, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current 
wrote:

While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build unless I happen to notice and it yields an incomplete package.

a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion:
"nstime_compare(&decay->epoch, &time) <= 0"
Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS
file-systems all around. I tried stopping NTPD temporarily but the failures
persist .. sometimes :-(

I've seen this at different points in the archiving process so it doesn't
seem specific to building kernel.txz.


What timecounter do you use? Perhaps show the whole output from
sysctl kern.timecounter.


imb@vm01:/home/imb> sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
dummy(-100)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 16124892
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1883995229
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 57
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1413153007
kern.timecounter.tc.TSC-low.counter: 2352002295
kern.timecounter.tc.TSC-low.mask: 4294967295

I overrode the default selection of counter-type as NTPD drifted so
badly as to require stepping almost hourly :-(


If you return to TSC, does the problem go away?
Same question if you leave HPET on, but set fast_gettime to 0.


While I've only done one build (still) with HPET with 
kern.timecounter.fast_gettime=0, I didn't see a core-dump.

I'll test more over the weekend,

imb

Re: intermittent bsdtar/jemalloc failures

2021-10-07 Thread Michael Butler via freebsd-current 

On 10/7/21 16:52, Mark Johnston wrote:

On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current 
wrote:

On 10/7/21 15:39, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current 
wrote:

While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build unless I happen to notice and it yields an incomplete package.

a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion:
"nstime_compare(&decay->epoch, &time) <= 0"
Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS
file-systems all around. I tried stopping NTPD temporarily but the failures
persist .. sometimes :-(

I've seen this at different points in the archiving process so it doesn't
seem specific to building kernel.txz.


What timecounter do you use? Perhaps show the whole output from
sysctl kern.timecounter.


imb@vm01:/home/imb> sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
dummy(-100)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 16124892
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1883995229
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 57
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1413153007
kern.timecounter.tc.TSC-low.counter: 2352002295
kern.timecounter.tc.TSC-low.mask: 4294967295

I overrode the default selection of counter-type as NTPD drifted so
badly as to require stepping almost hourly :-(


Could you show output from

# kldload cpuctl
# cpucontrol -i 0x15 /dev/cpuctl0
# cpucontrol -i 0x16 /dev/cpuctl0

as well as a copy of the dmesg after a boot?  I am looking at a similar
problem currently.


root@vm01:/usr/home/imb # cpucontrol -i 0x15 /dev/cpuctl0
cpuid level 0x15: 0x07280202 0x 0x 0x0503
root@vm01:/usr/home/imb # cpucontrol -i 0x16 /dev/cpuctl0
cpuid level 0x16: 0x07280202 0x 0x 0x0503

This is a Dell-1950 1-U box with a SAS drive-box attached ..

root@vm01:/usr/home/imb # less /var/log/dmesg.today
---<>---
VERBOSE_SYSINIT: DDB not enabled, symbol lookups disabled.
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.0-CURRENT #256 main-42dfad2ef1: Sat Oct  2 09:41:36 EDT 2021

r...@vm01.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/VM01 
amd64
FreeBSD clang version 12.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-12.0.1-0-gfed41342a82f)

VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz (2826.31-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6

Features=0xbfebfbff

Features2=0xce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65811677184 (62762 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
random: unblocking device.
Security policy loaded: MAC/ntpd (mac_ntpd)
ioapic0: MADT APIC ID 8 != hw id 0
ioapic0  irqs 0-23
Launching APs: 3 4 1 6 2 5 7
Timecounter "TSC-low" frequency 1413155409 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0
vtvga0: 
smbios0:  at iomem 0xfcdf0-0xfce0e
smbios0: Version: 2.5, BCD Revision: 2.5
acpi0: 
acpi0: Power Button (fixed)
Firmware Error (ACPI): Could not resolve symbol [\134_SB._OSC.CDW1], 
AE_NOT_FOUND (20210930/psargs-503)
ACPI Error: Aborting method \134_SB._OSC due to previous error 
(AE_NOT_FOUND) (20210930/psparse-689)

apei0:  on acpi0
ipmi0:  port 0xca8,0xcac on acpi0
ipmi0: KCS mode found at io 0xca8 on acpi
cpu0:  on acpi0
atrtc0:  port 0x70-0x7f irq 8 on acpi0
atrtc0: registered as a time-

Re: intermittent bsdtar/jemalloc failures

2021-10-07 Thread Michael Butler via freebsd-current 

On 10/7/21 15:39, Konstantin Belousov wrote:

On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current 
wrote:

While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build unless I happen to notice and it yields an incomplete package.

a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion:
"nstime_compare(&decay->epoch, &time) <= 0"
Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS
file-systems all around. I tried stopping NTPD temporarily but the failures
persist .. sometimes :-(

I've seen this at different points in the archiving process so it doesn't
seem specific to building kernel.txz.


What timecounter do you use? Perhaps show the whole output from
sysctl kern.timecounter.


imb@vm01:/home/imb> sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) 
dummy(-100)

kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 16124892
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1883995229
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 57
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1413153007
kern.timecounter.tc.TSC-low.counter: 2352002295
kern.timecounter.tc.TSC-low.mask: 4294967295

I overrode the default selection of counter-type as NTPD drifted so 
badly as to require stepping almost hourly :-(


So .. I have this in /etc/sysctl.conf ..

kern.timecounter.hardware=HPET

While I hope it wouldn't make a difference, I also have powerd enabled 
in /etc/rc.conf to (marginally) reduce the power-consumption when the 
machine is near-idle. sysctl -a | grep ^dev.cpu | grep freq shows ..


dev.cpu.7.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.7.freq: 2834
dev.cpu.3.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.3.freq: 2834
dev.cpu.5.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.5.freq: 2834
dev.cpu.1.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.1.freq: 2834
dev.cpu.6.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.6.freq: 2834
dev.cpu.2.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.2.freq: 2834
dev.cpu.4.freq_levels: 2834/103000 2333/9 2000/79000
dev.cpu.4.freq: 2834
dev.cpu.0.freq_levels: 2834/103000 2333/94000 2000/86000
dev.cpu.0.freq: 2834

imb


OpenPGP_signature
Description: OpenPGP digital signature

intermittent bsdtar/jemalloc failures

2021-10-07 Thread Michael Butler via freebsd-current 
While building a local release bundle, I sometimes get bsdtar failing 
(and dumping core) as follows below. Worse, as can be seen below, it 
doesn't stop the build unless I happen to notice and it yields an 
incomplete package.


a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_message.h
a usr/src/sys/netgraph/ng_echo.c
a usr/src/sys/netgraph/ng_gif.h
: jemalloc_arena.c:747: Failed assertion: 
"nstime_compare(&decay->epoch, &time) <= 0"

Abort trap (core dumped)
sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST

What causes this? Build machine is a 2x4-core Intel box with ZFS 
file-systems all around. I tried stopping NTPD temporarily but the 
failures persist .. sometimes :-(


I've seen this at different points in the archiving process so it 
doesn't seem specific to building kernel.txz.


Any thoughts?

imb


OpenPGP_signature
Description: OpenPGP digital signature

git commit for WITH_DETECT_TZ_CHANGES breaks date, et al

2021-09-13 Thread Michael Butler via freebsd-current 
After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to 
recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set.


For example ..

imb@vm01:/home/imb> date
Tue Sep 14 01:25:57  2021

Every other daemon also thinks it's running in UTC+0 :-(

When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in 
/etc/src.conf, the output is (for me) ..


imb@vm01:/usr/src/lib/libc> date
Mon Sep 13 21:28:29 EDT 2021

imb

Re: awk behaviour?

2021-07-29 Thread Michael Butler via freebsd-current 

On 7/29/21 6:09 AM, Michael Gmelin wrote:



On Wed, 28 Jul 2021 16:02:30 -0400
Ed Maste  wrote:


On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
 wrote:


What prompted the question was my (obviously poor) attempt to debug
and resolve this failure when attempting to build a release for
i386 on an amd64 ..


This will be due to my 4e224e4be7c3. I'm not sure exactly what's
happening yet, but I can provoke this behaviour if `${PKG_CMD}
--version` outputs something other than a single line with the version
number.



Could it be, that the pkg binary isn't installed in $LOCALBASE/sbin/pkg,
(whatever LOCALBASE is at that point)? This would make pkg --version
shows its bootstrap message:

   The package management tool is not yet installed on your system.
   Do you want to fetch and install it now? [y/N]:

which could explain the behavior.

Just speculating...


This is consistent with the behaviour I'm now seeing after the most 
recent patch.


In the chroot environment used by a cross-compilation, there is no 
installed pkg port. When pkg is invoked in the target environment, it 
now waits on the yes/no response,


imb

Re: awk behaviour?

2021-07-28 Thread Michael Butler via freebsd-current 

On 7/28/21 1:36 PM, Warner Losh wrote:

On Wed, Jul 28, 2021 at 11:31 AM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:


I tripped over this while trying to build a local release ..

imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001

imb@toshi:/home/imb> pkg --version
1.17.1

Is this expected?



Why $$ instead of $? $ isn't expanded in '' expressions, so doubling isn't
necessary
unlike in make... With single quotes it works for me:

% pkg --version | awk -F. '{print $1 * 1 + $2 * 100 + $3}'
11603
% pkg --version
1.16.3

In awk $$n is $($n), so $$ in this context would evaluate $1 to 1 and then
$1 to be 1. And then $2 to be 16
and then $17 to be 0 and then $3 to be 1 and then $1 to be 1 which leads to
10001.


What prompted the question was my (obviously poor) attempt to debug and 
resolve this failure when attempting to build a release for i386 on an 
amd64 ..


make -C /usr/src/release  obj
make -C /usr/src/release  ftp cdrom memstick.img mini-memstick.img
mkdir -p dist
cd /usr/src/release/.. && make TARGET_ARCH=i386 TARGET=i386 
distributeworld DISTDIR=/usr/obj/usr/src/i386.i386/release/dist
make[3]: "/usr/obj/usr/src/i386.i386/toolchain-metadata.mk" line 1: 
Using cached toolchain metadata from build at 
vm01.auburn.protected-networks.net on Wed Jul 28 18:01:01 UTC 2021


make[3]: "/usr/src/Makefile.inc1" line 1864: String comparison operator 
must be either == or !=
make[3]: "/usr/src/Makefile.inc1" line 2073: String comparison operator 
must be either == or !=

make[3]: Fatal errors encountered -- cannot continue
make[3]: stopped in /usr/src
*** Error code 1

Stop.

imb

Re: awk behaviour?

2021-07-28 Thread Michael Butler via freebsd-current 

NVM .. it's the escaping of '$' .. 

On 7/28/21 1:29 PM, Michael Butler via freebsd-current wrote:

I tripped over this while trying to build a local release ..

imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 * 
100 + $$3}'

10001

imb@toshi:/home/imb> pkg --version
1.17.1

Is this expected?

 imb

awk behaviour?

2021-07-28 Thread Michael Butler via freebsd-current 

I tripped over this while trying to build a local release ..

imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 * 
100 + $$3}'

10001

imb@toshi:/home/imb> pkg --version
1.17.1

Is this expected?

imb

Re: Build of some ports hang up on recent 14-CURRENT amd64

2021-04-09 Thread Michael Butler via freebsd-current 
This is likely fixed as of ~30 mins ago on commit 
e8b9c508b7ae5be618ada089103468c400e465cd


The cause appears to have been commit d36d6816151705907393889

imb

On 4/9/21 4:55 PM, Yasuhiro Kimura wrote:

yasu@rolling-vm-freebsd1[1044]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT 
#0 main-n245912-f2400e6e832: Sat Apr 10 01:42:33 JST 2021 
ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  amd64

After the update from 36d6e65722e to f2400e6e832 I noticed build of
some ports hang up in the middle of it on my 14-CURRENT amd64 host.

One of such examples is security/py-cryptography.

--
root@rolling-vm-freebsd1[1008]# make
===>  License APACHE20 BSD3CLAUSE accepted by the user
===>   py39-cryptography-3.3.2 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py39-cryptography-3.3.2 for building
===>  Extracting for py39-cryptography-3.3.2
=> SHA256 Checksum OK for cryptography-3.3.2.tar.gz.
===>  Patching for py39-cryptography-3.3.2
===>   py39-cryptography-3.3.2 depends on package: py39-cffi>=1.8 - found
===>   py39-cryptography-3.3.2 depends on package: py39-setuptools>0 - found
===>   py39-cryptography-3.3.2 depends on file: /usr/local/bin/python3.9 - found
===>  Configuring for py39-cryptography-3.3.2
running config
--

And another one is devel/arcanist-lib.

--
root@rolling-vm-freebsd1[1023]# make
===>  License APACHE20 accepted by the user
===>   arcanist-lib-php74-20210113 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by arcanist-lib-php74-20210113 for building
===>  Extracting for arcanist-lib-php74-20210113
=> SHA256 Checksum OK for phacility-arcanist-20210113-b2e715f_GH0.tar.gz.
===>  Patching for arcanist-lib-php74-20210113
===>  Applying FreeBSD patches for arcanist-lib-php74-20210113 from 
/usr/ports/devel/arcanist-lib/files
===>  Configuring for arcanist-lib-php74-20210113
===>  Staging for arcanist-lib-php74-20210113
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/include/php/main/php.h - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/curl.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/dom.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/json.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/simplexml.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/zlib.so - found
===>   arcanist-lib-php74-20210113 depends on file: 
/usr/local/lib/php/20190902/mbstring.so - found
===>   Generating temporary packing list
cd /usr/ports/devel/arcanist-lib/work-php74/arcanist-b2e715f ; /bin/pax -rw * 
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist
install -l rs 
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist/support/shell/hooks/bash-completion.sh
  
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/share/bash-completion/completions/arc
/usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist/bin/arc
 shell-complete --generate
  GENERATE  Generating shell completion rules...
  RULES  Wrote updated completion rules for "bash" to: 
work-php74/stage/usr/local/lib/php/arcanist/support/shell/rules/bash-rules.sh.
  NOTE  You may need to open a new terminal window or launch a new shell before 
the changes take effect.
--

The problem also happens with poudriere.

I tried boot with old 36d6e65722e kernel but the problem still
happens. So the cause may be older than it.

Does anyone else have the same problem?

Best Regards.

---
Yasuhiro Kimura
___
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"



___
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: On 14-CURRENT: no ports options anymore?

2021-03-13 Thread Michael Butler via freebsd-current 

On 3/13/21 3:00 PM, Hartmann, O. wrote:

On Sat, 13 Mar 2021 19:52:47 + (UTC)
Filippo Moretti via freebsd-current  wrote:

  
I had the same problem in console modeFiippo

 On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser 
 wrote:

  Am 13.03.21 um 20:17 schrieb Hartmann, O.:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


Hi Oliver,

please check your TERM setting and test with a trivial setting
if it is not one of xterm, vt100 or vt320 (for example).

I had this problem when my TERM variable was xterm-color, which
used to be supported but apparently no longer is.

Regards, STefan


[...]

on one of the hosts (non-X11), loged in via ssh, the settings are:

# echo $TERM
xterm
cd /usr/ports/www/apache24
make config
===> Options unchanged (no menu popping up)



I ran into something similar where dialog4ports would dump core after an 
upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,


imb


___
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"

kern_jail.c w/o INVARIANTS

2021-02-21 Thread Michael Butler via freebsd-current 

Seems there's a typo in this when INVARIANTS is not turned on ..

diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index 48c91a95bf..342af50462 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -2671,7 +2671,7 @@ prison_free_not_last(struct prison *pr)
("prison_free_not_last freed last ref on prison %p (jid=%d).",
 pr, pr->pr_id));
 #else
-   refcount_release(&pr>pr_ref);
+   refcount_release(&pr->pr_ref);
 #endif
 }


___
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"

make release broken?

2021-02-09 Thread Michael Butler via freebsd-current 

Any ideas what broke this?


--
>>> Kernel build for GENERIC completed on Tue Feb  9 20:48:05 UTC 2021
--
>>> Kernel(s)  GENERIC built in 465 seconds, ncpu: 8, make -j8
--
make -C /usr/src/release  obj
make -C /usr/src/release  ftp cdrom dvdrom memstick.img mini-memstick.img
`ftp' is up to date.
sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_CD 
disc1.iso disc1
makefs: cd9660_add_boot_disk: lstat("disc1/boot/cdboot"): No such file 
or directory

*** Error code 1

Stop.
make[1]: stopped in /usr/src/release
*** Error code 1

    imb




___
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"

ZFS feature compatibility?

2021-01-25 Thread Michael Butler via freebsd-current 
I have a few machines on which I've been hesitant to run 'zpool upgrade' 
as I'm not sure of the (boot?) implications. They report like this ..


imb@toshi:/home/imb> uname -a
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI 
 amd64


imb@toshi:/home/imb> zpool status
  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support

the features. See zpool-features(5) for details.

Is it safe to upgrade the root pool?

imb
___
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"