Bug 15310 - [855GM] occasional hang on VT switch
Summary: [855GM] occasional hang on VT switch
Status: RESOLVED DUPLICATE of bug 15168
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2008-04-01 12:12 UTC by Khashayar Naderehvandi
Modified: 2008-07-07 01:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
output of lspci -nv (4.50 KB, text/plain)
2008-04-01 12:12 UTC, Khashayar Naderehvandi
no flags Details
output of lspci -v (6.13 KB, text/plain)
2008-04-01 12:13 UTC, Khashayar Naderehvandi
no flags Details
the xorg log file (36.02 KB, text/plain)
2008-04-02 17:46 UTC, Khashayar Naderehvandi
no flags Details
xorg log (276.38 KB, text/plain)
2008-04-03 14:48 UTC, Khashayar Naderehvandi
no flags Details
Xorg log of session without the force-enable-pipe-a hack (227.84 KB, text/plain)
2008-04-03 17:57 UTC, Khashayar Naderehvandi
no flags Details
Update pipe configuration before plane configuration (3.85 KB, patch)
2008-04-08 17:23 UTC, Jesse Barnes
no flags Details | Splinter Review
Log patched intel drive, w/o ForceEnablePipeA hack (221.19 KB, text/plain)
2008-04-12 03:23 UTC, Khashayar Naderehvandi
no flags Details
log from session that crashed (269.90 KB, text/plain)
2008-04-14 04:16 UTC, Khashayar Naderehvandi
no flags Details
Fixup ordering and wait for vblank (15.13 KB, patch)
2008-05-05 16:37 UTC, Jesse Barnes
no flags Details | Splinter Review
debug register I/O (1.97 KB, patch)
2008-06-26 16:43 UTC, Jesse Barnes
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Khashayar Naderehvandi 2008-04-01 12:12:35 UTC
Created attachment 15611 [details]
output of lspci -nv

As of intel version 2.2.0 (running Hardy now with 2.2.1), it seems I need to use the ForceEnablePipeA hack in order to safely switch VTs. I have not had this problem with previous versions of the intel driver (as far as I can remember at least), so I don't know why it would turn up now. 

