Re: mesa-dri-24.0.8 failing to build on d1bd097d52cb
I pushed commits to fix this, the wpa_supplicant*, and hostapd* ports last night. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 In message , Nuno Teixeira writes: > > (...) > > commit 108de784513d87bbe850e7b003a73e26b5b54caa > Author: Val Packett > Date: Fri May 31 08:45:02 2024 -0600 > > Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME > > Nuno Teixeira escreveu (s=C3=A1bado, 1/06/2024 =C3=A0= > (s) 09:01): > > > Hello all, > > > > Anyone seeing this error on main? > > > > Thanks > > > > [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p > > -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc > > -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev > > -I/usr/local/ > > include -I/usr/local/include/libdrm -fvisibility=3Dhidden > > -fdiagnostics-color=3Dnever -DNDEBUG -D_FILE_OFFSET_BITS=3D64 -Wall > > -Winvalid-pch -std=3Dc11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS > > -D__STDC_LIMIT_MACROS > > '-DPACKAGE_VERSION=3D"24.0.8"' '-DPACKAGE_BUGREPORT=3D" > > https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=3D1 > > -DHAVE_OPENGL_ES_1=3D1 -DHAVE_OPENGL_ES_2=3D1 -DHAVE_SWRAST -DHAVE_ZINK > > -DHAVE_R300 -DHAVE_R600 > > -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA > > -DUSE_VK_COMPILER=3D1 -DVIDEO_CODEC_VC1DEC=3D1 -DVIDEO_CODEC_H264DEC=3D1 > > -DVIDEO_CODEC_H264ENC=3D1 -DVIDEO_CODEC_H265DEC=3D1 -DVIDEO_CODEC_H265ENC= > =3D1 > > -DVIDEO > > _CODEC_AV1DEC=3D1 -DVIDEO_CODEC_AV1ENC=3D1 -DVIDEO_CODEC_VP9DEC=3D1 > > -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM > > -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=3D0 > > -DENABLE_ST > > _OMX_TIZONIA=3D0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING > > -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=3D0 -DALLOW_KCMP > > -DETIME=3DETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 > > -DHAVE___BUILTIN_BSWA > > P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ > > -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL > > -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UN= > RE > > ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST > > -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC > > -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED > > -DHAVE_FUNC_ATTRIBUTE_WAR > > N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT > > -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL > > -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT > > TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN > > -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT > > -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H > > -DHAS_SCHED_GETAFFINITY -D > > HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H > > -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF > > -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R > > -DHAVE_GETRANDOM > > -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV > > -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN > > -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR > > -DSUPPORT_INTEL > > _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREA= > D > > -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING=3D"15.0.7"' -DLLVM_IS_SHARED=3D= > 1 > > -DLLVM_AVAILABLE=3D1 -DDRAW_LLVM_AVAILABLE=3D1 -DUSE_LIBELF -DWL_HIDE_ > > DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS > > -DHAVE_DRISW_KMS -Werror=3Dimplicit-function-declaration > > -Werror=3Dmissing-prototypes -Werror=3Dreturn-type -Werror=3Dempty-body > > -Werror=3Dincompatible-po > > inter-types -Werror=3Dint-conversion -Wimplicit-fallthrough > > -Wmisleading-indentation -Wno-missing-field-initializers > > -Wno-format-truncation -fno-math-errno -fno-trapping-math > > -Qunused-arguments -fno-common -Wno-unk > > nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=3Dfor= > mat > > -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variabl= > e > > -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron > > g -fno-strict-aliasing -fPIC -pthread -Wno-override-init > > -Wno-initializer-overrides -MD -MQ > > src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF > > src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src > > /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c > > ../src/intel/common/xe/intel_gem.c > > FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o > > cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common > > -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel > > -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include > > -I/usr/l > > ocal/incl
Re: mesa-dri-24.0.8 failing to build on d1bd097d52cb
On June 1, 2024 1:35:29 AM PDT, Nuno Teixeira wrote: >(...) > >commit 108de784513d87bbe850e7b003a73e26b5b54caa >Author: Val Packett >Date: Fri May 31 08:45:02 2024 -0600 > >Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME > >Nuno Teixeira escreveu (sábado, 1/06/2024 à(s) 09:01): > >> Hello all, >> >> Anyone seeing this error on main? >> >> Thanks >> >> [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p >> -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc >> -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev >> -I/usr/local/ >> include -I/usr/local/include/libdrm -fvisibility=hidden >> -fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall >> -Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS >> -D__STDC_LIMIT_MACROS >> '-DPACKAGE_VERSION="24.0.8"' '-DPACKAGE_BUGREPORT=" >> https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=1 >> -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK >> -DHAVE_R300 -DHAVE_R600 >> -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA >> -DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1 >> -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 >> -DVIDEO >> _CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 >> -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM >> -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 >> -DENABLE_ST >> _OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING >> -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP >> -DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 >> -DHAVE___BUILTIN_BSWA >> P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ >> -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL >> -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNRE >> ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST >> -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC >> -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED >> -DHAVE_FUNC_ATTRIBUTE_WAR >> N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT >> -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL >> -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT >> TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN >> -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT >> -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H >> -DHAS_SCHED_GETAFFINITY -D >> HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H >> -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF >> -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R >> -DHAVE_GETRANDOM >> -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV >> -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN >> -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR >> -DSUPPORT_INTEL >> _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD >> -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING="15.0.7"' -DLLVM_IS_SHARED=1 >> -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DWL_HIDE_ >> DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS >> -DHAVE_DRISW_KMS -Werror=implicit-function-declaration >> -Werror=missing-prototypes -Werror=return-type -Werror=empty-body >> -Werror=incompatible-po >> inter-types -Werror=int-conversion -Wimplicit-fallthrough >> -Wmisleading-indentation -Wno-missing-field-initializers >> -Wno-format-truncation -fno-math-errno -fno-trapping-math >> -Qunused-arguments -fno-common -Wno-unk >> nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=format >> -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable >> -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron >> g -fno-strict-aliasing -fPIC -pthread -Wno-override-init >> -Wno-initializer-overrides -MD -MQ >> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF >> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src >> /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c >> ../src/intel/common/xe/intel_gem.c >> FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o >> cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common >> -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel >> -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include >> -I/usr/l >> ocal/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG >> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 >> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >> '-DPACKAGE_VERS >> ION="24.0.8"' '-DPACKAGE_BUGREPORT=" >> https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=1 >> -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK >> -DHAVE_R300
Re: mesa-dri-24.0.8 failing to build on d1bd097d52cb
(...) commit 108de784513d87bbe850e7b003a73e26b5b54caa Author: Val Packett Date: Fri May 31 08:45:02 2024 -0600 Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME Nuno Teixeira escreveu (sábado, 1/06/2024 à(s) 09:01): > Hello all, > > Anyone seeing this error on main? > > Thanks > > [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p > -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc > -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev > -I/usr/local/ > include -I/usr/local/include/libdrm -fvisibility=hidden > -fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall > -Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS > -D__STDC_LIMIT_MACROS > '-DPACKAGE_VERSION="24.0.8"' '-DPACKAGE_BUGREPORT=" > https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=1 > -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK > -DHAVE_R300 -DHAVE_R600 > -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA > -DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1 > -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 > -DVIDEO > _CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 > -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM > -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 > -DENABLE_ST > _OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING > -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP > -DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 > -DHAVE___BUILTIN_BSWA > P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ > -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL > -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNRE > ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST > -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC > -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED > -DHAVE_FUNC_ATTRIBUTE_WAR > N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT > -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL > -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT > TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN > -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT > -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H > -DHAS_SCHED_GETAFFINITY -D > HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H > -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF > -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R > -DHAVE_GETRANDOM > -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV > -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN > -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR > -DSUPPORT_INTEL > _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD > -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING="15.0.7"' -DLLVM_IS_SHARED=1 > -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DWL_HIDE_ > DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS > -DHAVE_DRISW_KMS -Werror=implicit-function-declaration > -Werror=missing-prototypes -Werror=return-type -Werror=empty-body > -Werror=incompatible-po > inter-types -Werror=int-conversion -Wimplicit-fallthrough > -Wmisleading-indentation -Wno-missing-field-initializers > -Wno-format-truncation -fno-math-errno -fno-trapping-math > -Qunused-arguments -fno-common -Wno-unk > nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=format > -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable > -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron > g -fno-strict-aliasing -fPIC -pthread -Wno-override-init > -Wno-initializer-overrides -MD -MQ > src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF > src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src > /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c > ../src/intel/common/xe/intel_gem.c > FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o > cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common > -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel > -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include > -I/usr/l > ocal/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > '-DPACKAGE_VERS > ION="24.0.8"' '-DPACKAGE_BUGREPORT=" > https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=1 > -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK > -DHAVE_R300 -DHAVE_R600 -DHAVE_RADEONSI > -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA -DUSE_VK_COMPILER=1 > -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1
mesa-dri-24.0.8 failing to build on d1bd097d52cb
Hello all, Anyone seeing this error on main? Thanks [ 28% 661/2246] cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/ include -I/usr/local/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="24.0.8"' '-DPACKAGE_BUGREPORT=" https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK -DHAVE_R300 -DHAVE_R600 -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA -DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1 -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 -DVIDEO _CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST _OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP -DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWA P64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNRE ACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WAR N_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_AT TRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN -D_GNU_SOURCE -DUSE_SSE41 -DHAVE___BUILTIN_IA32_CLFLUSHOPT -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY -D HAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DSUPPORT_INTEL _INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_LIBDRM '-DMESA_LLVM_VERSION_STRING="15.0.7"' -DLLVM_IS_SHARED=1 -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DWL_HIDE_ DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=empty-body -Werror=incompatible-po inter-types -Werror=int-conversion -Wimplicit-fallthrough -Wmisleading-indentation -Wno-missing-field-initializers -Wno-format-truncation -fno-math-errno -fno-trapping-math -Qunused-arguments -fno-common -Wno-unk nown-pragmas -Wno-microsoft-enum-value -Wno-unused-function -Werror=format -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-stron g -fno-strict-aliasing -fPIC -pthread -Wno-override-init -Wno-initializer-overrides -MD -MQ src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -MF src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o src /intel/common/libintel_common.a.p/xe_intel_gem.c.o -c ./src/intel/common/xe/intel_gem.c FAILED: src/intel/common/libintel_common.a.p/xe_intel_gem.c.o cc -Isrc/intel/common/libintel_common.a.p -Isrc/intel/common -I../src/intel/common -Iinclude -I../include -Isrc -I../src -Isrc/intel -I../src/intel -Isrc/intel/genxml -Isrc/intel/dev -I/usr/local/include -I/usr/l ocal/include/libdrm -fvisibility=hidden -fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERS ION="24.0.8"' '-DPACKAGE_BUGREPORT=" https://gitlab.freedesktop.org/mesa/mesa/-/issues";' -DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ZINK -DHAVE_R300 -DHAVE_R600 -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA -DUSE_VK_COMPILER=1 -DVIDEO_CODEC_VC1DEC=1 -DVIDEO_CODEC_H264DEC=1 -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 -DVIDEO_CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP
mesa-dri, mesa-libs, libglvnd, software rasteriser
Re: my e-mail of 25th June (below)
If I lock mesa-dri and mesa-libs before pkg upgrade, then I am free of
the software rasteriser problem following an upgrade.
However: the locks cause libglvnd to not install at upgrade time; and
then applications such as Firefox and Thunderbird will not start.
Should I treat the software rasteriser problem as a bug with mesa-dri,
mesa-libs or libglvnd?
<https://www.freshports.org/graphics/libglvnd/>
<https://www.freshports.org/graphics/mesa-dri/>
<https://www.freshports.org/graphics/mesa-libs/>
If I unlock the packages then allow installation of libglvnd, might
there be a workaround to the software rasteriser problem?
Thanks
root@momh167-gjp4-8570p:~ # date ; uname -v
Sun Jun 28 16:56:31 BST 2020
FreeBSD 13.0-CURRENT #58 r361769: Thu Jun 4 09:45:38 BST 2020
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
root@momh167-gjp4-8570p:~ # pkg lock -l
Currently locked packages:
mesa-dri-19.0.8_4
mesa-libs-19.0.8
waterfox-2019.12.c
root@momh167-gjp4-8570p:~ # pkg install libglvnd
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
libglvnd: 1.3.1 [FreeBSD]
Number of packages to be installed: 1
The process will require 4 MiB more space.
Proceed with this action? [y/N]: y
[1/1] Installing libglvnd-1.3.1...
pkg: libglvnd-1.3.1 conflicts with mesa-libs-19.0.8 (installs files into
the same place). Problematic file: /usr/local/include/EGL/egl.h
root@momh167-gjp4-8570p:~ # exit
logout
grahamperrin@momh167-gjp4-8570p:~ % firefox
ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol
"pthread_setname_np@FBSD_1.6"
grahamperrin@momh167-gjp4-8570p:~ % thunderbird
ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol
"pthread_setname_np@FBSD_1.6"
grahamperrin@momh167-gjp4-8570p:~ % virtualbox
VirtualBox: supR3HardenedMainGetTrustedMain:
dlopen("/usr/local/lib/virtualbox/VirtualBox.so",) failed:
/usr/local/lib/libglib-2.0.so.0: Undefined symbol
"pthread_setname_np@FBSD_1.6"
grahamperrin@momh167-gjp4-8570p:~ % beadm list
BE Active Mountpoint Space Created
Waterfox - - 1.4G 2020-03-10 18:24
r357746h - - 1.7G 2020-04-08 09:28
r361769c - - 2.7G 2020-06-12 13:52
r361769d NR / 84.7G 2020-06-28 16:02
grahamperrin@momh167-gjp4-8570p:~ % sudo beadm activate r361769c
grahamperrin's password:
Activated successfully
grahamperrin@momh167-gjp4-8570p:~ %
On 25/06/2020 16:45, Graham Perrin wrote:
Subject: Hardware acceleration lost (?) following pkg upgrade
For me, all recent attempts to upgrade lead to plasmashell using
excessive CPU and frequently crashing.
Discussion in IRC led to an observation that I'm apparently without
hardware acceleration after these upgrades. For example (GL_RENDERER
= Software Rasterizer):
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Wed 24 Jun 2020 11:13:00 BST
FreeBSD 13.0-CURRENT #58 r361769: Thu Jun 4 09:45:38 BST 2020
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
grahamperrin@momh167-gjp4-8570p:~ % glxgears -info
GL_RENDERER = Software Rasterizer
GL_VERSION = 2.1 Mesa 19.0.8
GL_VENDOR = Mesa Project
GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object
GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture
GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters
GL_EXT_draw_range_elements GL_EXT_packed_pixels
GL_EXT_point_parameters GL_EXT_rescale_normal
GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp
GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_multitexture
GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat
GL_3DFX_texture_compression_FXT1 GL_ARB_texture_cube_map
GL_ARB_texture_env_add GL_ARB_transpose_matrix
GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays
GL_EXT_secondary_color GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias
GL_INGR_blend_func_separate GL_NV_blend_square
GL_NV_light_max_exponent GL_NV_texgen_reflection
GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays
GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos
GL_NV_packed_depth_stencil GL_NV_texture_rectangle
GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow
GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar
GL_AR
Intel HD5000 graphics no /dev/dri
Hi It looks like HD5000 should be supported but I can't get it to work on the new MacBook Air. Attached the log which will show that there is no /dev/dri device. I compiled drivers and libraries the same way as I've done on HD4000 (Panasonic laptop) which works just fine (except switching to console, of course). Has anyone been successful with the HD5000? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog <http://brilliantobjc.blogspot.com> Mirama homepage <http://www.brilliantservice.co.jp/viking/> blog<http://hmdviking.blogspot.jp> Company homepage <http://www.brilliantservice.co.jp> Xorg.0.log Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 2012-06-09 21:57, O. Hartmann wrote: ... > Now, with your patch set installed again, graphics/dri compiles without > a flaw. > > I was wondering why there are not more people/FreeBSD users out there > having the very same problem. Most likely because neither WITH_NEW_XORG nor CC=clang are defaults (at least not yet ;). I haven't exactly followed the new xorg import, but I imagine it has been a huge effort to get everything upgraded without breaking too much existing stuff. However, this kind of major update always causes a few edge cases to blow up. That's why miwi sent the call for testing to several mailing lists. So please test, and if possible, send fixes! :) > I'd appreciate your patch getting permanent soon. Since this particular fix isn't yet integrated into the latest MesaLib release, I filed a PR, ports/168902. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 06/09/12 19:34, Dimitry Andric wrote: > On 2012-06-09 19:00, O. Hartmann wrote: > ... >> I try to track down problems on one of our FreeBSD 10.0-CURRENT/amd64 >> boxes and therefore, I try recompiling "xorg". >> >> One box is constantly failing to compile port graphics/dri with a >> obviously well know error, as "googling" reveals ( >> http://lists.freedesktop.org/archives/mesa-dev/2011-December/016348.html). >> >> I share /etc/make.conf and /etc/src.conf on those FreeBSD 10.0-CURRENT >> boxes, they are supposed to have set >> WITH_NEW_XORG=yes >> WITHOUT_NOUVEAU=yes >> >> There was a time when also WITH_KMS=yes was set on the box in question, >> but I disabled that again (commented out). >> >> The problem is sticky. I also tried "portmaster -f graphics/dri", >> everything is compiled well (CLANG) until it comes to graphics/dri itself. > > You asked the same question a few weeks ago: > > http://docs.freebsd.org/cgi/mid.cgi?4F9BC101.8090305 > > I posted a patch here: > > http://docs.freebsd.org/cgi/mid.cgi?4F9C2047.8020108 > > Afterwards, I asked either the libGL maintainers or x11@ if it was OK > to commit, but I received no response. O, sorry. I deleted the /usr/ports completely on that specific box. Now, with your patch set installed again, graphics/dri compiles without a flaw. I was wondering why there are not more people/FreeBSD users out there having the very same problem. I'd appreciate your patch getting permanent soon. Thanks, Oliver signature.asc Description: OpenPGP digital signature
Re: graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 2012-06-09 19:00, O. Hartmann wrote: ... > I try to track down problems on one of our FreeBSD 10.0-CURRENT/amd64 > boxes and therefore, I try recompiling "xorg". > > One box is constantly failing to compile port graphics/dri with a > obviously well know error, as "googling" reveals ( > http://lists.freedesktop.org/archives/mesa-dev/2011-December/016348.html). > > I share /etc/make.conf and /etc/src.conf on those FreeBSD 10.0-CURRENT > boxes, they are supposed to have set > WITH_NEW_XORG=yes > WITHOUT_NOUVEAU=yes > > There was a time when also WITH_KMS=yes was set on the box in question, > but I disabled that again (commented out). > > The problem is sticky. I also tried "portmaster -f graphics/dri", > everything is compiled well (CLANG) until it comes to graphics/dri itself. You asked the same question a few weeks ago: http://docs.freebsd.org/cgi/mid.cgi?4F9BC101.8090305 I posted a patch here: http://docs.freebsd.org/cgi/mid.cgi?4F9C2047.8020108 Afterwards, I asked either the libGL maintainers or x11@ if it was OK to commit, but I received no response. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
I try to track down problems on one of our FreeBSD 10.0-CURRENT/amd64
boxes and therefore, I try recompiling "xorg".
One box is constantly failing to compile port graphics/dri with a
obviously well know error, as "googling" reveals (
http://lists.freedesktop.org/archives/mesa-dev/2011-December/016348.html).
I share /etc/make.conf and /etc/src.conf on those FreeBSD 10.0-CURRENT
boxes, they are supposed to have set
WITH_NEW_XORG=yes
WITHOUT_NOUVEAU=yes
There was a time when also WITH_KMS=yes was set on the box in question,
but I disabled that again (commented out).
The problem is sticky. I also tried "portmaster -f graphics/dri",
everything is compiled well (CLANG) until it comes to graphics/dri itself.
graphics/libdrm is compiled without KMS.
Somehow bad things slipped into the system and I feel like floating like
a dead man in the water. I considered deleting /var/db/pkg/*, since
sometimes I need to delete manually specific folders in that directory
to make a port compiling again. But I do not know wether this is
introducing larger problems.
Compiling the whole ports (implies deleting them all) is no option for
this moment.
Does anyone know this problem and has a solution to get rid of this
sticky thing?
Regards,
Oliver
[...]
../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/local/include -I/usr/local/include/libdrm-DFEATURE_GL=1
-I/usr/local/include -I/usr/local/include/libdrm
-I/usr/local/include/nouveau -I/usr/local/include -O3 -pipe
-fno-strict-aliasing -march=native -Wall -Wmissing-prototypes -std=c99
-fno-strict-aliasing -O3 -pipe -fno-strict-aliasing -march=native -fPIC
-DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -fvisibility=hidden
nouveau_scratch.c -o nouveau_scratch.o
clang -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mapi
-I../../../../../src/mesa -I../../../../../src/egl/main
-I../../../../../src/egl/drivers/dri -I/usr/local/include
-I/usr/local/include/libdrm-DFEATURE_GL=1 -I/usr/local/include
-I/usr/local/include/libdrm -I/usr/local/include/nouveau
-I/usr/local/include -O3 -pipe -fno-strict-aliasing -march=native -Wall
-Wmissing-prototypes -std=c99 -fno-strict-aliasing -O3 -pipe
-fno-strict-aliasing -march=native -fPIC -DUSE_X86_64_ASM
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -fvisibility=hidden nouveau_array.c -o
nouveau_array.o
nouveau_array.c:49:16: error: illegal storage class on function
*extract_u = EXTRACT(char, unsigned, 1);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:49:16: error: expected ';' at end of declaration
*extract_u = EXTRACT(char, unsigned, 1);
^
nouveau_array.c:39:50: note: expanded from macro 'EXTRACT'
out_t f(struct nouveau_array *a, int i, int j) {\
^
nouveau_array.c:50:16: error: illegal storage class on function
*extract_f = EXTRACT(char, float, SCHAR_MAX);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:50:16: error: expected ';' at end of declaration
*extract_f = EXTRACT(char, float, SCHAR_MAX);
^
nouveau_array.c:39:50: note: expanded from macro 'EXTRACT'
out_t f(struct nouveau_array *a, int i, int j) {\
^
nouveau_array.c:53:16: error: illegal storage class on function
*extract_u = EXTRACT(unsigned char, unsigned, 1);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:53:16: error: expected ';' at end of declaration
*extract_u = EXTRACT(unsigned char, unsigned, 1);
^
nouveau_array.c:39:50: note: expanded from macro 'EXTRACT'
out_t f(struct nouveau_array *a, int i, int j) {\
^
nouveau_array.c:54:16: error: illegal storage class on function
*extract_f = EXTRACT(unsigned char, float, UCHAR_MAX);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t
Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
Dimitry Andric wrote: On 2012-04-28 13:12, Volodymyr Kostyrko wrote: O. Hartmann wrote: Is there in "official" way to get this fixed with CLANG? I see that files folder in graphics/dri is missing, so none of the fixes for both the faulty source files I think the patch should go to graphics/libGL. cd /usr/ports/graphics/libGL/files fetch -rao - 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|'> patch-nouveau Should do. Please try this patch (lightly tested): http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff Works for me. Could this one be commited? It looks better then my quick hack. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
Am 04/28/12 18:52, schrieb Dimitry Andric: > On 2012-04-28 13:12, Volodymyr Kostyrko wrote: >> O. Hartmann wrote: >>> Is there in "official" way to get this fixed with CLANG? I see that >>> files folder in graphics/dri is missing, so none of the fixes for both >>> the faulty source files >> >> I think the patch should go to graphics/libGL. >> >> cd /usr/ports/graphics/libGL/files >> fetch -rao - >> 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' >> >> | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|' > patch-nouveau >> >> Should do. > > Please try this patch (lightly tested): > > http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff I'll give it a try as soon as possible. Ath the moment, things went perfect utilizing the initial hint by Volodymyr Kostyrko. signature.asc Description: OpenPGP digital signature
Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
Am 04/28/12 13:12, schrieb Volodymyr Kostyrko: > O. Hartmann wrote: >> Is there in "official" way to get this fixed with CLANG? I see that >> files folder in graphics/dri is missing, so none of the fixes for both >> the faulty source files > > I think the patch should go to graphics/libGL. > > cd /usr/ports/graphics/libGL/files > fetch -rao - > 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' > | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|' > patch-nouveau > > Should do. > Thank you very much. Yes, this worked ;-) Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 2012-04-28 13:12, Volodymyr Kostyrko wrote: > O. Hartmann wrote: >> Is there in "official" way to get this fixed with CLANG? I see that >> files folder in graphics/dri is missing, so none of the fixes for both >> the faulty source files > > I think the patch should go to graphics/libGL. > > cd /usr/ports/graphics/libGL/files > fetch -rao - > 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' > > | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|' > patch-nouveau > > Should do. Please try this patch (lightly tested): http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
O. Hartmann wrote: Is there in "official" way to get this fixed with CLANG? I see that files folder in graphics/dri is missing, so none of the fixes for both the faulty source files I think the patch should go to graphics/libGL. cd /usr/ports/graphics/libGL/files fetch -rao - 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|' > patch-nouveau Should do. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
Compiling Xorg stuff with the switch set in /etc/make.conf for the new Xorg graphics/dri mesa 7.11.x and xorg-server 1.10.6 with CLANG on bot FreeBSD 10 and 9 end up in an error: nouveau_array.c:49:16: error: illegal storage class on function *extract_u = EXTRACT(char, unsigned, 1); This error seem to be well known since last year, as this links states: http://lists.freedesktop.org/archives/nouveau/2011-December/009768.html and claimed to be resolved, as this link indicates: http://lists.freedesktop.org/archives/mesa-dev/2012-March/019815.html and http://cgit.freedesktop.org/mesa/mesa/commit/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95 Is there in "official" way to get this fixed with CLANG? I see that files folder in graphics/dri is missing, so none of the fixes for both the faulty source files nouveau_array.c nouveau_render_t.c as indicated by the patches have been fixed permanently for CLANG with FreeBSD so far. It would be a pleasure having a "nice" solution using CLANG. I was looking for a switch allowing to patch the sources upon a criteria, but the ports framework seems not to be capable of such a thing. If there is already a solution I would be pleased to have it, too, if available, otherwise I will go for installation of GIT, sucking in the patches and create myself patchfiles. I'm hesitating to do so at the moment since I don't want to have git installed since I do not use it, yet (updating useless/unused ports is sometimes a waste of time on slow boxes, sorry). Thanks in advance, Oliver signature.asc Description: OpenPGP digital signature
Re: DRI build failing
Sorry, I should have posted this in the ports mailing list and will do so. On Fri, Oct 22, 2010 at 2:13 PM, Chris wrote: > Hello, > > Seeing this on an amd64 box when doing a fresh Xorg build: > > ===> Building for dri-7.6.1,2 > gmake[1]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' > Making sources for autoconf > gmake[2]: Entering directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > rm -f depend > touch depend > /usr/local/bin/makedepend -fdepend -I. -I../../../include > -I../../../include/GL/internal -I../../../src/mesa > -I../../../src/mesa/glapi -I/usr/local/include > -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include glcontextmodes.c clientattrib.c compsize.c > eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c > indirect_init.c indirect_size.c indirect_window_pos.c > indirect_texture_compression.c indirect_transpose_matrix.c > indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c > render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c > glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c > glxhash.c dri2_glx.c dri2.c \ > ../../../src/mesa/main/dispatch.c > ../../../src/mesa/glapi/glapi.c > ../../../src/mesa/glapi/glapi_getproc.c > ../../../src/mesa/glapi/glthread.c > ../../../src/mesa/x86-64/glapi_x86-64.S > gmake[2]: Leaving directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > gmake[2]: Entering directory > `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' > cc -L/usr/local/lib -I/usr/local/include -c -I. -I../../../include > -I../../../include/GL/internal -I../../../src/mesa > -I../../../src/mesa/glapi -I/usr/local/include > -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include -I/usr/local/include -O2 -pipe -march=native > -fno-strict-aliasing -Wall -Wmissing-prototypes -std=c99 -ffast-math > -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN > -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING > -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER > -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\" glcontextmodes.c -o > glcontextmodes.o > glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': > glcontextmodes.c:193: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:194: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:196: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:197: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:200: error: '__GLcontextModes' has no member named > 'yInverted' > glcontextmodes.c: In function '_gl_get_context_mode_data': > glcontextmodes.c:333: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:336: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:339: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:343: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:346: error: '__GLcontextModes' has no member named > 'yInverted' > glcontextmodes.c: In function '_gl_context_modes_create': > glcontextmodes.c:418: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:419: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:420: error: '__GLcontextModes' has no member named > 'bindToMipmapTexture' > glcontextmodes.c:421: error: '__GLcontextModes' has no member named > 'bindToTextureTargets' > glcontextmodes.c:422: error: '__GLcontextModes' has no member named > 'yInverted' > glcontextmodes.c: In function '_gl_context_modes_are_same': > glcontextmodes.c:539: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:539: error: '__GLcontextModes' has no member named > 'bindToTextureRgb' > glcontextmodes.c:540: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:540: error: '__GLcontextModes' has no member named > 'bindToTextureRgba' > glcontextmodes.c:541: error: &
DRI build failing
Hello, Seeing this on an amd64 box when doing a fresh Xorg build: ===> Building for dri-7.6.1,2 gmake[1]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' Making sources for autoconf gmake[2]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' rm -f depend touch depend /usr/local/bin/makedepend -fdepend -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include glcontextmodes.c clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c indirect_size.c indirect_window_pos.c indirect_texture_compression.c indirect_transpose_matrix.c indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c dri2_glx.c dri2.c \ ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/glapi.c ../../../src/mesa/glapi/glapi_getproc.c ../../../src/mesa/glapi/glthread.c ../../../src/mesa/x86-64/glapi_x86-64.S gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' gmake[2]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' cc -L/usr/local/lib -I/usr/local/include -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -O2 -pipe -march=native -fno-strict-aliasing -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\" glcontextmodes.c -o glcontextmodes.o glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': glcontextmodes.c:193: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:194: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:196: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:197: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:200: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_get_context_mode_data': glcontextmodes.c:333: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:336: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:339: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:343: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:346: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_create': glcontextmodes.c:418: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:419: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:420: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:421: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:422: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_are_same': glcontextmodes.c:539: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:539: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:540: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:540: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:541: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:541: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:542: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:542: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c:543: error: '__GLcontext
Re: Radeon 7500 w/ DRI locking on restart of X
Eric, I updated my 5.1-RELEASE system to CURRENT dated today at approx. 9:10 CDT to give your changes a try. I had a bit of a fright at first with kernel panics right at the end of the boot sequence but it turned out I had forgotten to disable the ltmdm code -- the kernel module compiled under -RELEASE wasn't friendly to -CURRENT. I've got just a basic install with my custom kernel. I'm using the packages for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! I restarted about 10 times in a row and ran glxinfo and glxgears each time to verify DRI was still activated and working -- no issues. VT switches are fine (even while running glxgears). The one thing that does not work is resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no ability *apparently* to switch to a VT; the keystrokes just generate beeps. Interestingly, the cursor still changed between the different modes when mousing over the xterm and onto the background. Also, Alt-Cntl-Del did work just fine. The only other thing I noticed is that there seems to be a syslog entry for every instance of running glxgears that reads: [MP SAFE] drm0 Is this expected behavior? I noticed that same message (in brackets) in front of each of my disks as they were probed during boot. Any further info you'd like or more testing I could do to help? Sean -Original Message- From: Eric Anholt <[EMAIL PROTECTED]> Sent: Oct 23, 2003 9:09 PM To: Glenn Johnson <[EMAIL PROTECTED]> Cc: Vulpes Velox <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Tue, 2003-08-26 at 20:37, Glenn Johnson wrote: > On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > > > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > > > I had similar problem with a 7200 and OGL. I solved the problem by > > > turning off some of the options in the X config. > > > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > > collections and various versions of DRI installed over a ports > > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > > laptop. > > > > > > > > Everything works perfectly unless/until I restart the X server. > > > > This appears to be initiated automatically when running GDM -- ie, > > > > GDM starts, you log in using that X session, you log out and the > > > > session stops, GDM starts X again and displays the login screen. > > > > Everyone that's experiencing this and is using the DRI, what version > > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > > this without the DRI loaded? The ForcePCIMode workaround is > > interesting, I'll take a look at what could be going on there. > > I did some googling tonight and found out this problem is supposedly > fixed in XFree86-4.3.99 although I do not see any specific mention of > this problem in the Changelog. See: > > http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight= That patch has been in our XFree86 for quite a while. For those of you using -current, could you try with the latest DRM which I committed to FreeBSD CVS a few minutes ago? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
Okay. I won't worry about the messages then. I mentioned the suspend/resume problem only because it actually worked correctly when using option ForcePCIMode; I was shocked when it did and was hoping that your fix for AGP accelerated DRI would pull off the same trick. I should note here that I didn't see any of the panics other people did before your last iteration of the fix. I'm guessing it is because I didn't actually compile the code into my kernel but instead let it build new modules. Any idea why that would make the difference? Sean -Original Message- From: Eric Anholt <[EMAIL PROTECTED]> Sent: Oct 27, 2003 11:48 PM To: Sean Welch <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Fri, 2003-10-24 at 11:06, Sean Welch wrote: > Eric, I updated my 5.1-RELEASE system to CURRENT dated today at > approx. 9:10 CDT to give your changes a try. I had a bit of a fright at > first with kernel panics right at the end of the boot sequence but it turned > out I had forgotten to disable the ltmdm code -- the kernel module > compiled under -RELEASE wasn't friendly to -CURRENT. > > I've got just a basic install with my custom kernel. I'm using the packages > for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! > I restarted about 10 times in a row and ran glxinfo and glxgears each time > to verify DRI was still activated and working -- no issues. VT switches are > fine (even while running glxgears). The one thing that does not work is > resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no > ability *apparently* to switch to a VT; the keystrokes just generate beeps. > Interestingly, the cursor still changed between the different modes when > mousing over the xterm and onto the background. Also, Alt-Cntl-Del did > work just fine. Suspend/resume is doesn't work well. You might get lucky with the -current DRM with XFree86-4-Server-snap. > The only other thing I noticed is that there seems to be a syslog entry for > every instance of running glxgears that reads: > > [MP SAFE] drm0 > > Is this expected behavior? I noticed that same message (in brackets) in > front of each of my disks as they were probed during boot. That printout happens whenever an mpsafe interrupt handler is installed. It gets installed upon initializing the DRI in the server. I don't think any drivers do it more often. It may happen frequently if glxgears is your only app running, in which case you'll get a server regenerate on exit of glxgears. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Fri, 2003-10-24 at 11:06, Sean Welch wrote: > Eric, I updated my 5.1-RELEASE system to CURRENT dated today at > approx. 9:10 CDT to give your changes a try. I had a bit of a fright at > first with kernel panics right at the end of the boot sequence but it turned > out I had forgotten to disable the ltmdm code -- the kernel module > compiled under -RELEASE wasn't friendly to -CURRENT. > > I've got just a basic install with my custom kernel. I'm using the packages > for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! > I restarted about 10 times in a row and ran glxinfo and glxgears each time > to verify DRI was still activated and working -- no issues. VT switches are > fine (even while running glxgears). The one thing that does not work is > resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no > ability *apparently* to switch to a VT; the keystrokes just generate beeps. > Interestingly, the cursor still changed between the different modes when > mousing over the xterm and onto the background. Also, Alt-Cntl-Del did > work just fine. Suspend/resume is doesn't work well. You might get lucky with the -current DRM with XFree86-4-Server-snap. > The only other thing I noticed is that there seems to be a syslog entry for > every instance of running glxgears that reads: > > [MP SAFE] drm0 > > Is this expected behavior? I noticed that same message (in brackets) in > front of each of my disks as they were probed during boot. That printout happens whenever an mpsafe interrupt handler is installed. It gets installed upon initializing the DRI in the server. I don't think any drivers do it more often. It may happen frequently if glxgears is your only app running, in which case you'll get a server regenerate on exit of glxgears. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
Eric, I updated my 5.1-RELEASE system to CURRENT dated today at approx. 9:10 CDT to give your changes a try. I had a bit of a fright at first with kernel panics right at the end of the boot sequence but it turned out I had forgotten to disable the ltmdm code -- the kernel module compiled under -RELEASE wasn't friendly to -CURRENT. I've got just a basic install with my custom kernel. I'm using the packages for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! I restarted about 10 times in a row and ran glxinfo and glxgears each time to verify DRI was still activated and working -- no issues. VT switches are fine (even while running glxgears). The one thing that does not work is resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no ability *apparently* to switch to a VT; the keystrokes just generate beeps. Interestingly, the cursor still changed between the different modes when mousing over the xterm and onto the background. Also, Alt-Cntl-Del did work just fine. The only other thing I noticed is that there seems to be a syslog entry for every instance of running glxgears that reads: [MP SAFE] drm0 Is this expected behavior? I noticed that same message (in brackets) in front of each of my disks as they were probed during boot. Any further info you'd like or more testing I could do to help? Sean -Original Message- From: Eric Anholt <[EMAIL PROTECTED]> Sent: Oct 23, 2003 9:09 PM To: Glenn Johnson <[EMAIL PROTECTED]> Cc: Vulpes Velox <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Tue, 2003-08-26 at 20:37, Glenn Johnson wrote: > On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > > > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > > > I had similar problem with a 7200 and OGL. I solved the problem by > > > turning off some of the options in the X config. > > > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > > collections and various versions of DRI installed over a ports > > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > > laptop. > > > > > > > > Everything works perfectly unless/until I restart the X server. > > > > This appears to be initiated automatically when running GDM -- ie, > > > > GDM starts, you log in using that X session, you log out and the > > > > session stops, GDM starts X again and displays the login screen. > > > > Everyone that's experiencing this and is using the DRI, what version > > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > > this without the DRI loaded? The ForcePCIMode workaround is > > interesting, I'll take a look at what could be going on there. > > I did some googling tonight and found out this problem is supposedly > fixed in XFree86-4.3.99 although I do not see any specific mention of > this problem in the Changelog. See: > > http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight= That patch has been in our XFree86 for quite a while. For those of you using -current, could you try with the latest DRM which I committed to FreeBSD CVS a few minutes ago? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, 2003-08-26 at 20:37, Glenn Johnson wrote: > On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > > > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > > > I had similar problem with a 7200 and OGL. I solved the problem by > > > turning off some of the options in the X config. > > > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > > collections and various versions of DRI installed over a ports > > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > > laptop. > > > > > > > > Everything works perfectly unless/until I restart the X server. > > > > This appears to be initiated automatically when running GDM -- ie, > > > > GDM starts, you log in using that X session, you log out and the > > > > session stops, GDM starts X again and displays the login screen. > > > > Everyone that's experiencing this and is using the DRI, what version > > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > > this without the DRI loaded? The ForcePCIMode workaround is > > interesting, I'll take a look at what could be going on there. > > I did some googling tonight and found out this problem is supposedly > fixed in XFree86-4.3.99 although I do not see any specific mention of > this problem in the Changelog. See: > > http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight= That patch has been in our XFree86 for quite a while. For those of you using -current, could you try with the latest DRM which I committed to FreeBSD CVS a few minutes ago? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, 26 Aug 2003, Eric Anholt wrote: > (CC'ed to -current since it's not -stable specific) > > Everyone that's experiencing this and is using the DRI, what version of > the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > this without the DRI loaded? The ForcePCIMode workaround is > interesting, I'll take a look at what could be going on there. Just another datapoint, I've been running a 7500 under 4.8 -stable: FreeBSD 4.8-STABLE #10: Fri Jun 20 19:11:44 EDT 2003 and 5.1-RELEASE with no problems whatsoever (same machine). >From 5.1 dmesg: drm0: port 0xc000-0xc0ff mem 0xed00-0xed00,0xe000-0xe7ff at device 0.0 on pci1 info: [drm] AGP at 0xe800 64MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 This is a totally quirky and weird DFI board which is incredibly picky about what cards are where and it's been stable since I first ran your original DRI patches. Charles > -- > Eric Anholt[EMAIL PROTECTED] > http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
Okay, one more message before I *finally* go to bed. I got kind of excited by the stuff below... I decided to update my DRI install to see if things would improve. Now 4.8-RELEASE responds to the forcepcimode option nearly as well as 5.1-RELEASE does for me! I thought I had it made -- I've even found that a resume from hard drive with DRI enabled doesn't lock the machine!! That has *NEVER* worked before! Then I tried a switch to a virtual terminal and back. I get a corrupted color map with lock followed shortly thereafter by a reboot. I booted up under 5.1 and verified that this does *not* happen there. I didn't try a suspend/resume sequence there but I expect it works there as well. I'm guessing this is just a glitch in the DRI CVS code at the moment. The source is from around 9 08/26/03 and the output of 'dmesg | grep drm' is: drm0: port 0xcc00-0xccff mem 0xfcff-0xfcff,0xe000-0xe7ff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe800 64MB info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 It also seems that in most cases the performance hit is not as great as I had thought. If this works as well on the desktop machines I think I can work around the vt switching issue for the moment. Does any of this suggest anything to you, Eric? Anything I can help test? Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
I sent an earlier message which seems to have disappeared into the void. I tried the forcepcimode under the 5.1 install on my laptop (RELEASE with upgraded ports tree) and found that it behaved as you said yours does. I can't get it to hang no matter what I do now -- though the performance is a little less than half what it was with the AGP. I haven't had a chance to try that option on my desktops. If it works there I'll be mighty happy! Your other message about the newest version of X having this fixed is very interesting; I track both XFree86 and DRI CVS daily. The only problem is that I have nearly 2 GB of programs built on top of X, so that is not nearly as easy to upgrade... Maybe it is time for me to finally blow away that install of 4.7-RELEASE and try it out. Sean ---Original Message--- From: Glenn Johnson <[EMAIL PROTECTED]> Sent: 08/26/03 09:14 PM To: [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X > > On Tue, Aug 26, 2003 at 03:31:29PM -0500, Sean Welch wrote: > I have precisely the same symptoms as what Glenn listed. > > I have now tried the forcepcimode option on the laptop and > unfortunately experienced what appears to be the opposite effect to > what Glenn noted. I get a black screen with lots of disk activity. > I can log in remotely (at least that seemed to work every time) and > a top listing shows X taking up more and more CPU cycles. It seems > to be scribbling to the disk making temporary files as well because > eventually I couldn't edit the XF86Config file any longer -- I was > getting a "no space left on device" error. I ended up taking out all > options short of disabling DRI altogether and eventually discovered > the only way I could run with DRI switches on and forcepcimode set > to true was to unload the agp module from kernel space. This got it > started just fine but there was no DRI. It seems that X is getting > confused and somehow PCI and AGP modes are duking it out... Does it work on your desktops? I do not have agp in the kernel config. When X starts it loads both the radeon and agp modules, or maybe the radeon module is loading the agp module. Either way, both radeon.ko and agp.ko get loaded up. Here is some info about my hardware: - The motherboard is an Abit IS7 (P4c w/865PE chipset) - The graphics card is an ATI Radeon 9100 Here is the device section of my XF86Config (sans comments): Section "Device" Identifier "Card0" Driver "ati" VendorName "ATI Technologies Inc" BoardName "Radeon R200 QM [Radeon 9100]" BusID "PCI:1:0:0" Option "DDCMode" "true" Option "ForcePCIMode" "true" EndSection Finally, here are the first few lines of glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 -- Glenn Johnson > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > I had similar problem with a 7200 and OGL. I solved the problem by > > turning off some of the options in the X config. > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > <[EMAIL PROTECTED]> wrote: > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > collections and various versions of DRI installed over a ports > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > laptop. > > > > > > Everything works perfectly unless/until I restart the X server. > > > This appears to be initiated automatically when running GDM -- ie, > > > GDM starts, you log in using that X session, you log out and the > > > session stops, GDM starts X again and displays the login screen. > > Everyone that's experiencing this and is using the DRI, what version > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > this without the DRI loaded? The ForcePCIMode workaround is > interesting, I'll take a look at what could be going on there. I did some googling tonight and found out this problem is supposedly fixed in XFree86-4.3.99 although I do not see any specific mention of this problem in the Changelog. See: http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight= -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: ...snip... > Everyone that's experiencing this and is using the DRI, what version > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > this without the DRI loaded? The ForcePCIMode workaround is > interesting, I'll take a look at what could be going on there. drm0: port 0x9000-0x90ff mem 0xf900-0xf900,0xe000-0xefff irq 2 at device 0.0 on pci1 info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 info: [drm] Loading R200 Microcode -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 03:31:29PM -0500, Sean Welch wrote: > I have precisely the same symptoms as what Glenn listed. > > I have now tried the forcepcimode option on the laptop and > unfortunately experienced what appears to be the opposite effect to > what Glenn noted. I get a black screen with lots of disk activity. > I can log in remotely (at least that seemed to work every time) and > a top listing shows X taking up more and more CPU cycles. It seems > to be scribbling to the disk making temporary files as well because > eventually I couldn't edit the XF86Config file any longer -- I was > getting a "no space left on device" error. I ended up taking out all > options short of disabling DRI altogether and eventually discovered > the only way I could run with DRI switches on and forcepcimode set > to true was to unload the agp module from kernel space. This got it > started just fine but there was no DRI. It seems that X is getting > confused and somehow PCI and AGP modes are duking it out... Does it work on your desktops? I do not have agp in the kernel config. When X starts it loads both the radeon and agp modules, or maybe the radeon module is loading the agp module. Either way, both radeon.ko and agp.ko get loaded up. Here is some info about my hardware: - The motherboard is an Abit IS7 (P4c w/865PE chipset) - The graphics card is an ATI Radeon 9100 Here is the device section of my XF86Config (sans comments): Section "Device" Identifier "Card0" Driver "ati" VendorName "ATI Technologies Inc" BoardName "Radeon R200 QM [Radeon 9100]" BusID "PCI:1:0:0" Option "DDCMode" "true" Option "ForcePCIMode" "true" EndSection Finally, here are the first few lines of glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, 26 Aug 2003 13:27:11 -0700 Eric Anholt <[EMAIL PROTECTED]> wrote: > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > I had similar problem with a 7200 and OGL. I solved the problem by turning > > off some of the options in the X config. > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) > > Sean Welch <[EMAIL PROTECTED]> wrote: > > > > > Is anyone else seeing this issue? I'm running into it > > > on desktop boxes and a laptop running 4.8-RELEASE with > > > up to date ports collections and various versions of > > > DRI installed over a ports version of X. I'm also seeing > > > this under 5.1-RELEASE on the laptop. > > > > > > Everything works perfectly unless/until I restart the X > > > server. This appears to be initiated automatically when > > > running GDM -- ie, GDM starts, you log in using that X > > > session, you log out and the session stops, GDM starts X > > > again and displays the login screen. > > > > > > This seems to happen a bit more than 1/3 of the times I > > > try it (intentionally or not). It isn't much of a problem > > > on the laptop as I'm the only user and tend to turn the > > > machine off when I log out but it is causing all sorts of > > > issues on the desktops because they are intended to be > > > used as multi-user (serially and also simultaneously) > > > systems. > > > > > > Any ideas? The instability goes away completely with DRI > > > disabled, but part of the use of these desktops is in the > > > accelerated OpenGL rendering... > > > > > > Sean > > (CC'ed to -current since it's not -stable specific) > > This is an example of why people need to send PRs and not just emails. > I realize now I've seen emails on this before, but I had forgotten about > them because they seemed isolated and I didn't have them piling up in my > assigned prs list (things pile up in my mailboxes easily, and I don't go > back and check very often). > > I've tried to reproduce this with a radeon, by doing startx, C-A-B to > kill the server, then startx again. The second time, the screen > displays for a brief moment then goes black. The system isn't hung, and > I can exit using C-A-B again. Is this what everyone else sees? > > Everyone that's experiencing this and is using the DRI, what version of > the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > this without the DRI loaded? The ForcePCIMode workaround is > interesting, I'll take a look at what could be going on there. drm0: port 0x9800-0x98ff mem 0xdfe8-0xdfef,0xd800-0xdbff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe000 64MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > I had similar problem with a 7200 and OGL. I solved the problem by > > turning off some of the options in the X config. > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > <[EMAIL PROTECTED]> wrote: > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > collections and various versions of DRI installed over a ports > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > laptop. > > > > > > Everything works perfectly unless/until I restart the X server. > > > This appears to be initiated automatically when running GDM -- ie, > > > GDM starts, you log in using that X session, you log out and the > > > session stops, GDM starts X again and displays the login screen. > > > > > > This seems to happen a bit more than 1/3 of the times I try it > > > (intentionally or not). It isn't much of a problem on the laptop > > > as I'm the only user and tend to turn the machine off when I log > > > out but it is causing all sorts of issues on the desktops because > > > they are intended to be used as multi-user (serially and also > > > simultaneously) systems. > > > > > > Any ideas? The instability goes away completely with DRI > > > disabled, but part of the use of these desktops is in the > > > accelerated OpenGL rendering... > > > > > > Sean > > (CC'ed to -current since it's not -stable specific) > > This is an example of why people need to send PRs and not just emails. > I realize now I've seen emails on this before, but I had forgotten > about them because they seemed isolated and I didn't have them piling > up in my assigned prs list (things pile up in my mailboxes easily, and > I don't go back and check very often). Speaking for myself, I was not sure whether the problem was a BIOS setting problem, a graphics card problem, a FreeBSD problem, an XFree86 problem, or a configuration problem on my part. Until today, I thought I was the only one with seeing this. I discovered the "ForcePCIMode" option as a potential workaround only two days ago and I wanted to confirm that it did indeed make the problem go away before filing a PR and sending an e-mail directly to you about the issue. In fact, I was planning on doing that this evening after a few more tests. > I've tried to reproduce this with a radeon, by doing startx, C-A-B > to kill the server, then startx again. The second time, the screen > displays for a brief moment then goes black. The system isn't hung, > and I can exit using C-A-B again. Is this what everyone else sees? Sometimes. At times the Xserver will not start and I can switch to a console and login. Any further attempts to restart X will lock the machine up. Other times, the screen just goes black and the machine is locked up. I can not switch to a console nor ssh in via another machine. In that case, I have to hit the reset switch. Still other times, the gdm login screen will appear and look normal, except the cursor is not blinking and the keyboard and mouse do not respond. I did not try to ssh into the machine in that state but I would guess that it would fail. > Everyone that's experiencing this and is using the DRI, what version > of the radeon DRM is loaded? (dmesg | grep drm) I will have to get the dmesg output for you when I get home but it is the latest version in -current, with -current being up to date as of Aug 25, 2003, about 9:00 PM CDT. > Is anyone experiencing this without the DRI loaded? Not me; when I disable DRI the lock ups do not occur. > The ForcePCIMode workaround is interesting, I'll take a look at what > could be going on there. I have had that option in my config file for about two days and have tested by logging in and out repeatedly. So far, I have not had a lock up with that option enabled. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
I have precisely the same symptoms as what Glenn listed. I have now tried the forcepcimode option on the laptop and unfortunately experienced what appears to be the opposite effect to what Glenn noted. I get a black screen with lots of disk activity. I can log in remotely (at least that seemed to work every time) and a top listing shows X taking up more and more CPU cycles. It seems to be scribbling to the disk making temporary files as well because eventually I couldn't edit the XF86Config file any longer -- I was getting a "no space left on device" error. I ended up taking out all options short of disabling DRI altogether and eventually discovered the only way I could run with DRI switches on and forcepcimode set to true was to unload the agp module from kernel space. This got it started just fine but there was no DRI. It seems that X is getting confused and somehow PCI and AGP modes are duking it out... Here is a listing of the X modules from ports: XFree86-4.3.0,1 XFree86-FontServer-4.3.0 XFree86-Server-4.3.0_5 XFree86-clients-4.3.0_1 XFree86-documents-4.3.0 XFree86-font100dpi-4.3.0 XFree86-font75dpi-4.3.0 XFree86-fontCyrillic-4.3.0 XFree86-fontDefaultBitmaps-4.3.0 XFree86-fontEncodings-4.3.0 XFree86-fontScalable-4.3.0 XFree86-libraries-4.3.0_3 Xaw3d-1.5 Xft-2.1_8 This is what I see from 'dmesg | grep drm' : drm0: port 0xcc00-0xccff mem 0xfcff-0xfcff,0xe000-0xe7ff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe800 64MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 Here is the output of 'head /var/log/XFree86.0.log' : XFree86 Version 4.3.0 (DRI trunk) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 4.8-RELEASE i386 [ELF] Build Date: 09 August 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, The above was built on 08/03/03 in the evening. Here is 'uname -a': FreeBSD NitroPhys.welchsmnet.net 4.8-RELEASE FreeBSD 4.8-RELEASE #1: Thu May 29 11:24:46 CDT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/NITROPHYS i386 The kernel is compiled with SSE support. I have tried turning off all options in the config file and different AGP modes. I always get the same results. My 5.1-RELEASE install is just using the X off the install disc with the kernel module that shipped with it. Same exact issues. I believe I saw a commit to DRI CVS a while back that was supposed to address this very issue (comment said something about locks on logout with GDM) but it didn't change anything for me. Let me know what else you'd like to have in the way of info. Sean ---Original Message--- From: Glenn Johnson <[EMAIL PROTECTED]> Sent: 08/26/03 03:55 PM To: Eric Anholt <[EMAIL PROTECTED]> Subject: Re: Radeon 7500 w/ DRI locking on restart of X > > On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > I had similar problem with a 7200 and OGL. I solved the problem by > > turning off some of the options in the X config. > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > <[EMAIL PROTECTED]> wrote: > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > collections and various versions of DRI installed over a ports > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > laptop. > > > > > > Everything works perfectly unless/until I restart the X server. > > > This appears to be initiated automatically when running GDM -- ie, > > > GDM starts, you log in using that X session, you log out and the > > > session stops, GDM starts X again and displays the login screen. > > > > > > This seems to happen a bit more than 1/3 of the times I try it > > > (intentionally or not). It isn't much of a problem on the laptop > > > as I'm the only user and tend to turn the machine off when I log > > > out but it is causing all sorts of issues on the desktops because > > > they are intended to be used as multi-user (serially and also > > > simultaneously) systems. > > > > > > Any ideas? The instability goes away completely with DRI > > > disabled, but part of the use of these desktops is in the > > > accelerated OpenGL rendering... > > > > > > Sean > > (CC'ed to -current since it's not -stable specific) > > This
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > I had similar problem with a 7200 and OGL. I solved the problem by turning off > some of the options in the X config. > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) > Sean Welch <[EMAIL PROTECTED]> wrote: > > > Is anyone else seeing this issue? I'm running into it > > on desktop boxes and a laptop running 4.8-RELEASE with > > up to date ports collections and various versions of > > DRI installed over a ports version of X. I'm also seeing > > this under 5.1-RELEASE on the laptop. > > > > Everything works perfectly unless/until I restart the X > > server. This appears to be initiated automatically when > > running GDM -- ie, GDM starts, you log in using that X > > session, you log out and the session stops, GDM starts X > > again and displays the login screen. > > > > This seems to happen a bit more than 1/3 of the times I > > try it (intentionally or not). It isn't much of a problem > > on the laptop as I'm the only user and tend to turn the > > machine off when I log out but it is causing all sorts of > > issues on the desktops because they are intended to be > > used as multi-user (serially and also simultaneously) > > systems. > > > > Any ideas? The instability goes away completely with DRI > > disabled, but part of the use of these desktops is in the > > accelerated OpenGL rendering... > > > > Sean (CC'ed to -current since it's not -stable specific) This is an example of why people need to send PRs and not just emails. I realize now I've seen emails on this before, but I had forgotten about them because they seemed isolated and I didn't have them piling up in my assigned prs list (things pile up in my mailboxes easily, and I don't go back and check very often). I've tried to reproduce this with a radeon, by doing startx, C-A-B to kill the server, then startx again. The second time, the screen displays for a brief moment then goes black. The system isn't hung, and I can exit using C-A-B again. Is this what everyone else sees? Everyone that's experiencing this and is using the DRI, what version of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing this without the DRI loaded? The ForcePCIMode workaround is interesting, I'll take a look at what could be going on there. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is DRI on FreeBSD unmaintained?
In message: <[EMAIL PROTECTED]> Lefteris Chatzibarbas <[EMAIL PROTECTED]> writes: : Is DRI on FreeBSD unmaintained? Am I sending my problem report to the : wrong place? What should I do or who should I contact about this? anholt is currently on vacation... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is DRI on FreeBSD unmaintained?
On Sat, Jun 21, 2003 at 04:12:48PM +0300, Lefteris Chatzibarbas wrote: > Hello, > > I believe that the web page related to DRI on BSD (FreeBSD and NetBSD) > is: > > http://people.freebsd.org/~anholt/dri/index.html > > I have mailed both this mailing list and [EMAIL PROTECTED] (contact address > as stated in the aforementioned web page), about a problem with DRI on > FreeBSD and OpenGL and got no answer (10 days have passed since then). > > Is DRI on FreeBSD unmaintained? Am I sending my problem report to the > wrong place? What should I do or who should I contact about this? Eric is on vacation. kris pgp0.pgp Description: PGP signature
Re: Is DRI on FreeBSD unmaintained?
On Sat, 2003-06-21 at 09:12, Lefteris Chatzibarbas wrote: > Hello, > > I believe that the web page related to DRI on BSD (FreeBSD and NetBSD) > is: > > http://people.freebsd.org/~anholt/dri/index.html > > I have mailed both this mailing list and [EMAIL PROTECTED] (contact address > as stated in the aforementioned web page), about a problem with DRI on > FreeBSD and OpenGL and got no answer (10 days have passed since then). > > Is DRI on FreeBSD unmaintained? Am I sending my problem report to the > wrong place? What should I do or who should I contact about this? > > My message to this mailing list: > > http://lists.freebsd.org/pipermail/freebsd-current/2003-June/004859.html There are known problems with the DRI that Eric ([EMAIL PROTECTED]) is currently unable to fix (due to time and $$ problems). I think he got tired of answering the same question over and over, and has resorted to ignoring some emails. He is also very busy with school. You might join #XFree86 on irc.freenode.net if you *really* need to get help. There are many people in there with plenty of experience with the DRI. Eric even stops by on occasion. -- Adam <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Is DRI on FreeBSD unmaintained?
Hello, I believe that the web page related to DRI on BSD (FreeBSD and NetBSD) is: http://people.freebsd.org/~anholt/dri/index.html I have mailed both this mailing list and [EMAIL PROTECTED] (contact address as stated in the aforementioned web page), about a problem with DRI on FreeBSD and OpenGL and got no answer (10 days have passed since then). Is DRI on FreeBSD unmaintained? Am I sending my problem report to the wrong place? What should I do or who should I contact about this? My message to this mailing list: http://lists.freebsd.org/pipermail/freebsd-current/2003-June/004859.html Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DRI/XFree86/FreeBSD/OpenGL problem
Hello, I have a problem with DRI on FreeBSD. Specifically, in some OpenGL programs, objects are not drawn at all (in some cases only some of them get drawn) (DRI enabled), but when DRI is disabled all work fine. A simple example of such program is: http://www.opengl.org/developers/code/glut_examples/examples/cube.c The hardware is: AMD Athlon XP 1800+, MSI KT4V (KT400/VT8235), 256MB DDR333 PC2700, Matrox G450 32MB AGP4X The system runs -CURRENT (last updated 2 days ago). Some of the XFree86 ports installed (and their versions): XFree86-4.3.0,1, XFree86-Server-4.3.0_8, XFree86-clients-4.3.0_2, XFree86-libraries-4.3.0_5 Other system information: http://members.hellug.gr/lefcha/dmesg http://members.hellug.gr/lefcha/drm http://members.hellug.gr/lefcha/glxinfo http://members.hellug.gr/lefcha/libgldebug http://members.hellug.gr/lefcha/XF86Config-4 http://members.hellug.gr/lefcha/pciconf Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Julian St. wrote: It seems not to be related, but when I try to kill my X Server using Ctrl+Alt+Backspace, my box powers down (jsut like an APM power-down). I started noticing it using 4-STABLE+ NVidia driver, but it continued to be the case on -CURRENT with Xfree86's nv driver. I always see this on one machine. I always attributed it to the mainboard (a cheap ecs k7s5a) doing the powerdown by itself somehow if the appropriate keys are pressed on the keyboard... It powers back up if you press the Any Key, tho. --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Am Sa, 2003-04-05 um 16.52 schrieb Julian St.: > Am Fr, 2003-04-04 um 23.30 schrieb Eric Anholt: > > As the subject says, I'm wondering if anyone out there has experienced > > hangs on logging out from xdm (or perhaps switching VTs) with Radeon or > > matrox (perhaps r128, too) cards using the updated DRM in -current and > > XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this > > affects FreeBSD. > > It seems not to be related, but when I try to kill my X Server using > Ctrl+Alt+Backspace, my box powers down (jsut like an APM power-down). I > started noticing it using 4-STABLE+ NVidia driver, but it continued to > be the case on -CURRENT with Xfree86's nv driver. > I just re-installed NVidia's driver and it works great (far more stable > than on -STABLE *g*), but I did not confirm if I can kill my X server > using Ctrl+Alt+Backspace properly again. Will do that in some minutes, > though. I remember that I have lost quite a lot of files one time this > happened (I was used to kill my X Server using the shortcut) on -STABLE. Please disregard this. I have found the problem... My new mainboard had Ctrl+Alt+Backspace bound to "Immediate Shutdown" in BIOS Setup. Nice default hotkey for XFree86 users... -- Julian Stecklina Computers are like air conditioners: they stop working when you open windows. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Eric, this isn't precisely the situation you asked about, but it may be related. I've had similar problems to what was noted by MKB but an older setup. I'm running 5.0-RELEASE on my I8K with the Mobility Radeon 7500 (M7 chip with 64MB) configured with XFree86-4.2.0_1,1 and DRI compiled from CVS from around Jan 30 of this year. What I found was that the system ran completely stable as long as no X was running at all. I tried: stock X from cd with 5.0 modules stock X from cd with CVS DRI modules stock X from cd with overlayed CVS DRI including modules stock X from cd with overlayed CVS DRI with 5.0 modules X from CVS with 5.0 modules X from CVS with DRI CVS modules X from CVS with overlayed CVS DRI including modules X from CVS with overlayed CVS DRI with 5.0 modules all permutations of above both with and without DRI enabled all permutations of above under gnome with and without screensavers activated and also vanilla twm with no screensaver at all Whatever I did, X would run fine for a while and then at an unpredictable time it would all just freeze. It is not responsive to anything at all (including network access) except for hard power off by holding down the button for 5 seconds. I've even seen this freeze on the console when X is running. I haven't tried to update (because of my efforts to get the install to act as a server for ppc work I was hesitant to change anything) so I can't say anything for the newest software but I did try the combinations above into February. I finally gave up on trying things and left X off when working with 5.0 except for VERY short timeframes (I also have two installs of 4.7 that work fine on the same disk). I concluded that the problem lay in the OS somewhere, but I don't know if this fits in with your observations. Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SV: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Hi I am using a Radeon 7500 mobility and as of 4th of april I cannot get X going at all on current, it totally crashes X My X log can be found in pr i386/50606 rgds Matt -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Eric Anholt Skickat: den 4 april 2003 22:31 Till: [EMAIL PROTECTED] Ämne: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout? As the subject says, I'm wondering if anyone out there has experienced hangs on logging out from xdm (or perhaps switching VTs) with Radeon or matrox (perhaps r128, too) cards using the updated DRM in -current and XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this affects FreeBSD. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Am Fr, 2003-04-04 um 23.30 schrieb Eric Anholt: > As the subject says, I'm wondering if anyone out there has experienced > hangs on logging out from xdm (or perhaps switching VTs) with Radeon or > matrox (perhaps r128, too) cards using the updated DRM in -current and > XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this > affects FreeBSD. It seems not to be related, but when I try to kill my X Server using Ctrl+Alt+Backspace, my box powers down (jsut like an APM power-down). I started noticing it using 4-STABLE+ NVidia driver, but it continued to be the case on -CURRENT with Xfree86's nv driver. I just re-installed NVidia's driver and it works great (far more stable than on -STABLE *g*), but I did not confirm if I can kill my X server using Ctrl+Alt+Backspace properly again. Will do that in some minutes, though. I remember that I have lost quite a lot of files one time this happened (I was used to kill my X Server using the shortcut) on -STABLE. -- Julian Stecklina Morris dancing is an exercise in fertility. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Hi, On Fri, 4 Apr 2003, Eric Anholt wrote: > Date: 04 Apr 2003 13:30:39 -0800 > From: Eric Anholt <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout? > > As the subject says, I'm wondering if anyone out there has experienced > hangs on logging out from xdm (or perhaps switching VTs) with Radeon or > matrox (perhaps r128, too) cards using the updated DRM in -current and > XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this > affects FreeBSD. I see this on my IBM A30p notebook. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
On Fri, Apr 04, 2003 at 01:30:39PM -0800, Eric Anholt wrote: > As the subject says, I'm wondering if anyone out there has experienced > hangs on logging out from xdm (or perhaps switching VTs) with Radeon or > matrox (perhaps r128, too) cards using the updated DRM in -current and > XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this > affects FreeBSD. > What is the date of the updated DRM you are concerned with? I have a radeon 7500 M7 in my laptop with XFree86 4.3.0 and a kernel from yesterday's sources. I haven't noticed any problems with switch to VTs except for a few second delay in updating X when I switch back. I'm attributing the delay to a ULE quirk. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Eric Anholt wrote: As the subject says, I'm wondering if anyone out there has experienced hangs on logging out from xdm (or perhaps switching VTs) with Radeon or matrox (perhaps r128, too) cards using the updated DRM in -current and XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this affects FreeBSD. Yes, I had them from 5.0 onwards until -p7. Not only with radeon but also (although not so often) with mga. They don't seem to happen anymore with the Matrox card in -p7 but I can't right now check if it's still problematic with a Radeon (I have swapped cards in hope to workaround that problem.) But since I also had problems with the mga before -p7 and they don't seem to exist anymore now perhaps the problem has gone away? (The problem manifested itself in the X server taking 100% cpu in kernel mode, and trying to kill it, or trying to reboot made the machine freeze solid. It only happened when the X session was terminated / X server was restarted, and occasionally in some xscreensaver hacks, after a while, although I couldn't ascertain this because I usually am not there when xscreensaver is running... ;) --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
As the subject says, I'm wondering if anyone out there has experienced hangs on logging out from xdm (or perhaps switching VTs) with Radeon or matrox (perhaps r128, too) cards using the updated DRM in -current and XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this affects FreeBSD. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Netscape 4.76 & MGA DRI
Scott Long wrote: > > Rhett Monteg Hollander wrote: > > > Hello gentlemen, > > > > several days ago I've installed 5.0-RELEASE onto one > > of my machines, which already carried 4.7-RC1. To > > avoid possible compatibility problems, I did a clean > > install onto another hard drive, and later recompiled > > everything. Here I have a couple of annoying issues. > > > > Shell refuses to start Netscape Communicator 4.76 (for > > FreeBSD) saying "binary file is not executable", but > > it was (and is) running fine under 4.7. Since it was > > compiled under FreeBSD 2.2.x, I have compat22 > > installed (together with compat3x and compat4x). No > > help. > > Recompile your kernel with COMPAT_AOUT, or load the aout.ko kernel module. Floating exception (core dumped), ~2 megs > > > > > Second issue comes to be about hardware-accelerated > > OpenGL under XFree86 4.2.0, using Matrox G400 > > hardware. Simply, there is no hardware acceleration at > > all. DRM kernel modules that come with 4.2.0 are > > intended for use with FreeBSD 4.x, and they don't even > > compile under 5.x. I built kernel with "device mgadrm" > > and "options DRM_LINUX", as well as "options > > COMPAT_LINUX". After launching glxgears system hangs > > up completely. Problem seems to be within libdrm. So > > far I have no DRI, but software OpenGL, and 162fps > > compared to 368fps under 4.7. > > FreeBSD 5.0 comes with the DRM kernel modules in the base system, as it > looks like you discovered. Can you enable a serial console and capture > the crash? Fixed. Problem was in XF86Config, which was set up improperly. Not sure what exactly led to that point, because I've overwritten it with a substitute from 4.7. Now glxgears run fine, at 357fps; interesting, I supposed 5.0 to be faster than 4.7 in this case, at least in honour of gcc-3.2.1 > > Scott > > > > > --- > > Regards, > > Rhett > > __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape 4.76 & MGA DRI
Rhett Monteg Hollander wrote: Hello gentlemen, several days ago I've installed 5.0-RELEASE onto one of my machines, which already carried 4.7-RC1. To avoid possible compatibility problems, I did a clean install onto another hard drive, and later recompiled everything. Here I have a couple of annoying issues. Shell refuses to start Netscape Communicator 4.76 (for FreeBSD) saying "binary file is not executable", but it was (and is) running fine under 4.7. Since it was compiled under FreeBSD 2.2.x, I have compat22 installed (together with compat3x and compat4x). No help. Recompile your kernel with COMPAT_AOUT, or load the aout.ko kernel module. Second issue comes to be about hardware-accelerated OpenGL under XFree86 4.2.0, using Matrox G400 hardware. Simply, there is no hardware acceleration at all. DRM kernel modules that come with 4.2.0 are intended for use with FreeBSD 4.x, and they don't even compile under 5.x. I built kernel with "device mgadrm" and "options DRM_LINUX", as well as "options COMPAT_LINUX". After launching glxgears system hangs up completely. Problem seems to be within libdrm. So far I have no DRI, but software OpenGL, and 162fps compared to 368fps under 4.7. FreeBSD 5.0 comes with the DRM kernel modules in the base system, as it looks like you discovered. Can you enable a serial console and capture the crash? Scott --- Regards, Rhett __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Netscape 4.76 & MGA DRI
Hello gentlemen, several days ago I've installed 5.0-RELEASE onto one of my machines, which already carried 4.7-RC1. To avoid possible compatibility problems, I did a clean install onto another hard drive, and later recompiled everything. Here I have a couple of annoying issues. Shell refuses to start Netscape Communicator 4.76 (for FreeBSD) saying "binary file is not executable", but it was (and is) running fine under 4.7. Since it was compiled under FreeBSD 2.2.x, I have compat22 installed (together with compat3x and compat4x). No help. Second issue comes to be about hardware-accelerated OpenGL under XFree86 4.2.0, using Matrox G400 hardware. Simply, there is no hardware acceleration at all. DRM kernel modules that come with 4.2.0 are intended for use with FreeBSD 4.x, and they don't even compile under 5.x. I built kernel with "device mgadrm" and "options DRM_LINUX", as well as "options COMPAT_LINUX". After launching glxgears system hangs up completely. Problem seems to be within libdrm. So far I have no DRI, but software OpenGL, and 162fps compared to 368fps under 4.7. --- Regards, Rhett __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dri-devel - HEADS-UP
From: "Chuck Robey" <[EMAIL PROTECTED]> Sent: Monday, December 30, 2002 5:02 PM > The moral is, I think you need to rebuild/reinstall dri-devel if you're > running FreeBSD-current. I have found that it's generally a good idea to rebuild any modules you have from ports (in my case it's ltmdm and radeon) when you upgrade the kernel. Especially with -CURRENT, the module interface could change at any time. Specifically, I had the same issue you did with ltmdm early last week, with the same solution (rebuild the port). ltmdm's pkg-message specifically tells you you'll have to do this, in fact. --K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dri-devel - HEADS-UP
To those of you running the radeon.ko dri module from the ports (ports/graphics/dri-devel) IF YOU'RE RUNNING CURRENT then you might want to listen up. I just did a rebuild of the system for the first time in about 6 days, and my system rebooted immediately when XFree86 attempted loading the radeon.ko. I always rebuild and reinstall the modules when I do the kernel, but I also always take extra care to copy the ports version of radeon.ko over the one built/installed during the modules build, so I am completely certain that I was using the one from the ports. I reverified that on reboot. While I'm not totally certain it was the dri-devel, I rebuilt it again (it used the same sources as before from ports, on the new kernel sources from /usr/src/sys) and next time, used that to load. Result this time was just fine. I did check, the module binary had changed size (gotten a bit smaller). I don't know for sure if that is from a change in the compiler or a change in kernel sources (probably both). I'd previously built the dri-devel port with the gcc 3.2 compiler, it's in a new rev now. The moral is, I think you need to rebuild/reinstall dri-devel if you're running FreeBSD-current. If anyone can either show I'm wrong, or verify my experience, if you'd post your results you'd be doing everyone a favor. I won't mind being proven wrong. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree 4 DRM/DRI under -CURRENT
+---[ Sameh Ghane ]-- | Hi, | | Did anyone find a way to compile the x11-servers/XFree86-4-Server port ? | | According to the Makefile it is not possible to build it since FreeBSD 500013. | Will a package built under < 500013 work under > 500013 ? It's busted since the KSE changes went in, the changes are fairly easy to do, but, it involves a crapload of #ifdefing to do it properly... The pre 500013 kernel modules will not work for you, they will panic your system as soon as you try to access them d;) They're on my list of things to do someday if someone hasn't done them, by the time I get around to it. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree 4 DRM/DRI under -CURRENT
Hi, Did anyone find a way to compile the x11-servers/XFree86-4-Server port ? According to the Makefile it is not possible to build it since FreeBSD 500013. Will a package built under < 500013 work under > 500013 ? Another way to have DRI/M rendering with mga/G400 and XFree under -current ? Cheers, -- Sameh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DRI
+---[ David W. Chapman Jr. ]-- | Anyone know if -current supports Direct Rendering Infrastructure? XFree4 supports it, it's not really a FreeBSD issue, other than actually building the drm kernel module. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DRI
Anyone know if -current supports Direct Rendering Infrastructure? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
