Re: bsdinstall partition error when installing to nvme

[tech-lists]

Hello,

On Sat, Apr 23, 2022 at 07:51:10AM +0200, Alfonso S. Siciliano wrote:


Thank you for the report,


Reading "autopart failed -5", probably you chose "Auto UFS Guided Disk",


Yes, this is true, it's what was tried first. 


I found a problem with Auto Partitioning in CURRENT.
This should solve: .

However, to be sure, you could reinstall choosing "Manual" Partitioning
to understand if the cause is "nvme" or "bsdinstall".


I *think* i tried this. I remember thinking "hmm why is autopart 
invoked in a manual context" but I can't be 100% sure, and can't test

again until i'm in a position to install to nvme hardware again.

But thanks for looking at this and fixing it.
--
J.


signature.asc
Description: PGP signature

Re: bsdinstall partition error when installing to nvme

[tech-lists]

On Fri, Apr 22, 2022 at 10:16:07PM +, Glen Barber wrote:


Yes, please do, in case it is indeed related.


done!

thanks,
--
J.


signature.asc
Description: PGP signature

Re: bsdinstall partition error when installing to nvme

[tech-lists]

Hi Glen,

On Fri, Apr 22, 2022 at 09:36:45PM +, Glen Barber wrote:


This may be related to:

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


Do you think it'd be useful to the ticket if I added my
error?

My context was a little different (current/14 and bsdinstall)

thanks,
--
J.


signature.asc
Description: PGP signature

bsdinstall partition error when installing to nvme

[tech-lists]

Hi,

Attempting to install from: 
FreeBSD-14.0-CURRENT-amd64-20220421-b91a48693a5-254961-memstick.img


to brand-new hardware, the installer failed at the stage after where one
selects partition schema (so, GPT in this case) and UFS filesystem
with an error like (sorry to be paraphrasing this from memory as the 
hardware is no longer available)


"autopart failed -5"

I thought it might be down to it being a nvme stick. The hardware
in question is Crucial;CT1000P5PSSD8 1TB. Is this a known issue
with nvme? On that machine, this was the only "disk". Can
nvme be used as the primary disk on FreeBSD?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Chasing OOM Issues - good sysctl metrics to use?

[tech-lists]

Hi,

On Thu, Apr 21, 2022 at 07:16:42PM -0700, Pete Wright wrote:

hello -

on my workstation running CURRENT (amd64/32g of ram) i've been running
into a scenario where after 4 or 5 days of daily use I get an OOM event
and both chromium and firefox are killed.  then in the next day or so
the system will become very unresponsive in the morning when i unlock my
screensaver in the morning forcing a manual power cycle.


I have the following set in /etc/sysctl.conf on a stable/13 workstation. 
Am using zfs with 32GB RAM.


vm.pageout_oom_seq=120
vm.pfault_oom_attempts=-1
vm.pageout_update_period=0

Since setting these here, OOM is a rarity. I don't profess to exactly know
what they do in detail though. But my experience since these were set
is hardly any OOM and big users of memory like firefox don't crash.
--
J.


signature.asc
Description: PGP signature

Re: POLLHUP detected on devd socket

[tech-lists]

On Fri, Jan 28, 2022 at 02:54:25AM +, tech-lists wrote:

On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote:


Will try to play with zfsd disabled, as suggested.


since reporting the issue and disabling zfsd, the problem
has not re-occurred so far at this time (28th Jan)


It's happened again. But with zfsd being disabled, it
meant I wasn't detecting the problem except by indirect 
means. Like "hm why isn't nginx working".


The problem is, one of the things that stops first is syslogd. 
So it's not recorded anywhere.


syslogd is loaded with these flags:

syslogd_enable="YES"
syslogd_flags="-ss"
syslogd_oomprotect="YES"

context is main-n252544-7406ec4ea99 on a rpi4b/8GB.
zfs-on-root. There is no microsd; it boots from usb3.

How would I debug this? In the meantime, I'm re-enabling
zfsd.

thanks,
--
J.


signature.asc
Description: PGP signature

Re: POLLHUP detected on devd socket

[tech-lists]

On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote:


Will try to play with zfsd disabled, as suggested.


since reporting the issue and disabling zfsd, the problem 
has not re-occurred so far at this time (28th Jan)


--
J.


signature.asc
Description: PGP signature

Re: POLLHUP detected on devd socket

[tech-lists]

On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote:


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.


I can try that, thanks for the suggestion.

Right now I'm thinking it's tied to zfsd, since disabling that
service I've not seen the issue.
--
J.


signature.asc
Description: PGP signature

POLLHUP detected on devd socket

[tech-lists]

Hi,

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, but 
   the 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.

--
J.


signature.asc
Description: PGP signature

Re: observations on Ryzen 5xxx (Zen 3) processors

[tech-lists]

Next thing to try is I guess to turn hyperthreading off
--
J.


signature.asc
Description: PGP signature

Re: observations on Ryzen 5xxx (Zen 3) processors

[tech-lists]

On Tue, Jan 04, 2022 at 07:20:08PM -0500, mike tancsa wrote:


I would for sure try a clean src.conf first and use that as a baseline. 
Also, someome mentioned trying

machdep.idle=spin

In /boot/loader.conf

But removing your src.conf optimizations would be the first place to try


Yeah, tried this just now but it made no difference.

No src.conf or make.conf and GENERIC (so, as -current, debugging kernel)
it's as vanilla as I can make it. Some ports will build 
(ports-mgmt/dialog4ports) but lang/perl5.32 and devel/llvm13 won't.


All the dependencies build - there's a lot of python there too, for llvm. 
They build and install fine. perl installed as a pkg installs fine.

I've not tried it but expect llvm13 to install from pkg fine.

They (perl5.32 & llvm13) won't build from ports, though. But they will
on a vm of the same version, just a different cpu (xenon)

--
J.


signature.asc
Description: PGP signature

Re: observations on Ryzen 5xxx (Zen 3) processors

[tech-lists]

On Tue, Jan 04, 2022 at 02:06:43PM +, tech-lists wrote:

Hello,

On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote:


There have been some reports on strange / unexpected things with Ryzen 5xxx
processors.  I think I have seen 5950X, 5900X and 5800X mentioned, not sure
about others.


Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo:

https://bsd-hardware.info/?probe=e67007df20

I've noticed a couple of oddities:

1. some ports won't build, but world builds and installs just fine (current/14)


Can't build lang/perl5.32. I have many vms running perl5.32 and they're not 
seeing any issues.
There's nothing in bugs suggesting there's an issue with this port right now.

The context is 14.0-CURRENT #0 main-n252119-dfa5a74357f amd64 1400046 1400046 
with a nodebug kernel.
The sources were built with these (/etc/src.conf):

KERNCONF=RYZEN5
WITH_CCACHE_BUILD="TRUE"
CCACHE_PREFIX=/usr/local/bin
CPUTYPE?=znver3 
TARGET_CPU_ARCH=znver3
WITH_MALLOC_PRODUCTION= 
WITH_LLVM_TARGET_ALL=

WITH_LLVM_BINUTILS=
WITH_KERNEL_RETPOLINE=
#
WITH_PIE=yes
WITH_BIND_NOW=yes
WITH_RETPOLINE=yes
WITH_SSP=yes
#
WITH_OPENSSL_KTLS=

I'm going to try building a new world next, this time with no /etc/src.conf, or 
a minimal one.

But for now, I'm seeing unexpected failures with ports that compile fine on 
other systems:

1. portstree last updated: Tue Jan 4 17:03:38 2022 +0100 version: 570114
2. no /etc/make.conf
3. in /usr/ports/lang/perl5.32:
   [i] make clean && make distclean && make rmconfig && make rmconfig-recursive
   [ii] make MAKE_JOBS_UNSAFE=yes -j1 fails here:

98 warnings generated.

cc -pthread -Wl,-E  -fstack-protector-strong -L/usr/local/lib -o 
miniperl  opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o d
ump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o 
pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o
 utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o 
numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o tim
 e64.o  miniperlmain.o  -lpthread -lm -lcrypt -lutil
 ld: error: undefined symbol: __dtraceenabled_perl___op__entry
 >>> referenced by perlmini.c
 >>>   perlmini.o:(perl_destruct)
 >>> referenced by perlmini.c
 >>>   perlmini.o:(perl_destruct)
 >>> referenced by perlmini.c
 >>>   perlmini.o:(perl_parse)
 >>> referenced 8 more times
 ld: error: undefined symbol: __dtrace_perl___sub__entry
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_call)

 ld: error: undefined symbol: __dtrace_perl___sub__return
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_call)

 ld: error: undefined symbol: __dtrace_perl___loading__file
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_load)

 ld: error: undefined symbol: __dtrace_perl___loaded__file
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_load)

 ld: error: undefined symbol: __dtrace_perl___op__entry
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_op)
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_op)

 ld: error: undefined symbol: __dtrace_perl___phase__change
 >>> referenced by util.c
 >>>   util.o:(Perl_dtrace_probe_phase)

 ld: error: undefined symbol: __dtraceenabled_perl___sub__entry
 >>> referenced by pp_hot.c
 >>>   pp_hot.o:(Perl_pp_leavesub)
 >>> referenced by pp_hot.c
 >>>   pp_hot.o:(Perl_pp_entersub)
 >>> referenced by pp_ctl.c
 >>>   pp_ctl.o:(Perl_cx_popsub)
 >>> referenced 6 more times
 cc: error: linker command failed with exit code 1 (use -v to see 
invocation)
 *** [lib/buildcustomize.pl] Error code 1

 make[2]: stopped in /usr/ports/lang/perl5.32/work/perl-5.32.1
 1 error

 make[2]: stopped in /usr/ports/lang/perl5.32/work/perl-5.32.1
 *** [do-build] Error code 1

 make[1]: stopped in /usr/ports/lang/perl5.32
 1 error

 make[1]: stopped in /usr/ports/lang/perl5.32
 *** [stage] Error code 2

 make: stopped in /usr/ports/lang/perl5.32
 1 error

 make: stopped in /usr/ports/lang/perl5.32

--
J.


signature.asc
Description: PGP signature

Re: observations on Ryzen 5xxx (Zen 3) processors

[tech-lists]

Hello,

On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote:


There have been some reports on strange / unexpected things with Ryzen 5xxx
processors.  I think I have seen 5950X, 5900X and 5800X mentioned, not sure
about others.


Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo:

https://bsd-hardware.info/?probe=e67007df20

I've noticed a couple of oddities:

