firecrow silvernight | 14 May 00:41 2016
Gravatar

delete key funny character

Hi,
im having an isaue in xterm where the delete key shows ^? instead of normal 
behavior.

it doesnt happen all the time, when it starts it stays.

happens in xterm and tmux and nvi and vim, but not always at the same time, 
an xterm bash shell may be ok, but the vim session spawn from it may be broken.

any thoughts on how to configure this, or more helpful information i should 
dig for, welcome.

~fire

Rhialto | 25 Mar 14:57 2016
Picon

Buggy /usr/X11R7/lib/modules/dri/r600_dri.so ?

I have a program (VICE; see http://vice-emu.sourceforge.net/ ) which
can have multiple GUIs. Two of them seem to use the
/usr/X11R7/lib/modules/dri/r600_dri.so file eventually and crash in
them.

I think I saw something similar (at least involving dri, but with a
different crashing function) before in abiword, in PR 50320.
http://gnats.netbsd.org/50320

Fortunately VICE also has an Xaw GUI and that one works fine.

Do these stacktraces below ring a bell for anybody?

Here is a crash for the SDL2 GUI. This happens a few seconds after
starting up, and after some of the emulated screen has been shown
already:

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1]
0x00007f7fed942551 in r600_draw_rectangle () from /usr/X11R7/lib/modules/dri/r600_dri.so
(gdb) bt
#0  0x00007f7fed942551 in r600_draw_rectangle () from /usr/X11R7/lib/modules/dri/r600_dri.so
#1  0x00007f7fed94862c in util_blitter_custom_color () from /usr/X11R7/lib/modules/dri/r600_dri.so
#2  0x00007f7fed9016b7 in ?? () from /usr/X11R7/lib/modules/dri/r600_dri.so
#3  0x00007f7fed6a1c0e in dri_flush () from /usr/X11R7/lib/modules/dri/r600_dri.so
#4  0x00007f7ff4c5a73c in ?? () from /usr/X11R7/lib/libGL.so.2
#5  0x00000000004d8c61 in refresh_canvas (raster=<optimized out>, raster=<optimized out>) at ../../../vice/src/raster/raster-canvas.c:99
#6  raster_canvas_handle_end_of_frame (raster=0x7f7ff2731180, raster <at> entry=0x13e1310
<crtc+208>) at ../../../vice/src/raster/raster-canvas.c:124
#7  0x00000000004d8145 in crtc_raster_draw_alarm_handler (offset=0, data=<optimized out>) at ../../../vice/src/crtc/crtc.c:618
(Continue reading)

matthew green | 7 Dec 05:02 2015
Picon

odd radeondrmkms messages: edid checksum failure

i see this very occasionally on a radeon 4500 kernel messages:

DRM error in drm_edid_block_valid: EDID checksum is invalid, remainder is 208
drm kern error: Raw EDID:
00 ff ff ff ff ff ff 00 3d cb 33 0b 00 00 00 00
00 15 01 03 80 10 09 78 0a ae a5 a6 54 4c 99 26
14 50 54 20 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 1d 80 18 71 1c 16 20 58 2c
25 00 c4 8e 21 00 00 9e 01 1d 80 d0 72 1c 16 20
10 2c 25 80 c4 8e 21 00 00 9e 00 00 00 fc 00 48
54 2d 52 33 39 30 0a 20 20 20 20 20 00 00 00 fd
00 17 f0 0f 7e 11 00 0a 20 20 20 20 20 20 01 fb

it doesn't seem to affect anything, but it's odd, so i'm reporting it here.

.mrg.

Roy Bixler | 27 Nov 16:15 2015
Picon

can't get Nouveau console

I have an old Dell Precision M70 laptop with Nvidia NV40 series
graphics.  I tried to enable the Nouveau framebuffer on recent HEAD
kernels:

nouveau*        at pci? dev ? function ?
nouveaufb*      at nouveaufbbus?

but the framebuffer doesn't start on bootup.  It does work with a
Knoppix Linux CD.  I'll attach dmesg outputs for Linux and NetBSD HEAD
booting without Nouveau.  I think the following lines may be
important:

pchb0 at pci0 dev 0 function 0: vendor 8086 product 2590 (rev. 0x03)
agp0 at pchb0: can't find internal VGA config space

