Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Eugene Grosbein]

08.05.2021 2:52, Konstantin Belousov wrote:

> i386 kernel uses memory up to 24G since 13.0.
> 
> PAE only means that devices that can access full 64bit address are allowed
> to avoid dma bouncing.

Maybe you could tell something on similar topic?

There is FreeBSD 12.2-STABLE r369567 Base12 amd64 running
with Intel Atom CPU capable of long mode and addressing 8GB RAM,
ASRock A330ION motherboard and two memory modules installed: 4G+2GB.
Why so small "avail memory"?

FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-10.0.1-0-gef32c611aa2)
CPU: Intel(R) Atom(TM) CPU  330   @ 1.60GHz (1600.03-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x106c2  Family=0x6  Model=0x1c  Stepping=2
  
Features=0xbfe9fbff
  Features2=0x40e31d
  AMD Features=0x2800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 6442450944 (6144 MB)
Physical memory chunk(s):
0x0001 - 0x0009dfff, 581632 bytes (142 pages)
0x00103000 - 0x001f, 1036288 bytes (253 pages)
0x02b0 - 0xd8709fff, 3586170880 bytes (875530 pages)
avail memory = 3571384320 (3405 MB)

Also http://www.grosbein.net/freebsd/dmidecode.txt

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

Re: How to make 'named' rc script invokded earlier at boot time

[Eugene Grosbein]

30.04.2021 14:30, Yasuhiro Kimura wrote:
> I installed dns/bind916 on my home server and configured it so it
> worked as both authoritative and recursor. Then I added
> 'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.
> 
> But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed
> execution of some rc scripts fails at boot time because of DNS lookup
> error. And I also found these scripts are executed earlier than
> 'named'.
> 
> Now let me use 'ntpdate' as an example.

named sometimes *requires* correct time to be set before it is started,
so you should either use some IP addressess for NTP bootstrapping at boot time,
or put NTP server hostname to /etc/hosts with its IP, so it resolves before 
named fires.


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

Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?

[Eugene Grosbein]

07.04.2021 12:49, Scott Bennett via freebsd-stable wrote:

>  At least w.r.t. gvinum's raid5, I can attest that the kernel panics
> are real.  Before settling on ZFS raidz2 for my largest storage pool, I
> experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from
> sysutils/graid5).  All worked reasonably well, except for one operation,
> namely, "stop".  Most/all such devices cannot actually be stopped because
> a stopped device does not *stay* stopped.  As soon as the GEOM device
> node is destroyed, all disks are retasted, their labels, if any, are
> recognized, and their corresponding device nodes are recreated and placed
> back on line. :-(  All of this happens too quickly for even a series of
> commands entered on one line to be able to unload the kernel module for
> the device node type in question, so there is no practical way to stop
> such a device once it has been started.

In fact, you can disable re-tasting with sysctl kern.geom.notaste=1,
stop an GEOM, clear its lables and re-enable tasting setting 
kern.geom.notaste=0 back.

>  A special note is needed here regarding gcache(8) and graid3(8).  The
> documentation of gcache parameters for sector size for physical devices
> and gcache logical devices is very unclear, such that a user must have the
> device nodes and space on them available to create test cases and do so,
> whereas a properly documented gcache(8) would obviate the need to set up
> such experiments.  There is similar lack of clarity in various size
> specifications for blocks, sectors, records, etc. in many of the man pages
> for native GEOM commands.

I found gcache(8) very nice at first, it really boosts UFS performance provided
you have extra RAM to dedicate to its cache. gcache can be stacked with gmirror 
etc.
but I found it guilty to some obscure UFS-related panics. It seems there were 
races or something.
No data loss, though as it is intended to be transparent for writing.

I was forced to stop using gcache for sake of stability and it's a shame.
For example, dump(8) speed-up due to gcache was 2x at least with big cache
comparing to dump -C32 without gcache.

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

Re: Deprecating base system ftpd?

[Eugene Grosbein]

06.04.2021 15:37, aventa...@fastmail.fm wrote:

> Deprecating base system ftpd does seem to be a good idea, especially for 
> FreeBSD users wanting to use their computer
> as a workstation/desktop instead of as a server. I think the argument 
> becomes, "who is our target audience?"
> If the target audience is both server and desktop users, then minimizing the 
> base system makes a lot of sense.

Stock ftpd is single file /usr/libexec/ftpd sized 112KBytes uncompressed (71KB 
compressed with ZFS lz4 online compression)
and this is less than MAXPHYS=128K in current FreeBSD releases.
Minimizing the base system makes it another kind of Linux instead of solid 
operating system we love.


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

Re: Deprecating base system ftpd?

[Eugene Grosbein]

05.04.2021 19:57, Alan Somers write:

> I wouldn't say that anything is "very good" when it has no test suite 
> whatsoever.

Many years of employment of ftpd in different environments (sometimes under 
heavy load) means something, too.
Maybe even more than synthetic tests.

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

Re: Deprecating base system ftpd?

[Eugene Grosbein]

06.04.2021 1:27, Roger Leigh wrote:

>>> I propose deprecating the ftpd currently included in the base system
>>> before FreeBSD 14, and opened review D26447
>>> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
>>> I had originally planned to try to do this before 13.0, but it dropped
>>> off my list. FTP is not nearly as relevant now as it once was, and it
>>> had a security vulnerability that secteam had to address.
>>>
>>> I'm happy to make a port for it if anyone needs it. Comments?
>>
>> I'm strongly against remove of stock ftpd. FTP is fastest protocol for both 
>> testing
>> and daily file transfer for trusted isolated segments, and even for WAN 
>> wrapped in IPSec.
>>
>> Our stock ftpd has very short backlog of security issues comparing with 
>> other FTP server implementations,
>> mostly linked with libc or other libraries and not with ftpd code itself.
>>
>> Please don't fix what ain't broken. Please.
> 
> How would you draw the line between something that must be part of the base 
> system vs. something
> that would be better off as part of the ports tree?  What bar should ftpd 
> have to meet to warrant remaining in base vs moving to ports?

POLA at least.

> Personally, I’ve never enabled it nor had any desire to.  FTP is, at this 
> point in time, thoroughly obsolescent,

Because someone told us so? 

> and I cannot imagine that it is something that most people enable, if they 
> are even aware of its existence.
> Why can’t it simply be installed from the ports for the occasional user who 
> still requires it?

This is one of services that should be available even if distfiles/packages are 
not reachable.
You know, sshd used to be in ports too.

> Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or “scp”)?

sftp is not compatible with FTP clients and FTP is faster, basically it is 
plain TCP socket for data transfer.

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

Re: Deprecating base system ftpd?

[Eugene Grosbein]

On 05.04.2021 06:25, Dave Cottlehuber wrote:

> Eugene mentioned the convenience of ftpd in the same sentence as ipsec.
> I'm willing to bet those systems have ports installed too.

Ports/packages are great but they are not replacement for solid operating system
with bundled software tested and proven with time.

> If speed is an issue, HTTP supports pipelining, compression, chunked
> encoding, & parallel connections. I'm not sure ftpd is even in the same
> game anymore.

Compression and various encodings of raw data are not good for speed.
sendfile(2) system call used by ftpd to send raw data is good for speed.
Unlimited CPU power should not be assumed.

> The more code we hang onto in base, the larger the millstone around our
> necks when moving forwards. Each individual opportunity to slim down
> base *in itself* is not significant, but cumulatively they represent
> gridlock.
> 
> For each removal or deprecation, please consider, is this worth holding
> the project back for?

Our ftpd code does not hold the project back in any way. It's here, it works, 
it's very good.

High quality bundled software is what we love FreeBSD for.
Unfortunately, ports tend to rot more quick due to some known reasons.


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

Re: Fwd: Dell XPS 8940 SATA and NVMe disk controller not recognized

[Eugene Grosbein]

04.04.2021 5:09, Karl Dunn wrote:

>> See if the BIOS offers a choice of configuring the controller as SATA 
>> instead of RAID. That worked for me on an Inspiron 1180. (It also made W10 
>> unbootable - apparently each OS occupies its own universe.)
> 
> That worked, precisely as it did for you: gpart list shows partitions and 
> drives much to my expectations, and Win10 no longer boots.  I can boot 
> windows by setting the BIOS config back to RAID.  That's not much of a pain.  
> Now to try installing 12.2-RELEASE on the SSD!
> 
> Thank you very much indeed!

When such host-based RAID/AHCI system came in times of Windows XP, there was a 
way to make it boot Windows
with both kinds of BIOS settings. Boot to Windows in a way it normally boots - 
RAID in your case -
and forcibly add a driver corresponding to PCI ids of the controller in ACHI 
mode,
so Windows kernel already has it at boot time.

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

Re: Deprecating base system ftpd?

[Eugene Grosbein]

04.04.2021 3:39, Ed Maste wrote:

> I propose deprecating the ftpd currently included in the base system
> before FreeBSD 14, and opened review D26447
> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
> I had originally planned to try to do this before 13.0, but it dropped
> off my list. FTP is not nearly as relevant now as it once was, and it
> had a security vulnerability that secteam had to address.
> 
> I'm happy to make a port for it if anyone needs it. Comments?

I'm strongly against remove of stock ftpd. FTP is fastest protocol for both 
testing
and daily file transfer for trusted isolated segments, and even for WAN wrapped 
in IPSec.

Our stock ftpd has very short backlog of security issues comparing with other 
FTP server implementations,
mostly linked with libc or other libraries and not with ftpd code itself.

Please don't fix what ain't broken. Please.

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

Re: est and turbo boost

[Eugene Grosbein]

17.02.2021 10:40, Jack L. wrote:

> I've noticed for Dells, you have to set the performance setting to
> "Custom" and OS Control to be able to change the EST.

I've already tried numerous variants of BIOS setting including "Maximum 
Performance"
and "Custom" and still, ACPI BIOS does not export _PSS table required for 
est(4).


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

est and turbo boost

[Eugene Grosbein]

Hi!

We use leased server Dell PowerEdge R640 with latest firmware (BIOS/UEFI)
that does not export ACPI _PSS table, so FreeBSD 12.2-RELEASE/amd64 (GENERIC)
est(4) driver does not attach:

est0:  numa-domain 0 on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 1bc41c00
device_attach: est0 attach returned 6

Hence, no CPU frequency control and no TurboBoost for the CPU:

CPU: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz (2294.68-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x50657  Family=0x6  Model=0x55  Stepping=7
  
Features=0xbfebfbff
  AMD Features2=0x121
  Structured Extended 
Features=0xd39b
  Structured Extended 
Features3=0xbc000400
  XSAVE Features=0xf
  IA32_ARCH_CAPS=0xab
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
  TSC: P-state invariant, performance statistics
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
FreeBSD/SMP: 2 package(s) x 16 core(s)

Logical processors (hyperthreading) disabled in server's SETUP.

I've tried to use loader prompt to set hw.est.msr_info=1
but then is panices early at boot time with "integer divide fault".
No crashdump generated but a screenshot is available:

http://www.grosbein.net/freebsd/est-panic.jpg

What are options to enable est/TurboBoost in this case?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: DHCP and chnaging the MAC address on a network card

[Eugene Grosbein]

11.02.2021 6:26, Pete French wrote:

> I have a machine runnign 12-STABLE, which gets its upstream IP address from 
> my ISP using DHCP over a cable modem. What I just tried to do was to set the 
> MAC address on that interface at boot time, but if I do that then it no 
> longer acquires a DHCP address from the upstream.
> 
> Is there something going on here I dont understand ?
> 
> The interfaces are 'bge' and I have a file called /etc/start_if.bge0 whcih 
> contains:
> 
> /sbin/ifconfig $1 ether d0:bf:9c:46:a3:7c
> 
> and this works (have tried it on bge1 and another machine) in changing the 
> MAC address. But if i do that on the DHCP interface then it doesnt get an IP 
> address.
> 
> Any hints ?
> 
> -pete.
> 
> PS: reason  am doing this is my ISP will (in future) be able to give me a 
> static IP address basd on the MAC address. Which is lovely, but I have a 
> spare server I use when this one goes down, so was hoping to have the same 
> MAC address if I boot the same drive, to avoid any issues caused by the MAc 
> address chnaging if I chnage the hardware. But it doesnt work. :)

Try changing your command a bit:

/sbin/ifconfig $1 ether d0:bf:9c:46:a3:7c up

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

Re: time gives a strange result

[Eugene Grosbein]

14.01.2021 8:16, Erich Dollansky wrote:

> Hi,
> 
> all my make commands run as time make ...
> 
> I just got this result compiling scribus:
> 
> 5m19.94s real   1h15m31.76s user5m20.87s sys
> 
> I do not know how long it really took but 1h seems far to high. It
> really could be 15min.
> 
> NTPD is running. I did not notice any large time adjustments.

If you use 16 cores or more, numbers look fine: ~ 5min 20 sec "real" (wall 
clock) time
spent to utilize nearly all power of CPU cores summarized to user+sys times.

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

Re: Cannot find announcement that min supported i386 CPU is now i686

[Eugene Grosbein]

15.09.2020 9:42, Eugene Grosbein wrote:

>> I tried that on my workstation (dual Xeon, lots of RAM) but couldn't get
>> it to compile for i586 - various things kept bailing out.

Note that I use multiple WITHOUT_XXX knobs documented in src.conf(5) to 
decrease both
build time and size of resulting image, maybe some excluded code really has 
problems for i386, can't tell.
For CONF_BUILD (addition to src.conf for buildworld):

WITHOUT_KERNEL_SYMBOLS=
WITHOUT_DEBUG_FILES=
WITHOUT_TESTS=
MODULES_WITH_WORLD=
WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_APM=
WITHOUT_ASSERT_DEBUG=
WITHOUT_ATM=
WITHOUT_AUDIT=
WITHOUT_AUTHPH=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
WITHOUT_BSDINSTALL=
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
WITHOUT_CCD=
#WITHOUT_CDDL=
WITHOUT_CLANG_FULL=
WITHOUT_CPP=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
WITHOUT_DICT=
WITHOUT_EXAMPLES=
WITHOUT_FLOPPY=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GDB=
WITHOUT_GROFF=
WITHOUT_HAST=
WITGOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPX=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_LLDB=
WITHOUT_LLVM_TARGET_ALL=
WITH_LLVM_TARGET_X86=
WITHOUT_LOCATE=
WITHOUT_LS_COLORS=
WITHOUT_MAN=
WITH_MAN_UTILS=
WITHOUT_NCP=
WITHOUT_NDIS=
WITHOUT_NETCAT=
WITHOUT_NIS=
WITHOUT_NLS=
WITHOUT_NLS_CATALOGS=
WITHOUT_NS_CACHING=
WITH_OPENSSH_NONE_CIPHER=
WITHOUT_PC_SYSINSTALL=
WITHOUT_PF=
WITHOUT_PKGTOOLS=
WITHOUT_PMC=
WITHOUT_PORTSNAP=
WITHOUT_PPP=
WITHOUT_PROFILE=
WITHOUT_QUOTAS=
WITHOUT_RBOOTD=
WITHOUT_RCS=
WITHOUT_RESCUE=
WITHOUT_ROUTED=
WITHOUT_SHAREDOCS=
WITHOUT_SVNLITE=
WITHOUT_TALK=
WITHOUT_SYSINSTALL=
WITHOUT_TESTS=
WITHOUT_TEXTPROC=
WITHOUT_TIMED=
WITHOUT_VT=
MODULES_OVERRIDE=cryptodev zfs opensolaris

