Thread: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

Brought to you by: alanh, brianp, chadversary, keithw

mesa3d-users

[Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Mike S. <sc...@gm...> - 2009-03-23 20:26:52

I'm running Debian on an old laptop with a mach64-based video adapter ("ATI
Technologies Inc Rage Mobility P/M AGP 2x (rev 64)"). I've been wanting to
try out some simple 3D programming, but I figured I should get 3D
acceleration working first. The internet tells me that it is indeed
possible. I've set up xorg with the mach64 driver, but I can't seem to find
the kernel module it requires for acceleration to work. Here's what I've
tried so far:
- latest (20060403) common and mach64 tarballs from
http://dri.freedesktop.org/snapshots/ - common installs fine but mach64
refuses to compile since it depends on some symbols which were removed a few
kernels ago.
- modules from git://anongit.freedesktop.org/git/mesa/drm - compiles and
lets me insmod the modules, but when I restart X the kernel panics. This
happens after X switches to video mode, so I can't see what the panic
message is (screen is completely blank, my only indication is flashing
keyboard LEDs)

Is there another source from which I can get the modules which might compile
*and* work, or another module I can try that will give me 3D acceleration on
this card? Thanks.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Chris J. <cjn...@gm...> - 2009-03-28 15:46:18

On Mon, Mar 23, 2009 at 04:26:41PM EDT, Mike Smith wrote:

> I'm running Debian on an old laptop with a mach64-based video adapter
> ("ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)"). I've been
> wanting to try out some simple 3D programming, but I figured I should
> get 3D acceleration working first. The internet tells me that it is
> indeed possible. 

I have the lastest ubuntu installed on another partition and dri works
out of the box. I believe it ships with 2.6.27 .. so unless something
happened in this area between 26 & 27, that would appear to confirm your
internet findings.

> I've set up xorg with the mach64 driver, but I can't seem to find the
> kernel module it requires for acceleration to work. Here's what I've
> tried so far:

> - latest (20060403) common and mach64 tarballs from
> http://dri.freedesktop.org/snapshots/ - common installs fine but
> mach64 refuses to compile since it depends on some symbols which were
> removed a few kernels ago.

> - modules from git://anongit.freedesktop.org/git/mesa/drm - compiles
> and lets me insmod the modules, but when I restart X the kernel
> panics. This happens after X switches to video mode, so I can't see
> what the panic message is (screen is completely blank, my only
> indication is flashing keyboard LEDs)

> Is there another source from which I can get the modules which might
> compile *and* work, or another module I can try that will give me 3D
> acceleration on this card? Thanks.

Maybe taking a look at how they set it up in ubuntu might help?

Thanks,

CJ

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Mike S. <sc...@gm...> - 2009-03-28 19:38:36

>
>
> Maybe taking a look at how they set it up in ubuntu might help?
>
> I don't have a mach64 box with Ubuntu, and couldn't find a mach64.ko in any
package on packages.ubuntu.com. Can someone who does please take a look in
xorg.conf/Xorg.0.log and see what module it's loading?

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Chris J. <cjn...@gm...> - 2009-03-29 02:57:13

On Sat, Mar 28, 2009 at 03:38:20PM EDT, Mike Smith wrote:
> >
> >
> > Maybe taking a look at how they set it up in ubuntu might help?

> I don't have a mach64 box with Ubuntu, and couldn't find a mach64.ko
> in any package on packages.ubuntu.com. 

I think you can burn their install stuff to a CD/DVD and run it "live"
to investigate further.

> Can someone who does please take a look in xorg.conf/Xorg.0.log and
> see what module it's loading?

Here's an excerpt:

(II) LoadModule: "record"

(II) Loading /usr/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
	compiled for 1.5.2, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension RECORD
(II) LoadModule: "dri"

(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.5.2, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension XFree86-DRI
(II) Scanning /usr/share/xserver-xorg/pci directory for additional PCI ID's supported by the drivers
(II) Matched mach64 from file name mach64.ids
(==) Matched mach64 for the autoconfigured driver
(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "mach64"

(II) Loading /usr/lib/xorg/modules/drivers//mach64_drv.so
(II) Module mach64: vendor="X.Org Foundation"
	compiled for 1.5.0, module version = 6.8.0
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 4.1
(II) MACH64: Driver for ATI Mach64 chipsets
(II) Primary Device is: PCI 01@00:00:0
(II) resource ranges after probing:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
(II) MACH64(0): Creating default Display subsection in Screen section
	"Default Screen" for depth/fbbpp 24/32
(==) MACH64(0): Depth 24, (==) framebuffer bpp 32
(==) MACH64(0): Using XAA acceleration architecture
(II) MACH64: Mach64 in slot 1:0:0 detected.
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]

And here's the glxinfo output:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, 
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, 
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.2
OpenGL shading language version string: 1.10
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
    GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, 
    GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample, 
    GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, 
    GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, 
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, 
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, 
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, 
    GL_EXT_copy_texture, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, 
    GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord, 
    GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, 
    GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, 
    GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, 
    GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
    GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
    GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, 
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, 
    GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, 
    GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, 
    GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, 
    GL_ATI_texture_mirror_once, GL_ATI_fragment_shader, 
    GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, 
    GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, 
    GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_program_debug, 
    GL_MESA_resize_buffers, GL_MESA_texture_array, GL_MESA_ycbcr_texture, 
    GL_MESA_window_pos, GL_NV_blend_square, GL_NV_fragment_program, 
    GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texture_rectangle, 
    GL_NV_texgen_reflection, GL_NV_vertex_program, GL_NV_vertex_program1_1, 
    GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, 
    GL_SGI_texture_color_table, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, 
    GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays

3 GLX Visuals
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x22 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x3c 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None

32 GLXFBConfigs:
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x3d  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x3e  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x3f  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x40  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x41  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  8  0  0  0  0  0 0 None
0x42  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  8 16 16 16 16  0 0 Slow
0x43  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  8  0  0  0  0  0 0 None
0x44  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  8 16 16 16 16  0 0 Slow
0x45  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x46  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x47  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x48  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x49  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x4a  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x4b  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x4c  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x4d  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x4e  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x4f  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x50  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x51  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  8  0  0  0  0  0 0 None
0x52  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  8 16 16 16 16  0 0 Slow
0x53  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  8  0  0  0  0  0 0 None
0x54  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  8 16 16 16 16  0 0 Slow
0x55  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x56  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x57  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x58  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x59  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x5a  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x5b  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x5c  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow

Hope this helps.

CJ

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Mike S. <sc...@gm...> - 2009-04-01 01:00:13

On Sat, Mar 28, 2009 at 10:57 PM, Chris Jones <cjn...@gm...> wrote:
> I think you can burn their install stuff to a CD/DVD and run it "live"
> to investigate further.
I'll have to get some blank CDs one of these days...

> (II) LoadModule: "mach64"
> (II) Loading /usr/lib/xorg/modules/drivers//mach64_drv.so
So it's loading the same xorg module as mine. Any indication as to
what kernel module it's loading, and what ubuntu package it's in?

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Chris J. <cjn...@gm...> - 2009-04-01 19:16:52

On Tue, Mar 31, 2009 at 09:00:07PM EDT, Mike Smith wrote:
> On Sat, Mar 28, 2009 at 10:57 PM, Chris Jones <cjn...@gm...> wrote:

> > (II) LoadModule: "mach64"
> > (II) Loading /usr/lib/xorg/modules/drivers//mach64_drv.so
> So it's loading the same xorg module as mine. Any indication as to
> what kernel module it's loading, and what ubuntu package it's in?

On the current ubuntu 8.10 it lives in its own separate package:

$ dpkg -S mach64_drv.so
xserver-xorg-video-mach64: /usr/lib/xorg/modules/drivers/mach64_drv.so

$ dpkg -l xserver-xorg-video-mach64

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                                       Version                                 Description
+++-==========================================-=======================================-============================================
ii  xserver-xorg-video-mach64                  6.8.0-1build2                           X.Org X server -- ATI Mach64 display driver

Here's a list of the files installed by the package:

$ dpkg -L xserver-xorg-video-mach64

/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/xserver-xorg-video-mach64
/usr/share/doc/xserver-xorg-video-mach64/copyright
/usr/share/doc/xserver-xorg-video-mach64/NEWS.Debian.gz
/usr/share/doc/xserver-xorg-video-mach64/changelog.gz
/usr/share/doc/xserver-xorg-video-mach64/changelog.Debian.gz
/usr/share/xserver-xorg
/usr/share/xserver-xorg/pci
/usr/share/xserver-xorg/pci/mach64.ids
/usr/share/bug
/usr/share/bug/xserver-xorg-video-mach64
/usr/lib
/usr/lib/xorg
/usr/lib/xorg/modules
/usr/lib/xorg/modules/drivers
/usr/lib/xorg/modules/drivers/mach64_drv.so
/usr/share/bug/xserver-xorg-video-mach64/script

Ubuntu should have a source repos somewhere:

$ apt-get source xserver-xorg-video-mach64

If your system is not debian or debian-derived, you should be able to
use your web browser to locate and download the .deb file and you would
use the "ar" utility to extract its contents:

$ ar xv xserver-xorg-video-mach64.deb

./debian/rules is the Makefile and should provide insights as to how to
compile the source.

CJ

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Mike S. <sc...@gm...> - 2009-04-01 19:48:00

Thanks, but I was referring to the kernel module - the one somewhere
in /lib/modules, with a .ko extension.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Chris J. <cjn...@gm...> - 2009-04-02 12:08:17

On Wed, Apr 01, 2009 at 03:47:58PM EDT, Mike Smith wrote:

> Thanks, but I was referring to the kernel module - the one somewhere
> in /lib/modules, with a .ko extension.

I would need the actual name of the module to investigate further.

CJ

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Mike S. <sc...@gm...> - 2009-04-02 16:45:56

> I would need the actual name of the module to investigate further.
I would expect it to be mach64.ko...

Re: [Mesa3d-users] mach64 kernel modules for 2.6.26 kernel

From: Chris J. <cjn...@gm...> - 2009-04-02 18:01:14

On Thu, Apr 02, 2009 at 12:45:54PM EDT, Mike Smith wrote:

> > I would need the actual name of the module to investigate further.
> I would expect it to be mach64.ko...

Likewise. But there is not such module in /lib/modules on that system.

I also did an lsmod and did not see other likely candidates either.

But I may have missed something & I could post the lsmod output if you
want to double check.

I'm beginning to think there might be a reason why the kernel symbols
have disappeared - whatever functionalities lived in that kernel module
may have been moved somewhere else.. the Xorg module, a generic module
that services other video chips, the kernel itself..?

Since I know next to nothing about all this, I won't speculate further.

Sorry for bringing this up since it turns out to be pretty much a dead
end.. unless you want to switch to ubuntu for your 3D programming.

Re: [Mesa3d-users] Update: mach64 kernel modules for 2.6.26 kernel

From: Chris J. <cjn...@gm...> - 2009-04-05 03:29:50

On Fri, Apr 03, 2009 at 11:53:22AM EDT, c3kkos wrote:
> 
> Ok i've got the same here
> 
> old Acer Travelmate 743tl
> 
> with the ugly mach64 chip on it. the M, agp 2x version......

Same as me, it's the agp version of the card/chip.

Only system where I got dri to work on this hardware was debian sarge
with a 2.4 kernel and I do remember that I needed to load the agpgart
kernel module prior to loading the mach64 kernel module.

Two other things that I learned the hard way was that I needed was to
run X with 16-bit color and a screen resolution that was compatible
with the Mach64's miserly memory. 

My laptop's LCD's native resolution is 1400x1050 but in order to get dri
to work, I had to downgrade to 1024x768.

Since I never got it to work on debian "etch" on the same laptop, I
still have this old "sarge" system on a separate partition.

> i've compilated my own kernel module from the git source.. and that
> spits out two .ko listed in:

> /lib/modules/'uname -r'/kernel/drivers/char/drm/drm.ko && mach64.ko

> well.. everything seems to run fine.. those modules loads with NO
> PROBLEMS at all..

[..]

> Straight to the point:

> at this time, it seems that DRM for mach64 + Xorg cause a kernel panic
> (no logs are created from X, so i think that happens BEFORE the
> graphical server loads up)

In any event, please forget everything I said regarding ubuntu. 

I don't understand what the ubuntu packagers did in this respect, but
having had the time to look more closely at the output of glxinfo, I
noticed that although it says "direct rendering: yes" it also has
something that doesn't look promising a few lines down: "OpenGL
Renderer: Software Rasterizer". Hmm...

So, I rebooted to my old sarge system and sure enough, glxinfo says:
"Direct Rendering: Yes" _but_ it also says: "OpenGL Renderer: Mesa DRI
Mach64".

Not knowing exactly what this glxinfo renderer stuff really means, I
thought I'd run a few "tests" with some xscreensaver stuff (antinspect,
glmatrix, blocktube, dangerball, GLForestFire.. etc.) as well as
glxgears  on both my old sarge system and the ubuntu system (on the same
multi-boot laptop) and compare the results. 

Well, the difference was immediately noticeable and also quite
measurable, at least if you trust the -fps options of these programs.

Basically, on my old sarge system I was consistently getting FPS rates
that were roughly 5+ times higher than on the ubuntu system where dri is
supposedly enabled. True, I'm probably running different versions of
these programs, since the stuff in the sarge repositories must be about
5 years older than the ubuntur stuff.. but all the same, there does seem
to be a pattern.

As an example, at the same color depth, same resolution, glxgears is
just short of 300 FPS on my old debian sarge system. When I ran it on
ubuntu, it did about 56 FPS..!

So, to paraphrase what you said, I thought dri was a matter of 1, you
have it, or 0 you don't.. 

Not so, the ubuntu packagers seem to have it "half-enabled".

:-)