I also attach a screenshot I took showing what happens with Nouveau,
where I end up in the debugger and don't think I can otherwise save
the "dmesg" output.  I did try once booting a Nouveau-enabled kernel
under VESA mode.  I saw Nouveau driver lines similar to what I saw
under Linux and I could try taking a screenshot of those, except that
there are many of them and I'm not sure which ones would be most
useful.  How should I proceed?

--

-- 
Roy Bixler <rcbixler <at> nyx.net>
"The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment."
-- Richard P. Feynman
(Continue reading)

Richard PALO | 24 Nov 16:40 2015
Picon

bad karma between mouse and ati6 driver

Looking for advice on the following.
> ...
> [  4175.385] (II) RADEON(1): RADEONScreenInit d0000000 0 0
> [  4175.522] (II) RADEON(1): Dynamic Power Management Disabled
> [  4175.522] mc fb loc is 00df00d0
> [  4175.522] (II) RADEON(1): RADEONInitMemoryMap() : 
> [  4175.523] (II) RADEON(1):   mem_size         : 0x10000000
> [  4175.523] (II) RADEON(1):   MC_FB_LOCATION   : 0x00df00d0
> [  4175.523] (II) RADEON(1):   MC_AGP_LOCATION  : 0x003f0000
> [  4175.523] (II) RADEON(1): Depth moves disabled by default
> [  4175.531] (II) RADEON(1): RADEONRestoreMemMapRegisters() : 
> [  4175.531] (II) RADEON(1):   MC_FB_LOCATION   : 0x00df00d0 0x0f3f0f00
> [  4175.531] (II) RADEON(1):   MC_AGP_LOCATION  : 0x003f0000
> [  4175.542] (==) RADEON(1): Backing store enabled
> [  4175.542] (WW) RADEON(1): Direct rendering disabled
> [  4175.542] (II) RADEON(1): Acceleration enabled
> [  4175.542] (==) RADEON(1): DPMS enabled
> [  4175.542] (==) RADEON(1): Silken mouse disabled
> [  4175.542] (EE) RADEON(1): Hardware cursor initialization failed
> [  4175.542] (II) RADEON(1): Using software cursor
> [  4175.542] (II) RADEON(1): Textured video requires CP on R5xx/R6xx/R7xx/IGP
> [  4175.550] (II) RADEON(1): RADEONRestoreMemMapRegisters() : 
> [  4175.551] (II) RADEON(1):   MC_FB_LOCATION   : 0x00df00d0 0x00df00d0
> [  4175.551] (II) RADEON(1):   MC_AGP_LOCATION  : 0x003f0000
> [  4175.561] (II) RADEON(1): crtc(0) Clock: mode 94500, PLL 945000
> [  4175.561] (II) RADEON(1): crtc(0) PLL  : refdiv 2, fbdiv 0x54(84), fracfbdiv 0, pdiv 12
> [  4175.642] (II) RADEON(1): RandR 1.2 enabled, ignore the following RandR disabled message.
> [  4175.643] (--) RandR disabled
> [  4175.666] (II) AIGLX: Screen 0 is not DRI2 capable
> [  4175.666] (EE) AIGLX: reverting to software rendering
(Continue reading)

Ryosuke Moro | 6 Nov 22:41 2015
Picon

typo in src/external/mit/xorg/lib/pixman/Makefile

Hi,

Index: Makefile
===================================================================
RCS file: /cvsroot/src/external/mit/xorg/lib/pixman/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile	6 Nov 2015 21:32:22 -0000	1.33
+++ Makefile	6 Nov 2015 21:36:24 -0000
 <at>  <at>  -61,7 +61,7  <at>  <at>  SRCS+=	pixman-sse2.c pixman-ssse3.c
 COPTS.pixman-sse2.c=	-msse2 -fvisibility=hidden
 COPTS.pixman-ssse3.c=	-msse3 -mssse3 -fvisibility=hidden
 CPPFLAGS+=		-DUSE_SSE2 -DUSE_SSSE3
-MKDEPFLAGS+=		-msse2 -mssse3 -mssse3 -fvisibility=hidden
+MKDEPFLAGS+=		-msse2 -msse3 -mssse3 -fvisibility=hidden
 .endif

 .if ${MACHINE_ARCH} == "powerpc"

Thanks.
--

-- 
Ryosuke

Ottavio Caruso | 4 Nov 09:55 2015
Picon

xdm prevents me from shutting the system down clean

Hi,