And:

CONF_INSTALL="
$CONF_BUILD
WITHOUT_BINUTILS=
WITHOUT_CLANG=
WITHOUT_CLANG_FULL=
WITHOUT_CXX=
WITHOUT_TOOLCHAIN=
WITHOUT_INSTALLLIB=
"

>> It would compile i386 for i686, but not i586. Have you tried it with 11.4?

Not sure what you meant here. ARCH may be i386 (32 bit) or amd64 (64 bit),
however i586 is not a name for ARCH but for CPUTYPE only (not same thing).

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

Re: Cannot find announcement that min supported i386 CPU is now i686

[Eugene Grosbein]

14.09.2020 12:08, Charles Lecklider via freebsd-stable wrote:

> On 2020-09-14 04:41, Eugene Grosbein wrote:
>> Build time for modern FreeBSD version is too gross and needs way too much 
>> memory,
>> so I stopped building image for my i586 hardware "in place" quite long ago.
> 
> It would take about a week to compile, but since it was stable <11.4 I
> didn't really care.
> 
>> I use my i7-based desktop to build NanoBSD image for its upgrade, it works 
>> just fine
>> by default setting ARCH/TARGET_ARCH to i386 and correct CPUTYPE.
> 
> I tried that on my workstation (dual Xeon, lots of RAM) but couldn't get
> it to compile for i586 - various things kept bailing out. It would
> compile i386 for i686, but not i586. Have you tried it with 11.4?

Just updated that my i586 AMD Geode system upto latest 11.4-STABLE,
all went OK. I build it with standard nanobsd(8) utility in base system,
my build configuration contains:

NANO_PMAKE="make -j3"
NANO_KERNEL=GWOLD
CONF_BUILD='
TARGET=i386
TARGET_ARCH=i386
NANO_ARCH=i386
CPUTYPE?=k6-3
...
'

And kernel configuration has:
machine i386
cpu I586_CPU
cpu I686_CPU
options CPU_GEODE
options CPU_SOEKRIS
options SCHED_4BSD
...

For UP system, I find SCHED_4BSD behave better than default SCHED_ULE.

>>> Don't try -Os or -Oz (which really do help on a real i586) - ZFS will
>>> wedge quickly.
>>
>> Currently i586-class CPU needs as many speed improvements as possible
>> and I was told that -Os might drop performance comparing with -O2,
>> so why bother?
> 
> It depends on your workload. This machine spends most of its life
> running rsync over ssh, so having more useful code in L2 cache makes a
> difference even if it takes a few more clock cycles to run. The
> bottleneck is IO - mainly disc, but also network (way better with
> polling - don't know why it's not in GENERIC) so those extra clock
> cycles aren't as important.
> 
> If you're doing real number-crunching stuff with it, a) why?!,

Isn't ssh encryption/decryption "real" number-crunching?
My i586 system did IPSec encryption for tunnels and despite of having 
AES-CBC-128
onboard hardware accelerator suitable for IPSec, it was quite limited by CPU 
horsepower,
so I used hmac-md5 instead of SHA variants to speed-up things a bit and still,
it was able to saturate 100Mbps with unencrypted PPPoE+ipfw nat but only 33Mbps 
with IPSec AES+MD5
and less with SHA.

> and b) yes, -O2 would be better.
> 
>>> 11.4 i386 doesn't honour `vfs.zfs.arc_max` in any meaningful way
>>> resulting in one of the `find`s in periodic security wedging ZFS.
>>
>> Been there, seen that. The problem pre-dates 11.x series and appeared in 
>> 10.x.
>> It was much better in times of 9.x, though.
> 
> Yes, I've also seen it before, but 11.4 is particularly egregious with
> its disregard on i386 - amd64 is behaving itself on everything I've tried.
> 
>>> options KSTACK_PAGES=4
>>
>> This is default for 12.x/i386 but was not merged to stable/11.
> 
> That's good to know.
> 
>> You might find useful these also:
>>
>> vfs.zfs.vdev.cache.size="8M"
>> vfs.zfs.prefetch_disable="1"
> 
> Prefetch is disabled on i386 by default; I played with the vdev cache
> size too but it made no discernable difference.
> 
>> And for kernel config:
>>
>> options KVA_PAGES=512
>>
>> This makes ZFS more stable giving it bigger kernel virtual area with less 
>> utilization for it.
> 
> Yes, that's the theory, but when I tried it on earlier versions the
> kernel would just blow up on boot. I may try it again next time I update
> the kernel.

It worked for me with KVA_PAGES=768 even, so kernel and ZFS had 3GB for virtual 
area
and only 1GB for userland but that was i386 virtual machine with 512M or 1GB 
RAM only
(cheapest hoster provided some years ago), so 1GB for userland was just fine :-)

>>> TL;DR: I'd avoid 11.4 i386 as it doesn't appear to have been tested on
>>> i486/i586 at all.
>>
>> Finally I gave up running ZFS for vmem-contrained systems,
>> e.g. I moved my i386 virtual machines that benefit from ZFS compression to 
>> amd64.
> 
> Oh, sure - I'd never dream of doing anything fancy with ZFS on this
> machine - it just does backups.
> 
> My point was that 11.4 doesn't "feel" right - it doesn't seem to have
> been tested on  of FreeBSD since 2.x - some "feel" right, some "feel" dodgy (5.3, 6.x,
> some 8.x IIRC). On amd64 it "feels" great, but I don't really trust it
> on i386.

Can't see any difference with early 11.x versions but I build it all by myself
for many major releases.


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

Re: Cannot find announcement that min supported i386 CPU is now i686

[Eugene Grosbein]

14.09.2020 4:30, Charles Lecklider via freebsd-stable wrote:

> On 2020-09-01 03:20, Eugene Grosbein wrote:
>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU)
>>   Origin="AuthenticAMD"  Id=0x5a2  Family=0x5  Model=0xa  Stepping=2
>>   Features=0x88a93d
>>   AMD Features=0xc040
>>
>> Of course, its NanoBSD image is built with CPUTYPE=i586 as well as installed 
>> packages.
> 
> You've got CMOV so you'll be fine with 11.4-RELEASE, whereas I don't:
> 
> CPU: Pentium/P55C (232.68-MHz 586-class CPU)
>   Origin="GenuineIntel"  Id=0x543  Family=0x5  Model=0x4  Stepping=3
>   Features=0x8003bf
> 
> Getting 11.4 to work has been a *major* undertaking:
> 
> Setting CPUTYPE in `make.conf` doesn't set -march for the kernel build
> tools, so while you can compile world and kernel for i386, you can't
> actually link it to create a working kernel on a real i586 (I found that
> out with `/usr/obj` and `/usr/src` mounted over NFS).

Build time for modern FreeBSD version is too gross and needs way too much 
memory,
so I stopped building image for my i586 hardware "in place" quite long ago.
I use my i7-based desktop to build NanoBSD image for its upgrade, it works just 
fine
by default setting ARCH/TARGET_ARCH to i386 and correct CPUTYPE.

> Don't try -Os or -Oz (which really do help on a real i586) - ZFS will
> wedge quickly.

Currently i586-class CPU needs as many speed improvements as possible
and I was told that -Os might drop performance comparing with -O2,
so why bother?

> 11.4 i386 doesn't honour `vfs.zfs.arc_max` in any meaningful way
> resulting in one of the `find`s in periodic security wedging ZFS.

Been there, seen that. The problem pre-dates 11.x series and appeared in 10.x.
It was much better in times of 9.x, though.

> By ZFS wedging I mean something gets stuck on zio->i having eaten all of
> kmem (I presume - on the real i586 I expect ~200M in ARC would do that
> and that's what `top` shows) and that's it for the machine - it doesn't
> panic, but there's no more disk IO either.
> This also happens in VirtualBox with 4GB RAM, so it's not a hardware
> problem.
> 
> To get 11.4 to behave itself (and it's only been 72 hours so still early
> days) I've had to set:
> 
> options   KSTACK_PAGES=4

This is default for 12.x/i386 but was not merged to stable/11.

> and
> 
> kern.maxvnode="1024"
> vm.kmem_size="330M"
> vm.kmem_size_max="330M"
> vfs.zfs.arc_max="125M"
> vfs.zfs.arc_meta_limit="16M"
> 
> I had to set kmem for 11.3 but not the rest.

You might find useful these also:

vfs.zfs.vdev.cache.size="8M"
vfs.zfs.prefetch_disable="1"

And for kernel config:

options KVA_PAGES=512

This makes ZFS more stable giving it bigger kernel virtual area with less 
utilization for it.

> TL;DR: I'd avoid 11.4 i386 as it doesn't appear to have been tested on
> i486/i586 at all.

Finally I gave up running ZFS for vmem-contrained systems,
e.g. I moved my i386 virtual machines that benefit from ZFS compression to 
amd64.

As for real i586-class hardware uncapable of Long Mode,
I do not use ZFS at all, UFS2/async+gjournal works just fine there including 
WiFi, IPSec etc. but no ZFS.


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

Re: spa_namespace_lock and concurrent zfs commands

[Eugene Grosbein]

09.09.2020 19:29, Eugene M. Zheganin wrote:

> I'm using sort of FreeBSD ZFS appliance with custom API, and I'm suffering 
> from huge timeouts when large (dozens, actually) of concurrent zfs/zpool 
> commands are issued (get/create/destroy/snapshot/clone mostly).
> 
> Are there any tunables that could help mitigate this ?
> 
> Once I took part in reporting the 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203906 , but the issue that 
> time got resolved somehow. Now I have another set of FreeBSD SANs and it;'s 
> back. I've read the https://wiki.freebsd.org/AndriyGapon/AvgZFSLocking and I 
> realize this probably doesn't have a quick solution, but still...

I think this is some kind of bug/misfeature.
As work-around, try using "zfs destroy -d" instead of plain "zfs destroy".

I suffered from this, too when used ZFS pool over SSD only
instead of HDD+SSD for L2ARC and used SSD sucked really hard
processing BIO_DELETE (trim) with looong delays.

Take a look at "gstat -adI3s" output to monitor amount of delete operations and 
their timings.

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

Re: assfail

[Eugene Grosbein]

01.09.2020 15:23, Andy Farkas wrote:

> Just still wondering what 'assfail' could be.

Short for "assertion fail". Blame ZFS developers.



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

Re: assfail

[Eugene Grosbein]

01.09.2020 8:35, Andy Farkas wrote:

> My normally very reliable PC now panics in 'assfail+0x1d'
> Any idea why (or what!) this is?
> Imge of panic screen: https://imgur.com/1vRpkgW

You should describe your system: OS version and disk/file system setup,
because the screenshot shows ZFS-related assertion failure after GELI 
initialization,
so your setup seems to be non-trivial.

Perhaps, your system experienced unclean reboot before this problem?
Maybe you'll need to use "zpool import -F" or even
"zpool import -F -X" for "extreem rewind" (-X is not documented).

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

Re: Cannot find announcement that min supported i386 CPU is now i686

[Eugene Grosbein]

01.09.2020 6:50, Charles Lecklider via freebsd-stable wrote:

> On 2020-08-31 21:51, Christoph Moench-Tegeder wrote:
>> Given that the hardware notes
>> https://www.freebsd.org/releases/11.4R/hardware.html#proc-i386
>> explicitely claim 80486 compatibility, I'd guess this was not a
>> consciuous decision but a blunder which wasn't caught
> 
> Hmm I'd assumed that each release was at least *booted* on a real
> 486, but obviously not.
> 
>> (perhaps as
>> hardware of that vintage is getting rare these days. That box
>> must be old enough to buy alcohol by now?).
> 
> Yes, I first built it in 1998 IIRC; it ran Windows for a few years
> (desktop, gaming) then FreeBSD from about 2002. It's been in nearly
> continuous operation since, although I did have to replace the PSU last
> year ;-)

Just for the record, I still run AMD Geode-based FreeBSD 11.3-STABLE as my home 
WiFi Access Point.
This fanless system has 500Mhz 32-bit only i586-class CPU, 1GB RAM (no swap),
two 100M wired NICs vr0/vr1 onboard and Atheros 5212 ath0 wireless mini-PCI 
card (not PCI-E)
that supports multiple WLANs.

It has CompactFlash slot for ada0 occupied with 16GB CF card at boot device 
(nanobsd, r/o mounted)
plus ada1 2.5" PATA HDD WDC WD2500BEVE (250G) as additional storage.

Until recently is also served as PPPoE client (mpd5 kernel level) for uplink
with ipfw nat being able to saturate 100MBit/s uplink connection despite of 
NAT+PPPoE overhead.

CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU)
  Origin="AuthenticAMD"  Id=0x5a2  Family=0x5  Model=0xa  Stepping=2
  Features=0x88a93d
  AMD Features=0xc040

Of course, its NanoBSD image is built with CPUTYPE=i586 as well as installed 
packages.

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

Re: Cannot find announcement that min supported i386 CPU is now i686

[Eugene Grosbein]

01.09.2020 1:00, Charles Lecklider via freebsd-stable wrote:

> Having just trashed my dual Pentium 233 MMX by installing 11.4 I went
> digging to find the cause - and I found it.
> 
> As you can see from objdump below, clearly a decision was made that 11.4
> would no longer support anything before a i686.
> 
> Ignoring for a moment the wisdom of making breaking changes to a minor
> version, please could someone tell me where the announcement was made?

https://www.freebsd.org/releases/12.1R/relnotes.html section 11.1 discusses the 
topic
in context of upcoming FreeBSD 13.

There was some discussion on the topic in the freebsd-arch mailing list about a 
year ago:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=75083+0+archive/2019/freebsd-arch/20191006.freebsd-arch

It seems there was no announcement on the change for 11.x branch.

I wonder how much RAM does your Pentium 233 MMX have and what part of the RAM 
is cacheable by the chipset? :-)

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

Re: The spkr driver

[Eugene Grosbein]

29.08.2020 1:59, Charles Sprickman wrote:

>> spkr works just fine in my stable/11 systems. I use it for routers on modern 
>> fanless hardware
>> to audio signalling like successfull completition of reboot (going to 
>> multi-user mode).
> 
> Is this what pfsense/opnsense uses for the “booting complete” signal as well?

Can't tell (never used pfsense/opnsense), but possible.
 
> If so, it’s very handy.

Yes, it is.

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

Re: The spkr driver

[Eugene Grosbein]

28.08.2020 23:25, Warner Losh wrote:

> I'd like to retire the spkr driver. It was a cute hack before sound cards
> were ubiquitous, but it's not been kept up to date, and it's not clear that
> it still works It is still Giant locked, and though it's not a huge
> effort to do the locking I literally have no way to test it that I trust...
> 
> Is anybody using it these days for anything? If not, I'd propose we
> de-orbit it before 13. If so, I need people to test patches to remove
> Giant...

