Accelerated X driver testing

Nice. I have had troubles with this gdb being unreliable.
If you don't use startxfce4 and instead use say startlxde do you have the same issues with the debugger?

Well, I'm idiot
It works like a charms with Lxde I had to redownload it
Strange that it does not work with Xfce btw.
But the best thing is that I managed to reproduced tha crash ...now... in which directory can I find the core file?

How do you reproduce the crash? Can you do it every time? Are the steps required simple? That would be really handy if you could!
I spent quite some yesterday and I can't get X to generate a core file without the debugger
I might need to write some system for dumping the system state to the terminal if the system crashes.

The original driver displays the site correctly.

Attached you'll find the screenshot.

Enough for tonight: got to get to work tomorrow.

That's helpful thanks. At this end I'm tracking a bug which should cause general corruption with a specific pixel format input combination but your picture looks like it's sort of sheared... Does it do this *every* time the page is rendered?

It is pretty reproducible, even after the exact contents of the page changed. So I observed it on another pair of images.

I'm also unsure of why other instances of corruption are not repeatable. There may be another issue...

It seems that I'm the only one that can't start Xorg by gdb, quite frustrating...
So I imagine that there is no other way to get a core file dump, true?

Yeah this is actually really annoying - you're the only person other that me who's been able to crash it! (ever!) You are typing 'run' into gdb, right? Running in gdb should make no difference at all. Anyway it's too late now, we can't retrospectively get a core file

I managed to reproduce the crash browsing with Midori in http://forum.tgmonline.it/showthread.php?324000-Ecco-ora-%E8-mio-ma-mi-servono-esperti. Scroll down the page till the end and you should get into it.

Btw I found the core file, but I noticed is quite large. When I can I'll try to upload it, my ASDL line is not quite good

Here the core file: http://sharesend.com/7m8jn2sr

Amazing, thanks - I'll have a look later. Where was it anyway?

Amazing, thanks - I'll have a look later. Where was it anyway?

In the home folder

Hey juppiter89,

Did X actually crash when you went to that webpage or did the Raspberry Pi just become unresponsive?

I managed to reproduce the crash browsing with Midori in http://forum.tgmonline.it/showthread.php?324000-Ecco-ora-%E8-mio-ma-mi-servono-esperti. Scroll down the page till the end and you should get into it.

Btw I found the core file, but I noticed is quite large. When I can I'll try to upload it, my ASDL line is not quite good

Hey juppiter89,

Did X actually crash when you went to that webpage or did the Raspberry Pi just become unresponsive?

I managed to reproduce the crash browsing with Midori in http://forum.tgmonline.it/showthread.php?324000-Ecco-ora-%E8-mio-ma-mi-servono-esperti. Scroll down the page till the end and you should get into it.

Btw I found the core file, but I noticed is quite large. When I can I'll try to upload it, my ASDL line is not quite good

I get this in gdb:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
Op (width=<optimized out>, height=<optimized out>, source=..., dest=...,
    mask=..., coord=..., width=<optimized out>, height=<optimized out>)
    at /home/simon/Desktop/x/src/driver/xf86-video-fbdev_exa/src/./composite_ops.inl:876
876   /home/simon/Desktop/x/src/driver/xf86-video-fbdev_exa/src/./composite_ops.inl: File or directory not existing.

and so I had to restart Xorg. The screen though does not become black, just seems to freeze, but the Raspberry itself does not crash, in fact I could generate the core file.

Could you open the webpage www.canpages.ca and let me know if you get the same error?

Hey juppiter89,

Did X actually crash when you went to that webpage or did the Raspberry Pi just become unresponsive?

I managed to reproduce the crash browsing with Midori in http://forum.tgmonline.it/showthread.php?324000-Ecco-ora-%E8-mio-ma-mi-servono-esperti. Scroll down the page till the end and you should get into it.

Btw I found the core file, but I noticed is quite large. When I can I'll try to upload it, my ASDL line is not quite good

I get this in gdb:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
Op (width=<optimized out>, height=<optimized out>, source=..., dest=...,
    mask=..., coord=..., width=<optimized out>, height=<optimized out>)
    at /home/simon/Desktop/x/src/driver/xf86-video-fbdev_exa/src/./composite_ops.inl:876
876   /home/simon/Desktop/x/src/driver/xf86-video-fbdev_exa/src/./composite_ops.inl: File or directory not existing.

and so I had to restart Xorg. The screen though does not become black, just seems to freeze, but the Raspberry itself does not crash, in fact I could generate the core file.

Just tried, your webpage works fine for me.

