User Details
- User Since
- Jun 4 2014, 6:42 AM (313 w, 1 d)
Today
Tue, Jun 2
Mon, Jun 1
I have a vague memory, maybe wrong, that commonly used fixed RSS keys were selected because they had some property (-ies).
So, maybe just being random is not good enough?
I think that hypothetical rss_isbadkey was mentioned for a reason?
Fri, May 29
Thu, May 28
John, I know that you would prefer something grander.
Do you at least not object to this change ?
Wed, May 27
Just in case:
(kgdb) tid 101533
(kgdb) bt
#0 sched_switch (td=0xfffffe00b4f85500, flags=<optimized out>) at /usr/devel/git/motil/sys/kern/sched_ule.c:2147
#1 0xffffffff807e4de2 in mi_switch (flags=260) at /usr/devel/git/motil/sys/kern/kern_synch.c:542
#2 0xffffffff80831916 in sleepq_switch (wchan=0xfffff80085627bd8, pri=<optimized out>) at /usr/devel/git/motil/sys/kern/subr_sleepqueue.c:625
#3 0xffffffff807acb61 in sleeplk (lk=0xfffff80085627bd8, flags=532480, ilk=<optimized out>, wmesg=<optimized out>, pri=<optimized out>, timo=51, queue=0) at /usr/devel/git/motil/sys/kern/kern_lock.c:295
#4 0xffffffff807ab19f in lockmgr_xlock_hard (lk=0xfffff80085627bd8, flags=<unavailable>, ilk=0x0, file=0xffffffff80c40f02 "/usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", line=1438,
lwa=0xfffff80085627bd8) at /usr/devel/git/motil/sys/kern/kern_lock.c:841
#5 0xffffffff808c3c64 in VOP_LOCK1 (vp=0xfffff80085627b70, flags=532480, file=0xffffffff80c40f02 "/usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", line=1438) at ./vnode_if.h:879
#6 _vn_lock (vp=0xfffff80085627b70, flags=532480, file=0xffffffff80c40f02 "/usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c", line=1438) at /usr/devel/git/motil/sys/kern/vfs_vnops.c:1613
#7 0xffffffff8045ef27 in zfs_lookup_lock (dvp=0xfffff8000bc1c5b8, vp=0xfffff80085627b70, name=0xfffffe00b07cb3b0 "kcminit.1001.00.core", lkflags=532480)
at /usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1438
#8 zfs_lookup (dvp=<optimized out>, nm=0xfffffe00b07cb3b0 "kcminit.1001.00.core", vpp=<optimized out>, cnp=0xfffffe00b07cb8a0, nameiop=1, cr=<optimized out>, td=<optimized out>, flags=0, cached=1)
at /usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1612
#9 0xffffffff8045f60d in zfs_freebsd_lookup (ap=0xfffffe00b07cb4e0, cached=<error reading variable: Cannot access memory at address 0x1>) at /usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4922
#10 zfs_freebsd_cachedlookup (ap=0xfffffe00b07cb4e0) at /usr/devel/git/motil/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4930
#11 0xffffffff80898248 in VOP_CACHEDLOOKUP (dvp=0xfffff8000bc1c5b8, vpp=0xfffffe00b07cb870, cnp=0xfffffe00b07cb8a0) at ./vnode_if.h:80
#12 vfs_cache_lookup (ap=<optimized out>) at /usr/devel/git/motil/sys/kern/vfs_cache.c:2149
#13 0xffffffff808a22c1 in VOP_LOOKUP (dvp=0xfffff8000bc1c5b8, vpp=0xfffffe00b07cb870, cnp=0xfffffe00b07cb8a0) at ./vnode_if.h:54
#14 lookup (ndp=0xfffffe00b07cb810) at /usr/devel/git/motil/sys/kern/vfs_lookup.c:951
#15 0xffffffff808a17f3 in namei (ndp=0xfffffe00b07cb810) at /usr/devel/git/motil/sys/kern/vfs_lookup.c:512
#16 0xffffffff808c314b in vn_open_cred (ndp=0xfffffe00b07cb810, flagp=0xfffffe00b07cba4c, cmode=384, vn_open_flags=5, cred=0xfffff801edb7a000, fp=0x0) at /usr/devel/git/motil/sys/kern/vfs_vnops.c:226
#17 0xffffffff807dcec4 in corefile_open_last (td=<optimized out>, name=<optimized out>, indexpos=<optimized out>, indexlen=<optimized out>, ncores=<optimized out>, vpp=<optimized out>)
at /usr/devel/git/motil/sys/kern/kern_sig.c:3434
#18 corefile_open (comm=0xfffff80013c098f0 "kcminit", uid=<optimized out>, pid=<optimized out>, td=0xfffffe00b4f85500, compress=0, signum=5, vpp=<optimized out>, namep=<optimized out>)
at /usr/devel/git/motil/sys/kern/kern_sig.c:3585
#19 coredump (td=0xfffffe00b4f85500) at /usr/devel/git/motil/sys/kern/kern_sig.c:3669
#20 sigexit (td=0xfffffe00b4f85500, sig=6) at /usr/devel/git/motil/sys/kern/kern_sig.c:3211
#21 0xffffffff807ddc3c in postsig (sig=6) at /usr/devel/git/motil/sys/kern/kern_sig.c:3109
#22 0xffffffff8083969b in ast (framep=0xfffffe00b07cbc00) at /usr/devel/git/motil/sys/kern/subr_trap.c:336Tue, May 26
fix a typo
Some of the new description can use additional explanation, but I am not sufficiently fluent with WiFi concepts to do that.
Sun, May 24
Fri, May 22
Thu, May 21
address markj's feedback
Thank you for the feedback.
Working on it.
catch up with the fact that zfs.c is a "normal" file now
@adrian, is this closer to what you have in mind?
Thanks!
do not call rt_ifmsg directly, wrap it under ieee80211_notify_ifnet_change
Wed, May 20
Mark, thank you very much for this!
I think that this change is good.
I still wonder if we can do some trick to avoid busying valid pages.
Maybe there is some way to be more sloppy when checking the validity.
E.g., we could possibly rely on a fact that with ZFS the range lock makes sure the validity cannot change because both page-in and page-out would need to lock the range.
Tue, May 19
Wed, May 13
Tue, May 12
No feedback in long time.
Thu, May 7
update the module makefile
Wed, May 6
May 5 2020
May 4 2020
rebase on the latest tree
Yeah, I think that it is better to use _BQC whenever it is actually provided because there can be multiple ways to control the brightness.
The more I look into this the more quirks I discover.
Some systems handle brightness keys completely in firmware, some post ACPI events, some post custom events via WMI.
On some systems _BCM actually changes the brightness (it's handled by the firmware); on some systems _BCM is just another level of indirection -- it just posts more events to be handled elsewhere (e.g., via ATIF with AMD's video).
I think that Linux drifts towards converting brightness events to evdev brightness key events and then letting the userland handle those keys. The actual brightness controls are exposed as sysfs backlight nodes and they cab be hooked to ACPI video (_BCM) or directly to graphics drivers or something vendor specific, etc.
May 1 2020
Apr 30 2020
Apr 24 2020
Apr 18 2020
Mar 6 2020
Looks good as far as my knowledge of the recent VM changes goes.
Thank you very much!
Mar 3 2020
LGTM.
I assume that a change to vmxnet3 that takes advantage of this improvement is coming.
We came to the same conclusion at Panzura and used a similar fix.
Feb 28 2020
I like Ken's suggestion on PIM_NO_INIT_ID.
Feb 27 2020
@mav , I do not know much about this but I would expect that if an initiator can also be a target then its target ID -- which, if I understand correctly, you suggest to be treated as an initiator ID -- would be from a different namespace than IDs of its targets. That is, I think that for a SAS initiator it is impossible to see itself as a target (where a target ID is typically also some made up number derived from the actual SAS topology).
Move creation of a "minor" from dsl_dataset_snapshot_sync_impl() to
dsl_dataset_snapshot_sync(). The former is also used by
dsl_dataset_snapshot_tmp_sync() and we do not need to create minors for
temporary snapshots. They are used only by zfs diff against a filesystem (via
ZFS_IOC_TMP_SNAPSHOT).
rebase to r358382