Re: libc/libsys split coming soon

[Daniel Eischen]

Will this break binary compatibility with older programs expecting those 
symbols in libc and not linked to libsys?

> On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber  wrote:
> 
> On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
>> TL;DR: The implementation of system calls is moving to a seperate
>> library (libsys).  No changes are required to existing software (except
>> to ensure that libsys is present when building custom disk images).
>> 
>> Code: https://github.com/freebsd/freebsd-src/pull/908
>> 
>> After nearly a decade of intermittent work, I'm about to land a series
>> of patches which moves system calls, vdso support, and libc's parsing of
>> the ELF auxiliary argument vector into a separate library (libsys).  I
>> plan to do this early next week (February 5th).
>> 
>> This change serves three primary purposes:
>>  1. It's easier to completely replace system call implementations for
>> tracing or compartmentalization purposes.
>>  2. It simplifies the implementation of restrictions on system calls such
>> as those implemented by OpenBSD's msyscall(2)
>> (https://man.openbsd.org/msyscall.2).
>>  3. It allows language runtimes to link with libsys for system call
>> implementations without requiring libc.
> 
> Awesome! So (3) is generally considered ideal for languages like zig[1], rust 
> or go, to use directly?
> 
> What’s the appropriate mechanism for such a language to know which version of 
> FreeBSD it’s talking to, to ensure syscall table matches the languages 
> expectations?
> 
> It would be nice to hear about any experiments in (2) and how that compares 
> to things such as capsicum.
> 
> [1]: https://github.com/ziglang/zig/issues/165
> 
> A+
> Dave
> 
> 

Re: autofs -hosts maps

[Daniel Braniss]

> On 18 Nov 2023, at 5:47, Cy Schubert  wrote:
> 
> Hi,
> 
> The discussion about NFS exports of ZFS snapshots prompted me to play 
> around with -hosts maps on my network. -hosts maps are mounted on /net.
> 
> I've discovered that -hosts maps don't work with most shares but do with 
> others. I've only played with this for a few minutes so I don't fully 
> understand why some maps work and others not. Some of underlying 
> directories that don't work are ZFS while others are UFS.
> 
> Yet, auto_home maps mounting the same directories does work. And mounting 
> the shares by hand (using mount_nfs) also works.
> 
> Just putting this out there should someone else have noticed this.
> 
> I'll play around with this a little over the weekend.
> 
> 

it’s subdirectories that don’t work?
if so it’s a bug/feature of -hosts.

danny

> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
> 
>   e^(i*pi)+1=0
> 
> 
> 
> 

Daniel Braniss
da...@cs.huji.ac.il

Re: AMD Zen 4 (Ryzen 7000) resource allocation issues (on 14.0)

[Daniel Engberg]

On 2023-10-14T16:12:04.000+02:00, Gary Jennejohn  wrote:

> On Sat, 14 Oct 2023 15:05:22 +0200
> 
> Daniel Engberg  wrote:
> 
>>  On 2023-10-14T13:07:11.000+02:00, Daniel Engberg
>>  
>>wrote:
>>  
>>>   Hi,
>>>   
>>>After updating BIOS on my Asus motherboard (ProArt
>>>   X670E-CREATOR
>>>   
>>>WIFI) the kernel fails to allocate resources for a bunch of
>>>   devices
>>>   
>>>including USB and built-in SATA. This behaviour is also
>>>   observed on
>>>   
>>>at least ASRock boards too so it doesn't seem to be a specific
>>>   issue
>>>   
>>>to one manufacturer or model. If anyone has any ideas how to
>>>   fix
>>>   
>>>this I'd be grateful.
>>>   
>>>I've tried turning off and on "Fast boot" in BIOS without any
>>>   
>>>success, enabing SR-IOV makes the kernel hang during boot.
>>>   
>>>dmesg with older bios (working):
>>>   
>>>
>>>https://forums.freebsd.org/threads/sata-drives-show-in-bios-but-wont-show-in-dev.89656/page-2#post-620854
>>>   
>>>dmesg with new bios (not working):
>>>   
>>>https://reviews.freebsd.org/P612
>>>   
>>>Related PR:
>>>   
>>>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272507
>>>   
>>>If you need to more information or testing just ask and please
>>>   CC me
>>>   
>>>when replying.
>>>   
>>>Best regards,
>>>   
>>>Daniel
>>  
>>   In addition to the above, 13.2-RELEASE fails in the same way,
>>  also
>>  
>>   15.0-CURRENT (20231005-8818f0f1124e-265728). In addition to that,
>>  USB
>>  
>>   also fails to init so USB devices won't work once the kernel
>>  boots.
> 
> Considering that none of the current FreeBSD versions work I suspect
> 
> that you'll have to flash the previous BIOS version to get a working
> 
> system again.
> 
> --
> 
> Gary Jennejohn

Hi,

That's true although I'm going to guess it's going to be an ongoing
issue as at least one user with an ASRock board also has similar
issues (see PR). Looking into if downgrade is possible too.

Best regards,

Daniel

Re: AMD Zen 4 (Ryzen 7000) resource allocation issues (on 14.0)

[Daniel Engberg]

On 2023-10-14T13:07:11.000+02:00, Daniel Engberg
 wrote:

> Hi,
> 
> After updating BIOS on my Asus motherboard (ProArt X670E-CREATOR
> WIFI) the kernel fails to allocate resources for a bunch of devices
> including USB and built-in SATA. This behaviour is also observed on
> at least ASRock boards too so it doesn't seem to be a specific issue
> to one manufacturer or model. If anyone has any ideas how to fix
> this I'd be grateful.
> 
> I've tried turning off and on "Fast boot" in BIOS without any
> success, enabing SR-IOV makes the kernel hang during boot.
> 
> dmesg with older bios (working):
> 
> 
>https://forums.freebsd.org/threads/sata-drives-show-in-bios-but-wont-show-in-dev.89656/page-2#post-620854
> 
> dmesg with new bios (not working):
> 
> https://reviews.freebsd.org/P612
> 
> Related PR:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272507
> 
> If you need to more information or testing just ask and please CC me
> when replying.
> 
> Best regards,
> 
> Daniel

In addition to the above, 13.2-RELEASE fails in the same way, also
15.0-CURRENT (20231005-8818f0f1124e-265728). In addition to that, USB
also fails to init so USB devices won't work once the kernel boots.

Best regards,

Daniel

AMD Zen 4 (Ryzen 7000) resource allocation issues (on 14.0)

[Daniel Engberg]

Hi,

After updating BIOS on my Asus motherboard (ProArt X670E-CREATOR WIFI)
the kernel fails to allocate resources for a bunch of devices
including USB and built-in SATA. This behaviour is also observed on at
least ASRock boards too so it doesn't seem to be a specific issue to
one manufacturer or model. If anyone has any ideas how to fix this
I'd be grateful.

I've tried turning off and on "Fast boot" in BIOS without any success,
enabing SR-IOV makes the kernel hang during boot.

dmesg with older bios (working):

https://forums.freebsd.org/threads/sata-drives-show-in-bios-but-wont-show-in-dev.89656/page-2#post-620854

dmesg with new bios (not working):

https://reviews.freebsd.org/P612

Related PR:

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

If you need to more information or testing just ask and please CC me
when replying.

Best regards,

Daniel

Re: GitHub Code Search

[Daniel O'Connor]

> On 4 Feb 2023, at 22:08, Graham Perrin  wrote:
> 
> On 31/01/2023 17:47, David Chisnall wrote:
>> 〦… The old GitHub search is not great, but cs.github.com has replaced local 
>> search for me in the FreeBSD tree. It's not *quite* as good as fxr, but it's 
>> close. 
>> 
>> For example, searching for sys_cap_enter: 
>> 
>> https://cs.github.com/?scopeName=All+repos==sys_cap_enter+repo%3Afreebsd%2Ffreebsd-src+
>>  
> 
> I get: 
> 
>> failed to get nonce from session

It's in beta, when I tried that link it redirected me to the sign up page 
(which is waitlisted now..)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

Re: Good practices with bectl

[Daniel Tameling]

On Wed, Sep 21, 2022 at 12:08:38PM +0100, Nuno Teixeira wrote:
> Summary: Using bectl for upgrades
> 
> RELEASE=Whatever
> > bectl create ${RELEASE}
> > bectl mount ${RELEASE}
> BASEDIR=/tmp/be_mount. # Use mount point returned by bectl mount
> 
> [freebsd-update method]
> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update \
> upgrade -r ${RELEASE}
> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> # Ignore admonitions to reboot, since we're using a boot environment
> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> > bectl activate ${RELEASE}
> #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far away
> to simply walk over and
> switch to the old BE):
> > reboot
> 
> [upgrade from source method]
> > make DESTDIR=${BASEDIR} installkernel
> > etcupdate -p -D $BASEDIR
> > make DESTDIR=${BASEDIR} installworld
> > etcupdate -D $BASEDIR
> > make DESTDIR=${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old
> delete-old-libs
> > bectl activate ${RELEASE}
> #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far away
> to simply walk over and
> switch to the old BE):
> > reboot
> 

Would it be possible to add this to the handbook? I know that I will be looking 
for it when I upgrade next time.

Best regards,
Daniel

Re: Testing 14-CURRENT-f44280bf5fb on aarch64

[Daniel Morante]

Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 
10 02:52:27 EDT 2022) and removed the sysctl option 
(hw.usb.disable_enumeration=1).


Still seeing the problem.  The below just endlessly prints out on the 
console:


```

FreeBSD/arm64 (mars.morante.com) (ttyu0)

login: ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub_attach: port 1 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 2 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 3 power on or off failed, USB_ERR_IOERROR
uhub_attach: port 4 power on or off failed, USB_ERR_IOERROR
uhub4: 4 ports with 4 removable, self powered
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 1
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 2
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 3
uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 4
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
ugen0.2:  at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 1 (disconnected)
uhub4: detached
ugen0.2:  at usbus0
uhub4 numa-domain 0 on uhub0
uhub4:  on usbus0
uhub4: 4 ports with 4 removable, self powered
```

On 5/4/2022 4:10 AM, Hans Petter Selasky wrote:

On 5/4/22 09:49, Daniel Morante wrote:
I'm still using the sysctl option "hw.usb.disable_enumeration=1" to 
prevent the USB devices from disconnecting/reconnecting every few 
seconds.  Other than that the improvement in stability with 
14-CURRENT on aarach64 on this hardware is much better since the last 
time I tried, back in late February 2022.


Hi Daniel,

Could you try the very latest 14-current as of now? I've made a couple 
of USB fixes which may fix the issue you are seeing.


--HPS

Testing 14-CURRENT-f44280bf5fb on aarch64

[Daniel Morante]

I have been testing 14-CURRENT-f44280bf5fb for the last few days and so 
far it's been okay on my hardware (Cavium ThunderX2). Most of the 
details of the system are saved in 
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-f44280bf5fb. 
I've only had one kernel panic (seen under panic1.txt).


I'm still using the sysctl option "hw.usb.disable_enumeration=1" to 
prevent the USB devices from disconnecting/reconnecting every few 
seconds.  Other than that the improvement in stability with 14-CURRENT 
on aarach64 on this hardware is much better since the last time I tried, 
back in late February 2022.


I figured I would share my experience since I don't know what's the best 
way for me to help with testing new hardware with FreeBSD (besides 
opening PR's for hardware that's not detected).

Re: rc.d/zpool should require (rw) root?

[Daniel Braniss]

> On 4 Feb 2022, at 12:07, Andriy Gapon  wrote:
> 
> 
> It seems that in some cases zpool import -c requires read/write access to the 
> zpool.cache file.  So, it probably makes sense to import "other" pools 
> (non-root) after upgrading / to rw.
> What do you think?
> 

what if root is ro? i.e: diskless?

danny

> -- 
> Andriy Gapon
> 

Re: POLLHUP detected on devd socket

[Daniel O'Connor]

> On 23 Jan 2022, at 01:04, tech-lists  wrote:
> context is a usb3-booting rpi4 running main-n252544-7406ec4ea99
> 
> I see this in /var/log/daemon.log:
> 
> Jan 22 13:24:54 redacted zfsd[886]: POLLHUP detected on devd socket.
> Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd.
> Jan 22 13:24:54 redacted zfsd[886]: ConnectToDevd: Connecting to devd.
> Jan 22 13:24:54 redacted zfsd[886]: Unable to connect to devd
> Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd.
> 
> When this happens, several other things happen:
> 
> 1. the sshd server dies. Already-established sessions still run, butthe 
> server itself stops and no new ssh connections can be made.
> 
> 2. syslogd dies. so does exim, nginx, smartd, sshguard, pf
> 
> I don't know where to start looking for reasons for this. Is it
> a known issue? In the meantime I've turned off zfsd as it's not
> really needed in this machine's context (headless, zfs on single
> disk), from what I can tell.

Is it reproducible? ie can you trigger it post boot?

It is very strange that devd dying would kill anything else running - I have 
stopped and started it a lot while testing devd scripts and I haven't seen 
anything else break.

One idea would be to hack up devd's rc.d script and run it under ktrace and try 
and get some clues.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

Re: Arduino IDF -> make/automake based environment

[Daniel Braniss]

> On 29 Dec 2021, at 14:06, FreeBSD User  wrote:
> 
> On Wed, 29 Dec 2021 09:10:02 +0200
> Daniel Braniss mailto:da...@cs.huji.ac.il>> wrote:
> 
>>> On 29 Dec 2021, at 01:25, FreeBSD User >> <mailto:free...@walstatt-de.de>> wrote:
>>> 
>>> On Mon, 20 Dec 2021 14:35:10 +0100
>>> Marc Fonvieille mailto:black...@freebsd.org> 
>>> <mailto:black...@freebsd.org <mailto:black...@freebsd.org>>> wrote:
>>> 
>>>> Le 19.12.2021 21:03, Andrew Stevenson a écrit :  
>>>>> 
>>>>> 
>>>>>> On 19. Dec 2021, at 12:18, FreeBSD User  wrote:
>>>>>> 
>>>>>> environment. Since I'm interested in coding for some smaller AMTEL MCUs 
>>>>>> and ESP32
>>>>>> and like to digg a bit deeper than simply clicking a host base from a 
>>>>>> menu, I'm not
>>>>>> afraid of doing some larger basic setup if needed.
>>>>> 
>>>>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in 
>>>>> ports.
>>>>> 
>>>> 
>>>> For ESP32, you should look at:
>>>> https://wiki.freebsd.org/electronics/arduino/esp32  
>>> 
>>> Following these instructions with the most recent required ports on the 
>>> latest
>>> 13-STABLE, results in an linker error:
>>> 
>>> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
>>> cannot find crt1-sim.o: No such file or directory
>>> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
>>> cannot find _vectors.o: No such file or directory
>>> collect2: error: ld returned 1 exit status
>>> 
>>> 
>>>> and
>>>> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
>>>>  
>>>> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/>
>>>> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
>>>>  
>>>> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/>>
>>>> 
>> i gave up compiling the xtensa stuff, specially after espressif came out 
>> with a riscv
>> version. so I downloaded the oficial idf and under FreeBSD-13 it almost 
>> worked  out of
>> the box, if you want I can search my notes …
>> 
>> danny
>> 
> 
> Hello.
> 
> I think, that will be the first step in the right direction (using the 
> official eps-idf).
> Since I didn't come along with the salvation of the linker error reported 
> earlier, I
> switched back to an older project from January this year. It is also based on 
> the
> official FreeBSD Arduino 1.8.5 port and the xtensa compiler 5.2.0 from ports, 
> but I used
> within sketchbook/hardware/esp32 the esp32 git branch release/v1.0 instead of 
> master on
> which I faced the crt1-sim.o error. The goal is to compile HyperionLED (as a 
> side
> product) with the recommended libraries for this project.
> It doesn't compile with ESP32 branch release/v1.0, the error is now
> 
> [...]
> libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:149:33: error:
> 'cpu_hal_get_cycle_count' was not declared ...
> [...]
> 
> which lead me to the conclusion that a more recent version is required. With 
> the recent
> version of ESP32 stuff in place, I face the mentioned crt1-sim.o error.

same here, apart from the need for a different compiler for the riskv chips.

> 
> Searching the web for that error leads to a discrepancy of ESP-IDF and the 
> compiler stuff.
> 
> I'll try the original esp-idf as you suggested (it is a pity it is backed by 
> cmake, I'm
> not quite familiar with cmake yet).
> 
> Any advice is highly appreciated.

espidf version i’m using is 5 (master) and it needs linux emulation and yes, 
cmake, but it’s not that difficult to master,
just check the examples CMakefile’s.

if you need more specific help just yell :-)

danny



> 
> Kind regards,
> oh

Re: Arduino IDF -> make/automake based environment

[Daniel Braniss]

> On 29 Dec 2021, at 01:25, FreeBSD User  wrote:
> 
> On Mon, 20 Dec 2021 14:35:10 +0100
> Marc Fonvieille mailto:black...@freebsd.org>> wrote:
> 
>> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
>>> 
>>> 
 On 19. Dec 2021, at 12:18, FreeBSD User  wrote:
 
 environment. Since I'm interested in coding for some smaller AMTEL MCUs 
 and ESP32
 and like to digg a bit deeper than simply clicking a host base from a 
 menu, I'm not
 afraid of doing some larger basic setup if needed.  
>>> 
>>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in ports.
>>> 
>> 
>> For ESP32, you should look at:
>> https://wiki.freebsd.org/electronics/arduino/esp32
> 
> Following these instructions with the most recent required ports on the 
> latest 13-STABLE,
> results in an linker error:
> 
> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
> cannot find crt1-sim.o: No such file or directory
> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
> cannot find _vectors.o: No such file or directory
> collect2: error: ld returned 1 exit status
> 
> 
>> and
>> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
>>  
>> 
i gave up compiling the xtensa stuff, specially after espressif came out with a 
riscv version.
so I downloaded the oficial idf and under FreeBSD-13 it almost worked  out of 
the box,
if you want I can search my notes …

danny

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

[Daniel O'Connor via freebsd-current]

> On 17 Nov 2021, at 09:00, Marcin Wojtas  wrote:
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.

Firstly, thank your for your efforts here, it is appreciated :)

I am finding that the lang/sdcc port is crashing with a seg fault and the core 
dump is no help to me at all:
[freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb 
../../bin/sdcc sdcc.core
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]

