Bug 15070 - kernel mode switching broken on i830
Summary: kernel mode switching broken on i830
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-16 14:15 UTC by Kurt Roeckx
Modified: 2012-04-18 21:30 UTC (History)
5 users (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
full dmesg with kms enabled. (41.50 KB, text/plain)
2010-01-16 14:15 UTC, Kurt Roeckx
Details
Thinkpad X30 dmesg log with KMS and 2.6.33.1 (15.06 KB, text/x-log)
2010-03-28 11:38 UTC, Marcel Beister
Details
dmesg with 2.6.35-rc5 and kms enabled. (44.85 KB, text/plain)
2010-07-22 17:25 UTC, Kurt Roeckx
Details
xrandr output showing changes (1.62 KB, text/plain)
2010-12-26 23:22 UTC, Kurt Roeckx
Details

Description Kurt Roeckx 2010-01-16 14:15:33 UTC
Created attachment 24597 [details]
full dmesg with kms enabled.

I'm having problems with an i830 chipset when kernel mode switching is enabled.  I'm running 2.6.32.3 kernel, Debian's 2.6.32-5.  After upgrading to the latest version of X in unstable, KMS got enabled, and things broke for me.

When KMS is disabled, everything works properly.  When X starts, the i915 module gets loaded and this shows up in the log:
[   55.021263] [drm] Initialized drm 1.1.0 20060810
[   55.293251] pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
[   55.293269] pci 0000:00:02.0: setting latency timer to 64
[   55.314396] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

When modesetting is enabled, I get this instead:
[   55.049322] [drm] Initialized drm 1.1.0 20060810
[   55.253696] i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
[   55.253713] i915 0000:00:02.0: setting latency timer to 64
[   55.272730] [drm] set up 7M of stolen space
[   55.566079] [drm] DAC-6: set mode 640x480 0
[   56.150306] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[   56.151501] fb1: inteldrmfb frame buffer device
[   56.151508] registered panic notifier
[   56.151525] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[   56.319592] [drm] LVDS-8: set mode 1024x768 b
[   57.103488] [drm] DAC-6: set mode 640x480 0
[   57.611480] [drm] DAC-6: set mode 640x480 0
[   58.798400] [drm] DAC-6: set mode 1024x768 19
[   58.964037] [drm] LVDS-8: set mode 1024x768 1a
[   63.094242] [drm] LVDS-8: set mode 1024x768 b
[   66.987543] [drm] DAC-6: set mode 640x480 0
[   67.492465] [drm] DAC-6: set mode 640x480 0

This has several effects:
- The console isn't working properly anymore.  It displays what was showing in X, but reacts to the keyboard.  When X isn't running yet I just get a black screen instead.
- gdm still works properly, but after logging in my display gets black.

When booting I pass vga=0x305 to the kernel, and I get this in my log:
[    0.892508] vesafb: framebuffer at 0xf0000000, mapped to 0xd0700000, using 768k, total 768k
[    0.892531] vesafb: mode is 1024x768x8, linelength=1024, pages=0
[    0.892545] vesafb: scrolling: redraw
[    0.892561] vesafb: Pseudocolor: size=0:8:8:8, shift=0:0:0:0
[    0.898351] Console: switching to colour frame buffer device 128x48
[    0.903778] fb0: VESA VGA frame buffer device
[...]
[    2.298643] agpgart-intel 0000:00:00.0: Intel 830M Chipset
[    2.316497] agpgart-intel 0000:00:00.0: detected 892K stolen memory
[    2.404437] agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xf0000000


Kurt
Comment 1 ykzhao 2010-01-19 00:50:18 UTC
Will you please try the 2.6.33-rc4 kernel and attach the output of dmesg with the KMS enabled? (Please compile the i915 driver as built-in kernel and add the boot option of "drm.debug=0x06").

thanks.
Comment 2 Kurt Roeckx 2010-03-02 21:34:43 UTC
With the 2.6.32.9 kernel the initial problems went away.  Instead I get screen corruption after switching to console and then back.  I'm now also unable to play video because allocation fails.


Kurt
Comment 3 Marcel Beister 2010-03-28 11:36:51 UTC
I have a notebook (Thinkpad X30) with an i830M chipset and I also experience problems with KMS. To be more exact, after starting the kernel, the screen turns black (not off) when KMS kicks in. The system is able to boot and to start the x-server, but the screen is always black. I will attached a dmesg log of a boot with 2.6.33.1 vanilla with i915 built-in and the startup options i915.modeset=1 drm.debug=0x06 (no vga=xxx).

The important part seems to be:

Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 830M Chipset
agpgart-intel 0000:00:00.0: detected 8060K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xe0000000
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 9 (level, low) -> IRQ 9
i915 0000:00:02.0: setting latency timer to 64
[drm] set up 15M of stolen space
[drm] initialized overlay support
Console: switching to colour frame buffer device 128x48
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I'm a bit curious that lines like
[drm] LVDS-8: set mode 1024x768 b
which Kurt had in his log are not showing up in my dmesg log.

Marcel
Comment 4 Marcel Beister 2010-03-28 11:38:11 UTC
Created attachment 25739 [details]
Thinkpad X30 dmesg log with KMS and 2.6.33.1
Comment 5 Kurt Roeckx 2010-07-16 23:38:02 UTC
So I'm not using 2.6.32.16. Things work properly if KMS is disabled.

But if I enable KMS the console changes to black during boot, and stays that way.  When I start gdm, it properly shows the login screen.  But after logging it it also changes black.

Do you have any suggestions on what I can try?
Comment 6 Kurt Roeckx 2010-07-22 17:23:26 UTC
I'm now trying a 2.6.35-rc5 kernel.  It at least shows something when kms is enabled.  But it doesn't seem to like switching between X and the console.

dmesg now contains:
   14.103614] i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low)
 -> IRQ 10
