occasional hard crash on vt switch

Bug #204603 reported by Khashayar Naderehvandi on 2008-03-21
18
Affects Status Importance Assigned to Milestone
xf86-video-intel
Invalid
Medium
xserver-xorg-video-intel (Ubuntu)
Medium
Bryce Harrington
Hardy
Medium
Bryce Harrington

Bug Description

I haven't found any bug exactly like this although some seem to be very similar.

Using an up-to-date hardy installation I've had this problem plaguing me for some time now. Every now and then during VT-switch, everything turns black, the hard drive led keeps blinking and nothing works, not even the magic sysrq combinations. Only thing left is to shutdown the laptop.

At first, I thought this was related to suspend, cause that's normally when I see it, but after seeing the same problem when trying to reboot or log out I noticed it had to do with any form of VT-switching. It seems to happen about one out of three times.

It's been very hard to acquire any relevant debugging information. All I have is an xorg.log. I hope it helps.

The graphics chip is an intel 855GM, I'm using the intel driver.

Forgot to specify when I filed the bug

This seems to be the exact same problem on debian: http://<email address hidden>/msg469396.html

However, I have not yet tried the master branch of the intel driver. Will attempt to build it and see if it helps.

Bryce Harrington (bryce) wrote :

It would also be good to try this after logging out of X, or alternatively by switching to vesa and see if you can reproduce the issue then. In either case, if the issue still occurs, it'll be a kernel issue rather than -intel.

Changed in xserver-xorg-video-intel:
status: New → Incomplete

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

jhansonxi (jhansonxi) wrote :

I'm also encountering this problem on a Toshiba M35X-S114 laptop with an Intel 855GM. It freezes 90% of the time when switching to a VT, shutdown, or restart. It occurs with these actions from gdm or Gnome. Nothing useful in the logs. SSH server non-responsive. Laptop doesn't have a serial port so I can't use the serial console either. When it doesn't crash I get a persistent vertical white line from the middle of the screen to the bottom edge in the VT. Switching to vesa eliminates all these problems. Only oddity with vesa is a rainbow pattern is momentarily displayed before gdm starts. Thee is also a series of green vertical lines shown momentarily along the top edge of the desktop when switching back from a VT.

I'll push this, thanks for filing.

I was absolutely positive I had replied to the comment before the last already, but seems I haven't.

It seems the good old ForceEnablePipeA hack is needed on my laptop. The strange thing is that it hasn't been needed ever before, so I don't understand why now. As with jhansonxi, vesa eliminates the problems, and suspend outside of X works fine 100% of the time.

Now, I have been using ForceEnablePipeA for a while and everything has worked just fine, changing VT, suspend, everything. Except, when an external display is attached, in which case the problem re-occurs, i.e. ~33% success when switching VT.

jhansonxi, could you possibly try to add
Option ForceEnablePipeA "true"
to xorg.conf and see if it works out for you?

jhansonxi (jhansonxi) wrote :

Option ForceEnablePipeA "true" does eliminate the freeze problem for me. However, the white line on the VT is still present which may be a different issue.

I see the white line as well, something I think is related to the new drm module. However, as far as I can tell, the white stripe is just a visual artifact, it does not affect anything whatsoever.

If the ForceEnablePipeA worked well for you, don't forget to file a bug report upstream so that the intel driver developers can include the driver for your particular model.

jhansonxi (jhansonxi) wrote :

I created bug #210600 for the white line issue. It seems to occur with the intel driver only (or at least very rarely with vesa).

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

Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Bryce Harrington (bryce) wrote :

Good, looks like upstream is active on the bug. I doublechecked that the quirk jesse provided hasn't been committed to their git tree, so I'm guessing that they intend to look into it deeper and figure out a real fix. If he comes up with a fix that they commit to git, make sure to let me know and I can pull it in for Hardy. If a fix doesn't show up soonish, I'll put in the quirk as a temporary fix for Hardy.

Changed in xserver-xorg-video-intel:
assignee: nobody → bryceharrington
importance: Undecided → Medium
milestone: none → ubuntu-8.04
status: Incomplete → In Progress

>If he comes up with a fix that they commit to git, make sure to let me know

Alright, I'll let you know through this bug if anything interesting happens upstream.

>If he comes up with a fix that they commit to git, make sure to let me know

Alright, I'll let you know through this bug if anything interesting happens upstream.

@jhansonxi: It would nice if you could find the time to jump on the bug report upstream as well. I'm sure it gives a lot to have logs from two different machines to compare while trying to solve this issue.

jhansonxi (jhansonxi) wrote :

I've done some further testing with some of the git builds from Bryce against bug #210600. These two along with the latest today:
xserver-xorg-video-intel_2.1.0+git20070625.ccac60bf-1_i386.deb
xserver-xorg-video-intel_2.2.0+git20080102.0fd769b5-1_i386.deb

Sometimes the freeze doesn't happen for a couple of dozen tests then it happens several times in a row. The ForceEnablePipeA option does eliminate it. It doesn't happen with the i810 or vesa drivers although the intel driver also has the spurious green lines shown when returning from a VT just like vesa.

