search for: jiffies

...0530 +++ linux-2.6.7/net/bridge/br_stp.c 2004-06-22 19:32:49.015908632 +0530 @@ -161,20 +161,19 @@ void br_transmit_config(struct net_bridg if (!br_is_root_bridge(br)) { struct net_bridge_port *root = br_get_port(br, br->root_port); - bpdu.max_age = root->message_age_timer.expires - jiffies; - - if (bpdu.max_age <= 0) bpdu.max_age = 1; + bpdu.message_age = br->max_age - + (root->message_age_timer.expires - jiffies) + 1; } bpdu.max_age = br->max_age; bpdu.hello_time = br->hello_time; bpdu.forward_delay = br->forward_delay; - br_send_config_bpdu(p, &...

Hi there, I''m trying to find out if theres anything wrong with using extra = "clocksource=jiffies" in domU configuration. It seems to fix some problems we''ve had with live migration. Thanks. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard ca...

[ Ingo, Thomas cc'd in case this issue effects normal jiffies clock too? ] When the Host TSC is unreliable or can change, lguest guests use the jiffies clock. However, the clock value seems to creep upwards in sub-jiffies increments, and then tick_handle_periodic() goes into an infinite loop. Instead, the host writes the current time into the lguest page o...

[ Ingo, Thomas cc'd in case this issue effects normal jiffies clock too? ] When the Host TSC is unreliable or can change, lguest guests use the jiffies clock. However, the clock value seems to creep upwards in sub-jiffies increments, and then tick_handle_periodic() goes into an infinite loop. Instead, the host writes the current time into the lguest page o...

...ving the > recursion limit and retry the same servers several times as the UDP > packets may get lost. And coding style improvement. As you noted, you don't accommodate timeouts which is probably the most critical operation this doesn't have. We can't stay in the query forever. jiffies() and ms_timer() are the two available in the core. core/legacynet/dnsresolv.c used jiffies() but ms_timer() should be dealing with millisecond values, not 55ms jiffies and about CLK_TCK jiffies per second. An alternative way to just stub it is to merge everything but the actual call that starts s...

...s network interface hung issue recently, and have > >> been working on the issue from that time. I find that DomU''s network > >> interface, which send lesser package, will hung if Dom0 running > >> 32bit and DomU''s up-time is very long. I think that one jiffies > >> overflow bug exist in the function tx_credit_exceeded(). > >> I know the inline function time_after_eq(a,b) will process jiffies > >> overflow, but the function have one limit a should little that (b + > >> MAX_SIGNAL_LONG). If a large than the value, tim...

...nts this in console once every second, [55082.616234] __ratelimit: 1503 messages suppressed [55082.616234] clocksource/0: Time went backwards: ret=380ab26c53a I resolved this by following the instructions in "http://wiki.debian.org/Xen", which is basically changing clocksource to "jiffies". Now the problem has gone away, I''m wondering if somebody can help me: 1. Is domain-0 not able to set the system time of domain-u the root cause? I can see this error in console "Unable to set System Clock to: <a datetime value>", even after I changed clocks...

When booting 2.6.37 (from kernel.org) under Xen 4.1, there are apparently issues with timer interrupts being delivered to the dom0. Repeatedly causing an interrupt (for example, the ACPI power button) will allow the system to boot, as does adding "clocksource=jiffies" to the kernel command line. This is only present under Xen, not when booting the same kernel on real hardware. When boot with clocksource=jiffies, the system will sometimes freeze for about 30 seconds and then continue; however, this could be related to kernel debugging that I have enabled....

...;>> +++ b/drivers/vhost/net.c >>> @@ -473,6 +473,7 @@ static void handle_tx(struct vhost_net *net) >>> struct socket *sock; >>> struct vhost_net_ubuf_ref *uninitialized_var(ubufs); >>> bool zcopy, zcopy_used; >>> + unsigned long start = jiffies; >> Checking jiffies is tricky, need to convert it to ms or whatever others. >> >>> >>> mutex_lock(&vq->mutex); >>> sock = vq->private_data; >>> @@ -580,7 +581,7 @@ static void handle_tx(struct vhost_net *net) >>> e...

...;>> +++ b/drivers/vhost/net.c >>> @@ -473,6 +473,7 @@ static void handle_tx(struct vhost_net *net) >>> struct socket *sock; >>> struct vhost_net_ubuf_ref *uninitialized_var(ubufs); >>> bool zcopy, zcopy_used; >>> + unsigned long start = jiffies; >> Checking jiffies is tricky, need to convert it to ms or whatever others. >> >>> >>> mutex_lock(&vq->mutex); >>> sock = vq->private_data; >>> @@ -580,7 +581,7 @@ static void handle_tx(struct vhost_net *net) >>> e...

...g uses sched_clock() to measure time, it would automatically ignore stolen time, and therefore only report when the guest itself locked up. When running native, sched_clock() returns real-time nanoseconds, so the behaviour would be unchanged. Does this seem sound? Also, softlockup.c's use of jiffies seems archaic now. Should it be converted to use timers? Mightn't it report lockups just because there was no timer event? Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> diff -r b41fb9e70d72 kernel/softlockup.c --- a/kernel/softlockup.c Thu Mar 22 16:25:15 2007 -0700 +++ b/...

...g uses sched_clock() to measure time, it would automatically ignore stolen time, and therefore only report when the guest itself locked up. When running native, sched_clock() returns real-time nanoseconds, so the behaviour would be unchanged. Does this seem sound? Also, softlockup.c's use of jiffies seems archaic now. Should it be converted to use timers? Mightn't it report lockups just because there was no timer event? Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> diff -r b41fb9e70d72 kernel/softlockup.c --- a/kernel/softlockup.c Thu Mar 22 16:25:15 2007 -0700 +++ b/...

...iv; - - if (chan->inuse) - p9_virtio_close(chan->client); - vdev->config->del_vqs(vdev); + unsigned long warning_time; + bool inuse; mutex_lock(&virtio_9p_lock); + + /* Remove self from list so we don't get new users. */ list_del(&chan->chan_list); + warning_time = jiffies; + + /* Wait for existing users to close. */ + while (chan->inuse) { + mutex_unlock(&virtio_9p_lock); + msleep(250); + if (time_after(jiffies, warning_time + 10 * HZ)) { + dev_emerg(&vdev->dev, "p9_virtio_remove: " + "waiting for device in use.\n&...

...iv; - - if (chan->inuse) - p9_virtio_close(chan->client); - vdev->config->del_vqs(vdev); + unsigned long warning_time; + bool inuse; mutex_lock(&virtio_9p_lock); + + /* Remove self from list so we don't get new users. */ list_del(&chan->chan_list); + warning_time = jiffies; + + /* Wait for existing users to close. */ + while (chan->inuse) { + mutex_unlock(&virtio_9p_lock); + msleep(250); + if (time_after(jiffies, warning_time + 10 * HZ)) { + dev_emerg(&vdev->dev, "p9_virtio_remove: " + "waiting for device in use.\n&...

Hi, I''m using Xen 3.2.1 with 2.6.26 as Dom0 and DomU in the x86_64 Versions/Builds as provided by Debian Lenny. I noticed that when using "jiffies" as clocksource, the resolution of the timers in a DomU is 4ms, e.g. ping shows only runtimes in 4ms increments [1]. When using "xen" the resolution is fine (didn''t make exact measurements) but xen is a no-go when migrating guests between Dom0s. Is the 4ms resolution beh...

...27 14:01:28 2007 -0800 +++ b/arch/i386/kernel/vmitime.c Tue Feb 27 14:12:01 2007 -0800 @@ -276,15 +276,12 @@ static void vmi_account_real_cycles(unsi cycles_not_accounted = cur_real_cycles - real_cycles_accounted_system; while (cycles_not_accounted >= cycles_per_jiffy) { - /* systems wide jiffies and wallclock. */ + /* systems wide jiffies. */ do_timer(1); cycles_not_accounted -= cycles_per_jiffy; real_cycles_accounted_system += cycles_per_jiffy; } - - if (vmi_timer_ops.wallclock_updated()) - update_xtime_from_wallclock(); write_sequnlock(&xtime_lock); } @@ -380,7 +3...

...27 14:01:28 2007 -0800 +++ b/arch/i386/kernel/vmitime.c Tue Feb 27 14:12:01 2007 -0800 @@ -276,15 +276,12 @@ static void vmi_account_real_cycles(unsi cycles_not_accounted = cur_real_cycles - real_cycles_accounted_system; while (cycles_not_accounted >= cycles_per_jiffy) { - /* systems wide jiffies and wallclock. */ + /* systems wide jiffies. */ do_timer(1); cycles_not_accounted -= cycles_per_jiffy; real_cycles_accounted_system += cycles_per_jiffy; } - - if (vmi_timer_ops.wallclock_updated()) - update_xtime_from_wallclock(); write_sequnlock(&xtime_lock); } @@ -380,7 +3...

...ink current issue with "Kernel panic - not syncing: IO-APIC + timer doesn't work!" is also clear. timer_irq_works(void) never returns 1: https://github.com/torvalds/linux/blob/d966564fcdc19e13eb6ba1fbe6b8101070339c3d/arch/x86/kernel/apic/io_apic.c#L1641 I think it happens because of jiffies (http://www.makelinux.net/books/lkd2/ch10lev1sec3#ch10fig01) It should have the same address as jiffies_64: https://github.com/torvalds/linux/blob/b66484cd74706fa8681d051840fe4b18a3da40ff/arch/x86/kernel/vmlinux.lds.S#L41 And that is true for BFD linked binary: 10595: ffffffff8140b000 8 OBJE...

...imer_pending(&br->ip4_multicast_querier_timer)) return; memset(&br_group.u, 0, sizeof(br_group.u)); @@ -804,20 +823,41 @@ static void br_multicast_send_query(struct net_bridge *br, br_group.proto = htons(ETH_P_IP); __br_multicast_send_query(br, port, &br_group); + time = jiffies; + time += sent < br->multicast_startup_query_count ? + br->multicast_startup_query_interval : + br->multicast_query_interval; + mod_timer(port ? &port->ip4_multicast_query_timer : + &br->ip4_multicast_query_timer, time); +} + #if IS_ENABLED(CONFIG_IPV6) +static void...

...tible() instead of just schedule(), and in that case, need_resched() would be false too. You could argue that's intended behaviour, but I can't see how it happens in the normal case anyway. What am I missing? Thanks, Rusty. > This patch removed need_resched() and increase delay to 10 jiffies, > then other tasks can have chance to execute protected code. > Delaying 1 jiffy also works, but 10 jiffies is safer. > > Signed-off-by: Amos Kong <akong at redhat.com> > --- > drivers/char/hw_random/core.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) >...