Nouveau - Feb 2009 - [Bug 20341] New: NV31 lockup

http://bugs.freedesktop.org/show_bug.cgi?id=20341

           Summary: NV31 lockup
           Product: xorg
           Version: git
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: detringj at gmail.com
         QAContact: xorg-team at lists.x.org


Created an attachment (id=23346)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=23346)
Xorg.0.log

I'm seeing a lockup when images are changed on screen.  The display will
freeze
and all mouse clicks and keyboard input is lost, including keylock toggles. 
Curiously, the pointer will continue tracking mouse movement.  Attached X
clients also seem to be happy remaining connected.

In practice, this happens quite a bit in Opera when switching tabs or scrolling
web pages with large images.  I've found a test case using "x11perf
-putimage500" which triggers the same bug (I think?) after one or two
seconds
of drawing the test pattern.

Connecting to the machine over the network shows X taking 100% CPU time. 
Attaching strace shows a rapidly repeating output of:
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])

I can recover to a working system with a "killall -9 X; vbetool post;
startx"
stanza, but that's really not something I enjoy doing once an hour.  ;-)


My hardware is
> lspci
01:00.0 VGA compatible controller: nVidia Corporation NV31 [GeForce FX 5600
Ultra] (rev a1) 
> lspci -n
01:00.0 0300: 10de:0311 (rev a1)]
on a VIA KT133 on AGP.

My software is:
Linux 2.6.27.2 (vanilla)
Xserver 1.6.0
xf86-video-nouveau git master 1c4a284a80ebed9f9d1e01c47b929481801566b5
libdrm + nouveau.ko + drm.ko git master
e96fc62e5339e3c8c8944dfe9f5163f769bccbd8
The system is otherwise a Slackware-current installation upgraded with just
enough Xorg componentry to build the new X server.

Thanks,
Jason


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #1 from Jason Detring <detringj at gmail.com>  2009-02-26
17:51:49 PST ---
Created an attachment (id=23347)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=23347)
Verbose drm.ko output from dmesg


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #2 from Jason Detring <detringj at gmail.com>  2009-02-26
17:59:07 PST ---
Created an attachment (id=23348)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=23348)
xorg.conf


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #3 from Ben Skeggs <skeggsb at gmail.com>  2009-03-17 20:31:49
PST ---
Does this issue disappear if you add
  Option "CBLocation" "VRAM"
to the device section of your xorg.conf?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #4 from Jason Detring <detringj at gmail.com>  2009-03-17
21:22:55 PST ---
Yes, the lockups appear to have stopped from those two test conditions.

However, there seems to be minor screen corruption on anything more complex
than core fonts.  Text has a slightly "dirty" look to it, and bitmaps
seem to
be "echoed" in vertical stripes.  Some images seem to be echoed in
RGB-ish
stripes.  Others don't follow the "vertical stripe pattern" at all
and are
smudged (I can still make out what a given icon shape was for example), similar
to the text.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #5 from Ben Skeggs <skeggsb at gmail.com>  2009-03-17 21:36:11
PST ---
It's probably still some AGP braindamage causing your corruption.  That
option
just stops it being used for the command stream we send to the GPU.  Are you
able to get me a mmio-trace of how the NVIDIA driver initialises your card?

The instructions at http://nouveau.freedesktop.org/wiki/MmioTrace should help
you with that.

Thanks!
Ben.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #6 from Jason Detring <detringj at gmail.com>  2009-03-18
21:01:37 PST ---
Here's a copy of the e-mail I just sent.

Regards,
Jason

-----

Howdy,

This dump is in reference to fd.o bugzilla ticket 20341.  According to the
submission guidelines, you need the following information:
> uname -a
Linux anduril 2.6.28.8 #2 PREEMPT Wed Mar 18 12:25:17 CDT 2009 i686 AMD
Athlon(tm) Processor AuthenticAMD GNU/Linux
> dmesg | grep -A 5 -i nvidia 
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
nvidia 0000:01:00.0: PCI INT A -> Link[LNKA] -> GSI 3 (level, low) ->
IRQ 3
NVRM: loading NVIDIA UNIX x86 Kernel Module  173.14.18  Mon Mar  2 12:17:40 PST
2009

The Nvidia board in question has one each of a DVI, S-Video, and VGA
connectors.  A Sun 24" LCD is attached on the DVI port.  I'm not sure
what is
meant by "what display mode you used" but I always boot to a VGA
(non-framebuffer) console if that's what you want.

A kernel rebuild was required since the old 2.6.27.2 didn't have debugfs
included.  I took the opportunity to upgrade to 2.6.28.8.

The testing procedure involved increasing the trace entries to 12000000 before
events were no longer dropped.

Enabling MMIO tracing would always lock the system when X was started.  On a
freshly booted system, the lockup would happen extremely early in X startup,
resulting in no data beyond the initial PCIDEV entries being written to the
text file.  I was able to start capturing data by first "priming" the
graphics
hardware by starting X, exiting, unloading nvidia.ko, then setting up the MMIO
trace knobs and restarting X.

NVidia's GLX implementation combined with the running tracer seemed to
freeze X
midway through startup.  By disabling GLX, I was able to reach a window
manager.  X promptly froze afterward due to reasons unknown.

Despite all this, I'm hoping there is enough data to determine how the blob
sets up AGP for my system.  If not, I'll be happy to make another attempt.

