Re: Flickering single display in multi-head XRandR setup

2016-03-25 Thread Andreas Mohr
Hi,

On Fri, Mar 25, 2016 at 11:03:36AM +0100, martin f krafft wrote:
> Hi Andreas,
> 
> Thank you for taking your time to reply. I've since followed up
> having found the problem, and I think it must be one of the DP ports
> on the graphics card.

Ooook.

> Now, you write:
> 
> > Perhaps unthinkable, but the connectors of the card might be
> > implemented / wired up asymmetrically, e.g. due to an ickily
> > varying length of traces, or EMI issues.
> 
> This leads me to believe that the connector hardware itself could be
> at fault. Seriously, is DP *that* finicky and subject to connection
> failures? I'd have thought that it being 2016, the industry would
> have finally gotten the hang of it, especially after screwing up
> HDMI so badly.

Hmm, I was writing that focussing on PCB-side implementation etc.,
but of course mechanical connection issues (including soldering issues)
likely are more dominant (when doing failure diagnosis,
one likely should focus on more "mechanical" / electro-physical parts
such as connectors, fuses, capacitors, transformers, ... initially,
since these are much more prone to failure
due to their inherent wear and tear - movement, thermo-related etc.).


Nice to hear that this seems nailed now.

Andreas Mohr
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Flickering single display in multi-head XRandR setup

2016-03-25 Thread Andreas Mohr
On Thu, Mar 24, 2016 at 11:18:01AM +, xorg-requ...@lists.x.org wrote:
> Date: Thu, 24 Mar 2016 12:12:34 +0100
> From: martin f krafft 
> There is something very weird going on, which you may witness in the
> video downloadable here:
> http://scratch.madduck.net/xorg-display-flicker.mp4 (8Mb)
> 
> The left-most display (DP0) keeps turning off and on (or resets
> itself), and generally, it flickers and the pixels jiggle around.
> The other two displays are perfectly fine. The monitor on DP1 is of
> exactly the same make as that on DP0.

While it wasn't explicitly written,
let me just assume that you did try
actively connector/cable-swapping those "exactly the same make" monitors,
with identical results.


> Do you have any idea what might be going on? Why would the left-most
> display of three, all connected to the same card, act up, while the
> other two are just fine and stable?

Perhaps unthinkable, but the connectors of the card
might be implemented / wired up asymmetrically,
e.g. due to an ickily varying length of traces, or EMI issues.

(more esoteric option:) Try swapping plug (thus, wires) of power cord -
there are cases known
where having the live wire of the cord be the *other* one
will avoid/reduce EMI issues.




Another idea might be relocating completely
i.e. re-constructing the whole test set
at a sufficiently/entirely different location,
to see whether there is a weird location dependence.




So, I guess the actions I mentioned
mainly serve to figure out the separation of
whether it is a setup-/environment-related weirdness, or
whether it is a driver implementation/configuration issue in fact.

HTH,

Andreas Mohr
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Xorg not working on PPC

2014-01-23 Thread Andreas Mohr
Hi,

On Wed, Jan 22, 2014 at 11:40:58PM -0800, xorg-requ...@lists.x.org wrote:
> Date: Thu, 23 Jan 2014 02:49:38 +
> From: Geoff Down 

> Hello List,
>  I'm installing Linux on a PowerMac G4. Since the installation with
>  Gnome failed with a black-and-white horizontal stripey screen and
>  frozen system, I was advised to try Xorg instead.

Wording issue: GNOME is a desktop environment which *is* making use of Xorg.
They probably merely advised you to fall back to an Xorg-only troubleshooting 
way.
So whichever way it's configured, the problem solidly lies with Xorg startup
on your graphics card.

>   Depth:  32-bit Color

Might want to restrict that to 16-bit, since I'd assume that to be a bit
taxing given a semi-small 16MB VRAM amount.



Got a
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Rage Mobility 128 AGP 4X/Mobility M4
right here (r128 driver, too!), so things *do* work relatively okayish still 
(x86).
However very obviously I'd assume PPC handling to be quite a bit different to 
x86 handling.
So, as venerable Alex said, your first stop should be PPC-knowledgeable groups.