spkr works just fine in my stable/11 systems. I use it for routers on modern 
fanless hardware
to audio signalling like successfull completition of reboot (going to 
multi-user mode).

I'd like to keep it working. I'm ready to test patches. However, my CURRENT 
system lives in bhyve for the moment.
Though, I could try running CURRENT with one of my less important wireless AP 
systems built as NanoBSD,
so I can build and boot CURRENT-based image.


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

Re: 11.4 sendmail with SASL and ports openssl?

[Eugene Grosbein]

14.08.2020 17:46, Bengt Ahlgren wrote:

> Then the question is whether I need openssl libraries from ports, when I
> use that for all ports with DEFAULT_VERSIONS+=ssl=openssl due to QT5
> requirements?
> 
> If I want to link with openssl from ports, it looks like I anyway need
> SENDMAIL_LDFLAGS=-L/usr/local/lib, otherwise the linker will pick up
> libssl and libcrypto from base.  Specifying the full path for these
> libraries, like for libsasl2 in the handbook, only results in
> double-linking with libraries from both ports and base.  So I ended up
> with:
> 
> SENDMAIL_CFLAGS=-I/usr/local/include -I/usr/local/include/sasl -DSASL
> SENDMAIL_LDFLAGS=-L/usr/local/lib
> SENDMAIL_LDADD=/usr/local/lib/libsasl2.so

Stock sendmail was recently updated from 8.14.x to 8.16.x in base after 
11.4-RELEASE.

Previous sendmail version was incompatible with openssl 1.1+,
so Handbook updated before 11.4-RELEASE to make sure sendmail is built and 
linked
with stock openssl, or else build failed.

It seems updated sendmail in stable branches made compatible with openssl 1.1+,
so the choice is yours.


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

Re: 11.4 sendmail with SASL and ports openssl?

[Eugene Grosbein]

11.08.2020 20:49, Bengt Ahlgren wrote:

> I have since long compiled sendmail in base with SASL using a src.conf
> like this:
> 
> # sendmail with SASL required for outgoing SMTP AUTH, see:
> # https://www.freebsd.org/doc/en/books/handbook/SMTP-Auth.html
> # depends on port security/cyrus-sasl2
> SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL
> SENDMAIL_LDFLAGS=-L/usr/local/lib
> SENDMAIL_LDADD=-lsasl2
> 
> Since I'm still using 11.4, I had to start using openssl from ports due
> to qt5 5.15.  Then the above didn't work anymore, so a bit reluctantly I
> added -I/usr/local/include to the CFLAGS above, fearing that some other
> random include file could be picked up.

The Handbook was updated. Take a look to the link you have in the comment above
for new settings.

> It however compiled and the
> resulting binary is linked thus:
> 
> # ldd /usr/obj/usr/src/usr.sbin/sendmail/sendmail
> /usr/obj/usr/src/usr.sbin/sendmail/sendmail:
> libsasl2.so.3 => /usr/local/lib/libsasl2.so.3 (0x8008db000)
> libutil.so.9 => /lib/libutil.so.9 (0x800af9000)
> libssl.so.11 => /usr/local/lib/libssl.so.11 (0x800d0d000)
> libcrypto.so.11 => /usr/local/lib/libcrypto.so.11 (0x80100)
> libwrap.so.6 => /usr/lib/libwrap.so.6 (0x8014cb000)
> libc.so.7 => /lib/libc.so.7 (0x8016d4000)
> libdl.so.1 => /usr/lib/libdl.so.1 (0x801a8b000)
> libthr.so.3 => /lib/libthr.so.3 (0x801c8c000)
> 
> Does this look right?  Are there any know issues with this?

If it's working for you, that's fine. If you like to minimize linking with 
ports libraries,
use updated instructions from the Handbook. Sendmail will build and link with 
base system
libssl/libcrypto and use only libsasl2 from ports/packages.


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

Re: Traffic "corruption" in 12-stable

[Eugene Grosbein]

27.07.2020 5:16, Joe Clarke wrote:

> About two weeks ago, I upgraded from the latest 11-stable to the latest 
> 12-stable.  After that, I periodically see the network throughput come to a 
> near standstill.  This FreeBSD machine is an ESXi VM with two interfaces.  It 
> acts as a router.  It uses vmxnet3 interfaces for both LAN and WAN.  It runs 
> ipfw with in-kernel NAT.  The LAN side uses a bridge with vmx0 and a tap0 L2 
> VPN interface.  My LAN side uses an MTU of 9000, and my vmx1 (WAN side) uses 
> the default 1500.
> 
> Besides seeing massive packet loss and huge latency (~ 200 ms for on-LAN ping 
> times), I know the problem has occurred because my lldpd reports:
> 
> Jul 26 15:47:03 namale lldpd[1126]: frame too short for tlv received on 
> bridge0
> 
> And if I turn on ipfw verbose messages, I see tons of:
> 
> Jul 26 16:02:23 namale kernel: ipfw: pullup failed
> 
> This leads to me to believe packets are being corrupted on ingress.  I’ve 
> applied all the recent iflib changes, but the problem persists. What causes 
> it, I don’t know.
> 
> The only thing that changed (and yes, it’s a big one) is I upgraded to 
> 12-stable.  Meaning, the rest of the network infra and topology has remained 
> the same.  This did not happen at all in 11-stable.
> 
> I’m open to suggestions.

First, try: ifconfig $ifname -rxcsum -txcsum

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

Re: zfs meta data slowness

[Eugene Grosbein]

22.07.2020 20:02, mike tancsa wrote:
> 
> On 7/22/2020 1:29 AM, Eugene Grosbein wrote:
>> 22.07.2020 2:37, mike tancsa wrote:
>>
>>>> Something else special about the setup.
>>>> output of "top -b"
>>>>
>>> ports are right now being built in a VM, but the problem (zrepl hanging)
>>> and zfs list -t snapshots taking forever happens regardless
>>>
>>>   PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
>>> COMMAND
>>>  4439 root 12  40   20  6167M  5762M kqread   3 535:13 200.00% bhyve
>>> 98783 root  2  21016M  5136K hdr->b   4   0:01   1.95% zfs
>>> 76489 root 21  230   738M54M uwait1   2:18   0.88% zrepl
>>> 98784 root  1  21013M  3832K piperd   3   0:01   0.59% zfs
>>> 99563 root  1  20013M  4136K zio->i   4   0:00   0.39% zfs
>> You need top -SHPI
> 
> last pid: 66981;  load averages:  3.44,  3.25,  3.34  up 1+22:49:34   
> 08:58:06
> 2056 threads:  12 running, 1988 sleeping, 3 zombie, 53 waiting
> CPU 0:  7.7% user,  0.1% nice, 15.0% system,  0.7% interrupt, 76.5% idle
> CPU 1:  9.9% user,  0.1% nice, 16.6% system,  0.1% interrupt, 73.2% idle
> CPU 2: 10.0% user,  0.1% nice, 17.5% system,  0.4% interrupt, 71.9% idle
> CPU 3: 10.3% user,  0.1% nice, 21.2% system,  0.1% interrupt, 68.2% idle
> CPU 4:  9.7% user,  0.1% nice, 15.6% system,  0.4% interrupt, 74.3% idle
> CPU 5: 10.2% user,  0.1% nice, 21.3% system,  0.1% interrupt, 68.3% idle
> CPU 6:  9.7% user,  0.1% nice, 16.6% system,  0.5% interrupt, 73.1% idle
> CPU 7: 10.1% user,  0.1% nice, 21.3% system,  0.1% interrupt, 68.4% idle
> Mem: 4236M Active, 19G Inact, 283M Laundry, 37G Wired, 3248K Buf, 1667M Free
> ARC: 25G Total, 9939M MFU, 12G MRU, 397M Anon, 573M Header, 2143M Other
>  20G Compressed, 29G Uncompressed, 1.43:1 Ratio
> Swap: 20G Total, 20G Free
> 
>   PID USERNAMEPRI NICE   SIZERES STATEC   TIMEWCPU COMMAND
>  4439 root123   20  6167M  5856M CPU2 2  20.2H 100.00%
> bhyve{vcpu 0}
>  4439 root122   20  6167M  5856M CPU3 3  20.2H  99.17%
> bhyve{vcpu 1}
>11 root155 ki31 0B   128K CPU0 0  35.9H  65.38%
> idle{idle: cpu0}
>11 root155 ki31 0B   128K CPU4 4  34.8H  63.38%
> idle{idle: cpu4}
> 66956 root 90061M54M CPU5 5   0:09  62.70% zfs
>11 root155 ki31 0B   128K CPU6 6  34.3H  58.06%
> idle{idle: cpu6}
>11 root155 ki31 0B   128K RUN  2  33.7H  54.49%
> idle{idle: cpu2}
>11 root155 ki31 0B   128K RUN  1  34.3H  53.76%
> idle{idle: cpu1}
>11 root155 ki31 0B   128K RUN  3  32.0H  53.47%
> idle{idle: cpu3}
>11 root155 ki31 0B   128K CPU7 7  32.0H  50.68%
> idle{idle: cpu7}
>11 root155 ki31 0B   128K RUN  5  32.0H  48.29%
> idle{idle: cpu5}
>56 root-12- 0B  5168K -1   5:49   9.67%
> zpool-zbackup2{zio_write_issue_3}
>56 root-12- 0B  5168K -3   5:48   9.57%
> zpool-zbackup2{zio_write_issue_5}
>56 root-12- 0B  5168K -4   5:48   9.47%
> zpool-zbackup2{zio_write_issue_4}
>56 root-12- 0B  5168K -7   5:48   9.47%
> zpool-zbackup2{zio_write_issue_2}
>56 root-12- 0B  5168K -0   5:49   9.38%
> zpool-zbackup2{zio_write_issue_1}
>56 root-12- 0B  5168K -1   5:48   9.38%
> zpool-zbackup2{zio_write_issue_0}
> 63392 root 230   729M32M uwait0   0:01   4.20%
> zrepl{zrepl}

It's hard to read due to wrapping plus, it is truncated.
Maybe additional flag -d3 or similar will help, combined with dedirection < 
/dev/null > top.out
so it won't use size of your terminal to wrap/truncate output.

Also, make sure you invoke top while "zfs" command is running.
Also, procstat -kk for pid of "zfs" command would be useful (but may occur 
pretty long).

I suppose it blocks waiting for some kernel lock and procstat would show 
details.

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

Re: zfs meta data slowness

[Eugene Grosbein]

22.07.2020 2:37, mike tancsa wrote:

>> Something else special about the setup.
>> output of "top -b"
>>
> 
> ports are right now being built in a VM, but the problem (zrepl hanging)
> and zfs list -t snapshots taking forever happens regardless
> 
>   PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
> COMMAND
>  4439 root 12  40   20  6167M  5762M kqread   3 535:13 200.00% bhyve
> 98783 root  2  21016M  5136K hdr->b   4   0:01   1.95% zfs
> 76489 root 21  230   738M54M uwait1   2:18   0.88% zrepl
> 98784 root  1  21013M  3832K piperd   3   0:01   0.59% zfs
> 99563 root  1  20013M  4136K zio->i   4   0:00   0.39% zfs

You need top -SHPI

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

Re: zfs meta data slowness

[Eugene Grosbein]

19.07.2020 21:17, mike tancsa wrote:
> Are there any tweaks that can be done to speed up or improve zfs
> metadata performance ? I have a backup server with a lot of snapshots
> (40,000)  and just doing a listing can take a great deal of time.  Best
> case scenario is about 24 seconds, worst case, I have seen it up to 15
> minutes.  (FreeBSD 12.1-STABLE r363078)

I believe you have to perform kernel profiling for your specific use case.

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

Re: swap space issues

[Eugene Grosbein]

26.06.2020 1:30, Donald Wilde wrote:

> Here's 'pstat -s' on the i3 (which registers as cpu HAMMER):
> 
> Device  1K-blocks UsedAvail Capacity
> /dev/ada0s1b 335544320 33554432 0%
> /dev/ada0s1d 335544320 33554432 0%
> Total671088640 67108864 0%

"pstat -s" may also be invoked as "swapinfo" or better "swapinfo -h".


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

Re: swap space issues

[Eugene Grosbein]

25.06.2020 18:42, Donald Wilde wrote:

> Thanks, Kevin! My laptop's BIOS is old enough that it balked when I
> tried to boot from a GPT setup of 12.1R. One Of These Days I'll fix
> that but the MBR works and I needed to move on.
> 
> We'll get there! :D

gpart is not for GPT, it is for "GEOM Partitioning".
gpart manages all kind of partitioning in FreeBSD,
including swap partitions.


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

Re: Problem with Sendmail Mailertable

[Eugene Grosbein]

22.06.2020 21:56, Andrea Brancatelli via freebsd-stable wrote:

> I have an old 10.3 machine with sendmail 8.15.2 that's been working ok
> for a long time. 
> 
> We have a simple mailterable rule that looks like: 
> 
> schema31.itdbmail-lmtpd[10.33.whatever] 
> 
> That we use to forward mail in LMTP from sendmail to another machine
> where dbmail is working. Everything works as supposed but today after
> years of service someone realized the syntax user+mail...@schema31.it
> doesn't work as expected. 
> 
> I did a bit of research and debugging and whatever and found out that
> when a "+" is involved in the mail address mailertable's lookups doesn't
> seem to work and the mail gets sent to local mailer. 
> 
> I tried even something fancy like 
> 
> .schema31.it dbmail-lmtpd[10.33.whatever] 
> 
> Or even the plain all catchall 
> 
> .   dbmail-lmtpd[10.33.whatever] 
> 
> But nothing works. 
> 
> Anybody ever stepped on this and got it working? 
> 
> Please, please, please, avoid the "drop sendmail and switch to
> " replies, if I could I would already done it ;-) 

This feature works for me but I use FEATURE(virtusertable) instead of 
mailertable
to pass mail to my custom mailer:

#virtusertable
# the following rule diverts mail to "plussed" (and only plussed) destination 
addresses to custom mailer
++@realdomain.net  %1...@realdomain.net.pseudodomain
#EOF

(mailer definition has CPpseudodomain for this to work).

Maybe it works for mailertable too, try it.

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

Re: Buildworld and buildkernel with very slow compilation, recently

[Eugene Grosbein]

22.06.2020 3:56, Dimitry Andric wrote:

> One of the upstream problems is that there is not really any
> authoritative performance regression log being built up, so it is hard
> to see where such regressions were introduced. Somebody then has to
> spend a lot of time tracking down each and every regression, and then
> attempt to untangle it from the dozens of commits made around the same
> time. :)

Such project as FreeBSD could become valuable source of information to track 
such an issue
and it's easy to obtain, for example:

make buildworld 2>&1 | logger -t buildworld -p user.info

This generates timestamps for every line called in process with help of syslogd.
It should be easy to compare outputs obtained with same FreeBSD revision
but different clang versions, calculate time diffs and sort by diffs descending 
:-)

Same for ports builds, maybe even quicker.


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

Re: stucked on reading bad cd-rom

