Re: Request for Testing: TCP RACK

[Johan Hendriks]

I am running the rack stack for quiet some time now on a baremetal 
machiene and never had problems.

Also use pf.  This is a test machine so not a lot happening on it.

Are there any thing we can test? Do we have some test scripts we can run?

Re: ULE realtime scheduler advice needed

[Johan Hendriks]

On 21/11/2022 21:24, Hans Petter Selasky wrote:

On 11/21/22 20:12, Mark Johnston wrote:

There were some bug fixes earlier this year to address problems where
high-priority threads were not getting scheduled quickly enough.  If
you're using an old kernel, they might improve things:


Are any of these fixes merged to stable/13 ?

--HPS


It looks like it.
https://freshbsd.org/freebsd/src?q=sched_ule.c

build world fails on raw_ip.c

[Johan Hendriks]

,
Johan Hendriks

Zpool with latest feature com.delpfix:head_errlog can not be booted from.

[Johan Hendriks]

I did upgrade my FreeBSD Current and with that i updated my storage pool 
and my zroot pool.
I did add the new gptboot code on the disk. After the reboot i can not 
boot anymore.


So i did reinstall the os on one disk of the old zroot mirror pool and 
did leave the second untouched.


Then i can import the pools.
If i boot with the latest snapshot ISO 
(FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc1.iso) i see 
the following when i boot.


BIOS drive A: is fd0
BIOS drive B: is fd1

BIOS drive K: is disk9
ZFS: unsupported feature: com.delpfix:head_errlog
ZFS: pool zroot is not supported
ZFS: unsupported feature: com.delpfix:head_errlog
ZFS: pool storage is not supported
BIOS 624kB/2000420kB available memory

Then the OS is loaded, if i then go to the shell of the installer and do 
a zpool import, ik can import the pool zroot and storage. So this 
snapshot has the latest ZFS version with the com.delpfix:head_errlog 
feature. So it looks like the bootloader is not able to use the new 
feature and thus renders your system unbootable.


regards
Johan

Re: vnet jails loose network connectivity

[Johan Hendriks]

On 04/03/2022 15:36, Johan Hendriks wrote:
Hello all, i use jails for some testing, but i can not seem to make it 
stable.
I use vnet jails with a bridge but when i put some load on it, some 
jails loose there network connectivity.


My setup is as follows, haproxy internal IP 10.233.185.20 using binat 
to make it Public accessable.

Then a varnish jail, and two web servers al on the 10.233.185.x range.

If i give it a little load with hey (hey -h2 -n 10 -c 20 -z 60s 
https://wp.test.nl) than within the test the haproxy jail is not 
reachable anymore it is not pingable from the host machine, and from 
the other jails. restarting the jails solves it, if i leave the system 
alone for some time i saw the varnish jail become unresponsive.


If i do a tcpdump on the epair${name}a interface i do see the packages 
from the host machine to the jail but the jail itself is not reachable.


There is nothing in the logs from the host and the jail itself, i can 
ping the jails ip adres from the jail itself.



I do not think i have a special setup, but i could be doing something 
wrong.

my jail.conf

# Global settings applied to all jails.
$domain = "test.nl";
$subdomain = "";

exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;

mount.fstab = "/storage/jails/$name.fstab";

exec.system_user  = "root";
exec.jail_user    = "root";
mount.devfs;
sysvshm="new";
sysvsem="new";
allow.raw_sockets;
allow.set_hostname = 0;
allow.sysvipc;
enforce_statfs = "2";
devfs_ruleset = "11";

path = "/storage/jails/${name}";
host.hostname = "${name}${subdomain}.${domain}";

# Networking
$uplinkdev    = "vtnet1";
$epid = "${ip}";
$subnet   = "10.233.185.";
$cidr = "/24";
$ipv4_addr    = "${subnet}${ip}${cidr}";
vnet;
vnet.interface    = "vnet0";

$epair=epair${ip};
vnet;
#vnet.interface    = "${epair}b";  # default vnet interface
exec.prestart = "ifconfig bridge0 > /dev/null 2>&1 || ( ifconfig 
bridge0 create up && ifconfig bridge0 addm $uplinkdev )";
exec.prestart    += "ifconfig ${epair} create up description 
jail_${name}   || echo 'Skipped creating epair (exists?)'";
exec.prestart    += "ifconfig bridge0 addm ${epair}a   || echo 
'Skipped adding bridge member (already member?)'";

exec.created  = "ifconfig ${epair}b name vnet0";
exec.start    = "/bin/sh /etc/rc";
exec.consolelog   = "/var/log/jail/$name.test.nl";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.poststop = "ifconfig bridge0 deletem ${epair}a";
exec.poststop    += "ifconfig ${epair}a destroy";

varnish01 {
    $ip = 16;
    mount.fstab = "";
    path = "/storage/jails/${name}";
}

web01 {
    $ip = 18;
}

web02 {
    $ip = 19;
}

haproxy {
    $ip = 20;
    mount.fstab = "";
    path = "/storage/jails/${name}";
}

My ifconfig

bridge0: flags=8843 metric 0 
mtu 1500

    ether 58:9c:fc:10:ff:82
    inet 10.233.185.1 netmask 0xff00 broadcast 10.233.185.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: epair20a flags=143
    ifmaxaddr 0 port 13 priority 128 path cost 2000
    member: epair19a flags=143
    ifmaxaddr 0 port 53 priority 128 path cost 2000
    member: epair18a flags=143
    ifmaxaddr 0 port 48 priority 128 path cost 2000
    member: epair16a flags=143
    ifmaxaddr 0 port 28 priority 128 path cost 2000
    groups: bridge
    nd6 options=9
epair16a: flags=8963 
metric 0 mtu 1500

    description: jail_varnish01
    options=8
    ether 02:76:32:8e:0e:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29
epair18a: flags=8963 
metric 0 mtu 1500

    description: jail_web01
    options=8
    ether 02:6d:be:b8:36:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29
epair19a: flags=8963 
metric 0 mtu 1500

    description: jail_web02
    options=8
    ether 02:54:fd:77:9a:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29
epair20a: flags=8963 
metric 0 mtu 1500

    description: jail_haproxy
    options=8
    ether 02:f8:58:06:78:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29

This is on both 13-STABLE and 14-HEAD.


For the sake of testing i tried it with FreeBSD 13.0-RELEASE-p7 and this 
works fine. This is an exact copy of the setup i use on 14-CURRENT and 
13-STABLE. (i did a ZFS send and receive of the jails and a copy of the 
jai

vnet jails loose network connectivity

[Johan Hendriks]

Hello all, i use jails for some testing, but i can not seem to make it 
stable.
I use vnet jails with a bridge but when i put some load on it, some 
jails loose there network connectivity.


My setup is as follows, haproxy internal IP 10.233.185.20 using binat to 
make it Public accessable.

Then a varnish jail, and two web servers al on the 10.233.185.x range.

If i give it a little load with hey (hey -h2 -n 10 -c 20 -z 60s 
https://wp.test.nl) than within the test the haproxy jail is not 
reachable anymore it is not pingable from the host machine, and from the 
other jails. restarting the jails solves it, if i leave the system alone 
for some time i saw the varnish jail become unresponsive.


If i do a tcpdump on the epair${name}a interface i do see the packages 
from the host machine to the jail but the jail itself is not reachable.


There is nothing in the logs from the host and the jail itself, i can 
ping the jails ip adres from the jail itself.



I do not think i have a special setup, but i could be doing something wrong.
my jail.conf

# Global settings applied to all jails.
$domain = "test.nl";
$subdomain = "";

exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;

mount.fstab = "/storage/jails/$name.fstab";

exec.system_user  = "root";
exec.jail_user    = "root";
mount.devfs;
sysvshm="new";
sysvsem="new";
allow.raw_sockets;
allow.set_hostname = 0;
allow.sysvipc;
enforce_statfs = "2";
devfs_ruleset = "11";

path = "/storage/jails/${name}";
host.hostname = "${name}${subdomain}.${domain}";

# Networking
$uplinkdev    = "vtnet1";
$epid = "${ip}";
$subnet   = "10.233.185.";
$cidr = "/24";
$ipv4_addr    = "${subnet}${ip}${cidr}";
vnet;
vnet.interface    = "vnet0";

$epair=epair${ip};
vnet;
#vnet.interface    = "${epair}b";  # default vnet interface
exec.prestart = "ifconfig bridge0 > /dev/null 2>&1 || ( ifconfig 
bridge0 create up && ifconfig bridge0 addm $uplinkdev )";
exec.prestart    += "ifconfig ${epair} create up description 
jail_${name}   || echo 'Skipped creating epair (exists?)'";
exec.prestart    += "ifconfig bridge0 addm ${epair}a   || echo 
'Skipped adding bridge member (already member?)'";

exec.created  = "ifconfig ${epair}b name vnet0";
exec.start    = "/bin/sh /etc/rc";
exec.consolelog   = "/var/log/jail/$name.test.nl";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.poststop = "ifconfig bridge0 deletem ${epair}a";
exec.poststop    += "ifconfig ${epair}a destroy";

varnish01 {
    $ip = 16;
    mount.fstab = "";
    path = "/storage/jails/${name}";
}

web01 {
    $ip = 18;
}

web02 {
    $ip = 19;
}

haproxy {
    $ip = 20;
    mount.fstab = "";
    path = "/storage/jails/${name}";
}

My ifconfig

bridge0: flags=8843 metric 0 mtu 
1500

    ether 58:9c:fc:10:ff:82
    inet 10.233.185.1 netmask 0xff00 broadcast 10.233.185.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: epair20a flags=143
    ifmaxaddr 0 port 13 priority 128 path cost 2000
    member: epair19a flags=143
    ifmaxaddr 0 port 53 priority 128 path cost 2000
    member: epair18a flags=143
    ifmaxaddr 0 port 48 priority 128 path cost 2000
    member: epair16a flags=143
    ifmaxaddr 0 port 28 priority 128 path cost 2000
    groups: bridge
    nd6 options=9
epair16a: flags=8963 
metric 0 mtu 1500

    description: jail_varnish01
    options=8
    ether 02:76:32:8e:0e:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29
epair18a: flags=8963 
metric 0 mtu 1500

    description: jail_web01
    options=8
    ether 02:6d:be:b8:36:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29
epair19a: flags=8963 
metric 0 mtu 1500

    description: jail_web02
    options=8
    ether 02:54:fd:77:9a:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29
epair20a: flags=8963 
metric 0 mtu 1500

    description: jail_haproxy
    options=8
    ether 02:f8:58:06:78:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=29

This is on both 13-STABLE and 14-HEAD.

Re: Dragonfly Mail Agent (dma) in the base system

[Johan Hendriks]

On 27/01/2022 22:34, Ed Maste wrote:

The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA)
which accepts mail from a local Mail User Agent (MUA) and delivers it
locally or to a smarthost for delivery. dma does not accept inbound
mail (i.e., it does not listen on port 25) and is not intended to
provide the same functionality as a full MTA like postfix or sendmail.
It is intended for use cases such as delivering cron(8) mail.

Since 2014 we have a copy of dma in the base system available as an
optional component, enabled via the WITH_DMAGENT src.conf knob.

I am interested in determining whether dma is a viable minimal base
system MTA, and if not what gaps remain. If you have enabled DMA on
your systems (or are willing to give it a try) and have any feedback
or are aware of issues please follow up or submit a PR as appropriate.


We use it also to get periodic mail and other mail off of the system and 
it works fine!


Gr
Johan

Re: latest current fails to boot.

[Johan Hendriks]

On 25/09/2021 06:45, Jan Beich wrote:

Tomoaki AOKI  writes:


On Wed, 22 Sep 2021 05:47:46 -0700
David Wolfskill  wrote:


On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:

I did a git pull this morning and it fails to boot.
I hangs at Setting hostid : 0x917bf354

This is a vm running on vmware.
If i boot the old kernel from yesterday it boots normally.

uname -a
FreeBSD varnish-cdn-node03 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n249518-5572fda3a2f: Tue Sep 21 14:40:22 CEST 2021
root@varnish-cdn-node03:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64


I had no issues with my build machine or either of two laptops, either
from yesterday:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #358
main-n249518-5572fda3a2f3: Tue Sep 21 05:15:22 PDT 2021
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
amd64 1400033 1400033

or today:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #359
main-n249556-c96da1994587: Wed Sep 22 04:24:17 PDT 2021
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
amd64 1400033 1400033

[uname strings from my main laptop shown, but I keep the machines
in sync rather aggressively.]

Perhaps the issue you are encountering involves things not in my
environment (such as VMs or ZFS)?

Peace,
david
--
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

For me, on bare metal (non-vm) amd64 with root-on-ZFS,

   Fails to boot to multiuser at git: 8db1669959ce
   Boot fine at git: 0b79a76f8487

Boot to singleuser is fine even with failed revision.

Failure mode:
  Hard hangup or spinning and non-operable. Hard power-off needed.
  Seems to happen after starting rc.conf processing and before setting
  hostid.

Does "git revert --no-edit -2 8db1669959ce" help? Do you modify
kern.sched.* via /etc/sysctl.conf?

For me i had kern.sched.steal_thresh=1 in my sysctl as i use this 
machine mainly for tests and so on.
By removing this sysctl the system boots again. I already used the 
latest snapshot and that booted fine.


regards
Johan

Re: latest current fails to boot.

[Johan Hendriks]

On 23/09/2021 19:52, Konstantin Belousov wrote:

On Fri, Sep 24, 2021 at 12:43:01AM +0900, Tomoaki AOKI wrote:

On Wed, 22 Sep 2021 23:09:05 +0900
Tomoaki AOKI  wrote:


On Wed, 22 Sep 2021 05:47:46 -0700
David Wolfskill  wrote:


On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:

I did a git pull this morning and it fails to boot.
I hangs at Setting hostid : 0x917bf354

This is a vm running on vmware.
If i boot the old kernel from yesterday it boots normally.

uname -a
FreeBSD varnish-cdn-node03 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n249518-5572fda3a2f: Tue Sep 21 14:40:22 CEST 2021
root@varnish-cdn-node03:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64


I had no issues with my build machine or either of two laptops, either
from yesterday:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #358 
main-n249518-5572fda3a2f3: Tue Sep 21 05:15:22 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400033 1400033

or today:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #359 
main-n249556-c96da1994587: Wed Sep 22 04:24:17 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400033 1400033

[uname strings from my main laptop shown, but I keep the machines
in sync rather aggressively.]

Perhaps the issue you are encountering involves things not in my
environment (such as VMs or ZFS)?

Peace,
david
--
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

For me, on bare metal (non-vm) amd64 with root-on-ZFS,

   Fails to boot to multiuser at git: 8db1669959ce
   Boot fine at git: 0b79a76f8487

Boot to singleuser is fine even with failed revision.

Failure mode:
  Hard hangup or spinning and non-operable. Hard power-off needed.
  Seems to happen after starting rc.conf processing and before setting
  hostid.

--
Tomoaki AOKI


Additional info and correction.
  *Hung up before setting hostuuid, not hostid.

  *^T doesn't respond at all, only hard power off worked.

  *`kldload nvidia-modeset.ko` on single user mode sanely work.


Why I could know rc.conf is started to be processed:

  I have lines below at the end of /etc/rc.conf and its output is always
  the first line related to /etc/rc.conf, at least for non-verbose boot.
  The next line is normally "Setting hostuuid: " line, which was not
  displayed when boot hung up.


kldstat -q -n nvidia.ko
if [ 0 -ne $? ] ; then
   echo "Loading nvidia-driver modules via rc.conf."
   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
 kld_list="${kld_list} nvidia-modeset.ko"
   else
 kld_list="${kld_list} nvidia.ko"
   fi
fi

If you do not load nvidia-modeset.ko at all, does the boot proceed?

When the boot hangs, can you enter into ddb?


I do not load a nvidia-modeset.ko kernel module and it will not boot. It 
hangs with Setting hostid : as the last message. Then only a powercycle 
gets me back. If i boot in single user mode all is fine, but as soon as 
i exit single user mode it hangs at the same spot.

Re: latest current fails to boot.

[Johan Hendriks]

On 22/09/2021 16:09, Tomoaki AOKI wrote:

On Wed, 22 Sep 2021 05:47:46 -0700
David Wolfskill  wrote:


On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:

I did a git pull this morning and it fails to boot.
I hangs at Setting hostid : 0x917bf354

This is a vm running on vmware.
If i boot the old kernel from yesterday it boots normally.

uname -a
FreeBSD varnish-cdn-node03 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n249518-5572fda3a2f: Tue Sep 21 14:40:22 CEST 2021
root@varnish-cdn-node03:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64


I had no issues with my build machine or either of two laptops, either
from yesterday:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #358 
main-n249518-5572fda3a2f3: Tue Sep 21 05:15:22 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400033 1400033

or today:

FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #359 
main-n249556-c96da1994587: Wed Sep 22 04:24:17 PDT 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1400033 1400033

[uname strings from my main laptop shown, but I keep the machines
in sync rather aggressively.]

Perhaps the issue you are encountering involves things not in my
environment (such as VMs or ZFS)?