1. some ports won't build, but world builds and installs just fine (current/14)
2. sometimes it "lags" a bit, but am not sure if it's the cpu, the board, the board+cpu, 
   the connection (it's offsite) or all three.


Please let me know if there are tests you'd like me to run.
--
J.


signature.asc
Description: PGP signature

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

[tech-lists]

On Sun, Jun 13, 2021 at 09:16:58PM +0200, Michael Gmelin wrote:




On 13. Jun 2021, at 20:50, Ronald Klop  wrote:

What do you have configured as prompt? Or shell startup script?
Does it contain a call to git?



I agree that this smells like a prompt that calls "git status" or something 
similar (when on the FreeBSD source tree on an rpi, 15 seconds feels about right for 
performing such a call).


Hi,

Yes, that was it! In .cshrc, I had not quoted some git aliases properly.
fixed that and now everything is normal. I need to remember ctrl-t

thanks
--
J.


signature.asc
Description: PGP signature

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

[tech-lists]

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
load: 0.11  cmd: git 79703 [running] 1.42r 1.28u 0.14s 13% 161384k
load: 0.18  cmd: git 79703 [running] 2.06r 1.91u 0.14s 18% 177460k
load: 0.18  cmd: git 79703 [running] 2.69r 2.52u 0.16s 24% 197724k
load: 0.18  cmd: git 79703 [running] 3.92r 3.74u 0.18s 34% 225796k
load: 0.18  cmd: git 79703 [running] 4.55r 4.32u 0.22s 37% 255252k
load: 0.18  cmd: git 79703 [running] 5.23r 4.99u 0.23s 40% 270948k
load: 0.18  cmd: git 79703 [running] 5.79r 5.53u 0.25s 46% 283704k
load: 0.18  cmd: git 79703 [running] 6.37r 6.09u 0.26s 47% 296864k
load: 0.18  cmd: git 79703 [running] 6.98r 6.69u 0.28s 48% 310828k
load: 0.18  cmd: git 79703 [running] 7.54r 7.23u 0.30s 53% 323440k
load: 0.32  cmd: git 79703 [running] 8.13r 7.81u 0.31s 54% 336756k
load: 0.32  cmd: git 79703 [running] 8.66r 8.34u 0.31s 59% 355228k
load: 0.32  cmd: git 79705 [running] 0.05r 0.04u 0.00s 0% 32984k
load: 0.32  cmd: git 79705 [running] 0.65r 0.57u 0.07s 5% 116316k
load: 0.32  cmd: git 79705 [running] 1.23r 1.13u 0.09s 11% 138692k
load: 0.32  cmd: git 79705 [running] 1.85r 1.73u 0.11s 16% 161508k
load: 0.32  cmd: git 79705 [running] 2.43r 2.28u 0.14s 22% 186196k
load: 0.32  cmd: git 79705 [running] 3.06r 2.90u 0.14s 26% 199808k
load: 0.32  cmd: git 79705 [running] 3.71r 3.52u 0.18s 30% 217844k

how weird is that??!

git isn't running:

# ps ax | grep git
79708  1  S+   0:00.00 grep git

--
J.


signature.asc
Description: PGP signature

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

[tech-lists]

On Sun, Jun 13, 2021 at 04:35:18PM +0100, Graham Perrin wrote:

On 13/06/2021 15:21, tech-lists wrote:

Hi,

context is main-n247177-dab84426a68


<https://cgit.freebsd.org/src/log/?qt=range=dab84426a68=main>


# uname -KU
1400018 1400018
# uname -mn
rpi4 arm64

disk is usb3-connected spinning rust. OS is on microsd

I'm seeing, recently, a roughly 15s wait for the prompt to return after
sudo su -

sudo is aliased to doas

The problem does not happen on stable/13-n245218-41d864457dd


<https://cgit.freebsd.org/src/log/?qt=range=41d864457dd=stable%2F13>
finds nothing, can you double-check that reference?


Hi,

% git -C /usr/src --no-pager log -1 --format=%cd origin/stable/13
Wed Jun 9 12:51:50 2021 +0200

% git -C /usr/src rev-list --first-parent --count stable/13
245219

% uname -v
FreeBSD 13.0-STABLE #0 stable/13-n245218-41d864457dd: Mon May 24
03:46:32 BST 2021

do you need me to check anything else?

thanks,
--
J.


signature.asc
Description: PGP signature

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

[tech-lists]

Hi,

context is main-n247177-dab84426a68
# uname -KU
1400018 1400018
# uname -mn
rpi4 arm64

disk is usb3-connected spinning rust. OS is on microsd

I'm seeing, recently, a roughly 15s wait for the prompt to return after
sudo su -

sudo is aliased to doas

The problem does not happen on stable/13-n245218-41d864457dd on the same
hardware. DNS works fine both for itself and externally. How can I
fix/debug further?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: OpenZFS imports, status update

[tech-lists]

On Wed, Jun 09, 2021 at 03:14:01AM +0200, tue...@freebsd.org wrote:

Try: git remote prune freebsd


unfortunately that didn't work either. In the end I rm -rf'd src and
just cloned the repo again
--
J.


signature.asc
Description: PGP signature

Re: OpenZFS imports, status update

[tech-lists]

On Tue, Jun 08, 2021 at 05:02:15PM -0600, Warner Losh wrote:

On Tue, Jun 8, 2021 at 4:58 PM Michael Tuexen <
michael.tue...@macmic.franken.de> wrote:


> On 9. Jun 2021, at 00:52, Warner Losh  wrote:
>
> Top posting...
>
> You can do a 'git remote purge freebsd' to reset the branch names, then
> you'll be able to do a normal pull.
Do you mean 'git remote prune freebsd'?



Yes.  Should have cut and paste instead of retyping it :(


root@desktop:/usr/src# git remote prune freebsd
fatal: 'freebsd' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

--
J.


signature.asc
Description: PGP signature

Re: OpenZFS imports, status update

[tech-lists]

Hi,

On Tue, Jun 08, 2021 at 04:52:43PM -0600, Warner Losh wrote:

Top posting...

You can do a 'git remote purge freebsd' to reset the branch names, then
you'll be able to do a normal pull.


This doesn't work for me. I use the anonssh method of updating the tree

% git remote -v
origin  ssh://anon...@git.freebsd.org/src.git (fetch)
origin  ssh://anon...@git.freebsd.org/src.git (push)

% gvs
srctree last updated: Wed Jun 9 02:19:47 2021 +0200 version: 245848

root@desktop:/root# cd /usr/src

root@desktop:/usr/src# git version
git version 2.31.1

root@desktop:/usr/src# git checkout stable/13
Already on 'stable/13'
Your branch is behind 'origin/stable/13' by 6922 commits, and can be 
fast-forwarded.
  (use "git pull" to update your local branch)

root@desktop:/usr/src# git remote purge freebsd
error: Unknown subcommand: purge
usage: git remote [-v | --verbose]
   or: git remote add [-t ] [-m ] [-f] [--tags | --no-tags] 
[--mirror=]  
   or: git remote rename  
   or: git remote remove 
   or: git remote set-head  (-a | --auto | -d | --delete | )
   or: git remote [-v | --verbose] show [-n] 
   or: git remote prune [-n | --dry-run] 
   or: git remote [-v | --verbose] update [-p | --prune] [( | 
)...]
   or: git remote set-branches [--add]  ...
   or: git remote get-url [--push] [--all] 
   or: git remote set-url [--push]   []
   or: git remote set-url --add  
   or: git remote set-url --delete  

-v, --verbose be verbose; must be placed before a subcommand

--
J.


signature.asc
Description: PGP signature

Re: tuning a zfs-mounted /var

[tech-lists]

On Sat, May 22, 2021 at 09:13:52PM +0200, Michael Gmelin wrote:


Make sure your pool (or at least the /var file system) has compression=lz4 and 
that atime is off, beyond that I wouldn’t bother to try to optimize manually 
there, unless you run a database like MySQL in /var/db/…, in which case setting 
a fixed record size might make sense.


excellent, this is the kind of thing i was lookling for

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Building ZFS-based VM images

[tech-lists]

On Thu, May 06, 2021 at 09:17:30AM -0600, Alan Somers wrote:

It's easy to build a UFS-based VM image just by setting WITH_VMIMAGES in
release.conf and running release.sh.  But what about ZFS-based images?
What's the easiest way to build a ZFS-based VM image, using a pool layout
similar to what the interactive installer uses?
-Alan


Hi, 


I don't know of a way with make release

Briefly, the way I do zfs on amd64 vm is (given you're already set up on bhyve):

a: truncate -s 64G filename.img
b: sh vmrun.sh -c 4 -m 32768M -t tap1 -d filename.img -i -I
freebsd-installer.iso vmname
c: run through the installer, selecting auto-zfs on the way.
d: stop the reboot, run the vmrun.sh again and omit the -i -I 
freebsd-installer.iso bit


(in my context, vmrun.sh is a symlink to
/usr/share/examples/bhyve/vmrun.sh in the dir i'm working in)

[section 22.7 FreeBSD as a Host with bhyve]
--
J.


signature.asc
Description: PGP signature

Re: should bsdinstall work?

[tech-lists]

On Wed, May 05, 2021 at 04:37:12PM +0200, Daniel Dowse wrote:

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.


Hi Daniel, thanks for yr input.

Managed to get a little further with your instructions, but now the error is 
"no root partition found. The root FreeBSD partition must have a mountpoint of '/'".


This happens after the disk is selected to install zfs-on-root

If I remove the zfs element from the script, re-run it then select auto
ufs, it gets a little further then fails at the point where it wants to
alter the MBR, with the same error message.

Maybe I'm going about this the wrong way. What I really need is an
installer. As far as I can tell, the only things available for
arm64.aarch64 for the rpi4 are bootable images - ie without installer.
--
J.


signature.asc
Description: PGP signature

Re: should bsdinstall work?

[tech-lists]

On Tue, May 04, 2021 at 02:37:30PM -0700, Mark Millard via freebsd-current 
wrote:


As I remember, I had to use bsdinstall's DISTRIBUTIONS
environment variable to pick what to download in order
to get MANIFEST to download. Otherwise I got just the 2
files (base.txz and kernel.txz) and the complaint that
you report.


Thanks Mark, setting DISTRIBUTIONS env var is next on the list
--
J.


signature.asc
Description: PGP signature

Re: should bsdinstall work?

[tech-lists]

On Wed, May 05, 2021 at 04:48:13AM +0100, tech-lists wrote:

On Tue, May 04, 2021 at 07:33:40PM -0700, Chris wrote:

Doesn't bsdinstall allow choosing different means of fetching the
dist files?


iirc it gives an ftp list. I tried with ftp.uk and ftp.de.freebsd.org.


Last I remember using it, I was able to choose ftp http(s),
etc... Making, or using an already matched MANIFEST is fairly trivial.


i'll try downloading a matched manifest by hand, next. Thanks for the
tip.


Clarified there's no http/https in the download list, just ftp urls

I tried running bsdinstall in one console and fetch in another

root@generic:/mnt/usr/freebsd-dist # fetch
ftp://ftp.uk.freebsd.org/pub/FreeBSD/snapshots/arm64/14.0-CURRENT/MANIFEST
MANIFEST   782  B 2145 kBps
00s
root@generic:/mnt/usr/freebsd-dist # fetch
ftp://ftp.uk.freebsd.org/pub/FreeBSD/snapshots/arm64/14.0-CURRENT/MANIFEST
fetch: MANIFEST: stat()
root@generic:/mnt/usr/freebsd-dist # fetch
ftp://ftp.uk.freebsd.org/pub/FreeBSD/snapshots/arm64/14.0-CURRENT/MANIFEST
fetch: MANIFEST: stat()
root@generic:/mnt/usr/freebsd-dist # 


bsdinstall bails with the error.

then: 
root@generic:/mnt/usr/freebsd-dist # ls -lah

ls: .: Not a directory
root@generic:/mnt/usr/freebsd-dist # 

clearly theres an issue with the bsdinstaller unmounting the chroot at 
/mnt at the wrong point. If bsdinstall *should* work, I'll raise a PR


looking at man 8 bsdinstall, theres loads of parameters I can set, and
there's also logging. will read all this before making a PR.
--
J.


signature.asc
Description: PGP signature

Re: should bsdinstall work?

[tech-lists]

On Tue, May 04, 2021 at 07:33:40PM -0700, Chris wrote:

Doesn't bsdinstall allow choosing different means of fetching the
dist files? 


iirc it gives an ftp list. I tried with ftp.uk and ftp.de.freebsd.org.


Last I remember using it, I was able to choose ftp http(s),
etc... Making, or using an already matched MANIFEST is fairly trivial.


i'll try downloading a matched manifest by hand, next. Thanks for the
tip.
--
J.


signature.asc
Description: PGP signature

Re: should bsdinstall work?

[tech-lists]

Hi,

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


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


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

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

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

--
J.


signature.asc
Description: PGP signature

should bsdinstall work?

[tech-lists]

Hi,

I've been trying to set up a boot-from-usb3 raspberry pi 4. I thought
i'd be able to do this by booting into latest current snapshot image for
arm64 rpi (written to microsd), and then running bsdinstall as root.

I can select the auto-zfs option then select the usb3 disk as
installation destination. The bsdinstall selects the sets and downloads
them, but then get the error:

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

also tried via release/13 image, same error. Looks like it's downloading
the files but then the installer can't see them, something like that.

the downloaded files are there:

root@generic:~ # ls -lah /mnt/usr/freebsd-dist/
total 187454
drwxr-xr-x  2 root  wheel 4B Apr  9 06:51 .
drwxr-xr-x  6 root  wheel 6B Apr  9 06:50 ..
-rw-r--r--  1 root  wheel   158M Apr  9 06:51 base.txz
-rw-r--r--  1 root  wheel25M Apr  9 06:51 kernel.txz
root@generic:~ # 


worth submitting a PR? or is bsdinstall legacy and I need to use some
other method. I've not tried releng/12.2 yet.

thanks,
--
J.


signature.asc
Description: PGP signature

Re: systat -swap to display large swap space users

[tech-lists]

Hello Hiro,

On Sat, Apr 10, 2021 at 08:36:04AM -0400, Yoshihiro Ota wrote:

Hi,

How about these now?
These include extra improvements to other parts of systat.

These patches create new files.
If you already applies previosly, please check and clean up new files.


Sorry to report that for the 13.0-RELENG patch, it didn't apply cleanly.
I've not tried the others yet.

I saved the attatchment, and then uploaded it to a pristine 13-RELENG
vm. This vm was made from
https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-amd64-dvd1.iso.xz

Once installed to a 256GB vm, spun the vm up and did the following:

1. install git from packages
2. cd /usr && git clone ssh://anon...@git.freebsd.org/src.git
3. cd src && git checkout releng/13.0

Then copied systat-swap-releng13.0.diff to /usr/src, then ran the
following in /usr/src:

patch < systat-swap-releng13.0.diff

output follows:

[...]

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/Makefile b/usr.bin/systat/Makefile
|index ca3f7ed72ce..bfbe1336d29 100644
|--- a/usr.bin/systat/Makefile
|+++ b/usr.bin/systat/Makefile
--
Patching file usr.bin/systat/Makefile using Plan A...
Hunk #1 failed at 5.
Hunk #2 failed at 16.
2 out of 2 hunks failed--saving rejects to usr.bin/systat/Makefile.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/devs.c b/usr.bin/systat/devs.c
|index b293796c2c7..87d04f989ea 100644
|--- a/usr.bin/systat/devs.c
|+++ b/usr.bin/systat/devs.c
--
Patching file usr.bin/systat/devs.c using Plan A...
Hunk #1 failed at 426.
Hunk #2 failed at 433.
2 out of 2 hunks failed--saving rejects to usr.bin/systat/devs.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/devs.h b/usr.bin/systat/devs.h
|index cbedd844290..79a44a6c3f5 100644
|--- a/usr.bin/systat/devs.h
|+++ b/usr.bin/systat/devs.h
--
Patching file usr.bin/systat/devs.h using Plan A...
Hunk #1 failed at 2.
Hunk #2 failed at 34.
2 out of 2 hunks failed--saving rejects to usr.bin/systat/devs.h.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/extern.h b/usr.bin/systat/extern.h
|index 6e3117bece4..322065f7931 100644
|--- a/usr.bin/systat/extern.h
|+++ b/usr.bin/systat/extern.h
--
Patching file usr.bin/systat/extern.h using Plan A...
Hunk #1 failed at 168.
1 out of 1 hunks failed--saving rejects to usr.bin/systat/extern.h.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/main.c b/usr.bin/systat/main.c
|index b5a19d381ad..b84351379f4 100644
|--- a/usr.bin/systat/main.c
|+++ b/usr.bin/systat/main.c
--
Patching file usr.bin/systat/main.c using Plan A...
Hunk #1 failed at 135.
Hunk #2 failed at 206.
2 out of 2 hunks failed--saving rejects to usr.bin/systat/main.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/pigs.c b/usr.bin/systat/pigs.c
|index d9f3f8d4ad1..879f6548d86 100644
|--- a/usr.bin/systat/pigs.c
|+++ b/usr.bin/systat/pigs.c
--
Patching file usr.bin/systat/pigs.c using Plan A...
Hunk #1 failed at 56.
Hunk #2 failed at 90.
Hunk #3 failed at 146.
3 out of 3 hunks failed--saving rejects to usr.bin/systat/pigs.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/proc.c b/usr.bin/systat/proc.c
|new file mode 100644
|index 000..0def660d2dc
|--- /dev/null
|+++ b/usr.bin/systat/proc.c
--
(Creating file usr.bin/systat/proc.c...)
Patching file usr.bin/systat/proc.c using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/subs.h b/usr.bin/systat/subs.h
|new file mode 100644
|index 000..e4184be8dae
|--- /dev/null
|+++ b/usr.bin/systat/subs.h
--
(Creating file usr.bin/systat/subs.h...)
Patching file usr.bin/systat/subs.h using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/usr.bin/systat/swap.c b/usr.bin/systat/swap.c
|index fc44db7d7d4..44a321a5705 100644
|--- a/usr.bin/systat/swap.c
|+++ b/usr.bin/systat/swap.c
--
Patching file usr.bin/systat/swap.c using Plan A...
Hunk #1 

Re: systat -swap to display large swap space users

[tech-lists]

Hi,

On Fri, Apr 02, 2021 at 08:12:14PM -0400, Yoshihiro Ota wrote:

Hi,

We do not seem to have a nice way to see current swap space usage per process.
I updated systat to use libprocstat to obtain such infomation and display
along with swap devise/file stats.


Unfotunately your patch gets rejected on recent stable/13 and main/14

--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Fri, Mar 19, 2021 at 09:37:30PM +, Rick Macklem wrote:

J. wrote:

on the (main/14) server, /etc/rpc.tlsservd was not already there; I had
to create it. Is this correct?

version is main-n245454

I'll admit I have no idea what n245454 means, but the daemons were
committed to main on Feb 18, 2021.
Installing them from ports should be fine.


Hi Rick,

Does the recent reloval of wireguard have any bearing on ktls? The
reason I ask is that when I happened to see stable/13 updating, it
removed the if_wg stuff and also some nfs stuff.

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 11:07:23PM +, tech-lists wrote:

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:

If you want to try NFS-over-TLS, see this:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt



Please let us know if you try it, rick


Hi,

on the (main/14) server, /etc/rpc.tlsservd was not already there; I had
to create it. Is this correct?

version is main-n245454
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Wed, Mar 17, 2021 at 08:39:02PM +, Rick Macklem wrote:


Make sure you've done the following:
ktls_ocf - is loaded
these sysctls are set to 1
kern.ipc.tls.enable
kern.ipc.mb_use_ext_pgs


[on stable/13]

% sysctl kern.ipc.tls.enable kern.ipc.mb_use_ext_pgs
kern.ipc.tls.enable: 1
kern.ipc.mb_use_ext_pgs: 1

% kldstat | grep ktls
71 0x0135300025520 ktls_ocf.ko
% 


% sysctl -a | fgrep kern.ipc.tls.stats
kern.ipc.tls.stats.ocf.retries: 0
kern.ipc.tls.stats.ocf.separate_output: 0
kern.ipc.tls.stats.ocf.inplace: 0
kern.ipc.tls.stats.ocf.tls13_gcm_crypts: 0
kern.ipc.tls.stats.ocf.tls12_gcm_crypts: 0
kern.ipc.tls.stats.ocf.tls11_cbc_crypts: 0
kern.ipc.tls.stats.ocf.tls10_cbc_crypts: 0
kern.ipc.tls.stats.switch_failed: 0
kern.ipc.tls.stats.switch_to_sw: 0
kern.ipc.tls.stats.switch_to_ifnet: 0
kern.ipc.tls.stats.failed_crypto: 0
kern.ipc.tls.stats.corrupted_records: 0
kern.ipc.tls.stats.active: 0
kern.ipc.tls.stats.enable_calls: 535
kern.ipc.tls.stats.offload_total: 0
kern.ipc.tls.stats.sw_rx_inqueue: 0
kern.ipc.tls.stats.sw_tx_inqueue: 0
kern.ipc.tls.stats.threads: 4
% 


now to try setting up the nfs thing
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Tue, Mar 16, 2021 at 11:46:27PM +, Rick Macklem wrote:


Well, if you do "sysctl -a | fgrep kern.ipc.tls.stats" and it is working,
you should see the count for at least one of the "crypts" ticking up.
If they are all zero, it isn't working. That might depend on the apps
or setup and does not necessarily indicate broken.


OK. it's "not working" by those criteria on the stable/13 rpi4. 
This one has mutt (imaps) and lynx (https) installed. mutt appears to
use tlsv1.3 to connect with my email provider. 


Trying the nfs-over-tls should definitely test it. When it works, the
data on the wire after the first couple of Null RPCs is encrypted.
Also, if you start the daemons with "-v", 


This is what i'll try once buildworld etc completes on the main/14 rpi4.
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:


If you want to try NFS-over-TLS, see this:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Please let us know if you try it, rick


Hi,

I'm going to try this with 2x rpi4 machines, client on stable/13 and
server on main/14. both have zfs.

--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:


Alan explains how to set it up, below.
However, I thought I'd note that maybe one person has tested KTLS
on arm64, so you should consider doing this for test purposes only.
If you do do some testing, please post with your results,
success or failure.


It's present in current kernels for both 13 and 14, amd64 and aarch64.
However, it's not present in 13's openssl.  To use it, you must either
rebuild world with  WITH_OPENSSL_KTLS=YES in /etc/src.conf,



Doing it this way means that everything linked to OpenSSL will use
it. Probably a better testsituation, but expect at least the apache
server to break. (Most breakage was fixed by a recent patch to the
serf library, but I think the apache server is still broken.


OK, it's been built and all ports recompiled and reinstalled. Things 
that use openssl on this machine are mutt (imaps) lynx (https) and 
nginx (https) and py-certbot. They all seem to work. How would I test?


thanks,
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 11:07:23PM +, tech-lists wrote:

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:


Alan explains how to set it up, below.
However, I thought I'd note that maybe one person has tested KTLS
on arm64, so you should consider doing this for test purposes only.
If you do do some testing, please post with your results,
success or failure.


will do. The end-point I want is to have the arm64 machine accessible
externally for wireguard-based vpn.


ok, upgraded to stable/13-n244890-4e535a1ba72 with ktls. now, need to
rebuild the poudriere instance and rebuild all installed ports.

--
J.




--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:


Alan explains how to set it up, below.
However, I thought I'd note that maybe one person has tested KTLS
on arm64, so you should consider doing this for test purposes only.
If you do do some testing, please post with your results,
success or failure.


will do. The end-point I want is to have the arm64 machine accessible
externally for wireguard-based vpn. 


Doing it this way means that everything linked to OpenSSL will use
it. Probably a better testsituation, but expect at least the apache
server to break. (Most breakage was fixed by a recent patch to the
serf library, but I think the apache server is still broken.


I have latest serf installed with nginx. The machine, a rpi4/8GB, builds
its ports with poudriere. I have WITH_OPENSSL_KTLS= set in /etc/src.conf
and it's building a new world now.


If you want to try NFS-over-TLS, see this:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt



Please let us know if you try it, rick


yep, I'll try that too and post results here.

thanks :D
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Thu, Mar 11, 2021 at 03:42:55PM +, Rick Macklem wrote:

I'm going to cheat and top post (the discussion looks
pretty convoluted).

- The kernel must be built with "options KERN_TLS"
- OpenSSL must be built with KTLS enabled
- These two sysctls need to be set to 1
  kern.ipc.tls.enable
  kern.ipc.mb_use_ext_pgs


Hello,

I'd like to try ktls but have found the following:

On AMD64 (stable/13) this option is present in the GENERIC kernel 
of world built about a month ago: stable/13-n244496-618dee60231 
and openssl version is 1.1.1i-freebsd


On ARM64 (stable/13) it's *not* present in a world built earlier 
today from stable/13-n244876-0b45290603b. Here, the openssl version 
is 1.1.1j-freebsd


On another ARM64 (main/14) it *is* present in main-n245445-07564e17620 
built with sources from the 11th March. openssl is 1.1.1j-freebsd here 
as well.


I'd like to have it (ktls) available on the ARM64 
stable/13-n244876-0b45290603b. Is it just a matter of adding the option, 
and then the sysctls become available? Is it "better" with openssl[-devel] 
in ports or openssl in base?


thanks,
--
J.


signature.asc
Description: PGP signature

Re: 13-stable compile error when drm-kmod installed

[tech-lists]

On Wed, Feb 10, 2021 at 11:15:58AM +, M - Krasznai András wrote:

2.)several applications (multitail just to mention one of them) 
complain about missing ncurses libraries, e.g. libpanelw.so.5, etc. 
which are not missing from the january-29 snapshot of FreeBSD 
13-stable, that is after installing from the snapshot and installing 
the usual set of applications they do not complain about the missing 
libraries before updating world and the kernel.


Hi,

I caught this too, the ncurses thing. What I'm having to to is to
buildworld/installworld stable/13 and from there, recompile all my ports
while making sure there is nothing defined with ncurses in
/etc/make.conf.
--
J.


signature.asc
Description: PGP signature

Re: gib/em driver problems?

[tech-lists]

On Wed, Feb 03, 2021 at 06:40:50PM -0800, joe mcguckin wrote:
I went out and purchased a PCIe ethernet card - it uses the em driver. 
The system boots and it is em0.


It works fine in 100Mb mode, but in gigabit mode, it does not pass any 
traffic although ifconfig reports

the card as active and that it has negotiated 1000BTX full duplex.

I have tried plugging both the igb and em cards into 2 different switches 
with the same result.


Hi,

Try manually setting the card's speed to gigabit mode, instead of it
auto-negotiating. Speaking from experience, I have known some cards to
show either packet loss or just not work at all if the speed isn't
nailed up when they are talking to some switches.
--
J.


signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[tech-lists]

On Mon, Feb 01, 2021 at 05:13:42PM -0800, Rodney W. Grimes wrote:


One could build your own local pkg repository that contained pkg
and what ever other pkg's are needed during a make release and
modify the /etc/pkg/FreeBSD.conf file to point at it as a way
to work around this .


Thanks for the suggestion, might try that. I guess here you're thinking
poudriere?

--
J.


signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[tech-lists]

On Mon, Feb 01, 2021 at 09:27:44PM +, Glen Barber wrote:

On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:

Found
A pre-built version of pkg could not be found for your system.
Consider changing PACKAGESITE or installing it from ports:
'ports-mgmt/pkg'.

root@generic:/usr/src/release # which pkg
/usr/sbin/pkg



This is because the 14.0-CURRENT packages for arm64 take a significant
amount of more time to build than x86.


Hi,

Is there a way of making it use the pkg which is already installed on the system
running make release?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[tech-lists]

Hello,

I also tried to build a release and failed. My context is different to
yours, though. The failure error is different. Just thought I'd mention
it as "make release on -current is broken for me as well". In my
context, it ignores the installed pkg and tries, and fails to get a
-current pkg binary from the repos.

Context is raspberry pi4/8GB
git version is src.git as of 30/01/21 evening UTC

command used was: 
root@generic:/usr/src/release # sh release.sh -c arm64/RPI.conf


error:
--- installdirs-CONFSDIR ---
installing DIRS CONFSDIR
install -N /scratch/usr/src/etc  -d -m 0755 -o root  -g wheel
/scratch/etc/pkg
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
Bootstrapping pkg from
pkg+http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest, please wait...
pkg: Error fetching
http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest/Latest/pkg.txz: Not
Found
A pre-built version of pkg could not be found for your system.
Consider changing PACKAGESITE or installing it from ports:
'ports-mgmt/pkg'.

root@generic:/usr/src/release # which pkg
/usr/sbin/pkg

--
J.


signature.asc
Description: PGP signature

trying to make release with git-derived 14-current

[tech-lists]

Hi,

I'm trying to make release with -current on a rpi4b/8GB. Basically, I
have a working rpi4B/8GB with a no-debug kernel running -current.
However, release(7) says a lot about svn and nothing about git.

What's the method with git?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Getting /usr/src to match specific git hash?

[tech-lists]

On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote:

From: Steve Kargl 
Subject: Getting /usr/src to match specific git hash?
Date: Sat, 23 Jan 2021 19:58:52 -0800


Suppose one has an empty /usr/src.

Suppose further that one had to re-install a 32-bit
i386-*-freebsd with the 24 Dec 2020 image available
from freebsd.org.

uname -a for the booted kernel shows

% uname -a
FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \
3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386

How does one use git to pull the exact sources that match
this specifc kernel?


cd /usr
git clone https://git.freebsd.org/src.git
cd src
git checkout 3cc0c0d66a0


I have the exact same issue. The installation I have is:

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

The method described doesn't work for me for some reason:

[...]
root@rpi4:/usr # git clone https://git.freebsd.org/src.git
Cloning into 'src'...

remote: Enumerating objects: 377505, done.
remote: Counting objects: 100% (377505/377505), done.
remote: Compressing objects: 100% (26583/26583), done.
remote: Total 3831969 (delta 371848), reused 350922 (delta 350922), pack-reused 
3454464
Receiving objects: 100% (3831969/3831969), 1.14 GiB | 6.28 MiB/s, done.
Resolving deltas: 100% (3034679/3034679), done.
Updating files: 100% (85162/85162), done.
root@rpi4:/usr # cd src
root@rpi4:/usr/src # git checkout 2ed50808d2b 
error: pathspec '2ed50808d2b' did not match any file(s) known to git


thanks,
--
J.


signature.asc
Description: PGP signature

Re: using git to get a particular version of src

[tech-lists]

On Mon, Jan 25, 2021 at 04:31:13PM +, tech-lists wrote:

Hi,

I have this version installed:

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

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

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


OOPS sorry seems this exact same q was asked/answered earlier, pls ignore

thanks
--
J.


signature.asc
Description: PGP signature

using git to get a particular version of src

[tech-lists]

Hi,

I have this version installed:

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

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

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


thanks,
--
J.


signature.asc
Description: PGP signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[tech-lists]

On Mon, Jan 04, 2021 at 08:47:28PM +0100, Michal Meloun wrote:


Moreover mergemaster is still officially documented and recommend as
only right method in FreeBSD handbook. See
https://www.freebsd.org/doc/handbook/makeworld.html.
World is moving, we may have new tools but each deprecation should be,
in this order:
1) well announced
2) adjusted in the handbook
3) implemeted


Really +1 to this, times a thousand. Especially the 2nd point which I think
I'd be right in thinking is the source of truth? It also talks extensively 
about svn and yet 12-stable has been on git for a month nearly, and the svn 
repo has not been updated since. Not even a hint suggesting the new process, 
that the indicated process is depreciated, or a link to the newer 
process/workflow.


--
J.


signature.asc
Description: PGP signature

Re: rc.d/zpool runs before ada(4) attaches

[tech-lists]

On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote:

On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:


You can define these in /boot/loader.conf:
#kern.cam.boot_delay="1" # Delay (in ms) of root mount for CAM
bus
#kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI

Maybe that helps.

Ronald.



Those settings control waiting before mounting root.  Harry's problem
is that root is mounted quickly, before other drives are ready for zfs.

The zpool script waits for 'disks'.  It would be nice if the cam
subsystem had something like a sysctl it set to indicate when initial
probing for disks was done, then there could be an rc.d/camprobe script
with 'PROVIDE: disks' which waits for the probing to complete.

-- Ian


kern.cam.boot_delay should still fix it because what is required is a delay
while the devices (all of the disks, zfs or not) get ready. Because root 
has to happen before disks/zfs. 
--

J.


signature.asc
Description: PGP signature

Re: firewall choice

[tech-lists]

On Fri, Nov 27, 2020 at 06:11:43PM -0500, grarpamp wrote:

[...lots...]

OK thanks for that looks like I've got some reading to do
--
J.


signature.asc
Description: PGP signature

Re: possible usb3-connected hard drive spin down causing lag

[tech-lists]

On Fri, Nov 27, 2020 at 04:34:24PM +0100, Ronald Klop wrote:


Mind to share these tips, so I can use them on my RPI4? ;-)


