mesa-6.5: assertion failed on resolution change
Hi all, I use mesa-6.5-6 - as currently in Fedora Development - to drive RV350 (1002:4150) glxgears performance is not particularly impressive (920fps; my former gfx r200-based card used to give 1700-2200 depending on the driver revision) and there are random lines flashing on the screen, which may be just some memory bandwith problems (resolution 1280x1280, 24bpp) since the lines go away at lower resolutions. Anyway, a more serious problem is a failed assertion in radeon driver when one tries to eg. change the resolution in Return to Castle Wolfenstein. The message is: wolfsp.x86: radeon_mm.c:464: radeon_mm_free: Assertion `id = rmesa- rmm-u_last' failed. Clues? Hints? Patches? Pawel --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mesa-6.5: assertion failed on resolution change
On 05/21/2006 10:54:45 PM, Aapo Tahkola wrote: On Sun, 21 May 2006 00:55:23 +0200 Pawel Salek [EMAIL PROTECTED] wrote: Hi all, I use mesa-6.5-6 - as currently in Fedora Development - to drive RV350 (1002:4150). glxgears performance is not particularly impressive (920fps; my former gfx r200-based card used to give 1700-2200 depending on the driver revision) and there are random lines flashing on the screen, which may be just some memory bandwith problems (resolution 1280x1280, 24bpp) since the lines go away at lower resolutions. Anyway, a more serious problem is a failed assertion in radeon driver when one tries to eg. change the resolution in Return to Castle Wolfenstein. The message is: wolfsp.x86: radeon_mm.c:464: radeon_mm_free: Assertion `id = rmesa-rmm-u_last' failed. This has been fixed in CVS. You can set ColorTiling option to true in xorg.conf to get a speed boost. ColorTiling works like a charm: it gives factor two speedup in glxgears, one can play RTCW at 1280x1024 *and* the random lines are gone! Is there any reason this option is not the default? Pawel --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of X600 (5B62) support inquiry; bug 5413
On 03/15/2006 04:01:30 AM, Mike Mestnik wrote: --- Pawel Salek [EMAIL PROTECTED] wrote: [snip] Was working fine for me, until trying to use a newer snapshot. I still need to patch drm_pciids.txt and copy over the /scripts dir before ./install.sh 1. you do not need to copy over /scripts - modify drm_pciids.h directly instead: The makefiles won't try to rebuild it then. Of course, the drm_pciids.txt should be eventually modified in CVS so that no manual modification is required. 2. I confirm that something got broken between 20060306 and 20060308. With any recent snapshot like 20060313, I get: $ glxgears *WARN_ONCE* File r300_ioctl.c function r300Clear line 555 CB_DPATH has been enabled. Please let me know if this introduces new instabilities. *** drmRadeonCmdBuffer: -22 (exiting) and following stuff in dmesg: [drm] Initialized radeon 1.24.0 20060225 on minor 0: [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed Pawel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DOOM3 with dri/r200 drivers: first impression
Hello, I thought I would share my impression of running DOOM3 (250SEK on sale!) using DRI drivers (free!). SUMMARY: - hardware TCL broken. - some lighting problems with software TCL. - few lockups (save frequently!). - average 10 FPS on AMD XP1800+, Radeon 8500LE, 640x480. FOLLOWUP: My goal was to run DOOM3 with a minimal number of changes since this is a production machine. I used kernel-2.6.10-1.741_FC3 and patched xorg-x11-6.8.1.902-1. Trying to compile current Mesa against xorg-x11-6.8.1.902 is a major PIA[1]. I ended up using mesa-6.2.1 that comes with xorg and port the R200 part of Roland Scheidegger's S3TC patch to this code. See http://www.theochem.kth.se/~pawsa/dri/ for few more details. I could confirm that hardware TCL is broken (at least in the version I used) - does anybody know how to fix it? http://www.theochem.kth.se/~pawsa/dri/tcl-enabled.png http://www.theochem.kth.se/~pawsa/dri/tcl-disabled.png Software TCL appears to have some problems, too: http://www.theochem.kth.se/~pawsa/dri/lighting-problem1.png http://www.theochem.kth.se/~pawsa/dri/lighting-problem2.png - can anybody else confirm that? I could repeatedly get a hardware lockup when standing in certain place and looking at certain point: http://www.theochem.kth.se/~pawsa/dri/sure-hang.png The lockup happened twice also when looking at the moving bridge few corridors later. Pawel [1] current mesa CVS appears to use a number of constants mostly related to HYPERZ without defining them. Perhaps I should have followed build instructions exactly. I have a patch that gets me through the compilation (it is not something to commit, rather to give an idea where the problems lie). Still, the linking phase stops with some error related to software shaders, I believe. http://www.theochem.kth.se/~pawsa/dri/mesa-build-changes-20041207.patch I think the DRI building instruction phase is all nice and great but the whole process is complex and limits the number of people testing the code to hardcore hackers (or perhaps the goal is to reduce number of reporters that have no idea what they are writing about? In a way, I can understand that...:). --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Application performance: open source vs proprieta ry?
On 2003.11.27 06:20, Alexander Stohr wrote: [snip] There is a comparison from R.Scheidegger, it is linked at the dri web page at Documents page, Other Documents section comparing several Radeon 9000 capable drivers including the DRI drivers. [snip] This review is very good but I would really like to see the numbers - and some analysis! - for recently released game Savage that was even announced on Slashdot. I tried it on my ATI8500LE (I know it is not a state-of-the-art graphics card any more) and I have got mixed feelings. Binary ATI drivers appeared to have problems with character rendering (but performance was almost decent) and DRI drivers could render only single frame every few seconds and had usual problems with s3TC but the program can be asked not to compress textures - I wish it could detect the missing extension automatically as ID-software games do. I contacted S2Games and they said that: The open-source DRI drivers don't support the Vertex Buffer Object OpenGL extension [...]. We fall back to other methods like VAR and such on cards that don't support VBO, but really it comes down to the driver optimizing for high poly counts. We use the same code in both Linux and Windows (since it's all OpenGL), and in Windows we get fast speeds on both ATI and NVidia. In Linux, ATI seems like a non-starter on both driver sets, whereas the binary NVidia drivers work like a charm. In games like RTCW, they deal in the realm of 2,000-5,000 polygons per frame. In more recent games like Savage, we push more like 100,000 polygons per frame, since we're doing full outdoor scenes. [...] The VAR that we use is the NV_vertex_array_range extension. If the driver don't support that, I believe we fall back to the CVA extension (compiled vertex array). I can imagine many applications that require many polygons to be displayed: CAD, molecular modelling and I understand such extensions are not patented, are they? Does anybody know why GL_EXT_compiled_vertex_array cannot give same performance as GL_EXT_vertex_buffer_object? Would that be much work to implement this extension? Pawel --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Application performance: open source vs proprieta ry?
On 11/27/2003 08:18:17 PM, Alexander Stohr wrote: From: Pawel Salek [snip] DRI drivers could render only single frame every few seconds and had usual problems with s3TC but the program can be asked not to compress textures - I wish it could detect the missing extension automatically as ID-software games do. The DRI drivers dont have a problem with S3TC, they simply dont expose those patented color format. If there is a problem, then there is the problem that patents do have problem with free software and open source such as XFree86 licensed or GPL licensed software [snip] I absolutely agree with you. It was just my phrasing that was unfortunate and not reflecting my true opinion. Pawel --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Exceedingly large memory usage in XFree CVS, as of 20030213
Hi, I reported some time ago (Sat, 1 Feb 2003 22:38:44 +0100, message-id: [EMAIL PROTECTED]) that return to Castle Wolfenstein stutters with radeon 8500. The problem was traced to large memory usage by the game. Back then, I did not know whether it was a problem with the game or with XFree. Today, I have run a molecular visualisation program on a RNA strand (I usually deal with slightly smaller molecules) and I was surprised when I noticed that the process occupied more than 200MB of memory. Disabling the visualisation mode reduced the memory usage to mere 8MB. So, the 200MB memory is basically used by a very simple display list generation that for the molecule in question creates a 1336 GL_QUAD_STRIP's with total 34736 glVertex3f vertexes (26 vertexes per strip) and 1212 GL_TRIANGLES with 465408 total glVertex3fv vertexes (384 per glBegin/glEnd group) - which seem like reasonable values. My primary suspect is then XFree86, or exactly GL library. I thought I would start reporting the problem here first, particulary because I get following message in dmesg: [drm:radeon_lock_take] *ERROR* 4 holds heavyweight lock I will appreciate any redirection to more appriopriate lists, if needed. Pawel -- Pawel Salek http://www.theochem.kth.se/~pawsa/ Theoretical Chemistry Division, KTH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Exceedingly large memory usage in XFree CVS, as of 20030213
On 2003.03.04 20:00 Ian Romanick wrote: Pawel Salek wrote: Today, I have run a molecular visualisation program on a RNA strand (I usually deal with slightly smaller molecules) and I was surprised when I noticed that the process occupied more than 200MB of memory. Disabling the visualisation mode reduced the memory usage to mere 8MB. So, the 200MB memory is basically used by a very simple display list generation that for the molecule in question creates a 1336 GL_QUAD_STRIP's with total 34736 glVertex3f vertexes (26 vertexes per strip) and 1212 GL_TRIANGLES with 465408 total glVertex3fv vertexes (384 per glBegin/glEnd group) - which seem like reasonable values. Is the application using display lists? There is a know problem where display lists can use a lot more memory than they should. If the app does use display lists and you have access to the source, could you modify it to not use display lists? I'd be curious to see if the memory usage goes down. Affirmative. I do have access to the source and disabling the display list generation and doing direct rendering instead reduces the memory usage to the base level (8MB). I am sure plenty of people would love to have this issue fixed since it basically renders display lists useless for non-trivial applications (but I am sure you guys know that, too). Thanks for help! Pawel --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switching problems in wolfenstein.
On 2003.02.02 19:29 Keith Whitwell wrote: Pawel Salek wrote: No. Probably the most helpful thing you can do is binary search to try find the change which introduced your problem. So try a date half-way between now september, check out that version see if the problem is there, etc. I did the testing and pretty early realized the problem is somewhere else. I have 256MB memory and before, wolfenstein fit just fine in this space (230-240MB, IIRC). Now, when I run kernel 2.4.20-2.24 + glibc-2.3.1-38 (the patches as in RH's phoebe2), the process size is about 300MB, or even slighly more - and the box starts swapping. I wonder whether it is a memory leak, or something else has changed. In any case, I consider it unlikely DRI problem. If I have some more info, I will post it here. /pawel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On 2003.02.04 19:06 Michel Dänzer wrote: And there's even more: newer compilers seem to optimize away some of the reads with strict aliasing. I thought I'd steal some code from the kernel to detect if the compiler supports -fno-strict-aliasing, but it looks like it just uses that unconditionally. We probably want to do the same for the DRM at least? AFAIR it's been supported since early 2.95. Isn't the volatile keyword the right way to disable such optimizations? -pawel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switching problems in wolfenstein.
On 2003.02.02 04:24 Keith Whitwell wrote: Steps to Reproduce: 1. Run RTCW with normal quality settings. Try opening a door (the tram station, third level, is particularly good test case). The computer can hang for a second, and the sound will stutter like on damaged CD. Actual Results: The computer can hang for a second, and the sound will stutter like on damaged CD. Frame rate drops down from 100fps to 1. It can be very difficult to aim and shoot in such a situation. :-) This is a regression wrt September 2002. Pawel, Can you try using the pre-september kernel module with the current driver? I have a guess that it may be related to changes made in the radeon.o module about that time. I tried v 1.5.0 [drm] Initialized radeon 1.5.0 20020611 on minor 0 as in dri CVS on 2002-08-31 but the delays are still there. Should I try another version? -pawel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switching problems in wolfenstein.
Hi, I have a problem to report. When playing wolfenstein (RTCW, exactly) on ATi powered 8500LE card with XFree86-4.2.99.4-20030129.1 (I believe this is the current CVS, as packaged current in RH's rawhide), game hangs for a second when entering new rooms. Also, starting a new level takes unusually long time. These problems did not exist when I used dri.sf.net snapshots in August-September 2002. My first guess here is something wrong either with card memory management or with the texture upload. The delays remain even after changing the quality settings. FWIW, mode switching (geometry and texture detail) work only if the Xserver is started with the same resolution as used later by the game (i.e. if the game uses 800x600, XF86Config should contain only Mode 800x600). This may RTCW bug, though. Version-Release number of selected component (if applicable): XFree86-4.2.99.4-20030129.1 How reproducible: Always Steps to Reproduce: 1. Run RTCW with normal quality settings. Try opening a door (the tram station, third level, is particularly good test case). The computer can hang for a second, and the sound will stutter like on damaged CD. Actual Results: The computer can hang for a second, and the sound will stutter like on damaged CD. Frame rate drops down from 100fps to 1. It can be very difficult to aim and shoot in such a situation. :-) This is a regression wrt September 2002. I thought it might have been connected with introduction of RandR, but since I unsuccesfully tried playing with the resolution, I am not sure any longer. dmesg reports: agpgart: Maximum main memory to use for agp memory: 203M agpgart: Detected Via Apollo Pro KT266 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe000 64MB [drm] Initialized radeon 1.7.0 20020828 on minor 0 [drm] Loading R200 Microcode graphics card shares IRQ with a network card but I do not think this is a problem. Decreasing color depth from 24 to 16 helps considerably to shorten delays. It takes the image more coarse, too. It looks like half of the memory on the card gets wasted. If you need more info, just ask. Pawel -- Pawel Salek http://www.theochem.kth.se/~pawsa/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock
On 2002.10.11 21:31 José Fonseca wrote: Sorry for the delay, but it has been a busy day today. The libxaa.a module build from today's CVS using gcc-2.95.3/glibc-2.2.5 is available at http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/libxaa.a.bz2 This expands to some fat 6MB due to the debug info, but first try it as is before attempt to strip anything out of it. I hope this helps to discover the Sig11 problem. This fixes the problem for me (on RH8.0, radeon snapshot). And I nearly lost the hope. I think it would be nice to have the snapshots working smoothly again, they are really useful for people like me, who would like to follow the development but the due to notorius lack of spare time cannot afford tracking CVS changes. Thanks! -pawel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock
On 2002.10.10 18:09 Michel Dänzer wrote: Do you also see the signal 11 in the X server log? [snip] That won't help the signal 11 though, which is probably still due to some kind of incompatibility in the binary snapshots. Yes, I see signal 11 in the log (attached). Strangely, since the snapshots are supposedly compiled on RH8.0 (i.e. the same as mine), I thought it would not be a problem! Another strange for me thing is that the screen is not reset to text mode - but the keyboard works as it still was attached to the console. Pawel XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-72) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-11smp i686 [ELF] Build Host: daffy.perf.redhat.com Module Loader present OS Kernel: Linux version 2.4.18-14 ([EMAIL PROTECTED]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Sep 4 13:35:50 EDT 2002 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Thu Oct 10 23:51:24 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Radeon Mobility M6 (**) |--Input Device Mouse0 (**) |--Input Device Mouse1 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc102 (**) XKB: model: pc102 (**) Option XkbLayout se (**) XKB: layout: se (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8090, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3575 card 8086,1969 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,3576 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card , rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 41 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card , rev 01 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,2483 card , rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1558,0420 rev 01 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 1558,1800 rev 01 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c59 card 1558,0420 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:02:0: chip 104c,8023 card 1558,0420 rev 00 class 0c,00,10 hdr 00 (II) PCI: 02:04:0: chip 10ec,8139 card 1558,8586 rev 10 class 02,00,00 hdr 00 (II) PCI: 02:07:0: chip 1180,0476 card , rev 88 class 06,07,00 hdr 82 (II) PCI: 02:07:1: chip 1180,0476 card , rev 88 class 06,07,00 hdr 82 (II) PCI: 02:07:2: chip 1180,0576 card , rev 00 class 08,80,00 hdr 80 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0x -
[Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock
Hi, I have got a following messages on boot with current snapshot radeon-20021009, running with ATI Radeon Mobility M6 LY rev 0, stock RH8.0 kernel (2.4.18-14 with a whole lot of patches). modprobe: modprobe: Can't locate module char-major-226 last message repeated 3 times kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 439M kernel: agpgart: Detected Intel i830M chipset kernel: agpgart: AGP aperture is 32M @ 0xea00 kernel: [drm] AGP 0.99 on Unknown @ 0xea00 32MB kernel: [drm] Initialized radeon 1.6.0 20020828 on minor 0 kernel: [drm:radeon_unlock] *ERROR* Process 665 using kernel context 0 gm[664]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 kernel: [drm:radeon_unlock] *ERROR* Process 672 using kernel context 0 gdm[671]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 kernel: [drm:radeon_unlock] *ERROR* Process 674 using kernel context 0 gdm[673]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 kernel: [drm:radeon_unlock] *ERROR* Process 676 using kernel context 0 My impression is that it is more of a kernel module problem than the driver's but that a wild guess only. (just ask if more information is needed). -pawel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website.
On 2002.09.23 06:24 Frank Worsley wrote: 2. The main problem Ian Molton and you seem to have with the current site is that content is hard to find. That is probably a good point, but I think the way you have reorganized the content is even worse. I think it is much too early for this kind of criticism. While the updated website is far from perfect and finished, I definetely think it is a clear improvement with respect to the former version. From a point of view of a person that only ocassionally follows development of DRI, it is important to get the message out and I would consider any change that makes the website more alive (+the information can actually be found on it) a change for good. There are few things more discouraging that a unmaintained website. Some guys are trying to do something about it and IMO definetely deserve a credit for it. Pawel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
