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

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38133)
dmesg.sodoff

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38134)
dmesg.novesakernel

[Christian Wehrfritz (cfritz)]

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

I had no module named vesafb - that was compiled into the kernel. The dmesg.sodoff contains the dmesg from the run that you suggested. I then compiled a kernel without vesafb (.config: # CONFIG_FB_VESA is not set), the dmesg is dmesg.novesakernel. Note that I always booted into single mode. (Booting into X, logging in, opening a xterm and pulling the dmesg is a bit hard without a display)

[Robert Hooker (sarvatt)]

(In reply to comment #16)
> > <email address hidden>: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop
> > vesafb from loading but the invalid module parameter will.
>
> I had no module named vesafb - that was compiled into the kernel. The
> dmesg.sodoff contains the dmesg from the run that you suggested. I then
> compiled a kernel without vesafb (.config: # CONFIG_FB_VESA is not set), the
> dmesg is dmesg.novesakernel. Note that I always booted into single mode.
> (Booting into X, logging in, opening a xterm and pulling the dmesg is a bit
> hard without a display)

Yeah it's not a module but you still stop it from loading by passing an invalid option to it, no need to recompile :) Chris was just asking for a log of that kernel without vesafb and it was still loading in the dmesg you posted in comment 8.

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

Hi,

I tried to make a startup without loading the vesafb without success.

I attached the dmesg.

Is there any other idea for blocking the vesafb?

cu
Sascha

[Christian Wehrfritz (cfritz)]

> Is there any other idea for blocking the vesafb?

Yes. I learned that parts of the kernel can be deactivated by feeding incorrect parameters to non-existing modules :-)

See https://bugs.freedesktop.org/show_bug.cgi?id=29647 and the attachment dmesg.sodoff.

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

I have followed the bug-report 29647 at freedesktop.org and tried it with the non.existing parameters.

You can see it inside the dmesg in the attachment of post #27.
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.36-020636rc2-generic root=UUID=7c27cd01-d23e-4fd2-afb1-445ef72f3d0e ro quiet drm.debug=0xe i915.modeset=1 vesafb.grtfdse=0x34 novesafb single

I tried also vesafb=sodoff.

[Adam (adam-redhat-bugs)]

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

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

(In reply to comment #17)
> (In reply to comment #16)
> > > <email address hidden>: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop
> > > vesafb from loading but the invalid module parameter will.
> >
> > I had no module named vesafb - that was compiled into the kernel. The
> > dmesg.sodoff contains the dmesg from the run that you suggested. I then
> > compiled a kernel without vesafb (.config: # CONFIG_FB_VESA is not set), the
> > dmesg is dmesg.novesakernel. Note that I always booted into single mode.
> > (Booting into X, logging in, opening a xterm and pulling the dmesg is a bit
> > hard without a display)
>
> Yeah it's not a module but you still stop it from loading by passing an invalid
> option to it, no need to recompile :) Chris was just asking for a log of that
> kernel without vesafb and it was still loading in the dmesg you posted in
> comment 8.

I have followed your description and tried it with the non.existing parameters.

You can see it inside the dmesg in the attachment of launchpad post #27 https://bugs.launchpad.net/null/+bug/608907/comments/27 .

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.36-020636rc2-generic root=UUID=7c27cd01-d23e-4fd2-afb1-445ef72f3d0e ro quiet drm.debug=0xe i915.modeset=1 vesafb.grtfdse=0x34 novesafb single

I tried also vesafb=sodoff.

[Christian Wehrfritz (cfritz)]

> I have followed your description and tried it with the non.existing parameters.

Well, not quite. If you take
 - the kernel from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay and
 - a command line like BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+ root=UUID=980cc70e-5947-4f68-93af-526b4eb3224e ro vesafb=sodoff single quiet splash

you'd get the dmesg they are interested in (and which I have already posted 3 days ago, see dmesg.sodoff)

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

(In reply to comment #19)
> > I have followed your description and tried it with the non.existing parameters.
>
> Well, not quite. If you take
> - the kernel from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay
> and
> - a command line like BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+
> root=UUID=980cc70e-5947-4f68-93af-526b4eb3224e ro vesafb=sodoff single quiet
> splash
>
> you'd get the dmesg they are interested in (and which I have already posted 3
> days ago, see dmesg.sodoff)

thx!

ok, what else can we do to support the fixing process?

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

(In reply to comment #19)
> > I have followed your description and tried it with the non.existing parameters.
>
> Well, not quite. If you take
> - the kernel from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay
> and
> - a command line like BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+
> root=UUID=980cc70e-5947-4f68-93af-526b4eb3224e ro vesafb=sodoff single quiet
> splash
>
> you'd get the dmesg they are interested in (and which I have already posted 3
> days ago, see dmesg.sodoff)

Is there anything that I can do at the moment?
Plz, let me know.

[Francisco Cribari (cribari)]

A related bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/600453

See also

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

[Chris Wilson (ickle)]

All the latest Arrandale/DP fixes have been compiled into

http://cgit.freedesktop.org/~ickle/drm-intel/log/?h=drm-intel-staging

Please can you try that branch (which is essentially 2.6.36-rc3 + regression fixes + eDP) to see if we have nailed the problem for 2.6.36.

[Sven Bjarke Gudnason (sbgudnason)]

I have the same problem on a Lenovo U160 core i3 and also confirm that the patches which work for the X201 which has a similar problem does not work on the U160.
I can boot lucid and maverick with the option i915.modeset=0 .
Does anyone have a workaround to make the vesa driver show the resolution 1366x768 ? I remember once there was a package called 915resolution for ubuntu 6.0 which added widescreen resolutions for the intel chip, but this package does not exist anymore.
Does anyone know if there is an older version of ubuntu which works? I have tried Karmic Koala and Jaunty Jackalope which did not seem to work for me.

[Christian Wehrfritz (cfritz)]

> Please can you try that branch (which is essentially 2.6.36-rc3 + regression
> fixes + eDP) to see if we have nailed the problem for 2.6.36.

I did:
 git clone git://anongit.freedesktop.org/~ickle/drm-intel
 git checkout -b testing origin/drm-intel-staging

The screen is as black as ever. I'll attach the dmesg.36rc3 (drm.debug=0xe i915.modeset=1 vesafb=sodoff single)

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38486)
dmesg of drm-intel-staging

[Chris Wilson (ickle)]

Thanks for testing. It's just a normal LVDS panel, everything looks in order... So why is it still black? Is the backlight still on? What else could we be misprogramming? LVDS panel depth?

Can you download http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and build intel_reg_dumper and attach its output? Lets see if there are any oddities in the registers.

[Chris Wilson (ickle)]

And I have to ask where did you find an Arrandale U160? Is it still a 11.1" chasis? That would make a good netbook...

[Christian Wehrfritz (cfritz)]

> Is the backlight still on?

I think so. The last thing I see is a ureadahead exit (Ubuntu 10.10), then the screen goes totally black for a short moment, then it gets a bit brighter, which looks like the LED backlight.

> Can you download http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and build
> intel_reg_dumper and attach its output? Lets see if there are any oddities in
> the registers.

I pulled the regdump with the latest kernel, that you recommended, after booting into drm.debug=0xe i915.modeset=1 vesafb=sodoff single

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38513)
intel_reg_dump 2.6.36-rc3 after screen went black

[Chris Wilson (ickle)]

Hmm, as expected they look fine.

Can you grab the same reg dump but with i915.modeset=0 (i.e. so I can compare with what the BIOS is using)?

At this point, my suspicion is that we are failing to setup the FDI link correctly. Does changing mode help? Can you also grab a reg dump with i915.modeset=1 at 640x480?

X should be happy to run and change mode using xrandr, or you can use modetest from libdrm.git.

[Christian Wehrfritz (cfritz)]

(In reply to comment #26)
> And I have to ask where did you find an Arrandale U160?

It's a Lenovo Ideapad U160:
http://shop.lenovo.com/us/landing_pages/ideapad/2010/u-series

> Is it still a 11.1" chasis?

11.6"

> That would make a good netbook...

Well, up to now, I don't consider it good.. I've never had that much trouble getting a laptop to run Linux during the last 15 years. The panel that is not working is the most obvious annoyance. Besides that, the WLan chip doesn't work with the vanilla kernel, the ethernet chip doesn't work at all, yet (but I've read, that it should work with extra drivers). And the audio out won't work with jackd.

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38514)
intel_reg_dump 2.6.36-rc3 with xforcevesa modeset=0

[Chris Wilson (ickle)]

Ah, they don't seem to have made it to this side of the pond. Perhaps Jesse can pick one up?

[Chris Wilson (ickle)]

The biggest differences that stand out are:

vesa:
PCH_DREF_CONTROL: 0x00001002 (cpu source disable, ssc_source enable, nonspread_source disable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
PCH_FPA1: 0x00030d07 (n = 3, m1 = 13, m2 = 7)
FDI_TXA_CTL: 0xb01c4000 (enable, train pattern not train, voltage swing 0.4V,pre-emphasis none, port width X4, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
FDI_RXA_CTL: 0xb01a2050 (enable, train pattern not train, port width X4, 6bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, PCDClk)

i915:
PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
PCH_FPA1: 0x00010e05 (n = 1, m1 = 14, m2 = 5)
FDI_TXA_CTL: 0xb0044000 (enable, train pattern not train, voltage swing 0.4V,pre-emphasis none, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
FDI_RXA_CTL: 0xb0022050 (enable, train pattern not train, port width X1, 6bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, PCDClk)

That is we attempt to use a single lane for driving the FDI with spread-spectrum, whereas bios/vesa uses 4 lanes (and no ssc).

[Chris Wilson (ickle)]

Stab in the dark, let's boost the b/w to the panel:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 2951552..64240f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3706,6 +3706,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
                         */
                        u32 bps = target_clock * bpp * 21 / 20;
                        lane = bps / (link_bw * 8) + 1;
+ lane = 4; /* XXX bug 29647 */
                }

                intel_crtc->fdi_lanes = lane;

[Chris Wilson (ickle)]

But we should be using around 57% of the b/w of a single lane for your panel configuration. So it might be the PLL configuration instead...

[Chris Wilson (ickle)]

What is the output of sudo intel-gpu-tools/tools/intel_reg_read 0x46000 ?

[Christian Wehrfritz (cfritz)]

The patch didn't work, it's still black.

(In reply to comment #36)
> What is the output of sudo intel-gpu-tools/tools/intel_reg_read 0x46000 ?

0x46000 : 0x82B3019

for both, the vesa kernel, and the patched kernel (vesafb=sodoff single)

[Chris Wilson (ickle)]

Found it in the reg_dumper: FDI_PLL_BIOS_0: 0x082b3019

Ok, so not an unusual FDI configuration.

[Chris Wilson (ickle)]

Next stab before diving into the PLL maze, disable the nonspread source:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 1f6196a..fd74159 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3730,7 +3730,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
                temp = I915_READ(PCH_DREF_CONTROL);
                /* Always enable nonspread source */
                temp &= ~DREF_NONSPREAD_SOURCE_MASK;
- temp |= DREF_NONSPREAD_SOURCE_ENABLE;
+ //temp |= DREF_NONSPREAD_SOURCE_ENABLE;
                I915_WRITE(PCH_DREF_CONTROL, temp);
                POSTING_READ(PCH_DREF_CONTROL);

[Christian Wehrfritz (cfritz)]

(In reply to comment #39)
> Next stab before diving into the PLL maze, disable the nonspread source:

I did that (and removed the lane = 4;). It did not help.

Before we go diving, two questions:
 - I assume, it's sufficient, to `make modules; make modules_install`, instead of building a new kernel the ubuntu way (sudo make-kpkg --initrd kernel_image kernel_headers; sudo dpkg -i linux-image-2.6.*.Custom_i386.deb), right?

 - if I test one of your patches, what output do you want me to attach? reg_dump and dmesg, every time?

[Chris Wilson (ickle)]

(In reply to comment #40)
> (In reply to comment #39)
> > Next stab before diving into the PLL maze, disable the nonspread source:
>
> I did that (and removed the lane = 4;). It did not help.
>
> Before we go diving, two questions:
> - I assume, it's sufficient, to `make modules; make modules_install`, instead
> of building a new kernel the ubuntu way (sudo make-kpkg --initrd kernel_image
> kernel_headers; sudo dpkg -i linux-image-2.6.*.Custom_i386.deb), right?

Hmm, I've had issues where i915 is included in the initrd and so had to rerun update-initramfs which was not happening automatically on Ubuntu. Though I don't use initramfs unless I'm building a full disto-equivalent kernel, so I may be misinformed.

> - if I test one of your patches, what output do you want me to attach?
> reg_dump and dmesg, every time?

For those two stabs, the quickest way to check would be through intel_reg_dumper. dmesg doesn't contain the relevant information unless we patch it in.

[Christian Wehrfritz (cfritz)]

(In reply to comment #41)

> For those two stabs, the quickest way to check would be through
> intel_reg_dumper.

ok, the diff between the rc3 and the disabled nonspread source is:
root@cfritz-laptop:~# diff regs.36rc3 regs.disable_nonspread_source
64c64
< PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
---
> PCH_DREF_CONTROL: 0x00001002 (cpu source disable, ssc_source enable, nonspread_source disable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)

[Chris Wilson (ickle)]

Jesse reorganised the code around the FDI setup and worked on a few bugs that implied we weren't setting up the panel in the right order, and there were a few missing flushes whilst training the FDI...

So nothing that purports to explicitly target this bug, but I think we're heading the right direction!

Can you check with the current code:

git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-next

and see how we are faring?

[Christian Wehrfritz (cfritz)]

> Can you check with the current code:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
> drm-intel-next
>
> and see how we are faring?

It looks the same (black), but there are changes in the reg dumps.

I don't think that this has side effects on the panel, but Lenovo also screwed up turbo boost on this unit:
"The resistor locations that select the CPU type installed were populated with values for the i3 CPU rather than the i5 or i7. As a result the Turbo mode does not function correctly, and overall performance is limited." (http://forums.lenovo.com/t5/IdeaPad-Y-U-B-and-Z-series/U160-Turbo-Boost-broken/td-p/268106/page/2).

[Christian Wehrfritz (cfritz)]

Created an attachment (id=38633)
intel_reg_dump kernel drm-intel-next

[Chris Wilson (ickle)]

Aye no change, just we now use the "wrong" pipe for initial output (there will be a slight flicker as it changes) due to bug 30126.

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

[Christian Wehrfritz (cfritz)]

Considering that the panel works in ms windows, are there any intel_reg_dumper-like tools for windows, that I could check?

[Christian Wehrfritz (cfritz)]

> Does anyone have a workaround to make the vesa driver show the resolution
> 1366x768 ? I remember once there was a package called 915resolution
> for ubuntu 6.0 which added widescreen resolutions for the intel chip,
> but this package does not exist anymore.

You're probably talking about 915resolution from http://915resolution.mango-lang.org/

However, the chipset of the U160 is not supported (last update of i915resolution was in 2007) and the author hasn't (yet) responded.

Even if it would be supported, I don't think it would lead us to anything useable. I tried to bypass the chipset detection and forced it to detect a 915G. It then actually finds a couple of modes, but none that matches the resolution of the panel:

Mode 30 : 640x480, 8 bits/pixel
Mode 32 : 800x600, 8 bits/pixel
Mode 34 : 1024x768, 8 bits/pixel
Mode 38 : 1280x1024, 8 bits/pixel
Mode 3a : 1600x1200, 8 bits/pixel
Mode 3c : 1920x1440, 8 bits/pixel

(and then all of the above resolutions with 16 and 32 bits/pixel).

[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

[larppaxyz (larppaxyz-gmail)]

Anything else we could try?

I'm having one with i3 so i think this affects all U160:s.

[larppaxyz (larppaxyz-gmail)]

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?

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

[atla (atla)]

Who can i donate money for this? :S

I was linux only for years but wanted this great little device. Now i face the same problems as you, but i am not willing to use VESA or something non accelerated... well, i thought, it will be fixed in some months. :(

I have the i7 version of the u160, the high end version of this machine, i can confirm the same screen blackness right after boot menu on every distro i tried. Lucyd, Maverick, OpenSuse.. Fedora (newest releases) not one works.

Is this graphics chip/display combo so rare? I would be really happy if someone get it working :(

Greetings,

Marcus

[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 Wallin (clacke)]

I have a U160 with a 8086:0046 chip and Xorg reports the display as EDID vendor "AUO", prod id 12380.

Tried running 2.6.37-rc5, which as far as I understand is up-to-date with intel-drm. Problem persists.

If I boot without "nomodeset" the machine boots with the screen lit, but black. Also, it does not respond to keyboard input, so I am unable to warm reboot it.

If I boot with "nomodeset" X works, but only in 1024x768. In this case, if I do a user switch or quit X, the screen also hangs. Will try the i915.modeset=0 parameter to see if I can at least get a working 1024x768 display that doesn't hang.

[isync (o-zucker)]

I am experiencing this bug here on my U160 with an i3 U3400 CPU. Everything as described here.
The bug occurs under 10.04 and 10.10, which I both tested.

[Christian Wehrfritz (cfritz)]

This bug has been fixed by Chris Wilson. You either need to follow https://bugs.freedesktop.org/show_bug.cgi?id=31596 and compile yourself a kernel from the drm-intel-fixes repo, or you just wait until the fix is merged into the main tree.

[Claes Wallin (clacke)]

Latest drm-intel-fixes solves the problem for my i5 U160! Big hug to Chris Wilson and happy holidays to all the hard-working übergeeks making our lives better every day!

[Sascha Lars Strodthoff (sascha-krabbelmonster)]

Ok, i compiled a fixed Kernel and tried it.
The U160 is running like charme.

Thx to Chris Wilson for this Christmas present.

[isync (o-zucker)]

@Christian: Thank you so much for this hint!
And Chris for the patch!!

A few minutes ago I finished compiling a patched kernel (standard Ubuntu 10.10 2.6.35.8 kernel .conf plus just this patch here) and guess what: WORKS!
Only needed to change the Driver section in /etc/X11/xorg.conf back from vesa to intel...

This community is what makes Ubuntu/Linux great!

[madbiologist (me-again)]

The abovementioned patch has been included upstream in kernel 2.6.37-rc8, and also cc'd to the stable kernel series for review. From the changelog:

commit 448f53a1ede54eb854d036abf54573281412d650
Author: Chris Wilson
Date: Tue Dec 14 20:06:20 2010 +0000

    drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks

    Fixes the lack of output on the LVDS panel of the Lenovo U160.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31596
    Reported-and-tested-by: Dirk Gouders
    Cc: <email address hidden>
    Signed-off-by: Chris Wilson

[Claes Wallin (clacke)]

I confirm that 2.6.37-rc8 works on my Lenovo U160 with an U5400.

[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

[madbiologist (me-again)]

Bad news, this fix had to be reverted - see https://bugs.freedesktop.org/show_bug.cgi?id=32748

[madbiologist (me-again)]

Kernel 2.6.38-rc1 contains the following workaround for this problem:

commit a76150302d6e7ebc43e1a1ddaee7fd51db8da3b3
Author: Chris Wilson
Date: Wed Jan 12 17:04:08 2011 +0000

    drm/i915: Add a module option to override the use of SSC

    In order to workaround the issue with LVDS not working on the Lenovo
    U160 apparently due to using the wrong SSC frequency, add an option to
    disable SSC.

    Suggested-by: Lukács, Árpád
    Bugzillla: https://bugs.freedesktop.org/show_bug.cgi?id=32748
    Signed-off-by: Chris Wilson
    Cc: <email address hidden>

[Asko Kauppi (askok)]

Woooooooow. What a bug.

I'm joining the gang typing this on a U160 5400 we'd love to run Ubuntu on.

Would it help any to have some Chinese from Lenovo itself participate? I'm thinking of inviting them to see all this trouble and effort people are taking. Vendors really should work closer with communities, pro-actively rather. And China is supposed to be Linux-friendly. So if you see any Chinese knocking the door, be friendly. :)

[Oliver Arnold (derarnold)]

I just received my Lenovo IdeaPad U160 i5 and I installed Ubuntu 11.04 on it. Me experience:
1. The grafik works out of the box with the intel driver
2. I have trouble changing the monitor settings via the Ubuntu Controll Center. After changing the settings, the screen stays black. Even after the 30 Sec Timeout
3. This behavor causes many side effects (as I think): I suspending does not work --> Black screen, Connecting an external Monitor does not work --> Black screen

So I looked at the mentioned fix on the freedesktop site (https://bugs.freedesktop.org/show_bug.cgi?id=32748) and i have serveral questions
1. Is the fix included in 11.04 ?
2. Must I compile my own kernel? If yes, can I use one from Kernel.org or do I have to patch my own kernel?
3. If the patch is included, do I have to do some settings? In the attachment (https://bugs.freedesktop.org/attachment.cgi?id=41941) I see, that there is some variable to be set.

If requested, I can also attach some logfiles.

I hope, this helps.

Oliver

[madbiologist (me-again)]

Ubuntu 11.04 "Natty Narwhal" has the 2.6.38 kernel, so it includes the patch I mentioned in comment #93. This patch is also mentioned in comment 2 at https://bugs.freedesktop.org/show_bug.cgi?id=32748
I'm not sure if Natty includes the later patch mentioned in comments 3 and 4 at https://bugs.freedesktop.org/show_bug.cgi?id=32748
This is probably why your machine boots OK (your 1.), unlike the original reporter of this Launchpad bug and comment #12.

For your 2. and 3. problems of the screen going black after changing the settings and after suspending and after connecting an external monitor, these are probably a different bug/s than this bug and should be reported separately, but make sure you search Launchpad for the same problem/s on the same hardware before doing that. I'm not aware of any fixes for these problems on this hardware, but if any exist you will need to use a newer kernel. While some other people have reported in other Launchpad bugs that they have successfully patched their kernel, you best option would be to use a kernel from the Ubuntu kernel PPA at http://kernel.ubuntu.com/~kernel-ppa/mainline/

I have looked at the attachment https://bugs.freedesktop.org/attachment.cgi?id=41941 but could not see the variable you refer too. Can you provide more details?

[Oliver Arnold (derarnold)]

I just installed the 2.6.39-rc6 from kernel.org and guess what: Black screen after Boot :(

[Johanna Hofinger (j-hofinger)]

same problem with my lenovo u160 2.6.38-9-generic-pae #43-Ubuntu

[Ross Patterson (rossp)]

FYI, I have a U160 and I've finally gotten it working using the "i915.lvds_use_ssc=0" undocumented kernel boot argument. This makes it work for me under a number of different 2.6.39 kernels. Thanks to Chris Wilson for adding this, here's hoping google leads others to this option.

[Ross Patterson (rossp)]

One more detail, I've found it cleaner and better to add the lvds_use_ssc=0 option to the appropriate "options" line in the appropriate /etc/modprobe.d file to get resume working reliably.

[Steffen Rusitschka (rusi)]

#99 and #100 work for me, too, with the default kernel of Natty (2.6.38-8-generic #42-Ubuntu). It solved my problem of the display staying "black with full backlight" after closing and opening the lid (no standby, etc.). Thanks!

[mxjensen (mxjensen)]

Any chance a fix will be included in an update someday?

[Chris Van Hoof (vanhoof)]

It seems theres been a bit a bit more activity after the revert of 448f53a1ede54eb854d036abf . Would anyone mind testing the latest 3.0-rc6 build to confirm if this issue is still present (without using lvds_use_ssc=0) ?

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-rc6-oneiric/

Cheers,
Chris

[Chris Van Hoof (vanhoof)]

It appears this has been sorted out recently without the use of lvds_use_ssc=0:

https://patchwork.kernel.org/patch/973142/

[Chris Van Hoof (vanhoof)]

link to patch submitted in June: https://patchwork.kernel.org/patch/973182/

[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