> my kernel is 2.6.29 on a Debian box.   COME ON BOYS LET'S TRY TO SOLVE
> THIS!!

+1

The "ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)" is probably
not powerful enough to make much difference for a lot of stuff, even
with dri fully (?) enabled, but on my old "sarge" system I was able to
play (or demo) Heretic II with all textures and visual effects enabled
via the "GL renderer" and Tuxracer was tolerably responsive.. 

So, even though getting this to work is not one of my priorities, I
would really like to understand this stuff a little better and I _do_
wish someone knowledgeable could spare a couple of minutes and give us a
few pointers.

Thanks,

CJ

[Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: c3kkos <c3...@ho...> - 2009-04-06 19:43:36

Gotcha, my friends!

I'm about to tell you i made a step forward!

Well.. just to remind u:

running a net-inst (businness card) Debian testing with the latest bleedin'
edge kernel

2.6.29

I've installed from the apt system my whole system up to my needs
The thing that IS NOT included in the vanilla kernel is the famous drm.ko &&
mach64.ko which are made
by git cloning the latest DRM support sources from the freedesktop.org site.
compiling and installing those modules you have kernel support to obtain the
DRI layer on your X server

Problem was:
if you let the system load automatically all those modules the machine hangs
with an ugly kernel panic!!

BUT... I've killed the X init script from my /etc/rc.2/ to let the system
boots in text (bash) old-fashioned-style mode
Since i've created my custom-monolithic kernel i've not any modules to load
BUT those two drm.ko && mach64.ko that i've compiled separately

Those modules will NOT load at boot time. (dmesg|grep drm == NULL)

I've found out that if, in this state, i issue from shell the command
"startx" the X server LOADS without goin' in PANIC!!

I've made it too long so far. it's time to post some logs and outputs, here
we go

X logs excerp:

=============================================
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) MACH64(0): [drm] Using the DRM lock SAREA also for drawables.
(II) MACH64(0): [drm] framebuffer handle = 0x81000000
(II) MACH64(0): [drm] added 1 reserved context for kernel
(II) MACH64(0): X context handle = 0x1
(II) MACH64(0): [drm] installed DRM signal handler
(II) MACH64(0): [drm] Will request asynchronous DMA mode
(**) MACH64(0): [dri] Forcing PCI mode
(==) MACH64(0): [drm] Using 2 MB for DMA buffers
(II) MACH64(0): [pci] ring handle = 0x054e4000
(II) MACH64(0): [pci] Ring mapped at 0xb709c000
(II) MACH64(0): [drm] register handle = 0x80500000
(II) MACH64(0): [dri] Visual configs initi(II) MACH64(0): [dri] Block 0 base
at 0x80500400
(II) MACH64(0): Memory manager initialized to (0,0) (1024,4095)
(II) MACH64(0): Largest offscreen area available: 1024 x 3327
(II) MACH64(0): Will use 1598 kB of offscreen memory for XAA
(II) MACH64(0): Will use back buffer at offset 0x30f800
(II) MACH64(0): Will use depth buffer at offset 0x48f800
(II) MACH64(0): Will use 1985 kB for local textures at offset 0x60f800
(II) MACH64(0): Using XFree86 Acceleration Architecture (XAA)
        Screen to screen bit blits
        Solid filled rectangles
        8x8 mono pattern filled rectangles
        Indirect CPU to Screen color expansion
        Solid Lines
        Setting up tile and stipple cache:
                32 128x128 slots
                18 256x256 slots
                6 512x512 slots
