On Sat, Apr 06, 2013 at 01:05:59PM +0800, Chen Gang wrote:
> On 2013年04月06日 07:48, Arve Hjønnevåg wrote:
> > On Fri, Apr 5, 2013 at 3:01 PM, Greg KH wrote:
> >> > On Fri, Apr 05, 2013 at 04:05:25PM +0800, Chen Gang wrote:
> >>> >>
> >>> >> need break when 'target_thread' get value, firstly.
>
From: Namjae Jeon
Add tracepoints to debug checkpoint request.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
fs/f2fs/checkpoint.c|1 +
include/trace/events/f2fs.h | 18 ++
2 files changed, 19 insertions(+)
diff --git a/fs/f2fs/checkpoint.c
From: Namjae Jeon
Add tracepoints to debug the various page write operation
like data pages, meta pages.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
fs/f2fs/checkpoint.c|2 ++
fs/f2fs/data.c |2 ++
include/trace/events/f2fs.h | 62
From: Namjae Jeon
Add tracepoints to debug the block allocation & fallocate.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
fs/f2fs/data.c |1 +
fs/f2fs/file.c |3 ++
include/trace/events/f2fs.h | 76 +++
From: Namjae Jeon
Add tracepoints for tracing the garbage collector
threads in f2fs with status of collection & type.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
fs/f2fs/gc.c|2 ++
include/trace/events/f2fs.h | 20
2 files changed, 22
From: Namjae Jeon
add tracepoints for tracing the truncate operations
like truncate node/data blocks, f2fs_truncate etc.
Tracepoints are added at entry and exit of operation
to trace the success & failure of operation.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
From: Namjae Jeon
Add tracepoints for page i/o operations and block allocation
tracing during page read operation.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
fs/f2fs/data.c |9 ++-
include/trace/events/f2fs.h | 61
From: Namjae Jeon
Add tracepoints in f2fs for tracing the syncing
operations like filesystem sync, file sync enter/exit.
It will helf to trace the code under debugging scenarios.
Also add tracepoints for tracing the various inode operations
like building inode, eviction of inode, link/unlink of
From: Namjae Jeon
Add tracepoints in f2fs filesystem for tracing the filesystem
operations for information/debugging purpose if needed. All the
tracepoints are clubbed with respect to functionalities.
Change Log:
v3: Introduced TRACE_EVENT_CONDITION() macro for checking the
condition
From: Namjae Jeon
Fix typo mistakes.
1. I think that it should be 'L' instead of 'V'.
2. and try to fix 'Front' instead of 'Frone'
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/data.c|2 +-
fs/f2fs/segment.h |2 +-
2 files changed, 2 insertions(+), 2
On 2013年04月06日 13:05, Chen Gang wrote:
> On 2013年04月06日 07:48, Arve Hjønnevåg wrote:
>> Theoretically this should not change the behavior. The purpose of this
>> code it to make sure only thread per process is part of a transaction
>> stack, so if it finds more than one transaction with a matching
Sebastian Wankerl writes:
> On 04/05/13 06:00, Rusty Russell wrote:
>> Sebastian Wankerl writes:
>>> On 04/04/13 03:00, Rusty Russell wrote:
Sebastian Wankerl writes:
> Add non-zero module sections to sysfs on architectures unequal to PARISC.
> KGDB needs all module sections for
James Bottomley writes:
> On Fri, 2013-04-05 at 14:30 +1030, Rusty Russell wrote:
>> Sebastian Wankerl writes:
>> > On 04/04/13 03:00, Rusty Russell wrote:
>> >> Sebastian Wankerl writes:
>> >>> Add non-zero module sections to sysfs on architectures unequal to PARISC.
>> >>> KGDB needs all
On 2013年04月06日 06:01, Greg KH wrote:
> On Fri, Apr 05, 2013 at 04:05:25PM +0800, Chen Gang wrote:
>>
>> need break when 'target_thread' get value, firstly.
>>
>> 'tmp' is a stack (thread->transaction_stack),
>> if 'proc' was the same between child node and parent node,
>> the child
On 2013年04月06日 07:48, Arve Hjønnevåg wrote:
> On Fri, Apr 5, 2013 at 3:01 PM, Greg KH wrote:
>> > On Fri, Apr 05, 2013 at 04:05:25PM +0800, Chen Gang wrote:
>>> >>
>>> >> need break when 'target_thread' get value, firstly.
>>> >>
>>> >> 'tmp' is a stack (thread->transaction_stack),
>>> >>
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
> 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
> remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
> now it's going away. What should we do to its VMAs? Right now sysfs
> and procfs get away
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/block/drbd/drbd_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
A race condition exists when registering the first watchdog device.
Sequence of events:
- watchdog_register_device calls watchdog_dev_register
- watchdog_dev_register creates the watchdog misc device by calling
misc_register.
At that time, the matching character device (/dev/watchdog0) does
From: Wei Yongjun
Those symbols only used within this file, and should be static.
Signed-off-by: Wei Yongjun
---
drivers/char/virtio_console.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index
On Thu, Apr 04, 2013 at 06:59:59PM -0700, Guenter Roeck wrote:
> On Fri, Apr 05, 2013 at 12:23:30AM +0200, Arkadiusz Miskiewicz wrote:
> > On Thursday 14 of March 2013, Arkadiusz Miśkiewicz wrote:
> > > Hi.
> > >
> > > Just hit watchdog related oops in 3.8.3 kernel. Unfortunately photos only.
> >
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
> 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
> remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
> now it's going away. What should we do to its VMAs? Right now sysfs
> and procfs get away
On Fri, Apr 5, 2013 at 6:25 PM, Neil Horman wrote:
> I'm sorry. Forgot to change the wording of the error for the new model that
> I'm following here. Although the message is mostly right as bios is
> responsible for setting and clearing the IRQ remapping feature bit in the
> chips
[+cc linux-kernel]
On Fri, Apr 5, 2013 at 7:31 PM, Bjorn Helgaas wrote:
> Hi Linus,
>
> Here are some fixes for v3.9. They include fixes for an ASPM problem
> that affects pre-1.1 PCIe devices, a kexec problem, the platform ROM
> image problem, a couple hotplug issues related to PM, and a fix
On Fri, Apr 5, 2013 at 1:31 PM, Neil Horman wrote:
> A few years back intel published a spec update:
> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>
> For the 5520 and 5500 chipsets which contained an errata (specificially errata
>
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes-2
to get the following device-mapper fixes for 3.9.
Thanks,
Alasdair
A pair of patches to fix the writethrough mode of the
I'm sorry. Forgot to change the wording of the error for the new model that
I'm following here. Although the message is mostly right as bios is
responsible for setting and clearing the IRQ remapping feature bit in the chips
capabilities register.
I'll fix and repost Monday
Neil
Yinghai Lu
Hello, guys.
Status-quo
==
It's been about a year since I wrote up a summary on cgroup status quo
and future plans. We're not there yet but much closer than we were
before. At least the locking and object life-time management aren't
crazy anymore and most controllers now support
Hi,
First of all, thank you for your comments!
On 04/04/2013, at 10:12 PM, Arnd Bergmann wrote:
> For new platforms, we want to have only the absolute minimum amount of
> code in arch/arm and move everything else into drivers. However, that
> is only possible using device tree. It should not
(3/25/13 11:12 AM), Michal Hocko wrote:
> On Fri 22-03-13 16:23:55, Naoya Horiguchi wrote:
> [...]
>> @@ -2086,11 +2085,7 @@ int hugetlb_treat_movable_handler(struct ctl_table
>> *table, int write,
>> void __user *buffer,
>> size_t *length, loff_t *ppos)
On Sat, 6 Apr 2013, Stefano Stabellini wrote:
> On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Rob Herring wrote:
> >
> > > On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > > > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > > >
> > > >> This is what happens:
> > > >>
> > >
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
> Currently we can't offline memory blocks which contain hugepages because
> a hugepage is considered as an unmovable page. But now with this patch
> series, a hugepage has become movable, so by using hugepage migration we
> can offline such memory blocks.
On Fri, Apr 5, 2013 at 3:01 PM, Greg KH wrote:
> On Fri, Apr 05, 2013 at 04:05:25PM +0800, Chen Gang wrote:
>>
>> need break when 'target_thread' get value, firstly.
>>
>> 'tmp' is a stack (thread->transaction_stack),
>> if 'proc' was the same between child node and parent node,
>>
On Fri, 5 Apr 2013, Viresh Kumar wrote:
> On Thu, Apr 4, 2013 at 11:05 PM, wrote:
> > From: Dirk Brandewie
> >
> > The current calculation of the delay time is wrong and a cut and paste
> > error from a previous experimental driver. This can result in the
> > timeout being set to jiffies +
On Fri, Apr 5, 2013 at 3:00 PM, Greg KH wrote:
> On Thu, Apr 04, 2013 at 01:32:30PM +0100, Serban Constantinescu wrote:
>> Hi all,
>>
>> This set of patches will clean-up and fix some of the issues that arise
>> with the current binder interface when moving to a 64bit kernel. All these
>> changes
On Fri, Apr 5, 2013 at 12:31 PM, Neil Horman wrote:
> A few years back intel published a spec update:
> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>
> For the 5520 and 5500 chipsets which contained an errata (specificially errata
>
On Tue, Mar 26, 2013 at 4:17 PM, Sebastian Andrzej Siewior
wrote:
>
> Dear RT Folks,
>
> I'm pleased to announce the 3.8.4-rt2 release.
>
> changes since v3.8.4-rt1:
> - build fix for i915 (reported by "Luis Claudio R. Goncalves")
> - build fix for fscache (reported by tglx)
> - build fix for !RT
On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Rob Herring wrote:
>
> > On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > >
> > >> This is what happens:
> > >>
> > >> - No Xen
> > >> Xen is not running on the platform and a Xen
On Fri, Apr 5, 2013 at 1:43 PM, Borislav Petkov wrote:
> On Fri, Apr 05, 2013 at 01:19:39PM -0700, Julien Tinnes wrote:
>> I think it'd be perfectly ok for OOPS to print out the kernel base.
>
> Yeah, ok, this still would need some massaging of the oops output per
> script, but it shouldn't be a
On Thu, Apr 4, 2013 at 5:32 AM, Serban Constantinescu
wrote:
>
> Since the binder driver uses both uint32_t and unsigned int any further
> kernel changes will be difficult to read. This patch fixes the inconsistent
> types usage.
>
Would it make more sense to only change the types that need to
On Sat, Apr 06, 2013 at 12:18:11AM +0200, Jiri Slaby wrote:
> Ok, so now I'm runnning 3.9.0-rc5-next-20130404, it's not that bad, but
> it still sucks. Updating a kernel in a VM still results in "Your system
> is too SLOW to play this!" by mplayer and frame dropping.
What was the first kernel
On Fri, 5 Apr 2013, Rob Herring wrote:
> On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> >
> >> This is what happens:
> >>
> >> - No Xen
> >> Xen is not running on the platform and a Xen hypervisor node is not
> >> available on device tree.
> >>
Two sections checked whether the current channel != the new channel
without ever setting the current channel variables.
1. net/mac802154/tx.c: Prevent set_channel() from getting called every
time a packet is sent.
2. net/mac802154/mib.c: Lock (pib_lock) accesses to current_channel and
On Fri, Apr 05, 2013 at 09:51:37PM +0100, Al Viro wrote:
> On Fri, Apr 05, 2013 at 12:56:09PM -0700, Greg Kroah-Hartman wrote:
> > > 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
> > > remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
> > > now it's
Commit-ID: 918708245e92941df16a634dc201b407d12bcd91
Gitweb: http://git.kernel.org/tip/918708245e92941df16a634dc201b407d12bcd91
Author: Jan Beulich
AuthorDate: Wed, 3 Apr 2013 15:47:33 +0100
Committer: H. Peter Anvin
CommitDate: Fri, 5 Apr 2013 13:59:23 -0700
x86: Fix rebuild with
On Apr 5, 2013, at 2:35 PM, Bjorn Helgaas wrote:
> On Fri, Apr 5, 2013 at 2:31 PM, Chris Murphy
> wrote:
>>
>>
>> Are they in 3.9.0-0.rc5.git2.1.f19? I'm seeing a regression from 3.8.5 with
>> the radeon driver not finding BIOS ROM as well.
>>
>> -if (!new_hpage)
>> +/*
>> + * Getting a new hugepage with alloc_huge_page() (which can happen
>> + * when migration is caused by mbind()) can return ERR_PTR value,
>> + * so we need take care of the case here.
>> + */
>> +if (!new_hpage || IS_ERR_VALUE(new_hpage))
On 04/03/2013 12:19 PM, Mel Gorman wrote:
> On Tue, Apr 02, 2013 at 11:14:36AM -0400, Theodore Ts'o wrote:
>> On Tue, Apr 02, 2013 at 11:06:51AM -0400, Theodore Ts'o wrote:
>>>
>>> Can you try 3.9-rc4 or later and see if the problem still persists?
>>> There were a number of ext4 issues especially
> @@ -1277,14 +1279,10 @@ static long do_mbind(unsigned long start, unsigned
> long len,
> if (!err) {
> int nr_failed = 0;
>
> - if (!list_empty()) {
> - WARN_ON_ONCE(flags & MPOL_MF_LAZY);
> - nr_failed = migrate_pages(,
On Fri, Apr 5, 2013 at 2:54 PM, Tony Luck wrote:
> On Thu, Apr 4, 2013 at 4:46 PM, Yinghai Lu wrote:
>> It should not break ia64 by replacing acpi_numa_init with
>> acpi_numa_init_srat/acpi_numa_init_slit/acpi_num_arch_fixup.
>
> You are right - it doesn't break ia64. All my test configs still
On Fri, Apr 5, 2013 at 3:08 PM, H. Peter Anvin wrote:
> On 04/05/2013 03:06 PM, Julien Tinnes wrote:
>>
>> Speaking of IDT, and to capture some off-thread discussion here, we
>> should remember that the "SGDT" and "SIDT" instructions aren't
>> privileged on x86, so user-land can leak these out
On 04/05/2013 03:06 PM, Julien Tinnes wrote:
>
> Speaking of IDT, and to capture some off-thread discussion here, we
> should remember that the "SGDT" and "SIDT" instructions aren't
> privileged on x86, so user-land can leak these out without any way for
> the kernel to intercept that.
>
>
On Fri, Apr 5, 2013 at 12:11 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
>> can be randomized at boot.
>>
>> This makes kernel vulnerabilities harder to reliably exploit, especially
>> from remote attacks and local
On Thu, Apr 04, 2013 at 02:37:24PM -0700, Luck, Tony wrote:
> Calling memcmp() to check the value of the first byte in a string is overkill.
> Just use buf[0] == '1' or buf[0] != '1' as appropriate.
>
> Signed-off-by: Tony Luck
I'll let Jonathan take this through his tree which eventually makes
On Fri, Apr 05, 2013 at 04:05:25PM +0800, Chen Gang wrote:
>
> need break when 'target_thread' get value, firstly.
>
> 'tmp' is a stack (thread->transaction_stack),
> if 'proc' was the same between child node and parent node,
> the child would have higher priority than parent.
Are
On Fri, Apr 05, 2013 at 06:48:02PM +0100, Al Viro wrote:
> On Fri, Apr 05, 2013 at 10:31:56AM -0700, Puff . wrote:
> > No reason not to.
>
> Done (in vfs.git#for-next, should propagate in a few)
Thanks for doing that, you beat me to it.
greg k-h
--
To unsubscribe from this list: send the line
On Thu, Apr 04, 2013 at 01:32:30PM +0100, Serban Constantinescu wrote:
> Hi all,
>
> This set of patches will clean-up and fix some of the issues that arise
> with the current binder interface when moving to a 64bit kernel. All these
> changes will not affect the existing 32bit Android interface
On Fri, 05 Apr 2013 14:26:35 -0700
Joe Perches wrote:
> > +/* in the order of enum rapl_primitives */
> > +static struct rapl_primitive_info rpi[] = {
>
> const?
I do need to override one entry for a special case. The hardware uses a
different bit location for the same lock functionality.
On Thu, Apr 4, 2013 at 4:46 PM, Yinghai Lu wrote:
> It should not break ia64 by replacing acpi_numa_init with
> acpi_numa_init_srat/acpi_numa_init_slit/acpi_num_arch_fixup.
You are right - it doesn't break ia64. All my test configs still
build. Machines both with and without NUMA still boot
On Fri, Apr 05, 2013 at 02:33:40PM -0700, Jacob Pan wrote:
> On Fri, 5 Apr 2013 13:23:09 -0700
> Greg KH wrote:
>
> > On Wed, Apr 03, 2013 at 10:35:51AM -0700, Jacob Pan wrote:
> > > On Wed, 3 Apr 2013 09:35:09 -0700
> > > Greg KH wrote:
> > >
> > > > On Tue, Apr 02, 2013 at 09:48:18PM -0700,
Hey Thomas,
I seem to be running in to smpboot_thread_fn()'s
BUG_ON(td->cpu != smp_processor_id());
pretty regularly, both at boot and if I boot with maxcpus=x and then
online the CPUs from sysfs after boot. It's a 160-logical-cpu system,
so it's quite a beast. I _seem_ to be hitting
On Fri, Apr 05, 2013 at 01:07:25AM -0400, Chris Frey wrote:
> I'd like to duplicate these settings, so that it does not timeout, but
> when I use:
>
> libata.force=ata1:udma/44,ata1:pio4
I figured out what I was doing wrong. It should be:
libata.force=1:udma/44,1:pio4
- Chris
On Fri, Apr 05, 2013 at 02:26:35PM -0700, Joe Perches wrote:
> On Fri, 2013-04-05 at 14:02 -0700, Jacob Pan wrote:
> > +static ssize_t store_event_control(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf,
> > +
On Fri, 5 Apr 2013 13:23:09 -0700
Greg KH wrote:
> On Wed, Apr 03, 2013 at 10:35:51AM -0700, Jacob Pan wrote:
> > On Wed, 3 Apr 2013 09:35:09 -0700
> > Greg KH wrote:
> >
> > > On Tue, Apr 02, 2013 at 09:48:18PM -0700, Jacob Pan wrote:
> > > > > Let's step back and start over, what exactly are
Well, I have the "is_dup_page()" commented out...when RDMA is
activated.
Is there something else in QEMU that could be touching the page that I
don't know about?
- Michael
On 04/05/2013 05:03 PM, Roland Dreier wrote:
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
wrote:
Sorry,
On Fri, 2013-04-05 at 14:02 -0700, Jacob Pan wrote:
> RAPL(Running Average Power Limit) interface provides platform software
> with the ability to monitor, control, and get notifications on SOC
> power consumptions. Since its first appearance on Sandy Bridge, more
> features have being added to
On Fri, 5 Apr 2013, Rob Herring wrote:
> On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> >
> >> This is what happens:
> >>
> >> - No Xen
> >> Xen is not running on the platform and a Xen hypervisor node is not
> >> available on device tree.
> >>
On Tue, Apr 02, 2013 at 12:21:02PM -0400, Sasha Levin wrote:
> Hi all,
>
> It seems that trying to fuzz bcache without any devices triggers a BUG:
>
> That BUG looks very intentional there, any reason for adding it instead of
> exiting
> if there aren't any devices?
The fuzz tester is meant to
On 04/05/2013 05:05 PM, Werner Almesberger wrote:
> Alan Ott wrote:
>> Prevent set_channel() from getting called every time a packet is sent. This
>> looks like it was an oversight.
> at86rf230.c and derivatives avoid this problem by setting
> phy->current_* in the *_channel function.
>
> But I'd
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
> This patch extends check_range() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with migrate_pages(2) after
> applying the enablement patch which comes later in this series.
>
> Note that for larger hugepages (covered by pud
There is no any error handling in dgrp_create_class_sysfs_files().
The patch adds code to check return values and propagate them to
dgrp_init_module().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/staging/dgrp/dgrp_common.h |
On 04/05/2013 10:50 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> From: Lior Amsalem
>>
>> In order to be able to support he LPAE, the internal registers virtual
>> base must be aligned to 2MB.
>>
>> Signed-off-by: Lior Amsalem
>> Signed-off-by: Gregory CLEMENT
>
The warning about local_bh_enable inside IRQ happens when disconnecting a
virtual NIC.
The reason for the warning is -- netif_tx_disable() is called when the NIC
is disconnected. And it's called within irq context. netif_tx_disable() calls
local_bh_enable() which displays warning if in irq.
The
In some cases, the VM_PKT_COMP message can arrive later than RNDIS completion
message, which will free the packet memory. This may cause panic due to access
to freed memory in netvsc_send_completion().
This patch fixes this problem by removing rndis_filter_send_request_completion()
from the code
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
> Due to the previous patch, soft_offline_huge_page() switches to use
> migrate_pages(), and migrate_huge_page() is not used any more.
> So let's remove it.
>
> Signed-off-by: Naoya Horiguchi
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this
(3/27/13 9:00 AM), Michal Hocko wrote:
> On Tue 26-03-13 16:35:35, Naoya Horiguchi wrote:
> [...]
>> The differences is that migrate_huge_page() has one hugepage as an argument,
>> and migrate_pages() has a pagelist with multiple hugepages.
>> I already told this before and I'm not sure it's
On 04/05/2013 10:46 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> The Armada XP SoCs have LPAE support. This is the second version patch
>> set whixh allow to run kernel on this SoCs with LPAE support.
>>
>> The biggest changes are the conversion of the device tree
On Fri, Apr 05, 2013 at 02:02:04PM -0700, Jacob Pan wrote:
> RAPL(Running Average Power Limit) interface provides platform software
> with the ability to monitor, control, and get notifications on SOC
> power consumptions. Since its first appearance on Sandy Bridge, more
> features have being
Alan Ott wrote:
> Prevent set_channel() from getting called every time a packet is sent. This
> looks like it was an oversight.
at86rf230.c and derivatives avoid this problem by setting
phy->current_* in the *_channel function.
But I'd agree that it's nicer to do this in one place, not in
every
On Fri, Apr 05, 2013 at 02:02:03PM -0700, Jacob Pan wrote:
> Changes since V2:
> - use 'struct device' instead of raw kobject to represent
> RAPL domains
> - changed eventfd control interface to use event string
> instead of passing file descriptors that cannot be
>
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
wrote:
> Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
> (i.e. trying to register RDMA memory while using a cgroup swap limit cause
> the process get killed).
>
> But the GIFT flag patch works (my understanding is that
RAPL(Running Average Power Limit) interface provides platform software
with the ability to monitor, control, and get notifications on SOC
power consumptions. Since its first appearance on Sandy Bridge, more
features have being added to extend its usage. In RAPL, platforms are
divided into domains
Changes since V2:
- use 'struct device' instead of raw kobject to represent
RAPL domains
- changed eventfd control interface to use event string
instead of passing file descriptors that cannot be
authenticated in sysfs directory
- clean ups
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
> That didn't produce anything. I'll run some bisections over the
> weekend and see what I can sort out.
*Ugh*
I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry
and exit from close_pdeo(). If that doesn't show
On 04/05/2013 10:41 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> When LPAE is activated on Armada XP, all registers and IOs are still
>> 32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
>> That means that all the DMA transfer are restricted to
Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:
BUG: using smp_processor_id() in preemptible [] code: sh/111
caller is arch_timer_cpu_notify+0x14/0xc8
This happens because sometimes
On 04/05/2013 12:36 PM, Al Viro wrote:
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote:
On 04/04/2013 03:44 PM, Al Viro wrote:
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote:
Ok I am cloning the tree now.
It does look like the patches would conflict.
I'll run
To be more specific, here's what I did:
1. apply kernel module patch - re-insert module
1. QEMU does: ibv_reg_mr(IBV_ACCESS_GIFT | IBV_ACCESS_REMOTE_READ)
2. Start the RDMA migration
3. Migration completes without any errors
This test does *not* work with a cgroup swap limit, however.
On Fri, Apr 05, 2013 at 12:56:09PM -0700, Greg Kroah-Hartman wrote:
> Which methods do you mean here?
file->f_op->some_method()
> The vfs core would call start_using(), or would filesystems / drivers
> need to do this?
The former; we have relatively few places that call file_operations
members
Sorry, I was wrong. ignore the comments about cgroups. That's still
broken. (i.e. trying to register RDMA memory while using a cgroup swap
limit cause the process get killed).
But the GIFT flag patch works (my understanding is that GIFT flag allows
the adapter to transmit stale memory
On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Stefano Stabellini wrote:
>
>> This is what happens:
>>
>> - No Xen
>> Xen is not running on the platform and a Xen hypervisor node is not
>> available on device tree.
>> Everything keeps working seamlessly, this patch doesn't
On Friday 05 April 2013, Gregory CLEMENT wrote:
> From: Lior Amsalem
>
> In order to be able to support he LPAE, the internal registers virtual
> base must be aligned to 2MB.
>
> Signed-off-by: Lior Amsalem
> Signed-off-by: Gregory CLEMENT
This is a surprising limitation. Can you extend the
On 04/05/2013 10:43 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> Signed-off-by: Gregory CLEMENT
>
> The patch looks good but the description is a bit short.
>
It cannot be more brief! :)
I explained the purpose of this patch in the cover letter and forgot to
On Friday 05 April 2013, Gregory CLEMENT wrote:
> The Armada XP SoCs have LPAE support. This is the second version patch
> set whixh allow to run kernel on this SoCs with LPAE support.
>
> The biggest changes are the conversion of the device tree file to 64
> bits in order to be able to use more
On Friday 05 April 2013, Gregory CLEMENT wrote:
> From: Thomas Petazzoni
>
> Signed-off-by: Thomas Petazzoni
This should have a description, even though it's completely trivial.
I would also recommend moving this patch first, as the general rule
is to do cleanups first.
Arnd
--
To
On Friday 05 April 2013, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT
The patch looks good but the description is a bit short.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
wrote:
> I also removed the IBV_*_WRITE flags on the sender-side and activated
> cgroups with the "memory.memsw.limit_in_bytes" activated and the migration
> with RDMA also succeeded without any problems (both with *and* without GIFT
> also
On Fri, Apr 05, 2013 at 01:19:39PM -0700, Julien Tinnes wrote:
> I think it'd be perfectly ok for OOPS to print out the kernel base.
Yeah, ok, this still would need some massaging of the oops output per
script, but it shouldn't be a big problem.
Also, you probably need to make clear in the oops
During the ACPI S3 resume path the trampoline code handles it already.
During the ACPI S3 suspend phase (acpi_suspend_lowlevel) we set:
early_gdt_descr.address = (..)get_cpu_gdt_table(smp_processor_id());
which is then used during the resume path and has the same exact
value as what the
During the ACPI S3 suspend, we store the GDT in the wakup_header (see
wakeup_asm.s) field called 'pmode_gdt'.
Which is then used during the resume path and has the same exact
value as what the store/load_gdt do with the saved_context
(which is saved/restored via save/restore_processor_state()).
Long long time ago (way back in October 2012), when I posted the patches
that would make it possible to do ACPI S3 with Xen, Peter pointed out that:
"excellent set of pvops calls that should be nukable to Kingdom Come. There
is no reason, ever, to read the IDT and GDT from the kernel... the kernel
1 - 100 of 1014 matches
Mail list logo
