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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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.
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
...@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
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
...@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
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
[ 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
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
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
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
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
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
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
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
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
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]
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
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
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
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
+ 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.
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
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
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
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
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
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
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
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
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
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
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.
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?
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
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.
[
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
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,
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 :(
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
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,
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' maste
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:
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
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
>
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,
---
>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 Pet
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
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
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.
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
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.
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 e
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).
$
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)
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
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 =
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
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 +-
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
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,
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.
>
>
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 "
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
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,
> +
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...
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
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:
> > >
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
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
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]
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:
>
>
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
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
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
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*
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
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
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().
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
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
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 d
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
1 - 100 of 292 matches
Mail list logo