Without the option set I get hard freezes about 60-70% of the times I switch VTs (whether it's logging out, suspending, or just switching to the console). During these hard freezes the screen is black, and I can neither reach it through ssh or the magic sysrq. Only possibility at that point is the power button.

After adding the ForceEnablePipeA option to xorg.conf, I have not seen these problems, except for when I have an external display attached and enabled, in which case the problems re-occur.

Will attach relevant outputs.
Comment 1 Khashayar Naderehvandi 2008-04-01 12:13:06 UTC
Created attachment 15612 [details]
output of lspci -v
Comment 2 Jesse Barnes 2008-04-01 18:43:33 UTC
I'll push this, thanks for filing.
Comment 3 Khashayar Naderehvandi 2008-04-02 13:19:53 UTC
(In reply to comment #2)
> I'll push this, thanks for filing.
> 

Thanks!

Should I file a new bug for this issue (quoting myself):

>After adding the ForceEnablePipeA option to xorg.conf, I have not seen these
>problems, except for when I have an external display attached and enabled, in
>which case the problems re-occur.
Comment 4 Jesse Barnes 2008-04-02 14:18:55 UTC
Can you give this a try and make sure it works?

diff --git a/src/i830_quirks.c b/src/i830_quirks.c
index f29083b..aefd97c 100644
--- a/src/i830_quirks.c
+++ b/src/i830_quirks.c
@@ -259,6 +259,8 @@ static i830_quirk i830_quirk_list[] = {
     { PCI_CHIP_I855_GM, 0x1028, 0x0164, quirk_pipea_force },
     /* Toshiba Protege R-205, S-209 needs pipe A force quirk */
     { PCI_CHIP_I915_GM, 0x1179, 0x0001, quirk_pipea_force },
+    /* Fujitsu Lifebook P7010 needs pipe A force quirk */
+    { PCI_CHIP_I855_GM, 0x10cf, 0x1282, quirk_pipea_force },

     /* ThinkPad X40 needs pipe A force quirk */
     { PCI_CHIP_I855_GM, 0x1014, 0x0557, quirk_pipea_force },

You say you didn't see this behavior in previous versions?  What versions were you running?  Can you attach your Xorg.0.log to this bug?

We can track the "hang on VT switch with external device attached" issue here too.  Does that also work ok with previous versions?
Comment 5 Khashayar Naderehvandi 2008-04-02 17:45:48 UTC
The patch wouldn't apply cleanly against the ubuntu package I'm using (perhaps this patch is against git head?), so I simply added the two lines to src/i830_quirks.c. I will test it for a few rounds of VT switching tomorrow and then get back here.

I'm not 100% sure when exactly this problem started to show itself. However, I'm certain I didn't see it when I used gutsy and its 2.1.1 version of the intel driver.

Attaching Xorg.0.log
Comment 6 Khashayar Naderehvandi 2008-04-02 17:46:42 UTC
Created attachment 15635 [details]
the xorg log file
Comment 7 Khashayar Naderehvandi 2008-04-03 11:40:33 UTC
> I will test it for a few rounds of VT switching tomorrow and
> then get back here.
> 

So far so good. Adding the two lines to i830_quirks.c seems to detect my laptop just fine. VT switching does not cause a crash any longer even though I'm not adding the ForceEnablePipeA option to xorg.conf.

On the bug I filed against Ubuntu, there's this other guy who reports that the hack works for him on a toshiba laptop: https://bugs.launchpad.net/ubuntu/+bug/204603
Comment 8 Jesse Barnes 2008-04-03 14:13:49 UTC
What's weird about this is that the force pipe a enable isn't really intended for fixing VT switch problems, but the fact that it prevents VT switch freezes for you should help us narrow down the real cause...  I'll look at your xorg.log and see if I can find anything (btw, in the future please attach files as text/plain where possible).
Comment 9 Jesse Barnes 2008-04-03 14:14:52 UTC
Can you attach your xorg log with modedebug enabled?  Use
  Option "Modedebug" "true"
in the intel driver section of your xorg.conf.

Thanks,
Jesse
Comment 10 Khashayar Naderehvandi 2008-04-03 14:47:03 UTC
Sorry, I thought I had modedebug enabled already.
I'll attach a new log file.

I started a gnome session with the external display attached. Pretty early in the startup process gnome-settings-daemon turns off the external display (through xrandr 1.2, I believe).

Please write back if you want me to do anything special before posting the log file, such as enabling the external display, disabling the pipe-a-hack, or whatever.
Comment 11 Khashayar Naderehvandi 2008-04-03 14:48:46 UTC
Created attachment 15667 [details]
xorg log
Comment 12 Jesse Barnes 2008-04-03 16:03:21 UTC
Thanks, and yeah, I'd like to get one log file from when the pipe a force hack is disabled too.
Comment 13 Khashayar Naderehvandi 2008-04-03 17:57:42 UTC
Created attachment 15670 [details]
Xorg log of session without the force-enable-pipe-a hack

Here's the second log. Hope it helps!
Comment 14 Jesse Barnes 2008-04-08 17:23:10 UTC
Created attachment 15770 [details] [review]
Update pipe configuration before plane configuration

Can you give this patch a try?  I'm hoping with it applied you won't need the "ForceEnablePipeA" option (turns out we may have had some hw restore ordering violations).
Comment 15 Khashayar Naderehvandi 2008-04-08 22:09:43 UTC
Thanks for the patch. I'll try it as soon as I can. However, I might be out of internet connection for a few days so I'm not sure how soon I can get back.
Comment 16 Khashayar Naderehvandi 2008-04-10 04:49:11 UTC
(In reply to comment #15)
> Thanks for the patch. I'll try it as soon as I can. However, I might be out of
> internet connection for a few days so I'm not sure how soon I can get back.
> 

OK, I've been trying the patch for a little while now, and at first I was sure it fixed the problem. But then, I realized the problem was still there. It seems, however, like the patch produces a higher success ratio, but the problem is nevertheless there.

Do you want me to attach any sort of log?

(I'm still out of internet connection, so whenever I manage to post, it will be one of those lucky times I find a hotspot somewhere).
Comment 17 Jesse Barnes 2008-04-10 09:06:11 UTC
If you can capture a log from when the hang occurs it would be good to have, but I doubt it'll tell us anything we don't already know...

Thanks for testing though, if the patch makes things work a little better maybe I only fixed part of the ordering problem, I'll look again.
Comment 18 Khashayar Naderehvandi 2008-04-11 00:15:06 UTC
(In reply to comment #17)
> If you can capture a log from when the hang occurs it would be good to have,
> but I doubt it'll tell us anything we don't already know...
> 
> Thanks for testing though, if the patch makes things work a little better maybe
> I only fixed part of the ordering problem, I'll look again.
> 

I'll try to see if I can catch the log somehow. I don't think I'll manage though, because it crashes pretty hard (not even the magic sysrq key comination works, neither does ssh).

It definitely makes things better: a higher success rate for sure with the patch.

Comment 19 Khashayar Naderehvandi 2008-04-12 03:22:08 UTC
I've now been using the intel driver with the patch for a while without any crashes. Either something else caused the crash last time (but I wouldn't have any clue of what that would be), or the success rate with the patch is very high indeed. I'll attach the Xorg log with the patch enabled and the pipe a hack disabled, in hope that it will yield at least something.
Comment 20 Khashayar Naderehvandi 2008-04-12 03:23:52 UTC
Created attachment 15845 [details]
Log patched intel drive, w/o ForceEnablePipeA hack
Comment 21 Khashayar Naderehvandi 2008-04-14 04:13:44 UTC
After a few days of normal usage, I finally saw one of these crashes again. I'll attach the log for that session, but I doubt there's actually anything to be found there that might be useful concerning the crash.
Comment 22 Khashayar Naderehvandi 2008-04-14 04:16:57 UTC
Created attachment 15893 [details]
log from session that crashed

I marked the last log file obsolete, as this log file should be from the same session, but from a longer period of time and up until just before the crash.
Comment 23 Jesse Barnes 2008-04-29 18:53:57 UTC
Updating summary
Comment 24 Cristian Campora 2008-05-04 18:59:01 UTC
I have had exactly the same problem described here. My machine is a Dell 700m with 855GM intel, let me know if u need me to test something in order to fix this OMFG annoying bug.
Comment 25 Jesse Barnes 2008-05-05 16:37:35 UTC
Created attachment 16370 [details] [review]
Fixup ordering and wait for vblank

I can't reproduce your problem on my machine, but there's an off chance this latest patch will fix things...
Comment 26 Jesse Barnes 2008-05-21 13:54:36 UTC
Ping, has anyone had a chance to try the patch?
Comment 27 Khashayar Naderehvandi 2008-05-21 14:27:53 UTC
(In reply to comment #26)
> Ping, has anyone had a chance to try the patch?
> 

For some reason I wasn't notified about the last change in this bug report, so I wasn't aware of the new patch until now. I'll definitely give this a try over the weekend and will get back after that. Sorry, I missed it until now.
Comment 28 Khashayar Naderehvandi 2008-05-22 10:38:52 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > Ping, has anyone had a chance to try the patch?
> > 
> 
> For some reason I wasn't notified about the last change in this bug report, so
> I wasn't aware of the new patch until now. I'll definitely give this a try over
> the weekend and will get back after that. Sorry, I missed it until now.
> 


The patch wouldn't apply cleanly against 2.2.1 which is what ubuntu's shipped with. I, therefore, used debian unstable's source debs to compile 2.3.1. With or without this patch, the problem seems even worse in 2.3.1: So far every time I tried to VT-switched, the laptop completely died, as explained in this bug report. Using ForceEnablePipeA, however, once again solves the problem.
Comment 29 Jesse Barnes 2008-06-06 13:15:38 UTC
Clearing needinfo...  thanks for testing.
Comment 30 Jesse Barnes 2008-06-26 16:03:27 UTC
Does suspend hang 100% of the time w/o the pipe a force option?
Comment 31 Jesse Barnes 2008-06-26 16:43:44 UTC
Created attachment 17403 [details] [review]
debug register I/O

This looks very similar to #15168...

Can you try this patch?  Also, please add a section like this to your
xorg.conf:
Section "ServerFlags"
        Option "Log" "sync"
EndSection

Hopefully the log syncing will give us a useful log of where the hang happens. 
It would be best to start your X session by ssh'ing into the laptop and running X with the -verbose option, that way even if the log isn't preserved you'll see what's going on.
Comment 32 Jesse Barnes 2008-07-02 09:45:13 UTC
I'm going to go out on a limb and say this is a dup of 15168.  It looks like we may have to leave the PLLs and pipes enabled on 855 devices.  Trying to confirm with the hw guys.

*** This bug has been marked as a duplicate of bug 15168 ***
Comment 33 Khashayar Naderehvandi 2008-07-07 01:55:11 UTC
(In reply to comment #31)
> Created an attachment (id=17403) [details]
> debug register I/O
> 
> This looks very similar to #15168...
> 
> Can you try this patch?  Also, please add a section like this to your
> xorg.conf:
> Section "ServerFlags"
>         Option "Log" "sync"
> EndSection
> 
> Hopefully the log syncing will give us a useful log of where the hang happens. 
> It would be best to start your X session by ssh'ing into the laptop and running
> X with the -verbose option, that way even if the log isn't preserved you'll see
> what's going on.
> 

I'll be away from my home until mid-August, which means I can't do this over ssh. But I'll try the patch as soon as I can, and let you know how things go.


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.