[PATCH] i915, drm: Fix build dependency on VGA_ARB
I get: LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `intel_modeset_init': (.text+0xa993f): undefined reference to `vga_get' drivers/built-in.o: In function `intel_modeset_init': (.text+0xa9963): undefined reference to `vga_put' make: *** [.tmp_vmlinux1] Error 1 since CONFIG_AGB_ARB is not being selected. Make I915 driver select it as the numerous other things it selects. Signed-off-by: Borislav Petkov b...@alien8.de --- This is on latest Linus git (v2.6.36-rc2-237-gd4348c6) after doing `make oldconfig' on an Acer Aspire One netbook. drivers/gpu/drm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 4cab0c6..43590ab 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -97,6 +97,7 @@ config DRM_I830 config DRM_I915 tristate i915 driver depends on AGP_INTEL + select VGA_ARB select SHMEM select DRM_KMS_HELPER select FB_CFB_FILLRECT -- 1.7.1 -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915, drm: Fix build dependency on VGA_ARB
From: Ben Hutchings b...@decadent.org.uk Date: Thu, Aug 26, 2010 at 04:59:21PM +0100 linux/vgaarb.h should define dummy inline functions if CONFIG_VGA_ARB is not defined. It already does this for vga_client_register() but should cover the other functions as well. But what if you still need the VGA arbitration functionality? I don't think I'll be running more than one X server on that netbook but still... -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.36-rc3
From: Jean-Denis Girard jd.gir...@sysnux.pf Date: Sun, Aug 29, 2010 at 10:40:47PM + CC drivers/gpu/drm/i915/intel_overlay.o drivers/gpu/drm/i915/intel_overlay.c: In function ‘intel_overlay_print_error_state’: drivers/gpu/drm/i915/intel_overlay.c:1467: erreur: implicit declaration of function ‘seq_printf’ make[4]: *** [drivers/gpu/drm/i915/intel_overlay.o] Erreur 1 make[3]: *** [drivers/gpu/drm/i915] Erreur 2 make[2]: *** [drivers/gpu/drm] Erreur 2 make[1]: *** [drivers/gpu] Erreur 2 make: *** [drivers] Erreur 2 Command exited with non-zero status 2 This should fix it: --- From: Borislav Petkov b...@alien8.de Add a missing include fixing driver build. Signed-off-by: Borislav Petkov b...@alien8.de --- drivers/gpu/drm/i915/intel_overlay.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index 4f00390..4eaf08e 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -25,6 +25,8 @@ * * Derived from Xorg ddx, xf86-video-intel, src/i830_video.c */ +#include linux/seq_file.h + #include drmP.h #include drm.h #include i915_drm.h -- 1.7.1 -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Sat, Aug 27, 2011 at 06:50:37PM -0400, Pavel Ivanov wrote: 2011/8/27 Michel Dänzer mic...@daenzer.net: I observe very strange behavior dependent on value of CONFIG_DRM_RADEON parameter. When it's set to m everything works very good, no problem. When I set it to y I see kernel hang during boot. Or I should better say it almost hangs because during last boot attempt I accidentally waited a little bit longer and saw that after more than a minute waiting system continued to boot. Dmesg after hang shows these messages: [ 8.542639] [drm] Loading CEDAR Microcode [ 69.161605] r600_cp: Failed to load firmware radeon/CEDAR_pfp.bin [ 69.161670] [drm:evergreen_startup] *ERROR* Failed to load firmware! While during normal boot [ 9.898870] [drm] Loading CEDAR Microcode [ 9.908425] radeon :05:00.0: WB enabled With CONFIG_DRM_RADEON=y, the microcode is needed before it can be loaded from userspace, so it needs to be built into the kernel as well. How should I do that? I've tried to set all ms to y in .config and still saw this issue. Should I set some special parameter? You need to add radeon/CEDAR_pfp.bin to CONFIG_EXTRA_FIRMWARE when you configure your kernel and enable CONFIG_FIRMWARE_IN_KERNEL. The radeon/CEDAR_pfp.bin file (+ leading directory, mind you) should most probably be located in /lib/firmware or to whatever you have set CONFIG_EXTRA_FIRMWARE_DIR so that Kbuild can find it (if not, you'll get a warning at the end of the kernel build). This way, it works for both radeon being =m and =y. HTH. -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Sun, Aug 28, 2011 at 05:47:59PM -0400, Pavel Ivanov wrote: On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov b...@alien8.de wrote: With CONFIG_DRM_RADEON=y, the microcode is needed before it can be loaded from userspace, so it needs to be built into the kernel as well. How should I do that? I've tried to set all ms to y in .config and still saw this issue. Should I set some special parameter? You need to add radeon/CEDAR_pfp.bin to CONFIG_EXTRA_FIRMWARE when you configure your kernel and enable CONFIG_FIRMWARE_IN_KERNEL. The radeon/CEDAR_pfp.bin file (+ leading directory, mind you) should most probably be located in /lib/firmware or to whatever you have set CONFIG_EXTRA_FIRMWARE_DIR so that Kbuild can find it (if not, you'll get a warning at the end of the kernel build). This way, it works for both radeon being =m and =y. Everything else in /lib/firmware/radeon is needed after user space become available? You mean the other *.bin files? If so, not for your case, AFAICT - your driver is requesting CEDAR_pfp.bin only, correct? But I mean, it won't hurt if you leave them all there, they're under 1M. You should recheck and add any other .bin files to the CONFIG_EXTRA_FIRMWARE string so that radeon.ko is satisfied :). HTH. -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote: On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote: With CONFIG_DRM_RADEON=y, the microcode is needed before it can be loaded from userspace, so it needs to be built into the kernel as well. How should I do that? I've tried to set all ms to y in .config and still saw this issue. Should I set some special parameter? You need to add radeon/CEDAR_pfp.bin to CONFIG_EXTRA_FIRMWARE when you configure your kernel and enable CONFIG_FIRMWARE_IN_KERNEL. The radeon/CEDAR_pfp.bin file (+ leading directory, mind you) should most probably be located in /lib/firmware or to whatever you have set CONFIG_EXTRA_FIRMWARE_DIR so that Kbuild can find it (if not, you'll get a warning at the end of the kernel build). This way, it works for both radeon being =m and =y. Should we make Kconfig pop up a dialog and ask for the whereabouts of these firmware thingies when you mark the driver =y? This all sounds like magic to me, having to know you need to add to EXTRA_FIRMWARE, having to know what file it needs etc.. For all intents and purposes =y just doesn't work and that's broken. Yep, you make a lot of sense. I had to fumble the build/reboot cycle a couple of times and do some code staring even to figure this out. In the end, I copied the whole radeon/ folder from David's firmware git repo into /lib/firmware and made radeon.ko =m again so that I don't have to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm building a kernel on a different machine. Besides, there was this other issue on lkml today where CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you overflow its length of 256 by trying to include a bunch of firmware *bin files: http://lkml.org/lkml/2011/8/29/86 Alex? -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote: Should we make Kconfig pop up a dialog and ask for the whereabouts of these firmware thingies when you mark the driver =y? This all sounds like magic to me, having to know you need to add to EXTRA_FIRMWARE, having to know what file it needs etc.. For all intents and purposes =y just doesn't work and that's broken. Yep, you make a lot of sense. I had to fumble the build/reboot cycle a couple of times and do some code staring even to figure this out. In the end, I copied the whole radeon/ folder from David's firmware git repo into /lib/firmware and made radeon.ko =m again so that I don't have to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm building a kernel on a different machine. Besides, there was this other issue on lkml today where CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you overflow its length of 256 by trying to include a bunch of firmware *bin files: http://lkml.org/lkml/2011/8/29/86 If you are going to build the ucode into your kernel you'll need to pick the ones you want to include or increase the limit regardless of whether it's radeon ucode or ucode for some other chip. For a particular card you only need the ones for that card (e.g., CEDAR_*.bin or REDWOOD_*.bin, etc.) Alex, Dave, yeah, that's all fine. The question Peter asked is, how to make this much more understandable to the user so that she/he doesn't have to figure it out on their own. IOW, if one sets RADEON to =y in Kconfig, it should automatically generate a selection menu with all the firmware required so that the user can select from it either the CEDAR* or the REDWOOD* (or the DOUGHNUT* :-)) ones for her/his card and when the user selects one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE _automatically_. Maybe even Kbuild should try to find them on the system, and, if unable to, remind the user to install the needed firmware package. Anyway, something to that effect, the above is just to illustrate the intention, I don't know whether it would work. In any case, we're lacking user help there and we don't want to put every user through the process of finding which firmware files she/he needs when setting RADEON=y. Does that make more sense? -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 11:47:24AM -0400, David Airlie wrote: On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote: Should we make Kconfig pop up a dialog and ask for the whereabouts of these firmware thingies when you mark the driver =y? This all sounds like magic to me, having to know you need to add to EXTRA_FIRMWARE, having to know what file it needs etc.. For all intents and purposes =y just doesn't work and that's broken. Yep, you make a lot of sense. I had to fumble the build/reboot cycle a couple of times and do some code staring even to figure this out. In the end, I copied the whole radeon/ folder from David's firmware git repo into /lib/firmware and made radeon.ko =m again so that I don't have to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm building a kernel on a different machine. Besides, there was this other issue on lkml today where CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you overflow its length of 256 by trying to include a bunch of firmware *bin files: http://lkml.org/lkml/2011/8/29/86 If you are going to build the ucode into your kernel you'll need to pick the ones you want to include or increase the limit regardless of whether it's radeon ucode or ucode for some other chip. For a particular card you only need the ones for that card (e.g., CEDAR_*.bin or REDWOOD_*.bin, etc.) Alex, Dave, yeah, that's all fine. The question Peter asked is, how to make this much more understandable to the user so that she/he doesn't have to figure it out on their own. IOW, if one sets RADEON to =y in Kconfig, it should automatically generate a selection menu with all the firmware required so that the user can select from it either the CEDAR* or the REDWOOD* (or the DOUGHNUT* :-)) ones for her/his card and when the user selects one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE _automatically_. Maybe even Kbuild should try to find them on the system, and, if unable to, remind the user to install the needed firmware package. Anyway, something to that effect, the above is just to illustrate the intention, I don't know whether it would work. In any case, we're lacking user help there and we don't want to put every user through the process of finding which firmware files she/he needs when setting RADEON=y. Does that make more sense? Oh it makes sense, just neither of us are Kbuild hackers and I'm not sure that'll change at any point :) It also sounds like something that could apply to any driver with external firmware. So it seems like all the request_firmware() drivers could use a Kbuild functionality of some sort which presents the user with an option to select the firmware blobs for his hw when those drivers are =y. Hairy. Adding kbuild ML. -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote: do you want something ala: config EXTRA_FIRMWARE string default append FOO if BAR append FOZ if BAZ or maybe a new type list which would behave as a comma/space separated value. config EXTRA_FIRMWARE list bla append FOO if BAR append FOZ if BAZ Yeah, actually Kyle's note (http://lkml.org/lkml/2011/8/29/289) makes much more sense for linux and the whole firmware in the kernel deal. So it looks like the drivers should be taught to wait for userspace to appear instead of Kconfig helping them build-in firmware. And then we should go ahead and remove CONFIG_EXTRA_FIRMWARE completely... Thanks. -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 12:28:31PM -0400, Kyle Moffett wrote: No, Linus pushed back really hard last time this issue came up with something; a network driver if I recall correctly. r8169 probably. The issue is that this happens *EVEN FOR MODULAR DRIVERS* during suspend/resume. The firmware simply may not be available yet. If the driver fundamentally cannot work without the firmware then it should bind to the device and wait until the first userspace action before requesting firmware. Furthermore, the trend is generally to push the firmware OUT of the kernel binary to avoid any chance of license issues. Even if the code is built-in it should not need built-in firmware. The quickest fix is probably something like this: config DRM_RADEON_FIRMWARE tristate default m if STANDALONE default y config DRM_RADEON depends DRM_RADEON_FIRMWARE That should prevent somebody from building the radeon driver into the kernel unless they manually indicate that they have the extra firmware. Long-term, the driver should support modular firmware even when it's built-in to the kernel. Yep, and drivers should be able to select the firmware they need without users even needing to do anything about it except installing some firmware-nonfree package or whatever. Yeah, sounds much better than Kconfig actually aiding and abetting firmware blobs in the kernel and users needing to do stuff. Thanks. -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 08:16:53PM +0200, Peter Zijlstra wrote: On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote: That would suck, suppose this radeon thing is the only console you've got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come up? Same is true for NICs and netconsole of course. Not being able to stick blobs into the kernel image would so suck. NICs and nfsroot, I suppose can you use an initrd over tftp as well, but really, what's the point of an in-kernel nfsroot if you need initrd crap. Damn, just when I thought that the lofty goal of Linux distancing itself from firmware crap is within reach, you came up with all those real-life, nagging examples. So here's the whole deal IMHO: * driver =m and request_firmware() works fine - you only need the blobs in the right place. * driver =y and request_firmware() should be fixed in all cases where driver can wait. Your use cases could probably be addressed by supplying firmware blobs from the bootloader. We had this talk already concerning CPU microcode updates and how the current method is to load CPU ucode when the module gets loaded, which might be too late for some obscure (and not so obscure) cases. So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in. I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it... -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in. I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it... It would be very useful, yes. Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), .. lemme guess: they didn't put the correct tables in the BIOS in the first place and now it is too late for a BIOS fix and want to shuffle in all those fixes through initrd ontop of ACPI. Oh boy, do I love all the ACPI crap stories :). so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW. Yeah, that's not more than an idea right now, I haven't even started playing with it. If it turns out to be more superior, it could be reused for other things too but right now it's too early to tell. -- Regards/Gruss, Boris. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
This patch:
commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown len.br...@intel.com
Date: Fri Apr 1 18:28:35 2011 -0400
cpuidle: replace xen access to x86 pm_idle and default_idle
..scribble on pm_idle and access default_idle,
have it simply disable_cpuidle() so acpi_idle will not load and
architecture default HLT will be used.
idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
and acpi_idle_call to not set pm_idle (which is excellent). But the
what is acpi_idle_call, I can't find it anywhere.
amd_e400_idle and mwait_idle can still setup pm_idle which we really
do not want.
This is not the case: rather select_idle_routine()/idle_setup() sets
pm_idle.
[..]
+bool set_pm_idle_to_default()
+{
+ if (!pm_idle) {
+ pm_idle = default_idle;
+ return true;
+ }
+ return false;
+}
I don't understand what you're trying to achieve here? Do you want
default_idle to be always the pm_idle for xen or what is the deal here?
If yes, then simply do:
bool set_pm_idle_to_default(void) // remember to add void for no
function args
{
bool ret = !!pm_idle;
pm_idle = default_idle;
return ret;
}
...
void stop_this_cpu(void *dummy)
{
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..7506181 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
#endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+ WARN_ON(!set_pm_idle_to_default());
and then do
WARN_ON(set_pm_idle_to_default());
instead of having arbitrary confusing logic. This way you can warn
whether something else set pm_idle already. Or?
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
On Wed, Nov 30, 2011 at 12:59:36PM -0500, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
This patch:
Borislav,
Thanks for your review comments. How does this patch look? I believe
I touched upon all of the things you mentioned.
From eb6dbd80078312c428dde69e9313606b7513a2e6 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Mon, 21 Nov 2011 18:02:02 -0500
Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.
This patch:
commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown len.br...@intel.com
Date: Fri Apr 1 18:28:35 2011 -0400
cpuidle: replace xen access to x86 pm_idle and default_idle
..scribble on pm_idle and access default_idle,
have it simply disable_cpuidle() so acpi_idle will not load and
architecture default HLT will be used.
idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
to be set to pm_idle (which is excellent). But in the select_idle_routine()
and idle_setup(), the pm_idle can still be set to either:
amd_e400_idle, mwait_idle or default_idle. This depends on some
CPU flags (MWAIT) and in AMD case on the type of CPU.
In case of mwait_idle we can hit some instances where the hypervisor
(Amazon EC2 specifically) sets the MWAIT and we get:
Brought up 2 CPUs
invalid opcode: [#1] SMP
CPU 1
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[81015d1d] [81015d1d] mwait_idle+0x6f/0xb4
RSP: e02b:8801d28ddf10 EFLAGS: 00010082
RAX: 8801d28dc010 RBX: 8801d28ddfd8 RCX:
RDX: RSI: 0001 RDI: 0001
RBP: 8801d28ddf10 R08: R09: 0001
R10: 0001 R11: 8801d28ddfd8 R12: 81b590d0
R13: R14: R15:
FS: () GS:8801dff81000() knlGS:
CS: e033 DS: 002b ES: 002b CR0: 8005003b
CR2: CR3: 01a05000 CR4: 2660
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7:
Process swapper (pid: 0, threadinfo 8801d28dc000, task 8801d28cae60)
Stack:
8801d28ddf40 8100e2ed 8801dff8e390 c136dfe72feab515
8801d28ddf50 8149ee78
Call Trace:
[8100e2ed] cpu_idle+0xae/0xe8
[8149ee78] cpu_bringup_and_idle+0xe/0x10
RIP [81015d1d] mwait_idle+0x6f/0xb4
RSP 8801d28ddf10
In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.
The previous behavior before v3.0 was that pm_idle was set
to default_idle irregardless of select_idle_routine/idle_setup.
We want to do that, but only for one specific case: Xen.
This patch does that.
Fixes RH BZ #739499 and Ubuntu #881076
Reported-by: Stefan Bader stefan.ba...@canonical.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/include/asm/system.h |1 +
arch/x86/kernel/process.c |8
arch/x86/xen/setup.c |2 +-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long
end);
void default_idle(void);
+bool set_pm_idle_to_default(void);
void stop_this_cpu(void *dummy);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..31f47ba 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
EXPORT_SYMBOL(default_idle);
#endif
+bool set_pm_idle_to_default(void)
+{
+ bool ret = !!pm_idle;
+
+ pm_idle = default_idle;
+
+ return ret;
+}
void stop_this_cpu(void *dummy)
{
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..79dfb57 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
#endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+ WARN_ON(set_pm_idle_to_default());
fiddle_vdso();
}
From what I can see, you get the following
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Hi Alex, got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere down radeon_fence_wait_seq, judging by the error messages. And this doesn't happen with 3.7, of course. Let me know if you need any more info, thanks. [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than 1msec [16273.668361] radeon :02:00.0: GPU lockup (waiting for 0x002b last fence id 0x002a) [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in libflashplayer.so[7f1f130c5000+117b000] [16274.502807] [ cut here ] [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() [16274.502880] Hardware name: [16274.502897] list_del corruption, 8802216a3f10-next is LIST_POISON1 (dead00100100) [16274.502939] Modules linked in: nls_iso8859_15 nls_cp437 acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats binfmt_misc dm_crypt dm_mod ipv6 vfat fat fuse kvm_amd kvm radeon drm_kms_helper ttm edac_core microcode cfbfillrect cfbimgblt cfbcopyarea k10temp [16274.503141] Pid: 17386, comm: Xorg Not tainted 3.8.0-rc1 #13 [16274.503172] Call Trace: [16274.503190] [8124bd00] ? __list_del_entry+0x60/0xd0 [16274.503224] [8103b2cf] warn_slowpath_common+0x7f/0xc0 [16274.503257] [8103b3c6] warn_slowpath_fmt+0x46/0x50 [16274.503289] [8124bd03] __list_del_entry+0x63/0xd0 [16274.503320] [8124bd81] list_del+0x11/0x40 [16274.503348] [812fa00e] drm_mm_remove_node+0x9e/0xd0 [16274.503383] [812fa065] drm_mm_put_block+0x25/0x70 [16274.503422] [a003dd71] ? ttm_bo_man_put_node+0x31/0x60 [ttm] [16274.503464] [a003dd79] ttm_bo_man_put_node+0x39/0x60 [ttm] [16274.503503] [a0036790] ttm_bo_cleanup_memtype_use+0x80/0xb0 [ttm] [16274.503545] [a0037a3b] ttm_bo_release+0x1fb/0x270 [ttm] [16274.503585] [a0037ae1] ttm_bo_unref+0x31/0x40 [ttm] [16274.503656] [a00a04c7] radeon_bo_unref+0x47/0x80 [radeon] [16274.503707] [a00b2929] radeon_gem_object_free+0x39/0x40 [radeon] [16274.503748] [812f0e59] drm_gem_object_free+0x29/0x30 [16274.503781] [812f1248] drm_gem_object_release_handle+0xb8/0xd0 [16274.503819] [8122f97d] idr_for_each+0xdd/0x180 [16274.503850] [812f1190] ? drm_gem_handle_create+0x100/0x100 [16274.503887] [81099e0d] ? trace_hardirqs_on+0xd/0x10 [16274.503920] [812f17c4] drm_gem_release+0x24/0x40 [16274.503952] [812efffa] drm_release+0x54a/0x5e0 [16274.503984] [8106eed2] ? lg_local_unlock+0x42/0x70 [16274.504016] [8113afe2] __fput+0xb2/0x240 [16274.504044] [8113b22e] fput+0xe/0x10 [16274.504073] [81061765] task_work_run+0xb5/0xd0 [16274.504105] [8104144a] do_exit+0x23a/0xac0 [16274.504135] [81041e8c] do_group_exit+0x4c/0xc0 [16274.504167] [8105453d] get_signal_to_deliver+0x22d/0x960 [16274.504202] [81001a9f] do_signal+0x3f/0x5a0 [16274.504233] [8123a36e] ? trace_hardirqs_on_thunk+0x3a/0x3f [16274.504269] [8100205d] do_notify_resume+0x5d/0x90 [16274.504300] [8123a36e] ? trace_hardirqs_on_thunk+0x3a/0x3f [16274.504337] [8151d6c8] int_signal+0x12/0x17 [16274.504366] ---[ end trace 4aad5b52e5533e3e ]--- -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote: What chip is this? I think it is RV635. Here's the whole 3.8-rc1 dmesg. [0.00] Linux version 3.8.0-rc1 (boris@liondog) (gcc version 4.7.2 (Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel hpet=force [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcffe] usable [0.00] BIOS-e820: [mem 0xcfff-0xcfff2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfff3000-0xcfff] ACPI data [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] DMI:/M57SLI-S4, BIOS FF 01/24/2008 [0.00] e820: update [mem 0x-0x] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x23 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-E uncachable [0.00] F-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask F000 write-back [0.00] 3 base 0001 mask write-back [0.00] 4 base 0002 mask E000 write-back [0.00] 5 base 00022000 mask F000 write-back [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00023000 aka 8960M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xd000-0x] usable == reserved [0.00] e820: last_pfn = 0xcfff0 max_arch_pfn = 0x4 [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0xcffe] [0.00] [mem 0x-0xbfff] page 1G [0.00] [mem 0xc000-0xcfdf] page 2M [0.00] [mem 0xcfe0-0xcffe] page 4k [0.00] kernel direct mapping tables up to 0xcffe @ [mem 0x1fffd000-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x22fff] [0.00] [mem 0x1-0x1] page 1G [0.00] [mem 0x2-0x22fff] page 2M [0.00] kernel direct mapping tables up to 0x22fff @ [mem 0xcffee000-0xcffe] [0.00] ACPI: RSDP 000f6620 00014 (v00 GBT ) [0.00] ACPI: RSDT cfff3000 00038 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: FACP cfff3040 00074 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: DSDT cfff30c0 04C8E (v01 GBTNVDAACPI 1000 MSFT 010C) [0.00] ACPI: FACS cfff 00040 [0.00] ACPI: SSDT cfff7e40 004CE (v01 PTLTD POWERNOW 0001 LTP 0001) [0.00] ACPI: HPET cfff8340 00038 (v01 GBTNVDAACPI 42302E31 NVDA 0098) [0.00] ACPI: MCFG cfff8380 0003C (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: APIC cfff7d80 00098 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: Local APIC address 0xfee0 [0.00] [ea00-ea0008bf] PMD - [88022760-88022f5f] on node 0 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x22fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0xcffe] [0.00] node 0: [mem 0x1-0x22fff] [0.00] On node 0 totalpages: 2097023 [0.00] DMA zone:
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.wb=0
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.wb=0
[ … ]
[6.910104] radeon: `0' invalid for parameter `wb'
[ … ]
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried radeon.no_wb where the driver blubber appeared
but AGP writeback was still enabled:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb
[ … ]
[6.382636] [drm] radeon kernel modesetting enabled.
[6.384915] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.384981] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.388137] [drm] radeon: 512M of VRAM memory ready
[6.388181] [drm] radeon: 512M of GTT memory ready.
[6.388509] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.388570] radeon :02:00.0: radeon: using MSI.
[6.388705] [drm] radeon: irq initialized.
[6.567811] radeon :02:00.0: WB enabled
^^
[6.567856] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x8802243e5c00
[6.567922] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x8802243e5c0c
[6.601247] [drm] Radeon Display Connectors
[6.602427] [drm] radeon: power management initialized
[6.722544] fbcon: radeondrmfb (fb0) is primary device
[6.945065] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[6.945100] radeon :02:00.0: registered panic notifier
[6.945159] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
At this point, I got tired of this experimenting and went and took the
big hammer :-):
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49b06590001e..00214312db23 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -307,6 +307,11 @@ int radeon_wb_init(struct radeon_device *rdev)
rdev-wb.use_event = true;
}
+ if (rdev-wb.enabled) {
+ pr_err(%s: disable the goddam WB: radeon_no_wb: %d\n,
__func__, radeon_no_wb);
+ rdev-wb.enabled = false;
+ }
+
dev_info(rdev-dev, WB %sabled\n, rdev-wb.enabled ? en : dis);
return 0;
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+ root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb no_wb
[6.562905] [drm] radeon kernel modesetting enabled.
[6.565106] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.565172] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.567696] [drm] radeon: 512M of VRAM memory ready
[6.567742] [drm] radeon: 512M of GTT memory ready.
[6.568068] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.568130] radeon :02:00.0: radeon: using MSI.
[6.568269] [drm] radeon: irq initialized.
[6.684920] radeon_wb_init: disable the goddam WB: radeon_no_wb: 0
[6.684967] radeon :02:00.0: WB disabled
^^^
[6.685011] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x880221ea3c00
[6.685077] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x880221ea3c0c
[6.722367] [drm] Radeon Display Connectors
[6.723548] [drm] radeon: power management initialized
[6.843185] fbcon: radeondrmfb (fb0) is primary device
[7.066368] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[7.066402] radeon :02:00.0: registered panic notifier
[7.066462] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
Ok, I hope I turned off the proper WB thing (I'm assuming you meant the
radeon_no_wb parameter).
And I'm
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: no_wb=1 should work. Yeah, maybe all those radeon and other GPU module parameters' syntax should be documented somewhere - Documentation/kernel-parameters.txt for example, or a GPU-specific file, whatever - so that we can save us all the time and confusion. Provided this hasn't happened yet, of course. Thanks. -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote: (If you don't use modules: git grep MODULE_PARM_DESC -- drivers/gpu/drm/radeon/ ) Yeah. You may have hit the same issue as I, see: http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Yes, it very much looks like it. That same page kills the machine here too. Maybe the GPU gets scared from the graphic nature of those images and gives up. :-D Although the box is not completely dead - I can login to a console and save dmesg before rebooting. And this bug becomes funnier and funnier - Alex, you might want to add that webpage to your testsuite :-). Reverting commit 2d6cc729 fixes the problem for me, setting radeon.no_wb=1 doesn't help. Right, let me try that and report back. Good job Markus, thanks! -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: Right, let me try that and report back. Yep, looks like reverting the above commit fixes it - the boston.com website loads just fine. Thanks. -- 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
Re: [PATCH] drm/radeon/6xx: disable use of the DMA ring for ttm bo moves
On Sun, Dec 23, 2012 at 01:28:25PM -0500, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com Seems to fall over in some cases with heavy memory thrashing on 6xx. Needs more investigation after the holidays, disable for now. Cc: Markus Trippelsdorf mar...@trippelsdorf.de Cc: Borislav Petkov b...@alien8.de Signed-off-by: Alex Deucher alexander.deuc...@amd.com Yep, running with the revert doesn't show any other adverse effects so the real fix can take its time, relax and enjoy the holidays :-). I'll test this one tomorrow just in case, even though it looks trivial. Thanks. -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Mon, Dec 24, 2012 at 09:50:11PM -0700, Shuah Khan wrote: Saw the same error and after reading this thread, reverted the Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2. drm/radeon: use async dma for ttm buffer moves on 6xx-SI and the problem is gone. In my case, it is a solid hang right after system switches to vga. I was able to login on console once or twice. But dmesg showed the same message reported in this thread: [ 35.812085] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 35.812091] radeon :01:00.0: GPU lockup (waiting for 0x0002 last fence id 0x0001) My system has: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] You can apply http://marc.info/?l=dri-develm=135628734704029 instead, in the meantime. It partially reverts the above commit and if RV620 is a R600 asic (it should be) then it would fix your observation too. Thanks. -- 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
Re: [PATCH] drm/radeon/6xx: disable use of the DMA ring for ttm bo moves
On Sun, Dec 23, 2012 at 01:28:25PM -0500, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com Seems to fall over in some cases with heavy memory thrashing on 6xx. Needs more investigation after the holidays, disable for now. Cc: Markus Trippelsdorf mar...@trippelsdorf.de Cc: Borislav Petkov b...@alien8.de Signed-off-by: Alex Deucher alexander.deuc...@amd.com Tested-by: Borislav Petkov b...@alien8.de -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
From: Alex Deucher alexander.deuc...@amd.com
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
count must be a multiple of 2.
Cc: Borislav Petkov b...@alien8.de
Cc: Markus Trippelsdorf mar...@trippelsdorf.de
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Thanks, will run it on the box in question next week when I have access.
Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.
---
drivers/gpu/drm/radeon/r600.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2aaf147..9f4ce5e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
for (i = 0; i num_loops; i++) {
cur_size_in_dw = size_in_dw;
- if (cur_size_in_dw 0x)
- cur_size_in_dw = 0x;
+ if (cur_size_in_dw 0xFFFE)
+ cur_size_in_dw = 0xFFFE;
size_in_dw -= cur_size_in_dw;
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
cur_size_in_dw));
radeon_ring_write(ring, dst_offset 0xfffc);
--
1.7.7.5
--
Regards/Gruss,
Boris.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
[ deliberately breaking the thread because it got too long] On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: Hi Alex, got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere down radeon_fence_wait_seq, judging by the error messages. And this doesn't happen with 3.7, of course. Let me know if you need any more info, thanks. [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than 1msec [16273.668361] radeon :02:00.0: GPU lockup (waiting for 0x002b last fence id 0x002a) [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in libflashplayer.so[7f1f130c5000+117b000] [16274.502807] [ cut here ] [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() Ok, this got fixed by 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb which is upstream now. And I'm testing -rc2+ which contains this patch already + tip/master + another fix from Alan which reworks fb console locking (should be unrelated) and the machine gets unresponsive for a couple of seconds and then it is fine again. See dmesg below, the GPU gets the same lockup CP stall without the list corruption so it recovers fine. But I didn't have those stalls before so it has to be something which came up with 3.8 merge window. [44730.749380] radeon :02:00.0: GPU lockup CP stall for more than 1msec [44730.749391] radeon :02:00.0: GPU lockup (waiting for 0x00305211 last fence id 0x00305210) [44730.750596] radeon :02:00.0: Saved 25 dwords of commands on ring 0. [44730.750612] radeon :02:00.0: GPU softreset: 0x0007 [44730.768865] radeon :02:00.0: R_008010_GRBM_STATUS = 0xA0003030 [44730.768874] radeon :02:00.0: R_008014_GRBM_STATUS2 = 0x0003 [44730.768880] radeon :02:00.0: R_000E50_SRBM_STATUS = 0x20C0 [44730.768885] radeon :02:00.0: R_008674_CP_STALLED_STAT1 = 0x [44730.768889] radeon :02:00.0: R_008678_CP_STALLED_STAT2 = 0x [44730.768894] radeon :02:00.0: R_00867C_CP_BUSY_STAT = 0x00020184 [44730.768898] radeon :02:00.0: R_008680_CP_STAT = 0x80028645 [44730.768903] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE [44730.783898] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001 [44730.798893] radeon :02:00.0: R_008010_GRBM_STATUS = 0xA0003030 [44730.798896] radeon :02:00.0: R_008014_GRBM_STATUS2 = 0x0003 [44730.798899] radeon :02:00.0: R_000E50_SRBM_STATUS = 0x200080C0 [44730.798901] radeon :02:00.0: R_008674_CP_STALLED_STAT1 = 0x [44730.798904] radeon :02:00.0: R_008678_CP_STALLED_STAT2 = 0x [44730.798907] radeon :02:00.0: R_00867C_CP_BUSY_STAT = 0x [44730.798909] radeon :02:00.0: R_008680_CP_STAT = 0x8010 [44730.819926] radeon :02:00.0: GPU reset succeeded, trying to resume [44730.836763] [drm] probing gen 2 caps for device 10de:377 = 1/0 [44730.839732] [drm] PCIE GART of 512M enabled (table at 0x0004). [44730.839826] radeon :02:00.0: WB enabled [44730.839831] radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x880220223c00 [44730.839834] radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x880220223c0c [44730.871080] [drm] ring test on 0 succeeded in 0 usecs [44730.871140] [drm] ring test on 3 succeeded in 1 usecs [44730.871187] [drm] ib test on ring 0 succeeded in 0 usecs [44730.871206] [drm] ib test on ring 3 succeeded in 1 usecs Thanks. -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote: I'm assuming you didn't also update your userspace gfx stack? By that you mean x.org etc, right? Or GPU microcode too? In any case, I haven't touched any of those deliberately, AFAICR at least. Does disabling the new DMA ring for ttm bo moves avoid the issue? How do I do that? Thanks. -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 10, 2013 at 03:47:01PM -0500, Alex Deucher wrote: Does disabling the new DMA ring for ttm bo moves avoid the issue? How do I do that? diff --git a/drivers/gpu/drm/radeon/radeon_asic.c b/drivers/gpu/drm/radeon/radeon_asic.c index 9056faf..b0cc46d 100644 [ … ] Ok, I'm running -rc3 with this and will watch it for any changes in behavior. Thanks. -- 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
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote: Ok, I'm running -rc3 with this and will watch it for any changes in behavior. AFAICT, this fixes the CP stalls, for I haven't seen any of them in dmesg for the last couple of days after applying your revert. Thanks. -- 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
drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined reference to `acpi_video_get_edid'
Hi, I'm guessing someone has already triggered this on latest Linus' tree and has a fix? drivers/built-in.o: In function `nouveau_acpi_edid': /w/kernel/linux/drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined reference to `acpi_video_get_edid' make: *** [vmlinux] Error 1 Btw, I got CONFIG_ACPI_VIDEO=m while CONFIG_DRM_NOUVEAU=y and this is probably the reason for the vmlinux link error. Thanks. -- 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
Re: [PATCH] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote: Hey, Op 04-02-13 16:23, Borislav Petkov schreef: Hi, I'm guessing someone has already triggered this on latest Linus' tree and has a fix? drivers/built-in.o: In function `nouveau_acpi_edid': /w/kernel/linux/drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined reference to `acpi_video_get_edid' make: *** [vmlinux] Error 1 Btw, I got CONFIG_ACPI_VIDEO=m while CONFIG_DRM_NOUVEAU=y and this is probably the reason for the vmlinux link error. Thanks. Does this fix things? --8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by only requiring ACPI X86 to select ACPI_VIDEO. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 8a55bee..f08b9b6 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -10,7 +10,7 @@ config DRM_NOUVEAU select FB select FRAMEBUFFER_CONSOLE if !EXPERT select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT - select ACPI_VIDEO if ACPI X86 BACKLIGHT_CLASS_DEVICE VIDEO_OUTPUT_CONTROL INPUT + select ACPI_VIDEO if ACPI X86 select ACPI_WMI if ACPI select MXM_WMI if ACPI select POWER_SUPPLY Not really. drivers/built-in.o: In function `acpi_video_bus_put_one_device': /root/kernel/linux/drivers/acpi/video.c:1407: undefined reference to `thermal_cooling_device_unregister' drivers/built-in.o: In function `acpi_video_device_find_cap': /root/kernel/linux/drivers/acpi/video.c:842: undefined reference to `thermal_cooling_device_register' make: *** [vmlinux] Error 1 It is CONFIG_THERMAL=m this time. Thanks. -- 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
Re: [PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote: Argh, next attempt, based on i915's Kconfig. It seems that not only I have to select ACPI_VIDEO, I also have to select all the dependencies. Is this a Kconfig bug or working as intended? i915 seems to have a workaround, so I copied it from there. Except it's currently missing select THERMAL, so I guess it didn't get updated when that got added. 8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Yep, this takes care of all deps, Tested-by: Borislav Petkov b...@suse.de Thanks. -- 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
Re: Including drm-intel tree to linux-next
On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: Hi Steven, Since about a year ago we've switched drm/i915 to buffer around 2 weeks worth of patches so that we can do decent QA before breaking everyone's tree when things land in Dave's drm-next. But that also means we'll miss out a bit in the integration testing -next provides, which did hurt a bit in recent efforts. Hence can you please include git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued into linux-next? Probably best to merge it after drm-next. Note that drm-intel-next are the QA'ed chunks I send off to Dave. Also, any mailing lists I'm supposed to follow? And if possible please cc intel-...@lists.freedesktop.org besides dri-devel/lkml when conflicts with that tree pop up (you won't get moderation spam any more, we've fixed that up). I think you want to send this here to Stephen Rothwell. CCed. :-) -- 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
Re: [PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Tue, Feb 05, 2013 at 05:22:06PM +0100, Borislav Petkov wrote: On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote: Argh, next attempt, based on i915's Kconfig. It seems that not only I have to select ACPI_VIDEO, I also have to select all the dependencies. Is this a Kconfig bug or working as intended? i915 seems to have a workaround, so I copied it from there. Except it's currently missing select THERMAL, so I guess it didn't get updated when that got added. 8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Yep, this takes care of all deps, Tested-by: Borislav Petkov b...@suse.de Just to check whether anyone has picked this already - it is triggering on 3.8 too so it most probably needs a stable tag too. Thanks. -- 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
nouveau lockdep splat
New -rc1, so let the stabilization games begin.
I see the following on rc1, let me know if you need more info.
[0.633617] =
[0.633618] [ INFO: possible recursive locking detected ]
[0.633618] 3.9.0-rc1 #2 Not tainted
[0.633619] -
[0.633619] swapper/0/1 is trying to acquire lock:
[0.633623] (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633624]
[0.633624] but task is already holding lock:
[0.633626] (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633626]
[0.633626] other info that might help us debug this:
[0.633626] Possible unsafe locking scenario:
[0.633626]
[0.633626]CPU0
[0.633627]
[0.633627] lock(dmac-lock);
[0.633628] lock(dmac-lock);
[0.633628]
[0.633628] *** DEADLOCK ***
[0.633628]
[0.633628] May be due to missing lock nesting notation
[0.633628]
[0.633629] 10 locks held by swapper/0/1:
[0.633632] #0: (__lockdep_no_validate__){..}, at:
[8143375b] __driver_attach+0x5b/0xb0
[0.633633] #1: (__lockdep_no_validate__){..}, at:
[81433769] __driver_attach+0x69/0xb0
[0.633636] #2: (drm_global_mutex){+.+.+.}, at: [8135a8f6]
drm_get_pci_dev+0xc6/0x2d0
[0.633640] #3: (registration_lock){+.+.+.}, at: [812c8e75]
register_framebuffer+0x25/0x310
[0.633642] #4: (fb_info-lock){+.+.+.}, at: [812c7d86]
lock_fb_info+0x26/0x60
[0.633644] #5: (console_lock){+.+.+.}, at: [812c900a]
register_framebuffer+0x1ba/0x310
[0.633646] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[810694d2] __blocking_notifier_call_chain+0x42/0x80
[0.633648] #7: (dev-mode_config.mutex){+.+.+.}, at:
[8135e63a] drm_modeset_lock_all+0x2a/0x70
[0.633650] #8: (crtc-mutex){+.+.+.}, at: [8135e664]
drm_modeset_lock_all+0x54/0x70
[0.633652] #9: (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633652]
[0.633652] stack backtrace:
[0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
[0.633654] Call Trace:
[0.633656] [8109524b] __lock_acquire+0x76b/0x1c20
[0.633658] [8137f50c] ? dcb_table+0x1ac/0x2a0
[0.633659] [8141bb53] ? evo_wait+0x43/0xf0
[0.633660] [81096c6a] lock_acquire+0x8a/0x120
[0.633662] [8141bb53] ? evo_wait+0x43/0xf0
[0.633664] [815eaf52] ? mutex_lock_nested+0x292/0x330
[0.633665] [815ead2e] mutex_lock_nested+0x6e/0x330
[0.633667] [8141bb53] ? evo_wait+0x43/0xf0
[0.633668] [815eb0b7] ? __mutex_unlock_slowpath+0xc7/0x150
[0.633669] [8141bb53] evo_wait+0x43/0xf0
[0.633671] [8141e569] nv50_display_flip_next+0x749/0x7d0
[0.633672] [8141bc37] ? evo_kick+0x37/0x40
[0.633674] [8141e7ee] nv50_crtc_commit+0x10e/0x230
[0.633676] [8134c2a5] drm_crtc_helper_set_mode+0x365/0x510
[0.633677] [8134d69e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.633679] [8135f751] drm_mode_set_config_internal+0x31/0x70
[0.633680] [8134b7a1] drm_fb_helper_set_par+0x71/0xf0
[0.633682] [812d40e4] fbcon_init+0x514/0x5a0
[0.633683] [8132cbdc] visual_init+0xbc/0x120
[0.633685] [8132f293] do_bind_con_driver+0x163/0x320
[0.633686] [8132f521] do_take_over_console+0x61/0x70
[0.633687] [812d2703] do_fbcon_takeover+0x63/0xc0
[0.633689] [812d63dd] fbcon_event_notify+0x5fd/0x700
[0.633690] [815f23fd] notifier_call_chain+0x4d/0x70
[0.633691] [810694e8] __blocking_notifier_call_chain+0x58/0x80
[0.633692] [81069526] blocking_notifier_call_chain+0x16/0x20
[0.633694] [812c787b] fb_notifier_call_chain+0x1b/0x20
[0.633695] [812c9018] register_framebuffer+0x1c8/0x310
[0.633696] [8134b4d1] drm_fb_helper_initial_config+0x371/0x520
[0.633697] [8134a607] ?
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.633700] [81140a5e] ? kmem_cache_alloc_trace+0xee/0x150
[0.633701] [8140578e] nouveau_fbcon_init+0x10e/0x160
[0.633703] [813f5f8a] nouveau_drm_load+0x40a/0x5d0
[0.633705] [81430cee] ? device_register+0x1e/0x30
[0.633706] [8135c086] ? drm_sysfs_device_add+0x86/0xb0
[0.633708] [8135a9b6] drm_get_pci_dev+0x186/0x2d0
[0.633710] [812b0eab] ? __pci_set_master+0x2b/0x90
[0.633711] [813f63ba] nouveau_drm_probe+0x26a/0x2c0
[0.633713] [812b4f15] ? pci_match_device+0xd5/0xe0
[0.633714] [812b5096] pci_device_probe+0x136/0x150
[0.633715] [81433566] driver_probe_device+0x76/0x210
[0.633716] [814337ab] __driver_attach+0xab/0xb0
[0.633717]
Re: nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... Thanks. -- 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
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 08:14:18PM +0100, Marcin Slusarz wrote: On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 get_maintainer: allow keywords to match filenames) of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M:Stephen Warren swar...@wwwdotorg.org L:linux-te...@vger.kernel.org Q:http://patchwork.ozlabs.org/project/linux-tegra/list/ T:git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S:Supported K:(?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Yeah, and a lot of it, thanks for digging this out. So obviously this regex is a bit... unfortunate. Although the idea of grepping the files for unique patterns is not bad, I have to admit. :-) -- 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
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 12:31:49PM -0700, Stephen Warren wrote: get_maintainer.pl could always look at file contents IIRC. The change was that I added keyword tegra to the Tegra section that now matches this file's contents. ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau ... might be a better invocation, although perhaps I should add an explicit exclusion for nouveau to the Tegra section in MAINTAINERS. No, you should add a pattern which matches only tegra. If there's no such pattern, you should simply drop the K: thing. -- 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
Re: Who is responsible for radeon driver bugs?
Let's add some more people to CC. On Tue, Mar 12, 2013 at 05:02:49PM +0100, felix-linuxker...@fefe.de wrote: The radeon driver does not work on my laptop. I sent a bug report here a week ago, but got no responses. What is the right place to send bug reports for the radeon driver? The bug is that LVDS output does not work. This is, according to lspci, a 5000M series Madison Radeon. When I insmod the module, the screen stays in text mode and appears locked up. If something is connected to the HDMI port, I get a framebuffer console there. LVDS stays in broken text mode though. When I start X, the HDMI screen turns dark and stays dark and the LVDS screen also stays dark and I have to reboot. The driver loads the REDWOOD firmware OK. Who is responsible for this? Where do I send my bug report? Thanks, Felix -- 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
Re: OOPS with 3.9.0rc2+
+ dri-devel. On Wed, Mar 13, 2013 at 02:34:31PM +0100, Rolf Offermanns wrote: Hi, I get a kernel oops / panic with a 3.9.0rc2+ kernel (git from 2h ago) on my Sony Vaio laptop. It happened with rc1, too. Unfortunately I only have a screen photo as nothing gets written to the system log. Here is a transcript: -[cut here] WARNING: at linux-2.6/drivers/gpu/drm/drm.crtc.c:84 drm_warn_on_modeset_not_all_locked+0x80/0x90 [drm]() Hardware name: VPCF23A9E Modules linked in: [...] Pid: 1894, comm: plasma-desktop Tainted: G D W 3.9.0-rc2+ #1 Call Trace: IRQ warn_slowpath_common+0x7f/0xc0 warn_slowpath_null+0x1a/020 drm_warn_on_modeset_not_all_locked+0x80/0x90 [drm] drm_fb_helper_restore_fbdev_mode+0x1c/0x80 [drm_kms_helper] drm_fb_helper_force_kernel_mode+0x4d/0xa0 [drm_kms_helper] drm_fb_helper_panic+0x2b/0x30 [drm_kms_helper] notifier_call_chain+0x4d/0x70 __atomic_notifier_call_chain+0x12/0x20 atomic_notifier_call_chain+0x16/0x20 panic+0xef/0x1d0 oops_end+0xe2/0xf0 die+0x58/0x90 do_trap+0x6b/0170 ? __atomic_notifier_call_chain+0x12/0x20 do_divide_error+0x96/0xa0 ? intel_pstate_timer_func+0x15d/0x380 ? check_preempt_curr+0x75/0xa0 ? ttwu_do_wakeup+0x2c/0xf0 divide_error+0x1e/0x30 ? intel_pstate_timer_func+0x15d/0x380 ? intel_pstate_timer_func+0xbc/0x380 ? pid_param_set+0x120/0x120 call_timer_fn+0x3a/0x120 ? pid_param_set+0x120/0x120 run_timer_softirq+0x1fe/0x2b0 __do_softirq+0xe0/0x230 irq_exit+0xa5/0xb0 smp_apic_timer_interrupt+0x6e/0x99 apic_timer_interrupt+0x6d/0x80 EOI ? sysret_audit+0x17/0x21 -[ end trace ]-- NOHZ: local_softirq_pending 282 Is this of any use at all? How can I help track this down? Shall I attach a serial console (USB only)? lspci: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 540M] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1) 02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01) 03:00.0 SD Host controller: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 09) 03:00.1 System peripheral: Ricoh Co Ltd Device e232 (rev 06) 03:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 05) 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06) cpuinfo: processor : 0-7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz stepping: 7 microcode : 0x28 cpu MHz : 800.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4390.18
Re: nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's the same splat on -rc3. Someone better take a look
soonish, please:
[0.541078] [drm] No driver support for vblank timestamp query.
[0.541272] nouveau [ DRM] 3 available performance level(s)
[0.541276] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz
voltage 900mV
[0.541280] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.541284] nouveau [ DRM] 3: core 520MHz shader 1230MHz memory 790MHz
voltage 900mV
[0.541287] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.559846] nouveau [ DRM] MM: using COPY for buffer copies
[0.625371] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo
88043b54f000
[0.625441] fbcon: nouveaufb (fb0) is primary device
[0.62]
[0.625556] =
[0.625556] [ INFO: possible recursive locking detected ]
[0.625557] 3.9.0-rc3+ #25 Not tainted
[0.625557] -
[0.625558] swapper/0/1 is trying to acquire lock:
[0.625562] (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625562]
[0.625562] but task is already holding lock:
[0.625564] (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625565]
[0.625565] other info that might help us debug this:
[0.625565] Possible unsafe locking scenario:
[0.625565]
[0.625565]CPU0
[0.625565]
[0.625566] lock(dmac-lock);
[0.625567] lock(dmac-lock);
[0.625567]
[0.625567] *** DEADLOCK ***
[0.625567]
[0.625567] May be due to missing lock nesting notation
[0.625567]
[0.625568] 10 locks held by swapper/0/1:
[0.625570] #0: (__lockdep_no_validate__){..}, at:
[814337cb] __driver_attach+0x5b/0xb0
[0.625572] #1: (__lockdep_no_validate__){..}, at:
[814337d9] __driver_attach+0x69/0xb0
[0.625575] #2: (drm_global_mutex){+.+.+.}, at: [8135a8e6]
drm_get_pci_dev+0xc6/0x2d0
[0.625578] #3: (registration_lock){+.+.+.}, at: [812c8fc5]
register_framebuffer+0x25/0x310
[0.625581] #4: (fb_info-lock){+.+.+.}, at: [812c7ed6]
lock_fb_info+0x26/0x60
[0.625583] #5: (console_lock){+.+.+.}, at: [812c915a]
register_framebuffer+0x1ba/0x310
[0.625585] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[810695c2] __blocking_notifier_call_chain+0x42/0x80
[0.625587] #7: (dev-mode_config.mutex){+.+.+.}, at:
[8135e61a] drm_modeset_lock_all+0x2a/0x70
[0.625589] #8: (crtc-mutex){+.+.+.}, at: [8135e644]
drm_modeset_lock_all+0x54/0x70
[0.625591] #9: (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625591]
[0.625591] stack backtrace:
[0.625592] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc3+ #25
[0.625593] Call Trace:
[0.625595] [810953fb] __lock_acquire+0x76b/0x1c20
[0.625597] [8137f4ec] ? dcb_table+0x1ac/0x2a0
[0.625599] [81096e1a] lock_acquire+0x8a/0x120
[0.625600] [8141bb63] ? evo_wait+0x43/0xf0
[0.625602] [81615432] ? mutex_lock_nested+0x292/0x330
[0.625603] [8161520e] mutex_lock_nested+0x6e/0x330
[0.625605] [8141bb63] ? evo_wait+0x43/0xf0
[0.625606] [810976eb] ? mark_held_locks+0x9b/0x100
[0.625607] [8141bb63] evo_wait+0x43/0xf0
[0.625609] [8141e603] nv50_display_flip_next+0x713/0x7a0
[0.625611] [8161562e] ? mutex_unlock+0xe/0x10
[0.625612] [8141bc47] ? evo_kick+0x37/0x40
[0.625613] [8141e88e] nv50_crtc_commit+0x10e/0x230
[0.625615] [8134c295] drm_crtc_helper_set_mode+0x365/0x510
[0.625617] [8134d68e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.625618] [8135f731] drm_mode_set_config_internal+0x31/0x70
[0.625619] [8134b791] drm_fb_helper_set_par+0x71/0xf0
[0.625621] [812d4234] fbcon_init+0x514/0x5a0
[0.625623] [8132cbfc] visual_init+0xbc/0x120
[0.625624] [8132f2b3] do_bind_con_driver+0x163/0x320
[0.625625] [8132f541] do_take_over_console+0x61/0x70
[0.625627] [812d2853] do_fbcon_takeover+0x63/0xc0
[0.625628] [812d652d] fbcon_event_notify+0x5fd/0x700
[0.625629] [8161c91d] notifier_call_chain+0x4d/0x70
[0.625630] [810695d8] __blocking_notifier_call_chain+0x58/0x80
[0.625631] [81069616] blocking_notifier_call_chain+0x16/0x20
[0.625633] [812c79cb] fb_notifier_call_chain+0x1b/0x20
[0.625634] [812c9168]
Re: [Nouveau] nouveau lockdep splat
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. -- 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
Re: [Nouveau] nouveau lockdep splat
On Sun, Mar 24, 2013 at 10:00:55PM +0400, Lijo Antony wrote: Looks like this has been fixed in -rc4. Yep, it seems so here too. Thanks. -- 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
Re: [PATCH] drm: don't check modeset locks in panic handler
On Thu, May 02, 2013 at 09:43:05AM +0200, Daniel Vetter wrote:
Since we know that locking is broken in that case and it's more
important to not flood the dmesg with random gunk.
Cc: Dave Airlie airl...@gmail.com
Cc: Borislav Petkov b...@alien8.de
References:
https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/QFzFxSUeV4I
Yeah, we have this nice redirector service on k.org which uses the
Message-ID only and doesn't rely on some external URLs remaining stable.
You could use that instead:
Link: http://lkml.kernel.org/r/20130502000206.gh15...@pd.tnic
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 792c3e3..3be0802 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -78,6 +78,10 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device
*dev)
{
struct drm_crtc *crtc;
+ /* Locking is currently fubar in the panic handler. */
+ if (oops_in_progress)
+ return;
+
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
WARN_ON(!mutex_is_locked(crtc-mutex));
Yep, thanks.
Reported-and-tested-by: Borislav Petkov b...@suse.de
--
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
WARNING: CPU: 3 PID: 2701 at drivers/gpu/drm/nouveau/nouveau_gem.c:54 nouveau_gem_object_del+0xa8/0xc0()
Moin,
I got this on 3.11-rc1+ when halting the box:
[ 883.476242] [ cut here ]
[ 883.480927] WARNING: CPU: 3 PID: 2701 at
drivers/gpu/drm/nouveau/nouveau_gem.c:54 nouveau_gem_object_del+0xa8/0xc0()
[ 883.491545] Modules linked in: ntfs msdos dm_mod ext2 vfat fat loop fuse
usbhid snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp kvm_intel kvm
snd_hda_codec_realtek snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel ehci_pci xhci_hcd iTCO_wdt acpi_cpufreq
snd_hwdep aesni_intel ehci_hcd aes_x86_64 mperf glue_helper button snd_pcm
i2c_i801 iTCO_vendor_support snd_page_alloc usbcore dcdbas lrw gf128mul
processor snd_timer pcspkr sb_edac ablk_helper evdev edac_core usb_common
lpc_ich cryptd snd mfd_core soundcore microcode
[ 883.542505] CPU: 3 PID: 2701 Comm: Xorg Not tainted 3.11.0-rc1+ #4
[ 883.548746] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08
01/24/2013
[ 883.556214] 0009 88043b087ca0 815fc47d
[ 883.563735] 88043b087cd8 81047e6c 8804302a8800
88043c2cc600
[ 883.571252] 88043d6da000 0009 88043b087d70
88043b087ce8
[ 883.578780] Call Trace:
[ 883.581265] [815fc47d] dump_stack+0x54/0x74
[ 883.586463] [81047e6c] warn_slowpath_common+0x8c/0xc0
[ 883.592523] [81047eba] warn_slowpath_null+0x1a/0x20
[ 883.598408] [813e6e58] nouveau_gem_object_del+0xa8/0xc0
[ 883.604657] [8135cd5a] drm_gem_object_free+0x2a/0x30
[ 883.610630] [8135d008] drm_gem_object_release_handle+0xa8/0xd0
[ 883.617497] [812947e6] idr_for_each+0xb6/0x110
[ 883.622952] [8135cf60] ? drm_gem_vm_close+0x80/0x80
[ 883.628851] [81600ede] ? mutex_unlock+0xe/0x10
[ 883.634304] [8135dc60] drm_gem_release+0x20/0x30
[ 883.639933] [8135c01a] drm_release+0x5ba/0x650
[ 883.645397] [8116271f] __fput+0xff/0x250
[ 883.650317] [811628be] fput+0xe/0x10
[ 883.655244] [8106c6b5] task_work_run+0xb5/0xe0
[ 883.660706] [8104da93] do_exit+0x2b3/0xa40
[ 883.665808] [816049c9] ? retint_swapgs+0xe/0x13
[ 883.671343] [8104e349] do_group_exit+0x49/0xc0
[ 883.676803] [8104e3d7] SyS_exit_group+0x17/0x20
[ 883.682351] [8160d1c6] system_call_fastpath+0x1a/0x1f
[ 883.688418] ---[ end trace 9e774929633864b2 ]---
[ 883.693096]
[ 883.694609] ==
[ 883.700852] [ INFO: possible circular locking dependency detected ]
[ 883.707204] 3.11.0-rc1+ #4 Tainted: GW
[ 883.711955] ---
[ 883.718292] Xorg/2701 is trying to acquire lock:
[ 883.722969] (reservation_ww_class_mutex){+.+.+.}, at: [813e4cfc]
nouveau_bo_unpin+0x3c/0x120
[ 883.732548]
[ 883.732548] but task is already holding lock:
[ 883.738446] (dev-struct_mutex){+.+.+.}, at: [8135cfda]
drm_gem_object_release_handle+0x7a/0xd0
[ 883.748387]
[ 883.748387] which lock already depends on the new lock.
[ 883.748387]
[ 883.756649]
[ 883.756649] the existing dependency chain (in reverse order) is:
[ 883.764211]
- #1 (dev-struct_mutex){+.+.+.}:
[ 883.769051][810a61ea] lock_acquire+0x8a/0x120
[ 883.775066][815ff485] mutex_lock_nested+0x75/0x380
[ 883.781516][813e6cae] validate_fini_list.isra.7+0xde/0x130
[ 883.788662][813e6d20] validate_fini_no_ticket+0x20/0x50
[ 883.79][813e6d62] validate_fini+0x12/0x50
[ 883.801566][813e7862]
nouveau_gem_ioctl_pushbuf+0x3a2/0x16a0
[ 883.808887][8135b589] drm_ioctl+0x559/0x690
[ 883.814721][81172bf7] do_vfs_ioctl+0x97/0x590
[ 883.820737][81173140] SyS_ioctl+0x50/0x90
[ 883.826382][8160d1c6] system_call_fastpath+0x1a/0x1f
[ 883.832999]
- #0 (reservation_ww_class_mutex){+.+.+.}:
[ 883.838523][810a5b44] __lock_acquire+0x1c54/0x1d40
[ 883.844963][810a61ea] lock_acquire+0x8a/0x120
[ 883.850965][815ff485] mutex_lock_nested+0x75/0x380
[ 883.857401][813e4cfc] nouveau_bo_unpin+0x3c/0x120
[ 883.864402][813e6e45] nouveau_gem_object_del+0x95/0xc0
[ 883.871831][8135cd5a] drm_gem_object_free+0x2a/0x30
[ 883.878998][8135d008]
drm_gem_object_release_handle+0xa8/0xd0
[ 883.887030][812947e6] idr_for_each+0xb6/0x110
[ 883.893659][8135dc60] drm_gem_release+0x20/0x30
[ 883.900456][8135c01a] drm_release+0x5ba/0x650
[ 883.907060][8116271f] __fput+0xff/0x250
[ 883.913113][811628be] fput+0xe/0x10
[ 883.919163][8106c6b5] task_work_run+0xb5/0xe0
[ 883.925738][8104da93] do_exit+0x2b3/0xa40
[ 883.931959]
i915 INFO: trying to register non-static key.
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 :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] 0002 880213c9d708 815bc9d4 [0.675539] 82608750 880213c9d808 810aa864 88021d283fc0 [0.675828] 82654e60 8802 [0.676116] Call Trace: [0.676194] [815bc9d4] dump_stack+0x4f/0x84 [0.676281] [810aa864] __lock_acquire+0x1774/0x1d80 [0.676366] [81010d6f] ? save_stack_trace+0x2f/0x50 [0.676451] [810a6d7f] ? save_trace+0x3f/0xc0 [0.676535] [810aa36d] ? __lock_acquire+0x127d/0x1d80 [0.676621] [810ab445] lock_acquire+0x85/0x130 [0.676705] [810682f5] ? flush_work+0x5/0x280 [0.676787] [8106833c] flush_work+0x4c/0x280 [0.676870] [810682f5] ? flush_work+0x5/0x280 [0.676954] [810abd8e] ? mark_held_locks+0xae/0x120 [0.677039] [8106a961] ? __cancel_work_timer+0x71/0x110 [0.677125] [8106a96d] __cancel_work_timer+0x7d/0x110 [0.677207] [8106aa13] cancel_delayed_work_sync+0x13/0x20 [0.677292] [813c1e15] intel_disable_gt_powersave+0x65/0x410 [0.677379] [813c3b39] intel_gt_sanitize+0x49/0xb0 [0.677463] [81372541] i915_driver_load+0x611/0xe90 [0.677550] [8135acce] drm_get_pci_dev+0x17e/0x2a0 [0.677632] [8136ddec] i915_pci_probe+0x2c/0x70 [0.677716] [812b27fb] local_pci_probe+0x4b/0x80 [0.677798] [812b2a61] pci_device_probe+0x111/0x120 [0.677885] [813dc06b] driver_probe_device+0x7b/0x240 [0.677971] [813dc2db] __driver_attach+0xab/0xb0 [0.678053] [813dc230] ? driver_probe_device+0x240/0x240 [0.678138] [813da0ed] bus_for_each_dev+0x5d/0xa0 [0.678222] [813dbb2e] driver_attach+0x1e/0x20 [0.678304] [813db64f] bus_add_driver+0x10f/0x270 [0.678390] [813dc9ba] driver_register+0x7a/0x170 [0.678471] [812b1874] __pci_register_driver+0x64/0x70 [0.678558] [81b2b68a] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [0.678660] [8135af05] drm_pci_init+0x115/0x130 [0.678740] [81b2b68a] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [0.678843] [81b2b6f0] i915_init+0x66/0x68 [0.678927] [8100031a] do_one_initcall+0x11a/0x170 [0.679012] [8106f800] ? parse_args+0xa0/0x360 [0.679096] [81af2f92] kernel_init_freeable+0x108/0x197 [0.679182] [81af283f] ? do_early_param+0x8c/0x8c [0.679266] [815b3350] ? rest_init+0xd0/0xd0 [0.679349] [815b335e] kernel_init+0xe/0xf0 [0.679427] [815cca5c] ret_from_fork+0x7c/0xb0 [0.679509] [815b3350] ? rest_init+0xd0/0xd0 [0.680182] i915 :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
Re: i915 backlight
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. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
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 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 ^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 Backlightintel_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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
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.00] 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. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
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. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
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. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 INFO: trying to register non-static key.
On Mon, Aug 05, 2013 at 01:06:35AM +0200, Daniel Vetter wrote: On Wed, Jul 31, 2013 at 6:22 PM, Borislav Petkov b...@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 b...@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. Yes it is. Thanks. -- 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
Re: i915 INFO: trying to register non-static key.
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 :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] 0001 8802121559e0 816b265c 880212155a50 [4.410050] 8109ba03 822cd1c0 00010006 [4.410408] 8802121587a8 Looks similar to what I'm seeing. Can you cherry-pick commit e1b4d3036c07ff137955fb1c0197ab62534f46ec Author: Ben Widawsky b...@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? -- 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
Backlight control only in the kernel?
On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. Maybe tangential, so Aaron and I were wondering on https://bugzilla.kernel.org/show_bug.cgi?id=60680 whether it would make sense to handle the backlight control strictly in the kernel, without going to userspace and back? Background is that on my x230, I needed to connect the Fn-Fx backlight hotkey presses to a script to write to /sys/class/backlight/intel_backlight/brightness because Fluxbox doesn't do that (and maybe doesn't have to). So, without presuming any ACPI or backlight knowledge, can we make the backlight control work only in the kernel by connecting the hotkey presses to some backlight controlling interface which backlight-capable devices implement so that it works regardless of userspace environment? Even if the machine is not running X? Hmmm. Thanks. -- 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
Re: Backlight control only in the kernel?
On Wed, Aug 07, 2013 at 05:03:15PM +0800, Aaron Lu wrote: I think this would require the kernel has the knowledge of which backlight interface this system is using or should be using, or it wouldn't know which interface should receive and process the event... Well, we can have a default one, say acpi_video and make it overridable with command line options like acpi_backlight=vendor or acpi_backlight=gpu, for example, if acpi_video suffers of a major suckage... -- 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
Re: Backlight control only in the kernel?
On Wed, Aug 07, 2013 at 10:36:08AM +, Matthew Garrett wrote: Not really. The ACPI driver is able to do this because the events and the backlight are associated with the same device. Well, it doesn't work at least in my case. I need to echo stuff into /sys/class/backlight/intel_backlight :( We could potentially make something work with GPU backlight drivers since their PCI device should also be associated with the backlight device, but things get complicated quickly - once ddcci support is hooked up you'll also have kernel backlight devices for some external monitors, and now you need to make a policy decision about which display should be controlled in response to the keypress. One reasonable choice would be whichever display contains the currently focused window, which is obviously out of scope for the kernel. So if we're going to do this then we need a generalised mechanism in-kernel for connecting input devices to backlight devices, and we need a mechanism for disabling it when userspace knows better. This sounds like a lot of work for something that should really just be handled by userspace already. That's easy: single-monitor setups have it enabled by default. So every laptop out there will just work, without any userspace intervention. More complicated situations are presented with the opportunity to disable the kernel-side control and do it themselves. -- 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
Re: Intel Haswell kernel warning (3.11.2)
Let's CC some more people. On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote: Wakko Warner wrote: Please keep me in CC. I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This happens when I'm on a console, the screen has gone into power save and I press a key to wake it up. This doesn't happen when I'm in X. Kernel is Vanilla 3.11.2. Tested 3.12-rc2. Same result. Here's the kernel log from 3.12-rc2. [ 813.921516] [ cut here ] [ 813.921531] WARNING: CPU: 0 PID: 492 at /usr/src/linux/dist/3.12-rc2/drivers/gpu/drm/i915/intel_display.c:3920 /intel_modeset_check_state+0x764/0x770 [i915]() [ 813.921531] wrong connector dpms state [ 813.921547] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_intel crc32_pclmul snd_hda_codec i915 snd_hwdep snd_pcm_oss crc32c_intel snd_mixer_oss ghash_clmulni_intel aesni_intel intel_agp aes_x86_64 intel_gtt lrw drm_kms_helper gf128mul snd_pcm 8250_pci glue_helper drm ablk_helper e1000e snd_page_alloc agpgart snd_timer video thermal processor fan snd 8250 thermal_sys serial_core soundcore cryptd button hwmon evdev i2c_i801 [ 813.921549] CPU: 0 PID: 492 Comm: kworker/0:1 Not tainted 3.12.0-rc2 #3 [ 813.921549] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 813.921553] Workqueue: events console_callback [ 813.921554] 0009 8802360b1b48 8143608e 8802360b1b90 [ 813.921555] 8802360b1b80 8103df53 8800b24ec000 8800b24eb000 [ 813.921555] 8800b24e8800 8800b24e8bd8 8800379f3c00 8802360b1be0 [ 813.921556] Call Trace: [ 813.921560] [8143608e] dump_stack+0x54/0x8d [ 813.921563] [8103df53] warn_slowpath_common+0x73/0x90 [ 813.921564] [8103dfb7] warn_slowpath_fmt+0x47/0x50 [ 813.921569] [a056d0a3] ? intel_ddi_connector_get_hw_state+0x63/0x120 [i915] [ 813.921575] [a0564014] intel_modeset_check_state+0x764/0x770 [i915] [ 813.921578] [a0564065] intel_connector_dpms+0x45/0x80 [i915] [ 813.921581] [a03a31c0] drm_fb_helper_dpms.isra.11+0x110/0x150 [drm_kms_helper] [ 813.921582] [a03a323e] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper] [ 813.921584] [81217b52] fb_blank+0x52/0xc0 [ 813.921585] [812244bb] fbcon_blank+0x21b/0x2d0 [ 813.921588] [810481e6] ? lock_timer_base.isra.29+0x26/0x50 [ 813.921589] [81047d22] ? internal_add_timer+0x12/0x40 [ 813.921590] [810489b8] ? mod_timer+0xf8/0x1c0 [ 813.921591] [8126f871] do_unblank_screen+0xa1/0x1c0 [ 813.921593] [81270ba7] poke_blanked_console+0xc7/0xd0 [ 813.921594] [81270cef] console_callback+0x13f/0x160 [ 813.921596] [81053d08] process_one_work+0x148/0x3d0 [ 813.921597] [810549c9] worker_thread+0x119/0x3a0 [ 813.921599] [810548b0] ? manage_workers.isra.30+0x2a0/0x2a0 [ 813.921600] [8105a42b] kthread+0xbb/0xc0 [ 813.921601] [8105a370] ? kthread_create_on_node+0x120/0x120 [ 813.921603] [8143cc3c] ret_from_fork+0x7c/0xb0 [ 813.921605] [8105a370] ? kthread_create_on_node+0x120/0x120 [ 813.921605] ---[ end trace b0a29ba4948c3d5b ]--- # lspci -vns2 00:02.0 0300: 8086:041a (rev 06) (prog-if 00 [VGA controller]) Subsystem: 8086:2010 Flags: bus master, fast devsel, latency 0, IRQ 57 Memory at f000 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 # gcc version 4.8.1 (Debian 4.8.1-10) This is from dmesg: [ 354.803050] [ cut here ] [ 354.803064] WARNING: CPU: 0 PID: 482 at /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]() [ 354.803064] wrong connector dpms state [ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm
Re: 4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0
On Thu, Jan 26, 2017 at 05:26:00PM +0200, Jani Nikula wrote: > IIUC the alt fix should be for nouveau, and just the revert should be > enough for i915. I see. /me goes and reverts 3846fd9b86001bea171943cc3bb9222cb6da6b42, builds, boots... Yap, looks good, thanks. :-) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0
On Thu, Jan 26, 2017 at 03:51:25PM +0200, Jani Nikula wrote: > On Thu, 26 Jan 2017, Borislav Petkov <b...@alien8.de> wrote: > > Hi all, > > > > I see this brand new warning when booting here. > > > > Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master. > > Please try [1]. Maybe I should wait until Dave sends the "alternative driver fix" he mentions in the pull request? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0
Hi all, I see this brand new warning when booting here. Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master. [2.209255] [drm] Initialized [2.210636] [drm] Memory usable by graphics device = 2048M [2.210732] [drm] Replacing VGA console driver [2.211517] Console: switching to colour dummy device 80x25 [2.218452] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.218471] [drm] Driver supports precise vblank timestamp query. [2.219510] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.297687] [ cut here ] [2.297714] WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0 [2.297732] Modules linked in: [2.297745] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc5+ #1 [2.297757] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [2.297772] Call Trace: [2.297787] dump_stack+0x67/0x92 [2.297801] __warn+0xcb/0xf0 [2.297812] warn_slowpath_null+0x1d/0x20 [2.297824] drm_kms_helper_poll_enable.part.4+0xa8/0xc0 [2.297837] drm_kms_helper_poll_init+0xaa/0xb0 [2.297851] i915_driver_load+0x1384/0x1430 [2.297864] i915_pci_probe+0x2d/0x50 [2.297876] local_pci_probe+0x42/0xa0 [2.297888] ? pci_match_device+0xe0/0x110 [2.297900] pci_device_probe+0xdb/0x130 [2.297915] driver_probe_device+0x204/0x2e0 [2.297927] __driver_attach+0x9f/0xb0 [2.297938] ? driver_probe_device+0x2e0/0x2e0 [2.297950] bus_for_each_dev+0x66/0xa0 [2.297961] driver_attach+0x1e/0x20 [2.297972] bus_add_driver+0x1b4/0x230 [2.297986] ? mipi_dsi_bus_init+0x12/0x12 [2.297998] driver_register+0x60/0xe0 [2.298009] ? mipi_dsi_bus_init+0x12/0x12 [2.298020] __pci_register_driver+0x5d/0x60 [2.298032] i915_init+0x52/0x55 [2.298045] do_one_initcall+0x53/0x1a0 [2.298057] ? parse_args+0x260/0x3e0 [2.298071] kernel_init_freeable+0x11d/0x1a3 [2.298084] ? rest_init+0x140/0x140 [2.298094] kernel_init+0xe/0x100 [2.298104] ret_from_fork+0x2e/0x40 [2.298120] ---[ end trace a758b84f8e587539 ]--- [2.302699] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [2.304017] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 [2.304287] [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on minor 0 -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon_connector_unregister NULL ptr deref
Hi guys, I'm getting a NULL ptr deref splat when hibernating my box with 4.9-rc1+. All I got so far is an ugly camera shot from the splat which I'm typing in by hand. Any ideas or already a fix? The callstack looks like this: unable to handle kernel NULL pointer dereference at 00...0890 (I think it is 890) IP: radeon_connector_unregister+0xc/0x40 ... ? drm_connector_unregister.part drm_connector_unregister_all drm_modeset_unregister_all drm_dev_unregister drm_put_dev radeon_pci_shutdown pci_device_shutdown device_shutdown kernel_power_off power_down hibernate ... Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
radeon_connector_unregister NULL ptr deref
On Mon, Oct 24, 2016 at 04:46:30PM +0900, Michel Dänzer wrote: > Should be fixed in -rc2, specifically these commits: > > https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5 > https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=9305ee6fe52035f63d70d023235b792ba22107f0 Thanks but just tried rc2. Exactly the same splat :-( -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
radeon_connector_unregister NULL ptr deref
On Mon, Oct 24, 2016 at 02:55:26PM +, Deucher, Alexander wrote: > It was working in drm-next. It appears something regressed in the > meantime. See kernel bug 178421. Thanks Alex, I've added myself to CC. Ping me if you need me to test patches or need more debugging info. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
[PATCH] x86/pat, mm: Make track_pfn_insert() return void
On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote:
> A recent change to the mm code in:
> 87744ab3832b83ba71b931f86f9cfdb000d07da5
> mm: fix cache mode tracking in vm_insert_mixed()
While we're at it, let's simplify that track_pfn_insert() thing:
---
>From 6feb0b253e1fcccbcbc8ab3e8838db09e39b0466 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <b...@suse.de>
Date: Wed, 26 Oct 2016 19:43:43 +0200
Subject: [PATCH] x86/pat, mm: Make track_pfn_insert() return void
It only returns 0 so we can save us the testing of its retval
everywhere.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pat.c | 7 ++-
include/asm-generic/pgtable.h | 9 -
mm/huge_memory.c | 5 +++--
mm/memory.c | 8
4 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 170cc4ff057b..025bf1b929c0 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -972,20 +972,17 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t
*prot,
return 0;
}
-int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
-pfn_t pfn)
+void track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot, pfn_t pfn)
{
enum page_cache_mode pcm;
if (!pat_enabled())
- return 0;
+ return;
/* Set prot based on lookup */
pcm = lookup_memtype(pfn_t_to_phys(pfn));
*prot = __pgprot((pgprot_val(*prot) & (~_PAGE_CACHE_MASK)) |
cachemode2protval(pcm));
-
- return 0;
}
/*
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index c4f8fd2fd384..41b95d82a185 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -558,10 +558,9 @@ static inline int track_pfn_remap(struct vm_area_struct
*vma, pgprot_t *prot,
* track_pfn_insert is called when a _new_ single pfn is established
* by vm_insert_pfn().
*/
-static inline int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
- pfn_t pfn)
+static inline void track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
+ pfn_t pfn)
{
- return 0;
}
/*
@@ -593,8 +592,8 @@ static inline void untrack_pfn_moved(struct vm_area_struct
*vma)
extern int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
unsigned long pfn, unsigned long addr,
unsigned long size);
-extern int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
- pfn_t pfn);
+extern void track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
+pfn_t pfn);
extern int track_pfn_copy(struct vm_area_struct *vma);
extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
unsigned long size);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index cdcd25cb30fe..113aaa4278b9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -737,8 +737,9 @@ int vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned
long addr,
if (addr < vma->vm_start || addr >= vma->vm_end)
return VM_FAULT_SIGBUS;
- if (track_pfn_insert(vma, , pfn))
- return VM_FAULT_SIGBUS;
+
+ track_pfn_insert(vma, , pfn);
+
insert_pfn_pmd(vma, addr, pmd, pfn, pgprot, write);
return VM_FAULT_NOPAGE;
}
diff --git a/mm/memory.c b/mm/memory.c
index e18c57bdc75c..33f45edf8272 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1637,8 +1637,8 @@ int vm_insert_pfn_prot(struct vm_area_struct *vma,
unsigned long addr,
if (addr < vma->vm_start || addr >= vma->vm_end)
return -EFAULT;
- if (track_pfn_insert(vma, , __pfn_to_pfn_t(pfn, PFN_DEV)))
- return -EINVAL;
+
+ track_pfn_insert(vma, , __pfn_to_pfn_t(pfn, PFN_DEV));
ret = insert_pfn(vma, addr, __pfn_to_pfn_t(pfn, PFN_DEV), pgprot);
@@ -1655,8 +1655,8 @@ int vm_insert_mixed(struct vm_area_struct *vma, unsigned
long addr,
if (addr < vma->vm_start || addr >= vma->vm_end)
return -EFAULT;
- if (track_pfn_insert(vma, , pfn))
- return -EINVAL;
+
+ track_pfn_insert(vma, , pfn);
/*
* If we don't have pte special, then we have to use the pfn_valid()
--
2.10.0
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
Hi, commit in $Subject breaks suspend to disk on my box here. Reverting it ontop of 4.7-rc2 fixes the problem. DRM-specific messages in dmesg are: [6.837698] [drm] radeon kernel modesetting enabled. [6.871372] [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA 0x00). [6.871387] [drm] register mmio base: 0xFEA2 [6.871388] [drm] register mmio size: 65536 [6.871497] [drm] Detected VRAM RAM=512M, BAR=256M [6.871498] [drm] RAM width 128bits DDR [6.875602] [drm] radeon: 512M of VRAM memory ready [6.875603] [drm] radeon: 512M of GTT memory ready. [6.875619] [drm] Loading RV635 Microcode [6.888041] [drm] Internal thermal controller without fan control [6.888100] [drm] radeon: power management initialized [6.892400] [drm] GART: num cpu pages 131072, num gpu pages 131072 [6.893273] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [6.920032] [drm] PCIE GART of 512M enabled (table at 0x00142000). [6.920232] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [6.920232] [drm] Driver supports precise vblank timestamp query. [6.920290] [drm] radeon: irq initialized. [6.951284] [drm] ring test on 0 succeeded in 0 usecs [7.125955] [drm] ring test on 5 succeeded in 1 usecs [7.131079] [drm] UVD initialized successfully. [7.135817] [drm] ib test on ring 0 succeeded in 0 usecs [7.789092] [drm] ib test on ring 5 succeeded [7.794502] [drm] Radeon Display Connectors [7.798817] [drm] Connector 0: [7.801963] [drm] DVI-I-1 [7.804825] [drm] HPD1 [7.807430] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [7.814942] [drm] Encoders: [7.817985] [drm] DFP1: INTERNAL_UNIPHY [7.822230] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [7.826913] [drm] Connector 1: [7.830033] [drm] DIN-1 [7.832715] [drm] Encoders: [7.835751] [drm] TV1: INTERNAL_KLDSCP_DAC2 [7.840349] [drm] Connector 2: [7.843466] [drm] DVI-I-2 [7.846326] [drm] HPD2 [7.848926] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [7.856437] [drm] Encoders: [7.859479] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [7.864162] [drm] DFP2: INTERNAL_KLDSCP_LVTMA [7.941480] [drm] fb mappable at 0xC0243000 [7.945733] [drm] vram apper at 0xC000 [7.949897] [drm] size 9216000 [7.953019] [drm] fb depth is 24 [7.956327] [drm]pitch is 7680 [7.959930] fbcon: radeondrmfb (fb0) is primary device [8.028816] radeon :01:00.0: fb0: radeondrmfb frame buffer device [8.045087] [drm] Initialized radeon 2.45.0 20080528 for :01:00.0 on minor 0 [ 28.158851] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 28.160612] [drm] PCIE GART of 512M enabled (table at 0x00142000). [ 28.191669] [drm] ring test on 0 succeeded in 1 usecs [ 28.366319] [drm] ring test on 5 succeeded in 1 usecs [ 28.366323] [drm] UVD initialized successfully. [ 28.366338] [drm] ib test on ring 0 succeeded in 0 usecs [ 28.604362] ata1.00: supports DRM functions and may not be fully accessible [ 28.604405] ata2.00: supports DRM functions and may not be fully accessible [ 28.609305] ata1.00: supports DRM functions and may not be fully accessible [ 28.609410] ata2.00: supports DRM functions and may not be fully accessible [ 29.014440] [drm] ib test on ring 5 succeeded -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Mon, Jun 06, 2016 at 05:40:19PM -0400, Jerome Glisse wrote: > Brokens how ? Symptoms ? Whoops, sorry, I meant to elaborate... After doing: echo "shutdown" > /sys/power/disk echo "disk" > /sys/power/state screen goes blank but machine remains powered on and doesn't go off. No responses to keyboard presses, etc. The only thing left to do is the reset button. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Tue, Jun 07, 2016 at 05:51:52PM -0400, Jerome Glisse wrote: > Ok i don't have too much time to dig into r600 i assume that r700 breaks > the same way so could you verify that attached patch fix the issue for > you. Note that video decoding is likely broken for you after hibernation > but you might have never notice it. Probably. And that means I really haven't noticed. How do I test video decoding? mplayer seems to work fine :) > From 8ed42906e430880ce01bc6f175f1c7c180529353 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= > Date: Tue, 7 Jun 2016 17:43:04 -0400 > Subject: [PATCH] drm/radeon: do not hard reset GPU while freezing on r600/r700 > family > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Seems r600/r700 does not like hard reset while freezing for hibernation > (regression due to 274ad65c9d02bdcbee9bae045517864c3521d530 which itself > is a fix for hibernation on some GPU families). Until i can debug further > issue with r600, let just disable this for r600/r700 as they are very > similar family and bug affecting one likely affect the other. > > Signed-off-by: Jérôme Glisse Reported-and-tested-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Wed, Jun 08, 2016 at 01:50:28PM +0200, Christian König wrote: > What's the output of mplayer? Mplayer usually uses video acceleration when > it is available. Something like this? libavformat version 56.23.105 (internal) libavformat file format detected. [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang eng VIDEO: [H264] 1280x720 24bpp 23.976 fps 1702.9 kbps (207.9 kbyte/s) Clip info: major_brand: mp42 minor_version: 0 compatible_brands: isommp42 creation_time: 2015-09-24 14:54:07 Load subtitles in ./ == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 56.26.100 (internal) Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 23999->352800) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 1280x720 => 1280x720 Planar YV12 A: 1.5 V: 1.5 A-V: 0.001 ct: 0.041 0/ 0 8% 2% 1.3% 0 0 -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Wed, Jun 08, 2016 at 03:30:34PM +0200, Christian König wrote: > Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file". All good. Actually, this hw accel thing is much better, I better make it default :-P libavformat version 56.23.105 (internal) libavformat file format detected. [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang eng VIDEO: [H264] 1280x720 24bpp 23.976 fps 1702.9 kbps (207.9 kbyte/s) Clip info: major_brand: mp42 minor_version: 0 compatible_brands: isommp42 creation_time: 2015-09-24 14:54:07 Load subtitles in ./ == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 56.26.100 (internal) Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 23999->352800) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 1280x720 => 1280x720 Planar YV12 A: 3.5 V: 3.5 A-V: 0.000 ct: 0.042 0/ 0 8% 1% 1.3% 0 0 -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Wed, Jun 08, 2016 at 03:47:12PM +0200, Borislav Petkov wrote: > All good. Actually, this hw accel thing is much better, I better make it > default :-P And yes, this is with Jérôme's fix to exclude r600 and r700 from hard reset before hibernation. And after a s2d cycle I did earlier. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Wed, Jun 08, 2016 at 10:06:23AM -0400, Jerome Glisse wrote: > To be clear, you mean that after hibernation video acceleration keeps working > ? Apparently. At lest the vdpau output looks fine to me. > Can you copy radeon dmesg after hibernation cycle (once you resumed > from hibernation). $ dmesg | grep -Ei "(radeon|drm)" ... (boot messages) ... [8.149356] fbcon: radeondrmfb (fb0) is primary device [8.218800] radeon :01:00.0: fb0: radeondrmfb frame buffer device [8.238402] [drm] Initialized radeon 2.45.0 20080528 for :01:00.0 on minor 0 <-- hibernate. [ 64.711657] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 64.714898] [drm] PCIE GART of 512M enabled (table at 0x00142000). [ 64.714920] radeon :01:00.0: WB enabled [ 64.714923] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x88042b342c00 [ 64.715123] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x000521d0 and cpu addr 0xc900030121d0 [ 64.745988] [drm] ring test on 0 succeeded in 1 usecs [ 64.920633] [drm] ring test on 5 succeeded in 1 usecs [ 64.920637] [drm] UVD initialized successfully. [ 64.920652] [drm] ib test on ring 0 succeeded in 0 usecs [ 65.128759] ata1.00: supports DRM functions and may not be fully accessible [ 65.128799] ata2.00: supports DRM functions and may not be fully accessible [ 65.133700] ata1.00: supports DRM functions and may not be fully accessible [ 65.133811] ata2.00: supports DRM functions and may not be fully accessible [ 65.566744] [drm] ib test on ring 5 succeeded Let me know if you need more stuff dumped. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Wed, Jun 08, 2016 at 05:28:53PM +0200, Grigori Goronzy wrote: > Are you sure it is using accelerated decoding? CPU load should be just 1-2%. Ha, good point. So with mplayer vo=vdpau, CPU load was at something over 12%. Doing: $ mpv --vo=vdpau --hwdec=vdpau $file (+) Video --vid=1 (*) (h264) (+) Audio --aid=1 --alang=eng (*) (aac) Trying to use hardware decoding. AO: [alsa] 48000Hz stereo 2ch float VO: [vdpau] 1280x720 vdpau AV: 00:00:50 / 00:02:36 (32%) A-V: 0.000 did bring it down to 5-6ish. PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 12482 boris 20 0 1026628 74272 47632 S 5.6 0.5 0:02.77 mpv so I'm guessing this should be using hw accel now... In any case, output looks fine again too. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
On Wed, Jun 08, 2016 at 12:44:12PM -0400, Alex Deucher wrote: > If the ring and IB tests pass on resume, you should be good to go. Yap, they do. I pasted that output earlier but here it is again: [ 64.745988] [drm] ring test on 0 succeeded in 1 usecs [ 64.920633] [drm] ring test on 5 succeeded in 1 usecs [ 64.920637] [drm] UVD initialized successfully. [ 64.920652] [drm] ib test on ring 0 succeeded in 0 usecs -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
i386 allyesconfig: gfx_v7_0_ring_emit_vm_flush
Hey Alex, I see this on a 32-bit, allyesconfig build today: drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function âgfx_v7_0_ring_emit_vm_flushâ: drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3631:17: warning: initialization makes integer from pointer without a cast [-Wint-conversion] uint32_t seq = ring->fence_drv.sync_seq; ^ -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
[PATCH] drm/amd: Beef up ACP Kconfig menu text
From: Borislav Petkov <b...@suse.de>
The current "text" needs a user to use a crystal ball in order to find
out what this ACP thing is.
Use the text from
a8fe58cec351 ("drm/amd: add ACP driver support")
to make it a bit more understandable to the rest of the world.
Signed-off-by: Borislav Petkov
Cc: Alex Deucher
Cc: Chunming Zhou
Cc: Jammy Zhou
Cc: Maruthi Bayyavarapu
Cc: Murali Krishna Vemuri
---
drivers/gpu/drm/amd/acp/Kconfig | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig
index 0f734ee05274..ca77ec10147c 100644
--- a/drivers/gpu/drm/amd/acp/Kconfig
+++ b/drivers/gpu/drm/amd/acp/Kconfig
@@ -1,10 +1,14 @@
-menu "ACP Configuration"
+menu "ACP (Audio CoProcessor) Configuration"
config DRM_AMD_ACP
- bool "Enable ACP IP support"
+ bool "Enable AMD Audio CoProcessor IP support"
select MFD_CORE
select PM_GENERIC_DOMAINS if PM
help
Choose this option to enable ACP IP support for AMD SOCs.
+ This adds the ACP (Audio CoProcessor) IP driver and wires
+ it up into the amdgpu driver. The ACP block provides the DMA
+ engine for the i2s-based ALSA driver. It is required for audio
+ on APUs which utilize an i2s codec.
endmenu
--
2.7.3
[PATCH 06/10] x86/cpufeature: Kill cpu_has_clflush
From: Borislav Petkov <b...@suse.de>
Use the fast variant in the DRM code.
Signed-off-by: Borislav Petkov
Cc: dri-devel at lists.freedesktop.org
Cc: intel-gfx at lists.freedesktop.org
---
arch/x86/include/asm/cpufeature.h | 1 -
arch/x86/kernel/cpu/intel.c| 2 +-
arch/x86/kernel/tce_64.c | 2 +-
arch/x86/mm/pageattr.c | 2 +-
drivers/gpu/drm/drm_cache.c| 6 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
6 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 693b4aa43908..a75154232db5 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -129,7 +129,6 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
#define cpu_has_aesboot_cpu_has(X86_FEATURE_AES)
#define cpu_has_avxboot_cpu_has(X86_FEATURE_AVX)
#define cpu_has_avx2 boot_cpu_has(X86_FEATURE_AVX2)
-#define cpu_has_clflushboot_cpu_has(X86_FEATURE_CLFLUSH)
#define cpu_has_patboot_cpu_has(X86_FEATURE_PAT)
#define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
#define cpu_has_xsaves boot_cpu_has(X86_FEATURE_XSAVES)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 1f7fdb91a818..628a9f853b84 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -468,7 +468,7 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_PEBS);
}
- if (c->x86 == 6 && cpu_has_clflush &&
+ if (c->x86 == 6 && boot_cpu_has(X86_FEATURE_CLFLUSH) &&
(c->x86_model == 29 || c->x86_model == 46 || c->x86_model == 47))
set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR);
diff --git a/arch/x86/kernel/tce_64.c b/arch/x86/kernel/tce_64.c
index ab40954e113e..f386bad0984e 100644
--- a/arch/x86/kernel/tce_64.c
+++ b/arch/x86/kernel/tce_64.c
@@ -40,7 +40,7 @@
static inline void flush_tce(void* tceaddr)
{
/* a single tce can't cross a cache line */
- if (cpu_has_clflush)
+ if (boot_cpu_has(X86_FEATURE_CLFLUSH))
clflush(tceaddr);
else
wbinvd();
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index fb20c2ee0092..bbf462ff9745 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1460,7 +1460,7 @@ static int change_page_attr_set_clr(unsigned long *addr,
int numpages,
* error case we fall back to cpa_flush_all (which uses
* WBINVD):
*/
- if (!ret && cpu_has_clflush) {
+ if (!ret && boot_cpu_has(X86_FEATURE_CLFLUSH)) {
if (cpa.flags & (CPA_PAGES_ARRAY | CPA_ARRAY)) {
cpa_flush_array(addr, numpages, cache,
cpa.flags, pages);
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 6743ff7dccfa..059f7c39c582 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -72,7 +72,7 @@ drm_clflush_pages(struct page *pages[], unsigned long
num_pages)
{
#if defined(CONFIG_X86)
- if (cpu_has_clflush) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
drm_cache_flush_clflush(pages, num_pages);
return;
}
@@ -105,7 +105,7 @@ void
drm_clflush_sg(struct sg_table *st)
{
#if defined(CONFIG_X86)
- if (cpu_has_clflush) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
struct sg_page_iter sg_iter;
mb();
@@ -129,7 +129,7 @@ void
drm_clflush_virt_range(void *addr, unsigned long length)
{
#if defined(CONFIG_X86)
- if (cpu_has_clflush) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
const int size = boot_cpu_data.x86_clflush_size;
void *end = addr + length;
addr = (void *)(((unsigned long)addr) & -size);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1328bc5021b4..b845f468dd74 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -488,7 +488,7 @@ i915_gem_execbuffer_relocate_entry(struct
drm_i915_gem_object *obj,
ret = relocate_entry_cpu(obj, reloc, target_offset);
else if (obj->map_and_fenceable)
ret = relocate_entry_gtt(obj, reloc, target_offset);
- else if (cpu_has_clflush)
+ else if (static_cpu_has(X86_FEATURE_CLFLUSH))
ret = relocate_entry_clflush(obj, reloc, target_offset);
else {
WARN_ONCE(1, "Impossible case in relocation handling\n");
--
2.7.3
[RFC PATCH] nouveau: rename aux.c to auxiliary.c for reviewing it on Windows
On Wed, Jun 11, 2014 at 03:53:55PM +0800, Lai Jiangshan wrote: > When I tried to review the linux kernel on Windows in my laptop > and incidentally found that it failed to open the aux.c. > > And Microsoft tells me: > (http://msdn.microsoft.com/en-us/library/aa365247.aspx) > > > Do not use the following reserved names for the name of a file: > > CON, PRN, AUX, NUL, , and LPT9. Also avoid these names > > followed immediately by an extension; for example, NUL.txt > > is not recommended. > > The name "aux" is listed above. And it sometimes makes sense to > review linux on windows, so we rename the aux.c to auxiliary.c. I think you missed April 1st by more than 2 months. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 3/6] x86: Add support for the clwb instruction
On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote: > > +".byte 0x66; xsaveopt %P0", > > Huh, XSAVEOPT?!? Shouldn't that be CLWB?? Bah, the same opcodes, only 0x66 prefix makes it into CLWB. Could use a comment I guess. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 3/6] x86: Add support for the clwb instruction
On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> Add support for the new clwb instruction. This instruction was
> announced in the document "Intel Architecture Instruction Set Extensions
> Programming Reference" with reference number 319433-022.
>
> https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
>
> Here are some things of note:
>
> - As with the clflushopt patches before this, I'm assuming that the
> addressing
>mode generated by the original clflush instruction will match the new
>clflush instruction with the 0x66 prefix for clflushopt, and for the
>xsaveopt instruction with the 0x66 prefix for clwb. For all the test cases
>that I've come up with and for the new clwb code generated by this patch
>series, this has proven to be true on my test machine.
>
> - According to the SDM, xsaveopt has a form where it has a REX.W prefix. I
>believe that this prefix will not be generated by gcc in x86_64 kernel
> code.
>Based on this, I don't believe I need to account for this extra prefix when
>dealing with the assembly language created for clwb. Please correct me if
>I'm wrong.
>
> Signed-off-by: Ross Zwisler
> Cc: H Peter Anvin
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: x86 at kernel.org
> ---
> arch/x86/include/asm/cpufeature.h| 1 +
> arch/x86/include/asm/special_insns.h | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/x86/include/asm/cpufeature.h
> b/arch/x86/include/asm/cpufeature.h
> index b3e6b89..fbbed34 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -227,6 +227,7 @@
> #define X86_FEATURE_SMAP ( 9*32+20) /* Supervisor Mode Access Prevention
> */
> #define X86_FEATURE_PCOMMIT ( 9*32+22) /* PCOMMIT instruction */
> #define X86_FEATURE_CLFLUSHOPT ( 9*32+23) /* CLFLUSHOPT instruction */
> +#define X86_FEATURE_CLWB ( 9*32+24) /* CLWB instruction */
> #define X86_FEATURE_AVX512PF ( 9*32+26) /* AVX-512 Prefetch */
> #define X86_FEATURE_AVX512ER ( 9*32+27) /* AVX-512 Exponential and
> Reciprocal */
> #define X86_FEATURE_AVX512CD ( 9*32+28) /* AVX-512 Conflict Detection */
> diff --git a/arch/x86/include/asm/special_insns.h
> b/arch/x86/include/asm/special_insns.h
> index 1709a2e..a328460 100644
> --- a/arch/x86/include/asm/special_insns.h
> +++ b/arch/x86/include/asm/special_insns.h
> @@ -199,6 +199,16 @@ static inline void clflushopt(volatile void *__p)
> "+m" (*(volatile char __force *)__p));
> }
>
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
Any particular reason for using 0x3e as a prefix to have the insns be
the same size or is it simply because CLFLUSH can stomach it?
:-)
> + ".byte 0x66; clflush %P0",
> + X86_FEATURE_CLFLUSHOPT,
> + ".byte 0x66; xsaveopt %P0",
Huh, XSAVEOPT?!? Shouldn't that be CLWB??
> + X86_FEATURE_CLWB,
> + "+m" (*(volatile char __force *)__p));
> +}
> +
> static inline void pcommit(void)
> {
> alternative(ASM_NOP4, ".byte 0x66, 0x0f, 0xae, 0xf8",
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
[PATCH 3/6] x86: Add support for the clwb instruction
On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote:
> Yep, it's weird, I know. :)
But sure, saving opcode space, makes sense to me.
Btw, I'd still be interested about this:
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
Any particular reason for using 0x3e as a prefix to have the insns be
the same size or is it simply because CLFLUSH can stomach it?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
[PATCH 3/6] x86: Add support for the clwb instruction
On Tue, Nov 11, 2014 at 12:48:52PM -0700, Ross Zwisler wrote: > Essentially we need one additional byte at the beginning of the clflush so > that we can flip it into a clflushopt by changing that byte into a 0x66 > prefix. Two options are to either insert a 1 byte ASM_NOP1, or to add a 1 > byte NOP_DS_PREFIX. Both have no functional effect with the plain clflush, > but I've been told that executing a clflush + prefix should be faster than > executing a clflush + NOP. I see. :) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 3/6] x86: Add support for the clwb instruction
On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0",
> + ".byte 0x66; clflush %P0",
> + X86_FEATURE_CLFLUSHOPT,
> + ".byte 0x66; xsaveopt %P0",
Btw, I'm afraid you're going to have to spell out those new instruction
mnemonics as they aren't supported by older compilers:
CC drivers/gpu/drm/drm_cache.o
{standard input}: Assembler messages:
{standard input}:63: Error: no such instruction: `xsaveopt (%rax)'
{standard input}:249: Error: no such instruction: `xsaveopt (%rdi)'
{standard input}:283: Error: no such instruction: `xsaveopt -1(%rdx)'
make[1]: *** [drivers/gpu/drm/drm_cache.o] Error 1
make: *** [drivers/gpu/drm/drm_cache.o] Error 2
[boris at etch:14:35:40:k:14)-> gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
This is on a very old guest I have which has this gcc in it and the
kernel supports everything gcc >= 3.2.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
[PATCH 3/6] x86: Add support for the clwb instruction
On Wed, Nov 12, 2014 at 01:38:45PM +, Anvin, H Peter wrote: > No, it doesn't. x86 requires 3.4+ at a minimum. The only test I see is: #if GCC_VERSION < 30200 # error Sorry, your compiler is too old - please upgrade it. #endif And even if we do require 3.4, the build fails with 4.1+ so... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 6/6] x86: Use clwb in drm_clflush_virt_range
On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote: > On 11/11/2014 10:43 AM, Ross Zwisler wrote: > > If clwb is available on the system, use it in drm_clflush_virt_range. > > If clwb is not available, fall back to clflushopt if you can. > > If clflushopt is not supported, fall all the way back to clflush. > > I don't know exactly what drm_clflush_virt_range (and the other > functions you're modifying similarly) are for, but it seems plausible to > me that they're used before reads to make sure that non-coherent memory > sees updated data. If that's true, then this will break it. Why would it break it? The updated cachelines will be in memory and subsequent reads will be serviced from the cache instead from going to memory as it is not invalidated as it would be by CLFLUSH. /me is puzzled. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 6/6] x86: Use clwb in drm_clflush_virt_range
On Thu, Nov 13, 2014 at 08:38:23AM -0800, Andy Lutomirski wrote: > On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote: > > > > On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote: > > > On 11/11/2014 10:43 AM, Ross Zwisler wrote: > > > > If clwb is available on the system, use it in drm_clflush_virt_range. > > > > If clwb is not available, fall back to clflushopt if you can. > > > > If clflushopt is not supported, fall all the way back to clflush. > > > > > > I don't know exactly what drm_clflush_virt_range (and the other > > > functions you're modifying similarly) are for, but it seems plausible to > > > me that they're used before reads to make sure that non-coherent memory > > > sees updated data. If that's true, then this will break it. > > > > Why would it break it? The updated cachelines will be in memory and > > subsequent reads will be serviced from the cache instead from going to > > memory as it is not invalidated as it would be by CLFLUSH. > > > > /me is puzzled. > > Suppose you map some device memory WB, and then the device > non-coherently updates. If you want the CPU to see it, you need > clflush or clflushopt. Some architectures might do this for > dma_sync_single_for_cpu with DMA_FROM_DEVICE. Ah, you're talking about the other way around - the device does the writes. Well, the usage sites are all in i915*, maybe we should ask them - it looks to me like this is only the CPU making stuff visible in the shared buffer but I don't know that code... intel-gfx CCed although dri-devel is already on CC. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 6/6] x86: Use clwb in drm_clflush_virt_range
On Thu, Nov 13, 2014 at 07:33:54PM +0200, Ville Syrjälä wrote: > We use it both ways in i915. So please don't break it. Haha, we started from Intel with Ross' patch and made a full circle back. Maybe you guys should talk about it. LOL. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH v5 08/24] amdkfd: Add amdkfd skeleton driver
On Fri, Nov 21, 2014 at 09:34:45PM +0200, Oded Gabbay wrote: > The DRM_AMDGPU symbol belongs to AMD's new Linux kernel graphic > driver, called amdgpu. That driver is not yet upstreamed, so its > symbol is not present in any Kconfig file. However, internally we work > with that driver so that's why it appears in my patch. > > I can remove it if it violates some rule. Yes it does: no out-of-tree symbols. Please remove it. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
intel_sdvo_init: trying to register non-static key
Hi guys, so I'm seeing this on rc1 + tip during boot: [0.558106] Linux agpgart interface v0.103 [0.558283] [drm] Initialized drm 1.1.0 20060810 [0.562280] [drm] Memory usable by graphics device = 2048M [0.632301] i915 :00:02.0: irq 42 for MSI/MSI-X [0.632401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [0.632485] [drm] Driver supports precise vblank timestamp query. [0.633200] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [0.655917] INFO: trying to register non-static key. [0.656003] the code is fine but needs lockdep annotation. [0.656083] turning off the locking correctness validator. [0.656165] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc1+ #1 [0.656248] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [0.656348] 880213ca8000 880213d01518 8160ffa8 810ad3c1 [0.656641] 8800cabc7560 880213d01618 8109e7c7 880213ca8000 [0.656929] 880213ca8780 8802 [0.657216] Call Trace: [0.657295] [] dump_stack+0x4f/0x7c [0.657378] [] ? console_unlock+0x2a1/0x450 [0.657465] [] __lock_acquire+0x1b57/0x1d50 [0.657551] [] ? mark_held_locks+0x74/0x140 [0.657637] [] ? debug_check_no_locks_freed+0x8e/0x160 [0.657724] [] ? lockdep_init_map+0xb3/0x570 [0.657809] [] ? trace_hardirqs_on_caller+0x11d/0x1e0 [0.657897] [] ? kernfs_addrm_finish+0x38/0x60 [0.657982] [] lock_acquire+0x87/0x130 [0.658062] [] ? kernfs_addrm_finish+0x38/0x60 [0.658148] [] kernfs_deactivate+0x10e/0x150 [0.658232] [] ? kernfs_addrm_finish+0x38/0x60 [0.658318] [] kernfs_addrm_finish+0x38/0x60 [0.658404] [] kernfs_remove_by_name_ns+0x58/0xb0 [0.658490] [] remove_files.isra.1+0x41/0x80 [0.658574] [] sysfs_remove_group+0x50/0xb0 [0.658659] [] sysfs_remove_groups+0x3b/0x60 [0.658746] [] device_remove_attrs+0x5b/0x80 [0.658832] [] device_del+0x125/0x1c0 [0.658915] [] device_unregister+0x16/0x30 [0.659000] [] i2c_del_adapter+0x1ba/0x270 [0.659086] [] intel_sdvo_init+0x1f6/0x820 [0.659172] [] ? preempt_count_sub+0xb1/0x100 [0.659258] [] ? _raw_spin_unlock_irqrestore+0x4b/0x80 [0.659347] [] ? gen6_read32+0x63/0x170 [0.659431] [] intel_modeset_init+0xb3d/0x1010 [0.659519] [] ? intel_power_domains_init_hw+0xa9/0x110 [0.659606] [] i915_driver_load+0xd5f/0xeb0 [0.659692] [] drm_dev_register+0x8a/0x190 [0.659777] [] drm_get_pci_dev+0xf9/0x230 [0.659861] [] i915_pci_probe+0x3b/0x60 [0.659945] [] local_pci_probe+0x4e/0xa0 [0.660029] [] ? get_device+0x19/0x20 [0.660110] [] pci_device_probe+0xe1/0x130 [0.660194] [] driver_probe_device+0x7b/0x240 [0.660279] [] __driver_attach+0xab/0xb0 [0.660363] [] ? driver_probe_device+0x240/0x240 [0.660448] [] bus_for_each_dev+0x5e/0x90 [0.660532] [] driver_attach+0x1e/0x20 [0.660615] [] bus_add_driver+0x117/0x230 [0.660698] [] driver_register+0x64/0xf0 [0.660780] [] __pci_register_driver+0x64/0x70 [0.660869] [] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [0.660970] [] drm_pci_init+0x115/0x130 [0.661054] [] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [0.661157] [] i915_init+0x6a/0x6c [0.661241] [] do_one_initcall+0x4e/0x170 [0.661328] [] ? parse_args+0xb0/0x360 [0.661412] [] kernel_init_freeable+0x106/0x19a [0.661497] [] ? do_early_param+0x86/0x86 [0.661580] [] ? rest_init+0xd0/0xd0 [0.661663] [] kernel_init+0xe/0x130 [0.661746] [] ret_from_fork+0x7c/0xb0 [0.661828] [] ? rest_init+0xd0/0xd0 [0.747947] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [0.758745] fbcon: inteldrmfb (fb0) is primary device -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
intel_sdvo_init: trying to register non-static key
On Fri, Feb 07, 2014 at 01:12:22PM +0200, Imre Deak wrote: > On Fri, 2014-02-07 at 13:04 +0200, Jani Nikula wrote: > > Imre, is this the same i2c_del_adapter issue you're looking at? Any > > patches to try yet? > > It looks like the same issue yes. The following patch fixed it for me: > > http://patchwork.freedesktop.org/patch/18698/ > > I'm working on an improved version of this, but the main thing - to > remove the connector's sysfs entries before actually destroying the > encoder and connector objects - will remain the same as in the above > patch. You could shoot the final version my way so that I give it a run too. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
intel_sdvo_init: trying to register non-static key
On Fri, Feb 07, 2014 at 05:32:06PM +0200, Imre Deak wrote: > I just realized it's a different issue, since it's on the init path. > Also we set the drm device as the parent for the sdvo i2c adapter as > opposed to the dp i2c adapter where it's the connector device. So the > above patch won't help in Borislav's case. Yep, correct: [0.555355] Linux agpgart interface v0.103 [0.24] [drm] Initialized drm 1.1.0 20060810 [0.559559] [drm] Memory usable by graphics device = 2048M [0.630197] i915 :00:02.0: irq 42 for MSI/MSI-X [0.630301] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [0.630384] [drm] Driver supports precise vblank timestamp query. [0.631116] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [0.653810] INFO: trying to register non-static key. [0.653896] the code is fine but needs lockdep annotation. [0.653974] turning off the locking correctness validator. [0.654057] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc1+ #1 [0.654136] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [0.654236] 880213ca8000 880213d01518 81610028 810ad3c1 [0.654525] 8800ca6f5ab8 880213d01618 8109e7c7 880213ca8000 [0.654819] 880213ca8780 8802 [0.655108] Call Trace: [0.655186] [] dump_stack+0x4f/0x7c [0.655270] [] ? console_unlock+0x2a1/0x450 [0.655357] [] __lock_acquire+0x1b57/0x1d50 [0.655441] [] ? mark_held_locks+0x74/0x140 [0.655525] [] ? debug_check_no_locks_freed+0x8e/0x160 [0.655612] [] ? lockdep_init_map+0xb3/0x570 [0.655696] [] ? trace_hardirqs_on_caller+0x11d/0x1e0 [0.655784] [] ? kernfs_addrm_finish+0x38/0x60 [0.655868] [] lock_acquire+0x87/0x130 [0.655953] [] ? kernfs_addrm_finish+0x38/0x60 [0.656035] [] kernfs_deactivate+0x10e/0x150 [0.656119] [] ? kernfs_addrm_finish+0x38/0x60 [0.656206] [] kernfs_addrm_finish+0x38/0x60 [0.656290] [] kernfs_remove_by_name_ns+0x58/0xb0 [0.656375] [] remove_files.isra.1+0x41/0x80 [0.656455] [] sysfs_remove_group+0x50/0xb0 [0.656541] [] sysfs_remove_groups+0x3b/0x60 [0.656627] [] device_remove_attrs+0x5b/0x80 [0.656712] [] device_del+0x125/0x1c0 [0.656794] [] device_unregister+0x16/0x30 [0.656876] [] i2c_del_adapter+0x1ba/0x270 [0.656962] [] intel_sdvo_init+0x1f6/0x830 [0.657048] [] ? preempt_count_sub+0xb1/0x100 [0.657134] [] ? _raw_spin_unlock_irqrestore+0x4b/0x80 [0.657220] [] ? gen6_read32+0x63/0x170 [0.657305] [] intel_modeset_init+0xb3d/0x1010 [0.657392] [] ? intel_power_domains_init_hw+0xa9/0x110 [0.657478] [] i915_driver_load+0xd5f/0xeb0 [0.657565] [] drm_dev_register+0x8a/0x190 [0.657649] [] drm_get_pci_dev+0xf9/0x230 [0.657733] [] i915_pci_probe+0x3b/0x60 [0.657818] [] local_pci_probe+0x4e/0xa0 [0.657899] [] ? get_device+0x19/0x20 [0.657982] [] pci_device_probe+0xe1/0x130 [0.658067] [] driver_probe_device+0x7b/0x240 [0.658151] [] __driver_attach+0xab/0xb0 [0.658234] [] ? driver_probe_device+0x240/0x240 [0.658319] [] bus_for_each_dev+0x5e/0x90 [0.658403] [] driver_attach+0x1e/0x20 [0.658487] [] bus_add_driver+0x117/0x230 [0.658570] [] driver_register+0x64/0xf0 [0.658650] [] __pci_register_driver+0x64/0x70 [0.658738] [] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [0.658839] [] drm_pci_init+0x115/0x130 [0.658919] [] ? ftrace_define_fields_drm_vblank_event+0x6d/0x6d [0.659021] [] i915_init+0x6a/0x6c [0.659102] [] do_one_initcall+0x4e/0x170 [0.659187] [] ? parse_args+0xb0/0x360 [0.659270] [] kernel_init_freeable+0x106/0x19a [0.659355] [] ? do_early_param+0x86/0x86 [0.659440] [] ? rest_init+0xd0/0xd0 [0.659521] [] kernel_init+0xe/0x130 [0.659604] [] ret_from_fork+0x7c/0xb0 [0.659685] [] ? rest_init+0xd0/0xd0 [0.745837] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [0.756633] fbcon: inteldrmfb (fb0) is primary device -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
intel_sdvo_init: trying to register non-static key
On Fri, Feb 07, 2014 at 06:47:54PM +0200, Imre Deak wrote: > Ok, not sure why the sdvo initialization fails, but the lockdep > warning is probably fixed by the below patch. Could you try it and > send a dmesg with drm.debug=0xe? Yep, FWIW, the issue is fixed in -rc2, as it got cleared in the other thread that there's a fix for that on its way to Linus. I.e., this one commit da9846ae15186d491d6e21ebbb5051e1d3c7f652 Author: Tejun Heo Date: Wed Jan 29 12:04:03 2014 -0500 kernfs: make kernfs_deactivate() honor KERNFS_LOCKDEP flag Thanks for addressing this issue so quickly! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-) We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack. ... [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at [8800cac3-8800cec2] [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1 0xfed13fff pnp 00:01 [0.490079] [ cut here ] [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [0.490306] Info: mapping multiple BARs. Your kernel is fine. [0.490371] Modules linked in: [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 [0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [0.490742] 00ab 880213d01ad8 816112e3 0006 [0.491032] 880213d01b28 880213d01b18 8104e9bc 880213d01b08 [0.491343] c9c58000 fed1 fed1 6000 [0.491631] Call Trace: [0.493337] [] dump_stack+0x4f/0x7c [0.493420] [] warn_slowpath_common+0x8c/0xc0 [0.493503] [] warn_slowpath_fmt+0x46/0x50 [0.493588] [] __ioremap_caller+0x372/0x380 [0.493674] [] ? snb_uncore_imc_init_box+0x62/0x90 [0.493761] [] ioremap_nocache+0x17/0x20 [0.493846] [] snb_uncore_imc_init_box+0x62/0x90 [0.493933] [] uncore_pci_probe+0xe5/0x1e0 [0.494020] [] local_pci_probe+0x4e/0xa0 [0.494104] [] ? get_device+0x19/0x20 [0.494213] [] pci_device_probe+0xe1/0x130 [0.494300] [] driver_probe_device+0x7b/0x240 [0.494385] [] __driver_attach+0xab/0xb0 [0.494469] [] ? driver_probe_device+0x240/0x240 [0.494551] [] bus_for_each_dev+0x5e/0x90 [0.494634] [] driver_attach+0x1e/0x20 [0.494718] [] bus_add_driver+0x117/0x230 [0.494802] [] driver_register+0x64/0xf0 [0.494884] [] __pci_register_driver+0x64/0x70 [0.494972] [] ? uncore_types_init+0x19c/0x19c [0.495056] [] intel_uncore_init+0x177/0x41c [0.495155] [] ? uncore_types_init+0x19c/0x19c [0.495242] [] do_one_initcall+0x4e/0x170 [0.495326] [] ? parse_args+0x60/0x360 [0.495411] [] kernel_init_freeable+0x106/0x19a [0.495497] [] ? do_early_param+0x86/0x86 [0.495582] [] ? rest_init+0xd0/0xd0 [0.495666] [] kernel_init+0xe/0xf0 [0.495749] [] ret_from_fork+0x7c/0xb0 [0.495831] [] ? rest_init+0xd0/0xd0 [0.495921] ---[ end trace 428f365c054d9a01 ]--- [0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) [0.498833] audit: initializing netlink subsys (disabled) [0.499024] audit: type=2000 audit(1393259866.477:1): initialized ... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
Btw, I don't know whether the following observation is related or not, but it so happens that after resume from suspend-to-disk, I see the booting up of the resume kernel on the console but when it is time for the original kernel to take over and switch to graphics, the screen remains black but the machine is responsive over the network. And this doesn't happen on every resume but only sporadically. And yep, -rc3 was fine. On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote: > This started happening this morning after booting -rc4+tip, let's > add *everybody* to CC :-) > > We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and > other goodies on the stack. > > ... > [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at > [8800cac3-8800cec2] > [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff > 0xfed1 0xfed13fff pnp 00:01 > [0.490079] [ cut here ] > [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 > __ioremap_caller+0x372/0x380() > [0.490306] Info: mapping multiple BARs. Your kernel is fine. > [0.490371] Modules linked in: > [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 > [0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) > 11/13/2012 > [0.490742] 00ab 880213d01ad8 816112e3 > 0006 > [0.491032] 880213d01b28 880213d01b18 8104e9bc > 880213d01b08 > [0.491343] c9c58000 fed1 fed1 > 6000 > [0.491631] Call Trace: > [0.493337] [] dump_stack+0x4f/0x7c > [0.493420] [] warn_slowpath_common+0x8c/0xc0 > [0.493503] [] warn_slowpath_fmt+0x46/0x50 > [0.493588] [] __ioremap_caller+0x372/0x380 > [0.493674] [] ? snb_uncore_imc_init_box+0x62/0x90 > [0.493761] [] ioremap_nocache+0x17/0x20 > [0.493846] [] snb_uncore_imc_init_box+0x62/0x90 > [0.493933] [] uncore_pci_probe+0xe5/0x1e0 > [0.494020] [] local_pci_probe+0x4e/0xa0 > [0.494104] [] ? get_device+0x19/0x20 > [0.494213] [] pci_device_probe+0xe1/0x130 > [0.494300] [] driver_probe_device+0x7b/0x240 > [0.494385] [] __driver_attach+0xab/0xb0 > [0.494469] [] ? driver_probe_device+0x240/0x240 > [0.494551] [] bus_for_each_dev+0x5e/0x90 > [0.494634] [] driver_attach+0x1e/0x20 > [0.494718] [] bus_add_driver+0x117/0x230 > [0.494802] [] driver_register+0x64/0xf0 > [0.494884] [] __pci_register_driver+0x64/0x70 > [0.494972] [] ? uncore_types_init+0x19c/0x19c > [0.495056] [] intel_uncore_init+0x177/0x41c > [0.495155] [] ? uncore_types_init+0x19c/0x19c > [0.495242] [] do_one_initcall+0x4e/0x170 > [0.495326] [] ? parse_args+0x60/0x360 > [0.495411] [] kernel_init_freeable+0x106/0x19a > [0.495497] [] ? do_early_param+0x86/0x86 > [0.495582] [] ? rest_init+0xd0/0xd0 > [0.495666] [] kernel_init+0xe/0xf0 > [0.495749] [] ret_from_fork+0x7c/0xb0 > [0.495831] [] ? rest_init+0xd0/0xd0 > [0.495921] ---[ end trace 428f365c054d9a01 ]--- > [0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 > Joules, 3 fixed counters 163840 ms ovfl timer > [0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) > [0.498833] audit: initializing netlink subsys (disabled) > [0.499024] audit: type=2000 audit(1393259866.477:1): initialized -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote: > I am trying to understand your test case. > Were you actually measure uncore_imc events at the time you suspended? No test case, just the machine booting; look at the printk timestamps. > I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ > (tip.git). I used: echo -n disk >/sys/power/state That's an x230 too, right? What I do is, I take linus/master, merge tip/master, Matt's efi/next tree and my edac/for-next tree into it and then boot that. I don't think that the edac and efi trees interfere though. I'll do a fresh merge of only current tip/master into linus/master to test hpa's suggestion in the other mail. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote: > No, it's a T430s. What happens if you boot vanilla tip.git? linus/master + tip/master -> fails tip/master-> fails All trees are from today, like an hour ago or so. Doing what hpa suggested: diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index b262c6124cf3..ec217d2d28dd 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -3871,6 +3871,7 @@ static int __init uncore_pci_init(void) pci_uncores = snb_pci_uncores; uncore_pci_driver = _uncore_pci_driver; break; +#if 0 case 58: /* Ivy Bridge */ ret = snb_pci2phy_map_init(PCI_DEVICE_ID_INTEL_IVB_IMC); if (ret) @@ -3878,6 +3879,7 @@ static int __init uncore_pci_init(void) pci_uncores = snb_pci_uncores; uncore_pci_driver = _uncore_pci_driver; break; +#endif case 60: /* Haswell */ case 69: /* Haswell Celeron */ ret = snb_pci2phy_map_init(PCI_DEVICE_ID_INTEL_HSW_IMC); for model 58, IVB, works around the issue. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote: > I am on tip.git at cfbf8d4 Linux 3.14-rc4. > and I don't see the problem (using Ubuntu Saucy). Also IVB, model 58? > Given what you commented out, it seems like you're saying > something goes wrong with pci_get_device(). Probably. I'll add some debug printk's tomorrow to shed some more light on the matter. > Am I missing some pm callbacks? Dunno. What do you mean by "pm callbacks" exactly? I don't know that code so I have to ask. > The uncore IMC is not used internally. By IMC I'm assuming this PIC dev: #define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154 ? And "internally" means by BIOS or something behind the curtains like SMM...? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
> > Also IVB, model 58?
> >
> Yes.
Right, so it must be chipset-specific.
> > Dunno. What do you mean by "pm callbacks" exactly? I don't know that
> > code so I have to ask.
> >
> power management callbacks.
Ok, just as I thought. But why would they be relevant if this happens
very early during boot?
> > #define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
> Yes. Needs to point to the DRAM controller.
It seems I have it :-)
$ lspci -xxx -s 00.0
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller
(rev 09)
00: 86 80 54 01 06 00 90 20 09 00 00 06 00 00 00 00
^
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 fa 21
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00
50: 11 02 00 00 11 00 00 00 07 00 90 df 01 00 00 db
60: 05 00 00 f8 00 00 00 00 01 80 d1 fe 00 00 00 00
70: 00 00 00 fe 01 00 00 00 00 0c 00 fe 7f 00 00 00
80: 10 11 11 11 11 11 11 00 1a 00 00 00 00 00 00 00
90: 01 00 00 fe 01 00 00 00 01 00 50 1e 02 00 00 00
a0: 01 00 00 00 02 00 00 00 01 00 60 1e 02 00 00 00
b0: 01 00 a0 db 01 00 80 db 01 00 00 db 01 00 a0 df
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 09 00 0c 01 9b 61 00 e2 d0 00 e8 76 00 00 00 00
f0: 00 00 00 01 00 00 00 00 c8 0f 09 00 00 00 00 00
Anyway, here's some more debugging output and some more staring:
So we're correctly getting 0x154 and then snb_uncore_imc_init_box()
tries to ioremap 0xfed1 but this fails the resource map check with:
[0.485356] resource map sanity check conflict: 0xfed1 0xfed15fff
0xfed1 0xfed13fff pnp 00:01
and the pnp 00:01 device already partially occupies that range (from
/proc/iomem):
fed1-fed13fff : pnp 00:01
Oh, and snb_uncore_imc_init_box() gets that address from
SNB_UNCORE_PCI_IMC_BAR_OFFSET and SNB_UNCORE_PCI_IMC_BAR_OFFSET+4 and
they start at offset 0x48 in the PCI config space above, i.e.
40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00
^^^
which is 0x00fed10001 (the 0x1 bit disappears after addr &= ~(PAGE_SIZE -
1);)
So I'm guessing it is time to talk to platform guys and ask them why
they're putting SNB_UNCORE_PCI_IMC_BAR_OFFSET{,+4} in an overlapping
range with pnp 00:01.
[0.484023] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[0.484108] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at
[8800cac3-8800cec2]
[0.484971] DBG: will get device: 0x8086:154
[0.485054] DBG: Got device, bus: 0x0
[0.485254] DBG: ioremapping addr: 0xfed1
[0.485356] resource map sanity check conflict: 0xfed1 0xfed15fff
0xfed1 0xfed13fff pnp 00:01
[0.485460] [ cut here ]
[0.485544] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x372/0x380()
[0.485643] Info: mapping multiple BARs. Your kernel is fine.
[0.485709] Modules linked in:
[0.485935] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #6
[0.486019] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 )
11/13/2012
[0.486117] 00ab 880213d01ad8 81611339
0006
[0.486411] 880213d01b28 880213d01b18 8104e9cc
880213d01b08
[0.488308] c9c58000 fed1 fed1
6000
[0.488595] Call Trace:
[0.488671] [] dump_stack+0x4f/0x7c
[0.488754] [] warn_slowpath_common+0x8c/0xc0
[0.488877] [] warn_slowpath_fmt+0x46/0x50
[0.488966] [] __ioremap_caller+0x372/0x380
[0.489052] [] ? snb_uncore_imc_init_box+0x76/0xa0
[0.489137] [] ioremap_nocache+0x17/0x20
[0.489221] [] snb_uncore_imc_init_box+0x76/0xa0
[0.489307] [] uncore_pci_probe+0xe5/0x1e0
[0.489391] [] local_pci_probe+0x4e/0xa0
[0.489474] [] ? get_device+0x19/0x20
[0.489558] [] pci_device_probe+0xe1/0x130
[0.489642] [] driver_probe_device+0x7b/0x240
[0.489726] [] __driver_attach+0xab/0xb0
[0.489834] [] ? driver_probe_device+0x240/0x240
[0.489920] [] bus_for_each_dev+0x5e/0x90
[0.490003] [] driver_attach+0x1e/0x20
[0.490086] [] bus_add_driver+0x117/0x230
[0.490170] [] driver_register+0x64/0xf0
[0.490251] [] __pci_register_driver+0x64/0x70
[0.490337] [] ? uncore_types_init+0x19c/0x19c
[0.490421] [] intel_uncore_init+0x196/0x462
[0.490504] [] ? uncore_types_init+0x19c/0x19c
[0.490591] [] do_one_initcall+0x4e/0x170
[0.490676] [] ? parse_args+0x50/0x360
[0.490762] [] kernel_init_freeable+0x106/0x19a
[0.490863] [] ? do_early_param+0x86/0x86
[0.490948] [] ? rest_init+0xd0/0xd0
[0.491032] [] kernel_init+0xe/0xf0
[0.491116] [] ret_from_fork+0x7c/0xb0
[0.491199] [] ? rest_init+0xd0/0xd0
[0.491289] ---[ end trace b31a7f760e34b24a
Info: mapping multiple BARs. Your kernel is fine.
Can you please, pretty please, not top-post... On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote: > Hi, > > Ok, so I am getting the same error message as you. > I checked my syslog now. > > I have my uncore_imc addr=0xfed1 (after masking) > > And I also have pnp 00:01 overlapping the imc range completely. > > What pnp device does it really represent? the DRAM controller? > > So I think my laptop behaves like yours. grep -Er . /sys/devices/pnp0/00\:01/* 2>/dev/null /sys/devices/pnp0/00:01/firmware_node/hid:PNP0C02 ... so this PNP0C02 is [0.363943] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) @Rafael, can you please make sense of this whole ACPI gunk? We have a resource conflict with pnp 00:01, analysis here: http://lkml.kernel.org/r/20140226092903.GA22639 at pd.tnic This is the rest of the 00:01 info from sysfs: /sys/devices/pnp0/00:01/firmware_node/uid:0 /sys/devices/pnp0/00:01/firmware_node/path:\_SB_.PCI0.LPC_.SIO_ /sys/devices/pnp0/00:01/firmware_node/power/control:auto /sys/devices/pnp0/00:01/firmware_node/power/runtime_active_time:0 /sys/devices/pnp0/00:01/firmware_node/power/runtime_status:unsupported /sys/devices/pnp0/00:01/firmware_node/power/runtime_suspended_time:0 /sys/devices/pnp0/00:01/firmware_node/modalias:acpi:PNP0C02: /sys/devices/pnp0/00:01/firmware_node/uevent:MODALIAS=acpi:PNP0C02: /sys/devices/pnp0/00:01/id:PNP0c02 /sys/devices/pnp0/00:01/power/control:auto /sys/devices/pnp0/00:01/power/runtime_active_time:0 /sys/devices/pnp0/00:01/power/runtime_status:unsupported /sys/devices/pnp0/00:01/power/runtime_suspended_time:0 /sys/devices/pnp0/00:01/resources:state = active /sys/devices/pnp0/00:01/resources:io 0x10-0x1f /sys/devices/pnp0/00:01/resources:io 0x90-0x9f /sys/devices/pnp0/00:01/resources:io 0x24-0x25 /sys/devices/pnp0/00:01/resources:io 0x28-0x29 /sys/devices/pnp0/00:01/resources:io 0x2c-0x2d /sys/devices/pnp0/00:01/resources:io 0x30-0x31 /sys/devices/pnp0/00:01/resources:io 0x34-0x35 /sys/devices/pnp0/00:01/resources:io 0x38-0x39 /sys/devices/pnp0/00:01/resources:io 0x3c-0x3d /sys/devices/pnp0/00:01/resources:io 0xa4-0xa5 /sys/devices/pnp0/00:01/resources:io 0xa8-0xa9 /sys/devices/pnp0/00:01/resources:io 0xac-0xad /sys/devices/pnp0/00:01/resources:io 0xb0-0xb5 /sys/devices/pnp0/00:01/resources:io 0xb8-0xb9 /sys/devices/pnp0/00:01/resources:io 0xbc-0xbd /sys/devices/pnp0/00:01/resources:io 0x50-0x53 /sys/devices/pnp0/00:01/resources:io 0x72-0x77 /sys/devices/pnp0/00:01/resources:io 0x400-0x47f /sys/devices/pnp0/00:01/resources:io 0x500-0x57f /sys/devices/pnp0/00:01/resources:io 0x800-0x80f /sys/devices/pnp0/00:01/resources:io 0x15e0-0x15ef /sys/devices/pnp0/00:01/resources:io 0x1600-0x167f /sys/devices/pnp0/00:01/resources:mem 0xf800-0xfbff /sys/devices/pnp0/00:01/resources:mem 0xf000-0x /sys/devices/pnp0/00:01/resources:mem 0xfed1c000-0xfed1 /sys/devices/pnp0/00:01/resources:mem 0xfed1-0xfed13fff /sys/devices/pnp0/00:01/resources:mem 0xfed18000-0xfed18fff /sys/devices/pnp0/00:01/resources:mem 0xfed19000-0xfed19fff /sys/devices/pnp0/00:01/resources:mem 0xfed45000-0xfed4bfff /sys/devices/pnp0/00:01/resources:mem 0xfed4-0xfed44fff /sys/devices/pnp0/00:01/subsystem/drivers_autoprobe:1 /sys/devices/pnp0/00:01/uevent:DRIVER=system -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote: > On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote: > > This started happening this morning after booting -rc4+tip, let's > > add *everybody* to CC :-) > > What about -rc4 without tip? I don't think so because commit b9e1ab6d4c0582cad97699285a6b3cf992251b00 Author: Stephane Eranian Date: Tue Feb 11 16:20:12 2014 +0100 perf/x86/uncore: add SNB/IVB/HSW client uncore memory controller support in -tip introduces that snb_uncore_imc_init_box() thing which causes the ioremap conflict. Btw, see my last email on this thread for more details about what I'm seeing here. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Info: mapping multiple BARs. Your kernel is fine.
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and > there to BAR is at a completely different address. Same thing on my > Haswell desktop system. Hrrm, I'd like to see what Rafael finds out, whether what we're reading from PCI config space is even sane. > As a asides, my SNB and HSW desktops with 3.14-rc4 are totally > unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 > is stable. I am not so sure this is all related to the uncore IMC > support, though. Easy to test - just disable the uncore thing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
