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 "free
> - 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 t
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 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 @@
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
dir
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
CPU:
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:
> http://marc.info/?l=linux-a
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 softloc
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 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 is idle?
> > Have a look into irq_work_queue(). There is:
> >
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 module
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, 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 core
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, 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 the
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 highes
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 p
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 dri
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
includ
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 the
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, 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 iteratio
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?
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 sugg
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
> >
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
Descripti
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
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 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 required.
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 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 w
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
Descr
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 t
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 com
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 comm
indicates 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 Meno
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,
> > e
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.
-B
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
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 C
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, i
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 +348,
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 description.
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 signedn
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 b/d
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 d
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(-)
diff
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 b/drivers/cha
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' para
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 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
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 simplific
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 i
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 fi
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 thin
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 sk_filter_release_r
nded with.
Reported-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 cpufre
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 crct10dif_pclm
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 che
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 __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 OPS
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.
Thi
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 regu
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:
qatarf
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
> /home/johan/src/linux/linux-nu/mm/dmapool.c:3
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(+)
> > >
> > > Documentation/filesystem
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 featu
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 Documentation/devicetree/bindings/c
ee. Makes sense.
>>
>> 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 th
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
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 CONFIG_PAGE_OFFSET=0xC00
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
>
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 5a0bdaa..e32919f 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -133,6 +133,8 @@ void panic(const char *fmt, ...)
bust_spin
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 b/k
Otherwise we might not reboot when the user needs it the most (early
on).
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index b6c482c..46e37ff 100644
--- a/kernel/panic.c
+++ b
Hi,
While debugging a hang after panic in my laptop (I cannot hard-reboot, or
unplug the battery), I noticed the panic code has some areas of improvment.
Only the first patch is really needed, the rest seem like good to have.
Felipe Contreras (3):
panic: setup panic_timeout early
panic: impr
On Wed, 2013-11-06 at 11:28 -0800, Eric Dumazet wrote:
> On Wed, 2013-11-06 at 20:19 +0100, Daniel Borkmann wrote:
>
> > When you send v2 with Alexei's feedback, please also be more specific
> > in your subject like "net: x86: bpf: don't forget to free sk_filter"
> > or the like. Also it's enough
On 11/08/2013 04:59 AM, Paul E. McKenney wrote:
> On Thu, Nov 07, 2013 at 10:30:25AM +0800, Chen Gang wrote:
>> > If the contents is more than 4096 bytes (e.g. if have 1K cpus), current
>> > sprintf() will cause memory overflow. And this fix patch is to be sure
>> > of memory large enough.
>> >
>>
On Fri, 2013-11-08 at 00:56 +, Keller, Jacob E wrote:
> Has there been any mention of a forthcoming patch
> to ./Documentation/SubmittingPatches which documents this?
I do not remember if this point was raised, but you certainly
can submit a patch !
Thanks
--
To unsubscribe from this list:
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
drivers/usb/core/file.c between commit 469271f8c48f ("drivers: usb: core:
{file,hub,sysfs,usb}.c: Whitespace fixes") from Linus' tree and commit
e84f9e57b90c ("consolidate the reassignments of ->f_op in ->open()
instances") from the
Dear Sebastian,
On Thu, 7 Nov 2013 13:22:35 -0800
Sebastian Hesselbarth wrote:
> On 11/07/2013 05:20 PM, Arnd Bergmann wrote:
> > On Thursday 07 November 2013, Sebastian Hesselbarth wrote:
> >> Actually, IIRC smp_twd does not compile without SMP set, so the above
> >> should at least be 'HAVE_AR
On Thu, 2013-11-07 at 14:43 -0800, Michel Lespinasse wrote:
> 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 architectu
From: Mahesh Sivasubramanian
LPAE enabled kernels use the 64-bit version of TTBR0 and TTBR1
registers. If we're running an LPAE kernel, fill the upper half
of TTBR0 with 0 because we're setting it to the idmap here (the
idmap is guaranteed to be < 4Gb) and fully restore TTBR1 instead
of just rest
Joe Perches writes:
> On Fri, 2013-11-08 at 09:41 +1030, Rusty Russell wrote:
>> Joe Perches writes:
>> > That's a trust issue.
>> > I've done it. It isn't necessary.
>>
>> WTF? Now you just said it's not necessary, I *know* I can't trust you.
>
> "It" in this case is the grep that I did
> pri
On Thu, Nov 7, 2013 at 1:20 PM, Stephen Boyd wrote:
> If we're running on a v7 ARM CPU, detect if the CPU supports the
> sdiv/udiv instructions and replace the signed and unsigned
> division library functions with an sdiv/udiv instruction.
[snip]
> diff --git a/arch/arm/lib/Makefile b/arch/arm/l
On 11/05/13 at 05:16pm, Baoquan He wrote:
> Currently system always reboot after below message when execute "kexec -e".
>
> [0.572119] smpboot: Booting Node 0, Processors # 1 OK
>
> In commit 1b3a5d02ee070c8f994b9b6370f486601e0f, reboot= handling was
> moved to kerne/reboot.c. Howeve
Dear Dmitry Artamonow,
> Fix following build failure observed when support for
> OHCI host controller is enabled.
>
> CC arch/arm/mach-pxa/colibri-evalboard.o
> arch/arm/mach-pxa/colibri-evalboard.c: In function 'colibri_ohci_init':
> arch/arm/mach-pxa/colibri-evalboard.c:68: error: implic
On 2013-11-07 07:51, 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 the MSI-X bars
to setup or tear down vector values. To combat against
the generic code trying to write to that an
On Thu, 7 Nov 2013 16:40:57 -0700
Tim Gardner wrote:
> 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:
On Fri, 2013-11-08 at 11:56 +1030, Rusty Russell wrote:
> Joe Perches writes:
> > On Fri, 2013-11-08 at 09:41 +1030, Rusty Russell wrote:
> >> Joe Perches writes:
> >> > That's a trust issue.
> >> > I've done it. It isn't necessary.
> >>
> >> WTF? Now you just said it's not necessary, I *know*
Hi all,
On Thu, 07 Nov 2013 18:04:57 -0600 Dave Kleikamp
wrote:
>
> Can you please drop the aio-direct tree for the time being?
OK, I was afraid of this, but, yes, I can drop it. I am not quite sure
what affect this will have on Andrew's tree, though (hopefully not too
much).
This is a bit di
zsmalloc encodes a handle using the pfn and an object
index. On hardware platforms with physical memory starting
at 0x0 the pfn can be 0. This causes the encoded handle to be
0 and is incorrectly interpreted as an allocation failure.
To prevent this false error we ensure that the encoded handle
wi
On Thu, Nov 07, 2013 at 09:06:26AM -0800, Luigi Semenzato wrote:
> If I may add my usual 2c (and some news):
>
> zram is used by default on all Chrome OS devices. I can't say how
> many devices, but it's not a small number, google it, and it's an
> important market, low-end laptops for education
On Fri, Nov 08, 2013 at 12:53:07PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 07 Nov 2013 18:04:57 -0600 Dave Kleikamp
> wrote:
> >
> > Can you please drop the aio-direct tree for the time being?
>
> OK, I was afraid of this, but, yes, I can drop it. I am not quite sure
> what affect
This is the start of the review cycle for the Linux 3.8.13.13 stable kernel.
This version contains 91 new patches, summarized below. The new patches are
posted as replies to this message and also available in this git branch:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=linux-3.8.y-review;a
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Bob Moore
commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.
This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object di
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Takashi Iwai
commit 6fc16e58adf50c0f1e4478538983fb5ff6f453d4 upstream.
ASUS N76VZ needs the same fixup as N56VZ for supporting the boost
speaker.
Bugzilla: https://bugzilla.novell.com/
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Pravin B Shelar
commit 14bbd6a565e1bcdc240d44687edb93f721cfdf99 upstream.
This function will be used in next GRE_GSO patch. This patch does
not change any functionality.
Signed-off-by:
401 - 500 of 675 matches
Mail list logo
