Debugging xserver on Alpha

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.