Re: Debugging the Radeon 200M command processor (CP)
Which would exactly fit between 0xCFFE - 0xCFFF. Yes this is an assumption, but some of the DRI code mentions that PCI express allocates the GART table at the end of the frame buffer, so that is why I was thinking it worked this way. Can you dump that memory area? see if it has a GART table in it.. GART tables usually are fairly easy to spot lots of page pointers.. Ok.. I read that file. None of them seem to touch the card directly.. The only bits that I found which actually touch the card are in radeon_cp.c (at least the older git checkout that I have...) ati_pcigart.c just creates the tables, the registers to poke are differrent depending on the type of gart.. When you say that the card reacts, are you referring to tickling these registers: RADEON_AIC_CNTL, RADEON_AIC_PT_BASE, RADEON_AIC_LO_ADDR, RADEON_AIC_HI_ADDR? (none of my fglrx traces (libsegfault or kmmio) touch these registers...) Yeah I just tried to see if a PCI GART worked, I didn't care if fglrx used it or not,... there is probably something else necessary outside the normal setup regs to get it to work I gave it up on it when it didn't work out of the box.. Dave. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
(Unrelated) X.Org lockup resolved, radeonfb vs. vesa vga (was: Re: Kernel panic with Mobility M300 (TP43p) and DRI/Mesa/EGL demo)
Am Dienstag, den 20.02.2007, 20:10 +0100 schrieb Christian Neumair: Did you card work flawlessly with dri enabled under xorg ? No, it doesn't. The screen turns black, the computer itself does not seem to lock up, but according to the Xorg log (attached, gzipp'd) everything seems to go fine. My messages log has: Feb 20 19:39:31 localhost kernel: [17179959.672000] [drm] Used old pci detect: framebuffer loaded Feb 20 19:39:54 localhost kernel: [17179982.14] mtrr: 0xc000,0x800 overlaps existing 0xc000,0x400 (2 or 3 times) Feb 20 19:40:22 localhost kernel: [17180009.848000] 3[drm:drm_release] *ERROR* Device busy: 1 0 (this is in the log every 20 seconds) But maybe this is an expected result if I bring up the whole system at runtime? I run vesafb, modprobe drm and radeon and then just bring up the X server. Do these FBs interfere somehow? I didn't run vesafb, I actually ran radeonfb. The locking doesn't happen and X.Org can be launched fine when just using vesa (by appending video=vesa to the kernel line). I'm just dropping these lines to make it simpler for people desperately grepping mail archives to get their locked X.Org server (possibly on Ubuntu/Edgy) to run. I suppose this is really an unrelated readeonfb issue, the EGL/dri driver still doesn't work though. I'll further investigate it. -- Christian Neumair [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel panic with Mobility M300 (TP43p) and DRI/Mesa/EGL demo
On Tue, 2007-02-20 at 20:10 +0100, Christian Neumair wrote: Did you card work flawlessly with dri enabled under xorg ? No, it doesn't. You should probably fix that before worrying about EGL. But maybe this is an expected result if I bring up the whole system at runtime? I run vesafb, modprobe drm and radeon and then just bring up the X server. Do these FBs interfere somehow? They shouldn't, and they don't in my experience. YMMV though, so it can't hurt to try differently. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: bug in intelfbhw.c
On Wed, 2007-02-21 at 17:10 +0100, Orczykowski, Juergen wrote: Hello, we would like to use your drivers in our software. While debugging we found a bug in calculating the ring_space. This is for the Linux kernel frame buffer driver, not the DRI drivers. You should post this to the [EMAIL PROTECTED] alias as documented in the MAINTAINERS file in the Linux kernel source. If there is less then RING_MIN_FREE available in the ring buffer, dinfo-ring_space is set to a big value forcing wait_ring to return. We have attached a possible solution to solve this bug. intelfbhw.c Also note that changes should be supplied as a patch diff from the original file, not the complete file itself otherwise the changes can't be easily reviewed. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
No more Bug mails on the list?
I was wondering what happened to the bug-mails assigned to this list, there haven't been any for the last two weeks. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Hi guys. On Wed, 2007-02-21 at 08:51 +, Dave Airlie wrote: Which would exactly fit between 0xCFFE - 0xCFFF. Yes this is an assumption, but some of the DRI code mentions that PCI express allocates the GART table at the end of the frame buffer, so that is why I was thinking it worked this way. Can you dump that memory area? see if it has a GART table in it.. GART tables usually are fairly easy to spot lots of page pointers.. Ok.. I read that file. None of them seem to touch the card directly.. The only bits that I found which actually touch the card are in radeon_cp.c (at least the older git checkout that I have...) ati_pcigart.c just creates the tables, the registers to poke are differrent depending on the type of gart.. When you say that the card reacts, are you referring to tickling these registers: RADEON_AIC_CNTL, RADEON_AIC_PT_BASE, RADEON_AIC_LO_ADDR, RADEON_AIC_HI_ADDR? (none of my fglrx traces (libsegfault or kmmio) touch these registers...) Yeah I just tried to see if a PCI GART worked, I didn't care if fglrx used it or not,... there is probably something else necessary outside the normal setup regs to get it to work I gave it up on it when it didn't work out of the box.. Dave. I was wondering this morning, could it potentially help to dump the contents of the memory that fglrx allocates when the driver is suspended? I have a 200M as well (same 32MB config as you, Dave), and so could see what I got if it would have a hope of being helpful. Regards, Nigel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: No more Bug mails on the list?
On Wed, 2007-02-21 at 20:41 +0100, Rune Petersen wrote: I was wondering what happened to the bug-mails assigned to this list, there haven't been any for the last two weeks. I've been wondering about that as well. I suspect the mail preferences for this list as well as mesa3d-dev may have changed accidentally on the recent Bugzilla upgrade. Any ideas, Kristian? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
