d() function calling set_mems_allowed
with irqs enabled. While its possibly unlikely for the actual deadlock
to trigger, a fix is fairly simple: disable irqs before taking the
mems_allowed_seq lock.
Cc: Li Zefan
Cc: Mathieu Desnoyers
Cc: Steven Rostedt
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc
if you have any issues or concerns.
thanks
-john
The following changes since commit 389e067032fbb96e439abafae848dd447e4cafb4:
Merge branch 'fortglx/3.12/time' into fortglx/3.13/time (2013-09-16 18:54:07
-0700)
are available in the git repository at:
git://git.linaro.org/people/jstul
On 09/26/2013 12:26 PM, Eric Dumazet wrote:
> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
>> In order to enable lockdep on seqcount/seqlock structures, we
>> must explicitly initialize any locks.
>>
>> diff --git a/include/linux/u64_stats_sync.h b/include/linu
On 09/26/2013 12:34 PM, John Stultz wrote:
> On 09/26/2013 12:26 PM, Eric Dumazet wrote:
>> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
>>> In order to enable lockdep on seqcount/seqlock structures, we
>>> must explicitly initialize any locks.
>>
On 09/26/2013 12:30 PM, Eric Dumazet wrote:
> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
>> While enabling lockdep on seqlocks, I ran accross the warning below
>> caused by the ipv6 stats being updated in both irq and non-irq context.
>>
>> This is a novice a
On 09/26/2013 01:46 PM, Steven Rostedt wrote:
> On Thu, 26 Sep 2013 11:34:22 -0700
> John Stultz wrote:
>
>> @@ -156,10 +214,19 @@ static inline void write_seqcount_begin(seqcount_t *s)
>> {
>> s->sequence++;
>> smp_wmb();
>> +se
On 09/26/2013 10:47 PM, Ingo Molnar wrote:
> * John Stultz wrote:
>
>> On 09/26/2013 12:30 PM, Eric Dumazet wrote:
>>> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
>>>> While enabling lockdep on seqlocks, I ran accross the warning below
>>>> c
-0700)
John Johansen (1):
apparmor: fix suspicious RCU usage warning in policy.c/policy.h
Tyler Hicks (1):
apparmor: Use shash crypto API interface for profile hashes
security/apparmor/crypto.c | 34
lace+0x35/0x4c
[ 29.804835] [] vfs_write+0xad/0x113
[ 29.804840] [] SyS_write+0x44/0x7a
[ 29.804847] [] system_call_fastpath+0x16/0x1b
Reported-by: miles.l...@gmail.com
CC: paul...@linux.vnet.ibm.com
Signed-off-by: John Johansen
---
security/apparmor/include/policy.h | 4 +++-
sec
Signed-off-by: John Johansen
---
security/apparmor/crypto.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/security/apparmor/crypto.c b/security/apparmor/crypto.c
index d6222ba..532471d 100644
--- a/security/apparmor/crypto.c
+++ b/security
sed on
tip/timers/core, this pull request seems to be submitting items that are
already in tip/timers/core (like the changes from Prarit, Miroslav and
Zoran).
Does any of the changes here actually depend on 3.12-rc3? If not you
might just re-generate the branch against tip/timers/core, and you&
On 09/30/2013 11:09 AM, Daniel Lezcano wrote:
> On 09/30/2013 07:49 PM, John Stultz wrote:
>> On 09/30/2013 10:41 AM, Daniel Lezcano wrote:
>>>
>>> Hi Thomas,
>>>
>>> this pull request is based on 3.12-rc3 with the following content:
>>>
>
kmalloc() buffers to be handled in the same manner.
https://launchpad.net/bugs/1216294/
Signed-off-by: Tyler Hicks
Acked-by: John Johansen
---
I've tested this patch by comparing aafs/policy/profiles/*/sha1 between a
patched i386 VM (i386 is where the BUG is easily reproduced) and an unpa
pull
request. But now that the prereqs are in tip/timers/core for 3.13, I've
merge it up and I wanted to go ahead and send this out.
Let me know if you have any issues or concerns.
thanks
-john
The following changes since commit 389e067032fbb96e439abafae848dd447e4cafb4:
Merge branch 'fo
On 09/24/2013 04:58 PM, John Stultz wrote:
> Hey Daniel,
> Here's the sched_clock_register conversion that Stephen did earlier
> this summer, as part of extending the generic sched_clock code to
> support 64bit counters. Unfortunately the prereqs for this series missed
&
ame thing to Kees off list. But I don't have an
> answer either.
>
> Acked-by: Eric Paris
>
Yeah I'm not fond of it either but until some more generic form of LSM
stacking arives, I don't see a good alternative either
so until then
Acked-by: John Johan
Y || (int)arg2 == -1) {
> rc = yama_ptracer_add(NULL, myself);
> } else {
> struct task_struct *tracer;
>
yeah this looks good it should at least hit stable
Acked-by: John Johansen
--
To unsubscribe from this list: send the line &
)
Reported-and-debugged-by: Jon Medhurst (Tixy)
Signed-off-by: John Stultz
---
drivers/base/power/wakeup.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index cbb463b..0e4b093 100644
--- a/drivers/base
appears between v3.5 and v3.6-rc1.
It is not easy to reproduce but after taking some time to dig, it seems
to appear with this commit:
1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
Author: John Stultz
Date: Fri Jul 13 01:21:53 2012
On 09/09/2012 12:59 AM, Fengguang Wu wrote:
Hi John,
The below lockup warning pops up very occasionally in kvm guest
kernels and it's bisected down to
commit 2a8c0883c3cfffcc148ea606e2a4e7453cd75e73
Author: John Stultz
Date: Fri Jul 13 01:21:56 2012
On 09/07/2012 02:35 PM, Daniel Lezcano wrote:
On 09/07/2012 07:22 PM, John Stultz wrote:
On 09/07/2012 07:20 AM, Daniel Lezcano wrote:
On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:
On Thursday, September 06, 2012, Daniel Lezcano wrote:
On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
On
On 09/10/2012 12:45 PM, Daniel Lezcano wrote:
On 09/10/2012 07:14 PM, John Stultz wrote:
In the meantime, I'll try to reproduce on my T61. If you could send me
your .config, I'd appreciate it.
http://pastebin.com/qSxqfdDK
The header of the config file shows for a v3.5-rc7 because
own to
06ae115a1d551cd952d8 (when using the kvm clock) if it was more of a
hardware issue. And in those logs, I don't see the printk time-stamp
inconsistencies that were alluded to in this thread.
Fengguang: Is this still reproducible? Do you have any details (dmesg)
about host system as w
On 10/07/2012 11:25 PM, Minchan Kim wrote:
Hi John,
On Fri, Sep 28, 2012 at 11:16:30PM -0400, John Stultz wrote:
After Kernel Summit and Plumbers, I wanted to consider all the various
side-discussions and try to summarize my current thoughts here along
with sending out my current
also very much resembles volatile mmap ranges
(i.e. the work that John Stultz is leading in parallel).
Agreed. I haven't been paying close attention to those patches but it
seems to me that one possiblity is that a listener for a vmevent would
set volatile ranges in response.
I don't
On 10/04/2012 06:48 AM, Prarit Bhargava wrote:
Add debugfs entries for ntp time_status and time_state. These are useful
for debugging ntp issues.
Aren't these easily fetched from adjtimex()? How does having them in
debugfs help?
thanks
-john
--
To unsubscribe from this list: send the
seconds.
Thanks for the audit, and sending this in!
Thomas: Mind queuing this? Probably should be marked for stable too.
Acked-by: John Stultz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
mpfs, only as a convenience to userland in switching from virtual
address to/from mmapped file offset may be better left to a userland
library.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On 12/02/2012 11:36 PM, Zhangfei Gao wrote:
Provide a -O option to specify dir to put generated .config
Then merge_config.sh does not need to be copied to target dir,
for easy re-usage in other script
Signed-off-by: Zhangfei Gao
Tested-by: Jon Medhurst (Tixy)
Acked-by: John Stultz
thanks
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Saturday, December 01, 2012 12:49 PM
> To: Philip Balister
> Cc: Greg KH; Eli Billauer; linux-kernel@vger.kernel.org; Pavel Machek; John
> Linn; Michal Simek; Ira W.
> Snyder; Josh Cartwright
&g
nstructions
(commenting out various lines) to try to figure out what exactly is
triggering it.
Sorry for the trouble!
thanks
-john
--
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 12/03/2012 04:00 PM, Minchan Kim wrote:
On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote:
On 11/21/2012 04:36 PM, John Stultz wrote:
2) Being able to use this with tmpfs files. I'm currently trying
to better understand the rmap code, looking to see if there's a
w
our dmesg and kernel config?
After that I'll likely have to send you some debugging instructions
(commenting out various lines) to try to figure out what exactly is
triggering it.
Sorry for the trouble!
Hey John,
Don't worry, I know how it is to be busy.
For the dmesg/kernel config is
On 12/03/2012 11:22 PM, Minchan Kim wrote:
On Mon, Dec 03, 2012 at 04:57:20PM -0800, John Stultz wrote:
On 12/03/2012 04:00 PM, Minchan Kim wrote:
On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote:
On 11/21/2012 04:36 PM, John Stultz wrote:
2) Being able to use this with tmpfs
lity.h
> However, capability.h was moved to include/uapi/linux/capability.h and
> because
> of this, the array is empty.
> That's why, sa->u.cap become out of range this and segmentation fault caused.
>
> Let's fix it.
>
> Cc: James Morris
> Cc: John
On 12/04/2012 11:01 PM, Minchan Kim wrote:
Hi John,
On Tue, Dec 04, 2012 at 11:13:40AM -0800, John Stultz wrote:
I don't think the problem is when vmas being marked VM_VOLATILE are
being merged, its that when we mark the vma as *non-volatile*, and
remove the VM_VOLATILE flag we merge th
On 12/04/2012 08:18 PM, Minchan Kim wrote:
On Tue, Dec 04, 2012 at 11:13:40AM -0800, John Stultz wrote:
I don't think the problem is when vmas being marked VM_VOLATILE are
being merged, its that when we mark the vma as *non-volatile*, and
remove the VM_VOLATILE flag we merge the non-vol
attempt
to use the non-zeroed area as actual command entries.
Signed-off-by: John Blackwood
Index: b/kernel/debug/kdb/kdb_main.c
===
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -3341,7 +334
On 12/08/2012 03:10 AM, Heinz Wiesinger wrote:
On Tuesday 04 December 2012 10:34:39 John Stultz wrote:
On 12/04/2012 02:34 AM, Heinz Wiesinger wrote:
On Monday 03 December 2012 15:14:12 you wrote:
On 11/05/2012 02:55 PM, Heinz Wiesinger wrote:
On Monday 05 November 2012 11:13:31 Greg KH
the meantime, I'll be reading your patch in detail and seeing how we
might be able to combine our differing approaches.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
ot;../vclock_gettime.c"
+#endif
Could you expand a bit as to why a compat layer isn't possible? It seems
we could easily convert the vsyscall_gtod_data to a more explicit
arch-neutral size. Or is it the actual data page mapping?
thanks
-john
--
To unsubscribe from this list: send the line &quo
On 11/11/2012 12:32 PM, Stephane Eranian wrote:
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz wrote:
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
Hi,
There are many situations where we want to correlate events happening at
the user
final implementation in later
patches, because they already have function pointers in place for this
purpose.
Cc: Russell King
Cc: Mike Frysinger
Cc: Mikael Starvik
Cc: Hirokazu Takata
Cc: John Stultz
Cc: Thomas Gleixner
Acked-by: Geert Uytterhoeven
Acked-by: Jesper Nilsson
Signed-off-by: Stephen W
On 11/12/2012 12:54 PM, Stephane Eranian wrote:
On Mon, Nov 12, 2012 at 7:53 PM, John Stultz wrote:
On 11/11/2012 12:32 PM, Stephane Eranian wrote:
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz
wrote:
Also I worry that it will be abused in the same way that direct TSC
access
is, where the
a way that you always see good
results, where as with NOHZ the alignment might not be the same, so you
see periodic delays from timer interrupts, etc.
Anyway, let me know if this got resolved or not.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
_real() from intel_idle() to the second call of
ktime_get_real(), between which we're in deep idle (which would make sense)?
Because unless the timekeeping lock is getting held for a long time, I
don't know why else you'd see such long delays at getnstimeofday().
Cc'ing St
On 11/12/2012 03:53 PM, John Stultz wrote:
On 11/05/2012 12:51 AM, David Henningsson wrote:
Hi LKML,
I'm trying to make audio more useful in everyday low-latency
scenarios such as gaming or VOIP.
While doing so, I ran the wakeup_rt tracer, to track the time from
PulseAudio reque
On 11/12/2012 05:53 PM, Shan Wei wrote:
From: Shan Wei
Signed-off-by: Shan Wei
Reviewed-by: Christoph Lameter
Please provide a changelog (even for trivial changes) in the future.
Applied to my tree.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-k
/jiffies.c kernel/time/jiffies.c:61:20: warning: symbol
'clocksource_jiffies' was not declared. Should it be static?
Signed-off-by: Lars-Peter Clausen
Applied. Thanks!
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 10/19/2012 09:46 PM, Dan Carpenter wrote:
I changed the strict_strtoul() to kstrtouint(). That has the check
for UINT_MAX built in to it so the ifdefs can be removed. Also
I changed a printk() to pr_info().
Signed-off-by: Dan Carpenter
Applied. Thanks!
-john
--
To unsubscribe from this
On 11/13/2012 07:58 PM, Kees Cook wrote:
> Stop using spinlocks in the read path. Add RCU list to handle the readers.
>
> Signed-off-by: Kees Cook
Looks good to me
Acked-by: John Johansen
> ---
> security/yama/yama_lsm.c | 43 ---
&g
On 11/13/2012 12:58 PM, Steven Rostedt wrote:
On Fri, 2012-11-09 at 18:04 -0800, John Stultz wrote:
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
I've no problem with adding CLOCK_PERF (or another/better name).
Hrm. I'm not excited about exporting that sort of internal kernel
/2012/9/13/367
v8: http://lkml.org/lkml/2012/9/19/525
v9: http://lkml.org/lkml/2012/9/24/538
Just catching up from being on leave, but I've not seen any response to
this.
Are there objections to this patch set? Or did it just get buried in
everyone's inbox?
thanks
-j
thing is pretty straightforward.
Ping? Did this patchset fall through the cracks? Any issues left to
address?
thanks
-john
--
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 http://vger.kerne
ned-off-by: Axel Lin
for both of these feel free to add ...
Acked-by: John Crispin
Thanks,
John
--
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 http://vger.kernel.org/majord
> -Original Message-
> From: Josh Cartwright [mailto:josh.cartwri...@ni.com]
> Sent: Wednesday, November 07, 2012 6:18 AM
> To: Michal Simek
> Cc: a...@kernel.org; Arnd Bergmann; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org;
> John Linn; Nick
-mips patchwork. I would set it to "Other
Subsystem" if you took it already.
Thanks,
John
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I may not have my brain plugged in all the way yet).
thanks
-john
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
de that will break when moved from one machine to the next.
I'd probably rather perf output timestamps to userland using sane clocks
(CLOCK_MONOTONIC), rather then trying to introduce a new time domain to
userland. But I probably could be convinced I'm wrong.
thanks
-john
--
To unsubs
eported-by: Doug Anderson
Cc: Anton Vorontsov
Cc: John Stultz
Signed-off-by: Kees Cook
---
v2:
- export needed for timekeeping_suspended (thanks to Fengguang Wu).
---
fs/pstore/ram.c |8 +++-
kernel/time/timekeeping.c |1 +
2 files changed, 8 insertions(+), 1 deletio
On Thursday, December 27, 2012 4:08:46 AM UTC+2, Kent Overstreet wrote:
...
Great. Did you measure by how much your changes improve performance?
-- john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
really been able to get my head around the implications of this change.
Really, I'm not sure if I'll get to this before the new year.
Its on my list, but don't be afraid to ping me early Jan if I haven't
queued it for 3.9 by then.
thanks
-john
--
To unsubscribe from this
es, so I'd prefer they be merged through the arch tree, where it
can get proper review/testing.
Acked-by: John Stultz
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
will have to wait for 3.9.
Sorry for the delay, and thanks again!
-john
--
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 http://vger.kernel.org/majordomo-info.html
Please read t
e,
since it will return the time at the last tick, and doesn't require
accessing the clocksource hardware. Might that be a simpler solution?
Or is sub-tick granularity necessary?
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 11/18/2012 12:09 PM, Kees Cook wrote:
On Fri, Nov 16, 2012 at 7:16 PM, John Stultz wrote:
Yea, I wanted to revisit this, because it is an odd case.
We don't want to call getnstimeofday() while the timekeeping code is
suspended, since the clocksource cycle_last value may be invalid i
On 11/19/2012 09:45 AM, Kees Cook wrote:
On Mon, Nov 19, 2012 at 9:23 AM, John Stultz wrote:
On 11/18/2012 12:09 PM, Kees Cook wrote:
On Fri, Nov 16, 2012 at 7:16 PM, John Stultz wrote:
Yea, I wanted to revisit this, because it is an odd case.
We don't want to call getnstimeofday()
Hey Thomas,
I wanted to send you just a few minor changes I have queued for
3.8. Let me know if you have any objections.
thanks
-john
The following changes since commit a1c2d60889d633ffecfa9f1f7ac0bdb474b7484e:
Merge branch 'drm-fixes' of
git://people.freedesktop.org/~air
hes these kinds of things.
>
> I just fixed up those two. "git quiltimport" works now.
>
Where did you fix these up? Can we have access?
Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
n the real
HW too, but it never resumes there.
Thanks for chasing this down! Sorry for the trouble, does the following fix
resolve this?
thanks
-john
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 675f720..94041a9 100644
--- a/kernel/time/timekeeping.c
+++
On 04/22/2013 09:05 AM, John Stultz wrote:
On 04/20/2013 08:46 AM, Jiri Slaby wrote:
Hi,
my machine does not wake from suspend to RAM on my box running the -next
kernel. The last thing I see is "Disabling non-boot CPUs ...". I
bisected it to this commi
bably also prototype and test the 64bit code with x86_64, using the
TSC counter.
thanks
-john
--
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 http://vger.kernel.org/majordomo-info.
*/
- clock->cycle_last = cycle_now;
+ tk->cycle_last = clock->cycle_last = cycle_now;
Looks good.
Acked-by: John Stultz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
On 06/11/2013 11:48 PM, NeilBrown wrote:
On Tue, 11 Jun 2013 21:22:48 -0700 John Stultz wrote:
From: Minchan Kim
This patch adds new system call sys_vrange.
NAME
vrange - Mark or unmark range of memory as volatile
SYNOPSIS
int vrange(unsigned_long start, size_t length, int
nd for
non-passthrough devices, same as we do at open/stop.
While at it - since we touch this code anyway - check
dev_set_promiscuity return code and pass it to users (though an error
here is unlikely).
Cc: "David S. Miller"
CC: Roopa Prabhu
Cc: John Fastabend
Signed-off-by
On 06/12/2013 11:28 PM, Minchan Kim wrote:
Hey John,
On Tue, Jun 11, 2013 at 09:22:47PM -0700, John Stultz wrote:
At lsf-mm, the issue was brought up that there is a precedence with
interfaces like mlock, such that new mappings in a pre-existing range
do no inherit the mlock state.
This is
we're going to add a
new interface, lets not use an already out-dated structure (timeval).
Instead could you rework this to be timepsec based? Or ktime_t if its
really internal only?
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
atches are probably going to need a good bit more
work.
thanks
-john
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ed an equivalent resolution settime method?
thanks
-john
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
write_seqcount_begin(&timekeeper_seq);
+ systime_was_set = true;
+
+
timekeeping_forward_now(tk);
xt = tk_xtime(tk);
Might also want to add the flag to inject_offset as well, since that
could be used to set the time.
thanks
-john
--
To unsubscribe from this list: send
On 06/14/2013 11:05 AM, Alexander Holler wrote:
Am 14.06.2013 19:41, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
In order to let an RTC set the time at boot without the problem that a
second RTC overwrites it, the flag systime_was_set is introduced.
systime_was_set
all() and instead have it called when we register the RTC that
matches CONFIG_RTC_HCTOSYS_DEVICE.
I suspect it will end up being a much smaller change that way.
Then the last bit is just a matter of adding the
timekeeping_systimeset() check to the hctosys bits.
thanks
-john
--
To un
On 06/14/2013 10:43 AM, Alexander Holler wrote:
Am 14.06.2013 19:23, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
Some RTCs offer a higher resolution than seconds. To support reading
such
high resolution timestamps from inside the kernel implement
rtc_read_timeval
v_nsec = tv.tv_usec*NSEC_PER_USEC;
Yea, this sort of fallback logic should be centralized in the RTC layer
rather then in the individual users.
Might be easiest to modify the rtc_read_timeval() interface to try the
ops->read_timeval() operation and do the fallback to rtc_read_time()
inter
mpile time CONFIG_RTC_HCTOSYS_DEVICE?
If we need a boot argument, that's still doable, but it probably should
fall back to CONFIG_RTC_HCTOSYS_DEVICE if not specified.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
On 06/16/2013 02:45 AM, Baruch Siach wrote:
Hi John,
On Tue, Jun 04, 2013 at 10:53:04AM -0700, John Stultz wrote:
On 06/04/2013 09:09 AM, Will Deacon wrote:
On Tue, Jun 04, 2013 at 01:19:48AM +0100, John Stultz wrote:
On 06/01/2013 11:39 PM, Stephen Boyd wrote:
This is mostly a resend of a
On 06/04/2013 12:32 AM, Marcus Gelderie wrote:
On Mon, Jun 03, 2013 at 12:21:22PM -0700, John Stultz wrote:
These probably should be EXPORT_SYMBOL_GPL, no? Also there's a bunch of
new alarm functions that Todd Poynor that I have queued, which will
probably need similar.
thanks
-john
Opps
On 06/04/2013 09:09 AM, Will Deacon wrote:
On Tue, Jun 04, 2013 at 01:19:48AM +0100, John Stultz wrote:
On 06/01/2013 11:39 PM, Stephen Boyd wrote:
This is mostly a resend of a patch series I sent a little over a month
ago. I've reordered the patches so that John can pick up the first
ng linux/sched.h?
I don't know. John/Thomas, any thoughts? One benefit with it this way is
that we don't have to recompile all the timer drivers if we change
sched.h for other reasons.
Yea, I'm fine keeping it separate for now. We can merge them together if
we see fit later.
But if an
_read(void)
{
- return (u32)(jiffies - INITIAL_JIFFIES);
+ return (u64)(jiffies - INITIAL_JIFFIES);
}
Also, you might add a comment noting you register jiffies w/
BITS_PER_LONG, to clarify don't have to use jiffies_64 here on 32bit
systems (despite the u64 cast)?
thanks
On 06/14/2013 11:01 PM, Alexander Holler wrote:
Am 14.06.2013 20:28, schrieb John Stultz:
On 06/14/2013 11:05 AM, Alexander Holler wrote:
Am 14.06.2013 19:41, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
In order to let an RTC set the time at boot without the problem
hes land there) and send a pull request to
the maintainer (so he gets the dependencies in -tip), or we can see
about queuing your changes via tip/timers/core (assuming you get
maintainer acks).
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hey Thomas,
Here's the second chunk of changes I have pending for 3.11. Its
mostly the changes to make arm's sched_clock implementation generic.
Let me know if you have any objection.
thanks
-john
The following changes since commit 762cf9695d714d312ef7369bed1b9f9467c9e64e
On 06/17/2013 12:51 PM, Stephen Boyd wrote:
John,
I just saw your pull request for making this code generic. I believe
this patch fixes a bug that nobody has seen in practice so it's probably
fine to delay this until 3.11.
Also, I've just noticed that "ARM: sched_clock: Return
problem by reading the hardware after the epoch has
stabilized.
Cc: Russell King
Signed-off-by: Stephen Boyd
Thanks for the resend here.
I've got this in my tree and unless I get an objection in the next day
or so, I'll send it on to Thomas.
thanks
-john
--
To unsubscribe from this
eboot.
Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
u
nt of testing and run time
before this gets merged, so 3.12 is what we'd be targeting at the
earliest (its getting a bit late for taking changes for 3.11 anyway).
If you want to try to push patch 1/4 in for 3.11 via the Xen tree, I'll
see about queuing the other three for hopefully 3.12.
On 06/19/2013 10:13 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 19, 2013 at 09:52:06AM -0700, John Stultz wrote:
On 06/19/2013 08:25 AM, David Vrabel wrote:
From: David Vrabel
The high resolution timer code gets notified of step changes to the
system time with clock_was_set() or
On 06/20/2013 03:15 AM, Alexander Holler wrote:
Am 17.06.2013 20:10, schrieb John Stultz:
On 06/14/2013 11:01 PM, Alexander Holler wrote:
What do you think I should write?
void set_systime_was_set(void) and void clear_systime_was_set(void)?
And both functions would have to be exported in
On 06/20/2013 11:45 AM, Alexander Holler wrote:
Am 20.06.2013 19:27, schrieb John Stultz:
On 06/20/2013 03:15 AM, Alexander Holler wrote:
Therefor there now will be hctosys as a kernel command line parameter.
Instead of a kernel config option which can't be changed by 99% of all
Linux
401 - 500 of 11551 matches
Mail list logo