Peace,
david
--
David H. Wolfskill  da...@catwhisker.org
Life is not intended to be a zero-sum game.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

For me, on bare metal (non-vm) amd64 with root-on-ZFS,

   Fails to boot to multiuser at git: 8db1669959ce
   Boot fine at git: 0b79a76f8487

Boot to singleuser is fine even with failed revision.

Failure mode:
  Hard hangup or spinning and non-operable. Hard power-off needed.
  Seems to happen after starting rc.conf processing and before setting
  hostid.


For me a boot in single user works also.

latest current fails to boot.

[Johan Hendriks]

I did a git pull this morning and it fails to boot.
I hangs at Setting hostid : 0x917bf354

This is a vm running on vmware.
If i boot the old kernel from yesterday it boots normally.

uname -a
FreeBSD varnish-cdn-node03 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n249518-5572fda3a2f: Tue Sep 21 14:40:22 CEST 2021 
root@varnish-cdn-node03:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64

Re: testers needed: loader: use display pixel density for font autoselection

[Johan Hendriks]

On 23/02/2021 12:27, Toomas Soome via freebsd-current wrote:

hi!

I have done some work to make font pickup a bit smarter (hopefully better;), 
but my own ability to test is limited to one bugged supermicro and one MBP with 
retina display…

The phab link is https://reviews.freebsd.org/D28849 


I have built loader binaries as well (bios and uefi):
loader_lua 
loader_lua.efi 

To test, you should remove screen.font= line from loader.conf and test with 
different resolutions.

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


On my Intel core2 it looks fine, it has smaller fonts than before, but 
this looks more like a 1280 x 1024 screen that i use.
I use vbe_max_resolution="1280x1024" in /boot/loader.conf to use the new 
boot screens.

This is 13.0-BETA3 with the latest patches of today.

This is my dmesg output.

---<>---
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-BETA3 #52 releng/13.0-n244538-d7296b893969-dirty: Tue Feb 
23 15:58:29 CET 2021

    root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-0-g43ff75f2c3fe)

VT(vbefb): resolution 1280x1024
CPU: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x6fb  Family=0x6  Model=0xf Stepping=11
Features=0xbfebfbff
Features2=0xe3fd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 5372903424 (5124 MB)
avail memory = 5054898176 (4820 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
random: unblocking device.
ioapic0: MADT APIC ID 1 != hw id 0
ioapic0  irqs 0-23
Launching APs: 1
Timecounter "TSC-low" frequency 1163773173 Hz quality 1000
KTLS: Initialized 2 threads
random: entropy device external interface
[ath_hal] loaded
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 
13.0.

kbd1 at kbdmux0
000.54 [4350] netmap_init   netmap: loaded module
WARNING: Device "spkr" is Giant locked and may be deleted before FreeBSD 
13.0.

mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020)
nexus0
cryptosoft0: 
aesni0: No AES or SHA support.
acpi0: 
acpi0: Power Button (fixed)
cpu0:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
hpet1:  iomem 0xfed0-0xfed003ff on acpi0
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
device_attach: hpet0 attach returned 12
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
Firmware Error (ACPI): \134_SB.PCI0._OSC: Excess arguments - ASL 
declared 5, ACPI requires 4 (20201113/nsarguments-311)
Firmware Error (ACPI): Failure creating named object 
[\134_SB.PCI0._OSC.CAPD], AE_ALREADY_EXISTS (20201113/dsfield-352)
ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure 
(20201113/dswload2-639)
ACPI Error: Aborting method \134_SB.PCI0._OSC due to previous error 
(AE_ALREADY_EXISTS) (20201113/psparse-689)

pcib0: _OSC failed: AE_ALREADY_EXISTS
pci0:  on pcib0
vgapci0:  port 0x1230-0x1237 mem 
0xf010-0xf017,0xe000-0xefff,0xf000-0xf00f irq 16 
at device 2.0 on pci0

agp0:  on vgapci0
WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD 
13.0.

agp0: aperture size is 256M, detected 6140k stolen memory
vgapci0: Boot video device
pci0:  at device 3.0 (no driver attached)
atapci0:  port 
0x1238-0x123f,0x1270-0x1273,0x1240-0x1247,0x1274-0x1277,0x11e0-0x11ef 
irq 18 at device 3.2 on pci0

ata2:  at channel 0 on atapci0
ata3:  at channel 1 on atapci0
pci0:  at device 3.3 (no driver attached)
em0:  port 0x1100-0x111f mem 
0xf018-0xf019,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on pci0

em0: Using 1024 TX descriptors and 1024 RX descriptors
em0: Using an MSI interrupt
em0: Ethernet address: 00:22:64:19:cf:e6
em0: 

shutting down jails gives Lost 1 pages of memory error on console.

[Johan Hendriks]

I have just update my system to FreeBSD srv-01.thuis.local 13.0-ALPHA1 
FreeBSD 13.0-ALPHA1 #28 main-c256051-g7c7c231c1424: Mon Jan 18 14:12:01 
CET 2021 root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64


Now when i shutdown a jail i see the following appear on the console.

Stopping jails: haproxy Freed UMA keg (rtentry) was not empty (1 items). 
Lost 1 pages of memory.


regards,
Johan


___
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 loader blank screen

[Johan Hendriks]

On 16/01/2021 21:15, Alan Somers wrote:

On Sat, Jan 16, 2021 at 8:39 AM John Kennedy  wrote:


On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote:

Could you please check latest current now?:)

   Success!  With main-c255999-g0bc776f3da70, I've been able to comment out
the
screen.textmode=0 (so, back to the default like I originally was).

I needed to set vbe_max_resolution="800x600" to get the non text version 
of the boot loader.

___
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 loader blank screen

[Johan Hendriks]

On 16/01/2021 12:21, Johan Hendriks wrote:

On 15/01/2021 20:06, Johan Hendriks wrote:


On 15/01/2021 14:51, Toomas Soome wrote:

Could you please check latest current now?:)

Thanks,
Toomas

On 13. Jan 2021, at 20:13, Santiago Martinez  
wrote:


Hi, +1 on this, i still have issue on a supermicro.

Santi


On 1/8/21 8:11 PM, John Kennedy wrote:

On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote:
  I saw your commit of 99870c70bac7 (loader: rewrite 
vidc_install_font),
31c2bcad7e44 (loader: remove left over call to unsetenv()), and 
belatedly
babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> 
screen.textmode).


  Didn't fix the blank screen, and I thought the hw.vga.textmode 
workaround

had broken until I read that commit fully (will try it next reboot).

  At main-c255633-g3efe9b3e77c3 right now (also past your 
f1829643c476.
  At main-c255756-g40903394bf48, still no love for my system yet.  
FYI,

screen.textmode=0 continued to work around the issue, as expected.

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




I found out my desktop pc that i updated today also has a blank screen.
In my case setting the following helps

screen.textmode=1
vbe_max_resolution=800x600

And thank you for that lovely boot screen and awesome font, very neat!

My release is main-c255921-gec2700e01532: Wed Jan 13 12:32:28 CET 2021

This is on a old intel core 2
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #24 main-c255921-gec2700e01532: Wed Jan 13 
12:32:28 CET 2021

root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-rc2-0-g43ff75f2c3f)

VT(vbefb): resolution 1280x1024
CPU: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x6fb  Family=0x6  Model=0xf Stepping=11
Features=0xbfebfbff 

Features2=0xe3fd 


  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics



I found out that i have this line in my /boot/loader.conf file.
loader_logo="orb"

if i leave that in, than only this setting works and only the text 
based boot screen works.

screen.textmode=1

I then can not use the vbe_max_resolution="800x600" setting as i get 
no screen (in the top it looks like i have some small consoles of 
about 20 pixels high in all collors.)
If i remover the loader_logo="orb" line, then i can use 
vbe_max_resolution="800x600" and i see the console but only in 16 
colors i think.


I will rebuild to the current of this moment and see if the latest works.

I just did an update to FreeBSD jhost002.thuis.local 13.0-ALPHA1 FreeBSD 
13.0-ALPHA1 #26 main-c256002-gfe258f23ef36: Sat Jan 16 12:25:49 CET 2021 
root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64


For me all works now on my desktop pc.

With an empty /boot/loader.conf all is fine, it boots to the text based 
screen.
Setting vbe_max_resolution= resolution give me that beautiful boot page, 
thank you very much for that. I always get laugh about by my Linux 
colleages about the FreeBSD boot screen, those days are over ;-). Also 
the font for me is very pleasant to see.


Thank you for all your work on this.

regards Johan

___
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 loader blank screen

[Johan Hendriks]

On 15/01/2021 20:06, Johan Hendriks wrote:


On 15/01/2021 14:51, Toomas Soome wrote:

Could you please check latest current now?:)

Thanks,
Toomas

On 13. Jan 2021, at 20:13, Santiago Martinez  
wrote:


Hi, +1 on this, i still have issue on a supermicro.

Santi


On 1/8/21 8:11 PM, John Kennedy wrote:

On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote:
  I saw your commit of 99870c70bac7 (loader: rewrite 
vidc_install_font),
31c2bcad7e44 (loader: remove left over call to unsetenv()), and 
belatedly
babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> 
screen.textmode).


  Didn't fix the blank screen, and I thought the hw.vga.textmode 
workaround

had broken until I read that commit fully (will try it next reboot).

  At main-c255633-g3efe9b3e77c3 right now (also past your 
f1829643c476.
  At main-c255756-g40903394bf48, still no love for my system yet.  
FYI,

screen.textmode=0 continued to work around the issue, as expected.

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




I found out my desktop pc that i updated today also has a blank screen.
In my case setting the following helps

screen.textmode=1
vbe_max_resolution=800x600

And thank you for that lovely boot screen and awesome font, very neat!

My release is main-c255921-gec2700e01532: Wed Jan 13 12:32:28 CET 2021

This is on a old intel core 2
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #24 main-c255921-gec2700e01532: Wed Jan 13 
12:32:28 CET 2021

    root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-rc2-0-g43ff75f2c3f)

VT(vbefb): resolution 1280x1024
CPU: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x6fb  Family=0x6  Model=0xf Stepping=11
Features=0xbfebfbff 

Features2=0xe3fd 


  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics



I found out that i have this line in my /boot/loader.conf file.
loader_logo="orb"

if i leave that in, than only this setting works and only the text based 
boot screen works.

screen.textmode=1

I then can not use the vbe_max_resolution="800x600" setting as i get no 
screen (in the top it looks like i have some small consoles of about 20 
pixels high in all collors.)
If i remover the loader_logo="orb" line, then i can use 
vbe_max_resolution="800x600" and i see the console but only in 16 colors 
i think.


I will rebuild to the current of this moment and see if the latest works.

___
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 loader blank screen

[Johan Hendriks]

On 15/01/2021 14:51, Toomas Soome wrote:

Could you please check latest current now?:)

Thanks,
Toomas


On 13. Jan 2021, at 20:13, Santiago Martinez  wrote:

Hi, +1 on this, i still have issue on a supermicro.

Santi


On 1/8/21 8:11 PM, John Kennedy wrote:

On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote:
  I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font),
31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly
babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> screen.textmode).

  Didn't fix the blank screen, and I thought the hw.vga.textmode workaround
had broken until I read that commit fully (will try it next reboot).

  At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476.

  At main-c255756-g40903394bf48, still no love for my system yet.  FYI,
screen.textmode=0 continued to work around the issue, as expected.

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




I found out my desktop pc that i updated today also has a blank screen.
In my case setting the following helps

screen.textmode=1
vbe_max_resolution=800x600

And thank you for that lovely boot screen and awesome font, very neat!

My release is main-c255921-gec2700e01532: Wed Jan 13 12:32:28 CET 2021

This is on a old intel core 2
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #24 main-c255921-gec2700e01532: Wed Jan 13 12:32:28 
CET 2021

    root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-rc2-0-g43ff75f2c3f)

VT(vbefb): resolution 1280x1024
CPU: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x6fb  Family=0x6  Model=0xf Stepping=11
Features=0xbfebfbff
Features2=0xe3fd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics


___
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 can not create a pool after using gdisk to prepare the device

[Johan Hendriks]

On 12/01/2021 07:50, Graham Perrin wrote:

I used gdisk(8) with a USB flash drive to:

1. zap (destroy) GPT data structures
2. blank out the MBR
3. (below) write a new GPT with a FreeBSD ZFS (A504) partition at 
/dev/da1p1




root@mowa219-gjp4-8570p:~ # gdisk /dev/da1
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-7827358, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-7827358, default = 7827358) or {+-}size{KMGTP}:
Current type is A503 (FreeBSD UFS)
Hex code or GUID (L to show codes, Enter = A503): A504
Changed type of partition to 'FreeBSD ZFS'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE 
EXISTING

PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/da1.
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.
root@mowa219-gjp4-8570p:~ #



I exported the pool that used the device at /dev/da0 (preparing for a 
disruptive test), removed both devices then reconnected the USB flash 
drive.


zpool can not create a pool, the file system is reportedly read-only. 
Please, why is this?




root@mowa219-gjp4-8570p:~ # tail -n 0 -f /var/log/messages
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: ugen0.6: DataTraveler G2> at usbus0 (disconnected)
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: umass0: at uhub1, port 3, 
addr 14 (disconnected)
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: da0 at umass-sim0 bus 0 
scbus6 target 0 lun 0
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: da0: G2 1.00>  s/n 001D0F0CAABFF97115A00A15 detached
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: (da0:umass-sim0:0:0:0): 
Periph destroyed

Jan 12 06:44:44 mowa219-gjp4-8570p kernel: umass0: detached
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: ugen0.6: DataTraveler G2> at usbus0

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0 on uhub1
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0: DataTraveler G2, class 0/0, rev 2.00/1.00, addr 15> on usbus0
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0:  SCSI over 
Bulk-Only; quirks = 0xc100

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0:6:0: Attached to scbus6
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0 at umass-sim0 bus 0 
scbus6 target 0 lun 0
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: G2 1.00> Removable Direct Access SCSI-2 device
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: Serial Number 
001D0F0CAABFF97115A00A15

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: 40.000MB/s transfers
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: 3821MB (7827392 512 
byte sectors)

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: quirks=0x2
^C
root@mowa219-gjp4-8570p:~ # lsblk da0
DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT
da0  1:247 3.7G GPT - -
   -:-   1.0M - - -
  da0p1  1:248 3.7G freebsd-zfs gpt/efiboot0 
root@mowa219-gjp4-8570p:~ # zpool create -m /media/sorry sorry /dev/da0p1
cannot open '/dev/da0p1': Read-only file system
root@mowa219-gjp4-8570p:~ #



It looks like it is mounted or something like that.
So see with mount if it is mounted somewhere.

I alway use gpart to partition disk and i never have problems.
gpart destroy -F /dev/da0
gpart create -s GPT /dev/da0
gpart create -a 1M -t freebsd-zfs -l LABELNAME /dev/da0

Now you can create your pool using zpool create sorry gpt/LABELNAME

This way you create your pool using the GPT labelname that never 
changes, and you can use it everywhere



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

Re: src: continued use of Subversion for getting updates

[Johan Hendriks]

On 23/12/2020 09:49, Warner Losh wrote:

On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  wrote:


Warner, thanks for the clarification.

Apologies for me taking the (rough draft/work in progress) documentation
too literally.


I'm all ears on ways to make the docs better

Warner

On 23/12/2020 07:01, Warner Losh wrote:

… This has been a big job with way more moving parts than I'd ever
thought possible. We've attended to most of them, and are fixing the
stragglers as the team becomes aware of them. …

  From the outside looking in: for so complex a project, progress seems
remarkably smooth. Thanks to all involved.



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

First of all a big thank you for all your time and effort you and all 
the other people put in this tremendous task.


For me and i think a lot of regular users that do not push just pull, a 
simple page with the exact commands to track stable or head is very 
appreciated.


Like svnlite update /usr/src replace with git pull  and so on and an 
example for head, stable or release will push most people in the right 
direction.


I for one (i did not search that hard) can not find these steps very 
easily.


regards





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

Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )

[Johan Hendriks]

On 30/11/2020 16:03, Michal Meloun wrote:



On 30.11.2020 13:11, Johan Hendriks wrote:


On 30/11/2020 12:29, Hans Petter Selasky wrote:

On 11/30/20 11:43 AM, Johan Hendriks wrote:
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to 
r368182
I did a make cleanworld && make cleanworld to make sure i use a 
fresh build but it errors out with the following message.


This is a known issue and will be fixed.

--HPS


Thank you for the conformation.
And thank you all for your work on FreeBSD.

regards
Johan



Fixed in r368187. Sorry for troubles.
Michal



Thank you, no problem and no need for a sorry!

___
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: buildworld fails ( stopped in /usr/src/lib/libsysdecode )

[Johan Hendriks]

On 30/11/2020 12:29, Hans Petter Selasky wrote:

On 11/30/20 11:43 AM, Johan Hendriks wrote:
My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to 
r368182
I did a make cleanworld && make cleanworld to make sure i use a fresh 
build but it errors out with the following message.


This is a known issue and will be fixed.

--HPS


