Bug 3914

Oh, and it's a u10, and the toolchain/kernel are:
linux-2.6.13_rc3-git4, gcc-3.4.4, glibc-2.3.5, binutils-2.16.1

Ok, it's happening with 6.8.99.4 as well, and it appears from the log that it's
not a but in the ati driver like I originally thought, so reassigning

This is a pre-release version of the The X.Org Foundation X11.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the The X.Org Foundation "monolithic tree" CVS
repository hosted at http://www.freedesktop.org/Software/xorg/
X Window System Version 6.8.99.4
Release Date: 24 April 2005 + cvs
X Protocol Version 11, Revision 0, Release 6.8.99.4
Build Operating System: Linux 2.6.12-gentoo-r4 sparc64 [ELF] 
Current Operating System: Linux aeris 2.6.12-gentoo-r4 #6 Fri Jul 8 18:32:29 PDT
2005 sparc64
Build Date: 29 July 2005
        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: Fri Jul 29 21:21:17 2005
(==) Using config file: "/etc/X11/xorg.conf"
f(EE) end of block range 0xc0000b < begin 0x2c00000
(EE) end of block range 0xc0001b < begin 0x2c00010
f(EE) end of block range 0xc0000b < begin 0x2c00000
(EE) end of block range 0xc0001b < begin 0x2c00010
(WW) ****INVALID IO ALLOCATION**** b: 0x2c00400 e: 0x2c00500 correcting

Created attachment 6092 [details] [review]
add-altix.patch

A couple of ideas are the Altix support in the server, and the Theatre changes
in the ati driver. I attached the patch that added Altix support -- you could
try reversing it with `patch -R` to see whether this helps.

It doesn't apply cleanly to current xserver, so you may need to test this with
6.9 or fix up the patch.

Generated with `git diff d450a70~2 d450a70`

(In reply to comment #2)
> f(EE) end of block range 0xc0000b < begin 0x2c00000
> (EE) end of block range 0xc0001b < begin 0x2c00010
> f(EE) end of block range 0xc0000b < begin 0x2c00000
> (EE) end of block range 0xc0001b < begin 0x2c00010
> (WW) ****INVALID IO ALLOCATION**** b: 0x2c00400 e: 0x2c00500 correcting

This also happens in my perfectly working Ultra5.

(WW) ****INVALID IO ALLOCATION**** b: 0x2c00400 e: 0x2c004ff correcting

Created attachment 6093 [details] [review]
remove-altix.patch

This one oughta apply against current modular, and you don't need to pass -R.

This bug (or at least the symptom --- "basically my problem is a hardlock with a
nice corrupted display") persists into modular xorg-x11-7.1 on sparc.  Until
there is a fix for it, we (gentoo/sparc) cannot release x-modular as stable
because sparc+ati is a rather common configuration.  Is there an anticipated
release date for a fix, or should we plan to pin sparc at 6.8.2?

maybe you could help us to help you and test remove-altix.patch?

Created attachment 6589 [details] [review]
remove-altix patch for xorg-server-1.1.1

Attached patch cleans up original remove-altix patch so that (1) it applies
cleanly and (2) resulting xorg-server-1.1.1 actually builds.  Preliminary
testing indicates that it solves the mach64 lockup problem on sparc for
xorg-server-1.1.1, but testing is not complete.

I have no idea what happens on non-sparc systems if this patch is applied.

So far, Jason Wever's (weeve@gentoo.org) version of the patch (attachment 6589 [details] [review])
seems to work fine for us.  Or at least, so says gustavoz@gentoo.org.

The proposed fix for this in effect backs out the altix support provided as a
result of Bug 2373.  Consequently, the Bug 2373 altix support cannot be quite
complete as it stands, because it apparently has a side effect of breaking xorg
for sparc/mach64 systems.  Thus, correct resolution of this bug requires correct
resolution of the altix 2373 support request, and I am linking them.

Please also note Gustavo's comment at
https://bugs.freedesktop.org/show_bug.cgi?id=2373#c51 for more details.

The snippet below (from the revert patch) removes the new 
linuxTransAddrBusToHost routine from the PCI mapping function table.  This 
routine is *supposed* to be generic, but it may well be broken on some sparc64 
configurations.  Can you try building a tree without the revert patch but with 
that line protected #if defined(__ia64__) ... #endif instead of removed 
entirely?  That would tell us for sure if the xf86GetOSOffsetFromPCI routine 
was the culprit (it probably is, it has quite a few shortcomings).

If that works, simply protecting that line with an #ifdef __ia64__ might be a 
good short term fix...

Thanks,
Jesse

--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -63,7 +63,6 @@ #include "Pci.h"
 static CARD32 linuxPciCfgRead(PCITAG tag, int off);
 static void linuxPciCfgWrite(PCITAG, int off, CARD32 val);
 static void linuxPciCfgSetBits(PCITAG tag, int off, CARD32 mask, CARD32 bits);
-static ADDRESS linuxTransAddrBusToHost(PCITAG tag, PciAddrType type, ADDRESS 
addr);
 #if defined(__powerpc__)
 static ADDRESS linuxPpcBusAddrToHostAddr(PCITAG, PciAddrType, ADDRESS);
 static ADDRESS linuxPpcHostAddrToBusAddr(PCITAG, PciAddrType, ADDRESS);
@@ -84,7 +83,7 @@ #if defined(__powerpc__)
 /* pciAddrBusToHost */	linuxPpcBusAddrToHostAddr,
 #else
 /* pciAddrHostToBus */	pciAddrNOOP,
-/* pciAddrBusToHost */	linuxTransAddrBusToHost,
+/* pciAddrBusToHost */	pciAddrNOOP,
 #endif
 
 /* pciControlBridge */		NULL,

Works nice with your patch, that seem to did it.

Great, I'll go ahead and check in the workaround.  I'll file a new bug on 
linuxGetOffsetFromPCI since it seems like that's broken (fixing that would be 
more proper).  Thanks for testing.

Jesse

Ok, I looked at xf86GetOSOffsetFromPCI and it definitely seems broken.  It 
uses PCI device structures that don't handle 64 bit BARs when compiled as a 32 
bit binary, afaict.  What's weird is that supposedly that was fixed by 6377 
(using direct PCI config space access instead of the silly wrapper struct), 
but I don't see that code in the tree.  ajax?

I'd really rather fix xf86GetOSOffsetFromPCI than kludge the PCI operations 
structure, and ideally we'd unify the PPC implementation too, but maybe the 
kludge is fine for now since the PCI rework tree should kill all this ugly 
code?

I've committed a workaround as b3a3020fd018df8bc5a8193d36e1a1c7ae8af8ba.  It's 
ugly (just removes the mapping routine for sparc64 compiles) but all this code 
will soon disappear so I think that's ok.  Please test the latest tree to make 
sure things work for you.

Thanks,
Jesse