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

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

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

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

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

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

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

4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

I'm happy to announce a call for testers for the 4.6 update of drm and i915. The driver has been successfully tested on IvyBridge, Haswell, Broadwell and Skylake. At least basic HW 3D acceleration should work, VGA and DP out are known to work. Video decode has only been tried once and that did

4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

I'm happy to announce a call for testers for the 4.6 update of drm and i915. The driver has been successfully tested on IvyBridge, Haswell, Broadwell and Skylake. At least basic HW 3D acceleration should work, VGA and DP out are known to work. Video decode has only been tried once and that did not

Update on CFT error reporting

To improve the user experience I disabled debug logging by default. Before reporting a non-fatal error with i915 load the drm2 module first, then: sysctl dev.drm.drm_debug=-1 to enable full logging. Once you have done that you can then load i915. The "unimplemented" and "dodgy" warnings are exp

Note on CFT image

On Sun, 22 May 2016 11:27:28 -0700 Matthew Macy wrote > To improve the user experience I disabled debug logging by default. Before > reporting a non-fatal error with i915 load the drm2 module first, then: > sysctl dev.drm.drm_debug=-1 to enable full logging. Once

Re: pkg chroot issues?

On Sun, 22 May 2016 13:43:13 -0700 Tim Kientzle wrote > > > On May 22, 2016, at 1:28 PM, K. Macy wrote: > > > > > > > > On Sunday, May 22, 2016, Tim Kientzle wrote: > > Crochet has some experimental hooks to install packages onto the system > > being built, but

CFT update day 2

The highlights for today are the following: Bug fixes: - Will Andrews fixed attach for some laptops (such as the Carbon X1). The Carbon X1 has a quirky BIOS that doesn't allow the OS to enumerate the GPU's interrupt. - Will Andrews identified a conditionally uninitialized return in idr_find

Re: CFT update day 2

> > And as a reminder, if you're having problems with X on the USB > key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf > somewhere else on your file system. This change switches from SNA to UXA which may fix problems for some. > > If using the github repo, make sur

Re: CFT update day 2

Xorg - there are some rendering issues (pink lines, weird transparency where there should be no transparency), but I don't know if these are related to i915, the experimental xf86-video-intel driver or the software renderer On 2016-05-23 10:12, Matthew Macy wrote: > The highlights for

Re: CFT update day 2

sing, I may try patching them in tomorrow if I can find out what exactly is missing. On 2016-05-23 23:21, Matthew Macy wrote: > Have you tried with the xf86-intel in ports. That actually works > better for most. Also try SNA. What does pciconf -lvbc show for > graphics? > >

Re: CFT update day 2

hat exactly is > missing. Try working with the ports people. The module load and missing pciids are a ports problem. The outputs not working and visual artifacts are mine. -M > On 2016-05-23 23:21, Matthew Macy wrote: > > Have you tried with the xf86-intel in ports. That a

Re:CFT update day 2

dy present: > > http://sw.gddsn.org.cn/freebsd/drm-4.6-next-panic.jpg That should be easy to fix. However, I wont have time to get to it for a day or two. Could you please file a PR and assign it to me? I think that I can have that fixed by the next update. -M > > At 20

Note on filing bugs found in the CFT

I had previously told testers to file bugs in bugzilla. But the sheer numbers that are already there make it a bit heavyweight. In the future please file issues in the github issue tracker for our repo. Thanks. -M ___ freebsd-current@freebsd.org mai

Re: Note on filing bugs found in the CFT

On Tue, 24 May 2016 13:30:12 -0700 Matthew Macy wrote > > I had previously told testers to file bugs in bugzilla. But the sheer > numbers that are already there make it a bit heavyweight. In the future > please file issues in the github issue tracker for our

Re: CFT update day 2

the changes to sys to support this. If dates are interpreted as being UTC then it's already started. -M > > On May 23, 2016 4:12:52 AM EDT, Matthew Macy wrote: > > > >The highlights for today are the following: > > > >Bug fixes: > >- Will

Re: CFT update day 2

08, Eric McCorkle wrote: > > > > Letting you know, I had an error in detection. I'm trying to get a change > > done before code slush, but I will circle back and provide a detailed > > report > > > >> On May 23, 2016 4:12:52 AM EDT, Matt

Re: r300951 make buildworld duration 18h

On Mon, 30 May 2016 07:37:26 -0700 Matthias Apitz wrote > > Hello, > > Yesterday I pulled via svn co ... a fresh r300951 and started the buildworld > as > > # make -j2 buildworld > > it ended today at lunchtime after 18 hours. The laptop has 2x Intel Atom > 1.6GHz

Re: repeatable panic on pageout with 945GM

Tell me if that makes any difference. -M On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote > It looks like it might be trying to remove mappings for a page that doesn't > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem > release mmap. Compile the kernel and

Re: repeatable panic on pageout with 945GM

> > Slight variation -won't build as above; trying with "pmap_page_is_mapped(m)" > Oops copy pasta + serious fatigue. But you got the right idea. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freeb

