On 2019/04/11 18:59, Kamil Rytarowski wrote:
> On 11.04.2019 07:32, Masanobu SAITOH wrote:
>> Hi.
>>
>> i386/conf/ALL kernel can't link. See below.
>>
>
> This used to work.
>
> It means that __HAVE_ATOMIC64_OPS is defined but 64-bit atomics are
> unavailable..
>
> Someone disabled them for
On Thu, 11 Apr 2019, Chavdar Ivanov wrote:
> Please don't be so quick reverting the Intel driver. With today's
> build my laptop is working very well, I have no visible effects,
> glmark2 executes as expected with the exception of the crash upon
> exit, Kde4 was previously crashing on testing the
Updating src tree:
P src/distrib/amd64/ramdisks/ramdisk-cgdroot/list
P src/distrib/i386/ramdisks/ramdisk-cgdroot/list
P src/distrib/sets/regpkg
P src/external/mit/xorg/lib/libGL/Makefile
P src/lib/librefuse/refuse.3
P src/lib/libterminfo/setupterm.c
P src/sbin/tunefs/tunefs.c
P
Please don't be so quick reverting the Intel driver. With today's build my
laptop is working very well, I have no visible effects, glmark2 executes as
expected with the exception of the crash upon exit, Kde4 was previously
crashing on testing the gl capability, now everything works. Great work, in
i am fairly sure the new display glitches you are seeing are
related to the newer xf86-video-intel driver.
can people who are seeing issues not related to GL/Mesa try
forcing the "modesetting" driver instead? see if that makes
things go away? i am probably going to revert the driver in
-current
I have on occasion similar behaviour on my HP Envy laptop using the
530 graphics, it is rather weird. I also get the messages about not
being able to load the two microcode files, even if I have placed them
in the right location.
On Thu, 11 Apr 2019 at 21:31, Ron Georgia wrote:
>
> My monitor is
FYI glmark2 ran rather well under VirtualBox a moment ago with a few
hours old system, only crashing on exit:
...
Reading symbols from /usr/pkg/bin/glmark2...done.
[New process 1]
[New process 4]
Core was generated by `glmark2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0
My monitor is acting a little funky. When I call up something like wireshark or
firefox and start scrolling the content inside the active window looks like a
satellite TV during a storm. When the window repaints it is choppy (albeit
colorful). If I let it sit long enough it settles out. This
On Thu, Apr 11, 2019 at 04:49:09PM +, co...@sdf.org wrote:
> argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
> complicating testing :_/
Ah, disregard, I had the old libGL.so.3.0 (because I unpacked sets, but
for this manipulation I only re-linked libGL.so.
Putting
argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
complicating testing :_/
On Thu, Apr 11, 2019 at 10:03:24AM +, co...@sdf.org wrote:
> This avoids the crash but it crashes on exit too
I still seem to get the crash on start?
(gdb) bt
#0 0x7f7ff58427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12
#1 0x7f7ff16096ee in pthread_sigmask (how=,
The first machine I tried it on was equipped with some flavor of Radeon
graphics card (Sapphire X1500 or something like that):
[...]
radeon0 at pci1 dev 0 function 0: ATI Technologies product 7183 (rev. 0x00)
ATI Technologies product 71a3 (miscellaneous display) at pci1 dev 0 function 1
not
Quoting Robert Swindells :
Do powerpc kernels have a sysctl for page size ? I'm fairly sure
that arm does.
Yes. It has:
# sysctl -a | grep page
hw.pagesize = 4096
But I don't know if you can change that at runtime.
--
Frank Wille
This avoids the crash but it crashes on exit too
Index: Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/libGL/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- Makefile9 Apr 2019 14:31:06 - 1.24
On 11.04.2019 07:32, Masanobu SAITOH wrote:
> Hi.
>
> i386/conf/ALL kernel can't link. See below.
>
This used to work.
It means that __HAVE_ATOMIC64_OPS is defined but 64-bit atomics are
unavailable..
Someone disabled them for NetBSD/i386 them?
#if defined(_KERNEL)
/*
* Processors < i586
On Thu, Apr 11, 2019 at 10:26:36AM +0100, Patrick Welche wrote:
> I'm trying a slightly newer glmark2 as per trivial patch attached, but
> get the same abort in _sys___sigprocmask14 as you do.
P.S. I also did rm -rf ~/.cache just in case, and that didn't help, an
empty index appeared
$ hexdump
On Tue, Apr 09, 2019 at 04:18:59PM +, co...@sdf.org wrote:
> glmark2 aborts for me, but I don't understand why.
It took a while to rebuild with your changes - thanks for fixing the
dlopen!
I'm trying a slightly newer glmark2 as per trivial patch attached, but
get the same abort in
17 matches
Mail list logo