Thank you for the conformation.
And thank you all for your work on FreeBSD.

regards
Johan

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

buildworld fails ( stopped in /usr/src/lib/libsysdecode )

[Johan Hendriks]

My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182
I did a make cleanworld && make cleanworld to make sure i use a fresh 
build but it errors out with the following message.


Building /usr/obj/usr/src/amd64.amd64/lib/libsysdecode/ioctl.o
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   
-I/usr/obj/usr/src/amd64.amd64/lib/libsysdecode -I/usr/src/sys 
-I/usr/src/libexec/rtld-elf -DPF -g -std=gnu99 -Wno-format-zero-length 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch 
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition 
-Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Qunused-arguments    -c ioctl.c -o ioctl.o

In file included from ioctl.c:33:
In file included from /usr/src/sys/./cam/scsi/scsi_pass.h:35:
In file included from /usr/src/sys/cam/cam_ccb.h:46:
In file included from /usr/src/sys/cam/nvme/nvme_all.h:33:
/usr/src/sys/dev/nvme/nvme.h:1733:56: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_completion_swapbytes(struct nvme_completion *s)
  ^
/usr/src/sys/dev/nvme/nvme.h:1747:58: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_power_state_swapbytes(struct nvme_power_state *s)
    ^
/usr/src/sys/dev/nvme/nvme.h:1760:66: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_controller_data_swapbytes(struct nvme_controller_data *s)
    ^
/usr/src/sys/dev/nvme/nvme.h:1812:64: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_namespace_data_swapbytes(struct nvme_namespace_data *s)
^
/usr/src/sys/dev/nvme/nvme.h:1841:82: error: unused parameter 's' 
[-Werror,-Wunused-parameter]
void    nvme_error_information_entry_swapbytes(struct 
nvme_error_information_entry *s)

^
/usr/src/sys/dev/nvme/nvme.h:1858:26: error: unused parameter 'p' 
[-Werror,-Wunused-parameter]

void    nvme_le128toh(void *p)
    ^
/usr/src/sys/dev/nvme/nvme.h:1874:82: error: unused parameter 's' 
[-Werror,-Wunused-parameter]
void    nvme_health_information_page_swapbytes(struct 
nvme_health_information_page *s)

^
/usr/src/sys/dev/nvme/nvme.h:1902:62: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_firmware_page_swapbytes(struct nvme_firmware_page *s)
    ^
/usr/src/sys/dev/nvme/nvme.h:1913:50: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_ns_list_swapbytes(struct nvme_ns_list *s)
    ^
/usr/src/sys/dev/nvme/nvme.h:1924:76: error: unused parameter 's' 
[-Werror,-Wunused-parameter]
void    nvme_command_effects_page_swapbytes(struct 
nvme_command_effects_page *s)

^
/usr/src/sys/dev/nvme/nvme.h:1937:78: error: unused parameter 's' 
[-Werror,-Wunused-parameter]
void    nvme_res_notification_page_swapbytes(struct 
nvme_res_notification_page *s)

^
/usr/src/sys/dev/nvme/nvme.h:1946:76: error: unused parameter 's' 
[-Werror,-Wunused-parameter]
void    nvme_sanitize_status_page_swapbytes(struct 
nvme_sanitize_status_page *s)

^
/usr/src/sys/dev/nvme/nvme.h:1962:66: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    intel_log_temp_stats_swapbytes(struct intel_log_temp_stats *s)
    ^
/usr/src/sys/dev/nvme/nvme.h:1979:58: error: unused parameter 's' 
[-Werror,-Wunused-parameter]

void    nvme_resv_status_swapbytes(struct nvme_resv_status *s, size_t size)
    ^
/usr/src/sys/dev/nvme/nvme.h:1979:68: error: unused parameter 'size' 
[-Werror,-Wunused-parameter]

void    nvme_resv_status_swapbytes(struct nvme_resv_status *s, size_t size)
  ^
/usr/src/sys/dev/nvme/nvme.h:1996:66: error: unused parameter 's' 
[-Werror,-Wunused-parameter]
void    nvme_resv_status_ext_swapbytes(struct nvme_resv_status_ext *s, 
size_t size)

    ^
/usr/src/sys/dev/nvme/nvme.h:1996:76: error: unused parameter 'size' 
[-Werror,-Wunused-parameter]
void    nvme_resv_status_ext_swapbytes(struct nvme_resv_status_ext *s, 
size_t size)

^
17 errors generated.
*** Error code 1

Stop.
bmake[5]: stopped in /usr/src/lib/libsysdecode
.ERROR_TARGET='ioctl.o'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/lib/libsysdecode/ioctl.o.meta'

Re: Samba kernel panics.

[Johan Hendriks]

On 18/11/2020 05:53, Kyle Evans wrote:

On Tue, Nov 17, 2020 at 10:01 PM Mark Johnston  wrote:

On Tue, Nov 17, 2020 at 08:19:12PM +0200, Konstantin Belousov wrote:

On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote:

Hello all after updating FreeBSD13 from r367724 to r367755 my samba server
craches the server.
I did rebuild samba 4.11 but that does not help.

The output on the console is the following.

Fatal trap 12: page fault while in kernel mode
cpuid =3; apic id = 06
fault virtual address= 0x803a122b8
fault code   = supervisor read instruction, protection
violation
instruction pointer  = 0x20:0x803a122b8
stack pointer   = 0x28:0xfe0127733a50
frame pointer  = 0x28:0x803a122b0
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags  = 17340 (smbd)
trap number= 12
panic: page fault
cpuid =3
time = 1605632521
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame
0xfe0127733700
vpanic() at vpanic+0x182/frame 0xfe0127733750
panic() at panic+0x43/frame 0xfe01277337b0
trap_fatal() at trap_fatal+0x387/frame 0xfe0127733810
trap_pfault() at trap_pfault+0x4f/frame 0xfe0127733870
trap() at trap+0x27d/frame 0xfe0127733980
calltrap() at caltrap+0x8/frame 0xfe0127733980
--- trap 0xc, rip = 0x803a122b8, rsp = 0xfe0127733a50, rbp = 0x803a122b0
---
KDB: enter: panic
[ thread pid 17340 tid 101772 ]
stopped atkdb_enter+0x37: movq $0,0x1fa9446(%rip)
db>

This looks like SMEP catching an issue, but it is not clear why.

Probably fixed by r367783?  The bug would have partially overwritten the
stack frame, resulting in a jump to a user address after a return.


Ah, yes, sorry that I missed this -- smbd was in-fact the exact
program that the reporter noted observed it with, and what the fix was
confirmed with. Sorry for the breakage~

Kyle Evans


I can confirm all is working fine again after i svnupped to r367785
Thank you all for your time.

regards
Johan

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

Samba kernel panics.

[Johan Hendriks]

Hello all after updating FreeBSD13 from r367724 to r367755 my samba 
server craches the server.

I did rebuild samba 4.11 but that does not help.

The output on the console is the following.

Fatal trap 12: page fault while in kernel mode
cpuid =3; apic id = 06
fault virtual address    = 0x803a122b8
fault code   = supervisor read instruction, protection 
violation

instruction pointer  = 0x20:0x803a122b8
stack pointer   = 0x28:0xfe0127733a50
frame pointer  = 0x28:0x803a122b0
code segment = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags  = 17340 (smbd)
trap number    = 12
panic: page fault
cpuid =3
time = 1605632521
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame 
0xfe0127733700

vpanic() at vpanic+0x182/frame 0xfe0127733750
panic() at panic+0x43/frame 0xfe01277337b0
trap_fatal() at trap_fatal+0x387/frame 0xfe0127733810
trap_pfault() at trap_pfault+0x4f/frame 0xfe0127733870
trap() at trap+0x27d/frame 0xfe0127733980
calltrap() at caltrap+0x8/frame 0xfe0127733980
--- trap 0xc, rip = 0x803a122b8, rsp = 0xfe0127733a50, rbp = 
0x803a122b0 ---

KDB: enter: panic
[ thread pid 17340 tid 101772 ]
stopped at    kdb_enter+0x37: movq $0,0x1fa9446(%rip)
db>

regards,
Johan


___
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: Shutdown errors and timeout

[Johan Hendriks]

On 14/11/2020 13:03, Mateusz Piotrowski wrote:

Hi,

On 11/14/20 1:19 AM, Tomoaki AOKI wrote:

On Fri, 13 Nov 2020 20:04:59 +0900 (JST)
Yasuhiro KIMURA  wrote:


From: Johan Hendriks 


Hello all, i have two FreeBSD 13 machines, one is a bare metal and one
is virtualbox machine which i both update about once a week.

The vritual machine seems to fail stopping something and gives a
timeout after 90 sec.

The console ends with

Writing entropy file: .
Writing early boot entropy file: .

90 second watchdog timeout expired. Shutdown terminated.
Fri Nov13 11:20:40 CEST 2020
Nov 13 11:20:40 test-head init[1]: /etc/rc.shutdown terminated
abnormally, going to single user mode
...

On the bare metal machine i see the following.
Writing entropy file: .
Writing early boot entropy file: .
cannot unmount '/var/run': umount failed
cannot unmount '/var/log': umount failed
cannot unmount '/var': umount failed
cannot unmount '/usr/home': umount failed
cannot unmount '/usr': umount failed
cannot unmount '/': umount failed


(snip)

The pools have not been upgraded after the latest openzfs import,
maybe that is related?

FreeBSD test-freebsd-head 13.0-CURRENT FreeBSD 13.0-CURRENT #2
r367585:

First thing i noticed is about a week ago.

I'm facing same problem with 13.0-CURRENT amd64 r367487 and
virtualbox. In my case I use autofs to mount remote file system of
12.2-RELEASE amd64 server with NFSv4. When there is still filesystem
mounted by autofs, then watchdog timeout happens while shutdown. The
watchdog timeout can be worked around by executing `automount -fu`
before shutting down. But 'cannot unmount ...' error messages are
still displayed.

I added 'rc_debug="YES"' to /etc/rc.conf and checked which rc script
causes this message. Then it is displayed when following `zfs_stop`
function of /etc/rc.d/zfs is executed.

--
zfs_stop_main()
{
zfs unshare -a
zfs unmount -a
}
--

At this point syslog process still running and it opens some files
under /var/log. So it make sence that `zfs unmount -a` results in the
message.