[Eugene Grosbein]

15.06.2020 18:10, Miroslav Lachman wrote:

> I am running FreeBSD 11.3. Whenever I inserted some 20 year old CD (backups 
> on CD-R) which is currently unreadable the system is trying to read the CD 
> even after I want to eject it by button in the CD drive or "eject" command.
> 
> These messages are repeatedly logged in messages
> 
> Jun 15 13:05:28 illbsd kernel: (cd0:ahcich2:0:0:0): Error 6, Unretryable error
> Jun 15 13:05:28 illbsd kernel: (cd0:ahcich2:0:0:0): cddone: got error 0x6 back
> Jun 15 13:05:28 illbsd kernel: (cd0:ahcich2:0:0:0): READ(10). CDB: 28 00 00 
> 00 00 00 00 00 11 00
> Jun 15 13:05:28 illbsd kernel: (cd0:ahcich2:0:0:0): CAM status: SCSI Status 
> Error
> Jun 15 13:05:28 illbsd kernel: (cd0:ahcich2:0:0:0): SCSI status: Check 
> Condition
> Jun 15 13:05:28 illbsd kernel: (cd0:ahcich2:0:0:0): SCSI sense: NOT READY 
> asc:3a,2 (Medium not present - tray open)
> 
> It can take from 1 to 5 minutes from pressing eject to actually open the 
> drive.
> 
> Is there something I can do to not wait too long for this? Any tuneables or 
> command to interrupt endless reading?

Perhaps it's GEOM doing multiple "taste" attempts to detetmine logical format 
of the media.
Try setting "sysctl kern.geom.notaste=1" temporary.


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

Re: Virtual consoles stopped working

[Eugene Grosbein]

14.06.2020 12:21, Donald Wilde wrote:

> Since I am using this mule as a dev system for a server-based
> application, I have no WM or GUI activated. I really would like to
> have the virtual consoles back, and I will gladly learn from what I
> did to mess it up. :D

Can you boot it with distribution image of the Release to make sure
its virtual consoles work fine in same environment?

And/or try to interrupt boot at loader stage, break into loader prompt and do:

set kern.vty=sc
boot

To see if your kernel has same problem with syscons(1) console driver.


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

Re: incorrect installation

[Eugene Grosbein]

21.05.2020 8:23, Donald Wilde wrote:

> The installation -- whole disk, AUTO, GPT, all options selected --
> downloads everything and appears to match all checksums and complete
> successfully but when I reboot, it goes immediately into the PXE boot,
> failing with no DHCP success. I've tried both Legacy and UEFI BIOS
> mode and it refuses to recognize the hard drive and installation
> either way.

It seems your BIOS does not boot OS from GPT normally.
Try using MBR partitioning instead with Legacy mode.
And/or apply BIOS/UEFI firmware updates, if any.

You could also try 11.4-RC2 image as it contains come compatibility fixes for 
booting issues like yours.


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

Re: zfs receive -s: transfer got interrupted, but no token on the receiving side.

[Eugene Grosbein]

27.05.2020 22:11, Eugene M. Zheganin wrote:

> Hello,
> 
> 
> I have a ZFS dataset about 10T of actual size (may be more) that I need to 
> send over a very laggy connection. So I'm sending it from the shell-script 
> that reattempts to send it after a short timeout, retrieving the send token 
> first. Like that:
> 
> ===Cut===
> 
> #!/bin/sh
> 
> exitstatus=1
> token=`ssh user@server zfs get receive_resume_token data/reference | grep -v 
> SOURCE | awk '{print $3}'`
> while ([ $exitstatus -ne 0 ])
> do
> zfs send -t $token | ssh -C user@server sudo zfs receive -Fus 
> data/reference
> exitstatus=$?
> echo "Send interrupted/ended, sleeping for 5 secs."
> sleep 5
> done
> 
> ===Cut===
> 
> Usually this goes just flawlessly. But this time, due to a low transfer speed 
> and a very laggy connectivity, thus resulting in a send time of several 
> weeks, I got a problem:
> 
> about one reattempt out of 200 fails with a situation when there's no 
> snapshot on the receiving side (only an incomplete dataset which is 
> definitely smaller than original one), thus meaning that the dataset is 
> incomplete, but there's no token on this dataset. This happened already 
> twice, each time on a different size.
> 
> How can this even be possible ?
> 
> 
> Recieving side side:
> 
> [root@playkey-nas:~]# zfs list -t all
> NAME USED  AVAIL  REFER  MOUNTPOINT
> data4,67T  20,8T   128K  /data
> data/reference  4,67T  20,8T   128K  /data/reference
> 
> (as you can see there's no snapshot)
> 
> Sending side and the snapshot:
> 
> [root@san1:/usr/src]# zfs list -t all | grep data/reference@ver2_5917
> data/reference@ver2_5917 44,3G  -  7,73T  -

zfs(8) manual page tells:

 receive_resume_token
 For filesystems or volumes which have saved partially-completed state
 from zfs receive -s, this opaque token can be provided to zfs send -t
 to resume and complete the zfs receive.

Note that /bin/sh does NOT support storing arbitrary opaque data in its 
variables in unencoded form.
Maybe sometimes you get token with characters that break such code.

Here is how I encode completely opaque and even binary data when I need to 
store in a shell variable:

key=$(command_printing_data | b64encode -r -)
# use binary key later:
echo "$key" | b64decode -r | geli attach -pk - $p

This technique works for any kind of data including special symbols, zero bytes 
etc.

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

Re: State of encrypted-almost-everything on ZFS in 2020

[Eugene Grosbein]

16.05.2020 16:51, Thomas Zander via freebsd-stable wrote:

> Hi,
> 
> can the following be done these days?
> - Encrypted ZFS root pool on RAID-Z
> - Supply the key for the encrypted root pool during boot via USB thumb drive
>   - No keyboard is attached to the machine
>   - No /boot on the thumb drive, just the key
> - I don't mind if /boot is encrypted or not (the use case is not to
> protect against nation state attackers)
> - Bonus points if I can use bectl
> 
> Every single posting regarding this topic I can find always comes down to 
> either
> a) One needs /boot on the thumb drive, or
> b) One uses a keyboard and supplies a passphrase instead of a keyfile.

Note that root pool does not need to be original boot pool.

It is possible to share your disks between two different ZFS pools:
small first unencrypted boot pool that boots normally and starts plain shell 
script
that reads the key from any storage you prefer to decrypt and attach
second encrypted pool. Then set vfs.root.mountfrom to second pool with kenv(1)
and use re-rooting (reboot -r) to re-start booting from now-available encrypted 
pool.

This is how to share disks with GEOM_RAID:

1. Cut first N megabytes of each disk to form N-way mirror using "Promise" 
on-disk volume label format:

graid label -S ${N}M Promise r0 RAID1 /dev/da0 /dev/da1 /dev/da2 ...

This gives you /dev/raid/r0 device, use it to create unencrypted non-redundant 
ZFS boot pool,
as GEOM_RAID provides (mirrored) redundancy.

2. Allocate tail of each drive to set of SINGLE graid volumes:

graid label Promise r1 SINGLE /dev/da0
graid label Promise r2 SINGLE /dev/da1
graid label Promise r3 SINGLE /dev/da2
...

This gives you devices /dev/raid/r1, /dev/raid/r2 etc. Use them as vdevs to 
create your encrypted RAID-Z.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

stable/11 source upgrade broken for i386

[Eugene Grosbein]

Hi!

It seems that clang-6 supplied with 11.2 cannot build clang-9 in stable/11 for 
i386,
so buildworld is broken. Details are here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246274
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

stable/11 source upgrade broken for i386

[Eugene Grosbein]

Hi!

It seems that clang-6 supplied with 11.2 cannot build clang-9 in stable/9 for 
i386,
so buildworld is broken. Details are here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246274
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Loader hangs on the latest -STABLE

[Eugene Grosbein]

24.04.2020 11:26, Igor Pokrovsky пишет:

> Hello all,
> 
> I haven’t been using FreeBSD since 8-STABLE times. Recently I tried to 
> install latest 12-STABLE on my old computer.
> But even during initial boot up loader hangs. Eventually I was able to 
> proceed with installation after replacing loader in 
> the installation disk with one found in my old system 8-STABLE. The same 
> happened when I tried zfs on root partition.
> 
> I used MBR partition on PATA hard drive. Motherboard was ASUS A8V (Athlon64).

Modern FreeBSD versions use newer vt(4) console driver that defaults to pixel 
mode rendering
and depends on correctness of ACPI tables of motherboard's firmware much more
than old syscons(4) console driver that is still available.
You should try escaping to the loader prompt first and run these commands:

set kern.vty=sc
boot

Try it and see if it helps. If so, don't forget adding "kern.vty=sc" to 
/boot/loader.conf
after installation.

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

Re: What was the intention about "jail -e" in the first place ?

[Eugene Grosbein]

16.04.2020 16:31, David Marec wrote:

> The manpage and usage output doesn't match.
> 
> The manpage tells us that this option should be used alone on the command 
> line, as any other command will be discarded.
> 
> The usage ouput does not mention the "-r" flag but "cmr" (with a typo).
> 
> Both suggest that the user can request information about one single jail, or 
> all the jails using a wildcard or no other argument.
> 
> Well, looking at the code, it sounds that the only way to make it work is to 
> use it alone on the command line, and their is no way get information about a 
> single jail.
> 
> Attached is a short patch to get information about one single jail or all 
> jails (wildcards or empty).
> 
> 
> But,how was "jail -e" intending to be used, actually ?

"jail -e" mode is used by periodic/weekly/340.noid script to differentiate 
parts of mounted file trees
belonging to the host and to the configured full-blown jails, no matter started 
or not.

This is documentation ambiguity as "jail -e" was not intended to take jail name 
as additional argument.
Do you have any real use case this addition?

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

Re: make kernel ignore broken SATA disk

[Eugene Grosbein]

12.04.2020 23:30, Stefan Bethke пишет:
> Am 12.04.2020 um 18:29 schrieb Eugene Grosbein  <mailto:eu...@grosbein.net>>:
>>
>> 12.04.2020 21:57, Stefan Bethke wrote:
>>
>>>>> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 
>>>>> and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I 
>>>>> do have a spare disk I can use to replace the failed one, but I can't get 
>>>>> the machine into a state where I could even issue the zpool replace 
>>>>> command.
>>>>
>>>> It depends on the HDD controller the disk is attached to. What controller 
>>>> and driver does it have?
>>>
>>> This is from an identlical machine without disk issues:
>>>
>>> # camcontrol devlist
>>>   at scbus4 target 0 lun 0 (ada0,pass0)
>>>   at scbus5 target 0 lun 0 (ada1,pass1)
>>>   at scbus6 target 0 lun 0 (ada2,pass2)
>>>at scbus8 target 0 lun 0 (pass3)
>>> # pciconf -lv
>>> ...
>>> ahci0@pci0:0:23:0:class=0x010601 card=0x088415d9 chip=0xa1028086 rev=0x31 
>>> hdr=0x00
>>>vendor = 'Intel Corporation'
>>>device = 'Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA 
>>> Controller [AHCI Mode]'
>>>class  = mass storage
>>>subclass   = SATA
>>
>> And your FreeBSD version?
> 
> FreeBSD 12.1-STABLE r358833 amd64

Try something like this at loader prompt:

set hint.ahcich.5.disabled=1

or

set hint.ada.1.disabled=1


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

Re: make kernel ignore broken SATA disk

[Eugene Grosbein]

12.04.2020 21:57, Stefan Bethke wrote:

>>> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 
>>> and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do 
>>> have a spare disk I can use to replace the failed one, but I can't get the 
>>> machine into a state where I could even issue the zpool replace command.
>>
>> It depends on the HDD controller the disk is attached to. What controller 
>> and driver does it have?
> 
> This is from an identlical machine without disk issues:
> 
> # camcontrol devlist
>   at scbus4 target 0 lun 0 (ada0,pass0)
>   at scbus5 target 0 lun 0 (ada1,pass1)
>   at scbus6 target 0 lun 0 (ada2,pass2)
>at scbus8 target 0 lun 0 (pass3)
> # pciconf -lv
> ...
> ahci0@pci0:0:23:0:class=0x010601 card=0x088415d9 chip=0xa1028086 rev=0x31 
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller 
> [AHCI Mode]'
> class  = mass storage
> subclass   = SATA

And your FreeBSD version?

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

Re: make kernel ignore broken SATA disk

[Eugene Grosbein]

12.04.2020 21:37, Stefan Bethke wrote:

> I have a server I don't have physical access to right now, which has a broken 
> SATA disk that produces mostly errors (but not entirely).
> 
> The disk has two partitions that are part of a zpool each. I can't bring the 
> system up with this disk being online, because ZFS is trying its darndest to 
> use it.
> 
> I already renamed the GPT partitions in the hope that ZFS would not find them 
> anymore, but it does.
> 
> I can't gpart destroy -f ada1 because "device busy".
> 
> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 
> and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do 
> have a spare disk I can use to replace the failed one, but I can't get the 
> machine into a state where I could even issue the zpool replace command.

It depends on the HDD controller the disk is attached to. What controller and 
driver does it have?


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

Re: Why is the console a graphic/bitmapped console, and not text/character by default

[Eugene Grosbein]

12.04.2020 11:41, Chris wrote:

> Sorry for the ling title. But wasn't sure how make my
> question more concise.
> Why did we begin making an initial console "graphics mode"
> by default. My understanding has always been that (Free)BSD
> has been a "Server by default", and a Desktop after an initial
> install if that's one chosen target.
> It's near impossible to perform initial configuration
> in graphics mode, using a mouse to cut/copy/paste does *not*
> work as intended. Which requires one to make the necessary
> changes "breaking to the new system" after install completes
> to change initiation to test-mode before bouncing the box.
> While this "works" for long-time users. It's an *extra*, and
> seemingly *unnecessary* step. It is also likely to behoove
> first-time/new users -- except those already targeting a
> Desktop.
> 
> Thanks for any insight into this! :)

There are now many new hardware incapable of booting in legacy mode.
It runs in UEFI mode only that needs newer console driver vt(4)
that defaults to pixel rendering mode but supports text mode, too.
Sadly, some UEFI-based hardware does not support text mode even with vt(4)
and there is no option other than using pixel mode then.

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

Re: ZFS server has gone crazy slow

[Eugene Grosbein]

12.04.2020 2:25, Chris Ross пишет:
> 
>> On Apr 11, 2020, at 14:33, Eugene Grosbein  wrote:
>>
>> 12.04.2020 0:36, Chris Ross wrote:
>>
>>> I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror 
>>> (of two GPT disks) as it’s disk.  It’s many years old, and has only been 
>>> misbehaving like this for a day or so.  I’m trying to figure out what’s 
>>> wrong.
>>>
>>> […]
>>>
>>> I _think_ this is a filesystem problem.  It’s very hard to diagnose because 
>>> logging in, and doing anything, takes many seconds per command.  zpool 
>>> status shows my mirror as online, so I’m not sure where I should check.
>>>
>>> I’d appreciate any help!  Thanks much…
>>
>> First of all you should check if any of your ZFS pools is low on space.
> 
> Wow.  I’m so embarrassed that I didn’t notice that myself.  You mentioned it, 
> and now I look back at df output and see that the filesystems are all very 
> nearly full!
> 
> It’s very slowly booting now, but assumedly after it comes online, I’ll be 
> able to rectify that situation and hopefully that will be the issue.  Thanks, 
> and sorry that I hadn’t seen that myself!

