X Window server aborts

When I run Axis for a while my X session crashes. I get this in my X log:

Backtrace:
0: /usr/bin/X11/X(xf86SigHandler+0x7e) [0x80c24de]
1: [0xb80d9400]
2: /usr/lib/xorg/modules/extensions//libGLcore.so(_swrast_Line+0x26) [0xb69980a6]
3: /usr/lib/xorg/modules/extensions//libGLcore.so [0xb699e281]
4: /usr/lib/xorg/modules/extensions//libGLcore.so [0xb69bfbdc]
5: /usr/lib/xorg/modules/extensions//libGLcore.so [0xb69c150b]
6: /usr/lib/xorg/modules/extensions//libGLcore.so(_tnl_run_pipeline+0x164) [0xb69a52e4]
7: /usr/lib/xorg/modules/extensions//libGLcore.so(_tnl_draw_prims+0x406) [0xb69b9446]
8: /usr/lib/xorg/modules/extensions//libGLcore.so [0xb69faf57]
9: /usr/lib/xorg/modules/extensions//libGLcore.so(vbo_split_inplace+0x1e2) [0xb69fb222]
10: /usr/lib/xorg/modules/extensions//libGLcore.so(vbo_split_prims+0x85) [0xb6a01915]
11: /usr/lib/xorg/modules/extensions//libGLcore.so(_tnl_draw_prims+0x81b) [0xb69b985b]
12: /usr/lib/xorg/modules/extensions//libGLcore.so [0xb69fcadf]
13: /usr/lib/xorg/modules/extensions//libglx.so [0xb7d1f27d]
14: /usr/lib/xorg/modules/extensions//libglx.so(DoRenderLarge+0x236) [0xb7cfdd56]
15: /usr/lib/xorg/modules/extensions//libglx.so [0xb7cfdf2c]
16: /usr/lib/xorg/modules/extensions//libglx.so [0xb7d020e6]
17: /usr/bin/X11/X [0x8154c04]
18: /usr/bin/X11/X(Dispatch+0x314) [0x808de24]
19: /usr/bin/X11/X(main+0x4b5) [0x8074795]
20: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7e8b455]
21: /usr/bin/X11/X(FontFileCompleteXLFD+0x21d) [0x8073a81]

Fatal server error:
Caught signal 4. Server aborting

EMC2 keeps on running even though I am dumped to the console. If anyone can help me fix this I'd appreciate it. Thank you.

Hi

All the references I can find to this error appear to be video card and driver specific, ie. experienced when using a card / driver of one type but not when using a different one.
They occur over a variety of cards, nVidia being frequently mentioned.

When does Axis crash? Is it when you start a program, load a file or do something else that will require it to render a plot with GL?
The error log strongly suggests openGL calls are involved, but it is not as simple as a complete failure, if it runs for a while first.

Try running a non openGL based GUI, tkemc, xemc.
Does the error occur?

The options if this works might be trying the vesa driver, trying the nv driver if using a proprietary nVidia driver and even trying using the software opengl libraries.

Will need to know more about your hardware esp the video card or chipset, version of Ubuntu, version of LinuxCNC etc to suggest next step.

regards

Initially I thought the same thing myself. Then I found some other messages in my syslog file that lead me to believe the problem has nothing to do with GL. I think my system is improperly configured. There are a lot of settings, and obviously some of mine are wrong.

One of the first things I want to try though is an interface other than Axis, just to completely rule it out as my problem.

Changing my front end from Axis to tkemc my system does not exhibit any instability I can detect. Running glxgears while I am running my RTAI kernel extension causes the exact same error I see in Axis though. This is that error:

Jan 18 09:24:31 scnc kernel: 994258: ERROR: Unexpected realtime delay: check dmesg for details.
Jan 18 09:24:31 scnc kernel:
Jan 18 09:24:31 scnc kernel: In recent history there were
Jan 18 09:24:31 scnc kernel: 998121, 999267, 1000798, 998574, and 998325
Jan 18 09:24:31 scnc kernel: elapsed clocks between calls to the motion controller.
Jan 18 09:24:31 scnc kernel: This time, there were 1326671 which is so anomalously
Jan 18 09:24:31 scnc kernel: large that it probably signifies a problem with your
Jan 18 09:24:31 scnc kernel: realtime configuration. For the rest of this run of
Jan 18 09:24:31 scnc kernel: EMC, this message will be suppressed.

Is anyone familiar with what causes this and what steps I can take in order to rectify it? For now my only alternative is to avoid GL applications while I use RTAI, but doing that keeps me from using Axis as my CAM front end. I would like to find the real problem and fix it if possible.

Have you tried different display drivers as shown here?
wiki.linuxcnc.org/cgi-bin/wiki.pl?Troubl...oting#Display_Issues

Rick G

Hi

