| Summary: | doesn't start X - DMA Queue hang | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Bill Nottingham <notting> | ||||||||||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | medium | ||||||||||||||||
| Version: | 7.2 (2007.02) | ||||||||||||||||
| Hardware: | Other | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 10262 [details]
xorg conf
Created attachment 10263 [details]
X log
Created attachment 10264 [details]
dmesg with debug=1 passed to drm
It would be useful if you could bisect the git tree from the point the last working snapshot was known, to track down exactly what broke it (from the fedora bug: 2.0.1-1.fc7). Going to be hard to directly bisect - the last one that worked was with an older copy of drm as well, and the driver and drm are codependent. Will see what I can turn up. So, as best I can track down (due to the ddx driver, libdrm, and the kernel being all intertwined), it broke at some point between February 14th and March 30. Could you try with current GIT ? 10DE:032A works fine here, this card should be quite close to yours. I still get a DMA queue hang; the hex is slightly different. Could you provide kernel & X logs with that latest git ? There have been numerous change since june, so that the errors might be totally different now. Created attachment 11413 [details]
X log
Created attachment 11414 [details]
dmesg with debug=1 passed to drm
Can you: 1) Turn on the NV_DMA_DEBUG option in src/nv_includes.h 2) Try Option "CBLocation" "VRAM" in xorg.conf Created attachment 11746 [details]
log with debugging
OK, here's the log with debugging.
From https://bugzilla.redhat.com/show_bug.cgi?id=492399 can it be assumed this bug is resolved? Also, feel free to open a bug here about your DVI issue (an indication of whether the display works with the open source "nv" or closed "nvidia" drivers would be a good starting point). Yes, it works now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
startx dies with: (II) Module already built-in crtc 0 1360 1360 writting vpll 00027109 writting vpll2 00000000 output 0 debug_0 31101111 savep->dither 000F0000 0: crtc 0 output0: 0001: twocrt 1 twomon 1 crtc 1 1360 1360 writting vpll 00027109 writting vpll2 00027109 output 1 debug_0 31101111 savep->dither 000F0000 0: crtc 1 output1: 0101: twocrt 1 twomon 1 (EE) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory) (EE) AIGLX: reverting to software rendering Fatal server error: DMA queue hang: dmaPut=8a, current=0, status=0 writting vpll 00045405 writting vpll2 00045405 writting vpll 00045405 writting vpll2 00045405 XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. 01:00.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro FX 500/600 PCI] (rev a1) on an Intel E7505 chipset. Will attach X conf, x logs, etc. xorg server 1.3.0, March 30 noveau snapshot (git head of the randr 1.2 branch beahves similarly). Originally filed as http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242773