Re: FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"

[Kubilay Kocak]

On 30/03/2021 8:52 am, Rick Macklem wrote:

Hi,

The FreeBSD NFS server is broken when handling multiple
connections for NFSv4.1/4.2.


Whats the version scope for this issue? If a regression in 12.x 13.x, 
adding to RELNOTES and ERRATA would be great



It incorrectly binds the back channel to a new connection
when is sees an RPC with Sequence in it (almost all RPCs)
and might send a callback on the wrong connection.

I have a fix, but it won't be in a release until 12.3/13.1.
It can be found in Bugzilla PR#254560.

In the meantime, avoid using the "nconnects" option
on Linux client mounts.

Thanks go to Ben Coddington @redhat for diagnosing
this and testing the patch.

Sorry about the breakage, rick
ps: It was done intentionally long ago, when clients
   did not do BindConnectionToSession and then slipped
   through the cracks.



___
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

[Kubilay Kocak]

On 29/03/2020 5:53 am, Andrea Brancatelli via freebsd-stable wrote:

Hello everybody,

I'm not very sure this is the correct place to ask, in case it's not
please point me to the correct place.


If the systems are running *-STABLE branches, perhaps, but freebsd-net 
may be better



 From time to time my BSNMPD instance randomly crash without any apparent
reason.

It happens on different machines and different FreeBSD releases. It
happened tonight as well on one of our servers. Usually I just delete
the bsnpmd.core file and restart the service, but I thought there may be
someone interested in looking at the core to understand what the reason
may be?

The bsnmpd daemon is in a private network so malicious stuff is not the
case, and is used by a central Cacti instance to do usual graphs to
monitor cpus, disks, memory, lan cards and whatever.

The servers usually have high uptimes and quite solid network traffic.
The core file is 1.3GB with seems pretty a lot to me, so maybe it died
because it's leaking memory?

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



Hi Andrea,

Can you obtain a backtrace? If so, please include it as an attachment

Can you post your snmp config (sanitized if necessary) ?

Do any of these look relevant?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221487
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233431
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152259
___
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: Wrong architecture: FreeBSD:12.0:amd64 instead of FreeBSD:12:amd64

[Kubilay Kocak]

On 3/03/2020 10:56 am, Freddie Cash wrote:

On Mon, Mar 2, 2020 at 3:49 PM Antoine Michard 
wrote:


Hi all,

I just connect to my server this evening for pkg update task and I've got
this:
# pkg update
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 916 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.5MB/s 00:01
Processing entries: 63%
pkg: wrong architecture: FreeBSD:12.0:amd64 instead of FreeBSD:12:amd64
pkg: repository FreeBSD contains packages with wrong ABI:
FreeBSD:12.0:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!



It's not your system.  There's an issue with the package building cluster
that's putting the wrong version number (12.0 instead of 12) into the
architecture string.

It's a known issue, they're working on it, we just need to be patient while
they fix it.  :)

