occasional hard crash on vt switch

Created an attachment (id=15611)
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.

Created an attachment (id=15612)
output of lspci -v

I'll push this, thanks for filing.

(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.

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?

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

Created an attachment (id=15635)
the xorg log file

> 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

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).

Can you attach your xorg log with modedebug enabled? Use
  Option "Modedebug" "true"
in the intel driver section of your xorg.conf.

Thanks,
Jesse

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.

Created an attachment (id=15667)
xorg log

Thanks, and yeah, I'd like to get one log file from when the pipe a force hack is disabled too.

Created an attachment (id=15670)
Xorg log of session without the force-enable-pipe-a hack

Here's the second log. Hope it helps!

Created an attachment (id=15770)
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).

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.

(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).

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.

(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.

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.

Created an attachment (id=15845)
Log patched intel drive, w/o ForceEnablePipeA hack

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.

Created an attachment (id=15893)
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.

Updating summary

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.

Created an attachment (id=16370)
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...

Ping, has anyone had a chance to try the patch?

(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.

(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.

Clearing needinfo... thanks for testing.

Does suspend hang 100% of the time w/o the pipe a force option?

Created an attachment (id=17403)
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'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 ***

(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.