Re: [Fwd: r300 Report.]
On Sat, 2004-11-06 at 12:25 +0100, Nicolai Haehnle wrote: > > Okay, the new syslog has all the debug info. I notice the following line: > > Nov 7 07:37:58 disoft-dc [drm:radeon_cp_init_ring_buffer] writeback test > failed > > The Radeon DRM source code has a comment indicating that writeback doesn't > work everywhere, but I think it's safe to assume that all R300-based chips > should be capable of writeback. The comment says 'not everywhere' instead of 'not with all chips' for a reason... > This would indeed point towards a problem in the AGP setup in one way or > another, It's known that a lot of AGP bridges have issues with transfers from the chip to the AGP aperture. It would be better to allocate the page to write back to from PCI memory, but that's only guaranteed to work if dev_priv->fb_location != 0. > and that means that the ring buffer won't work properly. Without a working > ring buffer setup, it's only natural for a lockup to occur. Actually, the RPTR only matters for detecting that the ring buffer is filling up, which may never be the case as long as you're using indirect buffers. (E.g., RPTR writeback was completely broken for the longest time in the r128 DRM, nobody seemed to notice...) > Perhaps we should fail completely when the writeback test failed on > R300-based hardware. I don't think so. It may be a good idea to read the CP_RB_RPTR register directly in GET_RING_HEAD() if the writeback test failed though. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
On Sat, 06 Nov 2004 20:09:45 +1100, Ben Skeggs <[EMAIL PROTECTED]> wrote: > Hello, > > >The PCI ID is already added in the DRM branch of r300_driver. > > > >As for the AGP issues, I have no idea. Maybe they're related to the lockup, > >maybe not. > > > >cu, > >Nicolai > > > > > I think the AGP issues *are* related to the lockup. I've just switched > sysloggers, and switched to CVS XServer (was using release 6.8 before). > My previous problems still occurred, but I now seem to have a lot more > debugging information in my syslog. I have the same AGP problem. If I > set AGP to 4x in my BIOS (rather than 8x), the corruption, and the > lockup don't occur. > Th radeon Xserver doesn't yet have agp 8x support (there are some patch floating around). the agp kernel module should fall back to 4x mode, but it apparently is having problems with your agp chipset. Just leave it at 4x in the bios for now. Alex > I've attached my syslog from when the lockup occurred, in case it helps. > > I also have the problem as Pat, where glxinfo reports "direct rendering: > No", but my Xorg log says it is. > > Ben Skeggs > --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
On Saturday 06 November 2004 20:01, Ben Skeggs wrote: > >As long as the X server works and uses the ring buffer, that would point > >towards a simple configuration problem. Perhaps you could post a log of > >glxinfo with LIBGL_DEBUG=all and RADEON_DEBUG=all? > > > >cu, > >Nicolai > > Hmm, I believe you may be right about the config problem, I'm not > sure why I didn't think of running glxinfo with LIBGL_DEBUG=all > before.. > > [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=all glxinfo > name of display: :0.0 > libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed > (/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol: > XML_SetElementHandler) > libGL error: unable to find driver: r300_dri.so > --snip-- > > I'll have a mess around and try to find out what's going on there. r300_dri.so needs to get linked against expat. - ajax pgpFXMEaALMh7.pgp Description: PGP signature
Re: [Fwd: r300 Report.]
Am So, den 07.11.2004 schrieb Ben Skeggs um 2:01: > >As long as the X server works and uses the ring buffer, that would point > >towards a simple configuration problem. Perhaps you could post a log of > >glxinfo with LIBGL_DEBUG=all and RADEON_DEBUG=all? > > > >cu, > >Nicolai > > > > > Hmm, I believe you may be right about the config problem, I'm not > sure why I didn't think of running glxinfo with LIBGL_DEBUG=all > before.. > > [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=all glxinfo > name of display: :0.0 > libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed > (/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol: > XML_SetElementHandler) > libGL error: unable to find driver: r300_dri.so > --snip-- > > I'll have a mess around and try to find out what's going on there. Looks like a libexpat problem. It's not complaining that it doesn't find libexpat, maybe your version is too old? Is libexpat listed by "ldd r300_dri.so"? > > Ben. -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
r300_dri.so needs to get linked against expat. - ajax Yup, that did the trick. Thankyou. Any thoughts as to why it wasn't linked against expat when I built it the first time around? Ben. from glxinfo: disabling 3D acceleration 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_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig 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_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 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_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R300 20040924 AGP 1x x86/MMX+/3DNow!+/SSE NO-TCL OpenGL version string: 1.3 Mesa 6.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, 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_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, 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_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_secondary_color, GL_EXT_separate_specular_color, 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_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, 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 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL
Re: [Fwd: r300 Report.]
As long as the X server works and uses the ring buffer, that would point towards a simple configuration problem. Perhaps you could post a log of glxinfo with LIBGL_DEBUG=all and RADEON_DEBUG=all? cu, Nicolai Hmm, I believe you may be right about the config problem, I'm not sure why I didn't think of running glxinfo with LIBGL_DEBUG=all before.. [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=all glxinfo name of display: :0.0 libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed (/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol: XML_SetElementHandler) libGL error: unable to find driver: r300_dri.so --snip-- I'll have a mess around and try to find out what's going on there. Ben. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
Hi, On Saturday 06 November 2004 10:09, Ben Skeggs wrote: > I think the AGP issues *are* related to the lockup. I've just switched > sysloggers, and switched to CVS XServer (was using release 6.8 before). > My previous problems still occurred, but I now seem to have a lot more > debugging information in my syslog. I have the same AGP problem. If I > set AGP to 4x in my BIOS (rather than 8x), the corruption, and the > lockup don't occur. Okay, the new syslog has all the debug info. I notice the following line: Nov 7 07:37:58 disoft-dc [drm:radeon_cp_init_ring_buffer] writeback test failed The Radeon DRM source code has a comment indicating that writeback doesn't work everywhere, but I think it's safe to assume that all R300-based chips should be capable of writeback. This would indeed point towards a problem in the AGP setup in one way or another, and that means that the ring buffer won't work properly. Without a working ring buffer setup, it's only natural for a lockup to occur. Perhaps we should fail completely when the writeback test failed on R300-based hardware. Unfortunately, my AGP-fu isn't strong enough to know what's really going on here. > I've attached my syslog from when the lockup occurred, in case it helps. > > I also have the problem as Pat, where glxinfo reports "direct rendering: > No", but my Xorg log says it is. As long as the X server works and uses the ring buffer, that would point towards a simple configuration problem. Perhaps you could post a log of glxinfo with LIBGL_DEBUG=all and RADEON_DEBUG=all? cu, Nicolai > Ben Skeggs pgpVLxUiyCGRC.pgp Description: PGP signature
Re: [Fwd: r300 Report.]
Hello, The PCI ID is already added in the DRM branch of r300_driver. As for the AGP issues, I have no idea. Maybe they're related to the lockup, maybe not. cu, Nicolai I think the AGP issues *are* related to the lockup. I've just switched sysloggers, and switched to CVS XServer (was using release 6.8 before). My previous problems still occurred, but I now seem to have a lot more debugging information in my syslog. I have the same AGP problem. If I set AGP to 4x in my BIOS (rather than 8x), the corruption, and the lockup don't occur. I've attached my syslog from when the lockup occurred, in case it helps. I also have the problem as Pat, where glxinfo reports "direct rendering: No", but my Xorg log says it is. Ben Skeggs Nov 7 07:37:41 disoft-dc [drm:drm_core_init] drm_agp c0459e00 Nov 7 07:37:41 disoft-dc [drm] Initialized drm 1.0.0 20040925 Nov 7 07:37:44 disoft-dc [drm:drm_init] Nov 7 07:37:44 disoft-dc [drm:drm_get_dev] Nov 7 07:37:44 disoft-dc ACPI: PCI interrupt :02:00.0[A] -> GSI 19 (level, high) -> IRQ 19 Nov 7 07:37:44 disoft-dc [drm:drm_initmap] Nov 7 07:37:44 disoft-dc [drm:drm_initmap] initmap offset = 0xe900, size = 0x0001, type = 1 Nov 7 07:37:44 disoft-dc [drm:drm_initmap] finished Nov 7 07:37:44 disoft-dc [drm:drm_initmap] Nov 7 07:37:44 disoft-dc [drm:drm_initmap] initmap offset = 0xc000, size = 0x1000, type = 0 Nov 7 07:37:44 disoft-dc [drm:drm_initmap] finished Nov 7 07:37:44 disoft-dc [drm:radeon_preinit] AGP card detected Nov 7 07:37:45 disoft-dc [drm:setup_i2c_bus] I2C bus monid registered. Nov 7 07:37:45 disoft-dc [drm:setup_i2c_bus] I2C bus dvi registered. Nov 7 07:37:45 disoft-dc [drm:setup_i2c_bus] I2C bus vga registered. Nov 7 07:37:47 disoft-dc [drm:setup_i2c_bus] I2C bus crt2 registered. Nov 7 07:37:47 disoft-dc [drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0 Nov 7 07:37:47 disoft-dc [drm:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 Nov 7 07:37:47 disoft-dc [drm:drm_get_head] Nov 7 07:37:47 disoft-dc [drm:drm_get_head] new minor assigned 0 Nov 7 07:37:47 disoft-dc [drm] Initialized radeon 1.12.0 20041023 on minor 0: ATI Technologies Inc RV350 AP [Radeon 9600] Nov 7 07:37:58 disoft-dc [drm:drm_stub_open] Nov 7 07:37:58 disoft-dc [drm:drm_open_helper] pid = 15162, minor = 0 Nov 7 07:37:58 disoft-dc [drm:drm_setup] Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_release] open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_release] pid = 15162, device = 0xe200, open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_fasync] fd = -1, device = 0xe200 Nov 7 07:37:58 disoft-dc [drm:drm_takedown] Nov 7 07:37:58 disoft-dc [drm:radeon_do_cleanup_cp] Nov 7 07:37:58 disoft-dc [drm:drm_stub_open] Nov 7 07:37:58 disoft-dc [drm:drm_open_helper] pid = 15162, minor = 0 Nov 7 07:37:58 disoft-dc [drm:drm_setup] Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_release] open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_release] pid = 15162, device = 0xe200, open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_fasync] fd = -1, device = 0xe200 Nov 7 07:37:58 disoft-dc [drm:drm_takedown] Nov 7 07:37:58 disoft-dc [drm:radeon_do_cleanup_cp] Nov 7 07:37:58 disoft-dc [drm:drm_stub_open] Nov 7 07:37:58 disoft-dc [drm:drm_open_helper] pid = 15162, minor = 0 Nov 7 07:37:58 disoft-dc [drm:drm_setup] Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] offset = 0x, size = 0x2000, type = 2 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] 8192 13 e0911000 Nov 7 07:37:58 disoft-dc [drm:drm_mmap] start = 0xafcf4000, end = 0xafcf6000, offset = 0xe0911000 Nov 7 07:37:58 disoft-dc [drm:drm_vm_open] 0xafcf4000,0x2000 Nov 7 07:37:58 disoft-dc [drm:drm_do_vm_shm_nopage] shm_nopage 0xafcf4000 Nov 7 07:37:58 disoft-dc [drm:drm_do_vm_shm_nopage] shm_nopage 0xafcf5000 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] offset = 0xc000, size = 0x0800, type = 0 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] Looking for: offset = 0xc000, size = 0x0800, type = 0 Nov 7 07:37:58 disoft-dc [drm:drm_addmap]
Re: [Fwd: r300 Report.]
Hi, On Friday 05 November 2004 23:12, Pat Suwalski wrote: [snip] > I am running the following system: > - AMD 64 fx-51 I'm afraid that this is a very likely culprit, assuming you're running in 64 bit mode. The trouble is that parts of the DRM interface and also some of the code interfacing the hardware might be broken when it comes to 64 bit. I'm trying to fix code that is obviously 64bit unsafe when I notice something, but since I don't have the hardware to test it, I really can't promise anything. [snip] > One way or another, the PCI id of my card is 1002:4e48, and it seems to > have no negative effects on the hardware, so it might as well be added > to the list of pci id's. The PCI ID is already added in the DRM branch of r300_driver. As for the AGP issues, I have no idea. Maybe they're related to the lockup, maybe not. cu, Nicolai > If anyone has any insight into what's up with all of this, I'm all ears. > Again, I'll help out as much as I can. Thanks. > > --Pat pgpCKPT3cxirO.pgp Description: PGP signature
[Fwd: r300 Report.]
The original posting is below. Since then, I have disabled the driver, since it always locks within 5 minutes of starting X.org 6.8.0. Also, to answer a previous question, the r300 GL demo looks great, but the triangle demo does not. It comes out shifted and with some garbage. However, the triangles are visible. Original Message Subject: r300 Report. Date: Sun, 31 Oct 2004 00:15:19 -0400 From: Pat Suwalski <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hello, I just spent the evening fiddling with the two r300 patches from r300.sf.net. This eMail is a summary of my experiences, and I am willing to pursue the issues and keep trying. I am running the following system: - AMD 64 fx-51 - Radeon 9800XT - Kernel 2.6.9 - X.org 6.8.0 Initially, I was having a good deal of trouble getting it going. X would start, but as soon as any program would try to connect to the X server, the screen would go blank, but the computer was still in a responsive state. However, the X server was in state "R", and was not killable. I later discovered these dmesg messages (AGP basically killed itself): [drm] Initialized radeon 1.11.0 20020828 on minor 0: agpgart: Found an AGP 3.5 compliant device at :00:00.0. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a0a tmp:1f000a1a fell back to:- cmd:1f000a08 tmp:1f000a1a] agpgart: Bridge couldn't do AGP x4. agpgart: Graphic card couldn't do AGP x4. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a08 tmp:ff00021b fell back to:- cmd:1f000208 tmp:ff00021b] agpgart: Bridge couldn't do AGP x4. agpgart: Putting AGP V3 device at :00:00.0 into 0x mode agpgart: Putting AGP V3 device at :01:00.0 into 0x mode [drm] Loading R300 Microcode However, as you can see, the dri patch worked. The problem was that the gart can't seem to handle AGP8x, so I reduced it to 4x in the BIOS. At that point, the X server started working properly: [drm] Initialized radeon 1.11.0 20020828 on minor 0: agpgart: Found an AGP 3.5 compliant device at :00:00.0. agpgart: Putting AGP V3 device at :00:00.0 into 4x mode agpgart: Putting AGP V3 device at :01:00.0 into 4x mode [drm] Loading R300 Microcode If anyone has any insight into the 8x issue, please let me know. The X server confirmed success: (...) (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 169 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 (II) RADEON(0): Direct rendering enabled (...) However, glxinfo tells me: "direct rendering: No". The r300_demo confirms this by crapping out, suggesting the BusID is wrong, which it is not. One way or another, the PCI id of my card is 1002:4e48, and it seems to have no negative effects on the hardware, so it might as well be added to the list of pci id's. If anyone has any insight into what's up with all of this, I'm all ears. Again, I'll help out as much as I can. Thanks. --Pat --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