Probably order of executing each rc script in shutdown time should be
changed so `/etc/rc.d/zfs faststop` is executed after all processes
other than `init' are exited.

This happens on stable/12, too.
As a workaround, reverting r367291 on head (r367546 on stable/12)
would stop the issue until this is really fixed.

If you have shared dataset or jail(s) mounting dataset, the workaround
would be discouraged. Read commit message for detail.


I've committed r367291 and r367546.

I am not sure if I can think of a proper fix for the described issues, 
so I guess the best idea would be to revert those changes for now 
until we figure out how to do it properly.


Sorry for the regression.

Best,

Mateusz



I can tell that reverting the mentioned commit i do not have the 
symptoms when i reboot my servers.

Thank you all for your time, and no sorry needed ;-)

regards,
Johan

___
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: Shutdown errors and timeout

[Johan Hendriks]

On 13/11/2020 11:55, Andrea Venturoli wrote:

On 11/13/20 11:35 AM, Johan Hendriks wrote:

Just my 2c...



The vritual machine seems to fail stopping something and gives a 
timeout after 90 sec.


I've seen this on many (physical) boxes and I solved by increasing 
shutdown timeout. Sometimes 90s is just too little (especially, but 
not only, if you have VMs running).


E.g. I have rcshutdown_timeout="600" in /etc/rc.conf and 
kern.init_shutdown_timeout=900 in /etc/sysctl.conf.





On the bare metal machine i see the following.
Writing entropy file: .
Writing early boot entropy file: .
cannot unmount '/var/run': umount failed
cannot unmount '/var/log': umount failed
cannot unmount '/var': umount failed
cannot unmount '/usr/home': umount failed
cannot unmount '/usr': umount failed
cannot unmount '/': umount failed


Probably a process is still running and that's why those filesystems 
cannot be (unforcibly) unmounted.

Logs can help identify which process it is.
Perhaps putting rc_debug="YES" in /etc/rc.conf can be useful.



 bye
av.


Thank you for your anwer.
The rc_debug showed me that the virtualox server are hangs on zfs_stop, 
if i do not enable bastille and reboot all is fine after a shutdown, so 
i think the jail zfs datasets are interfering.
The baremetal server is not waiting for anything just throw the umount 
errors directly.


regards.




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

Shutdown errors and timeout

[Johan Hendriks]

Hello all, i have two FreeBSD 13 machines, one is a bare metal and one 
is virtualbox machine which i both update about once a week.


The vritual machine seems to fail stopping something and gives a timeout 
after 90 sec.


The console ends with

Writing entropy file: .
Writing early boot entropy file: .

90 second watchdog timeout expired. Shutdown terminated.
Fri Nov13 11:20:40 CEST 2020
Nov 13 11:20:40 test-head init[1]: /etc/rc.shutdown terminated 
abnormally, going to single user mode

...

On the bare metal machine i see the following.
Writing entropy file: .
Writing early boot entropy file: .
cannot unmount '/var/run': umount failed
cannot unmount '/var/log': umount failed
cannot unmount '/var': umount failed
cannot unmount '/usr/home': umount failed
cannot unmount '/usr': umount failed
cannot unmount '/': umount failed

The virtual machine has the following mount points set.
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs)
fdescfs on /dev/fd (fdescfs)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
zroot/jails on /jails (zfs, local, noatime, nfsv4acls)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, 
nfsv4acls)

zroot on /zroot (zfs, local, noatime, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, 
nfsv4acls)

zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)

The barematal one
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs)
fdescfs on /dev/fd (fdescfs)
zroot/usr on /usr (zfs, local, noatime, nfsv4acls)
zroot/var on /var (zfs, local, noatime, nfsv4acls)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/run on /var/run (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, 
nfsv4acls)

zroot/var/db on /var/db (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/empty on /var/empty (zfs, local, noatime, noexec, nosuid, 
read-only, nfsv4acls)
zroot/usr/src on /usr/src (zfs, NFS exported, local, noatime, noexec, 
nosuid, nfsv4acls)

zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/obj on /usr/obj (zfs, NFS exported, local, noatime, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime, 
noexec, nosuid, nfsv4acls)
zroot/usr/ports/packages on /usr/ports/packages (zfs, local, noatime, 
noexec, nosuid, nfsv4acls)

zroot/var/db/pkg on /var/db/pkg (zfs, local, noatime, nosuid, nfsv4acls)

The pools have not been upgraded after the latest openzfs import, maybe 
that is related?


FreeBSD test-freebsd-head 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r367585:

First thing i noticed is about a week ago.






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

Re: CFT for vendor openzfs - week 5 reminder + memdisk images

[Johan Hendriks]

Op 04-08-2020 om 02:24 schreef Matthew Macy:

On Wednesday, July 8th I issued the initial call for testing for the
update to HEAD to vendored openzfs. We'd like to give users roughly a
month to test before merging.  The tentative merge date is August
17th.

Again, I hope it's not terribly controversial to point out that
it really rests with users of non amd64 platforms to test to avoid any
unpleasant surprises the next time they update their trees following
the merge.

amd64, i386, and aarch64 memdisk images can be found at:
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/

If you're using a platform not listed above and would be inclined to
test if you had an image to work with, let us know. Alternatively, you
can still build following the instructions below.

The review for merging in to base can be found at:
https://reviews.freebsd.org/D25872

==
NB: Do NOT zpool upgrade unless you are willing to live without the
ability to ever rollback to the legacy zfs kmod.

Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd

Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs

Build world and kernel with whatever your usual configuration is.
Where possible the openzfs kmod is backward compatible with the cmd
utils in HEAD so common operations work with existing tools and the
new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
are backward compatible with the zfs kmod in HEAD. Although ideally
one would test this in a separate boot environment, the
interoperability should allow one to rollback without too much
difficulty.

NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools
other than the root pool will not be imported at boot.

Thanks in advance for your time.

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

I just downloaded the freebsd-openzfs-amd64-2020081100-memstick.img 
image and installed it as a fresh install. (ZFS install)
Then i imported a pool that is a mirrored zfs pool of 6 WD drives 
created with FreeBSD 12.1 without any problem.


The only thing i see when the ZFS module is loaded is the message can't 
handle raw ops yet!!!


# kldload zfs
can't handle raw ops yet!!!
can't handle raw ops yet!!!
can't handle raw ops yet!!!
ZFS filesystem version: 5
ZFS storage pool version: features support 5000
can't handle raw ops yet!!!

regards
Johan

___
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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

[Johan Hendriks]

Op 11-06-2020 om 15:21 schreef Konstantin Belousov:

On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote:

Build machine (mini-tower) performed the update (r362008 -> r362045)
without issue, but my laptop panicked quite early on -- before the dump
device was configured.

I have taken and placed a couple of screen shots in
http://www.catwhisker.org/~david/FreeBSD/head/r362045/

Looking at the displayed backtrace, I see:

--- trap 0xc ...
futex_xchgl_reslover()
elf_reloc_internal()
link_elf_reloc_local()
link_elf_link_preload_finish()
linker_preload()
mi_startup()

Any clues?  I'm hapy to poke at it or try patches.

Booting from kernel.old (r362008) still works:
FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 
r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300097 1300097

The link times out.

There is not much to access in futex_xchgl_resolver() except for the
data segment.  Without full panic message and disassemble of your instance
of futex_xchgl_resolver() it is not possible to ee what is going on.

Just in case, can you try clean build, if you did -DNO_CLEAN ?


Just a me too.
I updated from 362042 to 362053

I get this panic very early.

(hand typed so could contain some typo's)

FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-10.0.1-rc1-0-gf79cd71e145

VT(vgs): resolution 640x480
kernel trap 12 with interupts disabled
panic: vm_fault_lookup: fault on nofault entry, addr: 0x83a3d000
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0x83a65830

vpanic() at vpanic+0x182/frame 0x83a65880
panic() ata panic+0x43/frame 0x83a658e00
vm_fault() at vm_fault+0x1ab5/frame 0x83a659f0
vm_fault_trap() at vam_fault_trap+0x6-/frame 0x83a65a30
trap_pfault at trap_pfault+0x19c/frame 0x83a65a80
trap() at trap+0x271/frame 0x8365b90
calltrap() at calltrap+0x8/frame 0x83a65b90
--- trap 0xc, rip = 0x83a3d470, rsp = 0x83a65c68, rbp = 
0x83a65cb0 ---
opensolaris_utsname_init() at opensolaris_utsname_init/frame 
0x83a65cb0btext() at btext+0x2c

KDB: enter : panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x37: movq   $0,0x1fc1686(%rip)
db>



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

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

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

[Johan Hendriks]

Op 11-06-2020 om 15:21 schreef Konstantin Belousov:

On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote:

Build machine (mini-tower) performed the update (r362008 -> r362045)
without issue, but my laptop panicked quite early on -- before the dump
device was configured.

I have taken and placed a couple of screen shots in
http://www.catwhisker.org/~david/FreeBSD/head/r362045/

Looking at the displayed backtrace, I see:

--- trap 0xc ...
futex_xchgl_reslover()
elf_reloc_internal()
link_elf_reloc_local()
link_elf_link_preload_finish()
linker_preload()
mi_startup()

Any clues?  I'm hapy to poke at it or try patches.

Booting from kernel.old (r362008) still works:
FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 
r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300097 1300097

The link times out.

There is not much to access in futex_xchgl_resolver() except for the
data segment.  Without full panic message and disassemble of your instance
of futex_xchgl_resolver() it is not possible to ee what is going on.

Just in case, can you try clean build, if you did -DNO_CLEAN ?



Just a me too.
I updated from 362042 -> 362053

I get this panic very early.

(hand typed so could contain some typo's)

FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-10.0.1-rc1-0-gf79cd71e145

VT(vgs): resolution 640x480
kernel trap 12 with interupts disabled
panic: vm_fault_lookup: fault on nofault entry, addr: 0x83a3d000
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0x83a65830

vpanic() at vpanic+0x182/frame 0x83a65880
panic() ata panic+0x43/frame 0x83a658e00
vm_fault() at vm_fault+0x1ab5/frame 0x83a659f0
vm_fault_trap() at vam_fault_trap+0x6-/frame 0x83a65a30
trap_pfault at trap_pfault+0x19c/frame 0x83a65a80
trap() at trap+0x271/frame 0x8365b90
calltrap() at calltrap+0x8/frame 0x83a65b90
--- trap 0xc, rip = 0x83a3d470, rsp = 0x83a65c68, rbp = 
0x83a65cb0 ---
opensolaris_utsname_init() at opensolaris_utsname_init/frame 
0x83a65cb0btext() at btext+0x2c

KDB: enter : panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x37: movq   $0,0x1fc1686(%rip)
db>




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

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

Re: How to enable tcp bbr in FreeBSD???

[Johan Hendriks]

Op 24-04-2020 om 15:51 schreef ykla:
WITH_EXTRA_TCP_STACKS=1  in make.conf  ? And why not make it in kernel 
default?


在 2020年4月24日星期五，Johan Hendriks <mailto:joh.hendr...@gmail.com>> 写道：



Op 24-04-2020 om 15:37 schreef Kurt Jaeger:

Hi!

You can enable the stack globally on new connections without
restarting the box or daemons by running these commands:

kldload tcp_bbr

sysctl net.inet.tcp.functions_inherit_listen_socket_stack=0
sysctl net.inet.tcp.functions_default=bbr

This fails on the box running 13.0:

# kldload tcp_bbr
kldload: can't load tcp_bbr: No such file or directory

So it looks it has to be hooked to the build somehow ?

And: man -k bbr has no results as well...

The commit message says the following:


This commit adds BBR (Bottleneck Bandwidth and RTT) congestion
control. This
is a completely separate TCP stack (tcp_bbr.ko) that will be built
only if
you add the make options WITH_EXTRA_TCP_STACKS=1 and also include
the option
TCPHPTS. You can also include the RATELIMIT option if you have a
NIC interface that
supports hardware pacing, BBR understands how to use such a feature.


So i think you need te rebuild with the following option set
WITH_EXTRA_TCP_STACKS=1

regards
    Johan Hendriks

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



It looks like you need to add the following to the kernel as well.

option TCPHPTS

Maybe it is not ready for prime time, i do not know why it is not in the 
default build.

Maybe ask the committer.

regards,
Johan


___
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: How to enable tcp bbr in FreeBSD???

[Johan Hendriks]

Op 24-04-2020 om 15:37 schreef Kurt Jaeger:

Hi!


You can enable the stack globally on new connections without
restarting the box or daemons by running these commands:

kldload tcp_bbr

sysctl net.inet.tcp.functions_inherit_listen_socket_stack=0
sysctl net.inet.tcp.functions_default=bbr

This fails on the box running 13.0:

# kldload tcp_bbr
kldload: can't load tcp_bbr: No such file or directory

So it looks it has to be hooked to the build somehow ?

And: man -k bbr has no results as well...


The commit message says the following:


This commit adds BBR (Bottleneck Bandwidth and RTT) congestion control. This
is a completely separate TCP stack (tcp_bbr.ko) that will be built only if
you add the make options WITH_EXTRA_TCP_STACKS=1 and also include the option
TCPHPTS. You can also include the RATELIMIT option if you have a NIC 
interface that

supports hardware pacing, BBR understands how to use such a feature.


So i think you need te rebuild with the following option set 
WITH_EXTRA_TCP_STACKS=1


regards
Johan Hendriks

___
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: sort.core error doing installworld on Current.

[Johan Hendriks]

Op 17-04-2020 om 13:30 schreef Johan Hendriks:


Op 17-04-2020 om 12:47 schreef Rodney W. Grimes:

Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman 
 wrote:



So you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The 
questions, how
did get there? I'd take a look at the date on the file and, it 
it is older
than the buildworld, just assume that it was left-over garbage. 
In either

case, you can delete it and do another installworld.

That should most likely fix things, but, if the buildworld or 
installworld
had a crash of sort(1) that left the file, further investigation 
might be
needed. Re-making the zoneinfo would help track it down should 
this be a re

al bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Please forgive that awful post! I missed a part of your message 
by laziness.


It's odd that the error of sort(1) crashing was not caught by the 
script.

Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw.  Wildcards should NOT be 
used
in the source of an install list, exactly because of this type of 
cruft

that can be dropped in an obj dir.

 From src/share/zoneinfo/Makefile at about line 93:
92  if make(*install*)
93  TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
   this is a very bad thing to do 
in a Makefile.


94  .endif

Now I still don't know why sort cored, but I am sure this is the line 
that did it.


Clearly, sort should NOT crash! Again, a re-build of zoneinfo 
might catch
something. Looking at the core might tell you which "sort" was 
involved...
the one you just built or the one in the base system. This could 
be just a

FOTU, but I would not bet on it.

I suspect a recent zoneinfo commit as the root cause.


I have no idea how to bypass this issue.
I have used sort from the latest snapshot and placed that file on the
system and in the build dir, but i keep getting the core

How can i test an build and install part for zoneinfo

If i go into the dir /usr/src/share/zoneinfo and do make install it 
does

not work, do i need to add something?

Can you show us the output from
cd /usr/src/share/zoneinfo
make clean && make depend && make all && make install
Someplace in that we should get to see sort crashing...


On both machines my src.conf file is the same.

I will start over from a clean world by doing a make cleanworld and 
see if it then still gives the errors

Maybe some old artifacts are hanging around.






Thank you both for your time


--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 


wrote:


I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008

This is a quite powerful machine, so i thought it was a good 
idea to let
that server do the build and for my virtualbox machine i can 
use the

powerful machine to do a installword over NFS.

But when i did the make installworld step the client so to say 
gives an

error.

install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
/usr/share/zoneinfo/Zulu
install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
/usr/share/zoneinfo/posixrules
install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
/usr/share/zoneinfo/sort.core
install: 
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:

Permission denied
*** Error code 71

Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src
*** Error code 1

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

Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'

It looks likes sort coredumps in the usr/share/zoneinfo part of 
the base.

As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a
sort.core file behind in /usr/share/zoneinfo

cd /usr/share/zoneinfo
ls -al



__

Re: sort.core error doing installworld on Current.

[Johan Hendriks]

Op 17-04-2020 om 12:47 schreef Rodney W. Grimes:

Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:

On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  wrote:


So you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
did get there? I'd take a look at the date on the file and, it it is older
than the buildworld, just assume that it was left-over garbage. In either
case, you can delete it and do another installworld.

That should most likely fix things, but, if the buildworld or installworld
had a crash of sort(1) that left the file, further investigation might be
needed. Re-making the zoneinfo would help track it down should this be a re
al bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


Please forgive that awful post! I missed a part of your message by laziness.

It's odd that the error of sort(1) crashing was not caught by the script.

Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw.  Wildcards should NOT be used
in the source of an install list, exactly because of this type of cruft
that can be dropped in an obj dir.

 From src/share/zoneinfo/Makefile at about line 93:
92  if make(*install*)
93  TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
   this is a very bad thing to do in a 
Makefile.

94  .endif

Now I still don't know why sort cored, but I am sure this is the line that did 
it.


Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
something. Looking at the core might tell you which "sort" was involved...
the one you just built or the one in the base system. This could be just a
FOTU, but I would not bet on it.

I suspect a recent zoneinfo commit as the root cause.


I have no idea how to bypass this issue.
I have used sort from the latest snapshot and placed that file on the
system and in the build dir, but i keep getting the core

How can i test an build and install part for zoneinfo

If i go into the dir /usr/src/share/zoneinfo and do make install it does
not work, do i need to add something?

Can you show us the output from
cd /usr/src/share/zoneinfo
make clean && make depend && make all && make install
Someplace in that we should get to see sort crashing...


On both machines my src.conf file is the same.

I will start over from a clean world by doing a make cleanworld and see 
if it then still gives the errors

Maybe some old artifacts are hanging around.






Thank you both for your time


--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
wrote:


I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008

This is a quite powerful machine, so i thought it was a good idea to let
that server do the build and for my virtualbox machine i can use the
powerful machine to do a installword over NFS.

But when i did the make installworld step the client so to say gives an
error.

install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
/usr/share/zoneinfo/Zulu
install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
/usr/share/zoneinfo/posixrules
install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
/usr/share/zoneinfo/sort.core
install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
Permission denied
*** Error code 71

Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src
*** Error code 1

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

Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'

It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a
sort.core file behind in /usr/share/zoneinfo

cd /usr/share/zoneinfo
ls -al



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailm

Re: sort.core error doing installworld on Current.

[Johan Hendriks]

Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:

On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  wrote:


So you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
did get there? I'd take a look at the date on the file and, it it is older
than the buildworld, just assume that it was left-over garbage. In either
case, you can delete it and do another installworld.

That should most likely fix things, but, if the buildworld or installworld
had a crash of sort(1) that left the file, further investigation might be
needed. Re-making the zoneinfo would help track it down should this be a re
al bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


Please forgive that awful post! I missed a part of your message by laziness.

It's odd that the error of sort(1) crashing was not caught by the script.

Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw.  Wildcards should NOT be used
in the source of an install list, exactly because of this type of cruft
that can be dropped in an obj dir.


Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
something. Looking at the core might tell you which "sort" was involved...
the one you just built or the one in the base system. This could be just a
FOTU, but I would not bet on it.

I suspect a recent zoneinfo commit as the root cause.


I have no idea how to bypass this issue.
I have used sort from the latest snapshot and placed that file on the 
system and in the build dir, but i keep getting the core


How can i test an build and install part for zoneinfo

If i go into the dir /usr/src/share/zoneinfo and do make install it does 
not work, do i need to add something?


Thank you both for your time


--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683




On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
wrote:


I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008

This is a quite powerful machine, so i thought it was a good idea to let
that server do the build and for my virtualbox machine i can use the
powerful machine to do a installword over NFS.

But when i did the make installworld step the client so to say gives an
error.

install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
/usr/share/zoneinfo/Zulu
install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
/usr/share/zoneinfo/posixrules
install   -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
/usr/share/zoneinfo/sort.core
install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
Permission denied
*** Error code 71

Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src
*** Error code 1

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

Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'

It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a
sort.core file behind in /usr/share/zoneinfo

cd /usr/share/zoneinfo
ls -al



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


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

sort.core error doing installworld on Current.

[Johan Hendriks]

I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008

This is a quite powerful machine, so i thought it was a good idea to let 
that server do the build and for my virtualbox machine i can use the 
powerful machine to do a installword over NFS.


But when i did the make installworld step the client so to say gives an 
error.


install   -o root -g wheel -m 444 
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu 
/usr/share/zoneinfo/Zulu
install   -o root -g wheel -m 444 
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules 
/usr/share/zoneinfo/posixrules
install   -o root -g wheel -m 444 
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core 
/usr/share/zoneinfo/sort.core
install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core: 
Permission denied

*** Error code 71

Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src
*** Error code 1

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

Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'

It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a 
sort.core file behind in /usr/share/zoneinfo


cd /usr/share/zoneinfo
ls -al
-r--r--r--   1 root  wheel          118 Apr 16 20:25 Zulu
-r--r--r--   1 root  wheel        3519 Apr 16 20:25 posixrules
-r--r--r--   1 root  wheel  8982528 Apr 16 20:25 sort.core
-r--r--r--   1 root  wheel      19424 Apr 16 20:25 zone.tab
-r--r--r--   1 root  wheel      17955 Apr 16 20:25 zone1970.tab

my src.conf file looks like this
WITHOUT_BLUETOOTH=yes
WITHOUT_CALENDAR=yes
WITHOUT_DICT=yes
WITHOUT_GAMES=yes
WITHOUT_I4B=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_LPR=yes
WITHOUT_PROFILE=yes
WITHOUT_SENDMAIL=yes
WITHOUT_SHAREDOCS=yes
WITHOUT_WIRELESS=yes
WITHOUT_HAST=yes
WITHOUT_LLVM_TARGET_{MIPS,POWERPC,SPARC,RISCV}= YES
WITHOUT_LIB32=yes

in /etc/make.conf i have the following
MALLOC_PRODUCTION=yes
BATCH_DELETE_OLD_FILES= yes
CUPS_OVERWRITE_BASE=yes


What can i do about this?

Thank you for your time.


___
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: Panic with latest CURRENT amd64 as Virtualbox guest

[Johan Hendriks]

These is no file attached. I think the mailing list stripped it off.
But i had an kernel panic also with Freebsd currrent on virtualbox on a mac.

My latetst build is 356985



Op wo 22 jan. 2020 14:14 schreef Rares Aioanei :

> I updated my system today, by issuing "svn up; make buildowrld; make
> kernel; reboot" and I got the output as seen in the attached file.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Kernel panic after rebuilding CURRENT

[Johan Hendriks]

Yes for me too.



Op vr 27 sep. 2019 om 13:23 schreef mms.vanbreukelin...@gmail.com <
mms.vanbreukelin...@gmail.com>:

> Works again,  just 'svn up' to the latest release,  rebuuld,  nothing to
> do with virtualization but a serious kernel problem - IMO having too little
> userspace and too much right winged here.
>
> Miranda
>
> On Fri, 27 Sep 2019 at 11:48, Johan Hendriks
>  wrote:
> Just a me too, for me it is a standard FreeBSD running on virtualbox.
>
> regards,
> Johan
>
>
> Op wo 25 sep. 2019 om 17:30 schreef mms.vanbreukelin...@gmail.com <
> mms.vanbreukelin...@gmail.com>:
>
> Had verbose on and got the following kernel error on 290:
> taskqgroup_adjust_if_config_tqg: panic: sched_pickcpu: failed to find a cpu
> Looked for device tqg,  isn't available in a slightly changing GENERIC
> custom. I know what this personally means to me,  incompatibility and a
> lack of social integration,   but what's the reason for BSD telling me:
> "thank you,  that's it!" I have LOCK_PROFILING as option for building,  but
> this had nothing to do with that kinda problem.
> Reversion from this morning,  as a lack of Inet at the moment, I had to
> 'svn up' from within Linux with ufs write enabled and gave root to the
> rescue CD for fsck'ing the /dev/ada0p7. The hashkey terror stops and when
> unmounted without flags -fl on arch. They're doing well together simple
> because if unification purpose against monopoly.
> Had to rebuild without SMP,  so virtualization is problematic. #ing the
> ule_scheduler shouldn't be "unticked", as this causes severe compile
> errors.
> I think she just wants a backward development at this age,  nostalgia
> electronica should be a study tribe on universities like history in
> school!  Anyone able to get 2nd CPU up again?
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
> "
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Kernel panic after rebuilding CURRENT

[Johan Hendriks]

Just a me too, for me it is a standard FreeBSD running on virtualbox.

regards,
Johan


Op wo 25 sep. 2019 om 17:30 schreef mms.vanbreukelin...@gmail.com <
mms.vanbreukelin...@gmail.com>:

> Had verbose on and got the following kernel error on 290:
> taskqgroup_adjust_if_config_tqg: panic: sched_pickcpu: failed to find a cpu
> Looked for device tqg,  isn't available in a slightly changing GENERIC
> custom. I know what this personally means to me,  incompatibility and a
> lack of social integration,   but what's the reason for BSD telling me:
> "thank you,  that's it!" I have LOCK_PROFILING as option for building,  but
> this had nothing to do with that kinda problem.
> Reversion from this morning,  as a lack of Inet at the moment, I had to
> 'svn up' from within Linux with ufs write enabled and gave root to the
> rescue CD for fsck'ing the /dev/ada0p7. The hashkey terror stops and when
> unmounted without flags -fl on arch. They're doing well together simple
> because if unification purpose against monopoly.
> Had to rebuild without SMP,  so virtualization is problematic. #ing the
> ule_scheduler shouldn't be "unticked", as this causes severe compile
> errors.
> I think she just wants a backward development at this age,  nostalgia
> electronica should be a study tribe on universities like history in
> school!  Anyone able to get 2nd CPU up again?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Statement regarding employment change and roles in the Project

[Johan Hendriks]

Thank you Glen for all your hard work and time and good luck with the
new job.

regards
Johan

Op 20-06-19 om 18:22 schreef Glen Barber:
> Dear FreeBSD community:
>
> As I have a highly-visible role within the community, I want to share
> some news.  I have decided the time has come to move on from my role
> with the FreeBSD Foundation, this Friday being my last day.  I have
> accepted a position within a prominent company that uses and produces
> products based on FreeBSD.
>
> My new employer has included provisions within my job description that
> allow me to continue supporting the FreeBSD Project in my current
> roles, including Release Engineering.
>
> There are no planned immediate changes with how this pertains to my
> roles within the Project and the various teams of which I am a member.
>
> FreeBSD 11.3 and 12.1 will continue as previously scheduled, with no
> impact as a result of this change.
>
> I want to thank everyone at the FreeBSD Foundation for providing the
> opportunity to serve the FreeBSD Project in my various roles, and their
> support for my decision.
>
> I look forward to continue supporting the FreeBSD Project in my various
> roles moving forward.
>
> Glen
>
___
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"

PKGBase installs openssl with pkg install -g 'FreeBSD-*'

[Johan Hendriks]

I am testing pkg base on a 12 current system, and all went fine, but
after the update to ALPHA9 the system keeps installing openssl-1.0.2p_1,1

I do a make buildworld && make buildkernel Then make packages.
Then i upgrade the package tree so to say with pkg update -r FreeBSD-base

And then i do a pkg install -g 'FreeBSD-*'

root@builder:/usr/src # pkg install -g 'FreeBSD-*'
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 333 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    openssl: 1.0.2p_1,1 [FreeBSD]

Installed packages to be UPGRADED:
    FreeBSD-acct: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]
    FreeBSD-acct-debug: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]
    FreeBSD-acpi: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]

... SNIP .

    FreeBSD-vi-debug: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]
    FreeBSD-zfs: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base]

Installed packages to be REINSTALLED:
    pkg-1.10.5_3 [FreeBSD] (options changed)

Number of packages to be installed: 1
Number of packages to be upgraded: 331
Number of packages to be reinstalled: 1

The process will require 11 MiB more space.

Then the system is installing openssl and reinstalls pkg but after a
reboot pkg is not working anymore.
And gives me the following error.
root@builder:/usr/src # pkg
ld-elf.so.1: Shared object "libssl.so.8" not found, required by "pkg"

What can i do to get out of this cycle.

regards


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

Re: how to browse svnweb source?

[Johan Hendriks]

Op di 29 mei 2018 00:28 schreef Jeffrey Bouquet :

> Suddenly the site www.secnetix.de/olli/FreeBSD/svnews which showed
> sequential
> source as for example xx1966 on april 3  xx2040 on april 4 this year,
> is not loading
> in the browser.  It was informative to read color coded the source
> backported to v10
> v11 vs new, and new drivers coming into play.  I can find NOWHERE except
> freshsource.org which has the ports updates interspersed which makes the
> information
> too time consuming.  As an example,
>
> 09:36:34 - r 318137Affects: /head/usr.bin/mking/mking.1 [ mking.c]
> on 5-10-2017 adding the -C and --capacity options...
>
> ...
>   What was educational to browse now is found at 
> ..
> ___
> 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"
>


You can try www.freshbsd.org it has all the BSD's covered.  You can select
the branch you want to watch.

>
___
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: Fatal trap 12

[Johan Hendriks]

I just removed the following from my kernel file

#device  pf
#device  pflog
#device  pfsync

Changed back the SI_SUB_PSEUDO in sys/netpfil/pf/if_pflog.c

Rebuild the kernel and now the kernel is booting normally.

regards

Johan


Op 23/06/16 om 02:01 schreef Bjoern A. Zeeb:
> On 22 Jun 2016, at 17:56, Ivan Klymenko wrote:
>
>> On Wed, 22 Jun 2016 20:45:26 +0300
>> Ivan Klymenko  wrote:
>>
>>> On Wed, 22 Jun 2016 20:36:36 +0300
>>> Ivan Klymenko  wrote:
>>>
 Hello.
 After update from r302000 to r302083 i have panic
 http://i.imgur.com/YfvvhdS.png

 Thanks.
>>> Sorry, the first time discovered a revision  r302060.
>>
>> There is a suspicion that the reason for this commit:
>> https://svnweb.freebsd.org/base?view=revision=302054
>
> Do you compile pflog into the kernel or load it from loader by any
> chance?   I can see what might happen here.
>
> Can you try to see if this goes away if you load pflog after pf is
> loaded?   If that helps change the SI_SUB_PSEUDO at the end of
> sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix it.
>
> /bz
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"

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

Re: Fatal trap 12

[Johan Hendriks]

I have the following in my kernel config
# pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
device  pf
device  pflog
device  pfsync

I can not alter the order the modules load as far as I know.
I changed the following in /usr/src/sys/netpfil/pf/if_pflog.c

from

DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);

to

DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_FIREWALL, SI_ORDER_ANY);

But after a buildworld the same error.



Op 23/06/16 om 02:01 schreef Bjoern A. Zeeb:
> On 22 Jun 2016, at 17:56, Ivan Klymenko wrote:
>
>> On Wed, 22 Jun 2016 20:45:26 +0300
>> Ivan Klymenko  wrote:
>>
>>> On Wed, 22 Jun 2016 20:36:36 +0300
>>> Ivan Klymenko  wrote:
>>>
 Hello.
 After update from r302000 to r302083 i have panic
 http://i.imgur.com/YfvvhdS.png

 Thanks.
>>> Sorry, the first time discovered a revision  r302060.
>>
>> There is a suspicion that the reason for this commit:
>> https://svnweb.freebsd.org/base?view=revision=302054
>
> Do you compile pflog into the kernel or load it from loader by any
> chance?   I can see what might happen here.
>
> Can you try to see if this goes away if you load pflog after pf is
> loaded?   If that helps change the SI_SUB_PSEUDO at the end of
> sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix it.
>
> /bz
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"

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

Re: Fatal trap 12

[Johan Hendriks]

Just a me too.

Build yesterday (revision unclear) and starts fine, today a rebuild and
a panic.
But I do not see the panic message as it reboots right away.
The latest line I see is

atkbd0:  irq 1 on atkbdc0

Then a real quick panic and then it reboots.
I captured it by filming and then pause it before the reboot. ( the
first part is unreadable, but from processor eflags it is the same!
except the 0xf80b values.)
But also 10 lines of KDB stack backtrace: , and 1s uptime.

The old kernel boots fine!

My system uses root on ZFS!

regards
Johan


Op 22/06/16 om 19:36 schreef Ivan Klymenko:
> Hello.
> After update from r302000 to r302083 i have panic
> http://i.imgur.com/YfvvhdS.png
>
> Thanks.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
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: em(4) broken in HEAD?

[Johan Hendriks]

H

Op vrijdag 20 mei 2016 heeft Joel Dahl  het volgende
geschreven:

> On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote:
> > On Fri, 20 May 2016 13:55:50 +0200
> > Joel Dahl > wrote:
> >
> > > Hi,
> > >
> > > I've just rebuilt CURRENT on a VMware virtual machine and it's now
> > > running r300276. After reboot, I ssh'ed to the machine but my ssh
> > > session hanged after ~10 seconds or so. The console started spitting
> > > out "em0: Watchdog timeout - resetting" messages at the same time.
> > > Basically no networking works.
> > >
> > > It's the same thing after every reboot. Networking works for a few
> > > seconds, just long enough for you to run a couple of commands over
> > > ssh. Then it breaks.
> > >
> > > My previous build on this machine was from about one week ago. It
> > > works like it should.
> > >
> >
> > Do you use by any means IPFW ?
>
> Nope.
>
> --
> Joel
> ___
> 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
> "
>


Do you have alias ipadresses on the interface. That is what I have and that
is broken. If i disable alias ipadresses, all is fine again. Btw in my case
it is on alc0 as i do not have an em interface to test.
___
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"

alc0 aliases not working anymore after update to r300138

[Johan Hendriks]

Hello all.

I just rebuild current today, and now I can not use aliases on my
network interface anymore.

FreeBSD desk.server.testdomain.nl 11.0-CURRENT FreeBSD 11.0-CURRENT #6
r300138: Wed May 18 14:30:38 CEST 2016
r...@desk.server.testdomain.nl:/usr/obj/usr/src/sys/KRNL  amd64

my /etc/rc.conf looks like this (relevant part)

hostname="desk.server.testdomain.nl"
ifconfig_alc0="inet 192.168.2.237 netmask 255.255.255.0"
ifconfig_alc0_alias0="inet 192.168.1.155 netmask 255.255.255.255"
defaultrouter="192.168.2.1"

If I start the server with the alias commented out all is fine. If I
edit /etc/rc.conf and remove the # and run /etc/netstart, then ifconfig
shows both ipadresses and everything still works.
But after a reboot, the network card is not working, also a netstat -r
takes about 30 seconds to return to the prompt. If started without an
alias on the interface the prompt is back instant.

If I comment out the alias line and restart the server I can use my
network again,

Before my build world of yesterday all was fine.

regards




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

Re: Buildworld Fails

[Johan Hendriks]

My first Bug report for FreeBSD! Please be gentle with me if it is not
done right!

Bug 209435 has been successfully created


Regards
Johan

Op 10/05/16 om 20:36 schreef Adrian Chadd:
> Hi,
>
> please file a bug and I'll go make sure we can run it without it
> running a script like this. should be easy to do.
>
>
> -a
>
>
> On 10 May 2016 at 11:29, Johan Hendriks <joh.hendr...@gmail.com> wrote:
>>
>> Op 10/05/16 om 19:47 schreef Dimitry Andric:
>>> On 10 May 2016, at 13:53, Johan Hendriks <joh.hendr...@gmail.com> wrote:
>>>> My buildworld of current fails today with the following error message.
>>>> This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
>>>> 11.0-CURRENT #8 r299158:
>>> ...
>>>> ===> bhnd (all)
>>>> machine -> /usr/src/sys/amd64/include
>>>> x86 -> /usr/src/sys/x86/include
>>>> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
>>>> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
>>>> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
>>>> (Permission denied)
>>> Have you got /usr/src mounted noexec?
>>>
>>> -Dimitry
>>>
>> Thank you all.
>> I had exec=off on my /usr/src zfs dataset.
>>
>> Never needed exec on /usr/src so for that reason it was turned to off.
>> Till now, now it is turned to on.
>>
>> Now the kernel builds fine.
>>
>> Thanks Adrian and Dimitry for your time.
>>
>> regards
>> Johan
>>
>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: Buildworld Fails

[Johan Hendriks]

Op 10/05/16 om 19:47 schreef Dimitry Andric:
> On 10 May 2016, at 13:53, Johan Hendriks <joh.hendr...@gmail.com> wrote:
>> My buildworld of current fails today with the following error message.
>> This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
>> 11.0-CURRENT #8 r299158:
> ...
>> ===> bhnd (all)
>> machine -> /usr/src/sys/amd64/include
>> x86 -> /usr/src/sys/x86/include
>> /usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh
>> /usr/src/sys/dev/bhnd/nvram/nvram_map -h
>> make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
>> (Permission denied)
> Have you got /usr/src mounted noexec?
>
> -Dimitry
>
Thank you all.
I had exec=off on my /usr/src zfs dataset.

Never needed exec on /usr/src so for that reason it was turned to off.
Till now, now it is turned to on.

Now the kernel builds fine.

Thanks Adrian and Dimitry for your time.

regards
Johan



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

Buildworld Fails

[Johan Hendriks]

My buildworld of current fails today with the following error message.
This is FreeBSD desk.server.netaffairs.nl 11.0-CURRENT FreeBSD
11.0-CURRENT #8 r299158:

cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/KRNL/opt_global.h -I. -I/usr/src/sys -fno-common -g
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/sys/KRNL  -MD  -MF.depend.if_bge.o -MTif_bge.o
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -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  -mno-aes
-mno-avx  -std=iso9899:1999 -c
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c -o if_bge.o
ctfconvert -L VERSION -g if_bge.o
ld -d -warn-common -r -d -o if_bge.ko.full if_bge.o
ctfmerge -L VERSION -g -o if_bge.ko.full if_bge.o

:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk if_bge.ko.full  export_syms |
xargs -J% objcopy % if_bge.ko.full
objcopy --only-keep-debug if_bge.ko.full if_bge.ko.debug
objcopy --strip-debug --add-gnu-debuglink=if_bge.ko.debug 
if_bge.ko.full if_bge.ko
===> bhnd (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh 
/usr/src/sys/dev/bhnd/nvram/nvram_map -h
make[4]: exec(/usr/src/sys/dev/bhnd/tools/nvram_map_gen.sh) failed
(Permission denied)
*** Error code 1

Stop.
make[4]: stopped in /usr/src/sys/modules/bhnd
*** Error code 1

Stop.
make[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/KRNL
*** Error code 1

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

Stop.
make: stopped in /usr/src


My kernel Config File

include GENERIC
ident   KRNL

# hast support
options GEOM_GATE

# Carp support
device  carp

# pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
device  pf
device  pflog
device  pfsync

# new CAM scheduler
options CAM_NETFLIX_IOSCHED

# Console color options
options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK)
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK)
options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)

# System console options
options SC_DISABLE_REBOOT   # disable reboot key sequence
options SC_HISTORY_SIZE=8192 # number of history buffer lines

What could be wrong?

regards

Johan


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

Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd)

[Johan Hendriks]

Op 02/05/16 om 02:49 schreef Warren Block:
> CAM I/O Scheduler
>
>Links
>I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL:
>https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
>The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU
>
>Contact: Warner Losh 
>
>An enhanced CAM I/O scheduler has been committed to the tree. By
>default, this scheduler implements the old behavior. In addition, an
>advanced adaptive scheduler is available. Along with the scheduler,
>SATA disks can now use Queued Trims with devices that support them.
>Details about the new scheduler are available in the I/O Scheduling in
>FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk.
>
>The adaptive I/O scheduler is disabled by default, but can be enabled
>with options CAM_ADAPTIVE_IOSCHED in the kernel config file. This
>scheduler allows favoring reads over writes (or vice versa),
>controlling the IOPs, bandwidth, or concurrent operations (read,
> write,
>trim), and permits the selection of static or dynamic control of these
>operations. In addition, a number of statistics are collected for
> drive
>operations that are published via sysctl. One advanced use for the
>adaptive I/O scheduler is to compensate for deficiencies in some
>consumer-grade SSDs. These SSDs exhibit a performance cliff if too
> much
>data is written to them too quickly due to internal garbage
> collection.
>Without the I/O scheduler, read and write performance drop
>substantially once garbage collection kicks in. The adaptive I/O
>scheduler can be configured to monitor read latency. As read latency
>climbs, the I/O scheduler reduces the allowed write throughput, within
>limits, to attempt to maximize read performance. A simple use of the
>adaptive I/O scheduler would be to limit write bandwidth, IOPs or
>concurrent operations statically.
>
>Future work on the I/O scheduler will be coupled with improvements to
>the upper layers. The upper layers will be enhanced to communicate how
>urgent I/O requests are. The I/O scheduler will inform the upper
> layers
>of how full the I/O queues are, so less urgent I/O can be submitted to
>the lower layers as quickly as possible without overwhelming the lower
>layers or starving other devices of requests.
>
>This project was sponsored by Netflix.
>  __
I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error
about an unknown option.
If I use CAM_NETFLIX_IOSCHED the kernel compiles.
Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED?

regards
Johan

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

Re: Heads up

[Johan Hendriks]

Op 15/04/16 om 19:30 schreef Warner Losh:

> Also a horrible name. It's a generic I/O scheduler. It can do lots of
> things. I keep saying that, and categorically refuse to name the more
> expansive scheduler anything that's so limiting.
>
> Warner
Thanks for all the work on this.

One question?

If the scheduler can do a lot of things what are the defaults set to?
Are they set to the Netflix load or more like the behauvier of a
standard FreeBSD before this patch.

regards
Johan

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

Re: FreeBSD 10 and zfsd

[Johan Hendriks]

op 24-03-14 01:18, Alan Somers schreef:

On Sun, Mar 23, 2014 at 4:23 PM, Mark Felder f...@freebsd.org wrote:

Hi guys,

Any updates?

I've been very busy, but I did finally get those two seqpacket related
bugs fixed in head.  The next step is finding time for the merge.
Right now my FreeBSD todo list goes:
1) Commit fixes for half a dozen FIB related bugs.  I already have
them fixed in my private stable/9 branch, but need to port the fixes
to HEAD.
2) Update the zfsd branch.

I think that I'll be able to get number 1 done next week, or at least
send patches out for review.  I don't know if I'll get to number 2.

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


Hello all. Sorry for bringing up on old thread.
Is there any news on the zfsd part.
It seems it has been included in Truenas, but I did not see anything hit 
the tree regarding zfsd. Have I missed it or is it still not done.
FreeBSD 9.3 is about to get released, and 10.1 will follow it would be 
nice to have in a new build..



regards
Johan

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

Re: FreeBSD 10 and zfsd

[Johan Hendriks]

Op maandag 23 juni 2014 heeft Alan Somers asom...@freebsd.org het
volgende geschreven:

 On Mon, Jun 23, 2014 at 12:50 AM, Johan Hendriks joh.hendr...@gmail.com
 javascript:; wrote:
 
  op 24-03-14 01:18, Alan Somers schreef:
 
  On Sun, Mar 23, 2014 at 4:23 PM, Mark Felder f...@freebsd.org
 javascript:; wrote:
 
  Hi guys,
 
  Any updates?
 
  I've been very busy, but I did finally get those two seqpacket related
  bugs fixed in head.  The next step is finding time for the merge.
  Right now my FreeBSD todo list goes:
  1) Commit fixes for half a dozen FIB related bugs.  I already have
  them fixed in my private stable/9 branch, but need to port the fixes
  to HEAD.
  2) Update the zfsd branch.
 
  I think that I'll be able to get number 1 done next week, or at least
  send patches out for review.  I don't know if I'll get to number 2.
 
  -Alan
  ___
  freebsd-current@freebsd.org javascript:; mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org javascript:;
 
 
  Hello all. Sorry for bringing up on old thread.
  Is there any news on the zfsd part.
  It seems it has been included in Truenas, but I did not see anything hit
 the
  tree regarding zfsd. Have I missed it or is it still not done.
  FreeBSD 9.3 is about to get released, and 10.1 will follow it would be
 nice
  to have in a new build..

 The projects/zfsd project branch is up to date.  Merging it to CURRENT
 is blocked on these tasks.

 1) (The biggie) We must resolve the issue with multiple geom opens.
 Geom tries to prevent any two consumers from simultaneously opening
 the same provider.  This is why, for example, you can't do dd
 if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system.
 However, ZFS internally opens spare devices multiple times.  The only
 way that geom will allow that is if ZFS opens devices non-exclusively.
 That means that you will lose your protection.  Fixing this correctly
 requires deep changes to ZFS to remove the multiple opens.

 2) Need to merge in zfsd's functional tests.  I'm currently working on
 this issue as time allows.

 3) It needs a manpage.

 4) Various bug fixes need to be merged to the kernel and to LibZFS.
 Coordinating with Illumos makes that process slow.  will@ is working
 on it as time allows.

 5) libdevctl needs to be made private

 6) The sequential packet feature added to devd in the zfsd project
 branch at revision r266519 must be merged to head.  It's currently
 waiting for review from imp@ and ian@.

 For TrueNAS, I believe that delphij@ merged an older version of zfsd
 from the project branch.

 -Alan

 
 
  regards
  Johan
 
 
  ___
  freebsd-current@freebsd.org javascript:; mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org javascript:;


Thanks for the headsup and your time explaning the issues..

Regards
Johan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] bsdinstall and zfsboot enhancements

[Johan Hendriks]

Teske, Devin schreef:

Hi all,

Another Call For Testing...
This one is for bsdinstall.

Two patchsets are required for this CFT:

http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

The enhancements are:

+ Add a `-D FILE command-line option for overriding the
path to the bsdinstall log file (BSDINSTALL_LOG env var).

