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: 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: 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: 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: 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

the Oracle buyout. > > > On Dec 18, 2018, at 10:49 PM, 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 Solaris Portability Layer

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: 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 I heard the voice of > > > Steve

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: 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, Hans Petter Sela

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

Re: Page fault in udp_usrreq.c:823

Try updating. It should be fixed. On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert wrote: > In message <20180620090957.ga...@x2.osted.lan>, Peter Holm writes: >> 20180620 10:32:47 all (1/1): udp.sh >> Kernel page fault with the following non-sleepable locks held: >> shared rw udpinp (udpinp) r = 0 (0

Re: rust broken?

tup will only work on 11. This is why you need to use the port / pkg. -M > I missed that in the comparison between my two build environments :-( > > Michael > > On 06/07/18 13:21, Matthew Macy wrote: > > > > Rustup uses the 11 ABI. > > > &

Re: rust broken?

Rustup uses the 11 ABI. On Thu, Jun 7, 2018 at 10:11 Alan Somers wrote: > Can you reproduce the problem using rust installed from rustup instead of > from Ports? If so, you should file a bug report with the Rust developers. > Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of

Re: rust broken?

On Thu, Jun 7, 2018 at 10:50 Michael Butler wrote: > On 06/07/18 13:36, Matthew Macy wrote: > > On Thu, Jun 7, 2018 at 10:33 Michael Butler > <mailto:i...@protected-networks.net>> wrote: > > > > Ah - I'll re-enable that to see if it makes a difference

Re: [RFC] Deprecation and removal of the drm2 driver

Implementing a callback in 140 different files for the sake of a handful of out of tree drivers and people not reading updating is pretty prohibitive. 11 may be more your cup of tea. On Mon, Jun 4, 2018 at 22:27 Adrian Chadd wrote: > Hi, > > If there's an API that isn't being used then great, I'

Re: [RFC] Deprecation and removal of the drm2 driver

On Mon, Jun 4, 2018 at 12:03 PM, Adrian Chadd wrote: > Hi, > > As a driver/framework developer - no, don't do that. > > It's worked mostly great for the video side of things because your > touch points are "the VM system" and "linuxkpi". And they're all in > one big driver pull from Linux. > > For

Re: how to deal with variable set but not used warnings?

On Sun, Jun 3, 2018 at 2:40 PM, Theron wrote: >> 4. Disable the stupid warning in the Makefile / build system. If you don't >> care, and there's a good reason for what you are doing (sounds like there >> is), better to just disable the warning as so much useless noise. >> >> Warner >>

hwpmc - wither ppro and p4

Intel now provides comprehensive tables for all performance counters and the various valid configuration permutations as text .json files. I've converted libpmc to use these and simplified the hwpmc_core to pass the values through. I'd like to remove all the existing Intel tables from the kernel. T

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

> A flame graph for the core cycle count and a flame graph with cache miss > stats from pmc would be a great start. > > > ​I didn't know the exact event name to use for cache miss stats, but here > are the flame graphs for CPU_CLK_UNHALTED_CORE: > http://dev.bsdrp.net/netgate.r311848.C

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

> > > My tunning are (same for both test): > > > hw.igb.rxd="2048" (it should be useless now) > > > hw.igb.txd="2048" (it should be useless now) > > Matt: I think he meant "useless now" because there is no igb, and the > below hw.em version covers it. No. igb still exists and the old t

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

> > I can generate profiling data for you: what kind of data do you want ? > > > A flame graph for the core cycle count and a flame graph with cache miss stats from pmc would be a great start. ___ freebsd-current@freebsd.org mailing list http

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

You can still explicitly set the number of descriptors. It is now reported under the dev sysctl tree. dev... -M On Wed, 11 Jan 2017 12:34:23 -0800 Olivier Cochard-Labbé wrote > > On Wed, Jan 11, 2017 at 9:13 PM, Matthew Macy wrote: > > > Hmmm ... did your

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On Wed, 11 Jan 2017 12:02:06 -0800 Sean Bruno wrote > > > On 01/11/17 12:47, Olivier Cochard-Labbé wrote: > > On Wed, Jan 11, 2017 at 4:17 PM, Sean Bruno > > wrote: > > > > > > > > Olivier: > > > > Give this a quick try.

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

> > x head r311848: packets per second > + head r311849 and BAR patch: packets per second > +--+ > |++++ + xxx x x| > |

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On Wed, 11 Jan 2017 01:23:46 -0800 Olivier Cochard-Labbé wrote > On Tue, Jan 10, 2017 at 4:31 AM, Sean Bruno wrote: > > > > > I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on > > IFLIB in the kernel. > > > > At this point, the driver deviates from Int

Re: CURRENT: em0 NIC freezes under heavy I/O on net

Sorry, I meant to send that to the other thread. Was this after the iflib driver commit? If so it's odd that we haven't seen anything like this and I'll try to get a fix in ASAP. On Wed, 11 Jan 2017 03:06:19 -0800 Me wrote It looks like I have the wrong m

Re: CURRENT: em0 NIC freezes under heavy I/O on net

It looks like I have the wrong msix bar value for your NIC. Will fix in the next day or so.-M On Wed, 11 Jan 2017 00:27:30 -0800 O. Hartmann wrote Running recent CURRENT (FreeBSD 12.0-CURRENT #5 r311919: Wed Jan 11 08:24:28 CET 2017 amd64), the system fr

Re: PQ_LAUNDRY: unexpected behaviour

Thanks. Pete already filed that as part of #108. With luck markj@ will have that fixed this weekend. -M On Fri, 06 Jan 2017 11:24:00 -0800 Jonathan Anderson wrote > On 6 Jan 2017, at 14:06, Matthew Macy wrote: > > > kernel cores tend to be large (all of wired

Re: PQ_LAUNDRY: unexpected behaviour

10:53:03 -0800 Pete Wright wrote > > > On 1/6/17 10:44 AM, Jonathan Anderson wrote: > > On 6 Jan 2017, at 12:48, Pete Wright wrote: > > > >> On 1/6/17 9:14 AM, Matthew Macy wrote: > >>> > >>> I just did

Re: PQ_LAUNDRY: unexpected behaviour

> > Please try the drm-next branch now. Up until very recently, the > > shrinkers responsible for culling ttm/gem allocations were never run. > > I've now implemented the shrinker, but it's driven from vm_lowmem, so > > you'll probably still see what looks like a leak until you hit low

Re: PQ_LAUNDRY: unexpected behaviour

On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson wrote > Hi all, > > I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close > to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of > not-quite-CURRENT, it's also very possible that I

drm-next update and longer term plans

I imagine that for most users the state of graphics support for post-Haswell hardware is a bit of a black box so I'm sending out this note to let users know what they can and cannot expect. Wayland has actually become a reality for some. Talk to Johannes Lundberg if you're interested in tracki

warning errors with buildworld with llvm39

I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= as the llvm has added additional warnings since 3.8. https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01 The most prevalent seems to be: jemalloc_nstime.c:120:7: warning: macro expansion producing 'defined'

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis wrote > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: > > It looks like there is something broken with the devel/llvm38 port or > > external toolchain support has regressed: > >

  1   2   >