Hi Xiaotian,
On Wed, Oct 31, 2012 at 04:05:59PM +0800, Xiaotian Feng wrote:
> If tasklet_disable() is called before related tasklet handled,
> tasklet_kill will never be finished. tasklet_kill is enough.
>
Could you please elaborate on this? Needing to disable tasket before
killing it is quite
On 11/24/12, Mel Gorman wrote:
> On Sat, Nov 24, 2012 at 12:17:03PM +0800, Hillf Danton wrote:
>> A thp contributes 512 times more than a regular page to numa fault stats,
>> so deserves its own vm event counter. THP migration is also accounted.
>>
>
> I agree and mentioned it needed fixing. I
On Sat, Nov 24, 2012 at 9:52 PM, H. Peter Anvin wrote:
> But it doesn't solve the bigger problem, and it is just begging to be gotten
> wrong.
>>
>>later all new kernel need to check USE_EXT_BOOT_PARAMS bit for all new
>>added field in boot_params.
Do you mean
later someone would forget
as per 4) move towards where "most" memory. If we have a large shared
memory than private memnory. Why not we just move the process towrds
the memory.. instead of the memory moving towards the node. This will
i guess be less cumbersome, then moving all the shared memory
On Fri, Nov 16, 2012 at
But it doesn't solve the bigger problem, and it is just begging to be gotten
wrong.
Yinghai Lu wrote:
>On Sat, Nov 24, 2012 at 4:11 PM, Yinghai Lu wrote:
>> On Sat, Nov 24, 2012 at 4:04 PM, H. Peter Anvin
>wrote:
>>>
>>> It sounds like we are leaning toward some form of the sentinel hack,
On Sat, Nov 24, 2012 at 4:11 PM, Yinghai Lu wrote:
> On Sat, Nov 24, 2012 at 4:04 PM, H. Peter Anvin wrote:
>>
>> It sounds like we are leaning toward some form of the sentinel hack, which
>> means we need an enumerated list of things that should *not* be zeroed if
>> the sentinel is present.
>>
This patch applies spinlock to protect access to rx / tx structs in
certain call sites, which fixes the following crash in gdm_suspend.
It also fixes usb_set_intfdata() in gdm_usb_probe to avoid setting an
already freed phy_dev.
<5>[ 4996.815018] [<7f0074b0>] (gdm_suspend+0x1c/0x2b4 [gdmwm]) from
On Sat, Nov 24, 2012 at 11:41:23AM +0200, Pekka Enberg wrote:
> On Sat, Nov 24, 2012 at 10:29 AM, wrote:
> > For old glibc there's no the syscall number this tests will cause
> > make run_tests fail.
> > Add a macro to define the number. This should be ok because it will be
> > built in latest
Since nothing depends on the max_high field values anymore, we can just
remove the field and the code that was used to maintain it.
Signed-off-by: Michel Lespinasse
---
tools/kvm/include/kvm/rbtree-interval.h | 13 ---
tools/kvm/util/rbtree-interval.c| 58
As the rbtree intervals are not overlapping, rb_int_search_single can
trivially be implemented without making use of the max_high field.
Signed-off-by: Michel Lespinasse
---
tools/kvm/util/rbtree-interval.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff
The rbtree interval API is designed for handling non-overlapping intervals;
modify rb_int_insert() to guarantee this property is maintained by
returning -EEXIST when attempting to insert a new interval that overlaps
an existing interval.
Also fix an issue where the computation of 'result' could
On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse wrote:
> On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin wrote:
>> The following patch fixed the problem for me:
>>
>> diff --git a/include/linux/rbtree_augmented.h
>> b/include/linux/rbtree_augmented.h
>> index 214caa3..5cfdca6 100644
>> ---
Found using the following semantic patch:
@@
@@
spin_lock_irqsave(...);
... when != spin_unlock_irqrestore(...);
* GFP_KERNEL
Signed-off-by: Cyril Roelandt
---
drivers/usb/gadget/uvc_video.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Sat, Nov 24, 2012 at 12:35 PM, Yinghai Lu wrote:
> ext_ramdisk_image/size will record high 32bits for ramdisk info.
>
> xloadflags bit0 will be set if relocatable with 64bit.
>
> Let get_ramdisk_image/size to use ext_ramdisk_image/size to get
> right positon for ramdisk.
>
> bootloader will
On Sat, Nov 24, 2012 at 4:04 PM, H. Peter Anvin wrote:
>
> It sounds like we are leaning toward some form of the sentinel hack, which
> means we need an enumerated list of things that should *not* be zeroed if
> the sentinel is present.
>
> The option of declaring the list frozen makes me a bit
>Could you take few snapshots over time?
Here it is, now from different server, snapshot was taken every second for 10
minutes (hope it's enough):
www.watchdog.sk/lkml/memcg-bug-2.tar.gz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 11/24/2012 04:04 PM, Yinghai Lu wrote:
On Sat, Nov 24, 2012 at 3:50 PM, Eric W. Biederman
wrote:
I believe all added variables between the last version of the boot
protocol /sbin/kexec knows about and the current time were added in the
initialized data section. Certainly we can check and
On 11/24/2012 03:50 PM, Eric W. Biederman wrote:
It was conservative at the time the code was introduced and it most
definitely is not wrong. The code predates the verbage in boot.txt.
Apparently no one bothered to see what /sbin/kexec was actually doing
when they documented the 32bit boot
On Sat, Nov 24, 2012 at 3:50 PM, Eric W. Biederman
wrote:
>
> I believe all added variables between the last version of the boot
> protocol /sbin/kexec knows about and the current time were added in the
> initialized data section. Certainly we can check and that will tell us
> how likely changes
"H. Peter Anvin" writes:
> On 11/24/2012 09:32 AM, H. Peter Anvin wrote:
>> On 11/24/2012 04:37 AM, Eric W. Biederman wrote:
>>>
>>> Certainly /sbin/kexec isn't bothering to calculate the end of the setup
>>> header and just being far more conservative and using all of the 16bit
>>> real mode
On Saturday, November 24, 2012 03:21:49 PM Olof Johansson wrote:
> Rafael,
>
> On Sat, Nov 24, 2012 at 2:03 AM, Rafael J. Wysocki wrote:
> > On Monday, November 12, 2012 10:00:07 PM Arnd Bergmann wrote:
> >> On Wednesday 07 November 2012, Rob Herring wrote:
> >> > From: Rob Herring
> >> >
> >>
On Sat, Nov 24, 2012 at 2:32 PM, H. Peter Anvin wrote:
> On 11/24/2012 02:18 PM, Yinghai Lu wrote:
> Well, that solves the problem for *this specific instance* but I fear
> therein lies madness in the general case.
>
use
Bit 0 (read): CAN_BE_LOADED_ABOVE_4G
- If 1,
On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka wrote:
> So it's better to slow down mount.
I am quite proud of the linux boot time pitting against other OS. Even
with 10 partitions. Linux can boot up in just a few seconds, but now
you're saying that we need to do this semaphore check at boot
Rafael,
On Sat, Nov 24, 2012 at 2:03 AM, Rafael J. Wysocki wrote:
> On Monday, November 12, 2012 10:00:07 PM Arnd Bergmann wrote:
>> On Wednesday 07 November 2012, Rob Herring wrote:
>> > From: Rob Herring
>> >
>> > Add support for core powergating on Calxeda platforms. Initially, this
>> >
Miklos Szeredi writes:
> On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
> wrote:
>> Ian Kent writes:
>>
>>> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>
AFAICS autofs mounts mounted with MS_PRIVATE in the initial
On Saturday, November 24, 2012 11:01:56 PM Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 01:23:44 PM Toshi Kani wrote:
> > Added a new .sys_notify interface, which allows ACPI drivers to
> > register their system-level (ex. hotplug) notify handlers through
> > their acpi_driver table.
On 11/24/2012 02:18 PM, Yinghai Lu wrote:
Careful... consider the people who use a kexec-based solution as
bootloaders.
yes, those may not update kexec in the flash...
then, may need to use another bit in xloadflags to tell new kernel if
need to check ext_...
Field name: xloadflags
On Sat, Nov 24, 2012 at 1:38 PM, H. Peter Anvin wrote:
> On 11/24/2012 01:30 PM, Yinghai Lu wrote:
>>>
>>>
>>> So, given the mess we now have on our hands... any suggestions how to
>>> best
>>> solve it? There is the option of simply declaring old kexec binaries
>>> broken; they will then not
On Saturday, November 24, 2012 11:01:56 PM Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 01:23:44 PM Toshi Kani wrote:
> > Added a new .sys_notify interface, which allows ACPI drivers to
> > register their system-level (ex. hotplug) notify handlers through
> > their acpi_driver table.
On Thursday, November 08, 2012 01:23:44 PM Toshi Kani wrote:
> Added a new .sys_notify interface, which allows ACPI drivers to
> register their system-level (ex. hotplug) notify handlers through
> their acpi_driver table. This removes redundant ACPI namespace
> walks from ACPI drivers for faster
On 11/24/2012 01:30 PM, Yinghai Lu wrote:
So, given the mess we now have on our hands... any suggestions how to best
solve it? There is the option of simply declaring old kexec binaries
broken; they will then not work reliably with newer kernels, if they even
work reliably now -- it is hard to
On Sat, Nov 24, 2012 at 11:50 AM, H. Peter Anvin wrote:
> On 11/24/2012 09:32 AM, H. Peter Anvin wrote:
>>
>> On 11/24/2012 04:37 AM, Eric W. Biederman wrote:
>>>
>>>
>>> Certainly /sbin/kexec isn't bothering to calculate the end of the setup
>>> header and just being far more conservative and
Otherwise we are getting a nil dereference
| [0.00] BUG: unable to handle kernel NULL pointer dereference at
(null)
| [0.00] IP: [] strcmp+0x10/0x30
Signed-off-by: Cyrill Gorcunov
---
mm/percpu.c |3 +++
1 file changed, 3 insertions(+)
Index:
On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
wrote:
> Ian Kent writes:
>
>> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
>>> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>>> AFAICS autofs mounts mounted with MS_PRIVATE in the initial namespace do
>>> propagate to the
On Sat, 24 Nov 2012, Jeff Chua wrote:
> On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe wrote:
> > On 2012-11-22 20:21, Linus Torvalds wrote:
> >> Doesn't sound like a fsdevel issue since it seems to be independent of
> >> filesystems. More like some generic block layer thing. Adding Jens
> >>
On Sat, Nov 24, 2012 at 10:54:03AM +, Jonathan Cameron wrote:
> On 11/23/2012 03:13 PM, Thierry Reding wrote:
> > Add support for reading conversion results from the ADC and provide them
> > through a single IIO channel. A proper scaling factor is also exported
> > based on the reference
When 64bit bootloader put real mode data above 4g, We can not
access real mode data directly yet.
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 early from setup_arch()
to x86_64_start_kernel().
Also
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
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 |
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
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 path
and 32bit in 32bit path.
Signed-off-by: Yinghai Lu
---
arch/x86/boot/boot.h|8
arch/x86/boot/cmdline.c |4 ++--
2 files
We are short of space before 0x200 that is entry for startup_64.
According to hpa, we can not change startup_64 to other offset and
that become ABI now.
We could move function verify_cpu down, and that could avoid extra
code of jmp back and forth if we would move other lines.
Signed-off-by:
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.
cmdline.c::__cmdline_find_option... are shared between
16-bit setup code and 32/64 bit decompressor code.
for 32/64 only path via kexec, we should not check if ptr less 1M.
as those cmdline could be put above 1M, or even 4G.
Move out accessible checking out of __cmdline_find_option()
So
ext_ramdisk_image/size will record high 32bits for ramdisk info.
xloadflags bit0 will be set if relocatable with 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 above 4G.
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 BRK for early page table.
Need to set map for [_text, _end] include text/data/bss/brk...
Also current
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. It 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.
On Fri, Nov 23, 2012 at 01:48:51PM +0100, Peter Korsgaard wrote:
> > "Thierry" == Thierry Reding writes:
>
> Hi,
>
> Thierry> Everybody seems to be doing it with a warning, so I guess
> Thierry> that's fine for now. I just find it strange that if you
> Thierry> request the default pin
On Sat, 2012-11-24 at 21:28 +0100, Paul Bolle wrote:
> I submitted an identical patch in https://lkml.org/lkml/2012/6/25/154 .
> In a reaction on that patch Kukjin Kim wondered whether "Simtec Linux
> Team and Vincent are still supporting BAST". No-one bothered to reply on
> Kukjin's message,
On Fri, 2012-11-23 at 22:26 -0200, Cesar Eduardo Barros wrote:
> These files were renamed by commit 85fd6d6 (ARM: S3C2410: move
> mach-s3c2410/* into mach-s3c24xx/).
I submitted an identical patch in https://lkml.org/lkml/2012/6/25/154 .
In a reaction on that patch Kukjin Kim wondered whether
On 11/24/2012 09:32 AM, H. Peter Anvin wrote:
On 11/24/2012 04:37 AM, Eric W. Biederman wrote:
Certainly /sbin/kexec isn't bothering to calculate the end of the setup
header and just being far more conservative and using all of the 16bit
real mode code as it's initializer.
That's not
Hi,
Is the following normal on an X9SRL-F board (bios 1.0a)?
In the manual it states:
Data Direct I/O
Select Enabled to enable Intel I/OAT (I/O Acceleration Technology), which
significantly reduces CPU overhead by leveraging CPU architectural
improvements and freeing the system resource for
Any ideas on that? I'm currently avoiding the 3.6 series because
of that problem but would be willing to reproduce the hang if I'd
know what to do once it happens, ie. what kind of information to
collect in order to identify the cause of the problem.
I may also try 3.7-rc if there's any interest.
On Sat, Nov 24, 2012 at 07:10:24PM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
>
> On Sat, 24 Nov 2012 10:00:04 -0500, Jason Cooper wrote:
>
> > Yes, so that's what I thought happened. This would have made orion/dt
> > depend upon mvebu/everything. It already had two other
On Fri, Nov 23, 2012 at 10:26:44PM -0200, Cesar Eduardo Barros wrote:
> Added by commit 200efed (pwm: Take over maintainership of the PWM
> subsystem), but I could not find any trace of that file being ever added
> to the repository.
>
> Cc: Thierry Reding
> Signed-off-by: Cesar Eduardo Barros
On 11/24/2012 10:12 AM, Yinghai Lu wrote:
Now I have a fix ready, also found fix for kexec real mode path working
with recently kernel by settin heap end ptr correctly.
Please decide if we need to add 64 bit entry offset in setup header,
Or just stick to 0x200.
I check grub2 and gujin and
On 24 November 2012 23:29, Mark Brown
wrote:
> On Fri, Nov 23, 2012 at 01:33:15PM +0530, Thomas Abraham wrote:
>
>> This v6 patch is rebased to the latest max8997 driver code and there are no
>> functional changes from v5.
>
> That doesn't seem to be in mainline yet so the patch won't apply.
Hi
Dear Jason Cooper,
On Sat, 24 Nov 2012 10:00:04 -0500, Jason Cooper wrote:
> Yes, so that's what I thought happened. This would have made orion/dt
> depend upon mvebu/everything. It already had two other dependencies.
> Not ideal.
>
> The good thing is, the build is not broken. Once v3.8-rc1
Now that it safe to use ->consumer_rwsem under ->mmap_sem we can
almost finish the implementation of filter_chain(). It still lacks
the actual uc->filter(...) call but othewrwise it is ready, just
it pretends that ->filter() always returns true.
Signed-off-by: Oleg Nesterov
---
Now that ->register_rwsem is safe under ->mmap_sem we can kill
->copy_mutex and abuse down_write(>consumer_rwsem).
This makes prepare_uprobe() even more ugly, but we should kill
it anyway.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c |7 +++
1 files changed, 3
Simply remove UPROBE_RUN_HANDLER and the corresponding code.
It can only help if uprobe has a single consumer, and in fact
it is no longer needed after handler_chain() was changed to use
->register_rwsem, we simply can not race with uprobe_register().
Signed-off-by: Oleg Nesterov
---
Introduce uprobe->register_rwsem. It is taken for writing around
__uprobe_register/unregister.
Change handler_chain() to use this sem rather than consumer_rwsem.
The main reason for this change is that we have the nasty problem
with mmap_sem/consumer_rwsem dependency. filter_chain() needs to
Hello.
On top of
"[PATCH 0/7] uprobes: register/unregister preparations for filtering"
4/4 is not really needed and I won't insist if you dislike it.
Just this ->copy_mutex annoys me ;)
Please review. filter_chain() is almost ready, just we need to
discuss (again) its arguments/etc and
On Fri, Nov 23, 2012 at 01:33:15PM +0530, Thomas Abraham wrote:
> This v6 patch is rebased to the latest max8997 driver code and there are no
> functional changes from v5.
That doesn't seem to be in mainline yet so the patch won't apply.
signature.asc
Description: Digital signature
On Fri, Nov 23, 2012 at 01:33:14PM +0530, Thomas Abraham wrote:
> In case the gpio based volatage selection mode is not used for either of
> buck 1/2/5, then only the BUCKxDVS1 register need to be programmed. So
> determine whether dvs mode is used and limit the loop count appropriately.
Applied,
On Fri, Nov 23, 2012 at 01:33:13PM +0530, Thomas Abraham wrote:
> The BUCKxDVSx register programming is now moved prior to setting up of the
> gpio based dvs mode. This will ensure that all the BUCKxDVSx registers
> are programmed with appropriate voltage values before the gpio based dvs
> mode is
On Fri, Nov 23, 2012 at 10:27:12AM +0800, Qing Xu wrote:
> But, in fact, it is not necessary to initialize regulator_idx.
> for (i = 0; i < ARRAY_SIZE(max8925_regulator_info); i++) {
> ri = _regulator_info[i];
> if (ri->vol_reg == res->start) {
> **
On Fri, Nov 23, 2012 at 11:47:16PM +0800, Axel Lin wrote:
> This driver can be built as a module, add MODULE_ALIAS for it.
Applied, thanks.
signature.asc
Description: Digital signature
On 11/21/2012 12:50 AM, Linus Walleij wrote:
> To be crystal clear on what the arguments mean in this
> funtion dealing with both GPIO and PIN ranges with confusing
> naming, we now have gpio_offset and pin_offset and we are
> on the clear that these are offsets into the specific GPIO
> and pin
On 11/24/2012 04:37 AM, Eric W. Biederman wrote:
Certainly /sbin/kexec isn't bothering to calculate the end of the setup
header and just being far more conservative and using all of the 16bit
real mode code as it's initializer.
That's not conservative... that's just plain wrong. It means
This patch introduce the use of the sysfs attribute for the spidev
configuration. This avoid the user to have a specific program which does
ioctl() on spidev. The user can easily does cat (to read) and echo (to
write) on the sysfs file and configure SPI.
The patch exports the following
From: "Anthony G. Basile"
stime and utime are declared __u64 but are never used. On a glibc system
this is harmless lint, but on a uClibc system, because of the difference
in they way header files stack, including stdio.h brings in time.h and
this causes a name collision with stime. Since
At 2012/11/24 1:50, Vasilis Liaskovitis Wrote:
> Offlining and removal of memory is now done in the prepare_remove callback,
> not in the remove callback.
>
> The prepare_remove callback will be called when trying to remove a memory
> device
> with the following ways:
>
> 1. send eject request
At 2012/11/24 1:50, Vasilis Liaskovitis Wrote:
> Consider the following sequence of operations for a hotplugged memory device:
>
> 1. echo "PNP0C80:XX"> /sys/bus/acpi/drivers/acpi_memhotplug/unbind
> 2. echo "PNP0C80:XX"> /sys/bus/acpi/drivers/acpi_memhotplug/bind
> 3. echo
On 11/24/2012 03:54 PM, Lars-Peter Clausen wrote:
> On 11/24/2012 11:54 AM, Jonathan Cameron wrote:
>> On 11/23/2012 03:13 PM, Thierry Reding wrote:
>>> Add support for reading conversion results from the ADC and provide them
>>> through a single IIO channel. A proper scaling factor is also
On 11/23, Oleg Nesterov wrote:
>
> Change install_breakpoint() to call filter_chain() instead of checking
> uprobe->consumers != NULL. We obviously need this, and this equally
> closes the race with _unregister().
>
> Change remove_breakpoint() to call this helper too. Currently this is
>
On 11/24/2012 11:54 AM, Jonathan Cameron wrote:
> On 11/23/2012 03:13 PM, Thierry Reding wrote:
>> Add support for reading conversion results from the ADC and provide them
>> through a single IIO channel. A proper scaling factor is also exported
>> based on the reference voltage provided by a
On Wed, Nov 21, 2012 at 12:10:43AM +, Alan Cox wrote:
> > Not just a separate document but project / github / whatever given
> > that other projects are referring to it now, and we stand to gain more
> > in the community by streamlining it more and making it ubiquitous.
>
> Cutting and
On Thu, Nov 22, 2012 at 5:41 PM, Fengguang Wu wrote:
> On Wed, Nov 21, 2012 at 12:07:22PM +0200, Metin Döşlü wrote:
>> On Wed, Nov 21, 2012 at 12:00 PM, Jaegeuk Hanse
>> wrote:
>> >
>> > On 11/21/2012 05:58 PM, metin d wrote:
>> >
>> > Hi Fengguang,
>> >
>> > I run tests and attached the
Acked-by: Javier Muñoz
Thanks Cesar!
Javier
On 11/24/2012 01:26 AM, Cesar Eduardo Barros wrote:
> This directory was moved to drivers/staging/sm7xxfb/ by commit 925aa66
> (staging: sm7xxfb: sm7xx becomes sm7xxfb).
>
> Cc: Teddy Wang
> Cc: Javier M. Mellid
> Signed-off-by: Cesar Eduardo
On Sat, Nov 24, 2012 at 08:02:40AM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
>
> On Fri, 23 Nov 2012 21:39:42 -0500, Jason Cooper wrote:
> > > + pinctrl: pinctrl@d0200 {
> > > + compatible = "marvell,dove-pinctrl";
> > > + reg = <0xd0200 0x10>;
>
Hi Oleg,
This patch may look ugly, but it is one way to solve my problem.
This way, "strace" too, which is broken since the introduction of
the vsyscall page, will again be able to report when the program
calls "time()" or "gettimeofday()" - currently it cannot!
I think that allowing to set the
Linus,
The following changes since commit 947d299686aa9cc8aecf749d54e8475c6e498956:
ALSA: snd-usb: properly initialize the sync endpoint (2012-11-22 21:22:33
+0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.7
for
Hi Oleg,
> Hello Amnon,
>
> I am a bit confused,
So let's get things in order.
1) I asked for the ability to set hardware breakpoints on the vsyscall
page (x86 debug registers), so that the ptracer can stop the process
whenever it attempts to jump there, then the ptracer can emulate
On Sat, Nov 24, 2012 at 12:27:39PM +0800, Hillf Danton wrote:
> If fail to migrate thp(due to unsuccessful isolation), and if the original
> pmd entry is changed after reaquiring page table lock, it is unsafe to
> release the page lock as page maybe unstable.
>
> It is fixed by raising extra page
On Sat, Nov 24, 2012 at 12:18:51PM +0800, Hillf Danton wrote:
> Free newly allocated thp if fail to isolate the old.
>
> Signed-off-by: Hillf Danton
Thanks!
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Sat, Nov 24, 2012 at 12:17:03PM +0800, Hillf Danton wrote:
> A thp contributes 512 times more than a regular page to numa fault stats,
> so deserves its own vm event counter. THP migration is also accounted.
>
I agree and mentioned it needed fixing. I did not create a new counter
but I
If one storage interface or usb network interface(iSCSI case)
exists in current configuration, memory allocation with
GFP_KERNEL during usb_device_reset() might trigger I/O transfer
on the storage interface itself and cause deadlock because
the 'us->dev_mutex' is held in .pre_reset() and the
This patch applies the introduced memalloc_noio_save() and
memalloc_noio_restore() to force memory allocation with no I/O
during runtime_resume/runtime_suspend callback on device with
the flag of 'memalloc_noio' set.
Cc: Alan Stern
Cc: Oliver Neukum
Cc: Rafael J. Wysocki
Signed-off-by: Ming
Deadlock might be caused by allocating memory with GFP_KERNEL in
runtime_resume and runtime_suspend callback of network devices in
iSCSI situation, so mark network devices and its ancestor as
'memalloc_noio' with the introduced pm_runtime_set_memalloc_noio().
Cc: "David S. Miller"
Cc: Eric
This patch applyes the introduced pm_runtime_set_memalloc_noio on
block device so that PM core will teach mm to not allocate memory with
GFP_IOFS when calling the runtime_resume and runtime_suspend callback
for block devices and its ancestors.
Cc: Jens Axboe
Signed-off-by: Ming Lei
---
v5:
The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
to help PM core to teach mm not allocating memory with GFP_KERNEL
flag for avoiding probable deadlock.
As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume() or runtime_suspend() on any one of device in
This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
'struct task_struct'), so that the flag can be set by one task
to avoid doing I/O inside memory allocation in the task's context.
The patch trys to solve one deadlock problem caused by block device,
and the problem may happen
Hi,
This patchset try to solve one deadlock problem which might be caused
by memory allocation with block I/O during runtime PM and block device
error handling path. Traditionly, the problem is addressed by passing
GFP_NOIO statically to mm, but that is not a effective solution, see
detailed
Hi Oleg,
> Amnon,
>
> I am going to "ignore" this thread because this is not my area and
> I can't help anyway. Just one note:
>
> On 11/23, Amnon Shiloh wrote:
> >
> > The solution can be to hold all catched signals while in the VDSO page.
> > ...
> >
> > 1) + introduce a kernel feature to
"H. Peter Anvin" writes:
> On 11/22/2012 10:28 AM, Yinghai Lu wrote:
>>
>> has problem with old kexec, it only copy header from bzImage include
>> setup_header as boot_param.
>>
>
> How old are we talking here? This is a clear and blatant bug, and it would
> affect a whole bunch of things, not
Building ewrk3.o triggers this GCC warning:
drivers/net/ethernet/dec/ewrk3.c: In function '__check_irq':
drivers/net/ethernet/dec/ewrk3.c:1915:1: warning: return from incompatible
pointer type [enabled by default]
This can be trivially fixed by changing the 'irq' parameter from int to
Ian Kent writes:
> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
>> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>> > Ian Kent writes:
>> >
>> > > On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
>> > >> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
>> > >> >
use devm_kzalloc and remove the error path free'ing and unload free'ing
as the devm resource functions free them.
Signed-off-by: Devendra Naga
---
drivers/mfd/jz4740-adc.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/jz4740-adc.c
1 - 100 of 268 matches
Mail list logo
