Thanks for your reply Andy. lspci output is attached.
That sounds like FIFO underruns, which (I think) were introduced when
self-refresh was enabled but should have been fixed. I personally have
no clue how to fix them, but if you told the Intel people what kind of
chip you have (lspci output), they can probably fix it. (cc added)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Try to unmute "Speaker" mixer switch.
Takashi
Thanks Takashi, actually it seems to be a kernel config problem: I
just tried the stock .32 kernel of the distribution I'm using and all
channels are there again. I just have to figure out what has changed
that requires my config to be modified.
> Emmanuel Benisty wrote:
[snip]
>> I just wanted to report 2 regressions I am having now with 2.6.32.
>> Video
>> Screen is flickering/glitching like crazy in X. It happens whether
>> randomly or when conky is refreshed, when the mouse cursor moves and
>> like hell when a page is loading in the browser. Not so easy to
>> describe this issue.
[snip]
> That sounds like FIFO underruns, which (I think) were introduced when
> self-refresh was enabled but should have been fixed. I personally have no
> clue how to fix them, but if you told the Intel people what kind of chip
> you have (lspci output), they can probably fix it.
It also sounds like what I'm seeing on my EeePC 901. It only happens after
resume, which makes STR a little less than useful; the display will, sooner
or later, show a single colour (which is, presumably, the result of a display
engine hang, as described in the comment immediately before
intel_calculate_wm) and, seemingly, be stuck like that until power-off or
reboot.
Whether it *is* the same problem, I couldn't say.
Needless to say, this problem goes away if I disable KMS.
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + http://www.youmustbejoking.demon.co.uk/ & http://tlasd.wordpress.com/
Dumb luck beats sound planning every time. Trust me.
Arg, there are a few reports of this now, but I haven't been able to
reproduce it. I'll try harder... (FYI the upstream
bugs.freedesktop.org # for it is 24314).
--
Jesse Barnes, Intel Open Source Technology Center
It *seems* that we are facing two different issues here (I don't even
use S2R and the problem is there since the very first second I start
X). Anyway, I have bisected the problem on my box, it turns out to be
this one:
drm/i915: Fix render reclock availability detection
Great, thanks for narrowing it down. I'll see if I can come up with a
fix.
--
Jesse Barnes, Intel Open Source Technology Center
Thank you very much Jesse, I've opened a bug report here:
http://bugzilla.kernel.org/show_bug.cgi?id=14781
Can you give this a try?
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 279dc96..5bde801 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3808,6 +3808,8 @@ void intel_decrease_renderclock(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev->dev_private;
+ return;
+
if (IS_IRONLAKE(dev))
return;
> On Fri, Dec 18, 2009 at 2:05 AM, Jesse Barnes
> Thanks a lot Jesse, I have tried your bugzilla patch. Anyone
> interested, it's here:
> http://bugzilla.kernel.org/show_bug.cgi?id=14781
>
Ok, I'll follow further updates in the bug. If anyone else has
anything to report, please do it in the bug so it doesn't get lost.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
Thanks a lot Jesse, I have tried your bugzilla patch. Anyone
interested, it's here:
http://bugzilla.kernel.org/show_bug.cgi?id=14781