I've been using 7.0-rc3 on amd64 for a few months. I haven't bothered
upgrading 7.0 proper so far. I am using native x11.

The only way I can shutdown the system clean is to open a virtual
console, log in as root, kill xdm manually and then issue the poweroff
command.

Not your usual user friendly set up, is it?

In all other cases, whether by pressing the power button or issuing
"sudo poweroff" or "sudo shutdown -h now",  the system hangs forever.

When I enable debugging messages, I see that it is repeatedly try to
kill a pid that is associated with xdm.

Where would I start debugging this issue?

--

-- 
Ottavio

Robert Swindells | 31 Oct 18:44 2015
Picon

gallium build problem


Is anyone looking at the build problem in gallium that is happening
for most ports ?

It seems to me that there is no need to build gallium at all on most
of the ports that are failing.

I have disabled the build of it locally for a couple of ports but
it would be cleaner if there was something defined in share/mk to
enable building the 3d stuff on selected ports.

Robert Swindells

Ryosuke Moro | 30 Oct 16:37 2015
Picon

-DHAVE_NOUVEAU

Hi,

i don't have nVidia cards, though.

Index: Makefile.defines
===================================================================
RCS file: /cvsroot/src/external/mit/xorg/lib/libdrm/Makefile.defines,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile.defines
--- Makefile.defines	17 Mar 2014 08:01:18 -0000	1.1
+++ Makefile.defines	30 Oct 2015 15:24:15 -0000
 <at>  <at>  -10,7 +10,5  <at>  <at>  CPPFLAGS+=	-DHAVE_INTTYPES_H \
 		-DHAVE_STRING_H  \
 		-DHAVE_SYS_STAT_H \
 		-DHAVE_SYS_TYPES_H \
-		-DHAVE_UNISTD_H
-
-#		-DHAVE_NOUVEAU
-
+		-DHAVE_UNISTD_H \
+		-DHAVE_NOUVEAU

right ?
--

-- 
Ryosuke

matthew green | 29 Oct 09:36 2015
Picon

nouveaudrm -- actually worth trying now!

hi folks.

i seem to have figured out the final bits for getting nouveau limping
along in a working state.  i can't stress enough that Taylor and Chuq
really did the vast majority of this work, i feel like the final 5%
at best...

it's probably worth testing in -current now if you want.  you'll need
to enable these lines in your config:

   nouveau*        at pci? dev ? function ?
   nouveaufb*      at nouveaufbbus?

and you might want to disable nouveau debug -- my console spews a really
large amount, but only if it works ;)  you'll have to do this by editing
files.nouveau to have this instead:

   makeoptions     nouveau CPPFLAGS+="-DCONFIG_NOUVEAU_DEBUG=0"
   makeoptions     nouveau CPPFLAGS+="-DCONFIG_NOUVEAU_DEBUG_DEFAULT=0"

i've so far only testing with i386, but i'll be building an amd64
world to test next.  you'll need rebuilt kernel and xsrc from
- -current to test (i don't know about pkgsrc x11 offhand.)

enjoy!

.mrg.

Mariusz Wawrzyniak | 26 Oct 15:35 2015
Picon

Nouveau driver on nvidia 8500GT (amd64)

Hi,

Today I built the kernel from the latest sources with nouveau, LOCKDEBUG,
DEBUG and KMEM_GUARD_DEPTH=30000 enabled. It gave me no console
and the relevant fragment of /var/log/messages looks like this:

Oct 26 15:00:12 netbsd syslogd[580]: Exiting on signal 15
Oct 26 15:04:19 netbsd syslogd[606]: restart
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd016[ ]: CONDITION_TIME	0x01 0xff
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd019[ ]: RESUME
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd01a[ ]: COPY_NV_REG	R[0x61000c] &= 0xffff0000 |=
((R[0x610000] >> 0x00) & 0x0000ffff ^ 0x00000000)
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd030[ ]: NV_REG	R[0x61000c] &= 0xbfffffff |= 0x40000000
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd03d[ ]: CONDITION_TIME	0x02 0xff
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd040[ ]: RESUME
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[  
VBIOS][nouveau0] 0xd041[ ]: DONE
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau D[
DEVINIT][nouveau0] initialised
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[   
GPIO][nouveau0] use(+1) == 1
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[   
GPIO][nouveau0] initialising...
Oct 26 15:04:19 netbsd /netbsd: drm kern debug: nouveau T[ 
(Continue reading)


Gmane