Debugging xserver on Alpha
Michael Cree
mcree at orcon.net.nz
Mon Oct 5 16:28:06 PDT 2009
On 6/10/2009, at 11:16 AM, Matt Turner wrote:
> On Sat, Oct 3, 2009 at 7:05 PM, Michael Cree <mcree at orcon.net.nz>
> wrote:
>>
>> 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.
Hmmmmm. I will have to check it again - I'm not at the computer with
the xserver git so will have to wait a few hours.
>> 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?
Yes, the alpha_in and out routines needed _X_EXPORT and the other
patch is at http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/2095
Without that second patch I get a segmentation error in one of the
SlowBCopy routines. It is because it executed the sparse copy code,
thus the pointer for the copy is incremented by a far too big value
for a dense system and eventually gets incremented out of valid memory
space.
>> 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)
Okay, I will need to compile a new kernel - I see that 2.6.31.2 is now
out which apparently fixes some issues with the USB/serial port which
I require. What else do I need to do to enable KMS? I don't see any
configuration options in the xserver.
> (BTW: there's
> now a Radeon 4350 PCI card, so R700 on Alpha is possible. :)
Yes, I saw one in a local computer shop while browsing last weekend.
I was tempted to get it but didn't. Maybe I should allow myself to be
tempted even more?
>> 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?
No, it doesn't use int10 be default. The SRM successfully POSTs it and
the Xserver comes up fine on it.
>> 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.
Yes, that's because I have the source code on a different system. I
should copy the source code for libc and xorg across to the testing
machine so that gdb can find the source but I was too lazy :-/
> 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
Thanks, I already have it, just not on the computer where I did the
testing.
>> 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?
It definitely works with 1.4.2 (that was in Debian testing until
recently) and I assumed that it worked with the 1.5 branch because I
had the HD2400 working with the 1.5 branch and with both the radeonhd
and radeon video drivers back in about March. I should really test
the SIS card with 1.5 to completely verify and eliminate any
surprises. I haven't compiled the 1.5 xserver for quite a while and I
think I have lost the list of proto/lib/etc versions that was required
for it. Is there someway I can get all the proto and lib modules set
to the correct versions for xserver 1.5 branch build efficiently?
> The disk in my UP1500 is kind of dead, so I've got to replace it
> before I can do much more testing.
Bummer.
> Sent the _X_EXPORT patch to the list. Maybe we can get some testing.
Good.
Cheers
Michael.
More information about the xorg-devel
mailing list