We want to calculate the blinks per second, and instead of making it 5
(1000 / (3600 / 18)), let's make it 4, so the user can see two blinks
per second.
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/panic.c
Quoting Boris BREZILLON (2013-10-13 10:17:10)
> The clock accuracy is expressed in ppb (parts per billion) and represents
> the possible clock drift.
> Say you have a clock (e.g. an oscillator) which provides a fixed clock of
> 20MHz with an accuracy of +- 20Hz. This accuracy expressed in ppb is
>
On Fri, Nov 8, 2013 at 7:44 AM, Rusty Russell wrote:
> Axel Lin writes:
>> 2013/11/7 Ming Lei :
>>> Hi,
>>>
>>> On Thu, Nov 7, 2013 at 10:47 AM, Axel Lin wrote:
hi Ming,
Seems CONFIG_PAGE_OFFSET is not configurabe in "make menuconfig".
And I found
On Thursday 07 November 2013 07:37 PM, Joel Fernandes wrote:
> Add documentation for the generic OMAP DES crypto module describing the device
> tree bindings.
>
> Signed-off-by: Joel Fernandes
> ---
Thanks Joel for picking this up.
FWIW, Acked-by: Santosh Shilimkar
--
To unsubscribe from this
; That being said, I agree that omap_device should still be catching this
>> case in order to find/fix driver races like this.
>
>>
>>> To prevent this from happening, we should ensure that runtime_status
>>> exactly indicates the device status. As a result of thi
Add documentation for the generic OMAP DES crypto module describing the device
tree bindings.
Signed-off-by: Joel Fernandes
---
.../devicetree/bindings/crypto/omap-des.txt| 28 ++
1 file changed, 28 insertions(+)
create mode 100644
On 13-11-06 01:40 AM, Linus Walleij wrote:
On Wed, Nov 6, 2013 at 3:02 AM, Sherman Yin wrote:
When Linus asked me to try using generic pinconf instead, I ran into
problems with this feature due to how the generic pinconf properties are
defined differently than my properties - perhaps this
Hi Hannes, Rik.
On Thu, Nov 07, 2013 at 04:21:32PM -0500, Johannes Weiner wrote:
> On Thu, Nov 07, 2013 at 10:13:45AM -0500, Rik van Riel wrote:
> >
> > > > fs/proc/meminfo.c | 36
> > > > 1 file changed, 36 insertions(+)
> > >
> > >
This is to inform you that you were among the lucky beneficiary selected to
receive this donations award sum of $ 1Million US DOLLAR each as charity
donations/aid from the Qatar Foundation to promote your business and personal
Interest. Kindly revert back for claims processing via email:
On Fri, Nov 08, 2013 at 01:09:03AM +0100, Johan Hovold wrote:
> A recent change in usb-serial used the wrong memory-allocation flag in
> write(), which results in a
>
> [5.979005] BUG: sleeping function called from invalid context at
>
From: Dan Carpenter
Date: Thu, 7 Nov 2013 10:48:49 +0300
> There is a bug in cpsw_probe() where we do:
>
> ndev->irq = platform_get_irq(pdev, 0);
> if (ndev->irq < 0) {
>
> The problem is that "ndev->irq" is unsigned so the error handling
> doesn't work. I have changed it to a
Add Legacy PM OPS usage checks to class, bus, and driver register functions.
If Legacy PM OPS usage is found, print warning message to indicate the driver
code needs updating to use Dev PM OPS interfaces. This will help serve as a way
to track drivers that still use Legacy PM OPS and fix them.
Add Legacy PM OPS usage checks to __class_register() function. If Legacy PM OPS
usage is found, print warning message to indicate the driver code needs
updating to use Dev PM OPS interfaces. This will help serve as a way to track
drivers that still use Legacy PM OPS and fix them.
The Legacy PM
Add Legacy PM OPS usage checks to driver_register() function. If Legacy PM OPS
usage is found, print warning message to indicate the driver code needs
updating to use Dev PM OPS interfaces. This will help serve as a way to track
drivers that still use Legacy PM OPS and fix them.
The Legacy PM OPS
Add Legacy PM OPS usage checks to bus_register() function. If Legacy PM OPS
usage is found, print warning message to indicate the driver code needs
updating to use Dev PM OPS interfaces. This will help serve as a way to track
drivers that still use Legacy PM OPS and fix them.
The Legacy PM OPS
On Thu, Nov 07, 2013 at 05:37:28PM -0500, Dave Jones wrote:
> Seeing this since todays USB merge.
>
> WARNING: CPU: 0 PID: 226 at kernel/lockdep.c:2740
> lockdep_trace_alloc+0xc5/0xd0()
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> Modules linked in: usb_debug(+) kvm_intel kvm
ted-by: J Keerthy
Signed-off-by: Nishanth Menon
Acked-by: Rajendra Nayak
---
patch baseline: V3.12 tag (also applies on linux-next next-20131107 tag)
Logs from 3.12 based vendor kernel:
Before: http://pastebin.com/m5KxnB7a
After: http://pastebin.com/8AfX4e7r
The discussion on cpufreq side of the story
From: Andrey Vagin
Date: Thu, 7 Nov 2013 08:35:12 +0400
> sk_filter isn't freed if bpf_func is equal to sk_run_filter.
>
> This memory leak was introduced by v3.12-rc3-224-gd45ed4a4
> "net: fix unsafe set_memory_rw from softirq".
>
> Before this patch sk_filter was freed in
Hi Vincent,
Thanks for creating some benchmark numbers!
On Thursday, November 07, 2013 5:33 AM, Vincent Guittot
[vincent.guit...@linaro.org] wrote:
>
> On 7 November 2013 12:32, Catalin Marinas wrote:
> > Hi Vincent,
> >
> > (for whatever reason, the text is wrapped and results hard to read)
On 11/07/2013 01:25 PM, Kent Overstreet wrote:
> On Thu, Nov 07, 2013 at 01:20:26PM -0600, Dave Kleikamp wrote:
>> I ended up replacing a call to bio_iovec_idx() with __bvec_iter_bvec()
>> since the former was removed. It's not very elegant, but it works. I'm
>> open to suggestions on a cleaner
This logic is exactly equivalent to the old logic, but it should
be easier to see what it's doing.
The equivalence depends on one fact from outside this function:
when 'r->limit' is false, 'reserved' is zero. (Well, two facts;
the other is that 'reserved' is never negative.)
Which is a good
This commit makes the very boring simplifications so that the next
commit, which is a little trickier, is isolated and easy to review.
No change in behavior here at all.
Cc: "Theodore Ts'o"
Cc: Jiri Kosina
Signed-off-by: Greg Price
---
drivers/char/random.c | 10 --
1 file changed, 4
With this we handle "reserved" in just one place. As a bonus the
code becomes less nested, and the "wakeup_write" flag variable
becomes unnecessary. The variable "flags" was already unused.
This code behaves identically to the previous version except in
two pathological cases that don't occur.
The loop condition never changes until just before a break, so we
might as well write it as a constant. Also since v2.6.33-rc7~40^2~2
("random: drop weird m_time/a_time manipulation") we don't do
anything after the loop finishes, so the 'break's might as well
return directly. Some other
After this remark was written, commit d2e7c96af added a use of
arch_get_random_long() inside the get_random_bytes codepath.
The main point stands, but it needs to be reworded.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 5 +++--
1 file changed, 3 insertions(+), 2
This comment didn't quite keep up as extract_entropy() was split into
four functions. Put each bit by the function it describes.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
We cheerfully overflow these variables (at least where "int"
is 32 bits wide), so pedantically they should be unsigned.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c
Since 902c098a3 ("random: use lockless techniques in the interrupt
path") we have protected entropy_count only with cmpxchg, not the
lock. In 10b3a32d2 ("random: fix accounting race condition") we
put a cmpxchg-retry loop around most of the logic in account(),
but the enforcement of the 'min'
The only mutable data accessed here is ->entropy_count, but since
902c098a3 ("random: use lockless techniques in the interrupt path")
that member isn't protected by the lock anyway. Since 10b3a32d2
("random: fix accounting race condition") we use cmpxchg to protect
our accesses to ->entropy_count
There's only one function here now, as uuid_strategy is long gone.
Also make the bit about "If accesses via ..." clearer.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c
Hi Ted, hi all,
I recently read through the random number generator's code.
This series has fixes for some minor things I spotted.
Four of the patches touch comments only. Four simplify code without
changing its behavior (total diffstat: 35 insertions, 73 deletions),
and one is a trivial
On Fri, 2013-11-08 at 09:41 +1030, Rusty Russell wrote:
> Joe Perches writes:
> > On Thu, 2013-11-07 at 12:32 +1030, Rusty Russell wrote:
> >> Joe Perches writes:
> >> > This semicolon isn't necessary, remove it.
> >> >
> >> > Signed-off-by: Joe Perches
> >>
> >> This is a terrible
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 7a744d3..ef3e15b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -348,12
Joe Perches writes:
> On Thu, 2013-11-07 at 12:32 +1030, Rusty Russell wrote:
>> Joe Perches writes:
>> > This semicolon isn't necessary, remove it.
>> >
>> > Signed-off-by: Joe Perches
>>
>> This is a terrible description. Really bad.
>
> I'd've preferred no description.
Me too.
>> First,
Axel Lin writes:
> 2013/11/7 Ming Lei :
>> Hi,
>>
>> On Thu, Nov 7, 2013 at 10:47 AM, Axel Lin wrote:
>>>
>>> hi Ming,
>>> Seems CONFIG_PAGE_OFFSET is not configurabe in "make menuconfig".
>>> And I found CONFIG_PAGE_OFFSET=0xC000 for all below configs...
>>> $ make at91_dt_defconfig; grep
On Thu, 7 Nov 2013 15:39:00 -0800 Bryan Wu wrote:
> On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown wrote:
> >
>
> [PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
>
> I think it should be tca6507, right? Typo?
Obviously I'm still dreaming of the Apple IIe. Yes, a typo.
On Thu, Nov 7, 2013 at 3:39 PM, Bryan Wu wrote:
> On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown wrote:
>>
>
> [PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
>
> I think it should be tca6507, right? Typo?
>
I fixed this typo and queue up this patch in my devel branch.
On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> On Fri, 8 Nov 2013 00:21:51 +0100
> Frederic Weisbecker wrote:
>
> > Ok I see now.
> >
> > But then this irq_work based solution won't work if, say, you run in full
> > dynticks
> > mode. Also the hook on the timer interrupt is
On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> On Fri, 8 Nov 2013 00:21:51 +0100
> Frederic Weisbecker wrote:
> >
> > Offloading to a workqueue would be perhaps better, and writing to the serial
> > console could then be done with interrupts enabled, preemptible context,
> >
the device status. As a result of this change
> any further calls to pm_runtime_get* would return -EACCES (since
> disable_depth is 1). On resume, we restore the clocks and runtime
> status exactly as we suspended with.
>
> Reported-by: J Keerthy
> Signed-off-by: Nishanth Menon
> Ac
A bit of cleanup plus some gratuitous variable renaming. I think using
structures instead of numeric offsets makes this code much more
understandable.
Also added a comment about current time range expected by
the server.
Cc: Jeff Layton
Cc: Steve French
Signed-off-by: Tim Gardner
---
The
On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown wrote:
>
[PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
I think it should be tca6507, right? Typo?
For other parts of this patch, I'm OK for them.
And just a quick scan of the leds-tca6507, I found bunch of typos in
the
On Tue, Nov 5, 2013 at 12:41 PM, Pantelis Antoniou
wrote:
> +
> + pr_info("%s: Applied #%d overlay segments @%d\n", __func__,
> + od->ovinfo_cnt, od->id);
> +
This could be pr_debug so that we get normally get silence unless
something fails, like insmod.
Also please
Hi Uwe,
On Wed, 6 Nov 2013 09:41:17 +0100 Uwe Kleine-König
wrote:
>
> BTW, "cortex" is a bit too general. My tree is only about Cortex-M. Also
> you can drop -2.6 from the URL.
Updated both, thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpDNpGVBonys.pgp
On Fri, 8 Nov 2013 00:21:51 +0100
Frederic Weisbecker wrote:
> Ok I see now.
>
> But then this irq_work based solution won't work if, say, you run in full
> dynticks
> mode. Also the hook on the timer interrupt is something that I wish we get rid
> of on archs that can trigger self-IPIs.
Do
On Fri, 8 Nov 2013 00:01:11 +0100
Jan Kara wrote:
> On Thu 07-11-13 23:54:10, Frederic Weisbecker wrote:
> > So if the current CPU can handle it, what is the problem?
> I hope this gets cleared out in my other email. But to make sure: If
> other CPUs are idle (i.e. not appending to the printk
On Tue, Sep 17, 2013 at 5:43 AM, Russ Dill wrote:
> This patch adds support for and demonstrates the usage of an embedded
> position independent executable (PIE). The goal is to allow the use of C
> code in situations where carefully written position independent assembly
> was previously
Quoting Nicolas Ferre (2013-10-18 01:18:04)
> On 11/10/2013 09:37, Boris BREZILLON :
> > Hello,
> >
> > This patch series is the 4th version of the new at91 clock implementation
> > (using common clk framework).
>
> Mike, DT maintainers,
>
> Can you have a look at this series converting the AT91
On Fri, 2013-11-08 at 00:14 +0100, Jan Kara wrote:
> Still unnecessary type cast here (but that's a cosmetic issue).
...
> Otherwise the patch looks good. You can add:
> Reviewed-by: Jan Kara
Thanks. A version with this correction and the reviewed-by follows.
--
In ext4, the bottom two bits of
Hi all,
Just a reminder to *not* add any v3.14 material to linux-next until after
v3.13-rc1 has been released.
Also, please resist the temptation to rebase your trees before sending
them upstream.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpYb_OjfDphf.pgp
As we start having more sharing of device trees between architectures (arm &
arm64, arm & powerpc, guessing maybe mips & arm) we need dts to live in
location that
I was wondering what people felt about doing:
arch/dts//
as a common location that could be shared. I'm up for other
On Thu, Nov 07, 2013 at 11:57:33PM +0100, Jan Kara wrote:
> On Thu 07-11-13 23:43:52, Frederic Weisbecker wrote:
> > 2013/11/7 Jan Kara :
> > > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > > are reported by our customers) when other CPUs are using printk heavily
> >
On Thu 07-11-13 17:54:24, David Turner wrote:
> On Thu, 2013-11-07 at 17:03 +0100, Jan Kara wrote:
> > So I'm somewhat wondering: Previously we decoded tv_nsec regardless of
> > tv_sec size. After your patch we do it only if sizeof(time->tv_sec) > 4. Is
> > this an intended change? Why is it OK?
On Thu, Oct 31, 2013 at 04:46:21PM -0500, Andy Gross wrote:
> On Thu, Oct 31, 2013 at 10:29:48PM +0530, Vinod Koul wrote:
> > On Fri, Oct 25, 2013 at 03:24:02PM -0500, Andy Gross wrote:
> >
> > This should be sent to dmaeng...@vger.kernel.org
>
> I'll add the list when I send the second
On Thu 07-11-13 23:54:10, Frederic Weisbecker wrote:
> On Thu, Nov 07, 2013 at 11:50:34PM +0100, Jan Kara wrote:
> > On Thu 07-11-13 23:23:14, Frederic Weisbecker wrote:
> > > On Thu, Nov 07, 2013 at 11:19:04PM +0100, Jan Kara wrote:
> > > > On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> >
On Thu, Nov 07, 2013 at 09:46:26PM +0100, Sebastian Andrzej Siewior wrote:
> On 07.11.13, Pantelis Antoniou wrote:
> > Hi Sebastian,
> Hi Pantelis,
>
> > FWIW DT has been ported to x86. And is present on arm/powerpc/mips/arc and
> > possibly
> > others.
>
> Yes, I know. I am the one that did
On Thu, 7 Nov 2013 23:43:52 +0100
Frederic Weisbecker wrote:
> When a message takes tens of seconds to be printed, it usually means
> we are in trouble somehow :)
> I wonder what printk source can trigger such a high volume.
The only ones that I'm aware of is the prints from sysrq. Which
On Thu 07-11-13 23:43:52, Frederic Weisbecker wrote:
> 2013/11/7 Jan Kara :
> > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > are reported by our customers) when other CPUs are using printk heavily
> > and serial console makes printing slow. Despite serial console
On 11/6/2013 7:06 PM, Greg KH wrote:
> On Wed, Nov 06, 2013 at 04:00:02PM -0800, Olav Haugan wrote:
>> On 11/5/2013 5:56 PM, Greg KH wrote:
>>> On Tue, Nov 05, 2013 at 04:54:12PM -0800, Olav Haugan wrote:
zsmalloc encodes a handle using the page pfn and an object
index. On some hardware
On Thu, Oct 31, 2013 at 7:33 PM, NeilBrown wrote:
>
>
> 1/ The led_info array must be allocated to allow the full number
> of LEDs even if not all are present. The array maybe be sparsely
> filled but it is indexed by device address so we must at least
> allocate as many slots as the
On Thu, 2013-11-07 at 17:03 +0100, Jan Kara wrote:
> So I'm somewhat wondering: Previously we decoded tv_nsec regardless of
> tv_sec size. After your patch we do it only if sizeof(time->tv_sec) > 4. Is
> this an intended change? Why is it OK?
This is an error. Here is a corrected version of
On Thu, Nov 07, 2013 at 11:50:34PM +0100, Jan Kara wrote:
> On Thu 07-11-13 23:23:14, Frederic Weisbecker wrote:
> > On Thu, Nov 07, 2013 at 11:19:04PM +0100, Jan Kara wrote:
> > > On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> > > > But then, who's going to process that work if every CPUs
On Thu, Nov 07, 2013 at 04:43:11PM +, Christoph Lameter wrote:
> usermodehelper() threads can currently run on all processors.
> This is an issue for low latency cores. Spawnig a new thread causes
> cpu holdoffs in the range of hundreds of microseconds to a few
> milliseconds. Not good for
On 11/07/2013 02:15 PM, Ard Biesheuvel wrote:
>
> That would involve repurposing/generalizing a bit more of the existing
> x86-only code than I did the first time around, but if you (as x86
> maintainers) are happy with that, I'm all for it.
>
> I do have a couple of questions then
> - the
On Thu, Nov 07, 2013 at 10:06:31PM +0200, Pantelis Antoniou wrote:
> Hi Sebastian,
>
> On Nov 7, 2013, at 9:25 PM, Sebastian Andrzej Siewior wrote:
>
> > On 06.11.13, Guenter Roeck wrote:
> > |…
> > thanks for the explanation.
> >
> >> We use DT overlays to describe the hardware on those boards
On Thu 07-11-13 23:23:14, Frederic Weisbecker wrote:
> On Thu, Nov 07, 2013 at 11:19:04PM +0100, Jan Kara wrote:
> > On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> > > But then, who's going to process that work if every CPUs is idle?
> > Have a look into irq_work_queue(). There is:
> >
On Thu, Nov 7, 2013 at 2:20 PM, Jan Kara wrote:
> On Thu 07-11-13 13:50:09, Andiry Xu wrote:
>> On Thu, Nov 7, 2013 at 1:07 PM, Jan Kara wrote:
>> > On Thu 07-11-13 12:14:13, Andiry Xu wrote:
>> >> On Wed, Nov 6, 2013 at 1:18 PM, Jan Kara wrote:
>> >> > On Tue 05-11-13 17:28:35, Andiry Xu
2013/11/7 Jan Kara :
> A CPU can be caught in console_unlock() for a long time (tens of seconds
> are reported by our customers) when other CPUs are using printk heavily
> and serial console makes printing slow. Despite serial console drivers
> are calling touch_nmi_watchdog() this triggers
On Thu, Nov 7, 2013 at 2:21 PM, Peter Zijlstra wrote:
> On Thu, Nov 07, 2013 at 01:15:51PM -0800, Tim Chen wrote:
>> Michel, are you planning to do an implementation of
>> load-acquire/store-release functions of various architectures?
>
> A little something like this:
>
Seeing this since todays USB merge.
WARNING: CPU: 0 PID: 226 at kernel/lockdep.c:2740
lockdep_trace_alloc+0xc5/0xd0()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
Modules linked in: usb_debug(+) kvm_intel kvm crct10dif_pclmul crc32c_intel
ghash_clmulni_intel microcode(+) pcspkr serio_raw
It makes sense to split out the Chromebook/Chromebox hardware platform
drivers to a separate subdirectory, since some of it will be shared
between ARM and x86.
This moves over the existing chromeos_laptop driver without making
any other changes, and adds appropriate Kconfig entries for the new
On 11/06/13 17:50, Josh Cartwright wrote:
> On Fri, Nov 01, 2013 at 03:08:53PM -0700, Stephen Boyd wrote:
>> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
>> index f35906b..71a8592 100644
>> --- a/arch/arm/kernel/devtree.c
>> +++ b/arch/arm/kernel/devtree.c
>> @@ -25,6 +25,7
On Thu, Nov 07, 2013 at 11:19:04PM +0100, Jan Kara wrote:
> On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> > But then, who's going to process that work if every CPUs is idle?
> Have a look into irq_work_queue(). There is:
> /*
> * If the work is not "lazy" or the tick is
> - the module aliases host tool has no arch specific dependencies at
> all except having x86cpu as one of the entries: would you mind
> dropping the x86 prefix there? Or rather add dependencies on $ARCH?
> (If we drop it there, we basically end up with 'cpu:' everywhere)
Should be fine.
> - in
On Thu, 7 Nov 2013 16:21:32 -0500 Johannes Weiner wrote:
> > Subject: provide estimated available memory in /proc/meminfo
> >
> > Many load balancing and workload placing programs check /proc/meminfo
> > to estimate how much free memory is available. They generally do this
> > by adding up
On Thu, Nov 07, 2013 at 11:19:04PM +0100, Jan Kara wrote:
> On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> > But then, who's going to process that work if every CPUs is idle?
> Have a look into irq_work_queue(). There is:
> /*
> * If the work is not "lazy" or the tick is
On Thu, Nov 07, 2013 at 01:15:51PM -0800, Tim Chen wrote:
> Michel, are you planning to do an implementation of
> load-acquire/store-release functions of various architectures?
A little something like this:
http://marc.info/?l=linux-arch=138386254111507
It so happens we were working on that the
On Thu, Nov 07, 2013 at 08:25:58PM +0100, Sebastian Andrzej Siewior wrote:
> On 06.11.13, Guenter Roeck wrote:
> |…
> thanks for the explanation.
>
> > We use DT overlays to describe the hardware on those boards and, if
> > necessary,
> > its configuration. For example, if there is a PCIe
On Thu 07-11-13 13:50:09, Andiry Xu wrote:
> On Thu, Nov 7, 2013 at 1:07 PM, Jan Kara wrote:
> > On Thu 07-11-13 12:14:13, Andiry Xu wrote:
> >> On Wed, Nov 6, 2013 at 1:18 PM, Jan Kara wrote:
> >> > On Tue 05-11-13 17:28:35, Andiry Xu wrote:
> >> >> >> Do you know the reason why write()
On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> 2013/11/7 Jan Kara :
> > Provide new irq work flag - IRQ_WORK_UNBOUND - meaning that can be
> > processed on any cpu. This flag implies IRQ_WORK_LAZY so that things are
> > simple and we don't have to pick any particular cpu to do the work. We
On 7 November 2013 22:39, Andi Kleen wrote:
> On Thu, Nov 07, 2013 at 01:09:41PM -0800, H. Peter Anvin wrote:
>> On 11/07/2013 09:17 AM, Ard Biesheuvel wrote:
>> > This series implements automatic module loading based on optional CPU
>> > features,
>> > and tries to do so in a generic way.
On Thu 07-11-13 13:38:00, Andrew Morton wrote:
> On Wed, 6 Nov 2013 17:42:30 -0800 Cody P Schafer
> wrote:
>
> > The iterator rbtree_postorder_for_each_entry_safe() relies on pointer
> > underflow behavior when testing for loop termination. In particular
> > it expects that
> > _entry(NULL,
2013/11/7 Jan Kara :
> Provide new irq work flag - IRQ_WORK_UNBOUND - meaning that can be
> processed on any cpu. This flag implies IRQ_WORK_LAZY so that things are
> simple and we don't have to pick any particular cpu to do the work. We
> just do the work from a timer tick on whichever cpu it
On Thursday 07 of November 2013 10:40:16 Rob Herring wrote:
> On Thu, Nov 7, 2013 at 5:32 AM, Tomasz Figa wrote:
> > Hi Grant,
> >
> > Could you pick this patch up? It fixes boot-up at least on several
> > Exynos based platforms, which use interrupt-map nodes with
> > #interrupt-cells higher
On Thursday 07 November 2013, Sebastian Hesselbarth wrote:
> I haven't looked deeper into this, but I guess it will not be hard
> to make ARM_TWD independent of SMP.
Yes, I agree. Just make sure to look at the list archives to see if someone
already did that work.
Arnd
--
To unsubscribe
On 13-11-06 09:00 AM, Stephen Warren wrote:
You probably don't want to reference the individual xxx1/2/3 nodes in
the client pinctrl properties, but instead wrap them in a higher-level
node that represents the whole pinctrl state. Then, the client pinctrl
properties can reference just that
On 11/07/2013 01:38 PM, Andrew Morton wrote:
On Wed, 6 Nov 2013 17:42:30 -0800 Cody P Schafer
wrote:
The iterator rbtree_postorder_for_each_entry_safe() relies on pointer
underflow behavior when testing for loop termination. In particular
it expects that
_entry(NULL, type, field)->field
On Wed, Oct 16, 2013 at 10:54:29AM -0500, Alex Thorlton wrote:
> Hi guys,
>
> I ran into a bug a week or so ago, that I believe has something to do
> with NUMA balancing, but I'm having a tough time tracking down exactly
> what is causing it. When running with the following configuration
>
Now when per-cpu printk buffers are gone, there's no need to have printk
flags or printk irq_work per cpu. Just make printk_pending a single
variable operated by atomic operations and have single unbound irq work
doing the waking and printing. This has an advantage that any cpu can do the
printing
A CPU can be caught in console_unlock() for a long time (tens of seconds
are reported by our customers) when other CPUs are using printk heavily
and serial console makes printing slow. Despite serial console drivers
are calling touch_nmi_watchdog() this triggers softlockup warnings
because
On Thu, Nov 7, 2013 at 1:07 PM, Jan Kara wrote:
> On Thu 07-11-13 12:14:13, Andiry Xu wrote:
>> On Wed, Nov 6, 2013 at 1:18 PM, Jan Kara wrote:
>> > On Tue 05-11-13 17:28:35, Andiry Xu wrote:
>> >> >> Do you know the reason why write() outperforms mmap() in some cases? I
>> >> >> know it's not
Provide new irq work flag - IRQ_WORK_UNBOUND - meaning that can be
processed on any cpu. This flag implies IRQ_WORK_LAZY so that things are
simple and we don't have to pick any particular cpu to do the work. We
just do the work from a timer tick on whichever cpu it happens first.
This is useful as
From: Steven Rostedt
To prevent deadlocks with doing a printk inside the scheduler,
printk_sched() was created. The issue is that printk has a console_sem
that it can grab and release. The release does a wake up if there's a
task pending on the sem, and this wake up grabs the rq locks that is
Hello,
This is the next iteration of my printk patchset. Since v5 I've made the
limit for printing configurable via kernel parameter and let it default to 0.
So unless user sets printk.offload_chars on kernel command line, there will
be no difference to current printk behavior.
Summary:
On Wed, Nov 06, 2013 at 01:10:48PM +, Mel Gorman wrote:
> On Mon, Nov 04, 2013 at 02:03:46PM -0600, Alex Thorlton wrote:
> > On Mon, Nov 04, 2013 at 02:58:28PM +, Mel Gorman wrote:
> > > On Wed, Oct 16, 2013 at 10:54:29AM -0500, Alex Thorlton wrote:
> > > > Hi guys,
> > > >
> > > > I ran
On Wed, Nov 06, 2013 at 09:42:15PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 06, 2013 at 04:51:52PM -0700, Bjorn Helgaas wrote:
> > [+cc Thomas, Ingo, Peter, x86 list]
> >
> > On Wed, Nov 6, 2013 at 2:16 PM, Konrad Rzeszutek Wilk
> > wrote:
> > > Certain platforms do not allow writes in
On Wed, Nov 06, 2013 at 02:30:40PM -0500, Douglas Gilbert wrote:
> >during sg_open and sg_release, which are guranteed not to migrate
> >to a different process during their run time.
>
> True. What I stated would be a problem if a mutex tried
> to do something similar to Vaughan's patch that was
On Thu, Nov 07, 2013 at 01:09:41PM -0800, H. Peter Anvin wrote:
> On 11/07/2013 09:17 AM, Ard Biesheuvel wrote:
> > This series implements automatic module loading based on optional CPU
> > features,
> > and tries to do so in a generic way. Currently, 32 feature bits are
> > supported,
> > and
On Wed, 6 Nov 2013 17:42:30 -0800 Cody P Schafer
wrote:
> The iterator rbtree_postorder_for_each_entry_safe() relies on pointer
> underflow behavior when testing for loop termination. In particular
> it expects that
> _entry(NULL, type, field)->field
> is NULL. But the result of this
On Thu, Nov 07, 2013 at 10:13:45AM -0500, Rik van Riel wrote:
>
> > > fs/proc/meminfo.c | 36
> > > 1 file changed, 36 insertions(+)
> >
> > Documentation/filesystems/proc.txt told me it's feeling all offended.
>
> You're right, of course. Here is version
201 - 300 of 1350 matches
Mail list logo