Reading symbols from ../../bin/sdcc...
[New LWP 100122]
Core was generated by `../../bin/sdcc -I../../device/include 
-I../../device/include/mcs51 -mds390 --nos'.
Program terminated with signal SIGSEGV, Segmentation fault.
Invalid permissions for mapped object.
#0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
(gdb) info thread
  Id   Target Id Frame
* 1LWP 1001220x000804e3fbc0 in setrlimit () from /lib/libc.so.7
(gdb) bt
#0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
Backtrace stopped: Cannot access memory at address 0x7f87fd08

If I disable ASLR (via proccontrol) then it does not crash, but I am not sure 
how I can debug it further.

I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if 
you (or anyone else) has suggestions for what to try.

Thanks.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)

[Daniel O'Connor via freebsd-current]

> On 25 Nov 2021, at 18:50, FreeBSD User  wrote:
> 
> Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov 
> 22 18:17:54
> CET 2021 amd64) troubles me with our DNS server/service.
> Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 
> version and also,
> after the compilation of a fresh OS with LLVM13, the upgrade from 
> bind-9.16.22 to
> bind-9.16.23 took place as well as ASLR being the default.
> 
> Since then named is crashing with a mysterious segmentation fault (see PR 
> 259921,
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921).
> 
> Disabling ASLR as recommended to check whether ASLR triggers the SegFault did 
> not solve
> the problem, so I suspect a miscompilation due to llvm13.
> 
> On 13-STABLE bind-9.16.23 seem not to have this behaviour.
> 
> I'm floating like a dead man in the water, can someone help?

lang/sdcc also seg faults 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303), although there 
disabling ASLR via proccontrol does fix it.

Can you show a stacktrace for your seg fault?
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

Re: 14.0-CURRENT panic in early boot

[Daniel Morante via freebsd-current]

I've seen it on an arm64 system:

KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x78
--- exception, esr 0x200
vt_conswindow() at vt_conswindow+0x10
(null)() at -0x4
(null)() at 0x0001
Uptime: 3s

The full log is here: 
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-4082b189d2c/failed-boot1.txt


On 11/18/2021 12:22 AM, Dustin Marquess wrote:

I just updated a machine from a build that was ~2 weeks old. The
latest commit when I built it was 2e946f87055.

The system boots using UEFI, if that matters. The system is panicking
pretty early in the boot, however:

real memory  = 137438953472 (131072 MB)
avail memory = 133651496960 (127460 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
kernel trap 12 with interrupts disabled
panic: vm_fault_lookup: fault on nofault entry, addr: 0x81e1d000
cpuid = 0
time = 1


The backtrace shows:

KDB: stack backtrace:
#0 0x806deb5b at kdb_backtrace+0x6b
#1 0x80693b44 at vpanic+0x184
#2 0x806939b3 at panic+0x43
#3 0x8091d4b3 at vm_fault+0x1423
#4 0x8091bfb0 at vm_fault_trap+0xb0
#5 0x809c0902 at trap_pfault+0x1f2
#6 0x809992b8 at calltrap+0x8
#7 0x806ebcc1 at vsscanf+0x31
#8 0x806ebc7f at sscanf+0x3f
#9 0x806bd9ab at validate_uuid+0x8b
#10 0x80655be0 at prison0_init+0x90
#11 0x80623aba at proc0_init+0x29a
#12 0x80623689 at mi_startup+0xe9
#13 0x802e3062 at btext+0x22
Uptime: 1s

Compared to a boot using the old working kernel:

real memory  = 137438953472 (131072 MB)
avail memory = 133651505152 (127460 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0  irqs 0-23
ioapic1  irqs 24-47
ioapic2  irqs 48-71
Launching APs: 1 11 28 15 18 6 29 4 16 9 24 7 3 10 27 22 14 13 12 23
25 20 26 30 17 5 2 21 19 8 31
Timecounter "TSC-low" frequency 1197250876 Hz quality 1000

Has anybody else seen this?
-Dustin



smime.p7s
Description: S/MIME Cryptographic Signature

FreeBSD Quarterly Status Report - Third Quarter 2021

[Daniel Ebdrup Jensen]

FreeBSD Quarterly Status Report 3rd Quarter 2021

This report covers FreeBSD related projects for the period between July and
September, and is the third of four planned reports for 2021, and contains 42
entries.

The third quarter of 2021 was quite active in lots of different areas, so the
report covers a bunch of interesting work including but not limited to boot
performance, compile-time analysis, hole-punching support, various drivers, ZFS
raidz expansion, an update to the sound mixer, and many more.

Regrettably, the status report got a bit delayed, but we hope that the aphorism
better late than never can apply here.

Yours,
Daniel Ebdrup Jensen, with status hat on.

━━━
Table of Contents

  • FreeBSD Team Reports
  □ FreeBSD Foundation
  □ FreeBSD Release Engineering Team
  □ Cluster Administration Team
  □ Continuous Integration
  □ Ports Collection
  □ Documentation Engineering Team
  □ FreeBSD Website Revamp - WebApps working group
  • Projects
  □ Boot Performance Improvements
  □ Git Migration Working Group
  □ LLDB Debugger Improvements
  □ Linux compatibility layer update
  □ Sound mixer improvements
  □ Base System OpenSSH Update
  • Kernel
  □ Arm64 improvements
  □ FreeBSD on Microsoft HyperV and Azure
  □ Improved amd64 UEFI boot
  □ ENA FreeBSD Driver Update
  □ Hole-punching support on FreeBSD
  □ Intel Networking on FreeBSD
  □ Intel Wireless driver support
  □ Microchip LAN743x mgb(4) Device Driver
  □ Fixes for msdosfs_rename VOP
  □ OpenZFS RAIDZ Expansion update
  □ RFC1191 support in IPSEC tunnels
  □ Realtek rtw88 support
  □ Marvell SDHCI improvements and ACPI support
  □ Stack gap handling improvements
  □ syzkaller on FreeBSD
  □ Using OCF in WireGuard
  □ Intel Volume Management Device driver update
  • Ports
  □ Improve CPE Data in the Ports Collection
  □ Why do we need it?
  □ How can I help?
  □ Open Tasks
  □ FreeBSD Erlang Ecosystem Ports update
  □ KDE on FreeBSD
  □ OpenSearch on FreeBSD
  □ Valgrind - Official Support for FreeBSD has Landed
  □ Wine on FreeBSD
  □ Ztop
  • Miscellaneous
  □ -CURRENT compilation time analysis
  • Third-Party Projects
  □ Gitlab 14.3 available
  □ helloSystem
  □ Containers & FreeBSD: Pot, Potluck & Potman
  □ WireGuard on FreeBSD Stabilizes, Eyes Upstreaming

━━━

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://www.FreeBSDfoundation.org
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://www.FreeBSDfoundation.org/donate/
Foundation Partnership Program URL: https://www.FreeBSDfoundation.org/
FreeBSD-foundation-partnership-program
FreeBSD Journal URL: https://www.FreeBSDfoundation.org/journal/
Foundation News and Events URL: https://www.FreeBSDfoundation.org/
news-and-events/

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Donations
from individuals and corporations are used to fund and manage software
development projects, conferences, and developer summits. We also provide
travel grants to FreeBSD contributors, purchase and support hardware to improve
and maintain FreeBSD infrastructure, and provide resources to improve security,
quality assurance, and release engineering efforts. We publish marketing
material to promote, educate, and advocate for the FreeBSD Project, facilitate
collaboration between commercial vendors and FreeBSD developers, and finally,
represent the FreeBSD Project in executing contracts, license agreements, and
other legal arrangements that require a recognized legal entity.

Here are some highlights of what we did to help FreeBSD last quarter:

Fundraising Efforts

Fundraising last quarter wasn’t as spectacular as we were hoping. But, then
again, people tend to take vacations during the summer months, which makes it
that more difficult for our funding requests to go through the management chain
for approvals.

So far this year we’ve raised $180,000 towards our $2,000,000 spending budget.
Why do we need so much money? Well, last year we decided to make more
significant software contributions to FreeBSD. In order to do that, we had to
grow our team. We developed a technology roadmap based on input we were
receiving from commercial users as well as market trends. Based on the roadmap,
we identified positions we needed to fill.

This year we’ve hired three full-time software developers, one full-time ARM
kernel developer, and one project manager. We also are funding wifi work
full-time 

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[Daniel Nebdal]

On Sun, 10 Oct 2021 at 22:17, Baptiste Daroussin  wrote:
>
> >
> > I don't know if this is the right place to jump in, but I suspect this
> > is a related issue?
> > I'm trying to do the opposite - building 14 on a 13-STABLE machine. It
> > fails when trying to build ncurses:
> >
> > root@p14s-bsd:/usr/src # uname -v
> > FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10
> > 03:25:38 CEST 2021
> > root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> > root@p14s-bsd:/usr/src # git pull
> > Already up to date.
> > root@p14s-bsd:/usr/src # git status
> > On branch main
> > Your branch is up to date with 'origin/main'.
> >
> > nothing to commit, working tree clean
> > root@p14s-bsd:/usr/src # make buildworld > build.log
> > (...)
> >
> > The full log is at http://eurostar.nebdal.no/build.log
> > It's all variations over this:
> >
> > ===> lib/ncurses/ncurses (obj,all,install)
> > Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o
> > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error:
> > implicit declaration of function '_nc_tiparm' is invalid in C99
> > [-Werror,-Wimplicit-function-declaration]
> > TIPARM_1(set_a_background, bg),
> > ^
> > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from
> > macro 'TIPARM_1'
> > #define TIPARM_1(s,a) _nc_tiparm(1,s,a)
> >   ^
> > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error:
> > incompatible integer to pointer conversion passing 'int' to parameter
> > of type 'const char *' [-Werror,-Wint-conversion]
> > TIPARM_1(set_a_background, bg),
> > ^~
> > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from
> > macro 'TIPARM_1'
> > #define TIPARM_1(s,a) _nc_tiparm(1,s,a)
> >   ^
> >
> > -DanielN
>
> It is an entirely different storry that deserves its own investigation!
>
> I will try to find time in the next couple of days.
>
> In the meantile could you provide your make.conf, src.conf and src-env.conf?
>
> Best regards
> Bapt

Sure - they're plain enough:
 # cat /etc/make.conf
cat: /etc/make.conf: No such file or directory
 # cat /etc/src.conf
cat: /etc/src.conf: No such file or directory
 # cat /etc/src-env.conf
WITH_META_MODE=YES

I did try with meta mode disabled as well, with the same result.

-DanielN

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[Daniel Nebdal]

On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin  wrote:
>
> On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
> > On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans  wrote:
> >
> > > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh  wrote:
> > > >
> > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh  wrote:
> > > >
> > > > >
> > > > >
> > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin 
> > > > > wrote:
> > > > >
> > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> > > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov 
> > > > >> > wrote:
> > > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> > > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov <
> > > > >> kostik...@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric <
> > > d...@freebsd.org>
> > > > >> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh 
> > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > > > >> d...@freebsd.org> wrote:
> > > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric 
> > > > >> > > > > > > >  > > >
> > > > >> wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > > > >> free...@walstatt-de.de>
> > > > >> > > > > wrote:
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2
> > > > >> > > > > main-n249971-0525ece3554e:
> > > > >> > > > > > > > >> Fri Oct  8 15:17:34 CEST 2021 amd64) building of an
> > > > >> 13-STABLE
> > > > >> > > > > based
> > > > >> > > > > > > > >> appliance failed very early in the build process of
> > > the
> > > > >> 13-STABLE
> > > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent,
> > > since
> > > > >> the
> > > > >> > > > > sources
> > > > >> > > > > > > are
> > > > >> > > > > > > > >> fetched every time the build process is triggered.
> > > > >> > > > > > > > > ...
> > > > >> > > > > > > > >>
> > > > >> > > > > > >
> > > > >>
> > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > > >> > > > > > > > >> -s -o root -g wheel -m 555   compile_et
> > > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > > >> > > > > > > > >>
> > > > >> > > > > > >
> > > > >> > > > >
> > > > >>
> > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen ---
> > > ld:
> > > > >> error:
> > > > >> > > > > > > undefined
> > > > >> > > > > > > > >> symbol: setupterm
> > > > >> > > > > > > > > referenced by Process.cpp
> > > > >> > > > > > > > >
> > > > >> > > > > > >
> > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > It is complaining about ncurses functions; it seems
> > > that
> > > > >> even
> > > > >> > > > > though
> > > > >> > > > > > > the link step gets -lncursesw added, it still is not able
> > > to
> > > > >> find the
> > > > >> > > > > > > symbol:
> > > > >> > > > > > > >
> > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow
> > > got
> > > > >> split off
> > > > >> > > > > from
> > > > >> > > > > > > > libncursesw:
> > > > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd
> > > > >> > > > > > > >
> > > > >> > > > > > > > This affects such cross-builds obviously, and manually
> > > > >> adding
> > > > >> > > > > -ltinfow
> > > > >> > > > > > > > to the link command line makes it link correctly.
> > > > >> > > > > > > >
> > > > >> > > > > > > > However, the 396851c20aebd commit is probably not
> > > suitable
> > > > >> for
> > > > >> > > > > MFC'ing
> > > > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge
> > > in
> > > > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level
> > > > >> > > > > Makefile.inc1?
> > > > >> > > > > > > >
> > > > >> > > > > > > > Baptiste, any ideas? :)
> > > > >> > > > > > > >
> > > > >> > > > > > > > Add setupterm() to libegacy as a nop.
> > > > >> > > > > > >
> > > > >> > > > > > > That's not enough I think, it requires more ncurses
> > > functions
> > > > >> than just
> > > > >> > > > > > > setupterm. And it actually calls them and checks the
> > > return
> > > > >> values too,
> > > > >> > > > > > > IIRC. :)
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return
> > > OK; }
> > > > >> > > > > > int tigetnum(const char *t) { return 0; }
> > > > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; }
> > > > >> > > > > > int del_curterm(TERMINAL *t) { return OK; }
> > > > >> > > > > >
> > > > >> > > > > > 

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

[Daniel Morante via freebsd-current]

Will history/completion continue to work the same way? (for example 
typing part of the command, pressing UP and having it complete based on 
history)


On 9/22/2021 4: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





smime.p7s
Description: S/MIME Cryptographic Signature

Re: dumpdev AUTO in rc.conf does not work

[Daniel Morante via freebsd-current]

Yes my fstab entry is:

/dev/gpt/swap     none    swap    sw  0   0

It looks though that this issue might only happen on arm64?  I tried to 
reproduce on amd64 without any luck.


On 8/8/2021 3:03 AM, Gary Jennejohn wrote:

On Sat, 7 Aug 2021 20:10:50 -0400
Daniel Morante via freebsd-current  wrote:


Hello,

I am running 14.0-CURRENT using the snapshot from 2021-08-05.__ It looks
as if setting dumpdev="AUTO" in /etc/rc.conf has no effect on enabling
kernel crash dumps.

root@callisto:~ # uname -a
FreeBSD callisto 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n248478-f3a3b061216: Thu Aug__ 5 06:03:20 UTC 2021 root@releng
1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

root@callisto:~ # swapinfo -h
DeviceSize Used Avail Capacity
/dev/gpt/swap 30G030G0%

root@callisto:~ # dumpon -l
/dev/null

root@callisto:~ # sysrc dumpdev
dumpdev: AUTO

I have to manually enable it via dumpon even though it's set to AUTO in__
rc.conf

root@callisto:~ # dumpon /dev/gpt/swap
root@callisto:~ # dumpon -l
gpt/swap


Works for me if I set dumpdev to AUTO.

I ran '/bin/sh -x dumpon start' and it found the swap entry in /etc/fstab,
as expected.

Does your /etc/fstab entry for swap have the correct syntax?  Mine looks
like this:
/dev/ada0p5 noneswapsw  0   0





smime.p7s
Description: S/MIME Cryptographic Signature

dumpdev AUTO in rc.conf does not work

[Daniel Morante via freebsd-current]

Hello,

I am running 14.0-CURRENT using the snapshot from 2021-08-05.  It looks 
as if setting dumpdev="AUTO" in /etc/rc.conf has no effect on enabling 
kernel crash dumps.


root@callisto:~ # uname -a
FreeBSD callisto 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n248478-f3a3b061216: Thu Aug  5 06:03:20 UTC 2021 root@releng 
1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64


root@callisto:~ # swapinfo -h
Device  Size Used    Avail Capacity
/dev/gpt/swap    30G   0B  30G 0%

root@callisto:~ # dumpon -l
/dev/null

root@callisto:~ # sysrc dumpdev
dumpdev: AUTO

I have to manually enable it via dumpon even though it's set to AUTO in  
rc.conf


root@callisto:~ # dumpon /dev/gpt/swap
root@callisto:~ # dumpon -l
gpt/swap



smime.p7s
Description: S/MIME Cryptographic Signature

FreeBSD Quarterly Status Report - Second Quarter 2021

[Daniel Ebdrup Jensen]

Introduction

This report covers FreeBSD related projects for the period between April and
June, and is the second of four planned reports for 2021.

Some of this reports highlights include but are not limited to work on an
experimental installer, changes to pf, additional work on the Linuxulator,
updates on the state of kernel sanitizers, coverage of the raidz expansion
feature for ZFS, and some news about resource accounting.

Yours,
Daniel Ebdrup Jensen, with status hat on.

━━━
Table of Contents

  • FreeBSD Team Reports
  □ FreeBSD Foundation
  □ FreeBSD Release Engineering Team
  □ Cluster Administration Team
  □ Continuous Integration
  □ Ports Collection
  □ Documentation Engineering Team
  • Projects
  □ BSDDialog - TUI Widgets
  □ Experimental installer
  □ Git Migration Working Group
  □ LLDB Debugger Improvements
  □ Performance Monitoring Counters
  □ syzkaller on FreeBSD
  • Kernel
  □ NXP DPAA driver
  □ ENA FreeBSD Driver Update
  □ Graphics Driver Update from Linux 5.7
  □ Intel Wireless driver support
  □ Kernel Sanitizers
  □ Linux compatibility layer update
  □ NXP LS1028A SoC support
  □ Marvell ARM64 SoCs support
  □ Multicast routing rework
  □ VFS path descriptors API
  □ Dummynet support for pf
  □ Ethernet support for pf
  □ pf syncookie support
  □ Microchip PolarFire SoC support
  □ Racct (Resource Accounting) Bug Fixes and Improvements
  □ OpenZFS RAIDZ Expansion update
  □ Microchip Switchtec support
  • Ports
  □ Emacs Ports
  □ FreeBSD Erlang Ecosystem Ports update
  □ GCC in the Ports Tree (lang/gcc*)
  □ KDE on FreeBSD
  □ libglvnd on FreeBSD
  □ FreeBSD in Science
  • Documentation
  □ FreeBSD Translations on Weblate
  • Miscellaneous
  • Third-Party Projects
  □ FreshPorts
  □ helloSystem
  □ Containers & FreeBSD: Pot, Potluck & Potman

━━━

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Foundation

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Funding
comes from individual and corporate donations and is used to fund and manage
software development projects, conferences and developer summits, and provide
travel grants to FreeBSD contributors. The Foundation purchases and supports
hardware to improve and maintain FreeBSD infrastructure and provides resources
to improve security, quality assurance, and software engineering efforts;
publishes marketing material to promote, educate, and advocate for the FreeBSD
Project; facilitates collaboration between commercial vendors and FreeBSD
developers; and finally, represents the FreeBSD Project in executing contracts,
license agreements, and other legal arrangements that require a recognized
legal entity.

Here are some highlights of what we did to help FreeBSD last quarter:

COVID-19 Impact to the Foundation

Like most organizations, our team continued to work from home. Our temporary
ban on travel for staff members remains in effect, but continues to not affect
our output too much, since most conferences are still virtual. As the world
continues to open up we will re-evaluate the travel ban. We continued
supporting the community and Project through our regular channels.

Partnerships and Commercial User Support

We help facilitate collaboration between commercial users and FreeBSD
developers. We also meet with companies to discuss their needs and bring that
information back to the Project. Our temporary travel ban stayed in effect
during Q2, so we continued meeting with corporate users virtually. If things
look good for in-person meetings in the fall, then we’ll start incorporating
those into an in-person and virtual meeting mix.

Fundraising Efforts

First, we’d like to say thank you to everyone who has given us a financial
contribution this year! Last quarter we raised $70,410, which includes
donations from organizations like Verisign, VMware, and Stormshield, as well as
many individuals.

We depend on these donations to fund our work supporting FreeBSD. Late last
year we decided to put more funding into helping to improve FreeBSD. We hired a
Sr. Software Developer to work on arm64 and a Project Coordinator to manage our
projects and interface with the community. We also hired two of our part-time
software developers full-time. The purpose of this was to provide more
resources to step in to implement and improve major features in FreeBSD, review
patches and bug reports, implement bug fixes, and support the security efforts.
This ensures FreeBSD remains the innovative, secure, and reliable operating
system that 

Re: 15s wait for prompt for sudo su - on -current

[Daniel Dowse]

On Sun, 13 Jun 2021 18:19:04 +0100
tech-lists  wrote:

> On Sun, Jun 13, 2021 at 12:48:11PM -0400, Allan Jude wrote:
> >
> >During the 15 seconds of waiting, press control+t a bunch of times, what
> >is the waitchan?
> 
> % sudo su -
> load: 0.11  cmd: git 79703 [running] 0.81r 0.67u 0.12s 8% 141608k
[snip]
> J.

You could start su like

sudo su root -V 

to see what really gets sourced and loaded. And

sudo su - -f 

to not load/read .chsrc at all. 


best regards

-- 
Daniel Dowse 

Re: RFC: changing the default NFSv4 minor version?

[Daniel Ebdrup Jensen]

On Thu, May 13, 2021 at 11:02:35PM +, Rick Macklem wrote:

Hi,

I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
(In particular, the sessions mechanism for "exactly once RPC semantics"
is a significant improvement over the duplicate request cache for NFSv4.0,
plus other improvements.)

Right now, the FreeBSD NFSv4 client will use NFSv4.0 unless the
"minorversion" mount option is used to set the minor version to 1 or 2.

The Linux client uses the highest minor version supported by both
client and server by default.
I'd like to propose that the default behaviour of the FreeBSD client
be changed to do the same, so that NFSv4.1/4.2 will be used when possible.
--> The "minorversion" mount option could still be used to override the
 above default.

I have hesitated doing this change because it could be considered a POLA
violation, but I think the change from 4.0->4.1/4.2 will normally be a
neutral to positive experience. (To be honest, I suspect most won't notice
the change.)

How do others feel about this change?

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


Hi Rick,

 If I understand your plans correctly, you're not going to be making
 it so that minorversion=N complains?

 In that case, I don't quite understand how it can be a POLA
 violation, since presumably it'll fall back to NFSv4.0 if that's
 the only thing that's supported by ntpd on some other system.

 At any rate, I'm all for it since I'm already using NFSv4.2. :)

Yours,
Daniel Ebdrup Jensen


signature.asc
Description: PGP signature

Re: WSLg update on 1-5-2021 - BSD / WSL

[Daniel Nebdal]

On Thu, 6 May 2021 at 19:05, David Chisnall  wrote:
> [ Disclaimer: I work for Microsoft, but not on WSL and this is my own
> opinion ]
> (...)
> David
>

Just as a counterpoint to Rozhuk's take, that all sounds sensible
enough to me - FreeBSD would probably gain more from this than MS.

So the WSL2 TODO would be something like this:
* Ballooning driver. Seems like a proof of concept would be doable
enough - could you model it as an unkillable task (userland or kernel)
that wants to allocate a lot of memory, and anything it gets it hands
back to the host?
* Some sort of boot support. Maybe as a shim that chainloads an
unmodified kernel? Probably finicky, but also self-contained.
* File systems. Is / also 9p-over-HyperV-channels? If so that's kind
of crucial and perhaps the hardest part.

Oh, and how does the terminal work? You support multiple ttys, so I
guess it's not straight emulated serial?

-- 
Daniel
___
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 crashes at early boot on Lenovo T540p: rtsx to blame

[Daniel Dowse]

On Fri, 7 May 2021 14:33:27 +0300
Lev Serebryakov  wrote:

> 
>   Several versions of 14-CURRENT (including
> FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img) can not
> boot on Lenovo T540p 19 times out of 20.
> 
>   It crashes on device detection, after detecting sound subsystem, ...[snip]

Hi Lev,

Just my story with SDCARD Reader. 

I own a HP Elitebook 2170p. It crashed also with any Release i had used on it. 

Adding 

hw.sdhci.quirk_set="1"
hw.sdhci.quirk_clear="1"
hw.sdhci.enable_msi="0"

to /boot/device.hints solved the problem and the reader is usable, with GENERIC
Kernel.

-cheers


-- 
Daniel Dowse 
___
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 Quarterly Status Report - First Quarter 2021

[Daniel Ebdrup Jensen]

Introduction

This report covers FreeBSD related projects for the period between January and
March, and is the first of four planned reports for 2021.

The first quarter of 2021 has been very active in both FreeBSD-CURRENT and
-STABLE, with 13.0-RELEASE work starting in January and finishing up mid-April.
It provides lots of new features, and there’s even a good chance that some
workloads will experience performance improvements.

The number of entries is slightly down, and this is probably due to a
combination of factors like code slush as well as the ongoing issues with
COVID-19, but we naturally hope that things will look up next quarter. This
combined with a switch-over to AsciiDoctor and a decision to make full use of
the status report work schedule to avoid stress, means that the report can now
be expected to come out at the end of the first month after the quarter has
finished, rather than in the middle.

This report in particular includes a number of interesting entries, covering
everything from the linuxulator, various mitigation work, long-awaited work on
OpenBSM, work on kernel sanitizers, and many more things that it is hoped you
will enjoy reading about.

Yours,
Daniel Ebdrup Jensen, with a status hat on.

━━━
Table of Contents

  • FreeBSD Team Reports
  □ FreeBSD Foundation
  □ FreeBSD Release Engineering Team
  □ Cluster Administration Team
  □ Continuous Integration
  □ Ports Collection
  • Projects
  □ Git Migration Working Group
  □ LLDB Debugger Improvements
  □ Linux compatibility layer update
  □ Vulnerability Mitigations
  □ OpenBSM Synchronisation
  • Kernel
  □ ENA FreeBSD Driver Update
  □ Intel wireless update
  □ Kernel Sanitizers
  □ Marvell ARM64 SoCs support
  □ nv(9)-based audio device enumeration
  • Ports
  □ KDE on FreeBSD
  □ FreeBSD Office team 2021Q1 status report
  □ VirtualBox FreeBSD port
  • Documentation
  □ DOCNG on FreeBSD
  □ FreeBSD Translations on Weblate
  □ WebApps working group
  • Miscellaneous
  □ Discord Server & Community Growth
  • Third-Party Projects
  □ CBSD Project
  □ helloSystem
  □ PkgBase.live
  □ Potluck & Potman
  □ sysctl improvements

━━━

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Foundation

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Funding
comes from individual and corporate donations and is used to fund and manage
software development projects, conferences and developer summits, and provide
travel grants to FreeBSD contributors. The Foundation purchases and supports
hardware to improve and maintain FreeBSD infrastructure and provides resources
to improve security, quality assurance, and release engineering efforts;
publishes marketing material to promote, educate, and advocate for the FreeBSD
Project; facilitates collaboration between commercial vendors and FreeBSD
developers; and finally, represents the FreeBSD Project in executing contracts,
license agreements, and other legal arrangements that require a recognized
legal entity.

Here are some highlights of what we did to help FreeBSD last quarter:

COVID-19 Impact to the Foundation

Like most organizations, our team continued to work from home. Our temporary
ban on travel for staff members remains in effect, but continues to not affect
our output too much, since most conferences are still virtual. We continued
supporting the community and Project, even though some of our work and
responses may have been delayed because of changes in some of our priorities
and the impact of limited childcare for a few of our staff members.

Partnerships and Commercial User Support

We help facilitate collaboration between commercial users and FreeBSD
developers. We also meet with companies to discuss their needs and bring that
information back to the Project. Not surprisingly, the stay at home orders,
combined with our company ban on travel during Q1 made in-person meetings
non-existent. However, the team was able to continue meeting with our partners
and commercial users virtually. These meetings help us understand some of the
applications where FreeBSD is used.

We were thrilled for the opportunity to work with AMD early on to ensure
FreeBSD worked on their recently released third generation EPYC series. You can
read more about that here: https://freebsdfoundation.org/news-and-events/
latest-news/freebsd-well-prepared-for-amd-epyc-7003-series-processors/.

Fundraising Efforts

First, we’d like to say thank you to everyone who has given us a financial
contribution this year! Last quarter we raised $88,237, which includes
donati

Re: should bsdinstall work?

[Daniel Dowse]

On Tue, 4 May 2021 20:22:35 +0100
tech-lists  wrote:

> "error while fetching file://usr/freebsd-dist/MANIFEST : No such file or
> directory"
> 

Hello J.

you can try to run bsdinstall with script option. 
Create a file name it e.g rpi.bsdinstall and put


export DISTRIBUTIONS="kernel.txz base.txz"
export
BSDINSTALL_DISTSITE="https://download.freebsd.org/ftp/releases/arm64/13.0-RELEASE/;

bsdinstall zfsboot


inside. Then run

bsdinstall script rpi.bsdinstall 

and follow the dialog. 

This to be said, i haven't used it with ZFS but with UFS to create VM Images
(amd64) successfully this way.


Daniel


-- 
Daniel Dowse 
___
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: NPAPI (was: java web start / error)

[Daniel Nebdal]

On Fri, 2 Apr 2021 at 04:07, Graham Perrin  wrote:
>
> On 05/03/2021 14:01, Antonio Olivares wrote:
> > … worked well with firefox-esr which I use because the plugins
> > are deprecated using the newer firefox.  Despite that it also used to
> > work with the regular firefox. …
>
> For reference – I dug up some of what's below in response to a question
> in IRC about <https://wiki.freebsd.org/NPAPI>:
>
> Removal of NPAPI plugin support in Firefox 85
> <https://groups.google.com/g/mozilla.dev.platform/c/NsdReYslBU4/m/b9FwjVAbBAAJ>
>
> Java Plugin is Removed from JDK 8u for Linux, Solaris, and MacOS Platforms
> <https://www.oracle.com/java/technologies/javase/8u271-relnotes.html#JDK-8240210>
>
> <https://github.com/davidben/nspluginwrapper> no recent activity, and
> related <https://nspluginwrapper.org/> does not respond.
>
> <https://askubuntu.com/a/905937/25036> about Pale Moon.

At this point, it may be easier to get hold of an old OS, an old copy
of Firefox, and an old Java plugin, install them in a virtual machine,
and firewall it so the VM only has access to that one site. Much like
VHS, you apparently need to view it on preserved tech of a similar
vintage. On the positive side, a setup like that should at least keep
working indefinitely, unless they also manage to use HTTPS
certificates an old browser can't understand.

-- 
Daniel Nebdal
___
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: Update to the 13.0-RELEASE schedule

[Daniel Morante via freebsd-current]

Also, this release seems to have gotten a lot more attention than 
usual.  So probably more people are testing.


On 3/31/21 1:24 PM, Rainer Duffner wrote:



Am 31.03.2021 um 17:58 schrieb Glen Barber :

A small set of updates that we consider blocking the 13.0 release have
been brought to our attention.  As such, the 13.0-RELEASE schedule has
been updated to include a fifth release candidate (RC5).

The updated schedule is available on the FreeBSD Project website:

https://www.freebsd.org/releases/13.0R/schedule/

As usual, we will continue to consider critical bug fixes only for the
duration of this release cycle.

Thank you for your cooperation, and for your patience.

Glen
On behalf of:   re@




The truth is that a lot people don’t really start testing until the later 
release candidates.

So, having more of these release candidates with just refinements is a good 
thing, IMHO.



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




smime.p7s
Description: S/MIME Cryptographic Signature

[LAST OFFICIAL REMINDER] Call for 2021Q1 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
March, 30th 2021 for work done since the last round of Quarterly Reports:
January 2021 - March 2021.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2021Q1 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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"

[2 WEEKS LEFT REMINDER] Call for 2021Q1 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
March, 30th 2021 for work done since the last round of Quarterly Reports:
January 2021 - March 2021.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2021Q1 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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: Strange anomaly when Netgear A6100 - AC600 Dual Band WiFi USB Mini Adapter plugged in on boot

[Daniel Stevenson]

On Saturday, February 20th, 2021 at 04:38, Steven Friedrich  
wrote:

> On Friday, 19 February 2021 06:41:49 EST Steven Friedrich wrote:
>
> > BTW, I included output from pciconf, but the device is USB. Sorry.
> >
> > I was confused because there's an unsupported wi-fi on the motherboard, also
> >
> > from Realtek.
> >
> > mobo Realtek is 8821ce
> >
> > USB Realtek is 8811au
> >
> > On Thursday, 18 February 2021 21:37:34 EST Steven Friedrich wrote:
> >
> > > On Thursday, 18 February 2021 16:35:48 EST
> > >
> > > Daniel
> > >
> > > Stevenson wrote:
> > >
> > > > On Thursday, February 18th, 2021 at 04:40, Steven Friedrich
> > >
> > > free...@twc.com wrote:
> > >
> > > > > Starting devd.
> > > > >
> > > > > Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or
> > > > >
> > > > > use
> > > > >
> > > > > 'onestart' instead of 'start'.
> > > > >
> > > > > There's nothing in /etc/rc.conf to invoke webcam. Nothing in
> > > > >
> > > > > /etc/devd.conf
> > > > >
> > > > > (AFAIK). I haven't modified devd.conf
> > > > >
> > > > > If I unplug the adapter and reboot, no message about webcam appears.
> > > > >
> > > > > Here's the device as reported by pciconf -lv
> > > > >
> > > > > none6@pci0:2:0:0: class=0x028000 card=0x831a103c chip=0xc82110ec
> > > > >
> > > > > rev=0x00 hdr=0x00
> > > > >
> > > > > vendor = 'Realtek Semiconductor Co., Ltd.'
> > > > >
> > > > > device = 'RTL8821CE 802.11ac PCIe Wireless Network Adapter'
> > > > >
> > > > > class = network
> > > > >
> > > > > Here's the dmesg
> > > > >
> > > > > ugen0.2:  at usbus0
> > > > >
> > > > > rtwn0 on uhub0
> > > > >
> > > > > rtwn0: <802.11ac WLAN Adapter > on usbus0
> > > > >
> > > > > rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
> > > >
> > > > Whether or not you have a line in your /etc/rc.conf that says
> > > >
> > > > webcamd_enable="NO", webcamd is disabled by default. You have to
> > > >
> > > > override this by setting webcamd_enable="YES".
> > >
> > > You misinterpreted my post.
> > >
> > > I don't want webcam.
> > >
> > > I get this errant message because I have a USB network adapter plugged in
> > >
> > > on boot.
> > >
> > > I believe this is related to /usr/src/UPDATING entry 20180211:
> > >
> > > 20180211:
> > >
> > > devmatch functionality has been turned on in devd. It will
> > >
> > > automatically
> > >
> > > load drivers for unattached devices. This may cause unexpected
> > >
> > >
> > > drivers to
> > >
> > > be loaded. Please report any problems to current@ and
> > >
> > >
> > > i...@freebsd.org.
> > >
> > > freebsd-questi...@freebsd.org mailing list
> > >
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > >
> > > To unsubscribe, send any mail to
> > >
> > > "freebsd-questions-unsubscr...@freebsd.org"
>
> Here is the what the original report SHOULD have been:
>
> This appears in dmesg if Netgear A6100 plugged in at boot
>
> Starting devd.
>
> Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use
>
> 'onestart' instead of 'start'.
>
> I don't HAVE or want a webcam. This is an anomaly
>
> Here's the device as reported by lsusb
>
> Bus /dev/usb Device /dev/ugen0.5: ID 0846:9052 NetGear, Inc. A6100 AC600 DB
>
> Wireless Adapter [Realtek RTL8811AU]
>
> Here's the dmesg
>
> ugen0.2:  at usbus0
>
> rtwn0 on uhub0
>
> rtwn0: <802.11ac WLAN Adapter > on usbus0
>
> rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
>
> I hope I am getting better at reporting anomalies... 8o)

Uninstalling webcamd would be a good place to start.  It's not part of
the base system; it must have been pulled in as a dependency somewhere
along the line.

--
Daniel Stevenson
___
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: Interface counter inaccurate

[Daniel Ponte]

On Tue, Feb 16, 2021 at 10:39:28AM +0100, Kristof Provost wrote:
[...]
> Even stranger, in that you appear to only have the issue on one of your igb0
> interfaces.
> My initial guess was that there was a driver bug causing it to double count
> the packets.
> 
> That machine has 4 ethernet ports, does it have 4 igbX interfaces as well?
> Are there any vlans configured? (My current thinking is still that it’s a
> driver issue, manifesting only on one of the interfaces because of a
> configuration difference.)
> 
> It may also be useful to try capturing packets on igb0 and correlating the
> number of captured packets with the counters.
> 
> I’m not all that familiar with the igb driver code, so I don’t know if I’ll
> be able to help much.
> 
> Best regards,
> Kristof

It indeed has 4x igb interfaces.

I have been able to further correlate this. The issue is with incoming
packet counters on either interface. When the flow reverses (upload
speedtest vs download speedtest), the inside interface's ingress counter
starts counting double instead.

There is a single, seldom-used vlan, but it is only on the inside
interface. Destroying it made no difference.

Dan
___
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: Interface counter inaccurate

[Daniel Ponte]

On Mon, Feb 15, 2021 at 10:25:47PM +0100, Kristof Provost wrote:
> On 15 Feb 2021, at 22:09, Daniel Ponte wrote:
> > I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from
> > 12.2-STABLE, throughput on my WAN interface (the box runs pf) is
> > incorrectly showing double in systat -if, as well as in vnstat and pftop
> > from ports. The LAN interface does not appear to be so afflicted.
> > 
> `systat -if` doesn’t read the pf counters, so I wouldn’t expect that to be
> related.
> 
> Those are the interface counters.
> What network card and driver do you use?
> 
> Kristof

I, too, questioned the relation. They are igb(4) I210 builtin interfaces
(in a Protectli Vault 4).


systat -if during said speed test:

   igb1  in 11.670 Mb/s 11.670 Mb/s1.067 GB
 out   319.975 Mb/s320.458 Mb/s2.062 GB

   igb0  in640.120 Mb/s640.690 Mb/s6.351 GB
 out 5.824 Mb/s  5.824 Mb/s  987.050 MB 

igb1 is inside, igb0 is outside. The 6GB:2GB difference in totals seen above
is indeed real; this machine did not initiate that much traffic on its own.
___
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"

Interface counter inaccurate

[Daniel Ponte]

All,

I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from
12.2-STABLE, throughput on my WAN interface (the box runs pf) is
incorrectly showing double in systat -if, as well as in vnstat and pftop
from ports. The LAN interface does not appear to be so afflicted.

Running a speedtest on my 300Mb connection shows correctly in systat on a 12.2
client on the LAN, but on the router running 13-STABLE that it traverses, it
shows ~600Mb. Someone suggested I send email here, as the pf counter code has
recently been worked on.

I'm happy to perform further testing, if desired.

Thanks,
Dan
___
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: loader/boot fonts are painfully small (again)

[Daniel Nebdal]

On Fri, 12 Feb 2021 at 15:33, Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> >
> >
> > > On 11. Feb 2021, at 23:21, Yuri Pankov  wrote:
> > >
> > > Lenovo P51 laptop, 15'' 4k (3840x2160) display.
> > >
> > > Booting from the latest available current snapshot (20210107), fonts
> > > were at least readable; updating to the latest bits (manually
> installing
> > > new loader as well) made them really small -- terminal size reported by
> > > stty is 480x135.
> > >
> >
> > It is a issue about not so good automatic font size setup. The original
> code was using 80x24 terminal as base, it was complained it did end up with
> too large fonts, so I did pick uefi terminal size as base (see output from
> mode command), but thats also not perfect. Till better solution, right now
> the option is to set font manually (screen.font variable).
>
> Can we just stick with the "known to work almost everywhere and always"
> default value of 80x24?  These small fonts are great for those of you
> who have 20/20 un corrected vision, but it is a royal PITA for almost
> anyone who has even a slight visual imparement, even corrected I find
> it near imposible to read the default efi screens we put up.
>
> I would suggest we also override this in the -RELEASE/SNAPSHOT
> media as one just does not need to fight this font size issue
> while trying to install a new system.
>
> Thanks,
> Rod
> >
> > > I have also noticed large delays between different loader screens,
> > > probably caused by very slow screen blanking given the terminal size?
> >
> > yes, it definitely needs boost.There are few things we can do about it.
> >
> > rgds,
> > toomas
>
>
If we assume that 16:9 screens are the most common aspect ratio, and that
the font we use is 1:2 (which is just guesswork, based on the 8x16 console
font), that gives us a 32:9 aspect ratio counted in characters.

It seems sensible to stick to an integer multiple of that, to avoid any
uncomfortable stretching or scaling. The 480x135 console you got follows
that idea - it's the 15x scale. That's obviously a bit optimistic, but how
about the 3x or 4x scale, at 96x27 or 128x36?

-- 
Daniel Nebdal
___
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 Quarterly Status Report - Fourth Quarter 2020

[Daniel Ebdrup Jensen]

FreeBSD Project Quarterly Status Report - Fourth Quarter 2020

Introduction

   This report covers FreeBSD related projects for the period
   between October and December, and is the fourth of four planned
   reports for 2020.

   This quarter had quite a lot of work done, including but
   certainly not limited to, in areas relating to everything from
   multiple architectures such as x86, aarch64, riscv, and ppc64
   for both base and ports, over kernel changes such as vectored
   aio, routing lookups and multipathing, an alternative random(4)
   implementation, zstd integration for kernel dumps, log
   compression, zfs and preparations for pkg(8), along with wifi
   changes, changes to the toolchain like the new elfctl utility,
   and all the way to big changes like the git migration and
   moving the documentation from DocBook to Hugo/AsciiDoctor, as
   well as many other things too numerous to mention in an
   introduction.

   This report with 42 entries, which don't hold the answer to
   life, the universe and everything, couldn't have happened
   without all the people doing the work also writing an entry for
   the report, so the quarterly team would like to thank them, as
   otherwise, we wouldn't have anything to do.

   Please note that the deadline for submissions covering the
   period between January and March is March 31st.

   We hope you'll enjoy reading as much as we enjoyed compiling
   it. Daniel Ebdrup Jensen, on behalf of the quarterly team.
 __

FreeBSD Team Reports

 * FreeBSD Foundation
 * FreeBSD Release Engineering Team
 * Cluster Administration Team
 * Continuous Integration
 * Ports Collection
 * Office Hours

Projects

 * GPL in Base
 * Git Migration Working Group
 * Linux compatibility layer update
 * LLDB Debugger Improvements
 * Upstreaming NetApp Changes
 * NFS over TLS implementation
 * OpenBSM Synchronisation
 * Tool Chain

Kernel

 * ENA FreeBSD Driver Update
 * Intel wireless update
 * Fenestras X random(4)
 * pf performance improvement
 * IP Routing lookup improvements
 * Scalable routing multipath support
 * Thunderbolt3/USB4 stack
 * Vectored AIO
 * ZSTD Compression in ZFS

Architectures

 * arm64 platform updatesq
 * FreeBSD/RISC-V Project

Userland Programs

 * Dual-stack ping command

Ports

 * KDE on FreeBSD
 * FreeBSD Office team
 * Ports On Non-x86 Architectures
 * Python 2.7 removal from Ports
 * Xfce on FreeBSD

Documentation

 * FreeBSD Translations on Weblate
 * DOCNG on FreeBSD

Miscellaneous

 * Prometheus NFS Exporter

Third-Party Projects

 * FreeBSD Aarch64 under VMWare ESXi-ARM Fling
 * Bastille
 * CheriBSD
 * Embedded Lab Project
 * helloSystem
 * K8S-bhyve
 * Puppet
 __

FreeBSD Team Reports

   Entries from the various official and semi-official teams, as
   found in the Administration Page.

FreeBSD Foundation

   Contact: Deb Goodkin 

   The FreeBSD Foundation is a 501(c)(3) non-profit organization
   dedicated to supporting and promoting the FreeBSD Project and
   community worldwide. Funding comes from individual and
   corporate donations and is used to fund and manage software
   development projects, conferences and developer summits, and
   provide travel grants to FreeBSD contributors. The Foundation
   purchases and supports hardware to improve and maintain FreeBSD
   infrastructure and provides resources to improve security,
   quality assurance, and release engineering efforts; publishes
   marketing material to promote, educate, and advocate for the
   FreeBSD Project; facilitates collaboration between commercial
   vendors and FreeBSD developers; and finally, represents the
   FreeBSD Project in executing contracts, license agreements, and
   other legal arrangements that require a recognized legal
   entity.

   Here are some highlights of what we did to help FreeBSD last
   quarter:

COVID-19 Impact to the Foundation

   Like most organizations, we transitioned all of our staff to
   work from home. We also put a temporary ban on travel for staff
   members, which didn't affect our output too much, since most
   conferences went virtual. We continued supporting the community
   and Project, even though some of our work and responses may
   have been delayed because of changes in some of our priorities
   and the impact of limited childcare for a few of our staff
   members.

Partnerships and Commercial User Support

   We help facilitate collaboration between commercial users and
   FreeBSD developers. We also meet with companies to discuss
   their needs and bring that information back to the Project. Not
   surprisingly, the stay at home orders, combined with our
   company ban on travel during Q4 made in-person meetings
   non-existent. However

Bug in r361898 (was Re: poudriere: services_mkdb recompile with larger PROTOMAX)

[Daniel Eischen]

On Thu, 31 Dec 2020, Daniel Eischen wrote:


I see this message in src/UPDATING:

20201216:
 The services database has been updated to cover more of the basic
 services expected in a modern system. The database is big enough
 that it will cause issues in mergemaster in Releases previous to
 12.2 and 11.3, or in very old current systems from before r358154.

I'm trying to update a poudriere jail from a freshly built -current
system (r368820):

  FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820
  Wed Dec 30 15:55:06 EST 2020

I've tried running this command twice:

  export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj
  poudriere jail -u -j 13amd64

[ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ]

services_mkdb was updated in the jail on the first pass:

  # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb
  -r-xr-xr-x  1 root  wheel  15288 Dec 31 13:02 
/usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb


But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get
the following error:

...

--- _CONFSINS_services ---
install -N /opt/FreeBSD/svn/head/etc  -C -o root  -g wheel -m 644 
/opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services 
/usr/local/poudriere/jails/13amd64/etc/services

--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nice ---
===> usr.bin/nice (installconfig)
--- installconfig_subdir_usr.sbin ---
--- afterinstallconfig ---
--- installconfig_subdir_lib ---
--- installconfig_subdir_lib/ncurses ---
--- installconfig_subdir_lib/ncurses/ncurses ---
===> lib/ncurses/ncurses (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb -l -q -o /usr/local/poudriere/jails/13amd64/var/db/services.db 
/usr/local/poudriere/jails/13amd64/etc/services

--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nl ---
===> usr.bin/nl (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb: Ran out of protocols adding `divert'; recompile with larger 
PROTOMAX