+ Document new `-D FILE' in the man page for bsdinstall.

+ If FILE in `-D FILE' begins with a +, debug output goes to
stdout (interleaved between dialog(1) invocations/output) as
well as to FILE (minus the leading + of course).

+ If BSDINSTALL_LOG cannot be written, then debugging is
disabled (except in the case of a leading + in the pathname,
wherein debug will still be printed to stdout).

+ Update source code format to approximate a future shstyle(9)

+ Fix a dangling participle (Begun ... - Began ...)

+ Rewrite the docsinstall script (was necessary to abate direct
dependency on BSDINSTALL_LOG (instead, use fault-tolerant
bsdconfig framework which displays appropriate errors for
package management).

+ Add additional debug output for dhclient/rtsol/wpa_cliscan

+ Display script errors in a textbox rather than just on stdout

+ Update many coments.

+ Add new f_show_err() API call (like f_show_msg but changes
the dialog title to Error)(see bsdconfig's `common.subr').

+ Add new f_eval_catch() API call for executing a command via
eval but not before logging the command to debug. Several
example cases documented in API header for function in
bsdconfig's `common.subr'.

+ Fix dialog auto-sizing when launched as an rvalue to a pipe
for indirected scripts (previously would default to 80x24 sizing
in this case, now it can autosize to full size even when in a pipe
chain).

+ Fix a bug in f_snprintf wherein if the $format argument began
with a - or -- it would be misinterpreted as a flag to printf. (this
is in bsdcofig's strings.subr)

+ Add accompanying f_sprintf() and f_vsprintf() to go along with
already existing f_snprintf() and f_vsnprintf() (see bsdconfig's
strings.subr).

+ Update bsdinstall's config script to adjust ttyu* entries in
/etc/ttys when it is determined that we are in-fact doing an install
over serial (e.g. bhyve).

+ Remove some unnecessary default ZFS datasets from the
automatic zfsboot script. Such as: /usr/ports/distfiles
/usr/ports/packages /usr/obj /var/db /var/empty /var/mail and
/var/run (these can all be created as-needed once the system is
installed).

+ Remove setuid=off for /usr/home (as discussed with others from
last round of CFT).

+ Fix some i18n string violations in zfsboot

+ Bolster debugging output in zfsboot

+ Fix some string quoting issues in zfsboot

+ Fix some variable scope issues in zfsboot

+ Only display the ZFS vdev type selection menu when running
interactively (duh).

+ Change Create to Install in zfsboot main menu

+ Increase pedantic error checking in zfsboot (type-check
arguments and such).

+ Add a call to graid destroy to kill automatic metadata (part of
the series of pedantic destructions we do when bootstrapping
a new/naked disk).

+ Make judicious use of new f_eval_catch() in zfsboot

+ More comments (zfsboot).

+ Fixup some variable names for consistency (zfsboot).

I did not try this installer myself, but one question, can i seperate 
the swap space from the pool?

I have seen to many strange hangs on a server where i use swap on zfs!

regards
Johan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 and zfsd

[Johan Hendriks]

Johan Hendriks schreef:
When i started using ZFS on FreeBSD I quickly found out that hot 
spares are not possible on FreeBSD.
I was told that with zfsd it should be possible and that it would be 
included in FreeBSD 10.


Is there some info about the zfsd function and how it could be used?

regards
Johan Hendriks

On the wiki page  Whats new for FreeBSD 10 
https://wiki.freebsd.org/WhatsNew/FreeBSD10 under Other changes zfsd is 
mentioned as beeing part of 10.0


ZFS fault monitoring and management daemon, 
http://svn.freebsd.org/changeset/base/222836

Maybe it should be removed from that page.

regards
Johan



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

Re: FreeBSD 10 and zfsd.

[Johan Hendriks]

Johan Hendriks wrote:
When i started using ZFS on FreeBSD I quickly found out that hot 
spares are not possible on FreeBSD.
I was told that with zfsd it should be possible and that it would be 
included in FreeBSD 10.


Is there some info about the zfsd function and how it could be used?

regards
Johan Hendriks


Thanks all for the explanation and your time
A notice in the handbook may be a good thing to let new FreeBSD users 
know that you can add spares, but that it is not a hot spare.

So human action is required to activate the spare.

regards
Johan Hendriks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

FreeBSD 10 and zfsd

[Johan Hendriks]

When i started using ZFS on FreeBSD I quickly found out that hot spares 
are not possible on FreeBSD.
I was told that with zfsd it should be possible and that it would be 
included in FreeBSD 10.


Is there some info about the zfsd function and how it could be used?

regards
Johan Hendriks

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

Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking

[Johan Hendriks]

Alexander Motin wrote:

Hi.

I would like to invite more people to review and test my patches for 
improving CAM and GEOM scalability, that for last six months you could 
see developing in project/camlock SVN branch. Full diff of that branch 
against present head (r255131) can be found here:

http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch

Heavy CAM changes there were focused on reducing scope of SIM lock to 
only protecting SIM internals, but not CAM core. That allows many 
times reduce lock congestion, especially on heavily parallel request 
submission with GEOM changes below. More detailed description of 
changes you could see here earlier:

http://docs.freebsd.org/cgi/mid.cgi?520D4ADB.50209

GEOM changes were focused on avoiding switching to GEOM up/down 
threads in relatively simple setups where respective classes don't 
require it (and were explicitly marked so). That allows save on 
context switches and on systems with several HBAs and disks talk to 
them concurrently (that is where CAM locking changes are handy). Such 
classes were modified to support it: DEV, DISK, LABEL, MULTIPATH, NOP, 
PART, RAID (partially), STRIPE, ZERO, VFS, ZFS::VDEV, ZFS::ZVOL and 
some others. Requests to/from other classes will be queued to GEOM 
threads same as before.


Together that allows to double block subsystem performance on high (at 
least 100-200K) IOPS benchmarks, allowing to reach up to a million 
total IOPS, while keeping full compatibility with all major ABIs/KBIs.


Since we are already in 10.0 release process and changes are quite 
big, my plan is to wait and commit them to head branch after the 
freeze end, and then merge to stable/10.  I hope the release process 
will go on schedule to not delay this work for another six months.


This work is sponsored by iXsystems, Inc.


Hello i would like to test this patch set.
But how can i stress the machine, do you have a script or something i 
can use to make the system do heavy I/O on the disks!


regards
Johan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: On 10.0, Clang is not accepted as compiler

[Johan Hendriks]

Super Bisquit schreef:

What argument  do I need to add to /etc/make.conf to correct this?

Thanks muchly.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

On CURRENT aka 10, Clang is the default compiler.
As far as i know, you do not have to set anything in /etc/make.conf.

regards
Johan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS/RAIDZ and SAMBA: abyssimal performance

[Johan Hendriks]

Fleuriot Damien schreef:

On Jan 4, 2013, at 4:19 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote:


Am 01/04/13 15:45, schrieb Garrett Cooper:

On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien m...@my.gd wrote:

...


And this is under [global] in /usr/local/etc/smb.conf:
   min receivefile size = 16384
   aio read size = 16384
   aio write size = 16384
   aio write behind = yes

These are still pretty low, depending on what your networking/disk
setup is like; my important performance settings are:

socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY
IPTOS_LOWDELAY IPTOS_THROUGHPUT
write cache size = 65536
aio read size = 65536
aio write size = 65536
directory name cache size = 0

HTH,
-Garrett

Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot
Damien's values to /boot/loader.conf and yours to the smb.conf.
Somewhere in the handbook this should be documented! it is to much
efford to get SAMBA working properly with ZFS, if the tricks and
problems are so widespread over several architectural aspects of the system.

It could save a lot of time for adminsitartors and those which try
FreeBSD as a serving system instead of Linux.

Just for the record. I feel a bit confused about all the tricks and
tweak now published for ZFS, its magic L2ARC, the kernel_vmem wizzardy
thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would
be a great deal if all these things could be lined up a s a primer with
a bit more explanations than put this number there.

And by the way, it is like changing from hell to heaven having now ~ 100
MB/s throughput compared to ~1/500!

Thanks a lot,
Oliver



The problem, Oliver, is that these values are system dependant.

Notice how Garret replied that these values are a bit low (and they might be 
indeed !).

However, while you have 16gb RAM, my ZFS NAS only has 4gb.



Basically and as Jeremy Chadwick pointed out at the time, there is no one set 
of correct values for 100% of the population.

One has to adjust them step by step and decide what is best for them.



@garret: I'll try with the values you posted, although I get 90-120mbytes/s 
most of the time so I pretty much saturate my 1gbs link.

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

The only zfs tunable i use in my /boot/loader.conf is vfs.zfs.arc_max=
I  leave 4 GB for the system itself in most cases.

In my smb.conf i use the following
socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072
max protocol = SMB2
But if you set that then you can not use the aio settings as samba will 
crash then.


if you use aio also make sure you load the aio module by setting the 
following in the /boot/loader.conf

aio_load=YES

@Oliver
I see you use one device for ZIL/log and L2ARC/cache.
Be aware that you can lose the L2ARC/cache without data corruption, but 
losing the ZIL/log device might cause corrupted data.

So always create a mirror for the ZIL/log device.

gr
Johan Hendriks







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

auditdistd config file location

[Johan Hendriks]

Hello all.

I had some spare time so i thought it was a good moment to look at 
auditdistd .

One thing i noticed was the default config file location.
The man page and the wiki tells me it is /etc/security/auditdistd

I enabled audistd by placing the following in the rc.conf file
auditdistd_enable=YES

However if i want to start the deamon, it tells me the config file is 
not present.

And that is correct, because my config is in /etc/security/ and not /etc/

[root@smb-filer01 ~]# /etc/rc.d/auditdistd start
/etc/rc.d/auditdistd: WARNING: /etc/auditdistd.conf is not readable.
/etc/rc.d/auditdistd: WARNING: failed precmd routine for auditdistd
[root@smb-filer01 ~]#

I think the default location of the config file needs to be modified to 
match that of the wiki page and the man page.


regards
Johan  Hendriks


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

Re: LSI supported mps(4) driver available

[Johan Hendriks]

Kenneth D. Merry schreef:
 
 On Tue, Jan 24, 2012 at 15:42:57 +0100, Johan Hendriks wrote:
 Kenneth D. Merry schreef:
 The LSI-supported version of the mps(4) driver that supports their 6Gb SAS
 HBAs as well as WarpDrive controllers, is available here:
 
 http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt
 
 I plan to check it in to head next week, and then MFC it into stable/9 a
 week after that most likely.
 
 Please test it out and let me know if you run into any problems.
 
 In addition to supporting WarpDrive, the driver also supports Integrated
 RAID.
 
 Thanks to LSI for doing the work on this driver!
 
 I have added a number of other infrastructure changes that are necessary
 for the driver, and here is a brief summary:
 
  - A new Advanced Information buffer is now added to the EDT for drives
that support READ CAPACITY (16).  The da(4) driver updates this buffer
when it grabs new read capacity data from a drive.
  - The mps(4) driver will look for Advanced Information state change async
events, and updates its table of drives with protection information
turned on accordingly.
  - The size of struct scsi_read_capacity_data_long has been bumped up to
the amount specified in the latest SBC-3 draft.  The hope is to avoid
some future structure size bumps with that change.  The API for
scsi_read_capacity_16() has been changed to add a length argument.
Hopefully this will future-proof it somewhat.
  - __FreeBSD_version bumped for the addition of the Advanced Information
buffer with the read capacity information.  The mps(4) driver has a
kludgy way of getting the information on versions of FreeBSD without
this change.
 
 I believe that the CAM API changes are mild enough and beneficial enough
 for a merge into stable/9, but they are intertwined with the unmap changes
 in the da(4) driver, so those changes will have to go back to stable/9 as
 well in order to MFC the full set of changes.
 
 Otherwise it'll just be the driver that gets merged into stable/9, and
 it'll use the kludgy method of getting the read capacity data for each
 drive.
 
 A couple of notes about issues with this driver:
 
  - Unlike the current mps(4) driver, it probes sequentially.  If you have 
  a
lot of drives in your system, it will take a while to probe them all.
  - You may see warning messages like this:
 
 _mapping_add_new_device: failed to add the device with handle 0x0019 to 
 persiste
 nt table because there is no free space available
 _mapping_add_new_device: failed to add the device with handle 0x001a to 
 persiste
 nt table because there is no free space available
 
  - The driver is not endian safe.  (It assumes a little endian machine.)
This is not new, the driver in the tree has the same issue.
 
 The LSI folks know about these issues.  The driver has passed their testing
 process.
 
 Many thanks to LSI for going through the effort to support FreeBSD.
 
 Ken
 Sorry to bother you with this, but how do i test this on a 9.0 release 
 machine.
 I am no developer what so ever, but we use some LSI 9211-8i cards, in 
 supermicro storage machines.
 One machine give me scsi timeouts, and i like to try the new driver.
 
 I did the following: save the 
 http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt as lsi.patch 
 in /root
 
 then
 # cd /usr
 # patch  lsi.patch
 I do get some .rej from patch
 
 But when i rebuild the kernel it errors out, so i think i am doing 
 something wrong.
 The overall patch won't apply cleanly to 9.0, because it depends on some
 other CAM changes that are not in 9.0.
 
 The driver itself may apply and work, however.
 
 The easiest thing to do may be to edit the patch and only keep the patches
 against files in sys/dev/lsi, sys/conf, and sys/modules.
 
 Before you apply the revised patch, make sure you either back out the
 previous patch attempt, or otherwise get a clean source tree.
 
 Ken
Ok thanks.

I did some homework on patching, and to my own surprice, the altered patch i 
have now even compiles on 9.0-RELEASE.  :D
only the param.h failed in the end, and i can not figure out why.

So i hope the change in that file is not that important.
I am running it now on a Supermicro 3U storage server with a few sata disk in 
it, with a single LSI 9211-8i card connected the the backplane.

It seems to do the job.
The driver coming with 9.0 had some trouble when i remirror some drives, i try 
that tomorrow.

i have put the patch here http://xs4all.nl/~doub/mps.patch 

my dmesg for what is worth

filer01# dmesg
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-RELEASE #1: Thu Jan 26 15:37:38 CET 2012
root@filer01.neuteboom.local:/usr/obj/usr/src/sys/KRNL amd64
CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU

Re: LSI supported mps(4) driver available

[Johan Hendriks]

Kenneth D. Merry schreef:

On Tue, Jan 24, 2012 at 15:42:57 +0100, Johan Hendriks wrote:

Kenneth D. Merry schreef:

The LSI-supported version of the mps(4) driver that supports their 6Gb SAS
HBAs as well as WarpDrive controllers, is available here:

http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt

I plan to check it in to head next week, and then MFC it into stable/9 a
week after that most likely.

Please test it out and let me know if you run into any problems.

In addition to supporting WarpDrive, the driver also supports Integrated
RAID.

Thanks to LSI for doing the work on this driver!

I have added a number of other infrastructure changes that are necessary
for the driver, and here is a brief summary:

  - A new Advanced Information buffer is now added to the EDT for drives
that support READ CAPACITY (16).  The da(4) driver updates this buffer
when it grabs new read capacity data from a drive.
  - The mps(4) driver will look for Advanced Information state change async
events, and updates its table of drives with protection information
turned on accordingly.
  - The size of struct scsi_read_capacity_data_long has been bumped up to
the amount specified in the latest SBC-3 draft.  The hope is to avoid
some future structure size bumps with that change.  The API for
scsi_read_capacity_16() has been changed to add a length argument.
Hopefully this will future-proof it somewhat.
  - __FreeBSD_version bumped for the addition of the Advanced Information
buffer with the read capacity information.  The mps(4) driver has a
kludgy way of getting the information on versions of FreeBSD without
this change.

I believe that the CAM API changes are mild enough and beneficial enough
for a merge into stable/9, but they are intertwined with the unmap changes
in the da(4) driver, so those changes will have to go back to stable/9 as
well in order to MFC the full set of changes.

Otherwise it'll just be the driver that gets merged into stable/9, and
it'll use the kludgy method of getting the read capacity data for each
drive.

A couple of notes about issues with this driver:

  - Unlike the current mps(4) driver, it probes sequentially.  If you have
  a
lot of drives in your system, it will take a while to probe them all.
  - You may see warning messages like this:

_mapping_add_new_device: failed to add the device with handle 0x0019 to
persiste
nt table because there is no free space available
_mapping_add_new_device: failed to add the device with handle 0x001a to
persiste
nt table because there is no free space available

  - The driver is not endian safe.  (It assumes a little endian machine.)
This is not new, the driver in the tree has the same issue.

The LSI folks know about these issues.  The driver has passed their testing
process.

Many thanks to LSI for going through the effort to support FreeBSD.

Ken

Sorry to bother you with this, but how do i test this on a 9.0 release
machine.
I am no developer what so ever, but we use some LSI 9211-8i cards, in
supermicro storage machines.
One machine give me scsi timeouts, and i like to try the new driver.

I did the following: save the
http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt as lsi.patch
in /root

then
# cd /usr
# patch  lsi.patch
I do get some .rej from patch

But when i rebuild the kernel it errors out, so i think i am doing
something wrong.

The overall patch won't apply cleanly to 9.0, because it depends on some
other CAM changes that are not in 9.0.

The driver itself may apply and work, however.

The easiest thing to do may be to edit the patch and only keep the patches
against files in sys/dev/lsi, sys/conf, and sys/modules.

Before you apply the revised patch, make sure you either back out the
previous patch attempt, or otherwise get a clean source tree.

Ken

Ok thanks.

I did some homework on patching, and to my own surprice, the altered 
patch i have now even compiles on 9.0-RELEASE.  :D

only the param.h failed in the end, and i can not figure out why.

So i hope the change in that file is not that important.
I am running it now on a Supermicro 3U storage server with a few sata 
disk in it, with a single LSI 9211-8i card connected the the backplane.


It seems to do the job.
The driver coming with 9.0 had some trouble when i remirror some drives, 
i try that tomorrow.


i have put the patch here http://xs4all.nl/~doub/mps.patch maybe you can 
use it, maybe not.


my dmesg for what is worth

filer01# dmesg
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-RELEASE #1: Thu Jan 26 15:37:38 CET 2012
root@filer01.neuteboom.local:/usr/obj/usr/src/sys/KRNL amd64
CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x206a7

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Johan Hendriks]

Stefan Esser schreef:

Am 21.12.2011 22:49, schrieb Johan Hendriks:

Nice page, but one thing i do not get is the following.

[quote]
If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC
4.7 then the results are unlikely to tell you anything meaningful about
FreeBSD vs Ubuntu.
[/quote]

That is a little strange in my opinion.
It tells me that FreeBSD falls more and more behind on Linux.
The reason is or could be that FreeBSD cannot or will not include GCC
4.7 and that FreeBSD will not be on par with Linux anymore.
To compare it with Formula1 cars.
If Mercedes decide to use the engine from 2 seasons back (the engine
version 4.2.1) in there 2012 car, and Ferrari uses there new Engine
(version 4.7).
Can we not compare them anymore because of the decission from Mercedes
to use the old engine?
No we just say, if you want to win a race, get the Ferrari.

It is the reallity, FreeBSD uses 4.2.1 as there compiler!!!

As has been pointed out by others, FreeBSD ships with gcc-4.2.1 (with
some local modifications and fixes) as the system compiler.



If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux
to 4.2.1, then that will tell me nothing about FreeBSD vs Linux.

The gcc version distributed with FreeBSD was chosen for license reasons,
not for technical reasons. If you are OK with installing a GPLv3
licensed compiler on your systems, then just do it and take advantage of
the improved code generated by it.
It does not matter what the decission is to use the old compiler, it is 
a fact that the base comes with 4.2.x
Does that mean we can not compare/benchmark against other distributions 
because they use GPLv3 stuff.
No, i want to know where standard released FreeBSD stands against 
standard released Linux distributions.
If you compare benchmark userland applictions, then it is fair to use 
the latest compiler for the userland software also on FreeBSD.
But what if the ports tree defaults to LLVM, then again we want to know 
what FreeBSD does against a Linux distribution.

Why because that is what most of us will be using...!!

If we start to compile all the ports with gcc 4.7 to be on par in 
comparising and benchmarking, why spend all the time getting LLVM as the 
default compiler for ports also?
Why not take that effort into making the WHOLE ports tree to compile 
with GCC4.7?


Reason, because FreeBSD goes the LLVM route. That is a decission FreeBSD 
is making!
And that choise will be the FreeBSD that is used in comparising and 
benchmarks on the net , not the utterly overcopiled and tuned FreeBSD 
against stock Ubuntu or whatever Linux distribution.


If it is a good or bad choice! That we will see in the 
comparising/benchmarks we will be seeing when that time comes.


Same goes for the scheduler! and all the other subsystems FreeBSD has 
choosen, that makes FreeBSD.





I my opinion, you benchmark the latest release of Linux, FreeBSD,
Solaris, Windows and whatever OS you want to compare!

As you probably know, Linux is just the kernel and the distributions add
user space programs, including a compiler. You can easily create a
FreeBSD distribution with more advanced compiler and use or even sell
it. But the FreeBSD project was cautious to not heavily depend on a
GPLv3 compiler (for reasons openly discussed at the time this decision
was made).

I know Linux is a kernel, re read Linux as Linux Distribution!
Yes you can use a more advanced compiler on FreeBSD, BUT you can do that 
on Linux also ,so where do you stop?
Are you going to spend a month to compare a fullly tuned up FreeBSD 
system against a Linux distribution?
No because the users will not spend months tuning and recompile there 
servers.

They use the FreeBSD version that comes with the CD!
And that we want to compare/benchmark against a Linux distribution.


You want to benchmark the release and not a tuned version against a
standard version.
And that in general are the versions most of us users will use.

If you compare operating systems from a technical point of view, then
you'll be interested in relative performance of algorithms and methods
chosen. This is best achieved by using the same compiler for each of the
candidates.

If you compare performance from a user point of view, you are correct
that performance delivered out of the box (without complicated tuning)
may be, what counts for most users. But those users that depend on best
performance e.g. for a FreeBSD based embedded product or a data center,
may tune the system, including compilation with a newer compiler than
the system default.


And what if in the future LLVM gets on par with Linux, is it stil fair
to compare FreeBSD with Linux?

You can always compare anything with whatever you like (even apples with
oranges), but you need to be aware of what you compare and what your
goals are, to be able to draw reasonable conclusions.

If you want to test out of the box performance, then test with system
compilers (or just those binaries delivered

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Johan Hendriks]

Alexander Leidinger schreef:

Hi,

while the discussion continued here, some work started at some other place. 
Now... in case someone here is willing to help instead of talking, feel free to 
go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be 
improved. The page is far from perfect and needs some additional people which 
are willing to improve it.

This is only part of the problem. A tuning page in the wiki - which could be 
referenced from the benchmark page - would be great too. Any volunteers? A 
first step would be to take he tuning-man-page and wikify it. Other tuning 
sources are welcome too.

Every FreeBSD dev with a wiki account can hand out write access to the wiki. 
The benchmark page gives contributor-access. If someone wants write access 
create a FirstnameLastname account and ask here for contributor-access.

Don't worry if you think your english is not good enough, even some one-word 
notes can help (and _my_ english got already corrected by other people on the 
benchmark page).

Bye,
Alexander.



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


Nice page, but one thing i do not get is the following.

[quote]
If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 
4.7 then the results are unlikely to tell you anything meaningful about 
FreeBSD vs Ubuntu.

[/quote]

That is a little strange in my opinion.
It tells me that FreeBSD falls more and more behind on Linux.
The reason is or could be that FreeBSD cannot or will not include GCC 
4.7 and that FreeBSD will not be on par with Linux anymore.

To compare it with Formula1 cars.
If Mercedes decide to use the engine from 2 seasons back (the engine 
version 4.2.1) in there 2012 car, and Ferrari uses there new Engine 
(version 4.7).
Can we not compare them anymore because of the decission from Mercedes 
to use the old engine?

No we just say, if you want to win a race, get the Ferrari.

It is the reallity, FreeBSD uses 4.2.1 as there compiler!!!
If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux 
to 4.2.1, then that will tell me nothing about FreeBSD vs Linux.


I my opinion, you benchmark the latest release of Linux, FreeBSD, 
Solaris, Windows and whatever OS you want to compare!
You want to benchmark the release and not a tuned version against a 
standard version.

And that in general are the versions most of us users will use.

And what if in the future LLVM gets on par with Linux, is it stil fair 
to compare FreeBSD with Linux?
Or do we say, well we are on par, but it is not fair, yes we used the 
latest releases, but you can not blame Linux because they are still 
using GCC.
No what we will see then are haleluja blogs that FreeBSD is on par with 
Linux.


For me peformance is not a show stopper, and for the most of us i think 
it is not.
FreeBSD for me is a clean system that does the job perfect and has a 
very helpful community.


regards,
Johan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Johan Hendriks]