[   14.105784] i915 0000:00:02.0: setting latency timer to 64
[   14.118011] [drm] set up 7M of stolen space
[   14.145426] [drm] initialized overlay support
[   14.612763] checking generic (f0000000 c0000) vs hw (f0000000 8000000)
[   14.612773] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[   14.614920] Console: switching to colour dummy device 80x25
[...]
[   14.936242] Console: switching to colour frame buffer device 128x48
[   14.947658] fb0: inteldrmfb frame buffer device
[   14.947662] drm: registered panic notifier
[   14.947852] Slow work thread pool: Starting up
[   14.948094] Slow work thread pool: Ready
[   14.948195] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I'll attach a full dmesg.
Comment 7 Kurt Roeckx 2010-07-22 17:25:07 UTC
Created attachment 27207 [details]
dmesg with 2.6.35-rc5 and kms enabled.
Comment 8 Kurt Roeckx 2010-07-22 20:54:27 UTC
The stability problem happens at various moments.  It's doesn't seem to be related to switching to console and back to X.  I'm currently not sure that it's related to kms or not.  When I have the problem the screen just turns black.

When kms is enabled, I get DRI errors and can't play back video.  It works perfectly when kms is disabled.

When kms is enabled I also have more supported video modes and refresh rates then when it's disabled.
Comment 9 Chris Wilson 2010-07-24 08:31:28 UTC
Yes, the kernel overlay is missing a quirk for working around an erratum on i830. I have an attempt to make the overlay code work again in http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=fair-eviction 

Not sure about the DRI errors, but there are a few more crippling hardware bugs that make GEM unstable on i830/i845 which we have not found a way to workaround yet.
Comment 10 Kurt Roeckx 2010-07-24 17:14:19 UTC
I've switched to 2.6.35-rc6 now.  It seem to be more stable when kms is enabled.
I never had issues when kms is disabled.

The issues I still see when kms is enabled:
- Sometimes after switching between X and console, the proper screen shows, and then it blanks the screen for half a second.  I have the feeling if that happens other things go wrong as well.
- Sometimes I see the X cursor on the console
- Sometimes it still gives me a black screen or doesn't update the screen anymore.
- DRI doesn't work.

