i915 INFO: trying to register non-static key.

Dudes,

has anyone already reported this (happens on Linus of today + tip/master):

Quoted 4 lines · Borislav Petkov

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?

Quoted 1 line · Rafael J. Wysocki

Does reverting efaa14c help?

Nope.

But see my other reply to Aaron.

Quoted 6 lines · Borislav Petkov

Quoted 1 line · Rafael J. Wysocki

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/

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

Quoted 18 lines · Aaron Lu

Quoted 6 lines · Borislav Petkov

Quoted 1 line · Rafael J. Wysocki

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/

Quoted 7 lines · Josep Lladonosa

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

Quoted 38 lines

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

Quoted 18 lines · Aaron Lu

Quoted 6 lines · Borislav Petkov

Quoted 1 line · Rafael J. Wysocki

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/

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\""

Quoted 6 lines · Josep Lladonosa

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:

Quoted 1 line

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

Quoted 7 lines · Felipe Contreras

Quoted 6 lines · Josep Lladonosa

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:

Quoted 6 lines

Quoted 1 line

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.

Quoted 8 lines · Rafael J. Wysocki

Quoted 7 lines · Felipe Contreras

Quoted 6 lines · Josep Lladonosa

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:

Quoted 8 lines

Quoted 6 lines

Quoted 1 line

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.

Quoted 2 lines

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?

Quoted 1 line

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

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.

Quoted 7 lines · Josep Lladonosa

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

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

Quoted 3 lines · Josep Lladonosa

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

Quoted 1 line

I have not checked this issue with acpi_osi="!Windows 2012".

Please do.

--
Felipe Contreras

Quoted 15 lines · Rafael J. Wysocki

Quoted 13 lines · Felipe Contreras

Quoted 7 lines · Josep Lladonosa

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

Quoted 1 line

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.

Quoted 2 lines

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?

Quoted 1 line

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.

Quoted 8 lines · Felipe Contreras

Quoted 7 lines · Rafael J. Wysocki

Quoted 4 lines · Felipe Contreras

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

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 2 lines

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

Quoted 1 line

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.

Quoted 6 lines

Quoted 1 line

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

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

Quoted 9 lines

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

Quoted 1 line

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?

Assume you have specified to use intel_backlight in xorg.conf

does booting with video.brightness_switch_enabled=0 help?

Quoted 4 lines · Borislav Petkov

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.

From the bug page:

Can you please run acpi_listen and then press the Fn-Fx key, see if the events are 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

Quoted 2 lines · Aaron Lu

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

Quoted 11 lines

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.

Quoted 6 lines

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.

Quoted 6 lines · Borislav Petkov

Quoted 2 lines · Aaron Lu

Can you please run acpi_listen and then press the Fn-Fx key, see if the events are correctly sent out?

Like this?

Quoted 11 lines

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

Quoted 26 lines

Quoted 11 lines

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.

Quoted 6 lines

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

Quoted 1 line

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.

Quoted 10 lines

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

Quoted 5 lines

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.

Quoted 2 lines

I guess I need to write me a dirty script for now ... :-)

:-)

Quoted 3 lines

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/

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.

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(-)

drivers/gpu/drm/i915/intel_panel.c +4 -1

index 67e2c1f..7c674f0 100644
@@ -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)

Signature · 14 lines

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

Quoted 36 lines

Quoted 10 lines

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

Quoted 5 lines

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.

Quoted 2 lines

I guess I need to write me a dirty script for now ... :-)

:-)

Quoted 3 lines

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/

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. --
_______________________________________________
dri-devel mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 4 lines · Borislav Petkov

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.

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

Quoted 11 lines · Johannes Stezenbach

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?