DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-02-08T23:53:40ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3343 (Closed): New cookie_* functions in stdio.h should be guarded by somethinghttps://bugs.dragonflybsd.org/issues/33432023-02-08T23:53:40Zdavshao
<p>fopencookie(3): Add a wrapper around funopen(3)<br />commit a765cedf26cef470ba7deee42c365f0221690a1a<br />Date: Sat Feb 4 14:54:20 2023 +0100</p>
<p>changed /usr/include/stdio.h to add</p>
<p><ins>typedef ssize_t (cookie_read_function_t)(void *, char *, size_t);<br />+typedef ssize_t (cookie_write_function_t)(void *, const char *, size_t);<br />+typedef int (cookie_seek_function_t)(void *, off64_t *, int);<br />+typedef int (cookie_close_function_t)(void *);<br />+typedef struct {<br /></ins> cookie_read_function_t *read;<br />+ cookie_write_function_t *write;<br />+ cookie_seek_function_t *seek;<br />+ cookie_close_function_t *close;<br />+} cookie_io_functions_t;<br />+FILE *fopencookie(void *, const char *, cookie_io_functions_t);</p>
<p>These new functions are guarded by nothing, yet ssize_t has a definition<br />in the same header file guarded by something. Trying to build say png,<br />the compile is confused about ssize_t, among other things. For now, moving</p>
<p>#endif /* __BSD_VISIBLE */</p>
<p>to cover the new functions and structs allows png to build, but I<br />cannot guarantee other packages will regard this as sufficient.</p> DragonFlyBSD - Bug #3325 (Closed): Revert sys/vfs/hammer2: Properly set rdonly flag for PFShttps://bugs.dragonflybsd.org/issues/33252022-09-10T18:20:37Zdavshao
<p>After <br />sys/vfs/hammer2: Properly set rdonly flag for PFS<br />commit 5f5122fa2471887600e87e29917d577f65d73a05<br />Date: Wed Sep 7 00:11:28 2022 -0700</p>
<p>the system boots but there are read(only) errors reported with ttys not created, dhcp not working, etc.<br />Bisected to this particular commit.</p>
<p>Maybe unusual these days, I am using grub2 to boot from an ssd (not nvme) formatted mbr.</p>
<p>Here is the /etc/fstab:</p>
<ol>
<li>Device Mountpoint FStype Options Dump Pass#<br />/dev/serno/2017E29D5A8C.s1a /boot ufs rw 2 2<br />/dev/serno/2017E29D5A8C.s1b none swap sw 0 0<br />/dev/serno/2017E29D5A8C.s1d / hammer2 rw 1 1<br />/build/usr.obj /usr/obj null rw 0 0<br />/build/var.crash /var/crash null rw 0 0<br />/build/var.cache /var/cache null rw 0 0<br />/build/var.spool /var/spool null rw 0 0<br />/build/var.log /var/log null rw 0 0<br />/build/var.tmp /var/tmp null rw 0 0<br />tmpfs /tmp tmpfs rw 0 0<br />proc /proc procfs rw 0 0</li>
</ol>
<p>$ uname -a<br />DragonFly xxxxxx 6.3-DEVELOPMENT DragonFly v6.3.0.196.g64e301-DEVELOPMENT #0: Sat Sep 10 10:28:47 PDT 2022 xxxxxx@xxxxxx:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64</p> DragonFlyBSD - Submit #3244 (Resolved): Additional Intel I219-LM and I219-V Ethernet PCI device n...https://bugs.dragonflybsd.org/issues/32442020-08-19T03:06:01Zdavshao
<p>NetBSD current sys/dev/pci/pcidevs.h has additional PCI device numbers for Intel I219-LM and Intel I219-V Ethernet. Simply adding these numbers has been verified to enable em0 on an Asus Prime H470-Plus mATX motherboard for I219-V11 0x0D4D. Also NetBSD current had no problem activating its wm0 Ethernet device for this motherboard.</p>
<p>Note that Phoronix had an article "DragonFlyBSD vs. FreeBSD vs. Ubuntu 20.04 On Intel's Core i9 10900K Comet Lake" that noted on-board Ethernet was not functional on either FreeBSD 12 or DragonFly BSD, and that claimed that even for Linux, 5.6 or later was required. That claim may be incorrect for at least obtaining some minimal functionality on DragonFly for very little effort.</p>
<p>Attached is a patch adding the numbers from NetBSD. The naming of the devices using "CNP", which I believe is an abbreviation for previous generation codename Cannon Point chipsets, is arguably incorrect; however, I was unable to locate any code name at all for current series 400 Intel chipsets. In any case, for at least one device, the Cannon Point handler appears to work unchanged.</p> DragonFlyBSD - Submit #3145 (Closed): Update libelf to FreeBSD 12 current and build as base libra...https://bugs.dragonflybsd.org/issues/31452018-09-04T06:55:37Zdavshao
<p>DragonFly dports graphics/mesa-dri has</p>
<p><code>LIB_DEPENDS+= libelf.so:devel/libelf</code></p>
<p>FreeBSD links with its own base libelf and does not use ports devel/libelf.<br />FreeBSD is right in its approach. ports devel/libelf and base libelf are<br />different code bases. Ports or pkgsrc devel/libelf appears to have problems<br />with modern mesa. This can be seen using some Radeon graphics cards where<br />Firefox with<br /><code>user_pref("layers.acceleration.force-enabled", true);</code><br />results in a completely black window when trying to start Firefox with<br />something like<br /><code>LD_PRELOAD=/usr/local/lib/libGL.so firefox &</code><br />What is notable about this patch is just how little the result will<br />differ from FreeBSD 12 current's version.</p> DragonFlyBSD - Submit #3031 (Closed): Update drm/radeon to Linux 4.7.10 as much as possiblehttps://bugs.dragonflybsd.org/issues/30312017-04-27T04:00:18Zdavshao
<p>Sometimes one must go backwards before one can go forwards. The attached patch updates drm/radeon to Linux 4.7.10 as much as possible, with the obvious exception of patches related to dma_fence, reservation objects, dma_buf, prime, DisplayPort MST, and interval trees. In particular, because I do not have DisplayPort hardware to test, I expect complete breakage.</p>
<p>When I want decent font display without corruption on a CAICOS Sapphire Radeon HD6450 card, I use in a hacked version of pkgsrc for mesa 17 in /usr/pkg/share/X11/xorg.conf.d a 20-glamor.conf file resembling:</p>
<pre>
Section "Module"
Load "dri2"
Load "glamoregl"
EndSection
Section "Device"
Identifier "Radeon Graphics"
Driver "radeon"
Option "AccelMethod" "glamor"
Option "ShadowPrimary" "on"
EndSection
</pre>
<p>Take out the Option "ShadowPrimary" "on" and there are quite visible artifacts, but I am still able to fire up firefox using</p>
<p><code>LD_PRELOAD=/usr/pkg/lib/libGL.so firefox &</code></p>
<p>with layers acceleration forced to get some sort of display in WebGL Water:</p>
<p><a class="external" href="http://madebyevan.com/webgl-water/">http://madebyevan.com/webgl-water/</a></p>
<p>The patch is radeon47fast.patch generated by git format patch. Also attached is a diff between drm/radeon after the patch compared to Linux 4.7.10's. radeon_4_07.diff shows exactly what is left to be done.</p>
<p>The patch seems to apply cleanly up through at least</p>
<pre>
commit f30091155bf042c3e2934ca63573dabebe30f556
Date: Mon Apr 24 19:22:39 2017 +0200
<fcntl.h>: Add some missing defines (required by POSIX).
</pre> DragonFlyBSD - Submit #3026 (Resolved): Patch to enable HDMI audio for Gigabyte Radeon R7 240https://bugs.dragonflybsd.org/issues/30262017-04-13T01:27:10Zdavshao
<p>In a years old thread</p>
<p>amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)</p>
<p><a class="external" href="https://lists.freebsd.org/pipermail/freebsd-current/2010-July/018764.html">https://lists.freebsd.org/pipermail/freebsd-current/2010-July/018764.html</a></p>
<p>Andriy Gapon suggested the following patches to enable HDMI audio for<br />an ATI/AMD video card. But at that time the original poster was not<br />able to actually get the sound device to properly attach.</p>
<p>Well these patches DO work for DragonFly, at least using a custom kernel<br />starting from master sometime in the last couple of weeks with<br />radeon audio patches from Linux 4.7.10 (adding radeon_audio.c and radeon_audio.h<br />and updating everything related).</p>
<p>I startx using xfce4 and a custom version of pkgsrc with mesa 17, xorg server 19.3</p>
<ol>
<li>kldload snd_hda</li>
</ol>
<p>Read the end of dmesg:</p>
<p>[drm] Initialized radeon 2.40.0 20080528<br />hdac0: <Intel Panther Point HDA Controller> mem 0xf7f10000-0xf7f13fff irq 22 at device 27.0 on pci0<br />hdac0: link ctrl 0x800<br />hdac0: disable nosnoop<br />hdac1: <ATI (0xaab0) HDA Controller> mem 0xf7e60000-0xf7e63fff irq 17 at device 0.1 on pci2<br />hdac1: link ctrl 0x2800<br />hdac1: disable nosnoop<br />hdacc0: <VIA VT1708S_0 HDA CODEC> at cad 0 on hdac0<br />hdaa0: <VIA VT1708S_0 Audio Function Group> at nid 1 on hdacc0<br />hdacc1: <ATI R6xx HDA CODEC> at cad 0 on hdac1<br />hdaa1: <ATI R6xx Audio Function Group> at nid 1 on hdacc1<br />pcm0: <VIA VT1708S_0 (Analog 7.1+HP/2.0)> at nid 28,34,25,35,29 and 26,30,27 on hdaa0<br />pcm1: <VIA VT1708S_0 (Digital)> at nid 32 on hdaa0<br />pcm2: <VIA VT1708S_0 (Rear-panel Digital)> at nid 33 on hdaa0<br />pcm3: <ATI R6xx (HDMI)> at nid 3 on hdaa1</p>
<ol>
<li>sysctl hw.snd.default_unit=3<br />hw.snd.default_unit: 0 -> 3</li>
</ol>
<p>fire up firefox, go to youtube and listen to whatever.</p>
<p>The following patches are safer for DragonFly because by default<br />no sound drivers are loaded. Original poster actually had<br />kernel crashes because on his version of FreeBSD sound drivers<br />were automatically loaded. Also there was a claim at the time,<br />least if the initial value of corb_size was 0, that Linux actually does<br />do some default assumption of 256.</p>
<p>diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c<br />index d63843a10f..2178243f88 100644<br />--- a/sys/dev/sound/pci/hda/hdac.c<br />+<ins>+ b/sys/dev/sound/pci/hda/hdac.c<br /><code>@ -488,7 +488,15 </code>@ hdac_get_capabilities(struct hdac_softc *sc)<br /> else {<br /> device_printf(sc->dev, "%s: Invalid corb size (%x)\n",<br /> <i>func</i>, corbsize);<br />- return (ENXIO);<br /></ins> if (1) {<br />+ device_printf(sc->dev, "Resetting corb size to 256\n");<br />+ sc->corb_size = 256;<br />+ corbsize =<br />+ HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_256);<br />+ HDAC_WRITE_1(&sc->mem, HDAC_CORBSIZE, corbsize);<br />+ }<br />+ else<br />+ return (ENXIO);<br /> }</p>
<pre><code>rirbsize = HDAC_READ_1(&sc->mem, HDAC_RIRBSIZE);<br /><code>@ -504,7 +512,15 </code>@ hdac_get_capabilities(struct hdac_softc *sc)<br /> else {<br /> device_printf(sc->dev, "%s: Invalid rirb size (%x)\n",<br /> <i>func</i>, rirbsize);<br />- return (ENXIO);<br />+ if (1) {<br />+ device_printf(sc->dev, "Resetting rirb size to 256\n");<br />+ sc->rirb_size = 256;<br />+ rirbsize =<br />+ HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_256);<br />+ HDAC_WRITE_1(&sc->mem, HDAC_RIRBSIZE, rirbsize);<br />+ }<br />+ else<br />+ return (ENXIO);<br /> }</code></pre>
<pre><code>HDA_BOOTVERBOSE(<br /><code>@ -1211,6 +1227,8 </code>@ hdac_attach(device_t dev)<br /> if (result != 0)<br /> goto hdac_attach_fail;</code></pre>
<p>+ hdac_reset(sc, 1);<br />+<br /> /* Get Capabilities */<br /> result = hdac_get_capabilities(sc);<br /> if (result != 0)</p> DragonFlyBSD - Bug #2994 (New): Intermittent boot hangs after git: hammer - HAMMER Version 7https://bugs.dragonflybsd.org/issues/29942017-03-28T18:44:52Zdavshao
<p>Bisected to git: hammer - HAMMER Version 7<br />commit 4c09d9c4fd910651904ede280ad90a4abf3fc5d7<br />Date: Fri Mar 17 14:06:24 2017 -0700</p>
<pre><code>hammer - HAMMER Version 7</code></pre>
<p>intermittent boot hangs stopping at</p>
<p>ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/20.00, addr 5> on usb<br />ums0: 3 buttons and [XYX] coordinates ID=0<br />no B_DEVMAGIC (bootdev=0)</p>
<p>Boot proceeds normally when using verbose option which is why I can attach<br />the verbose dmesg.</p>
<p>The machine uses a refurbished Asus P8H77-V motherboard with several<br />internal hard drives with different OSes using legacy BIOS.</p>
<p>$ hammer info<br />Volume identification<br /> Label ROOT<br /> No. Volumes 1<br /> HAMMER Volumes /dev/serno/WD-WMAYP5624974.s3d<br /> Root Volume /dev/serno/WD-WMAYP5624974.s3d<br /> FSID 9d8141cd-c974-11e5-9ccd-bd5ff4499104<br /> HAMMER Version 6<br />Big-block information<br /> Total 29669<br /> Used 9119 (30.74%)<br /> Reserved 70 (0.24%)<br /> Free 20480 (69.03%)<br />Space information<br /> No. Inodes 856028<br /> Total size 232G (248881610752 bytes)<br /> Used 71G (30.74%)<br /> Reserved 560M (0.24%)<br /> Free 160G (69.03%)<br />PFS information<br /> PFS# Mode Snaps<br /> 0 MASTER 0 (root PFS)</p> DragonFlyBSD - Submit #2985 (Closed): Move drm linux_*.c files to subdirectory drm/linuxhttps://bugs.dragonflybsd.org/issues/29852017-03-22T00:47:50Zdavshao
<p>This patch moves the linux_*.c files under sys/dev/drm to their own<br />sub-directory sys/dev/drm/linux.</p>
<p>The idea is that eventually someone might want to import files<br />from FreeBSD linuxkpi. Though at some point the obvious question<br />is should these files and others added be turned into their own<br />separate module that can be used by drivers other than<br />the drm graphics ones, similar to what FreeBSD does with linuxkpi.</p>
<p>I don't really care where these files are moved: I just want them<br />moved somewhere to have their own separate identity.</p> DragonFlyBSD - Bug #2964 (Resolved): make upgrade REMOVE_OPENSSL_FILES=yes incompatible with make...https://bugs.dragonflybsd.org/issues/29642016-11-02T20:57:53Zdavshao
<p>On DragonFly master, for a previous recent build, if one does</p>
<p>make upgrade REMOVE_OPENSSL_FILES=yes</p>
<p>then updates to the latest master source, then</p>
<p>cd /usr/obj<br />mv usr usr.old<br />cd /usr/src<br />make buildworld</p>
<p>there seems a good chance one will encounter an error, really fast, such as:</p>
<p>===> bin/cpdup (bootstrap-tools)<br />/usr/obj/usr/src/btools_x86_64/usr/src/bin/cpdup created for /usr/src/bin/cpdup<br />rm -f .depend</p>
<blockquote>
<p>.depend</p>
</blockquote>
<p>mkdep -f .depend -a -std=gnu99 /usr/src/bin/cpdup/cpdup.c /usr/src/bin/cpdup/hcproto.c /usr/src/bin/cpdup/hclink.c /usr/src/bin/cpdup/misc.c /usr/src/bin/cpdup/fsmid.c /usr/src/bin/cpdup/md5.c<br />In file included from /usr/include/md5.h:41:0,<br /> from /usr/src/bin/cpdup/cpdup.h:28,<br /> from /usr/src/bin/cpdup/cpdup.c:58:<br />/usr/include/sys/md5.h:45:25: fatal error: openssl/md5.h: No such file or directory<br />compilation terminated.</p>
<p>It seems to me that cpdup.c includes "cpdup.h" which in turn includes <md5.h> if NOMD5 is undefined,<br />which in turn includes <sys/md5.h>, which in turn includes <openssl/md5.h>,<br />which after make upgrade REMOVE_OPENSSL_FILES doesn't exist anymore.</p> DragonFlyBSD - Bug #2961 (Closed): undefined reference to 'pthread_cancel' building multimedia/ff...https://bugs.dragonflybsd.org/issues/29612016-10-27T04:34:01Zdavshao
<p>I am classifying the following as a master source regression and not a dports issue because multimedia/ffmpegthumbnailer was building until yesterday without issue in a hacked version of pkgsrc I have been using. Some change from October 25 breaks building both on pkgsrc and dports.</p>
<p>To demonstrate the problem using dports, update to master source through:</p>
<p>commit 62a4e7957a736b4de38938b02fa7eb9b45bc5d0d<br />Date: Tue Oct 25 23:04:45 2016 +0200</p>
<pre><code>if_iwm - Switch arguments from iwm_node* to iwm_vap* in if_iwm_power.c.</code></pre>
<p>Now build dports git, xorg, xfce4 from scratch using:</p>
<p>make clean && make NO_DIALOG=yes install clean</p>
<p>Now try building for multimedia/ffmpegthumbnailer. I would guess one would obtain an error similar to:</p>
<p>CMake Warning:<br /> Manually-specified variables were not used by the project:</p>
<pre><code>CMAKE_CXX_FLAGS_DEBUG<br /> CMAKE_C_FLAGS_DEBUG<br /> CMAKE_C_FLAGS_RELEASE<br /> CMAKE_MODULE_LINKER_FLAGS<br /> THREADS_HAVE_PTHREAD_ARG</code></pre>
<p>...</p>
<p>--- ffmpegthumbnailer ---<br />[ 83%] Linking CXX executable ffmpegthumbnailer<br />/usr/local/bin/cmake -E cmake_link_script CMakeFiles/ffmpegthumbnailer.dir/link.txt --verbose=1<br />/usr/bin/c++ -pipe -g -O2 -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -std=c++11 -pipe -g -O2 -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include CMakeFiles/ffmpegthumbnailer.dir/main.cpp.o -o ffmpegthumbnailer libffmpegthumbnailer.so.4.11.0 /usr/local/lib/libavformat.so /usr/local/lib/libavcodec.so /usr/local/lib/libavutil.so /usr/local/lib/libswscale.so /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -lz -Wl,-rpath,/usr/obj/dports/multimedia/ffmpegthumbnailer/.build:/usr/local/lib <br />libffmpegthumbnailer.so.4.11.0: error: undefined reference to 'pthread_cancel'<br />collect2: error: ld returned 1 exit status</p>
<p>The /etc/make.conf I used is a simple:</p>
<ol>
<li>cat /etc/make.conf<br />CFLAGS+=-g<br />STRIP=</li>
</ol>
<p>WITH_PKGNG=yes<br />DISABLE_VULNERABILITIES=yes</p>
<p>WITH_VIM_OPTIONS=yes</p> DragonFlyBSD - Bug #2928 (Closed): Patch from later Linux drm: drm/fb-helper: Use proper plane ma...https://bugs.dragonflybsd.org/issues/29282016-07-22T16:24:30Zdavshao
<p>Thanks for the update to Linux 4.4 drm. There is a subtle bug<br />in the usage of drm_plane_index() in function pan_display_atomic()<br />of drm_fb_helper.c, found by Matt Roper. For reference:</p>
<p><a class="external" href="https://patchwork.kernel.org/patch/7889051/">https://patchwork.kernel.org/patch/7889051/</a></p>
<p>Please apply the following patch:</p>
<p>diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c<br />index 69cbab5..1e103c4 100644<br />--- a/drivers/gpu/drm/drm_fb_helper.c<br />+++ b/drivers/gpu/drm/drm_fb_helper.c<br /><code>@ -1251,7 +1251,7 </code>@ retry:<br /> goto fail;</p>
<pre><code>plane = mode_set->crtc->primary;<br />- plane_mask |= drm_plane_index(plane);<br />+ plane_mask |= (1 << drm_plane_index(plane));<br /> plane->old_fb = plane->fb;<br /> }</code></pre> DragonFlyBSD - Bug #2927 (Closed): e2a21467e1 Updates to show "4.7" and other changes to major he...https://bugs.dragonflybsd.org/issues/29272016-07-21T01:46:35Zdavshao
<p>commit 5d920ec6b97613f06aba4a09bfb91413b1fd93c3 Fix excessive ipiq recursion (2)<br />does not correct the problem I have observed on at least two machines that</p>
<p>make -j7 buildworld</p>
<p>locks up the machine. (When using make buildworld I move /usr/obj/usr to start the build from scratch.) On one machine there seems to be a reproducible lock up at</p>
<p>sh /usr/src/tools/install.sh -o root -g wheel -m 555 lto1 /usr/obj/usr/src/ctools_x86_64_x86_64/usr/libexec/gcc50</p>
<p>Changes to major headers should be temporarily suspended until this problem is resolved, because I have observed that even</p>
<p>make quickworld</p>
<p>can fail to complete without lockup. Someone using UFS as their filesystem may experience quite substantial filesystem corruption after a lockup. By limiting changes to major headers, this gives the greatest chance of a successful make quickworld when this problem is finally resolved.</p> DragonFlyBSD - Bug #2910 (Closed): Rethinking __printflike in the context of drm's __printfhttps://bugs.dragonflybsd.org/issues/29102016-05-06T05:34:46Zdavshao
<p>Currently DragonFly drm defines <i>printf to be __printflike. It seems likely to me that Linux drm actually expects behavior __printf0like, without the __nonnull</i>(fmtarg) attribute.</p>
<p>For example, more recent versions of Linux drm want to define a function like this:</p>
<p>extern __printf(6, 7)<br />int drm_crtc_init_with_planes(struct drm_device *dev,<br /> struct drm_crtc *crtc,<br /> struct drm_plane *primary,<br /> struct drm_plane *cursor,<br /> const struct drm_crtc_funcs *funcs,<br /> const char *name, ...);</p>
<p>and call it sometimes (well strangely enough, so far all of the time) with name == NULL.<br />Then inside the newer versions of the function is something like this:</p>
<pre><code>if (name) {<br /> __va_list ap;</code></pre>
<pre><code>__va_start(ap, name);<br /> crtc->name = kvasprintf(GFP_KERNEL, name, ap);<br /> __va_end(ap);<br /> } else {<br /> crtc->name = kasprintf(GFP_KERNEL, "crtc-%d",<br /> drm_num_crtcs(dev));<br /> }</code></pre>
<p>The obvious fix is in sys/dev/drm/include/linux/compiler.h<br />to redefine __printf as __printf0like.</p>
<p>For curiosity's sake, given the gcc 4+ series of compilers now used for DragonFly in 2015<br />as opposed to 2004 when the __printflike and __printf0like distinction was made, is it<br />still necessary to have both __printflike and printf0like?</p> DragonFlyBSD - Submit #2904 (Closed): Update drm/uapi_drm to Linux 4.6https://bugs.dragonflybsd.org/issues/29042016-04-28T04:49:07Zdavshao
<p>Attached is a patch to update drm/uapi_drm to Linux 4.6. There should be no functional changes. The possible change in behavior in i915_drm.h, redefining the mask for invalid flags since new flags are added, is #ifdef-ed out.</p>
<p>The patch has been tested on a Intel integrated graphics gen7 Ivybridge machine and an AMD processor machine with a Sapphire Radeon HD6450.</p>
<p>The timeliness of this patch is because Matthew Macy of Nextbsd.org seems quite advanced in his own port of Linux 4.6 drm to FreeBSD, with work at</p>
<p><a class="external" href="https://github.com/iotamudelta/freebsd-base-graphics">https://github.com/iotamudelta/freebsd-base-graphics</a></p>
<p>With all the great work that has been done for DragonFly, there is no reason an independent effort should not make similar progress. I apologize if this is a duplicate of no doubt better work by those who have already contributed so much to DragonFly.</p> DragonFlyBSD - Bug #2903 (Closed): args->flags & ~(I915_MMAP_WC) 7ec9f8e589bca0a Linux scatterlis...https://bugs.dragonflybsd.org/issues/29032016-04-24T07:25:32Zdavshao
<p>Commit 7ec9f8e589bca0a drm/i915/gem: Switch to the Linux scatterlist API<br />does a bit more than that. Commenting out the newly added</p>
<pre><code>if (args->flags & ~(I915_MMAP_WC))<br /> return -EINVAL;</code></pre>
<p>in i915_gem.c allows an Asrock Z77M motherboard machine using current pkgsrc with dports patches backported to once again startx xfce4.</p>
<p>Given that using packages from dports on the same machine allows startx xfce4, it would appear the fault is mine for using a hacked version of pkgsrc; nonetheless, I don't have the slightest idea what to do in userspace to avoid the conflict with the newly added check.</p>
<p>As an aside, I don't understand the logic of the following code in i915_gem_gtt.c, so in the attached diff the addition is commented out as well:</p>
<pre><code>ppgtt->base.allocate_va_range = aliasing ? NULL : gen6_alloc_va_range;<br /> ppgtt->base.allocate_va_range = gen6_alloc_va_range;</code></pre>