Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, 2003-11-19 at 20:46, Dave Jones wrote:
On Wed, Nov 19, 2003 at 11:44:42AM -0800, James Jones wrote:
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
Seems wrong to me... wouldn't this return -1 if say, MAX_HAMMER_GARTS ==
1 and 1 gart was found ( nr_garts == i == 1 when the comparison is made
). It would need to be:
MAX_HAMMER_GARTS can only be 1 if CONFIG_SMP=n, so the above code
is skipped, and we fall through, and return 0.
This would also be wrong, as the test would be too late, and hammer[]
would be overflowed by the time the test is performed. This is why the
test was moved before the assignment in our patches. The way we did it
would handle the SMP and non-smp cases I believe, the code you quoted
would only work right in the uniproc case.
That's how it should be.
If we have a UP system, with UP kernel, we just return 0 after
finding the first GART
If we have a UP system with an SMP kernel, we find the first GART,
and eventually end up returning 0 after finding no further garts.
If we have an SMP system with UP kernel, we exit early after
finding the first GART. The 2nd (And above) GARTs are irrelevant
when not running in SMP.
Agreed.
If we have an SMP system with an SMP kernel, we add however many
GARTs to the table, up to a limit of MAX_HAMMER_GARTS.
It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if
there is an MAX_HAMMER_GARTS'th GART.
--
Ronny V. Vindenes [EMAIL PROTECTED]
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 11:17:17AM -0800, James Jones wrote:
diff -ruN linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c
linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c
--- linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c 2003-10-08 12:24:04.0
-0700
+++ linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c2003-10-09
04:40:44.179994208 -0700
@@ -681,7 +681,7 @@
unsigned long iommu_start;
struct pci_dev *dev;
-#ifndef CONFIG_AGP_AMD_8151
+#ifndef CONFIG_AGP_AMD64
no_agp = 1;
Already in agpgart bitkeeper tree. Waiting for Linus to pull.
Andi also sent this to Linus..
/* Makefile puts PCI initialization via subsys_initcall first. */
diff -ruN linux-2.6.0-test7/drivers/char/agp/amd64-agp.c
linux-2.6.0-test7-fixed/drivers/char/agp/amd64-agp.c
--- linux-2.6.0-test7/drivers/char/agp/amd64-agp.c 2003-10-08 12:24:17.0
-0700
+++ linux-2.6.0-test7-fixed/drivers/char/agp/amd64-agp.c 2003-10-09
04:41:44.563814472 -0700
@@ -355,12 +355,14 @@
#endif
return -1;
}
-hammers[i++] = loop_dev;
-nr_garts = i;
+
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
+
+hammers[i++] = loop_dev;
+nr_garts = i;
}
return i == 0 ? -1 : 0;
}
The current code in -bk looks like this, which should do the right thing
on SMP and UP.. Can you confirm ?
Dave
...
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
#else
/* Uniprocessor case, return after finding first bridge.
(There may be more, but in UP, we don't care). */
return 0;
#endif
}
return i == 0 ? -1 : 0;
}
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
Dave,
Similar patch to Ronny's, but also changes a config check on x86_64
arch. It struck me that this patch is still slightly wrong. It should
check the number of bridges already found before going through the
entire detection routine again shouldn't it?
-James
Dave Jones wrote:
On Fri, Oct 31, 2003 at 11:46:54AM -0800, James Jones wrote:
test8 had broken detection for this agp chipset. You have to edit a
file in the x86_64 arch directory to get it to allow more than 0
(assuming you configed for uniprocessor) bridges to be used, as it
checks a variable after incrementing rather than before. I also found
the check wasn't even getting compiled in as the CONFIG_ define had a
different name in the arch file than in amd64-agp.c, and only one of
these matched the actual config define name.
Haven't tried test9 yet, I sent a patch to dave jones after I noticed
this in test7, but I received no response.
I don't recall seeing this mail. Bounce me another copy?
Dave
diff -ruN linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c
linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c
--- linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c 2003-10-08 12:24:04.0
-0700
+++ linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c 2003-10-09
04:40:44.179994208 -0700
@@ -681,7 +681,7 @@
unsigned long iommu_start;
struct pci_dev *dev;
-#ifndef CONFIG_AGP_AMD_8151
+#ifndef CONFIG_AGP_AMD64
no_agp = 1;
#else
/* Makefile puts PCI initialization via subsys_initcall first. */
diff -ruN linux-2.6.0-test7/drivers/char/agp/amd64-agp.c
linux-2.6.0-test7-fixed/drivers/char/agp/amd64-agp.c
--- linux-2.6.0-test7/drivers/char/agp/amd64-agp.c 2003-10-08 12:24:17.0
-0700
+++ linux-2.6.0-test7-fixed/drivers/char/agp/amd64-agp.c2003-10-09
04:41:44.563814472 -0700
@@ -355,12 +355,14 @@
#endif
return -1;
}
- hammers[i++] = loop_dev;
- nr_garts = i;
+
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
+
+ hammers[i++] = loop_dev;
+ nr_garts = i;
}
return i == 0 ? -1 : 0;
}
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
Seems wrong to me... wouldn't this return -1 if say, MAX_HAMMER_GARTS ==
1 and 1 gart was found ( nr_garts == i == 1 when the comparison is made
). It would need to be:
if (i MAX_HAMMER_GARTS) {
...
This would also be wrong, as the test would be too late, and hammer[]
would be overflowed by the time the test is performed. This is why the
test was moved before the assignment in our patches. The way we did it
would handle the SMP and non-smp cases I believe, the code you quoted
would only work right in the uniproc case.
I can test this when I get home today though I suppose.
-James
#else
/* Uniprocessor case, return after finding first bridge.
(There may be more, but in UP, we don't care). */
return 0;
#endif
}
return i == 0 ? -1 : 0;
}
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 11:44:42AM -0800, James Jones wrote:
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
Seems wrong to me... wouldn't this return -1 if say, MAX_HAMMER_GARTS ==
1 and 1 gart was found ( nr_garts == i == 1 when the comparison is made
). It would need to be:
MAX_HAMMER_GARTS can only be 1 if CONFIG_SMP=n, so the above code
is skipped, and we fall through, and return 0.
This would also be wrong, as the test would be too late, and hammer[]
would be overflowed by the time the test is performed. This is why the
test was moved before the assignment in our patches. The way we did it
would handle the SMP and non-smp cases I believe, the code you quoted
would only work right in the uniproc case.
That's how it should be.
If we have a UP system, with UP kernel, we just return 0 after
finding the first GART
If we have a UP system with an SMP kernel, we find the first GART,
and eventually end up returning 0 after finding no further garts.
If we have an SMP system with UP kernel, we exit early after
finding the first GART. The 2nd (And above) GARTs are irrelevant
when not running in SMP.
If we have an SMP system with an SMP kernel, we add however many
GARTs to the table, up to a limit of MAX_HAMMER_GARTS.
I don't see any problems.
Dave
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 08:56:32PM +0100, Ronny V. Vindenes wrote: If we have an SMP system with an SMP kernel, we add however many GARTs to the table, up to a limit of MAX_HAMMER_GARTS. It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if there is an MAX_HAMMER_GARTS'th GART. Ah, yes I think you're right. I'll fix that up. Thanks for double checking. Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 12:13:37PM -0800, James Jones wrote: Ronny V. Vindenes wrote It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if there is an MAX_HAMMER_GARTS'th GART. Yes, thanks for putting it more clearly Ronny. Dave, try walking through the code with MAX_HAMMER_GARTS=2 and SMP enabled. You should quickly see what we mean. Even with MAX_HAMMER_GARTS=1 and SMP enabled (running SMP support on one processor) which was the case I was trying to explain, it should fail. Now changed to your proposed change (i MAX_HAMMER_GARTS) Thanks again. Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
Ronny V. Vindenes wrote It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if there is an MAX_HAMMER_GARTS'th GART. Yes, thanks for putting it more clearly Ronny. Dave, try walking through the code with MAX_HAMMER_GARTS=2 and SMP enabled. You should quickly see what we mean. Even with MAX_HAMMER_GARTS=1 and SMP enabled (running SMP support on one processor) which was the case I was trying to explain, it should fail. -James --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
The ( i MAX_HAMMER_GARTS) fix was just an example. The test really needs to be == and be moved before the hammers[i++] = loop_dev; assignment, or hammers will be overflowed, as I mentioned in my previous email. Also, it really seems like this test should be done before you go through all the trouble of detecting another gart. If we already have the max number of hammer garts, why try to detect another one, we can just return -1 and be done with it right? Thanks for the fix though. -James Dave Jones wrote: On Wed, Nov 19, 2003 at 12:13:37PM -0800, James Jones wrote: Ronny V. Vindenes wrote It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if there is an MAX_HAMMER_GARTS'th GART. Yes, thanks for putting it more clearly Ronny. Dave, try walking through the code with MAX_HAMMER_GARTS=2 and SMP enabled. You should quickly see what we mean. Even with MAX_HAMMER_GARTS=1 and SMP enabled (running SMP support on one processor) which was the case I was trying to explain, it should fail. Now changed to your proposed change (i MAX_HAMMER_GARTS) Thanks again. Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Fri, Oct 31, 2003 at 11:46:54AM -0800, James Jones wrote: test8 had broken detection for this agp chipset. You have to edit a file in the x86_64 arch directory to get it to allow more than 0 (assuming you configed for uniprocessor) bridges to be used, as it checks a variable after incrementing rather than before. I also found the check wasn't even getting compiled in as the CONFIG_ define had a different name in the arch file than in amd64-agp.c, and only one of these matched the actual config define name. Haven't tried test9 yet, I sent a patch to dave jones after I noticed this in test7, but I received no response. I don't recall seeing this mail. Bounce me another copy? Dave -- Dave Jones http://www.codemonkey.org.uk --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Tue, 2003-11-18 at 18:55, Dave Jones wrote:
On Fri, Oct 31, 2003 at 11:46:54AM -0800, James Jones wrote:
test8 had broken detection for this agp chipset. You have to edit a
file in the x86_64 arch directory to get it to allow more than 0
(assuming you configed for uniprocessor) bridges to be used, as it
checks a variable after incrementing rather than before. I also found
the check wasn't even getting compiled in as the CONFIG_ define had a
different name in the arch file than in amd64-agp.c, and only one of
these matched the actual config define name.
Haven't tried test9 yet, I sent a patch to dave jones after I noticed
this in test7, but I received no response.
I don't recall seeing this mail. Bounce me another copy?
Don't know about the CONFIG_ define problem on x86-64, but this fixes it
for x86.
--
Ronny V. Vindenes [EMAIL PROTECTED]
--- linux-2.6.0-test8/drivers/char/agp/amd64-agp.c.orig 2003-11-18 22:09:13.0 +0100
+++ linux-2.6.0-test8/drivers/char/agp/amd64-agp.c 2003-11-18 22:14:23.0 +0100
@@ -355,12 +355,12 @@
#endif
return -1;
}
- hammers[i++] = loop_dev;
- nr_garts = i;
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
+ hammers[i++] = loop_dev;
+ nr_garts = i;
}
return i == 0 ? -1 : 0;
}
Re: [Dri-devel] r200 in cvs broken?
On Tue, 2003-11-04 at 03:28, Michel Dnzer wrote: On Thu, 2003-10-30 at 11:43, Ronny V. Vindenes wrote: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 This particular problem should be fixed in current CVS. Funny that the rest started working again for you though (right?), I didn't notice any related changes... Only thing I can think of was that I added the BusType AGP option (which had no effect on the non-cvs version). -- Ronny V. Vindenes [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Tue, 2003-11-04 at 12:11, Ronny V. Vindenes wrote: On Tue, 2003-11-04 at 03:28, Michel Dnzer wrote: On Thu, 2003-10-30 at 11:43, Ronny V. Vindenes wrote: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 This particular problem should be fixed in current CVS. Funny that the rest started working again for you though (right?), I didn't notice any related changes... Only thing I can think of was that I added the BusType AGP option (which had no effect on the non-cvs version). Option BusType was only added to CVS recently, together with the bus type detection; seems everything is related to the misdetection of the bus type then. Let's hope that the bus type detection changes Kevin mentioned will fix this. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Thu, 2003-10-30 at 11:43, Ronny V. Vindenes wrote: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 This particular problem should be fixed in current CVS. Funny that the rest started working again for you though (right?), I didn't notice any related changes... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
FIXED [was: Re: [Dri-devel] r200 in cvs broken?]
On Fri, 2003-10-31 at 01:54, Ronny V. Vindenes wrote: On Fri, 2003-10-31 at 00:43, Roland Scheidegger wrote: Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log From the log, the card gets detected as a PCI card, but from the bus id I'd say it's a AGP card, is that true? In that case, it looks like the test for AGP/PCI doesn't work correctly. It is an AGP card, but the amd64-agp module in 2.6.0-test9 doesn't detect the VIA K8T800 chipset [1] (agpgart in 2.4.23-pre9 does detect it, but XFree86 still defaults to pcigart [2]). In radeon_driver.c, it says Following detection method works for all cards tested so far. Guess your card is the first it doesn't :-( If that's the case, you can try to get it to work with BusType AGP in the XF86Config file. Though I'd have assumed that a AGP card detected as PCI should still work. Setting BusType AGP makes no difference. Just to clarify, it is detected as PCI when using older working also. [1] I can get it to load by some hand tweaking of some of the tests in the module, but it still works no better than 2.4.23-pre9. [2] Someone with the same motherboard is seeing the same problem with agp not working: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107805 Yesterday's patches in cvs not only fixed the CP errors, they also fixed my AGP issues. -- Ronny V. Vindenes [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
test8 had broken detection for this agp chipset. You have to edit a file in the x86_64 arch directory to get it to allow more than 0 (assuming you configed for uniprocessor) bridges to be used, as it checks a variable after incrementing rather than before. I also found the check wasn't even getting compiled in as the CONFIG_ define had a different name in the arch file than in amd64-agp.c, and only one of these matched the actual config define name. Haven't tried test9 yet, I sent a patch to dave jones after I noticed this in test7, but I received no response. -James Ronny V. Vindenes wrote: On Fri, 2003-10-31 at 00:43, Roland Scheidegger wrote: Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log From the log, the card gets detected as a PCI card, but from the bus id I'd say it's a AGP card, is that true? In that case, it looks like the test for AGP/PCI doesn't work correctly. It is an AGP card, but the amd64-agp module in 2.6.0-test9 doesn't detect the VIA K8T800 chipset [1] (agpgart in 2.4.23-pre9 does detect it, but XFree86 still defaults to pcigart [2]). In radeon_driver.c, it says Following detection method works for all cards tested so far. Guess your card is the first it doesn't :-( If that's the case, you can try to get it to work with BusType AGP in the XF86Config file. Though I'd have assumed that a AGP card detected as PCI should still work. Setting BusType AGP makes no difference. Just to clarify, it is detected as PCI when using older working also. [1] I can get it to load by some hand tweaking of some of the tests in the module, but it still works no better than 2.4.23-pre9. [2] Someone with the same motherboard is seeing the same problem with agp not working: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107805 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] r200 in cvs broken?
Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log -- Ronny V. Vindenes [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log If you can track this down to an individual change, it will help a lot in terms of getting it resolved. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Thu, 2003-10-30 at 12:03, Keith Whitwell wrote: Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log If you can track this down to an individual change, it will help a lot in terms of getting it resolved. OK, I'll take a closer look during the weekend. -- Ronny V. Vindenes [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: [...] Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. just wanted to let you know that current cvs works ok for me with a 8500LE. so it seems that not all r200 cards / configurations are affected. (athlon xp, 2.6.0-test8, crt connected to normal vga-port, not dvi) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Thu, 2003-10-30 at 20:43, Ronny V. Vindenes wrote: Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. Just checked latest DRI CVS with my radeon 9000 PCI, no errors. I know it doesn't help but it might give you a better idea of where to look. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log From the log, the card gets detected as a PCI card, but from the bus id I'd say it's a AGP card, is that true? In that case, it looks like the test for AGP/PCI doesn't work correctly. In radeon_driver.c, it says Following detection method works for all cards tested so far. Guess your card is the first it doesn't :-( If that's the case, you can try to get it to work with BusType AGP in the XF86Config file. Though I'd have assumed that a AGP card detected as PCI should still work. Roland btw, the ForcePCIMode option (which is only there for compatibility reasons I guess) no longer works (I just tried it out to test if a AGP card forced to PCI would work). It will set the card type to pci, but that gets immediately overwritten by the agp/pci test so the log file says (**) RADEON(0): Forced into PCI mode (II) RADEON(0): AGP card detected I'd suggest just to remove that option, I guess there aren't really a lot of users using this, and those who do probably could figure out they should now use the BusType option instead. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Fri, 2003-10-31 at 00:43, Roland Scheidegger wrote: Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log From the log, the card gets detected as a PCI card, but from the bus id I'd say it's a AGP card, is that true? In that case, it looks like the test for AGP/PCI doesn't work correctly. It is an AGP card, but the amd64-agp module in 2.6.0-test9 doesn't detect the VIA K8T800 chipset [1] (agpgart in 2.4.23-pre9 does detect it, but XFree86 still defaults to pcigart [2]). In radeon_driver.c, it says Following detection method works for all cards tested so far. Guess your card is the first it doesn't :-( If that's the case, you can try to get it to work with BusType AGP in the XF86Config file. Though I'd have assumed that a AGP card detected as PCI should still work. Setting BusType AGP makes no difference. Just to clarify, it is detected as PCI when using older working also. [1] I can get it to load by some hand tweaking of some of the tests in the module, but it still works no better than 2.4.23-pre9. [2] Someone with the same motherboard is seeing the same problem with agp not working: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107805 -- Ronny V. Vindenes [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
