Re: powerd forgets top CPU frequency ?

dev.cpu.0.freq: 1801 dev.cpu.7.freq_levels: 3500/-1 dev.cpu.7.freq: 799 Xeon E3 v5 (Skylake) dev.cpu.0.freq_levels: 3500/-1 dev.cpu.0.freq: 900 dev.cpu.1.freq_levels: 3500/-1 dev.cpu.1.freq: 799 Xeon E-21xx (Coffee Lake) Seems to just all be done by the hardware. -- Matthew Fuller (MF4839

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

se locallocks=1. > > rick > > On Wed, Aug 21, 2024 at 7:29 AM Matthew L. Dailey > mailto:matthew.l.dai...@dartmouth.edu>> > wrote: > > Hi all, > > I posted messages to the this list back in February and March > > (https://lists.freebsd.org/arc

Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

Hi all, I posted messages to the this list back in February and March (https://lists.freebsd.org/archives/freebsd-current/2024-February/005546.html) regarding kernel panics we were having with nfs clients doing hdf5 file operations. After a hiatus in troubleshooting, I had more time this summe

Re: FreeBSD panics possibly caused by nfs clients

Posting a few updates on this issue. I was able to induce a panic on a CURRENT kernel (20240215), built with GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189 hours. The panic message and backtrace are below - please reach out directly if you'd like to have a look at the core.

Re: FreeBSD panics possibly caused by nfs clients

Hi all, I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after about 24 hours. This is the one without any debugging, so it only confirms the fact that the panics we've been experiencing still exist in CURRENT. There was some disk issue that prevented the dump, so all I have i

Re: FreeBSD panics possibly caused by nfs clients

Hi all, So I finally induced a panic on a "pure" ufs system - root and exported filesystem were both ufs. So, I think this definitively rules out zfs as a source of the issue. This panic was on 14.0p5 without debugging options, so the core may not be helpful. The panic and backtrace are below

Re: FreeBSD panics possibly caused by nfs clients

Hi all, Before the week was out, I wanted to provide an update on this issue. Last weekend, I installed two VMs with CURRENT (20240208-82bebc793658-268105) - one on zfs and one on ufs - and built a kernel with this config file: include GENERIC ident THAYER-FULLDEBUG makeoptions DEBUG=-g op

Re: FreeBSD panics possibly caused by nfs clients

On 2/9/24 4:18 PM, Mark Johnston wrote: > [You don't often get email from ma...@freebsd.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote: >> I had my first ke

Re: FreeBSD panics possibly caused by nfs clients

I had my first kernel panic with a KASAN kernel after only 01:27. This first panic was a "double fault," which isn't anything we've seen previously - usually we've seen trap 9 or trap 12, but sometimes others. Based on the backtrace, it definitely looks like KASAN caught something, but I don't

Re: FreeBSD panics possibly caused by nfs clients

On 2/9/24 11:04 AM, Mark Johnston wrote: > [You don't often get email from ma...@freebsd.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote: >> Good morning all, &

FreeBSD panics possibly caused by nfs clients

ermining if it is ZFS specific would be the best > first step, I think? > > It would be good to post this to a mailing list like freebsd-current@, > since others might have some insite into this. (Although you are > not using freebsd-current@, that is where most developers read

Re: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K

d-boot partition, above which things would also break horribly. I don't recall exactly what it was, but it was >512k and <1m (maybe 600k-ish?). So don't just make it arbitrarily bigger. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http

Re: gib driver problems?

What is the PCIID for the MAC? On Wed, Feb 3, 2021 at 14:35 joe mcguckin wrote: > I recently installed 12.2 on a supermicro motherboard. > > Connected to a 100M port on a Cisco switch, everything works ok > Connecting to a 1000BTX port, ifconfig says “Active, 1000B full duplex” > but no traffic

Re: CURRENT, usr/src on git, howto "mergemaster"?

`etcupdate` through automation across all of your server inventory, and then go round and manually resolve anything that needs it.) Cheers, Matthew ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freeb

Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory

> > Getting back to your original question. A more efficient ARC would exercise > your memory more intensely because you are replacing disk reads with memory > reads. And as I said before the old ZFS "found" weak RAM on three separate > occasions in three different machines over the last ten years.

Re: vfs.zfs.min_auto_ashift and OpenZFS

On Sun, Sep 6, 2020 at 17:08 Ed Maste wrote: > On Fri, 1 May 2020 at 20:20, Matthew Macy wrote: > > > > > > OpenZFS doesn't have the same ashift optimization logic that FreeBSD > > > has. It's something that needs to be resolved before the code can be &

Re: OpenZFS support merged

On Sat, Aug 29, 2020 at 08:47 Kurt Jaeger wrote: > Hi! > > > > > r364746 merged OpenZFS support in to HEAD. > > > > > > The change should be transparent unless you want to use new features. > > > I caution against 'zpool upgrade' for the next few weeks. > > > https://svnweb.freebsd.org/base?view=

Re: panic in range_tree_seg64_compare()

Try updating. I think this may have been fixed in https://github.com/openzfs/zfs/pull/10823 which was MFVed this morning. On Fri, Aug 28, 2020 at 9:49 AM Matthew Macy wrote: > > On Thu, Aug 27, 2020 at 10:37 PM Yuri Pankov wrote: > > > > Matthew Macy wrote: > > > On T

Re: panic in range_tree_seg64_compare()

On Thu, Aug 27, 2020 at 10:37 PM Yuri Pankov wrote: > > Matthew Macy wrote: > > On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov wrote: > >> > >> Yet another issue I'm seeing after last update (currently running > >> r364870), hit it 2 times today: > &g

Re: can't handle raw ops yet!!!

https://github.com/openzfs/zfs/pull/10836 On Thu, Aug 27, 2020 at 11:37 AM Yuri Pankov wrote: > > Matthew Macy wrote: > > Expected. I'm working on it. It's just a friendly reminder when > > INVARIANTS is enabled. > > Good, thanks. > > > On Thu,

Re: panic in range_tree_seg64_compare()

On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov wrote: > > Yet another issue I'm seeing after last update (currently running > r364870), hit it 2 times today: > > Fatal trap 12: page fault while in kernel mode > cpuid = 19; apic id = 0d > fault virtual address = 0xf819e2ecdc40 > fault code

Re: buildkernel fais with option ZFS in kernel configuration

Need zstdio option when linking statically On Thu, Aug 27, 2020 at 8:23 AM Scott Kenney wrote: > > Hello, > > Just noticed that buildkernel fails with "options ZFS" in the kernel > configuration file, the modules build without error. > > Source is at revision 364870 > > FreeBSD datura.rmta.org 13

Re: can't handle raw ops yet!!!

Expected. I'm working on it. It's just a friendly reminder when INVARIANTS is enabled. On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov wrote: > > After OpenZFS merge, during boot I'm getting several occurrences of what > seems to be the following: > > http://src.illumos.org/source/xref/freebsd-head/

Re: OpenZFS support merged

On Tue, Aug 25, 2020 at 9:36 AM Danilo Egêa Gondolfo wrote: > > On Tue, Aug 25, 2020 at 3:39 AM Matthew Macy wrote: >> >> r364746 merged OpenZFS support in to HEAD. >> >> The change should be transparent unless you want to use new features. >> I caution agai

OpenZFS support merged

r364746 merged OpenZFS support in to HEAD. The change should be transparent unless you want to use new features. I caution against 'zpool upgrade' for the next few weeks. https://svnweb.freebsd.org/base?view=revision&revision=364746 If you encounter problems please report them to me, Ryan Moelle

Re: CFT for vendor openzfs - week 5 reminder + memdisk images

> # kldload zfs > can't handle raw ops yet!!! > can't handle raw ops yet!!! > can't handle raw ops yet!!! > ZFS filesystem version: 5 > ZFS storage pool version: features support 5000 > can't handle raw ops yet!!! I'm working on it - Ryan reminded me of it today. It will probably get fixed before

Re: CFT for vendor openzfs - week 5 reminder + memdisk images

> > Hi. I have some problems downloading the amd64 image: > > baymax /home/djn > fetch -a > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz > freebsd-openzfs-amd64-2020081100-memstick.img. 19% of 655 MB 2179 kBps 04m07s > fetch: freebsd-

CFT for vendor openzfs - week 5 reminder + memdisk images

On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The tentative merge date is August 17th. Again, I hope it's not terribly controversial to point out that it really rests with us

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

On Wed, Jul 29, 2020 at 20:16 Chris wrote: > On Tue, 28 Jul 2020 21:16:28 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 21:06 Chris wrote: > > > > > On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said > > > > &g

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

On Tue, Jul 28, 2020 at 21:06 Chris wrote: > On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 20:43 Chris wrote: > > > > > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said > > > >

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

On Tue, Jul 28, 2020 at 20:43 Chris wrote: > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said > > >

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said > > > On Wednesday, July 8th I issued the initial call for testing for the > > update to HEAD to vendored openzfs. We'd like to give users roughly

CFT for vendor openzfs - week 4 reminder + memdisk images

On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The tentative merge date is August 17th. Again, I hope it's not terribly controversial to point out that it really rests with us

CFT for vendor openzfs - week 3 reminder

On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. I'm pushing the tentative merge date out by a week to August 17th as I wasn't able to spend any time working on this myself last w

Re: CFT for vendor openzfs - week 2 reminder

To help us keep track, please file an issue https://github.com/zfsonfreebsd/zof/issues Thanks. On Mon, Jul 13, 2020 at 3:39 PM Evilham wrote: > > On dl., jul. 13 2020, Kyle Evans wrote: > > > On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy > > wrote: > >> > >&

CFT for vendor openzfs - week 2 reminder

On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with u

Further note - Re: CFT for vendor openzfs

Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. On Wed, Jul 8, 2020 at 2:31 PM Matthew Macy wrote: > > Checkout updated HEAD: > % git clone https://github.com/mattmacy/networking.git -b > projects/openzfs_ve

CFT for vendor openzfs

Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whate

Re: r362666 breaking buildworld (don't know how to make nvpair.c) & Fix/Patch

Well - it was from his review. On Fri, Jun 26, 2020 at 8:00 PM Enji Cooper wrote: > > (Moving hackers to BCC since the issue is current-related) > > > On Jun 26, 2020, at 6:56 PM, Neel Chauhan wrote: > > > > Hi, > > > > When I attempt to build world in 13-CURRENT, I get this error: > > … > > >

Fwd: iflib and options RSS is a no go for igbX

> > I can go setup my second PC this week (I have PTO!) and go see if I > have any PCIe igb hardware here. I /think/ I do but it's fibre. The RSS compile time option used to be disabled in part because of this. The drivers had working RSS that relied on packet receipt before setting flowid. -M ___

Re: vfs.zfs.min_auto_ashift and OpenZFS

OpenZFS doesn't have the same ashift optimization logic that FreeBSD has. It's something that needs to be resolved before the code can be integrated downstream. -M On Fri, May 1, 2020 at 11:04 AM Graham Perrin wrote: > > In my sysctl.conf: > > vfs.zfs.min_auto_ashift=12 > > – if I recall correct

Re: OpenZFS port updated

On Fri, Apr 17, 2020 at 1:16 PM Scott Long wrote: > > Is the intention to eventually replace the zfs code in src/ ? Yes. Once the feature gap is filled in and most of the potential POLA violations are fixed. > What will be the long-term relationship between src/ and ports/ for this? OpenZFS use

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

s, perhaps by including /usr/local and /var/db/pkg are both parts of your BEs. Cheers, Matthew signature.asc Description: OpenPGP digital signature

Re: Pkg repository is broken...

bled: no } ``` (presumably with an additional .../pkg/repos/foo.conf file to enable a custom local repository) The best way to confirm exactly what the resultant pkg(8) configuration comes out as is by: pkg -vv Cheers, Matthew signature.asc Description: OpenPGP digital signature

Re: kernel module code coverage

On Thu, Dec 5, 2019 at 8:38 AM Ed Maste wrote: > > > > Have you looked into /dev/kcov. This is used by SYZKALLER for getting > > > coverage information from the kernel. > > > > > That's part of Matt Macy's gcov project, right?. > > No, /dev/kcov is independent of, and predates, Matt Macy's work. I

Re: kernel module code coverage

The whole point of adding gcov support was for integrating with the ZoL CI framework which does coverage. So it very much does work with modules. Not sure where that comes from. -M On Thu, Aug 8, 2019 at 6:52 AM Alan Somers wrote: > > On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: > > > >

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

On Tue, Oct 8, 2019 at 15:01 Julian Elischer wrote: > On 10/8/19 2:42 PM, Walter Parker wrote: > > See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time > > but I was refering to the new "epoch" faciity in the kernel.. ( man 9 > epoch ) That’s what one would assume given that th

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

On Tue, Oct 8, 2019 at 14:42 Walter Parker wrote: > See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time > > Unrelated. http://concurrencykit.org/slides.html And see also Keir Fraser’s thesis where the idea originated. > > Walter > > On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer

Re: pkg: Cannot open /dev/null:No such file or directory

;re chroot'd to /chroot, then: mount -t devfs devfs /chroot/dev should allow pkg(8) to work as usual. Cheers, Matthew signature.asc Description: OpenPGP digital signature

Re: New vm-image size is much smaller than previos

s (if using UFS) or allow your vdevs to expand to fill the space available (if using ZFS). This allows you to build a system of pretty much any feasible size and parallels the behaviour of eg. the AMIs available for AWS. Cheers, Ma

Re: ZFS no longer mounted in alphanumerical order

On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > Has anyone else noticed ZFS datasets are no longer mounted in > alphanumerical order in CURRENT? It looks more like they are mounted > in the order in which they are encountered. > Wouldn't surprise m

Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:53 PM Matthias Apitz wrote: > > El día viernes, diciembre 28, 2018 a las 12:55:32p. m. -0800, Cy Schubert > escribió: > > > I

Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:55 PM Matthew Macy wrote: > > I just updated world/kernel/ports to today's HEAD and packages

Re: bind 9.12.3-P1 dies after change of IP on outbound interface

like a bug in bind. https://gitlab.isc.org/isc-projects/bind9/issues/777 Matthew signature.asc Description: PGP signature

Re: The future of ZFS in FreeBSD

On Thu, Dec 20, 2018 at 03:11 Eugene M. Zheganin wrote: > Hello, > > On 19.12.2018 23:32, Allan Jude wrote: > > The biggest thing to remember is that this is still OpenZFS, and still > > run by the same developers as it has been. We are just commonizing on > > the repo that has the most features

Re: The future of ZFS in FreeBSD

On Thu, Dec 20, 2018 at 06:39 Alexey Dokuchaev wrote: > On Thu, Dec 20, 2018 at 03:49:38PM +0500, Eugene M. Zheganin wrote: > > On 19.12.2018 23:32, Allan Jude wrote: > > > The biggest thing to remember is that this is still OpenZFS, and still > > > run by the same developers as it has been. We a

Re: The future of ZFS in FreeBSD

On Thu, Dec 20, 2018 at 9:33 AM Warner Losh wrote: > > > Matt, > > This is a fairly comprehensive plan. Kudos for putting it together. > > The big question here is do you have a complete list of FreeBSD-specific > changes that will be lost in the cut-over? We've heard about TRIM support and > ma

Re: The future of ZFS in FreeBSD

ntion it needs so that it can be merged before summer. My understanding is that it's mostly suffered from neglect. TRIM is most important to FreeBSD and it already had its own implementation. https://github.com/zfsonlinux/zfs/pull/5925 I forwarded you the private communication again as well.

Re: The future of ZFS in FreeBSD

se details than lamenting in public lists. Thanks. -M > On Wed, 19 Dec 2018 at 06:51, Matthew Macy wrote: > >> The sources for FreeBSD's ZFS support are currently taken directly >> from Illumos with local ifdefs to support the peculiarities of FreeBSD >> where the

Re: The future of ZFS in FreeBSD

On Wed, Dec 19, 2018 at 8:35 AM Shawn Webb wrote: > I'm curious what this means for OpenZFS. > OpenZFS will continue to be an umbrella project for coordinating all work on open-source ZFS. The primary activities of OpenZFS are the annual OpenZFS Developer Summit

Re: The future of ZFS in FreeBSD

On Tue, Dec 18, 2018 at 11:49 PM Enji Cooper wrote: > > Hello Matthew, > > I appreciate the long write up, as someone who still uses FreeBSD ZFS on my > NAS box and knowing some of the history with ZFS on *Solaris, etc. Something > like this was bound to happen with post

The future of ZFS in FreeBSD

The sources for FreeBSD's ZFS support are currently taken directly from Illumos with local ifdefs to support the peculiarities of FreeBSD where the Solaris Portability Layer (SPL) shims fall short. FreeBSD has regularly pulled changes from Illumos and tried to push back any bug fixes and new featur

Re: panic: mtx_lock() by idle thread ... mutex igb0 @ ../../../net/iflib.c:2084

Will fix. On Tue, Oct 23, 2018 at 2:21 AM Peter Holm wrote: > > Feeding entropy: . > lo0: link state changed to UP > panic: mtx_lock() by idle thread 0xf800036ac000 on sleep mutex igb0 @ > ../../../net/iflib.c:2084 > cpuid = 4 > time = 1540286062 > KDB: stack backtrace: > db_trace_self_wrappe

Re: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

On Fri, Oct 19, 2018 at 03:47:40PM -0700 I heard the voice of Don Lewis, and lo! it spake thus: > > The first is that when I attempt to start a Virtualbox VM, the > system panics. Perhaps https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230460 -- Matthew Fuller (MF4839) | full

Re: drm2 in base

On Fri, Sep 28, 2018 at 1:22 PM Warner Losh wrote: > > On Fri, Sep 28, 2018 at 2:02 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > On Fri, Sep 28, 2018 at 02:47:39PM -0500, Matthew D. Fuller wrote: > > > On Fri, Sep 28, 2018 at 11:00:02AM -0700

Re: drm2 in base

owing the last fence, I see Jul 20 21:19:47 cepheus pkg: drm-stable-kmod-g20180619_1 deinstalled Jul 20 21:19:48 cepheus pkg-static: drm-next-kmod-4.11.g20180619_1 installed and I haven't seen one since. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Admini

Re: drm2 in base

mod. Well, please don't tell that to the 6450 I've got running on drm-next-kmod (which also spent some time on drm-stable)... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Interne

Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4

On Sat, Sep 8, 2018 at 11:03 Cy Schubert wrote: > In message , Jakob > Alvermar > k writes: > > > > Total MFU MRUAnon Hdr L2Hdr > Other > > ZFS ARC667M186M168M 13M 3825K 0K295M > > > > rat

Re: drm / drm2 removal in 12

Please just stop responding to this person or we're going to have to migrate to moderated lists. You're legitimizing the voice of one person who project members have spend hours of their time (some even in person) trying to explain the time tradeoffs of supporting graphics. For some reason he isn't

Re: ifnet use after free

k you for updating me. -M > Kristof > > On 25 Aug 2018, at 19:44, Matthew Macy wrote: > > I'll take a look. But it's likely to not be the OP's issue. For future > reference memguard on the memory type in question is extremely useful in > catching use after free.

Re: ifnet use after free

> > On 25 Aug 2018, at 0:26, Matthew Macy wrote: > > On Fri, Aug 24, 2018 at 15:25 Shawn Webb > wrote: > > Hey All, > > Somewhere in the last month or so, a use after free was introduced. I > don't have the time right now to bisect the commits and figure out &g

Re: drm / drm2 removal in 12

arner Losh wrote: > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >> >> > On Fri, Aug 24, 2018 at 14:53 Ali wrote: >> > >> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >> > > > Just in case anyone misses

Re: ifnet use after free

On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote: > Hey All, > > Somewhere in the last month or so, a use after free was introduced. I > don't have the time right now to bisect the commits and figure out > which commit introduced the breakage. Attached is the core.txt (which > seems nonsensical bec

Re: drm / drm2 removal in 12

On Fri, Aug 24, 2018 at 14:53 Ali wrote: > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > Just in case anyone misses the change to UPDATING: > > > > 20180821: > > drm and drm2 have been removed. Users on powerpc, 32-bit > hardware, >

Re: priority of paths to kernel modules?

No we're not. x86 and PPC will be disconnected from the build in a subsequent commit during the freeze. Warner was simply too tired to communicate this adequately and still meet the timeline that RE wanted. And take heart. Even if Warner weren't trying to balance the needs of RE and the graphics t

Re: Native Encryption for ZFS on FreeBSD CFT

Hi Thomas, Alan believes that, even with dedup disabled, the ZFS native encryption support is vulnerable to watermarking attacks. I don't have enough exposure to crypto to pass any judgement and was hoping that you'd share your point of view. Thanks in advance. -M On Wed, Aug 22, 2018 at 12:42

Re: Native Encryption for ZFS on FreeBSD CFT

Fixed. Pull. bc2b257d1082112cc27e56db793f5c569f603bec On Wed, Aug 22, 2018 at 12:10 AM Matthew Macy wrote: > Yes. I _just_ rebased and broke world in the process. Fix coming up > momentarily. > -M > > On Wed, Aug 22, 2018 at 12:06 AM Outback Dingo > wrote: > >> of c

Re: Native Encryption for ZFS on FreeBSD CFT

eebsd_crypto.c:62:19: > error: tentative definition has type 'struct mtx' that is never > completed > static struct mtx freebsd_crypto_mutex; > ^ > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: > note: forward decl

Re: Native Encryption for ZFS on FreeBSD CFT

On Tue, Aug 21, 2018 at 20:22 Alan Somers wrote: > On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote: > >> On Aug 21, 2018, at 8:11 PM, Alan Somers wrote: >> > The last time I looked (which was a long time ago), Oracle's ZFS >> encryption looked extremely vulnerable to watermarking attacks. Did

Re: Native Encryption for ZFS on FreeBSD CFT

On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote: > To anyone with an interest in native encryption in ZFS please test the > projects/zfs-crypto-merge-0820 branch in my freebsd repo: > https://github.com/mattmacy/networking.git > > Oh and I neglected to state that this work is

Native Encryption for ZFS on FreeBSD CFT

To anyone with an interest in native encryption in ZFS please test the projects/zfs-crypto-merge-0820 branch in my freebsd repo: https://github.com/mattmacy/networking.git ( git clone https://github.com/mattmacy/networking.git -b projects/zfs-crypto-merge-0820 ) The UI is quite close to the Orac

drm / drm2 removal in 12

Just in case anyone misses the change to UPDATING: 20180821: drm and drm2 have been removed. Users on powerpc, 32-bit hardware, or with GPUs predating Radeon and i915 will need to install the graphics/drm-legacy-kmod. All other users should be able to use one of the

Re: panic excl->shared for an AF_LOCAL socket

On Sun, Aug 19, 2018 at 4:32 PM Rick Macklem wrote: > Hi, > > PR#230752 shows a witness panic() for "excl->shared" on a vnode lock. > In this case, the kernel RPC code is trying to do a soconnect() on an > AF_LOCAL > socket. The code is unp_connectat() looks like is does a straightforward > namei

Re: Sharing compiled builds between multiple 12-CURRENT boxes.

freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP specified. Cheers, Matthew signature.asc Description: OpenPGP digital signature

Re: kernel build failure

On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem wrote: > Rodney W. Grimes wrote: > >> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote: > >> > >> > Sorry guys, last time I touched ZFS I tried to push to make it an > option to > >> > statically lin

Re: kernel build failure

On Sun, Aug 12, 2018 at 3:25 PM Warner Losh wrote: > > > On Sun, Aug 12, 2018, 3:40 PM Matthew Macy wrote: > >> Sorry guys, last time I touched ZFS I tried to push to make it an option >> to >> statically link and was actually told that it wasn't something any

Re: kernel build failure

Sorry guys, last time I touched ZFS I tried to push to make it an option to statically link and was actually told that it wasn't something anyone else wanted. The issue comes from ZFS not being in NOTES and thus not in LINT. -M On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl < trond.endres...@fa

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

0, rsp = 0, rbp = 0 --- > db> > > > Li-Wen > > On Mon, Aug 6, 2018 at 9:53 AM Alan Somers wrote: > > > > I can't reproduce the failure. On my VM, with a kernel from Aug-2, the > test passes. But it sure seems to be consistent in Jenkins. > > > >

Re: panic after ifioctl/if_clone_destroy

The struct thread is typesafe. The problem is that the link is no longer typesafe now that it’s not part of the thread. Thanks for pointing this out. I’ll commit a fix later today. -M On Mon, Aug 6, 2018 at 02:39 Hans Petter Selasky wrote: > Hi Matthew, > > On 08/06/18 10:02, Ha

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

That looks like it is tied to changes I made 3 months ago. I won't be at my desk until the end of the week, but if it's consistent I can take a look. -M On Sun, Aug 5, 2018 at 17:57 Li-Wen Hsu wrote: > On Sun, Aug 5, 2018 at 6:23 PM Mark Millard wrote: > > > > amd64: #8493 was for -r337342 and

Re: panic after ifioctl/if_clone_destroy

If you could give me a self-contained reproducer that would expedite a fix. Thanks. -M On Sun, Aug 5, 2018 at 08:36 Roman Bogorodskiy wrote: > Running -CURRENT r336863 on amd64. Get the following panic right after > (or during) boot: > > Fatal trap 12: page fault while in kernel mode > cpuid =

Re: [PATCH] Recent libm additions

On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen wrote: > On 07/15/2018 02:09 PM, Warner Losh wrote: >> I'm not saying that he has a lock. I'm saying he's are domain expert and >> many mistakes can be avoided by talking to him. >> >> I'm saying we have history here, and that history, wh

Re: [PATCH] Recent libm additions

On Sun, Jul 15, 2018 at 11:33 AM, Steve Kargl wrote: > On Sun, Jul 15, 2018 at 12:06:47PM -0600, Ian Lepore wrote: >> >> On the other hand, what information is there for someone to know that >> Steve should be involved in a review? There is nothing in MAINTAINERS. >> The review was on phab for alm

Re: [PATCH] Recent libm additions

On Sun, Jul 15, 2018 at 10:17 AM, Steve Kargl wrote: > On Sun, Jul 15, 2018 at 11:00:41AM -0600, Ian Lepore wrote: >> On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote: >> > Index: ld80/e_powl.c >> > === >> > --- ld80/e_powl.c (r

Re: [PATCH] Recent libm additions

On Sun, Jul 15, 2018 at 10:55 AM, Warner Losh wrote: > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > >> > >> > Well, actually, the functions in polevll.c should have been copied >> > into ld80/e_powl.c, and polevall.c should never have been committed. >> > Unfortunately, the code was not review

Re: atomic changes break drm-next-kmod?

This seems like a clang inline asm bug. Could you try building the port with a recent gcc against an unpatched HEAD? On Tue, Jul 3, 2018 at 15:38 Pete Wright wrote: > > > On 07/03/2018 15:29, John Baldwin wrote: > > That seems like kgdb is looking at the wrong CPU. Can you use > > 'info threads

Re: atomic_testandclear_, atomic_testandset_

On Sun, Jun 24, 2018 at 01:42 Konstantin Belousov wrote: > On Sat, Jun 23, 2018 at 01:38:07PM -0700, Matthew Macy wrote: > > It turns out ck already has equivalent primitives. Pardon the noise. > Why not to add trivial cmpset-based implementations to the lacking > arches ? If mai

Re: atomic_testandclear_, atomic_testandset_

It turns out ck already has equivalent primitives. Pardon the noise. -M On Sat, Jun 23, 2018 at 12:18 Matthew Macy wrote: > The functions in the subject are both documented in atomic(9) and are > implemented by every arch except sparc64 and MIPS. I have some code in > review that

atomic_testandclear_, atomic_testandset_

The functions in the subject are both documented in atomic(9) and are implemented by every arch except sparc64 and MIPS. I have some code in review that uses them that I intend to commit once the various design issues are addressed. Please implement them so that those targets can remain part of uni

Re: Page fault in udp_usrreq.c:823

org > > The need of the many outweighs the greed of the few. > > > In message il.com> > , Matthew Macy writes: >> Try updating. It should be fixed. >> >> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert wrot >> e: >> > In message <201

  1   2   3   4   5   6   7   8   9   10   >