(==) MACH64(0): Backing store disabled
(==) MACH64(0): Silken mouse enabled
(II) MACH64(0): DPMS enabled
(II) MACH64(0): [DRI] installation complete
(II) MACH64(0): [drm] Added 128 16384 byte DMA buffers
(II) MACH64(0): [drm] Mapped 128 DMA buffers at 0xb6e9c000
(II) MACH64(0): [drm] Installed interrupt handler, using IRQ 5
(II) MACH64(0): Direct rendering enabled
(==) RandR enabled
=============================================

And here we go with the glxinfo output!

=============================================
leech:/home/c3kko# glxinfo
name of display: :0.0
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
    GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, 
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_visual_select_group
OpenGL vendor string: Gareth Hughes, Leif Delgass, Jos Fonseca
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 x86/MMX/SSE
OpenGL version string: 1.2 Mesa 7.0.4
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, 
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos, 
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, 
    GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, 
    GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, 
    GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, 
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
    GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, 
    GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_object, 
    GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_IBM_rasterpos_clip, 
    GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_light_max_exponent, 
    GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, 
    GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x24 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x25 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x26 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x27 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x28 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x29 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x2a 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x2b 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x2c 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x2d 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x2e 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x2f 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x30 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x31 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x32 16 dc  0 16  0 r  .  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x4c 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 Ncon