sure!

I'll write up a simple site later, but in summary this is what 
I've done subsequent to the initial setup. E, if it breaks you 
get to keep both bits, no guarantees etc etc. In no particular order:


1. in /boot/msdos/config.txt there's this:
over_voltage=6
arm_freq=2000
sdram_freq_min=3200

[I use a FLIRC case to keep it cool. you *must* use cooling for this.
Max temps I'm seeing under very heavy compiling (it runs poudriere)
is 72 degC in 25 degC ambient]

2. /usr/src /usr/ports /usr/local /usr/obj /home /var/cache/ccache
are all on the usb3 disk, seperate datasets.

3. swap is 16GB and is the first partition on the usb3 disk

4. for compiling, ccache is a must.

5. set tmp to tmpfs in /etc/fstab. I use 1GB like this:
tmpfs /tmp tmpfs rw,mode=1777,size=1024m 0 0

6. make things like mutt use this /tmp

7. enable powerd and on bootup. Make it almost always use the
overclocked speed like this in /etc/rc.conf
powerd_enable="YES"
powerd_flags="-r 1"

This makes it run @ 2GHz always without needing to set something like 
boost_turbo.

8. in /etc/sysctl.conf:
vfs.read_max=128  # default 64

9. compile mutt with kyotocabinet which uses (I think) memory mapping for cache
lookups things like that. Faster than on-disk.

