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 [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
