[DragonFlyBSD - Bug #3198] OpenGL app crash with Radeon driver
Issue #3198 has been updated by ftigeot. Among the three choices, I'd say get the R7 240. - R5 230: are rebadged models and variants of your existing chips. they will most likely exhibit the same issue. - RX550: it's a new generation and equires the amdgpu driver. A port of the driver is almost working but I can't say when the last issues will finally be ironed out. - R7 240 => that one is known to work fine and is a different radeon generation than the R5. Get a variant with a 128bit memory bus if speed is important four you. Bug #3198: OpenGL app crash with Radeon driver http://bugs.dragonflybsd.org/issues/3198#change-13791 * Author: yellowrabbit2010 * Status: Resolved * Priority: High * Assignee: * Category: Driver * Target version: The programs I work with, namely, FreeCAD, Kicad, MPV, Chromium crash with ``vm_fault: pager read error'' at different times, sometimes immediately after starting, sometimes after some manipulations. I managed to repeat the situation on the configuration with minimal changes: - I downloaded DragonFly-X86_64-LATEST.img.bz2 2019-07-16 03:56 285M - installed it on 8G usb flash drive - modify rc.conf and wpa_supplicant.conf in order to connect to WiFi - pkg install Xorg mesa-demos - added user rabbit - startx - glxgears Glxgears crushed immediately after start. Unfortunately, the test installation does not contain packages with debug information, so its core file is not very informative. But since the situation is always repeated, I built packages with debug information and made a screenshot of the gdb file with the downloaded core on the working machine (KERNCONF=X86_64_GENERIC). I have to note that I use the core of the March version and it has no problems with graphics at all: there have been no failures for a long time with all the programs listed above. That is, it is unlikely that this is a video memory or swap file problem and so on. = 5.5-DEVELOPMENT DragonFly v5.5.0.325.gf6792-DEVELOPMENT #25: Sun Mar 24 09:54:07 VLAT 2019 = I made an image of the flash drive immediately after the failure, you can download it from here https://yellowrabbit.gitlab.io/pub/bugs/dfly-glxgears.img.xz . There are no passwords neither for the rabbit user nor for root. ---Files IMG_20190718_080950_HDR-min.jpg (1.83 MB) Xorg.0.log (27.6 KB) gdb-0.txt (558 Bytes) messages (34.9 KB) gdb-1.txt (2.72 KB) gdb-1.png (394 KB) glxgears.core.xz (298 KB) IMG_20190724_210557_HDR-min.jpg (2.57 MB) vga.txz (312 KB) IMG_20190727_194932_HDR.jpg (4.11 MB) core.txt.0 (1.12 MB) messages (35.1 KB) core.txt.2 (1.47 MB) core.txt.3 (1.73 MB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #3203] (New) Don't assume pthread_t is a pointer
Issue #3203 has been reported by tkusumi.
Bug #3203: Don't assume pthread_t is a pointer
http://bugs.dragonflybsd.org/issues/3203
* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee:
* Category:
* Target version:
A pthread_t variable doesn't need to be initialized with NULL prior to calling
pthread_create(3).
This also isn't portable since pthread_t is an opaque type (i.e. may not be a
pointer, and in fact it's not on Linux/glibc).
# grep "thread = NULL" sbin/hammer2 -rI
sbin/hammer2/subs.c:pthread_t thread = NULL;
sbin/hammer2/cmd_service.c: thread = NULL;
sbin/hammer2/cmd_service.c: thread = NULL;
sbin/hammer2/cmd_service.c: thread = NULL;
sbin/hammer2/cmd_service.c: conf->thread = NULL;
sbin/hammer2/cmd_service.c: conf->iocom_thread = NULL;
sbin/hammer2/cmd_service.c: thread = NULL;
It looks like above exists for this conditional below.
If this could be rewritten without testing pthread_t itself (it shouldn't be
too), NULL initialization could be removed.
369 if (conf->thread == NULL) {
370 fprintf(stderr, "VOLCONF THREAD STARTED\n");
371 pthread_cond_init(>cond, NULL);
372 pthread_create(>thread, NULL,
373hammer2_volconf_thread, (void
*)conf);
374 }
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #3202] (New) Cannot boot from HAMMER2
Issue #3202 has been reported by mneumann.
Bug #3202: Cannot boot from HAMMER2
http://bugs.dragonflybsd.org/issues/3202
* Author: mneumann
* Status: New
* Priority: Normal
* Assignee:
* Category: Kernel
* Target version: master
Booting from HAMMER2 "BOOT" PFS works when created via "newfs_hammer2 -L BOOT".
But when I use "hammer2 pfs-create BOOT", I got the message "hammer2: 'BOOT'
PFS not found".
I might have created and deleted the "BOOT" PFS multiple times on that file
system.
My BOOT PFS inode number is "0xd9b36ce135528001", but HAMMER2_BOOT_KEY is
defined as "0xd9b36ce135528000".
With the following patch I can successfully boot from HAMMER2:
--- a/lib/libstand/hammer2.c
+++ b/lib/libstand/hammer2.c
@@ -692,7 +692,7 @@ h2init(struct hammer2_fs *hfs)
return(-1);
h2lookup(hfs, NULL, 0, 0, NULL, NULL);
r = h2lookup(hfs, >sroot,
-HAMMER2_BOOT_KEY, HAMMER2_BOOT_KEY,
+HAMMER2_BOOT_KEY, HAMMER2_BOOT_KEY | 0xU,
>sroot, );
if (r <= 0) {
printf("hammer2: 'BOOT' PFS not found\n");
I am not sure if this is 100% the right approach.
I would rather like to check for the name explicitly as there can be hash
collisions.
To successfully boot from HAMMER2, I have to "set currdev="disk0s1d" and then
"cd /kernel" and then follow normal boot procedure (loadall, boot).
To really be useful, one would have to allow other PFSes than "BOOT" to be
booted from,
so that you can boot from a snapshot for instance.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://bugs.dragonflybsd.org/my/account
