Created attachment 91601 [details]
Full Dmesg of another occurance

Did a cat /dev/kmsg > dmesg.txt to get it all.

Here is the error part of the above:

3,550,895023289,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,551,895023320,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,552,895023809,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,553,895023823,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,554,895137798,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,555,895137830,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,556,895138314,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,557,895138329,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,558,895138451,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,559,895138463,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,560,917967807,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,561,917967839,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,562,917968299,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,563,917968315,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,564,917996736,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,565,917996766,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,566,917997227,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,567,917997243,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,568,917997355,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,569,917997368,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,570,928392179,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,571,928392211,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,572,928392694,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,573,928392707,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,574,928546393,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,575,928546425,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,576,928546887,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,577,928546901,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,578,928547018,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,579,928547030,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,580,934091815,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,581,934091847,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,582,934092334,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,583,934092347,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,584,934117406,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,585,934117436,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,586,934117928,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,587,934117946,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
3,588,934118062,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,589,934118073,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [plugin-containe[1388]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120

This *might* be a regression.

I migrated from Ubuntu to ArchLinux. These seem kernel errors, which I also upgraded. From 3.13.0-rc3 -> 3.13.0-rc7-00055-gef350bb:

4706515 Merge branches 'acpi-pci-pm' and 'acpi-pci-hotplug'
f244d8b ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
b25b442 drm/nouveau: only runtime suspend by default in optimus configuration
c17f5bb Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux
bdefc8c drm/nv50/disp: min/max are reversed in nv50_crtc_gamma_set()
13cd1a5 drm/nouveau/sw: fix oops if gpu has its display block disabled
2fd04c8 drm/nouveau: unreference fence after syncing
f074d73 drm/nouveau/kms: send timestamp data for correct head in flip completion events
a7e4201 drm/nouveau/clk: Add support for NVAA/NVAC
b1cd497 drm/nouveau/fifo: Hook up pause and resume for NV50 and NV84+
efffa98 drm/nv10/plane: some chipsets don't support NV12
050828e drm/nv10/plane: add downscaling restrictions
92e5b0a drm/nv10/plane: fix format computation
5b19f4f drm/nv04-nv30/clk: provide an empty domain list

Could the above contain a likely culprit?

Ubuntu -> Arch upgrade

libdrm  2.4.46-1ubuntu1 -> 2.4.50-1
mesa 9.2.1-1ubuntu3 -> 10.0.1-2
xorg-server 2:1.14.3-3ubuntu2 -> 1.14.5-1
xf86-video-nouveau 1:1.0.9-2ubuntu1 -> 1.0.10-1
kernel 3.13.0-rc3 -> 3.13.0-rc7-00055-gef350bb

I've randomly seen these types of errors when running on my NV42 as well, definitely video related (but I was running the mpeg2 hw accel). Are you observing any actual issues besides annoying messages in dmesg?

Yeah, the entire screen stalls. If I kill the tab playing adobe flash, everything is fine again. Switching tty does not work. Xorg disappears, but I only see the contents of tty1 on any other tty just before Xorg was started. I did not have these errors before when using Ubuntu. Not in this form. They appeared sporadically but everything was fine afterwards.

Some more critical information. The first time after installation, everything worked fine.

I looked at the upgrade logs:

[2014-01-07 16:14] [PACKAGEKIT] upgraded xorg-server-common (1.14.5-1 -> 1.14.5-2)
[2014-01-07 16:14] [PACKAGEKIT] upgraded xorg-server (1.14.5-1 -> 1.14.5-2)
[2014-01-09 09:19] [PACKAGEKIT] upgraded glibc (2.18-11 -> 2.18-12)
[2014-01-09 09:19] [PACKAGEKIT] upgraded libdrm (2.4.50-1 -> 2.4.51-1)

It's not the kernel, I just tried v3.13-rc3.

Libdrm is not a huge upgrade and no nouveau files were touched.

The xorg-server bump was about this: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=7943d976eef97d4d75026b6f2c3936b03aeb4648

I think I got lucky the first time it all worked. I guess.

Looking again, I saw I had the 10.3 version linked. That version still had more security updates than 11.1. Hence the choice.

Reverting to 11.1 makes things work.

No more banking on this machine...

Sorry for the noise.

What are 10.3 and 11.1 references to? Flash?

FWIW

subc 7 class 0x0697 mthd 0x0208 data 0x00000120

decodes to

$ lookup -a 34 -d NV01_SUBCHAN -- -v obj-class NV34_3D 208 120
RT_FORMAT => { COLOR = 0 | ZETA = Z16 | TYPE = LINEAR | LOG2_WIDTH = 0 | LOG2_HEIGHT = 0 }

Based on the fact that COLOR isn't set, something highly illegal is happening. I don't see any paths that would leave COLOR unset, unless somehow an illegal format was being used. And since the process in question is plugin-container, that means that opengl is being used (otherwise you'd see Xorg as the process or something).

It'd be fantastic if you could get an apitrace of this. I don't know if apitrace follows exec'd processes, but I hope it does. If not, at the very least an ltrace may prove useful (restricted to opengl, of course).

Yelled too soon. The latest flash for this CPU (non SSE2) for google chrome (11.2.202.235) (I think) gives this:

[ 7036.622880] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
[ 7036.622912] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7036.622975] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: LIMIT_COLOR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7036.622987] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0204 data 0x00b80000
[ 7036.623357] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7036.623372] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7036.623485] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7036.623497] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7036.623969] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7036.623981] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7036.624097] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7036.624108] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7049.173857] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7049.173889] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7049.174067] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7049.174081] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7049.174129] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7049.174140] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7049.174359] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7049.174373] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7049.174421] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7049.174433] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7052.461416] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7052.461448] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7052.461894] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7052.461908] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7052.462023] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7052.462035] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7052.462511] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7052.462525] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 7052.462638] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[ 7052.462651] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[5871]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120

