Re: usb mouse not work on boot

[Chris]

On 2024-05-18 08:33, Warner Losh wrote:

On Sat, May 18, 2024, 9:22 AM Oleksandr Kryvulia 
wrote:


18.05.24 16:06, Warner Losh:



On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia 
wrote:


18.05.24 12:59, Oleksandr Kryvulia:

18.05.24 12:55, Dag-Erling Smørgrav:

Oleksandr Kryvulia   
writes:


Gary Jennejohn   writes:

Try adding uhid_load="YES" to your /boot/loader.conf.  With that
added the module should be automatically loaded during the kernel
boot.

As workaround I already have kld_list+="uhid" in /etc/rc.conf.

I hope you don't mean that literally, because /etc/rc.conf is a shell
script and += is not valid shell syntax.  On the other hand, something
like

kld_list="${kld_list} uhid"

Yes, you are right. I mean
sysrc kld_list+="uhid"


One more correction. Via kld_list I need load ums(4), loading only
uhid(4) does not solve a problem.




You don't need to change kld_list. In fact, you should undo any changes
you've made there. Undo everything in loader.conf you've done.

This is a bug in the boot optimization stuff. Or rather, this exposes a
long standing bug in the USB code where there's an asymmetry between the
nomatch events and the bus tree it presents to devctl causing devmatch to
fail when the nomatch events aren't present on boot.

Just set hw.bus.devctl_nomatch_enabled=1 in /boot/loader.conf and reboot.
Or update to the change I'm about to make.


Thanks for the detailed explanation, Warner. Interesting that on my system
hw.bus.devctl_nomatch_enabled=1 is set by /etc/rc.d/devmatch but only
explicit set it in /boot/loader.conf did the trick. That is why I think
this sysctl don't work in my case.



Yea. That's the optimization. We don't start generating events until it is
one. Setting it in the bootloader causes all events to coke through.
Setting it in devmatch turns them on after we run devmatch the first time,
omitting all of the ones generated on boot.

Why is sysctl.conf(5) not the best location for this?



Warner




--Chris

Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?

[Chris]

On 2024-04-02 04:32, Tomoaki AOKI wrote:

On Tue, 02 Apr 2024 00:42:23 -0700
Chris  wrote:


On 2024-04-01 22:51, Kevin Oberman wrote:
> On Mon, Apr 1, 2024 at 3:05 PM Chris  wrote:
>
>> I experience challenges running FreeBSD on my Alder Lake laptop.
>> With some help on the list and Bugzilla, I was able to get Graphics
>> WiFi at least working. But still wasn't as stable as running on
>> more dated CPU's. As it is; I'm only able to use CURRENT. Beginning
>> of last week, in hopes of getting a more stable experience. I wiped
>> the partition (UFS) and unpacked the version available on the FreeBSD
>> ftp servers at that time. I quickly discovered that multi-cons (Ctrl+
>> Alt+Fn || Alt+Fn) was no longer available. I posted this discovery to
>> the list. But no solution was discovered. I've since attempted to use
>> 2 more different newer versions. Both of them were also w/o multi-con(s)
>> support. What must I do to fix, or uncover the cause of this?
>> I only load the associated GPU module in rc.conf(5) (no keyboard settings).
>> I'm also unable to get multi-cons booting from any of the boot media
>> produced within the last week.
>>
>> Following are some specifics:
>>
>> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)
>>
>> IdeaPad 3 17IAU7
>>
>> WORKS:
>> FreeBSD 15.0-CURRENT #0 main-n267640-7a4d1d1df0b2:
>> Thu Jan 18 04:04:32 UTC 2024
>>
>> DOESN'T WORK:
>> FreeBSD 15.0-CURRENT #0 main-n269036-6baddb6b1176:
>> Fri Mar 29 10:19:43 UTC 2024
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>>
>> FreeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964:
>> Thu Mar 14 02:58:39 UTC 2024
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>>
>> hostb0@pci0:0:0:0:  class=0x06 rev=0x04 hdr=0x00 vendor=0x8086
>> device=0x4609 subvendor=0x17aa subdevice=0x3803
>>  vendor = 'Intel Corporation'
>>  class  = bridge
>>  subclass   = HOST-PCI
>> vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086
>> device=0x46b3 subvendor=0x17aa subdevice=0x3b3a
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake-UP3 GT1 [UHD Graphics]'
>>  class  = display
>>  subclass   = VGA
>> none0@pci0:0:4:0:   class=0x118000 rev=0x04 hdr=0x00 vendor=0x8086
>> device=0x461d subvendor=0x17aa subdevice=0x380c
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake Innovation Platform Framework Processor
>> Participant'
>>  class  = dasp
>> pcib1@pci0:0:6:0:   class=0x060400 rev=0x04 hdr=0x01 vendor=0x8086
>> device=0x464d subvendor=0x17aa subdevice=0x380e
>>  vendor = 'Intel Corporation'
>>  device = '12th Gen Core Processor PCI Express x4 Controller'
>>  class  = bridge
>>  subclass   = PCI-PCI
>> none1@pci0:0:10:0:  class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086
>> device=0x467d subvendor=0x17aa subdevice=0x3813
>>  vendor = 'Intel Corporation'
>>  device = 'Platform Monitoring Technology'
>>  class  = dasp
>> xhci0@pci0:0:13:0:  class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086
>> device=0x461e subvendor=0x17aa subdevice=0x3824
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake-P Thunderbolt 4 USB Controller'
>>  class  = serial bus
>>  subclass   = USB
>> xhci1@pci0:0:20:0:  class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086
>> device=0x51ed subvendor=0x17aa subdevice=0x3820
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake PCH USB 3.2 xHCI Host Controller'
>>  class  = serial bus
>>  subclass   = USB
>> none2@pci0:0:20:2:  class=0x05 rev=0x01 hdr=0x00 vendor=0x8086
>> device=0x51ef subvendor=0x17aa subdevice=0x381e
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake PCH Shared SRAM'
>>  class  = memory
>>  subclass   = RAM
>> iwlwifi0@pci0:0:20:3:   class=0x028000 rev=0x01 hdr=0x00 vendor=0x8086
>> device=0x51f0 subvendor=0x8086 subdevice=0x0074
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake-P PCH CNVi WiFi'
>>  class  = network
>> ig4iic0@pci0:0:21:0:class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086
>> device=0x51e8 subvendor=0x17aa subdevice=0x3812
>>  vendor = 'Intel Corporation'
>>  device = 'Alder Lake PCH Serial IO I2C Controller'
>>  class  = serial bus
>> ig4iic1

Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?

[Chris]

On 2024-04-01 22:51, Kevin Oberman wrote:

On Mon, Apr 1, 2024 at 3:05 PM Chris  wrote:


I experience challenges running FreeBSD on my Alder Lake laptop.
With some help on the list and Bugzilla, I was able to get Graphics
WiFi at least working. But still wasn't as stable as running on
more dated CPU's. As it is; I'm only able to use CURRENT. Beginning
of last week, in hopes of getting a more stable experience. I wiped
the partition (UFS) and unpacked the version available on the FreeBSD
ftp servers at that time. I quickly discovered that multi-cons (Ctrl+
Alt+Fn || Alt+Fn) was no longer available. I posted this discovery to
the list. But no solution was discovered. I've since attempted to use
2 more different newer versions. Both of them were also w/o multi-con(s)
support. What must I do to fix, or uncover the cause of this?
I only load the associated GPU module in rc.conf(5) (no keyboard settings).
I'm also unable to get multi-cons booting from any of the boot media
produced within the last week.

Following are some specifics:

CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)

IdeaPad 3 17IAU7

WORKS:
FreeBSD 15.0-CURRENT #0 main-n267640-7a4d1d1df0b2:
Thu Jan 18 04:04:32 UTC 2024

DOESN'T WORK:
FreeBSD 15.0-CURRENT #0 main-n269036-6baddb6b1176:
Fri Mar 29 10:19:43 UTC 2024
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

FreeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964:
Thu Mar 14 02:58:39 UTC 2024
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

hostb0@pci0:0:0:0:  class=0x06 rev=0x04 hdr=0x00 vendor=0x8086
device=0x4609 subvendor=0x17aa subdevice=0x3803
 vendor = 'Intel Corporation'
 class  = bridge
 subclass   = HOST-PCI
vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086
device=0x46b3 subvendor=0x17aa subdevice=0x3b3a
 vendor = 'Intel Corporation'
 device = 'Alder Lake-UP3 GT1 [UHD Graphics]'
 class  = display
 subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 rev=0x04 hdr=0x00 vendor=0x8086
device=0x461d subvendor=0x17aa subdevice=0x380c
 vendor = 'Intel Corporation'
 device = 'Alder Lake Innovation Platform Framework Processor
Participant'
 class  = dasp
pcib1@pci0:0:6:0:   class=0x060400 rev=0x04 hdr=0x01 vendor=0x8086
device=0x464d subvendor=0x17aa subdevice=0x380e
 vendor = 'Intel Corporation'
 device = '12th Gen Core Processor PCI Express x4 Controller'
 class  = bridge
 subclass   = PCI-PCI
none1@pci0:0:10:0:  class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086
device=0x467d subvendor=0x17aa subdevice=0x3813
 vendor = 'Intel Corporation'
 device = 'Platform Monitoring Technology'
 class  = dasp
xhci0@pci0:0:13:0:  class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086
device=0x461e subvendor=0x17aa subdevice=0x3824
 vendor = 'Intel Corporation'
 device = 'Alder Lake-P Thunderbolt 4 USB Controller'
 class  = serial bus
 subclass   = USB
xhci1@pci0:0:20:0:  class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51ed subvendor=0x17aa subdevice=0x3820
 vendor = 'Intel Corporation'
 device = 'Alder Lake PCH USB 3.2 xHCI Host Controller'
 class  = serial bus
 subclass   = USB
none2@pci0:0:20:2:  class=0x05 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51ef subvendor=0x17aa subdevice=0x381e
 vendor = 'Intel Corporation'
 device = 'Alder Lake PCH Shared SRAM'
 class  = memory
 subclass   = RAM
iwlwifi0@pci0:0:20:3:   class=0x028000 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51f0 subvendor=0x8086 subdevice=0x0074
 vendor = 'Intel Corporation'
 device = 'Alder Lake-P PCH CNVi WiFi'
 class  = network
ig4iic0@pci0:0:21:0:class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51e8 subvendor=0x17aa subdevice=0x3812
 vendor = 'Intel Corporation'
 device = 'Alder Lake PCH Serial IO I2C Controller'
 class  = serial bus
ig4iic1@pci0:0:21:1:class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51e9 subvendor=0x17aa subdevice=0x3814
 vendor = 'Intel Corporation'
 device = 'Alder Lake PCH Serial IO I2C Controller'
 class  = serial bus
none3@pci0:0:22:0:  class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51e0 subvendor=0x17aa subdevice=0x3815
 vendor = 'Intel Corporation'
 device = 'Alder Lake PCH HECI Controller'
 class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51d3 subvendor=0x8086 subdevice=0x7270
 vendor = 'Intel Corporation'
 device = 'Alder Lake-P SATA AHCI Controller'
 class  = mass storage
 subclass   = SATA
pcib2@pci0:0:29:0:  class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086
device=0x51b1 subvendor=0x17aa subdevice=0x381f
 vendor = 'Intel Corporation'
 device = 'Alder Lake

Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?

[Chris]

On 2024-04-01 14:57, Michael Gmelin wrote:
You never responded to my (and T’s) message - so I assume the suggestions 
made no

difference?

Right, and thank you for the reply. I (indirectly) answered it here
when I indicated that I had no references to "keyboard settings in
my rc.conf(5)". :) Any other thoughts?
Thanks again, Michael!

--Chris


-m


On 1. Apr 2024, at 22:48, Chris  wrote:

I experience challenges running FreeBSD on my Alder Lake laptop.
With some help on the list and Bugzilla, I was able to get Graphics
WiFi at least working. But still wasn't as stable as running on
more dated CPU's. As it is; I'm only able to use CURRENT. Beginning
of last week, in hopes of getting a more stable experience. I wiped
the partition (UFS) and unpacked the version available on the FreeBSD
ftp servers at that time. I quickly discovered that multi-cons (Ctrl+
Alt+Fn || Alt+Fn) was no longer available. I posted this discovery to
the list. But no solution was discovered. I've since attempted to use
2 more different newer versions. Both of them were also w/o multi-con(s)
support. What must I do to fix, or uncover the cause of this?
I only load the associated GPU module in rc.conf(5) (no keyboard settings).
I'm also unable to get multi-cons booting from any of the boot media
produced within the last week.

Following are some specifics:

CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)

IdeaPad 3 17IAU7

WORKS:
FreeBSD 15.0-CURRENT #0 main-n267640-7a4d1d1df0b2:
Thu Jan 18 04:04:32 UTC 2024

DOESN'T WORK:
FreeBSD 15.0-CURRENT #0 main-n269036-6baddb6b1176:
Fri Mar 29 10:19:43 UTC 2024
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

FreeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964:
Thu Mar 14 02:58:39 UTC 2024
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

hostb0@pci0:0:0:0:class=0x06 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x4609 subvendor=0x17aa subdevice=0x3803

   vendor = 'Intel Corporation'
   class  = bridge
   subclass   = HOST-PCI
vgapci0@pci0:0:2:0:class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 
device=0x46b3 subvendor=0x17aa subdevice=0x3b3a

   vendor = 'Intel Corporation'
   device = 'Alder Lake-UP3 GT1 [UHD Graphics]'
   class  = display
   subclass   = VGA
none0@pci0:0:4:0:class=0x118000 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x461d subvendor=0x17aa subdevice=0x380c

   vendor = 'Intel Corporation'
   device = 'Alder Lake Innovation Platform Framework Processor 
Participant'

   class  = dasp
pcib1@pci0:0:6:0:class=0x060400 rev=0x04 hdr=0x01 vendor=0x8086 
device=0x464d subvendor=0x17aa subdevice=0x380e

   vendor = 'Intel Corporation'
   device = '12th Gen Core Processor PCI Express x4 Controller'
   class  = bridge
   subclass   = PCI-PCI
none1@pci0:0:10:0:class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x467d subvendor=0x17aa subdevice=0x3813

   vendor = 'Intel Corporation'
   device = 'Platform Monitoring Technology'
   class  = dasp
xhci0@pci0:0:13:0:class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x461e subvendor=0x17aa subdevice=0x3824

   vendor = 'Intel Corporation'
   device = 'Alder Lake-P Thunderbolt 4 USB Controller'
   class  = serial bus
   subclass   = USB
xhci1@pci0:0:20:0:class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51ed subvendor=0x17aa subdevice=0x3820

   vendor = 'Intel Corporation'
   device = 'Alder Lake PCH USB 3.2 xHCI Host Controller'
   class  = serial bus
   subclass   = USB
none2@pci0:0:20:2:class=0x05 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51ef subvendor=0x17aa subdevice=0x381e

   vendor = 'Intel Corporation'
   device = 'Alder Lake PCH Shared SRAM'
   class  = memory
   subclass   = RAM
iwlwifi0@pci0:0:20:3:class=0x028000 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51f0 subvendor=0x8086 subdevice=0x0074

   vendor = 'Intel Corporation'
   device = 'Alder Lake-P PCH CNVi WiFi'
   class  = network
ig4iic0@pci0:0:21:0:class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51e8 subvendor=0x17aa subdevice=0x3812

   vendor = 'Intel Corporation'
   device = 'Alder Lake PCH Serial IO I2C Controller'
   class  = serial bus
ig4iic1@pci0:0:21:1:class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51e9 subvendor=0x17aa subdevice=0x3814

   vendor = 'Intel Corporation'
   device = 'Alder Lake PCH Serial IO I2C Controller'
   class  = serial bus
none3@pci0:0:22:0:class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51e0 subvendor=0x17aa subdevice=0x3815

   vendor = 'Intel Corporation'
   device = 'Alder Lake PCH HECI Controller'
   class  = simple comms
ahci0@pci0:0:23:0:class=0x010601 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51d3 subvendor=0x8086 subdevice=0x7270

   vendor = 'Intel Corporation'
   device = 'Alder Lake-P SATA AHCI Controller

Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?

[Chris]

 subdevice=0x382b

vendor = 'Intel Corporation'
device = 'Alder Lake PCH eSPI Controller'
class  = bridge
subclass   = PCI-ISA
hdac0@pci0:0:31:3:	class=0x040380 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51c8 subvendor=0x17aa subdevice=0x3881

vendor = 'Intel Corporation'
device = 'Alder Lake PCH-P High Definition Audio Controller'
class  = multimedia
subclass   = HDA
ichsmb0@pci0:0:31:4:	class=0x0c0500 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51a3 subvendor=0x17aa subdevice=0x382f

vendor = 'Intel Corporation'
device = 'Alder Lake PCH-P SMBus Host Controller'
class  = serial bus
subclass   = SMBus
none4@pci0:0:31:5:	class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x51a4 subvendor=0x17aa subdevice=0x381c

vendor = 'Intel Corporation'
device = 'Alder Lake-P PCH SPI Controller'
class  = serial bus
nvme0@pci0:1:0:0:	class=0x010802 rev=0x01 hdr=0x00 vendor=0x2646 
device=0x5013 subvendor=0x2646 subdevice=0x5013

vendor = 'Kingston Technology Company, Inc.'
device = 'KC3000/FURY Renegade NVMe SSD E18'
class  = mass storage
subclass   = NVM
sdhci_pci0@pci0:2:0:0:	class=0x080501 rev=0x01 hdr=0x00 vendor=0x1217 
device=0x8621 subvendor=0x17aa subdevice=0x3874

vendor = 'O2 Micro, Inc.'
device = 'SD/MMC Card Reader Controller'
class  = base peripheral
subclass   = SD host controller

Id Refs AddressSize Name
 1   95 0x8020  1d527c0 kernel
 21 0x81f54000287e8 fusefs.ko
 31 0x82d8f000   1e3228 i915kms.ko
 42 0x82f7300085090 drm.ko
 51 0x82ff9000 22b8 iic.ko
 62 0x82ffc000 40e9 linuxkpi_video.ko
 73 0x83001000 7358 dmabuf.ko
 83 0x83009000 3378 lindebugfs.ko
 91 0x8300d000 c338 ttm.ko
101 0x8301a000 5760 cuse.ko
111 0x8302 3390 acpi_wmi.ko
121 0x83024000 4250 ichsmb.ko
131 0x83029000 2178 smbus.ko
141 0x8302c00091260 if_iwlwifi.ko
151 0x830be000 5f90 ig4.ko
161 0x830c4000 4d20 ng_ubt.ko
173 0x830c9000 bbb8 netgraph.ko
182 0x830d5000 a250 ng_hci.ko
192 0x830e 2670 ng_bluetooth.ko
201 0x830e3000 3218 iichid.ko
215 0x830e7000 3380 hidbus.ko
221 0x830eb000 21e8 hms.ko
231 0x830ee000 40a8 hidmap.ko
241 0x830f3000 3355 hmt.ko
251 0x830f7000 22cc hconf.ko
261 0x830fa000 2260 pflog.ko
271 0x830fd00056540 pf.ko
281 0x83154000 3560 fdescfs.ko


Thanks!

--Chris

Re: Alt+Fn isn't functional. Has this been removed?

[Chris]

On 2024-03-29 23:06, Michael Schuster wrote:

Two ideas:
- does CTL-ALT-Fn work?

Thanks. But no, I tried that.


- perhaps the number of predefined ttys was overwritten/set to 0 somewhere?

I'm only aware of /etc/ttys, and they're all available (uncommented) and
ps(1) indicates getty(8) is running on all the normally assigned ttyv(n)'s.

Thanks for the reply!

--Chris


HTH
Michael

On Sat, Mar 30, 2024, 03:03 Chris  wrote:


I just poured the dist files onto an earlier 15 (after removing
the earlier version). After booting into the new install, I no longer
had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only
getting ttyv0. getty(8) is running, and a ps waux | grep getty shows
they're all up. Only things I saved from the older install were the
user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf.

What do I need to do to further isolate this problem?

Thanks.

System info:

FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0
main-n268793-220ee18f1964:
Thu Mar 14 02:58:39 UTC 2024
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)

IdeaPad 3 17IAU7

Id Refs AddressSize Name
  1   95 0x8020  1d527c0 kernel
  21 0x81f54000287e8 fusefs.ko
  31 0x82d8f000   1e3228 i915kms.ko
  42 0x82f7300085090 drm.ko
  51 0x82ff9000 22b8 iic.ko
  62 0x82ffc000 40e9 linuxkpi_video.ko
  73 0x83001000 7358 dmabuf.ko
  83 0x83009000 3378 lindebugfs.ko
  91 0x8300d000 c338 ttm.ko