There is very simple way to prevent such problem, use: zfs set reservation=1G
for single "root" file system of the pool.

This way ZFS won't allow applications to fill the pool to the point it starts 
crawling.
Instead, writing applications would obtain ENOSPC error when pool's free space 
hits the limit.

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

Re: ZFS server has gone crazy slow

[Eugene Grosbein]

12.04.2020 0:36, Chris Ross wrote:

> I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror (of 
> two GPT disks) as it’s disk.  It’s many years old, and has only been 
> misbehaving like this for a day or so.  I’m trying to figure out what’s wrong.
> 
> I confirmed that internet connectivity isn’t the problem, and a reboot didn’t 
> fix it.  (The reboot took 10-15 minutes to finish going multi-user, starting 
> daemons, due to the underlying problem described below.)
> 
> Truss’ing a very basic command (date), I can see that close() and exit() 
> calls are taking 1-2 seconds.  All of the files being opened are on ZFS, but 
> I don’t know if that’s for sure related.  Similarly, using shell builtin 
> “echo foo” always is immediate, but “/bin/echo” sometimes works quickly, but 
> sometimes the close() on /var/run/ld-elf.so.hints takes 3-5 seconds.
> 
> I _think_ this is a filesystem problem.  It’s very hard to diagnose because 
> logging in, and doing anything, takes many seconds per command.  zpool status 
> shows my mirror as online, so I’m not sure where I should check.
> 
> I’d appreciate any help!  Thanks much…

First of all you should check if any of your ZFS pools is low on space.

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

Re: BSNMPD crashing

[Eugene Grosbein]

29.03.2020 1:53, Andrea Brancatelli via freebsd-stable wrote:

> If anyone is interested please feel free to contact me otherwise I'll
> just delete it :-)

What is most recent version of FreeBSD that has this problem with bsnmpd 
crashing?

Please rebuild bsnmpd with debugging enabled, if you have sources installed:

cd /usr/src/usr.sbin/bsnmpd
make clean
make cleandir
make obj depend
make WITH_DEBUG=yes
install /usr/obj/usr/local/src/usr.sbin/bsnmpd/bsnmpd/bsnmpd /usr/sbin

Restart bsnmpd and wait for next crash. Then you could obtain meaningfull 
backtrace.

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

Re: users of xorg, in particular on FreeBSD 11.3

[Eugene Grosbein]

21.03.2020 6:41, Niclas Zeising wrote:

> [ This is cross-posted across several mailing lists for maximum visibility.  
> Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ]
> 
> In order to improve support when using evdev to manage input devices, in 
> particular keyboards, we have switched the default in x11/libxkbcommon to the 
> evdev instead of the legacy ruleset.  This was done in ports r528813 .
> 
> On FreeBSD 11.3, the default configuration still requires the legacy ruleset.
> 
> If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on 
> FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon.
> 
> If you have issues with your keyboard, most notably arrow keys, and if 
> /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, 
> you need to switch to legacy rules by setting the environment variable 
> XKB_DEFAULT_RULES to xorg.
> 
> The easiest way to accomplish this is by adding it to your shell startup file.
> 
> As an example, for users of [t]csh, put
>   setenv XKB_DEFAULT_RULES xorg
> in ~/.login
> 
> For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
> export XKB_DEFAULT_RULES=xorg
> in ~/.profile

Please consider improving x11/libxkbcommon so that it uses -Ddefault-rules=xorg
if OSVERSION notes 11.x at build time, so there would be no breakage for us 
building xorg from ports.

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

Re: Can't input '\', '|', '_' symbol in Japanese keyboard

[Eugene Grosbein]

25.02.2020 4:37, Minoru TANABE wrote:

CC'ing to author of mentioned revision.

> Hi, all.
> I'm 12-stable user.
> My system upgrade from 12.1-stable_r357351(2020-02-01) to
> r358294(2020-02-24).
> After upgrading, I can't input '\', '|', '_' symbol.
> 
> I use vt console driver and jp.capsctrl.kbd keymap.
> These symbols are defined as scancode 115 and 125 in keymap.
> I checked source, and find /stable/12/sys/dev/usb/input/ukbd.c was changed.
> I revert Revision 358211
> (Modified
> Fri Feb 21 08:30:34 2020 UTC) to Revision 356020
> (Modified
> Sun Dec 22 19:06:45 2019 UTC),
> everything works fine.
> Does anyone have better workaround?
> 
> I'm poor at English, excuse me.
> Thanks.
> 

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

Re: base svn(lite) LTS not updated

[Eugene Grosbein]

23.02.2020 3:01, Nuno Teixeira wrote:

> Hello,
> 
> I noticed that STABLE and CURRENT have base subversion at version 1.10.0.
> 
> Why is base svn not updated to last LTS 1.10.6?

You are supposed to install /usr/ports/devel/subversion (1.13.0 at the moment)
for any usage other than updating FreeBSD repositories (src, ports, etc.)


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

Re: 12.1, Dell 740 and the M2 SSD as boot media doesn't work

[Eugene Grosbein]

19.12.2019 11:21, George Michaelson wrote:

> I tried an install on a new Dell 740, which has dual M2 256GB internal
> SSD on a "Boss" controller. It exposes as AHCI.
> 
> It wouldn't recognize these as installable drives as raw devices. If
> you use the Boss to define a virtual drive in RAID-1 it exposes fine.
> 
> Tried BIOS mode (not UEFI), tried FB13. No go. But, as a virtual,
> worked fine in UEFI boot mode.
> 
> Dell. I mean, its not like we haven't been here before with their
> special SAS firmware, but still if anyone else has seen this and knows
> magic which unlocks the real device on AHCI I'd love to know.

You either switch the controller to "HBA" mode using its setup utility,
or keep it in current "RAID" mode but configure your SSD as "Non-RAID" drive.

Also, you must use mrsas(4) driver instead of default mfi(4) to get TRIM 
support for SSD.
mfi(4) has no TRIM support at all. You may switch to mrsas(4) after 
intallation, though.

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

Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Eugene Grosbein]

10.12.2019 23:08, Mark Martinec пишет:
> 2019-12-10 16:35, Marc Branchaud wrote:
> 
>> On 2019-12-10 9:18 a.m., Mark Martinec wrote:
>>> Commenting on a thread from 2018-12 and from 2019-09-20, with my solution
>>> to the boot problem at the end, in case anyone is still interested.
>>
>> Thank you very much for this.  A couple of questions:
>>
>> (1) Why do you say "raw devices for historical reasons"?  Glancing
>> through the zpool man page and the Handbook, I see nothing
>> recommending or requiring GPT partitions.
> 
> Apparently using raw devices for zpool is now discouraged,
> although I don't think it has ever become officially unsupported.

Loader bugs do not mean that "using raw devices for zpool is now discouraged".


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

Re: ng_ipacct on FreeBSD 12.1 doesnt work

[Eugene Grosbein]

07.12.2019 7:22, Eugene Grosbein wrote:

Adding port maintainer to CC:

>> Yes. It works. Thank you very much.
>>
>> I delete manual copied file.
>> I install ports via portsnap.
>> I fetch srcs from ftp.
>> And install ng_ipacct from ports.
>> And option VIMAGE in port ng_ipacct was disabled. I dont know why.
>> option VIMAGE in kernel of 12.1 by default is enabled.
>>
>> PS Is any option for pkg install to enable VIMAGE in this port?
>> Or I need to return to /usr/src and /usr/ports to rebuild this port after 
>> each FreeBSD version upgrade?
>>
>> So. I use FreeBSD many years. And in a few years ago I switched from manual 
>> building of kernel and world to freebsd-update. It works on 10.x version 
>> well. I install on that freebsd version ng_ipacct via "pkg install". And all 
>> works fine.
>> On version 11.1 it looks like all was fine too. Work with total pkg upgrade 
>> after upgrade FreeBSD from version 10 to 11. Here I dont sure, because I was 
>> on version 11.3 only a few days. At least one or two years it works on 
>> version 11.1 very well.
>> But after upgrade from 11.3 to 12.1 "pkg install ng_ipacct" got broken.
>> Is it really can be? Or it's my mistake?
> 
> This option is enabled by default, so the package should be built accordingly.
> Are you sure you use official source for packages?

Sorry, I was wrong: the port defaults to disabled VIMAGE option, this explains 
your difficulty.

Vsevolid, please consider enabling option VIMAGE for net-mgmt/ng_ipacct for 
branches having VIMAGE in GENERIC,
so the package would be usable out-of-the-box there.

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

Re: ng_ipacct on FreeBSD 12.1 doesnt work

[Eugene Grosbein]

07.12.2019 6:03, Eugene Kazarinov wrote:

> Yes. It works. Thank you very much.
> 
> I delete manual copied file.
> I install ports via portsnap.
> I fetch srcs from ftp.
> And install ng_ipacct from ports.
> And option VIMAGE in port ng_ipacct was disabled. I dont know why.
> option VIMAGE in kernel of 12.1 by default is enabled.
> 
> PS Is any option for pkg install to enable VIMAGE in this port?
> Or I need to return to /usr/src and /usr/ports to rebuild this port after 
> each FreeBSD version upgrade?
> 
> So. I use FreeBSD many years. And in a few years ago I switched from manual 
> building of kernel and world to freebsd-update. It works on 10.x version 
> well. I install on that freebsd version ng_ipacct via "pkg install". And all 
> works fine.
> On version 11.1 it looks like all was fine too. Work with total pkg upgrade 
> after upgrade FreeBSD from version 10 to 11. Here I dont sure, because I was 
> on version 11.3 only a few days. At least one or two years it works on 
> version 11.1 very well.
> But after upgrade from 11.3 to 12.1 "pkg install ng_ipacct" got broken.
> Is it really can be? Or it's my mistake?

This option is enabled by default, so the package should be built accordingly.
Are you sure you use official source for packages?

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

Re: ng_ipacct on FreeBSD 12.1 doesnt work

[Eugene Grosbein]

07.12.2019 0:49, Eugene Kazarinov wrote:

> pkg install ng_ipacct install ng_ipacct.ko in /boot/modules/ and it
> doesnt start
> 
> if I copy ng_ipacct.ko to /boot/kernel/ it didnt start with error:
> link_elf_obj: symbol tcbinfo undefined
> linker_load_file: /boot/kernel/ng_ipacct.ko - unsupported file type
> 
> How to run ng_ipacct on FreeBSD 12.1?

The port has option VIMAGE enabled by default matching GENERIC kernel that has 
options VIMAGE included.
It seems you have built the port with option VIMAGE disabled for some reason.

Use: make config clean all deinstall reinstall
to enable this option and rebuild ng_ipacct. You don't need to copy in 
manually, remove copied file.

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

Re: Slow zfs destroy

[Eugene Grosbein]

02.12.2019 20:35, Andriy Gapon wrote:

> On 02/12/2019 11:27, Scott Bennett wrote:
>>  The vast majority of my "destroy" operations are for snapshots, but what
>> I have seen is that, without the "-d", the command does not return until the
>> disk activity of the "destroy" finishes, but with the "-d", it returns within
>> a couple of seconds,--i.e., just long enough to get the operation going--and
>> the disk I/Os continue until the work is done and free space in the pool 
>> increases
>> until the I/Os stop.
>>  Perhaps the man pages for zfs(8) and zpool-features(7) need some 
>> modification/
>> clarification on this matter.
> 
> I don't know how to explain what you see, but the manual pages are correct.
> -d has nothing to do with asynchronous destroy which is automatic (when 
> enabled).

It seems that "zfs destroy" writes and/or removes large enough amount of data 
to spend lots of time
before return when TRIM performance is bad.


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

Re: Slow zfs destroy

[Eugene Grosbein]

30.11.2019 0:57, Scott Bennett wrote:

>  On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein 
> wrote:
> 
>> 28.11.2019 20:34, Steven Hartland wrote:
>>
>>> It may well depend on the extent of the deletes occurring.
>>>
>>> Have you tried disabling TRIM to see if it eliminates the delay?
>>
>> This system used mfi(4) first and mfi(4) does not support TRIM at all. 
>> Performance was abysmal.
>> Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs one-by-one 
>> then re-added them to RAID1.
>> Disabling TRIM is not an option.
>>
>> Almost a year has passed since then and I suspect SSDs have no or a few 
>> spare trimmed cells for some reason.
>> Is there documented way to check this out? Maybe some SMART attribute?
>>
>  You neglected to state whether you used "zfs destroy datasetname" or
> "zfs destroy -d datasetname".  If you used the former, then ZFS did what
> you told it to do.  If you want the data set destroyed in the background,
> you will need to include the "-d" option in the command.  (See the zfs(1)
> man page at defer_destroy under "Native Properties".)

The manual says "zfs destroy -d" is not for "background" but for "deferred".
The "zfs destroy" without -d would return EBUSY for a snapshot on hold (zfs 
hold)
or bound with a clone, but "zfs destroy -d" would mark the snapshot for later 
destruction
in a moment the clone is deleted or user lock (hold) is lifted.
Until then the snapshot still usable and destruction does not happen.

All my snapshots are free from holds or clones and can be deleted,
so "zfs destroy -d" is equal to "zfs destroy" for them.

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

Re: ZFS deadlock

[Eugene Grosbein]

30.11.2019 15:48, Eugene Grosbein wrote:

> Hi!
> 
> I have RAIDZ1 with five GELI-encrypted SSDs da[2-6].eli (non-boot pool).
> 
> I've exported the pool, destroyed da2.eli then successfully imported pool 
> back in degraded state.
> Then I've mounted some file systems successfully but zfs mount for next one 
> hung on [tx->tx_sync_done_cv]
> for 4400 seconds and counting.
> 
> # procstat -kk -L 55464
>   PIDTID COMMTDNAME  KSTACK
> 55464 102422 zfs -   mi_switch+0xeb 
> sleepq_wait+0x2c _cv_wait+0x16e txg_wait_synced+0xa5 dmu_tx_assign+0x48 
> zfs_rmnode+0x122 zfs_freebsd_reclaim+0x4e VOP_RECLAIM_APV+0x80 vgonel+0x213 
> vrecycle+0x46 zfs_freebsd_inactive+0xd VOP_INACTIVE_APV+0x80 vinactive+0xf0 
> vputx+0x2c3 zfs_unlinked_drain+0x1b8 zfsvfs_setup+0x5e zfs_mount+0x5f5 
> vfs_domount+0x573
> 
> It looks like deadlock for me.
> 
> What can I do to resolve this? FreeBSD 11.3-STABLE/amd64 r354667.

"zfs mount" just completed successfully after trim -f /dev/da2 (3.5TB) finished 
in 76 minutes.


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

ZFS deadlock