Thanks again.
Basically the two things which have had the least amount of testing are the VpuOffload option (about a month's worth) and the SelfManagedOffscreen (about two weeks worth). With those options turned off you lose a lot of performance but is by far the most tested configuration (many many months worth)

Hi Simon,
Ok some good news and an observation.
By setting 'SelfManagedOffscreen' to 'false' the corruption goes. But while testing the various options it seemed to me that with 'SelfManagedOffscreen' set to 'false' everything else set to standard, the gui seemed to respond faster then having both 'VpuOffload' and 'SelfManagedOffscreen' set to 'true' particularly loading the desktop back drop (with the large resberrypi), which visibly loaded quicker after a 'startlxde' with only 'SelfManagedOffscreen' set to 'false', but also your test of creating a large translucent selection box over the desktop, that seemed to follow the cursor closer too, it's probably just my imagination.
For the moment would you prefer we test with all options turned on, or shall I continue with 'SelfManagedOffscreen' set to 'false'?
I do have a USB to serial adapter, but neither my desktop or laptop have a serial input. In the mean time I'm tailing the kern.log.
I have tried juppiter89 link and sure enough it crashed mine as well, even with 'SelfManagedOffscreen' set to 'false'
If there is anything in-particular you would like us to try, let us know.
Regards, Kevin.

Just tried, your webpage works fine for me.

I have caught the crash - it happens when you try and scroll beyond the bottom of the page. It's a pretty silly bug that I should have caught - basically the browser is sending invalid data (it's trying to copy from the row ~12000 of an image that's only ~500 pix high!). Catching this more robustly should be pretty easy (my existing catcher isn't good enough). A good spot

I also have a handle on the VPU corruption issue and this happens (for some reason) when the pixel format has its channels reversed. And only on some pixels - which is odd since each pixel has the same operations done on it!

For the moment would you prefer we test with all options turned on, or shall I continue with 'SelfManagedOffscreen' set to 'false'?

Yes no worries about speed. Try breaking it with both options turned off. Although ignore any crash if you see a message on the console about overreading. Once you're comfortable with this, turn on just the SelfManagedOffscreen and get bug hunting!

I do have a USB to serial adapter, but neither my desktop or laptop have a serial input.

Sorry I mean the other way round; something like this http://www.play.com/PC/PCs/4-/22896719/ ... tails.html
You plug the loose wires into the pi and the USB end into your PC. You're then hooked in to the kernel's debug output.

Oh and just to add: could those who are getting flat out machine lock-ups try without the driver? I'm getting reports from others that Midori is hanging their Pi regardless of the driver!

Many thanks again to everyone who's testing

You are welcome Simon
Discovered something from the core file?

I don't think anyone's reported this yet but supposedly you can hang the VPU with the kernel's CPU temperature reading system. My code makes heavy use of the VPU so the two can clash.
https://github.com/raspberrypi/firmware ... t-11993814
(scroll to the bottom)

As a precaution, I'd recommend doing an rpi-update.
NB this has nothing to do with the image corruption nor the crash as reported. They are different issues.

Just for report, with the original driver I don't get any crash on same webpage I had linked yesterday, nor other graphic corruptions.

I do have a USB to serial adapter, but neither my desktop or laptop have a serial input.

Sorry I mean the other way round; something like this http://www.play.com/PC/PCs/4-/22896719/ ... tails.html
You plug the loose wires into the pi and the USB end into your PC. You're then hooked in to the kernel's debug output.

Hi Simon,
Ok I should be able to do that with what I’ve got then, it’s serial one end and USB the other, I can easily make up flying lead push on pin connection adapter. Ah maybe not, standard serial is 12V this needs to be TTL, ok I’ll get a TTL one. Can you point me at somewhere that tells me where the various RST, TXD, RXD, GND pins go on the Pi, and then what I need to do to get the kernel talking?
I’ll do an update to latest bleeding edge as soon as poss. Will we need to reinstall your Xdrivers after having done an update, or should they remain untouched?
Regards Kevin.

The serial thing, I'm using the same exact one on play.com (cost me a couple of pounds...but if you don't have one no troubles). Doing an rpi-update should not replace the driver. AFAIK it only changes the kernel and firmware.
If however you do an apt-get update/upgrade there's a slim chance a new version may come down the pipes and erase it

Anyway I'll have a new version for you all in a few days to fix these few bugs. You'll definitely need to install that

The serial thing, I'm using the same exact one on play.com (cost me a couple of pounds...but if you don't have one no troubles). Doing an rpi-update should not replace the driver. AFAIK it only changes the kernel and firmware.
If however you do an apt-get update/upgrade there's a slim chance a new version may come down the pipes and erase it

Anyway I'll have a new version for you all in a few days to fix these few bugs. You'll definitely need to install that

