Created attachment 35643 [details]
Xorg log (1.7.6-3, 0.0.16, 2.4.20, 2.6.34-rc5)

Moving to Nouveau.

Could you please retest with a recent kernel?
(The bug went unnoticed as it wasn't linked to Nouveau.)

Tested with Puppy Linux with kernel 3.14.20.  This is with Tahrpup 6.0, with an updated kernel released by the maintainer of Tahrpup.

The Xserver has no mouse pointer, and displays only vertical stripes.  But ctrl-alt-F2 worked and I can still use the text screen console.  Looked at /var/log/messages and saw PROTECTION_FAULT errors.

Tahrpup 6.0 is here:
http://distro.ibiblio.org/puppylinux/puppy-tahr/iso/tahrpup%20-6.0-CE/tahr-6.0-CE_PAE.iso
And the update to kernel 3.14.20 is here:
http://distro.ibiblio.org/puppylinux/puppy-tahr/kernels/kernel-3.14.20_PAE_update.tar.xz

I see that there is an newer update to kernel 3.17, which I will try next.

Sample of the error messages:

Jan 26 16:04:59 puppypc29622 user.err kernel: nouveau E[  PGRAPH][0000:01:00.0]  NOTIFY nsource: PROTECTION_ERROR nstatus: PROTECTION_FAULT
Jan 26 16:04:59 puppypc29622 user.err kernel: nouveau E[  PGRAPH][0000:01:00.0] ch 1 [X[10566]] subc 2 class 0x0042 mthd 0x0180 data 0x00003a04

Created attachment 112819 [details]
/var/log/messages, Puppy Linux, kernel version 3.14.20

Created attachment 112820 [details]
/var/log/Xorg.0.log, Puppy Linux, kernel version 3.14.20

Created attachment 112821 [details]
/var/log/messages, Puppy Linux, kernel version 3.14.20

Created attachment 112822 [details]
/var/log/Xorg.0.log, Puppy Linux, kernel version 3.14.20

Tried Puppy Linux 6 with Linux kernel version 3.17.7, and got the identical errors as with 3.14.20.

I can't say if the PFIFO_CACHE_ERROR is still present, because I can't get past this error to run any XWindows apps.  X is running, it has not crashed, but the display is corrupted and unusable.

(In reply to Brent from comment #8)
> Tried Puppy Linux 6 with Linux kernel version 3.17.7, and got the identical
> errors as with 3.14.20.
> 
> I can't say if the PFIFO_CACHE_ERROR is still present, because I can't get
> past this error to run any XWindows apps.  X is running, it has not crashed,
> but the display is corrupted and unusable.

Those protection errors are expected... there's some minor difference between NV04 and NV05, and so those happen.... iirc with the NOP handle or class or something. I looked into it at one point and decided I didn't care enough (see https://bugs.freedesktop.org/show_bug.cgi?id=68854). Does it cause any actual issues though?

(In reply to Brent from comment #8)
> X is running, it has not crashed, but the display is corrupted and unusable.

Oh, that's the issue. OK. At what point does the display become corrupted? Can you describe the corruption, and/or take a photo?

The display shows thin vertical stripes.  The very top line is solid, the rest of the lines alternate between white and light gray.  Best as I can make out, the stripes are 3 pixels wide.  I do not see a mouse pointer.  But if I move the mouse to the upper left and try a right click, the left side of the screen turns black, and if I hit Esc while this black area is on the screen, it turns back to the stripes.  I'll have to run Puppy Linux on another computer to see what menu I'm calling up when I right click, but X is accepting mouse and keyboard input.

The display is corrupt at the start.  After Puppy leaves the text console during boot, the screen goes black for a minute, then straight to the vertical stripes.

Created attachment 113332 [details]
picture of screen in 800x600 mode

What happened to ctrl-alt + and - to change resolutions?  Was able to switch between 1024x768 and 800x600 with xrandr.

So by the sounds of it, we broke the display stuff at some point between pre-history (i.e. before nouveau was in mainline) and... now. I'm fairly sure that it's a fairly self-contained problem -- my NV05 TNT2 M64 works fine (or at least did recently, I think I last tested after 3.10 or so). Another user's NV04 also worked OK on linux-3.9 (from bug 68854), although it was the Creative Labs one. However he also had the resolution issue (maxing out at 1024x768).

You have one of the (infamous?) BMP v0 vbioses, may be interesting to attach it to this bug, although I sincerely doubt that is the source of the issues (before BMP v2 or so, we just ignore it entirely). Without nouveau loaded, you can get it from /sys/kernel/debug/dri/0/vbios.rom .

The unfortunate reality here is that you are in posession of fairly unique piece of hardware, and that (I believe) similar HW works fine. So... it's something "funny" going on. 

You might try booting with

nouveau.debug=debug drm.debug=14

and capturing the kernel messages from that. Perhaps something interesting will come up.

Yes, someone else said that hardware was unusual.  But Nouveau did work with it, at elast somewhat, in the later 2.6 kernels.  If it helps at all, the Diamond Viper V550 video card reports a version of 1.93E during POST.

Tried older versions of Puppy Linux, and ran into other problems.  First, the older Puppy tried to load the saved configuration files from the newer Puppy.  Once I stopped that, I got this.  In Xorg.0.log, 5.3.3 Slacko Puppy says:

failed to load kernel module "nouveau"

Puppy falls back to the vesa driver, which, while very slow, does work, and at 1280x1024.

If I do "modprobe nouveau" I get 7 error messages of the form "WARNING: Error inserting xxx (/lib/modules/3.1.10-slacko_4gA/kernel/drivers/.." where xxx is:

button
wmi
agpgart
drm
ttm
drm_kms_helper
nouveau

Tried the debug boot parameters you suggested, with Slacko Puppy and Tahr Puppy but they had no effect.  There is no debug subdirectory in /proc/sys/kernel.  No doubt the stock Puppy kernel does not have debugging included.  Suppose I'll have to build my own kernel to get that, which means a good bit of work.

(In reply to Brent from comment #15)
> Tried the debug boot parameters you suggested, with Slacko Puppy and Tahr
> Puppy but they had no effect.  There is no debug subdirectory in
> /proc/sys/kernel.  No doubt the stock Puppy kernel does not have debugging
> included.  Suppose I'll have to build my own kernel to get that, which means
> a good bit of work.

/sys/kernel/debug not /proc/sys/kernel/debug

Created attachment 113580 [details]
/var/log/messages with debug, Puppy Linux, kernel version 3.17.7

There is a /sys/kernel/debug directory, but it is empty.  However, /var/log/messages has a lot more lines, so I have attached a copy.

Created attachment 113581 [details]
Xorg.0.log with debug, Puppy Linux 6 with kernel 3.17.7

Been trying to track down the oldest kernel that shows the corrupted display, but have run into further problems.  It seems nouveau with the early 3.x kernels does not work at all on this NV04 video card.  I think 3.4 is the first version with nouveau included in the kernel?  Have tried 3.1 (Slacko Puppy 5.3.3), a 3.4.106 kernel I built on the Arch Linux system with the 2.6.35 kernel that does work, and 3.5 (AntiX Linux 12).  Puppy and AntiX fall back to the VESA driver, and Arch with the custom 3.4.106 kernel and X 1.8.1.902 just drops to a text screen.  All try to use nouveau, and all give the same "(EE) [drm] failed to open device" message in Xorg.0.log.

(In reply to Brent from comment #19)
> Been trying to track down the oldest kernel that shows the corrupted
> display, but have run into further problems.  It seems nouveau with the
> early 3.x kernels does not work at all on this NV04 video card.  I think 3.4
> is the first version with nouveau included in the kernel?  Have tried 3.1
> (Slacko Puppy 5.3.3), a 3.4.106 kernel I built on the Arch Linux system with
> the 2.6.35 kernel that does work, and 3.5 (AntiX Linux 12).  Puppy and AntiX
> fall back to the VESA driver, and Arch with the custom 3.4.106 kernel and X
> 1.8.1.902 just drops to a text screen.  All try to use nouveau, and all give
> the same "(EE) [drm] failed to open device" message in Xorg.0.log.

nouveau was first merged in 2.6.33 as a staging driver. It moved out of staging in kernel 3.4. It's possible that your userspace expects a newer abi than the old nouveau provided.

This feels like some sort of tiling fail. Do things work better if you boot with

nouveau.noaccel=1 nouveau.nofbaccel=1

Tried the noaccel and nofbaccel kernel options under Puppy Linux 6.0 with the 3.17.7 kernel.  Didn't make any difference to the display, it is still bad, in the same way as without those options.  Xorg.0.log confirms that acceleration is indeed off.  It is mostly the same as the log I uploaded here, except after the line "(--) Depth 24 pixmap format is 32 bpp", I see:

(EE) NOUVEAU(0): Error creating GPU channel: -19
(EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
(==) NOUVEAU(0): Backing store enabled
...

I also tried kernel 3.10.71 on the Arch system.  It was no different than 3.4.106-- [drm] failed to open device.  Yes, I know there could be an API mismatch, and maybe the 3.4 and 3.10 kernels would work with a more recent XWindows.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/7.