10. Look up the spec of yr usb3 connected device. Does it have 4k sectors?
If it does, if you're using zfs make sure vfs.zfs.min_auto_ashift=12 in
/etc/sysctl.conf

11. if you do compile stuff it'd be worth using -j3 if you want reasonably 
responsive
interactive use from the pi while it's compiling.

Like I've said, this isn't even guaranteed to work. All I can say is it's
whats working on my rpi4/8GB now and I'm very happy with it.

--
J.


signature.asc
Description: PGP signature

Re: firewall choice

[tech-lists]

On Fri, Nov 27, 2020 at 06:17:53AM -0500, grarpamp wrote:

What's the "best" [1] choice for firewalling these days, in the list's opinion?
There's pf, ipf and ipfw.


This question comes up over years.

Consider starting and joining with people to create
a comparison page on the FreeBSD Wiki,
both a feature / capability comparison table,
and contextual paragraphs.
A mini project like that can help many users
and add their researches to it.


I'd be happy to if I knew where to start/how to start/is there a guide.
--
J.


signature.asc
Description: PGP signature

firewall choice

[tech-lists]

Hi,

What's the "best" [1] choice for firewalling these days, in the list's opinion?

There's pf, ipf and ipfw. Which is the one being most recently 
developed/updated?
I'm used to using pf, have done for over a decade. But OpenBSD's pf has diverged 
a lot more from when it first came across. There seems to be a lot more options.

