On Thu, Sep 06, 2012 at 03:35:00PM -0700, Kent Overstreet wrote:
> Now that we've got generic code for freeing bios allocated from bio
> pools, this isn't needed anymore.
>
> This patch also makes bio_free() static, since without bi_destructor
> there should be no need for it to be called anywhere
On 03/09/12 22:29, Axel Lin wrote:
> Include linux/sizes.h to fix below build errors:
>
> CC arch/arm/mach-ep93xx/adssphere.o
> arch/arm/mach-ep93xx/adssphere.c: In function 'adssphere_init_machine':
> arch/arm/mach-ep93xx/adssphere.c:32:49: error: 'SZ_32M' undeclared (first use
> in this f
On Thu, Sep 06, 2012 at 09:46:50AM +0200, Paolo Bonzini wrote:
> VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a
> "negative" feature: it tells you that silent defalte is not supported.
> Right now, QEMU refuses migration if the target does not support all the
> features tha
Hello Yasuaki,
On Thu, Sep 06, 2012 at 06:14:39PM +0900, Yasuaki Ishimatsu wrote:
> Hi, Minchan,
>
> 2012/09/06 16:30, Minchan Kim wrote:
> >Hello Yasuaki,
> >
> >On Thu, Sep 06, 2012 at 04:17:54PM +0900, Yasuaki Ishimatsu wrote:
> >>Hi Minchan,
> >>
> >>2012/09/06 14:16, Minchan Kim wrote:
> >>>
On Thu, Sep 06, 2012 at 10:24:24AM +0100, Mel Gorman wrote:
> On Thu, Sep 06, 2012 at 01:49:03PM +0900, Minchan Kim wrote:
> > > > __offline_isolated_pages
> > > > /*
> > > > * BUG_ON hit or offline page
> > > > * which is used by someone
> > > > */
> > > > BUG_ON(!PageBuddy(page A));
> > > >
>
Hello Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-linus-3.6-rc4-tag
Nothing controversial. Fix for the newer tlb flushing code;
an old fix for Xen-SWIOTLB that had been bouncing around until
we narrowed why it fixed it; and a
On Fri, 24 Aug 2012 16:57:35 +0800
Alex Shi wrote:
> The flush tlb optimization code has logical issue on UV platform.
> It doesn't flush the full range at all, since it simply
> ignores its 'end' parameter (and hence also the "all" indicator)
> in uv_flush_tlb_others() function.
>
> This patch
From: Gyungoh Yoo
The MAX8907 is an I2C-based power-management IC containing voltage
regulators, a reset controller, a real-time clock, and a touch-screen
controller.
The original driver was written by:
* Gyungoh Yoo
Various fixes and enhancements by:
* Jin Park
* Tom Cherry
* Prashant Gaikw
On 09/05/2012 06:01 PM, Mark Brown wrote:
> On Tue, Sep 04, 2012 at 02:43:39PM -0600, Stephen Warren wrote:
>> From: Laxman Dewangan
>>
>> Device have SYS rail which is always ON. It is system power bus. LDO5
>> and LDO_RTC get powered through this rail internally. Add support for
>> this rail and
Hello, Glauber.
On Thu, Sep 6, 2012 at 3:39 PM, Glauber Costa wrote:
> Yes, please.
>
> While you rightfully claim that you explained it a couple of times, it
> all seems to be quite fuzzy. I don't blame it on you: the current state
> of the interface leads to this.
Heh, I drank two cups of coff
On Sat, 4 Aug 2012 12:01:27 +0800
Ming Lei wrote:
> This patch introduces the three helpers below:
>
> void device_cache_fw_images(void)
> void device_uncache_fw_images(void)
> void device_uncache_fw_images_delay(unsigned long)
CONFIG_PM=n:
drivers/base/firmware_class.c:1147
Felipe Balbi writes:
> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be igno
On 09/07/2012 12:38 AM, Tejun Heo wrote:
> Hello, Peter, Glauber.
>
> (I'm gonna write up cgroup core todos which should explain / address
> this issue too. ATM I'm a bit overwhelmed with stuff accumulated
> while traveling.)
>
Yes, please.
While you rightfully claim that you explained it a co
On 09/07/2012 01:11 AM, Paul Turner wrote:
> On Thu, Sep 6, 2012 at 1:46 PM, Tejun Heo wrote:
>> Hello,
>>
>> cc'ing Dhaval and Frederic. They were interested in the subject
>> before and Dhaval was pretty vocal about cpuacct having a separate
>> hierarchy (or at least granularity).
>
> Really?
With the old code, when you allocate a bio from a bio pool you have to
implement your own destructor that knows how to find the bio pool the
bio was originally allocated from.
This adds a new field to struct bio (bi_pool) and changes
bio_alloc_bioset() to use it. This makes various bio destructors
Now that bios keep track of where they were allocated from,
bio_integrity_alloc_bioset() becomes redundant.
Remove bio_integrity_alloc_bioset() and drop bio_set argument from the
related functions and make them use bio->bi_pool.
Signed-off-by: Kent Overstreet
CC: Jens Axboe
CC: Martin K. Peters
This is prep work for killing bi_destructor - previously, pktcdvd had
its own pkt_bio_alloc which was basically duplication bio_kmalloc(),
necessitating its own bi_destructor implementation.
v5: Un-reorder some functions, to make the patch easier to review
Signed-off-by: Kent Overstreet
Acked-by
Screwed up the bio_reset() patch in the last patch series when I went to edit
the description, fixed that here.
Only other change is the dm patch - made the front_pad conditional on
DM_TYPE_BIO_BASED.
Kent Overstreet (8):
block: Generalized bio pool freeing
block: Ues bi_pool for bio_integrit
On Fri, 17 Aug 2012 15:14:32 +0100
Mel Gorman wrote:
> If allocation fails after compaction then compaction may be deferred for
> a number of allocation attempts. If there are subsequent failures,
> compact_defer_shift is increased to defer for longer periods. This patch
> uses that information t
Now that we've got generic code for freeing bios allocated from bio
pools, this isn't needed anymore.
This patch also makes bio_free() static, since without bi_destructor
there should be no need for it to be called anywhere else.
bio_free() is now only called from bio_put, so we can refactor thos
Previously, bio_kmalloc() and bio_alloc_bioset() behaved slightly
different because there was some almost-duplicated code - this fixes
some of that.
The important change is that previously bio_kmalloc() always set
bi_io_vec = bi_inline_vecs, even if nr_iovecs == 0 - unlike
bio_alloc_bioset(). This
Previously, there was bio_clone() but it only allocated from the fs bio
set; as a result various users were open coding it and using
__bio_clone().
This changes bio_clone() to become bio_clone_bioset(), and then we add
bio_clone() and bio_clone_kmalloc() as wrappers around it, making use of
the fu
Reusing bios is something that's been highly frowned upon in the past,
but driver code keeps doing it anyways. If it's going to happen anyways,
we should provide a generic method.
This'll help with getting rid of bi_destructor - drivers/block/pktcdvd.c
was open coding it, by doing a bio_init() and
Previously, dm_rq_clone_bio_info needed to be freed by the bio's
destructor to avoid a memory leak in the blk_rq_prep_clone() error path.
This gets rid of a memory allocation and means we can kill
dm_rq_bio_destructor.
The _rq_bio_info_cache kmem cache is unused now and needs to be deleted,
but du
Hi Arnd,
On Sat, Aug 18, 2012 at 3:08 PM, Arnd Bergmann wrote:
> On Saturday 18 August 2012, Fabio Estevam wrote:
>>
>> From: Fabio Estevam
>>
>> commit 7c5763 (drivers:misc: Remove MISC_DEVICES config option) removed
>> CONFIG_MISC_DEVICES option, so remove the occurrences from the config files
On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
> On 09/05/2012 09:55 PM, Christoph Lameter wrote:
> > On Wed, 5 Sep 2012, Michael Wang wrote:
> >
> >> Since the cachep and cachep->slabp_cache's l3 alien are in the same lock
> >> class,
> >> fake report generated.
> >
> > Ahh... Th
On Thu, Sep 06, 2012 at 12:21:15PM +0900, Jun'ichi Nomura wrote:
> On 09/06/12 05:27, Kent Overstreet wrote:
> > @@ -2718,7 +2705,8 @@ struct dm_md_mempools *dm_alloc_md_mempools(unsigned
> > type, unsigned integrity)
> > if (!pools->tio_pool)
> > goto free_io_pool_and_out;
> >
>
On 09/06/2012 07:31 PM, Steven Rostedt wrote:
> On Thu, 2012-09-06 at 18:35 +0200, Toralf Förster wrote:
>
>> I filed a bug report
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54495
>> and got this answer :
>>
>> --- Comment #1 from Hans-Peter Nilsson 2012-09-05
>> 22:14:00 UTC ---
>> But
On Thu, Sep 06, 2012 at 06:05:53PM -0400, Steven Rostedt wrote:
> On Thu, 2012-09-06 at 14:58 -0700, Paul E. McKenney wrote:
>
> > > All these cases deserve a warning.
> >
> > Agreed, and that is the whole purpose of the stall warnings.
>
> Then let me ask the question again. According to the ch
On Thu, Sep 06, 2012 at 05:57:45PM -0400, Steven Rostedt wrote:
> On Thu, 2012-09-06 at 14:35 -0700, Paul E. McKenney wrote:
>
> > But yes, RCU was a lot simpler before people started worrying about
> > its energy efficiency. ;-)
>
> Tell them to buy bigger batteries.
If nuclear batteries are g
On Thu, Sep 06, 2012 at 05:56:39PM -0400, Steven Rostedt wrote:
> On Thu, 2012-09-06 at 14:29 -0700, Paul E. McKenney wrote:
> >
> > > Didn't we talk about having the rcu_dereference_raw() not do the check?
> > > The function tracer is just too invasive to add work arounds to prevent
> > > lockde
On Thu, 2012-09-06 at 14:58 -0700, Paul E. McKenney wrote:
> > All these cases deserve a warning.
>
> Agreed, and that is the whole purpose of the stall warnings.
Then let me ask the question again. According to the change log:
> If a given CPU avoids the idle loop but also avoids starting a ne
Stephen Warren wrote:
>
> On 09/05/2012 12:20 AM, Thomas Abraham wrote:
> > Add a new device tree enabled pinctrl and gpiolib driver for Samsung
> > SoC's. This driver provides a common and extensible framework for all
> > Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This
>
On Thu, Sep 06, 2012 at 05:41:01PM -0400, Steven Rostedt wrote:
> On Thu, 2012-09-06 at 14:03 -0700, Paul E. McKenney wrote:
>
> > Here are a few other ways that stalls can happen:
> >
> > o A CPU looping in an RCU read-side critical section.
>
> For a minute? That's a bug.
>
> >
> > o
Felipe Balbi writes:
> nobody needs to access the uart_omap_port structure
> other than omap-serial.c file. Let's move that
> structure definition to the C source file in order
> to prevent anyone from accessing our structure.
>
> Tested-by: Shubhrajyoti D
> Acked-by: Tony Lindgren
> Signed-off
On Thu, 2012-09-06 at 14:35 -0700, Paul E. McKenney wrote:
> But yes, RCU was a lot simpler before people started worrying about
> its energy efficiency. ;-)
Tell them to buy bigger batteries.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Thu, 2012-09-06 at 14:29 -0700, Paul E. McKenney wrote:
>
> > Didn't we talk about having the rcu_dereference_raw() not do the check?
> > The function tracer is just too invasive to add work arounds to prevent
> > lockdep from screaming about it.
>
> Actually, rcu_dereference_raw() is already
Hello!
On Thu, Sep 6, 2012 at 11:17 PM, Tomas Hlavacek wrote:
> Added tty_device_create_release() and bound to dev->release in
> tty_register_device_attr().
> Added tty_port_register_device_attr() and used in uart_add_one_port()
> instead of tty_register_device_attr().
>
> Signed-off-by: Tomas Hl
On Thu, 2012-09-06 at 14:03 -0700, Paul E. McKenney wrote:
> Here are a few other ways that stalls can happen:
>
> o A CPU looping in an RCU read-side critical section.
For a minute? That's a bug.
>
> o A CPU looping with interrupts disabled. This condition can
> result in
Hi Linus,
Here are some more fixes for v3.6. These all fix things we merged in
v3.6-rc1. Four are fixes for the D3cold support, and one is for a
boot lockup on PA Semi caused by a printk while the console BAR is
still disabled.
Bjorn
The following changes since commit a6b881a5b8d4fa2135e55a74
Hi
On Thu, 6 Sep 2012, Felipe Balbi wrote:
> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
On Thu, Sep 06, 2012 at 05:12:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-08-30 at 11:56 -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > The can_stop_idle_tick() function complains if a softirq vector is
> > raised too late in the idle-entry process, presumably in order t
With the old code, when you allocate a bio from a bio pool you have to
implement your own destructor that knows how to find the bio pool the
bio was originally allocated from.
This adds a new field to struct bio (bi_pool) and changes
bio_alloc_bioset() to use it. This makes various bio destructors
Reusing bios is something that's been highly frowned upon in the past,
but driver code keeps doing it anyways. If it's going to happen anyways,
we should provide a generic method.
This'll help with getting rid of bi_destructor - drivers/block/pktcdvd.c
was open coding it, by doing a bio_init() and
This is prep work for killing bi_destructor - previously, pktcdvd had
its own pkt_bio_alloc which was basically duplication bio_kmalloc(),
necessitating its own bi_destructor implementation.
v5: Un-reorder some functions, to make the patch easier to review
Signed-off-by: Kent Overstreet
Acked-by
Reusing bios is something that's been highly frowned upon in the past,
but driver code keeps doing it anyways. If it's going to happen anyways,
we should provide a generic method.
This'll help with getting rid of bi_destructor - drivers/block/pktcdvd.c
was open coding it, by doing a bio_init() and
Now that bios keep track of where they were allocated from,
bio_integrity_alloc_bioset() becomes redundant.
Remove bio_integrity_alloc_bioset() and drop bio_set argument from the
related functions and make them use bio->bi_pool.
Signed-off-by: Kent Overstreet
CC: Jens Axboe
CC: Martin K. Peters
Now that we've got generic code for freeing bios allocated from bio
pools, this isn't needed anymore.
This patch also makes bio_free() static, since without bi_destructor
there should be no need for it to be called anywhere else.
While we're at it, since bio_free() is now only called from one pla
Now that we've got generic code for freeing bios allocated from bio
pools, this isn't needed anymore.
This patch also makes bio_free() static, since without bi_destructor
there should be no need for it to be called anywhere else.
bio_free() is now only called from bio_put, so we can refactor thos
Previously, there was bio_clone() but it only allocated from the fs bio
set; as a result various users were open coding it and using
__bio_clone().
This changes bio_clone() to become bio_clone_bioset(), and then we add
bio_clone() and bio_clone_kmalloc() as wrappers around it, making use of
the fu
Previously, bio_kmalloc() and bio_alloc_bioset() behaved slightly
different because there was some almost-duplicated code - this fixes
some of that.
The important change is that previously bio_kmalloc() always set
bi_io_vec = bi_inline_vecs, even if nr_iovecs == 0 - unlike
bio_alloc_bioset(). This
Previously, there was bio_clone() but it only allocated from the fs bio
set; as a result various users were open coding it and using
__bio_clone().
This changes bio_clone() to become bio_clone_bioset(), and then we add
bio_clone() and bio_clone_kmalloc() as wrappers around it, making use of
the fu
Previously, dm_rq_clone_bio_info needed to be freed by the bio's
destructor to avoid a memory leak in the blk_rq_prep_clone() error path.
This gets rid of a memory allocation and means we can kill
dm_rq_bio_destructor.
The _rq_bio_info_cache kmem cache is unused now and needs to be deleted,
but du
Previously, bio_kmalloc() and bio_alloc_bioset() behaved slightly
different because there was some almost-duplicated code - this fixes
some of that.
The important change is that previously bio_kmalloc() always set
bi_io_vec = bi_inline_vecs, even if nr_iovecs == 0 - unlike
bio_alloc_bioset(). This
Since v8: Just a few minor comment/patch descriptions changes
Kent Overstreet (9):
block: Generalized bio pool freeing
block: Ues bi_pool for bio_integrity_alloc()
dm: Use bioset's front_pad for dm_rq_clone_bio_info
block: Add bio_reset()
pktcdvd: Switch to bio_kmalloc()
block: Add bio
On Thu, Sep 06, 2012 at 05:18:59PM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > On Thu, Sep 06, 2012 at 04:36:02PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2012-08-30 at 11:18 -0700, Paul E. McKenney wrote:
> > > > From: "Paul E. McKenney"
> > > >
Hello,
On Wed, Sep 05, 2012 at 12:07:24PM +0200, Lars Ellenberg wrote:
> So reiterating the situation:
>
> If I'd submit a non-empty bio with FLUSH/FUA set,
> on a queue that does support flush, we get to
> blk_queue_bio()
> if (bio->bi_rw & (REQ_FLUSH | REQ_FUA)) {
>
On Thu, Sep 06, 2012 at 05:00:29PM -0400, Steven Rostedt wrote:
> On Wed, 2012-09-05 at 09:59 +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > This is possibly an aged warning.
> >
> > if (!hardirq_count()) {
> > if (softirq_count()) {
> > /* like
On Thursday, September 06, 2012, John Stultz wrote:
> Jon Medhurst (Tixy) recently noticed a problem with the
> events_lock usage. One of the Android patches that uses
> wakeup_sources calls wakeup_source_add() with irqs disabled.
> However, the event_lock usage in wakeup_source_add() uses
> spin_l
On Thu, Sep 06, 2012 at 08:41:09PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 17:46 +0200, Jiri Olsa wrote:
> > The 'perf diff' and 'std/hist' code is now changed to allow computations
> > mentioned in the paper. Two of them are implemented within this patchset:
> > 1) ratio differentia
Added tty_device_create_release() and bound to dev->release in
tty_register_device_attr().
Added tty_port_register_device_attr() and used in uart_add_one_port()
instead of tty_register_device_attr().
Signed-off-by: Tomas Hlavacek
---
drivers/tty/serial/serial_core.c |8
drivers/tty/
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Thu, Sep 06, 2012 at 04:36:02PM +0200, Peter Zijlstra wrote:
> > On Thu, 2012-08-30 at 11:18 -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > The current quiescent-state detection algorithm is needlessly
> > > co
On Thursday, September 06, 2012, Sedat Dilek wrote:
> On Thu, Sep 6, 2012 at 11:17 PM, Rafael J. Wysocki wrote:
> > On Thursday, September 06, 2012, Sedat Dilek wrote:
[...]
> >>
> >> Just wondering... Fell over it when digging into my boot-problem (this
> >> appeared as a new Kconfig option, so).
t;> >>>> Not sure why this setting is default YES, Rafael?
>> >>>>
>> >>>> To switch from upstart to systemd does not help.
>> >>>
>> >>>
>> >>> Andre, care to have a look at this?
>> >>>
&g
On Thursday, September 06, 2012, Daniel Lezcano wrote:
> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
> > On Thursday, September 06, 2012, Daniel Lezcano wrote:
> >> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> >>> On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
> On Saturday, Septembe
Calxeda highbank SATA phy has intermittent problems bringing up a link
with Gen3 drives. Retrying the phy hard reset can work-around this issue,
but each reset also disables spread spectrum support. The reset function
also needs to reprogram the phy to enable spread spectrum support.
Create a new
t;>
> >>
> >> I am not sure if the depends-on/default-n/default-y lines are correct.
> >> Here, I am on a Intel sandy-bridge CPU, so why do I need to activate
> >> any AMD CPU workaround?
> >
> >
> > It is not a workaround, it is about keeping a featur
On Thu, Sep 6, 2012 at 1:46 PM, Tejun Heo wrote:
> Hello,
>
> cc'ing Dhaval and Frederic. They were interested in the subject
> before and Dhaval was pretty vocal about cpuacct having a separate
> hierarchy (or at least granularity).
Really? Time just has _not_ borne out this use-case. I'll le
Commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 ("kbuild: link of
vmlinux moved to a script") introduced in v3.5-rc1 broke kallsyms on
architectures which have symbol prefixes.
The --symbol-prefix argument used to be added to the KALLSYMS command
line from the architecture Makefile, however this i
On Thu, Sep 06, 2012 at 05:19:18PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 11:07 -0400, Steven Rostedt wrote:
> > On Thu, 2012-09-06 at 16:56 +0200, Peter Zijlstra wrote:
> > > On Thu, 2012-08-30 at 11:56 -0700, Paul E. McKenney wrote:
> > > >
> > > > If a given CPU avoids the idle lo
* Peter Ujfalusi [120906 05:13]:
> Remove the use of set_hs_extmute callback and let the codec driver to
> handle the extmute GPIO.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/mach-omap2/board-zoom-peripherals.c | 9 ++---
> arch/arm/mach-omap2/include/mach/board-zoom.h | 2 --
Here
On Thu, Sep 06, 2012 at 04:51:18PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-08-30 at 11:56 -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > The print_other_cpu_stall() function accesses a number of rcu_node
> > fields without protection from the ->lock. In theory, this is n
There's a typo in $SUBJ.
On Wed, Sep 05, 2012 at 01:27:23PM -0700, Kent Overstreet wrote:
> Now that bios keep track of where they were allocated from,
> bio_integrity_alloc_bioset() becomes redundant.
+ Remove bio_integrity_alloc_bioset() and drop bio_set argument from
+ the related functions an
On Wed, 2012-09-05 at 09:59 +0800, Fengguang Wu wrote:
> Greetings,
>
> This is possibly an aged warning.
>
> if (!hardirq_count()) {
> if (softirq_count()) {
> /* like the above, but with softirqs */
> => DEBUG_LOCKS_WARN_ON(cu
On Thu, Sep 06, 2012 at 04:40:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-08-30 at 11:56 -0700, Paul E. McKenney wrote:
> > When rcu_preempt_offline_tasks() clears tasks from a leaf rcu_node
> > structure, it does not NULL out the structure's ->boost_tasks field.
> > This commit therefore fixe
Il 06/09/2012 21:29, Nicholas A. Bellinger ha scritto:
> On Thu, 2012-09-06 at 17:13 +0200, Paolo Bonzini wrote:
>> This patch started with the aim of fixing START STOP UNIT to a PSCSI
>> device. Right now, commands with a zero-size payload are skipped
>> completely. This is wrong; such commands
On Thu, Sep 06, 2012 at 05:11:58PM +0200, Kurt Van Dijck wrote:
> > > I also think that led triggers should be available.
> >
> > Right, that's why I think the only way is to use device name.
>
> yes, but it has 2 disadvantages:
> * inconvenient. I like 'can0-tx' much more than any device name
>
Ok, there's no line wrapping this time, so it applies.
However, your subject line is really too long, and you're missing a
description in the body of the patch. Did you lose the subject line
from the first version of the patch?
In general, subject lines shouldn't be longer than 50 characters,
be
the depends-on/default-n/default-y lines are correct.
>> Here, I am on a Intel sandy-bridge CPU, so why do I need to activate
>> any AMD CPU workaround?
>
>
> It is not a workaround, it is about keeping a feature that was in
> powernow-k8 for 2.5 years. AMD CPUs have this sysfs knob for tur
On Thu, Sep 06, 2012 at 04:38:32PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-08-30 at 11:56 -0700, Paul E. McKenney wrote:
> > +#ifdef CONFIG_PROVE_RCU_DELAY
> > + udelay(10); /* Make preemption more probable. */
> cond_resched(); /* for extra fun? */
The additional f
Il 06/09/2012 20:58, Nicholas A. Bellinger ha scritto:
> On Thu, 2012-09-06 at 17:13 +0200, Paolo Bonzini wrote:
>> The purpose of this function is to clear a LUN set in the CDB, in case
>> the initiator talking to us is speaking an old standards version.
>> However, as things stand, pscsi_clear_cd
> Let's wait once Dmitry is finished with the input changes, and I can
> either take the set through my tree with his Signed-off-by: on the Input
> patches, or vice-versa.
Ok. Meanwhile, the current set is now in a temporary branch on github,
see below. Given there are no more change requests, I
Il 06/09/2012 20:52, Nicholas A. Bellinger ha scritto:
> That way we can just disable a problematic fabric instead of having to
> revert the whole thing if users run into problems with a specific fabric
> module late during the cycle. If the other fabric maintainers are OK
> with enabling this in
On Thu, Sep 06, 2012 at 08:21:50PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 10:46 -0700, Paul E. McKenney wrote:
> > Getting these
> > CPUs into adaptive-tick mode more quickly reduces OS jitter, which is
> > one big expected benefit of adaptive-tick mode.
>
> I'm not sure I agree wit
ode, which
+* will probably be removed at some point in the future.
+*/
+ if (check_amd_hwpstate_cpu(0)) {
...
[ Linux-Next (next-20120906) ]
19 config X86_ACPI_CPUFREQ
20 tristate "ACPI Processor P-States driver"
21 select CPU_FREQ_TABLE
22
On Fri, Aug 31, 2012 at 1:39 AM, Michel Lespinasse wrote:
> On Fri, Aug 31, 2012 at 1:35 AM, Adrian Hunter
> wrote:
>> On 31/08/12 11:15, Andrew Morton wrote:
>>> On Fri, 31 Aug 2012 01:07:24 -0700 Michel Lespinasse
>>> wrote:
I thought Andrew had a patch
rbtree-adjust-root-color-in-
Hello,
cc'ing Dhaval and Frederic. They were interested in the subject
before and Dhaval was pretty vocal about cpuacct having a separate
hierarchy (or at least granularity).
On Wed, Sep 05, 2012 at 12:04:47PM +0200, Peter Zijlstra wrote:
> > cpuacct is rather unique tho. I think it's gonna be
On Thu, Sep 06, 2012 at 09:31:07PM +0200, Oliver Hartkopp wrote:
> >> +
> >> +/*
> >> + * NETDEV rename notifier to rename the associated led triggers too
> >> + */
> >> +static int can_led_notifier(struct notifier_block *nb, unsigned long msg,
> >> + void *data)
> >> +{
> >> + st
On Thu, Sep 06, 2012 at 08:28:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 10:53 -0700, Paul E. McKenney wrote:
>
> > > - how do I know if my workload wants a longer or shorter forced qs
> > >period?
> >
> > Almost everyone can do just fine with the defaults. If you have more
>
Hi Sam,
On Sat, Apr 28, 2012 at 10:59:19PM +0200, Sam Ravnborg wrote:
> From c92ef0a63bb191fb7642e744e8c5865a983713fa Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg
> Date: Sat, 28 Apr 2012 20:03:59 +0200
> Subject: [PATCH 3/4] kbuild: link of vmlinux moved to a script
>
> Move the final link of
Hello, Peter, Glauber.
(I'm gonna write up cgroup core todos which should explain / address
this issue too. ATM I'm a bit overwhelmed with stuff accumulated
while traveling.)
On Wed, Sep 05, 2012 at 12:20:53PM +0200, Peter Zijlstra wrote:
> But I don't really see the point though, this kind of i
In response to this RFC for zcache promotion, I've been asked to summarize
the concerns and objections which led me to NACK the previous zcache
promotion request. While I see great potential in zcache, I think some
significant design challenges exist, many of which are already resolved in
the new
On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
>>> On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> On Friday, August 31,
On Thu, Sep 06, 2012 at 07:46:16PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 10:41 -0700, Paul E. McKenney wrote:
> > On Thu, Sep 06, 2012 at 09:52:53AM -0400, Steven Rostedt wrote:
> > > On Thu, 2012-09-06 at 15:46 +0200, Peter Zijlstra wrote:
> > > > On Thu, 2012-08-30 at 11:18 -0700,
27;ll drop it for now until the issue is resolved.
>
Hi Rafael,
The problem was caused by the slab/next merge (see [1]).
[1] http://marc.info/?t=13469568658&r=1&w=2
>> I hacked to turn off CONFIG_X86_ACPI_CPUFREQ_CPB, but this is not the
>> root cause.
>> Not
On Thu, Sep 06, 2012 at 09:09:01PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 11:49 -0700, Josh Triplett wrote:
> >
> > Huh, I thought GCC knew to not emit that warning unless it actually
> > found control flow reaching the end of the function; since the
> > infinite
> > loop has no brea
On Thu, Sep 06, 2012 at 11:49:21AM -0700, Josh Triplett wrote:
> On Thu, Sep 06, 2012 at 10:32:07AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 06, 2012 at 03:39:51PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2012-08-30 at 11:18 -0700, Paul E. McKenney wrote:
> > > > +static int rcu_gp_kthread(
On Tue, Sep 04, 2012 at 05:01:05PM -0700, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> The CONFIG_HOTPLUG variable is tough to turn off, and almost all arches
> default to it on.
>
> If you turn it off, it saves you a big 200 or so bytes, and then starts
> to cause all sorts of problems as the
Hello, Lai.
On Thu, Sep 06, 2012 at 01:09:48PM -0700, Tejun Heo wrote:
> From f3b57042feab077e340da166f0a0329793e94a16 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Thu, 6 Sep 2012 12:59:59 -0700
>
> gcwq_associate() is now more involved with CPU hotplug and its current
> location requires
From: Ben Hutchings
There is a new convention, used by systemd and supported by most
distributions, to put basic OS release information in /etc/os-release.
Added some additional error checking on strdup()
Signed-off-by: Ben Hutchings
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_kvp_daemon.
201 - 300 of 793 matches
Mail list logo