101 0x8301a000 5760 cuse.ko
111 0x8302 3390 acpi_wmi.ko
121 0x83024000 4250 ichsmb.ko
131 0x83029000 2178 smbus.ko
141 0x8302c00091260 if_iwlwifi.ko
151 0x830be000 5f90 ig4.ko
161 0x830c4000 4d20 ng_ubt.ko
173 0x830c9000 bbb8 netgraph.ko
182 0x830d5000 a250 ng_hci.ko
192 0x830e 2670 ng_bluetooth.ko
201 0x830e3000 3218 iichid.ko
215 0x830e7000 3380 hidbus.ko
221 0x830eb000 21e8 hms.ko
231 0x830ee000 40a8 hidmap.ko
241 0x830f3000 3355 hmt.ko
251 0x830f7000 22cc hconf.ko
261 0x830fa000 2260 pflog.ko
271 0x830fd00056540 pf.ko
281 0x83154000 3560 fdescfs.ko

Alt+Fn isn't functional. Has this been removed?

[Chris]

I just poured the dist files onto an earlier 15 (after removing
the earlier version). After booting into the new install, I no longer
had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only
getting ttyv0. getty(8) is running, and a ps waux | grep getty shows
they're all up. Only things I saved from the older install were the
user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf.

What do I need to do to further isolate this problem?

Thanks.

System info:

FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 
main-n268793-220ee18f1964:

Thu Mar 14 02:58:39 UTC 2024
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)

IdeaPad 3 17IAU7

Id Refs AddressSize Name
 1   95 0x8020  1d527c0 kernel
 21 0x81f54000287e8 fusefs.ko
 31 0x82d8f000   1e3228 i915kms.ko
 42 0x82f7300085090 drm.ko
 51 0x82ff9000 22b8 iic.ko
 62 0x82ffc000 40e9 linuxkpi_video.ko
 73 0x83001000 7358 dmabuf.ko
 83 0x83009000 3378 lindebugfs.ko
 91 0x8300d000 c338 ttm.ko
101 0x8301a000 5760 cuse.ko
111 0x8302 3390 acpi_wmi.ko
121 0x83024000 4250 ichsmb.ko
131 0x83029000 2178 smbus.ko
141 0x8302c00091260 if_iwlwifi.ko
151 0x830be000 5f90 ig4.ko
161 0x830c4000 4d20 ng_ubt.ko
173 0x830c9000 bbb8 netgraph.ko
182 0x830d5000 a250 ng_hci.ko
192 0x830e 2670 ng_bluetooth.ko
201 0x830e3000 3218 iichid.ko
215 0x830e7000 3380 hidbus.ko
221 0x830eb000 21e8 hms.ko
231 0x830ee000 40a8 hidmap.ko
241 0x830f3000 3355 hmt.ko
251 0x830f7000 22cc hconf.ko
261 0x830fa000 2260 pflog.ko
271 0x830fd00056540 pf.ko
281 0x83154000 3560 fdescfs.ko

Re: NLNet Labs Ending Dev of drill(1)

[Chris]

On 2024-02-20 10:09, Pete Wright wrote:

I just came across this blog post which seems to indicate that the drill(1)
utility from NLNet is ending development in favor of a rust based tool:

https://blog.nlnetlabs.nl/domain-dns-building-blocks-for-rust-application-developers/

https://fosstodon.org/@nlnetlabs/111964417192522741

I was curious if a) anyone was aware of this and b) will we maintain a 
version of

drill(1) in base or revert to including dns/bind-tools in base?

+1 for keeping this as-is in $BASE.


not trying to start a "rust in base" discussion, just curious if i should 
start

making plans now to have a replacement for this tool at my site.

-pete

Thanks for the heads-up!

--Chris

Re: Alder lake supported? (graphics)

[Chris]

On 2024-01-18 15:42, Chris wrote:

On 2024-01-18 15:28, Chris wrote:

On 2024-01-18 08:47, Jan Beich wrote:

Chris  writes:


On 2024-01-16 19:02, Jan Beich wrote:


Chris  writes:


I upgraded to an alder lake based machine and installed 14.
But I can't seem to get the intel graphics loaded (drm-515-kmod).
It simply freezes at load.
Are Alder lake graphics supported?

Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >=
20230625).
Reported success in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8

[...]

