Re: FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"
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
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
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
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
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?
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
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
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
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&item=2bsd-7linux-bench&num=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
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
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
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&bug_status=Open&bug_status=In%20Progress&list_id=127434&product=Base%20System&query_format=advanced&version=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
Re: 10.3-BETA2 panic on boot with GCE NVMe
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?
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: Merging r286233 to stable/10?
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: Bug 201072
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=revision&revision=260024 > > They were later put back in this commit: > > https://svnweb.freebsd.org/base?view=revision&revision=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
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
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
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"
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" >> 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
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 - 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
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 - ) -- 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"