What's the work-around for this?  services_mkdb seems to have been
updated on the first pass off 'poudiere jail -u ...', but still fails
on the second pass.


A typo (tdp was used instead of tcp) in the services file seems to
have been introduced in r361898.  This is the patch that fixes the
problem for me.

Index: usr.sbin/services_mkdb/services
===
--- usr.sbin/services_mkdb/services (revision 368820)
+++ usr.sbin/services_mkdb/services (working copy)
@@ -1788,7 +1788,7 @@
 iscsi-target 3260/udp   # iSCSI port
 mysql  3306/tcp   #MySQL
 mysql  3306/udp   #MySQL
-ms-wbt-server 3389/tdp   rdp #MS WBT Server
+ms-wbt-server 3389/tcp   rdp #MS WBT Server
 ms-wbt-server 3389/udp   #MS WBT Server
 efi-lm  3392/tcp   #EFI License Management
 efi-lm  3392/udp   #EFI License Management

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

poudriere: services_mkdb recompile with larger PROTOMAX

[Daniel Eischen]

I see this message in src/UPDATING:

20201216:
  The services database has been updated to cover more of the basic
  services expected in a modern system. The database is big enough
  that it will cause issues in mergemaster in Releases previous to
  12.2 and 11.3, or in very old current systems from before r358154.

