[i915] Lenovo U160 Intel i7 620UM blank screen

[Sascha Lars Strodthoff]

Hi,
I tried to run Ubuntu 10.04 amd64 on my new Lenovo U160.

Inside the Lenovo U160 works a Intel Core i7 620UM (arrandale) with integratet graphics.
The error looks like this: https://bugs.launchpad.net/gentoo/+bug/554569 but the Kernel in post #98 did not solve my problem.

I know an other Lenovo U160 with Intel core i5 520UM which has the same problem.

I only can use it with the kernel boot parameter i915.modeset=0 in vesa-mode.

I am at my wit's end.

thx for your help
Sascha

[Adam (adam-redhat-bugs)]

I have here a Sony Vaio Z laptop. It's a fairly new model with switchable graphics: it has both a GeForce and an Intel integrated graphics chipset.

I can configure the BIOS so I can enable only one card during any given boot, using the selector switch on the laptop. At this point it ought to be just like dealing with a single adapter for the OS, so we should be able to cope with driving either adapter using nouveau or intel (respectively). In fact, neither work. Here's the report for the intel adapter.

As soon as i915 gets loaded with KMS enabled, the screen goes blank (with the backlight on). If I load i915 without KMS, it succeeds, but obviously this is no use for actually running X now the UMS support is gone from the X driver.

I will attach relevant sections from /var/log/messages , and the lspci -nn output. Xorg.0.log doesn't seem useful in this case as the failure is earlier.

Chip is: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)

[Adam (adam-redhat-bugs)]

Created attachment 417065
lspci output on the affected system

[Adam (adam-redhat-bugs)]

By the looks of the logs, the following appears in /var/log/messages when loading i915 *without* KMS:

May 26 16:39:05 vaioz kernel: [drm] Initialized drm 1.1.0 20060810
May 26 16:39:05 vaioz kernel: pci 0000:00:02.0: power state changed by ACPI to D0
May 26 16:39:05 vaioz kernel: pci 0000:00:02.0: power state changed by ACPI to D0
May 26 16:39:05 vaioz kernel: pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
May 26 16:39:05 vaioz kernel: mtrr: no more MTRRs available
May 26 16:39:05 vaioz kernel: [drm] MTRR allocation failed. Graphics performance may suffer.
May 26 16:39:05 vaioz kernel: acpi device:00: registered as cooling_device4
May 26 16:39:05 vaioz kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
May 26 16:39:05 vaioz kernel: ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
May 26 16:39:05 vaioz kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
May 26 16:39:05 vaioz kernel: modprobe used greatest stack depth: 3176 bytes left

when loading i915 *with* KMS, nothing at all appears in the logs. There's nothing in /var/log/messages between where boot is complete, and when the next boot starts up. I will attach the entire /var/log/messages . Here's my timing notes. All refer to today, May 26th:

16:36:28 - boot complete
~16:37 - modprobe i915 , screen blank with backlight on

16:38:35 - second boot complete
~16:39 - modprobe i915 modeset=0, screen fine

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Adam (adam-redhat-bugs)]

Created attachment 417066
/var/log/messages from the affected system

[Adam (adam-redhat-bugs)]

if you're wondering why the adapter apparently disappears entirely outside of these couple of test boots, to actually *use* the system I boot with the NVIDIA adapter selected, and use the NVIDIA proprietary driver (which works).

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Adam (adam-redhat-bugs)]

Final note - this happens with both 2.6.34-2.fc14.x86_64 and 2.6.33.4-95.fc13.x86_64 .

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Adam (adam-redhat-bugs)]

with thanks to the inhabitants of #fedora-devel, I'll attach the drm debug messages (with drm.debug=0x06 as directed by ajax).

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Adam (adam-redhat-bugs)]

Created attachment 417742
drm debug messages from a load of i915

[Christoph Emsenhuber (cph.0x00)]

Hi Sascha,