[Eugene Grosbein]

Hi!

I have RAIDZ1 with five GELI-encrypted SSDs da[2-6].eli (non-boot pool).

I've exported the pool, destroyed da2.eli then successfully imported pool back 
in degraded state.
Then I've mounted some file systems successfully but zfs mount for next one 
hung on [tx->tx_sync_done_cv]
for 4400 seconds and counting.

# procstat -kk -L 55464
  PIDTID COMMTDNAME  KSTACK
55464 102422 zfs -   mi_switch+0xeb 
sleepq_wait+0x2c _cv_wait+0x16e txg_wait_synced+0xa5 dmu_tx_assign+0x48 
zfs_rmnode+0x122 zfs_freebsd_reclaim+0x4e VOP_RECLAIM_APV+0x80 vgonel+0x213 
vrecycle+0x46 zfs_freebsd_inactive+0xd VOP_INACTIVE_APV+0x80 vinactive+0xf0 
vputx+0x2c3 zfs_unlinked_drain+0x1b8 zfsvfs_setup+0x5e zfs_mount+0x5f5 
vfs_domount+0x573

It looks like deadlock for me.

What can I do to resolve this? FreeBSD 11.3-STABLE/amd64 r354667.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Slow zfs destroy

[Eugene Grosbein]

28.11.2019 20:34, Steven Hartland wrote:

> It may well depend on the extent of the deletes occurring.
> 
> Have you tried disabling TRIM to see if it eliminates the delay?

This system used mfi(4) first and mfi(4) does not support TRIM at all. 
Performance was abysmal.
Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs one-by-one 
then re-added them to RAID1.
Disabling TRIM is not an option.

Almost a year has passed since then and I suspect SSDs have no or a few spare 
trimmed cells for some reason.
Is there documented way to check this out? Maybe some SMART attribute?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Slow zfs destroy

[Eugene Grosbein]

28.11.2019 14:26, Steven Hartland wrote:

> As you mentioned it’s on SSD you could be suffering from poor TRIM 
> performance from your devices
> if you run gstat -pd you’ll be able to get an indication if this is the case.

Yes, this box does have problems with poor TRIM performance.
But isn't "zfs destroy" supposed to perform actual removal in background?
"feature@async_destroy" is "enabled" for this pool.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Slow zfs destroy

[Eugene Grosbein]

28.11.2019 16:38, Pete French wrote:

> On 28/Nov/2019 07:03, Eugene Grosbein wrote:
>> 28.11.2019 13:46, Eugene Grosbein wrote:
>>
>>> Hi!
>>>
>>> Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to 
>>> 2112939808 bytes (~2GB)
>>> takes over two minutes waiting on "tx_sync_done_cv"? The pool is RAID1 over 
>>> five SSDs encrypted with GELI
>>
>> The pool is *RAIDZ1*
> 
> Not normal, no. Having said that I have seen zfs destory take a very lng time 
> on occasion,
> but for a 2GB volume then thats surprisng. Is there actual disc activity 
> during this time ?

Yes, a lot. Several rsync instances writing to another ZFS (mounted file 
systems) in parallel:
copying data over ssh from remote hosts (backups).

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

Re: Slow zfs destroy

[Eugene Grosbein]

28.11.2019 13:46, Eugene Grosbein wrote:

> Hi!
> 
> Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to 
> 2112939808 bytes (~2GB)
> takes over two minutes waiting on "tx_sync_done_cv"? The pool is RAID1 over 
> five SSDs encrypted with GELI

The pool is *RAIDZ1*

> having ZIL and Cache on distinct unencrypted SSD.
> 
> 11.3-STABLE/amd64 r354667. System has 360G RAM and vfs.zfs.arc_max=160g.

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

Slow zfs destroy

[Eugene Grosbein]

Hi!

Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to 
2112939808 bytes (~2GB)
takes over two minutes waiting on "tx_sync_done_cv"? The pool is RAID1 over 
five SSDs encrypted with GELI
having ZIL and Cache on distinct unencrypted SSD.

11.3-STABLE/amd64 r354667. System has 360G RAM and vfs.zfs.arc_max=160g.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Logging boot messages from the loader

[Eugene Grosbein]

21.11.2019 18:35, David Wolfskill wrote:

>> How do I get boot messages generated by loader itself written to some log 
>> after successfull boot?
>> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console 
>> driver.
>>
>> /var/run/dmesg.boot starts with kernel messages without previous lines from 
>> the loader.
>> Specifically, I need messages about loading kernel modules with full paths.
>> 
> 
> Perhaps: Set up serial console on the machine in question, then
> connect a machine that's expected to be "sufficiently stable" to
> the other end of a "null modem" cable & run tip(1) on the second
> machine (perhaps within script(1)).
> 
> Or something similar, anyway.

The box is located in remote hoster's datacenter, so I was looking for easier 
way. Bad luck.


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

Re: Logging boot messages from the loader

[Eugene Grosbein]

21.11.2019 17:22, Bjoern A. Zeeb wrote:

> On 21 Nov 2019, at 9:51, Eugene Grosbein wrote:
> 
>> Hi!
>>
>> How do I get boot messages generated by loader itself written to some log 
>> after successfull boot?
>> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console 
>> driver.
>>
>> /var/run/dmesg.boot starts with kernel messages without previous lines from 
>> the loader.
>> Specifically, I need messages about loading kernel modules with full paths.
> 
> loader cannot write to the kernel message buffer as there is no kernel yet.  
> There might be possible ways to preserve that but I doubt loader is fit for 
> that task.

Some hardware does not clear memory while warm booting, so KDB trace from 
previous panic sometimes survive reboot
and ends up in /var/run/dmesg.boot for successful boot. I wonder why loader 
messages cannot be there, too.
In fact, kernel message buffer can be found even in absence of kernel :-)

I've already searched through the sources in stand/ and see there is no code to 
support this yet.

> A boot -v (boot_verbose=“YES”) might spit the information out from the kernel 
> as well.   Not sure if that helps you.  However on modern server machines a 
> boot -v often overflows the message buffer.. so you might have to tune that 
> as well.
> 
> Extracted from an older console log of a random lab machine of someone else:
> ..
> WARNING: WITNESS option enabled, expect reduced performance.^M^@
> WARNING: DIAGNOSTIC option enabled, expect reduced performance.^M^@
> Preloaded elf kernel "/boot/kernel/kernel" at 0x80e66000.^M^@
> Preloaded elf obj module "/boot/kernel/if_igb.ko" at 0x80e66968.^M^@
> Preloaded elf obj module "/boot/kernel/nfscl.ko" at 0x80e66fd0.^M^@
> Preloaded elf obj module "/boot/kernel/nfslock.ko" at 0x80e67638.^M^@
> Preloaded elf obj module "/boot/kernel/nfssvc.ko" at 0x80e67ba0.^M^@
> Preloaded elf obj module "/boot/kernel/krpc.ko" at 0x80e68088.^M^@
> Preloaded elf obj module "/boot/kernel/nfscommon.ko" at 
> 0x80e686b0.^M^@
> Preloaded elf obj module "/boot/kernel/ahci.ko" at 0x80e68d20.^M^@
> Preloaded elf obj module "/boot/kernel/cam.ko" at 0x80e69308.^M^@
> Preloaded elf obj module "/boot/kernel/mfi.ko" at 0x80e699f0.^M^@
> Preloaded elf obj module "/boot/kernel/geom_part_gpt.ko" at 
> 0x80e6a058.^M^@
> Preloaded elf obj module "/boot/kernel/sysvsem.ko" at 0x80e6a648.^M^@
> Preloaded elf obj module "/boot/kernel/sysvshm.ko" at 0x80e6acb0.^M^@
> Calibrating TSC clock ... TSC clock: 3400185886 Hz^M^@
> CPU: Intel(R) Xeon(R) CPU   X5272  @ 3.40GHz (3400.19-MHz K8-class 
> CPU)^M^@

Yes, but this only shows results of loader's work and kldstat -v shows paths 
too.
I need to know why changing modules_path in the nextboot.conf does not work
and why does loader uses stock zfs.ko insted of my patched version 
/boot/nextboot/zfs.ko
if I use nextboot.conf with 
module_path="/boot/nextboot;/boot/kernel;/boot/modules"

I have panicing production server (ZFS-only) and cannot reboot it often and
I don't wont to make cycle-boot by mistake due to wrong debugging code I might 
add to the module.


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

Logging boot messages from the loader

[Eugene Grosbein]

Hi!

How do I get boot messages generated by loader itself written to some log after 
successfull boot?
This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console driver.

/var/run/dmesg.boot starts with kernel messages without previous lines from the 
loader.
Specifically, I need messages about loading kernel modules with full paths.

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

Re: jexec as user?

[Eugene Grosbein]

20.11.2019 16:47, Ronald Klop wrote:

> Thanks for all the advice. I am indeed looking for using jail from the 
> non-root user in the host. Jailme sounds like a good solution.
> 
> My use case is providing a relatively save way of giving a user the 
> possibility to experiment with root rights (like creating and installing 
> ports) without wracking the host system.
> The users are trusted so it is not so much about security. More about keeping 
> the host system clean.

You also could run ssh service inside the jail and give users opportunity to 
experiment with ssh and keys :-)

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

Re: bhyve memory leak in stable/11

[Eugene Grosbein]

18.11.2019 19:03, Eugene Grosbein wrote:

> Please point me to right direction for debugging this.

Is it normal that over 1/3rd of 360G total physical RAM is in "Laundry" 
category in addition to 173G Wired?

last pid: 20372;  load averages:  8.04,  7.73,  7.84   up 
2+05:55:29  16:04:02
130 processes: 3 running, 126 sleeping, 1 zombie
CPU:  1.1% user,  0.0% nice, 13.2% system,  0.1% interrupt, 85.7% idle
Mem: 42G Active, 8325M Inact, 112G Laundry, 173G Wired, 7809M Free
ARC: 131G Total, 28G MFU, 90G MRU, 11M Anon, 2442M Header, 10G Other
 107G Compressed, 363G Uncompressed, 3.41:1 Ratio
Swap: 64G Total, 16G Used, 48G Free, 24% Inuse

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
78042 root 34  200 54328M 52867M kqread  7  81.4H 210.63% bhyve: 
sappdev (bhyve)
59085 root 20  200 31512M 25256M kqread  6 490:16  16.25% bhyve: 
sdc01 (bhyve)
59568 root 28  200 28549M 24270M kqread  6 143:32   1.22% bhyve: 
sfile01 (bhyve)
60011 root 20  200 30262M 23697M kqread 27 121:22   1.08% bhyve: 
skms01 (bhyve)
63676 root 34  200 16418M 12799M kqread  3 113:06  19.92% bhyve: 
solap (bhyve)
26819 root 26  200 12321M 10472M kqread 28 151:43  10.12% bhyve: 
srdapp01 (bhyve)
63662 root 34  200  8226M  6969M kqread  4 114:52  20.36% bhyve: 
ssql01 (bhyve)

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

Re: bhyve memory leak in stable/11

[Eugene Grosbein]

After 2 days of uptime there is a guest that should have only 2GB of RAM but 
uses nearly 22G "extra":

# ps -o vsz,rss,command | grep sfile01
29234040 24851428 bhyve: sfile01 (bhyve)

# bhyvectl --vm=sfile01 --get-all | grep -B1 -A1 mem
ID  Length  Name
0   2048MB  sysmem
1   2048KB  bootrom
Address Length  Segment Offset  Prot  Flags
0   2048MB  sysmem  0   RWX
FFE02048KB  bootrom 0   R-X
--
number of ExtINTs delivered to vcpu 0
Resident memory 2085765120
Wired memory0
vcpu total runtime  5701638719326

Also, there is another guest vm using 23696M despite of limit 2048M,
and another one using 25238M despite of limit 4096M,
and another one using 52867M despite of limit 40960M.

Please point me to right direction for debugging this.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bhyve memory leak in stable/11

[Eugene Grosbein]

16.11.2019 6:24, Xin LI wrote:
> There are several leaks fixed recently, but not all of them were merged back 
> to stable/11 (e.g. r341705 which may or may not be related to your issue).

It seems that fix deals with virtio-scsi but all guest systems use virtio-net 
and ahci-hd here.

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

Re: bhyve memory leak in stable/11

[Eugene Grosbein]

16.11.2019 6:24, Xin LI wrote:
> There are several leaks fixed recently, but not all of them were merged back 
> to stable/11 (e.g. r341705 which may or may not be related to your issue).
> 
> Personally, I'd recommend updating to 12.x for new features as they are being 
> actively developed and would be supported for about 3 more years compared to 
> 11.x series.

12.1-STABLE has way too many unfixed regressions (including iflib-related) for 
production system.

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

Re: panic: I/O to pool appears to be hung on vdev

[Eugene Grosbein]

15.11.2019 13:08, Eugene Grosbein wrote:
> Hi!
> 
> Recently I did routine source upgrade from 11.2-STABLE/amd64 to 11.3-STABLE 
> r354667
> that went without any problem. After less than 2 days of uptime it paniced 
> and failed to reboot (hung),
> screenshot is here: http://www.grosbein.net/freebsd/zpanic.png
> 
> It did not panic with 11.2-STABLE but had some performance problems with ZFS.

I have to correct myself: it did panic same way at least once with 11.2-STABLE 
r344922

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

Re: panic: I/O to pool appears to be hung on vdev

[Eugene Grosbein]

15.11.2019 13:08, Eugene Grosbein wrote:
> Hi!
> 
> Recently I did routine source upgrade from 11.2-STABLE/amd64 to 11.3-STABLE 
> r354667
> that went without any problem. After less than 2 days of uptime it paniced 
> and failed to reboot (hung),
> screenshot is here: http://www.grosbein.net/freebsd/zpanic.png
> 
> It did not panic with 11.2-STABLE but had some performance problems with ZFS.
> 
> Hardware: Dell PowerEdge R640 with 360G RAM, mrsas(4)-supported controller 
> PERC H730/P Mini LSI MegaRAID SAS-3 3108 [Invader]
> and 7 SSD devices, two of them keep FreeBSD installation (distinct boot pool) 
> and five others
> are GELI-encrypted and combined to another (RAIDZ1) pool 'sata' mentioned on 
> screenshot.
> 
> vfs.zfs.arc_max=160g
> 
> The system runs several bhyve instances over ZVOls. There are many shapshots 
> that are routinely
> created/destroyed so system generally issues many TRIM requests to underlying 
> SSDs.
> 
> After 1.5 day of uptime (before panic) I set 
> kern.cam.da.[2-6].delete_max=262144
> changing it from default 17179607040 hoping it would decrease latency of 
> read-write operations
> like listing of snapshots. No other non-default settings for ZFS were done.
> 
> What does it mean "panic: I/O to pool appears to be hung on vdev" provided 
> hardware is healthy?

I wonder also why did it panic instead of degrading the RAIDZ pool.


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

panic: I/O to pool appears to be hung on vdev

[Eugene Grosbein]

Hi!