=============================================

Please notice the three most important lines from that amount of text up
above:

1) (II) MACH64(0): Direct rendering enabled

2) direct rendering: Yes

3)  OpenGL vendor string: Gareth Hughes, Leif Delgass, Jos Fonseca
    OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 x86/MMX/SSE
    OpenGL version string: 1.2 Mesa 7.0.4
=============================================

Now.. k i've got DRI on mach64 that's wonderful.. but...

i've encountered some problems.. 

well, glxgears works well, along with all those fancy GL screensavers..
but.......
the systems still hangs, goin' panic again, if i make intense use of flash
player 10 + iceweasel(firefox)
or when i try to fire up extremetuxracer

For the flash player.. i know that from the v10 the stream can be
hardware-accellerated and there might be some scary problems. Somehow i'm
still able to see some frames... the crash occours randomly but after only a
few seconds.

Extremetuxracer hangs the system without drawing a single colored pixel upon
the screen.. it's strange and it can be issued by some erroneous
configuration.. WE KNOW very well that our beloved mach64 chip
(01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) works only UP TO a 16bit depth and 1024x768 screening
configuration.. so if the little wheeled tux tries to overcome (or probe)
that settings.. well he has all the reason to spit out a bliking capslock on
my laptop!

So far, my friend... i'm writing to you on my DRI ENABLED but still very,
very and sadly UNSTABLE mach64-powered laptop.