Arnaud Lacombe schreef:

Hi,

On Thu, Dec 15, 2011 at 2:32 AM, O. Hartmann
ohart...@zedat.fu-berlin.de  wrote:

Just saw this shot benchmark on Phoronix dot com today:

http://www.phoronix.com/scan.php?page=news_itempx=MTAyNzA


it might be worth highlighting that despite Oracle Linux 6.1 Server is
using a kernel + compiler almost 2 years old, it still manages to
out-perform the bleeding edge FreeBSD :-)

Now, from what I've read so far in this thread, it seems that a lot of
people are still in abnegation...

my 0.2c,
  - Arnaud


It may be worth to discuss the sad performance of FBSD in some parts of
the benchmark. A difference of a factor 10 or 100 is simply far beyond
disapointing, it is more than inacceptable and by just reading those
benchmarks, I'd like to drop thinking of using FreeBSD even as a backend
server in scientific and business environments. In detail, some of the
SciMark benches look disappointing. The overall image can't help over
the fact that in C-Ray FreeBSD is better performing.

 From the compiler, I'd like say there couldn't be a drop of more than 10
- 15% in performance - but not 10 or 100 times.

I'm just thinking about the discussion of SCHED_ULE and all the saur
spots we discussed when I stumbled over the test.

Regards,
Oliver


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