Is FreeBSD's pf being actively developed still?

ipfw seems a lot more syntatically complex than pf. Is it more capable also?
I know nothing about ipf yet.

[1] up-to-date, versatile, low overhead, high throughput, IPv6-able,
traffic shaping/queueing

thanks,
--
J.


signature.asc
Description: PGP signature

Re: possible usb3-connected hard drive spin down causing lag

[tech-lists]

Hi,

It seems the issue wasn't with the hardware or the connection.
I use mutt and it's the program that was slowing everything down,
and that was down to me using new mutt with my old config. The whole
pause for 5 seconds thing was due to it scanning gigabytes of email each 
time it woke up. The fix was to review the config and change a couple of 
settings. Now there's no delay (well there is a bit but only because it's 
scanning the folders it's told to for new mail).


But looking at a hardware cause wasn't in vain. On the way to the solution, 
found a few tips through here that sped up the system generally, and learned 
a bit. So now I have a *really quick* raspberry pi4 which is rock-solid 
stable, so thanks :D


--
J.


signature.asc
Description: PGP signature

Re: possible usb3-connected hard drive spin down causing lag

[tech-lists]

On Thu, Nov 26, 2020 at 07:37:47PM +0100, Dimitry Andric wrote:

In this case it's about ATA commands being passed though the USB bridge.
Does "camcontrol identify daX" fail in your case too?

I have used quite a bunch of different USB disks, mostly from WD or
Seagate, and these come with varying qualities of USB-SATA bridges in
them. But all of them work with "camcontrol identify".


With my usb3 powered disk, camdontrol identify da0 works

some features: support  enabled value
advanced power management  yes  yes 254/0xFE
power management   yes  yes
microcode download yes  yes

loads of others

thanks for posting that script btw

--
J.


signature.asc
Description: PGP signature

possible usb3-connected hard drive spin down causing lag

[tech-lists]

Hi,

I have a usb3-connected harddrive. dmesg shows this:
[...]
da0:  Fixed Direct Access SPC-4 SCSI device
[...]

running current-r367806-arm64

I think it might be auto-spinning-down or auto-sleeping. It's
making initial interaction lag of 2-3 seconds. Is there a 
sysctl or something somewhere where I can tell it to never 
sleep? Or is that something I'd need to contact the 
manufacturer about? Or is there an alternative strategy 
like tmpfs. It's not a "green" drive but I guess it might

be "green" in that it's usb3 powered.

I have vfs.read_max=128 in /etc/sysctl.conf
zdb has ashift=12

In case it's relevant, the filesystem on the disk is zfs. Once
"woken up", inferaction is quick, as expected. 


thanks,
--
J.


signature.asc
Description: PGP signature

Re: git tools for building in base?

[tech-lists]

Hi,

On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote:

On Tue, Nov 24, 2020 at 2:19 PM tech-lists  wrote:


As subject - what will there be in base to interact with the new git repo?
I mean, right now, for svn there is svnlite. What for git?


'pkg add git' is your choice now.


Shouldn't it be in base before the move to git?


We will have got (from OpenBSD: Game Of Trees) in the future. It isn't
quite there yet, however, so it's not in base. 


Do you agree that this situation is a bad look for an *operating system* ?
Having to depend on a third-party tool to stay up-to-date and secure.

In multiple locations it is said that installing a port is *at your own 
risk*. Personally, I'd like the official updating tool to have had the 
same level of analysis (and so the same level of "risk") on it as the base OS, 
(and also be under the same licence).


I mean, shouldn't all the basic tools be present in an OS, at least in 
order to update it? And *then* migrate to the update method?


When we migrated from CVS to Subversion, we didn't grow svnlite in 
the base for many months after the conversion.


A mistake then and a mistake now with svn to git IMO.
--
J.


signature.asc
Description: PGP signature

git tools for building in base?

[tech-lists]

Hi,

As subject - what will there be in base to interact with the new git repo?
I mean, right now, for svn there is svnlite. What for git?

Shouldn't it be in base before the move to git? 


thanks,
--
J.


signature.asc
Description: PGP signature

Re: in -current is svn still canonical?

[tech-lists]

On Tue, Nov 17, 2020 at 10:57:51AM -0700, Warner Losh wrote:

For now, though, you might want to look at
https://github.com/bsdimp/freebsd-git-docs/ for the docs we do have,
especially
https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md which
should answer most of your questions.


Thanks for posting this. May I suggest that it is linked somewhere off the 
section of the website that deals with updating? Particularly following -current.

Like here: 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html
or here: 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html

where someone considering following -current would see immediately that 
changes were afoot. As well as say a link off the main site, so a casual reader 
could see, too.

--
J.


signature.asc
Description: PGP signature

Re: in -current is svn still canonical?

[tech-lists]

On Tue, Nov 17, 2020 at 03:04:26AM -0800, Jeffrey Bouquet wrote:

..
Can this be put up in a wiki page as well as in each UPDATING, referencing the 
wiki page?
something like

src - current   dec 2020   now  svn up /usr/src... git 
svn cleanup  git ... [ other svn-git...
src - stable may 2021  dec 2020  svn up /usr/ports
src -releasejuly 2021
ports   dec 2021
doc dec 2021


Yeah this is what I was looking for before posting here, was surprised not to find it. 
Thought something as important as this would be linked off the main page. 
--

J.


signature.asc
Description: PGP signature

in -current is svn still canonical?

[tech-lists]

Hi

As subject - is svn still canonical for -current or is it git now?
If it's not git now, when roughly is the intended switch?

thanks,
--
J.


signature.asc
Description: PGP signature

AR9271L Atheros Chipset (wireless usb)

[tech-lists]

Hi,

Is AR9271L Atheros Chipset supported yet? I can't find any mention of it
directly under -current.

thanks,
--
J.


signature.asc
Description: PGP signature

Re: tracking -current, using poudriere-devel and the switch to git

[tech-lists]

On Wed, Sep 09, 2020 at 04:34:20PM -0400, Ed Maste wrote:

[...lots of stuff explaining...]

thank you
--
J.


signature.asc
Description: PGP signature

tracking -current, using poudriere-devel and the switch to git

[tech-lists]

Hi,

What's the repo to use now in order to track -current with a poudriere jail
via git ? i.e. in poudriere.conf, what is GIT_BASEURL ?

What's the branch name? (is it master, head, something else?)

If -current fails to compile, how do we reference it? In svn, I'd point svn
info at the sources and it would give a revision number. How is this done with
git?

At the moment, is svn behind git in terms of most recent updates, or the other
way round?

thanks,
--
J.


signature.asc
Description: PGP signature

old 12-CURRENT snapshot

[tech-lists]

Hi,

I'm looking for an old 12-CURRENT snapshot from around r317212 or before. I've
looked at ftp-archive.freebsd.org but nothing there would fit. Are there other
locations for this kind of thing that I've not considered?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Inability to build FreeBSD-current amd64

[tech-lists]

On Wed, May 15, 2019 at 06:46:04AM +, Thomas Mueller wrote:

Hi Tom,
Are you using any nonstandard build options/modes?
Cheers!
-Enji


I don't think I am using any nonstandard build options/modes.


[...]


Build didn't even start when I had WITHOUT_MANCOMPRESS on.



Trouble occurs before there is any attempt to build the kernel.


hi,

What do you do before buildworld?

I'll rm -rf /usr/obj and /var/cache/ccache [1], create them again, then in
/usr/src I'll do this:

make -j32 cleanworld && make -j32 cleandir && make -j32 clean

before make buildworld. it's probably overkill but it'll for sure clean
away any cruft

[1] make sure they get deleted without error. I've encountered
bad_file_descriptor error in ccache dir before and it caused all kinds
of errors when building, which looked like build errors but obv. were
not.

--
J.


signature.asc
Description: PGP signature

make buildkernel doesn't

[tech-lists]

Hi,

fbsd 13-current r346053 amd64

make buildkernel fails near the start here:

awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -d
--- genoffset.o ---
cc: error: no such file or directory: 'FLAGS'
*** [genoffset.o] Error code 1

more detail at
https://rpi3.zyxst.net/errors/13-current/r346053/20190409-kernbuildfail.txt

thanks,
--
J.


signature.asc
Description: PGP signature

Re: is 4k desktop possible on freebsd-12?

[tech lists]

On 10/10/2018 11:17, tech-lists wrote:
> I'm trying to get xorg to display 4k. The context is:
> 
> FreeBSD 12.0-ALPHA8 r339084 amd64
> ports r481640
> AMD RX580 GPU
> Asus X99 Extreme3 mobo
> cpu: intel e5-2699v4
> 48GB RAM
> Samsung UE48JU6410U monitor connected via HDMI
> 
> drm-next-kmod-4.11.g20180822

Hi, just to follow up to this,

I'd run out of time to work on this so installed latest ubuntu desktop,
then ran xrandr and it showed 4k as the top resolution. I didn't have to
make any modifications:

[snip]
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 connected primary 1920x1080+0+0 (normal left inverted right x
axis y axis) 1872mm x 1053mm
   3840x2160 30.00 +  25.0024.0029.9723.98
   4096x2160 30.0025.0024.0029.9723.98
[/snip]

and then, additionally, installed boinc-client-opencl and boinc was able
to see the GPUand use it for crunching.

On FreeBSD I couldn't see a way of making the boinc client OpenCL-aware.

On the plus side, FreeBSD was much more stable on this hardware than
Ubuntu. Had to disable hyperthreading in the BIOS to stop it crashing
every few hrs on Ubuntu.

It would be interesting to know, if possible, what Ubuntu is doing that
FreeBSD isn't on this hardware.

thanks to all who replied/tried to help,
-- 
J.
___
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 4k desktop possible on freebsd-12?

[tech-lists]

On 11/10/2018 10:18, Johannes Lundberg wrote:

Do you have anything configured in /etc/X11/xorg.conf?


no. But there's a section in the handbook I missed; am reading it now

thanks,

--
J.
___
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 4k desktop possible on freebsd-12?

[tech-lists]

On 10/10/2018 15:24, Slawa Olhovchenkov wrote:

You need check HDMI 2.0 available on video card and monitor.
For HDMI 1.4 you need check of support both card and monitor support 4K@24.


Yes, the card, cable and monitor are all capable of 4k@30fps. The cable 
and monitor were tested by connecting a laptop running linux mint. This 
gave a 4k display @ 30fps. So for some reason, the card (AMD RX580) 
isn't sending 4k.


Is there a resource explaining how/can anyone tell me how to make the 
card send 4k? The xorg section of the handbook unfortunately hasn't been 
much help.


thanks,
--
J.
___
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 4k desktop possible on freebsd-12?

[tech-lists]

On 10/10/2018 13:45, Slawa Olhovchenkov wrote:

for 4K@60FPS you need DP connection.


problem is monitor only has HDMI. I'm not sure it'll 4k@30fps is an 
acceptable mode for it; need to check


--
J.
___
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 4k desktop possible on freebsd-12?

[tech-lists]

On 10/10/2018 14:00, Johannes Lundberg wrote:

Hi

What is the actual problem? Do you get any 4K modes listed when you run 
'xrandr' ?


The problem is, I'd like 4k output but it seems I'm not getting it even 
though the card and monitor are both capable of it. Problem also is my 
lack of expertise in this area.


xrandr output:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DisplayPort-0 disconnected primary (normal left inverted right x axis y 
axis)

DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 1872mm x 1053mm

1920x1080 60.00*
1680x1050 59.88
1600x900 60.00
1280x1024 75.02 60.02
1440x900 59.90
1280x800 59.91
1152x864 75.00
1280x720 60.00
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32
640x480 75.00 72.81 66.67 59.94
720x400 70.08
DVI-D-0 disconnected (normal left inverted right x axis y axis)
$

I've been running 4K@60FPS on an external display for a long time on my 
Intel laptops. However, that requires DP output. Your HDMI output is 
most likely limited to 30 FPS (but should still display 4K resolution...).


Would that work at 30 fps given that Xorg.0.log shows the following:

[  3474.097] (II) AMDGPU(0): Printing DDC gathered Modelines:
[  3474.098] (II) AMDGPU(0): Modeline "3840x2160"x0.0  297.00  3840 4016
4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz eP)