Might this little and awful review useful for future development.
I want to introduce myself. I'm a 1984 class italian boy my name is Davide
and i really can't take a chance
on improving the mach64 support code. i'm not familiar in programming, i'm
just a linux-lover and i'm using this mailing-list site for the first time,
even if i've read TONS of them all 'round the net.

I'm about to write some lines or just post the link to this webpage to the
authors listed in the glxinfo.
I just want to thank those person who helped in the driver development. i
want them to know there's still somebody like me that rely upon their code.

"Gareth Hughes, Leif Delgass, Jos Fonseca"

Davide Ceccherini. Pisa, Italy
EOF.


-- 
View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22915795.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: c3kkos <c3...@ho...> - 2009-04-06 21:01:59

just a little update

i was too excited to notice that the problems i've encountered are IRQ
related.

As i write just before in my first post in this thread, i always had a bad
feeling about that and i've just checked that in my laptop IRQ 5 is shared
between the video adapter and the audio chipset. mach64 and ESS SOLO-1

Tryin to find out how to resolve this problem.. uah... i'm facing a
neverending story
-- 
View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22917297.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: c3kkos <c3...@ho...> - 2009-04-07 07:21:29

I know i'm filling up your mailboxes but this is now n open challenge for me.

Here i have cat'ed my /proc/interrupts:

           CPU0       
  0:      11869    XT-PIC-XT        timer
  1:        377    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  3:          2    XT-PIC-XT      
  4:          2    XT-PIC-XT      
  5:          0    XT-PIC-XT        ES1938, mach64@pci:0000:01:00.0
  6:          5    XT-PIC-XT        floppy
  7:          2    XT-PIC-XT      
  8:          2    XT-PIC-XT        rtc0
  9:          0    XT-PIC-XT        acpi
 10:          5    XT-PIC-XT      
 11:        743    XT-PIC-XT        uhci_hcd:usb1, yenta, yenta
 12:       4472    XT-PIC-XT        i8042
 14:       2659    XT-PIC-XT        ide0
 15:       1473    XT-PIC-XT        ide1