I am owner of a Lenovo U160 i5 U520 and, of course, also affected of this annoying issue. I have been spending many days and nights without finding a good configuration making the display work...
In your first posting, you wrote about an i5 U520: have you got any information, if the owner (maybe you?) has found a setup which made the notebook's display work? If not, I am also willing to try your configuration on my machine. I would even take vesa if it would support 1366x768.

Thanks in advance
Christoph

[Christian Wehrfritz (cfritz)]

Created an attachment (id=37954)
dmesg

Hello,

I can't get more than 1024x768 with xforcevesa and i915.modeset=0 on a Lenovo U160. If I boot into single mode, then do a rmmod i915; modprobe i915 modeset=1, the screen goes black while the LED backlight is still lit. The happens with all kernels, I tried, e.g. Ubuntu 10.4, 10.10, latest Fedora, and vanilla 2.6.36-RC1.

The graphics chip is a
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 3920
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 43
        Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 1800 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee0f00c Data: 4171
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel modules: i915

I have attached the vbios dump *before* the modules insertion. The dmesg and the intel_reg_dump output were recorded *after* inserting i915.

Is there anything I can test?

Best regards,
Christian

[Christian Wehrfritz (cfritz)]

Created an attachment (id=37955)
vbios

[Christian Wehrfritz (cfritz)]

Created an attachment (id=37956)
intel_reg_dump

[Chris Wilson (ickle)]

Can you please try http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay as that contains various fixes for Arrandale? (Including a few timing fixes which have proven vital for bringing up DP/eDP.)

[Christian Wehrfritz (cfritz)]

(In reply to comment #3)
> Can you please try http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay
> as that contains various fixes for Arrandale? (Including a few timing fixes
> which have proven vital for bringing up DP/eDP.)

I'm afraid that didn't work. I pulled the repo with
 git clone git://anongit.freedesktop.org/~ickle/linux-2.6

but that resulted in a 2.6.32-rc2 kernel (which wouldn't boot with xforcevesa i915.modeset=0 single. How do I get the source of that overlay?

[Chris Wilson (ickle)]

(In reply to comment #4)
> I'm afraid that didn't work. I pulled the repo with
> git clone git://anongit.freedesktop.org/~ickle/linux-2.6
>
> but that resulted in a 2.6.32-rc2 kernel (which wouldn't boot with xforcevesa
> i915.modeset=0 single. How do I get the source of that overlay?

After git clone, git checkout -b testing origin/overlay

[Christian Wehrfritz (cfritz)]

> After git clone, git checkout -b testing origin/overlay

Thanks!

Screen, however, stays black with that kernel. Here are the last dmesg lines starting just before the `modprobe i915 modeset=1`:

[ 43.884476] [drm] Module unloaded
[ 138.283424] i915 0000:00:02.0: setting latency timer to 64
[ 138.329902] [drm] detected 63M stolen memory, trimming to 32M
[ 138.330110] i915 0000:00:02.0: irq 43 for MSI/MSI-X
[ 138.330137] [drm] set up 32M of stolen space
[ 138.450379] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 138.477971] acpi device:06: registered as cooling_device4
[ 138.478954] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input8
[ 138.479074] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 138.479445] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 138.848474] checking generic (d0000000 130000) vs hw (d0000000 10000000)
[ 138.848479] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[ 138.849853] Console: switching to colour dummy device 80x25
[ 138.867007] Console: switching to colour frame buffer device 170x48
[ 138.872953] fb0: inteldrmfb frame buffer device
[ 138.872955] drm: registered panic notifier

[Chris Wilson (ickle)]

So we know we have something different. Can you try booting [still with the overlay branch, as it that rules out several known bugs] with i915.modeset=1. i.e. skip loading of the VESA fb, and attach a fresh drm.debug=0xe dmesg?

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38010)
dmesg of boot with modeset=1 (overlay kernel)

here's the dmesg of booting the overlay image with modeset=1 and drm.debug=0xe

