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).
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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 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 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.
Thanks.
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 <[email protected]>
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 <[email protected]>
---
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)
--
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
--
Salutacions...Josep
--
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 <[email protected]> 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 [email protected]
>> 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 <[email protected]> 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).
--
Felipe Contreras
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 <[email protected]> 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 <[email protected]> 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 [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>>
>
--
--
Salutacions...Josep
--
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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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! :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa <[email protected]> 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 <[email protected]> wrote:
> On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa <[email protected]> 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.
--
Felipe Contreras
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 <[email protected]> wrote:
> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki <[email protected]> wrote:
>> On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
>>> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa <[email protected]> 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.
>
> --
> Felipe Contreras
--
--
Salutacions...Josep
--
On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa <[email protected]> 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
"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 <[email protected]> wrote:
> On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa <[email protected]> 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
--
--
Salutacions...Josep
--
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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa <[email protected]> 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.
--
Felipe Contreras
On 2 August 2013 23:25, Felipe Contreras <[email protected]> wrote:
> On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa <[email protected]> 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
--
--
Salutacions...Josep
--
On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> >> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa <[email protected]> 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:
>
> 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.
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
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Fri, Aug 2, 2013 at 6:35 PM, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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:
>>
>> 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.
>
> 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.
--
Felipe Contreras
On Wed, Jul 31, 2013 at 6:22 PM, Borislav Petkov <[email protected]> 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 <[email protected]>
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
> [email protected]
> 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 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 <[email protected]>
> 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 <[email protected]>
> ---
> 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
--
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 <[email protected]> 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 <[email protected]>
> 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.
Yes it is.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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 <[email protected]>
Date: Tue Jul 30 16:27:57 2013 -0700
drm/i915: fix missed hunk after GT access breakage
ontop of 3.10-stable?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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 <[email protected]>
> Date: Tue Jul 30 16:27:57 2013 -0700
>
> drm/i915: fix missed hunk after GT access breakage
>
> ontop of 3.10-stable?
This is already in 3.10.5 as commit c9af307d38974264922d35c77bb71087d171f8f8.
Thanks,
Johannes
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