Thanks,
Jason


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #7 from Pekka Paalanen <pq at iki.fi>  2009-03-19 10:05:45 PST
---
Mmiotrace recently got some important fixes that just might help you. If you
could try the latest rc kernel (or at least 2.6.29-rc7), I would be very
interested to hear how it behaves.

If it still locks up, it would be good to investigate, but I don't know if
you
have the time or the tools (serial terminal, netconsole, or debugging via
firewire). Please contact me personally, if you want to help in debugging
mmiotrace.

Thanks.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20341





--- Comment #8 from Jason Detring <detringj at gmail.com>  2009-03-19
21:54:43 PST ---
Another e-mail sent to mmio.dumps:
-----
This is a second attempt at tracing X startup.
> uname -a
Linux anduril 2.6.29-rc8 #1 PREEMPT Thu Mar 19 22:19:24 CDT 2009 i686 AMD
Athlon(tm) Processor AuthenticAMD GNU/Linux

I am using the same driver (173.14.18 "legacy") as before.

I experienced no lockups during this trace, even with GLX enabled.  Thanks for
the suggestion!  The only default I needed to change was increasing
buffer_size_kb to 20000.

Cheers,
Jason


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=20341

DarkRaven <drdarkraven at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|medium                      |high

--- Comment #9 from DarkRaven <drdarkraven at gmail.com> 2010-08-13
00:13:54 PDT ---
Same problem.
After a kernel update (git 20100807).
But I'm using a NV34 graphic card(FX5200).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #10 from DarkRaven <drdarkraven at gmail.com> 2010-08-14
21:04:54 PDT ---
No such problem with nouveau kernel tree;
seems that nouveau doesn't get along well with code in the upstream

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #11 from Albert Pool <albertpool at solcon.nl> 2011-10-17
08:50:05 PDT ---
My NV34 (XFX GeForce FX 5200) suffers from this problem too; but the mouse
pointer turns into a white square with black blur also. So I filed it as a
seperate bug #41892. Feel free to mark that one as duplicate when you think
it's the same problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=20341

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Ilia Mirkin <imirkin at alum.mit.edu> ---
It appears that this bug report has laid dormant for quite a while. Sorry we
haven't gotten to it. Since we fix bugs all the time, chances are pretty
good
that your issue has been fixed with the latest software. Please give it a shot.
(Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git
versions.) If upgrading to the latest isn't an option for you, your
distro's
bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs
that haven't seen updates since 2011. If the original issue remains, please
make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/
for what we need to see, and re-open this one.

Thanks,

The Nouveau Team

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130818/d2f6bd25/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

Jason Detring <detringj at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
           Priority|high                        |medium

--- Comment #13 from Jason Detring <detringj at gmail.com> ---
Hi Ilia, thanks for the ticket bump.

I pulled this machine out of storage to retest.  The entire graphics stack has
now been upgraded.
- Mesa 9.1.6
- Xorg server 1.13.4
- xf86-video-nouveau 1.0.9
- Linux 3.11-rc6

Nouveau now reports at bootup:
[    6.584942] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x031100a1
[    6.585121] nouveau  [  DEVICE][0000:01:00.0] Chipset: NV31 (NV31)
[    6.585212] nouveau  [  DEVICE][0000:01:00.0] Family : NV30
[    6.587705] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[    6.629569] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[    6.629663] nouveau  [   VBIOS][0000:01:00.0] using image from PRAMIN
[    6.629755] nouveau  [   VBIOS][0000:01:00.0] BMP version 5.27
[    6.630214] nouveau  [   VBIOS][0000:01:00.0] version 04.31.20.52.00
[    6.631927] nouveau W[  PTIMER][0000:01:00.0] unknown input clock freq
[    6.632210] nouveau  [     PFB][0000:01:00.0] RAM type: DDR1
[    6.632340] nouveau  [     PFB][0000:01:00.0] RAM size: 128 MiB
[    6.632429] nouveau  [     PFB][0000:01:00.0]    ZCOMP: 262144 tags
[    6.642148] [TTM] Zone  kernel: Available graphics memory: 93186 kiB
[    6.642277] [TTM] Initializing pool allocator
[    6.642535] nouveau  [     DRM] VRAM: 127 MiB
[    6.642661] nouveau  [     DRM] GART: 128 MiB
[    6.642752] nouveau  [     DRM] BMP version 5.39
[    6.642839] nouveau  [     DRM] DCB version 2.2
[    6.642928] nouveau  [     DRM] DCB outp 00: 01000300 00009c40
[    6.643043] nouveau  [     DRM] DCB outp 01: 02010310 00009c40
[    6.643132] nouveau  [     DRM] DCB outp 02: 01010312 00000000
[    6.643220] nouveau  [     DRM] DCB outp 03: 02020321 00000003
[    6.643663] nouveau  [     DRM] Loading NV17 power sequencing microcode
[    6.645661] nouveau  [     DRM] Saving VGA fonts
[    6.690672] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    6.690779] [drm] No driver support for vblank timestamp query.
[    6.690966] nouveau  [     DRM] 0xE176: Parsing digital output script table
[    6.691764] nouveau  [     DRM] 0 available performance level(s)
[    6.691859] nouveau  [     DRM] c: core 234MHz memory 501MHz voltage 1220mV
[    6.695827] nouveau  [     DRM] MM: using M2MF for buffer copies
[    6.696202] nouveau  [     DRM] Setting dpms mode 3 on TV encoder (output 3)
[    6.777513] nouveau  [     DRM] allocated 1920x1200 fb: 0x9000, bo cbb04600
[    6.777995] fbcon: nouveaufb (fb0) is primary device
[    6.794224] Console: switching to colour frame buffer device 240x75
[    6.798678] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[    6.798701] nouveau 0000:01:00.0: registered panic notifier
[    6.798729] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on
minor 0