I'm trying to update a poudriere jail from a freshly built -current
system (r368820):

   FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820
   Wed Dec 30 15:55:06 EST 2020

I've tried running this command twice:

   export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj
   poudriere jail -u -j 13amd64

[ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ]

services_mkdb was updated in the jail on the first pass:

   # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb
   -r-xr-xr-x  1 root  wheel  15288 Dec 31 13:02  
/usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb

But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get
the following error:

...

--- _CONFSINS_services ---
install -N /opt/FreeBSD/svn/head/etc  -C -o root  -g wheel -m 644  
/opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services 
/usr/local/poudriere/jails/13amd64/etc/services
--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nice ---
===> usr.bin/nice (installconfig)
--- installconfig_subdir_usr.sbin ---
--- afterinstallconfig ---
--- installconfig_subdir_lib ---
--- installconfig_subdir_lib/ncurses ---
--- installconfig_subdir_lib/ncurses/ncurses ---
===> lib/ncurses/ncurses (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb -l -q -o /usr/local/poudriere/jails/13amd64/var/db/services.db  
/usr/local/poudriere/jails/13amd64/etc/services
--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nl ---
===> usr.bin/nl (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb: Ran out of protocols adding `divert'; recompile with larger 
PROTOMAX

What's the work-around for this?  services_mkdb seems to have been
updated on the first pass off 'poudiere jail -u ...', but still fails
on the second pass.

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

[LAST OFFICIAL REMINDER] Call for 2020Q4 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2021 for work done since the last round of Quarterly Reports:
October 2020 - December 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q4 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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"

[2 WEEKS LEFT REMINDER] Call for 2020Q4 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2021 for work done since the last round of Quarterly Reports:
October 2020 - December 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q4 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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 Quarterly Status Report - Third Quarter 2020

[Daniel Ebdrup Jensen]

FreeBSD Project Quarterly Status Report - Third Quarter 2020
Introduction

   This report covers FreeBSD related projects for the period between July
   and September, and is the third of four planned reports for 2020.

   This quarter brings a good mix of additions and changes to the FreeBSD
   Project and community, from a diverse number of teams and people
   covering everything from architectures, continuous integration,
   wireless networking and drivers, over drm, desktop and third-party
   project work, as well as several team reports, along with many other
   interesting subjects too numerous to mention.

   As the world is still affected by the epidemic, we hope that this
   report can also serve as a good reminder that there is good work that
   can be done by people working together, even if we're apart.

   We hope you'll be as interested in reading it, as we've been in making
   it. Daniel Ebdrup Jensen, on behalf of the quarterly team.
 __

FreeBSD Team Reports

 * FreeBSD Foundation
 * FreeBSD Release Engineering Team
 * Cluster Administration Team
 * Continuous Integration
 * Ports Collection
 * FreeBSD Office team - 3rd quarter 2020 report
 * FreeBSD Graphics Team status report

Projects

 * FreeBSD on Microsoft HyperV and Azure
 * Building FreeBSD on non-FreeBSD hosts
 * Git Migration Working Group
 * Linux compatibility layer update
 * LLDB Debugger Improvements
 * Lua usage in FreeBSD
 * NFS over TLS implementation
 * syzkaller on FreeBSD

Kernel

 * DRM Drivers Update
 * DTS Update
 * DesignWare Ethernet adapter driver improvements
 * Google Summer of Code'20 Project - eBPF XDP Hooks
 * ENA FreeBSD Driver Update
 * IPSec Extended Sequence Number (ESN) support
 * NXP ARM64 SoC support
 * Addition of PowerPC64LE Architecture
 * ure - USB 3.0 Gigabit Ethernet Driver update
 * Stateless hardware offloads for VXLANs
 * Wireless updates
 * ZSTD Compression in ZFS

Architectures

 * CheriBSD 2020 Q3
 * FreeBSD/RISC-V Project

Ports

 * Update to grub-bhyve
 * KDE on FreeBSD

Documentation

 * DOCNG on FreeBSD

Third-Party Projects

 * Potluck - Flavour & Image Repository for pot
 __

FreeBSD Team Reports

   Entries from the various official and semi-official teams, as found in
   the Administration Page.

FreeBSD Foundation

   Contact: Deb Goodkin 

   The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
   to supporting and promoting the FreeBSD Project and community
   worldwide. Funding comes from individual and corporate donations and is
   used to fund and manage software development projects, conferences and
   developer summits, and provide travel grants to FreeBSD contributors.
   The Foundation purchases and supports hardware to improve and maintain
   FreeBSD infrastructure and provides resources to improve security,
   quality assurance, and release engineering efforts; publishes marketing
   material to promote, educate, and advocate for the FreeBSD Project;
   facilitates collaboration between commercial vendors and FreeBSD
   developers; and finally, represents the FreeBSD Project in executing
   contracts, license agreements, and other legal arrangements that
   require a recognized legal entity.

   Here are some highlights of what we did to help FreeBSD last quarter:

COVID-19 Impact to the Foundation

   Like other organizations, we put policies in place for all of our staff
   members to work from home. We also put a temporary ban on travel for
   staff members. We are continuing our work supporting the community and
   Project, but some of our work and responses may be delayed because of
   changes in some of our priorities and the impact of limited childcare
   for a few of our staff members.

Partnerships and Commercial User Support

   We help facilitate collaboration between commercial users and FreeBSD
   developers. We also meet with companies to discuss their needs and
   bring that information back to the Project. Not surprisingly, the stay
   at home orders, combined with our company ban on travel during Q3 made
   in-person meetings non-existent. However, the team was able to continue
   meeting with our partners and commercial users virtually. These
   meetings help us understand some of the applications where FreeBSD is
   used.

   We are currently scheduling Zoom company meetings for Q4, please reach
   out if you would like to schedule a meeting with us.

Fundraising Efforts

   Last quarter we raised $192,874.43! Thank you to the individuals and
   organizations that stepped in, to help fund our efforts. We'd like to
   thank Arm for their large contribution last quarter, which helped bring
   our 2020 fundraising effort to $521k. We hope other organizations will
   fo

[LAST OFFICIAL REMINDER] Call for 2020Q3 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
October, 1st 2020 for work done since the last round of Quarterly Reports:
July 2020 - September 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q3 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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: Can't forward X11 apps over ssh since migrating to 13-CURRENT

[O'Connor, Daniel]

> On 22 Sep 2020, at 08:06, Patrick McMunn  wrote:
> I don't know if it's just coincidental or if it's because of some change in
> 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable
> to forward X11 apps over ssh. The only app I was accustomed to running this
> way was Handbrake. It worked fine before, but now i get this:
> 
> $ ghb
> Unable to init server: Could not connect to 127.0.0.1: Connection refused
> 
> (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display:
> 
> I have tried other apps like Wireshark and even xclock just to see, but
> they won't work either. Has anyone else had problems with X11 forwarding on
> 13-CURRENT? If it's working for everyone else, at least I can know it's
> probably not 13-CURRENT's fault, and I need to look elsewhere for the
> cause. And yes, my sshd_config has it enabled. It worked fine before, and I
> made sure to keep the same config.

What is the value of DISPLAY? (ie echo $DISPLAY)

Is sshd listening on that port? eg..
[test 3:36] ~> echo $DISPLAY
localhost:11.0
[test 3:36] ~> sockstat|grep 6011
radarsshd   5414  8  tcp6   ::1:6011  *:*
radarsshd   5414  9  tcp4   127.0.0.1:6011*:*

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
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: Deprecating ftpd in the FreeBSD base system?

[Daniel Eischen]

> On Sep 17, 2020, at 11:20 AM, Maxim Sobolev  wrote:
> 
> Re: removing HTTP client please no!!! The current drive to "outlaw" HTTP
> coming from companies who see all world via web browser. Totally ignoring
> the fact that HTTP != HTTPS in particular in cases where reliability and
> lower complexity of the system takes precedence over on-the-wire protocol
> security. For example, many internal APIs of AWS EC2 are HTTP.

Agree.  And remember the mantra: tools, not policy.

--
DE


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

[2 WEEKS LEFT REMINDER] Call for 2020Q3 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
October, 1st 2020 for work done since the last round of Quarterly Reports:
July 2020 - September 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q3 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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"

Call for 2020Q3 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
October, 1st 2020 for work done since the last round of Quarterly Reports:
July 2020 - September 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q3 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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: CFT for vendor openzfs - week 5 reminder + memdisk images

[Daniel Nebdal]

On Sat, 15 Aug 2020 at 21:30, Matthew Macy  wrote:
>
> >
> > Hi. I have some problems downloading the amd64 image:
> >
> > baymax /home/djn > fetch -a
> > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
> > freebsd-openzfs-amd64-2020081100-memstick.img. 19% of  655 MB 2179 kBps 
> > 04m07s
> > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
> > truncated: 134152192/687158140 bytes
> > baymax /home/djn > fetch -ar
> > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
> > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  882 kBps 
> > 09m10s
> > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
> > truncated: 139132928/687158140 bytes
> > baymax /home/djn > fetch -ar
> > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
> > freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  647 kBps 
> > 12m23s
> > fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
> > truncated: 142065664/687158140 bytes
> > baymax /home/djn >
> >
> > It also fails using Firefox on windows on a different machine. (It's
> > also much slower from that machine, about 200 kB/sec. I have no idea
> > if that's relevant.)
>
> Yes, this appears to have been going on for at least the last week.
> The FreeBSD infrastructure directly available to developers appears to
> be unreliable for serving large files. Individuals with accounts on
> freefall have been able to scp the files. It's possible that we may
> just end up sharing images more widely by way of releng generated
> images after commit. I'll see if there's an alternative for the last
> week of the CFT.
>
> Cheers.
> -M

The instructions for building it myself seem easy enough, so it's not
a problem for *me* -  but I'm sure it can't hurt. :)

Thanks,
-- 
Daniel Nebdal
___
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 5 reminder + memdisk images

[Daniel Nebdal]

On Tue, 4 Aug 2020 at 02:25, Matthew Macy  wrote:
>
> 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/latest/
>
> If you're using a platform not listed above and would be inclined to
> test if you had an image to work with, let us know. Alternatively, you
> can still build following the instructions below.
>
> The review for merging in to base can be found at:
> https://reviews.freebsd.org/D25872
>
> ==
> NB: Do NOT zpool upgrade unless you are willing to live without the
> ability to ever rollback to the legacy zfs kmod.
>
> Checkout updated HEAD:
> % git clone https://github.com/mattmacy/networking.git -b
> projects/openzfs_vendor freebsd
>
> Checkout updated openzfs in to sys/contrib:
> % git clone https://github.com/zfsonfreebsd/ZoF.git -b
> projects/openzfs_vendor freebsd/sys/contrib/openzfs
>
> Build world and kernel with whatever your usual configuration is.
> Where possible the openzfs kmod is backward compatible with the cmd
> utils in HEAD so common operations work with existing tools and the
> new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
> are backward compatible with the zfs kmod in HEAD. Although ideally
> one would test this in a separate boot environment, the
> interoperability should allow one to rollback without too much
> difficulty.
>
> NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools
> other than the root pool will not be imported at boot.
>
> Thanks in advance for your time.
>
> -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"


Hi. I have some problems downloading the amd64 image:

baymax /home/djn > fetch -a
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
freebsd-openzfs-amd64-2020081100-memstick.img. 19% of  655 MB 2179 kBps 04m07s
fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
truncated: 134152192/687158140 bytes
baymax /home/djn > fetch -ar
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  882 kBps 09m10s
fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
truncated: 139132928/687158140 bytes
baymax /home/djn > fetch -ar
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  647 kBps 12m23s
fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
truncated: 142065664/687158140 bytes
baymax /home/djn >

It also fails using Firefox on windows on a different machine. (It's
also much slower from that machine, about 200 kB/sec. I have no idea
if that's relevant.)

-- 
Daniel Nebdal
___
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: Kernel panic on recent 12.1 on bridge creation.

[Daniel Dettlaff]

> On 17.07.2020, at 00:16, Daniel Dettlaff  wrote:
> 
> Hello, I heard it's known?
> 
> I built recent system from stable/12 branch and either "ifconfig bridge0 
> create" and `cloned_interfaces="bridge0"` + `ifconfig_bridge0_aliases="inet 
> 172.16.7.1/16` in rc.conf.local causes instant KP and system reboot.
> 
> kind regards
> Daniel Dettlaff

will just add screenshots from cause: 
http://s.verknowsys.com/6eade44caec93c46b134ec81c8597081.png it's production 
kernel build so no symbols.
___
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"

Kernel panic on recent 12.1 on bridge creation.

[Daniel Dettlaff]

Hello, I heard it's known?

I built recent system from stable/12 branch and either "ifconfig bridge0 
create" and `cloned_interfaces="bridge0"` + `ifconfig_bridge0_aliases="inet 
172.16.7.1/16` in rc.conf.local causes instant KP and system reboot.

kind regards
Daniel Dettlaff
___
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 Quarterly Status Report - Second Quarter 2020 [Inlined]

[Daniel Ebdrup Jensen]

FreeBSD Project Quarterly Status Report - Second Quarter 2020
Introduction

   This report will be covering FreeBSD related projects between April and
   June, and covers a diverse set of topics ranging from kernel updates
   over userland and ports, as well to third-party work.

   Some hilights picked with the roll of a d100 include, but are not
   limited to, the ability to forcibly unmounting UFS when the underlying
   media becomes inaccessible, added preliminary support for Bluetooth Low
   Energy, a introduction to the FreeBSD Office Hours, and a repository of
   software collections called potluck to be installed with the pot
   utility, as well as many many more things.

   As a little treat, readers can also get a rare report from the
   quarterly team.

   Finally, on behalf of the quarterly team, I would like to extend my
   deepest appreciation and thank you to salvadore@, who decided to take
   down his shingle. His contributions not just the quarterly reports
   themselves, but also the surrounding tooling to many-fold ease the
   work, are immeassurable.

   We hope you find the report as interesting as we have,
   Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team.
 __

FreeBSD Team Reports

 * FreeBSD Foundation
 * FreeBSD Core Team
 * FreeBSD Release Engineering Team
 * Cluster Administration Team
 * Continuous Integration
 * Ports Collection
 * FreeBSD Office Hours
 * Quarterly Status Reports Team

Projects

 * FreeBSD on Microsoft HyperV and Azure
 * Git Migration Working Group
 * Lua Usage in FreeBSD
 * Linux compatibility layer update
 * NFS over TLS implementation

Kernel

 * SoC audio framework and more audio drivers
 * bhyve - NVMe emulation improvements
 * Bluetooth Support
 * DRM Drivers Update
 * DTS Update
 * ENA FreeBSD Driver Update
 * Forcible Unmount of UFS/FFS Filesystems on Disk Failure
 * i.MX 8M support
 * Intel wireless and 11ac update
 * amd64 5-Level Paging Structures support
 * Not-transparent superpages
 * NXP ARM64 SoC support
 * amd64 pmap Fine-grained pv lists locking
 * Lockless routing lookups and scalable multipath
 * ZSTD Compression in ZFS
 * CheriBSD 2020 Q2

Architectures

 * Continuous Integration on !x86
 * FreeBSD/RISC-V Project

Userland Programs

 * Import of new implementation of bc and dc
 * Binutils Retirement
 * Run-Time Dynamic Linker improvements
 * VHDX support in mkimg(1)

Ports

 * Bastille
 * KDE on FreeBSD
 * Haskell on FreeBSD
 * rtsx - Porting driver for Realtek SD card reader from OpenBSD
 * Valgrind updates

Documentation

 * FreeBSD Translations on Weblate

Miscellaneous

 * FreshPorts
 * PCI passthrough with bhyve on Intel and for OpenBSD guests
 * SageMath

Third-Party Projects

 * chaifi - a tool to simplify joining public WiFi networks
 * MixerTUI
 * Potluck - Flavour & Image Repository for pot
 __

FreeBSD Team Reports

   Entries from the various official and semi-official teams, as found in
   the Administration Page.

FreeBSD Foundation

   Contact: Deb Goodkin 

   The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
   to supporting and promoting the FreeBSD Project and community
   worldwide. Funding comes from individual and corporate donations and is
   used to fund and manage software development projects, conferences and
   developer summits, and provide travel grants to FreeBSD contributors.
   The Foundation purchases and supports hardware to improve and maintain
   FreeBSD infrastructure and provides resources to improve security,
   quality assurance, and release engineering efforts; publishes marketing
   material to promote, educate, and advocate for the FreeBSD Project;
   facilitates collaboration between commercial vendors and FreeBSD
   developers; and finally, represents the FreeBSD Project in executing
   contracts, license agreements, and other legal arrangements that
   require a recognized legal entity.

   Here are some highlights of what we did to help FreeBSD last quarter:

COVID-19 Impact to the Foundation

   Like other organizations, we put policies in place for all of our staff
   members to work from home. We also put a temporary ban on travel for
   staff members. We are continuing our work supporting the community and
   Project, but some of our work and responses may be delayed because of
   changes in some of our priorities and the impact of limited childcare
   for a few of our staff members.

Partnerships and Commercial User Support

   We help facilitate collaboration between commercial users and FreeBSD
   developers. We also meet with companies to discuss their needs and
   bring that information back to the Project. Not surprisi

FreeBSD Quarterly Status Report - Second Quarter 2020

[Daniel Ebdrup Jensen]

FreeBSD Project Quarterly Status Report - Second Quarter 2020
Introduction

   This report will be covering FreeBSD related projects between April and
   June, and covers a diverse set of topics ranging from kernel updates
   over userland and ports, as well to third-party work.

   Some hilights picked with the roll of a d100 include, but are not
   limited to, the ability to forcibly unmounting UFS when the underlying
   media becomes inaccessible, added preliminary support for Bluetooth Low
   Energy, a introduction to the FreeBSD Office Hours, and a repository of
   software collections called potluck to be installed with the pot
   utility, as well as many many more things.

   As a little treat, readers can also get a rare report from the
   quarterly team.

   Finally, on behalf of the quarterly team, I would like to extend my
   deepest appreciation and thank you to salvadore@, who decided to take
   down his shingle. His contributions not just the quarterly reports
   themselves, but also the surrounding tooling to many-fold ease the
   work, are immeassurable.

   We hope you find the report as interesting as we have,
   Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team.
 __

FreeBSD Team Reports

 * FreeBSD Foundation
 * FreeBSD Core Team
 * FreeBSD Release Engineering Team
 * Cluster Administration Team
 * Continuous Integration
 * Ports Collection
 * FreeBSD Office Hours
 * Quarterly Status Reports Team

Projects

 * FreeBSD on Microsoft HyperV and Azure
 * Git Migration Working Group
 * Lua Usage in FreeBSD
 * Linux compatibility layer update
 * NFS over TLS implementation

Kernel

 * SoC audio framework and more audio drivers
 * bhyve - NVMe emulation improvements
 * Bluetooth Support
 * DRM Drivers Update
 * DTS Update
 * ENA FreeBSD Driver Update
 * Forcible Unmount of UFS/FFS Filesystems on Disk Failure
 * i.MX 8M support
 * Intel wireless and 11ac update
 * amd64 5-Level Paging Structures support
 * Not-transparent superpages
 * NXP ARM64 SoC support
 * amd64 pmap Fine-grained pv lists locking
 * Lockless routing lookups and scalable multipath
 * ZSTD Compression in ZFS
 * CheriBSD 2020 Q2

Architectures

 * Continuous Integration on !x86
 * FreeBSD/RISC-V Project

Userland Programs

 * Import of new implementation of bc and dc
 * Binutils Retirement
 * Run-Time Dynamic Linker improvements
 * VHDX support in mkimg(1)

Ports

 * Bastille
 * KDE on FreeBSD
 * Haskell on FreeBSD
 * rtsx - Porting driver for Realtek SD card reader from OpenBSD
 * Valgrind updates

Documentation

 * FreeBSD Translations on Weblate

Miscellaneous

 * FreshPorts
 * PCI passthrough with bhyve on Intel and for OpenBSD guests
 * SageMath

Third-Party Projects

 * chaifi - a tool to simplify joining public WiFi networks
 * MixerTUI
 * Potluck - Flavour & Image Repository for pot
 __

FreeBSD Team Reports

   Entries from the various official and semi-official teams, as found in
   the Administration Page.

FreeBSD Foundation

   Contact: Deb Goodkin 

   The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
   to supporting and promoting the FreeBSD Project and community
   worldwide. Funding comes from individual and corporate donations and is
   used to fund and manage software development projects, conferences and
   developer summits, and provide travel grants to FreeBSD contributors.
   The Foundation purchases and supports hardware to improve and maintain
   FreeBSD infrastructure and provides resources to improve security,
   quality assurance, and release engineering efforts; publishes marketing
   material to promote, educate, and advocate for the FreeBSD Project;
   facilitates collaboration between commercial vendors and FreeBSD
   developers; and finally, represents the FreeBSD Project in executing
   contracts, license agreements, and other legal arrangements that
   require a recognized legal entity.

   Here are some highlights of what we did to help FreeBSD last quarter:

COVID-19 Impact to the Foundation

   Like other organizations, we put policies in place for all of our staff
   members to work from home. We also put a temporary ban on travel for
   staff members. We are continuing our work supporting the community and
   Project, but some of our work and responses may be delayed because of
   changes in some of our priorities and the impact of limited childcare
   for a few of our staff members.

Partnerships and Commercial User Support

   We help facilitate collaboration between commercial users and FreeBSD
   developers. We also meet with companies to discuss their needs and
   bring that information back to the Project. Not surprisi

[LAST OFFICIAL REMINDER] Call for 2020Q2 quarterly status reports

[Daniel Ebdrup Jensen]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
July, 1st 2020 for work done since the last round of Quarterly Reports:
April 2020 - June 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissi...@freebsd.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q2 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
___
freebsd-quarterly-ca...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to 
"freebsd-quarterly-calls-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: Is amd automount still supported in 13.0 or not?

[Daniel Braniss]

> On 9 Mar 2020, at 19:26, Bob Willcox  wrote:
> 
> On Mon, Mar 09, 2020 at 08:35:58AM -0700, Cy Schubert wrote:
>> On March 9, 2020 7:49:34 AM PDT, Ed Maste  wrote:
>>> On Sun, 8 Mar 2020 at 13:23, Bob Willcox  wrote:
 
 Thanks for the tip! That worked for me. I guess from reading the
>>> documentation
 I didn't pick up on staying with the symlinks and simply changing
>>> host to net.
>>> 
>>> Glad it's working for you! Is there anything else that you found
>>> tricky or surprising in migrating? Perhaps we could produce a
>>> quick-reference transition guide.
>>> ___
>>> 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"
>> 
>> /net and indirect maps should be simple conversations. Direct maps may or 
>> may not be easy. Autofs doesn't support nested direct maps like amd does. 
>> You may need to mount elsewhere or use /net with symlinks.
>> 
>> We do have a port as well. The port will be retired after a reasonable 
>> amount of time to allow people to convert. Amd upstream has told me he no 
>> longer supports amd. His advice is to use autofs.
> 
> Yes, and I considered installing the amd port but that just seemed like I'd 
> be postponing
> the inevitable. Since I had a simple use case of just using symlinks to about 
> four of my
> remote filesystems, switching from using the /host symlink to the /net 
> symlink was pretty
> easy.
> 
> 
> -- 
> Bob Willcox| It's possible that the whole purpose of your life is to
> b...@immure.com  | serve as a warning to others.
> Austin, TX |
> ___
> 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 
> ”

short version:
 www.cs.huji.ac.il/~danny/autofs.py  
is a python script that converts old hesiod based am-utils maps to autofs
and has been in used for several years now.

long version:
we have been using amd (later am-utils) since sunos days, when we moved to BSD, 
there was no NIS support,
so we switched to hesiod (clever move then since we were all the time getting  
’NIS server not responding’)

with am-utils we had some issues, so when autofs finally made it to Linux, and 
then to FreeBSD, it has been
very solid indeed! 
BTW, autofs is heavily used here, for home directories, binaries etc.

my 2cents.

danny


___
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 October images do not create a bootable install

[Daniel Nebdal]

> On Thu, 7 Nov 2019 09:49:52 +0100 gljennj...@gmail.com said
> I chose GPT.

Maybe whoever wrote the EFI/BIOS code in your machine went all-in on
"Legacy", and it only handles MBR disks (or disks < 2.2TB)?
After all, it seems like "not booting" would be a standards-compliant
way for a classic BIOS to handle a GPT disk.

-- 
Daniel Nebdal
___
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: Lockdown adaX numbers to allow booting ?

[O'Connor, Daniel]

> On 14 Oct 2019, at 19:08, Kurt Jaeger  wrote:
> 
> Hi!
> 
>>>>> You're probably looking for this:
>>>>> https://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html
>>>> 
>>>> Would glabel solve it?
>>> 
>>> The disks are not gpart-formatted, they are used raw.
>> 
>> What file system are they formatted with?
> 
> ZFS, see
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2019-September/074398.html

Given this:
https://lists.freebsd.org/pipermail/freebsd-current/2019-September/074395.html

I think your problem is far earlier than changing ada probe order will help.

It would seem more likely to be a BIOS or BTX problem :(

I would definitely try moving ada0 and ada1 to the first SATA ports to see if 
that helps.

Does anything show up on the VGA console?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
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: Lockdown adaX numbers to allow booting ?

[O'Connor, Daniel]

> On 21 Sep 2019, at 02:36, Garrett Wollman  
> wrote:
> 
> In article <20190920155304.gn3...@zxy.spb.ru>, s...@zxy.spb.ru writes:
> 
>> Location of device in multi-chassis storage system is different story.
>> I am don't know how to field engineer insert disks in chassis.
>> For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and
>> turn ON led by sas2ircu.
> 
> sesutil does this for you!
> 
> # sesutil locate daXY on
> # sesutil locate daXY off
> 
> So long as your enclosure supports SES (all the modern ones I've seen
> do) and is enumerable by ses(4).

FWIW I find it doesn't work on the Supermicro chassis (SYS-5019S-MR) we use 
with SATA disks.
[chumphon 2:42] ~> sudo sesutil locate ada0 on
sesutil: Count not find the SES id of device 'ada0'

(Also I just noticed a spelling error in the above, "Count" should be "Could")

[chumphon 2:42] ~> sudo sesutil map
ses0:
Enclosure Name: AHCI SGPIO Enclosure
Enclosure ID:0
Element 0, Type: Array Device Slot
Status: Unsupported (0x00 0x00 0x00 0x00)
Element 1, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 000
Element 2, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 001
Element 3, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 002
Element 4, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 003
Element 5, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 004
Element 6, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 005
Element 7, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 006
Element 8, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 007

Using led(4) works:
echo 1 | sudo tee /dev/led/ahci0.X.fault 
(The X lines up with the "ahcich4" part of dmesg for adaX)
although I find you can only turn the LED on and not off which limits it's 
usefulness somewhat..

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
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: Lockdown adaX numbers to allow booting ?

[O'Connor, Daniel]

> On 14 Oct 2019, at 03:17, Kurt Jaeger  wrote:
>>> You're probably looking for this:
>>> https://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html
>> 
>> Would glabel solve it?
> 
> The disks are not gpart-formatted, they are used raw.

What file system are they formatted with?
UFS has both labels and IDs which show up in /dev/ufs and /dev/ufsid 
respectively.

(see the glabel man page)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
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: nvdXpY dissapears while ZFS pool on it is imported

[O'Connor, Daniel]

> On 6 Oct 2019, at 01:06, Bernd Walter  wrote:
> 
> On Sat, Oct 05, 2019 at 02:50:21PM +0900, Tomoaki AOKI wrote:
>> Hi.
>> 
>> By sets of commits starting from r351355 though r351747, nvd driver
>> creates partitioned GEOM provider like /dev/nvd0p1.
>> 
>> Unfortunately, these partitioned GEOM providers dissapears when
>> importing ZFS pool on it leaving /dev/nvd0, and re-appears when
>> exporting the pool.
>> 
>> Mounting filesystems other than ZFS (at least msdosfs) doesn't
>> affect.
> 
> It is not ZFS itself, it is the use of /dev/diskid/*, which ZFS prefers
> to open.
> Either explicitly import the volume with /dev/nvd* or use the other
> partitions with /dev/diskid/*
> What really sucks is that volume labels also disappear - e.g. /dev/msdosfs.

It Would Be Nice (tm) if all of the aliases were symlinks pointing to the 
canonical device which didn't disappear when it was opened.

No idea how feasible that is though :)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
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: Lockdown adaX numbers to allow booting ?

[Daniel Engberg]

Hi Kurt!

You're probably looking for this: 
https://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html


Best regards,
Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Daniel Eischen]

> On Aug 14, 2019, at 6:59 PM, Steve Kargl  
> wrote:
> 
>> On Wed, Aug 14, 2019 at 06:40:28PM -0400, Daniel Eischen wrote:
>> I've lost the original thread, but would the sources in
>> /usr/local/sys/modules get built regardless of what
>> MAKEOBJDIRPREFIX is?  And, now that sources may be installed
>> by a port, what is the method for _just_ updating the sources?
>> Why do I even need to build and install the port?  Personally,
>> I would just rather have the drm-kmod sources just imported
>> into base and maintained there.
> 
> You're joking right?  

Not fully, no.

> You remember drm and drm2 (aka drm-legacy-kmod). 

Yes, I remember them.

--
DE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Daniel Eischen]

I've lost the original thread, but would the sources in /usr/local/sys/modules 
get built regardless of what MAKEOBJDIRPREFIX is?  And, now that sources may be 
installed by a port, what is the method for _just_ updating the sources?  Why 
do I even need to build and install the port?  Personally, I would just rather 
have the drm-kmod sources just imported into base and maintained there.  If I 
have 2 or more different checked out base src trees, how do I get the correct 
drm-kmod to go with them if there is only one /usr/local/sys/modules?  Do I 
need multiple port trees just to pull in out of tree module sources?

--
DE
___
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 Core Team Response to Controversial Social Media Posts

[Daniel Braniss]

BIKE SHED SYNDROME?

danny
PS: intentionally top posting :-)

> On 19 May 2019, at 22:43, Igor Mozolevsky  wrote:
> 
> On Sun, 19 May 2019 at 20:16, Warner Losh wrote:
>> 
>> On Sun, May 19, 2019 at 11:34 AM Igor Mozolevsky wrote:
>>> 
>>> On Sun, 19 May 2019 at 17:54, Warner Losh wrote:
> 
> 
> 
 Yes. There will always be limits, just like in real life. You can't tell
 fire in a theater, and claim freedom of expression, for example.
>>> 
>>> 
>>> 
>>> While that is an often cited example, it is rather tenuous as far as
>>> "freedom of expression" is concerned: yelling "Fire!" in a crowded
>>> theatre is by no measure an expression of one's views, thoughts, or
>>> opinions. At the same time, the invocation of a CoC ctte review is
>>> triggered by precisely the latter.
>> 
>> 
>> It is a difficult problem. The project needs to protect itself and its
>> members from harm. Sometimes, though rarely, that harm
>> comes from expressing ones views in a way that's so extreme
>> it causes real and lasting problems either for the cohesiveness
>> of the project, or its effect on the project's reputation is so
>> extreme, people can't separate the two and stop using it. There
>> needs to be a review mechanism for cases that are extreme.
> 
> It's very difficult to subscribe to that view! The first problem you
> encounter is "what is an objectively extreme expression"--what is
> extreme to one, might be entirely common place to another. I'm sure
> whatever religious book one takes there is a passage that goes along
> the lines of "judge people by their deeds not by their words"...
> Secondly, the greatest legal minds in the US wrangled with that and
> came up with one answer: *ANY* expression is protected for otherwise
> it would not be "freedom."
> 
> 
>> At the same time, reviews are detrimental if they are triggered
>> for 'ordinary' conduct: they take time and energy away from
>> the project that could otherwise be spent on making things
>> better. The trick is to have any such review reflect the broad
>> consensus within the project of what's clearly out of bounds,
>> as well as having a fair and just response by the board in
>> the cases that require some action.
> 
> 
> Agreement by consensus is most dangerous, for, usually, the loudest
> wins because people with no backbone fall in-line; the best
> explanation of democracy I have ever heard was: "two wolves and a
> sheep deciding what to have for dinner!"
> 
> 
> --
> Igor 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"

___
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: What is evdev and autoloading?

[Daniel Ebdrup]

> On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko  wrote:
> 
> Michael Gmelin (gre...@freebsd.org) wrote:
>> 
>> 
 On 18. Feb 2019, at 23:54, Mark Linimon  wrote:
 
 On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
 I think one serious problem here is the summary dismissal of things
 simply on the "5 year old" basis.
>>> 
>>> IIUC the graphics changes are being forced upon FreeBSD by external
>>> projects (mainly Linux-based) that are making huge architectural changes
>>> that rely more and more on features from newer hardware.
>>> 
>>> If our upstreams aren't willing to do the work to keep from violating
>>> POLA on older hardware, IMHO it's an awful lot to ask of our already
>>> thinly stretched graphics volunteers to provide it in their stead.
>>> 
>>> w/rt graphics, we are at far more danger of being left further and
>>> further behind on modern hardware than we are at risk of losing users
>>> on older hardware here.
>>> 
>>> Again all IMHO.
>>> 
>>> disclaimer: I don't use any fancy graphics stuff, so (as the old folks
>>> say around here)
>> 
>> I’m very happy (and grateful) that 2018 was the first year in over a decade 
>> I was able to run FreeBSD on a state of the art laptop with all the features 
>> that are essential to me working - which included decent touchpad support 
>> provided through evdev+libinput.
> 
> I want to second this. evdev + libinput was the only option out of
> several that provided smooth multitouch experience for Xorg on my 2018
> laptop I really appreciate all the efforts to make it work both on
> kernel and ports side.
> 
> -- 
> gonzo
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

If I may throw my 0,02€, getting a newer graphics stack also gives me (and 
others) the option to combine many machine functions into one; for example, I 
can use a single machine as all the usual things like: router+firewall(ipfw), 
fileserver which can satuate 1Gbps LAN and WAN with NFSv4 and/or SMB, and many 
other things (those aren’t _that_ new)
What is new is that we can now use it as a media center for efficient hardware 
accelerated playback of h264 and h265, as well as on-the-fly transcoding to 
stream to mobile devices via libva or vdpau, qsv or similar.
___
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: ipv6/ppp: FreeBSD obtains linklocal on tun0 only

[O'Connor, Daniel]

> On 3 Dec 2018, at 08:15, O. Hartmann  wrote:
> 
> 
> The documentation lacks in many aspects how to deal with IPv6, especially 
> when it comes
> to "well known things from the old IPv4 world". Since DDNS also is still 
> something people
> use with IPv6, MYADDR6 doesn't carry the IPV6 address obtained after rtsold 
> has been
> started and rtsol tun0 has been issued as described above (MYADDR6/HISADDR6 
> are assigned
> with the linklocal addresses).

FWIW I use dhcp6c to get an IPv6 range from my ISP.

My /usr/local/etc/dhcp6c.conf looks like..

interface ng0 {
send ia-pd 0;
};

id-assoc pd {
prefix-interface bridge0 {
sla-id 0;
sla-len 8;
};
};

I am using mpd5 for PPPoE and bridge0 is my LAN interface.

My /etc/rtadvd.conf looks like..
# Leaving rltime at the default gives 
http://www.freebsd.org/cgi/query-pr.cgi?pr=162547
# setting it to 0 prevents it being used as a router. Setting to 1800 (the 
putative default)
# works..
bridge0:\
:rltime#1800:\
:rdnss="xxx":\
:dnssl="yyy":

where xxx is the IPv6 address of my server and yyy is my domain.

(I'm not sure if the comment regarding rltime is true any more though but it 
works so I don't touch it ;)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Conrad Meyer wrote:


On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:

I've attached it.  If it gets filtered by the mail list, I'll
make it http accessible.


Thanks Daniel.

It looks like your hostbridge zero device has a different device id
than in my first generation Ryzen system.  Would you please try the
following patch and see if it attaches on your system?  I don't
actually have documentation for Ryzen 2, unfortunately, so I'm not
totally sure if the SMN is accessed in the same way for the new
hostbridge device id.  The change below should at least attempt
attaching to hostb0 on your system.


That seems to have done the trick, thanks!  Output
attached.

--
 DEnet.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.usb.template: -1
kstat.zfs.misc.arcstats.arc_tempreserve: 0
kstat.zfs.misc.zcompstats.attempts: 18438
dev.amdtemp.0.core0.sensor0: 28.1C
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.%parent: hostb0
dev.amdtemp.0.%pnpinfo: 
dev.amdtemp.0.%location: 
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent: 
dev.cpu.7.temperature: 28.1C
dev.cpu.6.temperature: 28.1C
dev.cpu.5.temperature: 28.1C
dev.cpu.4.temperature: 28.1C
dev.cpu.3.temperature: 28.1C
dev.cpu.2.temperature: 28.1C
dev.cpu.1.temperature: 28.1C
dev.cpu.0.temperature: 28.1C
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Conrad Meyer wrote:


Hi Daniel,

On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen  wrote:


Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.


Maybe not.  If they do not attach, it suggests that maybe the Ryzen 2
has a different hostbridge PCI devid.


...
The amdtemp module loads fine (including the dependent amdsmn), but
doesn't report any temperature related sysctls.


Can you run 'devinfo -v' and send or paste the output?  Thank you.


I've attached it.  If it gets filtered by the mail list, I'll
make it http accessible.

--
DEnexus0
  cryptosoft0
  vtvga0
  apic0
  ram0
  acpi0
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
  acpi_perf0
  hwpstate0
  acpi_throttle0
  cpufreq0
cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.P001
  acpi_perf1
  hwpstate1
  acpi_throttle1
cpu2 pnpinfo _HID=none _UID=0 at handle=\_PR_.P002
  acpi_perf2
  hwpstate2
  acpi_throttle2
cpu3 pnpinfo _HID=none _UID=0 at handle=\_PR_.P003
  acpi_perf3
  hwpstate3
  acpi_throttle3
cpu4 pnpinfo _HID=none _UID=0 at handle=\_PR_.P004
  acpi_perf4
  hwpstate4
  acpi_throttle4
cpu5 pnpinfo _HID=none _UID=0 at handle=\_PR_.P005
  acpi_perf5
  hwpstate5
  acpi_throttle5
cpu6 pnpinfo _HID=none _UID=0 at handle=\_PR_.P006
  acpi_perf6
  hwpstate6
  acpi_throttle6
cpu7 pnpinfo _HID=none _UID=0 at handle=\_PR_.P007
  acpi_perf7
  hwpstate7
  acpi_throttle7
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P008
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P009
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00A
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00B
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00C
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00D
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00E
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00F
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
  pci0
hostb0 pnpinfo vendor=0x1022 device=0x15d0 subvendor=0x1043 
subdevice=0x876b class=0x06 at slot=0 function=0 dbsf=pci0:0:0:0 
handle=\_SB_.PCI0.D004
unknown pnpinfo vendor=0x1022 device=0x15d1 subvendor=0x1022 
subdevice=0x15d1 class=0x080600 at slot=0 function=2 dbsf=pci0:0:0:2 
handle=\_SB_.PCI0.IOMA
hostb1 pnpinfo vendor=0x1022 device=0x1452 subvendor=0x 
subdevice=0x class=0x06 at slot=1 function=0 dbsf=pci0:0:1:0
pcib1 pnpinfo vendor=0x1022 device=0x15d3 subvendor=0x1043 
subdevice=0x876b class=0x060400 at slot=1 function=2 dbsf=pci0:0:1:2 
handle=\_SB_.PCI0.GPP1
  pci1
xhci0 pnpinfo vendor=0x1022 device=0x43d0 subvendor=0x1b21 
subdevice=0x1142 class=0x0c0330 at slot=0 function=0 dbsf=pci0:1:0:0 
handle=\_SB_.PCI0.GPP1.PTXH
  usbus0
uhub2
ahci0 pnpinfo vendor=0x1022 device=0x43c8 subvendor=0x1b21 
subdevice=0x1062 class=0x010601 at slot=0 function=1 dbsf=pci0:1:0:1 
handle=\_SB_.PCI0.GPP1.PT01
  ahcich0 at channel=0
  ahcich1 at channel=1
  ahcich2 at channel=2
  ahcich3 at channel=3
  ahcich4 at channel=4
  ahcich5 at channel=5
  ahcich6 at channel=6
  ahcich7 at channel=7
pcib2 pnpinfo vendor=0x1022 device=0x43c6 subvendor=0x1b21 
subdevice=0x0201 class=0x060400 at slot=0 function=2 dbsf=pci0:1:0:2 
handle=\_SB_.PCI0.GPP1.PT02
  pci2
pcib3 pnpinfo vendor=0x1022 device=0x43c7 subvendor=0x1b21 
subdevice=0x3306 class=0x060400 at slot=0 function=0 dbsf=pci0:2:0:0 
handle=\_SB_.PCI0.GPP1.PT02.PT20
  pci3
pcib4 pnpinfo vendor=0x1022 device=0x43c7 subvendor=0x1b21 
subdevice=0x3306 class=0x060400 at slot=4 function=0 dbsf=pci0:2:4:0 
handle=\_SB_.PCI0.GPP1.PT02.PT24
  pci4
xhci1 pnpinfo vendor=0x1b21 device=0x1242 subvendor=0x1043 
subdevice=0x8675 class=0x0c0330 at slot=0 function=0 dbsf=pci0:4:0:0 
handle=\_SB_.PCI0.GPP1.PT02.PT24.AS42
  usbus1
uhub0
  ukbd0 pnpinfo vendor=0x046d product=0xc31c 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x6400 mode=host 
intclass=0x03 intsubclass=0x01 intprotocol=0x01 at bus=1 hubaddr=1 port=3 
devaddr=2 interface=0 ugen=ugen1.2
  uhid0 pnpinfo vendor=0x046d product=0xc31c 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x6400 mode=host 
intclass=0x03 intsubclass=0x00 intprotocol=0x00 at bus=1 hubaddr=1 port=3 
devaddr=2 interface=1 ugen=ugen1.2
  ums0 pnpinfo vendor=0x046d product=0xc014 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0340 mode=h

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

> On Nov 13, 2018, at 2:06 PM, Rozhuk Ivan  wrote:
> 
> On Tue, 13 Nov 2018 12:59:59 -0500 (EST)
> Daniel Eischen  wrote:
> 
>> I'm trying to track down a couple of things.  amdtemp doesn't
>> report any temperature sensors, and acpi seems to have some
>> errors.  Not sure if they are related.
> 
> It s a bit legacy )
> Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> does not use amdsmn.

Thanks, I think?!  I tried it and it panic'd as soon as it was kldload'd.  I 
don't have the trace back handy, but it was in a mtx lock after a pci_write.  
I'm running 13-current, so it could be something different between that and 
-stable or whatever you're testing it on.

--
DE
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

> On Nov 13, 2018, at 4:02 PM, Stefan Ehmann  wrote:
> 
>> On 11/13/18 8:59 PM, Daniel Eischen wrote:
>>> On Tue, 13 Nov 2018, Greg V wrote:
>>> 
>>> 
>>> 
>>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
>>> wrote:
>>>> Greetings,
>>>> 
>>>> I'm trying to track down a couple of things.  amdtemp doesn't
>>>> report any temperature sensors, and acpi seems to have some
>>>> errors.  Not sure if they are related.
>>>> 
>>>> These are the ACPI-related warnings and errors during boot.
>>>> 
>>>>Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
>>>> valid Length but zero Address: 0x/0x1
>>>> (20181031/tbfadt-796)
>>> 
>>> I see this one on my R7 1700 / X370 system, seems harmless.
> 
> I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
> But I don't get the Firmware errors below.

What BIOS version are you using?  I'm running 13-current built from just a few 
days ago.  Never had any temp sysctls since initial install (beginning of 
October).

>>>>acpi0:  on motherboard
>>>>Firmware Error (ACPI): Failure creating [\134_SB.SMIC],
>>>> AE_ALREADY_EXISTS (20181031/dswload2-477)
>>>>ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
>>>> (20181031/psobject-372)
>>>>Firmware Error (ACPI): Failure creating [\134_SB.SMIB],
>>>> AE_ALREADY_EXISTS (20181031/dsfield-803)
>>> 
>>> Looks like people see these on Linux:
>>> 
>>> https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5
>>> 
>>> 
>>> Are you on the latest firmware ("BIOS") revision for your board?
>> 
>> Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
>> BIOS from 2018 September 21, version 4024.
>> 
>>   https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/
>> 
> 
> After kldload amdtemp I see the following sysctls:
> dev.cpu.0.temperature: 77.1C
> dev.amdtemp.0.core0.sensor0: 77.1C
> 
> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
> know if just the offset is wrong or the numbers are completely bogus.
> 
> Numbers from sysutils/xmbmon look saner but not sure if they are correct.

Yeah, I don't have any sensors detected, but my BIOS reports around 39C, right 
around the same as yours.  There are both motherboard and CPU temps in BIOS, 
reporting just a couple of degrees difference.

Overall, this system is very stable, haven't had any crashes or hangs.

--
DE
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Greg V wrote:




On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?


Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
BIOS from 2018 September 21, version 4024.

  https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/

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

No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20181031/tbfadt-796)

   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], AE_ALREADY_EXISTS 
(20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], AE_ALREADY_EXISTS 
(20181031/dsfield-803)

The amdtemp module loads fine (including the dependent amdsmn), but
doesn't report any temperature related sysctls.

   $ sysctl -a | grep temp
   cd0: Attempt to query device size failed: NOT READY, Medium not present - 
tray closed
   cd0: Attempt to query device size failed: NOT READY, Medium not present- 
tray closed
   net.inet6.ip6.use_tempaddr: 0
   net.inet6.ip6.temppltime: 86400
   net.inet6.ip6.tempvltime: 604800
   net.inet6.ip6.prefer_tempaddr: 0
   hw.usb.template: -1
   kstat.zfs.misc.arcstats.arc_tempreserve: 0
   kstat.zfs.misc.zcompstats.attempts: 135280

Here's the relevent CPU line from dmesg.

   CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (3593.34-MHz K8-class 
CPU)
 Origin="AuthenticAMD"  Id=0x810f10  Family=0x17  Model=0x11  Stepping=0
 
Features=0x178bfbff
 
Features2=0x7ed8320b
 AMD Features=0x2e500800
 AMD 
Features2=0x35c233ff
 Structured Extended 
Features=0x209c01a9
 XSAVE Features=0xf
 AMD Extended Feature Extensions ID EBX=0x1007
 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
 TSC: P-state invariant, performance statistics

The full dmesg, /usr/sbin/acpidump -dt, and apcica-tools acpudumps
(with and without -s) are here:

   https://people.freebsd.org/~deischen/2400g/dmesg.txt
   https://people.freebsd.org/~deischen/2400g/acpidump.txt
   https://people.freebsd.org/~deischen/2400g/acpica.acpidump.txt

Thanks

--
DE
___
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: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Daniel Eischen]

>> On Nov 11, 2018, at 9:03 PM, Johannes Dieterich  
>> wrote:
>> 
>> On Sun, Nov 11, 2018 at 4:48 PM Johannes Lundberg  wrote:
>> 
>> I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the time
>> with references to various memory access errors (use after free among
>> other).
>> 
>> Ubuntu is also unstable on this machine but Windows 10 works well after a
>> windows update (I had to reinstall the previous motherboard with older cpu
>> to be able to run Windows update without crash...)
>> 
>> From my experience, stay away from this CPU.
> To put this a little into perspective: the R3 2200G is part of the
> most recent AMD APU generation and contains the most recent Vega
> graphics IP ("Vega 8"). It was officially released only in February of
> this year. The most recent DRM in ports is 4.16, which itself was
> released only in April. Problems with the 2200G on "older" Linux
> releases are unfortunately well known. However, kernel 4.18 with
> latest firmwares and BIOSs is documented to be stable on this platform
> (see phoronix, Ubuntu 18.10 "benchmark").
> 
> Johannes

Even the 2400G (Ryzen 5) released around the same time as the 2200G is 
extremely stable for me (13-current), except for DRM (for which I have to use 
the VESA radeonkms driver as the amdgpu doesn't yet seem to support the 2400G 
graphics).  I've done several buildworlds and more than a few poudriere runs 
building 1100+ ports, it never seems to break a sweat, the CPU and heat sink 
are still cool to the touch.

--
DE
___
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 status of Ryzen (non-)support

[Daniel Eischen]

Sent from my iPhone

> On Oct 22, 2018, at 6:00 PM, Hannes Hauswedell  wrote:
> 
>> On 21.10.18 19:33, Konstantin Belousov wrote:
>>> On Sun, Oct 21, 2018 at 06:09:50PM +0200, Hannes Hauswedell wrote:
>>> Hi everyone,
>>> 
>>> I wanted to ask what the current status of Ryzen support is and/or
>>> whether any new changes are planned.
>>> 
>>> My situation:
>>> * second generation Ryzen: 2600X
>>> * running -CURRENT
>>> * I have done the things described here:
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
>> This was based on the public errata document for the first gen ryzen.
>> I am not aware of the erratas ('revision guides' in AMD terminology)
>> for the second gen ryzens.

Coming in a little late on this thread, just upgraded my 10 year old system to 
an AMD Ryzen 5 2400G.  I noticed that the link below, and alluded to in the 
above pipermail link, does mention the 2nd gen Ryzen processors.  Apologies if 
I misunderstood the above response.

https://developer.amd.com/wp-content/resources/55449_1.12.pdf

Also, my cpuid (Id=0x810f10  Family=0x17  Model=0x11) isn't mentioned in the 
above errata, so I guess it's not quite up to date for more recent 2nd gen 
Ryzen, even though the 2400G was released months before the dated errata.

I've not applied any of the sysctls mentioned in the above email, but have 
updated my BIOS to the latest (ASUS X470-PRO).  I've not experienced any 
problems in several j8 buildworlds or poudriere runs (building roughly 1000 
ports).

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

vm_fault on boot with NVMe/nda

[Daniel Nebdal]

Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9),
with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card.

By default, it shows up as /dev/nvd0, and this is how I installed the
system. It has a single large UFS2 (with SJ and TRIM support) partition
mounted as /. (There's also a few other partitions on it that should be
irrelevant for this.) This works, but it does sometimes slow down for
minutes at the time with disturbing queue lengths in gstat; on the order of
tens of thousands. As I understand it, this is due to how TRIM operations
take precedence over everything else when using nvd ?

Looking around, I noticed the nda driver for NVMe-through-CAM. To test it,
I added hw.nvme.use_nvd=0 to loader.conf. On one level, this works: The
drive shows up as /dev/nda0 . On the other hand, trying to mount nda0p2 as
/ floods the console with "vm_fault: pager read error, pid 1 (init)", and
never finishes booting.

What is more interesting is that if I boot from the drive, but mount an
alpha9 usb stick as /, I can then mount the nda device just fine, and the
very minimal testing I did (using bin/cat and COPYRIGHT on the NVMe drive)
seems to work.

So - is nda meant to be bootable, or am I a bit over-eager in trying to do
so?
If not, is there anything smart I can do to get better performance out of
nvd?
(Or have I just overlooked something obvious?)

Dmesg from a normal nvd boot here:
https://openbenchmarking.org/system/1810159-RA-SSD30089593/SSD/dmesg

-- 
Daniel Nebdal
___
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: OpenSSL 1.1.1 libssl.so version number

[Daniel Eischen]

> On Oct 14, 2018, at 2:00 AM, Don Lewis  wrote:
> 
>> On 12 Oct, Don Lewis wrote:
>> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
>> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
>> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
>> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
>> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
>> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
>> is ambiguous because there are now two different versions of libssl.so
>> (1.0.2p and 1.1.1) with the same shared library version number.
>> 
>> I stumbled across this when debugging a virtualbox-ose configure
>> failure.  The test executable was linked to the ports version of
>> libssl.so but rtld chose the base libssl.so at run time.
> 
> It looks to me like the base libssl.so version needs to get moved to a
> value that doesn't collide with ports, perhaps 12.  These are the
> library version numbers currently used by the various ssl ports:

Even if base OpenSSL used 12, don't you potentially have the same problem if 
the port bumps their version sometime later?

And do you have a problem if a port library is built against a port OpenSSL, 
and another port library is built against base OpenSSL, then an app links to 
both libraries, getting both base and port OpenSSL's linked in the same image?  
It seems like you have to ensure that when you specify WITH_OPENSSL, that all 
your ports are [re]built this way, no?  I guess base OpenSSL is really no 
different, all ports need to be built using the same library, whether it's base 
or some other port version.

--
DE
___
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: OpenSSL 1.1.1 libssl.so version number

[Daniel Eischen]

> On Oct 12, 2018, at 10:58 PM, Cy Schubert  wrote:
> 
> In message , Don Lewis writes:
>> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
>> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
>> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
>> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
>> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
>> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
>> is ambiguous because there are now two different versions of libssl.so
>> (1.0.2p and 1.1.1) with the same shared library version number.
>> 
>> I stumbled across this when debugging a virtualbox-ose configure
>> failure.  The test executable was linked to the ports version of
>> libssl.so but rtld chose the base libssl.so at run time.
> 
> This is also the issue with ports-mgmt/pkg on a system that still 
> requires OpenSSL 1.0.2 from ports in order to support an old client.
> 
> cwfw# pkg info
> ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
> required by /usr/local/lib/libpkg.so.4 not defined
> cwfw# 
> 
> If I remove security/openssl, the above issue is resolved however the 
> old client, which should be replaced next year, fails to communicate 
> with the server. The classic rock & a hard place scenario.

Not saying this is a real solution for the general problem, but can you use a 
libmap.conf entry to work around this?

--
DE
___
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: ALPHA8/r338991 gpart coredumps

[Daniel Braniss]

made a new image/sd and the problem disappeared! freaky.
sorry for the noice

danny


> On 28 Sep 2018, at 10:07, Daniel Braniss  wrote:
> 
> Hi,
> this is happening on an arm/h3, is this only me?
> this is the output of truss:
> truss gpart show
> mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0x15) = 
> 537104384 (0x20039000)
> issetugid()  = 0 (0x0)
> openat(AT_FDCWD,"/etc/libmap.conf",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
> fstat(3,{ mode=-rw-r--r-- ,inode=81462,size=47,blksize=32768 }) = 0 (0x0)
> read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
> close(3) = 0 (0x0)
> open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145)
>  ERR#2 'No such file or directory'
> openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
> read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80)
> fstat(3,{ mode=-r--r--r-- ,inode=244811,size=158,blksize=32768 }) = 0 (0x0)
> pread(3,"/lib:/usr/lib:/usr/lib/compat\0",30,0x0) = 30 (0x1e)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libgeom.so.5",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241318,size=26436,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,32768,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537239552 
> (0x2005a000)
> mmap(0x2005a000,8192,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537239552 (0x2005a000)
> mmap(0x2005c000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537247744 (0x2005c000)
> mmap(0x2005f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537260032 (0x2005f000)
> mmap(0x20061000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 537268224 (0x20061000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libutil.so.9",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241436,size=71928,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,81920,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537272320 
> (0x20062000)
> mmap(0x20062000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537272320 (0x20062000)
> mmap(0x20066000,49152,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537288704 (0x20066000)
> mmap(0x20072000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537337856 (0x20072000)
> mmap(0x20074000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 537346048 (0x20074000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=244782,size=1683256,blksize=32768 }) = 0 
> (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,1826816,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 
> 537354240 (0x20076000)
> mmap(0x20076000,245760,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537354240 (0x20076000)
> mmap(0x200b2000,1400832,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 53760 (0x200b2000)
> mmap(0x20208000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 539000832 (0x20208000)
> mmap(0x20211000,143360,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 539037696 (0x20211000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libbsdxml.so.4",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 
> (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241314,size=150688,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,151552,PROT_NONE,MAP_GUARD,

ALPHA8/r338991 gpart coredumps

[Daniel Braniss]

Hi,
this is happening on an arm/h3, is this only me?
this is the output of truss:
truss gpart show
mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0x15) = 
537104384 (0x20039000)
issetugid()  = 0 (0x0)
openat(AT_FDCWD,"/etc/libmap.conf",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=81462,size=47,blksize=32768 }) = 0 (0x0)
read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
close(3) = 0 (0x0)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145) 
ERR#2 'No such file or directory'
openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80)
fstat(3,{ mode=-r--r--r-- ,inode=244811,size=158,blksize=32768 }) = 0 (0x0)
pread(3,"/lib:/usr/lib:/usr/lib/compat\0",30,0x0) = 30 (0x1e)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libgeom.so.5",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241318,size=26436,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,32768,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537239552 
(0x2005a000)
mmap(0x2005a000,8192,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537239552 (0x2005a000)
mmap(0x2005c000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537247744 (0x2005c000)
mmap(0x2005f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537260032 (0x2005f000)
mmap(0x20061000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 537268224 (0x20061000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libutil.so.9",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241436,size=71928,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,81920,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537272320 
(0x20062000)
mmap(0x20062000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537272320 (0x20062000)
mmap(0x20066000,49152,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537288704 (0x20066000)
mmap(0x20072000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537337856 (0x20072000)
mmap(0x20074000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 537346048 (0x20074000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=244782,size=1683256,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,1826816,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537354240 
(0x20076000)
mmap(0x20076000,245760,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537354240 (0x20076000)
mmap(0x200b2000,1400832,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 53760 (0x200b2000)
mmap(0x20208000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539000832 (0x20208000)
mmap(0x20211000,143360,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 539037696 (0x20211000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libbsdxml.so.4",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241314,size=150688,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,151552,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 539181056 
(0x20234000)
mmap(0x20234000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539181056 (0x20234000)
mmap(0x20238000,122880,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539197440 (0x20238000)
mmap(0x20256000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539320320 (0x20256000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)

Re: usb rtwn not loaded properly at boot

[Daniel Braniss]

> On 18 Sep 2018, at 10:32, Johannes Lundberg  wrote:
> 
> On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov  wrote:
> 
>> Johannes Lundberg wrote:
>>> Hi
>>> 
>>> I have (with 12-ALPHA5)
>>> 
>>> /boot/loader.conf
>>> rtwn_load="YES"
>>> if_urtw_usb_load="YES"
>> 
>> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
>> 
> 
> Ah yes. Sorry about that. I still suffer confusion from the rename.
> Still, it doesn't change anything since if_rtwn_usb was loaded anyway.
> 
> 
>>> /etc/rc.conf
>>> wlans_rtwn0="wlan0"
>>> ifconfig_wlan0="WPA DHCP"
>>> 
>>> but still after boot only lo0 exists and all modules are loaded.
>>> 
>>> Manually running
>>> ifconfig wlan0 create wlandev rtwn0
>>> sets up the interface correctly.
>>> 
>>> In my kernel config I have
>>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
>>> 
>>> I'm pretty sure this has worked before... Any clues?
>> 


devd is not calling netif!
try running ’service netif start’ and see what happens.

danny

> ___
> 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: Speed problems with both system openssl and security/openssl-devel

[Daniel Nebdal]

On Fri, 14 Sep 2018 at 02:12, Lev Serebryakov  wrote:
>
> Hello John,
>
> Friday, September 14, 2018, 1:44:13 AM, you wrote:
>
> >> % grep aesni ~/nanobsd/gatevay.v3/J3160
> >> device   aesni
>
> > From my understanding of the OpenSSL code, it doesn't use the kernel driver
> > at all (the kernel driver is only needed for in-kernel crypto such as IPSec
> > or GELI).
>  It is my understanding too.
>
> >  AESNI are just instructions that can be used in userland, and
> > OpenSSL's AESNI acceleration is purely different routines in userland.
> > I would verify if AESNI shows up in the CPU features in dmesg first (if it
> > doesn't I'd check for a BIOS option disabling it).
>   It is enabled. It is used for sure by openssl 1.1.0 on Linux and bu openssl 
> 1.1.1
>  on FreeBSD, but not by openssl 1.0.2 and 1.1.0 on FreeBSD. Problem is,
>  openssl 1.1.1 is not used by anything on FreeBSD (yet) and almost
>  everything uses system (1.0.2) and only some other ports could use  1.1.0
>  from ports.
>
> --
> Best regards,
>  Levmailto:l...@freebsd.org
>

Could it be relevant that the Debian binary was probably compiled with
gcc, and the FreeBSD binary with clang? This seems like the sort of
code that plausibly could bring out some compiler corner cases.
(It's weird that 1.1.1 is fine, though.)

--
Daniel Nebdal
___
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: arc_reclaim_thread running hot

[Daniel Nebdal]

On Thu, 13 Sep 2018 at 15:19, Eric van Gyzen  wrote:
>
> This morning, I found the arc_reclaim_thread running hot on my laptop
> running 12.0-ALPHA5 r338572.
>
> vfs.zfs.arc_max="4294967296"  <-- 4 GiB
>
> last pid: 13288;  load averages:  1.32,  1.26,  1.16
>
> Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
> ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
>   89M Compressed, 361M Uncompressed, 4.03:1 Ratio
>
> 22 root -8-  0   256K CPU2 2 309:20  99.75%
> zfskern{arc_reclaim_thread}
>
> zfs_arc_meta_strategy is still the default of 1.
>
> I sampled the thread's stacks with
>
> for N in `jot 1000`; do procstat -kk 100101; done | grep 100101
>
> and put the results here:
>
> https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt
>
> I'm happy to help debug this.  Just let me know what you need.
>
> Eric

Just to summarize, these are the top 15 active
(guessing that the leftmost function is "current"):
 22 arc_space_return
 22 uma_dbg_free
 26 uma_dbg_alloc
 30 mi_switch
 31 uma_zalloc_arg
 33 multilist_sublist_lock
 34 __mtx_unlock_flags
 39 
 46 _sx_xlock
 48 hdr_full_cons
 50 uma_zfree_arg
 58 aggsum_add
 91 arc_adjust
156 _sx_xunlock
185 arc_evict_state

And the top 15 in total
(that is, no matter where in the call stack):
 44 multilist_sublist_lock
 44 uma_dbg_free
 46 _sx_xlock
 47 uma_dbg_alloc
 61 arc_space_return
127 aggsum_add
139 hdr_full_cons
156 _sx_xunlock
211 uma_zfree_arg
219 uma_zalloc_arg
833 arc_evict_state
926 arc_adjust
961 arc_reclaim_thread
961 fork_exit
961 fork_trampoline

(I have nothing sensible to add about the actual problem.)

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

netif not started by devd?

[Daniel Braniss]

with latest current, but can tell when this stopped working,
the wifi dongle is recognised, ie there is a net.wlan.devices,
depending on the dongle it’s run0 or  rtwn0
but only if I type
service netif start
does it become operational.

so what am I missing?

cheers,
danny

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

declient without capsicum failes

[Daniel Braniss]

hi,
latest change to dhclient added chroot if there is no capsicum - my case,
so  chroot failes because /var/empty belongs to root and setgid/setgid/seteuid 
to user dhclient is performed before.

need a pr?

danny



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

ntpd user/group issue

[Daniel Braniss]

Hi,
I am cross compiling, which means i’m using for example an 11.1 to compile 
current, for
another host - an image which is different from the one i'm using to compile.

make install checks for ntpd in /etc, instead, should it look elsewhere? 
DESTDIR perhaps?

cheers,
danny

___
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: [RFC] Deprecation and removal of the drm2 driver

[Daniel Eischen]

On Thu, 31 May 2018, Konstantin Belousov wrote:


On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:


We're not replacing anything. We are moving the older drm1 and drm2 from
kernel to ports to make it easier for the majority of the users to load the
correct driver without conflicts.


You do understand that you increase your maintainence load by this move.
dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
branches, so you will need to chase these updates.


I agree.  One argument previously made was that it's easier
to maintain in ports.  One data point from me - I rarely
update my ports, I update my OS much more frequently.  In
fact, some times my ports get so out of date I just
(take off and) nuke /usr/local (from orbit, it's the only
way to be sure).

Also, are we trying to solve a problem by moving drm[2] to
ports that won't be a problem when base is pkg'ized?  If
drm[2] is a package unto itself, then you don't have this
problem of ports conflicting with it, at least not so
much.  You can either not install the base drm[2] package
or deinstall it to make way for a conflicting port.  Once
drm[2] is pkg rm'd, it's not going to be reinstalled
again when you update the base OS.

And don't we have the same problem with sendmail and a
few other base services?

--
DE
___
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: [RFC] Deprecation and removal of the drm2 driver

[Daniel Eischen]

> On May 18, 2018, at 6:27 PM, Cy Schubert <cy.schub...@cschubert.com> wrote:
> 
> In message <pine.gso.4.64.1805181617250.21...@sea.ntplx.net>, Daniel 
> Eischen wr
> ites:
>>> On Fri, 18 May 2018, Warner Losh wrote:
>>> 
>>> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
>>> s...@troutmask.apl.washington.edu> wrote:
>>>> 
>>>> Check the Makefiles
>>>> 
>>>> % more /usr/ports/graphics/drm-next-kmod/Makefile
>>>> 
>>>> ONLY_FOR_ARCHS= amd64
>>>> ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64
>>>> 
>>>> Not to ia32 friendly.
>>>> 
>>> 
>>> So do people use i386 for desktop? And need the latest KMS stuff?
>> 
>> I can easily imagine an embedded x86 kiosk type appliance.  Does
>> basic xorg stuff work without drm?
> 
> Yes, with VESA, albeit aspect ratios are off.

I'm using drm2 with an AMD (née ATI) Radeon 4850 (RV770), AGP.  This is on an 
amd64 somewhat old -current system.  Is this supported by the drm-next-kmod 
port?

--
DE
___
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: [RFC] Deprecation and removal of the drm2 driver

[Daniel Eischen]

On Fri, 18 May 2018, Warner Losh wrote:


On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:


Check the Makefiles

% more /usr/ports/graphics/drm-next-kmod/Makefile

ONLY_FOR_ARCHS= amd64
ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64

Not to ia32 friendly.



So do people use i386 for desktop? And need the latest KMS stuff?


I can easily imagine an embedded x86 kiosk type appliance.  Does
basic xorg stuff work without drm?

--
DE
___
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: zfsloader: messy output on Dell iDrac serial console

[Daniel Braniss]

> On 7 Apr 2018, at 7:21, Julian Elischer  wrote:
> 
> running on *some* Dell servers the serial console looks messed up at the time 
> of the FreeBSD menu.
> it looks like it's dropping (or adding? but that's less likely) characters.
> 
>  |  5. [K]ernel: kernel (1 of 2)   |  .- .-.
>  |  6. Configure Boot [O]ptions... |2  --| y/   -.   -/`   -o/
>  |137. Select Boot [E]nvironment...| `:`  `:` 
> ::/sy++:.
>  | H| .-- `--. --  /6H`:  
> :`
>  | | .---..
> 
> IS there an RTS/CTS input we should be attending to?
> 
> I will add that some of the other modules (e.g. the mfi raid setup section) 
> also get affected,
> so it's not just a bug in our code.

I’m using Serial-Over-LAN via ipmi/drac and am noticing this too on a Dell 
C6220,
don’t know when this started though, It’s only recently that I’m working on
this kind of hosts. It drives the xterm/rxvt crazy, but it’s only the output 
from the
boot/loader, once the kernel takes over, all is back to normal. the serial 
speed is
set to 115200, but changing it as far as i remember did not help. will try 
lowering soon.
I had to disable the menu to get some sense of the output, and usually have to 
hit ^B to remove most of the
garbage.



___
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: Testing requested: Hybrid ISO/USB boot

[O'Connor, Daniel]

> On 24 Mar 2018, at 07:31, Benno Rice <be...@freebsd.org> wrote:
> I think I’ve addressed this in this revision:
> 
> https://svnweb.freebsd.org/changeset/base/331463 
> <https://svnweb.freebsd.org/changeset/base/331463>
> 
> And I’ve regenerated the image here:
> 
> https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz 
> <https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz>

Hi Benno,
I tried this image on a Supermicro SYS-5019S-M (X11SSH-Fmotherboard) and it 
boots both ways (USB was via a USB stick, ISO was via the IPMI CD emulation 
with the Java JNLP applet)

The USB way booted legacy and the CD emulation booted UEFI (not sure if that's 
significant).

I also tried renaming it to .img and then telling the JNLP applet it was a hard 
disk image but the BIOS didn't detect it.

It also has a 'Web ISO' option but I can't figure out how you're supposed to 
enter a URL so I couldn't try it.

Thanks for the work!

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: devdmatch: Can't read linker file.

[Daniel Braniss]

> On 13 Mar 2018, at 19:12, Edward Napierala <tr...@freebsd.org> wrote:
> 
> I think it's only needed for kernels that are cross-built.  That's due to
> kldxref(8) being unable to handle kernels for other architectures.
> 
my case exactly.

> 2018-03-13 13:34 GMT+00:00 Warner Losh <i...@bsdimp.com 
> <mailto:i...@bsdimp.com>>:
> I wonder why that isn't the default, or why the linker.hints isn't at least
> created by the make installkernel step...
> 
> Warner
> 
> On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała <tr...@freebsd.org 
> <mailto:tr...@freebsd.org>>
> wrote:
> 
> > FWIW, it seems to be a common problem, see https://reviews.freebsd.org/ 
> > <https://reviews.freebsd.org/>
> > D14534.
> >
> > On 0312T1027, Warner Losh wrote:
> > > Well, is there a /boot/kernel/linker.hints?
> > >
> > > Warner
> > >
> > > On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss <da...@cs.huji.ac.il 
> > > <mailto:da...@cs.huji.ac.il>>
> > wrote:
> > >
> > > > Hi,
> > > > the above i get on arm/nanopi-neo. (it’s the only platform I run
> > current
> > > > :-)
> > > >
> > > > cheers,
> > > > danny
> > > >
> > > >
> > > ___
> > > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing 
> > > list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> > > <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> > freebsd.org <http://freebsd.org/>"
> >
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> <mailto: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: devdmatch: Can't read linker file.

[Daniel Braniss]

> On 12 Mar 2018, at 18:27, Warner Losh <i...@bsdimp.com> wrote:
> 
> Well, is there a /boot/kernel/linker.hints?
> 
no, but that was enough to do a grep and the run kldxref.

thanks,
danny
PS: just remembered: reach out and grep someone

> Warner
> 
> On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss <da...@cs.huji.ac.il 
> <mailto:da...@cs.huji.ac.il>> wrote:
> Hi,
> the above i get on arm/nanopi-neo. (it’s the only platform I run current :-)
> 
> cheers,
> danny
> 
> 

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

devdmatch: Can't read linker file.

[Daniel Braniss]

Hi,
the above i get on arm/nanopi-neo. (it’s the only platform I run current :-)

cheers,
danny

___
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: USB stack

[O'Connor, Daniel]

> On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com> wrote:
>> What is an "LG v30"?
>> 
> It's a smartphone from LG and only supports USB2 speed.  The reported
> transfer rate is no big surprise.

OK thanks.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: USB stack

[O'Connor, Daniel]

> On 3 Jan 2018, at 11:56, blubee blubeeme <gurenc...@gmail.com> wrote:
> On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel <dar...@dons.net.au> wrote:
> 
> 
> > On 3 Jan 2018, at 11:31, blubee blubeeme <gurenc...@gmail.com> wrote:
> > Does FreeBSD current USB stack support usb >= 2.0 devices?
> 
> Absolutely.
> 
> > Testing out the USB devices support I get about 7.2-7.8 megabytes per
> > second which seems odd.
> 
> What sort of test? What sort of device? What sort of port?
> 
> What is the output of dmesg and usbconfig?
> 
> I transferred about 30GB of audio from laptop to Samsung usb class 10 usb 
> device connected to LG v30.
> 
> current usbconfig shows this:
> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) 
> pwr=SAVE (0mA)
> ugen0.3:  at usbus0, cfg=0 md=HOST 
> spd=HIGH (480Mbps) pwr=ON (500mA)
> ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL 
> (12Mbps) pwr=ON (100mA)

Ugh, your mail client has mangled things, oh well.

You missed posting the output of dmesg..

What is an "LG v30"?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: USB stack

[O'Connor, Daniel]

> On 3 Jan 2018, at 11:31, blubee blubeeme <gurenc...@gmail.com> wrote:
> Does FreeBSD current USB stack support usb >= 2.0 devices?

Absolutely.

> Testing out the USB devices support I get about 7.2-7.8 megabytes per
> second which seems odd.

What sort of test? What sort of device? What sort of port?

What is the output of dmesg and usbconfig?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ...

[Daniel Nebdal]

On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann <ohartm...@walstatt.org> wrote:
> Hello out there,
>
> I had to replace a HDD on a RAIDZ1 pool comprised from 4 HDDs, each 3 TB 
> (netto size of
> the pool is about 8-9 TB, the used amount is reported to be ~ 6TB).
>
> I just started the rebuild/resilvering process and watch the pool crwaling at 
> ~ 18 MB/s.
> At the moment, there is no load on the array, the host is a IvyBridge XEON 
> with 4 core/8
> threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to a on-board 
> SATA II (300
> MB/s max) Intel chip - this just for the record.
>
> Recently, I switch on the "sync" attribute on most of the defined pools's zfs 
> filesystems
> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused recently 
> in FreeBSD
> CURRENT's ZFS - this from a observers perspective only.
>
> When scrubbing, I see recently also reduced performance on the pool, so I'm 
> wondering
> about the low throughput at the very moment when resilvering is in progress.
>
> If the "perspective" of "zpool status" is correct, then I have to wait after 
> two hours
> for another 100 hours - ~ 4 days? Ups ... I think there is something badly 
> misconfigured
> or missing.
>
> The pool is not "tuned" in any very sophisticated way, since I trust the 
> kernels ability
> to scale automatically - if I'm not wrong for amd64 ...
>
> Are there any aspects to look at?
>
> Thanks in advance,
>
> Oliver
>
> --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


This is kind of to be expected - for whatever reason, resilvers seem
to go super slow at first and then speed up significantly. Just don't
ask me how long "at first" is - I'd give it several (more) hours.
I don't _think_ sync affects resilver speed (since that's a filesystem
level setting and the resilver happens at the block level), but that's
pure speculation.
The Tuning guide at https://wiki.freebsd.org/ZFSTuningGuide also
suggests a list of sysctls you can tweak, which could be worth a try:

### wiki
If you're getting horrible performance during a scrub or resilver, the
following sysctls can be set:

vfs.zfs.scrub_delay=0
vfs.zfs.top_maxinflight=128
vfs.zfs.resilver_min_time_ms=5000
vfs.zfs.resilver_delay=0

Setting those sysctls to those values increased my (Shawn Webb's)
resilver performance from 7MB/s to 230MB/s.
###



-- 
Daniel Nebdal
___
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: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error

[Daniel Kalchev]

> On 13 Dec 2017, at 21:39, O. Hartmann <o.hartm...@walstatt.org> wrote:
> 
> Am Wed, 13 Dec 2017 08:47:53 -0800 (PST)
> "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> schrieb:
> 
>>> On Tue, 12 Dec 2017 14:58:28 -0800
>>> Cy Schubert <cy.schub...@komquats.com> wrote:
>>> 
>>>> There are a couple of ways you can address this. You'll need to
>>>> offline the vdev first. If you've done a smartcrl -t long and if the
>>>> test failed, smartcrl -a will tell you which block it had an issue
>>>> with. You can use dd, ddrescue or dd_rescue to dd the block over
>>>> itself. The drive may rewrite the (weak) block or if it fails to it
>>>> will remap it (subsequently showing as reallocated).
>>>> 
>>>> Of course there is a risk. If the sector is any of the boot blocks
>>>> there is a good chance the server will hang.  
>>> 
>>> The drive is part of a dedicated storage-only pool. The boot drive is a
>>> fast SSD. So I do not care about this - well, to say it more politely:
>>> I do not have to take care of that aspect.
>>> 
>>>> 
>>>> You have to be *absolutely* sure which the bad sector is. And, there
>>>> may be more. There is a risk of data loss.
>>>> 
>>>> I've used this technique many times. Most times it works perfectly.
>>>> Other times the affected file is lost but the rest of the file system
>>>> is recovered. And again there is always the risk.
>>>> 
>>>> Replace the disk immediately if you experience a growing succession
>>>> of pending sectors. Otherwise replace the disk at your earliest
>>>> convenience.  
>>> 
>>> The ZFS scrubbing of the volume ended this morning, leaving the pool in
>>> a healthy state. After reboot, there was no sign of CAM errors again.
>>> 
>>> But there is something else I'm worried about. The mainboard I use is a 
>>> 
>>> ASRock Z77 Pro4-M.
>>> The board has a cripple Intel MCP with 6 SATA ports from the chipset,
>>> two of them SATA 6GB, 4 SATA II, and one additional chip with two SATA
>>> 6GB ports:
>>> 
>>> [...]
>>> ahci0@pci0:2:0:0:   class=0x010601 card=0x06121849 chip=0x06121b21
>>> rev=0x01 hdr=0x00 vendor = 'ASMedia Technology Inc.'
>>>device = 'ASM1062 Serial ATA Controller'
>>>class  = mass storage
>>>subclass   = SATA
>>>bar   [10] = type I/O Port, range 32, base 0xe050, size 8, enabled
>>>bar   [14] = type I/O Port, range 32, base 0xe040, size 4, enabled
>>>bar   [18] = type I/O Port, range 32, base 0xe030, size 8, enabled
>>>bar   [1c] = type I/O Port, range 32, base 0xe020, size 4, enabled
>>>bar   [20] = type I/O Port, range 32, base 0xe000, size 32, enabled
>>>bar   [24] = type Memory, range 32, base 0xf7b0, size 512,
>>>enabled
>>> [...]
>>> 
>>> Attached to that ASM1062 SATA chip, is a backup drive via eSATA
>>> connector, a WD 4 TB RED drive. It seems, whenever I attach this drive
>>> and it is online, I experience problems on the ZFS pool, which is
>>> attached to the MCP SATA ports.  
>> 
>> How does this external drive get its power?  Are the earth grounds of
>> both the system and the external drive power supply closely tied
>> togeather?  A plug/unplug event with a slight ground creep can
>> wreck havioc with device operation.
> 
> The external drive is housed in a external casing. Its PSU is de facto with 
> the same
> "grounding" (earth ground) as the server's PSU, they share the same power 
> plug at its
> point were the plug is comeing out of the wall - so to speak.

Most external drive power supplies are not grounded. At least none I ever saw 
had grounded plugs for the mains cable. Might be, yours has it...

Worth checking anyway.

Daniel


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