Well it is just the way it is.
I must say that every time FreeBSD comes out bad, there are always 
comments on how the benchmark is done, but NOT in the case when FreeBSD 
comes out better.

I remember the MySQL and ULE benchmarkings.
FreeBSD was quicker than Linux...
Nobody complains from the FreeBSD side that we did not use same gcc as 
Linux and what ever more, and maybe the benchmarks where more equil, do 
we care?

Is FreeBSD not doing the job anymore for you if it is, or if it is not?
Do you want to run Linux because it comes out better in benchmarks? i 
for certain do not.
And to be honest, i did try Linux because of the bad samba performance 
of FreeBSD, but i take the lower performance over the whole Linux thing. 
Linux is just not my cup of thee. Why? feeling, community ? i do not know.


See it from the bright side, there is much more room for improvements. :D

I think that FreeBSD should not worry that much about benchmarks.
Sure it is strange that FreeBSD shows such a great gap, but we all know 
that FreeBSD needs some tuning.
Also it is know that FreeBSD is quite conservative with some default 
settings.

Every now and then someone complains about this.
MAXPHYS is such a value that comes to mind.
What most people seems to be doing after installing FreeBSD is set some 
network tunings in /etc/sysctl.conf. and other stuff.


Maybe it is time to overlook the default settings, and make them more 
suitable for machines of today.


The argument is mostly that FreeBSD also needs to run on older hardware, 
but if you use amd64, you already have some 'newer' hardware.


just me  ...

regards
Johan Hendriks









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

Re: Dog Food tm

[Johan Hendriks]

Sean Bruno schreef:

On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote:

And what problems did you run into?


More or less, trying to do gmirror(4) style mirroring on GPT partitions
doesn't work.  See http://www.freebsd.org/doc/handbook/geom-mirror.html
for the BIG RED WARNING that says why.


This guide worked for me:
http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror

That, along with a lot of how to's, is out of date in the FreeBSD 9
world.  I would suspect that my experience of attempting to setup a
mirrored volume won't be unique.

BSDInstaller and its predecessor Sysinstall don't have any code to
create or destroy zfs(4) or geom(4) volumes.  So, the amount of exposure
to real users is approaching 0 in comparison to the number of people who
really do use FreeBSD.

I have my hands full with other projects at the moment, but I'm more
than happy to grant access to a two disk SATA server if someone wants to
enhance BSDInstall with zfs(4) or geom(4) volume management features.

At a minimum, you *should* be able to take 2 disks and make a mirrored
volume with either tool.

Sean

also a good guide is here.
http://unix-heaven.org/node/24
And gmirror GPT partitions is no problem, only with whole disks is where 
problems arise.


regards
Johan Hendriks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found

[Johan Hendriks]

al...@stokes.ca schreef:

However, programs such as startx and portupgrade are failing with the
message libz.so.5 not found.  I know I can fix this with an evil
symlink, but that doesn't seem right, and what else is broken?  Is there
not a facility in portupgrade to scan my live dependencies and warn me of
breakage?  I have not encountered such a beast in my gleanings to date.