I'm on 14. Commenting that conditional indicates I don't have a necessary
file (linux/iosys-map.h). So looks like I'll we'll have to wait. Or I'll
need to track 15. :(


On current@ list -CURRENT is expected. Due to backward compatibility it's
possible to run -CURRENT kernel with -RELEASE userland (world + packages).
For example, poudriere (as used by the package cluster) relies on this
to build binary packages for older FreeBSD versions on the same machine.

Alternatively, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274770#c5
proposed a branch which removes .require_force_probe for both ADL-S and 
ADL-P.

It builds fine on 14.0-RELEASE "as is" e.g., see ports/ diff below.

diff --git a/graphics/drm-515-kmod/Makefile.version 
b/graphics/drm-515-kmod/Makefile.version

index 4a7c27611bc8..469071220731 100644
--- a/graphics/drm-515-kmod/Makefile.version
+++ b/graphics/drm-515-kmod/Makefile.version
@@ -1,5 +1,5 @@
 # drm-kmod common version definition
 #
 # This will be included from consumers such as nvidia-drm
-DRM_KMOD_DISTVERSION=  5.15.118
-DRM_KMOD_GH_TAGNAME=   drm_v5.15.118_4
+DRM_KMOD_DISTVERSION=  5.15.focal
+DRM_KMOD_GH_TAGNAME=   97a4ad4364
diff --git a/graphics/drm-515-kmod/distinfo 
b/graphics/drm-515-kmod/distinfo

index 3599fc42317b..cadc6be14456 100644
--- a/graphics/drm-515-kmod/distinfo
+++ b/graphics/drm-515-kmod/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1703336317
-SHA256 (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) =
58e2fc195979e2361346ca57cc158e44413e5de26b83b951a631d09849caf90c
-SIZE (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = 26092371
+TIMESTAMP = 1698298780
+SHA256 (freebsd-drm-kmod-5.15.focal-97a4ad4364_GH0.tar.gz) =
fc6a94a74aea714bb25ccf788b8361de4db348ef1893fc391d00bd346e828732
+SIZE (freebsd-drm-kmod-5.15.focal-97Thank you very mua4ad4364_GH0.tar.gz) 
= 26126042

Thank you very much for all your time and efforts in your replies, Jan.
I examined the the forum thread and applied your patch to a current pull of 
ports.
After deinstalling my current install of 515.118, I performed a make 
install. Which
proceeded as expected. A kld_list resulted in a hard lock, in the same way 
515.118 did.
Requiring the use of the power button to power it down. Then a boot to 
single-user for
an fsck(8). Nothing reported in the logs. A boot without loading via 
rc.conf was went
without incident. A kldload i915kms locked it up hard. Again, nothing 
reported in the
logs. I'm keeping recent copies of /var/logs/messages in case there is 
anything anyone

might be interested in looking at.
At this point I've resolved to boot a recent 15 and format my current 
slices and unpack
a recent snapshot of 15 in hopes of getting decent graphics support on 
this. I'm happy

to test or further report anything that might be helpful for others.


I forgot to mention. When calling kldload i915kms
the screen returned only (transcribed):

iic0: < I2C generic I/O > iicbus0
iic1: < I2C generic I/O > iicbus1
Lindebugfs registered


UPDATE
It's not i915kms that causes the problem. Turns out to be the 
graphics/gpu-firmware-intel-kmod.

I opened a pr (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276451).

Thanks again for all your help, Jan.

--Chris

Re: Alder lake supported? (graphics)

[Chris]

On 2024-01-18 15:28, Chris wrote:

On 2024-01-18 08:47, Jan Beich wrote:

Chris  writes:


On 2024-01-16 19:02, Jan Beich wrote:


Chris  writes:


I upgraded to an alder lake based machine and installed 14.
But I can't seem to get the intel graphics loaded (drm-515-kmod).
It simply freezes at load.
Are Alder lake graphics supported?

Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >=
20230625).
Reported success in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8

[...]

I'm on 14. Commenting that conditional indicates I don't have a necessary
file (linux/iosys-map.h). So looks like I'll we'll have to wait. Or I'll
need to track 15. :(


On current@ list -CURRENT is expected. Due to backward compatibility it's
possible to run -CURRENT kernel with -RELEASE userland (world + packages).
For example, poudriere (as used by the package cluster) relies on this
to build binary packages for older FreeBSD versions on the same machine.

Alternatively, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274770#c5
proposed a branch which removes .require_force_probe for both ADL-S and 
ADL-P.

It builds fine on 14.0-RELEASE "as is" e.g., see ports/ diff below.

diff --git a/graphics/drm-515-kmod/Makefile.version 
b/graphics/drm-515-kmod/Makefile.version

index 4a7c27611bc8..469071220731 100644
--- a/graphics/drm-515-kmod/Makefile.version
+++ b/graphics/drm-515-kmod/Makefile.version
@@ -1,5 +1,5 @@
 # drm-kmod common version definition
 #
 # This will be included from consumers such as nvidia-drm
-DRM_KMOD_DISTVERSION=  5.15.118
-DRM_KMOD_GH_TAGNAME=   drm_v5.15.118_4
+DRM_KMOD_DISTVERSION=  5.15.focal
+DRM_KMOD_GH_TAGNAME=   97a4ad4364
diff --git a/graphics/drm-515-kmod/distinfo 
b/graphics/drm-515-kmod/distinfo

index 3599fc42317b..cadc6be14456 100644
--- a/graphics/drm-515-kmod/distinfo
+++ b/graphics/drm-515-kmod/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1703336317
-SHA256 (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) =
58e2fc195979e2361346ca57cc158e44413e5de26b83b951a631d09849caf90c
-SIZE (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = 26092371
+TIMESTAMP = 1698298780
+SHA256 (freebsd-drm-kmod-5.15.focal-97a4ad4364_GH0.tar.gz) =
fc6a94a74aea714bb25ccf788b8361de4db348ef1893fc391d00bd346e828732
+SIZE (freebsd-drm-kmod-5.15.focal-97Thank you very mua4ad4364_GH0.tar.gz) 
= 26126042

Thank you very much for all your time and efforts in your replies, Jan.
I examined the the forum thread and applied your patch to a current pull of 
ports.
After deinstalling my current install of 515.118, I performed a make 
install. Which
proceeded as expected. A kld_list resulted in a hard lock, in the same way 
515.118 did.
Requiring the use of the power button to power it down. Then a boot to 
single-user for
an fsck(8). Nothing reported in the logs. A boot without loading via rc.conf 
was went
without incident. A kldload i915kms locked it up hard. Again, nothing 
reported in the
logs. I'm keeping recent copies of /var/logs/messages in case there is 
anything anyone

might be interested in looking at.
At this point I've resolved to boot a recent 15 and format my current slices 
and unpack
a recent snapshot of 15 in hopes of getting decent graphics support on this. 
I'm happy

to test or further report anything that might be helpful for others.


I forgot to mention. When calling kldload i915kms
the screen returned only (transcribed):

iic0: < I2C generic I/O > iicbus0
iic1: < I2C generic I/O > iicbus1
Lindebugfs registered

Thanks again.

--Chris

Re: Alder lake supported? (graphics)

[Chris]

On 2024-01-18 08:47, Jan Beich wrote:

Chris  writes:


On 2024-01-16 19:02, Jan Beich wrote:


Chris  writes:


I upgraded to an alder lake based machine and installed 14.
But I can't seem to get the intel graphics loaded (drm-515-kmod).
It simply freezes at load.
Are Alder lake graphics supported?

Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >=
20230625).
Reported success in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8

[...]

I'm on 14. Commenting that conditional indicates I don't have a necessary
file (linux/iosys-map.h). So looks like I'll we'll have to wait. Or I'll
need to track 15. :(


On current@ list -CURRENT is expected. Due to backward compatibility it's
possible to run -CURRENT kernel with -RELEASE userland (world + packages).
For example, poudriere (as used by the package cluster) relies on this
to build binary packages for older FreeBSD versions on the same machine.

Alternatively, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274770#c5
proposed a branch which removes .require_force_probe for both ADL-S and 
ADL-P.

It builds fine on 14.0-RELEASE "as is" e.g., see ports/ diff below.

diff --git a/graphics/drm-515-kmod/Makefile.version 
b/graphics/drm-515-kmod/Makefile.version

index 4a7c27611bc8..469071220731 100644
--- a/graphics/drm-515-kmod/Makefile.version
+++ b/graphics/drm-515-kmod/Makefile.version
@@ -1,5 +1,5 @@
 # drm-kmod common version definition
 #
 # This will be included from consumers such as nvidia-drm
-DRM_KMOD_DISTVERSION=  5.15.118
-DRM_KMOD_GH_TAGNAME=   drm_v5.15.118_4
+DRM_KMOD_DISTVERSION=  5.15.focal
+DRM_KMOD_GH_TAGNAME=   97a4ad4364
diff --git a/graphics/drm-515-kmod/distinfo b/graphics/drm-515-kmod/distinfo
index 3599fc42317b..cadc6be14456 100644
--- a/graphics/drm-515-kmod/distinfo
+++ b/graphics/drm-515-kmod/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1703336317
-SHA256 (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) =
58e2fc195979e2361346ca57cc158e44413e5de26b83b951a631d09849caf90c
-SIZE (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = 26092371
+TIMESTAMP = 1698298780
+SHA256 (freebsd-drm-kmod-5.15.focal-97a4ad4364_GH0.tar.gz) =
fc6a94a74aea714bb25ccf788b8361de4db348ef1893fc391d00bd346e828732
+SIZE (freebsd-drm-kmod-5.15.focal-97Thank you very mua4ad4364_GH0.tar.gz) = 
26126042

Thank you very much for all your time and efforts in your replies, Jan.
I examined the the forum thread and applied your patch to a current pull of 
ports.
After deinstalling my current install of 515.118, I performed a make install. 
Which
proceeded as expected. A kld_list resulted in a hard lock, in the same way 
515.118 did.
Requiring the use of the power button to power it down. Then a boot to 
single-user for
an fsck(8). Nothing reported in the logs. A boot without loading via rc.conf 
was went
without incident. A kldload i915kms locked it up hard. Again, nothing 
reported in the
logs. I'm keeping recent copies of /var/logs/messages in case there is 
anything anyone

might be interested in looking at.
At this point I've resolved to boot a recent 15 and format my current slices 
and unpack
a recent snapshot of 15 in hopes of getting decent graphics support on this. 
I'm happy

to test or further report anything that might be helpful for others.

Thanks again!

--Chris

Re: Alder lake supported? (graphics)

[Chris]

On 2024-01-16 19:02, Jan Beich wrote:

Chris  writes:


I upgraded to an alder lake based machine and installed 14.
But I can't seem to get the intel graphics loaded (drm-515-kmod).
It simply freezes at load.
Are Alder lake graphics supported?


Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >= 
20230625).
Reported success in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8



releng/14.0-n265380-f9716eee8ab4
12th Gen Intel(R) Core(TM) i3-1215U
vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086
device=0x46b3 subvendor=0x17aa subdevice=0x3b3a
vendor = 'Intel Corporation'
device = 'Alder Lake-UP3 GT1 [UHD Graphics]'
class  = display
subclass   = VGA


0x46b3 aka ADL-P is unstable with Linux < 5.17 or in drm-515-kmod.
https://github.com/torvalds/linux/commit/dfb924e33927
https://github.com/freebsd/drm-kmod/commit/3403defd86e5

include/drm/i915_pciids.h contains a list of supported Intel GPUs.
drivers/gpu/drm/i915/i915_pci.c with .require_force_probe contain
a list of unstable GPU generations. Previously, Linux < 5.5 used
.alpha_support and Linux < 4.9 used .preliminary_hw_support.

drm-kmod doesn't support hw.i915kms.force_probe (via loader.conf or kenv)
tunable yet thus cannot override .require_force_probe for specific GPUs.
Instead it sets DRM_I915_FORCE_PROBE="*" to enable all unstable support.
https://github.com/freebsd/drm-kmod/commit/054cb0598cab

Thank you for the informative report, Jan.
Unfortunately I don't pass the conditional in Makefile for FreeBSD 15 or 
greater.

I'm on 14. Commenting that conditional indicates I don't have a necessary
file (linux/iosys-map.h). So looks like I'll we'll have to wait. Or I'll
need to track 15. :(

Thanks again! :-)

--Chris

Alder lake supported? (graphics)

[Chris]

I upgraded to an alder lake based machine and installed 14.
But I can't seem to get the intel graphics loaded (drm-515-kmod).
It simply freezes at load.
Are Alder lake graphics supported?

releng/14.0-n265380-f9716eee8ab4
12th Gen Intel(R) Core(TM) i3-1215U
vgapci0@pci0:0:2:0:	class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 
device=0x46b3 subvendor=0x17aa subdevice=0x3b3a

vendor = 'Intel Corporation'
device = 'Alder Lake-UP3 GT1 [UHD Graphics]'
class  = display
subclass   = VGA

Thanks for any clues here. :-)

--Chris

Re: noatime on ufs2

[Chris]

On 2024-01-09 00:47, Olivier Certner wrote:
Why not make noatime the default across the whole system? Outside of mbox 
why is recording access time actually useful?


Exactly.

I've never found any compelling reason in most uses to enable "atime", 
except
perhaps local mail but as addressed in other answers it is a relic of the 
past
mostly irrelevant today.  And its drawbacks are well known and can be 
serious.


The auditing use is not what I consider "normal" in the sense I suspect it
concerns a small minority of users (maybe even tiny).  Plus, serious 
auditing
requires keeping a log (generally immutable) of accesses, i.e., more than a 
single
time and, as pointed out in another answer, at least the ID of the user 
performing
the access.  Updating the access time field on files/directories doesn't 
address

both.

What "relatime" only gives you is a guarantee that you know that some file 
has
been accessed at some point after its last modification (or creation), and 
that
the access time is correct if precision is only a day.  It also generally 
lowers
I/O obviously, but not in some scenarios (file creation and subsequent 
read).


So, to me, at this point, it still sounds more than a gimmick than something
really useful.  If someone has a precise use case for it and motivation, 
than of

course please go ahead.

In the short term, I'd vote for turning "atime" off by default.

Thanks and regards.
Honestly! Why do we have to upend decades of usage and understanding? Just 
because
it's old doesn't mean it's wrong. Several weeks of replies confirm my initial 
belief --

atime as it is currently implemented, is as it should be.
Administrators and users have spent years to decades finessing their systems 
and
policies based on the way the OS works. In fact administrators and users 
*pick* their
OS based on the way it works. In the case of atime; decades of 
scripting/policy and
utilities have been created based upon the it's expected behavior on any 
given OS.
I haven't seen anything in this thread that wouldn't be better placed in 
tuning(7)

or tunefs(8).

* Silicon disks fail without warning
  tapes did as well. Unless you're working with punch cards please implement 
an

  effective backup strategy -- snapshot(8)
* writing to my disk takes a long time
  see tuning(7) or tunefs(8)
* atime doesn't work like "realtime" does on Linux
  use Linux instead or add the ability to also use realtime

Security and forensics are good reasons to keep atime unchanged. Any 
discussion

regarding changes to it's current behavior seems folly or bikeshedding.

Apologies for the "attitude".

--Chris

Re: Why was Sendmail replaced with DMA?

[Chris]

On 2022-12-05 10:26, Gregory Shapiro wrote:
I think the problem was that the original developers of sendmail have 
mostly

disappeared.
More or less.
It looked like abandonware.

Oh. You mean for Political reasons. :-(



Nope, still here.  Granted, the release cycle has slowed, but new
features are being tested and coming (e.g.,  SMTPUTF8/EAI, MTA-STS).

I'll be integrating 8.17.2 into FreeBSD upon its release as it has
stabilized the EAI work for those who wish to use it.

Thank you very much, Gregory. I use it for all it's intended use cases,
but have also leveraged it to generate a list of "bad actors" that I
add to pf(4). The list is verified daily and currently contains `half
a billion IPv4 IP's. I could have never managed anything like this with
all the other mailers available. Can I help sponsor your work in any way?

Thanks again!

--chris

0xBDE49540.asc
Description: application/pgp-keys

Why was Sendmail replaced with DMA?

[Chris]

I just noticed that FreeBSD will now install dma(8) instead of
sendmail(8) as the default mailer. Why is this so?

Thank you

--chris

0xBDE49540.asc
Description: application/pgp-keys

Re: RFC: nfsd in a vnet jail

[Chris]

On 2022-12-01 17:32, Rick Macklem wrote:

On Thu, Dec 1, 2022 at 8:23 AM Chris  wrote:


On 2022-11-29 16:21, Rick Macklem wrote:
> On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson 
wrote:
>
>> Keep the global variables as defaults that apply to all nfsds and allow
>> (at least some subset) to be overridden inside the net jails if some
things
>> need to be changed from the defaults?
>>
>> This is pretty much a reply to one of the posts selected at random,
> but I thought that better than starting a new email thread.
>
> bz@ and asomers@ have both asked about running mountd within a vnet
prison
> (one via offlist email and the other on phabricator).
>
> I think it is worth discussing here...
> mountd (rightly or wrongly) does two distinctly different things:
> 1 - It pushes the exports into the kernel via nmount() so they
> can be hung off of the "struct mount" for a file system's
> mount point.
> --> This can only work for file system mount points and can
> only be done once for any given file system mount point.
>
> At this time, I have it done once globally outside of the prisons.
> The alternative I can see is doing it within each prison, but I
> think that would require that each prison have its own file
system(s).
> (ie. The prison's root would always be a file system mount point.)
>
> 2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
> is NFSv3 specific, which is why I have done this NFSv4 only at
> this time.  To do this, it must be able to register with rpcbind,
> and I have no idea if running rpcbind in a vnet jail is practical.
>
> Enforcing the use for separate file systems for each jail also makes
> things safer, since the exports are enforced by the kernel. Without
> this, a malicious NFSv4 client could "guess" a file handle for a file
> outside the jail and gain access to that file. Put another way, without
> a separate file system, there is no way to stop a malicious client from
> finding files above the Root file handle. (Normal clients will use
> PutRootFH and LookupParent and these won't be able to go above the top
> of the jail.)
>
> So, what do others think of enforcing the requirement that each jail
> have its own file systems for this?

I don't care for any of it. It looks like additional overhead with the
addition of potential security risks. All for a very limited (and as yet
unknown) use case.


I am thinking that if/when this goes into main, it would be
under a new kernel build option called something like
NFSD_VIMAGE. I think that would avoid the overhead/security
risks for those that do not need/want it.

Brilliant. Count me in. :-)

--chris


rick



--chris
>
> rick
>
>
>> - Peter
>>
>>
>> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem 
wrote:
>>
>>> Hi,
>>>
>>> bz@ has encouraged me to fiddle with the nfsd
>>> so that it works in a vnet jail.
>>> I have now basically done so, specifically for
>>> NFSv4, since NFSv3 presents various issues.
>>>
>>> What I have not yet done is put global variables
>>> in the vnet. This needs to be done so that the nfsd
>>> can be run in multiple jail instances and/or in and
>>> outside of a jail.
>>> The problem is that there are 100s of global variables.
>>>
>>> I can see two approaches:
>>> 1 - Move them all into the vnet jail. This would imply
>>> that all the sysctls need to somehow be changed,
>>> which would seem to be a POLA violation.
>>> It also implies a lot of stuff in the vnet.
>>> 2 - Just move the global variables that will always
>>> differ from one nfsd to another (this would make
>>> the sysctls global and apply to all nfsds).
>>> This will keep the number of globals in the vnet
>>> smaller.
>>>
>>> I am currently leaning towards #2, put what do others
>>> think?
>>>
>>> rick
>>> ps: Personally, I don't know what use there is of
>>> running the nfsd inside a vnet jail, but bz@ has
>>> some use case.
>>>
>>
>>



0xBDE49540.asc
Description: application/pgp-keys

Re: RFC: nfsd in a vnet jail

[Chris]

On 2022-12-01 08:37, Alan Somers wrote:

I don't care for any of it. It looks like additional overhead with the
addition of potential security risks. All for a very limited (and as yet
unknown) use case.


Here's an example of a real-world use case.  I'm responsible for
supporting multiple products involving NFS, iSCSI, and other
protocols.  For security reasons, each product is placed on its own
VLAN.  Sometimes it's not practical to dedicate a physical server to a
single product, so I have to double-up.  For the products that don't
involve NFS or iSCSI, I place them in a VNET jail.  That way their
processes can only access the correct VLAN.  But NFS and iSCSI can't
(yet) be jailed, so those products need to be served by JID 0.
Therefore, those products' processes can access each other's VLANs.
Clearly that's not ideal.

Jailing different products is also good for manageability.  It's
easier to manage the list of packages that must be installed for each
product, config file settings, etc.  For example, some of our NFS
products require vfs.nfsd.enable_stringtouid=1, but others could work
without it.  Right now, we're forced to turn it on for all products.

OK. I can see that. Assuming I understand your intent correctly, I might
choose bhyve(8) for that. Tho that *would* be a little more expensive.
I rely on jail(8) daily. They're cheap, fast && easy. As yet, I've never
had unreasonable concern for security. The proposed change looks like a
potentially high addition of overhead (jail not so cheap now?). RPC &&
NFS are not cheap && have a comparatively high attack surface. So I guess
my concerns/view are affected by this understanding.

Thanks for the clarification, Alan.

--chris


-Alan


0xBDE49540.asc
Description: application/pgp-keys

Re: RFC: nfsd in a vnet jail

[Chris]

On 2022-11-29 16:21, Rick Macklem wrote:

On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson  wrote:


Keep the global variables as defaults that apply to all nfsds and allow
(at least some subset) to be overridden inside the net jails if some things
need to be changed from the defaults?

This is pretty much a reply to one of the posts selected at random,

but I thought that better than starting a new email thread.

bz@ and asomers@ have both asked about running mountd within a vnet prison
(one via offlist email and the other on phabricator).

I think it is worth discussing here...
mountd (rightly or wrongly) does two distinctly different things:
1 - It pushes the exports into the kernel via nmount() so they
can be hung off of the "struct mount" for a file system's
mount point.
--> This can only work for file system mount points and can
only be done once for any given file system mount point.

At this time, I have it done once globally outside of the prisons.
The alternative I can see is doing it within each prison, but I
think that would require that each prison have its own file system(s).
(ie. The prison's root would always be a file system mount point.)

2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
is NFSv3 specific, which is why I have done this NFSv4 only at
this time.  To do this, it must be able to register with rpcbind,
and I have no idea if running rpcbind in a vnet jail is practical.

Enforcing the use for separate file systems for each jail also makes
things safer, since the exports are enforced by the kernel. Without
this, a malicious NFSv4 client could "guess" a file handle for a file
outside the jail and gain access to that file. Put another way, without
a separate file system, there is no way to stop a malicious client from
finding files above the Root file handle. (Normal clients will use
PutRootFH and LookupParent and these won't be able to go above the top
of the jail.)

So, what do others think of enforcing the requirement that each jail
have its own file systems for this?


I don't care for any of it. It looks like additional overhead with the
addition of potential security risks. All for a very limited (and as yet
unknown) use case.

--chris


rick



- Peter


On Fri, Nov 25, 2022, 4:24 PM Rick Macklem  wrote:


Hi,

bz@ has encouraged me to fiddle with the nfsd
so that it works in a vnet jail.
I have now basically done so, specifically for
NFSv4, since NFSv3 presents various issues.

What I have not yet done is put global variables
in the vnet. This needs to be done so that the nfsd
can be run in multiple jail instances and/or in and
outside of a jail.
The problem is that there are 100s of global variables.

I can see two approaches:
1 - Move them all into the vnet jail. This would imply
that all the sysctls need to somehow be changed,
which would seem to be a POLA violation.
It also implies a lot of stuff in the vnet.
2 - Just move the global variables that will always
differ from one nfsd to another (this would make
the sysctls global and apply to all nfsds).
This will keep the number of globals in the vnet
smaller.

I am currently leaning towards #2, put what do others
think?

rick
ps: Personally, I don't know what use there is of
running the nfsd inside a vnet jail, but bz@ has
some use case.






0xBDE49540.asc
Description: application/pgp-keys

Re: Turning security email back on

[Chris]

On 2022-11-15 08:05, bob prohaska wrote:

It looks as if daily email reporting login failures and system status
are no longer being sent out on -current. Is there a switch for
/etc/rc.conf that will turn them back on?

Isn't this facilitated in periodic(8)

HTH

--Chris


Thanks for reading,

bob prohaska


0xBDE49540.asc
Description: application/pgp-keys

Re: Trying to compile theNVIDIA driver ........ however no ^bsd.sysdir.mk^

[Chris]

On 2022-11-07 07:21, louis.free...@xs4all.nl wrote:
As the title is allready tells, I try to compile and install a NVIDIA driver 
for

my 960 video card.

So I downloaded the driver from the NVIDIA site and tried to compile. That … 
does not work



Below the messages I get. It seems that the makefile expects bsd.sysdir.mk, 
which

is not there

(I verified)

How to fix this!?


Below the error messages.

Louis

make[2]: "/usr/share/mk/bsd.sysdir.mk" line 15: Unable to locate the kernel 
source

tree. Set SYSDIR to override.


This message is trying to tell you that there is nothing in your /usr/src
It needs (at least) headers from the version of source of the system you're 
running.


HTH

--chris


make: stopped in /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76

[root@mysys /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76]#


0xBDE49540.asc
Description: application/pgp-keys

Re: trpt(8) to be decomissioned

[Chris]

On 2022-11-04 09:40, Gleb Smirnoff wrote:

Max,

the reason I want to retire it is not that it consumes 40 Kb
in the repository.  The reason is that knows kernel structures,
and fails to compile after changes to them.  So the tool that
nobody uses requires special care when working on TCP.  The
kernel headers disclose the structures for trpt (with some
protection with _WANT_TCPCB, though) and some software from
ports (not calling names!) would start use them too. Now a
kernel developer needs to care not only about trpt, but
about this software, too.

On the kernel side there is also TCPDEBUG code that needs
to be kept compilable, while apparently nobody uses it.

While I really hate hearing that small utils
(almost elegant in their simplicity) that have worked perfectly
well for a great many years must be kicked to the curb. I guess
I can see your point. However I think TCPDEBUG affects a great
deal more that trpt(8). I hope your not implying that it should
go as well.



On Fri, Nov 04, 2022 at 07:19:19AM +, Max Baroi wrote:
M> I'm sorry if this is an inappropriate suggestion, but I think it would be 
neat
if there was a place in the ports hierarchy for retired programs like trpt. 
Maybe

a "historical" or "archival" directory for programs phased out of from base,
especially ones that are almost four decades old.
M>
M> -Max
M>
M> Nov 3, 2022 11:04:07 PM Mike Karels :
M>
M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
M> >
M> >>   Hi,
M> >>
M> >> trpt(8) is utility to pull TCP debugging data from the kernel
M> >> in 4.2BSD. We still have it in the base, with corresponding
M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option.
M> >>
M> >> At the same time we have much more powerful debugging facilities
M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and
M> >> siftr.  These are the tools that modern developers use.

modern developer(s): those whom create things that scratch their itch,
without looking hard enough to see that something else was already available. 
;-)



M> >>
M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
M> >> None of them new what trpt(8) is :) Looks like a good justification
M> >> to me.
M> >
M> > I have used trpt, but not for many years.  It was done before tcpdump
M> > as well.  Its time has long since gone.
M> >
M> >     Mike
M> >> --
M> >> Gleb Smirnoff
M>
M>

--chris

0xBDE49540.asc
Description: application/pgp-keys

athp / ath10k or the Atheros QCA6174

[Chris]

It appears that many chips like the Atheros/Qualcomm QCA6174 are
supported on FreeBSD by the athp or the ath10k. But in some
7 years now, neither of those drivers have come to fruition.
Are there any plans to complete either of these? Or is there
a different option for these chips?

Thank you for all your time and consideration.

--chris

0xBDE49540.asc
Description: application/pgp-keys

Re: psm0: unable to allocate IRQ

[Chris]

On 2022-10-03 08:05, Rodney W. Grimes wrote:

On 2022-10-02 17:45, Chris wrote:
> I've spent the last 2 days attempting to get a fresh install of
> stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.

Just attempted it again with the
14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the
same results. Yet Linux && Windows work as intended. Any thoughts
on how I might track the problem down in FreeBSD?
Thanks.

> The problem I struggled with was getting the trackpad (synaptics?)
> to be recognized and function. As it is, it's only ever recognized
> as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
> sure this is on a psm(4). But any attempts to use psm fail with
> psm0: unable to allocate IRQ.
> An error I found in dmesg(8) on a verbose boot. Anybody familiar
> with this, or have any thoughts on how I might track this down?
>
> To rule out hardware; I installed Slackware along side the
> FreeBSD install, and it has no trouble creating a full featured
> trackpad under the MATE DE.


And in Slackware did it show up as a psm device,
and if it did what IRQ is it using.

Or what I suspect, is it shows up as a USB device.


Mr. Grimes, you're wise well beyond your years.
IOW Thanks! You nailed it.

# lsusb
Bus 004 Device 003: ID 8087:07dc Intel Corp.
Bus 004 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 004: ID 06cb:75bf Synaptics, Inc.  
<===
Bus 003 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card 
Reader Controller

Bus 003 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 064e:920b Suyin Corp. Integrated_Webcam_HD
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
|__ Port 1: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 1: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
Driver=rtsx_usb, 480M
|__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 
12M

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 2: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 2: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M

Now. If I can only figure out why FreeBSD's Synaptics module
only polls psm(4).

Thanks, Rodney!

--chris

0xBDE49540.asc
Description: application/pgp-keys

Re: psm0: unable to allocate IRQ

[Chris]

On 2022-10-02 17:45, Chris wrote:

I've spent the last 2 days attempting to get a fresh install of
stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.


Just attempted it again with the
14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the
same results. Yet Linux && Windows work as intended. Any thoughts
on how I might track the problem down in FreeBSD?
Thanks.


The problem I struggled with was getting the trackpad (synaptics?)
to be recognized and function. As it is, it's only ever recognized
as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
sure this is on a psm(4). But any attempts to use psm fail with
psm0: unable to allocate IRQ.
An error I found in dmesg(8) on a verbose boot. Anybody familiar
with this, or have any thoughts on how I might track this down?

To rule out hardware; I installed Slackware along side the
FreeBSD install, and it has no trouble creating a full featured
trackpad under the MATE DE.

Thank you for all your time, and consideration.

--chris


0xBDE49540.asc
Description: application/pgp-keys

psm0: unable to allocate IRQ

[Chris]

I've spent the last 2 days attempting to get a fresh install of
stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.
The problem I struggled with was getting the trackpad (synaptics?)
to be recognized and function. As it is, it's only ever recognized
as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
sure this is on a psm(4). But any attempts to use psm fail with
psm0: unable to allocate IRQ.
An error I found in dmesg(8) on a verbose boot. Anybody familiar
with this, or have any thoughts on how I might track this down?

To rule out hardware; I installed Slackware along side the
FreeBSD install, and it has no trouble creating a full featured
trackpad under the MATE DE.

Thank you for all your time, and consideration.

--chris

0xBDE49540.asc
Description: application/pgp-keys

Re: from X to terminal needs an fflush

[Chris]

On 2022-07-27 13:45, Ivan Quitschal wrote:

On Wed, 27 Jul 2022, Ivan Quitschal wrote:




On Tue, 26 Jul 2022, Tomoaki AOKI wrote:


On Tue, 26 Jul 2022 10:30:25 -0700
Chris  wrote:


On 2022-07-26 10:29, Chris wrote:

On 2022-07-22 08:27, Ivan Quitschal wrote:

hi all

Ive been trying to solve a problem which is happening to me but so far 
no

success.
problem is this:

sometimes happens, sometimes doesnt, but once im on X and do a "F2", 
"F3"

whatever
in order to get back to terminal, it *does* get back to terminal but 
the

screen
still shows like i was on X, therefore i have to do a F* twice in order 
to

see the
console , like an fflush was missing somewhere.
If I'm following you correctly; you should be performing a 
Ctrl+Atl+F<1-8>

to

TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>


...and Alt+F<1-8> to switch vtys afterwards.
To get back to X, Alt+F9.

You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.




Sorry.

accomplish your goal. Does doing it that way fix it for you?

HTH

--Chris


im using the drm-devel-kmod git for i915kms.ko btw

any ideas what could it be?

thank you guys

--tzk



-- Tomoaki AOKI



hi

no gyuys, i know how to go back from X to terminal, what i was saying is 
that by doing CTRL + ALT + F* it wasnt working until i did *another* 
CTRL+ALT+F.


example:
im getting off from X , so i do an CTRL+ALT+F2

nothing happens, until you do *another* CTRL+ALT+F3 . so you gotta do a 
CTRL+ALT+F* twice in order to get back to terminal


but i found out the problem lies within enlightenment themes, not anything 
else .
at least the problem is  solved by changing EE theme, this way i can get 
back instantly to terminal with just ONE CTRL+ALT+F2


thanks

Ivan




btw, there is something i always wanted to ask, why do we have just 9 
terminals?

im really asking , never understood that

in my case here , im using all F* keys

my /etc/ttys

ttyv0   "/usr/libexec/getty Pc" xterm   onifexists secure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv2   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv3   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv4   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv5   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv6   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv7   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv8   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyv9   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyva   "/usr/libexec/getty Pc" xterm   onifexists secure
ttyvb   "/usr/local/bin/xdm -nodaemon"  xterm   off secure


my F-key dedicated to get back to X is F12 , as it should be IMO. question 
is ,

why isnt it yet?

im sure there is a reason, just curious because honestly i got no idea 
whatsoever
ttys(5) is fairly informative and less /etc/ttys has some info. But I can't 
remember
the history on why 9 was the default. The SUN || terminal keyboard mapping, 
maybe?


--Chris


--tzk


0xBDE49540.asc
Description: application/pgp-keys

Re: from X to terminal needs an fflush

[Chris]

On 2022-07-26 10:29, Chris wrote:

On 2022-07-22 08:27, Ivan Quitschal wrote:

hi all

Ive been trying to solve a problem which is happening to me but so far no 
success.

problem is this:

sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
whatever
in order to get back to terminal, it *does* get back to terminal but the 
screen
still shows like i was on X, therefore i have to do a F* twice in order to 
see the

console , like an fflush was missing somewhere.
If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8> 
to

TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>

Sorry.

accomplish your goal. Does doing it that way fix it for you?

HTH

--Chris


im using the drm-devel-kmod git for i915kms.ko btw

any ideas what could it be?

thank you guys

--tzk


0xBDE49540.asc
Description: application/pgp-keys

Re: from X to terminal needs an fflush

[Chris]

On 2022-07-22 08:27, Ivan Quitschal wrote:

hi all

Ive been trying to solve a problem which is happening to me but so far no 
success.

problem is this:

sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
whatever
in order to get back to terminal, it *does* get back to terminal but the 
screen
still shows like i was on X, therefore i have to do a F* twice in order to 
see the

console , like an fflush was missing somewhere.

If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8> to
accomplish your goal. Does doing it that way fix it for you?

HTH

--Chris


im using the drm-devel-kmod git for i915kms.ko btw

any ideas what could it be?

thank you guys

--tzk


0xBDE49540.asc
Description: application/pgp-keys

Re: Posting Netiquette [ref: Threads "look definitely like" unreadable mess. Handbook project.]

[Chris]

On 2022-06-23 01:14, grarpamp wrote:

the “> ;† and leave empty lines between your text and the original



Seems there is a charset mismatch.
MUA displaying nonsense
Oh the joy of UTF-8... ;-)


https://unicode-table.com/en/sets/quotation-marks/

The pages ...

https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail
https://docs.freebsd.org/en/articles/freebsd-questions/
https://docs.freebsd.org/en/articles/mailing-list-faq/

... are intermixing standard ASCII double quotes with questionably
gratuitous choice of using left and right double quotes via UTF-8,
which then may get slaughtered by non UTF-8 enabled cut-paste,
systems, lists, gui's, desktops, apps, and MUAs along the way.


...

A proper page would need to add a number of the missing
email formatting netiquettes (such as no HTML), and actual
photo examples of former bad chaos and new good result, etc...
to be considered a good format, subject, and addressing
netiquette guide rule page.

Consider if "FreeBSD Articles" is best hier for a page that
may becoming more often directly linked or included into
prospective list user's signup clickstream, quarterly admin,
friendly cluebat hints, etc.


What is the possibility of getting the/a "netiquette" link in
the FreeBSD Mailinglist footer that is already appended to all
the messages? This would only be a small addition, with a quick/
easy reference to the subject at hand.

Just my .2¢

Chris


0xBDE49540.asc
Description: application/pgp-keys

Re: MCE: Does this look possibly like a slot issue?

[Chris]

On 2022-06-21 12:23, Larry Rosenman wrote:

On 06/21/2022 1:23 pm, Chris wrote:

On 2022-06-20 17:23, Larry Rosenman wrote:

I'm seeing them constantly:

FWIW it looks like a sync(ing) problem between your
RAM && CPU cache. Are are your clocks set correctly
for your CPU && RAM? Is your CPU too hot? Is the CPU
cache ECC?


root@freenas[~]# mcelog --dmi


[snip]

Hrm.  IIRC all the BIOS parameters are default (I could be mistaken).  It's 
a

SuperMicro X8DTN+ motherboard with:
CPU: Intel(R) Xeon(R) CPU   E5645  @ 2.40GHz (2400.22-MHz K8-class 
CPU)

  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2

Features=0xbfebfbff

Features2=0x29ee3ff
  AMD Features=0x2c100800
  AMD Features2=0x1
  Structured Extended Features3=0x9c00
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 77309411328 (73728 MB)
avail memory = 75186962432 (71703 MB)
(2 packages, 6 core, 12-threads each) and 18 4GB sticks.
this ONE slot seems to be a problem.

How would you recommend looking for an issue modulo pulling the 2 cpu 
packages?
When I ran into these errors it turned out to be a hot CPU as I recall. While 
I'm familiar with
the hardware your using. I have no history with *your* equipment. The first 2 
things I'd do
given ECC is so sensitive, is replace/swap the PSU with a known good one. The 
CPU(s) should
be re-seated && re-greased. The fans operate as intended? At that point a 
long session with
sysutils/memtest86 or a buildworld session should tell you if everything is 
AOK. Frankly; as to
testing memory; working with a single stick at a time would be more 
conclusive resulting

in a shorter time to conclusion.

HTH

Chris


0xBDE49540.asc
Description: application/pgp-keys

Re: MCE: Does this look possibly like a slot issue?

[Chris]

On 2022-06-20 17:23, Larry Rosenman wrote:

I'm seeing them constantly:

FWIW it looks like a sync(ing) problem between your
RAM && CPU cache. Are are your clocks set correctly
for your CPU && RAM? Is your CPU too hot? Is the CPU
cache ECC?


root@freenas[~]# mcelog --dmi
Hardware event. This is not a software error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac29890200046444 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 44
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c41009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 1
CPU 22 BANK 8 TSC 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c41009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 2
CPU 22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory ECC error occurred during scrub
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 884200cf MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 3
CPU 22 BANK 8 TSC 31e141418eb8
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c41009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 4
CPU 22 BANK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c41009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 5
CPU 22 BANK 8 TSC 41d1dbef1a6a
MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c41009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 6
CPU 22 BANK 8 TSC 4a1b1ecef446
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c41009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
MISC ac29890200040386 ADDR ee2f6e800
TIME 

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Chris]

On 2022-04-27 20:40, Michael Schuster wrote:

Chris,

thx for your response. However 

On Thu, Apr 28, 2022 at 4:19 AM Chris  wrote:


On 2022-04-27 12:59, Michael Schuster wrote:
> Hi,
>
> $subject happened to me just now on current. I researched it on the
> internet, the answer to this issue seems to be a universal "uninstall
> and install the package" which seems to have worked in all cases I saw
> it suggested.
>
> I'm trying to embed this command into a script and would like to avoid
> manual intervention (I have to admit, this is the first time I've
> encountered this error in the two years I've been doodling with
> FreeBSD again) ...
> Is anything more known about this error behaviour, and what I can do
> to avoid it?
>
> TIA
> Michael
>
> PS: in case it matters: the full path shown in the error message is
> 
/usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG,
> the package being extracted is grantleetheme-22.04.0
This looks more a case for the Maintainer of the GrantleeTheme than for
current@


 ... maybe. OTOH, the instances I found mentioned on the 'net are all
about different packages:

eg:
https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767

I feel there's something different at work here than just one
maintainer's oversight.
You may well be correct. On the surface, to me it looked like a port problem 
so I thought

you might get quicker results via it's maintainer. :-)

Good luck! :-)


Thx
Michael


0xBDE49540.asc
Description: application/pgp-keys

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Chris]

On 2022-04-27 12:59, Michael Schuster wrote:

Hi,

$subject happened to me just now on current. I researched it on the
internet, the answer to this issue seems to be a universal "uninstall
and install the package" which seems to have worked in all cases I saw
it suggested.

I'm trying to embed this command into a script and would like to avoid
manual intervention (I have to admit, this is the first time I've
encountered this error in the two years I've been doodling with
FreeBSD again) ...
Is anything more known about this error behaviour, and what I can do
to avoid it?

TIA
Michael

PS: in case it matters: the full path shown in the error message is
/usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG,
the package being extracted is grantleetheme-22.04.0
This looks more a case for the Maintainer of the GrantleeTheme than for 
current@


0xBDE49540.asc
Description: application/pgp-keys

Re: Which ath(4) cards are currently supported?

[Chris]

On 2022-04-04 11:17, Freddie Cash wrote:

On Mon, Apr 4, 2022 at 11:01 AM Chris  wrote:


OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new
laptop I picked up. But 80211ac isn't yet supported. :-(
OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE
Hardware notes[1] which indicates:
The ath(4) driver supports all Atheros Cardbus and PCI cards, except
those that are based on the AR5005VL chipset.



Note:  PCI means PCI, not PCIe.  :)  The ath(4) driver supports the old PCI
and CardBus adapters.  It doesn't support PCIe, USB, M.2, or other
formfactor adapters.

While slightly ambiguous, the hardware notes are technically correct.

Sure OK. I simply moved down to the "Wireless Network Interfaces" to see
if I could discover exactly *which* Atheros numbers I could safely buy
to use FreeBSD effectively on my new laptop. You know; like:
Atheros m.2. Which I could then compare to those indicated by FreeBSD as
being supported.
Oh well. I guess I'm stuck with the numbers given on the ath_hal(4) man page.
Maybe that's the complete list?

Thanks for taking the time to reply, Freddie! :-)

--Chris

0xBDE49540.asc
Description: application/pgp-keys

Which ath(4) cards are currently supported?

[Chris]

OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new
laptop I picked up. But 80211ac isn't yet supported. :-(
OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE
Hardware notes[1] which indicates:
The ath(4) driver supports all Atheros Cardbus and PCI cards, except
those that are based on the AR5005VL chipset.
Which I think must be completely incorrect. As far as I can tell, with
the exception of some hard work by bz@, FreeBSD WiFi is anywhere from
9-15yrs out. No 11ac or 11ax. WiFi-7 is also available, just not
supported on FBSD. I not attempting to take shots here. Just trying to
point out the fact that ath(4) doesn't cover all their chip-models as
the RELEASE NOTES indicate. Does anyone have/provide a list? Does the
SYNOPSIS in ath_hal(4) cover the entire list?

Thank you for all your time, and consideration.


1. https://www.freebsd.org/releases/13.0R/hardware/

P.S. Mad props to Bjoern for his hard work on this! :-)

--Chris

0xBDE49540.asc
Description: application/pgp-keys

Any hope for 802.11ac on an Atheros chip?

[Chris]

I recently got a laptop, and picked up an Atheros QCA6174 2x2 802.11ac
card for it. But after putting it in. FreeBSD-(13 && 13.1) doesn't even
know it's there. I was sure that they were supported, as it was reported
to be "close/almost finished" in the July-September 2020 Quarterly report[1]
as well as a report by Adrian that "We know whats missing"[2] somewhat
later on the mailing list.
So where can I find it? :-)

Thank you for all your time, and consideration.

--Chris


1. https://www.freebsd.org/status/report-2020-07-2020-09.html
2. https://www.mail-archive.com/freebsd-wireless@freebsd.org/msg06983.html

0xBDE49540.asc
Description: application/pgp-keys

Re: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported?

[Chris]

On 2022-03-23 14:57, Pete Wright wrote:

On 3/23/22 14:44, Chris wrote:
On a releng/13 install. I've installed the drm-kmod and loaded both the 
amdgpu
and the radeonkms (at different times). I also installed the xf86-ati 
driver.

But X isn't happy with it. This is in a laptop with the A8-7410. It claims
Radeon R5 (formerly Carrizo). I find no mention of it in the on the FBSD 
Graphics
wiki, or any of the links from there. Has anyone set one of these up 
sucessfully?

Is it even possible? If so, what must I do?


hey chris - what happens when you load the amdgpu driver via rc.conf?  does 
it
load correctly, or does the system crash on boot? for example what does 
"dmesg |

grep drm" look like?

Hey pete, thanks for the prompt reply!
It "flashes" but the resolution doesn't appear to change. It's booting UEFI, 
if that

should matter. grep(1) output attached. It's a bit long to paste inline.


assuming it does load successfully i think you are using the wrong xorg 
driver as
the xf86-ati driver is ATI not amd devices.  Does loading xf86-video-amdgpu 
work

better?

You're probably right. I'll give that a try.

Thanks again! :-)


cheers,
-pete

--Chris[drm] radeon kernel modesetting enabled.
drmn0:  on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] initializing kernel modesetting (MULLINS 0x1002:0x9851 0x1028:0x06BF 
0x45).
[drm] doorbell mmio base: 0xF000
[drm] doorbell mmio size: 8388608
[drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for 
ATOM IIO
drmn0: VRAM: 1024M 0x - 0x3FFF (1024M used)
drmn0: GTT: 2048M 0x4000 - 0xBFFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 128bits DDR
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 2048M of GTT memory ready.
[drm] Loading mullins Microcode
drmn0: successfully loaded firmware image 'radeon/mullins_pfp.bin'
drmn0: successfully loaded firmware image 'radeon/mullins_me.bin'
drmn0: successfully loaded firmware image 'radeon/mullins_ce.bin'
drmn0: successfully loaded firmware image 'radeon/mullins_mec.bin'
drmn0: successfully loaded firmware image 'radeon/mullins_rlc.bin'
drmn0: successfully loaded firmware image 'radeon/mullins_sdma.bin'
[drm] Internal thermal controller without fan control
[drm] radeon: dpm initialized
drmn0: successfully loaded firmware image 'radeon/bonaire_uvd.bin'
[drm] Found UVD firmware Version: 1.64 Family ID: 9
drmn0: successfully loaded firmware image 'radeon/BONAIRE_vce.bin'
[drm] Found VCE firmware/feedback version 40.2.2 / 15!
[drm] GART: num cpu pages 524288, num gpu pages 524288
[drm] PCIE GART of 2048M enabled (table at 0x0030E000).
drmn0: WB enabled
drmn0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 
0x0xf800079f1c00
drmn0: fence driver on ring 1 use gpu addr 0x4c04 and cpu addr 
0x0xf800079f1c04
drmn0: fence driver on ring 2 use gpu addr 0x4c08 and cpu addr 
0x0xf800079f1c08
drmn0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 
0x0xf800079f1c0c
drmn0: fence driver on ring 4 use gpu addr 0x4c10 and cpu addr 
0x0xf800079f1c10
drmn0: fence driver on ring 5 use gpu addr 0x00078d30 and cpu addr 
0x0xf800e0078d30
drmn0: fence driver on ring 6 use gpu addr 0x4c18 and cpu addr 
0x0xf800079f1c18
drmn0: fence driver on ring 7 use gpu addr 0x4c1c and cpu addr 
0x0xf800079f1c1c
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
drmn0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 3 usecs
[drm] ring test on 1 succeeded in 2 usecs
[drm] ring test on 2 succeeded in 2 usecs
[drm] ring test on 3 succeeded in 4 usecs
[drm] ring test on 4 succeeded in 4 usecs
[drm] ring test on 5 succeeded in 2 usecs
[drm] UVD initialized successfully.
[drm] ring test on 6 succeeded in 20 usecs
[drm] ring test on 7 succeeded in 2 usecs
[drm] VCE initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
[drm] ib test on ring 6 succeeded
[drm] ib test on ring 7 succeeded
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] radeon atom DIG backlight initialized
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   eDP-1
[drm]   HPD1
[drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[drm]   Encoders:
[drm] LCD1: INTERNAL_UNIPHY
[drm] Connector 1:
[drm]   HDMI-A-1
[drm]   HPD2
[drm]   DDC: 0x6540 0x6540 0x6544 

Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported?

[Chris]

On a releng/13 install. I've installed the drm-kmod and loaded both the 
amdgpu

and the radeonkms (at different times). I also installed the xf86-ati driver.
But X isn't happy with it. This is in a laptop with the A8-7410. It claims
Radeon R5 (formerly Carrizo). I find no mention of it in the on the FBSD 
Graphics
wiki, or any of the links from there. Has anyone set one of these up 
sucessfully?

Is it even possible? If so, what must I do?

Thank you for all your time, and consideration.

--Chris

0xBDE49540.asc
Description: application/pgp-keys

Re: Deprecating ISA sound cards

[Chris]

On 2022-03-18 09:08, Ed Maste wrote:

ISA sound cards have been obsolete for more than a decade, and it is
(past) time to retire their drivers. This includes the following
drivers/devices:

snd_ad1816  Analog Devices AD1816 SoundPort
snd_ess Ensoniq ESS
snd_guscGravis UltraSound
snd_mss Microsoft Sound System
snd_sbc Creative Sound Blaster

I have a review open to add deprecation notices:
https://reviews.freebsd.org/D34604

I expect to commit this in the near future, then MFC to stable
branches and remove these drivers from main. Please follow up if
there's a reason we should postpone the removal of any of these
drivers.
This only hurts from a nostalgic perspective. Those GUS cards were 
incredible!

I have a board running freebsd that has 2 GUS cards in it running
simultaneously. Sniff... cést la vié

0xBDE49540.asc
Description: application/pgp-keys

Re: compressed TIME-WAIT to be decomissioned

[Chris]

On 2022-01-12 10:48, Gleb Smirnoff wrote:

Hi!

Thanks for the informative writeup, Gleb!
Untrimmed, sorry...



[crossposted to current@, but let's keep discussion at net@]

I have already touched the topic with rrs@, jtl@, tuexen@, rscheff@ and
Igor Sysoev (author of nginx).  Now posting for wider discussion.

TLDR: struct tcptw shall be decomissioned

Longer version covers three topics: why does tcptw exist? why is it no
longer necessary? what would we get removing it?

Why does struct tcptw exist?

When TCP connection goes to TIME-WAIT state, it can only retransmit
the very last ACK, thus doesn't need all of the control data in the kernel.
However, we are required to keep it in memory for certain amount of time
(2*MSL). So, let's save memory: free the socket, free the tcpcb and
leave only inpcb that will point at small tcptw (much smaller than tcpcb)
that holds enough info to retransmit the last ACK. This was done in
early 2003, see 340c35de6a2.

What was different in 2003 compared to 2022?

* First of all, internet servers were running i386 with only 2 Gb of KVA
  space. Unlike today, they were memory constrained in the first place, not
  CPU bound like they are today.

* Many of HTTP connections were made by older browsers, which were not able
  to use persistent HTTP connections.  Those browsers that could, would
  recycle connections more often, then today.  Default timeouts in Apache
  for persistent connections were short.  So, the ratio of connections
  in TIME-WAIT compared to live connections was much bigger than today.
  Here is sample data from 2008 provided to me by Igor Sysoev:

  ITEM SIZE LIMIT  USED  FREE  REQUESTS  FAILURES
  tcpcb:728,   163840,22938,72722, 13029632,0
  tcptw: 88,   163842,10253,72949,  2447928,0

  We see that TIME-WAITs are ~ 50% of live connections.

  Today I see that TIME-WAITs are ~ 1% of connections. My data is biased
  here, since I'm looking at servers that do mostly video streaming. I'd
  be grateful if anybody replies to this email with some other modern data
  on ratio between tcpcb and tcptw allocations.

* The Internet bandwidth was lower and thus average size of HTTP object
  much smaller.  That made the average send socket buffer size much smaller
  than today.  Note that TCP socket buffers autosizing came in 2009 only.
  This means that today most significant portion of kernel memory consumed
  by an average TCP connection is the send socket buffer, and
  socket+inpcb+tcpcb is just a fraction of that.  Thus, swapping tcpcb to
  tcptw we are saving a fraction of a fraction of memory consumed by average
  connection.

* Who told that 2*MSL (60 seconds) is adequate time to keep TIME-WAIT?
  In 71d2d5adfe1 I added some stats on usage of tcptw and experimented a bit
  with lowering net.inet.tcp.msl. It appeared that lowering it down three
  times doesn't have statistically significant effect on TIME-WAIT use 
stats.

  This means that the already miniscule number of TIME-WAIT connection on a
  modern HTTP server can be lowered 3 times more.  Feel free to lower
  net.inet.tcp.msl and do your own measurements with
  'netstat -sp tcp | grep TIME-WAIT'.  I'd be glad to see your results.

I think that should be:
'netstat -sp tcp | grep TIME_WAIT'
fe; on the system I'm writing this from:

up 15:19, coffee#
netstat -sp tcp | grep TIME_WAIT
5 connections in TIME_WAIT state



Ok, now what would removal give us?

* One less alloc/free during socket lifetime (immediately).
* Reduced code complexity. inp->inp_ppcb always can be dereferenced as 
tcpcb.
  Lot's of checking for inp->inp_flags & INP_TIMEWAIT goes away 
(eventually).

* Shrink of struct inpcb. Today inpcb has some TCP-only data, e.g. HPTS.
  Reason for that is obvious - compressed TIME-WAIT. A HPTS-driven 
connection
  may transition to TIME-WAIT, so we can't use tcpcb. Now we would be able 
to.
  So, for non TCP connections memory footprint shrinks (with following 
changes).
* Embedding inpcb into protocols cb. An inpcb becomes one piece of memory 
with

  tcpcb. One more less alloc/free during socket lifetime. Reduced code
  complexity, since now inpcb == tcpb (following changes).

How much memory are we going to lose?

(kgdb) p tcpcb_zone->uz_keg->uk_rsize
$5 = 1064
(kgdb) p tcptw_zone->uz_keg->uk_rsize
$6 = 72
(kgdb) p tcpcbstor->ips_zone->uz_keg->uk_rsize
$8 = 424

After change a connection in TIME-WAIT would consume 424+1064 bytes instead
of 424+72. Multiply that by expected number of connections in TIME-WAIT on
your machine.

Comments welcome.


0xBDE49540.asc
Description: application/pgp-keys

Re: question on socket server

[Chris]

On 2021-12-15 02:55, Piper H wrote:

But I write this program to listen on port  who sends a random str to
the socket every 0.25 second. And there is no client connecting to the
port. The server just runs there without problem. :( So I am not sure
enough...

use strict;

package MyPackage;
use base qw(Net::Server);


my @fruit=qw(
...
);


sub process_request {
my $self = shift;
$| = 1;
my $max = scalar @fruit;

while (1) {
my $id1 = int(rand($max));
my $str = $fruit[$id1];

print "$str\015\012";
select(undef, undef, undef, 0.25);
}
}


I think it might be easier for you if you have a look at the MILTER
interface to Sendmail. There are a myriad milters written for sendmail.
The entire milter system is (unix) socket driven.
So the examples should prove enlightening? :-)

HTH

-- Chris

MyPackage->run(port => , ipv => '*');

On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop  wrote:


Hi,

Just try it!

I think you will get an error that you are writing to a not-connected
socket.
From "man 2 write":
" [EPIPE]An attempt is made to write to a socket of type
SOCK_STREAM that is not connected to a peer socket."

See also "man 2 send"  and "man 2 socket" for a lot more information.

So it depends a bit on the type of socket you created.

Regards and happy hacking,
Ronald.



*Van:* Piper H 
*Datum:* woensdag, 15 december 2021 07:52
*Aan:* freebsd-current@freebsd.org
*Onderwerp:* question on socket server

Hello

I have little knowledge about socket programming.
I have a question that, if I have made a socket server, listening on a
port. The server prints data to the socket, but there is never a client
connection to the port, and the data is never consumed. What will happen to
the server then? will the OS kernel be flushed by junk bytes?

Thanks for your help.
Piper
--

Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux

[Chris]

On 2021-12-11 02:38, David Chisnall wrote:
While I agree on most of your points, the value of Phoronix is that it tests 
the

default install.

As an end user, I don’t care that a particular program is twice as fast on a
particular Linux distro as it is on FreeBSD because of kernel features, 
compiler

options, or dependency choices.

I would love to see the base system include the ThinLTO (LLVM IR) .a files 
so that
I can do inlining from libc into my program.  I would love for ports to 
default to
ThinLTO unless they break with it.  Apple flipped that switch a few years 
ago, so

a lot of things that broke with ThinLTO are now fixed.

The FreeBSD memcpy / memset implementations look like they’re slower than 
the

latest ones, which can give a 5-10% perf boost on some workloads.  LLVM just
landed the automemcpy framework, which is designed by some Google folks to
synthesises efficient memcpy implementations tailored to different 
workloads.


FreeBSD often wins versus glibc-based distros because jemalloc is faster 
than

dlmalloc (the default malloc implementations in FreeBSD libc and glibc,
respectively).  I’ve been using snmalloc in my libc for a while and it 
generally
gives me a few percent more perf.  Unfortunately, FreeBSD decided to expose 
all of
the jemalloc non-standard functions from libc, which means I can’t 
contribute it
to upstream without implementing all of those on top of snmalloc or it would 
be an

ABI break.

It would be great if someone could pick up the Phronix benchmark suite and 
do some

profiling: where is FreeBSD spending more time than Linux?  Are there
Linux-specific code paths that hit slow paths on FreeBSD and fast paths on 
Linux

that could have FreeBSD-specific fast paths added (e.g. futex vs _umtx_op)?
I think everyones (here) making good points on the comparisons made on/at 
Phronix.
But given that the FreeBSD "default" install adds a fair amount of overhead 
to
elicit good feedback for bugs/failures. It makes it a poor candidate (kernel) 
for
comparing performance. Hell, dmesg(8) even throws a warning saying that 
performance

will be encumbered.
If they knew the BSD basics. They might be able to provide a more meaningful 
comparison.


I'm going to add Creating a BSD vs Linux comparison to the Foundation 
Sponsored Request/poll
recently posted on some of the mailing lists. It'd be great for 
promotion/advertising/evangelism. :-)


-- Chris


David



On 11 Dec 2021, at 10:17, dmilith .  wrote:

1. Where are compiler options for BSDs?
2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable
fast math in some, and disable it for others?
3. Why they don't mention powerd setup for FreeBSD? By default it may use
slowest CPU mode. Did they even load cpufreq kernel module?
4. Did they even care about default FreeBSD mitigations (via sysctl)
enabled, or it's only valid for Linuxes? ;)
5. What happened to security and environment details of BSDs?

It's kinda known that guys from Phroenix lack basic knowledge of how to do
proper performance testing and lack basic knowledge about BSD systems.
Nothing new. Would take these results with a grain of salt.

On Sat, 11 Dec 2021 at 10:53, beepc.ch  wrote:


I am surprised to see that the BSD cluster today has much worse

performance

than Linux.
What do you think of this?


"Default" FreeBSD install setting are quite conservative.
The Linux common distros are high tuned, those benchmark is in my
opinion comparison of apples and oranges.

Comparing "default" FreeBSD install with "default" Slackware install
would be more interesting, because Slackware builds are at most vanilla.




--
Daniel Dettlaff
Versatile Knowledge Systems
verknowsys.com

Re: 14-current: unable to boot after upgrade (installworld)

[Chris]

On 2021-12-10 08:01, Michael Gmelin wrote:

On 10. Dec 2021, at 16:57, Chris  wrote:

On 2021-12-09 05:36, Sergey V. Dyatko wrote:

Hi,
Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
14-current from git,it looked like this:
1) git pull https://git.freebsd.org/src.git /usr/src
2) cd /usr/src ; make buildworld; make kernel

Not sure you didn't actually do this. But it appears that you omitted a:
make install kernel
here.


`make kernel` does buildkernel and installkernel.

Right you are. I read it as make BUILDkernel. Sorry. :-/


-m



3) shutdown -r now
after that I _successfully_ booted into 14-current and continued with
etcupdate -p
make installworld
etcupdate -B
shutdown -r now
but after that server doesn't come back. After I conneted to this server 
via

IPMI ip-kvm I saw following (sorry for external link):
https://i.imgur.com/jH6MHd2.png
Well. There was a migration to zol between r368473 and current 'main' 
branch so

I decided to install fresh 14-current from snapshot
FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid
possible problems
and again, after make kernel and reboot OS runs, but after installworld I 
ended up

in the same situation
thoughts ?
--
wbr, Sergey


0xBDE49540.asc
Description: application/pgp-keys

Re: 14-current: unable to boot after upgrade (installworld)

[Chris]

On 2021-12-09 05:36, Sergey V. Dyatko wrote:

Hi,

Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
14-current from git,it looked like this:
1) git pull https://git.freebsd.org/src.git /usr/src
2) cd /usr/src ; make buildworld; make kernel

Not sure you didn't actually do this. But it appears that you omitted a:
make install kernel
here.

3) shutdown -r now
after that I _successfully_ booted into 14-current and continued with
etcupdate -p
make installworld
etcupdate -B
shutdown -r now

but after that server doesn't come back. After I conneted to this server via
IPMI ip-kvm I saw following (sorry for external link):
https://i.imgur.com/jH6MHd2.png

Well. There was a migration to zol between r368473 and current 'main' branch 
so

I decided to install fresh 14-current from snapshot
FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid
possible problems

and again, after make kernel and reboot OS runs, but after installworld I 
ended up

in the same situation

thoughts ?

--
wbr, Sergey

Re: problem with re(4) interface

[Chris]

On 2021-11-22 08:47, Chuck Tuffli wrote:

Running on a recent-ish -current
# uname -a
FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT
main-81b22a9892 GENERIC  amd64

I'm having trouble using the second NIC interface in a bridge to provide
network connectivity to bhyve VMs and need some help figuring out what is
wrong.

The system is an AMD Ryzen mini-pc (UM250) with two RealTek gigabit NICs
(8168/8111). The second NIC (re1) is a member of a bridge. A configuration
similar to this works on a different system with Intel NICs, but on this
system, the VMs aren't able to connect to the network. I've done the easy
things and verified, for example, the interface can pass traffic (i.e.
hardware, cable, switch are fine). There are some additional "odd" things.
For example, ifconfig doesn't configure an address or even enable the
interface. E.g.,

# ifconfig re1 10.0.0.10/24 up
# ifconfig re1
re1: flags=8902 metric 0 mtu 1500

options=82099
ether 1c:83:41:28:c9:e4
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29

The command does appear to enable/disable the port:
# tail -f /var/log/messages
Nov 22 08:31:03 stargate kernel: re1: link state changed to DOWN
Nov 22 08:31:11 stargate kernel: re1: link state changed to UP

Note that setting the interface's address from rc.conf works, but after the
system boots, setting the address from the command line doesn't. What else
should I check?

# ifconfig -a -G lo
re0: flags=8843 metric 0 mtu 1500

options=8209b
ether 1c:83:41:28:c9:e3
inet 192.168.5.10 netmask 0xff00 broadcast 192.168.5.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29
re1: flags=8902 metric 0 mtu 1500

options=82099
ether 1c:83:41:28:c9:e4
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29
vm-public: flags=8843 metric 0 mtu
1500
ether 46:76:29:af:7b:fa
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143
ifmaxaddr 0 port 5 priority 128 path cost 200
member: re1 flags=143
ifmaxaddr 0 port 2 priority 128 path cost 2
groups: bridge vm-switch viid-4c918@
nd6 options=9
tap0: flags=8943 metric 0
mtu 1500
description: vmnet-freebsd-0-public
options=8
ether 58:9c:fc:10:ff:f6
groups: tap vm-port
media: Ethernet autoselect
status: active
nd6 options=29
Opened by PID 38298


Because there's subtle differences between them; are you using the re driver
from base, or from ports?



--chuck

--Chris

Re: FreeBSD/arm64 becoming Tier 1 in FreeBSD 13

[Chris Stephan]

This is an amazing accomplishment, congrats and appreciation to all those who 
contributed to this effort! Looking forward to all the good things to come out 
of the arm world!

Get Outlook for iOS

From: owner-freebsd-curr...@freebsd.org  on 
behalf of Ed Maste 
Sent: Friday, April 9, 2021 8:23:13 AM
To: FreeBSD Current ; freebsd-arm 
; freebsd-annou...@freebsd.org 

Subject: FreeBSD/arm64 becoming Tier 1 in FreeBSD 13

Summary

FreeBSD will promote arm64 to a Tier 1 architecture in FreeBSD 13.
This means we will provide release images, binary packages, and
security and errata updates. While we anticipate there will be minor
issues with this first release, we believe the port is mature enough
that they can be resolved during the life of FreeBSD 13.

Details

Development efforts on FreeBSD/arm64 (also known as AArch64) started
in 2014, with generous financial and technical support from Arm,
Cavium and the FreeBSD Foundation. FreeBSD 11.0 arrived in October
2016 as the first release with support for the architecture.
Improvements to the kernel, tool chain, userland, and ports and
package infrastructure have been ongoing since that time, with
improvements arriving in each minor and major release.

The FreeBSD base system is ready for the promotion of arm64 to Tier 1,
and the Release Engineering, Security, and Ports teams are prepared to
support the Tier 1 requirements for arm64. Security updates via
freebsd-update now include arm64 support (starting with the FreeBSD
13.0 release candidates).

Required ports infrastructure is in place for arm64 and most ports
build successfully. The project now has several Ampere eMAG systems
acting as package build servers. These machines were obtained through
a combination of FreeBSD Foundation purchases and generous donations
from Ampere.

To support port maintainers who do not have access to arm64 hardware
we will be improving ports CI and testing resources (and this effort
will benefit all architectures). We will also be suggesting one or
more low-cost reference platforms for FreeBSD/arm64.

The guarantees included in Tier 1 status are described in
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.freebsd.org%2Fen_US.ISO8859-1%2Farticles%2Fcommitters-guide%2Farchs.htmldata=04%7C01%7C%7C2713b30cb188456c362a08d8fb5aba94%7C84df9e7fe9f640afb435%7C1%7C0%7C637535714381290774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b%2FuEf1O%2FpOJKq9vq2Cvx3o3t7K1FB%2BtTtTP3%2FcRYldY%3Dreserved=0

In particular, for Tier 1 architectures the project provides release
images, binary package sets, and binary and source updates for
Security Advisories and Errata Notices.

The AArch64 ecosystem’s maturity ensures follow on generations of
hardware. The diversity of offerings, as well as the multiple
generations of hardware shows that the FreeBSD project will benefit
from adding support for this platform. The growth trajectory suggests
this will be a significant portion of the market in the coming years,
and FreeBSD will benefit from tapping into this market with this Tier
1 platform.

(on behalf of core)
___
freebsd-current@freebsd.org mailing list
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-currentdata=04%7C01%7C%7C2713b30cb188456c362a08d8fb5aba94%7C84df9e7fe9f640afb435%7C1%7C0%7C637535714381290774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X4uvGOWbVdDXY5StdEoxT0XxeLC6q3TtHwcAnpFauYw%3Dreserved=0
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD base pkg (packaging) and critical ports build alongside

[Chris]

On 2021-09-29 01:28, FreeBSD User wrote:

Hello,

I use FreeBSD-base packages built on self hosted systems to update 13-STABLE
and CURRENT hosts.  I run into the problem, that the packages of the FreeBSD
base, built via the FreeBSD framework and from most recent 13-STABLE 
sources,
are often oit of synchronisation with our poudriere packaging builders, that 
is

especially true for critical ports with kernel modules, like i915 drm,
virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE 
sources
and probably the API changes more rapidly than those of the appropriate 
builder

hosts for poudriere and since it takes a bunch of days to build a whole
poudriere packages repository, there is often a gap between the revision of 
the

kernel and the port containing kernel modules.

So, the question is: how can I add ports to the building process of the 
FreeBSD

sources tree in the way they get build every time I build the FreeBSD-base
packages alongside the OS?
The simple answer is; by keeping/getting both trees where you want them 
before

you initiate a build.

This is what I do;

Pick some point in time, or in git(1) parlance; hash/revision. I then
git co/clone git hash/revision for both trees.
I then fire off a build for both. Creating $BASE install(s)/images &&
packages. Since I'm subscribed to the freebsd-security-notifications
ML. I get announcements whenever FreeBSD pushes security patches. I then
check the git log for when the patch(s) was/were pushed/committed. Then 
update

the affected tree to that hash/revision, and update the ports tree to
the same place in time. Then build both trees and update the affected
boxes (servers/hosts). You probably will also want to monitor the commit
list (WARNING it's a high volume list) for CVE notices. So as to keep
your ports tree safe. Simply do the same -- update the ports tree that
contains the CVE commit && build up/deploy your packages from it.
Customization (adding ports drivers to your $BASE (src) build:
Simply add
PORTS_MODULES=
to your make.conf(5). For instance; your i915 driver.

That pretty much covers it I think. :-)

See also; man make(1) man make.conf(5) && man ports(7)

HTH

--Chris


Thanks in advance,

oh


0xBDE49540.asc
Description: application/pgp-keys

Re: [HEADSUP] making /bin/sh the default shell for root

[Chris]

On 2021-09-23 09:40, Rodney W. Grimes wrote:


Quoting Miroslav Lachman <000.f...@quip.cz>:

> On 22/09/2021 22:50, grarpamp wrote:
>>> propose to make it the default shell for root starting FreeBSD 14.0-RELEASE

...


Whoever wants is free to add other users with root pemissions is free
to do so.


That is a zero sum argument.  Ie, same can be said about those who
wish to have the current default changed.  Changing that default is
actually going to require NEW special casing of any code that expects
the now 30+ year default.  Those who DO like it changed, have already
made changes to have it changed, so changing the default only adds
to work for both parties, to me a net loss.

^
I'm well inclined to agree here. But my past expressions of such have
been largely been ignored. In *this* case; it's not a big affect for me;
as I roll out all my updates from build farms. So all my users are already
predefined, and their dot files are preserved. But still,
more changes == more work. :-(

Out of curiosity; has anyone actually done a real assessment to determine
the *actual* value of this (proposed) change? I mean in the end, do we
really know the cost to loss ratio?

--Chris


Leave the defaults alone, provide tools and such to make it easier
for people to tweak those defaults on install.  Stop adding work
to both the people who like how it is now, and people who like
the idea of this change, its not productive for anyone.



Rolf M Dietze


0xBDE49540.asc
Description: application/pgp-keys

Re: [HEADSUP] making /bin/sh the default shell for root

[Chris]

On 2021-09-23 02:29, Mike Bristow wrote:

On Wed, Sep 22, 2021 at 10:00:49AM -0300, Renato Botelho wrote:

+1 for keeping this behavior on default config


-1 for this.

Things should be as default-as-possible, so that the behaviour of
/bin/sh as root on FreeBSD is unsuprising to someone used to /bin/sh
on other systems or users, because they won't be used to the magic
config.

I have no problem with a section of root's .profile having the
approprate magic commented out so that folk who want this can easily
have it, of course.

OK this bit confuses me.
If you logon as root. Then simply exec vipw(8) and change the default
shell to (t)csh. The .cshrc template will sucked out of /etc/ into /root/
where you'll live happily ever after. No (un)commenting involved. :-)

--Chris


Cheers,
Mike


0xBDE49540.asc
Description: application/pgp-keys

Re: [HEADSUP] making /bin/sh the default shell for root

[Chris]

On 2021-09-23 01:55, Hans Ottevanger wrote:

On 9/22/21 10:36 AM, Baptiste Daroussin wrote:

Hello,

TL;DR: this is not a proposal to deorbit csh from base!!!

For years now, csh is the default root shell for FreeBSD, csh can be 
confusing
as a default shell for many as all other unix like settled on a bourne 
shell

compatible interactive shell: zsh, bash, or variant of ksh.

Recently our sh(1) has receive update to make it more user friendly in
interactive mode:
* command completion (thanks pstef@)
* improvement in the emacs mode, to make it behave by default like other 
shells

* improvement in the vi mode (in particular the vi edit to respect $EDITOR)
* support for history as described by POSIX.

This makes it a usable shell by default, which is why I would like to 
propose to
make it the default shell for root starting FreeBSD 14.0-RELEASE (not 
MFCed)


If no strong arguments has been raised until October 15th, I will make this
proposal happen.

Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!

Best regards,
Baptiste



Hello,

I applaud the proposal to change the default login shell of root to /bin/sh. 
As
you mention the rest of the Unix(-like) world has used a Bourne-like root 
login
shell forever. It is one of the first things I change on a new FreeBSD 
install

anyway.

While there, you could change "Charlie &" in the gecos field to something 
more
sensible, e.g. just "Superuser". I know Charlie is there since 4.2BSD, but 
the
reference to a long forgotten baseball player is probably lost by now. Also, 
a lot
of explanation is often needed when users receive (automated) emails from 
Charlie

Root.

Once the login shell of root has changed to /bin/sh, I do not see any reason 
to
keep toor around. It is there since 4.3BSD, but I don't know anybody who 
uses it
in the long term. Many will just change the login shell of root to a 
Bourne-like

shell right away.

I have experimented a bit with the new usability features of sh in 14.0 and 
I must
say that it was quite a positive experience. I could easily suppress the 
urge to
install and use bash instead of sh. I wonder if the changes (but not the 
ones to
/etc/passwd) could be MFC'd in a few months, once they have matured a bit, 
so they


It was mentioned in the OP this *wouldn't* be MFC'd. An aspect I'm glad to 
hear.


would land in 13.1. As you mention elsewhere in this thread, usage in 
scripts is

not affected by these changes. And for interactive use it could be a POLA
violation, but the astonishment would be a positive one.


--Chris

0xBDE49540.asc
Description: application/pgp-keys

Re: [HEADSUP] making /bin/sh the default shell for root

[Chris]

On 2021-09-22 12:26, Marek Zarychta wrote:

W dniu 22.09.2021 o 19:46, Warner Losh pisze:

On Wed, Sep 22, 2021 at 9:35 AM John Baldwin  wrote:


On 9/22/21 1:36 AM, Baptiste Daroussin wrote:

Hello,

TL;DR: this is not a proposal to deorbit csh from base!!!

For years now, csh is the default root shell for FreeBSD, csh can be

confusing

as a default shell for many as all other unix like settled on a bourne

shell

compatible interactive shell: zsh, bash, or variant of ksh.

Recently our sh(1) has receive update to make it more user friendly in
interactive mode:
* command completion (thanks pstef@)
* improvement in the emacs mode, to make it behave by default like other

shells

* improvement in the vi mode (in particular the vi edit to respect

$EDITOR)

* support for history as described by POSIX.

This makes it a usable shell by default, which is why I would like to

propose to

make it the default shell for root starting FreeBSD 14.0-RELEASE (not

MFCed)


If no strong arguments has been raised until October 15th, I will make

this

proposal happen.

Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!


I think this is fine.  I would also be fine with either removing 'toor'
from the
default password file or just leaving it as-is for POLA.  (I would 
probably

prefer removing it outright.)



I think this is also fine. I also think we should remove toor from the
default
password file for one fewer attack surfaces. I strongly prefer this. Users
that want toor can add it to their system and/or provisioning scripts.

Warner



I am curious which attacks you are referring to since I have never heard
of attacks on toor account. I have seen a lot of malware attacking root,
admin, nobody, and other accounts, but never toor.

In the 30 some yrs I've been on UNIX and the likes. I've only ever known
~half a dozen administrators that ever choose toor. Those that want to
continue doing so, will not be prevented from continuing to do so.


TBH toor might be handy as a backdoor account if you are familiar with
FreeBSD enough to take advantage of it. It can also act as an account of
last resort when someone breaks into your system and changes root
password, wipes ssh keys etc, so it cuts both ways, not even mentioning
 POLA.

TBH this is a non-issue. toor is simply an alias to root.
Anyone that has a root hacked system need only spin up the FreeBSD mini
iso/img, mount their hacked system && hack back into shape. :-)

Props to all the work and proposed changes here. Thanks! :-)

--Chris

P.S. This is NOT a bike shed.


The transition from csh to sh as a default root's shell will probably
save some CPU cycles for people using Chef, Ansible, etc thus pushing
FreeBSD toward green computing. Sysadmins bound to csh will be fine
until it remains in the base system and chsh works.

I shouldn't probably post here since I am only a voice from the userbase
but can't help doing so.

Kind regards,


0xBDE49540.asc
Description: application/pgp-keys

Re: [HEADSUP] making /bin/sh the default shell for root

[Chris Stephan]

I completely agree. It will save me the ‘/bin/sh’ at the beginning of each ‘su 
-‘ session. Also, it will simplify building extra small FreeBSD images, 
allowing an easier removal of ‘csh’.

I use csh from time to time, but I do wish it would take a much more explicit 
action so my brain has switched over to ‘csh mode’. I won’t lie that I’ve 
pasted script into my terminal and spent time troubleshooting why the commands 
didn’t work only to realize I forgot to change to /bin/sh first.

Chris Stephan

Sent from FreeBSD

From: owner-freebsd-curr...@freebsd.org  on 
behalf of Baptiste Daroussin 
Sent: Wednesday, September 22, 2021 3:36:45 AM
To: curr...@freebsd.org ; a...@freebsd.org 

Subject: [HEADSUP] making /bin/sh the default shell for root

Hello,

TL;DR: this is not a proposal to deorbit csh from base!!!

For years now, csh is the default root shell for FreeBSD, csh can be confusing
as a default shell for many as all other unix like settled on a bourne shell
compatible interactive shell: zsh, bash, or variant of ksh.

Recently our sh(1) has receive update to make it more user friendly in
interactive mode:
* command completion (thanks pstef@)
* improvement in the emacs mode, to make it behave by default like other shells
* improvement in the vi mode (in particular the vi edit to respect $EDITOR)
* support for history as described by POSIX.

This makes it a usable shell by default, which is why I would like to propose to
make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed)

If no strong arguments has been raised until October 15th, I will make this
proposal happen.

Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!

Best regards,
Baptiste

Re: Building multiple kernels with "make release"

[Chris]

On 2021-07-28 10:11, Alan Somers wrote:

Is it possible to build multiple different kernels and include them all in
a release image?  release.conf says so.  But from experiment, what I see is
that:

* release.sh does pass both kernels in the KERNCONF variable to "make
buildkernel"
* "make buildkernel" dutifully builds both
* BUT, "make installkernel" only installs the first kernel and ignores the
rest
* Only the first kernel ends up in the final image
* It's not really clear where an alternate kernel should go, anyway.

FWIW
For me, the way I've always accomplished this was via the DESTDIR keyword
for kernels. Probably not the most elegant, or maybe even the "correct"
way. But It's something figured out a good while ago and since it worked. I
continue to use it. Maybe it'll work for you.

HTH

--Chris

Probably someplace like /boot/kernel.debug , but release.conf doesn't
provide a way to specify that.

So is the "multiple kernels in release.conf" feature unfinished?  If so,
does anybody have a good idea about the best way to finish it?

https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32

-Alan


0xBDE49540.asc
Description: application/pgp-keys

Re: storcli: howto crossflash Fujitsu PRAID400i to LSI3008 HBA?

[Chris]

On 2021-06-23 08:15, Mathieu Chouquet-Stringer wrote:

Hello,

On Wed, Jun 23, 2021 at 01:04:59PM +0200, O. Hartmann wrote:
I have a bunch of Fujitsu PRAID400i Controller from some servers we switch 
to
FreeBSD driven systems and ZFS. I will not use RAID controllers with ZFS so 
I
tried to cross flash these controllers, but without any success. The DOS 
tools

I use produce on several mainboards a PAL error. The motherboard's UEFI I
uitilise doesn't provide a UEFI shell, so at that point it seems I'm stuck. 
I
found the FreeBSD port storcli, but the tool doesn't crossflash - or it 
doesn't

reveal its magic knobs to do so.


You can download an UEFI shell online and use it to boot on a USB
thumbstick or something.

https://github.com/tianocore/edk2/tree/UDK2018/ShellBinPkg/UefiShell

I've used that in the past to update multiple IBM M1215 and a 9400-8i8e.

Yes that's true. But the tools provided by the different vendors are
unreasonably particular about their environment. So I've found that
"one size does not fit all". :-( But who knows? Maybe it'll work?

--Chris

Re: storcli: howto crossflash Fujitsu PRAID400i to LSI3008 HBA?

[Chris]

On 2021-06-23 04:04, O. Hartmann wrote:

Hello out there.

I have a bunch of Fujitsu PRAID400i Controller from some servers we switch 
to
FreeBSD driven systems and ZFS. I will not use RAID controllers with ZFS so 
I
tried to cross flash these controllers, but without any success. The DOS 
tools

I use produce on several mainboards a PAL error. The motherboard's UEFI I
uitilise doesn't provide a UEFI shell, so at that point it seems I'm stuck. 
I
found the FreeBSD port storcli, but the tool doesn't crossflash - or it 
doesn't

reveal its magic knobs to do so.

The sas3flash FreeBSD binary imag from Broadcom
https://www.broadcom.com/products/storage/host-bus-adapters/sas-9300-8i

doesn't recognize the test adapter (the adapters seem to have different 
stages

of firmware brandings, some from 2015 do have Avago, other, newer from 2019,
seem to be branded with Broadcom):

pciconf -lvbc

mrsas0@pci0:1:0:0:  class=0x010400 rev=0x02 hdr=0x00 vendor=0x1000
device=0x005f subvendor=0x1734 subdevice=0x1211
vendor = 'Broadcom / LSI'
device = 'MegaRAID SAS-3 3008 [Fury]'
class  = mass storage
subclass   = RAID
bar   [10] = type I/O Port, range 32, base 0xe000, size 256, enabled
bar   [14] = type Memory, range 64, base 0xfb30, size 65536, enabled
bar   [1c] = type Memory, range 64, base 0xfb20, size 1048576, 
enabled

cap 01[50] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 10[68] = PCI-Express 2 endpoint max data 256(4096) FLR NS
 max read 512
 link x4(x8) speed 8.0(8.0) ASPM disabled(L0s)
cap 05[a8] = MSI supports 1 message, 64 bit, vector masks
cap 11[c0] = MSI-X supports 97 messages, enabled
 Table in map 0x14[0xe000], PBA in map 0x14[0xf000]
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0019[1e0] = PCIe Sec 1 lane errors 0
ecap 0004[1c0] = Power Budgeting 1
ecap 0016[190] = DPA 1
ecap 000e[148] = ARI 1

The sas3flash utility reports:

# /tmp/Installer_P16_for_FreeBSD/sas3flash_freebsd_amd64_rel/sas3flash
Avago Technologies SAS3 Flash Utility
Version 17.00.00.00 (2018.04.02)
Copyright 2008-2018 Avago Technologies. All rights reserved.

No Avago SAS adapters found! Limited Command Set Available!
Finished Processing Commands Successfully.
Exiting SAS3Flash.



Does anyone have had success on flashing this type of SAS controller from IR
firmware to IT firmware?
I've done a bunch of variously branded 6Gb, and 12Gb SAS controllers to turn 
them
into pass(4) devices. It's been about a year and a half since my last 
efforts. So
my memory may be a bit off. But I did have problems a couple of times like 
you and
I was able to overcome it by using a different motherboard. IOW some did well 
in
DOS whereas some preferred the UEFI UI, and one needed a different UEFI -- a 
real
PITA. I have a stockpile of various flashing utils and notes/procedures from 
both
myself and others. I'll make a tarball out of everything I've got and give 
you a

link (offlist). Maybe something I have will work better that your tools.

HTH

--Chris


Thanks in advance,

oliver

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Chris]

On 2021-06-06 23:49, Graham Perrin wrote:

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original <https://bsd.to/De4n/raw> where the device 
given to swap is:


/dev/gpt/Sea1-08

In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
missing sw
IOW the line MUST read as:

/dev/gpt/Sea1-18noneswapsw  0   0

or

/dev/gpt/Sea1-18noneswapsw,trimonce 0   0

as appropriate for the media referenced.

--Chris

Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!

[Chris]

On 2021-05-13 02:49, Henri Hennebert via freebsd-current wrote:

On 5/13/21 6:00 AM, Marc Veldman wrote:



On 12 May 2021, at 20:49, Henri Hennebert  wrote:

On 5/12/21 8:01 PM, Marc Veldman wrote:

On 12 May 2021, at 18:06, Henri Hennebert  wrote:

On 5/12/21 5:04 PM, Marc Veldman wrote:
Unfortunately I can only say “me too”, but on a different Lenovo 
laptop.
I’ve put my diagnostics in this thread, with the SVN revision in which 
it seems to have broken.

https://docs.freebsd.org/cgi/getmsg.cgi?fetch=327822+0+archive/2020/freebsd-current/20201227.freebsd-current


I your first message on the thread I see

"mmc0: detached"

do you have the previous lines of the dmesg?


This is what I can see on the display:
(Copied by hand, so there might be some typos)
pcib2:  at device 28.2 on pci0
pci2:  on pcib2
pci2:  at device 0.0 (no driver attached)
pcib3:  at device 29.0 on pci0
pci3:  on pcib3
vgapci1:  port 0xd000-0xd07f mem 
0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at 
device 0.0 on pci3

isab0:  at device 31.0 on pci0
isa0:  on isab0
pci0:  at device 31.2 (no driver attached)
hdac0:  mem 
0xf424-0xf4243fff,0xf423-0xf423 at device 31.3 on pci0
em0:  mem 0xf420-0xf421 at device 31.6 on 
pci0

em0: Using 1024 TX descriptors and 1024 RX descriptors
em0: Using an MSI interrupt
em0: Ethernet address: 54:ee:75:cb:0d:e3
em0: netmap queues/slots: TX 1/1024, RX 1/1024
acpi_tz0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 
14.0.

psm0: model Synaptics Touchpad, device ID 0
battery0:  on acpi0
battery1:  on acpi0
acpi_acad0:  on acpi0
orm0:  at iomem 0xc-0xc pnpid ORM on isa0
hwpstate_intel0:  on cpu0
hwpstate_intel1:  on cpu1
hwpstate_intel2:  on cpu2
hwpstate_intel3:  on cpu3
Timecounters tick every 1.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)


Do you see an rtsx message before this mmc0 ?


mmc0: detached
ugen0.1: <0x8086



Yes.
rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem 
0xf410-0xf4100fff at device 0.0 on pci1>

rtsx0: Card present
mmc0:  on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent


The "card present" and just after the iterrupt and "card absent" seems 
strange...

I've been following this thread for awhile.
Doesn't this look like an interrupt sharing/storm problem?
MSI vs MSI-X maybe?

Just thought I'd throw that out.

--Chris


Can you please show the dmesg after a warm reboot with no card inserted.


pcib2:  ad device 28.2 on pci0
… (continue as above, with panic)

Note: The card is not inserted.



XHCI root HUB> at usbus0
Fatal trap 9: general protection fault while in kernel mode
cupid = 3; apic id = 03
….
….
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.


This remind me of a case of rebooting FreeBSD after a window session.
I will check in my mail archive...

Thank you for your time


Best regards,

Marc Veldman


___
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: Patch for patch, but not foreach :-)

[Chris]

On 2021-05-07 14:10, Michael Gmelin wrote:
What about using "."? Or "/" (which would match the muscle memory of 
"search" in

less/more/vi/some browsers)?

+1
I really like that idea.

--Chris


-m


On 7. May 2021, at 23:05, Maxim Sobolev  wrote:

Replace '*' with ^T perhaps and catch SIGINFO? 樂

-Max


On Fri., May 7, 2021, 10:11 a.m. Shawn Webb, 
wrote:


On Fri, May 07, 2021 at 03:49:00PM +0200, Hans Petter Selasky wrote:
Time has come that I make a patch for the most central patching tool in
FreeBSD, patch :-)

https://reviews.freebsd.org/D30160


As stupid as it sounds, '*' is a valid filename.

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD


https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


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

___
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: should bsdinstall work?

[Chris]

On 2021-05-04 18:58, tech-lists wrote:

Hi,

On Tue, May 04, 2021 at 04:35:17PM -0400, Nathan Whitehorn wrote:


Where are you trying to install
to? Usually the assumption is that the microsd images *are* the
installed system rather than a tool you use to install a system.


I'm trying to install -current (or stable/13 or releng/13.0) to a
bootable usb3-connected external hd on raspberry pi 4 hardware. The goal
is to have this pi booting without microsd to a root-on-zfs system.

I have used raspios 64-bit to update its firmware and configured it so
it tries to boot the microsd card and if this fails, boots to usb3. Took
out that card, wrote
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210415-14d0cd7225e-246078.img
to another and booted it, then ran bsdinstall and selected the external
hd. The install fails to progress beyond the point I mentioned.

Maybe another wau of doing it would be to just write
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210415-14d0cd7225e-246078.img
to the hd from my freebsd desktop. Would that method be expected to
work? The thing is, I want root-on-zfs *and* booting with no microsd.
Just writing the .img to the hd would mean i'd have to abandon zfs.

Doesn't bsdinstall allow choosing different means of fetching the
dist files? Last I remember using it, I was able to choose ftp http(s),
etc... Making, or using an already matched MANIFEST is fairly trivial.
You could obtain your desired base files and create or use the one
with it. Then point bsdinstall to somewhere to get them. If you need
a remote. I could give you one to use.

HTH

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

clean update 12.2 > 13.0

[Chris]

Wow.. Best update I have done in years. At least for me 12.2 > 13.0 was 
great.  Great job !

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

clean update 12.2 > 13.0

[Chris]

Wow.. Best update I have done in years. At least for me 12.2 > 13.0 was 
great.  Great job !


___
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: NFS issues since upgrading to 13-RELEASE

[Chris Roose]

> Does anything change if you set -tso -lro on the serving NIC on your
> FreeBSD server side?  Do the Linux clients remain responsive then?

Thank you, Jason. This seems to have cleared the problem up for me. 
Since disabling TSO and LRO on the server NIC last night, I haven't seen 
any timeouts.


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

NFS issues since upgrading to 13-RELEASE

[Chris Roose]

I posted this in -questions and someone suggested I post here as well.

I'm having NFS availability issues between my Proxmox client and FreeBSD server 
(10G link) since upgrading to 13-RELEASE. And unfortunately I upgraded my ZFS 
pool to v2.0.0 before I noticed the issue, so I'm kind of stuck.

Periodically, the NFS server (I've tried both v3 and v4.2 clients) will go 
unresponsive for several minutes. I never had this problem on 12.2, and as far 
as I can tell it's not a disk or network I/O issue. I'll get several "nfs: 
server not responding, still trying" messages on the client and a few minutes 
later it usually recovers. It's not clear to me yet what's causing the block. 
Restarting nfsd on the server will resolve the issue if it doesn't clear itself.

Any pointers for troubleshooting this? I've been looking through vmstat, gstat, 
top, etc. when the problem occurs, but I haven't been able to pinpoint the 
issue. I can get pcap, but it would be from the hosts, because I don't have a 
10G tap or managed switch.

-- 
Chris
___
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: [Bug 254395] bsdinstall: fail script install after BETA3

[Chris]

On 2021-03-19 15:55, Warner Losh wrote:

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:




> On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
>
> Chris wrote:
>> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>>
>>> Nathan Whitehorn  changed:
>>>
>>>What|Removed |Added
>>>

>>>
>>>Severity|Affects Only Me |Affects Some People
>>>  CC||i...@freebsd.org
>>>Priority|--- |Normal
>>>
>>> --- Comment #6 from Nathan Whitehorn  ---
>>> Thanks for the suggestion about the documentation -- I've updated the
>>> man page.
>>>
>>> The core problem here is that our tar can't extract archives to FAT32
>>> with
>>> default options, since it treats inability to set modification time as
>>> a fatal
>>> error and FAT32 doesn't let you do that on the root directory. As
>>> such, any
>>> file in the release tarballs can't be extracted to FAT32. For
interactive
>>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>>> libarchive, solves this by ignoring ctime/mtime errors.
>>>
>>> Some extra commentary on solutions, so it can be in one place.
>>> Possibilities
>>> are:
>>>
>>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>>> base.txz, solving this issue, but will result in it not being in
>>> mtree. It will
>>> also leave in place an identical bug that will break scripted
>>> installation on
>>> bare-metal POWER8 and POWER9 systems, although that is a tier-2
platform.
>>>
>>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>>> like the
>>> interactive installer uses. This has the difficulty that the patch is
>>> hacky and
>>> would have to go through upstream.
>>>
>>> 3. We go back to using distextract for scripted installations as well
as
>>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>>> This
>>> fixes this issue but will result in installation failures for scripted
>>> installs
>>> without a controlling tty. (It will also add nice progress bars to
>>> scripted
>>> installs).
>>>
>>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>>> afterward. This is incredibly hacky and otherwise essentially
>>> functionally
>>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>>> functional
>>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>>> broken.
>>>
>>> 5. We patch the file system driver to (pretend to) allow setting times
>>> on the
>>> mount point. I don't want to do this, since I don't want to solve this
>>> in the
>>> kernel at RC3 and I don't like it pretending to do things it can't do.
>>
>>  6. (my favorite) do NOT require that the efi/ partition be in strictly
a
>>  fat32 format. I mean fat32 is not strictly required as the format for
>> the efi
>>  partition. It is simply _assumed_ to be the required format and as
>> such, the
>>  one used in so many cases.
>
> Wrong, see "13.3 File System Format" in UEFI specification.
>

it is not as simple as that:)


13.3.1.1 is more specific:
=
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the
EFI file system. What variant of EFI FAT to use is defined by the size of
the media. The rules defining the relationship between media size and FAT
variants is defined in the specification for the EFI file system.



We've also seen a few non-conformant systems where FAT12 support has been
removed, so there's also a bit of real-world experience that goes along
with reading the UEFI specification :(.

I suppose that may be part of where my understanding came from. I've
got a couple of "hackintoshes" that dual-boot OS X, and FreeBSD. Part of
the process was working with the EFI partition (ESP) to get recognition
of both OS's in the (EFI) boot menu, as well as getting the firmware
properly functional in both instances. I also draw from a long article
by a boot manager author whom insisted that fat32 was not a requirement.
I've not got the time ATM to dig up the article. But it had many pointers
to the EFI spec to prove the point. All of which I verified.
In any case, sorry for the noise if I'm wrong. I'll dig up my references
when I can find the time. :-)

--Chris


Warner

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:

___
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: [Bug 254395] bsdinstall: fail script install after BETA3

[Chris]

On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Nathan Whitehorn  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People
 CC||i...@freebsd.org
   Priority|--- |Normal

--- Comment #6 from Nathan Whitehorn  ---
Thanks for the suggestion about the documentation -- I've updated the man 
page.


The core problem here is that our tar can't extract archives to FAT32 with
default options, since it treats inability to set modification time as a 
fatal

error and FAT32 doesn't let you do that on the root directory. As such, any
file in the release tarballs can't be extracted to FAT32. For interactive
installations, the bsdinstall distextract tool, a CURSES-y frontend to
libarchive, solves this by ignoring ctime/mtime errors.

Some extra commentary on solutions, so it can be in one place. Possibilities
are:

1. We drop /boot/efi from mtree. That will result in it not existing in
base.txz, solving this issue, but will result in it not being in mtree. It 
will
also leave in place an identical bug that will break scripted installation 
on

bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.

2. We add an option to tar to ignore failure in setting ctime/mtime, like 
the
interactive installer uses. This has the difficulty that the patch is hacky 
and

would have to go through upstream.

3. We go back to using distextract for scripted installations as well as
interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7. This
fixes this issue but will result in installation failures for scripted 
installs

without a controlling tty. (It will also add nice progress bars to scripted
installs).

4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
afterward. This is incredibly hacky and otherwise essentially functionally
equivalent to #1. Like #1, it will fix this issue and has no obvious 
functional

downside, but leaves scripted installs bare-metal POWER8 and POWER9 broken.

5. We patch the file system driver to (pretend to) allow setting times on 
the
mount point. I don't want to do this, since I don't want to solve this in 
the

kernel at RC3 and I don't like it pretending to do things it can't do.


 6. (my favorite) do NOT require that the efi/ partition be in strictly a
 fat32 format. I mean fat32 is not strictly required as the format for the 
efi

 partition. It is simply _assumed_ to be the required format and as such, the
 one used in so many cases.

Whould it actually be that much harder to use ffs/ufs?

You asked. ;-)





Of these, 1, 3, and 4 are quite easy to implement, but all have some 
downside.

My temptation is to do 4 for 13.0, since it will definitely work but is just
lame, then either do #2 or a variant on #3 where distextract notices there 
is

no tty and doesn't try to set up a dialog as a longer-term fix in HEAD. Any
thoughts?

___
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: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[Chris]

On 2021-03-17 05:18, Gary Jennejohn wrote:

On Wed, 17 Mar 2021 05:08:50 -0700
David Wolfskill  wrote:


My laptop is currently running main-n245489-15b82e00a164; after updating
sources to n245498-096a84721670, I am performing a source-based update.

A simialr update on my build machine (which is headless, and thus does
not use anything related to X11) was successful.

The laptop is set up to rebuild x11/nvidia-driver when the kernel
is updated.

The buildkernel step on it fails with:

...
awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | 
xargs -J% objcopy % nvidia-modeset.ko

===> lib (all)
===> lib/libglvnd (all)
...
===> x11/driver (all)
===> x11/extension (all)
===> doc (all)
make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")

make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc

*** Error code 1

Stop.


On reviewing the list of files changed in 15b82e00a164..096a84721670, I
note a couple of promising-looking candidates:

 share/mk/bsd.opts.mk|   1 +
 share/mk/src.opts.mk|   1 -

Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
recent entry is:

| commit 6827435548d257c672f934db5c6ff01012d96995
| Author: Jung-uk Kim 
| Date:   Tue Mar 16 14:16:10 2021 -0400
|
| pkgbase: Fix building out-of-tree manual pages
|
| c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
| building out-of-tree manual pages.  For example, x11/nvidia-driver 
fails

| with the following error:
|
| ===> doc (all)
| make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")

| make[3]: Fatal errors encountered -- cannot continue
|
| Move the definition from src.opts.mk to bsd.opts.mk to make it 
visible.


which looks ... apropos.

Indeed, it appears that the n245494-6827435548d2 change was intended to
fix the issue that I am now just seeing.

But I readily confess that I have neither familairity nor expertise
with share/mk/* (and that delving into it reminds me of "You are
in a mazy twist of passages, all different")

So...  help?  What do I need to do to be able to build the kernel now?

(E.g., if I need to just skip building x11/nvidia-driver once, get
everything installed, then build "normally" (with x11/nvidia-driver)
-- that's fine; I just need a clue.)



For me trying to build nvidia-driver along with the kernel always fails
miserably.

+1 for me too. I didn't _used_ to have this problem. But when I hit it.
I simply modified my procedure (as you), and never looked back.



My tree is at 096a8472167..c96151d3350  main.

Building the kernel on its own followed by building nvidia-driver in
the ports tree worked for me with no problems (but I didn't install
either one of them yet).

--Chris
___
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: ThinkPad: reboots after successful shutdown -p

[Chris]

On 2021-03-17 00:01, Xin Li via freebsd-current wrote:

On 3/16/21 9:45 PM, Warner Losh wrote:



On Tue, Mar 16, 2021 at 10:18 PM Xin Li mailto:delp...@freebsd.org>> wrote:

On 11/17/19 23:14, 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 a FreeBSD
> issue, but it seems that the Windows 10 installation doesn't have the
> problem, so I guess there might be some difference between our and
> Windows's shutdown sequence.

I've found a workaround for this, for the record, setting
hw.efi.poweroff=0 would make the laptop to correctly shutdown.

However I don't see anything wrong with sys/dev/efidev/efirt.c's
implementation of EFI shutdown; it appears to be essentially the same 
as

implemented in command_poweroff() in stand/efi/loader/main.c, but
'poweroff' would work just fine in loader.efi.

Can someone familiar with the code shed me some light here? :-)

It looks like what Linux did was to prefer ACPI S5, unless it's not
available or the system have HW_REDUCED flag in FADT, so if we do
something similar it would fix the issue for me, but according to
bugs.freebsd.org/233998 <http://bugs.freebsd.org/233998> that's not
the case for at least Conor's system
(_S5 appears to be in the ACPI dump), so I think it's something else...


For me, interrupt storm on shutdown has been the causes of issues like
this...

Any chance you can eliminate that as a possibility?


Hmm, that's a good question -- is there a way to tell after the screen
was turned off?

Before the screen was turned off, there doesn't appear to be interrupt
storm.  The system was performing a typical FreeBSD shutdown procedure:
All buffers synced, showed uptime, destroyed GELI devices, spin down the
SATA devices, shutdown the cardreader (rtsx0), detached all USB devices
(hidraw1, hidbus, usbhid1, ubt0, uhub0), screen turned slightly red for
a very brief period (maybe side effect of turning off the backlight),
then goes off.

I think most of FreeBSD drivers would turn off interrupt from the device
before detaching, but I haven't looked into all of my devices; but from
what I have seen on screen (captured a 60fps video and can share if that
helps), there doesn't appear to be an interrupt storm before that.

Cheers,

FWIW this also happened to me a few weeks ago after a fresh install.
I've since wiped the disk and repurposed the hardware. So I can't now
reproduce it. But it wasn't a laptop. So it's not isolated to them.
Sorry I can't offer anything more. I just wanted to mention this to
indicate that it's not a _too_ terribly isolated case. It was Intel
CPU/graphics. In case that says anything to anyone. If it matters,
I can get/offer more info on the hardware.

--Chris

P.S. Sorry about my last response. My MUA seems to be acting up this AM. :/
___
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: Rationalizing sed -i/-I (in-place editing) argument handling

[Chris]

On 2021-03-08 12:13, Ed Maste wrote:

A relatively minor but longstanding incompatibility between FreeBSD
and many other systems is the way sed handles backup files for
in-place editing -- sed's -I and -i options. GNU sed and other BSDs
accept an optional argument: -I.bak will save a backup file with a
.bak extension, and -I with no argument will not create a backup file.
FreeBSD currently accepts either -I.bak or -I .bak to save a backup
with the given extension, and -I "" (an empty argument) to specify no
backup.

I've been tripped up by this in the past and I know many others have.
Most recently tobik@  filed PR 254091 for this. Now, I think a single
change to make -i/-I to be compatible with other sed implementations
in one step is too much of a POLA violation, but I think it can
reasonably be done in stages:

1. Update the man page to indicate that -i/-I should not have a space
between the flag and the extension. This is compatible with current
FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below.
No backup is still a special case and remains as -I "".

I've opened https://reviews.freebsd.org/D29128 with proposed man page 
changes.


2. Continue accepting -I .bak, but emit a warning suggesting the use
of -I.bak instead.

3. Change -I/-i to getopt optional arguments, but keep a special case
for -I/-i "". At this point -I .bak becomes invalid as with other
seds, and specifying no backup can be done with either -I "" or -I
with no argument. This relies on an empty argument having no other
sensible interpretation.

4. Continue accepting -I "" to specify no backup, but emit a warning
suggesting the use of -I with no argument.

5. Retire the special case for -I "".

These steps could be done over an extended period of time (such as one
major release to another) - this is most important between steps 2 and
3.

Please let me know what you think, and if there's something I've missed.

+1
This seems more than a reasonable course of action. :-)
Thanks!
___
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: Waiting for bufdaemon

[Chris]

On 2021-03-05 15:33, Yasuhiro Kimura wrote:

From: Konstantin Belousov 
Subject: Re: Waiting for bufdaemon
Date: Fri, 5 Mar 2021 22:43:58 +0200


My belief is that this commit helps more users than it hurts.  Namely,
the VMWare and KVM users, which are majority, use fast timecounter,
comparing to the more niche hypervisors like VirtualBox.

For you, a simple but manual workaround, setting the timecounter to
ACPI (?) or might be HPET, with a loader tunable, should do it.


Then please let me know the name of it.

I have experienced same situation several time. That is, I faced a
problem and asked for it on ML. Then I was told to try some tunable.
So I thought there may be tunable that can be used as workaround in
this case. But for those who isn't familiar with kernel internal, it
it quite hard to find it without knowing its name. If all tunable were
listed with brief explanation in one document, then I saw it and could
pick up possible candidates.

Not exactly what you're asking for. But sysctl sysctl(3) and loader(8)
will provide some good clues.

HTH

--Chris

But actually they are documented
separately among many man pages. So the first difficulty is to find
man page in which possible tunable may be explained. If the problem is
releted to some device, it is most hopeful to check its man page. But
in this case, even after reading the commit message, I had no idea
which man page to check.

---
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: freebsd.org ftp site throws BOGUS cert

[Chris]

On 2021-03-04 10:36, Pete Wright wrote:

On 3/4/21 10:20 AM, Chris wrote:

This post probably belongs on a different list that I am not
subscribed to. But...



The appropriate list is freebsd-hubs@
https://lists.freebsd.org/mailman/listinfo/freebsd-hubs


I can't get to the freebsd ftp sites because the cert(s) appear
to be bad:

https://ftp0.tuk.freebsd.org/



they should be able to track down the owner of that site, it looks like the 
TLS

cert is valid for download.freebsd.org:
* Server certificate:
*  subject: CN=download.freebsd.org
*  start date: Feb 14 20:17:20 2021 GMT
*  expire date: May 15 20:17:20 2021 GMT
*  subjectAltName does not match ftp0.tuk.freebsd.org


download.freebsd.org may actually be the preferred method for accessing 
resources
on this system.  For example if geo-loadbalancing is used.  anywho - the 
people on

the above mailing list would know best.

Thanks, Pete! :-)

--Chris


-p

___
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.org ftp site throws BOGUS cert

[Chris]

This post probably belongs on a different list that I am not
subscribed to. But...

I can't get to the freebsd ftp sites because the cert(s) appear
to be bad:

https://ftp0.tuk.freebsd.org/

Unable to communicate securely with peer:
requested domain name does not match the server’s certificate.

HTTP Strict Transport Security: false
HTTP Public Key Pinning: false

Certificate chain:
-BEGIN CERTIFICATE-
MIIGPjCCBSagAwIBAgISBBaBf3jeye5v9zUnQI3QN4yxMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
...
SIXhu4zwerpxm3yKILymYibvj3QaNHaT22DpwXHtj53zimd7tcWD+VSAxAulR1lf
ujwDIeQCXmf5EBnYWtI7ieo+3WnogUrAGyRVo+aY1LyLpLFUegYO1yVzb4sWD4PI
PFc9yRDaZlkS9aGL6ySB01+E
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
...
O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw
UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg==
-END CERTIFICATE-

Please update or provide a solution.

Thanks!

--Chris
___
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: freebsd-update(8) without an echo of "You must be root to run this."

[Chris Rees]

Hey,

On 16 February 2021 08:53:29 GMT, Graham Perrin  wrote:
><https://cgit.freebsd.org/src/tree/usr.sbin/freebsd-update/freebsd-update.sh?id=48ffe56ac5b7adb5b851d32be12b2ec0f13705a4#n555>
>
>         echo "You must be root to run this."
>
>Below: is this my PEBKAM, or (with a system that is preconfigured to 
>deny login as root) _should_ there be an echo of the requirement to run
>
>as root?
>
>
>
>mowa219-gjp4-vm-hellosystem-eol-freebsd% su -
>Password:
>su: Sorry
>mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo grep LOCKED 
>/etc/master.passwd
>root:*LOCKED*:0:0::0:0:Charlie &:/root:/bin/csh
>mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo freebsd-update upgrade -r

Sudo means that you are root.  *LOCKED* just disables the root password.

Chris
___
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: using git to get a particular version of src

[Chris]

On 2021-01-25 08:31, tech-lists wrote:

Hi,

I have this version installed:

13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC 2020

I'd like to get the sources for this (want to make a no-debug kernel) as I 
know

this version works on this hardware.

But -current has gone to 14 and what was -current is now 13-stable. What git
incantation is required to get 2ed50808d2b-c254384 sources, given an empty
/usr/src and git method of ssh://anon...@git.freebsd.org ?

I am by *no* means a GIT expert
but will
cd /usr/src
git up 2ed50808d2b
accomplish your intended task?

HTH


thanks,

___
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: Current kernel build broken with linuxkpi?

[Chris]

On 2021-01-13 13:28, Emmanuel Vadot wrote:

On Wed, 13 Jan 2021 16:19:09 -0500
Robert Huff  wrote:



Emmanuel Vadot  writes:

>That's one of the problems of having external kmods.
>drm-current-kmod have the option by default to install it's
>   sources in /usr/local/sys/ and when doing a make buildkernel
>   those sources are getting built too.

That would be the SOURCE option?


 Yes


Further: if I have that set ... does that mean I can remove it
from PORTS_MODULES?


 I don't know what that is

eg;
PORTS_MODULES=x11/nvidia-driver-304
for the nvidia driver, for example. see src.conf(5).



(And I assume a note about this will appear in UPDATING?)


 A note about what ?

 Cheers,



Respectfully,


Robert Huff


___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Chris]

On 2021-01-04 11:13, Marek Zarychta wrote:

W dniu 04.01.2021 o 19:54, Enji Cooper pisze:


On Jan 4, 2021, at 10:49 AM, Marek Zarychta 
 wrote:


…


Terrible idea IMHO, but I am only the weak voice from the userbase.

It's like deprecating old, well-worn hammer in the favour of the nail
gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?


Marek,
	I’m curious: have you used etcupdate before instead of mergemaster? If so 
when? If you ran into issues (UX as well as functional): could you please 
report them on bugs.freebsd.org <http://bugs.freebsd.org/> ?
	etcupdate is a less fragile tool that’s broken my systems less when 
compared with mergemaster.


Dear Enji,

to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
over years. It works fine, but I don't like the idea of editing
conflicted files.

I won't complain about etcupdate(8), but please leave mergemaster(8)
as is. I believe we need both: solid, fast black boxes driven it auto
mode and fragile tools in the base. mergemaser is rather not a potential
security hole in the system.

You might find it in your best interest to adopt (become a maintainer) for
mergemaster(8). This would allow you to fix whatever ailments have arrived
over the years, and better adapt it to work with the newly adopted git(1) SCM
that is now the source of truth for /usr/src. :-)

--Chris


With kind regards,

___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Chris]

On 2021-01-04 10:58, Enji Cooper wrote:

On Jan 4, 2021, at 10:54 AM, Enji Cooper  wrote:


On Jan 4, 2021, at 10:49 AM, Marek Zarychta <mailto:zarych...@plan-b.pwste.edu.pl>> wrote:


…


Terrible idea IMHO, but I am only the weak voice from the userbase.

It's like deprecating old, well-worn hammer in the favour of the nail
gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?


Marek,
	I’m curious: have you used etcupdate before instead of mergemaster? If so 
when? If you ran into issues (UX as well as functional): could you please 
report them on bugs.freebsd.org <http://bugs.freebsd.org/> ?
	etcupdate is a less fragile tool that’s broken my systems less when 
compared with mergemaster.


That reminds me, there is a feature gap (in the last 5~10 years I’ve used
etcupdate) that I forgot about between mergemaster and etcupdate: in 
particular,
mergemaster works when adding/removing new users and groups from 
/etc/passwd* and
/etc/group, respectively, dealing with mtree files, the last time I checked. 
Apart
from that, I don’t see a use for mergemaster (and in which case, the feature 
gap

can be trimmed down/migrated to etcupdate). mergemaster has broken the
configuration of my machines/VMs more than etcupdate has ever and I’ve used 
both

tools for about the same time.

TBH I've continued to use mergemaster simply out of habit, because it was the
recommended/supported way of doing it from UPDATING.
It started acting odd awhile back. So I went to performing
mergemaster -viF
to simply burn through the $Id only changes. Then diff(1)ing the the 2 trees
to create a mega-patch which I could apply. I took that route with the 
intention
of coming back to it to discover what the problem was. But never got around 
to it.

I'm *really* glad this thread came about. Now I can move onto something that
actually works as intended -- assuming /etc/(group|passwd) bits get merged. 
:-)


--Chris


Cheers,
-Enji
___
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: etcupdate failed to build new tree

[Chris]

On 2021-01-01 11:01, Graham Perrin wrote:
At what should have been the end of my first upgrade since the transition to 
git:


cd /usr/src/freebsd-current && make installworld && etcupdate

Ĵ– concluded with a successful installworld, then a few lines about scanning 
and

skipping certificates, then:


Failed to build new tree.


I see the manual page for etcupdate(8) but I'm not sure how to proceed.



I did try `mergemaster -p` and somehow (!) ended up with an empty 
`/etc/group`

file. Dug myself out of that hole, I'll prefer to continue using etcupdate.

For years now I have always initiated a simple failsafe
# cp -Rp /etc /eetc
prior to (build|install) (world|kernel)
because you just never know. ;-)

Happy 20201!

--Chris
___
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: Enabling AESNI by default

[Chris]

On 2020-12-31 11:51, Allan Jude wrote:

We've had the AESNI module for quite a few years now, and it has not
caused any problems.

I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
you need to load aesni.ko'

Userspace crypto that uses openssl or similar libraries is already
taking advantage of these CPU instructions if they are available, by
excluding this feature from GENERIC we are just causing the "out of the
box" experience to by very very slow for crypto.

For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
device:

with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz

fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
--numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
--group_reporting --fallocate=none --runtime=60 --time_based


stock:
write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)

with aesni.ko loaded:
write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)


Does anyone have a compelling reason to deny our users the 5x speedup?

FWIW I'd just like to suggest that I'm a +1 for adding it to GENERIC.
Thanks for suggesting this, and have a Happy New Year!

--Chris
___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Chris]

On 2020-12-29 20:59, Chris wrote:

On 2020-12-29 16:46, John-Mark Gurney wrote:

Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:

 |SolarWinds supply chain attack, being able to smuggle a modified file
 |into a git repo, say an OS's build server, such that the tools don't
 |know the tree is modified is a real problem...

SHA-256 arrives, if you look at the git history.  Until then
signing a git tag even with SHA-1 is better than being unsealed.


Actually, no it is not.  It provides a false sense a security.  SHA-1
should only be used as a checksum (detecting non-malicous corruption)
now.

There's a reason I stopped signing (and even removed the historical
signatures) of the magnet links that I produce for FreeBSD.

This is also why I expanded the snapaid tool to support releases, to
make it extermely easy to verify signatures:
https://www.funkthat.com/gitea/jmg/snapaid


This attack, well, interesting that FreeBSD with so many
developers with ssh push hasn't been soiled more often.  I am


And that is why it isn't a major problem yet, in that there are
additional layers of security, both ssh and https that help
ensure integrity of the repo in transit...


cautious regarding such, there is a tremendous amount of
propaganda against Russia and China going on .. and then who
tapped the cables, who has the budget, hmm.  I have read one US
national security alert report once, and all i could see was


I am well aware of this, and infact, the reason I've been pushing
for better security like this IS because of the actions of the NSA...
I used to get lunch on a weekly basis across the street from one
of the early revealed NSA wiretap rooms.

OK I've been pondering this since last night. If this is a reasonable
concern, and given all that's already gone into coercing git into
something FreeBSD friendly. Is it reasonable to consider putting all
that effort that's already been excreted, and what would need to be
done. To cobble up a FreeBSD version? [tongue-in-cheek]
fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed

face-palm; that was: fuc-git. A failed attempt at wit. :-(
the rest holds true.

that acronym.
Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum.
Better; hmac-sha384, or any of a number of other digests. I'm just
thinking that if everyone pitched in, what with all the other work
that's already been done. It'd all get done on a timeline that wouldn't
leave the FreeBSD repo unsafe.
Mind you; much of this is all conceptual. But I just thought (hoped) it
might be worth while.

--Chris
___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Chris]

On 2020-12-29 16:46, John-Mark Gurney wrote:

Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:

 |SolarWinds supply chain attack, being able to smuggle a modified file
 |into a git repo, say an OS's build server, such that the tools don't
 |know the tree is modified is a real problem...

SHA-256 arrives, if you look at the git history.  Until then
signing a git tag even with SHA-1 is better than being unsealed.


Actually, no it is not.  It provides a false sense a security.  SHA-1
should only be used as a checksum (detecting non-malicous corruption)
now.

There's a reason I stopped signing (and even removed the historical
signatures) of the magnet links that I produce for FreeBSD.

This is also why I expanded the snapaid tool to support releases, to
make it extermely easy to verify signatures:
https://www.funkthat.com/gitea/jmg/snapaid


This attack, well, interesting that FreeBSD with so many
developers with ssh push hasn't been soiled more often.  I am


And that is why it isn't a major problem yet, in that there are
additional layers of security, both ssh and https that help
ensure integrity of the repo in transit...


cautious regarding such, there is a tremendous amount of
propaganda against Russia and China going on .. and then who
tapped the cables, who has the budget, hmm.  I have read one US
national security alert report once, and all i could see was


I am well aware of this, and infact, the reason I've been pushing
for better security like this IS because of the actions of the NSA...
I used to get lunch on a weekly basis across the street from one
of the early revealed NSA wiretap rooms.

OK I've been pondering this since last night. If this is a reasonable
concern, and given all that's already gone into coercing git into
something FreeBSD friendly. Is it reasonable to consider putting all
that effort that's already been excreted, and what would need to be
done. To cobble up a FreeBSD version? [tongue-in-cheek]
fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed
that acronym.
Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum.
Better; hmac-sha384, or any of a number of other digests. I'm just
thinking that if everyone pitched in, what with all the other work
that's already been done. It'd all get done on a timeline that wouldn't
leave the FreeBSD repo unsafe.
Mind you; much of this is all conceptual. But I just thought (hoped) it
might be worth while.

--Chris
___
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: FreeBSD: GitLab

[Chris]

On 2020-12-23 08:52, Warner Losh wrote:

On Wed, Dec 23, 2020 at 9:44 AM Chris  wrote:


On 2020-12-23 07:41, Graham Perrin wrote:
> On 23/12/2020 15:36, Chris wrote:
>
>> … Any plans to incorporate GitLab into any of this?
>
>
> <https://github.com/bsdimp/freebsd-git-docs/search?q=GitLab> ▶
> big-picture.md is
> probably the best starting point.
Brilliant! :)

I mainly asked because GitLab seems to offer a richer toolset IMHO.



The project is publishing many places, and will use features of the places
it publishes as it refines the future workflow. The different
mirroring/hosting services offer different features and it's not yet clear
how we can best utilize them or if even one size fits all.

Sure. I got that following the notes from the search listed above.
Just to be clear; I was *not* suggesting anyone was making any *wrong*
choices here. Just a humble inquiry. :-)

Thanks for taking the time to respond, Warner.


Warner


--Chris
___
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: FreeBSD: GitLab

[Chris]

On 2020-12-23 07:41, Graham Perrin wrote:

On 23/12/2020 15:36, Chris wrote:


… Any plans to incorporate GitLab into any of this?



<https://github.com/bsdimp/freebsd-git-docs/search?q=GitLab> ▶ 
big-picture.md is

probably the best starting point.

Brilliant! :)

I mainly asked because GitLab seems to offer a richer toolset IMHO.

Thanks, Graham!

--Chris



___
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: src: continued use of Subversion for getting updates

[Chris]

On 2020-12-22 23:01, Warner Losh wrote:

On Tue, Dec 22, 2020, 11:47 PM Graham Perrin  wrote:


On 23/12/2020 00:10, Paul Mather wrote:
> … continue to get src updates via Subversion. …

As far as I can tell:

* for stable/12 alone



stable/11 as well as the releng branches for as long as the project has
them under support. I wrote the code to replay commits into subversion for
the convenience of our users on those branches. The 12.x releases will be
built out of Subversion to preserve $FreeBSD$ expansion and other obscure
subversion details that may matter or be disruptive to people using those
branches.

Current has moved entirely to git. New commits have started up again.
Stable/11 and stable/12 are there as well, but there are a couple of last
minute snags that are being sorted out so it will be an additional day,
maybe two before those start. FreeBSD 13 will be entirely from git and will
be branching late winter or early spring if all goes well. Other issues
with git are being sorted our as they arise.

For those using github, migration instructions will be in place once the
changes there are complete. What I've written up is enough for the seasoned
traveler, but lacks a few details that were hosted worked out in the past
days I've not had time to fold in. We hope to have that all sorted out by
Christmas.

This has been a big job with way more moving parts than I'd ever thought
possible. We've attended to most of them, and are fixing the stragglers as
the team becomes aware of them.

On a slight aside;
Any plans to incorporate GitLab into any of this?

--Chris


Warner

* for a limited period.


<
https://github.com/bsdimp/freebsd-git-docs/blob/4833066feda51cc3a907cf7bff1c4344b3edd5c6/big-picture.md#L103
>

In context:
<https://github.com/bsdimp/freebsd-git-docs/blob/main/big-picture.md>

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

___
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: Updating current i386 broke wlan0...

[Chris]

On 2020-12-11 13:07, Jeffrey Bouquet wrote:

On Fri, 11 Dec 2020 10:53:55 -0800, Chris  wrote:


On 2020-12-11 10:32, Chris wrote:
> On 2020-12-11 08:10, Steve Kargl wrote:
>> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
>>> Longtime BSD current user, due to several constraints I had to update from
>>> a recent dec 10 image in
>>> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current
>>> to 13-Current except
>>>   service netif onestart wlan0 up
>>> no longer completes.
>>> 
>>> /etc/rc.d/netif set_rcvar_obsolete: not found
>>> eval: wlan_up: not found
>>> starting wpa_supplicant
>>> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
>>> starting dhclient
>>> eval: wlan0: not found
>>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
>>> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see
>>> rc.conf(5)
>>> starting network wlan0
>>> eval: check_startmsgs: not found
>>> eval: afexits: not found
>>> 
..
>>> Piecemeal update was needed because make toolchain and make buildworld
>>> failed each early on.
>>
>> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
>> over a lowly D-Link DWL-G630.  Works fine.  The change causing
>> you problems appears to have occurred after Dec 2.
>
> mergemaster appears to have not been done (I know. You said
> quasi-piecemeal). Fair
> enough. Assuming you have both your /etc && (proposed 13) /etc;
> perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
> will help you discover what function names were changed/moved/deleted. As
> well
> as what services were altered/added/deleted
Actually. As I think about it. Adding a p to the diff(1) line above may 
make

it
easier to visually determine the differences eg;

$ diff -rupN orig-etc/ 13-etc/

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


I had done a full mergemaster previously...
It gets stranger.
I tried etcmerge, it could not do any useful work [ no conflicts found iirc 
]
I tried etcupdate, it could neither  [ no /usr/src on the .img file 
filesytem  iirc ]

I found a wpa_supplicant line that creates wlan0 but run0 never gets beyond
'no carrier'
.
then I started Xorg and it worked... so maybe I just forgot to copy the new 
kernel over,

but then why would the newer binaries and  .ko files be working?

Also, when trying the install of the dec 10 .img again, it failed in a 
second or so

.
When copying several files I missed in /etc over, I accidently converted the
system to a 'live cd'... in other words, the system boots normally [ except 
the

run0 not starting and other error messages ] but after login I am presented
with the install menu even thought the thumbdrive is not present.  And get
a real boot completed by choosing 'live CD '
 which is also off topic though...
...
So I got further along,  [ fixed Xorg ... ] but it maybe shouldn't be.
...
Thanks for the suggestions.   I don't wish anyone to spend any more time on 
this, eventually

I may revert to  a wired interface [ if only I was certain how to connect
[ type of ethernet cable, ifconfig, route add paramaters... ]
 to the wifi
modem ethernet
router ports] ... I have more research to do.
...
Well FWIW when I've been confronted with the need to perform an "unorthodox" 
upgrade

path. I always perform a
cd / && cp -rp /etc /eetc
*prior* to a mergemaster(8)
because you never know. ;-)

Sorry for your grief, and best wishes for a quick & easy resolve. :-)

--Chris
___
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: Updating current i386 broke wlan0...

[Chris]

On 2020-12-11 10:32, Chris wrote:

On 2020-12-11 08:10, Steve Kargl wrote:

On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
Longtime BSD current user, due to several constraints I had to update from 
a recent dec 10 image in
a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current 
to 13-Current except

  service netif onestart wlan0 up
no longer completes.

/etc/rc.d/netif set_rcvar_obsolete: not found
eval: wlan_up: not found
starting wpa_supplicant
/etc/rc.d/wpa_supplicant: WARNING:  failed to start...
starting dhclient
eval: wlan0: not found
/etc/rc.d/dhclient: WARNING: failed to start dhclient
/etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see 
rc.conf(5)

starting network wlan0
eval: check_startmsgs: not found
eval: afexits: not found
..
Piecemeal update was needed because make toolchain and make buildworld
failed each early on.


I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
over a lowly D-Link DWL-G630.  Works fine.  The change causing
you problems appears to have occurred after Dec 2.


mergemaster appears to have not been done (I know. You said 
quasi-piecemeal). Fair

enough. Assuming you have both your /etc && (proposed 13) /etc;
perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
will help you discover what function names were changed/moved/deleted. As 
well

as what services were altered/added/deleted
Actually. As I think about it. Adding a p to the diff(1) line above may make 
it

easier to visually determine the differences eg;

$ diff -rupN orig-etc/ 13-etc/



--Chris

___
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: Updating current i386 broke wlan0...

[Chris]

On 2020-12-11 08:10, Steve Kargl wrote:

On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
Longtime BSD current user, due to several constraints I had to update from 
a recent dec 10 image in
a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current 
to 13-Current except

  service netif onestart wlan0 up
no longer completes.

/etc/rc.d/netif set_rcvar_obsolete: not found
eval: wlan_up: not found
starting wpa_supplicant
/etc/rc.d/wpa_supplicant: WARNING:  failed to start...
starting dhclient
eval: wlan0: not found
/etc/rc.d/dhclient: WARNING: failed to start dhclient
/etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see rc.conf(5)
starting network wlan0
eval: check_startmsgs: not found
eval: afexits: not found
..
Piecemeal update was needed because make toolchain and make buildworld
failed each early on.


I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
over a lowly D-Link DWL-G630.  Works fine.  The change causing
you problems appears to have occurred after Dec 2.


mergemaster appears to have not been done (I know. You said quasi-piecemeal). 
Fair

enough. Assuming you have both your /etc && (proposed 13) /etc;
perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
will help you discover what function names were changed/moved/deleted. As 
well

as what services were altered/added/deleted

--Chris
___
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: firewall choice

[Chris]

On 2020-11-27 00:29, tech-lists wrote:

Hi,

What's the "best" [1] choice for firewalling these days, in the list's 
opinion?


I can't speak for the whole list. ;-)
But in my opinion with tables totaling over 150 million IPs. I'm casting a 
vote
for pf(4). It's wildly easy on resources and as fast and flexible as I could 
ever

hope to want. Started using it years ago, and never looked back. :-)



There's pf, ipf and ipfw. Which is the one being most recently 
developed/updated?
I'm used to using pf, have done for over a decade. But OpenBSD's pf has 
diverged a
lot more from when it first came across. There seems to be a lot more 
options.

Is FreeBSD's pf being actively developed still?


Yes. It is actively developed.


ipfw seems a lot more syntatically complex than pf. Is it more capable also?
I know nothing about ipf yet.

[1] up-to-date, versatile, low overhead, high throughput, IPv6-able,
traffic shaping/queueing

thanks,


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

on moving freebsd from svn to git; would this be of any help?

[Chris]

While contemplating a massive re-tooling job ahead to accommodate
any/all changes when freebsd fully lands in git. I ran across this[1][2]
and wondered if it may be of any assistance for the task of those
involved in the migration process @freebsd.

1) http://catb.org/esr/reposurgeon/
2) https://gitlab.com/esr/reposurgeon

FTR I'm unaffiliated with the project. It just looked like it might be of
interest.

--Chris
___
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: Plans for git

[Chris]

On 2020-09-03 11:33, Kristof Provost wrote:

On 3 Sep 2020, at 19:56, Chris wrote:

Why was the intention to switch NOT announced as such MUCH sooner?

There was discussion about a possible switch to git on the freebsd-git 
mailing

list as early as February 2017:
https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html

Ed gave a talk about FreeBSD and git back in 2018:
https://www.youtube.com/watch?v=G8wQ88d85s4

The Git Transition Working group was mentioned in the quarterly status 
reports a
year ago: https://www.freebsd.org/news/status/report-2019-07-2019-09.html 
and

https://www.freebsd.org/news/status/report-2019-04-2019-06.html
It appears to me that the references you make here all allude to 
_investigation_

of a _possibility_ as opposed to a _likelihood_, or an _inevitable_.
IMHO a change as significant as this, which will require tossing years of 
tooling

out the window, and an untold amount of _re_tooling. Should have created an
announcement at _least_ as significant as a new release gets on the mailing
lists.

Thanks for taking the time to reply, Kristof.


Regards,
Kristof


--Chris
___
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: Plans for git

[Chris]

On 2020-09-03 11:03, Kurt Jaeger wrote:

Hi!


Why was the intention to switch NOT announced as such MUCH sooner?


Because communicating complex issues which might cause conflict
and flame wars etc is not easy. Everyone prefers to hack on code,
and possibly procrastinates on the hard stuff 8-}

And all those that do the really heavy work are very, very short on
time and capacity.

I commented on both of these in the original post. But you trimmed that
out. :-(

--Chris
___
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: Plans for git

[Chris]

I've been wanting to comment on the git(1) ==> svn(1) switch for
some time now. I feel quite strongly about it, and rightfully so
for many reasons. But _because_ I feel so strongly about it. I've
refrained from doing so. So as to speak in an objective manner --
I'm not _quite_ there yet.
But I want to make a statement I feel could have averted much of
the strong feelings expressed regarding this (inevitable) change;

Why was the intention to switch NOT announced as such MUCH sooner?

I, like perhaps many others, feel blindsided by the change. IMHO
having done so, could've solicited some productive input. Rather
than reactive commentary. In fact, I'd go so far as to say, it
would have garnered additional help for the changes required.

That's all I feel I can constructively say ATM. :-)

@Ian
I'm 60-something. I guess that makes me a dinosaur too. :-)

@wlosh
Please don't put me in your ~/.ignorelist ~/.killfile ;-)

--Chris
___
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: The spkr driver

[Chris]

On 2020-08-28 09:25, Warner Losh wrote:

Greetings,

I'd like to retire the spkr driver. It was a cute hack before sound cards
were ubiquitous, but it's not been kept up to date, and it's not clear that
it still works It is still Giant locked, and though it's not a huge
effort to do the locking I literally have no way to test it that I trust...

Is anybody using it these days for anything? If not, I'd propose we
de-orbit it before 13. If so, I need people to test patches to remove
Giant...

I still use it for important events, as alerts that something needs attention
on any one of my servers. It's easier to distinguish, and while many boards
include more complex sound. The speaker is "cheap" and easy to use.
I should be able to help test.

Thanks for the heads-up!

--Chris


Warner

___
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: CFT for vendor openzfs - week 4 reminder + memdisk images

[Chris]

On Tue, 28 Jul 2020 21:16:28 -0700 Matthew Macy mm...@freebsd.org said


On Tue, Jul 28, 2020 at 21:06 Chris  wrote:

> On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Tue, Jul 28, 2020 at 20:43 Chris  wrote:
> >
> > > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said
> > >
> > > > On Tue, Jul 28, 2020 at 8:03 PM Chris 
> wrote:
> > > > >
> > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org
> said
> > > > >
> > > > > > On Wednesday, July 8th I issued the initial call for testing for
> the
> > > > > > update to HEAD to vendored openzfs. We'd like to give users
> roughly a
> > > > > > month to test before merging.  The tentative merge date is August
> > > > > > 17th.
> > > > > >
> > > > > > Again, I hope it's not terribly controversial to point out that
> > > > > > it really rests with users of non amd64 platforms to test to
> avoid
> > > any
> > > > > > unpleasant surprises the next time they update their trees
> following
> > > > > > the merge.
> > > > > >
> > > > > > amd64, i386, and aarch64 memdisk images can be found at:
> > > > > >
> > > > >
> > >
> > >
>
> 
https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
> > > > >
> > > > > Is this in an attempt to replace the opensolaris version used now?
> > > >
> > > > The word "attempt" is a misnomer. If you search the mail archives
> this
> > > > has been the PoR for some time.
> > > Sure. OK. I caught this thread. But must have missed the announcement
> > > of the intent to replace the opensolaris version with openzfs.
> > > Do you recall which mailing list that was made to?
> > >
> > > Thank you for your quick reply, Matthew.
> > >
> >
> > Apart from the 3 previous CFT mails, the initial intent was discussed in
> > December 2018. Getting FreeBSD support integrated in to openzfs took a
> lot
> > more incremental PRs than I anticipated.
> >
> >
>
> https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html
>
> Thank you very much, Mathew. Sorry for any bother.
>


No bother or not much at least. It’s just been a long haul and I’d like
to
wrap this up.

No doubt.
FTR I'm not looking to impede you. :-)
My only concern would be that I'd need to remaster the art of ZFS. I've
got 1500 installs to maintain, and any changes tend to alarm me. :-)
I see we're a bit behind the others, if this status report is current:
https://docs.google.com/spreadsheets/d/1CFapSYxA5QRFYy5k6ge3FutU7zbAWbaeGN2nKVXgxCI/edit#gid=0
Will your impending commit move us closer? Is there anything others
like myself can do to help?

Thanks again, Matthew.

--Chris


-M

>



___
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: CFT for vendor openzfs - week 4 reminder + memdisk images

[Chris]

On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said


On Tue, Jul 28, 2020 at 20:43 Chris  wrote:

> On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Tue, Jul 28, 2020 at 8:03 PM Chris  wrote:
> > >
> > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said
> > >
> > > > On Wednesday, July 8th I issued the initial call for testing for the
> > > > update to HEAD to vendored openzfs. We'd like to give users roughly a
> > > > month to test before merging.  The tentative merge date is August
> > > > 17th.
> > > >
> > > > Again, I hope it's not terribly controversial to point out that
> > > > it really rests with users of non amd64 platforms to test to avoid
> any
> > > > unpleasant surprises the next time they update their trees following
> > > > the merge.
> > > >
> > > > amd64, i386, and aarch64 memdisk images can be found at:
> > > >
> > >
>
> 
https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
> > >
> > > Is this in an attempt to replace the opensolaris version used now?
> >
> > The word "attempt" is a misnomer. If you search the mail archives this
> > has been the PoR for some time.
> Sure. OK. I caught this thread. But must have missed the announcement
> of the intent to replace the opensolaris version with openzfs.
> Do you recall which mailing list that was made to?
>
> Thank you for your quick reply, Matthew.
>

Apart from the 3 previous CFT mails, the initial intent was discussed in
December 2018. Getting FreeBSD support integrated in to openzfs took a lot
more incremental PRs than I anticipated.

https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html


Thank you very much, Mathew. Sorry for any bother.

--Chris


Cheers.





___
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: CFT for vendor openzfs - week 4 reminder + memdisk images

[Chris]

On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said


On Tue, Jul 28, 2020 at 8:03 PM Chris  wrote:
>
> On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Wednesday, July 8th I issued the initial call for testing for the
> > update to HEAD to vendored openzfs. We'd like to give users roughly a
> > month to test before merging.  The tentative merge date is August
> > 17th.
> >
> > Again, I hope it's not terribly controversial to point out that
> > it really rests with users of non amd64 platforms to test to avoid any
> > unpleasant surprises the next time they update their trees following
> > the merge.
> >
> > amd64, i386, and aarch64 memdisk images can be found at:
> >
> 
https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
>
> Is this in an attempt to replace the opensolaris version used now?

The word "attempt" is a misnomer. If you search the mail archives this
has been the PoR for some time.

Sure. OK. I caught this thread. But must have missed the announcement
of the intent to replace the opensolaris version with openzfs.
Do you recall which mailing list that was made to?

Thank you for your quick reply, Matthew.

--Chris


>



___
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: CFT for vendor openzfs - week 4 reminder + memdisk images

[Chris]

On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said


On Wednesday, July 8th I issued the initial call for testing for the
update to HEAD to vendored openzfs. We'd like to give users roughly a
month to test before merging.  The tentative merge date is August
17th.

Again, I hope it's not terribly controversial to point out that
it really rests with users of non amd64 platforms to test to avoid any
unpleasant surprises the next time they update their trees following
the merge.

amd64, i386, and aarch64 memdisk images can be found at:
https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/


Is this in an attempt to replace the opensolaris version used now?

Thanks.

--Chris


___
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: Freebsd-update

[Chris]

On Mon, 27 Jul 2020 15:49:46 -0700 bsd-li...@bsdforge.com said


On Mon, 27 Jul 2020 15:14:49 -0700 Michael Dexter edi...@callfortesting.org
said

> On 7/17/20 4:37 AM, Cristian Cardoso wrote:
> > I would like to know if by chance in freeBSD there is some kind of log
> > when the command freebsd-update fetch / install is executed?
> > I looked in the documentation and found nothing about it.
> 
> There does not appear to be a log but running it with '--debug' is very 
> informative. Perhaps run a typescript for each run to capture this?
> 
> All, is the debug output something that should be logged?

Aren't the installs/up(grade|date)s individually logged in /var/messages?

Ahem... I mean't:

/var/log/messages

Sorry. :(
> 
> Michael


--Chris


___
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: Freebsd-update

[Chris]

On Mon, 27 Jul 2020 15:14:49 -0700 Michael Dexter edi...@callfortesting.org said


On 7/17/20 4:37 AM, Cristian Cardoso wrote:
> I would like to know if by chance in freeBSD there is some kind of log
> when the command freebsd-update fetch / install is executed?
> I looked in the documentation and found nothing about it.

There does not appear to be a log but running it with '--debug' is very 
informative. Perhaps run a typescript for each run to capture this?


All, is the debug output something that should be logged?

Aren't the installs/up(grade|date)s individually logged in /var/messages?


Michael


--Chris


___
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: CURRENT: swap issues and dying jails

[Chris]

On Mon, 29 Jun 2020 09:03:32 +0200 O. Hartmann ohartm...@walstatt.org said


Due to the circumstance I have no access anymore to the host in question,
I'll
report a problem occured out of the blue around last week's update of
CURRENT
with poudriere and swapspace.

Problem: under heavy load, the host dies - no ssh connection possible
anymore,
all jails are in the state "dead".
The box in question is running CURRENT, most recent, last update yesterday
morning (28th of June, around 1400 UTC). Revision numbers are added as soon
I
have access to the box again.

The host has 16 GB phsyical RAM and 64 GB configured swap - which the kernel
complains about to increase swapzone or something similar. The host runs
poudriere with both CURRENT and 12-STABLE jails (both recent versions). In
the
past 18 months we pushed the box to the limits with poudriere allwoing 4
poudriere jobs with each 4 threads - never had any problem except slowing
down
the system, but always responsive anyhow and never crashing or loosing
network
connection.

The first time the box died this way was 28th, after the last update of both
host and jails has been performed 26th June, ~ 1400 UTC. Jails running
12-stable are the first poudriere jobs running and that is the state were
the
first crash/hung occured yesterday.

Is this a known problem?

There was a situation very similar to yours mentioned over the last week
on freebsd-stable@. By Donald Wilde, under the title: swap space issues
I believe he also used 12.
There was a great deal of technical advice that appeared to improve his
situation. Interestingly; he was also experiencing this on his "builder"
altho he was using synth as opposed to poudriere.

Maybe it'll help your situation?

--Chris


Kind regards,

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