Ping,
To recap, the black screen first show up after the ACPI change to use widows 8
string. The i915_setmode function did not crash. The printk output
from that function seems the same as the one that is in 3.6 kernel.
I also include the 3.6 and 3.7 kernel dmesg. The black screen is 100%
reproducible.
Any suggestion how to further debug this i9515 black screen problem?
I really want to get it fixed.
Thanks
Chris
On Fri, Feb 22, 2013 at 2:42 PM, Chris Li <[email protected]> wrote:
> Ping. Any update for this black screen problem?
>
> Chris
>
> On Wed, Feb 20, 2013 at 1:04 PM, Chris Li <[email protected]> wrote:
>> Here is the dmesg with "drm.debug=0xe" at
>> 80187431762989ebade986468d3c548287a12689
>>
>> That is the 3.6 kernel, exactly one commit before the ACPI commit
>> which triggering the black screen.
>>
>> Thanks
>>
>> Chris
On Mon, Mar 4, 2013 at 6:11 PM, Chris Li <[email protected]> wrote:
> To recap, the black screen first show up after the ACPI change to use widows 8
> string. The i915_setmode function did not crash. The printk output
> from that function seems the same as the one that is in 3.6 kernel.
> I also include the 3.6 and 3.7 kernel dmesg. The black screen is 100%
> reproducible.
>
> Any suggestion how to further debug this i9515 black screen problem?
> I really want to get it fixed.
Sorry for missing out on this one, I'll add a few more mailing lists to.
Backlight issues themselves are usually a pain. I've looked through
your debug dmesg and there doesn't seem to be anything bad going on.
Two things to test:
- Can you please check whether any of the backlight drivers in
/sys/class/backlight does anything? You need to frob the brightness
file. Please also list all the drivers you have.
- Please grab the lates git of intel-gpu-tools and attach the output
of intel_reg_dumper for both a working and a broken kernel. The git
tree is at:
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Since backlight bugs usually take a lot of poking to figure out it
might be good to keep things together in a bugzilla report.
bugs.freedesktop.org, DRI -> DRM (Intel) is the preferred location,
please file a report there and attach the dump files (and the debug
dmesg logs we've gathered already).
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Meh, forgotten to actually cc more lists ...
-Daniel
On Mon, Mar 4, 2013 at 6:49 PM, Daniel Vetter <[email protected]> wrote:
> On Mon, Mar 4, 2013 at 6:11 PM, Chris Li <[email protected]> wrote:
>> To recap, the black screen first show up after the ACPI change to use widows 8
>> string. The i915_setmode function did not crash. The printk output
>> from that function seems the same as the one that is in 3.6 kernel.
>> I also include the 3.6 and 3.7 kernel dmesg. The black screen is 100%
>> reproducible.
>>
>> Any suggestion how to further debug this i9515 black screen problem?
>> I really want to get it fixed.
>
> Sorry for missing out on this one, I'll add a few more mailing lists to.
>
> Backlight issues themselves are usually a pain. I've looked through
> your debug dmesg and there doesn't seem to be anything bad going on.
>
> Two things to test:
> - Can you please check whether any of the backlight drivers in
> /sys/class/backlight does anything? You need to frob the brightness
> file. Please also list all the drivers you have.
> - Please grab the lates git of intel-gpu-tools and attach the output
> of intel_reg_dumper for both a working and a broken kernel. The git
> tree is at:
>
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
>
> Since backlight bugs usually take a lot of poking to figure out it
> might be good to keep things together in a bugzilla report.
> bugs.freedesktop.org, DRI -> DRM (Intel) is the preferred location,
> please file a report there and attach the dump files (and the debug
> dmesg logs we've gathered already).
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Thanks Daniel
I am recompiling the kernel.
I will also open a bug in bugzilla when I collect all the relative information.
Chris
On Mon, Mar 4, 2013 at 9:50 AM, Daniel Vetter <[email protected]> wrote:
>> Two things to test:
>> - Can you please check whether any of the backlight drivers in
>> /sys/class/backlight does anything? You need to frob the brightness
>> file. Please also list all the drivers you have.
This is the good one before
the acpi change.
lrwxrwxrwx. 1 root root 0 Mar 4 15:05 acpi_video0 ->
../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
lrwxrwxrwx. 1 root root 0 Mar 4 15:05 acpi_video1 ->
../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
lrwxrwxrwx. 1 root root 0 Mar 4 15:05 intel_backlight ->
../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
The brightness,actual_brightness and max_brightness are all
4648.
>> - Please grab the lates git of intel-gpu-tools and attach the output
>> of intel_reg_dumper for both a working and a broken kernel. The git
>> tree is at:
I attach the reg dump file here.
Thanks
Chris
On Mon, Mar 4, 2013 at 3:16 PM, Chris Li <[email protected]> wrote:
>>> Two things to test:
>>> - Can you please check whether any of the backlight drivers in
>>> /sys/class/backlight does anything? You need to frob the brightness
>>> file. Please also list all the drivers you have.
This is the kernel with the ACPI change causing the black screen.
lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video0 ->
../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video1 ->
../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
lrwxrwxrwx. 1 root root 0 Mar 4 15:20 intel_backlight ->
../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
Here is the interesting part. The brightness and max_brightness is all
set to 4648,
However, the actual brightness is 0. The bl_power is also 0. I think
you are on to some thing.
I attach the reg dump as intel-reg-bad.
Chris
On Tue, 05 Mar 2013, Chris Li <[email protected]> wrote:
> On Mon, Mar 4, 2013 at 3:16 PM, Chris Li <[email protected]> wrote:
>>>> Two things to test:
>>>> - Can you please check whether any of the backlight drivers in
>>>> /sys/class/backlight does anything? You need to frob the brightness
>>>> file. Please also list all the drivers you have.
>
> This is the kernel with the ACPI change causing the black screen.
>
> lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video0 ->
> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
> lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video1 ->
> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
> lrwxrwxrwx. 1 root root 0 Mar 4 15:20 intel_backlight ->
> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
>
> Here is the interesting part. The brightness and max_brightness is all
> set to 4648,
> However, the actual brightness is 0. The bl_power is also 0. I think
> you are on to some thing.
Hi Chris -
Interesting snippets from your dmesgs:
1) good
[ 0.000000] Linux version 3.6.0-rc6+ ([email protected]) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #25 SMP Wed Feb 20 12:55:06 PST 2013
...
[ 5.341431] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
[ 5.341442] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
[ 5.342572] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
[ 5.342578] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
2) bad
[ 0.000000] Linux version 3.8.0-rc7+ ([email protected]) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #23 SMP Tue Feb 19 19:24:57 PST 2013
...
[ 5.692853] [drm:asle_set_backlight], bclp = 0x800000ff
[ 5.692865] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
[ 5.692870] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
[ 5.693401] [drm:asle_set_backlight], bclp = 0x80000000
[ 5.693408] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
[ 5.693413] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0
(We've added another debug print to asle_set_backlight.)
For some reason we get two asle requests in a row. In the good kernel
it's the same request twice, in the bad kernel the second requests is
for 0 backlight. The register dumps seem to confirm this.
Please try a recent kernel, with and without the the bisected bad commit
commit a57f7f9175b8ccbc9df83ac13860488913115de4
Author: Bob Moore <[email protected]>
Date: Fri Aug 17 10:55:02 2012 +0800
ACPICA: Add Windows8/Server2012 string for _OSI method.
reverted. Is the difference the same? Check reg dumps and dmesgs with
drm.debug=0xe.
Thanks,
Jani.
On Mon, Mar 11, 2013 at 6:16 AM, Jani Nikula
<[email protected]> wrote:
> Interesting snippets from your dmesgs:
>
> 1) good
>
> [ 0.000000] Linux version 3.6.0-rc6+ ([email protected]) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #25 SMP Wed Feb 20 12:55:06 PST 2013
> ...
> [ 5.341431] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
> [ 5.341442] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
> [ 5.342572] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
> [ 5.342578] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
>
> 2) bad
>
> [ 0.000000] Linux version 3.8.0-rc7+ ([email protected]) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #23 SMP Tue Feb 19 19:24:57 PST 2013
> ...
> [ 5.692853] [drm:asle_set_backlight], bclp = 0x800000ff
> [ 5.692865] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
> [ 5.692870] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
> [ 5.693401] [drm:asle_set_backlight], bclp = 0x80000000
> [ 5.693408] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648
> [ 5.693413] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0
>
> (We've added another debug print to asle_set_backlight.)
>
> For some reason we get two asle requests in a row. In the good kernel
> it's the same request twice, in the bad kernel the second requests is
> for 0 backlight. The register dumps seem to confirm this.
>
> Please try a recent kernel, with and without the the bisected bad commit
Hi, I did try the tip of Linus git tree. However I can't make the kernel
boot regardless bad commit or not. The kernel just hang there after grub2
load the kernel and initram image. It looks like a different problem than the
intel black screen because it don't even get to the point show any console
print out.
I will try the intel branch instead.
Chris
On Thu, Mar 14, 2013 at 1:10 PM, Chris Li <[email protected]> wrote:
>>
>> Please try a recent kernel, with and without the the bisected bad commit
>
> I will try the intel branch instead.
Hi, I attach the two demsg and with and without the bad commit
on the intel nightly branch. Without the bad commit it actually works.
However, on the tip of intel nightly. the moeset work around does not work
there any more.
Let me know if you need any thing else from me.
Chris
On Thu, 14 Mar 2013, Chris Li <[email protected]> wrote:
> Hi, I attach the two demsg and with and without the bad commit
> on the intel nightly branch. Without the bad commit it actually works.
> However, on the tip of intel nightly. the moeset work around does not work
> there any more.
Hi Chris, thanks for the dmesgs.
So the diff in the dmesgs from intel nightly (bad) to the same with
a57f7f9175b8ccbc9df83ac13860488913115de4 reverted (good) wrt backlight
boils down to this, repeated a few times:
-[drm:asle_set_backlight], bclp = 0x80000000
+[drm:asle_set_backlight], bclp = 0x800000ff
[drm:intel_panel_get_max_backlight], max backlight PWM = 4648
-[drm:intel_panel_actually_set_backlight], set backlight PWM = 0
-[drm:asle_set_backlight], bclp = 0x80000000
+[drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
+[drm:asle_set_backlight], bclp = 0x800000ff
[drm:intel_panel_get_max_backlight], max backlight PWM = 4648
-[drm:intel_panel_actually_set_backlight], set backlight PWM = 0
+[drm:intel_panel_actually_set_backlight], set backlight PWM = 4648
Fun. The BIOS seems to ask for zero backlight. Maybe it means something
else for Windows 8. White is the new black or something.
> Let me know if you need any thing else from me.
Just one idea, please attach hexdumps of
/sys/kernel/debug/dri/0/i915_opregion (with debugfs mounted there,
obviously) for both kernels. Maybe we're missing something there that
the BIOS thinks Windows 8 should handle.
I've never used the acpi_osi= kernel parameter, but it looks like you
could workaround this with acpi_osi="!Windows 2012". Please check that
running the "bad" kernel.
BR,
Jani.
On Fri, Mar 15, 2013 at 12:29 AM, Jani Nikula
<[email protected]> wrote:
> Fun. The BIOS seems to ask for zero backlight. Maybe it means something
> else for Windows 8. White is the new black or something.
Interesting.
>
> Just one idea, please attach hexdumps of
> /sys/kernel/debug/dri/0/i915_opregion (with debugfs mounted there,
> obviously) for both kernels. Maybe we're missing something there that
> the BIOS thinks Windows 8 should handle.
Two kernels have different dump. BTW I have switched to tip of git again.
Last pull from the git seems fix the can't boot problem.
I attach the files here. The good one is tip with win8 acpi revert.
Chris
On Fri, Mar 15, 2013 at 12:29 AM, Jani Nikula
<[email protected]> wrote:
> I've never used the acpi_osi= kernel parameter, but it looks like you
> could workaround this with acpi_osi="!Windows 2012". Please check that
> running the "bad" kernel.
That did not work for me. Still have black screen on the tip of git.
I did that to the gurb2-efi.cfg
Here is my kernel cmdline:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.9.0-rc2+
root=UUID=75d90f06-bcdc-40c0-a3a3-7edf9af38d41 ro rd.md=0 rd.lvm=0
rd.dm=0 rd.luks=0 vconsole.keymap=us LANG=en_US.UTF-8 drm.debug=0xe
"acpi_osi=!Windows\x202012"
Chris
On Fri, Mar 15, 2013 at 12:29 AM, Jani Nikula
<[email protected]> wrote:
> Fun. The BIOS seems to ask for zero backlight. Maybe it means something
> else for Windows 8. White is the new black or something.
I did some experiment, I go to intel_backlight directory.
It show brightness is 4648, but actual_brightness is 0.
Then I do "echo 4648 > brightness", the screen actually
come back to light. X window function properly.
However, if I go to suspend and resume. It is black screen
again.
If I use the Fn+Brightness to adjust the brightness. It seems
the ACPI brightness is set to lowest. One press of "Fn+Brightness up"
will give me about 10% of the brightness. It does not feel like
white is the new black.
Chris
On Fri, Mar 15, 2013 at 12:29 AM, Jani Nikula
<[email protected]> wrote:
> I've never used the acpi_osi= kernel parameter, but it looks like you
> could workaround this with acpi_osi="!Windows 2012". Please check that
> running the "bad" kernel.
I find out that I just can't set the acpi_osi="!Windows 2012" properly
in grub2.cfg.
Grub2 will second guess the quote and change it. So it end up Linux kernel will
see "acpi_osi=!Windows\x202012" or some thing like that.
However, I just find out that if I set acpi_osi=Linux the black screen
will go away.
That is one usable work around on the stock fedora kernel.
Chris