Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Hi! Am 26.04.2015 um 22:57 schrieb Thomas Meyer: > Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger: >> On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote: >>> Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: >> Hmm, does this always happen? > > Yes, my single core system seems to trigger this every time after resume > from ram. What is your host kernel? >> At least on my notebook it did not happen. I've started an UML yesterday >> suspended it and after more than 12h it worked fine today. >> >> BTW: Do you see the issue also then freezing UML using the freezer >> cgroup? > > I'm not sure what do you mean by this. Do I need to enable some special > configs for this in the host or uml kernel? Create on the host side a new freezer cgroup, put UML into it and freeze/thaw it. i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo > /sys/fs/cgroup/freezer/uml/tasks. In the said shell run UML and then freeze it using echo FROZEN > /sys/fs/cgroup/freezer/uml/freezer.state. Later thaw it: echo THAWED > /sys/fs/cgroup/freezer/uml/freezer.state >>> >>> Sadly, this also happens with a cgroup freezer group :-( >>> >>> bt >>> #0 __iter_div_u64_rem (remainder=, divisor=, >>> dividend=14641577537827850536) at include/linux/math64.h:12 >>> 7 >>> #1 timespec_add_ns (ns=, a=) at >>> include/linux/time.h:235 >>> #2 __getnstimeofday64 (ts=0x) at >>> kernel/time/timekeeping.c:658 >>> #3 0x60098a00 in getnstimeofday64 (ts=) at >>> kernel/time/timekeeping.c:678 >>> #4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at >>> kernel/time/timekeeping.c:897 >>> #5 0x60090d66 in SYSC_gettimeofday (tz=, >>> tv=) at kernel/time/time.c:107 >>> #6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102 >>> #7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at >>> arch/um/kernel/skas/syscall.c:35 >>> #8 0x6004a247 in handle_trap (local_using_sysemu=, >>> regs=, pid=) at arch/um/os-Lin >>> ux/skas/process.c:174 >>> #9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399 >>> #10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149 >>> #11 0x in ?? () >>> >>> It seems as only very few people running UML kernels and suspend their host >>> systems... >>> >>> Any ideas? >> >> Can you give the attached patch a try? >> Let's see if it proves my theory. >> Looks like UML's clocksource needs fixing. > > Hi Richard, > > I did run this for an hour and did 4 suspend/resume cycles and it seems > not to hang any more! Yay! BTW: Changing the host's time should also work for testing... > I'll test your other patch the next week, but AFAIU using clock_gettime > should solve this hangs in a sane way. Yep. I have no idea why UML is currently using gettimeofday() as clocksource, this is completely bogus. ;-\ Thanks, //richard -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger: > On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote: > > Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: > >> Am 20.10.2014 um 11:51 schrieb Thomas Meyer: > >> >> Hmm, does this always happen? > >> > > >> > Yes, my single core system seems to trigger this every time after resume > >> > from ram. > >> > >> What is your host kernel? > >> > >> >> At least on my notebook it did not happen. I've started an UML yesterday > >> >> suspended it and after more than 12h it worked fine today. > >> >> > >> >> BTW: Do you see the issue also then freezing UML using the freezer > >> >> cgroup? > >> > > >> > I'm not sure what do you mean by this. Do I need to enable some special > >> > configs for this in the host or uml kernel? > >> > >> Create on the host side a new freezer cgroup, put UML into it and > >> freeze/thaw it. > >> i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo > > >> /sys/fs/cgroup/freezer/uml/tasks. > >> In the said shell run UML and then freeze it using echo FROZEN > > >> /sys/fs/cgroup/freezer/uml/freezer.state. > >> Later thaw it: echo THAWED > /sys/fs/cgroup/freezer/uml/freezer.state > >> > > > > Sadly, this also happens with a cgroup freezer group :-( > > > > bt > > #0 __iter_div_u64_rem (remainder=, divisor=, > > dividend=14641577537827850536) at include/linux/math64.h:12 > > 7 > > #1 timespec_add_ns (ns=, a=) at > > include/linux/time.h:235 > > #2 __getnstimeofday64 (ts=0x) at > > kernel/time/timekeeping.c:658 > > #3 0x60098a00 in getnstimeofday64 (ts=) at > > kernel/time/timekeeping.c:678 > > #4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at > > kernel/time/timekeeping.c:897 > > #5 0x60090d66 in SYSC_gettimeofday (tz=, > > tv=) at kernel/time/time.c:107 > > #6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102 > > #7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at > > arch/um/kernel/skas/syscall.c:35 > > #8 0x6004a247 in handle_trap (local_using_sysemu=, > > regs=, pid=) at arch/um/os-Lin > > ux/skas/process.c:174 > > #9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399 > > #10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149 > > #11 0x in ?? () > > > > It seems as only very few people running UML kernels and suspend their host > > systems... > > > > Any ideas? > > Can you give the attached patch a try? > Let's see if it proves my theory. > Looks like UML's clocksource needs fixing. Hi Richard, I did run this for an hour and did 4 suspend/resume cycles and it seems not to hang any more! I'll test your other patch the next week, but AFAIU using clock_gettime should solve this hangs in a sane way. Thanks for your support. kind regards thomas -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am 26.04.2015 um 20:32 schrieb Richard Weinberger:
> On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote:
>> Any ideas?
>
> Can you give the attached patch a try?
> Let's see if it proves my theory.
> Looks like UML's clocksource needs fixing.
Please give also this patch a try.
I should fix your issue in a sane way.
Thanks,
//richard
diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index d824528..b386cee 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -244,6 +244,7 @@ extern int timer_one_shot(int ticks);
extern long long disable_timer(void);
extern void uml_idle_timer(void);
extern long long os_nsecs(void);
+extern long long os_nsecs_monotonic(void);
/* skas/mem.c */
extern long run_syscall_stub(struct mm_id * mm_idp,
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 117568d..399687c 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -67,7 +67,7 @@ static irqreturn_t um_timer(int irq, void *dev)
static cycle_t itimer_read(struct clocksource *cs)
{
- return os_nsecs() / 1000;
+ return os_nsecs_monotonic() / 1000;
}
static struct clocksource itimer_clocksource = {
diff --git a/arch/um/os-Linux/time.c b/arch/um/os-Linux/time.c
index e9824d5..0ef8faa 100644
--- a/arch/um/os-Linux/time.c
+++ b/arch/um/os-Linux/time.c
@@ -79,6 +79,15 @@ long long os_nsecs(void)
return timeval_to_ns();
}
+long long os_nsecs_monotonic(void)
+{
+ struct timespec tp;
+
+ clock_gettime(CLOCK_MONOTONIC, );
+
+ return ((long long)tp.tv_sec * UM_NSEC_PER_SEC) + tp.tv_nsec;
+}
+
#ifdef UML_CONFIG_NO_HZ_COMMON
static int after_sleep_interval(struct timespec *ts)
{
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote:
> Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
>> Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
>> >> Hmm, does this always happen?
>> >
>> > Yes, my single core system seems to trigger this every time after resume
>> > from ram.
>>
>> What is your host kernel?
>>
>> >> At least on my notebook it did not happen. I've started an UML yesterday
>> >> suspended it and after more than 12h it worked fine today.
>> >>
>> >> BTW: Do you see the issue also then freezing UML using the freezer cgroup?
>> >
>> > I'm not sure what do you mean by this. Do I need to enable some special
>> > configs for this in the host or uml kernel?
>>
>> Create on the host side a new freezer cgroup, put UML into it and
>> freeze/thaw it.
>> i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo >
>> /sys/fs/cgroup/freezer/uml/tasks.
>> In the said shell run UML and then freeze it using echo FROZEN >
>> /sys/fs/cgroup/freezer/uml/freezer.state.
>> Later thaw it: echo THAWED > /sys/fs/cgroup/freezer/uml/freezer.state
>>
>
> Sadly, this also happens with a cgroup freezer group :-(
>
> bt
> #0 __iter_div_u64_rem (remainder=, divisor=,
> dividend=14641577537827850536) at include/linux/math64.h:12
> 7
> #1 timespec_add_ns (ns=, a=) at
> include/linux/time.h:235
> #2 __getnstimeofday64 (ts=0x) at
> kernel/time/timekeeping.c:658
> #3 0x60098a00 in getnstimeofday64 (ts=) at
> kernel/time/timekeeping.c:678
> #4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at
> kernel/time/timekeeping.c:897
> #5 0x60090d66 in SYSC_gettimeofday (tz=,
> tv=) at kernel/time/time.c:107
> #6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102
> #7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at
> arch/um/kernel/skas/syscall.c:35
> #8 0x6004a247 in handle_trap (local_using_sysemu=,
> regs=, pid=) at arch/um/os-Lin
> ux/skas/process.c:174
> #9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399
> #10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149
> #11 0x in ?? ()
>
> It seems as only very few people running UML kernels and suspend their host
> systems...
>
> Any ideas?
Can you give the attached patch a try?
Let's see if it proves my theory.
Looks like UML's clocksource needs fixing.
--
Thanks,
//richard
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 117568d..3936948 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -67,14 +67,14 @@ static irqreturn_t um_timer(int irq, void *dev)
static cycle_t itimer_read(struct clocksource *cs)
{
- return os_nsecs() / 1000;
+ return os_nsecs();
}
static struct clocksource itimer_clocksource = {
.name = "itimer",
.rating = 300,
.read = itimer_read,
- .mask = CLOCKSOURCE_MASK(64),
+ .mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
@@ -92,7 +92,7 @@ static void __init setup_itimer(void)
clockevent_delta2ns(60 * HZ, _clockevent);
itimer_clockevent.min_delta_ns =
clockevent_delta2ns(1, _clockevent);
- err = clocksource_register_hz(_clocksource, USEC_PER_SEC);
+ err = clocksource_register_hz(_clocksource, NSEC_PER_SEC);
if (err) {
printk(KERN_ERR "clocksource_register_hz returned %d\n", err);
return;
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am 26.04.2015 um 20:32 schrieb Richard Weinberger:
On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer tho...@m3y3r.de wrote:
Any ideas?
Can you give the attached patch a try?
Let's see if it proves my theory.
Looks like UML's clocksource needs fixing.
Please give also this patch a try.
I should fix your issue in a sane way.
Thanks,
//richard
diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index d824528..b386cee 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -244,6 +244,7 @@ extern int timer_one_shot(int ticks);
extern long long disable_timer(void);
extern void uml_idle_timer(void);
extern long long os_nsecs(void);
+extern long long os_nsecs_monotonic(void);
/* skas/mem.c */
extern long run_syscall_stub(struct mm_id * mm_idp,
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 117568d..399687c 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -67,7 +67,7 @@ static irqreturn_t um_timer(int irq, void *dev)
static cycle_t itimer_read(struct clocksource *cs)
{
- return os_nsecs() / 1000;
+ return os_nsecs_monotonic() / 1000;
}
static struct clocksource itimer_clocksource = {
diff --git a/arch/um/os-Linux/time.c b/arch/um/os-Linux/time.c
index e9824d5..0ef8faa 100644
--- a/arch/um/os-Linux/time.c
+++ b/arch/um/os-Linux/time.c
@@ -79,6 +79,15 @@ long long os_nsecs(void)
return timeval_to_ns(tv);
}
+long long os_nsecs_monotonic(void)
+{
+ struct timespec tp;
+
+ clock_gettime(CLOCK_MONOTONIC, tp);
+
+ return ((long long)tp.tv_sec * UM_NSEC_PER_SEC) + tp.tv_nsec;
+}
+
#ifdef UML_CONFIG_NO_HZ_COMMON
static int after_sleep_interval(struct timespec *ts)
{
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Hi! Am 26.04.2015 um 22:57 schrieb Thomas Meyer: Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger: On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer tho...@m3y3r.de wrote: Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. What is your host kernel? At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? I'm not sure what do you mean by this. Do I need to enable some special configs for this in the host or uml kernel? Create on the host side a new freezer cgroup, put UML into it and freeze/thaw it. i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo pid of a shell /sys/fs/cgroup/freezer/uml/tasks. In the said shell run UML and then freeze it using echo FROZEN /sys/fs/cgroup/freezer/uml/freezer.state. Later thaw it: echo THAWED /sys/fs/cgroup/freezer/uml/freezer.state Sadly, this also happens with a cgroup freezer group :-( bt #0 __iter_div_u64_rem (remainder=optimized out, divisor=optimized out, dividend=14641577537827850536) at include/linux/math64.h:12 7 #1 timespec_add_ns (ns=optimized out, a=optimized out) at include/linux/time.h:235 #2 __getnstimeofday64 (ts=0x) at kernel/time/timekeeping.c:658 #3 0x60098a00 in getnstimeofday64 (ts=optimized out) at kernel/time/timekeeping.c:678 #4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at kernel/time/timekeeping.c:897 #5 0x60090d66 in SYSC_gettimeofday (tz=optimized out, tv=optimized out) at kernel/time/time.c:107 #6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102 #7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at arch/um/kernel/skas/syscall.c:35 #8 0x6004a247 in handle_trap (local_using_sysemu=optimized out, regs=optimized out, pid=optimized out) at arch/um/os-Lin ux/skas/process.c:174 #9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399 #10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149 #11 0x in ?? () It seems as only very few people running UML kernels and suspend their host systems... Any ideas? Can you give the attached patch a try? Let's see if it proves my theory. Looks like UML's clocksource needs fixing. Hi Richard, I did run this for an hour and did 4 suspend/resume cycles and it seems not to hang any more! Yay! BTW: Changing the host's time should also work for testing... I'll test your other patch the next week, but AFAIU using clock_gettime should solve this hangs in a sane way. Yep. I have no idea why UML is currently using gettimeofday() as clocksource, this is completely bogus. ;-\ Thanks, //richard -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger: On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer tho...@m3y3r.de wrote: Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. What is your host kernel? At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? I'm not sure what do you mean by this. Do I need to enable some special configs for this in the host or uml kernel? Create on the host side a new freezer cgroup, put UML into it and freeze/thaw it. i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo pid of a shell /sys/fs/cgroup/freezer/uml/tasks. In the said shell run UML and then freeze it using echo FROZEN /sys/fs/cgroup/freezer/uml/freezer.state. Later thaw it: echo THAWED /sys/fs/cgroup/freezer/uml/freezer.state Sadly, this also happens with a cgroup freezer group :-( bt #0 __iter_div_u64_rem (remainder=optimized out, divisor=optimized out, dividend=14641577537827850536) at include/linux/math64.h:12 7 #1 timespec_add_ns (ns=optimized out, a=optimized out) at include/linux/time.h:235 #2 __getnstimeofday64 (ts=0x) at kernel/time/timekeeping.c:658 #3 0x60098a00 in getnstimeofday64 (ts=optimized out) at kernel/time/timekeeping.c:678 #4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at kernel/time/timekeeping.c:897 #5 0x60090d66 in SYSC_gettimeofday (tz=optimized out, tv=optimized out) at kernel/time/time.c:107 #6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102 #7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at arch/um/kernel/skas/syscall.c:35 #8 0x6004a247 in handle_trap (local_using_sysemu=optimized out, regs=optimized out, pid=optimized out) at arch/um/os-Lin ux/skas/process.c:174 #9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399 #10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149 #11 0x in ?? () It seems as only very few people running UML kernels and suspend their host systems... Any ideas? Can you give the attached patch a try? Let's see if it proves my theory. Looks like UML's clocksource needs fixing. Hi Richard, I did run this for an hour and did 4 suspend/resume cycles and it seems not to hang any more! I'll test your other patch the next week, but AFAIU using clock_gettime should solve this hangs in a sane way. Thanks for your support. kind regards thomas -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer tho...@m3y3r.de wrote:
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
Hmm, does this always happen?
Yes, my single core system seems to trigger this every time after resume
from ram.
What is your host kernel?
At least on my notebook it did not happen. I've started an UML yesterday
suspended it and after more than 12h it worked fine today.
BTW: Do you see the issue also then freezing UML using the freezer cgroup?
I'm not sure what do you mean by this. Do I need to enable some special
configs for this in the host or uml kernel?
Create on the host side a new freezer cgroup, put UML into it and
freeze/thaw it.
i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo pid of a shell
/sys/fs/cgroup/freezer/uml/tasks.
In the said shell run UML and then freeze it using echo FROZEN
/sys/fs/cgroup/freezer/uml/freezer.state.
Later thaw it: echo THAWED /sys/fs/cgroup/freezer/uml/freezer.state
Sadly, this also happens with a cgroup freezer group :-(
bt
#0 __iter_div_u64_rem (remainder=optimized out, divisor=optimized out,
dividend=14641577537827850536) at include/linux/math64.h:12
7
#1 timespec_add_ns (ns=optimized out, a=optimized out) at
include/linux/time.h:235
#2 __getnstimeofday64 (ts=0x) at
kernel/time/timekeeping.c:658
#3 0x60098a00 in getnstimeofday64 (ts=optimized out) at
kernel/time/timekeeping.c:678
#4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at
kernel/time/timekeeping.c:897
#5 0x60090d66 in SYSC_gettimeofday (tz=optimized out,
tv=optimized out) at kernel/time/time.c:107
#6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102
#7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at
arch/um/kernel/skas/syscall.c:35
#8 0x6004a247 in handle_trap (local_using_sysemu=optimized out,
regs=optimized out, pid=optimized out) at arch/um/os-Lin
ux/skas/process.c:174
#9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399
#10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149
#11 0x in ?? ()
It seems as only very few people running UML kernels and suspend their host
systems...
Any ideas?
Can you give the attached patch a try?
Let's see if it proves my theory.
Looks like UML's clocksource needs fixing.
--
Thanks,
//richard
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 117568d..3936948 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -67,14 +67,14 @@ static irqreturn_t um_timer(int irq, void *dev)
static cycle_t itimer_read(struct clocksource *cs)
{
- return os_nsecs() / 1000;
+ return os_nsecs();
}
static struct clocksource itimer_clocksource = {
.name = itimer,
.rating = 300,
.read = itimer_read,
- .mask = CLOCKSOURCE_MASK(64),
+ .mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
@@ -92,7 +92,7 @@ static void __init setup_itimer(void)
clockevent_delta2ns(60 * HZ, itimer_clockevent);
itimer_clockevent.min_delta_ns =
clockevent_delta2ns(1, itimer_clockevent);
- err = clocksource_register_hz(itimer_clocksource, USEC_PER_SEC);
+ err = clocksource_register_hz(itimer_clocksource, NSEC_PER_SEC);
if (err) {
printk(KERN_ERR clocksource_register_hz returned %d\n, err);
return;
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
> Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
> >> Hmm, does this always happen?
> >
> > Yes, my single core system seems to trigger this every time after resume
> > from ram.
>
> What is your host kernel?
>
> >> At least on my notebook it did not happen. I've started an UML yesterday
> >> suspended it and after more than 12h it worked fine today.
> >>
> >> BTW: Do you see the issue also then freezing UML using the freezer cgroup?
> >
> > I'm not sure what do you mean by this. Do I need to enable some special
> > configs for this in the host or uml kernel?
>
> Create on the host side a new freezer cgroup, put UML into it and freeze/thaw
> it.
> i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo >
> /sys/fs/cgroup/freezer/uml/tasks.
> In the said shell run UML and then freeze it using echo FROZEN >
> /sys/fs/cgroup/freezer/uml/freezer.state.
> Later thaw it: echo THAWED > /sys/fs/cgroup/freezer/uml/freezer.state
>
Sadly, this also happens with a cgroup freezer group :-(
bt
#0 __iter_div_u64_rem (remainder=, divisor=,
dividend=14641577537827850536) at include/linux/math64.h:12
7
#1 timespec_add_ns (ns=, a=) at
include/linux/time.h:235
#2 __getnstimeofday64 (ts=0x) at kernel/time/timekeeping.c:658
#3 0x60098a00 in getnstimeofday64 (ts=) at
kernel/time/timekeeping.c:678
#4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at
kernel/time/timekeeping.c:897
#5 0x60090d66 in SYSC_gettimeofday (tz=, tv=) at kernel/time/time.c:107
#6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102
#7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at
arch/um/kernel/skas/syscall.c:35
#8 0x6004a247 in handle_trap (local_using_sysemu=,
regs=, pid=) at arch/um/os-Lin
ux/skas/process.c:174
#9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399
#10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149
#11 0x in ?? ()
It seems as only very few people running UML kernels and suspend their host
systems...
Any ideas?
I'll go with this patch so long:
diff --git a/include/linux/time.h b/include/linux/time.h
index beebe3a..3486050 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -232,7 +232,7 @@ extern struct timeval ns_to_timeval(const s64 nsec);
*/
static __always_inline void timespec_add_ns(struct timespec *a, u64 ns)
{
- a->tv_sec += __iter_div_u64_rem(a->tv_nsec + ns, NSEC_PER_SEC, );
+ a->tv_sec += div_u64_rem(a->tv_nsec + ns, NSEC_PER_SEC, );
a->tv_nsec = ns;
}
kind regards
thomas
--
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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
Hmm, does this always happen?
Yes, my single core system seems to trigger this every time after resume
from ram.
What is your host kernel?
At least on my notebook it did not happen. I've started an UML yesterday
suspended it and after more than 12h it worked fine today.
BTW: Do you see the issue also then freezing UML using the freezer cgroup?
I'm not sure what do you mean by this. Do I need to enable some special
configs for this in the host or uml kernel?
Create on the host side a new freezer cgroup, put UML into it and freeze/thaw
it.
i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo pid of a shell
/sys/fs/cgroup/freezer/uml/tasks.
In the said shell run UML and then freeze it using echo FROZEN
/sys/fs/cgroup/freezer/uml/freezer.state.
Later thaw it: echo THAWED /sys/fs/cgroup/freezer/uml/freezer.state
Sadly, this also happens with a cgroup freezer group :-(
bt
#0 __iter_div_u64_rem (remainder=optimized out, divisor=optimized out,
dividend=14641577537827850536) at include/linux/math64.h:12
7
#1 timespec_add_ns (ns=optimized out, a=optimized out) at
include/linux/time.h:235
#2 __getnstimeofday64 (ts=0x) at kernel/time/timekeeping.c:658
#3 0x60098a00 in getnstimeofday64 (ts=optimized out) at
kernel/time/timekeeping.c:678
#4 0x60098a4c in do_gettimeofday (tv=0xab359e50) at
kernel/time/timekeeping.c:897
#5 0x60090d66 in SYSC_gettimeofday (tz=optimized out, tv=optimized
out) at kernel/time/time.c:107
#6 SyS_gettimeofday (tv=-1, tz=2097152000) at kernel/time/time.c:102
#7 0x60032cf3 in handle_syscall (r=0xa39db9e8) at
arch/um/kernel/skas/syscall.c:35
#8 0x6004a247 in handle_trap (local_using_sysemu=optimized out,
regs=optimized out, pid=optimized out) at arch/um/os-Lin
ux/skas/process.c:174
#9 userspace (regs=0xa39db9e8) at arch/um/os-Linux/skas/process.c:399
#10 0x6002f125 in fork_handler () at arch/um/kernel/process.c:149
#11 0x in ?? ()
It seems as only very few people running UML kernels and suspend their host
systems...
Any ideas?
I'll go with this patch so long:
diff --git a/include/linux/time.h b/include/linux/time.h
index beebe3a..3486050 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -232,7 +232,7 @@ extern struct timeval ns_to_timeval(const s64 nsec);
*/
static __always_inline void timespec_add_ns(struct timespec *a, u64 ns)
{
- a-tv_sec += __iter_div_u64_rem(a-tv_nsec + ns, NSEC_PER_SEC, ns);
+ a-tv_sec += div_u64_rem(a-tv_nsec + ns, NSEC_PER_SEC, ns);
a-tv_nsec = ns;
}
kind regards
thomas
--
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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: > Am 20.10.2014 um 11:51 schrieb Thomas Meyer: > >> Hmm, does this always happen? > > > > Yes, my single core system seems to trigger this every time after resume > > from ram. > > What is your host kernel? The standard Fedora kernel: 3.16.4-200.fc20.x86_64 > > >> At least on my notebook it did not happen. I've started an UML yesterday > >> suspended it and after more than 12h it worked fine today. > >> > >> BTW: Do you see the issue also then freezing UML using the freezer cgroup? > > > > I'm not sure what do you mean by this. Do I need to enable some special > > configs for this in the host or uml kernel? > > Create on the host side a new freezer cgroup, put UML into it and freeze/thaw > it. > i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo > > /sys/fs/cgroup/freezer/uml/tasks. > In the said shell run UML and then freeze it using echo FROZEN > > /sys/fs/cgroup/freezer/uml/freezer.state. > Later thaw it: echo THAWED > /sys/fs/cgroup/freezer/uml/freezer.state > I'll try this. Thanks for this tip. with kind regards thomas -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am 20.10.2014 um 11:51 schrieb Thomas Meyer: >> Hmm, does this always happen? > > Yes, my single core system seems to trigger this every time after resume from > ram. What is your host kernel? >> At least on my notebook it did not happen. I've started an UML yesterday >> suspended it and after more than 12h it worked fine today. >> >> BTW: Do you see the issue also then freezing UML using the freezer cgroup? > > I'm not sure what do you mean by this. Do I need to enable some special > configs for this in the host or uml kernel? Create on the host side a new freezer cgroup, put UML into it and freeze/thaw it. i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo > /sys/fs/cgroup/freezer/uml/tasks. In the said shell run UML and then freeze it using echo FROZEN > /sys/fs/cgroup/freezer/uml/freezer.state. Later thaw it: echo THAWED > /sys/fs/cgroup/freezer/uml/freezer.state Thanks, //richard -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am 20.10.2014 10:27 schrieb Richard Weinberger : > > On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer wrote: > > Hello, > > > > in UML kernel I get a long cpu using loop in __getnstimeofday() > > (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), > > when I left the host kernel suspended to ram for a few hours and resume > > again. > > this is because it seems like the tk->xtime_sec wasn't updated yet, but > > the nsecs were. nsecs can be as high as 8111000111000111000l > > > > the function timespec_add_ns() (include/linux/time.h:266) will call > > __iter_div_u64_rem() which has an optimized loop for the case > > that the dividend is not much bigger as the divisior. > > but this isn't the case for resume from ram on the host kernel. > > > > any ideas how to fix this? is it possible to intercept the resume from > > ram and update the timekeeper->xtime_sec somehow? > > or can the um arch somehow overwrite timespec_add_ns() to always use > > div_u64_rem() instead? > > Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. > At least on my notebook it did not happen. I've started an UML yesterday > suspended it and after more than 12h it worked fine today. > > BTW: Do you see the issue also then freezing UML using the freezer cgroup? I'm not sure what do you mean by this. Do I need to enable some special configs for this in the host or uml kernel? > Would be easier to debug. :) > > -- > Thanks, > //richard
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer wrote: > Hello, > > in UML kernel I get a long cpu using loop in __getnstimeofday() > (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), > when I left the host kernel suspended to ram for a few hours and resume > again. > this is because it seems like the tk->xtime_sec wasn't updated yet, but > the nsecs were. nsecs can be as high as 8111000111000111000l > > the function timespec_add_ns() (include/linux/time.h:266) will call > __iter_div_u64_rem() which has an optimized loop for the case > that the dividend is not much bigger as the divisior. > but this isn't the case for resume from ram on the host kernel. > > any ideas how to fix this? is it possible to intercept the resume from > ram and update the timekeeper->xtime_sec somehow? > or can the um arch somehow overwrite timespec_add_ns() to always use > div_u64_rem() instead? Hmm, does this always happen? At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? Would be easier to debug. :) -- Thanks, //richard -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer tho...@m3y3r.de wrote: Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk-xtime_sec wasn't updated yet, but the nsecs were. nsecs can be as high as 8111000111000111000l the function timespec_add_ns() (include/linux/time.h:266) will call __iter_div_u64_rem() which has an optimized loop for the case that the dividend is not much bigger as the divisior. but this isn't the case for resume from ram on the host kernel. any ideas how to fix this? is it possible to intercept the resume from ram and update the timekeeper-xtime_sec somehow? or can the um arch somehow overwrite timespec_add_ns() to always use div_u64_rem() instead? Hmm, does this always happen? At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? Would be easier to debug. :) -- Thanks, //richard -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am 20.10.2014 10:27 schrieb Richard Weinberger richard.weinber...@gmail.com: On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer tho...@m3y3r.de wrote: Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk-xtime_sec wasn't updated yet, but the nsecs were. nsecs can be as high as 8111000111000111000l the function timespec_add_ns() (include/linux/time.h:266) will call __iter_div_u64_rem() which has an optimized loop for the case that the dividend is not much bigger as the divisior. but this isn't the case for resume from ram on the host kernel. any ideas how to fix this? is it possible to intercept the resume from ram and update the timekeeper-xtime_sec somehow? or can the um arch somehow overwrite timespec_add_ns() to always use div_u64_rem() instead? Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? I'm not sure what do you mean by this. Do I need to enable some special configs for this in the host or uml kernel? Would be easier to debug. :) -- Thanks, //richard
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. What is your host kernel? At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? I'm not sure what do you mean by this. Do I need to enable some special configs for this in the host or uml kernel? Create on the host side a new freezer cgroup, put UML into it and freeze/thaw it. i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo pid of a shell /sys/fs/cgroup/freezer/uml/tasks. In the said shell run UML and then freeze it using echo FROZEN /sys/fs/cgroup/freezer/uml/freezer.state. Later thaw it: echo THAWED /sys/fs/cgroup/freezer/uml/freezer.state Thanks, //richard -- 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/
Re: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger: Am 20.10.2014 um 11:51 schrieb Thomas Meyer: Hmm, does this always happen? Yes, my single core system seems to trigger this every time after resume from ram. What is your host kernel? The standard Fedora kernel: 3.16.4-200.fc20.x86_64 At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? I'm not sure what do you mean by this. Do I need to enable some special configs for this in the host or uml kernel? Create on the host side a new freezer cgroup, put UML into it and freeze/thaw it. i.e. mkdir /sys/fs/cgroup/freezer/uml ; echo pid of a shell /sys/fs/cgroup/freezer/uml/tasks. In the said shell run UML and then freeze it using echo FROZEN /sys/fs/cgroup/freezer/uml/freezer.state. Later thaw it: echo THAWED /sys/fs/cgroup/freezer/uml/freezer.state I'll try this. Thanks for this tip. with kind regards thomas -- 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/
[UM] Long loop in __getnsdayoftime() after resume from ram
Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk->xtime_sec wasn't updated yet, but the nsecs were. nsecs can be as high as 8111000111000111000l the function timespec_add_ns() (include/linux/time.h:266) will call __iter_div_u64_rem() which has an optimized loop for the case that the dividend is not much bigger as the divisior. but this isn't the case for resume from ram on the host kernel. any ideas how to fix this? is it possible to intercept the resume from ram and update the timekeeper->xtime_sec somehow? or can the um arch somehow overwrite timespec_add_ns() to always use div_u64_rem() instead? with kind regards PS: repost on these lists, because nobody did respond to my original email. -- 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/
[UM] Long loop in __getnsdayoftime() after resume from ram
Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk-xtime_sec wasn't updated yet, but the nsecs were. nsecs can be as high as 8111000111000111000l the function timespec_add_ns() (include/linux/time.h:266) will call __iter_div_u64_rem() which has an optimized loop for the case that the dividend is not much bigger as the divisior. but this isn't the case for resume from ram on the host kernel. any ideas how to fix this? is it possible to intercept the resume from ram and update the timekeeper-xtime_sec somehow? or can the um arch somehow overwrite timespec_add_ns() to always use div_u64_rem() instead? with kind regards PS: repost on these lists, because nobody did respond to my original email. -- 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/