NMI:          0   			Non-maskable interrupts
LOC:          0   			Local timer interrupts
RES:          0   			Rescheduling interrupts
CAL:          0   			Function call interrupts
TLB:          0   			TLB shootdowns
TRM:          0   			Thermal event interrupts
SPU:          0   			Spurious interrupts
ERR:          0
MIS:          0
----------------------------------------------------------

it's now clear that i'm facing a irq problem. indeed the drm module does not
like sharing the bus with
the audio data trunks. I think trying to have a different pci latency
timings setup is a waste of time. The bios does not have any option to
manipulate the plug-n-play system..

IRQ 5 is bound to the SOLO-1 at boot time and is bound again to the
drm/mach64 when xorg load up his modules.

I've to find out how i can modify the solo-1 irq assignment via software..
cause the other way is the old "jumpers way" but since i'm using a
notebook.. i can hardly think there're some upon my hardware..

any suggestions? i've looked for a script set called rtirq that maybe can be
useful but it can be used, as the name already tells, with the real-time
kernels..

Ahuuuuuu!!!!!!!!
-- 
View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22922682.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: José J. <lis...@fr...> - 2009-04-07 08:14:30

A Tuesday 7 April 2009 09:21:15, c3kkos escreveu:
> IRQ 5 is bound to the SOLO-1 at boot time and is bound again to the
> drm/mach64 when xorg load up his modules.
>
As far as I have experimented, IRQ sharing gives no problems on PCI cards...
But still you can disable the sound card in the BIOS and see if Mach64 works 
better. The last time I managed to use it was with a Mandriva 2008 Spring, so 
a 2.6.24 kernel. Then, 3D never worked on more recent systems.

Anyway, the 3D of such a card is so bad, I'd suggest you forgetting using it 
on Linux. Simple example : most of the 3D open-source games use much more 
than 8MB of video RAM.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: Chris J. <cjn...@gm...> - 2009-04-22 00:44:09

On Tue, Apr 07, 2009 at 04:14:13AM EDT, José JORGE wrote:

[..]

> Anyway, the 3D of such a card is so bad, I'd suggest you forgetting
> using it on Linux. 

If not linux, what should we use it on..?

> Simple example : most of the 3D open-source games use much more than
> 8MB of video RAM.

Hmm.. Whoever wrote the code wasted their/our time.. all we need is
credit cards and new hardware?

Thanks,

CJ

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: José J. <lis...@fr...> - 2009-04-22 21:23:23

A Wednesday 22 April 2009 02:43:45, Chris Jones escreveu:
> If not linux, what should we use it on..?
The 2D part is OK, you can also play movies with the great Xv extension... 
what I mean is only the 3D with this card is somewhat useless. The only linux 
game that I played with it was Quake III arena, and it was slow and ugly.

> > Simple example : most of the 3D open-source games use much more than
> > 8MB of video RAM.
>
> Hmm.. Whoever wrote the code wasted their/our time.. all we need is
> credit cards and new hardware?
>
Well, open source games are made by gamers, so yes they are done according to 
their recent hardware....

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: Chris J. <cjn...@gm...> - 2009-04-22 22:48:51

On Wed, Apr 22, 2009 at 05:23:01PM EDT, José JORGE wrote:
> A Wednesday 22 April 2009 02:43:45, Chris Jones escreveu:

> > If not linux, what should we use it on..?

