We will add one 64bit entry for bzImage in boot header struct.
the contents in that field will be offset of startup_64.
Add macro for offset of startup_64 to keep two places consistent.
Signed-off-by: Yinghai Lu
Cc: Matt Fleming
---
arch/x86/boot/compressed/head_64.S |2 +-
Current kernel is not allowed to be loaded above 512g, it thinks
that address is too big.
We only need to add one extra spare page for needed level3 to
point another 512g range.
Need to check _text range and set level4 pg to point to that spare
level3 page, and set level3 to point to level2 page
They are the same, could move them out from head32/64.c to setup.c.
We are using memblock, and it could handle overlapping properly, so
we don't need to reserve some at first to hold the location, and just
need to make sure we reserve them before we are using memblock to find
free mem to use.
Current when kernel is loaded above 1G, only [_text, _text+2M]
is set up with extra ident page table.
That is not enough, some variables that could be used early are
out of that range. (like gdt...)
Just set map for [_text, _end] include text/data/bss/brk...
Signed-off-by: Yinghai Lu
Cc: "Eric
At that stage, it is already in 32bit protected mode or 64bit mode.
so we do not need to check if ptr less 1M.
When go from other boot loader (kexec) instead of boot/ code path.
Move out accessible checking out __cmdline_find_option
So misc.c will parse cmdline and have debug print out.
boot/compressed/misc.c could be with 64 bit, and cmd_line_ptr could
above 4g.
So change to unsigned long instead. that will be 64bit in 64bit,
and 32bit in 32bit.
Signed-off-by: Yinghai Lu
---
arch/x86/boot/boot.h|8
arch/x86/boot/cmdline.c |4 ++--
2 files changed, 6
later will check ext_cmd_line_ptr at the same time.
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/cmdline.c | 10 --
arch/x86/kernel/head64.c | 13 +++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/x86/boot/compressed/cmdline.c
When 64bit bootloader put real mode data above 4g, We can not
access real mode data directly.
because in arch/x86/kernel/head_64.S, only set ident mapping
for 0-1g, and kernel code/data/bss.
So need to move early_ioremap_init() calling from setup_arch
to x86_64_start_kernel.
Also use rsi/rdi
We are short of space before 0x200 that is entry for startup_64.
And we can not change startup_64 to other value --- ABI ?
We could move function verify_cpu down, and that could avoid extra
code of jmp back and forth.
Signed-off-by: Yinghai Lu
Cc: Matt Fleming
---
There several places to find ramdisk information early for reserving
and relocating.
Use functions to make code more readable and consistent.
Later will add ext_ramdisk_image/size in those functions to support
loading ramdisk above 4g.
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/setup.c |
commit 08da5a2ca
x86_64: Early segment setup for VT
add lldt/ltr to clean more segments.
Those code are put in code64, and it is using gdt that is only
loaded from code32 path.
That breaks booting with 64bit bootloader that does not go through
code32 path, and get at startup_64 directly,
Now we have limit kdump reseved under 896M, because kexec has the limitation.
and also bzImage need to stay under 4g.
To make kexec/kdump could use range above 4g, we need to make bzImage and
ramdisk could be loaded above 4g.
During booting bzImage will be unpacked on same postion and stay high.
Now 64bit kernel supports more than 1T ram and kexec tools
could find buffer above 1T, remove that obsolete limitation.
and use MAXMEM instead.
Tested on system more than 1024g ram.
Signed-off-by: Yinghai Lu
Cc: "Eric W. Biederman"
---
arch/x86/include/asm/kexec.h |6 +++---
1 files
ext_ramdisk_image/size will record high 32bits for ramdisk info.
code64_start_offset will be set for bzImage that support 64bit.
Let get_ramdisk_image/size to use ext_ramdisk_image/size to get
right positon for ramdisk.
bootloader will fill value to ext_ramdisk_image/size when it load
ramdisk
On 11/16/2012 03:27 AM, Kirill A. Shutemov wrote:
From: "Kirill A. Shutemov"
H. Peter Anvin doesn't like huge zero page which sticks in memory forever
after the first allocation. Here's implementation of lockless refcounting
for huge zero page.
We have two basic primitives:
On Fri, Nov 16, 2012 at 08:59:25AM +0100, Michal Simek wrote:
> Do you have set of tests which should run it?
>
>
> > 2) your definition of current_pt_regs() is an exact copy of on in
> > include/linux/ptrace.h; why is "microblaze: Define current_pt_regs"
> > needed at all? IOW, I'd rather
On Sat, Nov 17, 2012 at 10:06:18PM +0800, Xiao Guangrong wrote:
> On 11/16/2012 05:57 PM, Marcelo Tosatti wrote:
> > On Fri, Nov 16, 2012 at 12:46:16PM +0800, Xiao Guangrong wrote:
> >> On 11/16/2012 11:56 AM, Marcelo Tosatti wrote:
> >>> On Fri, Nov 16, 2012 at 11:39:12AM +0800, Xiao Guangrong
On Fri, Nov 02, 2012 at 10:09:20AM +, Jonathan Cameron wrote:
[...]
> > Looks good to me, fwiw:
> >
> > Reviewed-by Lars-Peter Clausen
>
> On this stuff as far as I'm concerned Lars' approval is fine but
> for what it's worth this all looks fine to me.
>
> Acked-by: Jonathan Cameron
All
On Tue, Oct 09, 2012 at 10:25:59PM +0530, Ramakrishna Pallala wrote:
> This patch registers the power supply as a cooling device if the
> power supply has support for charge throttling.
>
> Now with this change low level drivers need not register with
> thermal framework as it is automatically
On Thu, Oct 04, 2012 at 12:15:08AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Convert to the new da9052 interrupt functions, so that we can get rid of
> irq_base references.
>
> Cc: Anton Vorontsov
> Signed-off-by: Fabio Estevam
> ---
It seems that the patch depends on other
Hi Mike,
On Tue, Nov 13, 2012 at 2:52 AM, Mike Turquette wrote:
> Quoting Shiraz Hashim (2012-11-06 22:36:10)
>> On Wed, Nov 7, 2012 at 11:42 AM, Shiraz Hashim
>> wrote:
>> > Hi Mike, Rob,
>> >
>> > Devices in a SoC can have multiple possible clock sources which is
>> > perfectly captured
On Sat, Nov 17, 2012 at 11:34:19PM -0200, Thiago Farina wrote:
> Hi,
>
> When compiling this source file with the following command line I get
> this error:
What kernel version are you building?
> $ make drivers/usb/usb-skeleton.o
> drivers/usb/usb-skeleton.c: In function ‘skel_open’:
>
http://daringfireball.net/2007/07/on_top
On Sun, Nov 18, 2012 at 03:14:28AM +, Chen, Jun D wrote:
> Hi,
>I make this patch on your tty-next tree, Do I need to make it on the
> branch 3.7-rc6 against?
No, my tty-next branch. But something is odd, it didn't apply at all.
Please try
Hi,
I make this patch on your tty-next tree, Do I need to make it on the branch
3.7-rc6 against?
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Friday, November 16, 2012 8:39 PM
To: Chen, Jun D
Cc: Alan Cox; Bi, Chao; serial; Gorby, Russ;
From: Tejun Heo
Date: Fri, 16 Nov 2012 19:30:59 -0800
> Hello, guys.
>
> This patchset implements proper hierarchy support for netcls_cgroup.
> Pretty simliar to the netprio one[3]. Simpler as each cgroup has
> single config value instead of array of them.
>
> This patchset contains the
On Thu, Oct 18, 2012 at 02:06:01PM +0300, dragos.tatu...@intel.com wrote:
> From: Adrian Hunter
>
> Other modules that may wish to write to persistent storage
> are supported by adding a notifier and write function.
>
> The notifier has 3 events: PSTORE_BEGIN, PSTORE_DUMP and
> PSTORE_END.
On Thu, Oct 18, 2012 at 02:06:03PM +0300, dragos.tatu...@intel.com wrote:
> From: Dragos Tatulea
>
> The task dumper can dump task information during a panic.
> This is equivalent to a magic sysrq 't' command but
> the result is captured from the console and written
> to persistent storage.
On Thu, Oct 18, 2012 at 02:06:06PM +0300, dragos.tatu...@intel.com wrote:
> From: Dragos Tatulea
>
> Otherwise we might miss out on some pstore dumpers that use
> printks below current log level.
If anything, this should be folded into 'pstore: add debugfs support for
causing dumps and panics'.
On Thu, Oct 18, 2012 at 02:06:05PM +0300, dragos.tatu...@intel.com wrote:
> From: Dragos Tatulea
>
> Return error if flushing to backend failed.
I think you can easily fold this into 'pstore: add support for external
writers'.
Thanks.
> Signed-off-by: Dragos Tatulea
> ---
>
On Thu, Oct 18, 2012 at 02:06:02PM +0300, dragos.tatu...@intel.com wrote:
> From: Dragos Tatulea
>
> Added pstore_type_id in message header when storing to ram.
> On write, take into account the contents of this header and
> set the type accordingly.
>
> Signed-off-by: Dragos Tatulea
> ---
On Thu, Oct 18, 2012 at 02:06:00PM +0300, dragos.tatu...@intel.com wrote:
> From: Adrian Hunter
>
> There are 2 debugfs files:
>
> pstore/dump writing a kmsg dump reason code
> will cause a dump to persistent
> storage
>
>
On 11/17/2012 12:48 PM, Hugh Dickins wrote:
Further offtopic..
Hi Hugh,
- I see you add this in vfs.txt:
+ fallocate: called by the VFS to preallocate blocks or punch a hole.
I want to know if it's necessary to add it to man page since users
still don't know fallocate can punch a hole
On Mon, Oct 22, 2012 at 08:17:27AM -0700, Kees Cook wrote:
> On Mon, Oct 22, 2012 at 2:19 AM, Florian Fainelli
> wrote:
> > From: Maxime Bizon
> >
> > record_size / console_size / ftrace_size can be 0 (this is how you
> > disable the feature), but rounddown_pow_of_two(0) is undefined. As
The rcu_is_cpu_rrupt_from_idle() needs to allow for one interrupt level
from the idle loop, but TINY_RCU checks for a call from the idle loop
itself. This commit fixes this issue.
Reported-by: Josh Triplett
Signed-off-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney
b/kernel/rcutiny.c |
irq work can run on any arch even without IPI
support because of the hook on update_process_times().
So lets remove HAVE_IRQ_WORK because it doesn't reflect
any backend requirement.
Signed-off-by: Frederic Weisbecker
Acked-by: Steven Rostedt
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo
From: Steven Rostedt
If we are in nohz and there's still irq_work to be done when the idle
task is about to go offline, give a nasty warning. Everything should
have been flushed from the CPU_DYING notifier already. Further attempts
to enqueue an irq_work are buggy because irqs are disabled by
From: Steven Rostedt
In order not to offline a CPU with pending irq works, flush the
queue from CPU_DYING. The notifier is called by stop_machine on
the CPU that is going down. The code will not be called from irq context
(so things like get_irq_regs() wont work) but I'm not sure what the
The IRQ_WORK_BUSY flag is set right before we execute the
work. Once this flag value is set, the work enters a
claimable state again.
So if we have specific data to compute in our work, we ensure it's
either handled by another CPU or locally by enqueuing the work again.
This state machine is
On irq work initialization, let the user choose to define it
as "lazy" or not. "Lazy" means that we don't want to send
an IPI (provided the arch can anyway) when we enqueue this
work but we rather prefer to wait for the next timer tick
to execute our work if possible.
This is going to be a
Don't stop the tick if we have pending irq works on the
queue, otherwise if the arch can't raise self-IPIs, we may not
find an opportunity to execute the pending works for a while.
Signed-off-by: Frederic Weisbecker
Acked-by: Steven Rostedt
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo
We need some quick way to check if the CPU has stopped
its tick. This will be useful to implement the printk tick
using the irq work subsystem.
Signed-off-by: Frederic Weisbecker
Acked-by: Steven Rostedt
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Paul
klogd is woken up asynchronously from the tick in order
to do it safely.
However if printk is called when the tick is stopped, the reader
won't be woken up until the next interrupt, which might not fire
for a while. As a result, the user may miss some message.
To fix this, lets implement the
Work claiming wants to be SMP-safe.
And by the time we try to claim a work, if it is already executing
concurrently on another CPU, we want to succeed the claiming and queue
the work again because the other CPU may have missed the data we wanted
to handle in our work if it's about to complete
Ingo,
Please pull the printk support in dynticks mode patches that can
be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
tags/printk-dynticks-for-mingo-v2
for you to fetch changes up to 74876a98a87a115254b3a66a14b27320b7f0acaa:
printk: Wake up klogd
On 11/17/2012 12:48 PM, Hugh Dickins wrote:
Further offtopic..
Thanks for your explanation, Hugh. :-)
On Fri, 16 Nov 2012, Jaegeuk Hanse wrote:
Some questions about your shmem/tmpfs: misc and fallocate patchset.
- Since shmem_setattr can truncate tmpfs files, why need add another similar
> "DR" == David Rientjes writes:
I had to reboot to get some work done.
In order to re-create the missing ram I had to use a btrfs fs for the
temp files for a few emerge(1) runs. It seems that the ram which was
used for the cache of those temp files is not recovered when the files
are
Send an NMI to all CPUs when a lockup is detected and the lockup
watchdog code is configured to panic. This gives us a fairly uptodate
snapshot of all CPUs in the system.
This lets us get stack trace of all CPUs which makes life easier
trying to debug a deadlock, and the NMI doesn't change
On Fri, 16 Nov 2012, Tushar Behera wrote:
> Checking '< 0' for unsigned variables always returns false. For error
> codes, use IS_ERR_VALUE() instead.
Wouldn't just changing "irq" type to "int" also work? I think that would
be a more straight-forward solution. If however there are strong
On 11/16/2012 01:01:42 AM, Michael Kerrisk wrote:
After migrating most of the information in
Documentation/filesystems/proc.txt to the proc(5) man page,
Jim Paris pointed out to me that the description of SwapFree
in the man page seemed wrong. I think Jim is right,
but am given pause by fact
On Fri, Nov 16, 2012 at 12:04 AM, Laxman Dewangan wrote:
> Read the output value when gpio is set for the output mode for
> gpio_get_value(). Reading input value in direction out does not
> give correct value.
>
> Signed-off-by: Laxman Dewangan
> Acked-by: Stephen Warren
> ---
> Changes from
On Sat, Nov 17, 2012 at 4:58 AM, Christopher Heiny wrote:
> RMI Function 01 implements basic device control and power management
> behaviors for the RMI4 sensor.
>
> rmi_f01.h exports definitions that we expect to be used by other functionality
> in the future (such as firmware reflash).
>
>
>
On Sat, Nov 17, 2012 at 4:58 AM, Christopher Heiny wrote:
> rmi_f11.c is a driver for 2D touch sensors using the RMI4 protocol. It
> supports
> both touchscreen and touchpad input, in both absolute and relative formats.
> Support for Type-B multitouch is the default, Type-A support is included
On Sat, Nov 17, 2012 at 4:58 AM, Christopher Heiny wrote:
> Infrastructure files for configuration and building.
>
>
> Signed-off-by: Christopher Heiny
>
Cut blank line.
> Cc: Dmitry Torokhov
> Cc: Linus Walleij
> Cc: Naveen Kumar Gaddipati
> Cc: Joeri de Gram
(...)
> +++
On Sat, Nov 17, 2012 at 4:58 AM, Christopher Heiny wrote:
> rmi_i2c.c abstracts an RMI4 device on some arbitrary I2C bus as a logical
> device in the RMI bus. It handles reads/writes from/to the RMI4 devices,
> and manages the page select register setting (since the meaning of page
> select is
On Sat, Nov 17, 2012 at 4:58 AM, Christopher Heiny wrote:
> rmi_bus.c implements the basic functionality of the RMI bus. This file is
> greatly simplified compared to the previous patch - we've switched from
> "do it yourself" device/driver binding to using device_type to distinguish
> between
On Sat, Nov 17, 2012 at 4:58 AM, Christopher Heiny wrote:
> rmi.h provides public definitions required by the RMI bus implementation and
> modules that interact with it.
>
> debugfs and sysfs attributes are documented in files in
> Documentation/ABI/testing. There's two files, one for debugfs
On 16:23 Fri 09 Nov , Stephen Warren wrote:
> On 11/09/2012 09:28 AM, Grant Likely wrote:
> > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren
> > wrote:
> ...
> >> I do rather suspect this use-case is quite common. NVIDIA certainly has
> >> a bunch of development boards with pluggable
> >>
Hi Linus,
hopefully these are the last few GPIO fixes for this merge window.
Info is in the tag as usual.
Please pull them in.
Yours,
Linus Walleij
The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7:
Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)
are available in the
From: Constantine Shulyupin
debugfs_remove() and debugfs_remove_recursive() can take a NULL, so let's
check and warn about that.
Changes since v3, as Joe Perches suggested:
- removed redundant check
Changes since v2, as Joe Perches suggested:
- match whitespace around argument
Changes since
On Sat, Nov 17, 2012 at 08:35:18PM +0100, Mikael Pettersson wrote:
> mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS 3100M]
> graphics)
> up to and including kernel 3.7-rc4. However, with 3.7-rc5 or -rc6, any
> attempt to
> run mplayer just blanks the screen, shows some stray
On Sat, Nov 17, 2012 at 01:01:30PM -0500, Sasha Levin wrote:
>
> I'm getting the following while fuzzing using trinity inside a KVM tools
> guest,
> on latest -next:
>
> [ 1642.783728] BUG: unable to handle kernel NULL pointer dereference at
> 0194
> [ 1642.785083] IP: []
Hi Lee,
Pushed to mmc-next for 3.8 with a minor change:
On Wed, Nov 14 2012, Lee Jones wrote:
> There are discrepancies with regards to how MMC capabilities
> are carried throughout the subsystem. Let's standardise them
> to elevate any confusion.
I think you meant "eliminate" here. :)
On Fri, Nov 16, 2012 at 07:58:50PM -0800, Christopher Heiny wrote:
> +static void release_rmidev_device(struct device *dev)
> +{
> + device_unregister(dev);
> +}
You just leaked memory here, right?
Also, you already unregistered the device, otherwise this function would
have never been
Mikael Pettersson wrote:
> mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS
> 3100M] graphics) up to and including kernel 3.7-rc4. However, with
> 3.7-rc5 or -rc6, any attempt to run mplayer just blanks the screen,
> shows some stray white pixels in the upper left corner, kills the
The current throttling logic always skips RT class if rq->rt is throttled.
It doesn't handle the special case when RT tasks are the only running tasks
in the rq. So it's possible CPU picks idle task up when RTs are available.
This patch aims to avoid the above situation. The modified
I'm announcing the release of the 3.6.7 kernel.
All users of the 3.6 kernel series must upgrade.
The updated 3.6.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.6.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.4.19 kernel.
All users of the 3.4 kernel series must upgrade.
The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.0.52 kernel.
All users of the 3.0 kernel series must upgrade.
The updated 3.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.0.y
and can be browsed at the normal kernel.org git web browser:
Thanks to arrangements by the Linux Foundation, HP, and SUSE we now
have a suitable server we can share to help do compilation testing of
our work for compat-drivers which aims at automatically backporting
the Linux kernel down to all supported known kernel releases. HP
donated a server to the
Hi Steven,
Hmm, the quirk looks quite familiar to me.
IMHO you should (re-?)read Documentation/SubmittingPatches.
(esp. no attachements, and btw one patch per mail)
Do you mind adding Joerg with his current (non-AMD) mail address on
CC? Otherwise it's impossible to get any comment from him.
It's too old, that's the problem.
Gene Heskett wrote:
>On Saturday 17 November 2012, H. Peter Anvin wrote:
>>On 11/17/2012 10:34 AM, Gene Heskett wrote:>
>>
>>> And I don't see anything there that looks like a 'patch level'.
>>> The ucode obviously can, which is what counts in this game of
>>>
On Fri, Nov 16, 2012 at 7:50 AM, Tushar Behera wrote:
> Checking '< 0' for unsigned variables always returns false. For error
> codes, use IS_ERR_VALUE() instead.
>
> CC: Linus Walleij
> Signed-off-by: Tushar Behera
> ---
> drivers/pinctrl/pinctrl-samsung.c |2 +-
> 1 files changed, 1
More thorough testing revealed a typo in last koneplus cleanups.
Signed-off-by: Stefan Achatz
---
drivers/hid/hid-roccat-koneplus.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/hid-roccat-koneplus.h
b/drivers/hid/hid-roccat-koneplus.h
index
On Thu, Nov 15, 2012 at 2:59 PM, Roland Stigge wrote:
> For probing via device tree, we need to support the case without
> platform_data.
> In this case, chip.base is set to -1 for automatic numbering.
>
> Signed-off-by: Roland Stigge
Patch applied with Wolfram's ACK.
Thanks!
Yours,
Linus
On Tue, Nov 13, 2012 at 10:35 AM, Peter Ujfalusi wrote:
> Avoid using the TWL4030_MODULE_PWMA/B as module ID. The LEDEN, PWMA ON/OFF
> and PWMB ON/OFF registers are in a continuous range starting from LED base.
> This is going to be helpful for further cleanup in the twl stack.
>
> No functional
On Fri, Nov 9, 2012 at 7:04 AM, Laxman Dewangan wrote:
> Read the output value when gpio is set for the output mode for
> gpio_get_value(). Reading input value in direction out does not
> give correct value.
>
> Signed-off-by: Laxman Dewangan
Applied v2 with Stephen's ACK.
Yours,
Linus
On Saturday 17 November 2012, Andreas Herrmann wrote:
>On Thu, Nov 15, 2012 at 06:01:22PM -0500, Gene Heskett wrote:
>> On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
>> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
>> >> Add valid patch size for family 16h processors
>> >>
>> >>
On Saturday 17 November 2012, H. Peter Anvin wrote:
>On 11/17/2012 10:34 AM, Gene Heskett wrote:>
>
>> And I don't see anything there that looks like a 'patch level'.
>> The ucode obviously can, which is what counts in this game of
>> horseshoes. Perhaps something in that very long 'flags' string?
On Thu, Nov 15, 2012 at 06:01:22PM -0500, Gene Heskett wrote:
> On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >> Add valid patch size for family 16h processors
> >>
> >> Signed-off-by: Boris Ostrovsky
> >
> >Is this something
On 11/17/2012 10:34 AM, Gene Heskett wrote:>
> And I don't see anything there that looks like a 'patch level'.
> The ucode obviously can, which is what counts in this game of horseshoes.
> Perhaps something in that very long 'flags' string?
>
What kernel version is this?
-hpa
--
To
mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS 3100M]
graphics)
up to and including kernel 3.7-rc4. However, with 3.7-rc5 or -rc6, any attempt
to
run mplayer just blanks the screen, shows some stray white pixels in the upper
left
corner, kills the X server, and spews the
Hi Alex,
On 11/17/2012 06:34 PM, Alex Shi wrote:
> This patchset try to consider runnable load avg when do cpu load comparison
> in load balance.
>
> I had seen preeti's enabling before patch finished, but I still think
> considing
> runnable load avg on rq is may a more natrual way.
>
> BTW,
On Sat, 2012-11-17 at 20:54 +0200, Constantine Shulyupin wrote:
> From: Constantine Shulyupin
Hi Constantine.
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> +# check for needless debugfs_remove() and debugfs_remove_recursive*() checks
> + if ($line =~
From: Constantine Shulyupin
debugfs_remove() and debugfs_remove_recursive() can take a NULL, so let's
check and warn about that.
Changes since v2, as Joe Perches suggested:
- match whitespace around argument
Changes since v1, as Joe Perches suggested:
- added debugfs_remove_recursive
- all
On Mon, Nov 12, 2012 at 9:44 PM, Arnd Bergmann wrote:
>> Signed-off-by: Sasha Levin
>
> Linus Walleij is doing most of the integrator work these days, maybe he
> wants to apply the patch.
>
> Acked-by: Arnd Bergmann
OK I'll apply it to my stash and submit a pull request to
simplify things.
I
On Saturday 17 November 2012, Borislav Petkov wrote:
>On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
>> One possibility is that BIOS already incorporated all patches (which
>> typically is the case) and so the driver doesn't have to do anything.
>
>/proc/cpuinfo contains ucode
Hi,
On 11/08/2012 07:59 AM, Marek Szyprowski wrote:
> Since commit 2139cbe627b8 ("cma: fix counting of isolated pages") free
> pages in isolated pageblocks are not accounted to NR_FREE_PAGES counters,
> so watermarks check is not required if one operates on a free page in
> isolated pageblock.
>
Hi Alex,
On 11/17/2012 06:34 PM, Alex Shi wrote:
> Except using runnable load average in background, wake_affine and
> move_tasks is also the key functions in load balance. We need consider
> the runnable load average in them in order to the apple to apple load
> comparison in load balance.
>
>
Hi guys,
On 11/11/2012 02:01 PM, Rafael Aquini wrote:
> Memory fragmentation introduced by ballooning might reduce significantly
> the number of 2MB contiguous memory blocks that can be used within a guest,
> thus imposing performance penalties associated with the reduced number of
> transparent
Around Sat 17 Nov 2012 16:04:18 +0100 or thereabout, Joachim Eastwood wrote:
> Since commit 83b9d3a0 (UAPI: (Scripted) Disintegrate arch/avr32/include/asm)
> building AVR32 spews out tons warnings like this:
> In file included from include/linux/sched.h:11,
> from
On Sat, 2012-11-17 at 16:36 +0200, Constantine Shulyupin wrote:
> From: Constantine Shulyupin
>
> debugfs_remove() and debugfs_remove_recursive() can take a NULL, so let's
> check and warn about that.
>
> Channegs since v1:
>
> - added debugfs_remove_recursivere
> - all tests for pattenrs
Hi Linus,
Please pull these 3 bug fixes for XFS. This includes a fix for attribute
corruption, a fix for error handling in xfs_vm_writepage, and a fix for
reference counts on xfs_bufs.
Thanks,
Ben
The following changes since commit 6ce377afd1755eae5c93410ca9a1121dfead7b87:
When a thread exits mix it's cputime (userspace + kernelspace) to the entropy
pool.
We don't know how "random" this is, so we use add_device_randomness that
doesn't mess
with entropy count.
Signed-off-by: Nick Kossifidis
---
kernel/posix-cpu-timers.c |3 +++
1 files changed, 3
On Sat, Nov 17, 2012 at 01:29:19PM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 17 Nov 2012, Borislav Petkov wrote:
> > On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> > > One possibility is that BIOS already incorporated all patches (which
> > > typically is the case)
On Sat, 17 Nov 2012, Borislav Petkov wrote:
> On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> > One possibility is that BIOS already incorporated all patches (which
> > typically is the case) and so the driver doesn't have to do anything.
>
> /proc/cpuinfo contains ucode
On 11/17/2012 09:56 AM, Linus Torvalds wrote:
On Sat, Nov 17, 2012 at 6:50 AM, Borislav Petkov wrote:
I don't know, however, whether it would be prudent to have some sort of
a cheap assertion in the code (cheaper than INVLPG %ADDR, although on
older cpus we do MOV CR3) just in case. This
On Sat, Nov 17, 2012 at 06:56:10AM -0800, Linus Torvalds wrote:
> I wonder how we could actually test for it. We'd have to have some
> per-cpu page-fault address check (along with a generation count on the
> mm or similar). I doubt we'd figure out anything that works reliably
> and efficiently and
This is a static checker fix. The problem is that we store the bits
from "uv_apicid_hibits" into "apicid" (the high 16 bits) but then we
shift it 16 bit to the left. "apicid" is an int so it wraps and we lose
them.
Signed-off-by: Dan Carpenter
---
This is for an SGI product, and I can't test
We're holding a spin_lock here so we should use GFP_ATOMIC.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/megaraid/megaraid_mm.c
b/drivers/scsi/megaraid/megaraid_mm.c
index 25506c7..5205275 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@
Since commit 83b9d3a0 (UAPI: (Scripted) Disintegrate arch/avr32/include/asm)
building AVR32 spews out tons warnings like this:
In file included from include/linux/sched.h:11,
from init/do_mounts_initrd.c:17:
/linux-2.6/arch/avr32/include/asm/param.h:6:1: warning: "HZ" redefined
1 - 100 of 330 matches
Mail list logo
