Dudes,
has anyone already reported this (happens on Linus of today + tip/master):
[ 0.608465] Linux agpgart interface v0.103 [ 0.608615] [drm] Initialized drm 1.1.0 20060810 [ 0.612050] [drm] Memory usable by graphics device = 2048M [ 0.612212] i915 0000:00:02.0: setting latency timer to 64 [ 0.674824] INFO: trying to register non-static key. [ 0.674904] the code is fine but needs lockdep annotation. [ 0.674983] turning off the locking correctness validator. [ 0.675063] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #1 [ 0.675146] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.675244] 0000000000000002 ffff880213c9d708 ffffffff815bc9d4 0000000000000000 [ 0.675539] ffffffff82608750 ffff880213c9d808 ffffffff810aa864 ffff88021d283fc0 [ 0.675828] ffffffff82654e60 0000000000000000 ffffffff00000000 ffff880200000000 [ 0.676116] Call Trace: [ 0.676194] [<ffffffff815bc9d4>] dump_stack+0x4f/0x84 [ 0.676281] [<ffffffff810aa864>] __lock_acquire+0x1774/0x1d80 [ 0.676366] [<ffffffff81010d6f>] ? save_stack_trace+0x2f/0x50 [ 0.676451] [<ffffffff810a6d7f>] ? save_trace+0x3f/0xc0 [ 0.676535] [<ffffffff810aa36d>] ? __lock_acquire+0x127d/0x1d80 [ 0.676621] [<ffffffff810ab445>] lock_acquire+0x85/0x130 [ 0.676705] [<ffffffff810682f5>] ? flush_work+0x5/0x280 [ 0.676787] [<ffffffff8106833c>] flush_work+0x4c/0x280 [ 0.676870] [<ffffffff810682f5>] ? flush_work+0x5/0x280 [ 0.676954] [<ffffffff810abd8e>] ? mark_held_locks+0xae/0x120 [ 0.677039] [<ffffffff8106a961>] ? __cancel_work_timer+0x71/0x110 [ 0.677125] [<ffffffff8106a96d>] __cancel_work_timer+0x7d/0x110 [ 0.677207] [<ffffffff8106aa13>] cancel_delayed_work_sync+0x13/0x20 [ 0.677292] [<ffffffff813c1e15>] intel_disable_gt_powersave+0x65/0x410 [ 0.677379] [<ffffffff813c3b39>] intel_gt_sanitize+0x49/0xb0 [ 0.677463] [<ffffffff81372541>] i915_driver_load+0x611/0xe90 [ 0.677550] [<ffffffff8135acce>] drm_get_pci_dev+0x17e/0x2a0 [ 0.677632] [<ffffffff8136ddec>] i915_pci_probe+0x2c/0x70 [ 0.677716] [<ffffffff812b27fb>] local_pci_probe+0x4b/0x80 [ 0.677798] [<ffffffff812b2a61>] pci_device_probe+0x111/0x120 [ 0.677885] [<ffffffff813dc06b>] driver_probe_device+0x7b/0x240 [ 0.677971] [<ffffffff813dc2db>] __driver_attach+0xab/0xb0 [ 0.678053] [<ffffffff813dc230>] ? driver_probe_device+0x240/0x240 [ 0.678138] [<ffffffff813da0ed>] bus_for_each_dev+0x5d/0xa0 [ 0.678222] [<ffffffff813dbb2e>] driver_attach+0x1e/0x20 [ 0.678304] [<ffffffff813db64f>] bus_add_driver+0x10f/0x270 [ 0.678390] [<ffffffff813dc9ba>] driver_register+0x7a/0x170 [ 0.678471] [<ffffffff812b1874>] __pci_register_driver+0x64/0x70 [ 0.678558] [<ffffffff81b2b68a>] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [ 0.678660] [<ffffffff8135af05>] drm_pci_init+0x115/0x130 [ 0.678740] [<ffffffff81b2b68a>] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [ 0.678843] [<ffffffff81b2b6f0>] i915_init+0x66/0x68 [ 0.678927] [<ffffffff8100031a>] do_one_initcall+0x11a/0x170 [ 0.679012] [<ffffffff8106f800>] ? parse_args+0xa0/0x360 [ 0.679096] [<ffffffff81af2f92>] kernel_init_freeable+0x108/0x197 [ 0.679182] [<ffffffff81af283f>] ? do_early_param+0x8c/0x8c [ 0.679266] [<ffffffff815b3350>] ? rest_init+0xd0/0xd0 [ 0.679349] [<ffffffff815b335e>] kernel_init+0xe/0xf0 [ 0.679427] [<ffffffff815cca5c>] ret_from_fork+0x7c/0xb0 [ 0.679509] [<ffffffff815b3350>] ? rest_init+0xd0/0xd0 [ 0.680182] i915 0000:00:02.0: irq 42 for MSI/MSI-X [ 0.680278] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
Dudes,
has anyone already reported this (happens on Linus of today + tip/master):
Oh, one more thing: I can't control the backlight anymore on this x230 with the Fn-Fx keys and this is most probably related to that recent backlight revert story. If there is a new approach I can test, please let me know.
Btw, it worked before on this machine with "acpi_backlight=vendor" on the cmdline.
Thanks a lot.
On Wednesday, July 31, 2013 06:36:23 PM Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
Dudes,
has anyone already reported this (happens on Linus of today + tip/master):
Oh, one more thing: I can't control the backlight anymore on this x230 with the Fn-Fx keys and this is most probably related to that recent backlight revert story. If there is a new approach I can test, please let me know.
Btw, it worked before on this machine with "acpi_backlight=vendor" on the cmdline.
Does reverting efaa14c help?
Rafael
On 08/01/2013 04:07 PM, Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Assume you have specified to use intel_backlight in xorg.conf, does booting with video.brightness_switch_enabled=0 help?
Thanks, Aaron
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
instead of previous
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
to be able to change brightness. In some kernel versions before, it worked, but with 15 levels, but in graphical system brightness bar was not moving.
Now I have, though, 8 possible values for brightness and brightness bar shows its correct position.
Josep
On 2 August 2013 08:00, Aaron Lu aaron.lu@intel.com wrote:
On 08/01/2013 04:07 PM, Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Assume you have specified to use intel_backlight in xorg.conf, does booting with video.brightness_switch_enabled=0 help?
Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
What if you remove the above from kernel command line, and add video.brightness_switch_enabled=0 to kernel command line, then set the following in xorg.conf: $ cat /etc/X11/xorg.conf Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Does everything work?
If not, please test if manually change brightness level through sysfs works: # cd /sys/calss/backlight/intel_backlight # echo xxx > brightness
And also test if hotkey event is sent out or not by running acpi_listen and then press the hotkey.
Thanks, Aaron
instead of previous
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
to be able to change brightness. In some kernel versions before, it worked, but with 15 levels, but in graphical system brightness bar was not moving.
Now I have, though, 8 possible values for brightness and brightness bar shows its correct position.
Josep
On 2 August 2013 08:00, Aaron Lu aaron.lu@intel.com wrote:
On 08/01/2013 04:07 PM, Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Assume you have specified to use intel_backlight in xorg.conf, does booting with video.brightness_switch_enabled=0 help?
Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hello,
Yes, it works! I get now 11 levels from all black to the brightest.
acpi_listen shows messages
Josep
On 2 August 2013 08:36, Aaron Lu aaron.lu@intel.com wrote:
On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
What if you remove the above from kernel command line, and add video.brightness_switch_enabled=0 to kernel command line, then set the following in xorg.conf: $ cat /etc/X11/xorg.conf Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Does everything work?
If not, please test if manually change brightness level through sysfs works: # cd /sys/calss/backlight/intel_backlight # echo xxx > brightness
And also test if hotkey event is sent out or not by running acpi_listen and then press the hotkey.
Thanks, Aaron
instead of previous
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
to be able to change brightness. In some kernel versions before, it worked, but with 15 levels, but in graphical system brightness bar was not moving.
Now I have, though, 8 possible values for brightness and brightness bar shows its correct position.
Josep
On 2 August 2013 08:00, Aaron Lu aaron.lu@intel.com wrote:
On 08/01/2013 04:07 PM, Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Assume you have specified to use intel_backlight in xorg.conf, does booting with video.brightness_switch_enabled=0 help?
Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa jlladono@gmail.com wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now).
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa jlladono@gmail.com wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now).
That would have made sense 6 months ago, but not today.
The reason is that you don't really know what's affected by that and I'm pretty sure it's not only backlight.
So no, we won't do that.
We *might* blacklist machines that shipped with Windows 7, but whose BIOSes call the Windows 8 OSI, because there's a good chance they weren't really tested with Windows 8.
Thanks, Rafael
On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki rjw@sisk.pl wrote:
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa jlladono@gmail.com wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now).
That would have made sense 6 months ago, but not today.
Today, like 6 months ago these machines remain broken, and it will be the same tomorrow, presumably on v3.11, and at least v3.12 as well.
The reason is that you don't really know what's affected by that and I'm pretty sure it's not only backlight.
I haven't heard a single comment that says acpi_osi="!Windows 2012" breaks other things. OTOH everybody is saying it fixes the backlight problem (if indeed it's the same problem).
Are you claiming that those users are wrong?
So no, we won't do that.
Yeah, because that would fix the backlight problems, not tomorrow, or several months from now, *today*. Geez, who would want that?
Here is the patch to fix the problem, *today*.
https://bugzilla.kernel.org/show_bug.cgi?id=60682
This is what we should do:
1) Improve that blacklist list 2) Fix the Intel driver issues 3) Enable your patch that uses the Intel driver instead 4) Remove that patch
Anything else is not be good for the users.
Hi,
With this setup, something has happened: in xorg, when screen goes to screensaver and after, enters into Standby mode, when I press a key, it keeps black and, to recover screen, I have to adjust brightness manually (by increasing), as if it didn't remember previous value to standby mode.
This was something that before didn't happen.
Josep
On 2 August 2013 20:58, Felipe Contreras felipe.contreras@gmail.com wrote:
On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki rjw@sisk.pl wrote:
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa jlladono@gmail.com wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now).
That would have made sense 6 months ago, but not today.
Today, like 6 months ago these machines remain broken, and it will be the same tomorrow, presumably on v3.11, and at least v3.12 as well.
The reason is that you don't really know what's affected by that and I'm pretty sure it's not only backlight.
I haven't heard a single comment that says acpi_osi="!Windows 2012" breaks other things. OTOH everybody is saying it fixes the backlight problem (if indeed it's the same problem).
Are you claiming that those users are wrong?
So no, we won't do that.
Yeah, because that would fix the backlight problems, not tomorrow, or several months from now, *today*. Geez, who would want that?
Here is the patch to fix the problem, *today*.
https://bugzilla.kernel.org/show_bug.cgi?id=60682
This is what we should do:
- Improve that blacklist list
- Fix the Intel driver issues
- Enable your patch that uses the Intel driver instead
- Remove that patch
Anything else is not be good for the users.
-- Felipe Contreras
On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa jlladono@gmail.com wrote:
With this setup, something has happened: in xorg, when screen goes to screensaver and after, enters into Standby mode, when I press a key, it keeps black and, to recover screen, I have to adjust brightness manually (by increasing), as if it didn't remember previous value to standby mode.
This was something that before didn't happen.
You mean with acpi_osi="!Windows 2012"? And when you say "before", what do you mean?
"Before" means with previous kernels that worked with
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
I have not checked this issue with acpi_osi="!Windows 2012".
Josep
On 2 August 2013 22:08, Felipe Contreras felipe.contreras@gmail.com wrote:
On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa jlladono@gmail.com wrote:
With this setup, something has happened: in xorg, when screen goes to screensaver and after, enters into Standby mode, when I press a key, it keeps black and, to recover screen, I have to adjust brightness manually (by increasing), as if it didn't remember previous value to standby mode.
This was something that before didn't happen.
You mean with acpi_osi="!Windows 2012"? And when you say "before", what do you mean?
-- Felipe Contreras
On Fri, Aug 02, 2013 at 10:11:27PM +0200, Josep Lladonosa wrote:
"Before" means with previous kernels that worked with
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
I have not checked this issue with acpi_osi="!Windows 2012".
Hey Josep,
would you please not top-post when you reply?
Thanks.
On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa jlladono@gmail.com wrote:
"Before" means with previous kernels that worked with
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
That's probably a different issue. You would need to bisect the problem.
I have not checked this issue with acpi_osi="!Windows 2012".
Please do.
On 2 August 2013 23:25, Felipe Contreras felipe.contreras@gmail.com wrote:
On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa jlladono@gmail.com wrote:
"Before" means with previous kernels that worked with
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
That's probably a different issue. You would need to bisect the problem.
I have not checked this issue with acpi_osi="!Windows 2012".
Please do.
Hello, checking with acpi_osi="!Windows 2012" in the cmdline for kernel 3.11.0-rc3 (and without the section you gave for the xorg.conf) i get:
- brightness can be set among 16 levels. - brightness recovers fine after a standby. - brightness can be managed before entering xorg (during lightdm screen, in my case. With the configuration of xorg.conf and video.brightness_switch_enabled=0 it is not possible, only until xorg has started).
Josep
-- Felipe Contreras
On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki rjw@sisk.pl wrote:
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa jlladono@gmail.com wrote:
Hello,
I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to change to this parameter to the kernel boot:
GRUB_CMDLINE_LINUX="acpi_osi="!Windows 2012""
I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now).
That would have made sense 6 months ago, but not today.
Today, like 6 months ago these machines remain broken, and it will be the same tomorrow, presumably on v3.11, and at least v3.12 as well.
Can you possibly look at things from a bit broader perspective than just the broken backlight?
[I'm talking about "simply removing the OSI completely for all machines" if that's not clear.]
The problem is that for the last 6 months the kernel has responded to OSI(Windows 2012) with a "yes" and now, after that time, you want it to make a U turn and start saying "no" even though that may cause problems to happen on other people's machines. That's simply irresponsible.
The reason is that you don't really know what's affected by that and I'm pretty sure it's not only backlight.
I haven't heard a single comment that says acpi_osi="!Windows 2012" breaks other things. OTOH everybody is saying it fixes the backlight problem (if indeed it's the same problem).
Are you claiming that those users are wrong?
No, they are saying what they see and they are the people having the backlight problem in the first place. You have no data from people for whom things work now.
So no, we won't do that.
Yeah, because that would fix the backlight problems, not tomorrow, or several months from now, *today*. Geez, who would want that?
Here is the patch to fix the problem, *today*.
It doesn't "fix" anything. It just creates a blacklist of systems where acpi_osi="!Windows 2012" happens to help with the backlight control problem.
You don't even know why exactly it happens to work on those machines in the first place and you don't know what is affected by that apart from backlight (you can't be sure that nothing is affected in particular).
https://bugzilla.kernel.org/show_bug.cgi?id=60682
This is what we should do:
- Improve that blacklist list
- Fix the Intel driver issues
- Enable your patch that uses the Intel driver instead
- Remove that patch
Anything else is not be good for the users.
Actually, the users can easily put the acpi_osi="!Windows 2012" into the kernel command line (which is what they have been doing already for some time I suppose). However, if we add the blacklist to the kernel, that will mean we kind of give up fixing the backlight control for them (because they won't have any incentive to test anything else then).
That said this is a controverisal matter and we evidently don't agree with each other. I have my reasons, you have your arguments and it doesn't look like any of us is likely to change his mind, so why don't we do what's normally done in such cases: Why don't we ask others?
Matthew, Aaron, Rui, what do you think about this? Should we create an acpi_osi="!Windows 2012" blacklist of systems where this workaround is known to help with backlight control issues? Is this a good idea in your opinion?
Rafael
On Fri, Aug 2, 2013 at 6:35 PM, Rafael J. Wysocki rjw@sisk.pl wrote:
On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki rjw@sisk.pl wrote:
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now).
That would have made sense 6 months ago, but not today.
Today, like 6 months ago these machines remain broken, and it will be the same tomorrow, presumably on v3.11, and at least v3.12 as well.
Can you possibly look at things from a bit broader perspective than just the broken backlight?
[I'm talking about "simply removing the OSI completely for all machines" if that's not clear.]
The problem is that for the last 6 months the kernel has responded to OSI(Windows 2012) with a "yes" and now, after that time, you want it to make a U turn and start saying "no" even though that may cause problems to happen on other people's machines. That's simply irresponsible.
The difference is we *know* *for sure* responding "Windows 2012" with a yes causes problems, on the other hand you *think* responding with a no, *might* cause problems.
The only reason it would make sense to remain in the current situation is that if *knew* that switching to no would cause problems, but to my knowledge such problems are not real, merely theoretical.
We have had proven brokedness for four releases (almost five now), if you disable it for v3.12 and it turns out it causes even more problems, then you enable it back again for v3.13, or even v3.12.1. The only way to know for certain is to go ahead and try it.
But we know it's going to be all right, because v3.6 was all right.
The reason is that you don't really know what's affected by that and I'm pretty sure it's not only backlight.
I haven't heard a single comment that says acpi_osi="!Windows 2012" breaks other things. OTOH everybody is saying it fixes the backlight problem (if indeed it's the same problem).
Are you claiming that those users are wrong?
No, they are saying what they see and they are the people having the backlight problem in the first place. You have no data from people for whom things work now.
The data comes from v3.6, who complained? Anyway, it's easy to find out; just disable it for *one release*.
So no, we won't do that.
Yeah, because that would fix the backlight problems, not tomorrow, or several months from now, *today*. Geez, who would want that?
Here is the patch to fix the problem, *today*.
It doesn't "fix" anything. It just creates a blacklist of systems where acpi_osi="!Windows 2012" happens to help with the backlight control problem.
From the user's point of view; right now it doesn't work, after the
patch it does. That is a fix.
You don't even know why exactly it happens to work on those machines in the first place and you don't know what is affected by that apart from backlight (you can't be sure that nothing is affected in particular).
I have a fairly good idea of the *real* problems involved with the backlight.
The other problems you speak of are hypothetical, and yes, I don't know if there will be more problems, but neither do you. This is an argument from ignorance fallacy, and it's easy to solve; let's try it for one release and see how it goes. Then we would *know*.
https://bugzilla.kernel.org/show_bug.cgi?id=60682
This is what we should do:
- Improve that blacklist list
- Fix the Intel driver issues
- Enable your patch that uses the Intel driver instead
- Remove that patch
Anything else is not be good for the users.
Actually, the users can easily put the acpi_osi="!Windows 2012" into the kernel command line (which is what they have been doing already for some time I suppose).
The kernel should just work out-of-the-box. You can't expect every user out there to put all sorts of quirks into their boot command, that's why we have quirks in the kernel in the first place.
However, if we add the blacklist to the kernel, that will mean we kind of give up fixing the backlight control for them (because they won't have any incentive to test anything else then).
No, it doesn't mean that.
You should not break systems willingly and knowingly only to create incentives to the developers.
When things are ready, you enable the fix again, if they break, you disable it again. At no point in time does it make sense to retain code that we know breaks user-experience.
That said this is a controverisal matter and we evidently don't agree with each other. I have my reasons, you have your arguments and it doesn't look like any of us is likely to change his mind, so why don't we do what's normally done in such cases: Why don't we ask others?
Matthew, Aaron, Rui, what do you think about this? Should we create an acpi_osi="!Windows 2012" blacklist of systems where this workaround is known to help with backlight control issues? Is this a good idea in your opinion?
Mind that the suggestion is to do this *temporarily*, until there's more certainty that the proper fix works.
On Fri, Aug 02, 2013 at 02:00:42PM +0800, Aaron Lu wrote:
Assume you have specified to use intel_backlight in xorg.conf
Right, I have:
Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
in there currently.
does booting with video.brightness_switch_enabled=0 help?
Nope.
Kernel command line is like this:
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-rc3+ root=/dev/sdb2 ro root=/dev/sdb2 ignore_loglevel log_buf_len=10M resume=/dev/sdb1 acpi_backlight=vendor video.brightness_switch_enabled=0 i915.i915_enable_rc6=4 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.powersave=1
and acpi_backlight=vendor doesn't make any difference. It still works over sysfs though.
Thanks.
On 08/01/2013 12:36 AM, Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
Dudes,
has anyone already reported this (happens on Linus of today + tip/master):
Oh, one more thing: I can't control the backlight anymore on this x230 with the Fn-Fx keys and this is most probably related to that recent backlight revert story. If there is a new approach I can test, please let me know.
Can you please run acpi_listen and then press the Fn-Fx key, see if the events are correctly sent out?
Btw, it worked before on this machine with "acpi_backlight=vendor" on the cmdline.
From the bug page:
https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 I got the impression that both the acpi_video interface and the vendor interface thinkpad_screen are broken. So adding this cmdline here works suggests that either thinkpad_screen works or thinkpad vendor driver doesn't get loaded or doesn't create that interface for some reason.
Alternatively, if the intel_backlight interface works(highly possible), you can use xorg.conf to specify the that backlight interface for X.
Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Thanks, Aaron
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
Can you please run acpi_listen and then press the Fn-Fx key, see if the events are correctly sent out?
Like this?
# acpi_listen video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 ^C
From the bug page: https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 I got the impression that both the acpi_video interface and the vendor interface thinkpad_screen are broken. So adding this cmdline here works suggests that either thinkpad_screen works or thinkpad vendor driver doesn't get loaded or doesn't create that interface for some reason.
Alternatively, if the intel_backlight interface works(highly possible), you can use xorg.conf to specify the that backlight interface for X.
Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Yeah, that didn't work *but* manually writing to both:
/sys/class/backlight/acpi_video0/brightness
and
/sys/class/backlight/intel_backlight/brightness
works.
The ranges are different, though:
intel_backlight/actual_brightness:1000 intel_backlight/bl_power:0 intel_backlight/brightness:1000 intel_backlight/max_brightness:4437 intel_backlight/type:raw
acpi_video0/actual_brightness:41 acpi_video0/bl_power:0 acpi_video0/brightness:41 acpi_video0/max_brightness:100 acpi_video0/type:firmware
I guess I need to write me a dirty script for now ... :-)
Thanks guys.
On 08/01/2013 04:12 PM, Borislav Petkov wrote:
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
Can you please run acpi_listen and then press the Fn-Fx key, see if the events are correctly sent out?
Like this?
# acpi_listen video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 ^C
Yes, so the event is correctly sent out.
From the bug page: https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 I got the impression that both the acpi_video interface and the vendor interface thinkpad_screen are broken. So adding this cmdline here works suggests that either thinkpad_screen works or thinkpad vendor driver doesn't get loaded or doesn't create that interface for some reason.
Alternatively, if the intel_backlight interface works(highly possible), you can use xorg.conf to specify the that backlight interface for X.
Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Yeah, that didn't work *but* manually writing to both:
/sys/class/backlight/acpi_video0/brightness
and
/sys/class/backlight/intel_backlight/brightness
works.
Err...we have the event sent out on hotkey press and the interface also works, but still, using hotkey to adjust brightness level is broken...
I just found an old acer laptop that has similar issue(or even worse: on X starts, an almost black screen is shown and hotkey adjust doesn't work), I'll look into this.
The ranges are different, though:
intel_backlight/actual_brightness:1000 intel_backlight/bl_power:0 intel_backlight/brightness:1000 intel_backlight/max_brightness:4437 intel_backlight/type:raw
acpi_video0/actual_brightness:41 acpi_video0/bl_power:0 acpi_video0/brightness:41 acpi_video0/max_brightness:100 acpi_video0/type:firmware
Yes, different interface has different brightness ranges and a value in one range may turn out to be the same actual brightness level of another value in another range.
I guess I need to write me a dirty script for now ... :-)
:-)
Thanks guys.
Thanks, Aaron
On 08/01/2013 05:07 PM, Aaron Lu wrote:
On 08/01/2013 04:12 PM, Borislav Petkov wrote:
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
Can you please run acpi_listen and then press the Fn-Fx key, see if the events are correctly sent out?
Like this?
# acpi_listen video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 video/brightnessup BRTUP 00000086 00000000 video/brightnessdown BRTDN 00000087 00000000 ^C
Yes, so the event is correctly sent out.
From the bug page: https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 I got the impression that both the acpi_video interface and the vendor interface thinkpad_screen are broken. So adding this cmdline here works suggests that either thinkpad_screen works or thinkpad vendor driver doesn't get loaded or doesn't create that interface for some reason.
Alternatively, if the intel_backlight interface works(highly possible), you can use xorg.conf to specify the that backlight interface for X.
Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection
Yeah, that didn't work *but* manually writing to both:
/sys/class/backlight/acpi_video0/brightness
and
/sys/class/backlight/intel_backlight/brightness
works.
Err...we have the event sent out on hotkey press and the interface also works, but still, using hotkey to adjust brightness level is broken...
I just found an old acer laptop that has similar issue(or even worse: on X starts, an almost black screen is shown and hotkey adjust doesn't work), I'll look into this.
Hi Jani & Daniel,
It turned out there is an integer overflow problem, and the below patch fixed this problem on Acer Aspire 4732Z and thinkpad R61i.
From: Aaron Lu aaron.lu@intel.com Subject: [PATCH] drm/i915: avoid brightness overflow when doing scale
Some card's max brightness level is pretty large, e.g. on Acer Aspire 4732Z, the max level is 989910. If user space set a large enough level then the current scale done in intel_panel_set_backlight will cause an integer overflow and the scaled level will be mistakenly small, leaving user with an almost black screen. This patch fixes this problem.
Signed-off-by: Aaron Lu aaron.lu@intel.com --- Since the only external user of intel_panel_set_backlight is operation region code where the max will be a constant of 255, this patch fixes the problem by comparing freq and max and then do things accordingly instead of converting to 64 bits.
drivers/gpu/drm/i915/intel_panel.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 67e2c1f..7c674f0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -498,7 +498,10 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 level, u32 max) }
/* scale to hardware */ - level = level * freq / max; + if (freq < max) + level = level * freq / max; + else + level = freq / max * level;
dev_priv->backlight.level = level; if (dev_priv->backlight.device)
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
Since the sysfs interface works on your system, I think your problem should be different. Can you please file a bug for this? I can provide you with a debug patch and then see what happened. Please attach acpidump when filing the bug.
https://bugzilla.kernel.org, ACPI/Power-Video.
Done: https://bugzilla.kernel.org/show_bug.cgi?id=60680
I did acpidump by hand but it should be ok.
Thanks for looking into this Aaron! :)
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
Hi Jani & Daniel,
It turned out there is an integer overflow problem, and the below patch fixed this problem on Acer Aspire 4732Z and thinkpad R61i.
From: Aaron Lu aaron.lu@intel.com Subject: [PATCH] drm/i915: avoid brightness overflow when doing scale
Some card's max brightness level is pretty large, e.g. on Acer Aspire 4732Z, the max level is 989910. If user space set a large enough level then the current scale done in intel_panel_set_backlight will cause an integer overflow and the scaled level will be mistakenly small, leaving user with an almost black screen. This patch fixes this problem.
Signed-off-by: Aaron Lu aaron.lu@intel.com
Since the only external user of intel_panel_set_backlight is operation region code where the max will be a constant of 255, this patch fixes the problem by comparing freq and max and then do things accordingly instead of converting to 64 bits.
Yeah, makes sense. Picked up for -fixes, thanks for the patch. -Daniel
drivers/gpu/drm/i915/intel_panel.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 67e2c1f..7c674f0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -498,7 +498,10 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 level, u32 max) }
/* scale to hardware */
- level = level * freq / max;
if (freq < max)
level = level * freq / max;else
level = freq / max * level;dev_priv->backlight.level = level; if (dev_priv->backlight.device)
-- 1.8.3.1
Hi Boris,
Since the sysfs interface works on your system, I think your problem should be different. Can you please file a bug for this? I can provide you with a debug patch and then see what happened. Please attach acpidump when filing the bug.
https://bugzilla.kernel.org, ACPI/Power-Video.
Thanks, Aaron
The ranges are different, though:
intel_backlight/actual_brightness:1000 intel_backlight/bl_power:0 intel_backlight/brightness:1000 intel_backlight/max_brightness:4437 intel_backlight/type:raw
acpi_video0/actual_brightness:41 acpi_video0/bl_power:0 acpi_video0/brightness:41 acpi_video0/max_brightness:100 acpi_video0/type:firmware
Yes, different interface has different brightness ranges and a value in one range may turn out to be the same actual brightness level of another value in another range.
I guess I need to write me a dirty script for now ... :-)
:-)
Thanks guys.
Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Wed, Jul 31, 2013 at 6:22 PM, Borislav Petkov bp@alien8.de wrote:
Dudes,
has anyone already reported this (happens on Linus of today + tip/master):
I think this should be fixed with
commit e1b4d3036c07ff137955fb1c0197ab62534f46ec Author: Ben Widawsky ben@bwidawsk.net Date: Tue Jul 30 16:27:57 2013 -0700
drm/i915: fix missed hunk after GT access breakage
which is now in upstream git and -rc4. -Daniel
[ 0.608465] Linux agpgart interface v0.103 [ 0.608615] [drm] Initialized drm 1.1.0 20060810 [ 0.612050] [drm] Memory usable by graphics device = 2048M [ 0.612212] i915 0000:00:02.0: setting latency timer to 64 [ 0.674824] INFO: trying to register non-static key. [ 0.674904] the code is fine but needs lockdep annotation. [ 0.674983] turning off the locking correctness validator. [ 0.675063] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #1 [ 0.675146] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.675244] 0000000000000002 ffff880213c9d708 ffffffff815bc9d4 0000000000000000 [ 0.675539] ffffffff82608750 ffff880213c9d808 ffffffff810aa864 ffff88021d283fc0 [ 0.675828] ffffffff82654e60 0000000000000000 ffffffff00000000 ffff880200000000 [ 0.676116] Call Trace: [ 0.676194] [<ffffffff815bc9d4>] dump_stack+0x4f/0x84 [ 0.676281] [<ffffffff810aa864>] __lock_acquire+0x1774/0x1d80 [ 0.676366] [<ffffffff81010d6f>] ? save_stack_trace+0x2f/0x50 [ 0.676451] [<ffffffff810a6d7f>] ? save_trace+0x3f/0xc0 [ 0.676535] [<ffffffff810aa36d>] ? __lock_acquire+0x127d/0x1d80 [ 0.676621] [<ffffffff810ab445>] lock_acquire+0x85/0x130 [ 0.676705] [<ffffffff810682f5>] ? flush_work+0x5/0x280 [ 0.676787] [<ffffffff8106833c>] flush_work+0x4c/0x280 [ 0.676870] [<ffffffff810682f5>] ? flush_work+0x5/0x280 [ 0.676954] [<ffffffff810abd8e>] ? mark_held_locks+0xae/0x120 [ 0.677039] [<ffffffff8106a961>] ? __cancel_work_timer+0x71/0x110 [ 0.677125] [<ffffffff8106a96d>] __cancel_work_timer+0x7d/0x110 [ 0.677207] [<ffffffff8106aa13>] cancel_delayed_work_sync+0x13/0x20 [ 0.677292] [<ffffffff813c1e15>] intel_disable_gt_powersave+0x65/0x410 [ 0.677379] [<ffffffff813c3b39>] intel_gt_sanitize+0x49/0xb0 [ 0.677463] [<ffffffff81372541>] i915_driver_load+0x611/0xe90 [ 0.677550] [<ffffffff8135acce>] drm_get_pci_dev+0x17e/0x2a0 [ 0.677632] [<ffffffff8136ddec>] i915_pci_probe+0x2c/0x70 [ 0.677716] [<ffffffff812b27fb>] local_pci_probe+0x4b/0x80 [ 0.677798] [<ffffffff812b2a61>] pci_device_probe+0x111/0x120 [ 0.677885] [<ffffffff813dc06b>] driver_probe_device+0x7b/0x240 [ 0.677971] [<ffffffff813dc2db>] __driver_attach+0xab/0xb0 [ 0.678053] [<ffffffff813dc230>] ? driver_probe_device+0x240/0x240 [ 0.678138] [<ffffffff813da0ed>] bus_for_each_dev+0x5d/0xa0 [ 0.678222] [<ffffffff813dbb2e>] driver_attach+0x1e/0x20 [ 0.678304] [<ffffffff813db64f>] bus_add_driver+0x10f/0x270 [ 0.678390] [<ffffffff813dc9ba>] driver_register+0x7a/0x170 [ 0.678471] [<ffffffff812b1874>] __pci_register_driver+0x64/0x70 [ 0.678558] [<ffffffff81b2b68a>] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [ 0.678660] [<ffffffff8135af05>] drm_pci_init+0x115/0x130 [ 0.678740] [<ffffffff81b2b68a>] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [ 0.678843] [<ffffffff81b2b6f0>] i915_init+0x66/0x68 [ 0.678927] [<ffffffff8100031a>] do_one_initcall+0x11a/0x170 [ 0.679012] [<ffffffff8106f800>] ? parse_args+0xa0/0x360 [ 0.679096] [<ffffffff81af2f92>] kernel_init_freeable+0x108/0x197 [ 0.679182] [<ffffffff81af283f>] ? do_early_param+0x8c/0x8c [ 0.679266] [<ffffffff815b3350>] ? rest_init+0xd0/0xd0 [ 0.679349] [<ffffffff815b335e>] kernel_init+0xe/0xf0 [ 0.679427] [<ffffffff815cca5c>] ret_from_fork+0x7c/0xb0 [ 0.679509] [<ffffffff815b3350>] ? rest_init+0xd0/0xd0 [ 0.680182] i915 0000:00:02.0: irq 42 for MSI/MSI-X [ 0.680278] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine.
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Aug 05, 2013 at 01:06:35AM +0200, Daniel Vetter wrote:
On Wed, Jul 31, 2013 at 6:22 PM, Borislav Petkov bp@alien8.de wrote:
Dudes,
has anyone already reported this (happens on Linus of today + tip/master):
I think this should be fixed with
commit e1b4d3036c07ff137955fb1c0197ab62534f46ec Author: Ben Widawsky ben@bwidawsk.net Date: Tue Jul 30 16:27:57 2013 -0700
drm/i915: fix missed hunk after GT access breakagewhich is now in upstream git and -rc4.
Yes it is.
Thanks.
Hi,
wrt to $Subject, I get this with 3.10.5:
[ 4.342638] i915 0000:00:02.0: setting latency timer to 64 [ 4.409045] INFO: trying to register non-static key. [ 4.409164] the code is fine but needs lockdep annotation. [ 4.409278] turning off the locking correctness validator. [ 4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1 [ 4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 09/11/2012 [ 4.409690] 0000000000000001 ffff8802121559e0 ffffffff816b265c ffff880212155a50 [ 4.410050] ffffffff8109ba03 ffffffff822cd1c0 0000000000000000 0000000100000006 [ 4.410408] 0000000000000000 0000000000000000 0000000000000000 ffff8802121587a8 [ 4.410764] Call Trace: [ 4.410880] [<ffffffff816b265c>] dump_stack+0x19/0x1b [ 4.411000] [<ffffffff8109ba03>] __lock_acquire.isra.23+0x7f7/0xb9c [ 4.411120] [<ffffffff8109be68>] lock_acquire+0xc0/0x142 [ 4.411240] [<ffffffff813999f4>] ? i915_write32+0x99/0x13a [ 4.411360] [<ffffffff816b8c7f>] _raw_spin_lock_irqsave+0x57/0x8e [ 4.411481] [<ffffffff813999f4>] ? i915_write32+0x99/0x13a [ 4.411599] [<ffffffff813999f4>] i915_write32+0x99/0x13a [ 4.411718] [<ffffffff813d9aa8>] intel_disable_gt_powersave+0x264/0x2e5 [ 4.411839] [<ffffffff813db00c>] intel_gt_sanitize+0x91/0x93 [ 4.411956] [<ffffffff8139ca1d>] i915_driver_load+0x6e7/0xca5 [ 4.412080] [<ffffffff81387e8d>] ? drm_get_minor+0x1d4/0x22e [ 4.412199] [<ffffffff81389b1f>] drm_get_pci_dev+0x169/0x269 [ 4.412319] [<ffffffff816b8eac>] ? _raw_spin_unlock_irqrestore+0x5b/0x79 [ 4.412440] [<ffffffff81398f00>] i915_pci_probe+0x66/0x6f [ 4.412557] [<ffffffff812d4597>] pci_device_probe+0x6e/0xb2 [ 4.412679] [<ffffffff813ef7ac>] driver_probe_device+0x11a/0x2e2 [ 4.412799] [<ffffffff813efa12>] __driver_attach+0x61/0x83 [ 4.412918] [<ffffffff813ef9b1>] ? __device_attach+0x3d/0x3d [ 4.413039] [<ffffffff813edb2f>] bus_for_each_dev+0x7d/0x87 [ 4.413158] [<ffffffff813ef1e5>] driver_attach+0x1e/0x20 [ 4.413278] [<ffffffff813eedb5>] bus_add_driver+0x128/0x233 [ 4.413397] [<ffffffff813eff30>] driver_register+0x8c/0xfd [ 4.413515] [<ffffffff812d4420>] __pci_register_driver+0x5d/0x60 [ 4.413637] [<ffffffff81f16c96>] ? ftrace_define_fields_drm_vblank_event_delivered+0x9a/0x9a [ 4.413818] [<ffffffff81389ca5>] drm_pci_init+0x86/0xea [ 4.413936] [<ffffffff81f16c96>] ? ftrace_define_fields_drm_vblank_event_delivered+0x9a/0x9a [ 4.414117] [<ffffffff81f16cfc>] i915_init+0x66/0x68 [ 4.414235] [<ffffffff8100028d>] do_one_initcall+0xa0/0x13f [ 4.414355] [<ffffffff81edeeae>] kernel_init_freeable+0x115/0x196 [ 4.414475] [<ffffffff81ede738>] ? do_early_param+0x88/0x88 [ 4.414594] [<ffffffff8169e69e>] ? rest_init+0xc2/0xc2 [ 4.414711] [<ffffffff8169e6ac>] kernel_init+0xe/0xd6 [ 4.414828] [<ffffffff816ba5ac>] ret_from_fork+0x7c/0xb0 [ 4.414946] [<ffffffff8169e69e>] ? rest_init+0xc2/0xc2 [ 4.422529] i915 0000:00:02.0: irq 40 for MSI/MSI-X
If you have a fix for it please send it to stable.
Thanks, Johannes
On Mon, Aug 05, 2013 at 03:23:53PM +0200, Johannes Stezenbach wrote:
wrt to $Subject, I get this with 3.10.5:
[ 4.342638] i915 0000:00:02.0: setting latency timer to 64 [ 4.409045] INFO: trying to register non-static key. [ 4.409164] the code is fine but needs lockdep annotation. [ 4.409278] turning off the locking correctness validator. [ 4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1 [ 4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 09/11/2012 [ 4.409690] 0000000000000001 ffff8802121559e0 ffffffff816b265c ffff880212155a50 [ 4.410050] ffffffff8109ba03 ffffffff822cd1c0 0000000000000000 0000000100000006 [ 4.410408] 0000000000000000 0000000000000000 0000000000000000 ffff8802121587a8
Looks similar to what I'm seeing. Can you cherry-pick
commit e1b4d3036c07ff137955fb1c0197ab62534f46ec Author: Ben Widawsky ben@bwidawsk.net Date: Tue Jul 30 16:27:57 2013 -0700
drm/i915: fix missed hunk after GT access breakage
ontop of 3.10-stable?
On Mon, Aug 05, 2013 at 03:27:29PM +0200, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 03:23:53PM +0200, Johannes Stezenbach wrote:
wrt to $Subject, I get this with 3.10.5:
[ 4.342638] i915 0000:00:02.0: setting latency timer to 64 [ 4.409045] INFO: trying to register non-static key. [ 4.409164] the code is fine but needs lockdep annotation. [ 4.409278] turning off the locking correctness validator. [ 4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1 [ 4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 09/11/2012 [ 4.409690] 0000000000000001 ffff8802121559e0 ffffffff816b265c ffff880212155a50 [ 4.410050] ffffffff8109ba03 ffffffff822cd1c0 0000000000000000 0000000100000006 [ 4.410408] 0000000000000000 0000000000000000 0000000000000000 ffff8802121587a8
Looks similar to what I'm seeing. Can you cherry-pick
commit e1b4d3036c07ff137955fb1c0197ab62534f46ec Author: Ben Widawsky ben@bwidawsk.net Date: Tue Jul 30 16:27:57 2013 -0700
drm/i915: fix missed hunk after GT access breakageontop of 3.10-stable?
This is already in 3.10.5 as commit c9af307d38974264922d35c77bb71087d171f8f8.
Thanks, Johannes
dri-devel@lists.freedesktop.org
-
Aaron Lu -
Borislav Petkov -
Daniel Vetter -
Felipe Contreras -
Johannes Stezenbach -
Josep Lladonosa -
Rafael J. Wysocki