What you probably did is make delete-old-libs.
This deletes the old 8.x libs that where used by your ports.
What you need to do is rebuild all your ports.

That way they get linked to the proper libs again.

The next time when you go from one major to another major number eg from 
7 to 8 or from 8 to 9 and so on, is to do the make delete-old-libs step 
later.
Then after upgrading, rebuild all your ports, they still work with the 
old libs.
Once the ports are rebuild against the newer libs then do the make 
delete-old-libs step.


This is not nessacery when going from a minor number to amother minor 
number. eg from 8.1 to 8.2 and so on.


Hope this helps.
regards
Johan Hendriks


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

Re: Use of newest version number such as 10.0 instead of current

[Johan Hendriks]

George Kontostanos schreef:

On Fri, Nov 11, 2011 at 4:39 PM, Miroslav Lachman000.f...@quip.cz  wrote:

Chuck Burns wrote:

On Friday, November 11, 2011 08:17:52 AM you wrote:
-snip-

My sentence is NOT about Current , but 9.0 RC1 .
Perhaps , you will NOT say , if a person is NOT knowledgeable , he should
NOT use 9.0 RC1 .


If you use a proper RC, then pkg_add will work until a new RC, and since
there
is no binary upgrade path for anything other than releases, you will need
to
reinstall, with the newly released RC.

You can use freebsd-update for RC upgrades too!


-snip-

Up to now , my most disappointed situation is that , there is NO any
tendency to
lower required expertise level to use FreeBSD .
Such an approach is confining FreeBSD to a small number of elite users
  when compared to millions of Linux users let alone hundred millions of
some other operating systems which they are approaching to billions when
version users are summed in spite of paying money also .

GhostBSD, PCBSD are two options for lower expertise and, as such, are
billed
as desktop versions of FreeBSD.

FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where you
can
build your own system, making it either into a server, workstation, or
even
into a desktop system if you so desire.

If you want something with point-n-click ease of use, go use one of the
two
desktop-oriented versions.

Both GhostBSD, and PCBSD are just a desktop environment built on top of
FreeBSD.  PCBSD even has a 9.0 RC out now as well, if you're into testing.

PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32
environment.
If you want something else, feel free to create your own. There is nothing
in
the BSD license that prevents you from doing that.

Instead of complaining that SOMEONE ELSE should do something that YOU want
done, why not just do it yourself.

In other words, put up, or shut up. :)

Really, this is not a proper worded answer to someone who just tried to
request some more friendliness to new users and increase our user base.

It doesn't metter if there are some other freebsd based projects. FreeBSD
it-self has a problem - fewer users = fewer manufacturers will support
FreeBSD (drivers).

Miroslav Lachman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


I agree 100%. The more people follow current the better releases we
will have in the future. Sure current in not for the beginner, you
will need to be able to compile world and kernel and produce debug
symbols. That is expected.

But maybe we should keep an open mind into ideas and not condemn them
immediately.

If FreeBSD starts using numbers for HEAD/CURRENT, i think a lot of users 
would find them selves in a situation
that they download version 10 in this case and that they are using a 
develepment version instead of a real release version.


So FreeBSD will get more frustrated users, who need to download the 
latest release again and so on.
Keeping the name more seperated from the normal numbering prevents this 
more or less.


Gr
Johan Hendriks



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

Re: x.0 RELASE isn't for production.

[Johan Hendriks]

Pavel Timofeev schreef:

I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be
longer. Six months, for example.
New STABLE branch is very important!


  So is opening head up to allow developers to work on and commit new
  code.  As with many things in engineering, there's a cost/benefit
  trade-off.  RE is doing a remarkable job, IMO.


Sorry, don't misunderstand me. I'm talking about new STABLE branch.
Maybe we need to change things like BETA-1(2) is still CURRENT. For
example, let's introduce a new concept ALPHA (which will be CURRENT). And
BETAs will be STABLE.

If you want a really stable OS ,then there is never going to be a release.
In CURRENT, there are a lot of changes already that do not go into 9.0
You _must_ take a point in time to release the release, even with known 
and pending patches.

If you are going to wait, then there will never be a release.

The 9.0.1, 9.0.2 branch idea is very apealling i must say.
But here the same problem do we wait for that one patch that is waiting MFC?
So the same problem when do you release the 9.0.x version!

Releasing the release is a trade-off.

I do like the current approach that FreeBSD uses.
The only thing i think could be better is to slow down the release cycle.
I would like to see a release like 9.8, which then have an enormous real 
world exposure and where all possible bugs are ironed out.

A release that you could use without hesitating  for your daily tasks.
But then there is a trade-off again, all new features that are pending 
in CURRENT do not get as much exposure as we would like, and then when 
the new CURRENT become the next production release, we could have a much 
more buggier release then normal.


So i am glad i do not have to make these dicisions. :D

regards
Johan Hendriks








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

9.x installer and GPT vs geom

[Johan Hendriks]

Hello all.

I just used the 9.0 B3 installer, and it defaults to GPT, which is nice.
However, and there has been some discussions about it, it would be nice 
if the installer warns me that i could get in trouble if i want to use 
gmirror and the like.


Also i find it a little strange that the default mode, GPT in this case 
is in some sort not compatible with the other default  geom structure.
For a newcomer or for people who use gmirror and glabel on a regular 
basis because there somewhat default, it could strike them if they start 
using the default GPT.


It is not logical.
Two default ways to do things that are in a way not compatible.

So a warning at the installer level could make a lot of users aware of 
this, and they can decide what to do, use GPT or go back to the old MBR.
They can start looking at the mailling list and so on to make the right 
decision is GPT acceptable for me or not.
And not install FreeBSD and find out later that you could not use your 
old gmirror and glabel tactics without corrupting the GPT structure.


Just my thoughts about this.

regards,
Johan Hendriks



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

Re: 9.x installer and GPT vs geom

[Johan Hendriks]

Nathan Whitehorn schreef:

On 10/13/11 04:25, O. Hartmann wrote:

On 10/13/11 10:39, Johan Hendriks wrote:

Hello all.

I just used the 9.0 B3 installer, and it defaults to GPT, which is 
nice.

However, and there has been some discussions about it, it would be nice
if the installer warns me that i could get in trouble if i want to use
gmirror and the like.

Also i find it a little strange that the default mode, GPT in this case
is in some sort not compatible with the other default geom structure.
For a newcomer or for people who use gmirror and glabel on a regular
basis because there somewhat default, it could strike them if they 
start

using the default GPT.

It is not logical.
Two default ways to do things that are in a way not compatible.

So a warning at the installer level could make a lot of users aware of
this, and they can decide what to do, use GPT or go back to the old 
MBR.

They can start looking at the mailling list and so on to make the right
decision is GPT acceptable for me or not.
And not install FreeBSD and find out later that you could not use your
old gmirror and glabel tactics without corrupting the GPT structure.

Just my thoughts about this.

regards,
Johan Hendriks

Shouldn't be there also a warning that GPT can not be used with the 
FreeBSD native bootselector? I had trouble installing FreeBSD 
9.0-CURRENT a while ago with default being GPT on my notebook and 
also wanting a Windows 7/x64 for presentations, selectable via the 
FreeBSD bootselector. This was possible with MBR, but it seems gone 
with GPT.


If you install onto an already MBR-formatted disk (say, you're 
dual-booting), it will use MBR as the default, not GPT. It only uses 
GPT as the default if you (a) put in a totally blank disk or (b) say 
you want to dedicate the disk entirely to FreeBSD.

-Nathan


And that is what most people do, use an entire new disk, and use that 
whole disk for FreeBSD.

Me included, if i install a new server that is the way i do it.
I think most people do it that way. If they must install a new server i 
think the most  users will use the defaults the installer gives them.
And because there are a lot of people who use gmirror to mirror the 
whole disk, they get bitten by the GPT vs geom metadata issue.
If however the installer warns people, they know things have changed, so 
they can investigate, and then they will hopefully find the threads 
regarding GPT, gmirror and glabel, and the problems that could arise.

There is a lot on the internet about it already.
Forums.freebsd.org included.

So a warning (or pointer) is at place as far as i am concerned.

regards
Johan Hendriks



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

RE: CARP on 9.0 (was no subject)

[Johan Hendriks]

How about:

%sudo netstat -s carp

...on both machines.

A few years ago I submitted (or maybe it was Steve Polyack) a patch to add
debugging to CARP, not sure if it ever got commited.

Need-more-Cisco'sih-Debugging.

~BAS


On Fri, 26 Aug 2011, Patrick Lamaiziere wrote:

 Le Fri, 26 Aug 2011 15:26:28 +,
 Johan Hendriks jo...@double-l.nl a ?crit :

 I am trying to set up CARP under 9.0

 ...

 Also with a higer value like advskew 200 or 254 the role of the
 servers stays the same.

 Ok, there is something wrong so.

 Did you check that the sysctl net.inet.carp.suppress_preempt is equal
 to zero ? If yes, I don't have any more idea.

 Regards.

Hello 
first off all thanks for your time.

sysctl -a | grep carp on both machines give me the following output

sysctl -a | grep carp
device  carp
net.inet.ip.same_prefix_carp_only: 0
net.inet.carp.allow: 1
net.inet.carp.preempt: 0
net.inet.carp.log: 2
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0


netstat -s on the master

carp:
260 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
11430 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

netstat -s on the slave

carp:
11735 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
448 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

tcpdump -i bge0 on slave

20:10:48.868200 IP 192.168.50.40  vrrp.mcast.net: VRRPv2, Advertisement, vrid 
1, prio 50, authtype none, intvl 1s, length 36

Here the advskew is set to 50, on the slave it is 20.
So the slave should be the master.
if i raise the advskew to 254, i see the change in the capture.

Both machines are fresh install with nothing changed on them so far just a 
fresh build from a csup this morning.
And installed bash as the shell..

for freebsd-current@ the /etc/rc.conf file again
Master 
ifconfig_bge0=inet 192.168.50.40 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 
255.255.255.0

On the slave i have the following in /etc/rc.conf
ifconfig_bge0=inet 192.168.50.41 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 
255.255.255.0

regards,
Johan



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

RE: CARP on 9.0 (was no subject)

[Johan Hendriks]

SOLVED!

Was a typo in /etc/sysctl.conf
Sorry for the noise

and thanks for your time.

regards
Johan

Van: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] 
namens Johan Hendriks [jo...@double-l.nl]
Verzonden: vrijdag 26 augustus 2011 20:22
Aan: Brian Seklecki (Mobile); freebsd-questi...@freebsd.org
CC: freebsd-current@freebsd.org
Onderwerp: RE: CARP on 9.0 (was no subject)

How about:

%sudo netstat -s carp

...on both machines.

A few years ago I submitted (or maybe it was Steve Polyack) a patch to add
debugging to CARP, not sure if it ever got commited.

Need-more-Cisco'sih-Debugging.

~BAS


On Fri, 26 Aug 2011, Patrick Lamaiziere wrote:

 Le Fri, 26 Aug 2011 15:26:28 +,
 Johan Hendriks jo...@double-l.nl a ?crit :

 I am trying to set up CARP under 9.0

 ...

 Also with a higer value like advskew 200 or 254 the role of the
 servers stays the same.

 Ok, there is something wrong so.

 Did you check that the sysctl net.inet.carp.suppress_preempt is equal
 to zero ? If yes, I don't have any more idea.

 Regards.

Hello
first off all thanks for your time.

sysctl -a | grep carp on both machines give me the following output

sysctl -a | grep carp
device  carp
net.inet.ip.same_prefix_carp_only: 0
net.inet.carp.allow: 1
net.inet.carp.preempt: 0
net.inet.carp.log: 2
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0


netstat -s on the master

carp:
260 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
11430 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

netstat -s on the slave

carp:
11735 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
448 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

tcpdump -i bge0 on slave

20:10:48.868200 IP 192.168.50.40  vrrp.mcast.net: VRRPv2, Advertisement, vrid 
1, prio 50, authtype none, intvl 1s, length 36

Here the advskew is set to 50, on the slave it is 20.
So the slave should be the master.
if i raise the advskew to 254, i see the change in the capture.

Both machines are fresh install with nothing changed on them so far just a 
fresh build from a csup this morning.
And installed bash as the shell..

for freebsd-current@ the /etc/rc.conf file again
Master
ifconfig_bge0=inet 192.168.50.40 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 
255.255.255.0

On the slave i have the following in /etc/rc.conf
ifconfig_bge0=inet 192.168.50.41 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 
255.255.255.0

regards,
Johan



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

RE: buildworld has been broken for me since Sunday 20110815 at atrun

[Johan Hendriks]

Is anyone else seeing this?  This is current AMD64.  I'm running the
compile from Saturday 20110814 that I have been hammering and it has
been rock solid.

# uname -a
FreeBSD home.encontacto.net 9.0-BETA1 FreeBSD 9.0-BETA1 #16: Sat Aug
13 05:09:17 CDT 2011
r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  amd64

This morning I started with a make clean to be sure and recompile all
just in case and the same.

snip

There was a time laps where the kernel had a little hickup.
See /usr/src/UPDATING.

To resolve this, csup or svn to the latest source, do a buildkernel and 
installkernel, reboot , and do the buildworld, it should be ok.
It worked for me and a lot of other guys, so it should work for you to. :D

regards,
Johan Hendriks___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Failed Buildworld 9.0 Beta 1

[Johan Hendriks]

Hello all.

I cvsuped yesterday, and did a buildworld, all was fine.
cvsuped today again, and now i can not do a buildworld, it errors out on atrun

It ends like this (written by hand)

===libexec (all)
===libexec/atrun (all)

cc -O2 -pipe ..
cc -O2 -pipe ..
cc -O2 -pipe ..
/usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylex`
/usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyin`
/usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyytext`
/usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyerror`
/usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylineno`

*** error code 1
Stop in /usr/src/libexec/atrun


my make.conf

CPUTYPE?=nocona
KERNCONF=KRNL

BATCH_DELETE_OLD_FILES= yes

CUPS_OVERWRITE_BASE=yes

# added by use.perl 2011-08-11 12:41:27
PERL_VERSION=5.10.1


my src.conf
WITHOUT_BLUETOOTH=  yes
WITHOUT_CALENDAR=   yes
WITHOUT_DICT=   yes
WITHOUT_GAMES=  yes
WITHOUT_HTML=   yes
WITHOUT_I4B=yes
WITHOUT_IPFILTER=   yes
WITHOUT_IPX=yes
WITHOUT_LPR=yes
WITHOUT_NIS=yes
WITHOUT_RCMDS=  yes
WITHOUT_RCS=yes
#WITHOUT_PROFILE=   yes
WITHOUT_SENDMAIL=   yes
WITHOUT_SHAREDOCS=  yes
WITHOUT_WIRELESS=  yes

and my KRNL conf file
include GENERIC
ident   KRNL

# hast support
options GEOM_GATE

# Carp support
device  carp


# pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
device  pf
device  pflog
device  pfsync

# Console color options
options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK)
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK)
options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)

# Console video mode
options VESA # Vesa Support for Splash
options SC_PIXEL_MODE # add support for the raster tex

# System console options
options SC_DISABLE_REBOOT   # disable reboot key sequence
options SC_HISTORY_SIZE=200 # number of history buffer lines


# Disable debugging in -current
nooptions   KDB # Enable kernel debugger support.
nooptions   DDB # Support DDB.
nooptions   GDB # Support remote GDB.
nooptions   INVARIANTS  # Enable calls of extra sanity checking
nooptions   INVARIANT_SUPPORT   # Extra sanity checks of internal 
structures, required by INVARIANTS
nooptions   WITNESS # Enable checks to detect deadlocks and 
cycles
nooptions   WITNESS_SKIPSPIN# Don't run witness on spinlocks for 
speed

regards
Johan Hendriks

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

MFC

[Johan Hendriks]

Hello all i have a question regarding MFC

At the svn page from head most revisions comments contain a line like
MFC after:x weeks or x days. or x months.
Is this done automaticly, or is this still done by the auther.

I came to this question, because of the following.
http://svnweb.freebsd.org/base?view=revisionrevision=217174

MFC after 3 weeks, but it looks likei t still has not been MFC'd
That is 4 months ago

And if so are there more patches that goes not into STABLE?

Regards,
Johan Hendriks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

shutdown -p now reboots server instead off power down

[Johan Hendriks]

Hello all.

 

I have a proliant ML110 server, with the latest FreeBSD 9.0 current.
(cvsuped today)
When i do a shutdown - p now on the system, it reboots instead of the
power down it used to do.

regards

Johan Hendriks

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

RE: shutdown -p now reboots server instead off power down

[Johan Hendriks]

 Hello all.
 
  I have a proliant ML110 server, with the latest FreeBSD 9.0 current.
 (cvsuped today)
 When i do a shutdown - p now on the system, it reboots instead of the
 power down it used to do.

Which version was the last that successfully powered down?

Gavin

I really can not tell.
I installed it from cd and then do a buildworld around every 2 days.
I always reboot (shutdown -r) but last time we had some maintenance to
do at the power net.
So i needed to shutdown the server.
Then i discovered that a -p did not powerdown the server anymore.

regrads,
JOhan  

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