On the "fair-evition" branch are alot of patches it seems.  I have no idea which ones you think I should test.  I tried merging the whole branch but that gave merge conflicts.
Comment 11 Kurt Roeckx 2010-09-23 22:33:04 UTC
I've tried a 2.6.35.4.  When in the console it acted really weird.  All pixels where shifted to the right about 10 pixels and rapidly changing 1 position left and right making the text very hard to read.

I could start X without problems.  But playing something with mplayer still gives errors.

I tried switching to the console and was greeted by a black screen and it stopped responding.

Some days ago I also tried a 2.6.36-rc4, but then with a built in driver instead of a module.  I just got a black screen while booting and it wasn't doing anything.
Comment 12 Chris Wilson 2010-12-22 12:35:21 UTC
I was hoping that the modesetting failures would have been fixed by

commit 897493504addc5609f04a2c4f73c37ab972c29b2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Sep 12 18:25:19 2010 +0100

    drm/i915: Ensure that the crtcinfo is populated during mode_fixup()
    
    This should fix the mysterious mode setting failures reported during
    boot up and after resume, generally for i8xx class machines.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16478
    Reported-and-tested-by: Xavier Chantry <chantry.xavier@gmail.com>
    Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29413
    Tested-by: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@kernel.org

which is post 2.6.36-rc4.

Still leaves the stability issues which are probably due to the incoherency and the way we utilize the GTT more with GEM/UXA. Using the Option "shadow" "true" for X is the best way to make the current system stable.
Comment 13 Kurt Roeckx 2010-12-26 22:08:20 UTC
I just tried a 2.6.37-rc5 and it seems to work with KMS without any problems.  I didn't enable the shadow option yet.  Everything seems to work.
Comment 14 Kurt Roeckx 2010-12-26 23:22:01 UTC
Created attachment 41642 [details]
xrandr output showing changes

It seems that detection of the VGA connection is at least not correct the first time I run xrandr.  Each time I tried this it the first time it said that VGA1 is connected, and the next time it properly says disconnected.

Most of the time when I ran xrandr the screen went black for a while, sometimes staying that way.  I can still switch to the console at that time.  But changing to X again usually completely breaks things.  

What I sometimes also see is that the resolution of my screen changes.  Sometimes I get a message that it failed to change the resolution, usually making it wider.  But sometimes after having logged in it also starts that way.

The log file shows it changing from width 2048 to 1024 after the 3rd call to xrandr.
Comment 15 Kurt Roeckx 2011-02-27 00:18:26 UTC
I'm now using 2.6.38-rc6, and it now properly says that VGA1 is disconnected.
Running xrandr now usually doesn't have any effect, but sometimes it does.  That part seems to have improved a lot, but it's not fixed yet.

But instead I now get random screen corruption in X, which gets fixed after a redraw.
Comment 16 Kurt Roeckx 2011-02-27 00:24:53 UTC
Using the option shadow true the screen corruption seems to be gone.

Instead calling xrandr now has a very high chance of segfaulting X.
Comment 17 Kurt Roeckx 2011-03-19 00:44:29 UTC
The screen corruption got fixed in 2.6.38-rc7 but reintroduced in 2.6.38-rc8 and still present in 2.6.38.
Comment 18 Kurt Roeckx 2011-03-19 00:57:17 UTC
I just got this:
[  333.524036] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[  333.534498] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 28811 at 28806, next 28812) 

It's the first time I see this, it was with a 2.6.38 kernel.  It was the first time I booted the 2.6.38 kernel.
Comment 19 Kurt Roeckx 2011-05-19 22:39:18 UTC
2.6.39-rc7 doesn't have the screen corruption anymore.

I haven't seen that hangcheck timer error with 2.6.38 anymore for quiet a while.

Calling xrandr changes screen size about 1 out of 5 times, the call after wards it gets fixed.  When it changes the screen gets blank for a while.

So far this kernel looks like the best version since kms got introduces.


Kurt
Comment 20 Jesse Barnes 2012-04-18 21:30:27 UTC
Ok marking the initial problem as fixed then.  Please open new bugs for any other issues you encounter.

Note You need to log in before you can comment on or make changes to this bug.