[Jerone Young (jerone)]

This issue is also being tracked in launchpad:
https://bugs.launchpad.net/linux/+bug/608907

The issue appears to be with LG 1366x768 displays (product ID 703).

[Jerone Young (jerone)]

Also to add. This is similar to the issue with the Thinkpad X201 panel:
https://bugs.launchpad.net/gentoo/+bug/554569

[Adam (adam-redhat-bugs)]

This is still the case with the latest F14 kernel (2.6.35.2-9.fc14) - same behaviour, as soon as KMS kicks in, the system hangs with backlight on.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Jerone Young (jerone)]

Can someone try the lastest Maverick daily build (it's a little flacky at the moment):

http://cdimage.ubuntu.com/daily-live/current/

[Chris Wilson (ickle)]

(In reply to comment #10)
> Also to add. This is similar to the issue with the Thinkpad X201 panel:
> https://bugs.launchpad.net/gentoo/+bug/554569

Nope. Different bugs, this one has been fixed.

[Jerone Young (jerone)]

Oh also if you put the latest Maverick on a usb stick .. once the usb stick has been created .. you have to edit syslinux/syslinux.cfg and remove "ui" from the lbeginning of the last line.

[Jerone Young (jerone)]

Marked OEM priority as it will effect other machines with the same panel.

[Jerone Young (jerone)]

The Panel is a according to the Xorg log is a

vendor = "LGD"
product id =703

It is a 1366x768 panel.

[Jerone Young (jerone)]

LGD stands for "LG Display" .. so the panel is an LG panel.

info from:
http://www.pcworld.com/article/195409/au_to_seek_us_import_ban_on_lg_display_lcd_panels.html

[Jerone Young (jerone)]

@Chris
        Actually the issue is a similar issue. The fix for the X201 probably needs more tweaking to also work with this LG display.

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

I had tested the daily build from http://cdimage.ubuntu.com/daily-live/current/ without success. I looks like the same problem.

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

I made a dmesg with the latest mainline Kernel 2.6.36... with the daily Maveric.

[Jerone Young (jerone)]

@Sascha
       Thanks for the info. The issue has to do with the i915 driver and that specific LG display.

[Jerone Young (jerone)]

Can someone post the output of "lspci -vvnn" ?

[Jerone Young (jerone)]

Nevermind it is in the duplicate bug 610369...

http://launchpadlibrarian.net/52576714/Lspci.txt

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

Hi, here is the lspci-vvnn with the new Mainline 2.6.36rc2.

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

... and also a new dmesg with drm.debug=0xe from Mainline 2.6.36rc2

[Robert Hooker (sarvatt)]

Can you describe the problem in more detail by any chance? Is the screen black for the entire boot process? Does the backlight come on with a black screen or does the display completely turn off after the bios screen?

[Jerone Young (jerone)]

@Robert
         The issue as with bug 554569 is that the screen is not being properly cut on by the i915 driver. So the backlight is on..but no graphics are coming to the screen at all.

         We have seen this issue with other displays as well in the past with the i915 driver. This may just need a tweak to the same fix to handle these displays also.

[Robert Hooker (sarvatt)]

(In reply to comment #8)
> Created an attachment (id=38010) [details]
> dmesg of boot with modeset=1 (overlay kernel)
>
> here's the dmesg of booting the overlay image with modeset=1 and drm.debug=0xe

<email address hidden>: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop vesafb from loading but the invalid module parameter will.

[Adam (adam-redhat-bugs)]

*** Bug 618481 has been marked as a duplicate of this bug. ***

[Adam (adam-redhat-bugs)]

Upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=29141

Jesse Barnes apparently now has a matching system and is working on this.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Adam (adam-redhat-bugs)]

Jesse's posted fixes to his edp-hacks branch which others have tested with positive results - see the upstream bug. I'm trying to patch the fixes onto an F15 kernel build to test right now.

I'm fairly sure the fixes are the commits:

17 hours ago Jesse Barnes drm/i915/dp: more broken sequencing fixes edp-hacks commit | commitdiff | tree | snapshot
43 hours ago Jesse Barnes drm/i915/dp: broken eDP power sequencing bits commit | commitdiff | tree | snapshot
43 hours ago Jesse Barnes drm/i915/dp: wait for panel idle when enabling/disablin... commit | commitdiff | tree | snapshot

[Adam (adam-redhat-bugs)]

that's:

* http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=commit;h=f0c744bbce33c64bedbe15d9785efafd5380c58c

* http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=commit;h=050486e2f3f8aa97c5f8afdc9b898b00a7114493

* http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=commit;h=4da9b7d2917beb1f8aa9e7e4f6d4f10338b0f637

i think the other changes in the branch are not directly related to this bug, but haven't checked yet, it would probably be best to ask Jesse.

Proposing this as NTH for final.

[Adam (adam-redhat-bugs)]

Discussed at the blocker/NTH review meeting today, given the ickiness of making changes to panel code this late, we decided not to take it as NTH.

[Adam (adam-redhat-bugs)]

so I'm sucking at making these patches apply to the f15 kernel and build. But they have gone into drm-intel-next as part of a giant change set (just look at all the commits from Jesse dated together, late on 7th Oct). ajax, could you possibly just pull that whole change set into the f15 kernel (note: f15 not f14) for me to try? thanks!

[Adam (adam-redhat-bugs)]

OK, so I couldn't get a clean patch against a Fedora kernel, but I just built a kernel straight from the upstream drm-intel-next tree and confirmed that it works great.

[Christian Wehrfritz (cfritz)]

(In reply to comment #49)
> Bug #29278 http://bugs.freedesktop.org/show_bug.cgi?id=29278 looks very similar
> to this and patch is already available. Did anyone try that yet?

I compiled the current drm-staging today, but it still goes black.

[Christian Wehrfritz (cfritz)]

> Thanks for checking. Looks like we may have to do a few more stabs to see if we
> can find an "easy" solution.

What would be those next stabs?

[Vietor (vietor)]

I'm experiencing the same issue on a new U160-0894 (i5-470UM, working Turbo). I've tried current (Thu Oct 28 15:22:13 PDT 2010) versions of the fixes/next/staging branches to no effect.

To be clear:
Backlight is on, no output appears once the i915 driver loads.
External monitor works fine.
i915.modeset=0 'works', but of course the intel driver then cannot load later.
No other framebuffer driver is compiled in and dmesg says: "fbcon: inteldrmfb (fb0) is primary device"

In my dmesg I'm also seeing: "[drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero."

Which I did not see in either of the posted dmesg outputs. However the backlight appears to be fine, and even responds to the Fn+Up/Down controls while the screen is blank (more or less bleed-through), so probably not useful.

Please let me know what I can do to help.

[Gregor Müllegger (gregor-muellegger)]

I would also like to help with anything that's possible.

I would even spend a decent amount of money if this can help to resolve the
issue quicker. If someone wants to tackle this task as freelancer, feel free
to contact me and we will discuss the details then.

Am 2010 10 28 23:43 schrieb <email address hidden>:
> https://bugs.freedesktop.org/show_bug.cgi?id=29647
>
> Vietor Davis <email address hidden> changed:
>
> What |Removed |Added
>
----------------------------------------------------------------------------
> CC| |<email address hidden>
>
> --- Comment #52 from Vietor Davis <email address hidden> 2010-10-28
15:43:36 PDT ---
> I'm experiencing the same issue on a new U160-0894 (i5-470UM, working
Turbo).
> I've tried current (Thu Oct 28 15:22:13 PDT 2010) versions of the
> fixes/next/staging branches to no effect.
>
> To be clear:
> Backlight is on, no output appears once the i915 driver loads.
> External monitor works fine.
> i915.modeset=0 'works', but of course the intel driver then cannot load
later.
> No other framebuffer driver is compiled in and dmesg says: "fbcon:
inteldrmfb
> (fb0) is primary device"
>
> In my dmesg I'm also seeing: "[drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero."
>
> Which I did not see in either of the posted dmesg outputs. However the
> backlight appears to be fine, and even responds to the Fn+Up/Down controls
> while the screen is blank (more or less bleed-through), so probably not
useful.
>
> Please let me know what I can do to help.
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

[Adam (adam-redhat-bugs)]

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Vietor (vietor)]

Using intel_reg_dumper, the suggestions in this discussion, and a bit of poking around, I've attempted to harmonize the output from intel_reg_dumper between the plain no-frame-buffer output, and the intelfb using KMS.

Specifically I'm using the drm-intel-fixes branch of the current version of drm-intel, and have applied the two suggestions in this thread, and reverted commit 12e8ba25ef52f19e7a42e61aecb3c1fef83b2a82.

None of this has caused any change in behavior which I've noticed, but the diff of the intel_reg_dumper output is getting fairly small and perhaps someone who actually has some idea what they are doing can find some insight in it.

[Vietor (vietor)]

Created attachment 40129
fulltext of intel_reg_dumper showing diff between no-fb (as -) and intelfb (as +)

[Marc Bevand (bevand-m)]

I have an additional piece of information that other users did not report. I can reproduce this bug on my Lenovo U160 laptop. When loading i915.ko, the laptop display panel (LVDS) becomes blank. However I discovered that what actually happens is that the moment i915.ko is loaded, the output switches to HDMI. I found this out by connecting a monitor to the laptop's HDMI output while the LCD panel was blank.

Like many reporters, I can reproduce the bug with different kernels: Ubuntu 10.10's 2.6.35-based kernel, as well as a vanilla 2.6.36.

After discovering this, I tried playing with "xrandr --output LVDS --auto" (and --off) but all it seems to do is to turn the backlight on and off. The display remains blank.

PS: Vietor Davis' last message reveals what seems to be an important difference in the registers, between using vesa and i915:
- CPU_VGACNTRL: 0x0020298e (enabled)
+ CPU_VGACNTRL: 0x80000000 (disabled)
Anyone can comment on this?

[Vietor (vietor)]

Marc Bevand:
"However I discovered that what actually happens is that the moment i915.ko is loaded, the output switches to HDMI. I found this out by connecting a monitor to the laptop's HDMI output while the LCD panel was blank."

I do not think this is correct, rather I think what you are seeing is the HDMI port correctly detect a connection and begin using it. I can plug a VGA connector into my U160 and see the same behavior you describe, however, if you look at "/sys/class/drm/card0-*/enabled" I think you'll see what's actually happening here (At least what I *think* is happening...).

To begin with, in my configuration, only "/sys/class/drm/card0-LVDS-1/enabled" says 'enabled', however, as I plug in a VGA connector "/sys/class/drm/card0-VGA-1/enabled" transitions from 'disabled' to 'enabled' and I see the expected output on the monitor.

It looks very much like everything is working, except the LVDS output.

[Adam (adam-redhat-bugs)]

bumping this to at least 14 because i don't see it being backported to 13; it may eventually only be fixed in rawhide/15.

it was fixed briefly in rawhide by a backport of drm-intel-next/edp-fixes but that was backed out apparently for causing other problems, so current status is that it's still broken everywhere.

[Chris Wilson (ickle)]

*** This bug has been marked as a duplicate of bug 31596 ***

[Vietor (vietor)]

Applied the patch posted in the other thread manually as it hadn't shown up in git yet. Confirmed fixed my U160 model 0894 with a U470 (i5-470UM) CPU.

Thank you Chris, you've made my week.

[Claes (claes-redhat-bugs)]

I had similar problems on a Lenovo U160 with integrated Intel graphics. linux-2.6.37-rc8 fixes the problem for me. Have you tried it?

[Adam (adam-redhat-bugs)]

Yes, and no. When it comes to graphics, 'similar' problems are generally not similar at all. I'm already well aware of all relevant changes for this bug. But thanks. The reason this report isn't changing much is that all the interesting stuff is happening on the upstream report.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Adam (adam-redhat-bugs)]

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[isync (o-zucker)]

