error messages - was: xf86-video-intel 2.5.0 performance questions

[Eric Anholt]

On Sun, 2008-10-26 at 15:09 +0100, Tobias Hain wrote:
> Keith Packard wrote:
> 
> >> [drm:i915_getparam] *ERROR* Unknown parameter 5
> >> set status page addr 0x01fff000
> >
> > As Julien said, this is just the user-mode driver checking for GEM
> > support which isn't present in your old kernel. If it were the new 2D
> > driver printing the message, we would have fixed it, but it's the old
> > kernel driver. That old driver could be patched to not print the
> > message.
> 
> When having problems with the intel driver, people's attention first get on
> one of the many error messages almost any intel video configuration
> exhibits. Among these messages are:
> 
> [6] exaCopyDirty: Pending damage region empty!
> [6] (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
> [16](EE) intel(0): underrun on pipe A!
> [5] mtrr: no MTRR for e0000000,10000000 found
> [?] waiting for X server to shut down error setting MTRR (base = 0xe0000000,
> size = 0x10000000, type = 1) Invalid argument (22)
> 
> The number in square brackets [?] corresponds to the number of hits in the
> intel xorg video bugzilla.
> 
> Even without patching old kernel code, I can think of many ways to prevent
> the latest *ERROR* Unknown parameter 5 message.
> 
> Somebody involved in driver development, knows to judge those message. E.g.
> the underrun message is explained here:
> https://bugs.freedesktop.org/show_bug.cgi?id=16833#c16
> 
> However the general user (or developer, but just not being a video driver
> developer) is mislead by those bloating error messages. I think it would be
> helpful for people trying to debug issues, if those error messages get
> evaluated. Maybe some should be downgraded to warnings. Others may be
> presented more descriptive.
> 
> With the recent addition of GEM and G4x code and the multitude of
> configurations deployed (libdrm, kernel, mesa, xserver, ...) the number of
> bugs/issues facing people increased and one of the first things they
> encounter are often one of the above error messages.

This is a problem we have.  Messages with escalated severity increase
over time, and only get reduced when someone goes on a crusade to clean
them up.  It's happened a couple times before, and we're about due to do
it again.  It's going to be a goal of mine for 2.6.0.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081026/541eb8ce/attachment.pgp>