[  3474.211] (II) AMDGPU(0): Printing DDC gathered Modelines:
[  3474.211] (II) AMDGPU(0): Modeline "3840x2160"x0.0  297.00  3840 4016
4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz eP)

ie, 4k @67.5kHz card output if I'm understanding correctly.

thanks,
--
J.
___
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"

is 4k desktop possible on freebsd-12?

[tech-lists]

Hi,

I'm trying to get xorg to display 4k. The context is:

FreeBSD 12.0-ALPHA8 r339084 amd64
ports r481640
AMD RX580 GPU
Asus X99 Extreme3 mobo
cpu: intel e5-2699v4
48GB RAM
Samsung UE48JU6410U monitor connected via HDMI

drm-next-kmod-4.11.g20180822
libdrm-2.4.93,1
xf86-video-amdgpu-18.1.0
xf86-video-ati-18.1.0,1
xf86-video-openchrome-0.6.0_3
xf86-video-scfb-0.0.4_7
xf86-video-vesa-2.4.0_2
linux_base-c7-7.4.1708_6 and all its xorg/mesa libs

/var/log/Xorg.0.log has this:

[  3470.966] (II) AMDGPU(0): Printing probed modes for output HDMI-A-0
[  3470.966] (II) AMDGPU(0): Modeline "1920x1080"x60.0  148.50  1920 
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[  3470.966] (II) AMDGPU(0): Modeline "1680x1050"x59.9  119.00  1680 
1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
[  3470.966] (II) AMDGPU(0): Modeline "1600x900"x60.0  108.00  1600 1624 
1704 1800  900 901 904 1000 +hsync +vsync (60.0 kHz e)


but further along we have this:

[  3474.097] (II) AMDGPU(0): EDID vendor "SAM", prod id 3140
[  3474.097] (II) AMDGPU(0): Using EDID range info for horizontal sync
[  3474.097] (II) AMDGPU(0): Using EDID range info for vertical refresh
[  3474.097] (II) AMDGPU(0): Printing DDC gathered Modelines:
[  3474.098] (II) AMDGPU(0): Modeline "3840x2160"x0.0  297.00  3840 4016 
4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz eP)
[  3474.098] (II) AMDGPU(0): Modeline "1920x1080"x0.0  148.50  1920 2008 
2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[  3474.098] (II) AMDGPU(0): Modeline "800x600"x0.0   40.00  800 840 968 
1056  600 601 605 628 +hsync +vsync (37.9 kHz e)


and

[  3474.211] (II) AMDGPU(0): Printing DDC gathered Modelines:
[  3474.211] (II) AMDGPU(0): Modeline "3840x2160"x0.0  297.00  3840 4016 
4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz eP)
[  3474.211] (II) AMDGPU(0): Modeline "1920x1080"x0.0  148.50  1920 2008 
2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[  3474.211] (II) AMDGPU(0): Modeline "800x600"x0.0   40.00  800 840 968 
1056  600 601 605 628 +hsync +vsync (37.9 kHz e)


so would this indicate the card is 4k capable but the HDMI port on the 
card is not? Or the port on the monitor? Or something else?


thanks,

--
J.
___
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: drm confusion / xorg / AMD RX580 GPU

[tech-lists]

On 10/10/2018 00:19, tech-lists wrote:

[unquote]

Is this incorrect?


ah or do you mean it won't work with BOINC?

--
J.
___
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: drm confusion / xorg / AMD RX580 GPU

[tech-lists]

On 10/10/2018 00:13, Johannes Dieterich wrote:



On Tuesday, October 9, 2018, tech-lists wrote:

On 08/10/2018 19:55, Johannes Dieterich wrote:

Depends what the boinc client uses. OpenCL - you will need graphics/clover 
which is not officially supported by AMD but may work. ROCm/HIP - won't work.


Hi,

What is ROCm/HIP ?

https://github.com/RadeonOpenCompute/ROCm

Our open acceleration stack. HIP is a kernel language akin to CUDA.


But the page says the RX580 is supported:

[quote]

ROCm officially supports AMD GPUs that have use following chips:

GFX8 GPUs
"Fiji" chips, such as on the the AMD Radeon R9 Fury X and 
Radeon Instinct MI8
"Polaris 10" chips, such as on the AMD Radeon RX 580 and Radeon 
Instinct MI6
"Polaris 11" chips, such as on the AMD Radeon RX 570 and Radeon 
Pro WX 4100

GFX9 GPUs
"Vega 10" chips, such as on the AMD Radeon Radeon RX Vega 64 
and Radeon Instinct MI25


[unquote]

Is this incorrect?

thanks,

--
J.
___
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: drm confusion / xorg / AMD RX580 GPU

[tech-lists]

On 09/10/2018 14:33, Johannes Lundberg wrote:


Hi

Let me know if you manage to get GPU processing working. I haven't 
explored the option so much but from what I've seen so far, there 
doesn't seem to be much GPU work available for *nix systems. I'm also on 
WCG.


Hi,

OK the error message for missing firmware has gone from the X.org.0.log 
but I see "could not load firmware image" in /var/log/messages and 
unfortunately the GPU still isn't available to crunch from boincmgr:


Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_pfp.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_me.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_ce.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_rlc.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_mec.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_mec2.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: drmn0: fence driver on ring 0 use gpu 
addr 0x00020008, cpu addr 0x0xf8002f4f1008


[snip]

Oct  8 22:51:08 asrock kernel: drmn0: fence driver on ring 9 use gpu 
addr 0x00020098, cpu addr 0x0xf8002f4f1098

Oct  8 22:51:08 asrock kernel: i_size_write unimplemented
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_sdma.bin: could not load 
firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_sdma1.bin: could not 
load firmware image, error 2

Oct  8 22:51:08 asrock syslogd: last message repeated 1 times
Oct  8 22:51:08 asrock kernel: drmn0: fence driver on ring 10 use gpu 
addr 0x000200a8, cpu addr 0x0xf8002f4f10a8

Oct  8 22:51:08 asrock kernel: i_size_write unimplemented
Oct  8 22:51:08 asrock kernel: drmn0: fence driver on ring 11 use gpu 
addr 0x000200b8, cpu addr 0x0xf8002f4f10b8

Oct  8 22:51:08 asrock kernel: i_size_write unimplemented
Oct  8 22:51:08 asrock kernel: amdgpu/polaris10_uvd.bin: could not load 
firmware image, error 2


[etc]

and then this:

Oct  8 22:51:08 asrock kernel: amdgpu: [powerplay] [AVFS] Something is 
broken. See log!


Unfortunately it doesn't say which log.

[snip]

Oct  8 22:51:08 asrock kernel: amdgpu: [powerplay] Can't find requested 
voltage id in vdd_dep_on_sclk table!
Oct  8 22:51:08 asrock kernel: amdgpu: [powerplay] VDDCI is larger than 
max VDDCI in VDDCI Voltage Table!

Oct  8 22:51:08 asrock kernel: [drm] ring test on 1 succeeded in 25 usecs

[snip]

PS. A tip for not having your custom Linux-enabled boinc-client pkg 
overwritten every time you run pkg upgrade, do 'pkg lock boinc-client' :)


I build/update from ports, partly because of things like that ;)
--
J.
___
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: drm confusion / xorg / AMD RX580 GPU

[tech-lists]

On 08/10/2018 19:55, Johannes Dieterich wrote:

Depends what the boinc client uses. OpenCL - you will need graphics/clover 
which is not officially supported by AMD but may work. ROCm/HIP - won't work.