I spent some time ensuring the Nvidia driver (173.14.18) tested earlier in the
ticket was completely removed.  glxinfo now yields
   direct rendering: Yes
   ...
   OpenGL vendor string: nouveau
   OpenGL renderer string: Gallium 0.4 on NV31
   OpenGL version string: 1.5 Mesa 9.1.6
as expected.

Nouveau's 3D engine seems to have no lockup problems.  I spent a few minutes
working my way through xscreensaver's GL modules with no catastrophic
consequences.  It appears only 2D acceleration has issues.

Running "x11perf -putimage500" still locks up the machine.  Symptoms
aren't
exactly the same as earlier in the ticket, but the end result still is loss of
a usable UI.
1. X freezes.  Local input is dropped.  Mouse pointer freezes, keyboard lights
do not respond to toggles.
2. Machine is not completely frozen, SSH still works.
3. X continues to run for a few seconds, then crashes.  X dies, but the system
does not return to a console.  The keyboard is still locked and the screen is
black.
4. dmesg has been spammed as follows:

[ 5096.360378] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[1337]]
get 0x00037be4 put 0x0001d690 state 0x2000a428 (err: CALL_SUBR_ACTIVE) push
0x00000000
[ 5096.360431] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[1337]]
get 0x0001d690 put 0x0001d6a0 state 0x80000000 (err: INVALID_CMD) push
0x00000000
[ 5096.360475] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[1337]]
get 0x0001d6a0 put 0x0001d6b0 state 0x80000000 (err: INVALID_CMD) push
0x00000000
[ 5096.360516] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[1337]]
get 0x0001d6b0 put 0x0001d6c0 state 0x80000000 (err: INVALID_CMD) push
0x00000000

... lots of above lines repeated ...

[ 5126.421032] nouveau E[ X[1337]] failed to idle channel 0xcccc0000 [X[1337]]
[ 5126.425268] nouveau E[   PFIFO][0000:01:00.0] CACHE_ERROR - ch 1 [X[1337]]
subc 0 mthd 0x0000 data 0x00130000
[ 5141.425031] nouveau E[ X[1337]] failed to idle channel 0xcccc0000 [X[1337]]
[ 5141.457144] ------------[ cut here ]------------
[ 5141.457328] WARNING: CPU: 0 PID: 1337 at
drivers/gpu/drm/nouveau/nouveau_bo.c:151 nouveau_bo_del_ttm+0x66/0x70
[nouveau]()
[ 5141.457334] Modules linked in: lm90 ipv6 lp fuse hid_generic usbhid hid
nouveau mxm_wmi snd_via82xx wmi video ttm drm_kms_helper snd_mpu401_uart
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_page_alloc snd_timer drm
i2c_algo_bit via_agp agpgart uhci_hcd snd soundcore via686a ac97_bus gameport
mperf i2c_viapro processor ppdev e1000 i2c_core shpchp parport_pc ehci_hcd
parport thermal_sys button psmouse serio_raw evdev freq_table hwmon loop [last
unloaded: cpuid]
[ 5141.457413] CPU: 0 PID: 1337 Comm: X Not tainted 3.11.0-rc6 #1
[ 5141.457419] Hardware name: Compaq Compaq PC                      /06E4h,
BIOS 786K1 07/26/2001
[ 5141.457424]  00000000 00000000 c76a3ca0 c150d8e5 c76a3cd0 c10389fa c16233b0
00000000
[ 5141.457434]  00000539 ccc512f4 00000097 ccc10a16 ccc10a16 c5ca9800 c5ca9824
00006240
[ 5141.457444]  c76a3ce0 c1038ac2 00000009 00000000 c76a3cf8 ccc10a16 c76a3cf8
cc88190f
[ 5141.457454] Call Trace:
[ 5141.457480]  [<c150d8e5>] dump_stack+0x16/0x18
[ 5141.457497]  [<c10389fa>] warn_slowpath_common+0x7a/0xa0
[ 5141.457543]  [<ccc10a16>] ? nouveau_bo_del_ttm+0x66/0x70 [nouveau]
[ 5141.457586]  [<ccc10a16>] ? nouveau_bo_del_ttm+0x66/0x70 [nouveau]
[ 5141.457595]  [<c1038ac2>] warn_slowpath_null+0x22/0x30
[ 5141.457638]  [<ccc10a16>] nouveau_bo_del_ttm+0x66/0x70 [nouveau]
[ 5141.457685]  [<cc88190f>] ? drm_mm_put_block+0x3f/0x50 [drm]
[ 5141.457703]  [<cca385ee>] ttm_bo_release_list+0x6e/0xa0 [ttm]
[ 5141.457714]  [<cca3912e>] ttm_bo_release+0x13e/0x1d0 [ttm]
[ 5141.457725]  [<cca391e5>] ttm_bo_unref+0x25/0x30 [ttm]
[ 5141.457772]  [<ccc13abe>] nouveau_gem_object_del+0x3e/0x60 [nouveau]
[ 5141.457789]  [<cc879ed2>] drm_gem_object_free+0x22/0x30 [drm]
[ 5141.457804]  [<cc87a1e8>] drm_gem_object_release_handle+0x88/0xb0 [drm]
[ 5141.457818]  [<cc87a160>] ? drm_gem_handle_delete+0x110/0x110 [drm]
[ 5141.457840]  [<c1272cb5>] idr_for_each+0xa5/0x100
[ 5141.457854]  [<cc87a160>] ? drm_gem_handle_delete+0x110/0x110 [drm]
[ 5141.457873]  [<cc88748c>] ? drm_fb_release+0x9c/0xb0 [drm]
[ 5141.457889]  [<cc87aa1a>] drm_gem_release+0x1a/0x30 [drm]
[ 5141.457903]  [<cc879469>] drm_release+0x4a9/0x520 [drm]
[ 5141.457917]  [<c110168d>] __fput+0xbd/0x1e0
[ 5141.457924]  [<c11017ed>] ____fput+0xd/0x10
[ 5141.457932]  [<c104fa31>] task_work_run+0x81/0xa0
[ 5141.457941]  [<c10394f8>] do_exit+0x1f8/0x7f0
[ 5141.457957]  [<c1043886>] ? recalc_sigpending+0x16/0x50
[ 5141.457966]  [<c103a81e>] do_group_exit+0x2e/0x70
[ 5141.457976]  [<c1046237>] get_signal_to_deliver+0x157/0x520
[ 5141.457992]  [<c102ce90>] ? vmalloc_sync_all+0xe0/0xe0
[ 5141.458000]  [<c1001829>] do_signal+0x39/0x940
[ 5141.458007]  [<c10ffd40>] ? do_sync_write+0x60/0x90
[ 5141.458045]  [<c11005ad>] ? vfs_write+0x15d/0x1c0
[ 5141.458064]  [<c1072c5b>] ? get_monotonic_coarse+0x6b/0x80
[ 5141.458083]  [<c127e1c8>] ? copy_to_user+0x28/0x40
[ 5141.458093]  [<c1050fe0>] ? posix_get_realtime_coarse+0x20/0x20
[ 5141.458100]  [<c102ce90>] ? vmalloc_sync_all+0xe0/0xe0
[ 5141.458107]  [<c100217d>] do_notify_resume+0x4d/0x80
[ 5141.458118]  [<c1512533>] work_notifysig+0x24/0x31
[ 5141.458124] ---[ end trace 1bc9e065918e3541 ]---

