Debugging xserver on Alpha
Matt Turner
mattst88 at gmail.com
Mon Oct 5 15:16:25 PDT 2009
Hi Michael,
On Sat, Oct 3, 2009 at 7:05 PM, Michael Cree <mcree at orcon.net.nz> wrote:
> Matt and the xorg-devel maillist,
>
> I think it is time to report where I am with debugging the Xserver on Alpha
> and to ask for advice on how to proceed.
>
> Using the xserver 1.7 branch I find that I must wrap _X_EXPORTs around
> _alpha_inb et al. else the int10, etc., modules have undefined symbols and
> won't load.
>
> With commit c7680befe5ae on the xserver 1.7 branch only support for Alphas
> with sparse I/O remains. I have already sent you and the list a patch that
> reenables the code path for Alphas with dense I/O mapping.
I can't see anything in this commit that would break dense systems. It
just removed Jensen support (which is a _third_ memory mapping model,
i.e., not the same as sparse or dense). This commit was present in
xserver-1.5, which I can confirm works on alpha, so I don't think it's
got anything to do with the problems we've seen.
> I have tested on three Alphas (all have the BWX extension, hence a dense I/O
> mapping model) and a number of (mostly older) video cards. I am still
> running a 2.6.30 variant kernel, hence haven't tested KMS.
>
> The xserver 1.7 branch with the two patches I mention above works on an
> Compaq Alpha XP1000 (ev67 CPU) with a Radeon 9250 card. At least I have a
> gnome desktop opened on it but haven't done extensive usage testing.
Excellent news! To clarify, this is with the _alpha_{in,out} functions
marked with _X_EXPORT, and what was the other patch?
> However, on the DEC Alpha PWS600au (an ev56 CPU), I am seeing lockups/kernel
> oops with other video cards emanating from the vbe/int10 code.
>
> With a newer Radeon HD2400 I get a kernel oops (which I reported a couple or
> so months ago to the linux kernel mail list) which appears to happen in the
> int10 code. Note that this card is not POSTed at boot; it is up to the
> xserver to POST it. This kernel oops was seen with the 1.6 xserver branch
> and I haven't tested it since as I've put this video card aside as the video
> cards I discuss below seem to offer a better chance of finding the problem
> (and the kernel oops is nasty - it corrupted a disc partition on one
> occasion).
Maybe KMS is going to be the only way we can support R600+ cards on
Alpha. It would be interesting to see if you got the same results as I
did. (http://bugs.freedesktop.org/show_bug.cgi?id=23227) (BTW: there's
now a Radeon 4350 PCI card, so R700 on Alpha is possible. :)
> When I use an old 1997 Matrox card the xserver (1.7 branch) comes up fine.
> An examination of the xf86-video-mga driver reveals that it doesn't load
> int10 unless there is a request for that in xorg.conf.
So is int10 needed to start X with the matrox?
> When I use an old Sis card (with the xf86-video-sis) driver the int10 code
> is loaded but the xserver gets lost in the int10 initialisation code and
> eats 100% cpu forever. Connecting to the X process with gdb reveals
> backtraces of the following nature:
>
> 0x00000200006507e8 in inline_bwx_inb (addr=<value optimized out>)
> at ../sysdeps/unix/sysv/linux/alpha/ioperm.c:359
> 359 ../sysdeps/unix/sysv/linux/alpha/ioperm.c: No such file or directory.
> in ../sysdeps/unix/sysv/linux/alpha/ioperm.c
> (gdb) bt
> #0 0x00000200006507e8 in inline_bwx_inb (addr=<value optimized out>)
> at ../sysdeps/unix/sysv/linux/alpha/ioperm.c:359
> #1 dense_inb (addr=<value optimized out>)
> at ../sysdeps/unix/sysv/linux/alpha/ioperm.c:444
> #2 0x0000020000650960 in _inb (port=2199033660378)
> at ../sysdeps/unix/sysv/linux/alpha/ioperm.c:826
> #3 0x0000000120135008 in _dense_inb (port=2199033660378) at lnx_ev56.c:124
> #4 0x0000020000a2a930 in inb (port=986)
> at ../../../hw/xfree86/common/compiler.h:344
> #5 x_inb (port=986) at helper_exec.c:333
> #6 0x0000020000a34cbc in x86emuOp_in_byte_AL_DX (op1=<value optimized out>)
> at ./../x86emu/ops.c:9737
> #7 0x0000020000a45158 in X86EMU_exec () at ./../x86emu/decode.c:122
> #8 0x0000020000a2d5f8 in xf86ExecX86int10 (pInt=0x12024e550)
> at xf86x86emu.c:40
> #9 0x0000020000a2e8a8 in xf86ExtendedInitInt10 (entityIndex=0,
> Flags=<value optimized out>) at generic.c:285
> #10 0x0000020000a10410 in VBEExtendedInit (pInt=0x0, entityIndex=0, Flags=3)
> at vbe.c:68
> #11 0x00000200009881b8 in SiS_LoadInitVBE (pScrn=0x120248870)
> at sis_driver.c:2828
> #12 0x000002000098d504 in SISPreInit (pScrn=0x120248870,
> flags=<value optimized out>) at sis_driver.c:5996
> #13 0x000000012008bef0 in InitOutput (pScreenInfo=0x12022c758, argc=4,
> argv=0x11fd45738) at xf86Init.c:817
> #14 0x0000000120024da0 in main (argc=4, argv=0x11fd45738, envp=0x11fd45760)
> at main.c:204
The "No such file or directory" error is puzzling. The only two files
accessed by ioperm.c are /etc/alpha_systype (which is not expected to
exist) and /proc/cpuinfo, which certainly exists.
For reference, the ioperm.c code can be read here,
http://sourceware.org/git/?p=glibc-ports.git;a=blob;f=sysdeps/unix/sysv/linux/alpha/ioperm.c;h=32e96ec2f295db114722b34d8d5c3bc66643f87f;hb=afd09ae82a5f6cc0a358acfe72e8463b37003131
> I strongly suspect that the xserver is lost cycling around in the
> X86EMU_exec() routine and never exits it.
>
> Since the xserver 1.5 branch works on Alpha and the 1.6 branch doesn't, I
> did a diff of the code in the int10, x86emu, os-support/linux, etc.,
> directories to search for changes that might prove problematic on Alpha but
> I didn't spot anything that looked suspicious.
Does the SIS card work with 1.5?
> I see the emu86 code has debugging and disassembling capabilities. I tried
> setting DEBUG in the Makefile in the x86emu directory but discovered I will
> probably have to insert a call to X86EMU_trace_on() before any debugging
> output will occur.
>
> Am I on the right track here? How does one go about debugging the int10 and
> vbe code? Since an examination of code changes between a working xserver
> and a broken xserver has failed to highlight anything, and the problem seems
> to be somewhere in the x86 emulation is the best approach to enable the x86
> emulator debugging modes and track exactly what it is doing? Is there
> someone who is happy to give me a bit of guidance on doing this? I am quite
> unfamiliar with the x86 emulator, and while I have programmed in various
> assembler languages in the past I am unfamiliar with Intel x86.
Sorry, I'm not going to be much help when it comes to x86emu, int10,
and vbe. But I can't see how the problem could be in this code if it
hasn't changed. I guess this is why knowing if the SIS card works with
1.5 is important.
> Cheers
> Michael Cree.
Thanks _so_ much for this analysis. I _really_ appreciate it. I'm also
sorry for not getting back to you sooner.
The disk in my UP1500 is kind of dead, so I've got to replace it
before I can do much more testing.
Sent the _X_EXPORT patch to the list. Maybe we can get some testing.
Thanks,
Matt Turner
More information about the xorg-devel
mailing list