Awesome, good news! I can't wait
Btw I could not find other bugs apart that crash and graphic corruptions. I think it's a nice thing

Hi,

First of all, great work!
I'd love to help out. I've installed the driver (VideoCore support included) and everything worked fine right out of the box. As far as I can tell, things seem faster but I'd love to know if this is just some kind of Xorg placebo effect, given that when I drag file manager windows around the CPU usage goes up the roof.

Here's the commands I am running:
* SSH Shell #1 (pastebin, the log is a bit long)

Followed by this, on another shell:

Code: Select all

pi@raspberrypi ~ $ startlxde
Obt-Message: Xinerama extension is not present on the server
Openbox-Message: Unable to find a valid menu file "/usr/share/lxde/openbox/menu.xml"

Is everything OK? Can you guys confirm I'm not running some kind of crazy fallback to the old driver?
Cheers!

Edit: running xdpyinfo | grep 'depth of root window' | awk '{ print $5 }' returns 24. Shouldn't it indicate 32?

Another tester...cool
Have a read through the thread - there's mention of what the CPU load means, what Xinerama is for and also details of two bugs that have been found (so watch out for them!)
Just to confirm: are you running Xorg in a window (SSH?) that you can always see the output of? Looking at your log all looks good. See all the FBDEV_RPI messages? That's me.

xdpyinfo | grep 'depth of root window' | awk '{ print $5 }' returns 24. Shouldn't it indicate 32?

This is fine. The goodies are this line in your log file,

Code: Select all

(II) FBDEV_RPI(0): Raspberry Pi Xorg driver build date Jan  3 2013 build time 22:54:08
(II) FBDEV_RPI(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
(==) FBDEV_RPI(0): Depth 24, (==) framebuffer bpp 32
(==) FBDEV_RPI(0): RGB weight 888
(==) FBDEV_RPI(0): Default visual is TrueColor

If you have the ability to connect to the rpi's serial port (see a few posts back) make sure you tail -f /var/log/kern.log to watch for the Ethernet driver dying.

I'll be providing an update to the two bugs within a matter of days.

Hi,
First of all, great work!
I'd love to help out. I've installed the driver (VideoCore support included) and everything worked fine right out of the box. As far as I can tell, things seem faster but I'd love to know if this is just some kind of Xorg placebo effect, given that when I drag file manager windows around the CPU usage goes up the roof.
Here's the commands I am running:
* SSH Shell #1 (pastebin, the log is a bit long)
Followed by this, on another shell:

Code: Select all

pi@raspberrypi ~ $ startlxde
Obt-Message: Xinerama extension is not present on the server
Openbox-Message: Unable to find a valid menu file "/usr/share/lxde/openbox/menu.xml"

Is everything OK? Can you guys confirm I'm not running some kind of crazy fallback to the old driver?
Cheers!

Hi Knight4
From my testing I would say that at the moment it is performing about the same as the original drivers, some things appear slightly slower some appear slightly faster, but as Simon mentioned earlier, there is tons of debug built in at the moment all of which will be tending to make things slower, but also, because the VPU/GPU is now being utilised, even though the CPU may look as though it is flat out, there is much more likely to be spare CPU cycles floating around in the background, these will then be available to other tasks. One of the things I do to stress it out, on the old driver definitely used up 100% CPU, now maxes out at 80% and visually appears faster, so faster with significant spare CPU cycles, hopefully once Simon is happy and he starts to back out most of the debug we should see further improvements. Like you, I was unsure initially that I had actually got Simons new drivers running correctly, but I guess that is just a sign of how good they are that we can't tell.
Regards Kevin.

Just to confirm: are you running Xorg in a window (SSH?) that you can always see the output of?

Yup.

Looking at your log all looks good. See all the FBDEV_RPI messages? That's me.
(...)
I'll be providing an update to the two bugs within a matter of days

Awesome thanks

If you have the ability to connect to the rpi's serial port (see a few posts back) make sure you tail -f /var/log/kern.log to watch for the Ethernet driver dying.

Not right now as I haven't got a USB serial port adaptor, but I'll let you know if I get one.

One of the things I do to stress it out, on the old driver definitely used up 100% CPU, now maxes out at 80% and visually appears faster, so faster with significant spare CPU cycles, hopefully once Simon is happy and he starts to back out most of the debug we should see further improvements. Like you, I was unsure initially that I had actually got Simons new drivers running correctly, but I guess that is just a sign of how good they are that we can't tell.

Indeed thanks for the insight

Out of interest, is there much improvement to graphics performance in Midori? We have a full screen presentation application that uses Midori in full-screen, with images that fill the screen, and JQuery set to cross-fade images.

At the moment it works, but drops frames a lot.

Will this driver help with it?