Re: PostgreSQL performance on FreeBSD

> >>> A couple small steps have been taken toward eliminating the need for > >>> this > >>> hack: the addition of the "page size index" field to struct vm_page and > >>> the > >>> addition of a similarly named parameter to pmap_enter(). However, at > >>> the > >>> moment, the only ta

latest memstick image fails to mountroot by default on Thinkpad e565

In order to boot USB reliably on recent laptop hardware (both my thinkpad and XPS13 need this) you need to add the following to the installer images loader.conf: kern.cam.boot_delay="1" kern.cam.scsi_delay="3000" ___ freebsd-current@freebsd.org

Re: repeatable panic on pageout with 945GM

> > This "band-aid" seems to have worked. I haven't had a single panic since > - Thanks! :-) > > I tried to compile with -O0 but, for some reason, it panics in the sound > driver with a double-fault. When I get time, I'll recompile only the > files involved and see if I can't ge

Re: latest memstick image fails to mountroot by default on Thinkpad e565

On Sat, 04 Jun 2016 06:03:49 -0700 Edward Tomasz Napierała wrote > Dnia 04.06.2016 o godz. 07:52 Matthew Macy napisał(a): > > > > > In order to boot USB reliably on recent laptop hardware (both my thinkpad > > and XPS13 need this) you need to

Re: repeatable panic on pageout with 945GM

> > I believe that this is a bug in amd64 pmap. Fictitious pages are not > promoted, in particular, the pv_table array does not span over the > dynamically registered fictitious ranges. As result, pa_to_pvh() returns > garbage and pvh must not be accessed in the case of 'small_mappings'

Re: VirtualBox network connectivity broken on recent -CURRENT