The 'CBLocation' parameter, as mentioned earlier in Comment #3, seems to
have
been removed, so I was unable to test this.
[    98.210] (WW) NOUVEAU(0): Option "CBLocation" is not used

Ben is probably correct when he suggested the chip has an unstable AGP bus. 
Setting the agpmode=0 parameter on the kernel module makes everything nice and
stable (but probably slower on the top end where it is needed).  Is there some
workaround or hardware manipulation ordering that is in Mesa, but hasn't
made
its way into xf86-video-nouveau?


Thanks,
Jason

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130823/2d5c5c45/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #14 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Don't worry about the WARN -- that should get fixed in -rc7 (or you can grab
nouveau/master).

[ 5096.360378] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[1337]]
get 0x00037be4 put 0x0001d690 state 0x2000a428 (err: CALL_SUBR_ACTIVE) push
0x00000000

This is bad. Once this happens, I guess the fifo is out of sync, and that is a
recipe for bad times.

From
https://github.com/envytools/envytools/blob/master/hwdocs/fifo/dma-pusher.txt:

"""
The call command copies dma_get to subr_return, sets subr_active to 1, and
sets dma_get to the target. If subr_active is already set before the call, the
DMA_PUSHER error of type CALL_SUBR_ACTIVE is raised.

The return command copies subr_return to dma_get and clears subr_active. If
subr_active isn't set, it instead raises DMA_PUSHER error of type
RET_SUBR_INACTIVE.
"""

And it looks like we make use of the call functionality in
nouveau_gem_ioctl_pushbuf. The whole scheme seems a bit fragile since we do the
call to some new pushbuf, and then tell userspace to write a return at the
beginning of its next pushbuf. However we might need to do a call in order to
get to that pushbuf, thus causing this condition. But... this code is very
subtle so perhaps I'm missing why this can't happen.

Another thing to try is nouveau.vram_pushbuf on the kernel cmdline -- this
might be what the old CBLocation thing did, not sure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130823/d7f3739f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #15 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Hm, after more careful review, I take back my comment about the scheme being
fragile. (I mean, it's still fragile, but not AS fragile as I thought. I
don't
see a way for it to fail under normal circumstances.)

