Re: [XFree86] XFree86: ati driver problem

2008-01-31 Thread Anton 'FaioN' Mayorov

Marc Aurele La France wrote:

I'm not sure if this bug is connected with XFree86 at all. There are 
several bits of information that it is a kernel bug. It seems to me 
that affected kernel versions are 2.6.22 and 2.6.23. Check this:

http://lkml.org/lkml/2007/6/21/216 .


atyfb has __ALWAYS__ been broken, especially for laptops or adapters not 
initialised by BIOS/firmware.  And it is unfixable primarily because its 
maintainers over the years don't really know what they're doing.  That 
sounds harsh, but it is true.  On ix86, I recommend you use vesafb 
instead, or (better) no kernel framebuffer at all.

Sorry, I've rather misled you. I don't use atyfb at all.

However, now that you have some kind of display, please send me a 
-logverbose 5 log, and I'll see what I can do to mitigate atyfb's 
latest brain damage.
XFree86 -logverbose 5 lock my system entirely. Even SysRq magic 
doesn't work. I've failed to trace the reason out.


BTW, I've managed to synchronize my screen. I've overridden 
pATI-LCDClock and used Option LCDSync in XF86Config (although I 
don't know for certain what it means). It seems to work, but XFree86 
still corrupts console mode (i.e. after X server shutdown, all local 
ttys are in unusable state). And I haven't found the reason why clock 
values are set wrong.


And one more question. This is the part of atimode.c:
-
static void
ATISwap
(
int  iScreen,
ATIPtr   pATI,
ATIHWPtr pATIHW,
Bool ToFB
)
{
pointer save, *from, *to;
unsigned int iPlane = 0, PlaneMask = 1;
CARD8 seq2, seq4, gra1, gra3, gra4, gra5, gra6, gra8;

/*
 * This is only done for non-accelerator modes.  If the video state on
 * server entry was an accelerator mode, the application that 
relinquished

 * the console had better do the Right Thing (tm) anyway by saving and
 * restoring its own video memory contents.
 */
if (pATIHW-crtc != ATI_CRTC_VGA)
return;
-

I don't use kernel framebuffer, so I think my console mode isn't 
accelerated. But at this point, pATIHW-crtc is ATI_CRTC_MACH64. May it 
be the reason that my console is not restored on exit? Is this the only 
method to restore video state?



I've attached diff between 4.7.0 and my current version and my 
XF86Config to this message. I've tried to make changes as small as I can 
while saving the effect. So don't be surprised if you find traces I've 
left while debugging.


Best wishes,
Anton Mayorov


Mayorov2.diff.gz
Description: GNU Zip compressed data


XF86Config.gz
Description: GNU Zip compressed data


Re: [XFree86] XFree86: ati driver problem

2008-01-26 Thread Anton 'FaioN' Mayorov

Marc Aurele La France wrote:

---skipped---
Given you've been building from source, please let me know if the 
attached patch fixes the problem.


Thanks.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.


Thank you for the patch, but it doesn't resolved all problems. After 
patching, there is no need to set Chipset mach64. But it doesn't fix 
video distortion.


I've done a dig in the code and found that LCD clock calculation is 
broken. The previous version of system set LCD clock at approximately 
65MHz, my new build sets it about 150kHz, and I have all my screen 
distorted. Overriding the frequency helped a bit, and now I get a 
jittered X, as with out-of-vsync on CRT.


I'm not sure if this bug is connected with XFree86 at all. There are 
several bits of information that it is a kernel bug. It seems to me that 
affected kernel versions are 2.6.22 and 2.6.23. Check this:

http://lkml.org/lkml/2007/6/21/216 .



I will continue debugging and try to localize the problem ASAP.
Best wishes, Anton Mayorov

P.S. BTW, is there any way to load symbols both from XFree86 main 
executable and driver module simultaneously? Using xf86Break and 
xf86DummyVar is not very convenient...

___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86


[XFree86] XFree86: ati driver problem

2008-01-24 Thread Anton 'FaioN' Mayorov

Hello
I've got troubles running XFree86-4.7.0 on a IBM Thinkpad laptop
(ATI Rage Mobility P/M video adapter). Launching XFree86 results in
blank screen or meaningless garabge (if nolinear is not set). It seems
that it corrupts video memory (all fonts are gone until cold reboot, hot
reboot has no effect) I've tried several different Chipset settings
with the same result. Downgrading to  XFree86-4.6.0 has no result.

Here goes a piece of log file (Chipset mach64)...
...
(II) Primary Device is: PCI 01:00:0
(II) ATI:  Candidate Device section ATI Rage Mobility P/M.
(II) ATI:  Unshared VGA not probed in domain 0 due to a potential
hard-failed master abort.
(II) ATI:  Unshared 8514/A not probed in domain 0 due to a potential
hard-failed master abort.
(II) ATI:  Shared PCI/AGP Mach64 in slot 1:0:0 detected.
(WW) ATI:  VGA not detected on this adapter.
(II) ATI:  Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active
Device section ATI Rage Mobility P/M.
...
And another one (Chipset ati)
...
(II) Primary Device is: PCI 01:00:0
(II) ATI:  Candidate Device section ATI Rage Mobility P/M.
(II) ATI:  Unshared 8514/A not probed in domain 0 due to a potential
hard-failed master abort.
(WW) ATI:  Sparse I/O base 0x02EC not probed in domain 0.
(II) ATI:  Unshared Mach64 at I/O base 0x02EC not probed in domain 0 due
to I/O conflict.
(II) ATI:  Unshared Mach64 at I/O base 0x01CC not probed in domain 0 due
to a potential master abort.
(II) ATI:  Unshared Mach64 at I/O base 0x01C8 not probed in domain 0 due
to a potential master abort.
(II) ATI:  Shared PCI/AGP Mach64 in slot 1:0:0 detected.
(WW) ATI:  VGA not detected on this adapter.
(II) UnloadModule: ati
(II) Unloading /usr/X11R6/lib/modules/drivers/ati_drv.o
(EE) No devices detected.
...

Full logs are included in attachment.

I had no problems with antique version of XFree86 (4.3.0, supplied with
RedHat 9 distribution). tinyX, shipped with 4.7.0, works OK, but I
haven't run extensive tests yet.

My current system is a home-made Linux, based on linux-2.6.23.8,
glibc-2.7 and gcc-4.2.2.


Any information on the subject would be deeply appreciated.



XFree86-logs.tgz
Description: GNU Zip compressed data