I have a theory that the two bugs are related. It may be that the intel driver is not initializing the shared memory area correctly and sometimes the corruption is just visual as in bug #210600 and sometimes it hits something important and freezes the system.

There is another issue I discovered - if I attempt a display switch to an external monitor when one is not connected then the system freezes. This also doesn't happen with the i810 or vesa drivers (although vesa can't seem to make the switch).

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.

Steve Langasek (vorlon) wrote :
Changed in xserver-xorg-video-intel:
milestone: ubuntu-8.04 → ubuntu-8.04.1
Steve Langasek (vorlon) on 2008-05-03
Changed in xserver-xorg-video-intel:
assignee: nobody → bryceharrington
importance: Undecided → Medium
milestone: none → ubuntu-8.04.1
milestone: ubuntu-8.04.1 → none

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.

Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here

Changed in xserver-xorg-video-intel:
milestone: ubuntu-8.04.1 → none
status: New → Fix Committed

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

Steve Langasek (vorlon) on 2008-05-05
Changed in xserver-xorg-video-intel:
milestone: none → ubuntu-8.04.1
Launchpad Janitor (janitor) wrote :
Download full text (4.2 KiB)

This bug was fixed in the package xserver-xorg-video-intel - 2:2.2.1-2ubuntu1

---------------
xserver-xorg-video-intel (2:2.2.1-2ubuntu1) intrepid; urgency=low

  * Merge from debian unstable, remaining changes:
    - debian/patches
      + 01_fix_compiz_video.diff:
        use xf86XVFillKeyHelperDrawable() to fix video playback with
        compositing enabled.
      + 03_dell_1535_quirk.diff:
        Add a quirk for Dell Inspiron 1535 so it does not configure
        against the HDMI port instead of the LCD's native resolution
        (LP: 187860).
      + 04_dell_1735_quirk.diff:
        Another HDMI port quirk, for the Dell Inspiron 1735.
        (LP: 188204)
      + 05_intel_exa_force_greedy.patch:
        Force use of greedy mode on i965 hardware.
        (LP: 177492, 148247, 152206)
      + 08_945gm_quirk.diff:
        Adds quirk for another laptop model with a tv out detection bug.
        (LP: 152416)
      + 10_hw_overlay.diff:
        Replace explicit checks for G965 for having no overlay since it
        has one, with general check for future chips that may have no
        overlay. (LP: 201596, 152206)
      + 11_hw_overlay_option.diff:
        Add a Boolean "TexturedVideo" option with default 'true' value
        to be able to turn textured video off.
        (LP: 201596, 152206)
      + 12_quirk_sync.patch: Add some quirks from current git
        upstream, and a quirk for Dell Latitude D630 (LP: 197740)
      + 13_dpms_low_power_overlay.patch:
        Fix crash triggered by dpms low power mode with hardware overlay
        running (LP: 160309)
      + 14_sysfs_fujitsu_backlight.patch:
        Add sysfs backlight support for Fujitsu laptops (LP: 197620)
      + 15_quirk_sony_vaio_vgn-sz4mn.patch:
        Another Pipe A quirk - not already included - for the Sony Vaio
        VGN-SZ4MN. (LP: 212163)
      + 16_legacy_backlight_blc_pwn_ctl.patch:
        Fixes issue where gdm, opengl apps, and vlc resets brightness to
        xbacklight value on i915, by switching from BCM_LEGACY to
        BCM_COMBO. (LP: 201933)
      + 17_lockup_virtual_size_2048.patch:
        Fixes crash if Virtual set to >2048 by disabling DRI in this case,
        prior to initializing the DRI subsystem. (LP: 188178)
    - debian/control:
      + Change the maintainer address.
      + Add lpia to the list of architectures.
      + Nuke Conflicts and Replaces related to -i810.
      + Nuke /usr/lib/xorg/modules/drivers/i810_drv.so symlink
      + Nuke /usr/share/man/man4/i810.4 conflict
      + Don't conflict with 915resolution, since it breaks upgrades
        where people are still using i810 with widescreen resolutions.
        (LP: 206167)
    - debian/rules:
      + Don't build the intel_reg_dumper tool, since libpciaccess is in
        universe.
      + Allow xserver-xorg-video-i810 and xserver-xorg-video-intel to
        coexist until -intel is able to replace it completely.
  * debian/patches/18_quirks.patch:
    - Add quirks for pipe A and tv output bugs.
      (Closes LP: #204603, #216490, #201257, #224102)
  * debian/patches/19_check_exa_pitch_to_fix_rotate_crash.patch:
    - Fixes crash on xrandr rotation by checking EXA pitch size.
      EXA w...

Read more...

Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in xserver-xorg-video-intel:
status: Fix Committed → Fix Released

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.

Changed in xserver-xorg-video-intel:
status: Confirmed → In Progress

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.

Changed in xserver-xorg-video-intel:
status: In Progress → Invalid
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Changed in xserver-xorg-video-intel:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.