Per a suggestion in #xorg: jgavey: Triskelios, yes, I can snapshot the striping/tearing Triskelios: see if disabling tiling (see the driver options) helps. file a bug on bugs.freedesktop.org, attach what you pastied, as well as Xorg.0.log and the screenshots The orginal pastebin was: http://pastebin.com/ggCsta8T I'll attach upload the files put in pastebin as attachments.
Created attachment 56306 [details] Detals about the system with the problem
Created attachment 56307 [details] xorg.conf file that causes the problem
Created attachment 56308 [details] X server log file The first error looks like: (**) RADEON(1): Depth 24, (--) framebuffer bpp 32 (II) RADEON(1): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(1): Default visual is TrueColor (==) RADEON(1): RGB weight 888 (II) RADEON(1): Using 8 bits per RGB (8 bit DAC) (--) RADEON(1): Chipset: "ATI Radeon VE/7000 QY (AGP/PCI)" (ChipID = 0x5159) (II) RADEON(1): PCI card detected (II) RADEON(1): KMS Color Tiling: disabled (EE) RADEON(1): reusing fd for second head (II) RADEON(1): Output DVI-2 using monitor section MonitorCenterUppr (**) RADEON(1): Option "Primary" "false" (II) RADEON(1): EDID for output DVI-2 (II) RADEON(1): Manufacturer: DEL Model: a024 Serial#: 827934037 (II) RADEON(1): Year: 2007 Week: 22 This is the upper center display which acutally works, and is card with the boot console on it. The same error occurs on the upper display (secondary) port on each of the auxilliary cards too.
Triskelios (see opening comment) suggested turning off KMS. So I added: Option "EXAPixmaps" "false" To each device section. That made things work properly.
Please attach your dmesg output. Does X work ok on each card individually?
> [...] attach [...] the screenshots What happened to the screenshots? :)
Created attachment 56325 [details] Snapshot of 'striped' screen... image is not always the same... just an example
Created attachment 56326 [details] Snapshot of working/primary/boot screen (and what prior snapshot should look like)
Created attachment 56327 [details] dmesg output
(In reply to comment #5) > Please attach your dmesg output. Does X work ok on each card individually? The hardware is all working and by disabling kms, and indeicated comment #4. If I had to guess at the source of the bug, it has something to do with sharing file descriptors between two video outputs (VGA-N and DVI-N), and that the board(s) are 32M each (Appian Hurricane), of which the logs show 23.5M being used. Basically the KMS turnoff for low memory boards fails to get triggered, and has to be done manually through the xorg.conf. Not a good thing. If it wasn't for Triskelios' suggestion in #xorg, I'd have never gotten this up and working. I have no idean why being the BIOS/Linux boot console protects the board from the KMS problem. Maybe this is simply a misleading fact.
(In reply to comment #10) > > Please attach your dmesg output. Does X work ok on each card individually? > > The hardware is all working and by disabling kms, and indeicated comment #4. I think Alex's question was whether X works on each card individually (selecting only one of them in xorg.conf) without any workarounds. > [...] the board(s) are 32M each [...] Hmm, dmesg shows two cards having 64M and one having 32M. If they really all have 32M, that could explain the problem. Can you try a newer kernel, ideally 3.2?
(In reply to comment #11) > Hmm, dmesg shows two cards having 64M and one having 32M. If they really all > have 32M, that could explain the problem. Can you try a newer kernel, ideally > 3.2? I bought these cards "new". They were unopened in the manufacturers original packaging. They had been sitting around gathering dust for several years (since I'm sure you recognize the 'vintage' of these cards). I double checked the packaging. All three cards are identical. I think you may have identified the problem. The cards showing 64MB should be showing 32 MB. This would then fool the KMS flag/switch into doing the wrong thing. This system is up and running. What I can do to it is now limited. It needs to be put to use.
If there's a way to download bootable CD ISO test images, I could try that.
(In reply to comment #12) > > Can you try a newer kernel, ideally 3.2? [...] > This system is up and running. What I can do to it is now limited. It needs to > be put to use. The reason I'm asking is that with a current kernel, even if the problem isn't fixed yet, you can limit the amount of VRAM used with KMS with the kernel command line option radeon.vramlimit=32 . (I don't think that option works properly with your kernel, though I guess it doesn't hurt to try :) FWIW, it looks like there's a 3.2 kernel available for squeeze at http://backports.debian.org .
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.