It might be this bug resurfaced somewhere else:

Running 11.04 with the 2.6.38-8-generic kernel in Ubuntu Classic mode, the system boots okay without any tweaks (out-of-the-box). Having the screen-saver coming up is no problem either. But: when you close the lid and let the system closed for some time, opening the lid again presents you a black screen with the backlight on.

Some sources indicated going to compiz manager: OpenGL plugin: uncheck "Sync to VBlank", but this seems to be a completely unrelated issue with the system freezing after a lid-close but here the system seems to continue running properly behind a black screen!

I anyone more aware of all the display related bugs feels this needs to be a new bug, please open one and link us up.

[Rasmus Olesen (jernelg)]

After updating from 2.6.38-8-generic to 2.6.38-9-generic or 2.6.38-11-generic i got black screen on boot (Systems runs behind black screen.)
The black screen is also present in recovery mode.
2.6.38-9-generic or 2.6.38-11-generic boots fine with nomodeset parameter.
Thought it was a "new" Unity problem, since i hadn't seen it since 10.04 and 10.10, but Xubuntu have same symptoms.

[madbiologist (me-again)]

@ isync and Rasmus - does it work if you add i915.lvds_use_ssc=0 to your kernel boot options?

[Rasmus Olesen (jernelg)]

Awesome. Thanks.
It works on 2.6.38-11, but i have not been able to try it on 2.6.38-9.
What is the catch ? :) i have not been able to find anything but vague descriptions on the boot parameter i915.vlds_use_ssc=0. Any good links for information ?