On Sat, 04 Jun 2016 19:04:42 -0700 Randy Westlund wrote > On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote: > > It looks like something changed in -CURRENT to break network > > connectivity to VirtualBox guests. This was last known to work with > > r299139 (May 6th

Re: HWPMC on SkyLake

I think rrs@ may have done it.Randall? On Tue, 14 Jun 2016 08:06:55 -0700 Doug Rabson wrote Did you get any feedback on this? I would like to be able to use hwpmc but my desktop is a recent skylake and I also get the 'hwpc_core: unknown PMC architecture:

Re: Kqueue races causing crashes

You can use dwarf4 if you use GDB from ports  On Wed, 15 Jun 2016 04:50:00 -0700 Peter Holm wrote On Wed, Jun 15, 2016 at 11:11:43AM +0300, Konstantin Belousov wrote: > On Tue, Jun 14, 2016 at 10:26:14PM -0500, Eric Badger wrote: > > I believe they all ha

Re: Kqueue races causing crashes

On Wed, 15 Jun 2016 10:45:24 -0700 Konstantin Belousov wrote > On Wed, Jun 15, 2016 at 10:39:42AM -0700, Matthew Macy wrote: > > > > > > > > > > You can use dwarf4 if you use GDB from ports >

Mapping drm's OBJT_DEFAULT causes crash on munmap

Clicking 2 times on the following WebGL demo will cause a panic using drm 3.8/4.6 (this particular usage of OBJT_DEFAULT is one of the few remaining pieces of shared code). http://myshards.com/ This is the backtrace from HEAD as of f1bd70502f890a8668985030c0aecc3aeacb10ac running the latest

Skylake PMC support?

Does anyone have PMC patches for Skylake? Thanks in advance. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic with tcp timers

You guys should really look at Samy Bahra's epoch based reclamation. I solved a similar problem in drm/linuxkpi using it. -M On Tue, 28 Jun 2016 02:58:56 -0700 Julien Charbon wrote > > Hi Randall, > > On 6/25/16 4:41 PM, Randall Stewart via freebsd-net wrote: > > Ok

EBR fix for life cycle races was Re: panic with tcp timers

On Tue, 28 Jun 2016 15:51:57 -0700 K. Macy wrote > On Tue, Jun 28, 2016 at 10:51 AM, Matthew Macy wrote: > > You guys should really look at Samy Bahra's epoch based reclamation. I > > solved a similar problem in drm/linuxkpi using it. > > The

Re: EBR fix for life cycle races was Re: panic with tcp timers

On Tue, 28 Jun 2016 23:19:45 -0700 Matthew Macy wrote > > > > On Tue, 28 Jun 2016 15:51:57 -0700 K. Macy wrote > > > On Tue, Jun 28, 2016 at 10:51 AM, Matthew Macy wrote: > > > > You guys should really look at Sam

difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

As a first step towards managing linux user space in a chrooted /compat/linux, initially for i915 testing with intel gpu tools, later on to get widevine and steam to work I'm trying to get apt to work. I've fixed a number of issues to date in pseudofs/linprocfs but now I'm running in to a bug ca

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov wrote > On 07.07.2016 7:52, K. Macy wrote: > > On Wednesday, July 6, 2016, Don Lewis wrote: > > > >> On 6 Jul, Matthew Macy wrote: > >>> As a first step towards managing linux user

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov wrote > On 07.07.2016 9:40, Matthew Macy wrote: > > > > > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov > > wrote > > > On 07.07.2016 7:52, K. Ma

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

On Thu, 07 Jul 2016 07:04:24 -0700 Konstantin Belousov wrote > On Thu, Jul 07, 2016 at 12:14:52AM -0700, Don Lewis wrote: > > On 6 Jul, Matthew Macy wrote: > > > > > > > > > > > > On Wed, 06 Jul 2016

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

> Unsurprisingly I may have misinterpreted the trace. > > John observes: > Alternatively, if apt is creating a pipe() that it passes to dpkg() via > fork() and apt > only creates the read end opened and dpkg only keeps the write end up > opened, then when > dpkg exits, the pipe_r

Re: Recent -current stable panic at later boot stage

On Sat, 09 Jul 2016 18:19:57 -0700 Andrey Chernov wrote > BTW, it never happens with 11-ALPHA3 even with world build for 12. > > On 09.07.2016 22:06, Andrey Chernov wrote: > > SCHED_ULE used. I have textdump only. Interesting parts: > > <118>Starting syslogd. > > kernel

callout_drain either broken or man page needs updating

Upon updating my drm-next branch to the latest -CURRENT callout_drain returning no longer means that the function was in fact pending when it was called. This little bit of code will panic because dwork->wq is NULL, because the callout was _not_ in fact enqueued. So either it's no longer possi

Re: refcnt 0 on LLE at boot....

On Thu, 07 Jul 2016 06:36:19 -0700 Larry Rosenman wrote > Thanks for that. I've added myself to the cc list, and a comment about > having 2 vmcore's. > This was introduced by 302350. It broke the return value of callout_{stop,drain}. returning 1 even if the callout system

Re: callout_drain either broken or man page needs updating

On Thu, 14 Jul 2016 21:21:57 -0700 Hans Petter Selasky wrote > On 07/15/16 05:45, Matthew Macy wrote: > > glebius last commit needs some further re-work. > > Hi, > > Glebius commit needs to be backed out, at least the API change that > chang

Re: callout_drain either broken or man page needs updating

On Fri, 15 Jul 2016 01:43:03 -0700 Gleb Smirnoff wrote > On Thu, Jul 14, 2016 at 10:14:46PM -0700, Matthew Macy wrote: > M> > On 07/15/16 05:45, Matthew Macy wrote: > M> > > glebius last commit needs some further re-work. > M> > &

Re: 4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

> > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > When is a Broadwell support supposed

Re: RoCE v2 on FreeBSD

On Thu, 14 Jul 2016 10:31:40 -0700 David Somayajulu wrote > Hi All, > Does FreeBSD support RoCE v2 ? > Thanks > David S. FreeBSD has OFED support. Does OFED support RoCE v2? -M ___ freebsd-current@freebsd.org mailing list http

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

On Mon, 18 Jul 2016 16:11:53 -0700 Alfred Perlstein wrote > I believe the > > > On 7/6/16 9:34 PM, Matthew Macy wrote: > > As a first step towards managing linux user space in a chrooted > > /compat/linux, initially for i915 testing with i

drm-4.7-rc1 tagged

A few days ago I branched drm-next-4.6 in to drm-next and synced it with Torvalds' tree as of the v4.6 tag. I then integrated the ~800 commits to drm / i915 / radeon / amdgpu , testing periodically along the way and updating the linuxkpi as needed. I've just tagged the drm-next branch with drm-

Re: Wayland work status

> > ​Wayland relies on kqueue which is not implemented in drm's 3.8 or 4.6 > branches. I'm working on this now for drm-next-4.6 and it is almost > complete. > I will probably implement it also in the 3.8 ​branch to be able to run > Wayland on both to compare and find bugs in linuxkpi more e

drm-4.7-final tagged - CFT for drm-next was Re: drm-4.7-rc1 tagged

not show corruption, but requires the use of a compositor to avoid tearing to keep frame updates in sync with screen refresh. The scope of my personal testing is limited so please report any regressions with respect to drm-next-4.6. On Fri, 12 Aug 2016 00:21:02 -0700 Matthew M

gfx-next update: drm-4.8-rc2 tagged in drm-next

As of this moment sys/dev/drm in the drm-next tree is sync with https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the subset of drivers that FreeBSD supports - i915, radeon, and amdgpu). I feel this is a bit of a milestone as it means that it is possible that in the future grap

Re: gfx-next update: drm-4.8-rc2 tagged in drm-next

phics. > > Thanks in advance. > > Tomoya > > On Tue, Aug 16, 2016 at 12:12:44AM -0700, Matthew Macy wrote: > > As of this moment sys/dev/drm in the drm-next tree is sync with > > https://github.com/torvalds/linux drivers/gpu/drm (albeit only for t

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

It looks like there is something broken with the devel/llvm38 port or external toolchain support has regressed: This works: make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s This fails: make XCC=/usr/local/bin/clang38 XCXX=/usr

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

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'

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

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

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

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

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

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

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

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

> 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

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

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

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

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

  1   2   >