On Mon, 18 Nov 2013, One Thousand Gnomes wrote:
> On Mon, 18 Nov 2013 11:41:22 -0500 (EST)
> Vince Weaver wrote:
>
> > On Mon, 18 Nov 2013, Peter Zijlstra wrote:
> >
> > > On Fri, Nov 15, 2013 at 01:04:23PM -0500, Vince Weaver wrote:
> > > >
> > > > (figured out the minicom issue).
> > > >
>
All DATA/NODE/META bio buffers in superblock is protected by
'sbi->write_mutex', but each bio buffer area is independent, So we
should split write_mutex to three for DATA/NODE/META.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h|2 +-
fs/f2fs/segment.c |8
fs/f2fs/super.c |
Hi Linus,
Today's linux-next merge of the gpio tree got a conflict in
drivers/gpio/gpiolib.c between commit 7b1998116bbb ("ACPI / driver core:
Store an ACPI device pointer in struct acpi_dev_node") from the pm tree
and commit f760f1967ee8 ("gpiolib: use dedicated flags for GPIO
properties") from
Hi
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Monday, November 18, 2013 5:11 PM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net; '谭姝'
> Subject: RE: [f2fs-dev] [PATCH V2 1/2]
The prototype for static GPIO lookup functions has been updated to use
an explicit type for GPIO lookup flags. Unfortunately the definition of
of_find_gpio() when CONFIG_OF is not defined has been omitted, which
triggers a warning. This patch fixes this.
Signed-off-by: Alexandre Courbot
--
This
On 11/19/2013 08:04 AM, Steven Rostedt wrote:
>
> I'll start out saying that this email was a complete oops. I only kept
> it around for reference, as this didn't fix the bug we were seeing, and
> I used this email to just document what I initially thought.
>
Can you describe the panic
On Fri, Nov 15, 2013 at 01:52:35PM +0200, Mika Westerberg wrote:
> On Thu, Oct 24, 2013 at 09:33:50PM -0600, Bjorn Helgaas wrote:
> > On Wed, Oct 23, 2013 at 11:53 PM, Yinghai Lu wrote:
> > > On Tue, Oct 22, 2013 at 8:32 PM, Bjorn Helgaas
> > > wrote:
> > >> On Thu, Oct 17, 2013 at 7:59 AM,
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>
> And IOMMU support is very flaky with kdump. And IOMMU's can be turned
> off at command line. And that would force one to remove crahkernel_low=0.
> So change of one command line option forces change of another. It is
> complicated.
>
> Also there
On Mon, Nov 18, 2013 at 04:38:03PM -0800, Linus Torvalds wrote:
> Hmm.. Al - this looks like a major oversight, but it also looks like
> the wrong place to initialize count/from in, just because it doesn't
> follow any sane patterns.
>
> My gut feel is that this needs more cleanup and some sane
On Mon, 18 Nov 2013, Michal Hocko wrote:
> > A subset of applications that wait on memory.oom_control don't disable
> > the oom killer for that memcg and simply log or cleanup after the kernel
> > oom killer kills a process to free memory.
> >
> > We need the ability to do this for system oom
This is version 3 of the watchdog driver for the BCM281xx family of mobile
SoCs.
Changes since version 2:
- BCM_KONA_WDT_NAME: "bcm-kona-wdt" -> "bcm_kona_wdt"
- Don't initialize static variable
- Remove '{'/'}' from single-line statements
- busy_count retains the maximum loop count of the
This commit adds support for the watchdog timer used on the BCM281xx
family of SoCs.
Signed-off-by: Markus Mayer
Reviewed-by: Matt Porter
---
drivers/watchdog/Kconfig| 22 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm_kona_wdt.c | 366
This commit enables the watchdog driver for the BCM281xx family of SoCs.
Signed-off-by: Markus Mayer
Reviewed-by: Matt Porter
---
arch/arm/configs/bcm_defconfig |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index
On Mon, 18 Nov 2013, Michal Hocko wrote:
> > Even though the situation may not require a kill, the user still wants
> > to know that the memory hard limit was breached and the isolation
> > broken in order to prevent a kill. We just came really close and the
>
> You can observe that you are
On Tue, Nov 19, 2013 at 12:18:41AM +, Charley (Hao Chuan) Chu wrote:
> The buffer count is not initialized when a new buffer is allocated.
>
> It cause kernel crash with "Unable to handle kernel paging
> request..." error in __copy_to_user_std(). It happens when a
> memory allocation
On Mon, 18 Nov 2013, Michal Hocko wrote:
> > > When current has a pending SIGKILL or is already in the exit path, it
> > > only needs access to memory reserves to fully exit. In that sense, the
> > > memcg is not actually oom for current, it simply needs to bypass memory
> > > charges to exit
On Thu, Oct 24, 2013 at 11:51 AM, Viktar Palstsiuk
wrote:
>> Isolated i2c specific parts and
>> added spi bindings for the sx151x devices.
>>
>> Signed-off-by: Viktar Palstsiuk
>>
>> diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
>> index d2983e9..bee1661 100644
>> ---
On Wed, Oct 23, 2013 at 09:29:24PM +0800, Xiao Guangrong wrote:
> Change the algorithm to:
> 1) always add new desc to the first desc (pointed by parent_ptes/rmap)
>that is good to implement rcu-nulls-list-like lockless rmap
>walking
>
> 2) always move the entry in the first desc to the
From: Andi Kleen
cpusets has settings per cpu sets to enable NUMA node
interleaving for the slab cache or for the file cache.
These are quite useful, especially the setting for interleaving
the file page cache. This avoids the problem that some
program doing IO fills up a node completely and
On Tue, 19 Nov 2013 00:42:09 +0100
Peter Zijlstra wrote:
> I briefly talked to Thomas about this earlier today and we need to fix
> this at a lower level -- the quick 'n dirty solution is to add 1 jiffy
> down in the timer-wheel when we enqueue these things.
That can lead to situations like the
Hi
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Monday, November 18, 2013 5:12 PM
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH 1/2] f2fs: clean up the
Hmm.. Al - this looks like a major oversight, but it also looks like
the wrong place to initialize count/from in, just because it doesn't
follow any sane patterns.
My gut feel is that this needs more cleanup and some sane helper
function that always initializes those fields when allocating a new
On 11/18/13, 5:24 PM, Namhyung Kim wrote:
What now? Can we add the mmap path as an option?
I'd say an option is always a possibility, but someone please try
what happens if you use stupid large events (dwarf stack copies) on
PERF_COUNT_SW_PAGE_FAULTS (.period=1) while recording with mmap().
On Mon, Nov 18, 2013 at 02:29:24PM -0800, Dave Hansen wrote:
> On 11/18/2013 01:56 PM, Naoya Horiguchi wrote:
> >> > Why bother trying to "optimize" it?
> > I thought that if we call cond_resched() too often, the copying thread can
> > take too long in a heavy load system, because the copying
No new configuration, just a 'compatible' string and documentation.
Signed-off-by: NeilBrown
diff --git a/Documentation/devicetree/bindings/iio/gyro/itg3200.txt
b/Documentation/devicetree/bindings/iio/gyro/itg3200.txt new file mode 100644
index ..4581620632df
--- /dev/null
+++
Hi Ingo,
On Mon, 18 Nov 2013 10:40:36 +0100, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
>> On Fri, Nov 15, 2013 at 09:41:53AM -0700, David Ahern wrote:
>> > On 11/13/13, 4:34 AM, Peter Zijlstra wrote:
>> > >>>one option here is not allow page faults and system wide system calls.
>> >
On Fri, Nov 15, 2013 at 03:09:13PM +0800, Xiao Guangrong wrote:
> On 11/15/2013 02:39 AM, Marcelo Tosatti wrote:
> > On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
> >>
> >> Hi Marcelo,
> >>
> >> On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
> >>
> >>>
> >>> Any code location
The buffer count is not initialized when a new buffer is allocated.
It cause kernel crash with "Unable to handle kernel paging
request..." error in __copy_to_user_std(). It happens when a
memory allocation failure in the while(1)-loop, which left the
buffer count (m->count) is larger than
Hi Arnaldo,
On Mon, 18 Nov 2013 10:57:00 -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 18, 2013 at 02:34:53PM +0900, Namhyung Kim escreveu:
>> If --show-task option is given, also print internal COMM, FORK and
>> EXIT events. It would be helpful for debugging.
>
> Humm, --show-task-events
When Jiri Olsa was writing a function callback for
scsi_trace_parse_cdb(), he thought that the traceevent library had a
bug in it because he was getting this error:
Error: expected ')' but read ','
Error: expected ')' but read ','
Error: expected ')' but read ','
Error: expected ')' but
> This patch adds the support of the I2C_SMBUS_I2C_BLOCK_DATA
> transaction type for the iSMT SMBus Controller.
>
> Signed-off-by: Robert Valiquette
> ---
> --- a/drivers/i2c/busses/i2c-ismt.c 2013-11-14 11:36:15.830322000 -0500
> +++ b/drivers/i2c/busses/i2c-ismt.c 2013-11-14
Greeting To You!
My name is Miss.Azeeza Ikraam a medical doctor working with NATO currently in
Syria.I got your esteemed contact during my comprehensive research for a
reliable and trustworthy individual in your country. I will need your help to
invest in your country, I have some money I made
On Thu, Nov 14, 2013 at 11:09:03PM -0600, Rob Landley wrote:
> On 10/28/2013 08:05:11 AM, Henrik Austad wrote:
> >Hi Rob, Jiri
> >Hacking away at python shows me that of the 254 subfolders 57 has
> >outdated
> >00-INDEX, either with missing files, or files that has been
> >removed. (see
> >list
Hi Trond,
After merging the nfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from fs/nfs/dns_resolve.c:52:0:
fs/nfs/netns.h:28:15: error: 'NFS4_MAX_MINOR_VERSION' undeclared here (not in a
function)
int cb_users[NFS4_MAX_MINOR_VERSION + 1];
On Mon, Nov 18, 2013 at 03:10:21PM +0100, Peter Zijlstra wrote:
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -746,13 +746,23 @@ void irq_exit(void)
> #endif
>
> account_irq_exit_time(current);
> - trace_hardirq_exit();
> sub_preempt_count(HARDIRQ_OFFSET);
> - if
On 11/13/2013 12:25 PM, tip-bot for Peter Zijlstra wrote:
> Commit-ID: 911b2898b3c9fe0048e9485ad1629ed4fce330fd
> Gitweb: http://git.kernel.org/tip/911b2898b3c9fe0048e9485ad1629ed4fce330fd
> Author: Peter Zijlstra
> AuthorDate: Mon, 11 Nov 2013 18:21:56 +0100
> Committer: Ingo Molnar
>
On Monday, November 18, 2013 03:46:34 PM Linus Torvalds wrote:
> On Mon, Nov 18, 2013 at 11:38 AM, Wolfram Sang wrote:
> >
> > here is the pull request from the i2c subsystem for 3.13:
>
> So while resolving some fairly trivial conflicts here, I noticed that
> commit a76e9bd89ae7 ("i2c:
On Mon, Nov 18, 2013 at 3:30 PM, James Morris wrote:
> On Mon, 18 Nov 2013, Josh Boyer wrote:
>>
>> Unless I'm missing something, I don't think this has landed in Linus'
>> tree yet. Linus, did this pull request get NAKed or fall through the
>> cracks?
>
> I think Linus is on vacation and
2013/11/19 Jens Axboe :
> On 11/18/2013 06:11 AM, Akinobu Mita wrote:
>> The data type of max_sectors and max_hw_sectors in queue settings are
>> unsigned int. But these values are passed to __bio_add_page() as an
>> argument whose data type is unsigned short. In the worst case such as
>>
On 15 November 2013 20:27, Guenter Roeck wrote:
> On 11/15/2013 12:58 PM, Markus Mayer wrote:
>>
>> This commit adds support for the watchdog timer used on the BCM281xx
>> family of SoCs.
>>
>> Signed-off-by: Markus Mayer
>
>
> You are using two different e-mail addresses, the one here and the
On 11/18/2013 04:43 AM, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 07:40:47PM +0900, Alexandre Courbot wrote:
>> FUSE clock is enabled by most bootloaders, but we cannot expect
>> it to be on in all contexts (e.g. kexec).
>>
>> This patch adds a FUSE clkdev to all Tegra platforms and makes
On Mon, Nov 18, 2013 at 11:38 AM, Wolfram Sang wrote:
>
> here is the pull request from the i2c subsystem for 3.13:
So while resolving some fairly trivial conflicts here, I noticed that
commit a76e9bd89ae7 ("i2c: attach/detach I2C client device to the ACPI
power domain") that I got earlier
On Mon, 18 Nov 2013 15:27:46 -0800 Andrew Morton
wrote:
> On Sun, 17 Nov 2013 08:06:03 +1100 NeilBrown wrote:
>
> > It would be reasonable to assume that
> >
> > wait_for_completion_timeout(>auxadc_done,
> > msecs_to_jiffies(5));
> >
> > would wait at least 5 msecs for the auxadc_done
On Fri, 2013-11-01 at 15:02 +0100, Joerg Roedel wrote:
> On Sun, Oct 27, 2013 at 12:06:29AM -0700, Adam Williamson wrote:
> > On Sat, 2013-10-26 at 11:15 +0200, Ingo Molnar wrote:
> > > CONFIG_IRQ_REMAP=y
> >
> > Agh, sorry - I had this down in my mind as a boot time parameter, not a
> >
On Mon, Nov 18, 2013 at 03:27:46PM -0800, Andrew Morton wrote:
> On Sun, 17 Nov 2013 08:06:03 +1100 NeilBrown wrote:
>
> > It would be reasonable to assume that
> >
> > wait_for_completion_timeout(>auxadc_done,
> > msecs_to_jiffies(5));
> >
> > would wait at least 5 msecs for the
On Mon, Nov 18, 2013 at 11:19:08PM +0100, Arend van Spriel wrote:
> what about:
>
> config BRCMSMAC
> tristate "Broadcom IEEE802.11n PCIe SoftMAC WLAN driver"
> depends on MAC80211
> depends on BCMA_POSSIBLE
> + select LEDS_CLASS if BCMA_DRIVER_GPIO
> select BCMA
Thank you for testing this RFC patch. It is great to have confirmation that
the code works in a different test environment.
You asked: "What is the status of this patch?"
I have made a few changes since the RFC version of this patch:
1. Consolidated all of the operational code into the
Hi Steve,
On Mon, 18 Nov 2013 17:26:56 -0600 Steve French wrote:
>
> It is there now. I had just (very briefly) deleted it for a few
> minutes to update the branch with David Disseldorp's ack on an earlier
> patch so you might have tried in the very few minutes it was gone
> (Murphy's law?)
On Mon, Nov 18, 2013 at 03:23:01PM -0800, Joe Perches wrote:
> Functions like this one are evil:
>
> void foo()
> {
> ...
> }
>
> Because these functions allow variadic arguments without
> checking the arguments at all.
>
> Original-patch-by: Richard Weinberger
> Signed-off-by: Joe
On Sun, 17 Nov 2013 08:06:03 +1100 NeilBrown wrote:
> It would be reasonable to assume that
>
> wait_for_completion_timeout(>auxadc_done, msecs_to_jiffies(5));
>
> would wait at least 5 msecs for the auxadc_done to complete. But it does not.
> With a HZ of 200 or less,
It is there now. I had just (very briefly) deleted it for a few
minutes to update the branch with David Disseldorp's ack on an earlier
patch so you might have tried in the very few minutes it was gone
(Murphy's law?)
On Mon, Nov 18, 2013 at 5:20 PM, Stephen Rothwell wrote:
> Hi all,
>
>
On Mon, 18 Nov 2013, Josh Boyer wrote:
> On Wed, Nov 6, 2013 at 7:51 PM, James Morris wrote:
> > In this patchset, we finally get an SELinux update, with Paul Moore taking
> > over as maintainer of that code.
> >
> > Also a significant update for the Keys subsystem, as well as maintenance
> >
Functions like this one are evil:
void foo()
{
...
}
Because these functions allow variadic arguments without
checking the arguments at all.
Original-patch-by: Richard Weinberger
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 9 +
1 file changed, 9 insertions(+)
Hi all,
Fetching the cifs tree produces this error:
fatal: Couldn't find remote ref refs/heads/for-next
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpD2LnzqNOaD.pgp
Description: PGP signature
On 11/18/2013 10:25 AM, Michal Marek wrote:
> MFD_AS3722 can only be builtin, so it needs I2C builtin as well.
> With I2C=m, we get:
>
> drivers/mfd/as3722.c:372: undefined reference to `devm_regmap_init_i2c'
> drivers/built-in.o: In function `as3722_i2c_driver_init':
> drivers/mfd/as3722.c:444:
On Mon, 2013-11-18 at 22:39 +0100, Rafael J. Wysocki wrote:
> On Monday, November 18, 2013 11:10:05 AM Toshi Kani wrote:
> > On Thu, 2013-11-14 at 00:16 +0100, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Since the PCI host bridge scan handler does not set hotplug.enabled,
> And accessing the emergency reserves means we are definitely no longer
> A-OK, this is not comparable to the first direct reclaim invocation.
>
> We exhausted our options and we got really lucky. It should not be
> considered the baseline and a user listening for "OOM conditions"
> should be
On Mon, 18 Nov 2013 11:41:22 -0500 (EST)
Vince Weaver wrote:
> On Mon, 18 Nov 2013, Peter Zijlstra wrote:
>
> > On Fri, Nov 15, 2013 at 01:04:23PM -0500, Vince Weaver wrote:
> > >
> > > (figured out the minicom issue).
> > >
> > > Anyway while trying to reproduce the last bug I instead got
From: "Kirill A. Shutemov"
Date: Mon, 18 Nov 2013 10:49:41 +0200 (EET)
> Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the final tree, today's linux-next build (sparc64 defconfig)
>> failed like this:
>>
>> arch/sparc/mm/init_64.c: In function 'pte_alloc_one':
>>
From: "Kirill A. Shutemov"
Date: Mon, 18 Nov 2013 11:44:09 +0200
> Commit ea1e7ed33708 triggers build regression on sparc64.
>
> include/linux/mm.h:1391:2: error: implicit declaration of function
> 'pgtable_cache_init' [-Werror=implicit-function-declaration]
>
On Mon, Nov 18, 2013 at 3:34 PM, Grygorii Strashko
wrote:
> On 11/18/2013 03:11 PM, Linus Walleij wrote:
>> I think we recently established that map creating cannot be done
>> in gpio_to_irq* functions as that will not work properly if you request
>> an IRQ from device tree without first
> I doubt this is caused by a race condition; the first hangup would do most
> of the destruction regardless, and a second hangup can't really race with
> the first because of the tty_lock() held for most of the hangup.
>
> In any event, it's worth discovering what state a subsequent hangup can
>
On Sun, Nov 17, 2013 at 05:48:14PM -0800, anish singh wrote:
> On Sun, Nov 17, 2013 at 5:19 PM, 韩磊 wrote:
> > when we delete,add,search,amend the list_head,should we use spinlock
> > or rcu in case of conflicit to list_head???
> There is no implicit locking when we use 'list' api's.You should
On Mon, 18 Nov 2013 11:57:42 + Mark Rutland wrote:
> On Fri, Nov 01, 2013 at 04:48:54AM +, NeilBrown wrote:
> >
> >
> > No new configuration, just a 'compatible' string and documentation.
> >
> > Signed-off-by: NeilBrown
> >
> > diff --git
On Sat, Nov 16, 2013 at 02:01:17AM +0200, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
On Wed, Nov 13, 2013 at 09:01:57PM +0100, Thomas Gleixner wrote:
> On Wed, 13 Nov 2013, Paul E. McKenney wrote:
> > On Wed, Nov 13, 2013 at 11:23:38AM -0500, Steven Rostedt wrote:
> > > On Wed, 13 Nov 2013 08:18:29 -0800
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Wed, Nov 13, 2013 at
Functions like this one are evil:
void foo()
{
...
}
Signed-off-by: Richard Weinberger
CC: h...@zytor.com
---
scripts/checkpatch.pl | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 61090e0..a1b846d 100755
---
Am Montag, 18. November 2013, 14:36:22 schrieb Joe Perches:
> On Mon, 2013-11-18 at 23:31 +0100, Richard Weinberger wrote:
> > Functions like this one are evil:
> >
> > void foo()
> > {
> >
> > ...
> >
> > }
> >
> > Signed-off-by: Richard Weinberger
> > CC: h...@zytor.com
>
> I won't
On Mon, 18 Nov 2013 18:20:54 +0100 Nicolas Ferre
wrote:
> From: Linus Pizunski
>
> Update month and day of month to the alarm month/day instead
> of current day/month when setting the RTC alarm mask.
>
> Signed-off-by: Linus Pizunski
> Acked-by: Nicolas Ferre
I changed this to
On Mon, 2013-11-18 at 23:31 +0100, Richard Weinberger wrote:
> Functions like this one are evil:
>
> void foo()
> {
> ...
> }
>
> Signed-off-by: Richard Weinberger
> CC: h...@zytor.com
I won't take simple resubmissions without updating
based on the notes I gave you.
And now, this should
On 11/18/2013 09:40 PM, Borislav Petkov wrote:
On Mon, Nov 18, 2013 at 02:32:50PM +0100, Borislav Petkov wrote:
On Mon, Nov 18, 2013 at 12:58:58PM +0100, Rafał Miłecki wrote:
Borislav: I think I didn't get your original patch.
Forget it, I'll send a better one later.
Ok, let's try another
On Mon, 18 Nov 2013 21:04:36 + (GMT) Jason Baron wrote:
> The panic_timeout value can be set via the command line option 'panic=x', or
> via
> /proc/sys/kernel/panic, however that is not sufficient when the panic occurs
> before we are able to set up these values. Thus, add a
On 11/18/2013 01:56 PM, Naoya Horiguchi wrote:
>> > Why bother trying to "optimize" it?
> I thought that if we call cond_resched() too often, the copying thread can
> take too long in a heavy load system, because the copying thread always
> yields the CPU in every loop.
I think you're confusing
On Mon, 2013-11-18 at 14:54 +, Russell King - ARM Linux wrote:
> On Mon, Nov 18, 2013 at 04:30:17PM +0200, Andy Shevchenko wrote:
> > On Mon, 2013-11-18 at 13:16 +0100, Florian Meier wrote:
> > > >> + uint32_t chans_available;
> > > >
> > > > Why uint32_t?
> > >
> > > Because it is a
Issues Xen hypercall subop XENMEM_get_vnumainfo and sets the
NUMA topology, otherwise sets dummy NUMA node and prevents
numa_init from calling other numa initializators as they dont
work with pv guests.
Signed-off-by: Elena Ufimtseva
---
arch/x86/include/asm/xen/vnuma.h | 12
On Mon, 2013-11-18 at 13:14 -0800, H. Peter Anvin wrote:
> On 11/18/2013 12:25 PM, Elena Ufimtseva wrote:
> > +/* Checks if hypercall is supported */
> > +bool xen_vnuma_supported()
>
> This isn't C++...
> http://lwn.net/Articles/487493/
>
> There are several more things in this patchset that
> SDHCI_QUIRK2_BCM57785_CR:
> Bit twiddles some Broadcom-specific registers and supresses an error
> about the 64k bar0.
> I think this can be done without spending a global SDHCI quirk bit. This
> is just a one-time setup that needs to be done, isn't it? It's hard
> to tell since there's
Xen vnuma introduction.
The patchset introduces vnuma to paravirtualized Xen guests
runnning as domU.
Xen subop hypercall is used to retreive vnuma topology information.
Bases on the retreived topology from Xen, NUMA number of nodes,
memory ranges, distance table and cpumask is being set.
If
On Fri, Nov 15, 2013 at 08:27:58PM +0800, ZHAO Gang wrote:
> 1. change function name: et1310_phy_power_down -> et1310_phy_power_switch
> change function name to better describe its functionality.
>
> 2. as TODO file suggested, do this sort of things to reduce split lines
> struct fbr_lookup *fbr;
Enables numa if vnuma topology hypercall is supported and it is domU.
Signed-off-by: Elena Ufimtseva
---
arch/x86/xen/setup.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 68c054f..0aab799 100644
---
From: "Paul E. McKenney"
If CONFIG_RCU_NOCB_CPU_ALL=y, then rcu_needs_cpu() will always
return false, however, the current version nevertheless checks
for RCU callbacks. This commit therefore creates a static inline
implementation of rcu_needs_cpu() that unconditionally returns false
when
From: "Paul E. McKenney"
If CONFIG_RCU_NOCB_CPU_ALL=y, then no CPU will ever have RCU callbacks
because these callbacks will instead be handled by the rcuo kthreads.
However, the current version of RCU_FAST_NO_HZ nevertheless checks for RCU
callbacks. This commit therefore creates static inline
From: "Paul E. McKenney"
If CONFIG_RCU_NOCB_CPU_ALL=y, then rcu_is_nocb_cpu() will always
return true, however, the current version nevertheless checks
rcu_nocb_mask. This commit therefore creates a static inline
implementation of rcu_is_nocb_cpu() that unconditionally returns
true when
Hello!
This series provides some minor latency optimizations for kernels that
build with CONFIG_RCU_NOCB_CPU_ALL=y:
1. Create a static inline implementation of rcu_is_nocb_cpu() that
unconditionally returns true when CONFIG_RCU_NOCB_CPU_ALL=y.
2. Create a static inline
On Mon, Nov 18, 2013 at 12:48:54PM -0800, Dave Hansen wrote:
> On 11/18/2013 12:20 PM, Naoya Horiguchi wrote:
> >> > Really, though, a lot of things seem to have MAX_ORDER set up so that
> >> > it's at 256MB or 512MB. That's an awful lot to do between rescheds.
> > Yes.
> >
> > BTW, I found that
On Wednesday 16 October 2013 14:57:34 Herbert Xu wrote:
> On Tue, Oct 08, 2013 at 12:04:09PM -0700, Tony Lindgren wrote:
> > * Pali Rohár [130920 06:33]:
> > > This driver provides kernel-side support for the Random
> > > Number Generator hardware found on OMAP34xx processors.
> > >
> > > This
On Mon, Nov 18, 2013 at 4:14 PM, H. Peter Anvin wrote:
> On 11/18/2013 12:25 PM, Elena Ufimtseva wrote:
>> +/* Checks if hypercall is supported */
>> +bool xen_vnuma_supported()
>
> This isn't C++...
>
> http://lwn.net/Articles/487493/
>
> There are several more things in this patchset that get
On 11/15/2013 11:03 PM, Richard Cochran wrote:
> On Thu, Nov 14, 2013 at 03:50:40PM +0100, Miroslav Lichvar wrote:
>
>> include/linux/timekeeper_internal.h | 4 +
>> kernel/time/timekeeping.c | 209
>> +---
>> 2 files changed, 31 insertions(+), 182
On Monday, November 18, 2013 11:10:05 AM Toshi Kani wrote:
> On Thu, 2013-11-14 at 00:16 +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Since the PCI host bridge scan handler does not set hotplug.enabled,
> > the check of it in acpi_bus_device_eject() effectively prevents
From: Zhi Yong Wu
Date: Mon, 18 Nov 2013 21:19:27 +0800
> From: Zhi Yong Wu
>
> It is more appropriate to use # of queue pairs currently used by
> the driver instead of a magic value.
>
> Signed-off-by: Zhi Yong Wu
> Acked-by: Michael S. Tsirkin
Applied, thanks.
--
To unsubscribe from this
These two patches are cleanups, please resubmit them after the merge
window closes and the net-next tree opens back up.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 11/18/2013 12:25 PM, Elena Ufimtseva wrote:
> +/* Checks if hypercall is supported */
> +bool xen_vnuma_supported()
This isn't C++...
http://lwn.net/Articles/487493/
There are several more things in this patchset that get flagged by
checkpatch, but apparently this rather common (and rather
On 11/18/13, 2:55 AM, Adrian Hunter wrote:
Long options can be negated by prefixing them
with 'no-'. However options that already start
with 'no-', such as '--no-inherit' result in ugly
double 'no's. Avoid that by accepting that the
removal of 'no-' also negates the long option.
Why not
101 - 200 of 1351 matches
Mail list logo