Since it appears that there is a problem between GL and your video chipset and/or driver, it now becomes a process of elimination.

The huge jitter figures in your error messages worry me a little and I would be looking to run a latency test against heavy non-GL usage (opening .pdfs, web browsing, large file copies etc) just to make sure the computer was a viable candidate in the first place, before spending too much time trying to sort GL out.

As Rick highlighted, you can try changing the video driver in xorg.conf.

The flip side and perhaps easier to try initially, is to substitute the software opengl libraries for the default ones
(see 5.2 of the same link Rick gave)

We still know nothing of your hardware, video card / chipset etc so cannot say if it is known to have problems or if there is a specific known fix.

regards

That did not work here. I could not get a display when I put Driver "vesa" into my xorg.conf file. I'm not sure now what that means.

Might be because of this:
"some TFT monitors refuse to work with default refresh rate of VESA driver."

So the next time I reboot I'll swap that monitor. I've some others I can try. I don't consider that done until I've tried another.

I do know that machine has an ATI card in it and runs the r128 open source driver. But I don't know much about ATI, I usually run nvidia. Man this is a pain, I sort of like that one monitor.

Thanks for the page link. Gives me more to explore. When I find out more I'll be sure to update the thread. I will probably get to the bottom of this one way or another.

I'm not sure what this means but I just ran /usr/realtime/testsuite/kern/latency; time ./run

with glxgears going and it seemed fine to me.

Hi

A search of the forum, shows a previous post from someone with the ATI card and openGL problems, which was resolved by using the software opengl libraries as I previously suggested.

www.linuxcnc.org/index.php/english/compo...iew&catid=21&id=4822

Searching the web produced a number of links to discussions of ATI r128 and opengl problems.
One apparently knowledgeable contributor linked them to later kernels, because ATI have not updated the driver for some time, regarding the cards as old technology.

The suggestion that flows from that is if you are unable to get 10.04 to run opengl with your video card / driver, to try installing 8.04 and see if you have the same problems.

Keep plugging away, you will hit the solution eventually:)

regards

I read that thread and what happened to them isn't what I am seeing here. But I'll try it anyways to see what results I get. It could be the same issue regardless. Until I see things fixed I cannot rule anything out. I might in fact build a whole local version of X for it. Wouldn't be the first time I've done it. Though the last time I can recall such I was running a P200, Permedia bug if memory serves me. This isn't exactly my first spin around the old Linux block.

I don't fault ATI for their opinion of the card, it is old tech to me too. I think a large part of my problem is the machine I am running EMC on. I actually pulled that system out of a rubbish pile. Trying to keep the project costs down here.

The system in question is a Gateway E-3400 that I've put an ATI Rage 128 Pro Ultra TF card into, a NetMos tech PCI 9815 parallel port card, and a system memory module too. For what it is it runs well, except for this one hiccup of course.

At this point the only reason I'm still looking into this problem is morbid curiosity. I'm not longer even of the mind that it should work. Plus for my purposes tkemc will work. Though giving up Axis I am losing a lot of functionality. So It'd be nice for me to resolve this.

There does appear to be something going on with the vesa display driver too. I just tried another TFT display I have and I get the same out of range results with it. Not sure why it doesn't work. I'm seeing EDID info in my Xorg.0.log file. The r128 driver seems to be working at any rate. Maybe I have to steal the modelines it generates and put them into my conf file? Sounds dumb to me.

Out of the Xorg log for when I tried the vesa driver:
(II) VESA(0): VBESetVBEMode failed ... Tried again without customized values.

I guess it is stuff like this which is why Linux really isn't ready for prime time even today? In any event it is something I may have to address. Sure doesn't make me happy.

Ubuntu versions do not apply here as I am running Debian Lenny. Other than this one minor wrinkle it all works well for me. Thanks for the vote of confidence. At this point I've still a number of plugs at my disposal here. They do get increasingly hard to hammer home though as I go through them all.

Next is the GL can of worms I suppose. Whenever I've found myself messing with it I'm usually headed the other way. Hardware acceleration etc. What is the expression? Inside out and backwards? That is the direction I appear to be pointed in now. *sigh*

I'll update the thread when I've some results there to report, one way or the other. Might be a bit though as I'm not in the mood to crack that nut right now.

It looks like because I'm using DRI GL that is why my system is crashing. But I'm hesitant to take it out and run software acceleration. Because even DRI GL is a huge performance hit with my latency figures. For now the fix seems to be avoid GL while the real time kernel extension is running. To run Axis I am going to need a much faster computer. For now I'm very pleased with how TkEMC performs. It is not as flashy as Axis is but TkEMC flies on the old PC I am using.

If anyone can confirm that changing from DRI to software accelerated GL will improve my performance I might be tempted to try it but as of now I am going to have to assume it is just going to make my performance worse.