Bug 14092 - No fonts and missing Icons
Summary: No fonts and missing Icons
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-15 20:04 UTC by Mike Lothian
Modified: 2008-03-24 18:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
My xorg.conf (3.33 KB, application/octet-stream)
2008-01-15 20:04 UTC, Mike Lothian
no flags Details
The Xorg Log (96.55 KB, application/octet-stream)
2008-01-15 20:05 UTC, Mike Lothian
no flags Details
My dmesg output (15.20 KB, application/octet-stream)
2008-01-15 20:06 UTC, Mike Lothian
no flags Details

Description Mike Lothian 2008-01-15 20:04:35 UTC
Created attachment 13736 [details]
My xorg.conf

On a nVidia Corporation NV41.8 [GeForce Go 6800] [10de:00c8] (rev a2) Xorg loads however the fonts are garbled and once past KDM all the fonts for KDE are missing and half of the desktop icons don't show up
Comment 1 Mike Lothian 2008-01-15 20:05:25 UTC
Created attachment 13737 [details]
The Xorg Log
Comment 2 Mike Lothian 2008-01-15 20:06:01 UTC
Created attachment 13738 [details]
My dmesg output
Comment 3 Maarten Maathuis 2008-02-01 15:51:32 UTC
Does this occur with current git?

More importantly, did you load without a tainted kernel (=no nvidia driver ever loaded), because the blob can mess things up for us?
Comment 4 Mike Lothian 2008-02-02 17:03:28 UTC
I made sure that the nvidia module was never loaded. The problem was "fixed" by changing:

 shared-core/nv40_graph.c in the drm code from 

#define NV41_GRCTX_SIZE (92*1024)

to

#define NV41_GRCTX_SIZE (175*1024)

but that was apparently just a work around. 

I sent in a mmio trace as requested
Comment 5 Maarten Maathuis 2008-02-03 11:16:49 UTC
Could you check if smaller values work as well?

Like 100*1024 and 128*1024?
Comment 6 Mike Lothian 2008-03-23 07:11:43 UTC
I've just tested it (sorry for the long delay)

100x1024 doesn't work
128x1024 does :D

Would you like any others tested?
Comment 7 Ben Skeggs 2008-03-23 07:49:16 UTC
Maarten, checking smaller values is of little use.  It's already well established what exactly accounts for the differences in the context sizes across chips.  As the submitter reports, adjusting to 175*1024 is a *workaround* until a proper fix is devised.  It's a nice safe number, as the 0x40 NV4x chip has both a large number of vertex pipes, and is unique in that each per-pipe block is far larger than the other NV4x chipsets.
Comment 8 Maarten Maathuis 2008-03-23 08:10:55 UTC
I know it's only a workaround, but *if* anything gets committed, then i would prefer something better than the highest upper bound.
Comment 9 Ben Skeggs 2008-03-23 09:24:42 UTC
Too large doesn't matter.  If you want to use a workaround, you may as well play it safe :)  The only down-side of a large block of space being reserved is that we'll run out of PRAMIN for contexts and limit how many channels can be created.  But, that is another problem that has to be solved regardless.

In that light, I've committed something similar to the original workaround to drm git.  This bug should be "resolved" now :)
Comment 10 Mike Lothian 2008-03-24 18:52:04 UTC
Your fix did the job, the code it totally different now so I'm not quite sure what's going on but it works which is the main thing

I'm marking the bug as resolved as you suggested


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.