[isync (o-zucker)]

@madbiologist
Normally my system (as long as I haven't forgotten about some leftover switches somewhere) is running 11.04 + 2.6.38-8 without any kernel options. Vanilla, just like the dist-upgrade process supplied me with.

After your comment I added the kernel options. To force the error I put the machine into stand-by and after wake-up it presented me with the "running system with black but lit screen" error. So no change with your kernel options.

[madbiologist (me-again)]

@Rasmus - the only info I know about for the i915.lvds_use_ssc=0 boot parameter (you made a typo BTW) is comments 90, 92, 93 and 99 in this bug. It seems that the only catch is that using this boot parameter causes other hardware (such as the ThinkPad T410) to boot with a black screen.

FYI, LVDS stands for Low-voltage differential signalling, it is the type of connection used to connect the graphics card/chip to the screen in many laptops such as your U160. It is also used in HyperTransport, FireWire, Serial ATA and PCI Express, but this patch doesn't affect those systems as it is specific to the Intel i915 section of the DRM section of the Linux kernel. According to Wikipedia, "Intel and AMD expect that the LVDS LCD-panel interface would no longer be supported in their product lines by 2013, with Embedded DisplayPort (eDP) and Internal DisplayPort as preferred solutions." SSC stands for Spread-Spectrum Clocking and is not really worth going into, but you can look it up if you really want.

@isync - as I suspected from your comment 107, the info you supplied in comment 111 confirms that you have a different bug. The only arrandale (Core i3, i5, and i7) bugs I could find have been fixed, so I recommend that you file a new bug using the ubuntu-bug command.

[Rasmus Olesen (jernelg)]

@madbiologist
I just tested Suspend, and i works fine to.
The typo must be due to the late hours, i have the right parameter in my boot menu, so i got i right once i guess :)
Thanks for all the help and info.

[Chris Van Hoof (vanhoof)]

Can anyone confirm that this bug is still present in 11.10 without the use of i915.lvds_use_ssc=0 as a boot time option?

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping