Re: noatime on ufs2

On Tue, Jan 9, 2024 at 2:47 AM void wrote: > I was concerned that email might not work right without atime. > So far, it seems to be working OK. > Depending on how you define "correct". Deliveries won't be affected by atime setting in any way; telling if you have new mail _may_ be affected,

Re: noatime on ufs2

On Sun, Jan 7, 2024 at 5:27 AM void wrote: > Hi, > > Does /var/mail still need atime? > > I've installed a ufs2-based -current main-n267425-aa1223ac3afc on > rpi4/8BG which installs into one / . If it's mounted with noatime, > will it have consequences for /var/mail ? It doesn't matter if you

Re: Move u2f-devd into base?

On Mon, Jan 8, 2024 at 10:37 AM Warner Losh wrote: > > > On Mon, Jan 8, 2024 at 9:35 AM Kyle Evans wrote: > >> On 1/8/24 10:30, Tomoaki AOKI wrote: >> > On Mon, 8 Jan 2024 08:18:38 -0700 >> > Warner Losh wrote: >> > >> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber >> >> wrote: >> >> >>

Re: Move u2f-devd into base?

On Mon, Jan 8, 2024 at 7:19 AM Warner Losh wrote: > > > On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber > wrote: > >> We have FIDO/U2F support for SSH in base. >> >> We also have a group "u2f", 116, in the default /etc/group file. >> >> Why do we keep the devd configuration (to chgrp the

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 14:17, Mike Karels wrote: On 23 Dec 2023, at 15:23, Craig Leres wrote: On 12/23/23 06:52, Konstantin Belousov wrote: This is strange change at best. I have no opinion about the disabling of compression of the rotated logs by default, but we already have knobs to do that.

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-24 10:03, Rodney W. Grimes wrote: On 2023-12-23 06:52, Konstantin Belousov wrote: On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 07:09, Enji Cooper wrote: This impacts embedded systems or jails which use UFS as the default /var/log backed device. There are quite a few larger consumers of FreeBSD out there that still use UFS instead of ZFS. I appreciate your feedback! Thank you for pointing out the

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 10:17, Ceri Davies wrote: I really don’t like the idea of adding flags that make the program ignore a config file. I also think this is premature until ZFS installs are default on all architectures. However, if you must (and I see you have) change this, please don’t call the

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 13:08, Steve Kargl wrote: On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote: I appreciate your perspective on this issue. However, I believe there are additional benefits to modifying the newsyslog code (which is already done in commit 906748d208d3, by the way) beyond what

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 06:52, Konstantin Belousov wrote: On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 00:51, Miroslav Lachman wrote: On 23/12/2023 08:18, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed rotated

Proposal: Disable compression of newsyslog by default

Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed rotated log files to save disk space. This approach was valuable in the early days where

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

On 2023-11-20 19:33, Warner Losh wrote: On Mon, Nov 20, 2023 at 6:21 PM Xin Li <mailto:delp...@delphij.net>> wrote: Hi, It seems that the recent improvements of ACPI detection (e0f3dc82727f and 0b01d45783c3) would leave the system in an unbootable state if the U

HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

Hi, It seems that the recent improvements of ACPI detection (e0f3dc82727f and 0b01d45783c3) would leave the system in an unbootable state if the UEFI files are not being updated at the same time of "make installworld". At early boot the kernel would panic with: panic: running without

Re: MOTD is not created correctly (since 2022/02/18)

On 2023-05-22 8:18 PM, Jamie Landeg-Jones wrote: I've just finally updated to 13-stable, and can't be the first to notice this?! /etc/rc.d/motd contains the line: uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' Note the space before the "$" - needed

Re: find(1): I18N gone wild ?

This is expected behavior (in en_US.UTF-8 the ordering is AaBb, not ABab). You might want to set LC_COLLATE to C if C behavior is desirable. On Mon, Apr 17, 2023 at 2:06 PM Poul-Henning Kamp wrote: > This surprised me: > > # mkdir /tmp/P > # cd /tmp/P > # touch FOO >

Re: cant login after make installworld: pam_opie.so.6 not found

On 2023-01-04 6:59 PM, grarpamp wrote: looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6 and now I cannot pass the login prompt says the error "pam_opie.so: not found how can I get it back? I tried everything and nothing brought it back commit

Re: Proposal: remove /usr/bin/minigzip

On 7/28/22 23:24, Eugene Grosbein wrote: 29.07.2022 13:12, Xin Li пишет: Hi, I'd like to remove /usr/bin/minigzip , a patch is available at: https://reviews.freebsd.org/D35979 The minigzip is originally an example application shipped with zlib to demonstrate how to use

Proposal: remove /usr/bin/minigzip

Hi, I'd like to remove /usr/bin/minigzip , a patch is available at: https://reviews.freebsd.org/D35979 The minigzip is originally an example application shipped with zlib to demonstrate how to use it to implement basic functionality of gzip. It was connected to the base system in

[RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?

haven't actually tested it yet). Cheers,From eb6e60233d840d072d0280325ca2cb37455dc2f1 Mon Sep 17 00:00:00 2001 From: Xin LI Date: Mon, 3 Jan 2022 10:48:17 -0800 Subject: [PATCH] mount_nfs: Attempt NFSv4 before NFSv3 and NFSv2. --- sbin/mount_nfs/mount_nfs.8 | 6 +++--- sbin/mount_nfs/mount_nfs.c

Re: ThinkPad: reboots after successful shutdown -p

On 3/16/21 9:45 PM, Warner Losh wrote: > > > On Tue, Mar 16, 2021 at 10:18 PM Xin Li <mailto:delp...@freebsd.org>> wrote: > > On 11/17/19 23:14, Xin Li wrote: > > Hi, > > > > I recently noticed that if I do a 'shutdown -p' from -C

Re: ThinkPad: reboots after successful shutdown -p

On 11/17/19 23:14, Xin Li wrote: > Hi, > > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the > system would shut down and seemingly powered off, then it would restart > after about 5-10 seconds. > > Is this a known issue? Arguably this is not necessar

Re: UEFI boot hangs after loading kernel with efi_max_resolution="4k"

With Toomas's help (thanks!), I was able to partially resolve the hang and blank screen at boot issue, for the record, for now this can be solved by adding: screen.font="16x32" in /boot/loader.conf; no more efi_max_resolution setting is needed. Setting allscreen_flags to load font still panics

UEFI boot hangs after loading kernel with efi_max_resolution="4k"

Hi, It seems that some recent change after 282381aa53a would prevent my laptop (Lenovo P51, with 4k LCD) from booting. I have made some attempt to find out why, so far, it seems that setting efi_max_resolution="480p" or efi_max_resolution="720p" would allow it to boot to single user mode.

Re: zpool upgrade to draid feature: does it require updated zfs boot code ?

On 1/28/21 11:00, Kurt Jaeger wrote: > Hi! > > Short question: > > Does a zpool upgrade on 14.0 (current) for the draid feature > require a boot code update ? > > Long version of the same question: [...] > With the draid update, no message was displayed. > > Does it require the bootcode update

Re: GPF on boot with devmatch

On 10/12/20 11:13, Warner Losh wrote: > > > On Mon, Oct 5, 2020 at 3:39 PM Alexander Motin > wrote: > > On 05.10.2020 17:20, Warner Losh wrote: > > On Mon, Oct 5, 2020 at 12:36 PM Alexander Motin > >

Re: GPF on boot with devmatch

On 10/4/20 10:13 PM, Warner Losh wrote: > > > On Sun, Oct 4, 2020, 11:07 PM Xin Li <mailto:delp...@delphij.net>> wrote: > > Hi, > > I'm seeing this panic at boot after upgrading from r366217 to r366364, > and continues to exist for r366421

GPF on boot with devmatch

Hi, I'm seeing this panic at boot after upgrading from r366217 to r366364, and continues to exist for r366421 (but I haven't find out the exact change that caused it). Preloading the relevant kernel modules (uhid.ko, ums.ko and wmt.ko) seems to make the kernel boot correctly. This is not

ioctl argument type [Was Re: svn commit: r359968 - head/sys/kern]

Hi, I have seen Chromium trigger the warning (I run -CURRENT with INVARIANTS) and looked into the code history a little bit. It seems that the command was changed to u_long in r36846 with a follow up commit of r38517

Re: Is there any error checking on swap?

On 7/12/20 12:29 AM, John-Mark Gurney wrote: > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: >> Is there any error checking on swap traffic, along the lines of >> a checksum or parity test? >> >> Just curious what happens if a page written out is corrupted when >> it

Re: magic file update?

On 6/17/20 8:08 AM, Antoine Brodin wrote: > On Wed, Jun 17, 2020 at 4:00 PM Michael Butler > wrote: >> >> I'm seeing this message repeatedly during port builds. Should I be >> concerned? >> >> file: File 5.39 supports only version 16 magic files. >> `/usr/share/misc/magic.mgc' is version 14 >

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

On 6/11/20 10:19, Mark Johnston wrote: > On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote: >> On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: >>> ... >>> This should fix noexec for modules. >>> >>> diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c >>>

Re: HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

, > On Sat, Jun 6, 2020 at 8:52 AM Conrad Meyer wrote: >> >> Hi Xin Li, >> >> Thank you for the report and diagnosis. Sorry for the breakage. >> >> I have reverted the change and hope to address the issues you have >> identified. >> >> There

HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

I just spent quite some time to revive my laptop. TL;DR: if you are using /dev/diskid or /dev/gptid labels and GELI, please wait until things settled. === On 6/5/20 9:12 AM, Conrad Meyer wrote: > Author: cem > Date: Fri Jun 5 16:12:21 2020 > New Revision: 361838 > URL:

Re: CFT: if_bridge performance improvements

On 4/24/20 06:42, Kristof Provost wrote: > On 22 Apr 2020, at 18:15, Xin Li wrote: >> On 4/22/20 01:45, Kristof Provost wrote: >>> On 22 Apr 2020, at 10:20, Xin Li wrote: >>>> Hi, >>>> >>>> On 4/14/20 02:51, Kristof Provost wrote: >>>&

Ordering of files in zoneinfo [Was Re: sort.core error doing installworld on Current.]

Hi, Thanks for raising this. I have took a look at the change history, it seems that the find operation was introduced in r245265 (brooks@, to support packaged base) and sort was initially implemented as find -s in r289451

Re: CFT: if_bridge performance improvements

On 4/22/20 01:45, Kristof Provost wrote: > On 22 Apr 2020, at 10:20, Xin Li wrote: >> Hi, >> >> On 4/14/20 02:51, Kristof Provost wrote: >>> Hi, >>> >>> Thanks to support from The FreeBSD Foundation I’ve been able to work on >>> improving t

Re: CFT: if_bridge performance improvements

Hi, On 4/14/20 02:51, Kristof Provost wrote: > Hi, > > Thanks to support from The FreeBSD Foundation I’ve been able to work on > improving the throughput of if_bridge. > It changes the (data path) locking to use the NET_EPOCH infrastructure. > Benchmarking shows substantial improvements (x5 in

ThinkPad: reboots after successful shutdown -p

Hi, I recently noticed that if I do a 'shutdown -p' from -CURRENT, the system would shut down and seemingly powered off, then it would restart after about 5-10 seconds. Is this a known issue? Arguably this is not necessarily a FreeBSD issue, but it seems that the Windows 10 installation doesn't

Re: DRM-current-kmod is still a problem at r353339

uld be sleeping but can't because I have to use an older > kernel to have working graphics. Thanks, Netflix for making my life > harder. > > -Neel > > On 2019-10-18 01:01, Xin Li wrote: > > Another (semi-fixed!) data point -- I can confirm that with if >

in6_mcast: in6_joingroup attempts to acquire IN6_MULTI_LOCK when sleeping prohibited

I have seen this on boot of my laptop. It appears that in6_joingroup() was called in netisr_dispatch_src codepath, and it tried to acquire IN6_MULTI_LOCK(), which happened to sleep because we failed to acquire the sx, thus triggered the panic. === panic: sleepq_add: td 0xf8000ecd6000 to

Re: DRM-current-kmod is still a problem at r353339

Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

On Mon, May 27, 2019 at 7:08 AM wrote: > Hello, > I wanted to discuss about bug 231768 a bit: it is about keeping > COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs. > > The patch attached for the bug is for disabling these options by > default, following a few reasons which I'm going

Re: newfs silently fails if random is not ready (?)

On 9/4/18 21:39, Conrad Meyer wrote: > With current libc, I instead see: > > load: 0.10 cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s > 0% 2328k (SIGINFO) > > $ procstat -kk 1668 > PIDTID COMMTDNAME KSTACK > 1668 100609 blocked_random_poc -

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

On Thu, Aug 16, 2018 at 9:26 AM Brad Davis wrote: > > On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote: > > This was caused by r337852, but I didn't investigated further. > > > > The problem is that we have a source file called 'moduli.c' in > > crypto/openssh/ whi

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

This was caused by r337852, but I didn't investigated further. The problem is that we have a source file called 'moduli.c' in crypto/openssh/ while the build target was moduli, and bmake seen 'moduli' in source tree as older than moduli.c, and decided to rebuild it from source, while the two

Re: post ino64: lockd no runs?

On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote: > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any >> > of my systems

Re: Build fails in libpcap with WITHOUT_INET6

Thanks for reporting. I have applied a fix as r316125. On Tue, Mar 28, 2017 at 9:31 AM, Randy Westlund wrote: > Building r315872 for the Tegra (arm/armv6) board with WITHOUT_INET6 set fails > in libpcap: > >> --- klm_prot_xdr.pico --- >> cc -target

Re: mlock and jail

saying that we should have more fine grained control over it (a knob to allow system administrators to tweak it would be a good start). Cheers, > > From: Xin LI<mailto:delp...@gmail.com> > Sent: Thursday, February 2, 2017 1:13 PM > To: Pavel Timofeev<mailto:tim...@gmail.com>

Re: mlock and jail

On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote: > 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>: >> I like this idea. >> >> Note that potentially your patch would make it possible for a jailed >> root to DoS the whole system

Re: mlock and jail

I like this idea. Note that potentially your patch would make it possible for a jailed root to DoS the whole system by locking too much of pages in memory. I think it would be sensible to provide a per-jail flag to enable doing it, or better, have some finer grained control (e.g. per jail quota

Panic with some recent changes (between r309016 and r309184)

Is this known? The traceback: panic: vm_page_assert_xbusied: page 0xf807fae225b0 not exclusive busy @ /usr/src/sys/vm/vm_pager.c:263 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0a528ea620 vpanic() at vpanic+0x186/frame

EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

Hi, I finally got some time to explore the UEFI boot process (kudos to everyone who made this work!) and getting myself familiarize with the basics. One quick question -- Is there some technical restriction that prevents us from merging boot1.efi and loader.efi into one binary? Cheers,

Re: FreeBSD_HEAD_i386 - Build #3460 - Failure

My bad. Proposed fix would be: Index: lib/libmagic/Makefile === --- lib/libmagic/Makefile (revision 302221) +++ lib/libmagic/Makefile (working copy) @@ -19,7 +19,7 @@ INCS= magic.h MAGICPATH?=/usr/share/misc

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 6/8/16 23:10, Craig Rodrigues wrote: > Hi, > > I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD > current. > > In latest current, it should be possible to put in /etc/rc.conf: > > nis_ypldap_enable="YES" > to activate the ypldap daemon. > > When set up properly, it

Re: [zfs] Cache on SD stops working after updating to 11-CURRENT r291458 amd64

Please subscribe: https://bugs.freebsd.org/205882 You can locally apply -r292066 or modify the code to skip the check when pguid is 0 as a stopgap. Cheers, signature.asc Description: OpenPGP digital signature

HEADSUP: Memory corruption issue with ZFS users using L2ARC [Fwd: svn commit: r287283 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]

-CURRENT and have L2ARC, please be sure to examine if you have any data loss. Cheers, Forwarded Message Subject: svn commit: r287283 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Date: Sat, 29 Aug 2015 09:22:33 + (UTC) From: Xin LI delp...@freebsd.org To: src-committ

Re: Read-only /usr/obj/ no longer kosher?

freebsd-version.sh is generated from the files (but it's not clear to me whether if it's a bug or a feature that 'make install' checks if it's up-to-date and decides to regenerate it...). Cheers, -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve

Re: Read-only /usr/obj/ no longer kosher?

On 8/23/15 14:55, Pawel Jakub Dawidek wrote: I used to build world and kernel on one machine and export both /usr/src/ and /usr/obj read-only to other machines. It doesn't work anymore (this is from 'make installworld'): === bin/freebsd-version (install) eval $(egrep

Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/07/15 08:50, Jamie Landeg-Jones wrote: Xin Li delp...@delphij.net wrote: On 8/6/15 22:24, Kevin Oberman wrote: Or the code in portsnap could be modified to get the current running version. I thought about this today but it won't work

Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 8/6/15 22:24, Kevin Oberman wrote: Or the code in portsnap could be modified to get the current running version. I thought about this today but it won't work as advertised: someone (currently me) still have to tweak the portsnap builder

Proposal: make portsnap generate INDEX-${OSREL:R} only by default

/concerns? I'll commit the change if no objection is raised in a week. Cheers, -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die Index: etc/portsnap.conf === --- etc

HEADSUP: password database format change [Was: svn commit: r283981 - head/usr.sbin/pwd_mkdb]

any breakage as we currently plan to remove the -l, -B and -L options from pwd_mkdb(8) in 12.0-RELEASE. Cheers, - Forwarded Message Subject: svn commit: r283981 - head/usr.sbin/pwd_mkdb Date: Thu, 4 Jun 2015 07:24:56 + (UTC) From: Xin LI delp...@freebsd.org To: src-committ

Re: What to do about RCS/OpenRCS

, so I still object the replacement unless the issues have been taken care of. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.2 (FreeBSD

Re: backward dependencies on libzfs

compatibility shims (I think it was introduced in r248445). I don't have much time to work on it right now though. Andriy -- maybe file a bug and assign it to me? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN

Re: default pager (csh)

. As far as I can remember, less(1) has never done that clear-the-screen thing on FreeBSD, which is why it is so jarring on Linux. Not all terminals will clear screen... Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die

Re: default pager (csh)

to speak up). I use less(1) instead of more(1) on all systems I have, so if some brave soul wants to make the change I'd say just go for it! but that's my $0.02 only. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN

Re: tzsetup chroot

effect. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJU0X+zAAoJEJW2GBstM+nsfpwQAIwPBj11lzJS662RPBPQR6dB vb3gCGJjqRANCD

Re: old bug: mount_nfs path/name is limited to 88 chars

old world with new kernel) would be a big pain to recover from. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0

Re: Delayed atime updates (lazytime)

) and partially lack of interest from the community. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQIcBAEBCgAGBQJUdjhZAAoJEJW2GBstM+nsJvsQAJAYNhKU3+3OTIEX7+1w1WlQ

Re: current panic: Lock (sx) random_adaptors not locked @

/random_adaptors.c:278 This was fixed in r274006 FYI. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUWRmsAAoJEJW2GBstM+nsvZEP/1JKJsptJGPrkOfhE9MznH03

Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The problem should have been corrected by r273919. Please update your system and update /etc/ with mergemaster. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die

Re: zfs recv hangs in kmem arena

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/16/14 4:25 AM, James R. Van Artsdalen wrote: The zfs recv / kmem arena hang happens with -CURRENT as well as 10-STABLE, on two different systems, with 16GB or 32GB of RAM, from memstick or normal multi-user environments, Hangs usually

Re: zfs recv hangs in kmem arena

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/16/14 8:43 PM, James R. Van Artsdalen wrote: On 10/16/2014 11:12 AM, Xin Li wrote: On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote: FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2 r272070M: Wed Sep 24 17:36:56 CDT 2014

Re: ZFS-related panic: possible spa-spa_errlog_lock deadlock

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 9/7/14 9:02 PM, Fabian Keil wrote: Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the following panic yesterday: [...] Unread portion of the kernel message buffer: [6880] panic: deadlkres: possible deadlock detected for

Re: ZFS-related panic: possible spa-spa_errlog_lock deadlock

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 9/7/14 11:23 PM, Fabian Keil wrote: Xin Li delp...@delphij.net wrote: On 9/7/14 9:02 PM, Fabian Keil wrote: Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the following panic yesterday: [...] Unread portion of the kernel

Recent vt(4) broke moused when hw.vga.textmode=1

Hi, I have seen this panic via serial console, but the console is completely unusable at the time. VGA console is full of '?'. Booting single user mode, I can provoke the panic with '/etc/rc.d/moused start ums0'. === Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 0e

Re: Recent vt(4) broke moused when hw.vga.textmode=1

On 8/23/14 12:42 AM, Jean-Sébastien Pédron wrote: On 23.08.2014 08:38, Xin Li wrote: Fatal trap 12: page fault while in kernel mode And the crash is fixed in r270390. Thank you for reporting this! I have verified and r270390 have fixed the crash, thanks for the prompt fix! Cheers

Re: [ZFS][PANIC] Solaris Assert/zio.c:2548

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I think this is my stupid. Feeling ashamed. Please try r268980+ and report back if it's fixed or not, thanks! Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTzihjAAoJEJW2GBstM+ns2esP/3zfORqtE11QeveWI8wBzHav

Re: svn commit: r267897 - in head: contrib/file contrib/file/Magdir contrib/file/doc contrib/file/m4 contrib/file/magic contrib/file/python contrib/file/src contrib/file/tests lib/libmagic usr.bin/fil

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 7/2/14, 12:10 AM, Matthias Meyser wrote: Am 26.06.2014 08:03, schrieb Xin LI: Author: delphij Date: Thu Jun 26 06:03:39 2014 New Revision: 267897 URL: http://svnweb.freebsd.org/changeset/base/267897 Log: MFV r267843: update file/libmagic

Re: userland breakage, zfs ?

://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Xin LI delp...@delphij.net https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ freebsd-current@freebsd.org

HEADSUP -- ZFS users

. The fix will be committed after I have done sufficient testing, and I'll send another headsup once everything is settled. Sorry for the inconvenience and thanks for your patience. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free

Re: HEADSUP -- ZFS users

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Should be fixed in r268116. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJTsyDiAAoJEJW2GBstM+nsz

Re: svn commit: r267977 - head/bin/mv

[moving discussion to freebsd-current@] On 06/27/14 15:23, Jilles Tjoelker wrote: On Fri, Jun 27, 2014 at 07:57:54PM +, Xin LI wrote: Author: delphij Date: Fri Jun 27 19:57:54 2014 New Revision: 267977 URL: http://svnweb.freebsd.org/changeset/base/267977 Log: Always set UF_ARCHIVE

Re: [rfc] /dev/devstat permissions patch

, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTKMofAAoJEJW2GBstM+nspPYQAKt8UiAqDBQwe0KTeH+ykpis 4EG4+oM43Ze8WCc3DgsbB

Re: processes stuck in vmo_de state

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, It looks like there is a regression (or a regression that gets exposed by some new feature) that is related to time-keeping or timecounter, although I'm not yet familiar with the related code to tell if my conclusion was right or not. The

processes stuck in vmo_de state

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I have recently upgraded my home storage box (Avoton based board running FreeBSD/amd64) from 10.0-RELEASE (patched with some ZFS changes) to -CURRENT. It looks like the system would easily hang when I start 'buildworld', when this happens, I

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

rounds though. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGkLzAAoJEJW2GBstM+nsaVoP/017iARGzd++lCsfqyFDozGk nXJjatlrIcRjrbCmVRT0lsHiK

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 15:07, John-Mark Gurney wrote: Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: On 2014-03-07 17:06, Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J

nvi: tab can't be used in the context of substitute

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, It looks like the new nvi version don't accept tab in the context of substitute. A minimal use case would be to replace all leading 8 spaces with tabs, what one would do on older version of nvi would be: : 1,$ s/^/tab/g Now, with nvi

Re: UDP Lite support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 3/2/14, 10:42 AM, Joe Nosay wrote: On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com wrote: On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net wrote: On 02/26/14 18:52, Joe Nosay wrote: On Wed, Feb 26

Re: UDP Lite support

. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTDrzbAAoJEJW2GBstM+nsJVoP/29XRcleHMnAVa1UOG0+CD2y 0e/pAmk5vay599gjmiKSAuTSeKNaawRF3FZP+QsxhKw

Re: [head tinderbox] failure on powerpc64/powerpc

for the breakage. I'm testing a fix right now and will commit once validated. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSxLupAAoJEJW2GBstM+nsYnQQAIlQhsYIff7FuDmD363hHi30

[PATCH RFC] Disable save-entropy in jails

+fi + case ${entropy_dir} in [Nn][Oo]) exit 0 Cheers, -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org

Re: [PATCH RFC] Disable save-entropy in jails

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/24/13 14:36, Paul Hoffman wrote: On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net wrote: I think we shouldn't save entropy inside jails, as the data is not going to be used by rc script (pjd@126744). If there is no objections

Re: [PATCH RFC] Disable save-entropy in jails

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/24/13 15:26, Paul Hoffman wrote: On Dec 24, 2013, at 2:53 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/24/13 14:36, Paul Hoffman wrote: On Dec 24, 2013, at 12:44 PM, Xin Li delp

Re: 10-RC2 current wireless link aggregation not working correctly

to initiate one or a few gratuitous ARP broadcast when the active port changes. Some switches could use this to kick out their (outdated) memory of where the port is. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP

Re: 10-RC2 current wireless link aggregation not working correctly

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/17/13, 11:28 PM, dan_partelly wrote: What claims you do not believe ? Not important anyway. This is engineering, so you need not believe, you need to know. Go and replicate the bug. You will know then. I don't believe in merely doing

Re: [PATCH] Haswell Kernel Mode Setting

existing hardware, if it's not an explicit objection from a reviewer, I think it's Okay to just go ahead and commit the change after a reasonable timeout instead of waiting indefinitely. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live

  1   2   3   >