Recently I did routine source upgrade from 11.2-STABLE/amd64 to 11.3-STABLE 
r354667
that went without any problem. After less than 2 days of uptime it paniced and 
failed to reboot (hung),
screenshot is here: http://www.grosbein.net/freebsd/zpanic.png

It did not panic with 11.2-STABLE but had some performance problems with ZFS.

Hardware: Dell PowerEdge R640 with 360G RAM, mrsas(4)-supported controller PERC 
H730/P Mini LSI MegaRAID SAS-3 3108 [Invader]
and 7 SSD devices, two of them keep FreeBSD installation (distinct boot pool) 
and five others
are GELI-encrypted and combined to another (RAIDZ1) pool 'sata' mentioned on 
screenshot.

vfs.zfs.arc_max=160g

The system runs several bhyve instances over ZVOls. There are many shapshots 
that are routinely
created/destroyed so system generally issues many TRIM requests to underlying 
SSDs.

After 1.5 day of uptime (before panic) I set kern.cam.da.[2-6].delete_max=262144
changing it from default 17179607040 hoping it would decrease latency of 
read-write operations
like listing of snapshots. No other non-default settings for ZFS were done.

What does it mean "panic: I/O to pool appears to be hung on vdev" provided 
hardware is healthy?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bhyve memory leak in stable/11

[Eugene Grosbein]

Hi!

After 1 day and 11 hours of host's uptime I observe significant leak of bhyve 
instances RSS:

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
8 root 34  200 60320M 58866M kqread 21  62.0H 692.35% bhyve: 
sappdev (bhyve)
 5546 root 26  200 22573M 22088M kqread 12 310:39   6.41% bhyve: 
srdapp01 (bhyve)
 3842 root 20  200 15946M 15862M kqread 13 340:36  14.03% bhyve: 
sdc01 (bhyve)
 4729 root 20  200 13792M 13455M kqread  8  79:40   1.02% bhyve: 
skms01 (bhyve)
 4283 root 28  200 12721M 12682M kqread 29  92:23   0.80% bhyve: 
sfile01 (bhyve)
 8057 root 34  200  8512M  8183M kqread 25 186:52  17.02% bhyve: 
ssql01 (bhyve)
23336 root 34  200 16418M  7716M kqread 14 114:23  17.62% bhyve: 
solap (bhyve)

The package vm-bhyve-1.2.3 is used here to manage bhyve instances
and sappdev.conf has memory=40G limit. srdapp01 is limited to 12G,
sdc01 to 4G, skms01 to 2G, sfile01 to 2G, ssql01 to 8G and solap to 16G.

Most of are using much more memory than they should. All of them run different 
versions of Windows servers.

The host is 11.3-STABLE/amd64 r354667 with 360G RAM and guest systems use
ZFS ZVOLs and vfs.zfs.arc_max=160g. 

How do I debug this?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kernel bug in 11.3-STABLE causes frequent crashes

[Eugene Grosbein]

09.11.2019 19:45, Scott Bennett wrote:

>  The rest of this message was posted a little while ago to the
> freebsd-questions list by mistake.  It was intended for freebsd-stable,
> so I am posting it here now after posting a brief apology on the other
> list.
>  I have had to waste a great deal of time lately in recovering my
> system from crashes due to a kernel bug.  At present, my system is
> 
> FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 
> 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas  amd64
> 
> There are actually at least two problems, but this particular one has been
> causing a large portion of my forced reboots.  It usually fails to produce
> a dump and freezes right after the panic and backtrace messages, as it did
> earlier tonight, but Wednesday night it did create a dump, which I am
> keeping in case it should prove helpful in getting the bug identified and
> solved.  I copied the console messages to paper painstakingly by hand.
> They appear to be identical each time, except, of course, for the messages
> that a dump is produced when, indeed, it does produce one.  I am omitting
> those fairly standard messages.
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0x3b8
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80a4b14c
> stack pointer   = 0x0:0xfe012a60ea50
> frame pointer   = 0x0:0xfe012a60eae0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 28 (flowcleaner)
> trap number = 12
> panic: page fault
> cpuid = 2
> KDB: stack backtrace:
> #0 0x80a94707 at kdb_backtrace+0x67
> #1 0x80a4fa2e at vpanic+0x17e
> #2 0x80a4f8a3 at panic+0x43
> #3 0x80f3a4d0 at trap_pfault+0
> #4 0x80f3a519 at trap_pfault+0x49
> #5 0x80f39bad at trap+0x29
> #6 0x80f19f33 at calltrap+0x8
> #7 0x80b3bb8d at flowtable_clean_vnet+0x43d
> #8 0x80b3c758 at flowtable_cleaner+0xc8
> #9 0x80a12ea2 at fork_exit+0x82
> #10 0x80flaf4e at fork_trampoline+0xe
> 
>  The machine is ancient.  The CPU is a QX9650 (last group of Core 2
> Quads) with 8 GB of DDR3 memory.
>  If this can be identified as a known bug and a clue provided to a
> patch or a safer version to upgrade to, I would be grateful.  I am getting
> very, very tired of these crashes.
>  The other forced reboots I will describe in a separate message, but
> that problem has existed since the time of 11.2-RELEASE and apparently was
> never investigated, much less fixed, although people began complaining on
> this list and possibly -questions within the first few days after the
> release date.
>  Thanks in advance for any help with this problem!

It seems you have custom kernel with options FLOWTABLE. The code it includes
is known to cause panics, this options was removed from GENERIC many releases 
ago.
Remove it from your kernel configuration, rebuild kernel and you will be fine.

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

Re: kernel bug in 11.3-STABLE causes frequent crashes

[Eugene Grosbein]

09.11.2019 19:45, Scott Bennett пишет:
>  The rest of this message was posted a little while ago to the
> freebsd-questions list by mistake.  It was intended for freebsd-stable,
> so I am posting it here now after posting a brief apology on the other
> list.
>  I have had to waste a great deal of time lately in recovering my
> system from crashes due to a kernel bug.  At present, my system is
> 
> FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 
> 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas  amd64
> 
> There are actually at least two problems, but this particular one has been
> causing a large portion of my forced reboots.  It usually fails to produce
> a dump and freezes right after the panic and backtrace messages, as it did
> earlier tonight, but Wednesday night it did create a dump, which I am
> keeping in case it should prove helpful in getting the bug identified and
> solved.  I copied the console messages to paper painstakingly by hand.
> They appear to be identical each time, except, of course, for the messages
> that a dump is produced when, indeed, it does produce one.  I am omitting
> those fairly standard messages.
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0x3b8
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80a4b14c
> stack pointer   = 0x0:0xfe012a60ea50
> frame pointer   = 0x0:0xfe012a60eae0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 28 (flowcleaner)
> trap number = 12
> panic: page fault
> cpuid = 2
> KDB: stack backtrace:
> #0 0x80a94707 at kdb_backtrace+0x67
> #1 0x80a4fa2e at vpanic+0x17e
> #2 0x80a4f8a3 at panic+0x43
> #3 0x80f3a4d0 at trap_pfault+0
> #4 0x80f3a519 at trap_pfault+0x49
> #5 0x80f39bad at trap+0x29
> #6 0x80f19f33 at calltrap+0x8
> #7 0x80b3bb8d at flowtable_clean_vnet+0x43d
> #8 0x80b3c758 at flowtable_cleaner+0xc8
> #9 0x80a12ea2 at fork_exit+0x82
> #10 0x80flaf4e at fork_trampoline+0xe
> 
>  The machine is ancient.  The CPU is a QX9650 (last group of Core 2
> Quads) with 8 GB of DDR3 memory.
>  If this can be identified as a known bug and a clue provided to a
> patch or a safer version to upgrade to, I would be grateful.  I am getting
> very, very tired of these crashes.
>  The other forced reboots I will describe in a separate message, but
> that problem has existed since the time of 11.2-RELEASE and apparently was
> never investigated, much less fixed, although people began complaining on
> this list and possibly -questions within the first few days after the
> release date.
>  Thanks in advance for any help with this problem!

It seems you have custom kernel with options FLOWTABLE. The code it includes
is known to be buggy, this options was removed from GENERIC many releases ago.
Remove it from your kernel configuration, rebuild kernel and you will be fine.



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

Re: 12.1 weirdness

[Eugene Grosbein]

17.10.2019 12:37, Daniel Braniss wrote:

> just trying out 12,1 on a DELL PowerEdge R710, and I see:
> ...
> Oct 16 22:52:12 store-08 kernel: bce3: bce_pulse(): Warning: bootcode thinks 
> driver is absent! (bc_state = 0x0023600E)
> Oct 16 22:52:13 store-08 kernel: Limiting icmp unreach response from 3244 to 
> 200 packets/sec
> Oct 16 22:52:13 store-08 kernel: bce3: bce_pulse(): Bootcode found the driver 
> pulse! (bc_state = 0x0003610E)
> Oct 17 06:04:29 store-08 kernel: Limiting icmp unreach response from 564 to 
> 200 packets/sec
> 
> there is nothing connected to bce3, only bce0, 
> rev is r353486, and it’s diskless.

Does it experience some disruption? If not, you may just ignore those.

> BTW: is there a way of knowing which port is being reported as unreachable? 

So many packets should be easily seen with net/trafshow or just tcpdump.

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

Re: pkg thinks kernel is old

[Eugene Grosbein]

11.10.2019 18:57, Bengt Ahlgren wrote:

>> Can you show the output of file /usr/bin/uname ?
> 
> $ uname -aKU
> FreeBSD P142.sics.se 11.3-STABLE FreeBSD 11.3-STABLE #9 r353280: Mon Oct  7 
> 22:16:02 CEST 2019 r...@p142.sics.se:/storage/obj/usr/src/sys/X250  amd64 
> 1103500 1103500
> 
> no signs of 1102509 there...
> 
> and "strings -a /usr/bin/uname |grep 110" returns nothing.

Do: "file /usr/bin/uname" and post output.


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

Re: Running iperf3 as a server drops all connections to a machine

[Eugene Grosbein]

30.09.2019 3:11, Pete French wrote:

> Its a bit worrying to me that this can happen, especially in userland.
> 
> Any opinions or things people would ike me to check ?

netstat -p tcp -ss
tcpdump -i $interface -npvs0 icmp or 'tcp[tcpflags] & (tcp-rst) != 0'

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

Re: extremely slow boot of RELENG_10

[Eugene Grosbein]

31.07.2019 22:30, mike tancsa wrote:

> While moving a pair of ZFS disks from an *very* old motherboard to a new
> one, I ran into an odd problem I had not seen before.  The box was
> running just fine RELENG_10 from FreeBSD 10.1-STABLE #18 r279918 on 10yr
> old MB. Boots normally and expected speeds for old hardware/CPU.  But on
> the new one, as soon as the |\-/|\ starts spinning, it looks like its
> 1/100th of the speed it should be.  Unfortunately, we didnt have the
> luxury to wait for it to boot up all the way.  We put the disks back in
> the old motherboard, did the RELENG_11 upgrade which included putting in
> the new boot blocks after zpool upgrade and then the disks booted just
> fine in the new box.  We at first thought it was a hardware issue, but
> same behaviour on another new MB, new SATA cables etc etc.
> 
> Any idea what was going on behind the scenes that might have caused it
> ?  Is there something about the way the old boot blocks would interact
> poorly with new motherboards (in this case, a SuperMicro X11SSH-F) ?

Maybe it attempted dual-console boot involving output to serial port...


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

Re: ZFS root mount regression

[Eugene Grosbein]

CC'ing Alexander Motin who comitted the change.

20.07.2019 1:21, Garrett Wollman wrote:

> I recently upgraded several file servers from 11.2 to 11.3.  All of
> them boot from a ZFS pool called "tank" (the data is in a different
> pool).  In a couple of instances (which caused me to have to take a
> late-evening 140-mile drive to the remote data center where they are
> located), the servers crashed at the root mount phase.  In one case,
> it bailed out with error 5 (I believe that's [EIO]) to the usual
> mountroot prompt.  In the second case, the kernel panicked instead.
> 
> The root cause (no pun intended) on both servers was a disk which was
> supplied by the vendor with a label on it that claimed to be part of
> the "tank" pool, and for some reason the 11.3 kernel was trying to
> mount that (faulted) pool rather than the real one.  The disks and
> pool configuration were unchanged from 11.2 (and probably 11.1 as
> well) so I am puzzled.
> 
> Other than laboriously running "zpool labelclear -f /dev/somedisk" for
> every piece of media that comes into my hands, is there anything else
> I could have done to avoid this?

Both 11.3-RELEASE announcement and Release Notes mention this:

> The ZFS filesystem has been updated to implement parallel mounting.

I strongly suggest reading Release documentation in case of troubles
after upgrade, at least. Or better, read *before* updating.

I guess this parallelism created some race for your case.

Unfortunately, a way to fall back to sequential mounting seems undocumented.
libzfs checks for ZFS_SERIAL_MOUNT environment variable to exist having any 
value.
I'm not sure how you set it for mounting root, maybe it will use kenv,
so try adding to /boot/loader.conf:

ZFS_SERIAL_MOUNT=1

Alexander should have more knowledge on this.

And of course, attaching unrelated device having label conflicting
with root pool is asking for trouble. Re-label it ASAP.

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

Re: Kernel panic in zfs code; 12-STABLE

[Eugene Grosbein]

19.07.2019 3:13, Karl Denninger wrote:

> FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019
> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP
> 
> Note -- no patches of any sort in the ZFS code; I am NOT running any of
> my former patch set.
> 
> NewFS.denninger.net dumped core - see /var/crash/vmcore.8
> 
> Thu Jul 18 15:02:54 CDT 2019
> 
> FreeBSD NewFS.denninger.net 12.0-STABLE FreeBSD 12.0-STABLE #2 r349024M:
> Thu Jun 13 18:01:16 CDT 2019
> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP  amd64
> 
> panic: double fault

[skip]

> #283 0x82748d91 in zio_vdev_io_done (zio=0xf8000b8b8000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3376
> #284 0x82744eac in zio_execute (zio=0xf8000b8b8000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1786
> #285 0x80c3b7f4 in taskqueue_run_locked (queue=0xf801a8b35100)
> at /usr/src/sys/kern/subr_taskqueue.c:467
> #286 0x80c3cb28 in taskqueue_thread_loop (arg=)
> at /usr/src/sys/kern/subr_taskqueue.c:773
> #287 0x80b9ab23 in fork_exit (
> callout=0x80c3ca90 ,
> arg=0xf801a0577520, frame=0xfe009d4edc00)
> at /usr/src/sys/kern/kern_fork.c:1063
> #288 0x810b367e in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:996
> #289 0x in ?? ()
> Current language:  auto; currently minimal
> (kgdb)

You have "double fault" and completely insane number of stack frames in the 
trace.
This is obviously infinite recursion resulting in kernel stack overflow and 
panic.

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

Re: fsck vs zvol

[Eugene Grosbein]

12.06.2019 12:17, O'Connor, Daniel wrote:

>>> The Samba 4 ZFS is from https://wiki.freebsd.org/Samba4ZFS (which I wrote..)

You should correct this page and change the line for /etc/fstab
and use non-zero value for fsck pass number.

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

