Re: [PATCH] radeon_cp: use request_firmware
Krzysztof Halasa wrote: Ben Hutchings b...@decadent.org.uk writes: I don't copy Signed-off-by if I make significant changes as the original author should not be held responsible for any errors. I'll be happy to ask for your S-o-b before submitting a patch based on your work in future. I think we should never include the original SOB if there was _any_ change. SOB is not credits, it's a signature. If someone takes my patch and changes it, I want my SOB line removed unless I re-sign the modified patch. We may invent some other Based-on-patch-by: etc. tag if really necessary, but the signature is a different thing. Given that this is the 2nd or 3rd instance of someone feeling that their code has been used without credit, that may be a good idea. I certainly can see the point, having had a significant effort of mine lightly patched and then given to FSF without my name on it. -- Bill Davidsen david...@tmr.com We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 driver problem
Adam Jackson wrote: On Tuesday 14 December 2004 19:03, Bill Shannon wrote: It's been over a month since I sent this message and I've yet to receive a single response. If you're ignoring me on purpose, would someone please say so? If I'm asking the wrong people, again I'd appreciate a pointer to the right people. You're asking the right people, we're just not always perfect about responding to every message. This sounds exactly like: https://bugs.freedesktop.org/show_bug.cgi?id=1886 which is fixed in Xorg CVS, and slated for inclusion in the upcoming 6.8.2 maintenance release. - ajax Thanks much for the pointer! I tried the workaround suggested in one of the referenced bug reports (comment out load dri in xorg.conf) and that solved the problem. I'll update all the bugs I filed in other places to point to the bug above. Thanks again! Bill --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 driver problem
It's been over a month since I sent this message and I've yet to receive a single response. If you're ignoring me on purpose, would someone please say so? If I'm asking the wrong people, again I'd appreciate a pointer to the right people. If you've just never gotten back to my message to consider it, maybe now would be a good time to do so? Thanks much. Bill Shannon Bill Shannon wrote: I sent this once but I don't see it in the archives so here it is again without the attachments. Summary: my ATI Rage 128 Pro Ultra continues to generate vertical blanking interrupts after the driver is closed and the interrupt handler is removed. Can someone help? Thanks. Bill Shannon Bill Shannon wrote: Someone on [EMAIL PROTECTED] suggested that this list was probably the right list to sent this plea for help... Original Message Subject: r128 driver problem Date: Thu, 04 Nov 2004 20:34:06 -0800 From: Bill Shannon [EMAIL PROTECTED] To: [EMAIL PROTECTED] I'm looking for someone to help me with a problem I'm having with the r128 driver. See attached messages for a description of the problem. I think I've proven that the problem is related to the driver/device, but I don't know enough about the device and how it works to fix the problem myself. Any help would be much appreciated. Thanks! Bill Shannon Subject: r128 driver problems From: Bill Shannon [EMAIL PROTECTED] Date: Wed, 27 Oct 2004 17:46:56 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi guys. I got your names from r128_irq.c. I'm hoping you can help me or point me in the right direction. I upgraded my Dell 4550 from Fedora Core 1 to Fedora Core 2 and I'm having problems that I reported here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132930 I've been trying to debug this myself and so far it looks like as soon as the r128 driver is closed, I get a flood of interrupts that aren't handled, eventually causing the kernel to disable IRQ 11. My theory is that these are VBLANK interrupts from the video card that are no longer handled because the r128 interrupt handler has been removed from the IRQ handler list. It's pretty clear that the driver is attempting to disable such interrupts before removing the driver from the list. I don't know anything about how this device works so I can't say whether or not it's doing that correctly. I've tried hacking the IRQ handler to call back into the r128 driver when it finds that the IRQ hasn't been handled by any of the drivers on the list, so that the r128 driver can determine if it was the cause of the interrupt after all. Unfortunately, I don't understand enough about how devices work in Linux (or on x86 hardware) and I can't seem to get this to work. As soon as I try to touch the device the kernel hangs. I noticed that in FC1 the r128 driver didn't appear to use interrupts. That seems to be a capability added in the 2.6 kernel, in the r128_irq.c file that has your names in it! :-) So that would explain why FC1 works fine on the same hardware. Oh, and I've tried all the frequently recommended tips like booting with pci=noacpi and acpi=off. They don't make any difference. Anyway, I was hoping that one of you might have some idea of what the problem might be or what I could do to further debug the problem. Oh yes, the video card is an ATI Rage 128 Pro Ultra. Thanks for any help you might offer! Bill Shannon Subject: Re: r128 driver problems From: Bill Shannon [EMAIL PROTECTED] Date: Wed, 27 Oct 2004 23:12:09 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Ok, I think I've now proven that my ATI Rage 128 device is generating interrupts even after the r128 driver disables interrupts. In r128_driver_irq_uninstall, after it writes to the device to disable interrupts, I set a global variable that says interrupts are disabled. I then use vblank_wait to wait for the next vblank interrupt. If interrupts were really disabled, I would expect vblank_wait to return indicating that the timeout expired. It doesn't, it returns success. In r128_dma_service, if I get an interrupt while the global interrupts are disabled flag is set, I increment a counter. After vblank_wait returns in r128_driver_irq_uninstall, I check the count. It indicates that an interrupt was received after interrupts were disabled. To me, that looks like proof that there's something wrong here. Maybe the hardware is broken, or maybe it's just not working the way the driver expects. Or maybe the driver is not doing the right thing to really disable interrupts. At this point I need some help. Are either of you the right person to help? If not, can you point me to someone else who might be able to help? Thanks much! Bill Shannon
r128 driver problem
I sent this once but I don't see it in the archives so here it is again without the attachments. Summary: my ATI Rage 128 Pro Ultra continues to generate vertical blanking interrupts after the driver is closed and the interrupt handler is removed. Can someone help? Thanks. Bill Shannon Bill Shannon wrote: Someone on [EMAIL PROTECTED] suggested that this list was probably the right list to sent this plea for help... Original Message Subject: r128 driver problem Date: Thu, 04 Nov 2004 20:34:06 -0800 From: Bill Shannon [EMAIL PROTECTED] To: [EMAIL PROTECTED] I'm looking for someone to help me with a problem I'm having with the r128 driver. See attached messages for a description of the problem. I think I've proven that the problem is related to the driver/device, but I don't know enough about the device and how it works to fix the problem myself. Any help would be much appreciated. Thanks! Bill Shannon Subject: r128 driver problems From: Bill Shannon [EMAIL PROTECTED] Date: Wed, 27 Oct 2004 17:46:56 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi guys. I got your names from r128_irq.c. I'm hoping you can help me or point me in the right direction. I upgraded my Dell 4550 from Fedora Core 1 to Fedora Core 2 and I'm having problems that I reported here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132930 I've been trying to debug this myself and so far it looks like as soon as the r128 driver is closed, I get a flood of interrupts that aren't handled, eventually causing the kernel to disable IRQ 11. My theory is that these are VBLANK interrupts from the video card that are no longer handled because the r128 interrupt handler has been removed from the IRQ handler list. It's pretty clear that the driver is attempting to disable such interrupts before removing the driver from the list. I don't know anything about how this device works so I can't say whether or not it's doing that correctly. I've tried hacking the IRQ handler to call back into the r128 driver when it finds that the IRQ hasn't been handled by any of the drivers on the list, so that the r128 driver can determine if it was the cause of the interrupt after all. Unfortunately, I don't understand enough about how devices work in Linux (or on x86 hardware) and I can't seem to get this to work. As soon as I try to touch the device the kernel hangs. I noticed that in FC1 the r128 driver didn't appear to use interrupts. That seems to be a capability added in the 2.6 kernel, in the r128_irq.c file that has your names in it! :-) So that would explain why FC1 works fine on the same hardware. Oh, and I've tried all the frequently recommended tips like booting with pci=noacpi and acpi=off. They don't make any difference. Anyway, I was hoping that one of you might have some idea of what the problem might be or what I could do to further debug the problem. Oh yes, the video card is an ATI Rage 128 Pro Ultra. Thanks for any help you might offer! Bill Shannon Subject: Re: r128 driver problems From: Bill Shannon [EMAIL PROTECTED] Date: Wed, 27 Oct 2004 23:12:09 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Ok, I think I've now proven that my ATI Rage 128 device is generating interrupts even after the r128 driver disables interrupts. In r128_driver_irq_uninstall, after it writes to the device to disable interrupts, I set a global variable that says interrupts are disabled. I then use vblank_wait to wait for the next vblank interrupt. If interrupts were really disabled, I would expect vblank_wait to return indicating that the timeout expired. It doesn't, it returns success. In r128_dma_service, if I get an interrupt while the global interrupts are disabled flag is set, I increment a counter. After vblank_wait returns in r128_driver_irq_uninstall, I check the count. It indicates that an interrupt was received after interrupts were disabled. To me, that looks like proof that there's something wrong here. Maybe the hardware is broken, or maybe it's just not working the way the driver expects. Or maybe the driver is not doing the right thing to really disable interrupts. At this point I need some help. Are either of you the right person to help? If not, can you point me to someone else who might be able to help? Thanks much! Bill Shannon --- 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=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
3D not working after software suspend/resume
after a software suspend/resume cycle, running glxgears emits the following error msgs and quits: libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 intelWaitIrq: drmI830IrqWait: -16 The kernel also logged the following message: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 972815 emitted: 972834 I'm running Xorg 6.8.1 with i915-20041008 snapshot. My video card is an Intel 855GM, below is the lspci -v output # lspci -v 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Flags: bus master, fast devsel, latency 0 Memory at unassigned (32-bit, prefetchable) Capabilities: [40] #09 [a105] 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at b000 (32-bit, prefetchable) [size=128M] Memory at f000 (32-bit, non-prefetchable) [size=512K] I/O ports at e000 [size=8] Capabilities: [d0] Power Management version 1 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: fast devsel Memory at 2000 (32-bit, prefetchable) [disabled] [size=128M] Memory at 1e00 (32-bit, non-prefetchable) [disabled] [size=512K] Capabilities: [d0] Power Management version 1 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 1200 [size=32] 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1700 [size=32] 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at f008 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [2080] 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 83) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: c000-dfff Memory behind bridge: e000-efff Prefetchable memory behind bridge: a000-afff 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at 1100 [size=16] Memory at 1e08 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 03) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: medium devsel, IRQ 6 I/O ports at 1400 [size=32] 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio Controller (rev 03) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at e100 [size=256] I/O ports at e200 [size=64] Memory at f0080400 (32-bit, non-prefetchable) [size=512] Memory at f0080600 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 03) (prog-if 00 [Generic]) Subsystem: Toshiba America Info Systems: Unknown device 0001 Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at e300 [size=256] I/O ports at e400 [size=128]
Re: Merging DRM and fbdev
Jon Smirl wrote: On Sun, 3 Oct 2004 11:38:39 -0700 (PDT), Mike Mestnik [EMAIL PROTECTED] wrote: What about moving the DRM and FB specific code into there own per card libs? radeon - attached to hardware radeon-drm drm - library radeon-fb fb - library fbcon - library Fell free to convert the merged radeon driver in to a driver plus two libs if you want. I'll accept the patch back. You'll need to wait until I get the merged driver working. What I don't want is two independent implementations of the hardware initialization code like we currently have. The point of merging is to make sure that a single logical driver programs the hardware is a consistent way. We spend so much time talking about splitting the radeon driver into pieces. But I don't hear anyone saying I can't ship my product because the radeon driver is 120K and all I can handle is 60K. I'm not going to spend a week's work breaking things up and testing them just because of some theoretical need for a non-existant embedded system. When this hypothetical embedded system shows up the people making the money off from the system can do the work. Perhaps there might be some feedback from the embedded folks and/or those who decide if these changes are what they want to go in the kernel. If you're going to do something like this, one of the embedded vendors might want to contribute to development. Clearly smaller software parts have advantages, if resources were available to do it split as part of the modification. That would probably reduce the maintenence effort in the future as well. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops when loading i830 module
Dave Airlie wrote: again please, found another error in the logic, this is like programming by numbers!!! thanks be to God you found these issues before I submitted this for the kernel :-) Still can't unload it. It seems the problem is that the kernel thought the driver is in use, and did not even call the clean-up code. The debug msg follows: [drm] Debug messages ON [drm:drm_probe] [drm:i830_stub_register] [drm:i830_stub_register] calling inter_module_register [drm:i830_stub_getminor] info count increased 1 [drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82852/855GM Integrated Graphics Device [drm:drm_probe] [drm:i830_stub_register] [drm:i830_stub_register] already registered 1 [drm:i830_stub_getminor] info count increased 2 [drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm] Initialized i830 1.3.2 20021108 on minor 1: Intel Corp. 82852/855GM Integrated Graphics Device (#2) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops when loading i830 module
Dave Airlie wrote: The module couldn't be unloaded. I tried to unload it right after loading, rmmod complains i830: Device or resource busy. lsmod shows: Module Size Used byTainted: PF i830 66620 1 jeez this is annoying me :-), there was a bug with my ++ and -- for the pointers so I've fixed that try again please.. (if it doesn't work throw a drm_opts=debug on it again, as I've added further debugging...).. Thanks for this again, Dave. Still the same. This is the debug msg: [drm] Debug messages ON [drm:drm_probe] [drm:i830_stub_register] [drm:i830_stub_register] calling inter_module_register [drm:i830_stub_getminor] info count increased 1 [drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82852/855GM Integrated Graphics Device [drm:drm_probe] [drm:i830_stub_register] [drm:i830_stub_register] already registered 1 [drm:i830_stub_getminor] info count increased 2 [drm:i830_stub_register] info_register failed [drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm] Initialized i830 1.3.2 20021108 on minor 1: Intel Corp. 82852/855GM Integrated Graphics Device (#2) Bill --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops when loading i830 module
Dave Airlie wrote: Okay my final attempt :-) is now checked in... the last issue that register_chrdev returns a 0 when the fops is the same caused your last problem.. hopefully this work.. if you can load/unload this module and see if it works... then I'll add the couple of lines to hopefully avoid using the second device.. The module couldn't be unloaded. I tried to unload it right after loading, rmmod complains i830: Device or resource busy. lsmod shows: Module Size Used byTainted: PF i830 66620 1 Bill --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops when loading i830 module
Dave Airlie wrote: First I built the i830 module from 2.4.24. Then I tried to unload the current module which was built from dri cvs, the kernel gave me an oops. See attachment for the decoded oops. okay there is something wrong with the unload but I can't see it straight away, can you insmod the i830 from the snapshot with drm_opts=debug and then rmmod it and send me the dmesg output I'd like to track that one down... I'll then make the fix I think is needed to stop the second head getting detected... I'll do that later and come back to you. It may also me the DDX that needs upgrading a lot of changes have been made to Xorg i810 DDX and I may need to fold them back into the DRI tree.. Next, I started X. The Xorg.0.log shows dri was enabled, but glxinfo gives me the following error msg: name of display: :0.0 glxinfo: xmlconfig.c:102: findOption: Assertion `i size' failed. Aborted This is wierd alright.. no matter what happens you shouldn't see it .. can you send me on the X startup log for this, The Xorg.0.log was attached in my previous mail. I noticed the following interesting part in the log: (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_clip.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_norm.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_xform.o: No symbols found Bill --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops when loading i830 module
Dave Airlie wrote:
okay there is something wrong with the unload but I can't see it straight
away, can you insmod the i830 from the snapshot with drm_opts=debug and
then rmmod it and send me the dmesg output I'd like to track that one
down... I'll then make the fix I think is needed to stop the second head
getting detected...
Here's the dmesg output:
...
[drm] Debug messages ON
[drm:drm_probe]
[drm:i830_stub_register]
[drm:i830_stub_register] calling inter_module_register
[drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0
[drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82852/855GM Integrated
Graphics Device
[drm:drm_probe]
[drm:i830_stub_register]
PCI: Enabling device 00:02.1 ( - 0002)
[drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0
[drm] Initialized i830 1.3.2 20021108 on minor 1: Intel Corp. 82852/855GM Integrated
Graphics Device (#2)
[drm:drm_cleanup]
[drm:i830_takedown]
[drm:i830_stub_unregister] 0
inter_module_unregister: no entry for 'drm'kernel BUG at module.c:158!
invalid operand:
CPU:0
EIP:0010:[c0118f7b]Tainted: PF
EFLAGS: 00010282
eax: 002e ebx: ddeef5c0 ecx: dcfe2000 edx: dcfe3f64
esi: c03069d7 edi: dec962d0 ebp: bfffe628 esp: d4d53f20
ds: 0018 es: 0018 ss: 0018
Process rmmod.old (pid: 1540, stackpage=d4d53000)
Stack: c02e2ae0 dec962cc dec97a80 dec9031c dec962cc d8c0de00
d8c0de80 dec90538 dec96301 dec97c20 dec8c910
dec95fa4 0206 c155d800 c025d418 dec97c20 dec89000 fff0
Call Trace:[dec962cc] [dec97a80] [dec9031c] [dec962cc] [dec90538]
[dec96301] [dec97c20] [dec8c910] [dec95fa4] [c025d418] [dec97c20]
[dec8ca70] [dec97a80] [c011a66a] [c01199e7] [c01079bf]
Code: 0f 0b 9e 00 46 84 2e c0 eb df 8b 41 04 89 43 04 89 18 c7 41
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops when loading i830 module
Dave Airlie wrote: I've checked in a fix for this load/unload it probably won't help your main situation yet but I'd appreciate if you could check it the module load and unload, if that works I'll try and fix your specific problem or at least rule out the DRM. oops again, seems this time at a different place. [drm] Debug messages ON [drm:drm_probe] [drm:i830_stub_register] [drm:i830_stub_register] calling inter_module_register [drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82852/855GM Integrated Graphics Device [drm:drm_probe] [drm:i830_stub_register] PCI: Enabling device 00:02.1 ( - 0002) [drm:i830_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm] Initialized i830 1.3.2 20021108 on minor 1: Intel Corp. 82852/855GM Integrated Graphics Device (#2) [drm:drm_exit] [drm:drm_cleanup] [drm:i830_takedown] [drm:i830_stub_unregister] 0 inter_module_put: no entry for 'drm'kernel BUG at module.c:230! invalid operand: CPU:0 EIP:0010:[c01190ba]Tainted: PFZ EFLAGS: 00010282 eax: 0027 ebx: ddeef5c0 ecx: dcfde000 edx: dcfdff64 esi: c03069d7 edi: dec962f9 ebp: bfffe668 esp: d57b5f20 ds: 0018 es: 0018 ss: 0018 Process rmmod.old (pid: 2884, stackpage=d57b5000) Stack: c02e2b20 dec962f5 dec97ac0 dec9031f dec962f5 d7cbb580 d7cbb100 dec90558 dec9632a dec97c60 dec8c910 dec95fc4 c0328198 c155d800 c025d418 dec97c60 dec95fea fff0 dec8ca73 Call Trace:[dec962f5] [dec97ac0] [dec9031f] [dec962f5] [dec90558] [dec9632a] [dec97c60] [dec8c910] [dec95fc4] [c025d418] [dec97c60] [dec95fea] [dec8ca73] [dec97ac0] [dec95fea] [c011a66a] [c01199e7] [c01079bf] Code: 0f 0b e6 00 46 84 2e c0 83 c4 08 5b 5e 5f c3 8b 41 0c 85 c0 --- Decode the oops: ksymoops 2.4.9 on i686 2.4.24-1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.24-1/ (default) -m /usr/src/linux-2.4.24-1/System.map (specified) Warning (compare_ksyms_lsmod): module i830 is in lsmod but not in ksyms, probably no symbols exported [drm] Debug messages ON inter_module_put: no entry for 'drm'kernel BUG at module.c:230! invalid operand: CPU:0 EIP:0010:[c01190ba]Tainted: PFZ Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 0027 ebx: ddeef5c0 ecx: dcfde000 edx: dcfdff64 esi: c03069d7 edi: dec962f9 ebp: bfffe668 esp: d57b5f20 ds: 0018 es: 0018 ss: 0018 Process rmmod.old (pid: 2884, stackpage=d57b5000) Stack: c02e2b20 dec962f5 dec97ac0 dec9031f dec962f5 d7cbb580 d7cbb100 dec90558 dec9632a dec97c60 dec8c910 dec95fc4 c0328198 c155d800 c025d418 dec97c60 dec95fea fff0 dec8ca73 Call Trace:[dec962f5] [dec97ac0] [dec9031f] [dec962f5] [dec90558] [dec9632a] [dec97c60] [dec8c910] [dec95fc4] [c025d418] [dec97c60] [dec95fea] [dec8ca73] [dec97ac0] [dec95fea] [c011a66a] [c01199e7] [c01079bf] Code: 0f 0b e6 00 46 84 2e c0 83 c4 08 5b 5e 5f c3 8b 41 0c 85 c0 EIP; c01190ba inter_module_put+5a/80 = ebx; ddeef5c0 _end+1db2d2a8/1e81fd48 ecx; dcfde000 _end+1cc1bce8/1e81fd48 edx; dcfdff64 _end+1cc1dc4c/1e81fd48 esi; c03069d7 bl_order+28fcb/3abb4 edi; dec962f9 [vmnet].data.end+150ea/449e51 esp; d57b5f20 _end+153f3c08/1e81fd48 Trace; dec962f5 [vmnet].data.end+150e6/449e51 Trace; dec97ac0 [vmnet].data.end+168b1/449e51 Trace; dec9031f [vmnet].data.end+f110/449e51 Trace; dec962f5 [vmnet].data.end+150e6/449e51 Trace; dec90558 [vmnet].data.end+f349/449e51 Trace; dec9632a [vmnet].data.end+1511b/449e51 Trace; dec97c60 [vmnet].data.end+16a51/449e51 Trace; dec8c910 [vmnet].data.end+b701/449e51 Trace; dec95fc4 [vmnet].data.end+14db5/449e51 Trace; c025d418 pci_unregister_driver+58/60 Trace; dec97c60 [vmnet].data.end+16a51/449e51 Trace; dec95fea [vmnet].data.end+14ddb/449e51 Trace; dec8ca73 [vmnet].data.end+b864/449e51 Trace; dec97ac0 [vmnet].data.end+168b1/449e51 Trace; dec95fea [vmnet].data.end+14ddb/449e51 Trace; c011a66a free_module+ba/d0 Trace; c01199e7 sys_delete_module+a7/1d0 Trace; c01079bf system_call+33/38 Code; c01190ba inter_module_put+5a/80 _EIP: Code; c01190ba inter_module_put+5a/80 = 0: 0f 0b ud2a = Code; c01190bc inter_module_put+5c/80 2: e6 00 out%al,$0x0 Code; c01190be inter_module_put+5e/80 4: 46inc%esi Code; c01190bf inter_module_put+5f/80 5: 84 2e test %ch,(%esi) Code; c01190c1 inter_module_put+61/80 7: c0 83 c4 08 5b 5e 5f rolb $0x5f,0x5e5b08c4(%ebx) Code; c01190c8 inter_module_put+68/80 e: c3ret Code; c01190c9 inter_module_put+69/80 f: 8b 41 0c mov0xc(%ecx),%eax Code; c01190cc
Re: Kernel oops when loading i830 module
Dave Airlie wrote: On Thu, 8 Jul 2004, Bill Gou wrote: Hi there, I'm running X.org 6.7, kernel 2.4.24. Whenever I load the i830 module compiled from dri snapshot, I get a kernel oops. Below is the ksymoops and 'lspci -v'output. I can see the issue, I just have to think of a clean way to fix it ... I've checked in a probable fix (read ugly backways compat hack :-) can you check it out and test it? I have to split the 2.4 compat stuff into a separate header file at some stage soon, it is messy having it in there at the moment... Dave. Yes, I can load the module now. Here's the kernel msg: [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82852/855GM Integrated Graphics Device PCI: Enabling device 00:02.1 ( - 0002) [drm] Initialized i830 1.3.2 20021108 on minor 1: Intel Corp. 82852/855GM Integrated Graphics Device (#2) However, DRI is disable after starting X. Below is the log: Xorg.0.log -- _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/cooldog:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: Linux 2.4.26 i686 [ELF] Current Operating System: Linux cooldog 2.4.24-1 #2 Wed Mar 3 20:10:35 CST 2004 i686 Build Date: 28 April 2004 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. 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/Xorg.0.log, Time: Sun Jul 11 20:30:40 2004 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor My Monitor (**) | |--Device Intel 855GM (**) |--Input Device Mouse1 (**) |--Input Device Mouse2 (**) |--Input Device Keyboard1 (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/cyrillic/,/usr/X11R6/lib/X11/fonts/zh/,/usr/X11R6/lib/X11/fonts/gbk/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/lib/X11/fonts/TrueType/western/,/usr/X11R6/lib/X11/fonts/TrueType/zh/,/usr/X11R6/lib/X11/fonts/freefont/,/usr/X11R6/lib/X11/fonts/sharefont/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (**) Option BlankTime 5 (**) Option StandbyTime 0 (**) Option SuspendTime 0 (**) Option OffTime 10 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=X.Org Foundation compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=X.Org Foundation compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (++) using VT number 5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8000113c, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3580 card , rev 02 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 8086,3584 card 1179,ff10 rev 02 class 08,80,00 hdr 00 (II) PCI: 00:00:3: chip 8086,3585 card 1179,ff10 rev 02 class 08,80,00 hdr 80 (II) PCI: 00:02:0: chip 8086,3582 card 1179,ff10 rev 02 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,3582 card 1179,ff10 rev 02 class 03,80,00 hdr 80 (II) PCI: 00:1d:0: chip 8086,24c2 card 1179,ff10 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:2: chip 8086,24c7 card 1179,ff10 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 1179,ff10 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 83 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24cc card , rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24ca card 1179,ff10 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,24c3 card 1179,ff10 rev 03 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,24c5 card 1179,ff10 rev 03 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,24c6 card 1179,0001 rev 03 class 07,03,00 hdr 00 (II) PCI: 01:04:0: chip 8086,1043 card 8086,2581 rev 04 class
Kernel oops when loading i830 module
Hi there, I'm running X.org 6.7, kernel 2.4.24. Whenever I load the i830 module compiled from dri snapshot, I get a kernel oops. Below is the ksymoops and 'lspci -v'output. ksymoops 2.4.9 on i686 2.4.24-1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.24-1/ (default) -m /boot/System.map-2.4.24-1 (specified) inter_module_register: duplicate im_name 'drm'kernel BUG at module.c:117! invalid operand: CPU:0 EIP:0010:[c0118ecc]Tainted: PFZ Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 0031 ebx: dec9628c ecx: dcece000 edx: dcecff64 esi: dec96290 edi: dec96290 ebp: c96ceb00 esp: d8231e40 ds: 0018 es: 0018 ss: 0018 Process modprobe.old (pid: 17977, stackpage=d8231000) Stack: c02e2a00 dec9628c 0014 c96ce2c0 dec98214 0654 dec9048b dec9628c dec89000 dec97b28 dec98214 c155dc00 dec8c645 dec95f43 dec97560 dec98214 0003 0002 dec95f48 c155da1c Call Trace:[dec9628c] [dec98214] [dec9048b] [dec9628c] [dec97b28] [dec98214] [dec8c645] [dec95f43] [dec97560] [dec98214] [dec95f48] [c013fe79] [dec979b8] [dec97a20] [c025d315] [dec979b8] [dec97a20] [c025d3bc] [dec97a20] [dec8c892] [dec97a20] [c01197b8] [dec89060] [dec89060] [c01079bf] Code: 0f 0b 75 00 46 84 2e c0 8b 55 00 eb a0 89 5c 24 04 c7 04 24 EIP; c0118ecc inter_module_register+dc/110 = ebx; dec9628c [i830]__module_using_checksums+1c14/2ee8 ecx; dcece000 _end+1cb0bce8/1e822d48 edx; dcecff64 _end+1cb0dc4c/1e822d48 esi; dec96290 [i830]__module_using_checksums+1c18/2ee8 edi; dec96290 [i830]__module_using_checksums+1c18/2ee8 ebp; c96ceb00 _end+930c7e8/1e822d48 esp; d8231e40 _end+17e6fb28/1e822d48 Trace; dec9628c [i830]__module_using_checksums+1c14/2ee8 Trace; dec98214 [i830]i830_device+654/1950 Trace; dec9048b [i830]i830_stub_register+12b/180 Trace; dec9628c [i830]__module_using_checksums+1c14/2ee8 Trace; dec97b28 [i830]i830_stub_info+0/18 Trace; dec98214 [i830]i830_device+654/1950 Trace; dec8c645 [i830]drm_probe+c5/240 Trace; dec95f43 [i830]__module_using_checksums+18cb/2ee8 Trace; dec97560 [i830]i830_fops+0/0 Trace; dec98214 [i830]i830_device+654/1950 Trace; dec95f48 [i830]__module_using_checksums+18d0/2ee8 Trace; c013fe79 alloc_area_pte+a9/b0 Trace; dec979b8 [i830]i830_pciidlist+38/a0 Trace; dec97a20 [i830]drm_driver+0/40 Trace; c025d315 pci_announce_device+35/80 Trace; dec979b8 [i830]i830_pciidlist+38/a0 Trace; dec97a20 [i830]drm_driver+0/40 Trace; c025d3bc pci_register_driver+5c/60 Trace; dec97a20 [i830]drm_driver+0/40 Trace; dec8c892 [i830]drm_init+b2/f0 Trace; dec97a20 [i830]drm_driver+0/40 Trace; c01197b8 sys_init_module+538/690 Trace; dec89060 [i830]i830_agp_info+0/0 Trace; dec89060 [i830]i830_agp_info+0/0 Trace; c01079bf system_call+33/38 Code; c0118ecc inter_module_register+dc/110 _EIP: Code; c0118ecc inter_module_register+dc/110 = 0: 0f 0b ud2a = Code; c0118ece inter_module_register+de/110 2: 75 00 jne4 _EIP+0x4 Code; c0118ed0 inter_module_register+e0/110 4: 46inc%esi Code; c0118ed1 inter_module_register+e1/110 5: 84 2e test %ch,(%esi) Code; c0118ed3 inter_module_register+e3/110 7: c0 8b 55 00 eb a0 89 rorb $0x89,0xa0eb0055(%ebx) Code; c0118eda inter_module_register+ea/110 e: 5cpop%esp Code; c0118edb inter_module_register+eb/110 f: 24 04 and$0x4,%al Code; c0118edd inter_module_register+ed/110 11: c7 04 24 00 00 00 00 movl $0x0,(%esp) lscpi -v 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Flags: bus master, fast devsel, latency 0 Memory at unassigned (32-bit, prefetchable) Capabilities: [40] #09 [a105] 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at b000 (32-bit, prefetchable) [size=128M] Memory at f000 (32-bit, non-prefetchable) [size=512K] I/O ports at e000 [size=8] Capabilities: [d0] Power Management version 1 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10
Re: [Dri-devel] Re: Finally looking at the DRI SMP issues - Yahooo! (fps 30-31 fps up)!
On Fri, Apr 16, 2004 at 11:35:14AM -0700, Ian Romanick wrote: The r200 is the clear bottleneck, now What we need next is the TMU3 patch...;-) I'm still trying to work through the t_vertex conversion. That should help some too. Of course, Quake3 only uses 2 TMUs anyway. I'll post what I have for the t_vertex conversion (working or not!) later today. Maybe someone will be able to see what I'm doing wrong... QuakeForge uses 3 tmus for map rendering (wall textures + lightmap + fullbrights) if available. Bill -- Leave others their otherness. -- Aratak --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal
On Thu, Feb 21, 2002 at 04:53:04AM +, Keith Whitwell wrote: That sounds like a bug in the quake physics model - some silly feedback between the integration time step and the display subsystem... I'm suprised... I can only speak about the quake 1/quakeworld source (I haven't studied the quake2 code enough yet), but it's actually nothing that complex. In fact, it's the opposit. quake doesn't do the integeration properly at all. It just adds the gravity acceleration to the velocity then the velocity to the location. I'm not sure if t squared shows up in the physics code or not (it looks like it does, but indirectly), but the 1/2 for the 1/2at**2 doesn't. Basicly, a projectile (player, grenade) has a piece-wise linear trajectory that doesn't touch the correct parabola except at the start point. Quake: the universe where G depends on how fast you can blink your eyes. Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] chown /dev/dri/card0, system crashes
On Tue, Jan 29, 2002 at 04:46:32PM -0800, Jim Carter wrote: However, when the current user did not have permission to write on card0 (due to mode 0660 group video, the default provided by SuSE SaX2) Wouldn't it be better to add the user to group video? Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI on mach64
From: Manuel Teira [EMAIL PROTECTED] But, are you able to play Quake3 decently at 1024x768 with your mach64? That's what I wanted to mean, perhaps it's too work for our little rage. The Utah-GLX drivers made Quake III Arena *just* playable on Mach64, with an 8MB Rage Pro ... I've been meaning to try out the DRI-based driver, but the card is at work. -- Manuel Teira -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include stddiscl.h ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Compiling Glide for a Voodoo 3
From: Nick Hudson [EMAIL PROTECTED] References: [EMAIL PROTECTED] Greetings, Ok ive compiled Glide many times with very few problems but this I have never seen and maybe someone can give me some help on it. This is what I get when I run ./chores.3dfx --clean --generate: nhudson@nhudson:~/glide-cvs/glide3x$ ./chores.3dfx --clean --generate Removing detritus...Done Regenerating everything...Aclocal...Automake...automake: configure.in: required file `./depcomp' not found automake: cvg/glide3/src/makefile.autoconf.am: Assembler source seen but `ASFLAGS' not defined in `configure.in' automake: h3/glide3/src/makefile.autoconf.am: Assembler source seen but `ASFLAGS' not defined in `configure.in' automake: h5/glide3/src/makefile.autoconf.am: Assembler source seen but `ASFLAGS' not defined in `configure.in' Failed!! IIRC, I fixed this by downgrading either automake or autoconf, or it may have been both. It was a while ago, so I'm a little hazy on detail. Certainly there have been a lot of changes in automake particularly, which also break building a lot of GNOME packages, until the packages in question get upgraded to support it. -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include stddiscl.h ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] undefined symbols in mesa-4-0-branch
On Fri, Dec 21, 2001 at 09:40:29AM +, Keith Whitwell wrote: Bill Currie wrote: This patch fixes undefined symbol errors for _compat_FogCoordfEXT (and likely _compat_SecondaryColor3ubEXT and _compat_SecondaryColor3fEXT but I didn't bother checking to see if they caused problems). They are defined in api_compat.c. You probably need to do a make Makefiles from lib/GL and recompile. Hmm, probably should have done that make world after all :/ (yes, api_compat.c was not getting compiled at all). Still, thanks. Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4 untextured poly bug in mga
On Thu, Dec 20, 2001 at 09:50:54AM +, Keith Whitwell wrote: Bill Currie wrote: this is for mesa-4-0-branch, current cvs + mga agp texturing patch (minus the bits for mgavb.c: they didn't apply). http://taniwha.2y.net/~bill/qf011.png shows the bug nicely. The black to white gradient areas should be solid black (they are in trunk). It looks like clipped corners are having their color set to white rather than the specified color. Other than this and some issues with texture sub-image updates (I'm going to investigate if it's related to the agp patch), I am /very/ impressed with what I have so far seen of the mesa-4-0-branch: I got a 4% speed increas on one of our benchmarks (only tested one so far), and that was having to drop back to full texture updates. Great work, and thanks: my g200 is doing nicely:) I've located the problem for mga cards committed a fix. Unfortunately this isn't the same problem as on the tdfx - I'll keep looking for that one. Great, thanks! Now I've just got to sort out the glTextureSubImage2D problem (I need to sort out if it's base dri or the agp patch). Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] undefined symbols in mesa-4-0-branch
This patch fixes undefined symbol errors for _compat_FogCoordfEXT (and likely _compat_SecondaryColor3ubEXT and _compat_SecondaryColor3fEXT but I didn't bother checking to see if they caused problems). Index: extras/Mesa/src/api_loopback.c === RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/Attic/api_loopback.c,v retrieving revision 1.1.6.2 diff -u -r1.1.6.2 api_loopback.c --- extras/Mesa/src/api_loopback.c 2001/12/20 10:29:11 1.1.6.2 +++ extras/Mesa/src/api_loopback.c 2001/12/21 03:28:50 @@ -66,9 +66,9 @@ -#define FOGCOORDF(x)_compat_FogCoordfEXT(x) -#define SECONDARYCOLORUB(a,b,c) _compat_SecondaryColor3ubEXT(a,b,c) -#define SECONDARYCOLORF(a,b,c) _compat_SecondaryColor3fEXT(a,b,c) +#define FOGCOORDF(x)glFogCoordfEXT(x) +#define SECONDARYCOLORUB(a,b,c) glSecondaryColor3ubEXT(a,b,c) +#define SECONDARYCOLORF(a,b,c) glSecondaryColor3fEXT(a,b,c) static void Index: extras/Mesa/src/tnl/t_imm_dlist.c === RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/tnl/Attic/t_imm_dlist.c,v retrieving revision 1.1.6.7 diff -u -r1.1.6.7 t_imm_dlist.c --- extras/Mesa/src/tnl/t_imm_dlist.c 2001/12/20 10:29:11 1.1.6.7 +++ extras/Mesa/src/tnl/t_imm_dlist.c 2001/12/21 03:28:50 @@ -620,10 +620,10 @@ } if (flags[i] VERT_SPEC_RGB) - _compat_SecondaryColor3fvEXT( IM-SecondaryColor[i] ); + glSecondaryColor3fvEXT( IM-SecondaryColor[i] ); if (flags[i] VERT_FOG_COORD) - _compat_FogCoordfEXT( IM-FogCoord[i] ); + glFogCoordfEXT( IM-FogCoord[i] ); if (flags[i] VERT_INDEX) glIndexi( IM-Index[i] ); Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mesa 4 untextured poly bug in mga
this is for mesa-4-0-branch, current cvs + mga agp texturing patch (minus the
bits for mgavb.c: they didn't apply).
http://taniwha.2y.net/~bill/qf011.png shows the bug nicely. The black to white
gradient areas should be solid black (they are in trunk). It looks like
clipped corners are having their color set to white rather than the specified
color.
Other than this and some issues with texture sub-image updates (I'm going to
investigate if it's related to the agp patch), I am /very/ impressed with what
I have so far seen of the mesa-4-0-branch: I got a 4% speed increas on one of
our benchmarks (only tested one so far), and that was having to drop back to
full texture updates. Great work, and thanks: my g200 is doing nicely:)
this is the code that renders the black sky:
static inline void
draw_poly (glpoly_t *poly)
{
int i;
qfglBegin (GL_POLYGON);
for (i = 0; i poly-numverts; i++) {
qfglVertex3fv (poly-verts[i]);
}
qfglEnd ();
}
static void
draw_black_sky_polys (msurface_t *sky_chain)
{
msurface_t *sc = sky_chain;
qfglDisable (GL_BLEND);
qfglDisable (GL_TEXTURE_2D);
qfglColor3ubv (color_black);
while (sc) {
glpoly_t *p = sc-polys;
while (p) {
draw_poly (p);
p = p-next;
}
sc = sc-texturechain;
}
qfglEnable (GL_TEXTURE_2D);
qfglEnable (GL_BLEND);
qfglColor3ubv (color_white);
}
(from gl_sky_clip.c in quakeforge)
Bill
--
Leave others their otherness. -- Aratak
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mga (g200) agp texturing.
I've got the apg texturing patches applied to my checked out dri tree (trunk) and I was wondering if they've ever been committed to any branch of the dri cvs tree? I get the odd problem (programs using dri segfaulting at indeterminate occasions, corrupted textures, out of memory (null heap pointer)) and I would like to work from something more official (I've also hacked mine a bit to get it using the right size of memory pool). While I don't remember who created the patch, many thanks to you. It's made it possible for me to run X in my preferred resolution (1152x864) and run the gl apps more than acceptably (quakeforge and q3) on my g200. Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Dri-devel] Curious happening
From: zifnab [EMAIL PROTECTED]
I am running CVS from Tuesday and I was playing Tribes 2 with no problem.
Then I came back a few hours later and started it up again. It took quite
a while to start up (at first I thought X had crashed but then Tribes
finally started). When I started to play it was painfully slow when it
needed to render lots of stuff (slow compaired to previous performance a
couple hours previous that is). Anyway has anyone else encountered this?
Yes, the makewhatis cron job kicks off on my home machine at prime
Unreal Tournament / Quake 3 Arena time (a little after midnight :o)
That produces exactly the symptoms you describe (although Quake 3 is
actually playable for low values of playable, under that load (!))
It is worth ruling that out as a cause if this was during daylight,
though, so it can be investigated further if there is a real problem.
Glen
--
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include stddiscl
const char *addresses[] = {
[EMAIL PROTECTED], [EMAIL PROTECTED], // work
[EMAIL PROTECTED], [EMAIL PROTECTED]// home
};
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] website logos
From: Frank Worsley [EMAIL PROTECTED] Also, it doesn't have to say Direct Rendering Interace or 3D for XFree86 on it. If you can think of anything else that sounds nice then you can say that too. You can also not say anything at all! I think the only letters that really should be _somewhere_ on there are DRI. For example if you have a really cool 3D render or some other cool image that would fit with the 3D theme then you could just slap the letters DRI somewhere on there and it would also be a cool logo! I'd like to propose using an image from the gears demo and work a letter into each gear. I'm not volunteering either, I can draw easily as well as my eight- year-old daughter. -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include stddiscl.h ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon on Irongate: DRI locks up machine instantly
On Sat, May 19, 2001 at 02:10:43PM +1000, Gareth Hughes wrote: I'm currently working on some kernel-related tasks, but I can take a look into the problems you (and others) have mentioned regarding the Radeon driver early next week. Are you running it from the DRI CVS? If you're game, you might want to try the in-development mesa-3-5-branch. This is where all our focus is at the moment, and many of the GL-related problems may be fixed there already. I'm getting the lockups on my g200 as well (though I'm not sure yet if it's the code in cvs or the agp texturing patch). Does the mesa-3-5 build for mga yet? It didn't when I last tried (mga was disabled). Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] g200 texture upload problems
On Mon, Apr 16, 2001 at 11:50:13PM -0600, Bill Currie wrote: I am attempting to trunk cvs dri with my g200 but I'm running into a problem with all gl apps that use textures (the demos that don't use textures (afaict) work just fine). It seems that the texture heap is not being initialized and I haven't been able to figure out why yet. I am assuming I've done something wrong. I've done some hunting and it seems textureSize and agpTextureSize from mgaScreen (and thus from serverInfo) are being set to 0. I can understand one or the other, but why both? I assume I am doing something wrong to wind up with no texture memory (that seems to be my problem), but I have no idea what it would be. Could somebody help me with this, please? TIA Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] g200 texture upload problems
On Mon, Apr 16, 2001 at 11:50:13PM -0600, Bill Currie wrote: I am attempting to trunk cvs dri with my g200 but I'm running into a problem with all gl apps that use textures (the demos that don't use textures (afaict) work just fine). It seems that the texture heap is not being initialized and I haven't been able to figure out why yet. I am assuming I've done something wrong. I've managed to determine that the mga_dri.so module is getting 0 for textureSize and agpTextureSize, and thus I am getting no texture memory. What things should I look for as to why this is happening? TIA Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird behavior?
Gareth Hughes wrote:
Time for a coffee. Please ignore the last sentence, I don't know what
I'm talking about...
I know the feeling ... time I went home for coffee (and sleep :)
-- Gareth
While I think of it, I'd like to have a poke at the Rage Pro code
that was on one of the branches somewhere ... is there anything that
will compile that I can chew on? I have a spare AGP card I can take
home, and my work box has an AGP and a PCI variant (a GI and a GB if
I remember rightly).
If nothing else I still need to learn my way around the code ...
--
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include stddiscl
const char *addresses[] = {
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]", // work
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]"// home
};
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird behavior?
Alan Hourihane wrote:
On Thu, Apr 05, 2001 at 07:41:34PM +0100, Bill Crawford wrote:
Gareth Hughes wrote:
Time for a coffee. Please ignore the last sentence, I don't know what
I'm talking about...
I know the feeling ... time I went home for coffee (and sleep :)
Huh ? It's early.. It's only 8:00pm in the UK.
I'm still at work ... and I've been up until 2am every night this
week; mostly reading this list, (re-)compiling applications, and then
sitting hitting my browser refresh buttons on the LiveJournal site.
Alan.
--
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include stddiscl
const char *addresses[] = {
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]", // work
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]"// home
};
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
