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 - 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 - 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 #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 #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 - 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> DragonFlyBSD - Bug #2893 (Closed): Don't clean /usr/obj/usr error: conflicting types for 'unctrl'https://bugs.dragonflybsd.org/issues/28932016-03-13T00:58:20Zdavshao
<p>Update through (I have been using full buildworlds after latest updates including cleaning /usr/obj/usr):</p>
<p>commit b34d3b9b8fa26892a7eb1f0fbf9a053d72798cd8<br />Date: Thu Mar 10 10:43:31 2016 +0200</p>
<pre><code>nrelease: Allow to build snapshots on tmpfs.</code></pre>
<p>After installation,</p>
<p>cd /usr/obj<br />mv usr usr.prev</p>
<p>because it appears one needs a functioning /usr/obj/usr to build anymore.</p>
<p>Now update through:</p>
<p>commit 3eec877432eb8056a5450dd96fad6f6abad016b9<br />Date: Fri Mar 11 20:11:40 2016 +0100</p>
<pre><code>ncurses: Upgrade version 5.9 (20110402) => 6.0 (20160305)</code></pre>
<p>cd /usr/src<br />make buildworld</p>
<p>Not long into the build, reproduced on 2 separate machines so far:</p>
<p>echo tic: /usr/obj/usr/src/btools_x86_64/usr/lib/libc.a /usr/obj/usr/src/btools_x86_64/usr/lib/priv/libprivate_ncurses.a >> .depend<br />cc -O -pipe -g -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -DSET_NCURSES_CH_T=cchar_t -DSET_NEED_WCHAR_H=1 -I/usr/src/usr.bin/tic/../../contrib/ncurses/progs -I. -I/usr/src/usr.bin/tic/../../contrib/ncurses/include -I/usr/src/usr.bin/tic/../../lib/libncurses/include -I/usr/src/usr.bin/tic -I/usr/obj/usr/src/btools_x86_64/usr/src/usr.bin/tic -std=gnu99 -Wmissing-include-dirs -Wsystem-headers -Wall -Wformat-security -Winit-self -Wno-pointer-sign -Wextra -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/usr.bin/tic/../../contrib/ncurses/progs/tic.c -o tic.o<br />In file included from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/progs.priv.h:121:0,<br /> from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/tic.c:42:<br />/usr/src/usr.bin/tic/../../lib/libncurses/include/unctrl.h:60:38: error: conflicting types for 'unctrl'<br /> NCURSES_EXPORT(NCURSES_CONST char <strong>) NCURSES_SP_NAME(unctrl) (SCREEN</strong>, chtype);<br /> ^<br />In file included from /usr/include/curses.h:1971:0,<br /> from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/progs.priv.h:121,<br /> from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/tic.c:42:<br />/usr/src/usr.bin/tic/../../lib/libncurses/include/unctrl.h:57:38: note: previous declaration of 'unctrl' was here<br /> NCURSES_EXPORT(NCURSES_CONST char *) unctrl (chtype);</p>
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make<sup><a href="#fn3">3</a></sup>: stopped in /usr/src/usr.bin/tic<br />sh /usr/src/tools/install.sh -o root -g wheel -m 555 tic /usr/obj/usr/src/btools_x86_64/usr/bin<br />install: tic: No such file or directory
<ul>
<li>Error code 71</li>
</ul>
<p>The /etc/make.conf used is:</p>
<p>CFLAGS+=-g<br />STRIP=</p>
<p>WITH_PKGNG=yes<br />DISABLE_VULNERABILITIES=yes</p>
<p>WITH_VIM_OPTIONS=yes</p>
<p>On one machine, moving back /usr/obj/usr allows<br />make quickworld<br />to complete successfully. However I have not attempted to install this world yet.</p> DragonFlyBSD - Bug #2836 (Closed): Removal of /usr/include/regex.h needs to be loudly announcedhttps://bugs.dragonflybsd.org/issues/28362015-08-09T01:06:20Zdavshao
<p>The removal of /usr/include/regex.h as a consequence of updating the regex library needs to be loudly announced, such as in UPDATING and on the user mailing list.</p>
<p>Software that used to do something like check for PCRE and if that fails check for a native regex library by searching for /usr/include/regex.h is now broken building. A prominent example of this is x11/xterm. In either dports or pkgsrc, try building xterm.</p>
<p>For the example of xterm, changing to enabling PCRE will probably fix the build. A more serious problem is that software that used to find DragonFly's native regex library will do something like dump core. An example of this is apparently pkgsrc's bmake, where one can see during its configuration that it is checking for regex.h. At least this is happening to me using latest 4.3-DEVELOPMENT and doing a full buildworld.</p>
<p>The change to the new regex library I believe should be treated as a flag day event, with users told to rebuild or obtain updated packages of all userland software.</p> DragonFlyBSD - Bug #2835 (New): /usr/include/c++/5.0/bits/c++locale.h likes _POSIX_C_SOURCE>=200809https://bugs.dragonflybsd.org/issues/28352015-08-04T15:05:55Zdavshao
<p>Using current master DragonFly, trying to build dports devel/ncurses or pkgsrc devel/ncurses fails with:</p>
<p>c++ -DHAVE_CONFIG_H -I. -I../../c++ -I../include -I../../c++/../include -D_BSD_TYPES -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -DNDEBUG -pipe -g -O2 -fno-strict-aliasing -fPIC -DPIC -c ../../c++/cursesmain.cc -o ../obj_s/cursesmain.o<br />In file included from /usr/include/c++/5.0/bits/localefwd.h:40:0,<br /> from /usr/include/c++/5.0/ios:41,<br /> from /usr/include/c++/5.0/ostream:38,<br /> from /usr/include/c++/5.0/iostream:39,<br /> from ../../c++/cursesmain.cc:39:<br />/usr/include/c++/5.0/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)':<br />/usr/include/c++/5.0/bits/c++locale.h:61:47: error: 'locale_t' was not declared in this scope<br /> _<em>c_locale __old = (</em>_c_locale)uselocale((locale_t)__cloc);<br /> ^<br />/usr/include/c++/5.0/bits/c++locale.h:61:62: error: 'uselocale' was not declared in this scope<br /> _<em>c_locale __old = (</em>_c_locale)uselocale((locale_t)__cloc);</p>
<p>I suspect the responsible change may be:</p>
<p>commit d1732c039257d5ff06e218b885a2d1ee92daa355<br />Date: Thu Jul 30 22:22:02 2015 +0200</p>
<pre><code>gcc50: Remove generic versions of added files</code></pre>
<p>where in particular<br />.../libstdc++-v3/config/locale/generic/c_locale.h <br />was removed.</p>
<p>c++/5.0/bits/c++locale.h contains<br />#include <clocale></p>
<p>/usr/include/c++/5.0/clocale contains<br />#include <locale.h></p>
<p>/usr/include/locale.h contains</p>
<p>#if __POSIX_VISIBLE >= 200809<br />#include <xlocale/_locale.h><br />#endif</p>
<p>locale_t appears to be defined in /usr/include/xlocale/_locale.h</p>
<p>And I believe __POSIX_VISIBLE is defined in cdefs.h where it is set depending on the value of _POSIX_C_SOURCE.</p>
<p>At least on pkgsrc devel/ncurses, the build was able to be completed when its configure was hacked similar to the following:</p>
<p>cf_POSIX_C_SOURCE=200809L<br />cf_XOPEN_SOURCE=700</p>
<p>Now the obvious workaround is simply to use the built-in ncurses. However I am wondering if in general the new recommendation for userland software is to edit their aclocal.m4's or whatever else they use defining</p>
<p>_POSIX_C_SOURCE=200809<br />_XOPEN_SOURCE=700</p>
<p>for DragonFly. And do they need to test the version of DragonFly?</p>
<p>Or would it be possible to put the deleted generic files back?</p> DragonFlyBSD - Bug #2834 (Resolved): Post 3.16 i915 drm freedesktop Bug 76554 one line fixhttps://bugs.dragonflybsd.org/issues/28342015-08-02T19:53:29Zdavshao
<p>After the update to Linux 3.16 i915 drm, Bug 76554 from freedesktop.org</p>
<p><a class="external" href="https://bugs.freedesktop.org/show_bug.cgi?id=76554">https://bugs.freedesktop.org/show_bug.cgi?id=76554</a></p>
<p>manifests itself on an Intel(R) Core2 Quad CPU Q9400 with G45 integrated graphics:</p>
<p>drm0: taking over the fictitious range 0xd0000000-0xe0000000<br />error: [drm:pid1054:init_ring_common] <strong>ERROR</strong> render ring initialization failed ctl 0001f001 (valid? 1) head 05663004 tail 00000000 start 00003000 [expected 00003000]<br />error: [drm:pid1054:i915_gem_init] <strong>ERROR</strong> Failed to initialize GPU, declaring it wedged</p>
<p>Fortunately Jiri Kosina found a 1-line workaround that is still there in the<br />Linux 4.0.8 code:</p>
<p><a class="external" href="https://bugs.freedesktop.org/attachment.cgi?id=104224">https://bugs.freedesktop.org/attachment.cgi?id=104224</a></p>
<p>This fix has been verified on the Q9400 machine to at least stop the error messages.</p> DragonFlyBSD - Bug #2823 (Closed): Intel Q9400 PC fails to boot waiting for the following device ...https://bugs.dragonflybsd.org/issues/28232015-06-07T15:37:49Zdavshao
<p>For one Intel Core 2 Q9400 machine, booting fails with console output listed below. The same problem has not been observed on a couple of newer generation Intel-based PCs. Bisection seems to indicate the problem began between, inclusive, master commit</p>
<p>commit 6f1a15dc79a822710cc37e99f6a8bd9910e5e3f1<br />Date: Sat Jun 6 16:17:41 2015 -0700</p>
<pre><code>sysctl - SMP performance work</code></pre>
<p>and</p>
<p>commit bb06d795144b04574aa0b5fdb94e95ab77360a1a<br />Date: Sun Jun 7 04:16:12 2015 +0200</p>
<pre><code>&lt;sys/sysctl.h&gt;: Include &lt;sys/lock.h&gt; only for the kernel (unbreaks world).</code></pre>
<p>Attached is a full verbose dmesg from a successful boot with a previous kernel.</p>
<p>Console output for unsuccessful boot:</p>
<p>CAM: finished configuring all busses<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xffffffff8029ea32 arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xffffffff8029ea32 arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xffffffff8029ea32 arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xffffffff8029ea32 arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xffffffff8029ea32 arg=0<br />Giving up, interrupt routing is probably hosed<br />no B_DEVMAGIC (bootdev=0)<br />ATA PseudoRAID loaded<br />Mounting root from hammer:serno/WD-WMATV8216330.s1d<br />no disk named 'serno/WD-WMATV8216330.s1d'<br />hammer_mountroot: can't find devvp<br />kthread 0xffffffe056318c80 syncer3 has exited<br />Root mount failed:6</p>
<p>Manual root filesystem specification<br /> <fstype>:<device> Specify root (e.g. ufs:da0s1a)<br /> ? List valid disk boot devices<br /> panic Just panic<br /> abort Abort manual input</p>
<p>mountroot></p>
<p>Dmesg output for earlier kernel, successful boot:</p>
<p>sl0: bpf attached<br />hpt27xx: no controller detected.<br />hptrr: no controller detected.<br />CAM: Configuring bus: ahci0<br />CAM: Configuring bus: ahci0<br />CAM: Configuring bus: ahci0<br />CAM: Configuring bus: ahci0<br />CAM: Configuring bus: ahci0<br />CAM: Configuring bus: ahci0<br />CAM: Configuring 6 busses<br />CAM: Finished configuring bus: ahci0<br />CAM: Finished configuring bus: ahci0<br />CAM: Finished configuring bus: ahci0<br />CAM: Finished configuring bus: ahci0<br />CAM: Finished configuring bus: ahci0<br />CAM: Finished configuring bus: ahci0<br />CAM: finished configuring all busses<br />pass0 at ahci0 bus 1 target 0 lun 0<br />pass0: <SATA WDC WD1002FBYS-0 03.0> Fixed Direct Access SCSI-4 device <br />pass0: Serial Number WD-WMATV5981256<br />pass0: 300.000MB/s transfers<br />pass1 at ahci0 bus 2 target 0 lun 0<br />pass1: <SATA WDC WD1002FBYS-0 03.0> Fixed Direct Access SCSI-4 device <br />pass1: Serial Number WD-WMATV8216330<br />pass1: 300.000MB/s transfers</p> DragonFlyBSD - Bug #2813 (Resolved): Lock-up starting xfce for Radeon 4xxx graphics cardshttps://bugs.dragonflybsd.org/issues/28132015-05-15T00:05:37Zdavshao
<p>On two machines, one with a Radeon 4350 and the other with a Radeon 4550 graphics card, using startx to start xfce locks-up the machines. This is using DragonFly master through:</p>
<p>commit 0d421097a3ece111e0d4cebe2651b7a3500774c3<br />Date: Thu May 14 06:54:24 2015 +0900</p>
<pre><code>sys/vfs/tmpfs: Remove duplicated cross-device check on nlink vop</code></pre>
<p>and latest dports packages.</p>
<p>Before the lock-up<br />tail -f /var/log/messages<br />shows:</p>
<p>May 14 16:56:51 kernel: info: [drm] Initialized drm 1.1.0 20060810<br />May 14 16:56:51 kernel: drm0: <ATI Radeon HD 4550> on vgapci0<br />May 14 16:56:51 kernel: info: [drm] RADEON_IS_PCIE<br />May 14 16:56:51 kernel: info: [drm] initializing kernel modesetting (RV710 0x1002:0x9540 0x174B:0xE970).<br />May 14 16:56:51 kernel: info: [drm] register mmio base: 0xF7E20000<br />May 14 16:56:51 kernel: info: [drm] register mmio size: 65536<br />May 14 16:56:51 kernel: info: [drm] radeon_atrm_get_bios: ===> Try ATRM...<br />May 14 16:56:51 kernel: info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:4:0:0, vendor=1002, device=9540<br />May 14 16:56:51 kernel: info: [drm] radeon_atrm_get_bios: Get ACPI device handle<br />May 14 16:56:51 kernel: info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT...<br />May 14 16:56:51 kernel: info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table<br />May 14 16:56:51 kernel: info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND<br />May 14 16:56:51 kernel: info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM...<br />May 14 16:56:51 kernel: info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe0000000<br />May 14 16:56:51 kernel: info: [drm] igp_read_bios_from_vram: Map address: 0xffffffe20c810000 (262144 bytes)<br />May 14 16:56:51 kernel: info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x4907<br />May 14 16:56:51 kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...<br />May 14 16:56:51 kernel: info: [drm] radeon_read_bios: Map address: 0xffffffe20c810000 (131072 bytes)<br />May 14 16:56:51 kernel: info: [drm] ATOM BIOS: 11X<br />May 14 16:56:51 kernel: drm0: info: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)<br />May 14 16:56:51 kernel: drm0: info: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF<br />May 14 16:56:51 kernel: info: [drm] Detected VRAM RAM=512M, BAR=256M<br />May 14 16:56:51 kernel: info: [drm] RAM width 64bits DDR<br />May 14 16:56:51 kernel: [TTM] (struct ttm_mem_global *)0xffffffe20a933f18<br />May 14 16:56:51 kernel: [TTM] Zone kernel: Available graphics memory: 65536 kiB<br />May 14 16:56:51 kernel: [TTM] Zone dma32: Available graphics memory: 65536 kiB<br />May 14 16:56:51 kernel: [TTM] Initializing pool allocator<br />May 14 16:56:51 kernel: info: [drm] radeon: 512M of VRAM memory ready<br />May 14 16:56:51 kernel: info: [drm] radeon: 512M of GTT memory ready.<br />May 14 16:56:51 kernel: info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).<br />May 14 16:56:51 kernel: info: [drm] Driver supports precise vblank timestamp query.<br />May 14 16:56:51 kernel: info: [drm] radeon: irq initialized.<br />May 14 16:56:51 kernel: info: [drm] GART: num cpu pages 131072, num gpu pages 131072<br />May 14 16:56:51 kernel: info: [drm] probing gen 2 caps for device 1002:9540 = 1/0<br />May 14 16:56:51 kernel: info: [drm] Loading RV710 Microcode<br />May 14 16:56:51 kernel: info: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).<br />May 14 16:56:51 kernel: drm0: info: WB enabled<br />May 14 16:56:51 kernel: drm0: info: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0x0xffffdf8003e32c00<br />May 14 16:56:51 kernel: drm0: info: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0x0xffffdf8003e32c0c<br />May 14 16:56:51 kernel: info: [drm] ring test on 0 succeeded in 1 usecs<br />May 14 16:56:51 kernel: info: [drm] ring test on 3 succeeded in 0 usecs<br />May 14 16:56:51 kernel: info: [drm] ib test on ring 0 succeeded in 0 usecs<br />May 14 16:56:51 kernel: info: [drm] ib test on ring 3 succeeded in 0 usecs<br />May 14 16:56:51 kernel: info: [drm] radeon_device_init: Taking over the fictitious range 0xe0000000-0xf0000000<br />May 14 16:56:51 kernel: iicbus0: <Philips I2C bus> on iicbb0 addr 0xff<br />May 14 16:56:51 kernel: iicbus1: <Philips I2C bus> on iicbb1 addr 0xff<br />May 14 16:56:51 kernel: iicbus2: <Philips I2C bus> on iicbb2 addr 0xff<br />May 14 16:56:51 kernel: iicbus3: <Philips I2C bus> on iicbb3 addr 0xff<br />May 14 16:56:51 kernel: iicbus4: <Philips I2C bus> on iicbb4 addr 0xff<br />May 14 16:56:51 kernel: iicbus5: <Philips I2C bus> on iicbb5 addr 0xff<br />May 14 16:56:51 kernel: iicbus6: <Philips I2C bus> on iicbb6 addr 0xff<br />May 14 16:56:51 kernel: info: [drm] Radeon Display Connectors<br />May 14 16:56:51 kernel: info: [drm] Connector 0:<br />May 14 16:56:51 kernel: info: [drm] VGA-1<br />May 14 16:56:51 kernel: info: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c<br />May 14 16:56:51 kernel: info: [drm] Encoders:<br />May 14 16:56:51 kernel: info: [drm] CRT2: INTERNAL_KLDSCP_DAC2<br />May 14 16:56:51 kernel: info: [drm] Connector 1:<br />May 14 16:56:51 kernel: info: [drm] HDMI-A-1<br />May 14 16:56:51 kernel: info: [drm] HPD1<br />May 14 16:56:51 kernel: info: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c<br />May 14 16:56:51 kernel: info: [drm] Encoders:<br />May 14 16:56:51 kernel: info: [drm] DFP1: INTERNAL_UNIPHY<br />May 14 16:56:51 kernel: info: [drm] Connector 2:<br />May 14 16:56:51 kernel: info: [drm] DVI-I-1<br />May 14 16:56:51 kernel: info: [drm] HPD4<br />May 14 16:56:51 kernel: info: [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c<br />May 14 16:56:51 kernel: info: [drm] Encoders:<br />May 14 16:56:51 kernel: info: [drm] CRT1: INTERNAL_KLDSCP_DAC1<br />May 14 16:56:51 kernel: info: [drm] DFP2: INTERNAL_UNIPHY2<br />May 14 16:56:51 kernel: info: [drm] Internal thermal controller with fan control<br />May 14 16:56:51 kernel: info: [drm] radeon: power management initialized<br />May 14 16:56:51 kernel: info: [drm] Initialized radeon 2.30.0 20080528</p> DragonFlyBSD - Bug #2800 (Resolved): Resizing Xfce4 Terminal window unexpectedly closes windowhttps://bugs.dragonflybsd.org/issues/28002015-03-06T19:08:48Zdavshao
<p>Using master through <br />commit 04b9236f8a624ef900f3669b86ee62dd23374fc2<br />Date: Fri Mar 6 04:42:08 2015 +0900</p>
<pre><code>sbin/hammer: Print '>' or '<' if the element is a copy of root_btree_(beg|end)</code></pre>
<p>and dports master, resizing an Xfce4 Terminal window by grabbing a corner with the mouse causes the window to unexpectedly close. This has been observed on multiple systems with both Radeon 4xxx graphics cards and Intel integrated graphics. Furthermore the systems had relatively recent full buildworld buildkernels, and dports was built against the up-to-date systems.</p>
<p>One question is whether this behavior could be related to a libedit update.</p> DragonFlyBSD - Bug #2794 (Closed): /usr/share/mk/sys.mk" line 66: Malformed conditionalhttps://bugs.dragonflybsd.org/issues/27942015-02-25T19:16:00Zdavshao
<p>After using a full buildworld, buildkernel, installkernel, installworld for current master, use of make fails with:</p>
<p>make: "/usr/share/mk/sys.mk" line 66: Malformed conditional ((${CCVER:Mgcc4<sup><a href="#fn89">89</a></sup>} || ${CCVER:Mgcc5*}))</p>
<p>This may be related to:</p>
<p>commit 7431acdac28b044e8c36042bc91009824a095ce8<br />Date: Wed Feb 25 04:55:09 2015 +0100</p>
<pre><code>gcc50: Exclude -Wunused-local-typedefs from C++ flags for now.</code></pre>
<p>Since /usr/share/mk/sys.mk appears to be affected, can full instructions be given for the fix that has to apparently be manually applied to each system.</p>