I tried to do this but browsers are so complicated it does not work.

- apitrace trace firefox does not work
- apitrace trace chromium does not work
- replacing firefox plugin loader with script calling apitrace does not work
- replacing chromium exec with a script that catches the plugin instances yielded no results
- I downloaded fp_11.2.1.102.63_archive.zip and extracted the standalone player. Attaching apitrace seems to work. Other then the other 4 attempts it sucessfully catches the libGL calls. However, it only accepts direct links to .swf files. This will not work for youtube.

Do you have any ideas?

I have the latest apitrace from git if that matters.

Was not able to use the standalone version. Alternative apitrace methods yielded nill except for the most sophisticated method (LD_PRELOAD glxtrace.so). However, this fails:

apitrace: tracing to /home/gebruiker/plugin-container.trace
apitrace: error: failed to look up real dlopen
apitrace: error: couldn't find libGL.so
error: unavailable function glXGetClientString

Almost there :/

Tried both chromium (single-process, no-sandbox etc etc) and firefox.

What arguments do I have to use for ltrace?

-l libGL.so


???

(In reply to comment #11)
> What arguments do I have to use for ltrace?
> 
> -l libGL.so
> 
> 
> ???

And/or nouveau-dri.so. I've never used ltrace for this, so I'm not sure how useful it will be. But definitely worth a shot.

I get stuff like this:

[pid 9120] --- Called exec() ---
[pid 9120] +++ exited (status 0) +++
[pid 9119] --- SIGCHLD (Child exited) ---
[pid 9119] --- Called exec() ---
[pid 9122] --- Called exec() ---

No calls with libGL.so.1. This works with glxgears (as with apitrace).

Tried chromium -> would not even start
Firefox or plugin-container itself (i.e. exec ltrace -f -l libGL.so.1 /usr/lib/firefox/plugin-container.real $@ yields no results as well)

There is a lot of forking involved I guess.

Maybe we are hitting some sort of (insane) protection scheme here?

Btw, chromium would not even start with --single-process or --no-sandbox (those are not mutually exclusive I think).

I got somewhat the same errors with supertuxkart (don't ask).

3,1775,10645808600,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,1776,10645808638,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [supertuxkart[9875]] subc 7 class 0x0697 mthd 0x0208 data 0x02000248
3,1777,10645813906,-;nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
3,1778,10645813938,-;nouveau E[  PGRAPH][0000:01:00.0] ch 3 [supertuxkart[9875]] subc 7 class 0x0697 mthd 0x0208 data 0x02000248

Closed the window as soon as the errors appear. Yet the uncompressed trace is 30MB. Hope this helps.

Had to upload it:

http://www.send6.com/52258032

Created attachment 92246 [details] [review]
printfs and bail

Ronald try this patch. Apply it on top of the mesa that you're using currently.

It will print the different formats, and bail when we try to program 0x0000120 to the card. This may cause side effects so do _not_ install, but rather specify the location of the local/new nouveau_dri.so via the LIBGL_DRIVERS_PATH variable.

ex.
LIBGL_DRIVERS_PATH=/home/emo/mesa/build/lib/gallium firefox >& fdo73358.log

If there is no output, change the printf from stdout to stderr

s/printf(/fprintf(stderr,/

Here's a patch I made: http://patchwork.freedesktop.org/patch/18063/

Would be interesting to see if it helps your situation. Note that if you install mesa (and thus libvdpau_nouveau.so) into not-/usr/lib, then you will need to install libvdpau to that same location and use LD_LIBRARY_PATH. Otherwise it'll load the system libvdpau which will have hardcoded locations it searches for libvdpau_$driver.so.

BTW, the supertuxkart thing is unrelated. It's trying to use a 16-bit depth buffer with a 32-bit color buffer, which the card doesn't support. Unfortunately gallium doesn't make it possible to reject such a fbo (since individually the buffers are supported, just not together), and patches I wrote to enable this were rejected.

I'm having a hard time reproducing this. The libpepflashplayer.so used to crash reliably but it won't now. Furthermore, I changed the first patch to use fprintf(stderr, instead of printf( but the compiler gives some warnings.

  CC       nv30_state_validate.lo
nv30/nv30_state_validate.c: In function ‘nv30_validate_fb’:
nv30/nv30_state_validate.c:99:11: warning: passing argument 1 of ‘printf’ from incompatible pointer type [enabled by default]
           util_format_name(p_format), p_format, rt_format, hw_format);
           ^
In file included from ./nv30/nv30_screen.h:4:0,
                 from ./nv30/nv30_context.h:7,
                 from nv30/nv30_state_validate.c:32:
/usr/include/stdio.h:362:12: note: expected ‘const char * restrict’ but argument is of type ‘struct _IO_FILE *’
 extern int printf (const char *__restrict __format, ...);
            ^
  CC       nv30_clear.lo
nv30/nv30_clear.c: In function ‘nv30_clear_render_target’:
nv30/nv30_clear.c:128:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘const char *’ [-Wformat=]
    util_format_name(ps->format), ps->format, rt_format, hw_format);
    ^
nv30/nv30_clear.c:128:4: warning: too many arguments for format [-Wformat-extra-args]

It compiles and runs, but I'm not getting output on the terminal.

I did this as well:

[gebruiker@delta mesa]$ cd mesa
[gebruiker@delta mesa]$ export LD_LIBRARY_PATH=./lib/gallium/:$LD_LIBRARY_PATH
[gebruiker@delta mesa]$ export LIBGL_DRIVERS_PATH=./lib/gallium/
[gebruiker@delta mesa]$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
nv30_validate_fb: p_format 2, rt_format 105, hw 5
�(���I[��I[��I[��I[��I[��I[��I[��I[�[gebruiker@delta mesa]$ 

I do not get this output with either chromium or firefox. I guess the garbage output has something to do with the above warnings?

FWIW, I downloaded mesa git and moved to 10.0.2 as requested.

Created attachment 92277 [details]
Patch replacing apitrace/ltrace for debugging (modified for stderr)

Here's my modified version of the patch (in case you spot any errors).

Created attachment 92278 [details]
Print screen of garbled screen when using flash

I updated Xorg and some components a while ago. It seems that Xorg does not crash as fast anymore. Instead the flash video looks all garbled.

@Ilia Mirkin

Did this:

git clone git://anongit.freedesktop.org/mesa/mesa mesa
cd mesa
git checkout mesa-10.0.2
wget http://patchwork.freedesktop.org/patch/18063/raw/ -O ../patch_2.txt
patch -p1 < ../patch_2.txt
./autogen.sh --with-gallium-drivers=nouveau --enable-shared-glapi --enable-texture-float --enable-vdpau --disable-egl --enable-dri --disable-dri3 --disable-gbm --disable-xvmc --with-dri-drivers=nouveau
make

export LD_LIBRARY_PATH=./lib/gallium/:$LD_LIBRARY_PATH
export LIBGL_DRIVERS_PATH=./lib/gallium/
chromium --ppapi-flash-path=/home/gebruiker/Documenten/Ronald/flash/libgcflashplayer-11.2.202.235-19.0.1084.46-135956.so

Youtube still shows a garbled video like in comment #23 . Furthermore, dmesg fills with errors once again:

[ 8569.194470] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[578]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[ 8569.194563] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
[ 8569.194574] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[578]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120

To clarify comment #21: Not being being able to reproduce means that the session does not crash anymore. I get a garbled screen (see comment #23) instead.

Dmesg still fills with the same errors. Only libgcflashplayer.so (PPAPI) seems to suffer from this. The 'old style' (NPAPI) flashplayer (older version) plays the video's just fine for now.

(In reply to comment #24)
> @Ilia Mirkin
> 
> Did this:
> 
> git clone git://anongit.freedesktop.org/mesa/mesa mesa
> cd mesa
> git checkout mesa-10.0.2
> wget http://patchwork.freedesktop.org/patch/18063/raw/ -O ../patch_2.txt
> patch -p1 < ../patch_2.txt
> ./autogen.sh --with-gallium-drivers=nouveau --enable-shared-glapi
> --enable-texture-float --enable-vdpau --disable-egl --enable-dri
> --disable-dri3 --disable-gbm --disable-xvmc --with-dri-drivers=nouveau
> make
> 
> export LD_LIBRARY_PATH=./lib/gallium/:$LD_LIBRARY_PATH
> export LIBGL_DRIVERS_PATH=./lib/gallium/
> chromium
> --ppapi-flash-path=/home/gebruiker/Documenten/Ronald/flash/libgcflashplayer-
> 11.2.202.235-19.0.1084.46-135956.so

I think you meant to say LD_LIBRARY_PATH=./lib

Also, since I'm pretty sure that this is all caused by vdpau, in order for it to use the libvdpau_nouveau.so that you generated, you need to have a libvdpau in that *same* lib directory. Otherwise it'll get loaded from a fixed path. (You can run strace -f -e open to confirm.)

> 
> Youtube still shows a garbled video like in comment #23 . Furthermore, dmesg
> fills with errors once again:
> 
> [ 8569.194470] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[578]] subc 7
> class 0x0697 mthd 0x0208 data 0x00000120
> [ 8569.194563] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR
> nstatus: BAD_ARGUMENT
> [ 8569.194574] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[578]] subc 7
> class 0x0697 mthd 0x0208 data 0x00000120

Mind testing out http://patchwork.freedesktop.org/patch/18063/ ? (Note, again, make _sure_ that the 'new' version of libvdpau_nouveau.so is being loaded, not the old one.)

(In reply to comment #26)

> I think you meant to say LD_LIBRARY_PATH=./lib

The vdpau_nouveau.so was sitting in mesa/lib/gallium. But it turns out that even with your suggestion it would not load. What I did was this:

- vdpau_nouveau.so was sitting in ~/mesa/lib/gallium
- cd ~/mesa/lib/gallium
- git clone git://people.freedesktop.org/~aplattner/libvdpau
- ./configure --with-module-dir=~/mesa/lib/gallium
- cd ..
- ln -s -t . libvdpau/src/.libs/libvdpau.so
- ln -s libvdpau.so libvdpau.so.1
- ln -s libvdpau.so libvdpau.so.1.0.0
- cd ~/mesa/lib/gallium

And reran the tests. Same garbled screen as in comment #23. Sorry.

I went to verify I did thinks right so I ran inotifywait on the system vdpau and my own build of vdpau:

[gebruiker@delta ~]$ inotifywait -m ~/mesa/lib/gallium/libvdpau_nouveau.so
Setting up watches.
Watches established.
mesa/lib/gallium/libvdpau_nouveau.so OPEN 
mesa/lib/gallium/libvdpau_nouveau.so ACCESS 
mesa/lib/gallium/libvdpau_nouveau.so CLOSE_NOWRITE,CLOSE 
mesa/lib/gallium/libvdpau_nouveau.so OPEN 
mesa/lib/gallium/libvdpau_nouveau.so ACCESS 
mesa/lib/gallium/libvdpau_nouveau.so CLOSE_NOWRITE,CLOSE 

( other terminal )

[gebruiker@delta mesa]$ inotifywait -rm /usr/lib/vdpau/
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.

( empty -> not used -> good! )

So I can fairly confidently say that your patch did not fix the issue.

> Also, since I'm pretty sure that this is all caused by vdpau, in order for
> it to use the libvdpau_nouveau.so that you generated, you need to have a
> libvdpau in that *same* lib directory. Otherwise it'll get loaded from a
> fixed path. (You can run strace -f -e open to confirm.)

Yes, thanks for the tip. I used strace and inotifywait.

> Mind testing out http://patchwork.freedesktop.org/patch/18063/ ? (Note,
> again, make _sure_ that the 'new' version of libvdpau_nouveau.so is being
> loaded, not the old one.)

Yes, you suggested this in comment #19 (or did you accidentaly ment another patch?)

(In reply to comment #27)
> (In reply to comment #26)
> 
> > I think you meant to say LD_LIBRARY_PATH=./lib
> 
> The vdpau_nouveau.so was sitting in mesa/lib/gallium. But it turns out that
> even with your suggestion it would not load. What I did was this:

Right, because libvdpau hardcodes its paths, it doesn't just try to dlopen(). Note that normally the libvdpau_$driver.so are NOT in a dlopen-able place, which is why it has to do this.

> 
> - vdpau_nouveau.so was sitting in ~/mesa/lib/gallium
> - cd ~/mesa/lib/gallium
> - git clone git://people.freedesktop.org/~aplattner/libvdpau
> - ./configure --with-module-dir=~/mesa/lib/gallium
> - cd ..
> - ln -s -t . libvdpau/src/.libs/libvdpau.so
> - ln -s libvdpau.so libvdpau.so.1
> - ln -s libvdpau.so libvdpau.so.1.0.0
> - cd ~/mesa/lib/gallium
> 
> And reran the tests. Same garbled screen as in comment #23. Sorry.

Blast! What about messages in dmesg? Do you still see

subc 7 class 0x0697 mthd 0x0208 data 0x00000120

Or are those completely gone? Those are the messages I would expect to have seen fixed by my patch.

Also, since you're on NV34, you don't get NPOT textures either (those came with NV40). I wonder if the vdpau st deals with those. Hmm... it never asks the driver whether it has NPOT textures or not, which probably means not-good, and most likely accounts for your crashes. I need to look into exactly what the NPOT restriction should be...

> > Mind testing out http://patchwork.freedesktop.org/patch/18063/ ? (Note,
> > again, make _sure_ that the 'new' version of libvdpau_nouveau.so is being
> > loaded, not the old one.)
> 
> Yes, you suggested this in comment #19 (or did you accidentaly ment another
> patch?)

Wow, I must have spaced out there. My bad. It indeed is the same patch, but I had forgotten I already asked you about it :)

> > And reran the tests. Same garbled screen as in comment #23. Sorry.
> 
> Blast! What about messages in dmesg? Do you still see
> 
> subc 7 class 0x0697 mthd 0x0208 data 0x00000120

Yes, (notice that the fourth line is different)

[  460.500905] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT
[  460.500936] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[1377]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[  460.500990] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: LIMIT_COLOR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[  460.501002] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[1377]] subc 7 class 0x0697 mthd 0x0204 data 0x00980000
[  460.501306] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[  460.501320] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[1377]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[  460.501415] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[  460.501427] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[1377]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[  460.501819] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[  460.501834] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[1377]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120
[  460.501925] nouveau E[  PGRAPH][0000:01:00.0]  ERROR nsource: DATA_ERROR nstatus: BAD_ARGUMENT PROTECTION_FAULT
[  460.501937] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [chromium[1377]] subc 7 class 0x0697 mthd 0x0208 data 0x00000120


> Or are those completely gone? Those are the messages I would expect to have
> seen fixed by my patch.

The machine also hangs again.

> Also, since you're on NV34, you don't get NPOT textures either (those came
> with NV40). I wonder if the vdpau st deals with those. Hmm... it never asks
> the driver whether it has NPOT textures or not, which probably means
> not-good, and most likely accounts for your crashes. I need to look into
> exactly what the NPOT restriction should be...

I didn't even knew libvdpau was provided for nv34. Let me know if I can help. This machine just got upgraded from 512 to 1536 megs of ram making it pretty usable again. Testing is a lot easier as well, let me know when you have something new.

> > Yes, you suggested this in comment #19 (or did you accidentaly ment another
> > patch?)
> 
> Wow, I must have spaced out there. My bad. It indeed is the same patch, but
> I had forgotten I already asked you about it :)

No problem.

(In reply to comment #29)
> > > And reran the tests. Same garbled screen as in comment #23. Sorry.
> > 
> > Blast! What about messages in dmesg? Do you still see
> > 
> > subc 7 class 0x0697 mthd 0x0208 data 0x00000120
> 
> Yes, (notice that the fourth line is different)

Very unfortunate. I guess I'll have to look for a different cause :(

> I didn't even knew libvdpau was provided for nv34. Let me know if I can
> help. This machine just got upgraded from 512 to 1536 megs of ram making it
> pretty usable again. Testing is a lot easier as well, let me know when you
> have something new.

VDPAU = Video Decoding AND Presentation. What's being used is the presentation aspect -- it's essentially like Xv, but fancier. And I believe it's what's hanging stuff. Quick test -- remove any instance of libvdpau_nouveau.so(.*) -- does everything become better? If not, it must be coming in via OpenGL or something.

While there is video decoding HW on the NV34, it's only semi-supported; I've disabled this support since it appears to hang my NV34 and I haven't identified the cause. I believe it's actually something related to the NPOTness of the textures, but I don't know for sure. My plan was to create a standalone VPE1-supporting libXvMC library (well, the libXvMCW interface) that renders using the hw video overlay (available on pre-NV40 cards), but that requires some libdrm and possibly kernel changes to support the VPE1 command stream. One could, conceivably, create a VPE2-using standalone libXvMC library that uses the hw overlay to render instead of the 3d hardware. However the only cards that have VPE2 and are pre-NV40 are NV31 and NV34. The rest of the NV3x's (and NV17/NV18) have VPE1 only.

If you're interested in working on this, come over to #nouveau@freenode, would be happy to provide some pointers.

Yes, I relocated (In reply to comment #30)
> (In reply to comment #29)
> > > > And reran the tests. Same garbled screen as in comment #23. Sorry.
> > > 
> > > Blast! What about messages in dmesg? Do you still see
> > > 
> > > subc 7 class 0x0697 mthd 0x0208 data 0x00000120
> > 
> > Yes, (notice that the fourth line is different)
> 
> Very unfortunate. I guess I'll have to look for a different cause :(

Thomas Edison 

..."I have not failed 700 times. I have not failed once. I have
succeeded in proving that those 700 ways will not work. When I have
eliminated the ways that will not work, I will find the way that will
work."

> > I didn't even knew libvdpau was provided for nv34. Let me know if I can
> > help. This machine just got upgraded from 512 to 1536 megs of ram making it
> > pretty usable again. Testing is a lot easier as well, let me know when you
> > have something new.
> 
> VDPAU = Video Decoding AND Presentation. What's being used is the
> presentation aspect -- it's essentially like Xv, but fancier. And I believe
> it's what's hanging stuff. Quick test -- remove any instance of
> libvdpau_nouveau.so(.*) -- does everything become better? If not, it must be
> coming in via OpenGL or something.

Yes, moving /usr/lib/vdpau away makes the kernel errors go away. Which is what I did right now. So it's vdpau (narrows it down I hope?).

Furthermore, when I do that I get this message:

Failed to open VDPAU backend libvdpau_nouveau.so: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet

(cannot open shared library: File or directory does not exist)

Which makes me wonder why error messages like these get through, despite all the attempts with fprintf(stderr within Emil's patch xD yielding 0 results.

> While there is video decoding HW on the NV34, it's only semi-supported; I've
> disabled this support since it appears to hang my NV34 and I haven't
> identified the cause. I believe it's actually something related to the
> NPOTness of the textures, but I don't know for sure. My plan was to create a
> standalone VPE1-supporting libXvMC library (well, the libXvMCW interface)
> that renders using the hw video overlay (available on pre-NV40 cards), but
> that requires some libdrm and possibly kernel changes to support the VPE1
> command stream. One could, conceivably, create a VPE2-using standalone
> libXvMC library that uses the hw overlay to render instead of the 3d
> hardware. However the only cards that have VPE2 and are pre-NV40 are NV31
> and NV34. The rest of the NV3x's (and NV17/NV18) have VPE1 only.
> 
> If you're interested in working on this, come over to #nouveau@freenode,
> would be happy to provide some pointers.

I would love to help, but I cannot code. To this point, I have always gotten away by reading lot's of (badly written) manpages and bash scripting. If you bend with the system it will be nice to you. Never had the courage to touch a line of C code. Maybe it's time ...

Is it possible to contribute after an initial phase of self study? What kind of topics would I need to get familiair with?

Created attachment 92316 [details] [review]
vdpau patch

OK, here's a patch that

(a) disables vdpau for devices that don't support NPOT textures
(b) error handling cleanups when creating surfaces
(c) the thing i did before which checking surface params before making them

Now, I believe that part (a) should essentially disable VDPAU for you. When you build it, run vdpauinfo -- it should say something like "no devices" or "error creating device" or something. Hopefully flash can also deal with that error.

(In reply to comment #32)
> Created attachment 92316 [details] [review] [review]
> vdpau patch
> 
> OK, here's a patch that
> 
> (a) disables vdpau for devices that don't support NPOT textures
> (b) error handling cleanups when creating surfaces
> (c) the thing i did before which checking surface params before making them
> 
> Now, I believe that part (a) should essentially disable VDPAU for you. When
> you build it, run vdpauinfo -- it should say something like "no devices" or
> "error creating device" or something. Hopefully flash can also deal with
> that error.

Yes,

[gebruiker@delta mesa]$ ../vdpauinfo/vdpauinfo
display: :0.0   screen: 0
Error creating VDPAU device: 1

I get no more errors in dmesg and no more hangs. For now, I disabled hardware acceleration inside the player itself using the lef-click menu. Your patch works as intended.

I take it there is no other way for me to contribute??

Thank you.

(In reply to comment #33)
> (In reply to comment #32)
> > Created attachment 92316 [details] [review] [review] [review]
> > vdpau patch
> > 
> > OK, here's a patch that
> > 
> > (a) disables vdpau for devices that don't support NPOT textures
> > (b) error handling cleanups when creating surfaces
> > (c) the thing i did before which checking surface params before making them
> > 
> > Now, I believe that part (a) should essentially disable VDPAU for you. When
> > you build it, run vdpauinfo -- it should say something like "no devices" or
> > "error creating device" or something. Hopefully flash can also deal with
> > that error.
> 
> Yes,
> 
> [gebruiker@delta mesa]$ ../vdpauinfo/vdpauinfo
> display: :0.0   screen: 0
> Error creating VDPAU device: 1
> 
> I get no more errors in dmesg and no more hangs.

Great! I've posted the patch as a series, hopefully it should be in mesa.git soonish.

> For now, I disabled
> hardware acceleration inside the player itself using the lef-click menu.

Hmmm... that shouldn't be necessary -- no hw acceleration will be provided anyways.

> Your patch works as intended.
> 
> I take it there is no other way for me to contribute??

This is not the proper forum to discuss that. Come join us in #nouveau @ irc.freenode.net and we can see if there's overlap between your skillset/time commitment/etc, and things that would be helpful for nouveau. Or start a discussion at nouveau@lists.freedesktop.org if you dislike IRC.

(In reply to comment #34)

> > I get no more errors in dmesg and no more hangs.
> 
> Great! I've posted the patch as a series, hopefully it should be in mesa.git
> soonish.
> 

Cool.

> > For now, I disabled
> > hardware acceleration inside the player itself using the lef-click menu.
> 
> Hmmm... that shouldn't be necessary -- no hw acceleration will be provided
> anyways.

Well, it *does* work around the problem (!). It's a temporary substitute for your patch.

> > Your patch works as intended.
> > 
> > I take it there is no other way for me to contribute??
> 
> This is not the proper forum to discuss that. Come join us in #nouveau @
> irc.freenode.net and we can see if there's overlap between your
> skillset/time commitment/etc, and things that would be helpful for nouveau.
> Or start a discussion at nouveau@lists.freedesktop.org if you dislike IRC.

Okay.

My patch series is upstream now, and the NPOT bit is tagged for stable, so 10.0.3 should have it, hopefully. Thanks for testing!