Re: [Dri-devel] R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied
On Tuesday 08 October 2002 17:52, Jens Owen wrote: > Ilia Zadorozhko wrote: > > Hi people, > > Help me please getting DRI to work. > > I've installed latest (rage128-20021008-linux.i386.tar.bz2) versions of > > DRI. Function drmSetBusid requires some kind of permission, which I can't > > understand. Launching X from root gives the same results. Please, help ! > > > > Some info and logs: > > Kernel 2.4.19 > > - lsmod - > > Module Size Used by > > r128 88132 0 > > agpgart31840 1 > > ---ls -l /dev/dri/--- > > crw-rw-rw-1 root root 226, 0 ïËÔ 7 17:14 card0 > > ---XF86Config-4 > > Section "DRI" > > Mode0666 > > EndSection > > XFree86.0.log--- > > XFree86 Version 4.2.0 / X Window System > > . > > (--) PCI:*(2:0:0) ATI Rage 128 Pro PF rev 0, Mem @ 0xf000/26, > > 0xff9fc000/14, I/O @ 0xd800/8, BIOS @ 0xff9c/17 > > ... > > (==) R128(0): Write-combining range (0xf000,0x200) > > drmOpenDevice: minor is 0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 7, (OK) > > drmOpenDevice: minor is 0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 7, (OK) > > drmOpenDevice: minor is 0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 7, (OK) > > drmGetBusid returned '' > > (II) R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied > > (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. > > > > > Ilia, > > Maybe it's a kernel module problem. Make sure your AGPGART module is > loaded into the kernel before the r128 module. If that doesn't work, > post the output from dmesg. Jens, This is a dmesg log you asked for. --- dmesg -- Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 321M agpgart: agpgart: Detected an Intel i815, but could not find the secondary device. Assuming a non-integrated video card. agpgart: Detected Intel i815 chipset agpgart: AGP aperture is 64M @ 0xf800 [drm] AGP 0.99 on Intel i815 @ 0xf800 64MB [drm] Initialized r128 2.2.0 20010917 on minor 0 - --- 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] Quake3 1.32, r_smp 1, mga (G550) error
Am Mittwoch, 9. Oktober 2002 05:40 schrieb Dieter Nützel: > Am Dienstag, 8. Oktober 2002 16:37 schrieb Timothee Besset: > > Mh .. setting the default to r_smp 1 when SMP detected may have been an > > oversight. This has been tested to work on nvidia cards, it's likely to > > break on anything else. I'd be interested to hear about work/not work in > > various situations. > > > > Use +set developer 1 +set logfile 2 on the command line to get a log file > > from q3. > > With my "startup script" I get log all the time...;-) > > Card: R200 DRI CVS. > Kernel: 2.4.19-ck5 and 2.5.40-ac4 > System: dual AMD Athlon MP 1900+, MSI K7D Master-L, AMD 760MPX > > I get ups with both kernels when "demo four" should come up (after weapons > load). > > But I think it is a r100/r200 driver issue not your fault. > Even though "r_smp" should default to "0". > > Load is _definitely_ shortened 'cause "quake3.x86" and "X" rising on > different CPUs, now. GREAT! Can't wait to see it running. > > - finished R_Init - > Loading vm file vm/ui.qvm. > VM file ui compiled to 594408 bytes of code > ui loaded in 1963008 bytes on the hunk > 35 arenas parsed > 32 bots parsed > Loading vm file vm/cgame.qvm. > VM file cgame compiled to 786818 bytes of code > cgame loaded in 5380768 bytes on the hunk > drmCommandWrite: -22 > drmRadeonCmdBuffer: -22 > > Get the same crash with several other "threaded" (multiple context) apps. OK, here comes the whole log. -Dieter q3.log.bz2 Description: BZip2 compressed data
Re: [Dri-devel] Quake3 1.32, r_smp 1, mga (G550) error
Am Dienstag, 8. Oktober 2002 16:37 schrieb Timothee Besset: > Mh .. setting the default to r_smp 1 when SMP detected may have been an > oversight. This has been tested to work on nvidia cards, it's likely to > break on anything else. I'd be interested to hear about work/not work in > various situations. > > Use +set developer 1 +set logfile 2 on the command line to get a log file > from q3. With my "startup script" I get log all the time...;-) Card: R200 DRI CVS. Kernel: 2.4.19-ck5 and 2.5.40-ac4 System: dual AMD Athlon MP 1900+, MSI K7D Master-L, AMD 760MPX I get ups with both kernels when "demo four" should come up (after weapons load). But I think it is a r100/r200 driver issue not your fault. Even though "r_smp" should default to "0". Load is _definitely_ shortened 'cause "quake3.x86" and "X" rising on different CPUs, now. GREAT! Can't wait to see it running. - finished R_Init - Loading vm file vm/ui.qvm. VM file ui compiled to 594408 bytes of code ui loaded in 1963008 bytes on the hunk 35 arenas parsed 32 bots parsed Loading vm file vm/cgame.qvm. VM file cgame compiled to 786818 bytes of code cgame loaded in 5380768 bytes on the hunk drmCommandWrite: -22 drmRadeonCmdBuffer: -22 Get the same crash with several other "threaded" (multiple context) apps. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: Dieter.Nuetzel at hamburg.de (replace at with @) --- 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] Quake3 1.32, r_smp 1, mga (G550) error
On Tuesday 08 October 2002 08:30 am, you wrote: > Hi, > > I was quite interested to see this in the changelog of the latest Quake3 > point release: > > - SMP support in the renderer. Detects CPU count, r_smp 1 default if > available. (thanks to Gareth Hughes for contributing this) > > Starting up with +set r_smp 0 is still ok. However, when I start up > trying to use r_smp 1 quake3 exits (not very cleanly, but ok) it tells > me: > > mga_get_buffer_ioctl: flush ret=-22 > > bang. dead. It doesn't lock my computer, but mouse input etc doesn't > work till I restart X. > > hardware is: > - 2x P3-800 on a BX chipset (not overclocked or anything - running > 100mhz FSB) > - a matrox G550 > > software is: > - Debian with Xfree 4.2.1 (I tried both the matrox distributed drivers > and the Xfree ones.) > - Linux 2.4.19 SMP > > One final note: since it is the default behaviour of quake3 to start > with r_smp 1 when >1 cpu's are detected, I'd expect it to break for > everyone using SMP and matrox. (maybe it even only works on nvidia?) > > Thanks, > > -- Mourad I get something very similar w/my Radeon r100. When it exits, mouse focus/events are lost, but if I restart q3 and then exit (up arrow in the konsole) it restores the input for mouse and keyboard. Nick --- 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] waiting for anoncvs_dri's still there ;-(
Dieter Nützel wrote: > cvs update > M xc/config/cf/host.def > M xc/config/cf/xf86site.def > M xc/config/cf/xfree86.cf > P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c > cvs server: [16:53:25] waiting for anoncvs_dri's lock in > /cvsroot/dri/xc/xc/lib/GLw > cvs server: [16:53:55] waiting for anoncvs_dri's lock in > /cvsroot/dri/xc/xc/lib/GLw > cvs server: [16:54:25] waiting for anoncvs_dri's lock in > /cvsroot/dri/xc/xc/lib/GLw > cvs server: [16:54:55] waiting for anoncvs_dri's lock in > /cvsroot/dri/xc/xc/lib/GLw > cvs [update aborted]: received interrupt signal > > Any glue? I'm stuck on this too. I think that sourceforge has a cron job that goes through and deletes stale cvs locks (once per day). Hopefully it'll be OK tomorrow. -Brian --- 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
[Dri-devel] waiting for anoncvs_dri's still there ;-(
cvs update M xc/config/cf/host.def M xc/config/cf/xf86site.def M xc/config/cf/xfree86.cf P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c cvs server: [16:53:25] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:53:55] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:54:25] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:54:55] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs [update aborted]: received interrupt signal Any glue? -Dieter --- 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
[Dri-devel] cvs update and checkout: waiting for anoncvs_dri's lock
Hi, I can't make any cvs updates or checkouts. It hangs up with messages like this one: cvs server: [12:29:45] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw If I understand the numbers correctly then there is a lock which is over 12 hours old. That's a bit confusing, I completed a cvs update without such messages less than 12 hours ago. Can someone fix this, please? Thanks, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- 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] Quake3 1.32, r_smp 1, mga (G550) error
On Tue, 2002-10-08 at 19:09, Jonny.Strom wrote: > Hi > > I did a patch for lockups on Matrox cards it is included in the > latest pre relase for the new upcomming 2.4.20 kernel, but I don't > know what will happen on a SMP system, but you can try it out and I > would be intrested to get feedback :) I can also send you the patch if > you don't want to get the new kernel. I'll get the latest kernel and try it out. By the way, something interesting that I saw in my messages log: [drm:mga_dma_buffers] *ERROR* mga_dma_buffers called without lock held [drm:mga_dma_flush] *ERROR* mga_dma_flush called without lock held [drm:mga_dma_reset] *ERROR* mga_dma_reset called without lock held mtrr: base(0xd400) is not aligned on a size(0x180) boundary And a whole bunch of them like that. I'll tell you my findings... -- Mourad > Mourad De Clerck wrote: > > - SMP support in the renderer. Detects CPU count, r_smp 1 default if > > available. (thanks to Gareth Hughes for contributing this) > > > > Starting up with +set r_smp 0 is still ok. However, when I start up > > trying to use r_smp 1 quake3 exits (not very cleanly, but ok) it tells > > me: > > > > mga_get_buffer_ioctl: flush ret=-22 > > > > bang. dead. It doesn't lock my computer, but mouse input etc doesn't > > work till I restart X. > > --- 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
[Dri-devel] Re: [Dri-users] problems with radeon-20021001,2 and 4 and RadeonMobility M6
On Sun, 6 Oct 2002, José Fonseca wrote: > I can already advance that the full XFree86.0.log would be nice to see > if a message regarding the XAA versioning pops up or not. attached, compiled and installed from 1008 radeon package. Please let me know if there is anoy other information to assist. XFree86 Version 4.2.0 (Custom Build: 4.2.0-8) / 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-acpi-0517 i686 [ELF] Build Host: samurai Module Loader present 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: Tue Oct 8 13:05:29 2002 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Anaconda Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Radeon (generic)" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc101" (**) XKB: model: "pc101" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) 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 (WW) Open APM failed (/dev/apm_bios) (No such device) (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 = 0x800240e0, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3575 card 104d,80e7 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 104d,80e7 rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 104d,80e7 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2487 card 104d,80e7 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 104d,80e7 rev 01 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,2483 card 104d,80e7 rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 104d,80e7 rev 01 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 104d,80e7 rev 01 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c59 card 104d,80e7 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:02:0: chip 104c,8021 card 104d,80e7 rev 02 class 0c,00,10 hdr 00 (II) PCI: 02:05:0: chip 1180,0476 card 4400, rev 80 class 06,07,00 hdr 82 (II) PCI: 02:05:1: chip 1180,0476 card 4c00, rev 80 class 06,07,00 hdr 82 (II) PCI: 02:08:0: chip 8086,1031 card 104d,80e7 rev 41 class 02,00,00 hdr 00 (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 - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0x3000 - 0x30ff (0x100) IX[B] [1] -1 0x3400 - 0x34ff (0x100) IX[B] [2] -1 0x3800 - 0x38ff (0x100) IX[B] [3] -1 0x3c00 - 0x3cff (0x100) IX[B] (II) Bus 1 non-prefetchab
[Dri-devel] Re: http://penguinppc.org/~daenzer/debian/dri-trunk/
> > > Why don't you just use > > > > > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > > > > This is new to me, > > I guess it wouldn't be a bad idea to mention them somewhere on > dri.sf.net. Who is them? > DRI CVS snapshot packages, so based on 4.2.0. What is it it? Details are needed if you want it (a link) on the website. Liam it depends --- 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] R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied
On Tue, 8 Oct 2002 11:29:44 +0300 Ilia Zadorozhko <[EMAIL PROTECTED]> wrote: > Hi people, > Help me please getting DRI to work. > I've installed latest (rage128-20021008-linux.i386.tar.bz2) versions of DRI. > Function drmSetBusid requires some kind of permission, which I can't > understand. Launching X from root gives the same results. Please, help ! > > Some info and logs: > Kernel 2.4.19 > - lsmod - > Module Size Used by > r128 88132 0 > agpgart31840 1 > ---ls -l /dev/dri/--- > crw-rw-rw-1 root root 226, 0 ïËÔ 7 17:14 card0 > ---XF86Config-4 > Section "DRI" > Mode0666 > EndSection > XFree86.0.log--- > XFree86 Version 4.2.0 / X Window System > . > (--) PCI:*(2:0:0) ATI Rage 128 Pro PF rev 0, Mem @ 0xf000/26, > 0xff9fc000/14, I/O @ 0xd800/8, BIOS @ 0xff9c/17 > ... > (==) R128(0): Write-combining range (0xf000,0x200) > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmGetBusid returned '' > (II) R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied > (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. > > José, didn't we see such problems with the Mach64 driver some months ago, when mixing compiler versions? I don't remember which combination it was that had these problems. Ilia, make sure that the kernel module is compiled with the same compiler version as your kernel (in case you have several versions installed). Cheers, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- 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] R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0),Permission denied
Ilia Zadorozhko wrote: > Hi people, > Help me please getting DRI to work. > I've installed latest (rage128-20021008-linux.i386.tar.bz2) versions of DRI. > Function drmSetBusid requires some kind of permission, which I can't > understand. Launching X from root gives the same results. Please, help ! > > Some info and logs: > Kernel 2.4.19 > - lsmod - > Module Size Used by > r128 88132 0 > agpgart31840 1 > ---ls -l /dev/dri/--- > crw-rw-rw-1 root root 226, 0 ïËÔ 7 17:14 card0 > ---XF86Config-4 > Section "DRI" > Mode0666 > EndSection > XFree86.0.log--- > XFree86 Version 4.2.0 / X Window System > . > (--) PCI:*(2:0:0) ATI Rage 128 Pro PF rev 0, Mem @ 0xf000/26, > 0xff9fc000/14, I/O @ 0xd800/8, BIOS @ 0xff9c/17 > ... > (==) R128(0): Write-combining range (0xf000,0x200) > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmGetBusid returned '' > (II) R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied > (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. > > > > > --- > 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 > > Ilia, Maybe it's a kernel module problem. Make sure your AGPGART module is loaded into the kernel before the r128 module. If that doesn't work, post the output from dmesg. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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] Quake3 1.32, r_smp 1, mga (G550) error
Mh .. setting the default to r_smp 1 when SMP detected may have been an oversight. This has been tested to work on nvidia cards, it's likely to break on anything else. I'd be interested to hear about work/not work in various situations. Use +set developer 1 +set logfile 2 on the command line to get a log file from q3. TTimo On 08 Oct 2002 16:30:58 +0200 Mourad De Clerck <[EMAIL PROTECTED]> wrote: > Hi, > > I was quite interested to see this in the changelog of the latest Quake3 > point release: > > - SMP support in the renderer. Detects CPU count, r_smp 1 default if > available. (thanks to Gareth Hughes for contributing this) > > Starting up with +set r_smp 0 is still ok. However, when I start up > trying to use r_smp 1 quake3 exits (not very cleanly, but ok) it tells > me: > > mga_get_buffer_ioctl: flush ret=-22 > > bang. dead. It doesn't lock my computer, but mouse input etc doesn't > work till I restart X. > > hardware is: > - 2x P3-800 on a BX chipset (not overclocked or anything - running > 100mhz FSB) > - a matrox G550 > > software is: > - Debian with Xfree 4.2.1 (I tried both the matrox distributed drivers > and the Xfree ones.) > - Linux 2.4.19 SMP > > One final note: since it is the default behaviour of quake3 to start > with r_smp 1 when >1 cpu's are detected, I'd expect it to break for > everyone using SMP and matrox. (maybe it even only works on nvidia?) > > Thanks, > > -- Mourad > > > > > > > --- > 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 > --- 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
[Dri-devel] Quake3 1.32, r_smp 1, mga (G550) error
Hi, I was quite interested to see this in the changelog of the latest Quake3 point release: - SMP support in the renderer. Detects CPU count, r_smp 1 default if available. (thanks to Gareth Hughes for contributing this) Starting up with +set r_smp 0 is still ok. However, when I start up trying to use r_smp 1 quake3 exits (not very cleanly, but ok) it tells me: mga_get_buffer_ioctl: flush ret=-22 bang. dead. It doesn't lock my computer, but mouse input etc doesn't work till I restart X. hardware is: - 2x P3-800 on a BX chipset (not overclocked or anything - running 100mhz FSB) - a matrox G550 software is: - Debian with Xfree 4.2.1 (I tried both the matrox distributed drivers and the Xfree ones.) - Linux 2.4.19 SMP One final note: since it is the default behaviour of quake3 to start with r_smp 1 when >1 cpu's are detected, I'd expect it to break for everyone using SMP and matrox. (maybe it even only works on nvidia?) Thanks, -- Mourad --- 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
[Dri-devel] Ann: I830/i845 snapshots available
Binary snapshots for the Intel i830/i845 chipsets are now available from the usual place, http://dri.sourceforge.net/snapshots/ . Please report any problems with the driver installation to me and/or dri-users mailing list, and problems with the drivers themselves to dri-devel. Jose Fonseca --- 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: problems with radeon
On Die, 2002-10-08 at 11:01, José Fonseca wrote: > Michel, > > On Mon, Oct 07, 2002 at 12:58:34AM +0200, Michel Dänzer wrote: > >On Son, 2002-10-06 at 18:08, Svein Harang wrote: > >> Michel Dänzer: > >> > On Son, 2002-10-06 at 17:21, Svein Harang wrote: > >> > > GNU/linux Debian testing/XFree86 Version 4.2.1, Hercules 3D Prophet 8500LE > >> > > 2.4.19 > >> > Why don't you just use > >> > > >> > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > >> > >> This is new to me, > > > >I guess it wouldn't be a bad idea to mention them somewhere on dri.sf.net. > > > > Add into http://dri.sourceforge.net/snapshots/ a README.debian with a link and > a brief description of how those differ from the ones provided on > SourceForge. Done (http://dri.sourceforge.net/snapshots/README.Debian), would be nice if this was linked to from the downloads page. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] New r100 waiting patch
On Tue, 08 Oct 2002 13:34:47 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > Hi Keith, > > > > I attached a new r100 waiting patch against the latest trunk. I assume > > that you have the most up-to-date r200 waiting code in your tree. I > > added EAGAIN to conditions handled gracefully. But I couldn't find any > > situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using > > grep on .../linux/drm/kernel). Is that just a precaution for future > > changes in the ioctl? > > Felix, > > Does this patch address the irq/busywait pingponging that was happening last time? I've never had this on R100, not with busy waiting. This should only happen with extremely high frame rates, so I didn't think it's that important for the general case. If you disagree I'll try to come up with a solution, maybe a second chance for the interrupt would help. Reducing the number of cycles in the busy waiting loop would be an ad-hoc solution. But it's too system dependent (CPU, compiler ...) to be a real solution. > > Keith Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- 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] New r100 waiting patch
Felix Kühling wrote: > Hi Keith, > > I attached a new r100 waiting patch against the latest trunk. I assume > that you have the most up-to-date r200 waiting code in your tree. I > added EAGAIN to conditions handled gracefully. But I couldn't find any > situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using > grep on .../linux/drm/kernel). Is that just a precaution for future > changes in the ioctl? Felix, Does this patch address the irq/busywait pingponging that was happening last time? Keith --- 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] New r100 waiting patch
Felix Kühling wrote: > Hi Keith, > > I attached a new r100 waiting patch against the latest trunk. I assume > that you have the most up-to-date r200 waiting code in your tree. I > added EAGAIN to conditions handled gracefully. But I couldn't find any > situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using > grep on .../linux/drm/kernel). Is that just a precaution for future > changes in the ioctl? I've had reports of it on FreeBSD. Keith --- 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: problems with radeon
José Fonseca: > Michel Dänzer >> Svein Harang > >>> > GNU/linux Debian testing/XFree86 Version 4.2.1, Hercules 3D Prophet > >>> > 8500LE 2.4.19 > >>> Why don't you just use > >>> > >>> deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > > Add into http://dri.sourceforge.net/snapshots/ a README.debian with a link > and a brief description of how those differ from the ones provided on > SourceForge. Sounds like a good idea, I had much struggle whith this one before Michel helpt me. -- Svein Harang Its time to kick ass and chew bubblegum... And I'm all outta gum msg06651/pgp0.pgp Description: PGP signature
[Dri-devel] New r100 waiting patch
Hi Keith, I attached a new r100 waiting patch against the latest trunk. I assume that you have the most up-to-date r200 waiting code in your tree. I added EAGAIN to conditions handled gracefully. But I couldn't find any situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using grep on .../linux/drm/kernel). Is that just a precaution for future changes in the ioctl? Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! radeon_smartwait.patch Description: Binary data
Re: [Dri-devel] Re: problems with radeon
Michel, On Mon, Oct 07, 2002 at 12:58:34AM +0200, Michel Dänzer wrote: >On Son, 2002-10-06 at 18:08, Svein Harang wrote: >> Michel Dänzer: >> > On Son, 2002-10-06 at 17:21, Svein Harang wrote: >> > > GNU/linux Debian testing/XFree86 Version 4.2.1, Hercules 3D Prophet 8500LE >> > > 2.4.19 >> > Why don't you just use >> > >> > debhttp://penguinppc.org/~daenzer/debian/dri-trunk/./ >> >> This is new to me, > >I guess it wouldn't be a bad idea to mention them somewhere on dri.sf.net. > Add into http://dri.sourceforge.net/snapshots/ a README.debian with a link and a brief description of how those differ from the ones provided on SourceForge. >> I use another unofficial Xfree deb-mirror, is this 4.1/4.2? > >DRI CVS snapshot packages, so based on 4.2.0. > José Fonseca --- 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
[Dri-devel] R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied
Hi people, Help me please getting DRI to work. I've installed latest (rage128-20021008-linux.i386.tar.bz2) versions of DRI. Function drmSetBusid requires some kind of permission, which I can't understand. Launching X from root gives the same results. Please, help ! Some info and logs: Kernel 2.4.19 - lsmod - Module Size Used by r128 88132 0 agpgart31840 1 ---ls -l /dev/dri/--- crw-rw-rw-1 root root 226, 0 ïËÔ 7 17:14 card0 ---XF86Config-4 Section "DRI" Mode0666 EndSection XFree86.0.log--- XFree86 Version 4.2.0 / X Window System . (--) PCI:*(2:0:0) ATI Rage 128 Pro PF rev 0, Mem @ 0xf000/26, 0xff9fc000/14, I/O @ 0xd800/8, BIOS @ 0xff9c/17 ... (==) R128(0): Write-combining range (0xf000,0x200) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. --- 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
