search for: softlockup_tick

...past so I was hoping someone with better insight might just have an elegant solution up his sleeve. Best regards, Ranko PS: If this list is not the right place for this report - please let me know. -----------CONSOLE (2.6.19.7)----------- BUG: soft lockup detected on CPU#3! [<c013c890>] softlockup_tick+0x93/0xc2 [<c0127585>] update_process_times+0x26/0x5c [<c0111cd5>] smp_apic_timer_interrupt+0x97/0xb2 [<c0104373>] apic_timer_interrupt+0x1f/0x24 [<c02e007b>] klist_next+0x4/0x8a [<c02e2570>] _spin_unlock_irqrestore+0xa/0xc [<c012729b>] try_to_del_timer_syn...

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the

...tic int did_panic = 0; @@ -37,7 +39,7 @@ static struct notifier_block panic_block void touch_softlockup_watchdog(void) { - __raw_get_cpu_var(touch_timestamp) = jiffies; + __raw_get_cpu_var(touch_timestamp) = sched_clock(); } EXPORT_SYMBOL(touch_softlockup_watchdog); @@ -49,6 +51,7 @@ void softlockup_tick(void) { int this_cpu = smp_processor_id(); unsigned long touch_timestamp = per_cpu(touch_timestamp, this_cpu); + unsigned long long now; /* prevent double reports: */ if (per_cpu(print_timestamp, this_cpu) == touch_timestamp || @@ -62,12 +65,14 @@ void softlockup_tick(void) return;...

...tic int did_panic = 0; @@ -37,7 +39,7 @@ static struct notifier_block panic_block void touch_softlockup_watchdog(void) { - __raw_get_cpu_var(touch_timestamp) = jiffies; + __raw_get_cpu_var(touch_timestamp) = sched_clock(); } EXPORT_SYMBOL(touch_softlockup_watchdog); @@ -49,6 +51,7 @@ void softlockup_tick(void) { int this_cpu = smp_processor_id(); unsigned long touch_timestamp = per_cpu(touch_timestamp, this_cpu); + unsigned long long now; /* prevent double reports: */ if (per_cpu(print_timestamp, this_cpu) == touch_timestamp || @@ -62,12 +65,14 @@ void softlockup_tick(void) return;...

Hi Ingo, This series of patches implements a number of improvements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time,

Hi Ingo, This series of patches implements a number of improvements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time,

Stamp softlockup thread earlier before do_timer, because the latter is the one to actually trigger lock warning for long-time offline. Or else, I obserevd softlockup warning easily at manual vcpu hot-remove/plug, or when suspend cancel into old context. One point here is to cover both stolen and blocked time to compare with offline threshold. vcpu hotplug falls into ''stolen''

...enter startup! TE2XXP: Span 1 configured for CCS/HDB3/CRC4 timing source auto card 0! wct2xxp: Setting yellow alarm on span 1 timing source auto card 0! SPAN 1: Primary Sync Source VPM400: Not Present VPM450: echo cancellation for 64 channels BUG: soft lockup detected on CPU#0! [<c044d448>] softlockup_tick+0x96/0xa4 [<c042ddc8>] update_process_times+0x39/0x5c [<c04196f7>] smp_apic_timer_interrupt+0x5b/0x6c [<c04059bf>] apic_timer_interrupt+0x1f/0x24 [<f89bc1e7>] init_vpm450m+0x32d/0x34a [wct4xxp] [<f89a3b11>] t4_vpm450_init+0x18ce/0x198c [wct4xxp] [<f89a7ee4>...

....el5 kernel-xen-2.6.18-8.1.14.el5 The Domain0 zone is indeed rock stable, while the Web1 etc. are crashing daily with the 2.6.18-8.1.14 Xen kernel and the stack trace we see after a few hours is as follows: BUG: soft lockup detected on CPU#5! Call Trace: <IRQ> [<ffffffff802a76ad>] softlockup_tick+0xdb/0xed [<ffffffff8026ba66>] timer_interrupt+0x396/0x3f2 [<ffffffff80210a87>] handle_IRQ_event+0x2d/0x60 [<ffffffff802a79ec>] __do_IRQ+0xa4/0x105 [<ffffffff802699b3>] do_IRQ+0xe7/0xf5 [<ffffffff8038dde8>] evtchn_do_upcall+0x86/0xe0 [<ffffffff8025cc1a>] do...

....el5 kernel-xen-2.6.18-8.1.14.el5 The Domain0 zone is indeed rock stable, while the Web1 etc. are crashing daily with the 2.6.18-8.1.14 Xen kernel and the stack trace we see after a few hours is as follows: BUG: soft lockup detected on CPU#5! Call Trace: <IRQ> [<ffffffff802a76ad>] softlockup_tick+0xdb/0xed [<ffffffff8026ba66>] timer_interrupt+0x396/0x3f2 [<ffffffff80210a87>] handle_IRQ_event+0x2d/0x60 [<ffffffff802a79ec>] __do_IRQ+0xa4/0x105 [<ffffffff802699b3>] do_IRQ+0xe7/0xf5 [<ffffffff8038dde8>] evtchn_do_upcall+0x86/0xe0 [<ffffffff8025cc1a>] do...

...ll ruleset of 3000 rules takes about 30 seconds. My questions are: 1. Should I be worried by these messages 2. Is it likely the rules are not being loaded properly 3. Is there anything I can do to get rid of the errors Best regards, Derek BUG: soft lockup detected on CPU#0! [<c044a05f>] softlockup_tick+0x98/0xa6 [<c042ccd4>] update_process_times+0x39/0x5c [<c04176ec>] smp_apic_timer_interrupt+0x5c/0x64 [<c04049bf>] apic_timer_interrupt+0x1f/0x24 [<e09aa7e3>] translate_table+0x22d/0x717 [ip_tables] [<c0406406>] do_IRQ+0xa5/0xae [<e09aadbb>] do_ipt_set_ctl+...

...[1] SMP dovecot01gluster01 kernel: CR2: 0000000000100108 <3>BUG: soft lockup detected on CPU#0! Call Trace: <IRQ> [<ffffffff80257f78>] softlockup_tick+0xd8/0xea [<ffffffff8020f110>] timer_interrupt+0x3a9/0x405 [<ffffffff80258264>] handle_IRQ_event+0x4e/0x96 [<ffffffff80258350>] __do_IRQ+0xa4/0x105 [<ffffffff8020b0e8>] call_softirq+0x1c/0x28 [<ffffffff8020cecb>] do_IRQ+0x65/0x73 [<ffffffff8034a8c1>] evtchn_do_up...

http://bugzilla.netfilter.org/show_bug.cgi?id=714 Summary: Kernel panics in same_src() Product: netfilter/iptables Version: linux-2.6.x Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: NAT AssignedTo: netfilter-buglog at lists.netfilter.org ReportedBy:

....4, have irq 10, want irq 7 PCI: Sharing IRQ 7 with 0000:00:1d.3 PCI: Sharing IRQ 7 with 0000:01:00.0 mptbase: Initiating ioc0 bringup ioc0: SAS1064E: Capabilities={Initiator} mptbase: Initiating ioc0 recovery BUG: soft lockup detected on CPU#1! Call Trace: <IRQ> [<ffffffff802a76ad>] softlockup_tick+0xdb/0xed [<ffffffff8026ba66>] timer_interrupt+0x396/0x3f2 [<ffffffff80210a87>] handle_IRQ_event+0x2d/0x60 [<ffffffff802a79ec>] __do_IRQ+0xa4/0x105 [<ffffffff802699b3>] do_IRQ+0xe7/0xf5 [<ffffffff8038dde8>] evtchn_do_upcall+0x86/0xe0 [<ffffffff8025cc1a>] do...

Hi all, This is my first post to the list, I hope someone out there can help! I am running xen 3.0.3, with CentOS 5.2 based Dom0 (kernel-xen-2.6.18-92.1.22.el5) Recently I have noticed some complete system lockups on a few different servers. Neither Dom0 or any of the guests respond to pings, connecting a keyboard and monitor to the system only shows a blank screen. Nothing is written to logs