Re: fsck vs zvol

[Eugene Grosbein]

12.06.2019 12:17, O'Connor, Daniel wrote:

>> Please show your /etc/fstab line for this UFS-inside-ZVOL and your changes 
>> to rc.d/fsck.
>> Your logs do not show that fsck is started so I presume some mistake in the 
>> /etc/fstab.
>> Maybe you forgot that it needs non-zero sixth field.
> 
> The fsck line is..
> /dev/zvol/zroot/samba4sysvol /var/db/samba4/sysvol ufs   rw,acls 0   0
> 
> The diff is just..
> --- fsck.orig 2019-06-12 14:43:03.279407000 +0930
> +++ fsck  2019-06-12 14:42:51.094142000 +0930
> @@ -24,6 +24,10 @@
>   # During fsck ignore SIGQUIT
>   trap : 3
> 
> + echo "Samba FS hack"
> + fsck -y /dev/zvol/zroot/samba4sysvol
> + err=$?
> +
>   check_startmsgs && echo "Starting file system checks:"
>   if checkyesno background_fsck; then
>   fsck -F -p
> 
> Oh I see for the passno field.. It must be non-zero it fsck won't check it at 
> all!

And you don't need to change /etc/rc.d/fsck script at all.


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

Re: fsck vs zvol

[Eugene Grosbein]

12.06.2019 8:04, O'Connor, Daniel wrote:

> Hi,
> I have a small UFS partition that is the sysvol for Samba 4 (otherwise it 
> doesn't work due to ACL issues).
> 
> I found that I usually have to manually fsck it on a bad reboot, even if I 
> have fsck_y_enable so I added a hack to /etc/rc.d/fsck to fsck -y that FS 
> before the normal fsck runs.
> 
> Logging looks like..
> 
> Jun 12 09:45:41 moo kernel: Setting hostuuid: 
> ----ac1f6b01103a.
> Jun 12 09:45:41 moo kernel: Setting hostid: 0x6cbfec5d.
> Jun 12 09:45:41 moo kernel: Starting file system checks:
> Jun 12 09:45:41 moo kernel: Mounting local filesystems:mount: 
> /dev/zvol/zroot/samba4sysvol: R/W mount of /var/db/samba4/sysvol denied. 
> Filesystem is not clean - run fsck.: Operation not permitted
> Jun 12 09:45:41 moo kernel: Mounting /etc/fstab filesystems failed, will 
> retry after root mount hold release
> Jun 12 09:45:41 moo kernel: mount: /dev/zvol/zroot/samba4sysvol: R/W mount of 
> /var/db/samba4/sysvol denied. Filesystem is not clean - run fsck.: Operation 
> not permitted
> Jun 12 09:45:41 moo kernel: .
> Jun 12 09:45:41 moo kernel: Mounting /etc/fstab filesystems failed, startup 
> aborted
> Jun 12 09:45:41 moo kernel: ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> 
> I'm not sure if marking this FS as 'late' would help (and/or break something 
> else..)
> 
> Has anyone else tried something like this?
> 
> The Samba 4 ZFS is from https://wiki.freebsd.org/Samba4ZFS (which I wrote..)

Please show your /etc/fstab line for this UFS-inside-ZVOL and your changes to 
rc.d/fsck.
Your logs do not show that fsck is started so I presume some mistake in the 
/etc/fstab.
Maybe you forgot that it needs non-zero sixth field.



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

Re: Gmirror and bigger disks (growfs)

[Eugene Grosbein]

01.06.2019 19:57, Eugene Grosbein wrote:

> 01.06.2019 19:04, Nenhum_de_Nos wrotr:
>> Hi,
>>
>> I replaced a faulty disk from a gmirror some time ago. The array had two
>> 1TB disks and I got one 2TB disk there. Now I replaced the second one and
>> tried to growfs it. No good for me.
> 
> First you need to resize the mirror itself with "gmirror resize" command.
> Refer to gmirror(8) manual page for details.

As you use GPT that keeps copy of its data at the end of the "device",
you also need to reconfigure GPT with "gpart recover" after increasing of the 
mirror.

> Then you need to resize last slice or create new slice for available space.
> If you prefer resize existing slice, use "gpart resize".
> 
> Only then you will be able to run growfs to utilise new space for file system 
> inside the slice.

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

Re: Gmirror and bigger disks (growfs)

[Eugene Grosbein]

01.06.2019 19:04, Nenhum_de_Nos wrotr:
> Hi,
> 
> I replaced a faulty disk from a gmirror some time ago. The array had two
> 1TB disks and I got one 2TB disk there. Now I replaced the second one and
> tried to growfs it. No good for me.

First you need to resize the mirror itself with "gmirror resize" command.
Refer to gmirror(8) manual page for details.

Then you need to resize last slice or create new slice for available space.
If you prefer resize existing slice, use "gpart resize".

Only then you will be able to run growfs to utilise new space for file system 
inside the slice.

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

Re: trying to expand a zvol-backed bhyve guest which is UFS

[Eugene Grosbein]

20.05.2019 9:14, Freddie Cash wrote:

> On Sun, May 19, 2019, 6:59 PM Paul Mather,  wrote:
> 
>> On May 19, 2019, at 9:46 PM, tech-lists  wrote:
>>
>>> Hi,
>>>
>>> context is 12-stable, zfs, bhyve
>>>
>>> I have a zvol-backed bhyve guest. Its zvol size was initially 512GB
>>> It needed to be expanded to 4TB. That worked fine.
>>>
>>> The problem is the freebsd guest is UFS and I can't seem to make it see
>>> the new size. But zfs list -o size on the host shows that as far as zfs
>> is
>>> concerned, it's 4TB
>>>
>>> On the guest, I've tried running growfs / but it says requested size is
>>> the same as the size it already is (508GB)
>>>
>>> gpart show on the guest has the following
>>>
>>> # gpart show
>>> =>63  4294967232  vtbd0  MBR  (4.0T)
>>>  63   1 - free -  (512B)
>>>  64  4294967216  1  freebsd  [active]  (2.0T)
>>> 4294967280  15 - free -  (7.5K)
>>>
>>> => 0  4294967216  vtbd0s1  BSD  (2.0T)
>>>   0  10653532161  freebsd-ufs (508G)
>>>  1065353216 83885442  freebsd-swap  (4.0G)
>>>  1073741760  3221225456   - free -  (1.5T)
>>>
>>> I'm not understanding the double output, or why growfs hasn't worked on
>>> the guest ufs. Can anyone help please?
>>
>>
>> Given the above, the freebsd-ufs partition can't grow because there is a
>> freebsd-swap partition between it and the free space you've added at the
>> end of the volume.
>>
>> You'd need to delete the swap partition (or otherwise move it to the end
>> of
>> the partition on the volume) before you could successfully growfs the
>> freebsd-ufs partition.
>>
> 
> Even if you do all that, you won't be able to use more than 2 TB anyway, as
> that's all MBR supports.
> 
> If you need more than 2 TB, you'll need to backup, repartition with GPT,
> and restore from backups.

Strictly speaking, FreeBSD is capable of using over 2TB "disk" with MBR.
And there are multiple ways to achieve that. Simplies one is to boot one time
using another root file system (mdconfig'ed image, iSCSI or just another local 
media)
and use "graid label -S" for large media to create GRAID "Promise" array with 
two SINGLE volumes.
First volume should span over boot/root partion in the MBR and then
instead of /dev/vtb0s1 it will be shown like /dev/raid/r0s1. No existing data 
will be lost
if there are two 512b blocks free at the end of media for GRAID label.

Second volume should span over rest of space and can be arbitrary large
as GRAID uses 64 bit numbers. It may be seen as /dev/raid/r1 then.

You may then just "newfs /dev/raid/r1" or put BSD label on it beforehand
or use this "device" for new ZFS pool etc.

There is also GEOM_MAP capable of similar things but it is less convenient.

But, if your boot environment supports GPT, it is easier to use GPT.

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

Re: route based ipsec

[Eugene Grosbein]

08.05.2019 3:23, KOT MATPOCKuH wrote:

> I'm misunderstand what in my configuration can result core dumps a running
> daemon...
> I'm attached a sample racoon.conf. Can You check for possible problems?
> Also on one host I got a crash in another function:
> (gdb) bt
> #0  0x0024717f in privsep_init ()
> #1  0x002375f4 in inscontacted ()
> #2  0x002337d0 in isakmp_plist_set_all ()
> #3  0x0023210d in isakmp_ph2expire ()
> #4  0x0023162a in isakmp_ph1delete ()
> #5  0x0023110b in isakmp_ph2resend ()
> #6  0x0008002aa000 in ?? ()
> #7  0x in ?? ()

I guess configuration using certificates is not tested enough.
It works stable for me but I use psk only.

You need to fix code yourself or stop using racoon with certificates.

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

Re: about zfs and ashift and changing ashift on existing zpool

[Eugene Grosbein]

09.04.2019 7:00, Kevin P. Neal wrote:

>> My guess (given that only ada1 is reporting a blocksize mismatch) is that
>> your disks reported a 512B native blocksize.  In the absence of any override,
>> ZFS will then build an ashift=9 pool.

[skip]

> smartctl 7.0 2018-12-30 r4883 [FreeBSD 11.2-RELEASE-p4 amd64] (local build)
> Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Vendor:   SEAGATE
> Product:  ST2400MM0129
> Revision: C003
> Compliance:   SPC-4
> User Capacity:2,400,476,553,216 bytes [2.40 TB]
> Logical block size:   512 bytes
> Physical block size:  4096 bytes

Maybe it't time to prefer "Physical block size" over "Logical block size" in 
relevant GEOMs
like GEOM_DISK, so upper levels such as ZFS would do the right thing 
automatically.


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

Re: ipsec/gif(4) tunnel not working: traffic not appearing on the gif(4) interface after deciphering

[Eugene Grosbein]

26.03.2019 14:26, Eugene M. Zheganin wrote:

> I have a FreeBSD 11.1 box with 2 public IPs that has two tunnels to another 
> FreeBSD box with 1 public IP. One of these tunnels is working, the other 
> isn't. Long story short: I have some experience in ipsec tunnels setup. and I 
> supposed that have configured everything properly, and to illustrate this 
> I've loaded if_enc(4) on the 11.1 and it does show the traffic for the second 
> gif:

[skip]

> Any ideas ?

Always add "link2" to ifconfig_gifX configuration in such cases:

ifconfig_gif0="inet 192.168.254.25 192.168.254.26 netmask 255.255.255.252 mtu 
1500 link2"

Refer to gif(4) manual page for details, look for IFF_LINK2 description.

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

Re: hw.vga.acpi_ignore_no_vga=1 for installation media

[Eugene Grosbein]

18.03.2019 17:22, Konstantin Belousov wrote:

> That said, did anybody considered ignoring NO_VGA FACP flag on Silvermonts
> only ?  Or even better, gather SMBIOS identifications for affected BIOSes
> and ignore the flag for them ?

Is SMBIOS-bases blacklisting reliable considering future BIOS updates 
(including pre-installed)?

When it comes to human-managed interactive installation, it seems for me more 
reliable
to check real functions of VGA and ACPI flag than collecting black list.

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

Re: hw.vga.acpi_ignore_no_vga=1 for installation media

[Eugene Grosbein]

18.03.2019 0:34, Konstantin Belousov wrote:

> Can anybody provide an example of machine where the flag is set but VGA
> works ?  For me, it is set on headless NUC when there is no monitor
> attached, and then BIOS does not configure framebuffer at all.

http://freebsd.1045724.x6.nabble.com/vt-4-related-hang-of-11-2-td6299125.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229235

> > So the proposal is about reversing the set of broken machines, but only
> in installer ?  In other words, if it worked for installer, the installed
> system would be broken (again) ?

VGA-based installation session won't event start unless this is fixed.

It should be easy to make installer generate the knob for target machine
if installer sees wrong ACPI flag with working VGA hardware.

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

Re: Observations from a ZFS reorganization on 12-STABLE

[Eugene Grosbein]

17.03.2019 21:58, Karl Denninger wrote:

> Huh?  A simple *filesystem copy* managed to force a 16Gb system into
> requiring page file backing store?
> 
> I was able to complete the copy by temporarily adding the swap space
> back on (where it would be when the move was complete) but that
> requirement is pure insanity and it appears, from what I was able to
> determine, that it came about from the same root cause that's been
> plaguing VM/ZFS interaction since 2014 when I started work this issue --
> specifically, when RAM gets low rather than evict ARC (or clean up UMA
> that is allocated but unused) the system will attempt to page out
> working set.  In this case since it couldn't page out working set since
> there was nowhere to page it to the process involved got an OOM error
> and was terminated.
> 
> *I continue to argue that this decision is ALWAYS wrong.*

I agree. Recently I've found kind-of-workaround for this problem:
increase vm.v_free_min so when "FREE" memory goes low,
page daemon wakes earlier and shrinks UMA (and ZFS ARC too) moving some memory
from WIRED to FREE quick enough so it can be re-used before bad things happen.

But avoid increasing vm.v_free_min too much (e.g. over 1/4 of total RAM)
because kernel may start behaving strange. For 16Gb system it should be enough
to raise vm.v_free_min upto 262144 (1GB) or 131072 (512M).

This is not permanent solution in any way but it really helps.

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

hw.vga.acpi_ignore_no_vga=1 for installation media

[Eugene Grosbein]

Hi!

Since 11.2-RELESE, default console driver vt(4) checks ACPI table for presence 
of VGA in the system.
It does not initialize console (no input, no output) if ACPI states there is no 
VGA adapter.

There are PRs describing many cases when VGA is present but ACPI lies
and we have a regression compared with 11.1 and earlier:
FreeBSD cannot be installed interactively onto such a system, leaving aside 
serial console.

vt(4) has loader knob to restore pre-11.2 behaviour and ignore ACPI:

hw.vga.acpi_ignore_no_vga=1

Should we add this unconditionally to the installation media designed for 
interactive VGA-based installation?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: source upgrade FBSD10 -> 11 (then 12)

[Eugene Grosbein]

28.02.2019 23:18, Lee Damon wrote:

> I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do this 
> by building a new box with the latest OS then migrating services and data. 
> Unfortunately I don't have that option this time, the upgrade has to happen 
> in-place. My plan is to go from 10 to 11 then from 11 to 12.
> 
> I was looking at the "Upgrading FreeBSD" part of 
> https://www.freebsd.org/releases/11.1R/installation.html#upgrade but 
> unfortunately it seems to be missing a critical URL or two:
> 
> "The procedure for doing a source code based update is described in and ."
> 
> I tracked down where I think it points and the instructions appear to be just 
> for same-version updates. Can I safely move /usr/src out of the way then 
> check out the stable/11 and compile/install it or are there other things I 
> need to do?

I did source upgrade from 10.3-STABLE to 11.2-STABLE multiple times with no 
problems.

Keep in mind that you should not try source upgrade from 10.2 or earlier 
without test try first in lab
because it might work but not supported. Better safe than sorry and first 
update FreeBSD10 system
to 10.3-STABLE (if not yet) and only then update to 11.2-STABLE.


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