Bug 26201 - Some screen garbage, NoAccel and GPU lockup reported with NV4E
Summary: Some screen garbage, NoAccel and GPU lockup reported with NV4E
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-25 01:38 UTC by Ted Phelps
Modified: 2010-03-02 07:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
drm/nouveau lines from dmesg (3.59 KB, text/plain)
2010-01-25 01:38 UTC, Ted Phelps
no flags Details
Xorg log messages (13.31 KB, text/plain)
2010-01-25 01:40 UTC, Ted Phelps
no flags Details

Description Ted Phelps 2010-01-25 01:38:34 UTC
Created attachment 32800 [details]
drm/nouveau lines from dmesg

This is a weird one, so bear with me.

I'm using nouveau-linux git (eeec3a1) and KMS on the GeForce 6150 (NV4E) embedded in my M2NPV-VM motherboard.  When I load the nouveau module, the kernel logs the following, but the console appears to work just fine:

    [drm] nouveau 0000:00:05.0: GPU lockup - switching to software fbcon

When I start up the X server, it reports a similar error:

    (EE) NOUVEAU(0): Error creating GPU channel: -16
    (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel

This is probably not a duplicate of bug#26193 since the work-around that I'm using doesn't help in that case.

Things then mostly work except window outlines turn to garbage when another window is dragged over it.  This garbage isn't captured by a screen capture, so I'm afraid we're stuck with my hand-wavy description.

Long ago, this used to just work, so I've bisected to find which commits broke things, and found that these related commits appear to be the culprit:

    77bce8e  drm/nouveau: fix for ttm interface changes, and
    ad49f50  drm/ttm/radeon: add dma32 support.

I've found that commenting out the bit of ttm_tt_alloc page which adds __GFP_DMA32 to the alloc_page flags fixes this issue, as does forcing the last argument of ttm_bo_device_init() to false in nouveau_mem_init().  This, of course, makes no sense -- the DMA32 memory zone is a fallback for the normal memory zones.

I'm happy to test patches if anyone can think of anything to try.

Thanks,
-Ted
Comment 1 Ted Phelps 2010-01-25 01:40:08 UTC
Created attachment 32801 [details]
Xorg log messages
Comment 2 Ted Phelps 2010-03-02 07:14:01 UTC
This appears to be fixed by Linux kernel 2.6.33.

nouveau-linux revision ea0a1d5 running in linux-2.6.32.8 produces the GPU lockup warning mentioned in the description.  That same revision running in linux-2.6.33 seems to work just fine.  Everything else (xorg-server, mesa, xf86-video-nouveau) is unchanged.

I'd be prepared to bisect the Linux kernel itself to track this if anyone is keen to know what changed...

-Ted


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.