However one very simple explanation is that a call command is making it onto
the userspace-supplied pushbuf. Let's make sure that this is not the case --
Get valgrind-mmt going (http://nouveau.freedesktop.org/wiki/Valgrind-mmt/), and
run X inside of mmt, and run x11perf until it dies, e.g.

valgrind --tool=mmt --mmt-trace-file=/dev/dri/card0 --mmt-trace-nouveau-ioctls
xinit x11perf -putimage500 -- :1 >& xorg-mmt.log

or something along those lines. (And you can run it in a separate X server so
you don't have to kill your "real" session.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130823/83723e1c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #16 from Jason Detring <detringj at gmail.com> ---
Created attachment 84575
  --> https://bugs.freedesktop.org/attachment.cgi?id=84575&action=edit
Valgrind mmap trace log

Attaching valgrind mmap trace log.

Notes:
- Prior to testing the kernel was upgraded to nouveau/linux-2.6 master @
3b56bba6abaa70d629fccdcf8490e087ea3a1ab4 "drm/nv04/disp: fix framebuffer
pin
refcounting" 2013-08-21 01:37:09 (GMT)

- The agpmode=0 noveau.ko parameter was removed.

- X was especially slow during the test, as expected.  This corresponds to the
note on valgrind-mmt's wiki page: "tracing slows down Xorg considerably
- ~20x"

- X did not crash during this test.  The test procedure was conducted 5 times
to ensure the system didn't have a spurious nonfailure.

- This is a huge logfile.  It will expand to ~220 MB when decompressed.  This
log covers only the first test instance.

- Rerunning the test without valgrind caused the usual lockup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/3fb4b6f0/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|NV31 lockup                 |[NV31] lockup when using
                   |                            |AGP. agpmode=0 fixes it.

--- Comment #17 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Argh. So if it didn't crash with valgrind-mmt, it's a heisenbug :( Some
silly
timing thing... and agpmode=0 either slows it down enough or it's something
to
do with the GART. (I assume agpmode=0 -> 0 GART memory, yes?) In either case,
this is out of my (debugging) league. Thanks for doing the tests, and sorry
they didn't lead to anything easy. I'll leave this open, perhaps some
brave
soul will delve into it.

Did you ever give nouveau.vram_pushbuf=1 a shot (without agpmode=0)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/a9b06c49/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #18 from Jason Detring <detringj at gmail.com> ---
Created attachment 84576
  --> https://bugs.freedesktop.org/attachment.cgi?id=84576&action=edit
firefox corruption

Setting vram_pushbuf=1 seems to help a little.  There are no more lockups, but
graphics get trashed when things start moving fast (x11perf) or big and
complicated (fullscreen web browsers).  Basically, any large volume data
transfers.

After the initial corruption occurs due to the mystery trigger, the system
never really goes back to normal.  There's broken graphics everywhere, even
on
unrelated, small, sparsely-updated windows.

Things look roughly like I remember writing about in Comment #4, so this
parameter is probably doing the same job as 'CBLocation'.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/4fb30d01/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #19 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Yeah, looks like good ol' data corruption. Keeping the pushbuf out of the
corruption avoids lockups, but your images are still messed up. Dunno what to
say other than "agp is broken". Unfortunately I know next to nothing
about its
workings. You could try agpmode=1 or 2 (since it goes into 4x for you).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/84bd2621/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #20 from Jason Detring <detringj at gmail.com> ---
Created attachment 84577
  --> https://bugs.freedesktop.org/attachment.cgi?id=84577&action=edit
x11perf corruption at lockup

Also related--if it helps anybody.  When vram_pushbuf and agpmode are unset
lockups will typically (but not always) show vertical banding on the part of
the screen x11perf was updating.  It looks like the black lines are pulled
apart into red and blue components.  

I'm not sure if x11perf is intended to work this way (drawing color
components
seperately and converging to black), but it seems to be a common symptom that
shows up when things stop moving.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/fcad560a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #21 from mypersonalmailbox1 at mail.com ---
Hi,

I believe VIA Technologies KT133's AGP may be the culprit.

http://us.download.nvidia.com/XFree86/Linux-x86/173.14.09/README/chapter-12.html

KT133's (VT8363) AGP is likely to be generationally be closer to Apollo
Pro133A
(VT82C694X) and KX133 (VT8371).
KT133 and KX133 are fairly similar with KT133 correctly supporting AMD Socket
A.
KX133 supposedly did not implement a certain type of I/O buffer for EV6 bus to
support Socket A, and as a result, it will not be able to support Socket A.
Of course, that issue is not related to AGP, but since KT133 came out fairly
quickly after the EV6 bus issue was acknowledged, it is probably a minor
updated version of KX133.
Nouveau may have to add special code to detect the chipset, and if it detects
certain known VIA Technologies chipsets, it should turn off AGP 4X mode (i.e.,
run at 2X mode).
I do not know if VIA Technologies really fixed the AGP for these chipsets, or
perhaps they fixed it with their newer chipsets.
I hope this information adds to the discussion.

Regards,

fpgahardwareengineer

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/6278a171/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #22 from mypersonalmailbox1 at mail.com ---
Hi,

I guess running the AGP at 2X mode might be a good way to see if this issue is
caused by VIA Technologies' bad implementation of AGP 4X mode around that
time
(1999 to early 2000s, I am sure they fixed the problems on later chipsets.).

Regards,

fpgahardwareengineer

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130825/9c73ae2c/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #23 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Do nouveau.agpmode=1 or agpmode=2 produce the same corruption? I don't
remember
the KT133 as being the most reliable chipset in the world... even the
proprietary driver has the NvAGP setting (or something along those lines). Does
the blob work for you btw? Can you play with forcing different AGP speeds on
it, and/or perhaps figure out from logs what AGP speed it's defaulting to?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130926/aa8f23aa/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #24 from Jason Detring <detringj at gmail.com> ---
Ah, yeah, sorry about that.  This ticket got away from me.  I've got a small
pile of research and resources I'd promised myself to post Real Soon Now. 
So I
guess I should.

I haven't reinstalled the blob, but from what I recall it did work without
problems last time it was loaded.  I don't remember if it left a console
message describing which AGP mode it was running at, but it likely had the 2x
limiter since those drivers were from 2009.

Answering the big question: yes.  Setting agpmode=2 makes things stable. 
Hooray.  But it is sort of a hollow victory to say things work great at
half-speed.  As fpgahardwareengineer said, the problem is likely in the KT133. 
The linked NVIDIA document points to the AGP signalling drive strength being
insufficent.



Following up on "AGP drive strength", I found copies of a document
called the
"BIOS Optimization Guide" floating around the internet.  Parts of it
are
reposted on various bulletin boards [1] [2] [3] [4] and websites [5] [6].  An
older version talks about upping the drive strength from 0xCA or 0xDA to 0xEA
or 0xEE when running GeForce boards.

[1]
http://forums.pcper.com/showthread.php?99837-A7M266-Infinite-Loop-Troubleshooting-(detailed)&p=681721#post681721
[2] http://www.rage3d.com/board/showpost.php?p=1331276579&postcount=2
[3]
http://www.scrigroup.com/calculatoare/tutorials/414/OPTIMIZING-WINDOWS-TIPS64128.php
[4] http://arstechnica.com/civis/viewtopic.php?f=8&t=737578
[5] http://hardwarehell.com/articles/videobios.htm
[6] http://archive.arstechnica.com/guide/building/bios/m-bios-3.html



It also sounds like ATI had a similiar problem and did a thorough investigation
at one point [7].  Their solution was to force down to 2x mode on a chipset
blacklist, and only allow 4x if the "VIA chipset driver" had been
installed.
The advisory document talks about something called the "AGP Read
Synchronization bit" needing set at register 0xAC[6].  I'm guessing
this
chipset driver is some combination of this read synchronization register poke
or the abovementioned drive strength register poke.

[7] http://www.rage3d.com/board/showthread.php?p=1331422045#post1331422045



The ATI document is slightly at odds with the KT133(a) programmer's guide
[8],
which lists 0xAC[6] as "CPU Stall on AGP command FIFO GART Address
Request",
but I didn't see anything else remotely resembling a "Read
synchronization
bit".

[8] http://gkernel.sourceforge.net/specs/via/KT133a.pdf.bz2



So, I tried testing these theories.  It didn't go so well.

1. My BIOS has a pretty spartan set of options since the PC is a mass-market
consumer box.  There was no option to adjust AGP drive strength.  Darn.

2. I tried to adjust the drive strength while Linux was running.  According to
the VIA doc, AGP drive strength is set from PCI register 0xB1[7-0].  It looks
like this entire register is the P Ctrl and N Ctrl values for drive strength. 
On the console with nouveau already loaded, I wrote 0xEA.  Nothing broke, so I
started X.  It had the same lockup as usual.  Darn.  I tried 0xEB through 0xEE
as well.  No good.

3. I tried to adjust the read synchronization bit.  It was already set.  So, no
use in that.

Presently, I'm stuck.  There's not a whole lot else I can think of that
might
be worth trying.  Maybe there's some commit register or reinit procedure
that
needs to take place after writing the drive strength?  I don't know enough
about AGP to figure out where to go next.



At this time, I agree with fpgahardwareengineer's assessment.  A quirk for
those chipsets listed in the ATI doc should be added to allow negotiation up to
AGP 2x maximum.  It is the safest option in all cases.  Maybe at the same time
leave a note in the dmesg describing "buggy chipset detected, defaulting to
2x,
please read fd.o bug 20341 for more information", and also allow agpmode=4
to
override the safe default. I'm not sure whether this quirk should be in
nouveau
or in via-agp.ko, since it sounds like the problem affects all major vendors.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130927/f84d054b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #25 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Created attachment 87854
  --> https://bugs.freedesktop.org/attachment.cgi?id=87854&action=edit
quirk patch

Could you try this patch -- it adds a quirk to limit the mode to 2 for your
particular configuration. This is similar to the quirks that the radeon driver
uses, and was recommended to me as the proper way forward. (Unfortunately, it
seems like *combinations* of chipset/card are the issue, not just the chipset
on its own.)

I guessed about your chipset id, if it doesn't trigger, please attach the
output of lspci -vnn (I'd like to see it for both the chipset and your
card).

You should see a print like

Setting agp speed to 2X. Use agpmode to override.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20131019/f523a7d4/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #26 from Jason Detring <detringj at gmail.com> ---
Works well, just needs the chipset ID swapped.

-       { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8363_0, PCI_VENDOR_ID_NVIDIA,
0x0311, 2 },
+       { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C691_0, PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_GEFORCE_FX_5600_ULTRA, 2 },


> lspci -vnn
00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT82C693A/694x [Apollo
PRO133x] [1106:0691] (rev 03)
        Flags: bus master, medium devsel, latency 0
        Memory at 90000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 2.0
        Capabilities: [c0] Power Management version 2
        Kernel driver in use: agpgart-via

00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
[1106:8305] (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: 80000000-80ffffff
        Prefetchable memory behind bridge: 88000000-8fffffff
        Capabilities: [80] Power Management version 2

00:05.0 Ethernet controller [0200]: Intel Corporation 82541PI Gigabit Ethernet
Controller [8086:107c] (rev 05)
        Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter [8086:1376]
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
        Memory at a0000000 (32-bit, non-prefetchable) [size=128K]
        Memory at a0100000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at 1480 [size=64]
        [virtual] Expansion ROM at 0c000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [e4] PCI-X non-bridge device
        Kernel driver in use: e1000

00:14.0 ISA bridge [0601]: VIA Technologies, Inc. VT82C686 [Apollo Super South]
[1106:0686] (rev 22)
        Flags: bus master, stepping, medium devsel, latency 0
        Kernel driver in use: parport_pc

00:14.1 IDE interface [0101]: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 10)
(prog-if 8a [Master SecP PriP])
        Flags: bus master, medium devsel, latency 64
        [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
        [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
        [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
        [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
        I/O ports at 1440 [size=16]
        Capabilities: [c0] Power Management version 2
        Kernel driver in use: pata_via

00:14.2 USB controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller [1106:3038] (rev 10) (prog-if 00 [UHCI])
        Subsystem: First International Computer, Inc. VA-502 Mainboard
[0925:1234]
        Flags: bus master, medium devsel, latency 66, IRQ 11
        I/O ports at 1400 [size=32]
        Capabilities: [80] Power Management version 2
        Kernel driver in use: uhci_hcd

00:14.3 USB controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller [1106:3038] (rev 10) (prog-if 00 [UHCI])
        Subsystem: First International Computer, Inc. VA-502 Mainboard
[0925:1234]
        Flags: bus master, medium devsel, latency 66, IRQ 11
        I/O ports at 1420 [size=32]
        Capabilities: [80] Power Management version 2
        Kernel driver in use: uhci_hcd

00:14.4 Bridge [0680]: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
[1106:3057] (rev 30)
        Flags: medium devsel, IRQ 9
        Capabilities: [68] Power Management version 2

00:14.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT82C686
AC97 Audio Controller [1106:3058] (rev 20)
        Subsystem: Compaq Computer Corporation Device [0e11:003d]
        Flags: medium devsel, IRQ 10
        I/O ports at 1000 [size=256]
        I/O ports at 1450 [size=4]
        I/O ports at 1454 [size=4]
        Capabilities: [c0] Power Management version 2
        Kernel driver in use: snd_via82xx

01:00.0 VGA compatible controller [0300]: nVidia Corporation NV31 [GeForce FX
5600 Ultra] [10de:0311] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: Chaintech Computer Co. Ltd Device [270f:1946]
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 3
        Memory at 80000000 (32-bit, non-prefetchable) [size=16M]
        Memory at 88000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [60] Power Management version 2
        Capabilities: [44] AGP version 3.0
        Kernel driver in use: nouveau

> uname -a
Linux anduril 3.12.0-rc6 #2 SMP Sat Oct 19 16:47:44 CDT 2013 i686 AMD
Athlon(tm) Processor AuthenticAMD GNU/Linux

> dmesg
...
[ 1786.573538] [drm] hdmi device  not found 1 0 1
[ 1786.573760] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x031100a1
[ 1786.573769] nouveau  [  DEVICE][0000:01:00.0] Chipset: NV31 (NV31)
[ 1786.573776] nouveau  [  DEVICE][0000:01:00.0] Family : NV30
[ 1786.575845] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[ 1786.616891] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[ 1786.616900] nouveau  [   VBIOS][0000:01:00.0] using image from PRAMIN
[ 1786.616909] nouveau  [   VBIOS][0000:01:00.0] BMP version 5.27
[ 1786.617452] nouveau  [   VBIOS][0000:01:00.0] version 04.31.20.52.00
[ 1786.623690] nouveau W[  PTIMER][0000:01:00.0] unknown input clock freq
[ 1786.623718] nouveau  [     PFB][0000:01:00.0] RAM type: DDR1
[ 1786.623724] nouveau  [     PFB][0000:01:00.0] RAM size: 128 MiB
[ 1786.623731] nouveau  [     PFB][0000:01:00.0]    ZCOMP: 262144 tags
[ 1786.636667] nouveau  [  DEVICE][0000:01:00.0] Setting agp speed to 2X. Use
agpmode to override.
[ 1786.636683] agpgart-via 0000:00:00.0: AGP 2.0 bridge
[ 1786.636715] agpgart-via 0000:00:00.0: putting AGP V2 device into 2x mode
[ 1786.636766] nouveau 0000:01:00.0: putting AGP V2 device into 2x mode
[ 1786.640057] [TTM] Zone  kernel: Available graphics memory: 92344 kiB
[ 1786.640064] [TTM] Initializing pool allocator
[ 1786.640118] nouveau  [     DRM] VRAM: 127 MiB
[ 1786.640123] nouveau  [     DRM] GART: 64 MiB
[ 1786.640135] nouveau  [     DRM] BMP version 5.39
[ 1786.640145] nouveau  [     DRM] DCB version 2.2
[ 1786.640155] nouveau  [     DRM] DCB outp 00: 01000300 00009c40
[ 1786.640163] nouveau  [     DRM] DCB outp 01: 02010310 00009c40
[ 1786.640169] nouveau  [     DRM] DCB outp 02: 01010312 00000000
[ 1786.640176] nouveau  [     DRM] DCB outp 03: 02020321 00000003
[ 1786.640562] nouveau  [     DRM] Loading NV17 power sequencing microcode
[ 1786.646548] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 1786.646560] [drm] No driver support for vblank timestamp query.
[ 1786.646580] nouveau  [     DRM] 0xE1B4: Parsing digital output script table
[ 1786.647246] nouveau  [     DRM] 0 available performance level(s)
[ 1786.647258] nouveau  [     DRM] c: core 234MHz memory 501MHz voltage 1220mV
[ 1786.655499] nouveau  [     DRM] MM: using M2MF for buffer copies
[ 1786.655538] nouveau  [     DRM] Setting dpms mode 3 on TV encoder (output 3)
[ 1786.751345] nouveau  [     DRM] allocated 1920x1200 fb: 0x9000, bo cab83400
[ 1786.751589] fbcon: nouveaufb (fb0) is primary device
[ 1786.781270] Console: switching to colour frame buffer device 240x75
[ 1786.784371] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[ 1786.784376] nouveau 0000:01:00.0: registered panic notifier
[ 1786.789898] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on
minor 0



I've had x11perf in a while-true loop for the better part of a day.  Seems
solid, no issues to report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20131021/d4d688a9/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Ilia Mirkin <imirkin at alum.mit.edu> ---
The quirk went into 3.13-rc1 (commit fd34381b0e2827228cbda45aa2cca4127ff073b2).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140205/3da678c2/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=20341

Jason Detring <detringj at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |VERIFIED

--- Comment #28 from Jason Detring <detringj at gmail.com> ---
This was tested for 24+ hours against a vanilla 3.13.1.  No problems found, so
setting VERIFIED.  I'm happy to see this bug being put to rest.

Thank you for taking care of this issue for me!

Jason


[   18.213336] [drm] Initialized drm 1.1.0 20060810
[   18.463592] wmi: Mapper loaded
[   18.669773] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 3
[   18.669891] PCI: setting IRQ 3 as level-triggered
[   18.670951] [drm] hdmi device  not found 1 0 1
[   18.671233] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x031100a1
[   18.671326] nouveau  [  DEVICE][0000:01:00.0] Chipset: NV31 (NV31)
[   18.671416] nouveau  [  DEVICE][0000:01:00.0] Family : NV30
[   18.673632] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[   18.714842] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[   18.714936] nouveau  [   VBIOS][0000:01:00.0] using image from PRAMIN
[   18.715029] nouveau  [   VBIOS][0000:01:00.0] BMP version 5.27
[   18.715527] nouveau  [   VBIOS][0000:01:00.0] version 04.31.20.52.00
[   18.716448] nouveau W[  PTIMER][0000:01:00.0] unknown input clock freq
[   18.716555] nouveau  [     PFB][0000:01:00.0] RAM type: DDR1
[   18.716645] nouveau  [     PFB][0000:01:00.0] RAM size: 128 MiB
[   18.716794] nouveau  [     PFB][0000:01:00.0]    ZCOMP: 262144 tags
[   18.724684] nouveau  [     CLK][0000:01:00.0] --:   
[   18.724853] nouveau  [  DEVICE][0000:01:00.0] Forcing agp mode to 2X. Use
agpmode to override.
[   18.724994] agpgart-via 0000:00:00.0: AGP 2.0 bridge
[   18.725106] agpgart-via 0000:00:00.0: putting AGP V2 device into 2x mode
[   18.725243] nouveau 0000:01:00.0: putting AGP V2 device into 2x mode
[   18.725559] [TTM] Zone  kernel: Available graphics memory: 444174 kiB
[   18.725650] [TTM] Zone highmem: Available graphics memory: 513810 kiB
[   18.725739] [TTM] Initializing pool allocator
[   18.725836] [TTM] Initializing DMA pool allocator
[   18.725962] nouveau  [     DRM] VRAM: 127 MiB
[   18.726048] nouveau  [     DRM] GART: 64 MiB
[   18.726138] nouveau  [     DRM] BMP version 5.39
[   18.726228] nouveau  [     DRM] DCB version 2.2
[   18.726318] nouveau  [     DRM] DCB outp 00: 01000300 00009c40
[   18.726409] nouveau  [     DRM] DCB outp 01: 02010310 00009c40
[   18.726498] nouveau  [     DRM] DCB outp 02: 01010312 00000000
[   18.726588] nouveau  [     DRM] DCB outp 03: 02020321 00000003
[   18.727035] nouveau  [     DRM] Loading NV17 power sequencing microcode
[   18.728729] nouveau  [     DRM] Saving VGA fonts
[   18.773146] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   18.773253] [drm] No driver support for vblank timestamp query.
[   18.773517] nouveau  [     DRM] 0xE176: Parsing digital output script table
[   18.778990] nouveau  [     DRM] MM: using M2MF for buffer copies
[   18.779120] nouveau  [     DRM] Setting dpms mode 3 on TV encoder (output 3)
[   18.864770] nouveau  [     DRM] allocated 1920x1200 fb: 0x9000, bo f5ae2e00
[   18.865359] fbcon: nouveaufb (fb0) is primary device
[   18.891030] Console: switching to colour frame buffer device 240x75
[   18.893942] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[   18.893967] nouveau 0000:01:00.0: registered panic notifier
[   18.894004] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on
minor 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140209/2ea6b318/attachment-0001.html>