search for: jiffy

Fixes message_age field update in config BPDUs. Also checks whether the BPDU message age has exceeded bridge max age before transmitting config BPDUs. Signed-off-by: Kishore A K <KishoreAK@myw.ltindia.com> Index: linux-2.6.7/net/bridge/br_stp.c ============================================================= --- linux-2.6.7/net/bridge/br_stp.c.orig 2004-06-17 20:17:27.000000000 +0530 +++

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.

[ 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 on every interrupt. This

[ 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 on every interrupt. This

On Fri, Sep 25, 2015 at 6:40 PM, Celelibi via Syslinux <syslinux at zytor.com> wrote: > 2015-09-25 21:27 UTC+02:00, Geert Stappers via Syslinux <syslinux at zytor.com>: >> On Tue, Sep 15, 2015 at 05:22:40AM -0400, Gene Cumm via Syslinux wrote: >>> On Sep 10, 2015 1:32 AM, "celelibi--- via Syslinux" <syslinux at zytor.com> >>> wrote:

On Tue, 2013-10-15 at 10:44 +0800, jianhai luan wrote: > On 2013-10-14 19:19, Wei Liu wrote: > > On Sat, Oct 12, 2013 at 04:53:18PM +0800, jianhai luan wrote: > >> Hi Ian, > >> I meet the DomU''s network interface hung issue recently, and have > >> been working on the issue from that time. I find that DomU''s network > >> interface,

Hi All, I''m new to Xen and... Happy New Year! After restarting dom-0, my dom-u prints 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

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

On 2018?03?28? 12:01, haibinzhang(???) wrote: > On 2018?03?27? 19:26, Jason wrote > On 2018?03?27? 17:12, haibinzhang wrote: >>> handle_tx() will delay rx for a long time when busy tx polling udp packets >>> with short length(ie: 1byte udp payload), because setting VHOST_NET_WEIGHT >>> takes into account only sent-bytes but no time. >> Interesting. >>

On 2018?03?28? 12:01, haibinzhang(???) wrote: > On 2018?03?27? 19:26, Jason wrote > On 2018?03?27? 17:12, haibinzhang wrote: >>> handle_tx() will delay rx for a long time when busy tx polling udp packets >>> with short length(ie: 1byte udp payload), because setting VHOST_NET_WEIGHT >>> takes into account only sent-bytes but no time. >> Interesting. >>

The softlockup watchdog is currently a nuisance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which

The softlockup watchdog is currently a nuisance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which

On device hot-unplug, 9p/virtio currently will kfree channel while it might still be in use. Of course, it might stay used forever, so it's an extremely ugly hack, but it seems better than use-after-free that we have now. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- net/9p/trans_virtio.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)

On device hot-unplug, 9p/virtio currently will kfree channel while it might still be in use. Of course, it might stay used forever, so it's an extremely ugly hack, but it seems better than use-after-free that we have now. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- net/9p/trans_virtio.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)

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

...86/kernel/vmitime.c Tue Feb 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(&am...

...86/kernel/vmitime.c Tue Feb 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(&am...

And I think 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

Currently we would still potentially suffer multicast packet loss if there is just either an IGMP or an MLD querier: For the former case, we would possibly drop IPv6 multicast packets, for the latter IPv4 ones. This is because we are currently assuming that if either an IGMP or MLD querier is present that the other one is present, too. This patch makes the behaviour and fix added in "bridge:

...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(-) > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > ind...