> The 2D part is OK, you can also play movies with the great Xv
> extension...  what I mean is only the 3D with this card is somewhat
> useless. The only linux game that I played with it was Quake III
> arena, and it was slow and ugly.

Thanks for getting back to me.

Two examples of 3D with a Mach64 that make it worth enabling dri:

  . Heretic II - if dri is enabled + 16-bit color + 1024x768 at most the
    rendering is quite beautiful. If not, you are switched to the software 
    renderer and the game is ugly as sin.

  . tuxracer - without dri, it takes maybe ten seconds before you switch
    from the menu to an actual game sequence - which turns out to be so 
    slow that it is unplayable anyway.

Another reason I was looking into this was indeed because I was
wondering whether it would make any difference playing movies or
streaming TV with mplayer+xv - not to mention watching Adobe Flash
content in mozilla with the flashplayer plugin.

So maybe "of limited usefulness" is what it boils down to.

> > > Simple example : most of the 3D open-source games use much more than
> > > 8MB of video RAM.
> >
> > Hmm.. Whoever wrote the code wasted their/our time.. all we need is
> > credit cards and new hardware?

> Well, open source games are made by gamers, so yes they are done
> according to their recent hardware....

Problem being that with a family to feed, and .. the depressing "state
of the economy", I cannot afford to spend $5000.00 on a high-end gaming
laptop any time soon.