Hi,

What is ROCm/HIP ?

thanks,

--
J.
___
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: drm confusion / xorg / AMD RX580 GPU

[tech lists]

On 08/10/2018 19:55, Johannes Dieterich wrote:
>> 1. is this the right/fastest/best driver for this card?
> Yes, amdgpu kernel module and amdgpu DDX

aha I didn't know about the xf86-video-amdgpu DDX requirement. OK, have
installed that :D

>> 3. I'd like this card to crunch with boinc. What determines if this is
>> possible? is it freebsd, boinc, the card driver, the project boinc is on
>> or something else?
> Depends what the boinc client uses. OpenCL - you will need graphics/clover 
> which is not officially supported by AMD but may work. ROCm/HIP - won't work.
 ok thnks for that. I saw no option for boinc_client to use OpenCL when
building the port, so I installed opencl first, then linux-c7 (was c6
before) then built boinc-client ensuring the option to take linux work
was selected. The boinc project is World Community Grid.

I'm not able to immediately test as it's a friend's computer. He says it
"displays great" but I'm looking for a way to quantify that. Hence the
question how to test the cards capabilities.

thanks,
-- 
J.
___
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: drm confusion / xorg / AMD RX580 GPU

[tech lists]

Hi,

On 08/10/2018 14:06, Warner Losh wrote:
> You need "/boot/kernel/amdgpu.ko" here
> 
> Warner

The instructions in pkg-message (at the time, haven't updated ports in a
day or so) contradict this:

$ cd /usr/ports/graphics/drm-next-kmod/
$ ls
Makefiledistinfopkg-descr   pkg-message
pkg-plist   work
$ less pkg-message

[snip]
The drm-next-kmod port can be enabled for amdgpu (for AMD GPUs starting
with the HD7000 series / Tahiti) or i915kms (for Intel APUs starting
with HD3000 / Sandy Bridge) through kld_list in /etc/rc.conf. radeonkms
for older AMD GPUs can be loaded and there are some positive reports if
EFI boot is NOT enabled (similar to amdgpu).

For amdgpu: kld_list="amdgpu"
For Intel: kld_list="/boot/modules/i915kms.ko"
For radeonkms: kld_list="/boot/modules/radeonkms.ko"

Please ensure that all users requiring graphics are members of the
"video" group.

Older generations are supported by the stable kms modules (radeonkms /
i915kms) in base.
[/snip]

svnlite info shows /usr/ports at r481442. Shall I make bug report?

thanks,

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

drm confusion / xorg / AMD RX580 GPU

[tech-lists]

Hi,

context: 12-alpha8, amd64, xorg, AMD rx580 card

As per /usr/ports/UPDATING, I have installed graphics/drm-kmod which has
installed drm-next-kmod-4.11.g20180822

As per pkg message, it's loaded with this line in /etc/rc.conf:

kld_list="amdgpu"

But even though I get a graphical display, this shows in the X.org.0.log:

[91.379] (II) LoadModule: "ati"
[91.379] (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so
[91.379] (II) Module ati: vendor="X.Org Foundation"
[91.379]compiled for 1.18.4, module version = 18.1.0
[91.379]Module class: X.Org Video Driver
[91.379]ABI class: X.Org Video Driver, version 20.0
[91.382] (II) LoadModule: "amdgpu"
[91.383] (WW) Warning, couldn't open module amdgpu
[91.383] (II) UnloadModule: "amdgpu"
[91.383] (II) Unloading amdgpu
[91.383] (EE) Failed to load module "amdgpu" (module does not exist, 0)

$ kldstat
Id Refs AddressSize Name
 1   86 0x8020  13341b0 kernel
 21 0x81536000   3ace18 zfs.ko
 32 0x818e3000 a500 opensolaris.ko
 41 0x81a22000   159978 amdgpu.ko
 51 0x81b7c00075d70 drm.ko
 64 0x81bf200010570 linuxkpi.ko
 73 0x81c0300011300 linuxkpi_gplv2.ko
 82 0x81c15000  6c0 debugfs.ko
 91 0x81c16000 80db amdgpu_polaris10_mc_bin.ko
101 0x81c1f000 441d amdgpu_polaris10_pfp_bin.ko
111 0x81c24000 441b amdgpu_polaris10_me_bin.ko
121 0x81c29000 241b amdgpu_polaris10_ce_bin.ko
131 0x81c2c000 5d3d amdgpu_polaris10_rlc_bin.ko
141 0x81c320004042d amdgpu_polaris10_mec_bin.ko
151 0x81c730004042f amdgpu_polaris10_mec2_bin.ko
161 0x81cb4000 331f amdgpu_polaris10_sdma_bin.ko
171 0x81cb8000 3321 amdgpu_polaris10_sdma1_bin.ko
181 0x81cbc0005bbfd amdgpu_polaris10_uvd_bin.ko
191 0x81d1800028d1d amdgpu_polaris10_vce_bin.ko
201 0x81d410001fe51 amdgpu_polaris10_k_smc_bin.ko
211 0x81d61000 1800 uhid.ko
221 0x81d63000 2368 ums.ko
231 0x81d66000399d8 linux.ko
242 0x81da 2d98 linux_common.ko
251 0x81da300034008 linux64.ko

Need to know:

1. is this the right/fastest/best driver for this card?

2. how can I tell if it's using all its capability?

3. I'd like this card to crunch with boinc. What determines if this is
possible? is it freebsd, boinc, the card driver, the project boinc is on
or something else?

thanks,
-- 
J.
___
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"

best linux emulation for 12-current

[tech-lists]

Hi,

Which is the better package for linux emulation on 12-alpha8 - c6 or c7? 
Or something else?


Emulation is for boinc_client to take linux work

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

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

[tech-lists]

On 11/09/2018 20:35, Ed Maste wrote:

On 11 September 2018 at 07:35, Tomoaki AOKI  wrote:

I prefer releng, rather than stable, to make it default.
Binary releases requiring reproducible builds are built from
release and releng branches.


This might be the reasonable long-term strategy, but we don't yet have
experience running through the release process with it enabled. I
would like to enable it by default on the branch, at least initially,
to avoid discovering issues only immediately prior to the release.


Hi,

Personally I think this should (after testing on -current) be enabled 
only where binary-only updates (for everything) are anticipated. Then 
again, I don't run a binary-only system despite having to manage more 
than 16 systems. One reason is the hardware is all different, so 
different things are enabled in the kernel. The other reason is that I 
can reduce a machines security overhead if only what is required is 
available. This all requires source builds. So, I want to know where and 
when each system was compiled. Why lose this information by default?


thanks,
--
J.
___
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: change in uname -a behaviour between 12-ALPHA5 and 12-ALPHA7

[tech-lists]

On 26/09/2018 14:34, Andrey Fesenko wrote:

See WITH_REPRODUCIBLE_BUILD
https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071125.html


Thanks, I was unaware of the change till now. Somehow missed that thread.

I had to add the line WITHOUT_REPRODUCIBLE_BUILD="YES"
to /etc/src.conf. I could not see WITH_REPRODUCIBLE_BUILD in man 
src.conf. So this means at least in -current r338903 that 
WITHOUT_REPRODUCIBLE_BUILD="NO" is the default, iow REPRODUCIBLE_BUILD 
is on by default unless everything is recompiled 
WITHOUT_REPRODUCIBLE_BUILD="YES".

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

change in uname -a behaviour between 12-ALPHA5 and 12-ALPHA7

[tech-lists]

Hello,

uname -a used to show a string including the date and where the kernel 
was compiled:


FreeBSD 12.0-ALPHA5 #0 r338518: Fri Sep  7 02:13:14 UTC 2018 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC


It no longer does:

root@REDACTED:/etc# uname -a
FreeBSD REDACTED.REDACTED.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338903 
REDACTED  amd64


How can I get the old behaviour back?

thanks,

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

how to enforce one version of python

[tech-lists]

Hi,

There are a number of ports that seem to have their own preferential 
flavour of python, and some for example want to install python27 and 
python36 in the same place, and it's a pain when using portupgrade or 
similar tools.


I have this in my /etc/make.conf:

DEFAULT_VERSIONS+= python=2.7

Is this incorrect? I assume it must be, as for example devel/pylint 
(pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1


thanks,
--
J.
___
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"

github freebsd and svn freebsd

[tech-lists]

Hello list,

What's the difference between github freebsd and svn freebsd, other than 
one is on github and the other is on svn?


How does one transcode or translate a git commit reference into a svn 
reference number?


thanks,
--
J.
___
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 and nvidia-driver again

[tech-lists]

On 28/08/2018 10:14, Alex V. Petrov wrote:

/usr/src Revision: 338342


===>  Building for nvidia-driver-390.77


Hi,

Have you tried applying the patch at 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230780 ? Update your 
ports tree first.


Apply it in /usr/ports

It worked for me on r338323

--
J.
___
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: x11/nvidia-driver no longer works under -current (r338323)

[tech-lists]

On 26/08/2018 13:05, John wrote:

Hi,

On Sun, 26 Aug 2018, at 13:02, Tomoaki AOKI wrote:

Hi, John.
It's broken again by r338318. (Previously broken by r338107.)

If your previous src rev is older, you could be bitten by these.
If so, update ports tree at latest rev and try the latest single patch
below [1]. The patch itself is [2], applicable on top of /usr/ports.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230780
[2] https://bz-attachments.freebsd.org/attachment.cgi?id=196559


awesome, thank you I'll try that and let you know how I get on.



Thanks again, it's all working now :D

--
J.
___
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: nvidia-driver build error (last ports, FreeBSD-HEAD)

[tech-lists]

On 22/08/2018 16:29, Alan Cox wrote:

All of kmem_alloc_attr(), kmem_alloc_contig(), and kmem_malloc() should
have their first parameter, typically kernel_arena, but sometimes
kmem_arena, removed in FreeBSD 12.

There is still one more pending change to kmem_free() that has not hit
HEAD yet.  That change will be the last.


Thank you, that's very good news. Do you have an idea when the change 
will arrive in -HEAD?


--
J.
___
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: nvidia-driver build error (last ports, FreeBSD-HEAD)

[tech-lists]

On 22/08/2018 05:29, Manfred Antar wrote:



On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev  wrote:

On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:

 Перенаправленное сообщение 
Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
Дата: Tue, 21 Aug 2018 16:41:42 +0700
От: Alex V. Petrov
Кому: FreeBSD Ports

Should be fixed as of r477761.

./danfe


It's not fixed, seems to error elsewhere now:

context: 12.0-ALPHA1 #0 r337886 / ports r477782 / empty /etc/make.conf

This is a bare metal installation.

root@desktop:/usr/ports/x11/nvidia-driver# make distclean && make clean 
&& make MAKE_JOBS_UNSAFE=yes


[...]

cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" 
-D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 
-fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-compare 
-Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef  -Werror 
-D_KERNEL -DKLD_MODULE -nostdinc  -I. -I../common/inc -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer   -MD  -MF.depend.nvidia_subr.o 
-MTnvidia_subr.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual 
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -c 
nvidia_subr.c -o nvidia_subr.o
nvidia_subr.c:1131:41: error: too many arguments to function call, 
expected 7, have 8

sc->dma_mask, PAGE_SIZE, 0, attr);
^~~~
/usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here
vm_offset_t kmem_alloc_contig(vm_size_t size, int flags,
^
nvidia_subr.c:1269:45: error: too many arguments to function call, 
expected 7, have 8

sc->dma_mask, PAGE_SIZE, 0, attr);
^~~~
/usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here
vm_offset_t kmem_alloc_contig(vm_size_t size, int flags,
^
2 errors generated.
*** Error code 1

Stop.
make[4]: stopped in 
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia

*** Error code 1

Stop.
make[3]: stopped in 
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src

*** Error code 1

Stop.
make[2]: stopped in 
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77

*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11/nvidia-driver
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/nvidia-driver
root@desktop:/usr/ports/x11/nvidia-driver#

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

usb keyboard nonfunctional at beastie menu after r337835

[tech-lists]

Hi,

context: amd64 FreeBSD 12.0-ALPHA1 #0 r337835

USB keyboard is non-functional after r337835. It's fine when booting 
completes. I'm happy to do more diagnostics if anyone can suggest any.


thanks,
--
J.
___
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: boot errors since upgrading to 12-current

[tech-lists]

On 15/08/2018 13:20, tech-lists wrote:

On 15/08/2018 12:49, Kyle Evans wrote:

On Wed, Aug 15, 2018 at 6:22 AM, tech-lists  wrote:

Hello Toomas,

On 15/08/2018 07:31, Toomas Soome wrote:


Well that does explain the problem, if you look on the sizes 
reported… so
your BIOS is reporting wrong sizes, is unable to access whole 4TB 
space and

the zfs reader is not getting the correct data from the disks



Do you know why this was not happening on 11-stable but is happening on
12-current?

The BIOS has not been modified since the machine was bought back in 
2014.




Perhaps r335245, which fixed a logical error and completely changed
the calculations for this stuff and possibly sent you on dramatically
different path. There's not too many commits to this area that haven't
yet landed back in stable/11, fortunately.

Thanks,

Kyle Evans



Thank you Toomas and Kyle for the clarifications.



addendum to this - installed new world and kernel r337835 and the zfs 
warning at boot seems to have disappeared. Something else odd has 
started happening though, will make a new email for it - usb keyboard no 
longer functioning at the beastie menu, but functions when boot completes.


--
J.
___
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: boot errors since upgrading to 12-current

[tech-lists]

On 15/08/2018 12:49, Kyle Evans wrote:

On Wed, Aug 15, 2018 at 6:22 AM, tech-lists  wrote:

Hello Toomas,

On 15/08/2018 07:31, Toomas Soome wrote:


Well that does explain the problem, if you look on the sizes reported… so
your BIOS is reporting wrong sizes, is unable to access whole 4TB space and
the zfs reader is not getting the correct data from the disks



Do you know why this was not happening on 11-stable but is happening on
12-current?

The BIOS has not been modified since the machine was bought back in 2014.



Perhaps r335245, which fixed a logical error and completely changed
the calculations for this stuff and possibly sent you on dramatically
different path. There's not too many commits to this area that haven't
yet landed back in stable/11, fortunately.

Thanks,

Kyle Evans



Thank you Toomas and Kyle for the clarifications.

--
J.
___
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: boot errors since upgrading to 12-current

[tech-lists]

Hello Toomas,

On 15/08/2018 07:31, Toomas Soome wrote:
Well that does explain the problem, if you look on the sizes reported… 
so your BIOS is reporting wrong sizes, is unable to access whole 4TB 
space and the zfs reader is not getting the correct data from the disks


Do you know why this was not happening on 11-stable but is happening on 
12-current?


The BIOS has not been modified since the machine was bought back in 2014.

Once booted, the whole drives in the pool are accessible:

Filesystem SizeUsed   Avail Capacity  Mounted on
storage5.8T1.1T4.8T18%/storage

The pool is raidz1-0 so this is the available size I'd expect with 3 x 
4Tb drives. Am I incorrect here?


- and is resulting with errors. Thats why you get the errors from 
‘storage’ pool and yes, this is harmless for boot because you have 
separate (small) disk for the boot.


Is it also harmless for the 'storage' pool ?

thanks,

--
J.
___
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: zpool scrub. Wtf?

[tech-lists]

On 12/08/2018 18:53, Cy Schubert wrote:

I haven't looked at it closely but from what I saw it was counting scan reads 
and issued reads. It may be a simple matter of dividing by 2.


Dividing what by 2?

scan: scrub in progress since Tue Aug  7 21:21:51 2018
804G scanned at 163M/s, 1,06T issued at 219M/s, 834G total
0 repaired, 129,87% done, 929637 days 13:43:01 to go

I'm also seeing this problem running 12.0-ALPHA1 #0 r337682

thanks,
--
J.
___
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: boot errors since upgrading to 12-current

[tech-lists]

On 14/08/2018 21:16, Toomas Soome wrote:




On 14 Aug 2018, at 22:37, tech-lists  wrote:

Hello,

context: amd64, FreeBSD 12.0-ALPHA1 #0 r337682, ZFS. The system is
*not* root-on-zfs. It boots to an SSD. The three disks indicated
below are spinning rust.

NAMESTATE READ WRITE CKSUM storage ONLINE   0
0 0 raidz1-0  ONLINE   0 0 0 ada1ONLINE   0
0 0 ada2ONLINE   0 0 0 ada3ONLINE   0
0 0

This machine was running 11.2 up until about a month ago.

Recently I've seen this flash up on the screen before getting to
the beastie screen:

BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS drive E: is
disk2 BIOS drive F: is disk3 BIOS drive G: is disk4 BIOS drive H:
is disk5 BIOS drive I: is disk6 BIOS drive J: is disk7

[the above is normal and has always has been seen on every boot]

read 1 from 0 to 0xcbdb1330, error: 0x31 read 1 from 0 to
0xcbdb1330, error: 0x31 read 1 from 0 to 0xcbdb1330, error: 0x31 
read 1 from 0 to 0xcbdb1330, error: 0x31 read 1 from 0 to
0xcbdb1330, error: 0x31 read 1 from 0 to 0xcbdb1330, error: 0x31 
read 1 from 0 to 0xcbdb1330, error: 0x31 read 1 from 0 to

0xcbdb1330, error: 0x31

the above has been happening since upgrading to -current a month
ago

ZFS: i/o error - all block copies unavailable ZFS: can't read MOS
of pool storage

the above is alarming and has been happening for the past couple of
days, since upgrading to r337682 on the 12th August.

The beastie screen then loads and it boots normally.

Should I be concerned? Is the output indicative of a problem?



Not immediately and yes. In BIOS loader, we do all disk IO with INT13
and the error 0x31 is often hinting about missing media or some other
controller related error. Could you paste the output from loader
lsdev -v output?

The drive list appears as an result of probing the disks in
biosdisk.c. The read errors are from attempt to read 1 sector from
sector 0 (that is, to read the partition table from the disk). Why
this does end with error, would be interesting to know, unfortunately
that error does not tell us which disk was probed.


Hi Toomas, thanks for looking at this.

lsdev -v looks like this:

OK lsdev -v
disk devices:
disk0: BIOS drive C (16514064 X 512):
disk0s1: FreeBSD  111GB
disk0s1a: FreeBSD UFS 108GB
disk0s1b: FreeBSD swap3881MB

disk1: BIOS drive D (16514064 X 512):
disk2: BIOS drive E (16514064 X 512):
disk3: BIOS drive F (16514064 X 512):
disk4: BIOS drive G (2880 X 512):
read 1 from 0 to 0xcbde0a20, error 0x31
disk5: BIOS drive D (2880 X 512):
read 1 from 0 to 0xcbde0a20, error 0x31
disk6: BIOS drive D (2880 X 512):
read 1 from 0 to 0xcbde0a20, error 0x31
disk7: BIOS drive D (2880 X 512):
read 1 from 0 to 0xcbde0a20, error 0x31
OK

disk4 to disk7 corresponds with da0 to da3 which are sd/mmc devices 
without any media in. What made me notice it is it never showed the read 
1 from 0 to $random_value on 11-stable. The system runs 12-current now.


disk1 to disk3 are the hard drives making up ZFS. These are 4TB Western 
Digital SATA-3 WDC WD4001FAEX.



Since you are getting errors from data pool ‘storage’, it does not
affect the boot. Why the pool storage is unreadable - it likely has
to do about the errors above, but can not tell for sure based on the
data presented here….


Thing is, the data pool works fine when boot completes. i.e it loads 
read/write and behaves normally.


thanks,
--
J.
___
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"

boot errors since upgrading to 12-current

[tech-lists]

Hello,

context: amd64, FreeBSD 12.0-ALPHA1 #0 r337682, ZFS. The system is *not* 
root-on-zfs. It boots to an SSD. The three disks indicated below are 
spinning rust.


NAMESTATE READ WRITE CKSUM
storage ONLINE   0 0 0
  raidz1-0  ONLINE   0 0 0
ada1ONLINE   0 0 0
ada2ONLINE   0 0 0
ada3ONLINE   0 0 0

This machine was running 11.2 up until about a month ago.

Recently I've seen this flash up on the screen before getting to the 
beastie screen:


BIOS drive C: is disk0
BIOS drive D: is disk1
BIOS drive E: is disk2
BIOS drive F: is disk3
BIOS drive G: is disk4
BIOS drive H: is disk5
BIOS drive I: is disk6
BIOS drive J: is disk7

[the above is normal and has always has been seen on every boot]

read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31
read 1 from 0 to 0xcbdb1330, error: 0x31

the above has been happening since upgrading to -current a month ago

 ZFS: i/o error - all block copies unavailable
 ZFS: can't read MOS of pool storage

the above is alarming and has been happening for the past couple of 
days, since upgrading to r337682 on the 12th August.


The beastie screen then loads and it boots normally.

Should I be concerned? Is the output indicative of a problem?

thanks,
--
J.
___
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"

how to make ports not install xorg or dependencies

[tech-lists]

Hello,

context: freebsd-12 r336215 arm64

I don't want xorg or X11 or any of its components installed on this 
system. I install ports in the traditional way, in other words cd port 
&& make config && make install. Any ports that in a generic config want 
to install xorg libs, I want the no-x11 variant.


There used to be a way to enforce this no-xorg in make.conf but looking 
at /usr/share/examples/etc/make.conf I can find no reference to X Xorg 
x11 or xorg. I presume there's a new method. If there is, can anyone 
please tell me how?


thanks,
--
J.
___
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: aarch64-arm64 fails to build kernel 12-current raspberry pi 3

[tech-lists]

On 14/07/2018 11:15, Ronald Klop wrote:
What is RPI3? Mine runs GENERIC and there is no RPI3 config in 
/usr/src/sys/arm64/conf. I can find RPI2 in sys/arm/conf.


RPI3 is the same as GENERIC-NODEBUG, apart from the ident string which 
is also RPI3. (was mentioned at the start of the thread which branched off)


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