(Although, all previous mentions of this were regarding 13.0; this is the
first time I've seen the issue with 12.0 come across the mailing lists.)



Issue tracked in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549
___
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: No amdtemp sysctls, AMD Ryzen 5 3600X

[Kubilay Kocak]

On 15/11/2019 3:27 am, Mark Martinec wrote:

Running 12.1-RELEASE-p1 on AMD Ryzen 5 3600X cpu,
but I don't see any temperatures reported in sysctl,
even though amdtemp.ko and amdsmn.ko are loaded
and they don't produce any complaints on loading.

   $ kldstat | fgrep amd
   27    1 0x82f3 1458 amdtemp.ko
   28    1 0x82f32000  808 amdsmn.ko

   $ sysctl -a | grep -i tempe
   $

   $ sysctl dev.amdtemp
   sysctl: unknown oid 'dev.amdtemp'
   $

Nov 13 12:07:27 xxx kernel: CPU: AMD Ryzen 5 3600X 6-Core Processor 
(4100.09-MHz K8-class CPU)
Nov 13 12:07:27 xxx kernel:   Origin="AuthenticAMD"  Id=0x870f10 
Family=0x17  Model=0x71  Stepping=0



Motherboard is an ASUS with X570 chipset, latest BIOS.
No obvious errors are reported during booting.

Any additional information that I can provide?
Any suggestions?

   Mark


Resolver of original Ryzen 2 temperature support:

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

"In Progress" issue for Ryzen 5 support with patch:

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

Was committed to head (CURRENT), apparently merged to stable/12 (cant 
find the MFC commit).


I've updated/retriaged the issue, and asked about a merge to stable/11, 
but at this point it looks like it missed the 12.1-RELEASE window

___
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: syslogd truncating messages on FreeBSD >11.2-R

[Kubilay Kocak]

On 9/11/2019 2:08 pm, Scott wrote:

Hi,

please let me know if there is a better forum for this.

As of 11.3-RELEASE syslogd truncates all forwarded messages to 480 bytes for
IPV4 and 1180 for IPv6.

The change occurs in the added code:

 switch (f->f_type) {
 case F_FORW:
 /* Truncate messages to RFC 5426 recommended size. */
 dprintf(" %s", f->fu_forw_hname);
 switch (f->fu_forw_addr->ai_addr->sa_family) {
#ifdef INET
 case AF_INET:
 dprintf(":%d\n",
 
ntohs(satosin(f->fu_forw_addr->ai_addr)->sin_port));
 iovlist_truncate(il, 480);
 break;
#endif

There's more code for IPv6 and the function iovlist_truncate itself.

This change is not turned on by a switch and happens automatically, however I
can't find it documented in UPDATING or the release notes.  I would have
thought that any change in default behaviour of the system should at least be
documented.

Ideally this change would have been implemented via a switch given that the
RFC mentioned in the code (RFC 5426) does not mandate truncation, but
recommends it when the network MTU is not known.

What's the best way to reach out to the maintainer to suggest a switch to
turn on this code?

Thanks,
Scott



Hi Scott,

Looks like this came in in base r332510 [1] via:

https://reviews.freebsd.org/D15011

The commit log message and review history may provide additional context 
for the behaviour change (I haven't reviewed them)


I have CC'd the committer on this email, but in the meantime, and if you 
wouldn't mind, it is worth reporting the issue via Bugzilla, so that we 
track it, and so others can find it.


[1] https://svnweb.freebsd.org/changeset/base/332510

--
Regards,

koobs



___
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: suspend resume broken on 12.1-BETA1?

[Kubilay Kocak]

On 24/09/2019 1:38 pm, Pete Wright wrote:
i've got an amd64 laptop which while running stable had no issues with 
suspend/resume.  after upgrading to beta1 yesterday the system hangs on 
resume.  its a hard hang on resume, can't SSH in and nothing gets into 
the logs.


i've been able to reproduce both with the i915kms module loaded, as well 
as with it *not* loaded.  has anyone else been able to reproduce this?


cheers,
-pete



Could be:

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

If your hardware is different please include /var/run/dmesg.boot and 
pciconf -lv output as an attachment


It would be handy to know what stable/12 revision you were on before 
(that's *the* open question on that issue)


___
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 on 12-STABLE-r348203 amd64

[Kubilay Kocak]

On 6/06/2019 5:04 am, Mark Saad wrote:

On Wed, Jun 5, 2019 at 2:42 PM Mark Saad  wrote:


On Wed, Jun 5, 2019 at 12:29 PM Mark Saad  wrote:


All
  I was wondering if anyone could shed some light on this boot panic I
saw yesterday. This is on a Dell R630 with Bios 2.9.1  booting
12.0-STABLE-r348203 amd64.
I reverted this back to 12.0-RELEASE-p4 and its fine .

The only custom options I had were in loader.conf

kern.geom.label.gptid.enable="0"
ipmi_load="YES"
boot_multicons="YES"
boot_serial="YES"
console="comconsole,vidconsole"
net.inet.tcp.tso="0"
cc_htcp_load="YES"
autoboot_delay="5"
hw.mfi.mrsas_enable="1"
hw.usb.no_pf="1"# Disable USB packet filtering
hw.usb.no_shutdown_wait="1"
hw.vga.textmode="1" # Text mode
machdep.hyperthreading_allowed="0"

Any ideas ?

Screen shot here
https://imgur.com/a/nGvHtIs

--
mark saad | nones...@longcount.org


Plain text version of the crash

Loading kernel...
/boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80
syms=[0x8+0x1778e8+0x8   /
+0x194f1d]
Loading configured modules...
/boot/kernel/ipmi.ko size 0x11e10 at 0x2645000
loading required module 'smbus'
/boot/kernel/smbus.ko size 0x2ef0 at 0x2657000
/boot/entropy size=0x1000
/boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000
---<>---c_hmodule 'smbus'
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-STABLE r348693 GENERIC amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
LLVM 8.0.0)
panic: UMA zone "UMA Zones": Increase vm.boot_pages
cpuid = 0
time = 1
KDB: stack backtrace:
#0 0x80c16df7 at ??+0
#1 0x80bcaccd at ??+0
#2 0x80bcab23 at ??+0
#3 0x80f0b03c at ??+0
#4 0x80f08d8d at ??+0
#5 0x80f0bb3d at ??+0
#6 0x80f0b301 at ??+0
#7 0x80f0b3d1 at ??+0
#8 0x80f066c4 at ??+0
#9 0x80f0543f at ??+0
#10 0x80f23aef at ??+0
#11 0x80f1133b at ??+0
#12 0x80b619c8 at ??+0
#13 0x8036a02c at ??+0
Uptime: 1s


Also increasing the vm.boot_pages to 128 in the loader works. Anyone
know why ? This box has 64G ram.

--
mark saad | nones...@longcount.org


So after some poking in the bios this has to do with how the Dell NUMA
options are set. If the system is set Cluster On Die mode, you get a
kernel panic
Home Snoop or Early Snoop no issue.




Hi Mark,

Could you report this bug (Bugzilla) if you haven't already, providing:

- exact freebsd version(s) reproducible with
- panic/backtrace output as an attachment. Ideally with a debug kernel
- /var/run/dmesg.boot output (as an attachment) in a verbose boot
- if you can test a current snapshot, that would be great
- any other system information you believe might be helpful in isolating 
root cause(s) or potential fixes


Thanks!
Feel free to CC me on 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: Benchmarks results for FreeBSD 11

[Kubilay Kocak]

On Mon, 22 Aug 2016, 11:31 AM Mark Linimon  wrote:

> On Mon, Aug 22, 2016 at 09:57:24AM +1000, Dewayne Geraghty wrote:
> > unless knowledgable people respond publicly and/or in the phoronix
> > forums [...] this interpretation of reality will be fixed in decision-
> > makers' minds and consequently the uptake (and support) of FreeBSD.
>
> IIRC this has been done before and hasn't really been productive.  OTOH
> I don't recall the details.
>
> FreeBSD hasn't had a benchmarking guru since Kris Kennaway retired from
> working on FreeBSD.


Michael has reached out off-list (thanks!) If anyone else is interested,
I'd be happy to create a dedicated IRC channel on freenode to widen and
focus the freebsd performance discussion net and doc any outcomes/notes in
the FreeBSD Wiki.

./koobs
___
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: Benchmarks results for FreeBSD 11

[Kubilay Kocak]

On 19/08/2016 9:34 AM, Erich Dollansky wrote:
> Hi,
> 
> I am sure that some know of this site:
> 
> http://www.phoronix.com/scan.php?page=article=2bsd-7linux-bench=4
>
>  I wonder about the results for FreeBSD. As I do not have 11 on my 
> machines, a stupid question. Are there still some debugging aids 
> enabled in 11?

They're off in those versions, but did note compiler (and compiler args)
differences between within most tests (See attachments) as you mentioned.


> I know that some of the results are caused by the use of CLang and
> some of the results test applications/compilers and not operating
> systems.

gcc/clang tests and defaults in upstream build systems are almost
certainly contributors. At a minimum it would be nice to see an attempt
to standardise (force) compiler args across all OS runs for the same
test, even if this doesn't prove to be perfect.

Separating or adding tests for the same tests using non-default
compilers (in particular latest GCC versions from ports) so they match
across OS's would also be valuable.

At a minimum it would be worth Michael highlighting the differences, and
ideally removing these variables from the tests, even if they aren't
default configurations. Though a test of out of the box configurations
is still valuable, it can serve to muddy the underlying differences and
make them tougher to isolate.
___
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: [Bug 211491] System hangs after "Uptime" on reboot with iSCSI, zfs, and altroot

[Kubilay Kocak]

On 11/08/2016 1:14 AM, Eric van Gyzen wrote:
> On 08/09/16 06:10 PM, bugzilla-nore...@freebsd.org wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211491
>>
>> --- Comment #13 from Ngie Cooper  ---
>> Please don't add -current or -stable to bugs like this; it spams the list
>> unnecessarily (this issue impacts users of iSCSI + ZFS -- which seems a bit
>> niche right now)
> 
> I'm sorry that some people were annoyed, although I wouldn't call it
> spam.  It's a discussion of a bug that affects -STABLE, so stable@ is
> appropriate.
> 
> Furthermore, it's a new regression that will go into 11.0-RELEASE, so
> getting some attention is a good thing.  I imagine this is why koobs@
> CC'd stable@.

It was the original reporter CC'd, I added mfc-stable{10,11} flags in
case the issue was in those branches.

I'm very careful with cc'ing lists for src/base issues unless SNR is
very high, high impact or it needs eyes now.

> I thought it was limited to iSCSI, so I put that in the summary.
> However, we now know that it is not limited to iSCSI.  I just updated
> the summary accordingly.
> 
> Cheers,
> 
> Eric

___
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: FreeBSD 11.0-BETA2 won't boot on an Acer Aspire 5560

[Kubilay Kocak]

On 27/07/2016 7:22 PM, Peter Jeremy wrote:
> I'm trying to boot the 11.0-BETA2/amd64 memory stick image and the
> kernel panics: (Following copied by hand):
> 
> ACPI APIC Table: 
> ...
> acpi0:  on motherboard
> ACPI Error: Hardware did not change modes (20160527/hwacpi-160)
> ACPI Error: Could not transition to APCI mode (20160527/evxfevnt-105)
> ACPI Warning: AcpiEnable failed (20160527/utxfinit-184)
> acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE
> device_attach: acpi0 attach returned 6
> 
> Followed by a NULL dereference panic at nexus_acpi_attach+0x89
> 
> The system boots a 10.0-RELEASE/amd64 memstick (the only other image I
> have conveniently to date) without problem.
> 

Thank you for the report Peter

Did it boot prior to 11.0-BETA2? ie; is it a regression?

Please report a bug in bugzilla with version: 11.0-BETA2 and cc
r...@freebsd.org

If it's possible to obtain a backtrace of the panic, please include it
as an attachment:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

Setting debug.debugger_on_panic=1 in loader may help get it to the debugger.


___
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: FreeBSD 11.0-BETA2 Now Available

[Kubilay Kocak]

On 25/07/2016 5:25 AM, Glen Barber wrote:
> The second BETA build of the 11.0-RELEASE release cycle is now
> available.

11.0-BETA2 version added to Bugzilla for bug reports/regression/etc

Bugs marked 11.0-BETA1 that are unresolved [1] should be updated to
11.0-BETA2

[1]
https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=New_status=Open_status=In%20Progress_id=127434=Base%20System_format=advanced=11.0-BETA1


> Installation images are available for:
> 
> o 11.0-BETA2 amd64 GENERIC
> o 11.0-BETA2 i386 GENERIC
> o 11.0-BETA2 powerpc GENERIC
> o 11.0-BETA2 powerpc64 GENERIC64
> o 11.0-BETA2 sparc64 GENERIC
> o 11.0-BETA2 armv6 BANANAPI
> o 11.0-BETA2 armv6 BEAGLEBONE
> o 11.0-BETA2 armv6 CUBIEBOARD
> o 11.0-BETA2 armv6 CUBIEBOARD2
> o 11.0-BETA2 armv6 CUBOX-HUMMINGBOARD
> o 11.0-BETA2 armv6 GUMSTIX
> o 11.0-BETA2 armv6 RPI-B
> o 11.0-BETA2 armv6 RPI2
> o 11.0-BETA2 armv6 PANDABOARD
> o 11.0-BETA2 armv6 WANDBOARD
> o 11.0-BETA2 aarch64 GENERIC
> 
> Note regarding arm/armv6 images: For convenience for those without
> console access to the system, a freebsd user with a password of
> freebsd is available by default for ssh(1) access.  Additionally,
> the root user password is set to root, which it is strongly
> recommended to change the password for both users after gaining
> access to the system.
> 
> Installer images and memory stick images are available here:
> 
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/
> 
> The image checksums follow at the end of this e-mail.
> 
> If you notice problems you can report them through the Bugzilla PR
> system or on the -stable mailing list.
> 
> If you would like to use SVN to do a source based update of an existing
> system, use the "stable/11" branch.
> 
> A summary of changes since 11.0-BETA1 includes:
> 
> o Several build-/toolchain-related fixes.
> 
> o WITNESS and INVARIANTS have been disabled on powerpc/powerpc64 and
>   arm/armv6 architectures.
> 
> o freebsd-update(8) has been updated to allow '*-dbg' distribution sets.
> 
> o ctld(8) no longer exits when reloading the configuration with invalid
>   initiator-portal clauses.
> 
> o GENERIC-NODEBUG kernel configurations have been removed.
> 
> o The callout code has been updated to avoid a system panic with TCP
>   timers.
> 
> o Several other changes.
> 
> A list of changes since 10.0-RELEASE are available on the stable/11
> release notes:
> 
> https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html
> 
> Please note, the release notes page is not yet complete, and will be
> updated on an ongoing basis as the 11.0-RELEASE cycle progresses.
> 
> === Virtual Machine Disk Images ===
> 
> VM disk images are available for the amd64 and i386 architectures.
> Disk images may be downloaded from the following URL (or any of the
> FreeBSD FTP mirrors):
> 
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-BETA2/
> 
> The partition layout is:
> 
> ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
> ~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
> ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)
> 
> The disk images are available in QCOW2, VHD, VMDK, and raw disk image
> formats.  The image download size is approximately 135 MB and 165 MB
> respectively (amd64/i386), decompressing to a 21 GB sparse image.
> 
> Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
> loader file is needed for qemu-system-aarch64 to be able to boot the
> virtual machine images.  See this page for more information:
> 
> https://wiki.freebsd.org/arm64/QEMU
> 
> To boot the VM image, run:
> 
> % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
>   -bios QEMU_EFI.fd -serial telnet::,server -nographic \
>   -drive if=none,file=VMDISK,id=hd0 \
>   -device virtio-blk-device,drive=hd0 \
>   -device virtio-net-device,netdev=net0 \
>   -netdev user,id=net0
> 
> Be sure to replace "VMDISK" with the path to the virtual machine image.
> 
> === Amazon EC2 AMI Images ===
> 
> FreeBSD/amd64 EC2 AMIs are available in the following regions:
> 
>  us-east-1 region: ami-684bc37f
>  us-west-1 region: ami-2592d345
>  us-west-2 region: ami-210cc041
>  sa-east-1 region: ami-511b8f3d
>  eu-west-1 region: ami-3d12704e
>  eu-central-1 region: ami-92f80cfd
>  ap-northeast-1 region: ami-355ba354
>  ap-northeast-2 region: ami-edef2583
>  ap-southeast-1 region: ami-789d421b
>  ap-southeast-2 region: ami-1a81ab79
> 
> === Vagrant Images ===
> 
> FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
> be installed by running:
> 
> % vagrant init freebsd/FreeBSD-11.0-BETA2
> % vagrant up
> 
> Note to freebsd-update(8) consumers: An EN for earlier FreeBSD releases
> is required before upgrading to 11.0-BETA2 will work properly, so it is
> advised to wait until the ENs are published before attempting an upgrade
> via freebsd-update(8).
> 
> == ISO CHECKSUMS ==
> 
> o 11.0-BETA2 amd64 GENERIC:
>   

Re: 10.3-BETA2 panic on boot with GCE NVMe

[Kubilay Kocak]

On 23/02/2016 3:35 AM, Andy Carrel via freebsd-stable wrote:
> I've created a 10.3-BETA2 image for Google Compute Engine using swills'
> script and am getting a panic on boot when the VM is configured with Local
> SSD as NVMe (--local-ssd interface="NVME"). This is a regression from
> 10.2-RELEASE which will boot successfully with an identical configuration.
> 
> """
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x60
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80e16019
> stack pointer= 0x28:0xfe01bfff59c0
> frame pointer= 0x28:0xfe01bfff59e0
> 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 = 12 (irq11: virtio_pci0+)
> [ thread pid 12 tid 100039 ]
> Stopped at  nvme_ctrlr_intx_handler+0x39:   cmpq$0,0x60(%rdi)
> db> bt
> Tracing pid 12 tid 100039 td 0xf8000422e000
> nvme_ctrlr_intx_handler() at nvme_ctrlr_intx_handler+0x39/frame
> 0xfe01bfff59e0
> intr_event_execute_handlers() at intr_event_execute_handlers+0xab/frame
> 0xfe01bfff5a20
> ithread_loop() at ithread_loop+0x96/frame 0xfe01bfff5a70
> fork_exit() at fork_exit+0x9a/frame 0xfe01bfff5ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe01bfff5ab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> """

Hi Andy,

Could you please create a Bugzilla issue for this.

I've created a '10.3-BETA2' version so it can be tracked

--
Regards

Kubilay
Bugmeister

___
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: Merging r286233 to stable/10?

[Kubilay Kocak]

On 8/11/2015 12:48 AM, Luigi Rizzo wrote:
> Request to all: would you mind a brief English summary with this kind of
> requests? It would attract relevant people's attention much more than a
> commit id.

Yep, this and ideally a Bugzilla issue reference so mfc-stableX flag can
be set on the issue, and re-opened if necessary getting the relevant
original committers attention

> Cheers
> Luigi
> 
> On Saturday, November 7, 2015, Trond Endrestøl <
> trond.endres...@fagskolen.gjovik.no> wrote:
> 
>> Hi,
>>
>> Would someone please consider merging r286233 to stable/10?
>>

___
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: Merging r286233 to stable/10?

[Kubilay Kocak]

On 7/11/2015 10:58 PM, Trond Endrestøl wrote:
> Hi,
> 
> Would someone please consider merging r286233 to stable/10?
> 

cc'ing original committer :)
___
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: Bug 201072

[Kubilay Kocak]

On 29/06/2015 8:18 PM, Kimmo Paasiala wrote:
 It looks like the atf directories were removed from /etc/mtree/* in:
 
 https://svnweb.freebsd.org/base?view=revisionrevision=260024
 
 They were later put back in this commit:
 
 https://svnweb.freebsd.org/base?view=revisionrevision=277457
 
 My patch is not valid apparently because it would break the tests
 stuff again, I had no idea how complex the issue was...

Hi Kimmo, thanks for the report :)

Please add your comment to the issue, I have triaged it and cc'd our
testing gurus who can hopefully help

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

Re: VirtualBox hangs on FreeBSD 10-stable and then reports error

[Kubilay Kocak]

On 13/05/2015 10:57 PM, Graham Menhennitt wrote:
 I've been successfully running VirtualBox for some time. Last week I
 updated my /usr/src/ and /usr/ports, built  installed world and kernel,
 and did portupgrade -a. Now VirtualBox won't start - it doesn't even
 show the window with the list of VMs. I've tried as root and as myself.
 I've also tried removing my .virtualbox directory. kldstat shows
 vboxdrv.ko is loaded. I've rebooted after building and installing
 everything.
 
 I've run it in truss as root and the bzipped output file is at
 http://menhennitt.com.au/truss.bz2. It runs for a few seconds and then
 gets to the point in the truss output (around line 2890) where it does
 the stuff shown below. It repeats the last poll() line at 5 second
 intervals for about 5 minutes. It then shows a dialog:
 Failed to create the VirtualBox COM object.
 The application will now terminate.
 Callee RC: NS_ERROR_FACTORY_NOT_REGISTERED (0x80040154)
 When I click Ok in the dialog, it exits.
 
 It's virtualbox-ose-4.3.26 and virtualbox-ose-kmod-4.3.26 on FreeBSD
 10-stable from last week on amd64.
 
 Does anybody please have any clues?
 
 Thanks,
 Graham

Hi Graham, you may also want to try the freebsd-emulation list and
#freebsd-vbox on IRC [1]

[1] https://wiki.freebsd.org/VirtualBox
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ports/base ntpd rc.d script with WITHOUT_NTP=yes

[Kubilay Kocak]

On 9/04/2015 2:48 AM, Matt Smith wrote:
 Hi,
 
 I just upgraded my server to 10.1-STABLE r281264 and when I ran
 mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to
 delete it. It's never done this before. I've figured out it's because I
 have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the
 ports version of ntpd and thus wanted to remove the base installed
 version so that when I run commands like ntpq it's using my possibly
 newer port installed version and not the older one.
 
 However, the port version doesn't have its own rc script. It usually
 uses the base version with ntpd_program and ntpd_config set.  With this
 latest change it means I have to have the base version installed again. 
 Is it possible to get the port version to have its own rc script?
 

Hi Matt,

It is certainly *possible*, and best addressed with an enhancement
request (via Bugzilla) to the NTP port maintainer, who I've CC'd here.

I like the idea as it improves user experience, removes a POLA
violation, and further decouples ports/pkg from base (which we like)

./koobs


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

Re: Problems with openssl 1.0.2 update

[Kubilay Kocak]

On 24/03/2015 12:53 AM, Gerhard Schmidt wrote:
 On 23.03.2015 14:17, Mike Tancsa wrote:
 On 3/23/2015 6:33 AM, Gerhard Schmidt wrote:
 Hi,

 we experiencing a problem after upgrading  the openssl port to openssl
 1.0.2.

 /usr/bin/vi started to crash after some seconds with segfault.

 Is you vi linked to openssl ?


Let's get this into an issue report @ Bugzilla

Please add this mailing lists threads URL to the issue report in the URL
field as well

Koobs

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

Re: 9.2-PRE: switch off that stupid Nakatomi Socrates

[Kubilay Kocak]

On 28/09/2013 12:17 PM, Alfred Perlstein wrote:
 On 9/27/13 7:14 PM, Freddie Cash wrote:
 On Sep 27, 2013 5:05 PM, grenville armitage garmit...@swin.edu.au
 wrote:


 On 09/28/2013 08:06, David Demelier wrote:
  [..]

 Also in the future you can just forgot that crappy ideas as you can
 see,
 nobody liked it.

 I beg to differ.
 I know it's not a poll, but myself and the 5 people in my office all
 thought it was awesome, and will be leaving it enabled for as long as 9.2
 is installed on our servers.

 That definitely puts it above nobody liked it.

 Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is
 too short for this. :)

 Agreed.  When it stop being fun, then it will see a decline in
 participation.
 
 -Alfred
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Both of you have it *right* on the money :) A more discerning question
is *why* you thought it was awesome.

Poeple might think its obvious, but the answer is *not* a cool logo, nor
any Nakatomi reference.

The real answer is deeper than that, and goes to the heart of why we
feel affinities toward one individual, group, organisation or another.

The purpose is entirely non-technical, and *precisely* to be active in
honing FreeBSD's brand identity, personality and culture moving forward.

If the outcomes are a perception of a community that is approachable and
lighthearted, and encouraging participation, so much the better.

To those who read this thread, ask yourself first: What message do YOU
want to communicate to the world about who we are?

Now make your decisions follow from that :)

--
Kubilay koobs Kocak


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

Re: About kern.ipc.somaxconn and netstat

[Kubilay Kocak]

On 31/01/2013 4:54 AM, Efraín Déctor wrote:
 -Mensaje original- From: Kubilay Kocak
 Sent: Wednesday, January 30, 2013 3:25 AM
 To: Efraín Déctor
 Cc: freebsd-stable@freebsd.org
 Subject: Re: About kern.ipc.somaxconn and netstat
 
 On 30/01/2013 12:26 PM, Efraín Déctor wrote:
 Hello.

 We have a webserver using FreeBSD, we read about tunning
 kern.ipc.somaxconn
 (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html)
 so the OS can handle all the connections. Is there a way to know how
 many connections are established in a certain moment?. I know about
 netstat(1) but is there any other command that we can use to know the
 exact amount of how many connections are established?.


 This one might help:
 
 kern.ipc.numopensockets: Number of open sockets
 
 It's usefulness will depend on the granularity you require (in only, out
 only, established only, etc) but it's always represented system-wide
 resource consumption very well (matching observed workloads - some
 baseline value)
 

 
 Thank you, it is very helpfull, using kern.ipc.numopensockets with
 sockstat(1) and netstat(1) will give me a clue to tune kern.ipc.somaxconn
 
 Thank you all.

Also, if you haven't already come across this one in your netstat
travels, this one directly reports listen queue overflows:

netstat -s -p tcp |grep listen

--
Ta,

Koobs


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

Re: About kern.ipc.somaxconn and netstat

[Kubilay Kocak]

On 30/01/2013 12:26 PM, Efraín Déctor wrote:
 Hello.
 
 We have a webserver using FreeBSD, we read about tunning kern.ipc.somaxconn 
 (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html)
  so the OS can handle all the connections. Is there a way to know how many 
 connections are established in a certain moment?. I know about netstat(1) but 
 is there any other command that we can use to know the exact amount of how 
 many connections are established?.
 
 
 Thanks in advance.
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 

This one might help:

kern.ipc.numopensockets: Number of open sockets

It's usefulness will depend on the granularity you require (in only, out
only, established only, etc) but it's always represented system-wide
resource consumption very well (matching observed workloads - some
baseline value)

--
Ta,

Koobs

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