:-(

I'm currently in the process of switching from debian etch to lenny and
I will try again to get this to work .. hopefully before my ten-year old
machine expires.

CJ

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: José J. <lis...@fr...> - 2009-04-23 08:31:59

A Thursday 23 April 2009 00:48:40, Chris Jones escreveu:
> Two examples of 3D with a Mach64 that make it worth enabling dri:
>
>   . Heretic II - if dri is enabled + 16-bit color + 1024x768 at most the
>     rendering is quite beautiful. If not, you are switched to the software
>     renderer and the game is ugly as sin.
>
>   . tuxracer - without dri, it takes maybe ten seconds before you switch
>     from the menu to an actual game sequence - which turns out to be so
>     slow that it is unplayable anyway.
>

Ok maybe Heretic (I didn't test). But tuxracer has been replaced by 
extremetuxracer or ppracer, which both ask for a better graphics card.

Of course, if you want a distribution that just works with Mach64 dri, I'd 
recommend you a Mandriva 2007 Spring, it was the last one I used with a 
Mach64 and DRI (and at his time I filled bug reports to Mandriva each time 
DRI was forgotten for Mach64). If you just want those old games, I think they 
will run better with such an old distribution.

> Another reason I was looking into this was indeed because I was
> wondering whether it would make any difference playing movies or
> streaming TV with mplayer+xv - not to mention watching Adobe Flash
> content in mozilla with the flashplayer plugin.

Here DRI will not change anything : xv and flash DON'T use DRI.

Re: [Mesa3d-users] mach64 kernel modules for 2.6.29 WORKS but...

From: Chris J. <cjn...@gm...> - 2009-05-03 00:51:32

On Thu, Apr 23, 2009 at 04:31:36AM EDT, José JORGE wrote:
> A Thursday 23 April 2009 00:48:40, Chris Jones escreveu:

> > Two examples of 3D with a Mach64 that make it worth enabling dri:

> >   . Heretic II - if dri is enabled + 16-bit color + 1024x768 at most
> >   the rendering is quite beautiful. If not, you are switched to the
> >   software renderer and the game is ugly as sin.

> >   . tuxracer - without dri, it takes maybe ten seconds before you
> >   switch from the menu to an actual game sequence - which turns out
> >   to be so slow that it is unplayable anyway.
> >

> Ok maybe Heretic (I didn't test). 

To be honest.. I don't think Heretic II could run - or even install on
anything more recent that debian sarge.. needs patching.. that's not
forthcoming..

> But tuxracer has been replaced by extremetuxracer or ppracer, which
> both ask for a better graphics card.

Sigh.. :-(

> Of course, if you want a distribution that just works with Mach64 dri,
> I'd recommend you a  Mandriva 2007 Spring, it was the  last one I used
> with  a Mach64  and DRI  (and  at his  time  I filled  bug reports  to
> Mandriva each  time DRI  was forgotten for  Mach64). If you  just want
> those  old games,  I  think they  will  run better  with  such an  old
> distribution.

That's why I haven't deleted my old sarge system.

> > Another reason I was looking into this was indeed because I was
> > wondering whether it would make any difference playing movies or
> > streaming TV with mplayer+xv - not to mention watching Adobe Flash
> > content in mozilla with the flashplayer plugin.
> 
> Here DRI will not change anything : xv and flash DON'T use DRI.

Thanks... that I am more concerned about that than gaming.

CJ

[Mesa3d-users] Solution: mach64 kernel modules for 2.6.26 kernel

From: Davicillo U. <dav...@ya...> - 2009-05-15 06:27:27

Dear Mike Smith 41

I think I have solved this problem, although I don't really know what I'm
doing.

It seems that the DRM developers have recently changed the code of the 
mach64_irq.c and that change is what is causing us so many problems. I have
been trying to reach a solution since January until now.

I have downloaded the latest git and afterwards modified the mach64_irq.c,
this way:
1.-as root, download with "git clone git://anongit.freedesktop.org/mesa/drm"
2.-"cd drm/linux-core"
3.-Edit the mach64_irq.c
4.-Inside the function "int mach64_driver_irq_postinstall(struct drm_device
* dev)" there is only one line "return 0;"
5.-Replace the "return 0;" by "return drm_vblank_init(dev,1);"
6.-Save the file and exit
7.-Make with "make DRM_MODULES=mach64" and "make install"
8.-Unload any previously loaded drm.ko and mach64.ko with "modprobe -rv
mach64"
9.-(optional) load the new modules with "modprobe -v mach64"
10.-Start X the way you like better. In my case no longer hangs X and my
glxgears is about 250fps. Hooray!

I hope it solves the problem for good, but I'm also a little worried about
why the DRM developers changed this. Anyway, it's worse for me that DRI hang
my PC, so I will take the risk.

Best regards. Davicillo Uno.
-- 
View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p23549757.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Solution: mach64 kernel modules for 2.6.26 kernel

From: Davicillo U. <dav...@ya...> - 2009-05-15 10:26:55

Dear Mike Smith 41

I think I have found another solution, that is better than the previous one.

When I modified the mach64_irq.c file, I managed to prevent the hang of the
computer when starting X, but anyway applications as Celestia end up hanging
anyway (as they used to do in the past).

As I was messing with the source code, and you gave me the clue of the IRQ
sharing, I have managed (at last!) to change manually the IRQ used by the
MACH64 driver, so it uses an unused IRQ.

For instance, previously the MACH64 DRI used my IRQ11, shared with the usb
host and pcmcia wireless card, causing trouble and hangs.

Manually modifying the source code, I have managed to initialize the MACH64
DRI in the (previously unused) IRQ7. This has solved all my problems,
including initial X hang and the Celestia hangs, so I think this can be a
permanent solution for all people with MACH64 DRI sharing IRQ problems.

The new procedure replaces the previous one I posted here, and now it's NOT
necessary to modify the mach64_irq.c file from the one dowloaded from git.
This time, the file to be modified is drm_irq.c

1.-Get a list of the used and unused IRQ by using "cat /proc/interrupts".
Choose one that is not used by any other card and that appears empty.
2.-as root, download with "git clone git://anongit.freedesktop.org/mesa/drm"
3.-"cd drm/linux-core"
4.-Edit the drm_irq.c
5.-Search for the function "int drm_irq_by_busid(...". We have to add
several lines inside this function.
6.-After the line "p->irq = dev->pdev->irq;", add the following lines of
code (in this example, to install the driver in the IRQ7):
p->irq = 7;
dev->pdev->irq=7;
8.-Save the file and exit
9.-Make with "make DRM_MODULES=mach64" and "make install"
9.-Unload any previously loaded drm.ko and mach64.ko with "modprobe -rv
mach64"
10.-(optional) load the new modules with "modprobe -v drm debug=1" (this way
you can see debug messages using "dmesg |grep drm |more", and "modprobe -v
mach64"
11.-Start X the way you like better. In my case no longer hangs X and my
glxgears is about 250fps. Now even Celestia doesn't hang!

I don't know the possible negative implications of this modification, but it
works for me! I hope this can solve other people problems like this. I have
been looking for a solution more than a year for the Celestia problem!

Best regards. Davicillo Uno.

--
View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p23556802.html
Sent from the mesa3d-users mailing list archive at Nabble.com.