On Wed, Nov 28, 2012 at 05:27:45AM -0800, Denis Lotarev wrote:
> Im using kernel (Linux initbox 3.6.7-1-ARCH #1 SMP PREEMPT Sun Nov 18
> 10:11:22 CET 2012 x86_64 GNU/Linux) and i see some problems at booting... So
> dmesg output with BUG lines:
>
> $ dmesg |grep Bug
> [1.363154] [Firmware Bu
On Wed, Nov 28, 2012 at 11:50:25AM -0800, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
> code.
This commit message should say something about XADD and not about
CMPXCHG, right?
--
Regards/Gruss,
Boris.
--
To unsubscrib
On Wed, Nov 28, 2012 at 11:50:30AM -0800, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> Simplify the implementation of sync_core() for the case where we may
> not have the CPUID instruction available.
>
> Signed-off-by: H. Peter Anvin
> ---
> arch/x86/include/asm/processor.h | 27
On Wed, Nov 28, 2012 at 04:14:43PM -0800, H. Peter Anvin wrote:
> Wrong barrier semantics.
Let me try to understand what you mean by that :)
Now, your version's asm output looks like this:
.loc 2 95 0
movl$139, %esi #, tmp140
xorl%eax, %eax # tmp141
On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
> Hi,
>
> Due to unexplained dns problems, I'll be using google plus to post the
> photo of the bug output.
>
> https://plus.google.com/photos/110698868656495230656/albums/5816005854482735041
>
> I'm sorry but my knowledge is limited
On Tue, Nov 27, 2012 at 02:32:11PM +0800, Daniel J Blueman wrote:
> Fix locating sibling memory controller PCI functions by using the
> correct PCI domain.
>
> v7: Refactor patches grouping changes
>
> Signed-off-by: Daniel J Blueman
> ---
> drivers/edac/amd64_edac.c | 40
On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
> I think that chrome does traceing all the time as a part of it's
> sandbox - this is most likely chrome monitoring flash...
Ah, ok.
> BUG: unable to handle kernel NULL pointer dereference at
> 0063
> IP: [] syscall_trace_e
On Tue, Nov 27, 2012 at 02:32:12PM +0800, Daniel J Blueman wrote:
> Use appropriate types for northbridge IDs and memory ranges.
>
> v7: Refactor patches grouping changes
>
> Signed-off-by: Daniel J Blueman
> ---
> arch/x86/include/asm/amd_nb.h |2 +-
> drivers/edac/amd64_edac.c | 20
On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
> > Can you do:
> >
> > make arch/x86/kernel/ptrace.lst
> >
> > and send me that file, privately is fine too.
>
> Done, =)
Ok, thanks. Here it is:
8100b627: 83 3f 00cmpl $0x0,(%rdi)
8100b62a:
On Thu, Nov 29, 2012 at 01:06:20PM -0800, H. Peter Anvin wrote:
> It doesn't matter in that context, as the surrounding MSR references
> have barriers, but what I'm refering to is the "memory" barrier.
Ok, but the only difference between the two versions is this line:
movl%esi, %ecx
On Thu, Nov 29, 2012 at 01:20:00PM -0800, H. Peter Anvin wrote:
> On 11/29/2012 01:18 PM, Borislav Petkov wrote:
> > On Thu, Nov 29, 2012 at 01:06:20PM -0800, H. Peter Anvin wrote:
> >> It doesn't matter in that context, as the surrounding MSR references
> >> have
On Thu, Nov 29, 2012 at 01:24:26PM -0800, H. Peter Anvin wrote:
> Thinking about it some more, there is another reason to not do
> this, which is that we don't want this particular CPUID to be
> paravirtualized; we're after the synchronizing side effect, not the
> CPUID return value itself.
Ok, yo
On Fri, Nov 30, 2012 at 12:56:08AM +0100, Ian Kumlien wrote:
> > From looking at the code, task audit contexts get normally allocated
> > at fork time and dealloc'd at task exit time so your process should
> > actually have a valid task context.
>
> Weird, and this should be allocated automaticall
Hi,
On Mon, Mar 18, 2013 at 06:13:58PM +0900, Namhyung Kim wrote:
> > -static void ring_buffer_put(struct ring_buffer *rb)
> > +void perf_ring_buffer_put(struct ring_buffer *rb)
>
> Why did you rename this function?
Yeah, actually that's not needed.
However, the perf ring buffer function naming
On Mon, Mar 18, 2013 at 09:40:08AM +0100, Ingo Molnar wrote:
> That definitely looks interesting and desirable. It would be nice to
> have more generic/flexible semantics by using the VFS for tracing
> context discovery.
>
> That would allow 'stateful tracing', and not just in a kernel
> initiated
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
+ Tony.
On Wed, Mar 20, 2013 at 03:31:29PM +0530, Srivatsa S. Bhat wrote:
> On 03/20/2013 08:46 AM, Chen Gong wrote:
> > On Tue, Mar 19, 2013 at 06:44:08PM -0400, Dave Jones wrote:
> >>
> >> offlining a CPU in 3.9-rc3 gets me this trace..
> >>
> >> numa_remove_cpu cpu 1 node 0: mask now 0,2-3
> >>
Hi,
when trying to log stuff with netconsole, I get the following:
[ … ]
[2.036977] netpoll: netconsole: device eth0 not up yet, forcing it
[2.037632] forcedeth :00:08.0: irq 42 for MSI/MSI-X
[2.037763] forcedeth :00:08.0 eth0: MSI enabled
[2.038074] forcedeth :00:08.
On Wed, Mar 20, 2013 at 12:01:51PM +0100, Borislav Petkov wrote:
> Hi,
>
> when trying to log stuff with netconsole, I get the following:
>
> [ … ]
>
> [2.036977] netpoll: netconsole: device eth0 not up yet, forcing it
> [2.037632] forcedeth :00:08
From: Borislav Petkov
Hi,
this is v2, with some added functionality in patches 5 and 6. It all
looks pretty straight-forward and testing it in kvm (even with lying to
the guest it is running on a Cyrix) works, as well as on bare metal.
Comments and suggestions appreciated,
Thanks.
Borislav
From: Borislav Petkov
... to using the new facility and drop the cpuinfo_x86 member.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 2 ++
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/intel.c | 4 ++--
arch/x86/kernel/cpu/proc.c| 2 +-
arch
From: Borislav Petkov
Convert AMD erratum 400 to the bug infrastructure. Then, retract all
exports for modules since they're not needed now and make the AMD
erratum checking machinery local to amd.c. Use forward declarations to
avoid shuffling too much code around needlessly.
Signed-o
From: Borislav Petkov
... to the new facility. Add a reference to the wikipedia article
explaining the FDIV test we're doing here.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/bugs.c
From: Borislav Petkov
Convert the AMD erratum 383 testing code to the bug infrastructure. This
allows keeping the AMD-specific erratum testing machinery private to
amd.c and not export symbols to modules needlessly.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1
From: Borislav Petkov
... to the new facility.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/cyrix.c | 5 +++--
arch/x86/kernel/cpu/proc.c| 2 +-
4 files changed, 5 insertions(+), 4
From: Borislav Petkov
We add another 32-bit vector at the end of the ->x86_capability
bitvector which collects bugs present in CPUs. After all, a CPU bug is a
kind of a capability, albeit a strange one.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h |
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 wron
On Wed, Mar 20, 2013 at 11:10:58AM -0400, Rob Edwards wrote:
> I posted a question at
> http://www.dslreports.com/forum/r28112391-AMD-A6-3650-getting-Kernel-Panics-
> in-Ubuntu-12.10- looking for help with my Ubuntu machine and some strange
> kernel panics I have been getting and was directed here
Hi Andrew,
On Thu, Feb 28, 2013 at 04:39:53PM -0500, Joern Engel wrote:
> Blockconsole is a console driver very roughly similar to netconsole.
> Instead of sending messages out via UDP, they are written to a block
> device. Typically a USB stick is chosen, although in principle any
> block device
On Wed, Mar 20, 2013 at 07:22:59PM -0700, Paul E. McKenney wrote:
> > > > > The "full_nohz=" boot parameter specifies which CPUs are to be
> > > > > adaptive-ticks CPUs. For example, "full_nohz=1,6-8" says that CPUs 1,
> > > >
> > > > This is the first time you mention "adaptive-ticks". Probably
On Thu, Mar 21, 2013 at 08:18:11AM -0700, Paul E. McKenney wrote:
> Actually, this is a generic transformation. Given an English verb,
> you almost always add "ing" to create a noun. Since "round-robin" is
> used as a verb,
... which sounds, in this case, weird IMHO. :-)
> as in "The scheduler wi
On Sun, Feb 03, 2013 at 12:04:46AM +0100, Rafael J. Wysocki wrote:
> The [2/5] is at: https://patchwork.kernel.org/patch/2001211/
>
> The other two are attached. I suppose the ordering doesn't matter.
Ok, the eth link cable hotplugging issue seems fixed, plugging and
unplugging the cable works a
From: Borislav Petkov
Hi,
here are some initial low-hanging fruits wrt head_32.S cleanup. I've
made them as easily digestible as possible; after all, this is boot asm
and meddling with it tends to upset kernels.
Also, I've made the assumption that having boot_cpu_data.cpuid_level
c
From: Borislav Petkov
Remove code fragments detecting a 386 CPU since we don't support those
anymore. Also, do not do alignment checks because they're done only at
CPL3. Also, no need to preserve EFLAGS.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head
From: Borislav Petkov
We do that once earlier now and cache it into boot_cpu_data.cpuid_level
so no need for the EFLAGS.ID toggling dance anymore.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 40 +++-
1 file changed, 7 insertions(+), 33
From: Borislav Petkov
We copy it to boot_cpu_data anyway so use boot_cpu_data from the get-go.
Cc: Rusty Russell
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/head_32.S| 17 -
arch/x86/kernel
From: Borislav Petkov
We detect CPUID function support on the boot CPU and save it for later
use, obviating the need to play the toggle EFLAGS.ID game every time. C
code is looking at ->cpuid_level anyway.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S |
On Sun, Feb 03, 2013 at 09:15:12PM +0100, Rafael J. Wysocki wrote:
> Is suspend-to-RAM triggering that as too?
Nope, not really. But, just to confirm: s2r is
echo "shutdown" > /sys/power/disk
echo "mem" > /sys/power/state
right?
Btw, this bug is very strange. So I did a couple more s2disk runs,
On Sun, Feb 03, 2013 at 09:58:57PM +0100, Borislav Petkov wrote:
> and it seemed to me that when the eth cable is plugged in, it would
> suspend and resume fine. When I then boot, unplug the cable, set all
> tunables to "Good", suspend to disk and resume, no NMI message. When
On Sun, Feb 03, 2013 at 10:06:45PM +0100, Borislav Petkov wrote:
> On Sun, Feb 03, 2013 at 09:58:57PM +0100, Borislav Petkov wrote:
> > and it seemed to me that when the eth cable is plugged in, it would
> > suspend and resume fine. When I then boot, unplug the cable, set all
> &
On Sun, Feb 03, 2013 at 03:44:29PM -0800, H. Peter Anvin wrote:
> On 02/03/2013 08:14 AM, Borislav Petkov wrote:
> >From: Borislav Petkov
> >
> >We copy it to boot_cpu_data anyway so use boot_cpu_data from the get-go.
> >
>
> Hmm... this is the only part
On Sun, Feb 03, 2013 at 09:44:02PM -0800, H. Peter Anvin wrote:
> boot_cpu_data is ok for things that are indeed universally valid
> across. That does not include CPUID level, for one.
Wait a minute, hold the phone! :-)
Are you saying that CPUID_EAX(0) could return different values in %eax
on the
From: Borislav Petkov
I've been getting the following warning when doing randbuilds since
forever. Now it finally pissed me off just the perfect amount so that I
can fix it.
arch/x86/kernel/cpu/intel_cacheinfo.c:489:27: warning: ‘cache_disable_0’
defined but not used [-Wunused-variable]
From: Borislav Petkov
Check whether both executables are present on the system before
continuing with the build instead of failing halfway, if either are
missing.
Signed-off-by: Borislav Petkov
---
tools/perf/Makefile | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff
On Mon, Feb 04, 2013 at 05:54:18PM +0530, Viresh Kumar wrote:
> One important point i would like to highlight is: governors directory
> would be present in cpu/cpu*/cpufreq/ now instead of cpu/cpufreq/.
Uh, hold on, isn't this breaking a bunch of userspace with this move?
Also, on all those other
On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote:
> That's why i am highlighting it again and again. :)
Ah, see, someone caught up with it :).
> What i believe is, the place where this directory was present earlier
> (cpu/cpufreq/) wasn't the right place. Everything else was in
> cpu
On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
> That's not completely true. There lies cpufreq directory in cpu/cpu*/
> too, where we have per policy stuff in cpu/cpu*/, like policy tunables
> and stats. And the same is true for governor too.
$ tree /sys/devices/system/cpu/cpu0/cpu
On Mon, Feb 04, 2013 at 08:50:33AM -0500, Rik van Riel wrote:
> We need to know whether we are actually running on top of a
> hypervisor, not whether we have the code compiled in to do so.
Oh ok, I see.
The thing is, if CONFIG_PARAVIRT_GUEST is disabled, x86_hyper won't
exist, see: http://marc.in
On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
> All files which are directly present in cpu/cpu*/cpufreq/ folder. I am
> not talking about governor tunables but policy tunables. Things like
> scaling_[min]max_freq are policy tunables.
No, on x86 those are the P-states frequencies.
On Mon, Feb 04, 2013 at 07:51:33PM +0530, Viresh Kumar wrote:
> We correlate things with cpus rather than policies and so the current
> directory structure of cpu/cpu*/cpufreq/*** is the best suited ones.
Ok, show me the details of that layout. How is that going to look?
One thing I've come to re
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_AC
On Mon, Feb 04, 2013 at 09:07:11PM +0530, Viresh Kumar wrote:
> I don't have board right now to take the snapshot, but it would be
> like:
>
> $ tree /sys/devices/system/cpu/cpu0/cpufreq/
> /sys/devices/system/cpu/cpu0/cpufreq/
> ├── affected_cpus
> ├── bios_limit
> ├── cpb
> ├── cpuinfo_cur_freq
On Mon, Feb 04, 2013 at 08:55:17AM -0800, H. Peter Anvin wrote:
> Yes and yes (in the latter case due to inconsistent MSR programming.)
Ok, I'll drop the last one, redo 2/4 and run them on the hardware I have
here.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Forma
On Tue, Feb 05, 2013 at 12:50:31PM +0530, Viresh Kumar wrote:
> > I think this is cleaner but whatever - I don't care that much. My
> > only strong concern is that this thing should be a Kconfig option and
> > optional for arches where it doesn't apply.
>
> Your concern is: we don't want to fix us
On Tue, Feb 05, 2013 at 03:17:21PM +0530, Viresh Kumar wrote:
> > multiple policies support in cpufreq should be optional and
> > selectable in Kconfig so that systems which don't need that, don't
> > have to see or use it. It is yet another feature which doesn't apply
> > universally so we make su
On Tue, Feb 05, 2013 at 04:13:23PM +0530, Viresh Kumar wrote:
> There isn't lot of code that we have to keep inside the macro you
> suggest. Its just an if else (with single line block), which would
> give the parent kobject. Nothing else.
>
> I didn't wanted to create a macro for just that. For me
On Tue, Feb 05, 2013 at 04:42:23PM +0530, Viresh Kumar wrote:
> Tricky part is the name of this routine: add_additional_sysfs_entries().
Now you're just being silly - this is just an example how to do it. If
you want me to do it for ya, you need to send me your monthly salary.
> And so, keeping t
On Tue, Feb 05, 2013 at 04:56:03PM +0530, Viresh Kumar wrote:
> Just some kind of indication from platform driver is required about
> how/where it wants its governor directory to be present.
The indication is this:
config CPUFREQ_PLATFORM_DRIVER_X
...
select CPUFREQ_MULTIPLE_POLIC
On Tue, Feb 05, 2013 at 11:29:04AM +, Charles Garcia-Tobin wrote:
> Actually shooting myself in the foot here, Krait is not such a great
> example because although you can use difference between frequencies
> you are less likely to use different tunables (not inconceivable
> but unlikely). The
On Tue, Feb 05, 2013 at 05:54:57PM +0530, Viresh Kumar wrote:q
> This indication isn't enough. On a single image solution, we need to
> identify the system which needs support for multiple policies and i
> still feel we need that variable type indication :)
If the image is going to run also on sys
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?
> >
> > driv
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
Yep, this takes care of all deps,
Tested-by: Borislav Petkov
Thanks.
--
Regards/Gruss,
B
On Tue, Feb 05, 2013 at 06:38:07PM +, Charles Garcia-Tobin wrote:
> Later. Whatever you'd like to call it, but essentially a set of cpus,
> as linux understands them, that are logically related by the fact that
> you'd like to be able to use the same tuning policy and same governor
> across all
On Fri, Feb 08, 2013 at 02:30:52PM -0800, H. Peter Anvin wrote:
> Also, keep in mind that there is a very simple way to deny MSR access
> completely, which is to not include the driver in your kernel (and not
> allow module loading, but if you can load modules you can just load a
> module to muck w
On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote:
> Also, _reading_ MSRs from userspace arguably has utility that doesn't
> compromise ring-0.
And to come back to the original question: what is that utility, who
would need it on a secure boot system and why?
--
Regards/Gruss,
Boris.
On Fri, Feb 08, 2013 at 12:28:13PM -0800, Dave Hansen wrote:
>
> Boris, could you check that this series also fixes the /dev/mem
> problem you were seeing?
>
> --
>
> We have a new debugging check on x86 that has caught a number
> of long-standing bugs. However, there is a _bit_ of collateral
>
On Fri, Feb 08, 2013 at 11:08:52AM -0800, H. Peter Anvin wrote:
> Yes, or anything else getting a pointer in memory from user space.
Here are some more from a 32-bit build here:
fs/exec.c: In function ‘get_user_arg_ptr’:
fs/exec.c:414:6: warning: cast to pointer from integer of different size
[-
On Sat, Feb 09, 2013 at 10:41:21AM +0100, Borislav Petkov wrote:
> > +static inline bool phys_addr_is_highmem(phys_addr_t addr)
> > +{
> > + return addr > last_lowmem_paddr();
>
> I think you mean last_lowmem_phys_addr() here:
>
> include/linux/mm.h:
From: Borislav Petkov
Ok,
here's the next version with new_cpu_data left put and two minor fixlets
added at the end. The patchset was boot-tested on a bunch of baremetal
boxes and all QEMU cpu models - no issues.
Boot tests:
* baremetal:
- P4
- Atom n270
- 32-bit kernel on an AMD64
From: Borislav Petkov
We do that once earlier now and cache it into new_cpu_data.cpuid_level
so no need for the EFLAGS.ID toggling dance anymore.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a
From: Borislav Petkov
Jumping here we are about to enable paging so rename the label
accordingly.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
From: Borislav Petkov
gcc2 wants direction flag cleared but we don't support gcc2 anymore. So
drop it. Original patch adding this was:
commit 57d40092c375d2b6d34f814f5fb306967e22c4f5
Author: linus1
Date: Mon Nov 9 12:00:00 1992 -0600
[PATCH] Linux-0.98.4 (November 9, 1992)
...
S
From: Borislav Petkov
We detect CPUID function support on each CPU and save it for later use,
obviating the need to play the toggle EFLAGS.ID game every time. C code
is looking at ->cpuid_level anyway.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S |
From: Borislav Petkov
Remove code fragments detecting a 386 CPU since we don't support those
anymore. Also, do not do alignment checks because they're done only at
CPL3. Also, no need to preserve EFLAGS.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head
On Sat, Feb 09, 2013 at 12:52:01PM -0800, H. Peter Anvin wrote:
> However... DF should have been cleared long before this...
How about we do this at the beginning of default_entry where we clear
EFLAGS too:
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index fc56613224c3..8b2
From: Borislav Petkov
All GCC versions expect the direction flag to be cleared (DF=0) so move
this to the default entry point for each core.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel
On Sat, Feb 09, 2013 at 02:23:36PM -0800, H. Peter Anvin wrote:
> The pushfl/popfl sequence clears DF too...
Yes, indeed, good realization!
Ok, I'll fold that fact as a comment into the 2/5 patch resend it only
as a reply to this mail so as not to spam unnecessarily.
Thanks.
--
Regards/Gruss,
From: Borislav Petkov
We detect CPUID function support on each CPU and save it for later use,
obviating the need to play the toggle EFLAGS.ID game every time. C code
is looking at ->cpuid_level anyway.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S |
On Sat, Feb 09, 2013 at 08:34:53PM -0800, H. Peter Anvin wrote:
> I wouldn't really call it a "side effect". Perhaps the right thing
> here is to say something like "we want to start out with %eflags
> unambiguously clear".
>
> (Note also we have had to CLD earlier because we have already copied
>
On Sun, Feb 10, 2013 at 04:37:27PM -0500, Len Brown wrote:
> From: Len Brown
>
> Remove 32-bit x86 a cmdline param "no-hlt",
> and the cpuinfo_x86.hlt_works_ok that it sets.
>
> If a user wants to avoid HLT, then "idle=poll"
> is much more useful, as it avoids invocation of HLT
> in idle, while
From: Borislav Petkov
Hi,
so this is a rough first version to collect some initial comments. It is
lightly tested in kvm.
Thanks.
Borislav Petkov (4):
x86, cpu: Expand cpufeature facility to include cpu bugs
x86, cpu: Convert F00F bug detection
x86, cpu: Convert FDIV bug detection
x86
From: Borislav Petkov
... to using the new facility and drop the cpuinfo_x86 member.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 2 ++
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/intel.c | 4 ++--
arch/x86/kernel/cpu/proc.c| 2 +-
arch
From: Borislav Petkov
... to the new facility.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/bugs.c| 5 +++--
arch/x86/kernel/cpu/proc.c| 2 +-
4 files changed, 5 insertions(+), 4
From: Borislav Petkov
We add another 32-bit vector at the end of the ->x86_capability
bitvector which collects bugs present in CPUs. After all, a CPU bug is a
kind of a capability, albeit a strange one.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h |
From: Borislav Petkov
... to the new facility. Drop the padding too since it becomes
unnecessary now.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/processor.h | 2 --
arch/x86/kernel/cpu/cyrix.c | 5 +++--
arch/x86/kernel/cpu/proc.c
From: Borislav Petkov
Hi,
this is the new version with patch 5 from the old transformed into an
expanded, more verbose comment at the beginning of default_entry. No
changes otherwise.
Changelog:
v2:
Here's the next version with new_cpu_data left put and two minor fixlets
added at th
From: Borislav Petkov
We detect CPUID function support on each CPU and save it for later use,
obviating the need to play the toggle EFLAGS.ID game every time. C code
is looking at ->cpuid_level anyway.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S |
From: Borislav Petkov
Jumping here we are about to enable paging so rename the label
accordingly.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
From: Borislav Petkov
We do that once earlier now and cache it into new_cpu_data.cpuid_level
so no need for the EFLAGS.ID toggling dance anymore.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a
From: Borislav Petkov
Remove code fragments detecting a 386 CPU since we don't support those
anymore. Also, do not do alignment checks because they're done only at
CPL3. Also, no need to preserve EFLAGS.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head
On Tue, Jan 08, 2013 at 03:08:07AM +0100, Frederic Weisbecker wrote:
[ … ]
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 8601f0d..dc6381d 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -70,6 +70,15 @@ config NO_HZ
> only trigger on an as-needed basi
On Mon, Feb 11, 2013 at 07:49:14AM -0800, H. Peter Anvin wrote:
> What about CPUs with inconsistent cpuid levels? Yes, they can and do
> happen, as we discussed on IRC.
Yes, this should still work. We're doing the EFLAGS.ID dance right at
the beginning of default_entry on each cpu and cache cpuld
On Mon, Feb 11, 2013 at 09:32:41AM -0800, Dave Hansen wrote:
> That's crazy. Didn't expect that at all.
>
> I guess X is happier getting an error than getting random pages back.
Yeah, I think this is something special only this window manager wdm
does. The line below has appeared repeatedly in the
On Mon, Feb 11, 2013 at 11:44:12AM -0800, H. Peter Anvin wrote:
> Oh, craptastic. X used to hash /dev/mem to get a random seed. It
> should have stopped that long ago, and used /dev/[u]random.
That's because debian still has this WINGs window manager which hasn't
seen any new releases since 2005:
On Mon, Feb 11, 2013 at 02:46:43PM -0800, H. Peter Anvin wrote:
> The X server itself used to do that. Are you saying that wdm is a
> *privileged process*?
Nah, it is a simple display manager you start with /etc/init.d/wdm init
script. Like the other display managers gdm, kdm, etc.
But it looks l
Two issues I got with this one, see below.
On Thu, Jan 31, 2013 at 02:45:06PM -0800, tip-bot for Boris Ostrovsky wrote:
> Commit-ID: f0322bd341fd63261527bf84afd3272bcc2e8dd3
> Gitweb: http://git.kernel.org/tip/f0322bd341fd63261527bf84afd3272bcc2e8dd3
> Author: Boris Ostrovsky
> AuthorDat
On Tue, Feb 12, 2013 at 04:21:13PM -0800, H. Peter Anvin wrote:
> On 02/12/2013 04:16 PM, Borislav Petkov wrote:
> >
> >This family check is redundant, we're already in a 0x10 if-branch
> >above. Boris had sent a second version which doesn't have that check:
> &
From: Borislav Petkov
It should be "governor".
Signed-off-by: Borislav Petkov
---
drivers/cpufreq/cpufreq_governor.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index 51
On Thu, Mar 28, 2013 at 01:24:16PM -0500, Jacob Shin wrote:
> This allows for another [arch specific] driver to hook into existing
> powersave bias function of the ondemand governor. i.e. This allows AMD
> specific powersave bias function (in a separate AMD specific driver)
> to aid ondemand govern
On Tue, Apr 02, 2013 at 01:40:13PM +0200, Thomas Renninger wrote:
> On Thursday, March 28, 2013 01:24:17 PM Jacob Shin wrote:
> > Future AMD processors, starting with Family 16h, can provide software
> > with feedback on how the workload may respond to frequency change --
> > memory-bound workloads
1 - 100 of 13227 matches
Mail list logo