That said, the lockup / garbled screen might perhaps be caused by AGP issues.
On x86, AGP support often is provided by the intel-agp.ko module.
If that module is not available (or perhaps a driver setting is provided to 
disable it),
then driver operation falls back to PCI-only, which might improve reliability.

Also, you should check whether Xorg reports DRI as enabled
(and if so, try setting it to disabled, since that might be problematic too).

In general, try disabling as many of the driver options that you can find in
man r128
, to try to figure out which setting caused such problems.

And of course check Xorg.0.log file content for specifics of all the specific
problem areas mentioned above, and more.


So far, *not* very specific help, but it might just end up helping anyway :)

HTH,

Andreas Mohr
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com


Re: Question needs asked

2014-01-18 Thread Andreas Mohr
Hello venerable Mr. Heskett,

On Fri, Jan 17, 2014 at 12:00:53PM -0800, xorg-requ...@lists.x.org wrote:
> Date: Fri, 17 Jan 2014 00:57:58 -0500
> From: Gene Heskett 

> Kernel is 32 bit PAE 3.12.6, cpu is Phenom 9550, 8 gigs of dram.  Install 
> is ubuntu 10.04.4 LTS, frozen by an app that will not run on a later 
> kernel, so I keep the original rtai patched kernel handy for when I need to 
> run that app.

Hmm... "why?".

Two things coming to my mind:
- why would there be an incompatibility here? I thought the kernel had
  intended to keep (relatively) high levels of compatibility?
  ("relatively" since I know that some udev / syscalls stuff has been
  deprecated sometimes...)
- so, given an incompatibility, using/creating an ld wrapper library
  workaround is not an option?

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s


Re: Unable to start xserver

2012-07-03 Thread Andreas Mohr
Hi,

On Tue, Jul 03, 2012 at 09:07:40AM -0700, xorg-requ...@lists.x.org wrote:
> Date: Tue, 3 Jul 2012 14:08:57 +0200
> From: Abhishek Gupta 

> Hi,
> 
> I was trying to run xserver on l4linux which is paravirtualised liux
> running on top of l4
> 
> using vesa frame buffer (l4 is running on kvm) and virtual machine
> hangs with a black screen.
> 
> 
> When I tried to debug it using gdb, it displays
> 0xb6ee9b28 in SetResetBIOSVars (pInt=0x820f5a0, set=)
> at ../../../../hw/xfree86/int10/helper_exec.c:686
> 
> this code is from the xserver 1.7.7
> 
> static void
> SetResetBIOSVars(xf86Int10InfoPtr pInt, Bool set)
> {
> int pagesize = getpagesize();
> unsigned char* base = xf86MapVidMem(pInt->scrnIndex,
> VIDMEM_MMIO, 0, pagesize);
> int i;
> 
> if (set) {
> for (i = BIOS_SCRATCH_OFF; i < BIOS_SCRATCH_END; i++)
> MEM_WW(pInt, i, *(base + i));
> } else {
> for (i = BIOS_SCRATCH_OFF; i < BIOS_SCRATCH_END; i++)
>   /*line 685*/
> *(base + i) = MEM_RW(pInt, i);/*line 686*/ //This line of code
> is not working
> 
> }
> 
> xf86UnMapVidMem(pInt->scrnIndex,base,pagesize);
> }
> I changed the DEFAULT_INT10 from x86emu to vm86 but then also xserver
> stops at exactly same Macro.
> 
> Is there any driver which I can use that doesn't uses int10 to set the
> video mode?

I'm not qualified to indicate this, sorry.

> Also what could be the possible reasons that xserver is showing
> segmentation fault while running MEM_RW macro??

You should have listed a disas around EIP register
(i.e. info reg, disas $eip-0x40 $eip+0x40 or some such).
That way one would be able to gather more details of what's
failing (possibly base address NULL, ...).

HTH,

Andreas Mohr
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com